RPKI beveiligt internet-routeringssysteem BGP

IP-adresblokken en Autonomous Systems

Om te begrijpen hoe RPKI de BGP-infrastructuur beschermt, moeten we eerst begrijpen hoe internet-routering en het BGP-protocol werken. Dat begint bij IANA, die (onder andere) alle IP-adressen beheert (zowel voor IPv4 als IPv6). Blokken van die adressen worden toegekend aan de 5 Regional Internet Registries (RIR's), die deelblokken daarvan op hun beurt weer toekennen aan de Local Internet Registries (LIR's). Onze RIR is RIPE NCC, verantwoordelijk voor groot-Europa en West-Azië. En bij de LIR's moet je denken aan internetproviders, grote ondernemingen en andere grote organisaties.

Om een ‘eigen’ adresblok te kunnen krijgen, moet een organisatie lid worden van een RIR (als LIR) en daar een Autonomous System Number (ASN) aanvragen. Maar ook kleinere organisaties kunnen (via een LIR) een ASN krijgen. Een daarmee aangeduid Autonomous System (AS) moet je zien als een technisch-administratief onafhankelijk onderdeel van het internetnetwerk. De adresblokken die de betreffende organisatie onder zich heeft zijn via de RIR/LIR gekoppeld aan haar AS-nummer. Net als de IP-adressen zelf zijn ook de AS-nummers wereldwijd uniek; ze worden op vergelijkbare manier beheerd en toegekend als de IP-adressen.

BGP

Het volgende onderdeel in dit systeem is het Border Gateway Protocol (BGP), gedefinieerd in RFC 4271. Een organisatie gebruikt dit protocol om naar zijn upstream (transit) providers en peers te communiceren welke IP-adressen bij haar thuishoren, zodat zij verkeer dat voor de betreffende organisatie (of achterliggende netwerken) is bestemd daar ook kunnen afleveren. In technische termen: de routers in een AS die ook met routers in andere AS'en zijn verbonden (de border gateways), gebruiken BGP om onderling routes uit te wisselen. Onder een route wordt hier verstaan een bereikbare adresreeks (het destination prefix) met het bijbehorende pad daarnaartoe (een lijst van met elkaar verbonden AS-nummers, stapsgewijs opgebouwd bij de propagatie van de route-informatie).

Binnenkomende route-informatie wordt eerst gecombineerd met de bestaande en eigen (lokale) routes, en daarna waar mogelijk geoptimaliseerd. Dat laatste houdt in dat prefixen waarvan het eerste gedeelte hetzelfde is en waarvoor de netwerkpakketten dezelfde kant op moeten, worden gecombineerd (geaggregeerd) tot een korter prefix (een zogenaamd supernet). Op die manier houdt men de grootte van de route-tabel binnen de perken.

Daarnaast worden alle routes van ‘afstanden’ voorzien: door administratieve afstanden (netwerktopologische afstanden, bijvoorbeeld het aantal hops) en netwerk-metrics (bijvoorbeeld bandbreedte, betrouwbaarheid en kosten) te combineren, worden onderlinge prioriteiten en voorkeuren vastgesteld (best path selection).

Tenslotte voegt de router zijn eigen AS-nummer als eerste stap toe aan de paden, om deze routes tenslotte weer te delen met andere routers (propagatie).

Op die manier is uiteindelijk (binnen een paar minuten) overal op internet bekend welke volgende hop het snelst en het meest betrouwbaar is om een netwerkpakket naar toe te sturen op weg naar zijn eindbestemming. In de default-vrije zone, de kern van het internet waar geen default-routes bestaan, gaat het alles bij elkaar om meer dan een miljoen routes.

Op beheerniveau is BGP aanzienlijk complexer en uitgebreider dan hier beschreven, maar voor nu volstaat deze uitleg.

Aanvallen

De meest eenvoudige aanval op dit systeem is route hijacking: het kapen van een andermans route (dat wil zeggen: zijn IP-adressen). Het enige dat een aanvaller daarvoor hoeft te doen is om via BGP een route met een technisch-economisch hogere score voor het betreffende prefix te adverteren. Vaak gebeurt dit door een route met een langere (meer specifieke) prefix aan te kondigen. Op die manier kan een kwaadwillende verkeer dat niet voor hem bestemd is naar zich toe halen, of een adresreeks misbruiken om spam-berichten te versturen of DoS-aanvallen uit te voeren.

