Stageonderzoek: Wie draait al die kleine RPKI-servers?

Wat is RPKI en waarom is het belangrijk?

Elke keer dat je een website opent, legt je internetverkeer een traject af langs tientallen routers die worden aangestuurd door het Border Gateway Protocol (BGP). BGP is de lijm van het internet: het vertelt routers waar ze pakketten naartoe moeten sturen om elk IP-adres ter wereld te bereiken. Het probleem is dat BGP is ontworpen in een tijd waarin netwerken elkaar vertrouwden en misbruik nog zeldzaam was. Daardoor kan elk netwerk – per ongeluk of opzettelijk – aankondigen dat het eigenaar is van een IP-prefix die het in werkelijkheid niet beheert. We spreken dan van een routing incident, dat ertoe kan leiden dat je internetverkeer ongemerkt naar de verkeerde bestemming wordt omgeleid.

De Resource Public Key Infrastructure (RPKI) is een van de oplossingen die het internet hiervoor heeft ontwikkeld. RPKI werkt door de rechtmatige houders van IP-adresblokken cryptografisch een Route Origin Authorization (ROA) te laten ondertekenen – een klein record waarin staat: 'IP-prefix X mag worden aangekondigd door AS-nummer Y'. Routers die Route Origin Validation (ROV) ondersteunen, gebruiken deze ondertekende records vervolgens om binnenkomende BGP-aankondigingen te controleren en de aankondigingen die niet overeenkomen te verwerpen.

Het hele systeem is gebaseerd op een vertrouwensketen waarvan de 5 Regional Internet Registries (RIR's) de ankers vormen: ARIN (Noord-Amerika), RIPE NCC (Europa/Midden-Oosten/Centraal-Azië), APNIC (Azië-Pacific), LACNIC (Latijns-Amerika) en AFRINIC (Afrika). Deze organisaties geven IP-adresruimte uit aan netwerken en beheren de hoogste RPKI-certificeringsinstanties. ROA-objecten kunnen rechtstreeks vanaf de servers van de RIR's worden gepubliceerd, of via kleinere, onafhankelijke publicatieservers.

Kleine RPKI-publicatieservers

De meeste ROA-objecten worden gepubliceerd door de 5 RIR's, die beschikken over ruime middelen, professioneel worden beheerd en wereldwijd vertrouwen genieten. Maar naast deze reuzen bestaat er een lange staart van kleinere publicatieservers, beheerd door cloudproviders, hobbyisten, onderwijsinstellingen, internetproviders (ISP's) en aanbieders van RPKI-as-a-Service (RPKIaaS). Tijdens het onderzoek dat in deze blog wordt beschreven, hebben we deze 'kleine' servers onder de loep genomen om te zien wat we ervan kunnen leren, wat de reden is om zo'n server te beheren en waarom ze überhaupt bestaan.

Wat verstaan we onder 'klein'?

De eerste methodologische uitdaging was om te bepalen wanneer een server als 'klein' kan worden beschouwd. Daarvoor hanteerden we een eenvoudige definitie op basis van het aantal ROA-objecten:

Een server wordt als 'klein' geclassificeerd als hij minder dan 1.300 ROA-objecten publiceert.

Die grenswaarde is gekozen door te kijken naar de empirische cumulatieve distributiefunctie (ECDF) van het aantal ROA's op alle bekende RPKI-servers. De verdeling is sterk scheef: een handvol grote aanbieders (de 5 RIR's en Amazon Web Services (AWS)) is verantwoordelijk voor het merendeel van alle ROA-objecten. De grens van 1.300 ROA's vormt de natuurlijke scheidslijn tussen deze grote spelers en de rest.

Eén opvallende uitzondering: de RPKI Repository Delta Protocol (RRDP)-servers van AWS. Amazon heeft zijn RPKI-publicatie-infrastructuur op een ongebruikelijke manier ingericht. De architectuur wijkt voldoende af van die van de andere kleine servers om buiten de reikwijdte van dit onderzoek te vallen. Of een dergelijke opzet operationele voordelen biedt, blijft een open vraag voor toekomstig onderzoek.

Waarom zou iemand een eigen RPKI-server draaien?

Het bestaan van kleine servers roept vanzelf de vraag op: waarom eigenlijk? De RIR's bieden immers al publicatiediensten aan als onderdeel van het lidmaatschap. Toch zijn er meerdere legitieme redenen om onafhankelijk te opereren. De onderstaande tabel geeft een aantal voorbeelden.

