Een Route Origin Authorization is een digitaal ondertekend RPKI een record dat aangeeft welke ASN het recht heeft om een IP-prefix in BGP te origineren. Het wordt aangemaakt door, of namens, de organisatie die de relevante Internet-nummerbronnen bezit. Een ROA bevat doorgaans drie essentiële elementen: de IP-prefix, de geautoriseerde oorsprongs-ASN en de maximale prefixlengte die de ASN mag aankondigen. Zo kan een organisatie bijvoorbeeld de IPv4-prefix 203.0.113.0/24 beheren en AS64500 gebruiken om deze aan te kondigen. Een bijbehorende ROA kan AS64500 autoriseren om die /24 te origineren. In eenvoudige termen communiceert het record de volgende instructie aan het routingecosysteem: “Deze ASN is gemachtigd om deze prefix aan te kondigen.” Netwerken die RPKI-validatie uitvoeren, kunnen vervolgens het record vergelijken met wat ze waarnemen in BGP. Een ROA overdraagt geen eigendom van een IP-adresblok. Het vervangt geen contract, registratie-invoer, toewijzingsrecord of IPv4-overeenkomst voor transfer. Het publiceert uitsluitend een autorisatie met betrekking tot de oorsprong van een route. Juridische controle en routingautorisatie zijn met elkaar verbonden, maar niet hetzelfde. ROAs kunnen worden aangemaakt voor zowel IPv4- als IPv6-bronnen. De opmaak is vergelijkbaar, hoewel de prefixlengtes en operationele ontwerpen kunnen verschillen. IPv4-netwerken werken vaak met prefixes zoals /24, terwijl IPv6-netwerken doorgaans aggregaten aankondigen zoals /32, /36, /48 of een andere lengte die past bij hun toewijzing en routeplan.
Waarom is een ROA nodig?
Zonder een ROA hebben andere netwerken geen RPKI-gebaseerde autorisatie om te bevestigen dat een BGP-origin ASN het recht heeft een prefix aan te kondigen. De route kan nog steeds legitiem zijn, maar zal doorgaans tijdens RPKI-validatie een resultaat opleveren van 'Not Found' omdat er geen bijpassende autorisatie is. Een 'Not Found'-resultaat is niet automatisch een routingprobleem. Veel geldige routes op internet hebben geen ROA's. Wanneer een organisatie echter een accurate ROA publiceert, geeft dit andere netwerken een sterker signaal waarmee de verwachte origin onderscheiden kan worden van een ongeautoriseerde of verkeerd geconfigureerde origin. Een ROA wordt vooral nuttig wanneer een prefix waardevol is, bedrijfskritiek, of breed wordt aangekondigd. Een enterprise kan zijn eigen adresruimte gebruiken voor publieke diensten, kan een cloudplatform klantinfrastructuur aankondigen, of een hostingprovider kan grote adresbereiken vanuit meerdere locaties adverteren. In deze situaties kan een onjuiste origin veel gebruikers en diensten beïnvloeden. ROA's helpen ook tijdens incidentrespons. Als een prefix plotseling verschijnt vanuit een onverwachte ASN, kan een netwerkoperator de RPKI-status controleren en snel vaststellen of de aankondiging in conflict is met de gepubliceerde intentie van de resourcehouder. Dit verklaart niet elk detail van het incident, maar biedt wel een belangrijk startpunt voor onderzoek. Voor organisaties die meerdere upstreamproviders gebruiken, kan een ROA een consistente autorisatie bieden, ongeacht welke provider de route draagt. De provider kan veranderen, maar de origin ASN kan hetzelfde blijven. In dat geval hoeft de ROA meestal niet te worden gewijzigd alleen omdat het transitpad is veranderd.
Hoe werkt een ROA met BGP?
BGP verspreidt route-aankondigingen tussen autonome systemen. Een route-aankondiging bevat meestal een IP-prefix en een oorsprong-ASN, samen met andere pad- en beleidsinformatie. De oorsprong-ASN is het autonome systeem dat beweert de bron van de route te zijn. RPKI-validatie werkt parallel aan BGP. Een validator haalt gesigneerde autorisatiegegevens op uit het RPKI-systeem en controleert of de records authentiek en actueel zijn. Vervolgens wordt een gevalideerde dataset aangemaakt die gebruikt kan worden door routers, routeservers of routingbeleidsystemen. Wanneer een netwerk een BGP-aankondiging ontvangt, vergelijkt het de aangekondigde prefix en oorsprong-ASN met de gevalideerde ROA-informatie. Er zijn drie primaire uitkomsten: de aankondiging kan Valid, Invalid of Not Found zijn. Een Valid-resultaat betekent dat de aankondiging onder een ROA valt en dat de oorsprong-ASN geautoriseerd is. Een Invalid-resultaat betekent dat er een relevante ROA bestaat, maar dat de aankondiging hiermee in conflict is. Een Not Found-resultaat betekent dat geen toepasselijke ROA is gevonden. Het ontvangende netwerk beslist wat te doen met deze resultaten. Sommige operators verwerpen Invalid-routes. Anderen wijzen ze een lagere voorkeur toe, genereren een waarschuwing of passen verschillend beleid toe afhankelijk van de bron. Er is geen universeel beleid voor elk netwerk, maar veel providers behandelen Invalid-aankondigingen als een ernstig probleem voor de routingbeveiliging. Het belangrijke punt is dat de ROA niet direct de globale internetstroom regelt; deze publiceert alleen autorisatie-informatie. Het praktische effect hangt af van het feit of andere netwerken deze informatie ophalen, valideren en gebruiken in hun routingbeslissingen.
De drie belangrijkste onderdelen van een ROA
Het eerste deel van een ROA is het geautoriseerde IP-prefix, dat het adresbereik identificeert dat de oorsprongs-ASN mag aankondigen. Voor IPv4 kan een prefix bijvoorbeeld 198.51.100.0/24 zijn; voor IPv6 kan het 2001:db8:1234::/48 zijn. Het prefix moet overeenkomen met een resource die de organisatie gemachtigd is te beheren via de relevante registry of sponsoring-relatie. Het prefix moet nauwkeurig worden ingevoerd, omdat een typefout, een onjuiste netwerk-grens of een verkeerde prefixlengte de ROA onwerkzaam kan maken of een ander bereik kan autoriseren dan bedoeld.
Het tweede onderdeel is de oorsprongs-ASN die gemachtigd is om het prefix te origineren, overeenkomend met de ASN die verschijnt als de oorsprong van de BGP-aankondiging. Als een bedrijf een adresblok bezit maar dit aankondigt via de ASN van een transitprovider, hangt de juiste oorsprong af van het daadwerkelijke routingontwerp. De ASN in de ROA moet normaal gesproken de ASN zijn die de route origineert, niet simpelweg de ASN van de upstream-carrier. Dit onderscheid is belangrijk omdat een transitprovider een route kan transporteren zonder dat hij de oorsprong is; als de ASN van de klant het prefix origineert en de provider deze alleen transporteert, is doorgaans de ASN van de klant de waarde die gemachtigd moet worden.
Het derde onderdeel is de maximale prefixlengte, vaak aangeduid als maxLength, die bepaalt hoe specifiek een aankondiging mag zijn terwijl deze nog steeds wordt gedekt door het ROA. Stel dat een ROA 198.51.100.0/24 autoriseert met een maximale lengte van /24: de geautoriseerde ASN mag dan exact de /24 aankondigen, maar het is niet geautoriseerd om kleinere sub-prefixen zoals /25 of /26 aan te kondigen. Als hetzelfde prefix wordt geautoriseerd met een maximale lengte van /26, kunnen aankondigingen voor de /24, /25 en /26 als gedekt worden beschouwd, afhankelijk van de exacte route en validatieregels. Dit biedt flexibiliteit, maar stelt ook meer specifieke aankondigingen toe. De maximale lengte moet daarom de echte routingplanning weerspiegelen, omdat het instellen ervan te kort kan leiden tot het ongeldig worden van legitieme meer specifieke routes, terwijl het instellen ervan te lang aankondigingen kan toestaan die de organisatie nooit heeft bedoeld toe te staan.
Waarom is maxLength belangrijk?
De maximale prefixlengte is een van de belangrijkste en het meest verkeerd begrepen ROA-instellingen, die het niveau van specificiteit bepaalt dat de geautoriseerde ASN mag gebruiken bij het aankondigen van het resource. Veel netwerkoperators kondigen een geaggregeerde prefix aan om groei van de routingtabel te beperken; bijvoorbeeld, een organisatie kan een /20 bezitten maar deze als één enkele aggregaat aankondigen. In sommige gevallen moet de organisatie ook kleinere prefixes aankondigen voor traffic engineering, regionale connectiviteit of service scheiding. Als de ROA alleen de aggregaat dekt terwijl het netwerk meer-specifieke routes aankondigt, kunnen deze routes worden geclassificeerd als ongeldig. De BGP-aankondiging kan technisch correct zijn vanuit het perspectief van de organisatie, maar komt niet overeen met de autorisatie gepubliceerd in RPKI. Aan de andere kant kan het autoriseren van elke mogelijke meer-specifieke route de precisie van het beleid verzwakken, aangezien een /20 geautoriseerd met een extreem brede maximale lengte toestaat dat een veel kleinere sub-prefix wordt geautoriseerd, zelfs buiten het beoogde ontwerp. Een praktische aanpak is om alleen de prefixlengtes te autoriseren die het netwerk echt verwacht aan te kondigen op basis van zijn adresseringsplan, providervereisten, failoverontwerp en traffic engineeringstrategie. Wijzigingen aan de maximale lengte moeten zorgvuldig worden getest, waarbij wordt bevestigd dat alle productaanmeldingen het verwachte validatieresultaat retourneren voordat strikte filtering wordt toegepast.
ROAs for IPv4 and IPv6
ROA's kunnen worden aangemaakt voor zowel IPv4- als IPv6-netwerken, en het onderliggende beveiligingsprincipe is hetzelfde: het koppelen van een prefix aan een geautoriseerde oorsprongs-ASN. Het belangrijkste operationele verschil ligt in de adresstructuur. IPv4-bronnen zijn schaars en worden vaak aangekondigd in relatief kleine prefixes, waarbij /24 een veelvoorkomende minimale aankondigingsgrootte is op het publieke internet. IPv6-netwerken ontvangen doorgaans grotere toewijzingen en kunnen deze verdelen in site-, service- of geografische segmenten, waarbij één aggregate wordt aangekondigd terwijl meerdere interne prefixes worden gebruikt. De ROA moet overeenkomen met de openlijk aangekondigde prefixes. IPv6-operatoren mogen niet aannemen dat een groot adresruimte routingrisico's elimineert, omdat een ongeautoriseerde IPv6-aankondiging nog steeds problemen met bereikbaarheid, verkeersherleiding of inconsistente globale routing kan veroorzaken. RPKI biedt IPv6-operatoren dezelfde mogelijkheid om oorsprongsautorisatie te publiceren als IPv4-operatoren. Voordat IPv6-ROA's worden aangemaakt, moet het netwerkteam documenteren welke aggregate-prefixes zullen worden aangekondigd, of meer-specifieke aankondigingen worden verwacht, en welke ASN ze zal origineren, om records te vermijden die te restrictief of onnodig breed zijn.
Wanneer moet je een ROA aanmaken?
Er moet een ROA worden aangemaakt voordat een prefix in productie wordt aangekondigd, zodra de resourcehouder een duidelijk routingplan heeft, zodat validerende netwerken de tijd hebben om de informatie op te halen voordat de route breed zichtbaar wordt. Organisaties moeten ook ROA's herzien wanneer ze een nieuwe toewijzing ontvangen, een IPv4-blok verwerven, een adresoverdracht voltooien, de oorspronkelijke ASN wijzigen of beginnen met het gebruik van een nieuwe IPv6-toewijzing, omdat deze gebeurtenissen de relatie tussen de prefix en het oorspronkelijke netwerk veranderen. Een provider-migratie is nog een veelvoorkomende trigger: als de organisatie dezelfde oorspronkelijke ASN behoudt en alleen de upstream-carrier wijzigt, kan de ROA geldig blijven; als de migratie de oorspronkelijke ASN wijzigt, moet het record worden bijgewerkt vóór of gelijktijdig met de routewijziging. ROA's moeten worden herzien tijdens fusies, overnames, verhuizingen naar datacenters, wijzigingen in ASN-sponsoring en grote netwerkherontwerpen, om ervoor te zorgen dat de openbare autorisatie overeenkomt met de operationele realiteit. Een periodieke herziening is nuttig, zelfs wanneer geen bekende wijziging heeft plaatsgevonden, omdat netwerkdocumentatie verouderd raakt, verantwoordelijkheden binnen het personeel veranderen en oude autorisaties lang na vervanging van het oorspronkelijke routingontwerp actief kunnen blijven.
Veelvoorkomende configuratiefouten bij ROA
Een van de meest voorkomende fouten is het invoeren van het verkeerde oorsprongs-ASN, wat gebeurt wanneer ingenieurs het klant-ASN verwarren met het transit-provider-ASN of wanneer een oud ASN na een migratie in de configuratie blijft staan. Een andere veelvoorkomende fout is het vergeten bij te werken van de ROA na een IPv4-overdracht, waarbij de nieuwe houder het prefix aankondigt vanaf zijn eigen ASN terwijl de oude autorisatie nog steeds naar de vorige oorsprong verwijst, waardoor de route ongeldig wordt. Een onjuiste maximale lengte veroorzaakt vergelijkbare problemen wanneer een organisatie alleen een /24 autoriseert maar later een /25 aankondigt voor traffic engineering. Sommige organisaties maken meerdere overlappende ROAs zonder hun doel te documenteren; hoewel dit in bepaalde ontwerpen geldig is, kan dit onverwachte resultaten opleveren en het opsporen van fouten bemoeilijken. Het achterwege laten van het verwijderen van verouderde records maakt het mogelijk dat een ASN een prefix blijft origineren lang nadat het netwerkontwerp is gewijzigd. Tot slot schakelen sommige organisaties soms de strenge afwijzing van ongeldige routes in zonder eerst hun eigen aankondigingen te testen; productieprijzen, maximale lengtes en oorsprongs-ASNs moeten altijd worden geverifieerd voordat er vertrouwd wordt op geautomatiseerde filtering.
ROA and IPv4 Transfer Planning
IPv4-overdrachten vereisen speciale aandacht omdat de administratieve houder, sponsoringregeling en routingoorsprong op verschillende fasen van het proces kunnen wijzigen. Vóór een overdracht moet de huidige houder bestaande ROA’s documenteren en bevestigen welke ASN momenteel het prefix oorspronkelijk verzendt, terwijl de koper de bedoelde oorsprongsinformatie voorbereidt en afstemt met transitproviders. Tijdens de overgang moeten beide partijen een duidelijk plan hebben voor het bijwerken of vervangen van autorisatiegegevens: het te lang actief houden van de vorige ROA autoriseert de oude oorsprong na de overdracht, terwijl het te vroeg verwijderen ervan ervoor zorgt dat de bestaande route ongeldig wordt voordat de nieuwe route klaar is. Het exacte proces hangt af van het register, het type resource, de overeenkomst voor de overdracht en het operationele ontwerp, waardoor RPKI een essentieel checklistitem is naast registry-verificatie, contractuele beoordeling, BGP-aankondigingen, route-objecten, reverse DNS en reputatiescreening. Een openbare klaarheidschecker helpt bij het identificeren van de huidige oorsprongs-ASN, RPKI-status, registry-informatie en BGP-zichtbaarheid van een prefix voor technische pre-checks, hoewel deze geen juridisch eigendom bevestigt noch transfergeschiktheid garandeert.
ROA- en ASN-wijzigingen
Een ASN-wijziging heeft directe invloed op de RPKI-validatie. Als een prefix dat eerder werd aangekondigd door AS64500 nu wordt aangekondigd door AS64510, moet de ROA de nieuwe oorsprong autoriseren voordat de BGP-aankondiging als geldig kan worden geaccepteerd. Dit is met name belangrijk wanneer een organisatie overstapt van een provider-beheerde ASN naar haar eigen ASN of wijzigt in haar ondersteunende LIR-regeling, waarbij zowel de registratierelatie als de routingautorisatie samen moeten worden herzien. Een zorgvuldig geplande overgang kan tijdelijk het autoriseren van zowel de oude als de nieuwe oorsprong omvatten om een gecontroleerde migratiefase te creëren, mits dit gedocumenteerd is en de verouderde autorisatie na voltooiing wordt verwijderd. Het netwerkteam moet de volgorde van handelingen testen voordat productieaanpassingen worden uitgevoerd, ervoor zorgend dat de nieuwe autorisatie gepubliceerd en gevalideerd is voordat de nieuwe BGP-route wordt aangekondigd.
Hoe controleer je of een ROA werkt?
De eerste controle bevestigt dat de ROA het bedoelde prefix, de oorsprong-ASN en de maximale prefixlengte bevat via de relevante RIR-portaal, de interface van de sponsor-LIR of het RPKI-beheersysteem. Vervolgens wordt de autorisatie vergeleken met de daadwerkelijke BGP-aankondiging, waarbij wordt geverifieerd dat de aangekondigde prefixlengte wordt gedekt en dat de oorsprong-ASN overeenkomt met die in de ROA. Een externe RPKI-validator kan vervolgens de openbare status bevestigen; een correct geconfigureerde aankondiging levert dan 'Valid' op. Als het resultaat 'Invalid' is, inspecteer dan eerst de oorsprong-ASN en de prefixlengte; bij 'Not Found' moet worden gecontroleerd of de ROA is gepubliceerd en of validators de tijd hebben gehad om deze op te halen. Resultaten worden niet onmiddellijk bijgewerkt omdat repositories, validators en routersystemen afhankelijk zijn van vernieuwingsintervallen, waardoor korte vertragingen tijdens de verspreiding normaal zijn. Het vergelijken van meerdere openbare bronnen – waaronder registratiedata, validatorresultaten en huidige BGP-waarnemingen – voorkomt dat er wordt vertrouwd op gecachte informatie en biedt een volledig beeld.
Wat gebeurt er als een ROA ongeldig is?
Wanneer een BGP-aankondiging in conflict is met een bestaande ROA, classificeren RPKI-valideerders deze als ongeldig. De route wordt niet automatisch uit het globale internet verwijderd, maar netwerken die op RPKI gebaseerde beleidsregels afdwingen, kunnen deze weigeren of een lagere voorkeur toekennen. De operationele impact hangt af van de reikwijdte van de handhaving: sommige netwerken filteren streng, terwijl anderen de status gebruiken voor monitoring, wat betekent dat een ongeldige route zichtbaar kan blijven in delen van het internet, maar onbereikbaar wordt via andere delen. Als een legitieme route ongeldig wordt, moet de organisatie dit behandelen als een urgent configuratieprobleem en prioriteit geven aan het controleren van de oorsprongs-ASN, de aangekondigde prefixlengte en de maximale lengte van de ROA. De route mag niet automatisch als kwaadaardig worden beschouwd, omdat de meeste ongeldige resultaten voortkomen uit routinefouten zoals onvolledige migraties, verouderde records, incorrecte providergegevens of per ongeluk meer-specifieke aankondigingen. Eenmaal gecorrigeerd, hebben systemen tijd nodig om te vernieuwen, en het netwerkteam moet de route monitoren tot deze over alle observatiepunten gestabiliseerd is.
Hoe moeten organisaties ROA's beheren?
Het beheer van ROA vereist een duidelijke eigenaar, zoals het netwerkengineeringteam, het securityteam, de sponsor-LIR, een managed service provider of een andere groep die verantwoordelijk is voor Internet-nummerbronnen. De organisatie moet een inventaris bijhouden met details over elk prefix, oorsprongs-ASN, maximale lengte, aankondigingslocaties en verantwoordelijke contactpersonen om wijzigingsreviews en incidentresponsen te vereenvoudigen. ROA-wijzigingen moeten worden geïntegreerd in standaardnetwerkwijzigingsprocedures, waarbij RPKI wordt beschouwd als een expliciete eis tijdens ASN-migraties, providerswitches, IPv4-overdrachten of IPv6-implementaties. Monitoring en alarmering moeten zijn geconfigureerd voor ongeldige resultaten, onverwachte oorsprongen, verwijderde autorisaties of verschuivingen in BGP-zichtbaarheid. Cruciaal is dat organisaties te brede autorisaties vermijden: precieze ROA's blijven makkelijker te begrijpen, eenvoudiger te auditen en veel minder vatbaar voor het toestaan van onbedoelde aankondigingen.
Veelgestelde vragen
Is ROA hetzelfde als een IP-eigendomsdocument?
Nee. Een ROA is een routingautorisatie die aangeeft welke ASN een prefix in BGP mag origineren. Het vervangt geen registratiedata, contracten, overdrachtsdocumenten of bewijsstukken van juridisch eigendom.
Kan één prefix meer dan één ROA hebben?
Ja. Meerdere ROA's kunnen passend zijn wanneer een prefix opzettelijk door meer dan één ASN wordt georiginéerd, of wanneer een gecontroleerde migratie tijdelijke autorisatie vereist voor meerdere origins, hoewel overlappende records zorgvuldig gedocumenteerd moeten worden.
Deelt een ROA mijn prefix mee in BGP?
Nee. Het aanmaken van een ROA leidt niet tot een BGP-aankondiging; het netwerk moet nog steeds BGP configureren via zijn routers en upstream-providers.
Moet een transitprovider in de ROA worden vermeld?
Doorgaans moet de ROA het ASN identificeren dat de route oorspronkelijk uitgeeft. Een provider die alleen de route transporteert, is niet noodzakelijkerwijs het oorspronkelijke ASN, en de juiste waarde hangt af van de daadwerkelijke routingarchitectuur.
Hoe lang duurt het voordat een ROA zichtbaar wordt?
De timing is afhankelijk van het RIR-systeem, de publicatierepository, de vernieuwingsintervallen van de validator en caching. Updates zijn vaak relatief snel zichtbaar, maar voor wijzigingen in productie moet voldoende tijd worden gereserveerd voor validatie.
Moet elke IPv4- en IPv6-prefix een ROA hebben?
Het wordt sterk aanbevolen om nauwkeurige ROA's te publiceren voor prefixes die in BGP worden aangekondigd. De organisatie moet eerst haar routingontwerp bevestigen, zodat de autorisatie niet per ongeluk legitieme aankondigingen ongeldig maakt.
Kan een ROA tegen elke BGP-aanval beschermen?
Nee. Een ROA ondersteunt voornamelijk de validatie van de oorsprong. Het valideert niet elk onderdeel van het BGP-pad, voorkomt niet alle routelekkages, versleutelt geen verkeer of garandeert niet dat het verkeer een fysiek veilige route volgt.
Een Route Origin Authorization (ROA) is een centraal onderdeel van RPKI, waarbij een cryptografisch ondertekende relatie wordt vastgesteld tussen een IP-prefix en het ASN dat gemachtigd is om die prefix in BGP te origineren. Het record bevat doorgaans de prefix, het originerende ASN en een maximale prefixlengte—elk van deze elementen speelt een beslissende rol bij het identificeren van het resource, het toestaan van de originering en het definiëren van hoe specifiek de aankondiging mag zijn. Nauwkeurige ROAs helpen netwerken om ongeautoriseerde of verkeerd geconfigureerde aankondigingen te identificeren, wat cruciaal is tijdens IPv4-overdrachten, ASN-wijzigingen, provider-migraties, IPv6-implementaties en operaties met gemulti-homed netwerken. Tegelijkertijd is een ROA geen bewijs van juridisch eigendom en geen op zichzelf staande oplossing voor routingbeveiliging; het werkt het beste in combinatie met accurate registratiedata, gedisciplineerde BGP-configuraties, IRR-gegevens, routebewaking en gedocumenteerde wijzigingsprocessen. Voor elke organisatie die publieke IPv4- of IPv6-adresruimte aankondigt, geldt de praktische regel: publiceer alleen de origins die je van plan bent te gebruiken, autoriseer alleen de prefixlengtes die je daadwerkelijk van plan bent aan te kondigen, en controleer de records telkens wanneer er netwerkwijzigingen plaatsvinden. Dit houdt RPKI-data in lijn met de werkelijke routomgeving en verkleint de kans dat een legitieme route als ongeldig wordt geclassificeerd.