Een bekende Nederlandse casus is die van 2014 waarbij een (op dat moment ongebruikte) adresreeks van het Ministerie van Buitenlandse Zaken werd gekaapt door Bulgaarse criminelen [1, 2]. Andere opzienbarende hacks betroffen Amazon in 2018 (vandaar dat Cloudflare RPKI zo pusht) en YouTube in 2008.

Ongelukken

Maar veel vaker betreft het gevallen waarbij foutieve route-informatie per ongeluk wordt geannonceerd, of correcte informatie per ongeluk wordt gepropageerd buiten zijn bedoelde scope (een zogenaamd route-lek, in detail besproken in RFC 7908). Dergelijke vergissingen en lekken kunnen ertoe leiden dat een heel netwerk onbereikbaar wordt.

In 2004 waren grote delen van het internet een paar uur onbereikbaar voor grote groepen gebruikers, nadat de Turkse provider TTNET zijn hele routetabel naar al zijn transitproviders had laten lekken. En bij de omschakeling van het IP-adres van de L rootnameserver in 2007-2008 werden in de overlapperiode van een half jaar verschillende ongeautoriseerde rootservers opgezet. Andere gevallen betroffen onder andere Google en Spotify (in 2015).

RFC 4272 geeft een gedetailleerd overzicht van de kwetsbaarheden van BGP. De consequenties voor DNS in het bijzonder worden besproken in dit ICANN-SSAC-rapport.

Filtering

Dat dit soort aanvallen en ongelukken kunnen plaatsvinden, heeft te maken met het ontwerp van BGP, dat van origine open staat voor alle route-updates aangeboden door transitproviders en peers. En ondanks dat netwerkbeheerders bijhouden welke routes hun partners en klanten mogen aanbieden, blijkt een strikte filtering op die afspraken in de praktijk vaak niet te gebeuren.

De aanbevelingen voor filtering op basis van afzenderadres zijn vastgelegd in BCP38 (RFC 2827, ingress filtering om address spoofing tegen te gaan), BCP 84 (RFC 3704 en 8704, de Reverse-Path Forwarding (RPF-)uitbreiding voor multihoming) en BCP 194 (RFC 7454, operationele beveiliging).

RPKI

RPKI is een volgende stap in de bescherming van de internet-routering. Het basisprincipe van deze cryptografische beveiligingsmethode (vastgelegd in RFC 6480) is niet fundamenteel anders dan dat van DNSSEC: in dit geval voorzien houders van IP-adressen en AS-nummers hun route-informatie van een digitale handtekening, waarna gebruikers van deze informatie (dat wil zeggen: andere routers) de authenticiteit ervan kunnen valideren aan de hand van een certificaatketen (chain of trust).

Op deze manier wordt voorkomen dat valse route-informatie geïnjecteerd in het BGP-systeem daadwerkelijk in de routers belandt, waarmee het voor kwaadwillenden veel moeilijker wordt om IP-adressen te kapen of internetverkeer om te leiden. En minstens net zo belangrijk: om te voorkomen dat vergissingen van netwerkbeheerders verder propageren en belangrijke onderdelen en diensten afkoppelen. Uitgangspunt is immers dat houders geen handtekening kunnen zetten onder route-informatie die niet van hen is.

Daarbij moeten we gelijk een belangrijke kanttekening maken: op dit moment beveiligt RPKI alleen de koppeling tussen AS-nummers en prefixen (Route Origin Validation, ROV). De beveiliging van de pad-informatie (path validation) is nog niet uitontwikkeld.

Route Origin Validation

De certificaatketen voor RPKI begint bij de vijf RIR's, die elk een eigen trust anchor (het startpunt van een vertrouwensketen) hebben. LIR's krijgen van hun RIR een digitaal ondertekend houdercertificaat specifiek voor hun eigen AS-nummers en prefixen, waarmee ze op hun beurt route-informatie voor die AS-nummers en prefixen kunnen ondertekenen.