Tabel A: Redenen om een onafhankelijke RPKI-publicatieserver te beheren.

De dataset: IP-ruimtestatistieken

Met behulp van de Routinator-API (versie 0.15.1) haalden we op 23 april 2026 alle ROA-objecten op bij alle in aanmerking komende publicatieservers. De resulterende dataset bevat in totaal 2.467 unieke ROA's, goed voor 3.778 prefixen verspreid over 1.163 unieke AS'en. De onderstaande tabel vat de belangrijkste cijfers samen.

Geldig: er bestaat ten minste 1 Validated ROA Payload (VRP) die de aangekondigde prefix dekt (identiek of minder specifiek, binnen de maximale lengte) en waarvan het originerende AS overeenkomt.

Ongeldig: er bestaat een VRP die deze prefixruimte dekt, maar een deel van de informatie in die VRP is onjuist of het object is verlopen.

Onbekend: er is geen VRP gevonden of er is een onjuiste VRP gevonden die is verworpen.

Tabel B: Belangrijkste statistieken voor de dataset afkomstig van kleine RPKI-servers (gegevens verzameld op 23 april 2026)

Enkele cijfers springen eruit. De gedekte IPv4-ruimte (698.000 adressen, ofwel 0,016% van alle IPv4-adressen) en IPv6-ruimte (adressen of %) lijken op het eerste gezicht klein, maar zijn verre van onbeduidend. De dataset bevat prefixen die overheidsdiensten hosten – zoals gov.ai, het officiële domein van de overheid van Anguilla – en mogelijk nog andere diensten waar mensen dagelijks op vertrouwen. Het uitvallen van zulke servers zou het internet niet volledig platleggen, maar kan er stiekem wel voor zorgen dat delen ervan voor sommige gebruikers niet meer verifieerbaar zijn.

Geen van de onbekende ROA-objecten had actieve BGP-aankondigingen. Dat is goed nieuws, want anders zou dat betekenen dat de betreffende prefixen kwetsbaar zijn voor BGP-kaping.

Achter de cijfers: het serveroverzicht

De onderstaande tabel geeft per server een gecomprimeerd overzicht van de in het onderzoek verzamelde statistieken. Elke rij vertegenwoordigt 1 publicatieserver. De kolommen tonen het aantal prefixen, de verdeling van validatiestatussen, het gebruik van maxLength, de BGP-bereikbaarheid en de overlap met een blocklist van FireHOL (een partij die verschillende abuselijsten combineert om een zo uitgebreid en volledig mogelijke lijst samen te stellen van prefixen die moeten worden geblokkeerd om te zorgen voor een acceptabel veiligheidsniveau). Hieronder worden enkele rijen als voorbeeld weergegeven.

Tabel C: Gecomprimeerd overzicht van geanalyseerde RPKI-publicatieservers (top 15 op basis van aantal prefixen). 'At-risk' = risicovolle maxLength-ROA's waarvoor geen overeenkomstige BGP-aankondiging bestaat voor de geautoriseerde sub-prefixen.

In de rest van deze sectie lichten we een aantal servers uit die afwijkend gedrag vertonen en beschrijven we de ongebruikelijke gedragingen die we hebben waargenomen.

r.magellan.ipxo.com: de grootste en meest complexe

Met 776 prefixen is de Magellan-server, beheerd door het bedrijf IPXO, de grootste in de dataset. Alle 776 prefixen zijn IPv4-prefixen en 100% is bereikbaar via BGP, maar 103 prefixen zijn aangemerkt als at-risk, omdat ze ruime maxLength-instellingen hebben zonder volledige BGP-dekking van het geautoriseerde bereik.

Repo.rpki.space: spaminfrastructuur

Met slechts 79 prefixen waarvan er maar liefst 8 in de firehol_level1-blocklist voorkomen, springt repo.rpki.space meteen in het oog. Een analyse van de DNS-records voor deze server via BGP Tools laat een hoge dichtheid aan e-maildomeinen zien, wat sterk doet vermoeden dat de betreffende prefixen worden gebruikt voor spaminfrastructuur. Een mogelijke reden waarom een spamoperator een eigen RPKI-server zou draaien: de RIR's hanteren actieve procedures tegen misbruik. Een onafhankelijke publicatieserver voegt dan een stap toe aan het proces om de infrastructuur offline te halen en creëert daarmee een extra drempel voor misbruikmelders.

