Vier Klassen von Routing-Angriffen entgehen weiterhin der Validierung, warnt neue Studie

Am 20. Mai 2025 stammte ein Border-Gateway-Protocol (BGP)-Update mit einem beschädigten Prefix-SID-Attribut, einem optionalen und transitiven Feld mit dem Code 40, von einem Autonomen System (AS) in der Region Asien-Pazifik. Ein AS ist ein Netzwerk oder eine Gruppe von Netzwerken unter einer einzigen technischen Verwaltung, identifiziert durch eine eindeutige Nummer, und BGP ist das Protokoll, mit dem diese Netzwerke Informationen darüber austauschen, wie man jedes Ziel im Internet erreicht. Was als Nächstes geschah, war weder ein traditioneller Route-Hijack noch ein Route-Leak. Cisco IOS-XR und Nokia SR-OS taten das, was RFC 7606 empfiehlt: Sie verwarfen das fehlerhafte Attribut und machten weiter. Juniper JunOS leitete die Nachricht unverändert weiter. Arista-Router, die sie erhielten, setzten ihre BGP-Sitzungen zurück. Route-Server an mehreren Internet-Knotenpunkten (IXPs), den physischen Orten, an denen verschiedene Netzwerke verbinden und Datenverkehr austauschen, leiteten das Attribut ohne Filterung weiter. Innerhalb von zehn Sekunden sah das globale Routing-System mehr als 150.000 Updates, und BGP-Sitzungen flappten unter anderem bei Starlink, Disney, Zscaler und ByteDance. Arista änderte dieses Verhalten später in EOS 4.28.11 und späteren Versionen.

Nichts, was die Resource Public Key Infrastructure (RPKI), das wichtigste kryptografische System zur Validierung von Routenursprüngen, zu prüfen bestimmt ist, wurde in dieser Kette verletzt. Betreiber haben oft Schwierigkeiten, das Ereignis zu klassifizieren: kein Hijack, kein Leak, nur etwas Seltsames mit einem Attribut. Diese Lücke war einer der Ausgangspunkte für eine neue Studie, die im IEEE Communications Surveys & Tutorials unter CC BY 4.0 (DOI: 10.1109/COMST.2026.3714569) Open Access veröffentlicht wurde. Die Autoren von der Sapienza-Universität Rom, Namex (Rom IXP) und der italienischen Agentur für Cybersicherheit (ACN) greifen die offenen Fragen einer Routing-Sicherheitsstudie von Huston, Rossi und Armitage aus dem Jahr 2011 auf und fragen, was sich in 15 Jahren geändert hat. Die Antwort enthält eine Taxonomie, die sogar sie selbst überraschte.

Die Studie organisiert Routing-Angriffe in vier Makro-Kategorien und acht Mikro-Kategorien und bietet eine konsistente Benennung, sodass jede Klasse den Verteidigungsmaßnahmen zugeordnet werden kann, die sie adressieren. Die erste Makro-Kategorie ist Routenmanipulation, die unbefugte Änderungen an Präfix- oder Pfadinformationen abdeckt. Sie umfasst Präfix-Hijacking (PRH) mit vollständigen, unvollständigen, abfangenden und missbräuchlichen Varianten sowie AS_PATH-Manipulation (ASM) mit Poisoning, gefälschter Ursprungsinjektion, Pfadverkürzung und Pfaderweiterung. Die zweite ist Routing-Konsistenz, Angriffe auf die Stabilität der Routing-Tabelle und nicht auf ihren Inhalt. Dies umfasst Zustandsvolatilität (VOL) wie disruptives Flapping, Fluten durch Oszillation, verstärkten Churn-Injektionen und verzögerte Konvergenz sowie Präfix-Deaggregation (DEG), die böswillig, nachlässig, ausbeuterisch oder eine Fragmentierungsflut sein kann. Die dritte ist Richtlinienverletzung, die Routing-Leaks (RLK) in den vier in RFC 7908 definierten Richtungen und Richtlinienmanipulation (POL) über Local Preference, Multi-Exit Discriminator (MED), AS_PATH-Länge und selektive Weitergabe umfasst. Die vierte sind sitzungsbasierte Angriffe, insbesondere attributbasierter Sitzungsreset (ATR), bei dem fehlerhafte optionale transitive Attribute, ausnutzung herstellerspezifischer Attribute oder Missbrauch der Fehlerbehandlungsrichtlinie BGP-Sitzungen zurücksetzen können. Das Ereignis vom Mai 2025 gehört in diese vierte Kategorie.

