Het internet is afhankelijk van een wereldwijd routersysteem dat netwerken, datacenters, cloudplatforms, internetaanbieders en ondernemingen in staat stelt verkeer uit te wisselen. Een van de belangrijkste protocollen in dit systeem is het Border Gateway Protocol, algemeen bekend als BGP. BGP stelt onafhankelijke netwerken in staat aan te kondigen welke IP-adresbereiken ze kunnen bereiken. Zonder BGP zou het moderne internet niet in staat zijn om miljoenen netwerken over verschillende landen en aanbieders heen te verbinden. Echter, BGP is oorspronkelijk ontworpen om routinginformatie uit te wisselen op basis van vertrouwen. Wanneer een netwerk een IP-prefix aankondigt, kunnen andere netwerken deze aankondiging accepteren zonder een sterke cryptografische methode om te bevestigen of dat netwerk daadwerkelijk gemachtigd is om de prefix te gebruiken. Dit creëert een veiligheidsprobleem. Een incorrecte of kwaadaardige route-aankondiging kan verkeer omleiden, diensten onderbreken of gegevens blootstellen aan ongewenste paden.
RPKI is ontwikkeld om de beveiliging van internetrouting te verbeteren. De naam staat voor Resource Public Key Infrastructure. Het biedt een manier om internetnummers, zoals IPv4- en IPv6-prefixen, te koppelen aan het Autonomous System Number (ASN) dat gemachtigd is om ze te origineren. Netwerkbeheerders kunnen deze informatie vervolgens gebruiken om te bepalen of een BGP-aankondiging consistent is met de geregistreerde machtiging.
Voor bedrijven die hun eigen ASN beheren, IP-resources beheren, gebruikmaken van meerdere upstream-providers of plannen om IPv4- of IPv6-adresruimte aan te kondigen, wordt het begrijpen van RPKI steeds belangrijker. RPKI vervangt BGP niet en lost niet elk routingprobleem op. In plaats daarvan biedt het een extra verifiatielaag die netwerken helpt veiligere routingbeslissingen te nemen.
Wat is RPKI?
RPKI is een beveiligingskader dat digitale certificaten en cryptografische records gebruikt om de relatie tussen een IP-adresprefix en een oorsprongs-ASN te verifiëren. Een IP-prefix is een blok van adressen, zoals een IPv4 /24 or an IPv6 /48. Een ASN identificeert een onafhankelijk netwerk dat deelneemt aan BGP-routing.
Het basisidee is eenvoudig. Een organisatie die gemachtigd is om een IP-prefix te gebruiken, publiceert een ondertekende verklaring waarin wordt aangegeven welke ASN het toegestaan is om die prefix in BGP te origineren. Netwerken die BGP-aankondigingen ontvangen, kunnen de aankondiging vergelijken met de gepubliceerde informatie. Als de aankondiging overeenkomt, kan deze als geautoriseerd worden beschouwd. Als er een conflict is met de informatie, kan de aankondiging als verdacht of ongeldig worden beschouwd.
De records die worden gebruikt om deze autorisatie uit te drukken, worden doorgaans Route Origin Authorizations (ROA's) genoemd. Een ROA identificeert een IP-prefix, een geautoriseerde oorsprong-ASN en, indien van toepassing, de maximale prefixlengte die de ASN mag aankondigen. Hoewel ROA's een belangrijk onderdeel zijn van RPKI, richt dit artikel zich op het bredere doel van RPKI en hoe het de routingbeveiliging verbetert.
RPKI wordt over het algemeen beheerd via de regionale internetregistraars, waaronder RIPE NCC, ARIN, APNIC, LACNIC en AFRINIC. Afhankelijk van de regio en het type resource kan de houder van de resource of de sponsororganisatie de relevante autorisatierecords aanmaken en beheren via de systemen van de registrar.
Waarom heeft BGP RPKI nodig?
BGP werd ontwikkeld in een tijdperk waarin het internet kleiner was en het aantal deelnemende netwerken beperkt. Het primaire doel was het uitwisselen van bereikbaarheidsinformatie tussen autonome systemen. BGP kan paden selecteren op basis van beleid, padlengte, lokale voorkeur en andere attributen, maar het protocol zelf verifieert niet automatisch of een ASN gemachtigd is om een bepaald IP-prefix te origineren.
Dit betekent dat een configuratiefout er soms hetzelfde uitziet als een kwaadwillige aankondiging. Als een netwerk per ongeluk een prefix aankondigt dat toebehoort aan een andere organisatie, kunnen andere netwerken de route aanvankelijk accepteren. Het resultaat kan zijn dat verkeer naar de verkeerde bestemming gaat, verbindingen verloren gaan of onstabiele routing optreedt.
Een bekend voorbeeld is een route leak of prefix hijack. Bij een hijack kondigt een ASN een prefix aan die het niet beheert of waarvoor het niet bedoeld is om deze te origineren. De aankondiging kan specifieker zijn dan de legitieme route, of het kan voldoende netwerken bereiken om het verkeer te beïnvloeden. Zelfs wanneer het incident per ongeluk gebeurt, kan de operationele impact aanzienlijk zijn.
RPKI helpt door netwerkbeheerders een externe bron van autorisatie-informatie te bieden. In plaats van alleen te vertrouwen op de inhoud van een BGP-aankondiging, kan een router of routersysteem voor beveiliging controleren of de oorsprongs-ASN is geautoriseerd door de houder van het adresruimte. Dit voorkomt niet elke routingincident, maar maakt het wel eenvoudiger om een belangrijke klasse van routingfouten te identificeren en te filteren.
Hoe werkt RPKI?
RPKI werkt via een keten van vertrouwen. Internetnummerbronnen worden beheerd door regionale internetregistries, en deze registries vormen de basis voor de relevante digitale certificaten. De houder van een IP-bron kan een autorisatierecord aanmaken waarin wordt vermeld welke ASN het prefix mag origineren.
De ondertekende records worden verzameld in repositories die toegankelijk zijn via routing security software. Een netwerkoperator voert een RPKI-validator uit of maakt gebruik van een service die de validatie namens hem uitvoert. De validator downloadt de beschikbare records, verifieert hun handtekeningen, controleert of ze actueel zijn en produceert een gevalideerde dataset.
De gevalideerde dataset wordt vervolgens aangesloten op de routing-infrastructuur van het netwerk. Wanneer een BGP-route wordt ontvangen, vergelijkt de router of het routingbeleidssysteem het aangekondigde prefix en de oorsprongs-ASN met de gevalideerde RPKI-informatie. Het resultaat wordt doorgaans geclassificeerd als Geldig, Ongeldig of Niet gevonden.
Dit proces vindt plaats los van de BGP-sessie zelf. BGP blijft routinginformatie uitwisselen, terwijl RPKI aanvullende autorisatiegegevens levert die kunnen worden gebruikt in het routeringsbeleid. Een netwerk kan beslissen hoe elk validatieresultaat wordt afgehandeld. Zo kan het ongeldige routes weigeren, ze een lagere voorkeur geven of waarschuwingen genereren voor verdere beoordeling.
Het proces is ontworpen om gedistribueerd en schaalbaar te zijn. Grote netwerken kunnen duizenden prefixen valideren zonder dat elke organisatie een directe relatie hoeft aan te gaan met elk ander netwerk. Dit is belangrijk omdat het internet uit een enorm aantal onafhankelijke operators bestaat met verschillende beleidsregels en technische omgevingen.
Wat is een Route Origin Authorization?
Een Route Origin Authorization is een ondertekend record dat aangeeft welke ASN gemachtigd is om een specifiek IP-prefix te origineren. Het is een van de meest zichtbare en praktische onderdelen van RPKI-implementatie.
Een organisatie kan bijvoorbeeld de IPv4-prefix controleren 192.0.2.0/24 en gebruik ASN AS64500 om dit aan te kondigen. De organisatie kan een machtiging maken die toestaat AS64500 ontstaan 192.0.2.0/24Als een andere ASN later hetzelfde prefix aankondigt, kunnen netwerken die RPKI-validatie uitvoeren detecteren dat de oorsprong niet overeenkomt met de autorisatie.
De autorisatie kan ook een maximale prefixlengte specificeren. Dit is belangrijk omdat een netwerk de oorspronkelijke ASN wellicht het aankondigen van de exacte geaggregeerde prefix wil toestaan, maar niet van kleinere, meer specifieke prefixes. Een zorgvuldig geselecteerde maximale lengte kan het risico verkleinen dat een onverwachte aankondiging als geautoriseerd wordt beschouwd.
ROA-configuratie vereist aandacht omdat een onjuist record een legitieme route ongeldig kan laten lijken. Als een organisatie zijn transitprovider wijzigt, een prefix naar een andere ASN verplaatst, een aankondiging splitst in meer-specifieke prefixes, of resources overdraagt aan een andere houder, kunnen de autorisatierecords mogelijk moeten worden bijgewerkt. Een verouderd record kan een uitval veroorzaken, zelfs wanneer de BGP-configuratie zelf correct is.
Een toekomstig artikel kan uitleggen hoe je een ROA maakt, hoe je een maximale lengte kiest en hoe je autorisaties bijwerkt tijdens een migratie van ASN- of IP-resources.
Wat betekenen geldig, ongeldig en niet gevonden?
Een geldig resultaat betekent dat een BGP-aankondiging wordt gedekt door een toepasselijke RPKI-autorisatie en dat de oorspronkelijke ASN het voorvoegsel mag aankondigen. Het geeft over het algemeen aan dat het aangekondigde voorvoegsel, de voorvoegsellengte en de oorspronkelijke ASN consistent zijn met de gepubliceerde autorisatie.
Een ongeldig resultaat betekent dat er een autorisatie bestaat, maar de BGP-aankondiging voldoet niet aan deze autorisatie. Dit kan gebeuren omdat het oorsprongs-ASN niet geautoriseerd is, omdat de aankondiging specifieker is dan de toegestane maximale lengte, of omdat het prefix overlapt met een autorisatie voor een andere oorsprong. Ongeldige routes verdienen onmiddellijke aandacht omdat ze een hijack, een per ongeluk gemaakte configuratie of een onvolledige migratie kunnen vertegenwoordigen.
Een resultaat van "Not Found" betekent dat er geen toepasbare autorisatie voor de aankondiging is gevonden. Dit betekent niet automatisch dat het route malicieus of onjuist is. Het betekent simpelweg dat RPKI de oorsprong niet kan bevestigen met behulp van de momenteel gepubliceerde records. Veel legitieme routes blijven "Not Found" omdat de resourcehouder geen autorisatie heeft aangemaakt.
Het onderscheid tussen ongeldig en niet gevonden is belangrijk. Ongeldig geeft een conflict aan met bestaande autorisatiegegevens, terwijl niet gevonden gebrek aan autorisatiegegevens aangeeft. Netbeheerders behandelen vaak ongeldige routes serieuzer, maar hun exacte routingbeleid hangt af van hun risicotolerantie, service-eisen en operationele procedures.
Why RPKI Matters for IPv4 Networks
Het IPv4-adresruimte is beperkt, en veel IPv4-prefixen worden nu gebruikt in complexe regelingen die providers, datacenters, cloudplatforms, verhuurbedrijven en overdrachtstransacties omvatten. Deze regelingen maken routingnauwkeurigheid extra belangrijk.
Wanneer een IPv4-prefix wordt overgedragen of verplaatst tussen organisaties, kan de BGP-origin ook wijzigen. Als de autorisatie van de vorige eigenaar nog actief blijft terwijl de nieuwe eigenaar het prefix aankondigt vanuit een andere ASN, kan de route RPKI ongeldig worden. Dit is één van de redenen waarom RPKI-planning moet worden opgenomen in werk voor IPv4-overdracht en migratie.
Voordat een organisatie een IPv4-prefix accepteert of aankondigt, moet ze bevestigen welke entiteit het beheer over de resource heeft, welk ASN wordt verwacht deze te origineren en of de relevante autorisatierecords het geplande routingontwerp weerspiegelen. Het openbare registratiebestand, BGP-aankondigingen en RPKI-informatie moeten samen worden gecontroleerd. RPKI is met name nuttig wanneer een bedrijf meerdere transitproviders gebruikt. Een consistente oorsprongsautorisation kan de prefix beschermen, ongeacht welke upstream-provider de route transporteert. De organisatie moet echter nog steeds ervoor zorgen dat alle providers het juiste ASN en prefixlengte gebruiken.
Bedrijven die een IPv4-blok evalueren, kunnen ook openbare tools gebruiken om actuele registratiegegevens, informatie over de oorsprongs-ASN, RPKI-status en BGP-zichtbaarheid te controleren. Deze controles vervangen geen contractuele due diligence of reputatiescreening, maar kunnen duidelijke routinginconsistenties blootleggen vóór een transactie of implementatie.
Why RPKI Matters for IPv6 Networks
IPv6-netwerken profiteren van dezelfde validatieprincipes voor de oorsprong als IPv4-netwerken. IPv6-prefixen worden aangekondigd via BGP, en een onjuiste oorsprong kan vergelijkbare risico's veroorzaken, waaronder onderbreking van het verkeer, routelekken en ongeautoriseerde aankondigingen.
IPv6-implementaties omvatten vaak grotere adresblokken en meer gestructureerde adresseringsplannen. Een organisatie kan een brede toewijzing ontvangen en een aggregate aankondigen terwijl kleinere interne subnets worden gebruikt voor locaties, datacenters of diensten. RPKI-autorisatie moet overeenkomen met de prefixen die daadwerkelijk bedoeld zijn voor openbare routing.
Een veelgemaakte fout is de aanname dat IPv6-routing automatisch veiliger is omdat IPv6 een veel groter adresbereik heeft. De grootte van het adresbereik neemt niet de noodzaak weg om de oorsprong van routes te verifiëren. Als een IPv6-prefix wordt aangekondigd door een incorrect ASN en er bestaat geen autorisatie, dan hebben andere netwerken mogelijk beperkte mogelijkheden om de aankondiging te onderscheiden van een legitieme route. Organisaties die IPv6 implementeren, moeten RPKI opnemen in hun initiële routingontwerp in plaats van te wachten tot het netwerk volledig operationeel is. Dit maakt het eenvoudiger om het adresplan, het gebruik van ASNs, upstream-providers en autorisatierecords te coördineren voordat productieverkeer afhankelijk wordt van de aankondiging.
Wat zijn de belangrijkste voordelen van RPKI?
Het belangrijkste voordeel van RPKI is dat het een breed erkende methode biedt voor het valideren van de oorsprong van een BGP-route. Dit geeft netwerkbeheerders een sterkere basis voor het filteren en monitoren van aankondigingen dan alleen BGP-informatie.
RPKI kan het risico verkleinen van het accepteren van routes die duidelijk in strijd zijn met de expliciete autorisatie van de resourcehouder. Het kan ook helpen operationele fouten te identificeren tijdens netwerkverschuivingen, providerwissels, wijzigingen in ASN-sponsoring en IPv4- of IPv6-resourcetransfers.
Voor IP-bronhouders toont RPKI aan dat de organisatie actief het routingbeveiliging van haar adresruimte beheert. Dit kan de coördinatie met transitproviders verbeteren en verwarring verminderen wanneer meerdere partijen betrokken zijn bij het aankondigen van hetzelfde prefix.
Voor transitproviders en hostingbedrijven kan RPKI-validatie onderdeel worden van een breder routingbeveiligingsprogramma. Providers kunnen validatieresultaten gebruiken in combinatie met prefixfilters, IRR-gegevens, BGP-monitoring en interne routingbeleidsregels. Geen enkele gegevensbron is perfect, maar het combineren van meerdere signalen biedt betere operationele zichtbaarheid.
RPKI verbetert ook de incidentrespons. Wanneer een onverwachte BGP-aankondiging verschijnt, kan het netwerkteam snel controleren of de oorsprong geautoriseerd is. Dit kan helpen om een potentiële hijack te onderscheiden van een legitieme maar niet gedocumenteerde routingwijziging.
Wat RPKI niet kan doen
RPKI is waardevol, maar het is geen volledig vervanging voor routingbeveiliging. Het valideert de relatie tussen een prefix en een oorsprongs-ASN. Het bewijst niet dat elke hop in het BGP-pad vertrouwbaar is, en het garandeert niet dat verkeer de beste of veiligste fysieke route volgt.
RPKI versleutelt geen applicatieverkeer. Het beschermt geen websessies, DNS-query's, e-mail of privégegevens tegen onderschepping. Voor die doeleinden zijn nog steeds encryptietechnologieën zoals TLS, VPN's en beveiligde applicatieprotocollen vereist.
RPKI voorkomt ook niet automatisch elke vorm van routelek. Een route kan worden georiginaleerd door het juiste ASN, maar toch worden doorgegeven aan locaties waar deze niet zou moeten verschijnen. Originvalidatie kan een dergelijke route als 'Geldig' classificeren omdat de oorsprong geautoriseerd is, hoewel het bredere pad operationeel onjuist is.
RPKI bewijst op zichzelf niet de wettelijke eigendom. Registergegevens, contracten, overdrachtsdocumenten en organisatorische autorisatie blijven belangrijk. Een geldig resultaat geeft aan dat de route overeenkomt met een gepubliceerde autorisatie; het bevestigt niet dat elke commerciële of juridische vereiste is vervuld.
Tot slot werkt RPKI alleen effectief wanneer de records worden bijgehouden. Een organisatie die autorisaties maakt en vervolgens vergeet deze te updaten na een provider- of ASN-wijziging, kan zelf een routingstoring veroorzaken.
Hoe kan een bedrijf beginnen met het gebruik van RPKI?
De eerste stap is het maken van een inventaris van alle IPv4- en IPv6-prefixen die de organisatie bezit, leaset, sponsort of verwacht aan te kondigen. Voor elk prefix worden het beoogde oorsprong-ASN, de aankondigende providers, de prefixlengte en de huidige zichtbaarheid in BGP geregistreerd.
De volgende stap is het bevestigen van de register- en resource-recordgegevens. De organisatie moet verifiëren dat het adresruimte aan het juiste account, de organisatie, de sponsor-LIR of de resourcehouder is gekoppeld. Als de openbare registratiegegevens verouderd zijn, moeten deze worden gecorrigeerd voordat nieuwe routingautorisaties worden aangemaakt. Nadat de inventarisatie van resources is bevestigd, kan de organisatie de passende autorisatierecords aanmaken via haar Regionale Internet Registry of sponsorprovider. Het oorspronkelijke ASN en de maximale prefixlengte moeten het werkelijke routingschema weerspiegelen. Als er meerdere ASNs legitiem worden gebruikt, dient het ontwerp zorgvuldig te worden gedocumenteerd in plaats van brede autorisaties toe te voegen zonder duidelijke reden.
De organisatie moet vervolgens de records valideren met behulp van een RPKI-validator of een gevestigde monitoringdienst. Het is belangrijk om te bevestigen dat de beoogde aankondigingen een geldig resultaat opleveren voordat strikte filteringsbeleid worden toegepast op klant- of productieverkeer.
Implementatie moet worden beschouwd als een operationeel proces, niet als een eenmalige configuratietaak. Wijzigingen in upstreamproviders, ASN-sponsoring, prefixaggregatie, datacenterlocaties en IPv4-overdrachtsregelingen kunnen allemaal invloed hebben op RPKI-records. Monitoring en change management moeten onderdeel zijn van de normale netwerkworkflow.
Veelvoorkomende fouten bij RPKI-implementatie
Een veelvoorkomende fout is het aanmaken van een autorisatie voor het verkeerde oorsprongs-ASN. Dit gebeurt vaak tijdens een provider-migratie, waarbij het oude ASN nog in het record staat terwijl het netwerk al aankondigingen vanaf een nieuw ASN begint te doen.
Een andere fout is het onjuist instellen van de maximale prefixlengte. Als een organisatie alleen een aggregate autoriseert maar een meer-specifieke route aankondigt, kan de aankondiging van die meer-specifieke route ongeldig worden. Als de maximale lengte te breed wordt ingesteld, kan de autorisatie aankondigingen toestaan die de organisatie niet had bedoeld toe te staan.
Verouderde records vormen ook een groot probleem. Een autorisatie die enkele jaren geleden correct was, komt mogelijk niet meer overeen met het huidige netwerkontwerp van de organisatie. Regelmatige controles zijn vooral belangrijk na een IPv4-overdracht, fusie, wijziging van de sponsor-LIR of ASN-renummering.
Sommige organisaties gaan er ook van uit dat een "Not Found"-resultaat betekent dat een route moet worden afgewezen. In de meeste gevallen betekent "Not Found" dat er geen autorisatie bestaat. Dit moet worden afgehandeld volgens het beleid en risicomodel van het netwerk, in plaats van automatisch als kwaadaardig te worden beschouwd.
RPKI, IRR en BGP-monitoring
RPKI is één onderdeel van een bredere aanpak voor routingbeveiliging. IRR-databases bevatten routingbeleidsobjecten die door netwerkoperators kunnen worden gebruikt om filters te genereren. Deze objecten kunnen beschrijven welke ASN wordt verwacht een prefix te origineren, maar ze gebruiken een ander trust- en validatiemodel dan RPKI.
BGP-monitoring toont wat er daadwerkelijk wordt aangekondigd en waar deze aankondiging zichtbaar is. Het kan routeveranderingen, onverwachte oorsprongen, padwijzigingen en perioden van instabiliteit blootleggen. RPKI toont of de oorsprong geautoriseerd is, maar biedt geen volledig operationeel geschiedenis van een route.
Om deze reden worden RPKI, IRR en BGP-monitoring vaak samen gebruikt. Een grondige routereview kan de registratievermelding, het verwachte ASN, het IRR-object, de RPKI-autorisatie en actieve BGP-waarnemingen met elkaar vergelijken. Wanneer deze bronnen overeenstemmen, is de routingpositie makkelijker te begrijpen. Wanneer ze niet overeenstemmen, moet het verschil worden onderzocht voordat een migratie of overdracht wordt voltooid.
Hoe moet RPKI worden onderhouden?
RPKI-onderhoud moet worden gekoppeld aan netwerkchange management. Wanneer een organisatie van plan is wijzigingen aan te brengen in haar oorspronkelijke ASN, upstream-provider, prefixlengte of aankondigingslocatie, dient ze de verwachte effecten op de autorisatierecords te beoordelen voordat de wijziging wordt doorgevoerd.
Monitoring moet het netwerkteam waarschuwen wanneer een verwachte prefix ongeldig wordt, wanneer een autorisatie wordt verwijderd of wanneer er een voorheen onbekende origin verschijnt. Waarschuwingen zijn het meest nuttig wanneer ze de getroffen prefix, de oorspronkelijke ASN, de huidige validatiestatus en het tijdstip van de wijziging bevatten.
Organisaties moeten ook documenteren wie verantwoordelijk is voor het beheer van RPKI. Bij sommige bedrijven verzorgt het netwerkengineeringteam het beheer van de records. In andere gevallen worden deze afgehandeld door de sponsor-LIR, managed service provider of securityteam. Duidelijke eigenaarschap helpt vertragingen tijdens incidenten en provider-migraties te voorkomen.
Een periodieke herziening kan maandelijks, kwartaallijks of telkens wanneer er een grote wijziging in de routing optreedt, worden gepland. De geschikte frequentie hangt af van de grootte en complexiteit van het netwerk. Het belangrijke punt is dat RPKI moet worden beschouwd als een levend onderdeel van het routersysteem.
Veelgestelde vragen over RPKI
Is RPKI vereist om BGP te gebruiken?
Nee. Een netwerk kan BGP gebruiken zonder RPKI-autorisatierecords te publiceren. RPKI wordt echter steeds meer aanbevolen omdat het andere netwerken een manier biedt om de oorsprong van de routes die de organisatie aankondigt te valideren.
Voorkomt RPKI een BGP-hijack?
RPKI voorkomt niet fysiek dat een ander netwerk een ongeautoriseerde BGP-aankondiging verzendt. Het stelt ontvangende netwerken in staat aankondigingen te identificeren die niet overeenkomen met gepubliceerde autorisaties. Netwerken kunnen deze routes vervolgens afwijzen, minder prioriteit geven of monitoren volgens hun beleidsregels.
Is RPKI alleen voor IPv4?
No. RPKI supports both IPv4 and IPv6 prefixes. The same basic origin validation concept applies to both address families.
Is een RPKI "Not Found"-resultaat gevaarlijk?
Niet noodzakelijk. 'Not Found' betekent dat er geen toepasbare autorisatie is gevonden. Het bewijst niet dat het route verkeerd is. Resourcehouders moeten echter overwegen om nauwkeurige autorisaties te publiceren, zodat andere netwerken hun aankondigingen kunnen valideren.
Kan RPKI een IRR-routeobject vervangen?
Nee. RPKI en IRR dienen verschillende doeleinden en worden vaak samen gebruikt. Sommige providers gebruiken beide systemen bij het opstellen van routingfilters en het controleren van aankondigingen.
Wat gebeurt er als een RPKI-record onjuist is?
Een verkeerd record kan ervoor zorgen dat een legitieme BGP-aankondiging als ongeldig wordt geclassificeerd. De organisatie moet de oorsprong-ASN, prefixlengte en maximale lengte controleren en vervolgens de autorisatie bijwerken voordat strikte routefiltering wordt toegepast.
RPKI is an important improvement to the security of Internet routing. It gives IP resource holders a way to publish cryptographic authorization for the ASNs that are allowed to originate their IPv4 and IPv6 prefixes. It also gives network operators a practical method for checking whether BGP announcements match that authorization.
Het concept is eenvoudig: de houder van een IP-prefix publiceert de beoogde oorsprong, en andere netwerken valideren de aankondiging tegen die informatie. Het resultaat kan helpen bij het identificeren van geautoriseerde routes, conflicterende routes en routes waarvoor geen autorisatie is gepubliceerd. RPKI vervangt niet zorgvuldige netwerkengineering, beheer van registers, IRR-records, BGP-monitoring of contractuele due diligence. Het garandeert ook niet dat elke route veilig is of dat elk routingincident zal worden voorkomen. De waarde ervan ligt in het toevoegen van een betrouwbaar autorisatiesignaal aan het routeringsproces.
Voor organisaties die een ASN, IPv4-adresruimte, IPv6-adresruimte of meerdere upstream-providers beheren, moet RPKI worden opgenomen in het normale routingontwerp. Voordat u een prefix aankondigt, van provider wisselt, een IPv4-overdracht voltooit of een nieuw IPv6-netwerk implementeert, controleer dan de registratiergegevens, de oorsprongs-ASN, autorisatierecords en de actuele BGP-status samen. Dit eenvoudige proces kan vermijdbare fouten voorkomen en de algehele betrouwbaarheid van internetconnectiviteit verbeteren.