Ca.nat.moe: 99 onbekende objecten

Deze server is een opvallende uitschieter: alle 99 ROA-objecten hebben een onbekende validatiestatus, wat betekent dat ze niet cryptografisch gevalideerd konden worden. Desondanks is van de geldige objecten 100% bereikbaar en maken 64 ervan gebruik van maxLength.

rpki-01.pdxnet.uk: het maxLength-raadsel

Deze server kondigt bijna de helft van zijn prefixen aan met maxLength ingesteld op 32 (IPv4) of 128 (IPv6): de maximaal mogelijke prefixlengte. Dat betekent dat elk IP-adres binnen het aangekondigde bereik formeel geautoriseerd is. In de praktijk is dat niet bruikbaar: BGP accepteert geen prefixen die specifieker zijn dan /24 voor IPv4 of /48 voor IPv6, en de onderliggende prefixen zitten al op die grenzen. De reden voor deze ongebruikelijke configuratie is vooralsnog onduidelijk.

Waar komt de IP-ruimte vandaan?

Een van de interessantste structurele bevindingen betreft de RIR-herkomst van de prefixen die door kleine servers worden aangekondigd. Wanneer een organisatie ROA's op een eigen server publiceert, ligt het voor de hand om bijvoorbeeld te verwachten dat er sprake is van toewijzingen die over meerdere RIR's zijn verspreid – dus IP-ruimte afkomstig uit meerdere van de 5 regio's. Dan is het wel zo handig om een centraal publicatiepunt te hebben. Uit de data komt echter een genuanceerder beeld naar voren.

Tabel D: RIR-herkomst per publicatieserver (gecomprimeerde top 18). Een vinkje geeft aan dat er minstens 1 prefix uit die RIR aanwezig was in de ROA-set van de server.

Een aanzienlijk deel van de servers kondigt prefixen uit slechts 1 RIR aan (meestal RIPE). Voor servers die uitsluitend binnen RIPE opereren, vervalt daarmee een van de meest overtuigende redenen om een eigen server te draaien – er hoeft immers niet met meerdere RIR-accounts te worden gewerkt.

Het maxLength-probleem

Meer dan de helft van alle ROA-objecten in de dataset (53,98%) gebruikt de maxLength-parameter om aankondigingen te autoriseren voor specifiekere prefixen dan de prefix die in de ROA staat vermeld. RFC 9319 raadt deze werkwijze uitdrukkelijk af.

Een ROA voor 103.0.0.0/22 met maxLength /24 autoriseert niet alleen de /22, maar ook elke /23 en /24 binnen dat blok – van 103.0.0.0/24 tot 103.0.3.0/24 – zonder dat daarvoor aparte ROA's nodig zijn. Vanuit BGP-perspectief geldt dat de meest specifieke overeenkomende prefix voorrang krijgt. Dat betekent dat wanneer een aanvaller die controle heeft over het geautoriseerde AS-nummer de prefix 103.0.0.0/24 aankondigt, alle vertrouwende partijen die aankondiging (in principe) als geldig zullen aanmerken. De bredere ROA heeft de kaping geautoriseerd (mits er geen concurrerende BGP-aankondiging is die sneller wordt geaccepteerd en de aankondiging RPKI-geldig is).

Van de ROA's met een ruime maxLength-instelling heeft ongeveer 80% de meer specifieke sub-prefixen al gedekt door bestaande BGP-aankondigingen, waardoor het daadwerkelijke risico in de meeste gevallen beperkt blijft.

De resterende 19,6% heeft echter geen BGP-aankondiging die de geautoriseerde sub-prefixen dekt. Dat zijn potentieel risicovolle configuraties: een sub-prefixkaping met het legitieme originerende AS-nummer kan ongehinderd door de RPKI-validatie komen (opnieuw: mits er geen snellere concurrerende BGP-aankondiging is en de aankondiging RPKI-geldig is).

De oplossing is in principe eenvoudig: maak voor elke prefix die je wilt aankondigen een aparte ROA en zet maxLength op een waarde die gelijk is aan de lengte van de prefix zelf. Het nadeel is dat het aantal ROA's hierdoor aanzienlijk toeneemt – precies het tegenovergestelde van het voordeel van aggregatie dat maxLength nou net moest opleveren.