Voor ROV, vastgelegd in RFC 6811, heeft dit de vorm van een Route Origination Authorization (ROA), die aangeeft welke AS-nummers een bepaalde route mogen aankondigen (de origins). Door een ROA te publiceren voor andere AS-nummers dan zijn eigen nummer, kan een houder bovendien ook anderen toestemming geven om routes voor zijn prefixen aan te kondigen. En andersom: heb je een ROA gepubliceerd, dan kunnen anderen (of jijzelf) niet jouw prefixen onder een ongeautoriseerd AS-nummer aankondigen (of dat nu per ongeluk of expres is).

Gedelegeerde of gehoste RPKI

Waar deze ROA's gepubliceerd worden, is afhankelijk van de configuratie aan houderzijde. RPKI is in principe een gedistribueerd systeem. Dat betekent dat je zelf je eigen certificaten en ROA's kunt genereren en publiceren. Vervolgens laat je de RIR naar je eigen infrastructuur verwijzen, waarmee de certificaatketen naar jouw systemen wordt uitgebreid (delegated RPKI).

Maar alle 5 RIR's bieden ook een dienst waarbij hun LIR's de ROA's door de RIR kunnen laten publiceren (hosted RPKI). Dat betekent dat bijvoorbeeld kleinere LIR's die maar één RIR gebruiken zelf geen CA-server hoeven draaien.

Validatie

Ook de validatie van route-informatie door gebruikers (de zogenaamde relying parties) begint bij de RIR's. Referenties naar hun self-signed root-certificaten zitten meestal al als trust anchor ingebakken in de RPKI validator-software (via de trust anchor locators, TAL's).

Bij het opstarten haalt een validator alle certificaten en ROA's binnen (tegenwoordig meestal via het RRDP-protocol, gedefinieerd in RFC 8182, hoewel de ondersteuning van rsync nog steeds verplicht is). Voor hosted RPKI kan hij direct bij de RIR's terecht. Voor delegated RPKI volgt de validator de gedistribueerde vertrouwensketen van certificaten naar beneden tot aan de repository waar hij de ROA's met bijbehorende certificaten kan vinden.

RTR-servers

Al die certificaten en ROA's worden gevalideerd en verzameld in een cache (de VRP-cache), waarna bijvoorbeeld elk uur updates worden opgevraagd en verwerkt. Deze cache wordt vervolgens gebruikt om binnenkomende route-aankondigingen te valideren. Bij het doorzetten krijgen geauthentiseerde routes de voorkeur boven routes waarvoor (nog) geen RPKI-informatie beschikbaar is. Aankondigingen die ongeldig blijken, worden simpelweg gedropt.

Als RPKI in de toekomst eenmaal overal ingevoerd is, is het idee om uiteindelijk ook de aankondigingen zonder handtekening niet meer te accepteren. Maar het valt nog te bezien of het daadwerkelijk zo ver gaat komen (Fastly spreekt over een ontwikkel- en adoptietijd van secure routing die decennia kan duren).

In een laatste stap kunnen netwerkbeheerders de globale RPKI-informatie nog combineren met eigen (lokale) policy’s en uitzonderingen. Daarvoor gebruiken zij de SLURM-specificatietaal (gedefinieerd in RFC 8416).

Het eindresultaat is nu beschikbaar voor routers, die hun route-informatie bij de RPKI-validator kunnen ophalen middels het RPKI-to-Router-protocol (RTR, vastgelegd in RFC 8210). Omwille van de robuustheid is een router bij voorkeur verbonden met meerdere van deze RTR-servers.

De Internet Routing Registry

De ROV-functionaliteit van RPKI is de opvolger van de Internet Routing Registry (IRR). Deze begon ooit met de publicatie van RADb [1], een centrale database van autoritatieve route-policy’s (gespecificeerd in RPSL). IRR heeft zich daarna ontwikkeld tot een netwerk van tientallen vergelijkbare registry’s, waarvan er inmiddels nog 2 dozijn over zijn.

