RPKI beveiligt internet-routeringssysteem BGP

Test voor RPKI opgenomen in Internet.nl-testportal

Rood digitaal hangslot in een digitale omgeving - Cybersecurityconcept

Onlangs introduceerde het Platform Internetstandaarden een nieuwe versie van zijn Internet.nl-testportalLink opent in een nieuwe browsertab. Daarin is nu ook de beveiligingsstandaard RPKILink opent in een nieuwe browsertab opgenomen als onderdeel van de website-Link opent in een nieuwe browsertab en mail-testLink opent in een nieuwe browsertab.

RPKI is een cryptografische beveiliging voor het internet-routeringssysteem BGPLink opent in een nieuwe browsertab. Daarmee wordt het voor kwaadwillenden veel moeilijker om valse route-informatie in het systeem in te brengen, om op die manier IP-adressen te kapen of internetverkeer om te leiden. En minstens net zo belangrijk: RPKI voorkomt dat vergissingen van netwerkbeheerders verder propageren en belangrijke onderdelen en diensten afkoppelen.

Daarmee is RPKI een logische aanvulling op DNSSEC. Immers: DNSSEC garandeert de juiste vertaling van domeinnamen naar IP-adressen, terwijl RPKI zorgt dat verkeer naar die IP-adressen inderdaad op de juiste plek belandt.

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 IANALink opent in een nieuwe browsertab, 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'sLink opent in een nieuwe browsertab), die deelblokken daarvan op hun beurt weer toekennen aan de Local Internet Registries (LIR'sLink opent in een nieuwe browsertab). Onze RIR is RIPE NCCLink opent in een nieuwe browsertab, 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 (ASLink opent in een nieuwe browsertab) 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 uniekLink opent in een nieuwe browsertab; ze worden op vergelijkbare manier beheerd en toegekendLink opent in een nieuwe browsertab als de IP-adressen.

BGP

Het volgende onderdeel in dit systeem is het Border Gateway Protocol (BGP), gedefinieerd in RFC 4271Link opent in een nieuwe browsertab. Een organisatie gebruikt dit protocol om naar zijn upstream (transit) providersLink opent in een nieuwe browsertab en peersLink opent in een nieuwe browsertab 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 gatewaysLink opent in een nieuwe browsertab), 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 supernetLink opent in een nieuwe browsertab). Op die manier houdt men de grootte van de route-tabel binnen de perken.

Daarnaast worden alle routes van ‘afstanden’ voorzien: door administratieve afstandenLink opent in een nieuwe browsertab (netwerktopologische afstanden, bijvoorbeeld het aantal hopsLink opent in een nieuwe browsertab) en netwerk-Link opent in een nieuwe browsertabmetricsLink opent in een nieuwe browsertab (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 zoneLink opent in een nieuwe browsertab, de kern van het internet waar geen default-routesLink opent in een nieuwe browsertab bestaan, gaat het alles bij elkaar om meer dan een miljoen routesLink opent in een nieuwe browsertab.

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 hijackingLink opent in een nieuwe browsertab: 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-aanvallenLink opent in een nieuwe browsertab 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 [1Link opent in een nieuwe browsertab, 2Link opent in een nieuwe browsertab]. Andere opzienbarende hacks betroffen Amazon in 2018Link opent in een nieuwe browsertab (vandaar dat Cloudflare RPKI zo pushtLink opent in een nieuwe browsertab) en YouTube in 2008Link opent in een nieuwe browsertab.

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 7908Link opent in een nieuwe browsertab). Dergelijke vergissingen en lekken kunnen ertoe leiden dat een heel netwerk onbereikbaarLink opent in een nieuwe browsertab wordt.

In 2004 waren grote delen van het internet een paar uur onbereikbaarLink opent in een nieuwe browsertab 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 rootnameserverLink opent in een nieuwe browsertab in 2007-2008 werden in de overlapperiode van een half jaar verschillende ongeautoriseerde rootservers opgezetLink opent in een nieuwe browsertab. Andere gevallen betroffen onder andere Google en Spotify (in 2015)Link opent in een nieuwe browsertab.

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

