RPKI-credentials in eigen beheer; publicatie door de RIR

Internetroutering, BGP en RPKI

RPKI is een raamwerk voor de cryptografische beveiliging van het internetrouteringssysteem BGP. Daarmee wordt het voor kwaadwillenden veel moeilijker om valse routeinformatie 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. We bespreken internetroutering, BGP en RPKI uitgebreid in dit artikel.

RPKI maakt gebruik van een wereldwijde, gedistribueerde Public-Key Infrastructuur (PKI) voor de bescherming van internetresources (IP-adressen en AS-nummers). Op dit moment is Route Origin Validation (ROV) de meest gebruikte RPKI-toepassing. Daarbij worden route-aankondigingen aan een AS-nummer gekoppeld in een Route Origin Authorisation (ROA-record) voorzien van een digitale handtekening. Die ondertekening wordt uitgevoerd door de Certificate Authorities (CA's); validatie aan afnemerszijde wordt gedaan door een RPKI-validator (de zogenaamde Relying Parties). Zo worden alleen nog valide aankondigingen aan de routers doorgegeven.

ROV biedt vooral bescherming tegen configuratiefouten; kwaadwillenden kunnen immers nog steeds het AS-pad vervalsen. In de nabije toekomst zal een aanvullende RPKI-toepassing, Autonomous System Provider Authorization (ASPA), ook de padinformatie beschermen. Door vast te leggen welke AS-nummers route-aankondigingen van een bepaald AS-nummer mogen propageren, wordt het veel moeilijker om een (plausibel) pad te vervalsen. Daarnaast biedt ASPA bescherming tegen een aantal vormen van onbedoelde routelekken.

Route Origin Validation

Op dit moment (november 2023) wordt 84 procent van de Nederlandse IPv4-adresruimte beschermd door RPKI/ROV. In totaal gaat het om 8050 VRP's (gevalideerde autorisaties voor route-aankondigingen) voor IPv4 en 3403 VRP's voor IPv6.

Figuur 1: Nederlandse VRP's voor IPv4. Bron: RIPE NCC.

Figuur 2: Nederlandse VRP's voor IPv6. Bron: RIPE NCC.

ROV in het .nl-domein

Onze eigen statistieken laten een vergelijkbaar beeld zien: ongeveer 85 procent van de websites onder het .nl-domein is via RPKI/ROV beveiligd.

Andere Europese landen

Zoals onderstaande tabel laat zien, is de adoptie van RPKI/ROV in Nederland vergelijkbaar met die in de landen om ons heen. De Verenigde Staten hebben nog een achterstand, maar lopen die nu in.

"De kinderziekten zijn er inmiddels wel uit," zegt Tim Bruijnzeels, lead developer van de Krill CA-software bij NLnet Labs. "Ook de kwaliteit van de data is de afgelopen jaren sterk verbeterd. Die ROA's moet je nu echt goed bijhouden, anders worden je routes niet meer geaccepteerd door validerende RTR-systemen."

Figuur 4: IPv4-adresruimte beschermd met RPKI/ROV. Bron: RIPE NCC.

Delegated, Hosted en Hybrid RPKI

De hoge adoptie van RPKI/ROV – een relatief nieuwe internetbeveiligingsstandaard – heeft alles te maken met de brede verscheidenheid aan configuratieset-ups. Je kunt de routeinformatie voor je prefixen zelf ondertekenen en die handtekeningen (ROA's) zelf publiceren. Daarvoor laat je de RIR naar je eigen infrastructuur verwijzen, waarmee de certificaatketen (volgens RFC 6492) naar jouw systemen wordt uitgebreid (Delegated RPKI).

Een andere mogelijkheid is om de ROA's volledig door de RIR te laten genereren en publiceren (Hosted RPKI). Alle 5 RIR's bieden een dergelijke dienst aan. Dat betekent dat bijvoorbeeld kleinere LIR's die maar één RIR gebruiken zelf geen CA-server hoeven draaien.

Hybrid RPKI zit – zoals de naam al aangeeft – ertussenin: daarbij draai je zelf een complete CA/RPKI-server (het provisioninggedeelte), maar wordt de data door de RIR overgenomen (volgens RFC 8181) voor publicatie aldaar (het publicationgedeelte). RPKI-validators hoeven dan bij het verzamelen van alle certificaten en ROA's (iets dat ze typisch elk uur opnieuw doen) niet af te dalen naar de afzonderlijke repository’s.

Cruciaal verschil voor de LIR's is dat zij in deze opzet de cryptografische sleutels zelf in beheer hebben. Bovendien kan de LIR nog steeds onderdelen van zijn adresruimte naar andere CA/RPKI-servers delegeren. Maar het belangrijkste voordeel van Hybrid RPKI bevindt zich op operationeel niveau: in deze opzet hoeft een LIR geen volwaardige publieke internetdienst op te tuigen met alle daarbij behorende eisen betreffende schaalbaarheid en beschikbaarheid. Daarnaast hoeft hij alleen verbinding te maken met één van zijn RIR's, waar hij tegelijkertijd ook de ROA's behorend bij een andere parent RIR kan laten publiceren.

Voordeel voor het RPKI-systeem als geheel is dat het aantal publication points op deze manier beperkt blijft.

Ondersteuning Hybrid RPKI

Onze RIR RIPE NCC ondersteunt Hybrid RPKI (in bèta) sinds december 2022. In februari van dit jaar kwam hun 'RPKI Publication as a Service'-dienst voor al hun LIR's beschikbaar.

Waar Hosted RPKI inmiddels bij alle 5 RIR's beschikbaar is, geldt dat nog niet voor Hybrid RPKI. ARIN en APNIC bieden een vergelijkbare dienst aan als RIPE NCC. Alle 3 RIR's beschrijven op hun website hoe je Krill voor hun Hybrid RPKI configureert [RIPE NCC, ARIN, APNIC].

De overige 2 RIR's, AFRINIC en LACNIC, ondersteunen deze mogelijkheid op dit moment nog niet. Maar omdat elke RIR ook de repository’s van de andere RIR's publiceert, maakt het in principe niet uit welke RIR je als ingang neemt voor je 'Hybrid RPKI'-setup (je moet natuurlijk wel lid zijn van de RIR die je voor publicatie wilt gebruiken).

De Krill CA/RPKI-server

Op dit moment is Krill de enige praktisch inzetbare CA/RPKI-server. De software wordt ontwikkeld door NLnet Labs en is geschreven in de moderne programmeertaal Rust. Krill laat je ROA's genereren uit prefix-ASN-combinaties, die je vervolgens zelf kunt publiceren (Delegated RPKI) of kunt laten ophalen voor publicatie door een RIR (Hybrid RPKI). In het eerste geval fungeert Krill als een zogeheten publication point, een zelfstandig repository-onderdeel van de RPKI-boom. De ROA's worden bij de Publication Server opgehaald door validators via het RRDP-protocol [RFC 8182] (daarnaast moet de content voor recursieve fetches altijd bereikbaar zijn via rsync). In het tweede geval zijn de ROA's alleen beschikbaar voor de RIR voor opname en publicatie in zijn eigen repository. De Publication Server hoef je in dit geval niet op te zetten.

Krill kan dit voor meerdere LIR's tegelijk, en voor meerdere RIR's. Eventueel kun je prefixen weer verder delegeren naar klanten of andere gebruikers die hun eigen instantie van Krill draaien. Doe je dit in 'Hybrid RPKI'-modus, dan kunnen ook deze gebruikers volstaan met een eenvoudige setup en worden hun repository’s via jouw Krill-systeem naar de RIR gestuurd.

Zowel RIPE NCC [1] als NLnet Labs [1] bieden een testomgeving die je voor experimenten en tijdens de configuratie van RPKI kunt gebruiken.

Een alternatief is de RPKI toolkit van Dragon Research Labs, maar die wordt allang niet meer onderhouden. "Hun rpkid werkt nog wel, maar is sterk verouderd," aldus Bruijnzeels. "De software is geschreven in Python 2 en ondersteunt geen nieuwere RPKI-onderdelen zoals ASPA.

Daarnaast publiceert ook RIPE NCC zijn RPKI-software als open source, maar dat is eerder vanuit oogpunt van transparantie dan om daadwerkelijk zelf te gebruiken. Deze software vormt wel weer de basis onder de (proprietary) RPKI-software die Amazon op het moment voor zijn clouddienst ontwikkelt.

Praktisch gezien is Krill nu de enige CA-server, wat betekent dat het RPKI-ecosysteem zich echt nog moet ontwikkelen."

Meer RPKI

De beveiliging van je prefixen met RPKI/ROV en het valideren van de ROA's zijn onafhankelijk van elkaar, en kunnen los van elkaar opgezet worden (het validatiegedeelte bijvoorbeeld met de Routinator validator). Daarmee heb je dan het RPKI-onderdeel dat de bron van route-aankondigingen vastlegt en valideert compleet, waarmee route hijacking maar vooral de propagatie van fouten en vergissingen wordt voorkomen.

Bruijnzeels raadt netwerkbeheerders die met RPKI aan de slag gaan aan om hun huiswerk goed te doen. Daarvoor verwijst hij naar de documentatie van RPKI, die van de Routinator, en naar de 'RPKI Community'Discord-server. Bovendien raadt hij aan om ongeldige aankondigingen niet gelijk te droppen, maar te beginnen met het loggen ervan.

Om BGP ook tegen aanvallen van kwaadwillenden te beschermen heb je ASPA nodig, een complementaire RPKI-toepassing die ook de onderdelen van de routes zelf van een digitale handtekening voorziet. Deze technologie wordt wel al ondersteund door Krill, maar is nog niet uitontwikkeld.

Voor meer informatie over de beveiliging van prefixen en routes verwijzen we je naar dit artikel waarin we RPKI, ROV, ASAP en gerelateerde beveiligingstechnologieën uitgebreider bespreken.

Wil je weten of de IP-adressen achter een specifieke domeinnaam met RPKI beschermd zijn, dan kun je daarvoor naar de Internet.nl-testportaal. Naast een heleboel andere moderne internetstandaarden test deze sinds augustus 2022 ook op RPKI/ROV-ondersteuning voor web en mail.