Gebruikers kunnen deze databases bevragen via het Whois-protocol, inmiddels opgevolgd door RDAP – dezelfde twee protocollen die ook door de RIR's worden aangeboden om hun 'internet number'-databases te bevragen.

Routers kunnen de IRR gebruiken in hun filtering en om de authenticiteit van route-informatie te verifiëren, maar het netwerk heeft geen officiële status en de informatie wordt inmiddels ook minder nauwkeurig bijgehouden. De RPSL-specificatietaal kan heel uitgebreide policy’s beschrijven, maar IRR wordt nu alleen nog maar gebruikt om informatie betreffende de houders te publiceren.

Path validation

Zoals gezegd implementeert RPKI op dit moment alleen de ROV-functionaliteit: de geauthentiseerde koppeling van geautoriseerde AS-nummers aan prefixen. Deze technologie wordt inmiddels ook ondersteund door alle vijf RIR's, door alle opensource routersoftware en door alle routers.

Het volgende onderdeel is path validation: de beveiliging van BGP route-updates inclusief de onderweg stapsgewijs opgebouwde paden. Een eerste implementatie is al gestandaardiseerd, en wel als BGPsec in de RFC's 8205 tot en met 8209.

BGPsec

BGPsec breidt het BGP-protocol uit met Secure Paths. Daarbij wordt voor elke nieuwe node (een AS-nummer) die wordt toegevoegd aan het pad ook een nieuwe digitale handtekening bijgevoegd. Die handtekening dekt niet alleen het nieuwe AS-nummer maar ook het daarachterliggende pad met eerdere handtekeningen. Bovendien wordt ook het AS-nummer van de ontvangende partij onder die handtekening meegenomen.

Daarmee kunnen validators verifiëren dat een BGP update-bericht voor hen bestemd is, en dat het opgebouwde pad vanaf de origin authentiek is. De eerder besproken ROV-functie bewijst dat de origin zelf inderdaad gemachtigd is om de betreffende route aan te kondigen, waarmee de hele keten gesloten is.

Deze implementatie van Secure Paths vraagt echter nogal wat resources aan de zijde van de resolvers. Die moeten immers een recursieve cascade van digitale handtekeningen verifiëren om het hele opgebouwde pad te valideren. Bovendien werkt BGPsec alleen als alle nodes onderweg dit protocol ondersteunen (anders wordt teruggeschakeld naar het originele AS-pad-systeem).

ASPA

Autonomous System Provider Authorization (ASPA), waarvan de specificatie op dit moment nog in ontwikkeling is [1, 2], past de concepten van geauthentiseerde origins toe op de propagatie van routes. Zoals een ROA-record aangeeft welke AS-nummers een bepaalde route mogen aankondigen, zo specificeert een ASPA-record welke AS-nummers route-aankondigingen van een bepaald AS-nummer mogen propageren. Het idee is dat organisaties op die manier vastleggen wie hun upstream providers en peers zijn (in feite een beschrijving van zakelijke overeenkomsten en de daaruit volgende AS-topologie), en dat die geauthentiseerde informatie via de RPKI-infrastructuur overal bekend is.

Door de ASPA's op dezelfde wijze te publiceren en distribueren als de ROA's, kan een validator direct vanuit zijn gevalideerde ASPA-cache de individuele schakels in het pad valideren. Maar omdat op deze manier niet het daadwerkelijk gevolgde (onderweg opgebouwde) pad is gegarandeerd, maar alleen gevalideerd kan worden of het doorgegeven pad past in de AS-topologie, spreekt men hier van path plausibility in plaats van path validation.

Naast de eenvoud en efficiëntie biedt ASPA nog een ander belangrijk voordeel ten opzichte van BGPsec: alle individuele schakels waarvoor een ASPA-record is gepubliceerd kunnen onafhankelijk van elkaar worden gecontroleerd, waarmee iedere organisatie die ASPA gaat gebruiken direct de veiligheid en foutbestendigheid van zijn BGP-infrastructuur verbetert.