Das Übereinanderlegen bestehender Verteidigungsmaßnahmen auf diese Struktur ergibt ein unausgewogenes Bild. Präfix-Hijacking hat die meisten Fortschritte gesehen, aber mit wichtigen Einschränkungen. Internet Routing Registries (IRRs) und RPKI bieten Ursprungsvalidierung, und die Abdeckung von Route Origin Authorizations (ROA) steigt weiter. Abdeckung ist jedoch nicht Durchsetzung: Eine Längsschnittstudie über mehr als 28.000 ASes ergab, dass 36,2 % Route Origin Validation (ROV) überhaupt nicht implementieren, und nur 12,3 % erreichen vollständigen Schutz. Permissive maxLength-Einstellungen können die Angriffsfläche vergrößern statt verkleinern, weshalb RFC 9319 veröffentlicht wurde. Missbräuchliches Hijacking von nicht angekündigtem Adressraum bleibt möglich, wo Objekte nicht gepflegt werden. AS_PATH-Manipulation wird prinzipiell teilweise durch BGPsec adressiert, ein Protokoll, das den Pfad, den eine Ankündigung nimmt, kryptografisch signiert, aber es ist im Wesentlichen nicht eingesetzt. Ein einziges nicht adoptierendes AS im Pfad entfernt die Sicherheitsinformationen, was eine teilweise Bereitstellung fast wertlos macht. Routing-Leaks zeigen die ermutigendste Entwicklung: Autonomous System Provider Authorization (ASPA)-Objekte, mit denen Netzwerke ihre legitimen Upstream-Provider auflisten können, sind seit Dezember 2025 in den Repositorien der Regional Internet Registries veröffentlichbar, mit 1.314 registrierten zum Zeitpunkt des Schreibens. Analysen deuten darauf hin, dass die Bereitstellung durch strategisch positionierte ASes die Anzahl der von Leaks betroffenen ASes um bis zu 96 % reduzieren könnte. Das Only-to-Customer (OTC)-Attribut und die Down-Only-Community, die beide auf in RFC 9234 definierten Rollen aufbauen, könnten über 98 % der Multi-Hop-Leaks unterdrücken, wenn sie selektiv in gut verbundenen Tier-1- und Tier-2-Netzwerken übernommen würden.

Im krassen Gegensatz dazu haben die verbleibenden vier Klassen, Zustandsvolatilität, Präfix-Deaggregation, Richtlinienmanipulation und attributbasierter Sitzungsreset, überhaupt keine kryptografische Antwort. Nicht einmal eine teilweise bereitgestellte, keine. Sie werden nur mit operativer Härtung, Control-Plane-Policing, Max-Prefix-Limits, Präfixlängen-Filtern, Richtlinienhygiene, robuster Fehlerbehandlung und Attributfilterung an Route-Servern adressiert. All dies ist lokal, reaktiv und für die Partei, die die Konsequenzen trägt, nicht überprüfbar. Es gibt kein Äquivalent zum Überprüfen einer ROA und Verwerfen ungültiger Ankündigungen, und keinen globalen Zustand, den man abfragen könnte. Wenn ein Betreiber fragt, ob er gegen eine Fragmentierungsflut von einem Peer geschützt ist, ist die ehrliche Antwort, dass er ein Max-Prefix-Limit und eine Hoffnung hat.

Zwei Verschiebungen haben diese nicht abgedeckten Klassen wichtiger gemacht als früher. Die erste ist IPv6-Arithmetik. Ein IPv6-Adressblock, das neuere und viel größere Internet-Adressierungsschema, kann viel aggressiver unterteilt werden als IPv4. Innerhalb einer einzigen /29-Zuweisung können bis zu 524.288 verschiedene /48-Blöcke erzeugt und angekündigt werden. Die globale IPv6-BGP-Tabelle enthält derzeit etwa 219.000 Einträge. Eine Zuweisung, ein Router, und die Tabelle verdoppelt sich mehr als. Die Verteidigung, ein statischer Max-Prefix-Schwellenwert, bricht auch legitimes Wachstum, wenn er zu eng gesetzt ist, weshalb Betreiber ihn genau deshalb locker setzen. Die zweite Verschiebung ist, dass der Teilerfolg der Ursprungsvalidierung die Aufmerksamkeit der Angreifer umverteilt. Mit wachsender ROV-Durchsetzung sinkt die Rendite des Hijackings eines Präfixes, während die Rendite der Klassen, die niemand validiert, steigt. Dies ist keine Behauptung über die Absichten von irgendjemandem; es ist die gewöhnliche Ökonomie einer Kontrolle, die eine Sache gut abdeckt.