Filtering

Dat dit soort aanvallen en ongelukkenLink opent in een nieuwe browsertab 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 BCPLink opent in een nieuwe browsertab38Link opent in een nieuwe browsertab (RFC 2827Link opent in een nieuwe browsertab, ingress filteringLink opent in een nieuwe browsertab om address spoofingLink opent in een nieuwe browsertab tegen te gaan), BCP 84Link opent in een nieuwe browsertab (RFC 3704Link opent in een nieuwe browsertab en 8704Link opent in een nieuwe browsertab, de Reverse-Path Forwarding (RPF-)uitbreiding voor multihomingLink opent in een nieuwe browsertab) en BCP 194Link opent in een nieuwe browsertab (RFC 7454Link opent in een nieuwe browsertab, operationele beveiliging).

RPKI

RPKILink opent in een nieuwe browsertab is een volgende stap in de bescherming van de internet-routering. Het basisprincipe van deze cryptografische beveiligingsmethode (vastgelegd in RFC 6480Link opent in een nieuwe browsertab) 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 handtekeningLink opent in een nieuwe browsertab, waarna gebruikers van deze informatie (dat wil zeggen: andere routers) de authenticiteit ervan kunnen valideren aan de hand van een certificaatketen (chain of trustLink opent in een nieuwe browsertab).

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 RPKILink opent in een nieuwe browsertab 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 anchorLink opent in een nieuwe browsertab (het startpunt van een vertrouwensketenLink opent in een nieuwe browsertab) 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 6811Link opent in een nieuwe browsertab, 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 RPKILink opent in een nieuwe browsertab).

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

Validatie

Ook de validatie van route-informatieLink opent in een nieuwe browsertab door gebruikers (de zogenaamde relying parties) begint bij de RIR's. Referenties naar hun self-signed root-certificatenLink opent in een nieuwe browsertab 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 8182Link opent in een nieuwe browsertab, 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 durenLink opent in een nieuwe browsertab).

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 8416Link opent in een nieuwe browsertab).

Het eindresultaat is nu beschikbaar voor routersLink opent in een nieuwe browsertab, die hun route-informatieLink opent in een nieuwe browsertab bij de RPKI-validator kunnen ophalen middels het RPKI-to-Router-protocol (RTRLink opent in een nieuwe browsertab, vastgelegd in RFC 8210Link opent in een nieuwe browsertab). 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 (IRRLink opent in een nieuwe browsertab). Deze begon ooit met de publicatie van RADbLink opent in een nieuwe browsertab [1Link opent in een nieuwe browsertab], een centrale database van autoritatieve route-policy’s (gespecificeerd in RPSLLink opent in een nieuwe browsertab). IRR heeft zich daarna ontwikkeld tot een netwerk van tientallen vergelijkbare registry’s, waarvan er inmiddels nog 2 dozijn over zijnLink opent in een nieuwe browsertab.