BGPsec

BGPsec is een methode waarmee kan worden gecontroleerd of de aangekondigde BGP-route door elk afzonderlijk AS in het pad cryptografisch is gevalideerd. Met andere woorden: BGPsec verifieert of elk AS in het aangekondigde pad bevestigt dat het pad geldig is. Hoewel BGPsec al sinds 2017 is gestandaardiseerd, hebben we vastgesteld dat BGPsec (niet alleen in onze dataset) in de praktijk simpelweg niet wordt toegepast – er is slechts 1 AS dat zijn BGPsec-sleutels aankondigt. Dit wordt ook opgemerkt door Lisa Bruder in haar blogpost: BGPsec - Zou je het kunnen draaien als je dat wilde?.

Een reactie van een operator

We hebben contact opgenomen met Axivora – een van de grotere operators en beheerder van rpki.cc, krill.accuristechnologies.ca en rpki.folf.systems – om erachter te komen waarom het een eigen RRDP-notificatieserver draait. We ontvingen de volgende reactie:

Het korte antwoord is dat we oorspronkelijk onze eigen RPKI-publicatie-infrastructuur zijn gaan draaien omdat we internetfanaten waren (en nog steeds zijn) die wilden achterhalen hoe het systeem precies werkt.

Axivora huurt nog steeds twee dedicated IPv6 PA /40-toewijzingen voor educatieve en onderzoeksdoeleinden. Binnen die prefixen delegeert het bedrijf kleinere blokken aan partijen die hun eigen onafhankelijke adresruimte willen hebben. Axivora neemt hen de logistiek rond het aanmaken van de bijbehorende ROA en IRR-records uit handen en zorgt ervoor dat ze geen eigen AS-nummer hoeven te beheren.

De oorspronkelijke reden om een eigen publicatie-infrastructuur te draaien was om meer inzicht te krijgen in het RPKI-ecosysteem en te leren hoe ROA's zich door het internet verspreiden.

Tegenwoordig maakt het bedrijf voor alle zakelijke prefixen gebruik van de PaaS-diensten van RIPE, maar beheert het nog steeds een eigen publicatieserver voor onderzoeks-, educatieve en experimentele doeleinden.

En eerlijk gezegd vinden we het nog steeds heel leuk.

Conclusie

Alles bij elkaar wijzen de data erop dat kleine RPKI-publicatieservers slechts een relatief bescheiden hoekje van het internet beslaan. Hoewel de prefixen die ze dekken gezamenlijk maar een fractie van de totale IP-adresruimte vormen, omvatten ze wel enkele cruciale diensten, zoals overheidsdomeinen. Het uitvallen van dergelijke servers zou het internet als geheel niet ontwrichten, maar zou wel gevolgen hebben voor de verifieerbaarheid van het internet en er mogelijk toe leiden dat specifieke prefixen onbereikbaar worden.

Aan de validatiekant ziet het beeld er betrekkelijk gezond uit: 92,4% van de ROA-objecten is geldig, en van die objecten heeft 91% een actieve, overeenkomende BGP-aankondiging. De enige opvallende bevinding is dat het percentage met onbekende validatiestatus met 7,6% relatief hoog is.

Een duidelijker punt van zorg is het gebruik van maxLength. Meer dan de helft van de ROA-objecten hield zich niet aan de aanbevelingen uit RFC 9319, wat op zich niet problematisch hoeft te zijn. Van die objecten had echter 19,6% geen BGP-aankondigingen die alle toegestane sub-prefixen dekten. Hierdoor ontstaat een relatief beperkt maar relevant risico dat deze sub-prefixen kunnen worden gekaapt. Dat risico geldt overigens niet alleen voor deze publicatieservers en zou heel goed ook bij grotere publicatieservers kunnen bestaan.

Andere beschermende technologieën bleken evenmin te zijn ingezet op de servers die we onderzochten. BGPsec werd helemaal niet toegepast.

Wat betreft de redenen waarom operators ervoor kiezen hun eigen infrastructuur te draaien, wijzen de data er in grote lijnen op dat eenvoud bij het werken met meerdere RIR's de belangrijkste drijfveer is, maar niet de enige. Educatieve doeleinden bleken een minder vaak voorkomende motivatie dan aanvankelijk verwacht.