RPKI and BGP Route Origin Validation
RPKI og BGP Route Origin Validering
Hvordan Resource Public Key Infrastructure forhindrer route hijacks - der dækker ROA trust chain, validering stater, RTR-protokollen, og hvor implementering står i dag.
1. Hvorfor BGP har ingen indfødte oprindelse Validering
BGP er designet til et samarbejdsbaseret internet, hvor alle deltagere var betroede. En router accepterer en UPDATE meddelelse og formerer den uden kryptografisk verifikation af, at det oprindelige AS faktisk er bemyndiget til at annoncere disse IP-præfikser. Dette betyder, at ethvert AS - gennem forkert konfiguration eller ondskab - kan annoncere en andens præfikser, og at annonceringen kan sprede sig globalt inden for få minutter.
Notable hændelser, der fremskyndede RPKI adoption:
- 2008 - Pakistan Telecom:
- 2010 - China Telecom:
- 2018 - Amazon Route 53 DNS kapring:
- 2019 - Europæisk trafik omdirigeret gennem China Telecom:
2. RPKI Trust Hierarchy
RPKI () bygger et hierarki af X.509 certifikater afspejler hvordan IP-adresseplads er delegeret:
- IANA
- RUR
- MedlemmerneTilladelse til ruteoprindelse
Verifikatorer henter dette underskrevne objekthierarki fra fem RIR-datalagre (plus eventuelle delegerede datalagre), validerer certifikatkæden og bygger en valideret ROA-nyttelast (VRP) tabel. Routere derefter spørge en lokal RPKI cache via () til at få denne tabel og udføre oprindelsesvalidering på indgående BGP UPDATES.
3. Route Oprindelse Tilladelser (ROAs)
En ROA () er et underskrevet objekt, der indeholder tre felter:
- ASN
- Præfiks
- maxLængde
En enkelt ROA kan tillade flere præfikser for samme ASN, men en ROA kan ikke tillade flere ASN 'er for et enkelt præfiks. For at give en sekundær ASN (f.eks. en transitudbyder eller CDN) mulighed for at få dit præfiks, skal du oprette en separat ROA for det pågældende ASN.
4. Valideringsstater
Når en router modtager en BGP UPDATE, udfører den oprindelsesvalidering () mod sin lokale VRP tabel:
| Tilstand | Betingelse | Typisk lokaliseringsbehandling |
|---|---|---|
| Gyldig | Mindst én ROA dækker præfikset (præfiks arefiks og præfiks længde ≤ maxlength) OG ROA 's ASN matcher BGP UPDATE' s oprindelse ASN | + 20 eller foretrækkes (almindelig) |
| Ugyldig | Mindst én ROA dækker præfikset, men ingen dækning af ROA har en matchende ASN og en maxLængde ≥ den annoncerede præfiks længde | Sæt local- pref 0 eller drop (operatørvalg; RFC 6811 anbefaler tillader, men mærkning) |
| NotFundet | Der findes ingen ROA, der dækker det annoncerede præfiks | Uændret (behandlet som før RPKI eksisterede) |
Den vigtigste indsigt: er stærkere tegn på et problem end NotFundet betyder, at ejeren ikke har skabt en ROA endnu. Ugyldig betyder en ROA eksisterer siger dette ASN er autoriseret - et stærkt signal om enten forkert konfiguration eller kapring.
5. RTR-protokollen
Routere validerer ikke selv X.509 certifikatkæder - det ville være computermæssigt dyrt og kræver at holde en fuld RPKI cache. I stedet en dedikeret (Routator, OctoRPKI, Fort, rpki- client) downloader og validerer det fulde RPKI-arkiv og eksporterer netop de resulterende validerede ROA-indbetalinger (VRP) til routere via RTR-protokollen ().
RTR bruger TCP (IANA-tildelt port 323; validatorer såsom Routator standard til port 3323 for at undgå kræver root privilegier) med en trinvis sync mekanisme: validatoren sender serienumre, og routere anmoder kun delta siden deres sidste sync. Dette holder båndbredden lav selv for store VRP tabeller (i øjeblikket ~ 400.000 + IPv4 indgange globalt).
6. Implementering og statistik
I begyndelsen af 2026 har RPKI-deployeringen nået et betydeligt omfang:
- Over 50% af de globalt styrede IPv4-præfikser har mindst én dækning af ROA (op fra ~ 10% i 2019).
- Et flertal af Tier-1 og Tier-2 ISP 'er udfører nu Route Origin Validering og slip eller fratage Ugyldige ruter.
- MANRS (Muligt aftalte standarder for Routing Security) kræver RPKI ROA skabelse som en forudsætning for medlemskab og udgiver en per- AS overensstemmelse dashboard.
Levende statistikker: , , .
7. Ud over ROV: ASPA og BGPsec
RPKI Route Origin Validering bekræfter kun, at er bemyndiget til at offentliggøre præfikset. Det validerer ikke AS _ PATH - en angriber kan stadig konstruere en falsk AS _ PATH med en legitim oprindelse AS i slutningen. To IETF-standarder vedrører dette:
- BGPsecRFC 8205
- ASPAudkast- ietf- siderops- aspa- profil