Hoewel ASPA eerder werd gepositioneerd als een generieker en efficiënter alternatief voor BGPsec [1, 2, 3, 4], benadrukt Job Snijders, medeauteur van de ASPA-specificatie, dat ASPA een zelfstandige technologie is naast BGPsec, met een eigen beveiligingsfunctie. Origin validation en path validation beveiligen weliswaar de route zoals die is gepubliceerd en gepropageerd, maar beschermen niet tegen fouten gemaakt door legitieme partijen. ASPA moet dan ook vooral beschermen tegen routelekken.

Daarnaast gaat Snijders (en zijn werkgever Fastly) ervan uit dat het een kwestie van tijd is voordat routerhardware voldoende resources aan boord heeft om BGPsec volledig te kunnen ondersteunen [1]. Wat hem betreft moeten in de toekomst zowel BGPsec als ASPA beschikbaar komen voor netwerk-operators en moeten RIR's beide technologieën ondersteunen.

RPKI als generiek beveiligingsplatform

Strikt genomen zijn ROV, BGPsec en ASPA geen onderdeel van RPKI, maar bouwen ze daarop voort (zoals bijvoorbeeld DANE gebruikmaakt van de fundering die met DNSSEC is gelegd). Op vergelijkbare wijze levert RPKI in dit geval een Public Key Infrastructure (PKI) voor houders van internet numbers, maar dan helemaal los van de BGP-infrastructuur zelf (out-of-band). Deze gedistribueerde hiërarchie van X.509-certificaten vormt een generiek beveiligingsplatform waarop vervolgens toepassingen kunnen worden gebouwd, waarvan ROV, BGPsec en ASPA er 3 zijn.

ROV en BGPsec zijn weliswaar complementair, maar kunnen in principe ook onafhankelijk van elkaar gebruikt worden. Op dit moment gebruiken we vooral RPKI met ROV en is het idee om daar later path validation aan toe te voegen. Nog later zou ASPA daar weer als derde naast gezet kunnen worden. Een volgende RPKI-toepassing die nu op het punt staat als RFC gepubliceerd te worden is RSC (RPKI Signed Checklists).

De waarde van RPKI met ROV

Dat path validation op dit moment nog niet wordt toegepast, wil niet zeggen dat RPKI met ROV geen waarde heeft. Integendeel: de transit-netwerken in de kern van internet wisselen zo veel verkeer uit dat daar enorm veel peering-overeenkomsten worden afgesloten, waarmee die netwerken dan directe buren worden. Dat betekent dat het voor een buitenstaander sowieso heel moeilijk is om daar een beter scorende route te injecteren.

ROV beschermt op dit moment dan ook vooral tegen vergissingen, waarbij netwerkbeheerders fouten met potentieel grote consequenties maken bij het invoeren van AS-nummers en prefixen.

De 'BGP Stream'-website laat zien dat het alles bij elkaar om zo'n 5 to 25 gevallen per dag gaat. De OECD rapporteert op basis van deze aggregator een totaal van meer dan 3000 incidenten in 2021, maar wel een sterk dalende trend.

Figuur 1: Screenshot van de BGP Stream-website van CISCO.

Figuur 2: Rapportage over BGP-lekken en mogelijke kapingen (Bron: OECD).

Opensourcesoftware

NLnet Labs heeft inmiddels 3 opensource RPKI-pakketten ontwikkeld, alle 3 geschreven in de programmeertaal Rust:

• Routinator: een RPKI-client bestaande uit een validator en een RTR-server

• RTRTR: een RTR-proxy waarmee voor grote gedistribueerde netwerkinfrastructuren een extra laag (cascade) van cachende RTR-servers kan worden opgezet

• Krill: een RPKI CA-server voor het zelf opzetten van een 'Delegated RPKI'-systeem

Maar er is nog meer dan een dozijn pakketten van andere ontwikkelaars beschikbaar, waaronder:

