RPKI and BGP Route Origin Validation
Overenie pôvodu trasy RPKI a BGP
Ako infraštruktúra verejného kľúča zdrojov zabraňuje únosom trasy – pokrýva reťaz dôveryhodnosti ROA, stavy overenia, protokol RTR a súčasné nasadenie.
1. Prečo BGP nemá overenie pôvodného pôvodu
BGP bol navrhnutý pre kooperatívny internet, kde boli všetci účastníci dôveryhodní. Smerovač prijme správu UPDATE a rozšíri ju bez kryptografického overenia, či je pôvodný AS skutočne oprávnený oznamovať tieto IP prefixy. To znamená, že akýkoľvek AS – prostredníctvom nesprávnej konfigurácie alebo zlomyseľnosti – môže oznámiť predpony niekoho iného a toto oznámenie sa môže globálne šíriť v priebehu niekoľkých minút.
Pozoruhodné incidenty, ktoré urýchlili prijatie RPKI:
- 2008 – Pakistan Telecom:PTCL omylom oznámilo špecifickejšiu predponu pre adresný priestor YouTube (208.65.153.0/24), čím YouTube globálne narušilo približne na 2 hodiny predtým, ako poskytovatelia upstream stiahli trasu.
- 2010 – China Telecom:China Telecom vytvoril ~ 50 000 prefixov patriacich americkej armáde, vláde a komerčným sieťam na ~ 18 minút. Či náhodne alebo úmyselne sa nikdy nepotvrdilo.
- 2018 – Únos DNS na Amazon Route 53:Útočník použil BGP na únos 205.251.196.0/24 (Amazon DNS), pričom presmeroval návštevnosť kryptomenovej peňaženky s cieľom ukradnúť finančné prostriedky. Útok použil BGP UPDATE z eNet (AS10297).
- 2019 – európska doprava presmerovaná cez China Telecom:Európska mobilná prevádzka (vrátane Vodafone a švajčiarskeho Swisscomu) bola presmerovaná cez China Telecom na približne 2 hodiny z dôvodu úniku trasy BGP.
2. Hierarchia dôvery RPKI
RPKI (RFC 6480) vytvára hierarchiu certifikátov X.509, ktorá odráža spôsob delegovania priestoru adries IP:
- IANAdrží kotvu koreňovej dôvery. Vydáva certifikáty zdroja piatim RIR (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), z ktorých každý pokrýva ich adresný priestor.
- RIRsvydávať certifikáty svojim členom (ISP, podniky) pre adresný priestor, ktorý títo členovia vlastnia.
- členovvydať certifikáty koncovej entity (EE) a podpísaťAutorizácie pôvodu trasy(ROA) — podpísané osvedčenia oprávňujúce konkrétnu ASN vytvárať špecifické predpony.
Overovatelia stiahnu túto hierarchiu podpísaných objektov z piatich repozitárov RIR (plus akýchkoľvek delegovaných úložísk), overia reťazec certifikátov a zostavia overenú tabuľku užitočného zaťaženia ROA (VRP). Smerovače potom vyhľadávajú lokálnu vyrovnávaciu pamäť RPKI cezRTR protokol (RFC 8210), aby ste získali túto tabuľku a vykonali overenie pôvodu prichádzajúcich AKTUALIZÁCIÍ BGP.
3. Autorizácie pôvodu trasy (ROA)
ROA (RFC 6482) je podpísaný objekt obsahujúci tri polia:
- ASN: Autonómny systém oprávnený vytvoriť predponu.
- Predpona: Autorizovaná predpona IP (IPv4 alebo IPv6).
- maxLength: Maximálna dĺžka prefixu, ktorú je ASN oprávnená oznamovať. Ak nie je zadaný, autorizuje sa len presná predpona. Ak je nastavené, povedzme, 24 pre predponu /20, ASN môže tiež oznámiť akúkoľvek špecifickejšiu hodnotu medzi /20 a /24.
Jedna ROA môže autorizovať viacero prefixov pre rovnakú ASN, ale jedna ROA nemôže autorizovať viacero ASN pre jednu predponu. Ak chcete, aby sekundárne ASN (napr. poskytovateľ verejnej dopravy alebo CDN) vytvorilo vašu predponu, vytvorte pre toto ASN samostatnú ROA.
4. Štáty overenia
Keď smerovač prijme AKTUALIZÁCIU BGP, vykoná overenie pôvodu (RFC 6811) oproti svojej miestnej tabuľke VRP:
| štátu | Podmienka | Typická lokálna preferenčná liečba |
|---|---|---|
| Platné | Aspoň jedna ROA pokrýva predponu (predpona ⊆ predpona ROA A dĺžka predpony ≤ maxLength) A ASN ROA sa zhoduje s pôvodným ASN BGP UPDATE | +20 alebo preferované (bežné) |
| Neplatné | Aspoň jedna ROA pokrýva predponu, ale žiadna pokrývajúca ROA nemá zodpovedajúce ASN a maxLength ≥ ohlásená dĺžka predpony | Nastavte lokálnu predvoľbu 0 alebo znížte (voľba operátora; RFC 6811 odporúča povoliť, ale označiť) |
| NotFound | Neexistuje žiadna ROA, ktorá by pokrývala oznámenú predvoľbu | Nezmenené (zaobchádzalo sa s ním ako pred existenciou RPKI) |
Kľúčový poznatok:Neplatnéje silnejším dôkazom problému akoNotFound. NotFound jednoducho znamená, že vlastník prefixu ešte nevytvoril ROA. Neplatné znamená, že existuje ROA, ktorá hovorí, že toto ASN jenieautorizovaný — silný signál buď nesprávnej konfigurácie alebo únosu.
5. Protokol RTR
Smerovače samy neoverujú reťazce certifikátov X.509 – to by bolo výpočtovo nákladné a vyžadovalo by to udržiavanie úplnej vyrovnávacej pamäte RPKI. Namiesto toho oddanývalidátor RPKI(Routinátor, OctoRPKI, Fort, rpki-client) stiahne a overí celý repozitár RPKI a exportuje len výsledné overené užitočné zaťaženia ROA (VRP) do smerovačov prostredníctvom protokolu RTR (RFC 8210).
RTR používa TCP (port 323 priradený IANA; validátory, ako je napríklad Routinator, predvolene na port 3323, aby sa predišlo vyžadovaniu oprávnení root) s mechanizmom inkrementálnej synchronizácie: validátor odosiela sériové čísla a smerovače požadujú iba delta od poslednej synchronizácie. To udržuje nízku šírku pásma aj pre veľké tabuľky VRP (v súčasnosti ~ 400 000+ záznamov IPv4 globálne).
6. Nasadenie a štatistika
Začiatkom roku 2026 nasadenie RPKI dosiahlo značný rozsah:
- Viac ako 50 % globálne smerovaných IPv4 prefixov má aspoň jednu pokrývajúcu ROA (nárast oproti ~10 % v roku 2019).
- Väčšina poskytovateľov internetových služieb Tier-1 a Tier-2 teraz vykonáva overenie pôvodu trasy a zruší alebo zruší prioritu neplatných ciest.
- MANRS (Mutually Agreed Norms for Routing Security) vyžaduje vytvorenie RPKI ROA ako predpoklad členstva a zverejňuje dashboard zhody pre jednotlivé AS.
Živé štatistiky:Monitor NIST RPKI, ROV++, Štatistiky APNIC RPKI.
7. Mimo ROV: ASPA a BGPsec
Overenie pôvodu trasy RPKI iba overuje, žepôvod ASNje oprávnený oznámiť predvoľbu. Neoveruje AS_PATH – útočník môže stále vytvoriť falošnú AS_PATH s legitímnym pôvodom AS na konci. Riešia to dva štandardy IETF:
- BGPsec (RFC 8205): Každý AS v ceste kryptograficky podpíše AKTUALIZÁCIU, čím sa vytvorí neprerušiteľný reťazec správy. Vyžaduje, aby všetky tranzitné AS podporovali BGPsec – významnú prekážku nasadenia. Zriedkavo nasadzované od roku 2026.
- ASPA(Oprávnenie poskytovateľa autonómneho systému,draft-ietf-sidrops-aspa-profile): AS podpisuje objekt so zoznamom jeho autorizovaných upstream poskytovateľov. Overovatelia dokážu odhaliť neplatné cesty bez údolia (napr. zákazník oznamuje trasy, ako keby to bol poskytovateľ). Jednoduchšie nasadenie ako BGPsec a získanie trakcie v rokoch 2025–2026.
Referencie
- RFC 6480— Infraštruktúra na podporu bezpečného internetového smerovania (prehľad RPKI)
- RFC 6482— Profil pre autorizácie pôvodu trasy (ROA)
- RFC 6811— Overenie pôvodu prefixu BGP
- RFC 8210— Protokol RPKI na smerovač, verzia 1 (RTR)
- RFC 8416— Zjednodušená správa zdrojov miestnych internetových čísel pomocou RPKI (SLURM – lokálne prepisy)
- RFC 9286— Manifests for the Resource Public Key Infrastructure (RPKI)
- RFC 8205— Špecifikácia protokolu BGPsec
- MANRS— Vzájomne dohodnuté normy pre bezpečnosť smerovania
- Portál Cloudflare RPKI— živé vyhľadávanie ROA