RPKI and BGP Route Origin Validation
RPKI és BGP Route Origin Validation
Hogyan akadályozza meg az erőforrás nyilvános kulcsú infrastruktúrája az útvonal-eltérítéseket – lefedi a ROA megbízhatósági láncot, az érvényesítési állapotokat, az RTR protokollt és a telepítés jelenlegi állását.
1. Miért nem érvényes a BGP eredeti eredete?
A BGP-t olyan kooperatív internethez tervezték, ahol minden résztvevőben megbíztak. Az útválasztó elfogad egy UPDATE üzenetet, és kriptográfiai ellenőrzés nélkül továbbítja azt, hogy a kiinduló AS valóban jogosult-e ezen IP-előtagok bejelentésére. Ez azt jelenti, hogy bármely AS – hibás konfiguráció vagy rosszindulat miatt – bejelentheti valaki más előtagjait, és ez a bejelentés perceken belül globálisan terjedhet.
Figyelemre méltó események, amelyek felgyorsították az RPKI elfogadását:
- 2008 – Pakistan Telecom:A PTCL véletlenül egy specifikusabb előtagot jelentett be a YouTube címteréhez (208.65.153.0/24), ami a YouTube-ot globálisan mintegy 2 órán keresztül feketeholta, mielőtt az upstream szolgáltatók visszavonták az útvonalat.
- 2010 – China Telecom:A China Telecom körülbelül 50 000 előtagot hozott létre, amelyek az Egyesült Államok katonai, kormányzati és kereskedelmi hálózataihoz tartoznak ~18 percig. Hogy véletlen vagy szándékos, azt soha nem erősítették meg.
- 2018 – Amazon Route 53 DNS-eltérítés:Egy támadó a BGP-t használta a 205.251.196.0/24 (Amazon DNS) eltérítésére, átirányítva a kriptovaluta pénztárca forgalmat pénzek ellopására. A támadás az eNet BGP UPDATE-jét (AS10297) használta.
- 2019 – Az európai forgalom átirányítása a China Telecomon keresztül:Az európai mobilforgalom (beleértve a Vodafone-ot és a svájci Swisscomot is) a China Telecomon keresztül körülbelül 2 órára átirányították a BGP-útvonal-szivárgás miatt.
2. Az RPKI Trust Hierarchia
RPKI (RFC 6480) az X.509-tanúsítványok hierarchiáját építi fel, tükrözve az IP-címterület delegálásának módját:
- IANAtartja a gyökér bizalom horgonyt. Erőforrástanúsítványokat ad ki az öt RIR-nek (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), amelyek mindegyike lefedi a saját címterét.
- RIR-ektanúsítványokat állítanak ki tagjaiknak (internetszolgáltatók, vállalkozások) az általuk birtokolt címterületre.
- tagokEnd Entity (EE) tanúsítványokat bocsát ki és írja aláÚtvonal kiindulási engedélyei(ROA) – aláírt tanúsítványok, amelyek felhatalmazzák egy adott ASN-t meghatározott előtagok létrehozására.
A hitelesítők letöltik ezt az aláírt objektum-hierarchiát öt RIR-lerakatból (plusz a delegált lerakatból), érvényesítik a tanúsítványláncot, és létrehoznak egy érvényesített ROA hasznos adattáblázatot (VRP). Az útválasztók ezután lekérdeznek egy helyi RPKI gyorsítótárat aRTR protokoll (RFC 8210).
3. Route Origin Authorizations (ROA)
A ROA (RFC 6482) egy aláírt objektum, amely három mezőt tartalmaz:
- ASN: Az előtag létrehozására jogosult autonóm rendszer.
- Előtag: Az IP-előtag (IPv4 vagy IPv6) engedélyezett.
- maxLength: Az a maximális előtaghossz, amelyet az ASN bejelenthet. Ha nincs megadva, csak a pontos előtag engedélyezett. Ha mondjuk 24-re van állítva egy /20 előtagnál, az ASN a /20 és /24 közötti konkrétabbakat is bejelentheti.
Egyetlen ROA több előtagot is engedélyezhet ugyanahhoz az ASN-hez, de egy ROA nem engedélyezhet több ASN-t egyetlen előtaghoz. Ha engedélyezni szeretné, hogy egy másodlagos ASN (például egy tranzitszolgáltató vagy CDN) előhívja az előtagot, hozzon létre külön ROA-t az ASN számára.
4. Érvényesítési állapotok
Amikor egy útválasztó BGP FRISSÍTÉST kap, eredetellenőrzést végez (RFC 6811) a helyi VRP-táblázattal szemben:
| Állami | Állapot | Tipikus helyi preferencia kezelés |
|---|---|---|
| Érvényes | Legalább egy ROA lefedi az előtagot (előtag ⊆ ROA előtag ÉS előtag hossza ≤ maxLength), ÉS a ROA ASN-je megegyezik a BGP UPDATE eredeti ASN-jével. | +20 vagy preferált (gyakori) |
| Érvénytelen | Legalább egy ROA lefedi az előtagot, de egyetlen lefedő ROA sem rendelkezik megfelelő ASN-vel és maxLength értékkel ≥ a bejelentett előtag hosszával | Állítsa be a helyi beállítást 0-ra vagy dobja le (az operátor választása; az RFC 6811 engedélyezi, de jelölje meg) |
| Nem található | Nincs olyan ROA, amely lefedi a bejelentett előtagot | Változatlan (mint az RPKI létezése előtt) |
A legfontosabb betekintés:Érvénytelenerősebb bizonyíték a problémára, mintNem található. A NotFound egyszerűen azt jelenti, hogy az előtag tulajdonosa még nem hozott létre ROA-t. Az érvénytelen azt jelenti, hogy létezik egy ROA, amely szerint ez az ASNnemengedélyezett – a rossz konfiguráció vagy az eltérítés erős jele.
5. Az RTR protokoll
Az útválasztók maguk nem érvényesítik az X.509 tanúsítványláncokat – ez számítási szempontból költséges lenne, és teljes RPKI-gyorsítótárat igényelne. Ehelyett egy dedikáltRPKI validátor(Routinator, OctoRPKI, Fort, rpki-client) letölti és érvényesíti a teljes RPKI-tárat, és csak az eredményül kapott Validated ROA Payloads-okat (VRP-ket) exportálja a routerek az RTR protokollon keresztül (RFC 8210).
Az RTR a TCP-t (IANA-hoz rendelt 323-as port; az olyan érvényesítők, mint például a Routinator alapértelmezés szerint a 3323-as portot használják, hogy elkerüljék a root jogosultságokat) növekményes szinkronizálási mechanizmussal: az érvényesítő sorozatszámokat küld, az útválasztók pedig csak az utolsó szinkronizálás óta eltelt időszakot kérik. Ez még a nagy VRP-táblák esetében is alacsonyan tartja a sávszélességet (jelenleg kb. 400 000+ IPv4 bejegyzés globálisan).
6. Telepítés és statisztika
2026 elejétől az RPKI bevezetése jelentős léptéket ért el:
- A globálisan irányított IPv4-előtagok több mint 50%-a rendelkezik legalább egy lefedő ROA-val (a 2019-es kb. 10%-hoz képest).
- A Tier-1 és Tier-2 internetszolgáltatók többsége most már az útvonal eredetének ellenőrzését végzi, és az érvénytelen útvonalakat elveti vagy prioritáson kívül helyezi.
- A MANRS (Mutually Agreed Norms for Routing Security) megköveteli az RPKI ROA létrehozását a tagság előfeltételeként, és AS-onkénti megfelelőségi irányítópultot tesz közzé.
Élő statisztika:NIST RPKI monitor, ROV++, APNIC RPKI statisztika.
7. ROV-n túl: ASPA és BGPsec
Az RPKI Route Origin Validation csak azt ellenőrzi, hogy aeredet ASNjogosult az előtag bejelentésére. Nem érvényesíti az AS_PATH-t – a támadó továbbra is létrehozhat egy hamis AS_PATH-t, amelynek a végén legitim eredetű AS. Két IETF szabvány foglalkozik ezzel:
- BGPsec (RFC 8205): Az elérési út minden AS-je kriptográfiailag aláírja a FRISSÍTÉST, megbonthatatlan felügyeleti láncot hozva létre. Minden tranzit AS-nek támogatnia kell a BGPsec-et – ez egy jelentős telepítési akadály. 2026 óta ritkán telepítették.
- ASPA(Autonóm rendszerszolgáltatói jogosultság,draft-ietf-sidrops-aspa-profil): Az AS aláír egy objektumot, amely felsorolja a jogosult upstream szolgáltatóit. Az ellenőrzők észlelhetik az érvénytelen, völgy nélküli útvonalakat (pl. egy ügyfél úgy hirdeti meg az útvonalakat, mintha szolgáltató lenne). Egyszerűbb telepíteni, mint a BGPsec, és 2025–2026-ban egyre nagyobb teret nyer.
Hivatkozások
- RFC 6480– A biztonságos internetes útválasztást támogató infrastruktúra (RPKI áttekintése)
- RFC 6482— Az útvonal eredetengedélyeinek (ROA) profilja
- RFC 6811— BGP előtag eredetének ellenőrzése
- RFC 8210– Az RPKI-ból Router Protocol, 1-es verzió (RTR)
- RFC 8416– Egyszerűsített helyi internetszám-erőforrás-kezelés az RPKI-vel (SLURM – helyi felülírások)
- RFC 9286— A nyilvános kulcsú erőforrás-infrastruktúra (RPKI) kiáltványai
- RFC 8205— BGPsec Protokoll specifikáció
- MANRS— Kölcsönösen elfogadott normák az útválasztás biztonságára
- Cloudflare RPKI portál— élő ROA keresés