RPKI and BGP Route Origin Validation
RPKI- und BGP-Routenursprungsvalidierung
Wie die Ressourcen-Public-Key-Infrastruktur Routenhijacks verhindert – deckt die ROA-Vertrauenskette, Validierungszustände, das RTR-Protokoll und den aktuellen Stand der Bereitstellung ab.
1. Warum BGP keine native Ursprungsvalidierung hat
BGP wurde für ein kooperatives Internet entwickelt, in dem allen Teilnehmern vertraut wird. Ein Router akzeptiert eine UPDATE-Nachricht und verbreitet sie ohne kryptografische Überprüfung, ob der Ursprungs-AS tatsächlich berechtigt ist, diese IP-Präfixe bekannt zu geben. Dies bedeutet, dass jeder AS – durch Fehlkonfiguration oder böswillige Absicht – die Präfixe einer anderen Person ankündigen kann und dass sich diese Ankündigung innerhalb von Minuten weltweit verbreiten kann.
Bemerkenswerte Vorfälle, die die Einführung von RPKI beschleunigten:
- 2008 – Pakistan Telecom:PTCL hat versehentlich ein spezifischeres Präfix für den Adressraum von YouTube (208.65.153.0/24) angekündigt, wodurch YouTube etwa zwei Stunden lang weltweit blockiert wurde, bevor Upstream-Anbieter die Route zurückzogen.
- 2010 – China Telecom:China Telecom hat etwa 18 Minuten lang etwa 50.000 Präfixe für US-Militär-, Regierungs- und kommerzielle Netzwerke erstellt. Ob versehentlich oder vorsätzlich, wurde nie bestätigt.
- 2018 – Amazon Route 53 DNS-Hijack:Ein Angreifer nutzte BGP, um 205.251.196.0/24 (Amazon DNS) zu kapern und den Kryptowährungs-Wallet-Verkehr umzuleiten, um Gelder zu stehlen. Der Angriff nutzte ein BGP-UPDATE von eNet (AS10297).
- 2019 – Europäischer Verkehr wurde über China Telecom umgeleitet:Der europäische Mobilfunkverkehr (einschließlich Vodafone und Swisscom aus der Schweiz) wurde aufgrund eines BGP-Routenlecks für etwa zwei Stunden über China Telecom umgeleitet.
2. Die RPKI-Vertrauenshierarchie
RPKI (RFC 6480) erstellt eine Hierarchie von X.509-Zertifikaten, die widerspiegelt, wie der IP-Adressraum delegiert wird:
- IANAenthält den Root-Vertrauensanker. Es stellt den fünf RIRs (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) Ressourcenzertifikate aus, die jeweils ihren Adressraum abdecken.
- RIRsstellen ihren Mitgliedern (ISPs, Unternehmen) Zertifikate für den Adressraum aus, den diese Mitglieder besitzen.
- MitgliederEndentitätszertifikate (EE) ausstellen und signierenAutorisierungen für den Routenursprung(ROAs) – signierte Bescheinigungen, die eine bestimmte ASN berechtigen, bestimmte Präfixe zu erstellen.
Prüfer laden diese signierte Objekthierarchie aus fünf RIR-Repositorys (plus allen delegierten Repositorys) herunter, validieren die Zertifikatskette und erstellen eine validierte ROA-Nutzlasttabelle (VRP). Router fragen dann einen lokalen RPKI-Cache über abRTR-Protokoll (RFC 8210), um diese Tabelle abzurufen und eine Ursprungsvalidierung für eingehende BGP-UPDATEs durchzuführen.
3. Routenursprungsautorisierungen (ROAs)
Ein ROA (RFC 6482) ist ein signiertes Objekt, das drei Felder enthält:
- ASN: Das Autonome System, das berechtigt ist, das Präfix zu erstellen.
- Präfix: Das IP-Präfix (IPv4 oder IPv6), das autorisiert wird.
- maxLength: Die maximale Präfixlänge, die der ASN ankündigen darf. Wenn nicht angegeben, ist nur das genaue Präfix zulässig. Wenn beispielsweise 24 für ein /20-Präfix eingestellt ist, kann die ASN auch spezifischere Angaben zwischen /20 und /24 ankündigen.
Ein einzelner ROA kann mehrere Präfixe für dieselbe ASN autorisieren, aber ein ROA kann nicht mehrere ASNs für ein einzelnes Präfix autorisieren. Damit eine sekundäre ASN (z. B. ein Transitanbieter oder CDN) Ihr Präfix erstellen kann, erstellen Sie eine separate ROA für diese ASN.
4. Validierungszustände
Wenn ein Router ein BGP-UPDATE empfängt, führt er eine Ursprungsvalidierung durch (RFC 6811) gegen seine lokale VRP-Tabelle:
| Zustand | Zustand | Typische lokale Präferenzbehandlung |
|---|---|---|
| Gültig | Mindestens ein ROA deckt das Präfix ab (Präfix ⊆ ROA-Präfix UND Präfixlänge ≤ maxLength) UND die ASN des ROA stimmt mit der Ursprungs-ASN des BGP UPDATE überein | +20 oder bevorzugt (üblich) |
| Ungültig | Mindestens ein ROA deckt das Präfix ab, aber kein abdeckender ROA hat eine passende ASN und eine maxLength ≥ der angekündigten Präfixlänge | Local-Pref auf 0 setzen oder löschen (Operatorwahl; RFC 6811 empfiehlt, das Zulassen, aber Markieren zuzulassen) |
| Nicht gefunden | Es existiert kein ROA, der das angekündigte Präfix abdeckt | Unverändert (behandelt wie vor der Existenz von RPKI) |
Die wichtigste Erkenntnis:Ungültigist ein stärkerer Hinweis auf ein Problem alsNicht gefunden. NotFound bedeutet lediglich, dass der Präfixeigentümer noch keinen ROA erstellt hat. Ungültig bedeutet, dass eine ROA vorhanden ist, die besagt, dass diese ASN vorhanden istnichtautorisiert – ein starkes Signal für eine Fehlkonfiguration oder einen Diebstahl.
5. Das RTR-Protokoll
Router validieren X.509-Zertifikatketten nicht selbst – das wäre rechenintensiv und erfordert die Beibehaltung eines vollständigen RPKI-Cache. Stattdessen ein engagierterRPKI-Validator(Routinator, OctoRPKI, Fort, rpki-client) lädt das vollständige RPKI-Repository herunter, validiert es und exportiert nur die resultierenden Validated ROA Payloads (VRPs) über das RTR-Protokoll an Router (RFC 8210).
RTR verwendet TCP (IANA-zugewiesener Port 323; Validatoren wie Routinator verwenden standardmäßig Port 3323, um Root-Rechte zu vermeiden) mit einem inkrementellen Synchronisierungsmechanismus: Der Validator sendet Seriennummern und Router fordern nur das Delta seit ihrer letzten Synchronisierung an. Dadurch bleibt die Bandbreite selbst für große VRP-Tabellen niedrig (derzeit über 400.000 IPv4-Einträge weltweit).
6. Bereitstellung und Statistik
Seit Anfang 2026 hat der RPKI-Einsatz ein erhebliches Ausmaß erreicht:
- Über 50 % der weltweit gerouteten IPv4-Präfixe verfügen über mindestens einen abdeckenden ROA (gegenüber ~10 % im Jahr 2019).
- Die meisten Tier-1- und Tier-2-ISPs führen mittlerweile eine Routenursprungsvalidierung durch und verwerfen oder priorisieren ungültige Routen.
- MANRS (Mutually Agreed Norms for Routing Security) erfordert die Erstellung eines RPKI-ROA als Voraussetzung für die Mitgliedschaft und veröffentlicht ein Konformitäts-Dashboard pro AS.
Live-Statistiken:NIST RPKI-Monitor, ROV++, APNIC RPKI-Statistiken.
7. Über ROV hinaus: ASPA und BGPsec
Die RPKI-Routenursprungsvalidierung überprüft nur, ob dieUrsprungs-ASNist berechtigt, das Präfix bekannt zu geben. Der AS_PATH wird nicht validiert – ein Angreifer kann immer noch einen falschen AS_PATH mit einem legitimen Ursprungs-AS am Ende erstellen. Zwei IETF-Standards befassen sich damit:
- BGPsec (RFC 8205): Jeder AS im Pfad signiert das UPDATE kryptografisch und schafft so eine unzerbrechliche Chain of Custody. Erfordert, dass alle Transit-ASes BGPsec unterstützen – ein erhebliches Bereitstellungshindernis. Ab 2026 kaum noch im Einsatz.
- ASPA(Autonome Systemanbieterautorisierung,Draft-ietf-sidrops-aspa-profile): Ein AS signiert ein Objekt, das seine autorisierten Upstream-Anbieter auflistet. Verifizierer können ungültige talfreie Pfade erkennen (z. B. wenn ein Kunde Routen ankündigt, als wäre er ein Anbieter). Einfacher bereitzustellen als BGPsec und von 2025 bis 2026 zunehmend an Bedeutung gewinnen.
Referenzen
- RFC 6480— Eine Infrastruktur zur Unterstützung sicherer Internet-Routing (RPKI-Übersicht)
- RFC 6482– Ein Profil für Route Origin Authorizations (ROAs)
- RFC 6811– BGP-Präfix-Ursprungsvalidierung
- RFC 8210— Das RPKI-zu-Router-Protokoll, Version 1 (RTR)
- RFC 8416– Vereinfachtes lokales Internetnummern-Ressourcenmanagement mit dem RPKI (SLURM – lokale Überschreibungen)
- RFC 9286– Manifeste für die Resource Public Key Infrastructure (RPKI)
- RFC 8205– BGPsec-Protokollspezifikation
- MANRS– Einvernehmlich vereinbarte Normen für die Routing-Sicherheit
- Cloudflare RPKI-Portal– Live-ROA-Suche