Bei der Wiederaufnahme der offenen Fragen von 2011 bleiben vier aktuell. Erstens: Kann eine vertrauende Partei nicht nur validieren, dass der AS_PATH in einem Update dem Pfad entspricht, den die Ankündigung gereist ist, sondern auch, dass der tatsächliche Weiterleitungszustand des Netzwerks damit übereinstimmt? Pfadvalidierungsmechanismen, einschließlich ASPA und BGPsec, sichern die Control Plane, den Teil des Netzwerks, der entscheidet, wohin der Verkehr gehen soll, sagen aber nichts darüber, wohin Pakete tatsächlich gehen. Vorschläge wie FC-BGP und SBAS versuchen, diese Lücke zu schließen, bleiben aber beide experimentell. Dies ist das technisch schwierigste offene Problem auf diesem Gebiet. Zweitens: Wenn sich ein umfassendes Framework als nicht bereitstellbar erweist, kann ein weniger umfassendes akzeptable Ergebnisse liefern? Die Beweislage sagt ja, aber die Wirksamkeit hängt von der Betreiberpolitik ab. Eine Umfrage unter 100 Betreibern ergab, dass die partielle Pfadvalidierung gut schützt, wenn Richtlinien sichere Routen bevorzugen, und viel weniger gut, wenn sie kurze bevorzugen. Partielle Bereitstellung sollte die Grundannahme für neue Vorschläge sein, nicht der degradierte Fall. Drittens: Verbesserung des Bestehenden: Die Rechenkosten sind nicht mehr das Haupthindernis, aber die operative Komplexität. Die Verwaltung von ROAs, IRR-Datensätzen, ASPA-Beziehungen und Zertifikaten ist eine echte Belastung, unverhältnismäßig für kleinere Netzwerke mit begrenztem Personal. Vorschläge wie Signed Prefix Lists, die permissive maxLength durch explizite Aufzählung beabsichtigter Ankündigungen ersetzen, sind gerade deshalb interessant, weil sie ein wenig mehr Wartung gegen viel weniger Mehrdeutigkeit eintauschen. Viertens: Hilfswerkzeuge. Angesichts der Tatsache, dass Sicherheit auf Protokollebene unvollständig ist und bleiben wird, gewinnen Überwachung und Risikobewertung an Bedeutung. Tools wie ARTEMIS, ROSE-T, Ursprungsänderungs-Erkennungssysteme und Risikobewertungen, die aus IXP-Route-Server-Routing-Informationsbasen (RIBs) abgeleitet werden, bieten Mehrwert, ohne Änderungen an BGP oder Koordination über ASes hinweg zu erfordern. Ihre Wirksamkeit hängt jedoch vollständig von der Qualität der IRR-Datensätze, RPKI-Repositorien und AS-Beziehungsdaten ab, die inkonsistent gepflegt werden. Die Verbesserung dieser Datensätze ist eine Voraussetzung für alles andere.

Drei Beobachtungen durchziehen all dies. Bereitstellbar schlägt optimal, durchgängig: S-BGP, soBGP und psBGP boten stärkere Garantien als alles heute Bereitgestellte und verschwanden, während RPKI, IRR und jetzt ASPA an Zugkraft gewannen, weil sie inkrementell übernommen werden können. Universelle Übernahme ist keine realistische Annahme, und Entwürfe, die sie erfordern, haben eine schlechte Erfolgsbilanz. Die Kosten sind individuell und der Nutzen ist kollektiv, ein klassisches Kollektivgutproblem, weshalb gut gestaltete Mechanismen ins Stocken geraten. Hier sind institutionelle Hebel wichtig, wie die NIS2-Richtlinie der Europäischen Union, der vorgeschlagene Digital Networks Act und nationale Strategien, obwohl ihre Wirksamkeit von Durchsetzung und Compliance-Überwachung abhängt, die in den verschiedenen Rechtsgebieten ungleichmäßig bleibt.

Die Autoren laden auch zum Widerspruch ein. Der Teil, bei dem sie am wenigsten sicher sind, ist die Grenze zwischen Angriff und Unfall. Fast jeder Vorfall in den nicht abgedeckten Klassen hat eine plausible unschuldige Erklärung: eine falsch konfigurierte Redistribution, ein Skript, das zweimal lief, ein Herstellerfehler. Diese Mehrdeutigkeit ist genau der Grund, warum diese Klassen unterforscht sind, aber sie könnte auch bedeuten, dass das Risiko überbewertet ist. Die Autoren würden lieber von Netzwerkbetreibern korrigiert werden, als in einer Zeitschrift recht zu haben. Wenn die operative Erfahrung sagt, dass das Max-Prefix-Limit in Ordnung ist oder dass die RFC-7606-Konformität jetzt gut genug ist, ist das das Gespräch, das sie hoffen zu beginnen.

Für Organisationen, die ihre eigene Netzwerkinfrastruktur betreiben, bedeutet die Umsetzung dieser Erkenntnisse in die Praxis oft die Zusammenarbeit mit einer sicherheitsorientierten IT- und Infrastrukturberatung wie AEU-I, die bei der Bewertung von Routing-Sicherheitskontrollen wie RPKI-Validierung und Präfix-Filterung helfen kann, bevor ein Vorfall Lücken aufdeckt. Die Studie „Survey on Internet Routing Security: Stakeholder Interests, Current and Future Research Directions“ ist unter CC BY 4.0 in IEEE Communications Surveys & Tutorials, DOI: 10.1109/COMST.2026.3714569, Open Access. Sie ist eine Zusammenarbeit zwischen der Sapienza-Universität Rom, Namex (Rom IXP) und der italienischen Agentur für Cybersicherheit (ACN). Flavio Luciani ist Chief Technology Officer bei Namex und Co-Autor des Buches „BGP: from theory to practice“.