Gebruikers kunnen deze databases bevragen via het Whois-protocolLink opent in een nieuwe browsertab, inmiddels opgevolgd door RDAPLink opent in een nieuwe browsertab – 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 validationLink opent in een nieuwe browsertab: de beveiliging van BGP route-updates inclusief de onderweg stapsgewijs opgebouwde paden. Een eerste implementatie is al gestandaardiseerd, en wel als BGPsecLink opent in een nieuwe browsertab in de RFC's 8205Link opent in een nieuwe browsertab 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 [1Link opent in een nieuwe browsertab, 2Link opent in een nieuwe browsertab], 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 [1Link opent in een nieuwe browsertab, 2Link opent in een nieuwe browsertab, 3Link opent in een nieuwe browsertab, 4Link opent in een nieuwe browsertab], benadrukt Job SnijdersLink opent in een nieuwe browsertab, 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 [1Link opent in een nieuwe browsertab]. 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 (PKILink opent in een nieuwe browsertab) voor houders van internet numbers, maar dan helemaal los van de BGP-infrastructuur zelf (out-of-bandLink opent in een nieuwe browsertab). Deze gedistribueerde hiërarchie van X.509-certificatenLink opent in een nieuwe browsertab 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 ChecklistsLink opent in een nieuwe browsertab).

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 'Link opent in een nieuwe browsertabBGP StreamLink opent in een nieuwe browsertab'-Link opent in een nieuwe browsertabwebsiteLink opent in een nieuwe browsertab laat zien dat het alles bij elkaar om zo'n 5 to 25 gevallen per dag gaat. De OECD rapporteertLink opent in een nieuwe browsertab op basis van deze aggregator een totaal van meer dan 3000 incidenten in 2021, maar wel een sterk dalende trend.

Screenshot van de website https://bgpstream.crosswork.cisco.com/

Figuur 1: Screenshot van de BGP Stream-websiteLink opent in een nieuwe browsertab van CISCO.

Staafdiagram van de OECD dat inzicht geeft in het aantal keer dat netwerkbeheerders in 2021 fouten met potentieel grote consequenties maakten bij het invoeren van AS-nummers en prefixen.

Figuur 2: Rapportage over BGP-lekken en mogelijke kapingen (Bron: OECDLink opent in een nieuwe browsertab).

Opensourcesoftware

NLnet Labs heeft inmiddels 3 opensource RPKI-pakketten ontwikkeld, alle 3 geschreven in de programmeertaal RustLink opent in een nieuwe browsertab:

Maar er is nog meer dan een dozijn pakketten van andere ontwikkelaars beschikbaarLink opent in een nieuwe browsertab, waaronder:

Maarten AertsenLink opent in een nieuwe browsertab is degene die de RPKI-uitbreiding voor de Internet.nl testportal heeft geschreven, destijds in dienst van het Nationaal Cyber Security Centrum (NCSCLink opent in een nieuwe browsertab). Inmiddels is hij werkzaam bij NLnet Labs. "De ontwikkeling van Routinator en veel van de andere RPKI-toolsLink opent in een nieuwe browsertab 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 statistiekenLink opent in een nieuwe browsertab maakt inmiddels bijna de helftLink opent in een nieuwe browsertab 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 niveauLink opent in een nieuwe browsertab.

Grafiek die het aantal nameservers in de .nl-zone laat zien die beveiligd zijn met RPKI.

Figuur 3: Het aantal .nl-domeinnamen beveiligd met RPKI (Bron: stats.sidnlabs.nlLink opent in een nieuwe browsertab).

Grafiek die het aantal webservers in de .nl-zone laat zien die beveiligd zijn met RPKI.

Figuur 4: Het aantal .nl-websites beveiligd met RPKI (Bron: stats.sidnlabs.nlLink opent in een nieuwe browsertab).

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 RPKILink opent in een nieuwe browsertab 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 StreefbeeldafspraLink opent in een nieuwe browsertabaLink opent in een nieuwe browsertabkLink opent in een nieuwe browsertab 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 NCSCLink opent in een nieuwe browsertab," vertelt Bart KnubbenLink opent in een nieuwe browsertab, 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)Link opent in een nieuwe browsertab, 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 documentationLink opent in een nieuwe browsertab'. Technische details vind je in de hierboven genoemde RFC's.

Voor wie de routering van zijn netwerken moet beveiligen, is de website van MANRSLink opent in een nieuwe browsertab (Mutually Agreed Norms for Routing Security) een goed startpunt [primersLink opent in een nieuwe browsertab]. 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 actionsLink opent in een nieuwe browsertab' aanraden.

Wil je zelf testen of jouw website of maildienst RPKI al ondersteund, dan kun je daarvoor gebruikmaken van de Internet.nl-testportaalLink opent in een nieuwe browsertab.