• OctoRPKI: een RPKI-validator/library (Cloudflare's RPKI Toolbox)

• StayRTR: een RTR-server; een fork van GoRTR (Cloudflare, niet langer onderhouden)

• rpki-client: een RPKI-validator (OpenBSD, portable client)

• FORT Validator: een RPKI-validator en RTR-server (NIC.mx, als onderdeel van het FORT-project)

• BGPalerter: een BGP/RPKI monitoring tool

Maarten Aertsen is degene die de RPKI-uitbreiding voor de Internet.nl testportal heeft geschreven, destijds in dienst van het Nationaal Cyber Security Centrum (NCSC). Inmiddels is hij werkzaam bij NLnet Labs. "De ontwikkeling van Routinator en veel van de andere RPKI-tools gaat terug tot de tijd dat RPKI zelf nog in ontwikkeling was," zegt hij. "Destijds was er alleen maar experimentele software beschikbaar, geschreven door degenen die aan de standaard werkten en door de RIR's die hun infrastructuur optuigden. Ons doel was bij te dragen aan een divers ecosysteem van stabiele RPKI-implementaties. Krill is op dit moment zelfs de enige opensource CA-server die onderhouden wordt. Daar vullen we dus een gat, in lijn met onze missie."

Adoptie

Volgens onze eigen statistieken maakt inmiddels bijna de helft van de .nl-domeinen gebruik van autoritatieve nameservers die op een netwerk draaien beveiligd met RPKI plus ROV. Tellen we daar de gedeeltelijk beveiligde domeinen bij op (dat wil zeggen: de domeinen waarvan niet alle nameservers op een beveiligd netwerk draaien), dan komen we in totaal op driekwart uit. De adoptie voor webservers ligt grofweg op hetzelfde niveau.

Figuur 3: Het aantal .nl-domeinnamen beveiligd met RPKI (Bron: stats.sidnlabs.nl).

Figuur 4: Het aantal .nl-websites beveiligd met RPKI (Bron: stats.sidnlabs.nl).

Op dit moment zijn er bij ons nog geen concrete plannen om een incentive-regeling voor RPKI op te tuigen. Wel is het een onderwerp dat we met de Vereniging van registrars (VvR) zullen bespreken.

Vanzelfsprekend hebben we wel onze eigen infrastructuur met RPKI beveiligd.

Nederlandse overheidsorganisaties

Hoewel RPKI wel al sinds eind 2019 op de 'pas toe of leg uit'-lijst (ptolu) van Forum Standaardisatie staat, is er voor deze beveiligingsstandaard nog geen overheidsbrede Streefbeeldafspraak met een uiterste implementatiedatum gemaakt zoals dat voor DNSSEC, SPF/DKIM/DMARC, DANE en IPv6 wel het geval is. "RPKI staat al even op de lijst en werd ook eerder al gestimuleerd door NCSC," vertelt Bart Knubben, coördinerend adviseur bij Forum Standaardisatie. "We hebben gezien dat verschillende overheidsorganisaties, waaronder Logius, SSC-ICT, DICTU en de Belastingdienst, daardoor RPKI hebben geïmplementeerd."

"Met de nieuwe RPKI-test in Internet.nl kunnen we nu een eerste nulmeting doen over alle overheidsdomeinen. Mede op basis van die nulmeting besluit Forum Standaardisatie of er ook voor RPKI een Streefbeeldafspraak moet komen."

Uit de laatste Monitor Open Standaarden (november 2021), waarin RPKI voor de eerste keer is meegenomen in het onderzoek naar de infrastructuur van overheidsdiensten, blijkt dat deze standaard in 95 procent van de gevallen relevant was. Bij 72 procent van de 19 onderzochte diensten werden inderdaad RPKI ROA's gepubliceerd.

Meer informatie

Voor meer informatie omtrent RPKI verwijzen we je graag naar de 'RPKI documentation'. Technische details vind je in de hierboven genoemde RFC's.

Voor wie de routering van zijn netwerken moet beveiligen, is de website van MANRS (Mutually Agreed Norms for Routing Security) een goed startpunt [primers]. En voor een beleidsmatige bespreking van de beveiliging van de internet-routering gericht op overheden kunnen we het OECD-rapport 'Routing security; BGP incidents, mitigation techniques and policy actions' aanraden.

Wil je zelf testen of jouw website of maildienst RPKI al ondersteund, dan kun je daarvoor gebruikmaken van de Internet.nl-testportaal.