RPKI and BGP Route Origin Validation
RPKI och BGP Route Origin Validation
Hur Resource Public Key Infrastructure förhindrar ruttkapningar - som täcker ROA-förtroendekedjan, valideringstillstånd, RTR-protokollet och där utplacering står idag.
Varför BGP inte har någon ursprunglig ursprungsvärdering
BGP var utformad för ett kooperativt internet där alla deltagare var betrodda. En router accepterar ett UPDATE-meddelande och förökar det utan kryptografisk verifiering att den ursprungliga AS faktiskt är behörig att meddela dessa IP-prefix. Detta innebär att alla AS - genom felkonfiguration eller illvilja - kan tillkännage någon annans prefix och att tillkännagivandet kan spridas globalt inom några minuter.
Anmärkningsvärda incidenter som accelererade RPKI-antagande:
- 2008 – Pakistan Telecom:
- 2010 – China Telecom:
- 2018 – Amazon Route 53 DNS kapare:
- 2019 – Europeisk trafik omdirigerad via China Telecom:
RPKI:s förtroendehierarki
RPKI (RPKI)) bygger en hierarki av X.509-certifikat som speglar hur IP-adressutrymmet delegeras:
- IANA
- RIRs
- MedlemmarRoute Origin Authorizations
Verifiers laddar ner denna signerade objekthierarki från fem RIR-repositorier (plus eventuella delegerade repositorier), validerar certifikatkedjan och bygger en validerad ROA-belastningstabell (VRP). Routers frågar sedan en lokal RPKI-cache via (b)) för att få denna tabell och utföra ursprung validering på inkommande BGP UPDATEs.
Route Origin Authorizations (ROAs)
En ROA) är ett signerat objekt som innehåller tre fält:
- ASN
- Prefix
- MaxLength
En enda ROA kan tillåta flera prefix för samma ASN, men en ROA kan inte tillåta flera ASN för ett enda prefix. För att tillåta en sekundär ASN (t.ex. en transitleverantör eller CDN) att starta ditt prefix, skapa en separat ROA för den ASN.
4. Valideringsstater
När en router får en BGP UPDATE, utför den ursprungsvalidering (mot sitt lokala VRP-bord:
| Staten | Villkor | Typisk Lokal-Preferens behandling |
|---|---|---|
| Valid | Minst en ROA täcker prefixet (prefix ROA prefix och prefix-längd ≤ maxLength) OCH ROA: s ASN matchar BGP UPDATE: s ursprung ASN | +20 eller föredragen (vanlig) |
| Invalid | Minst en ROA täcker prefixet, men ingen täcker ROA har en matchande ASN och en maxLength ≥ den tillkännagivna prefixlängden | Ange lokal-pref 0 eller droppe (operatorval; RFC 6811 rekommenderar att du tillåter men markerar) |
| NotFound | Ingen ROA existerar som täcker det tillkännagivna prefixet | oförändrad (behandlad som före RPKI fanns) |
Nyckelinsikten: är starkare bevis på ett problem än NotFound betyder helt enkelt att prefixägaren inte har skapat en ROA ännu. Invalid betyder att en ROA existerar och säger att ASN är auktoriserad - en stark signal om antingen felkonfiguration eller kapning.
5. RTR-protokollet
Routers validerar inte X.509-certifikatkedjor själva - det skulle vara beräkningsmässigt dyrt och kräver att du håller en fullständig RPKI-cache. Istället en dedikerad (Routinator, OctoRPKI, Fort, rpki-client) laddar ner och validerar hela RPKI-förvaret och exporterar bara de resulterande Validated ROA Payloads (VRP) till routrar via RTR-protokollet (RPKI).).
RTR använder TCP (IANA-tilldelad port 323; validatorer som Routinator standard till port 3323 för att undvika att kräva rot privilegier) med en stegvis synkroniseringsmekanism: validatorn skickar serienummer, och routrar begär endast deltat sedan deras sista synkronisering. Detta håller bandbredd låg även för stora VRP-bord (för närvarande ~ 400 000 + IPv4-poster globalt).
Utplacering och statistik
Från och med början av 2026 har RPKI-utplaceringen nått betydande skala:
- Över 50% av de globalt dirigerade IPv4-prefixen har minst en som täcker ROA (upp från ~ 10% under 2019).
- En majoritet av Tier-1 och Tier-2 ISP utför nu Route Origin Validation och släpper eller deprioriterar ogiltiga rutter.
- MANRS (Mutually Agreed Norms for Routing Security) kräver RPKI ROA skapande som en förutsättning för medlemskap och publicerar en per-AS överensstämmelse instrumentbräda.
Live statistik: , , .
Utöver ROV: ASPA och BGPsec
RPKI Route Origin Validation verifierar endast att är behörig att meddela prefixet. Den validerar inte AS PATH – en angripare kan fortfarande bygga en falsk AS PATH med ett legitimt ursprung AS i slutet. Två IETF-standarder adresserar detta:
- BGPsecRFC 8205
- ASPAUtkast-ietf-sidrops-aspa-profil