RPKI and BGP Route Origin Validation
RPKI kaj BGP Route Origin Validation
Kiel la Rimeda Publika Ŝlosila Infrastrukturo malhelpas itinerajn kaperatojn — kovrante la fidan ĉenon de ROA, validigajn ŝtatojn, la RTR-protokolon kaj kie troviĝas hodiaŭ.
1. Kial BGP Ne Havas Denaskan Originan Validadon
BGP estis dizajnita por kunlabora interreto kie ĉiuj partoprenantoj estis fidindaj. Enkursigilo akceptas UPDATE-mesaĝon kaj disvastigas ĝin sen kriptiga konfirmo, ke la origina AS estas fakte rajtigita por anonci tiujn IP-prefiksojn. Ĉi tio signifas, ke ĉiu AS — per misagordo aŭ malico — povas anonci la prefiksojn de iu alia, kaj tiu anonco povas disvastigi tutmonde ene de minutoj.
Rimarkindaj okazaĵoj kiuj akcelis RPKI-adopto:
- 2008 - Pakistan Telecom:PTCL hazarde anoncis pli specifan prefikson por la adresspaco de Jutubo (208.65.153.0/24), nigratruante Jutubo tutmonde dum ~2 horoj antaŭ ol kontraŭfluaj provizantoj retiris la itineron.
- 2010 - China Telecom:China Telecom estigis ~50,000 prefiksojn apartenantaj al usonaj armeaj, registaraj kaj komercaj retoj dum ~18 minutoj. Ĉu hazarde aŭ intencite neniam estis konfirmitaj.
- 2018 - Amazon Route 53 DNS-kapero:Atakanto uzis BGP por kaperi 205.251.196.0/24 (Amazon DNS), redirektante kriptan monujon-trafikon por ŝteli financon. La atako uzis BGP UPDATE de eNet (AS10297).
- 2019 - Eŭropa trafiko redirektita tra China Telecom:Eŭropa movebla trafiko (inkluzive de Vodafone kaj Swisscom de Svislando) estis redirektita tra China Telecom dum ĉirkaŭ 2 horoj pro BGP-itinera liko.
2. La RPKI-Fida Hierarkio
RPKI (RFC 6480) konstruas hierarkion de X.509-atestiloj spegulantaj kiel IP-adresspaco estas delegita:
- IANAtenas la radikan fidan ankron. Ĝi emisias rimedatestiloj al la kvin RIRoj (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), ĉiu kovrante sian adresspacon.
- RIR-ojeldonas atestilojn al siaj membroj (ISP-oj, entreprenoj) por la adresspaco kiun tiuj membroj tenas.
- Membrojeldonu atestojn de Fina Ento (EE) kaj subskribuItineraj Originaj Rajtoj(ROAoj) - subskribitaj atestoj rajtigantaj specifan ASN estigi specifajn prefiksojn.
Kontroliloj elŝutas ĉi tiun subskribitan objektohierarkion el kvin RIR-deponejoj (krom iuj delegitaj deponejoj), validigas la atestilĉenon kaj konstruas validigitan ROA-utilan ŝarĝon (VRP) tabelon. Enkursigiloj tiam pridemandas lokan RPKI-kaŝmemoron per laRTR-protokolo (RFC 8210) por akiri ĉi tiun tabelon kaj fari originvalidigon pri alvenantaj BGP-ĜISDATIJoj.
3. Itineraj Originaj Rajtoj (ROAs)
A ROA (RFC 6482) estas subskribita objekto enhavanta tri kampojn:
- ASN: La Aŭtonoma Sistemo rajtigita por estigi la prefikson.
- Prefikso: La IP-prefikso (IPv4 aŭ IPv6) rajtigita.
- maxLength: La maksimuma prefiksa longo, kiun la ASN estas rajtigita anonci. Se ne specifita, nur la preciza prefikso estas rajtigita. Se fiksite al, ekzemple, 24 por /20 prefikso, la ASN ankaŭ povas anonci ajnan pli specifan inter /20 kaj /24.
Ununura ROA povas rajtigi multoblajn prefiksojn por la sama ASN, sed unu ROA ne povas rajtigi plurajn ASNojn por ununura prefikso. Por permesi al duaranga ASN (ekz., transitprovizanto aŭ CDN) estigi vian prefikson, kreu apartan ROA por tiu ASN.
4. Validaj Ŝtatoj
Kiam enkursigilo ricevas BGP-ĜISDATON, ĝi faras originvalidigon (RFC 6811) kontraŭ ĝia loka VRP-tabelo:
| Ŝtato | Kondiĉo | Tipa Loka-Prefera traktado |
|---|---|---|
| Valida | Almenaŭ unu ROA kovras la prefikson (prefikso ⊆ ROA prefikso AND prefikso-longo ≤ maxLength) KAJ la ASN de la ROA kongruas kun la origino ASN de BGP UPDATE | +20 aŭ preferata (ofta) |
| Nevalida | Almenaŭ unu ROA kovras la prefikson, sed neniu kovra ROA havas kongruan ASN kaj maxLength ≥ la anoncita prefiksa longo | Agordu loka-pref 0 aŭ fali (elekto de operaciisto; RFC 6811 rekomendas permesi sed marki) |
| NeTrovita | Neniu ROA ekzistas kiu kovras la anoncitan prefikson | Neŝanĝita (traktita kiel antaŭ ol RPKI ekzistis) |
La ŝlosila kompreno:Nevalidaestas pli forta pruvo de problemo olNeTrovita. NotFound simple signifas, ke la prefiksa posedanto ankoraŭ ne kreis ROA. Nevalida signifas ke ROA ekzistas dirante ke ĉi tiu ASN estasnerajtigita - forta signalo de aŭ misagordo aŭ kapero.
5. La RTR-Protokolo
Enkursigiloj ne validigas X.509-atestilĉenojn mem - tio estus komputile multekosta kaj postulus konservi plenan RPKI-kaŝmemoron. Anstataŭe, dediĉitaRPKI validigilo(Routinator, OctoRPKI, Fort, rpki-kliento) elŝutas kaj validas la plenan RPKI-deponejon kaj eksportas nur la rezultajn Validigitajn ROA-Utilŝarĝojn (VRP) al enkursigiloj per la RTR-protokolo (RFC 8210).
RTR uzas TCP (IANA-asignitan havenon 323; validigiloj kiel ekzemple Routinator defaŭlte al haveno 3323 por eviti postuli radikprivilegiojn) kun pliiga sinkroniga mekanismo: la validigilo sendas seriajn numerojn, kaj enkursigiloj petas nur la delton ekde sia lasta sinkronigo. Ĉi tio tenas bendolarĝon malalta eĉ por grandaj VRP-tabloj (nuntempe ~400,000+ IPv4-enskriboj tutmonde).
6. Deplojo kaj Statistiko
En frua 2026, RPKI-deplojo atingis signifan skalon:
- Pli ol 50% de tutmonde direktitaj IPv4-prefiksoj havas almenaŭ unu kovrantan ROA (pli ol ~10% en 2019).
- Plimulto de Tier-1 kaj Tier-2 ISP-oj nun elfaras Route Origin Validation kaj faligas aŭ malprioritigas Malvalidajn itinerojn.
- MANRS (Reciproke Interkonsentitaj Normoj por Voja Sekureco) postulas RPKI ROA-kreadon kiel antaŭkondiĉon por membreco kaj publikigas per-AS-konforman panelon.
Vivaj statistikoj:NIST RPKI Monitoro, ROV++, APNIC RPKI Statoj.
7. Preter ROV: ASPA kaj BGPsec
RPKI Route Origin Validation nur kontrolas ke laorigino ASNestas rajtigita por anonci la prefikson. Ĝi ne validas la AS_PATH — atakanto ankoraŭ povas konstrui falsan AS_PATH kun legitima origino AS ĉe la fino. Du IETF-normoj traktas ĉi tion:
- BGPsec (RFC 8205): Ĉiu AS en la vojo kriptografie subskribas la ĜISDATIGON, kreante nerompeblan ĉenon de gardado. Postulas ĉiujn transitajn AS-ojn por subteni BGPsec - signifa deploja baro. Malofte deplojita aktuale en 2026.
- ASPA(Aŭtonoma Sistemo-Provizanta Rajto,draft-ietf-sidrops-aspa-profile): AS subskribas objekton listigante siajn rajtigitajn kontraŭfluajn provizantojn. Konfirmiloj povas detekti malvalidajn senvalajn padojn (ekz., kliento anoncanta itinerojn kvazaŭ ĝi estus provizanto). Pli simple deplojebla ol BGPsec kaj akirante tiradon de 2025–2026.
Referencoj
- RFC 6480- Infrastrukturo por Subteni Sekuran Interretan Vojadon (RPKI-superrigardo)
- RFC 6482— Profilo por Itineraj Originaj Rajtoj (ROAoj)
- RFC 6811— BGP Prefiksa Origina Valido
- RFC 8210- La RPKI al Router-Protokolo, Versio 1 (RTR)
- RFC 8416- Simpligita Loka Interreta Numero-Rimedo-Administrado kun la RPKI (SLURM - lokaj anstataŭoj)
- RFC 9286— Manifestoj por la Rimeda Publika Ŝlosila Infrastrukturo (RPKI)
- RFC 8205— BGPsec-Protokola Specifo
- MANRS— Reciproke Interkonsentitaj Normoj por Voja Sekureco
- Cloudflare RPKI Portalo— viva ROA-serĉo