1. Waarom BGP geen native origin-validatie heeft
BGP is ontworpen voor een coöperatief internet waar alle deelnemers vertrouwd werden. Een router accepteert een UPDATE-bericht en verspreidt dit zonder cryptografische verificatie dat de oorspronkelijke AS daadwerkelijk geautoriseerd is om die IP-voorvoegsels aan te kondigen. Dit betekent dat elke AS – door een verkeerde configuratie of kwaadwilligheid – de voorvoegsels van iemand anders kan aankondigen, en die aankondiging kan zich binnen enkele minuten wereldwijd verspreiden.
Opmerkelijke incidenten die de adoptie van RPKI hebben versneld:
- 2008 - Pakistan Telecom:PTCL kondigde per ongeluk een specifieker voorvoegsel aan voor de adresruimte van YouTube (208.65.153.0/24), waardoor YouTube ongeveer twee uur lang wereldwijd op de zwarte lijst werd gezet voordat upstream-providers de route introkken.
- 2010 — China Telecom:China Telecom heeft gedurende ~18 minuten ongeveer 50.000 voorvoegsels gemaakt die behoren tot Amerikaanse militaire, overheids- en commerciële netwerken. Of het nu per ongeluk of opzettelijk was, werd nooit bevestigd.
- 2018 — Amazon Route 53 DNS-kaping:Een aanvaller gebruikte BGP om 205.251.196.0/24 (Amazon DNS) te kapen en het cryptocurrency-portemonneeverkeer om te leiden om geld te stelen. Bij de aanval werd gebruik gemaakt van een BGP-UPDATE van eNet (AS10297).
- 2019 — Europees verkeer omgeleid via China Telecom:Het Europese mobiele verkeer (waaronder Vodafone en het Zwitserse Swisscom) werd ongeveer twee uur lang omgeleid via China Telecom vanwege een BGP-routelek.
2. De RPKI-vertrouwenshiërarchie
RPKI (RFC-6480) bouwt een hiërarchie van X.509-certificaten op die weerspiegelt hoe IP-adresruimte wordt gedelegeerd:
- IANAbevat het root trust anchor. Het geeft broncertificaten uit aan de vijf RIR's (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), die elk hun adresruimte bestrijken.
- RIR'scertificaten uitgeven aan hun leden (ISP's, ondernemingen) voor de adresruimte die deze leden bezitten.
- LedenEE-certificaten (End Entity) uitgeven en ondertekenenAutorisaties van herkomst routeren(ROA's) - ondertekende attesten die een specifiek ASN autoriseren om specifieke voorvoegsels te maken.
Verificateurs downloaden deze ondertekende objecthiërarchie uit vijf RIR-opslagplaatsen (plus eventuele gedelegeerde opslagplaatsen), valideren de certificaatketen en bouwen een gevalideerde ROA-payload-tabel (VRP). Routers vragen vervolgens een lokale RPKI-cache op via deRTR-protocol (RFC8210) om deze tabel op te halen en de oorsprongsvalidatie uit te voeren op binnenkomende BGP-UPDATE's.
3. Autorisaties van routeoorsprong (ROA's)
Een ROA (RFC6482) is een ondertekend object dat drie velden bevat:
- ASN: Het autonome systeem dat geautoriseerd is om het voorvoegsel te creëren.
- Voorvoegsel: Het IP-voorvoegsel (IPv4 of IPv6) dat wordt geautoriseerd.
- maximale lengte: De maximale prefixlengte die de ASN mag aankondigen. Indien niet gespecificeerd, is alleen het exacte voorvoegsel toegestaan. Indien ingesteld op bijvoorbeeld 24 voor een /20-voorvoegsel, kan de ASN ook een meer specifiek voorvoegsel tussen /20 en /24 aankondigen.
Eén ROA kan meerdere voorvoegsels autoriseren voor hetzelfde ASN, maar één ROA kan niet meerdere ASN's autoriseren voor één enkel voorvoegsel. Als u wilt dat een secundair ASN (bijvoorbeeld een transitprovider of CDN) uw voorvoegsel kan genereren, maakt u een afzonderlijke ROA voor dat ASN.
4. Validatiestatussen
Wanneer een router een BGP-UPDATE ontvangt, voert deze een oorsprongsvalidatie uit (RFC6811) tegen zijn lokale VRP-tabel:
| Staat | Voorwaarde | Typische Local-Preference-behandeling |
|---|---|---|
| Geldig | Ten minste één ROA dekt het voorvoegsel (voorvoegsel ⊆ ROA-voorvoegsel EN voorvoegsellengte ≤ maxLength) EN de ASN van de ROA komt overeen met de oorspronkelijke ASN van de BGP UPDATE | +20 of voorkeur (vaak) |
| Ongeldig | Ten minste één ROA dekt het voorvoegsel, maar geen enkele overkoepelende ROA heeft een overeenkomende ASN en een maxLength ≥ de aangekondigde voorvoegsellengte | Stel local-pref in op 0 of laat vallen (keuze van de operator; RFC 6811 raadt aan om maar markering toe te staan) |
| Niet gevonden | Er bestaat geen ROA die het aangekondigde voorvoegsel dekt | Ongewijzigd (behandeld zoals voordat RPKI bestond) |
Het belangrijkste inzicht:Ongeldigis een sterker bewijs van een probleem danNiet gevonden. NotFound betekent eenvoudigweg dat de eigenaar van het voorvoegsel nog geen ROA heeft gemaakt. Ongeldig betekent dat er een ROA bestaat waarin staat dat dit ASN isnietgeautoriseerd – een sterk signaal van een verkeerde configuratie of kaping.
5. Het RTR-protocol
Routers valideren zelf de X.509-certificaatketens niet; dat zou rekentechnisch duur zijn en een volledige RPKI-cache vereisen. In plaats daarvan een toegewijdeRPKI-validator(Routinator, OctoRPKI, Fort, rpki-client) downloadt en valideert de volledige RPKI-repository en exporteert alleen de resulterende gevalideerde ROA Payloads (VRP's) naar routers via het RTR-protocol (RFC8210).
RTR gebruikt TCP (door IANA toegewezen poort 323; validators zoals Routinator gebruiken standaard poort 3323 om te voorkomen dat rootrechten nodig zijn) met een incrementeel synchronisatiemechanisme: de validator verzendt serienummers en routers vragen alleen om de delta sinds hun laatste synchronisatie. Hierdoor blijft de bandbreedte laag, zelfs voor grote VRP-tabellen (momenteel ~400.000+ IPv4-vermeldingen wereldwijd).
6. Implementatie en statistieken
Vanaf begin 2026 heeft de RPKI-implementatie een aanzienlijke omvang bereikt:
- Meer dan 50% van de wereldwijd gerouteerde IPv4-voorvoegsels heeft ten minste één dekkende ROA (tegenover ~10% in 2019).
- Een meerderheid van de Tier-1- en Tier-2-ISP's voeren nu Route Origin Validation uit en laten ongeldige routes vallen of geven er geen prioriteit meer aan.
- MANRS (Mutually Agreed Norms for Routing Security) vereist het maken van RPKI ROA als voorwaarde voor lidmaatschap en publiceert een per-AS-conformiteitsdashboard.
Live-statistieken:NIST RPKI-monitor, ROV++, APNIC RPKI-statistieken.
7. Verder dan ROV: ASPA en BGPsec
RPKI Route Origin Validation verifieert alleen dat deherkomst ASNis bevoegd het voorvoegsel bekend te maken. Het valideert de AS_PATH niet: een aanvaller kan aan het einde nog steeds een valse AS_PATH construeren met een legitieme oorsprong AS. Twee IETF-standaarden behandelen dit:
- BGPsec (RFC-8205): Elke AS in het pad ondertekent de UPDATE cryptografisch, waardoor een onbreekbare bewakingsketen ontstaat. Vereist dat alle transit-AS'en BGPsec ondersteunen – een aanzienlijke implementatiebarrière. Zelden ingezet vanaf 2026.
- ASPA(autorisatie van autonome systeemaanbieder,draft-ietf-sidrops-aspa-profiel): Een AS ondertekent een object met een lijst van zijn geautoriseerde upstream-providers. Verificateurs kunnen ongeldige dalvrije paden detecteren (bijvoorbeeld een klant die routes aankondigt alsof hij een aanbieder is). Eenvoudiger te implementeren dan BGPsec en wint terrein vanaf 2025-2026.
Referenties
- RFC-6480— Een infrastructuur ter ondersteuning van veilige internetroutering (RPKI-overzicht)
- RFC6482— Een profiel voor routeoorsprongautorisaties (ROA's)
- RFC6811— Validatie van oorsprong BGP-voorvoegsel
- RFC8210— Het RPKI naar Router Protocol, versie 1 (RTR)
- RFC-8416— Vereenvoudigd beheer van lokale internetnummerbronnen met de RPKI (SLURM — lokale overschrijvingen)
- RFC9286— Manifesten voor de Resource Public Key Infrastructure (RPKI)
- RFC-8205— BGPsec-protocolspecificatie
- MANRS— Onderling overeengekomen normen voor routeringsbeveiliging
- Cloudflare RPKI-portaal- live ROA-zoekopdracht