- Im Netzwerk von CANTV (AS8048) in Venezuela kam es mehrfach zu BGP-Route-Leaks, wodurch einige Netzwerkpfade anormal weiterverbreitet wurden
- Laut Daten von Cloudflare Radar wurden seit Dezember 11 Leak-Ereignisse bestätigt; als wahrscheinlichste Ursache gilt ein technischer Fehler durch unzureichende Routing-Richtlinien
- In diesem Vorfall leitete AS8048 Pfade, die es vom Upstream-Provider AS6762 (Sparkle) erhalten hatte, an einen anderen Provider AS52320 (V.tal GlobeNet) weiter – eine typische Struktur eines Type-1-Hairpin-Leaks
- RPKI-basierte Route Origin Validation (ROV) ist in diesem Fall nicht wirksam; zur Verhinderung solcher Leaks werden neue Standards wie ASPA (Autonomous System Provider Authorization) und RFC9234 benötigt
- Aufgrund der vertrauensbasierten Struktur von BGP sind solche Vorfälle häufig; die Einführung von Technologien wie ASPA, Peerlock und RFC9234 ist entscheidend für einen sicheren Internetbetrieb
Das Konzept von BGP-Route-Leaks
- BGP (Border Gateway Protocol) ist das Protokoll zum Austausch von Pfaden zwischen autonomen Systemen (AS) im Internet
- Beziehungen zwischen Netzwerken sind als Customer-Provider oder Peer-Peer organisiert
- Ein Route-Leak wird in RFC7908 als „Weiterverbreitung von Routing-Informationen über den beabsichtigten Geltungsbereich hinaus“ definiert
- Beispiel: Wenn ein Kunde Pfade, die er von einem Provider erhalten hat, erneut an einen anderen Provider weiterverbreitet
- Solche Leaks verstoßen gegen die Valley-Free-Routing-Regel, wodurch Traffic über anormale Pfade geleitet wird
- Das führt zu Problemen wie Netzwerküberlastung, Latenz und Traffic-Verlust
Der Route-Leak-Fall von AS8048 (CANTV)
- Cloudflare Radar bestätigte, dass AS8048 (CANTV) Pfade, die von AS6762 (Sparkle) empfangen wurden, an AS52320 (V.tal GlobeNet) weiterleitete
- Das ist ein eindeutiger Route-Leak
- Der Ursprung der geleakten Pfade war AS21980 (Dayco Telecom), ein Kundennetzwerk von AS8048
- Die Beziehung zwischen beiden AS wird in Daten von Cloudflare Radar und bgp.tools als Provider-Kunde-Beziehung bestätigt
- Im Pfad war AS8048 mehrfach prepended
- Prepending ist eine Technik, um einen Pfad weniger attraktiv zu machen und Traffic auf andere Wege zu lenken
- Daher ist die Wahrscheinlichkeit eines absichtlichen MITM-Angriffs (Man-in-the-Middle) gering
- Die Leaks traten am 2. Januar 2026 zwischen 15:30 und 17:45 UTC mehrfach auf und sind wahrscheinlich auf Fehler in Netzwerkrichtlinien oder Konvergenzprobleme zurückzuführen
- Laut Cloudflare-Radar-Aufzeichnungen haben sich seit Dezember 11 ähnliche Leaks wiederholt, was auf anhaltende Richtlinienmängel hindeutet
Technische Ursachen und Probleme bei Richtlinien
- Es ist möglich, dass AS8048 die Routing-Export-Richtlinie gegenüber dem Provider AS52320 zu locker konfiguriert hatte
- Falls statt Customer-BGP-Community-Tags nur IRR-basierte Prefix-Listen verwendet wurden, kann es zu einer fehlerhaften Weiterverbreitung von Pfaden kommen
- Solche Richtlinienfehler lassen sich durch das Only-to-Customer-(OTC)-Attribut aus RFC9234 verhindern
- OTC definiert BGP-Rollen (Kunde, Provider, Peer) explizit und blockiert falsche Pfadverbreitung
Die Rolle von RPKI und ASPA
- Sparkle (AS6762) hat RPKI Route Origin Validation (ROV) nicht vollständig implementiert,
- doch da es sich hier um eine Pfad-Anomalie handelt, kann ROV den Vorfall nicht verhindern
- ASPA (Autonomous System Provider Authorization) bietet pfadbasierte Validierung
- Jedes AS gibt eine Liste autorisierter Upstream-Provider an, sodass anormale Pfade automatisch blockiert werden können
- Beispiel: Wenn AS6762 erklärt, dass es keine Upstream-Provider hat, können andere Netzwerke falsche Pfade, die AS6762 enthalten, ablehnen
- ASPA arbeitet auf Basis von RPKI und hat direkte Wirkung bei der Verhinderung von Route-Leaks
Vorschläge für ein sicheres BGP
- BGP ist seinem Wesen nach ein vertrauensbasiertes Protokoll, daher sind Leaks durch Richtlinienfehler oder Fehlkonfigurationen häufig
- Wenn Technologien wie ASPA, RFC9234 und Peerlock/Peerlock-lite gemeinsam eingesetzt werden,
- wird die Pfadvalidierung gestärkt
- die Verbreitung falscher Pfade blockiert
- und die Netzwerkstabilität verbessert
- RIPE unterstützt bereits die Erstellung von ASPA-Objekten,
- und Betreiber sollten von Netzwerkgeräteherstellern die Implementierung von RFC9234 einfordern
- Die Einführung solcher kooperativen Standards ist ein zentraler Hebel zur Verhinderung von BGP-Vorfällen wie im Fall Venezuela
Noch keine Kommentare.