Zusammenfassung

  • Ab 07:35 UTC gab AS3223 über AS3356 Routen weiter, die es von Peers gelernt hatte; das Ereignis dauerte etwa zwanzig Minuten [1].
  • Es war ein Pfad- oder Beziehungsleck, keine einfache falsche Ursprungsaussage.
  • RPKI-Ursprungsvalidierung reichte nicht. BGP-Rollen, Only-to-Customer, explizite Richtlinien und eine Überwachung der Routenzusammensetzung beantworten, wer welchen Pfad an welchen Nachbarn weitergeben darf [13][14][15][16].
  • RouteViews und RIPE RIS liefern wertvolle, aber unvollständige Außenbeobachtungen [8][9].
  • Öffentliche Quellen belegen weder Absicht noch genaue interne Ursache, Engpassstelle oder vollständige Betroffenenliste.

Was geschah

Das Border Gateway Protocol, kurz BGP, ist das Protokoll, mit dem unabhängige Netze Erreichbarkeitsinformationen austauschen. Jedes Netz trägt eine Autonomous System Number, kurz ASN. Kentik berichtet, dass Voxility AS3223 von Peers gelernte Routen an Lumen AS3356 ankündigte. Peers tauschen normalerweise Verkehr für ihre jeweiligen Kunden aus, ohne vollständigen Internettransit zu liefern. Ein Transitprovider bietet breitere Erreichbarkeit. Wird eine Peer-Route an einen Provider exportiert, kann sie ihren vorgesehenen Geltungsbereich verlassen [1][11].

Kentik zählte 31.258 Routen. 7.381 davon wurden von mindestens fünfzig Teilnehmern gesehen, die Daten an den öffentlichen Routensammler RouteViews liefern [1][8]. Das zeigt breite Ausbreitung in einer Stichprobe, nicht das gesamte Internet. Pfadbeispiele zu Präfixen von TPG Telecom und Yahoo führten unerwartet über AS3223 und AS3356. Der im Vertrag festgehaltene Wirkmechanismus nennt AS3356, AS3223 und Bukarest als Pfadbestandteile; das ist eine geografische Einordnung des beobachteten Pfads, kein Beweis für jeden betroffenen Nutzer oder den genauen Engpass.

Diese Beispiele machen die Ausbreitung sichtbar, schreiben den Zielnetzen aber keine Ursache zu.

Kentiks Flussdaten verbanden den Pfadwechsel mit fehlgeleitetem sowie stärkerem gestörtem oder verworfenem Verkehr. Sie bestimmen nicht den genauen überlasteten Link. Ein ehrlicher Abschluss hält diese Grenze fest: Der öffentliche Datensatz belegt einen anomalen Pfad und Verkehrsfolgen, aber nicht jede interne Entscheidung.

Warum das wichtig ist

DDoS-Mitigation-Anbieter können berechtigt Routen vieler Kunden transportieren und Ankündigungen in Notfällen schnell aktivieren. Eine starre Liste kann zu breit oder zu langsam sein. Das rechtfertigt keine unbegrenzte Annahme. Erforderlich ist ein Betriebsregister für Kunde, erlaubte Präfixe, Ursprung, Sitzungsrolle, Aktivierungsfenster, Rückweg und Ablauf.

Der Transitprovider hat die spiegelbildliche Pflicht. Er muss autorisierte Kundenrouten von Routen unterscheiden, die der Kunde seitlich von Peers oder Providern gelernt hat. Wenn „dieser Kunde kündigt viele Routen an“ als einzige Regel gilt, erhält ein lokaler Fehler einen globalen Verbreitungskanal. Geplante Richtlinie und tatsächlich laufende Routerkonfiguration müssen abgeglichen werden.

Die technische Ebene

RPKI und Route Origin Authorizations (ROAs) prüfen, ob eine ASN ein Präfix originieren darf [15]. Hier konnte der Ursprung korrekt bleiben, während der Fehler in der Pfadmitte lag. Ursprungsvalidierung beantwortete daher nicht die Beziehungsfrage.

RFC 8212 fordert ausdrückliche Import- und Exportrichtlinien [13]. RFC 9234 beschreibt BGP-Rollen und das Attribut Only-to-Customer (OTC), das Ausbreitungsgrenzen signalisiert [14]. ASPA liefert zusätzliche Hinweise zu Providerbeziehungen [16]. Das sind Kontrollvergleiche, kein Beleg für ihre konkrete Nutzung zwischen AS3223 und AS3356.

ASN-Register und bgp.tools-Seiten verknüpfen Pfade mit stabilen Nummernidentitäten [3][4][5][6]. Sie sind Register, keine Urteile. Entscheidend ist der laufende Zustand: empfangene, ausgewählte, angekündigte und zurückgezogene Routen sowie die zugehörigen Richtlinienversionen.

Wer betroffen war

Ein Leak kann Wege verlängern, Latenz erhöhen, Links überlasten oder Pakete verlieren lassen, obwohl die Zielanwendung gesund bleibt. Ziele, Nutzer, Mitigation, Transit und nachgelagerte Netze sehen unterschiedliche Ausschnitte. Kein Sammler sieht das gesamte Internet. Eine Untersuchung muss Routerprotokolle, Sammler, Flussdaten, Verluste, Kundenmeldungen und Withdrawals zeitlich zusammenführen.

Worauf zu achten ist

Zu überwachen sind die Abweichung zwischen erlaubtem und angekündigtem Routensatz, ungewöhnliche Ursprünge oder Beziehungen, BGP-Rollen- und OTC-Abdeckung, die Konvergenz von RouteViews und RIPE RIS sowie die Verkehrserholung. Eine glaubwürdige Reparatur stellt die genaue Fehlerklasse im Test nach und weist sie beim Export wie beim Import ab.

Die Bewertung ändert sich, falls AS3223 nie exportierte oder AS3356 ablehnte. Sie verschärft sich bei bekannter permissiver Richtlinie, ignorierten Warnungen oder Wiederholung. Sie wird milder bei enger Ursache, automatischer Eindämmung, konsistentem Verschwinden in den Sammlern und unabhängig verifiziertem Fix.

Quellen

  1. https://www.kentik.com/blog/beyond-their-intended-scope-ddos-mitigation-leak/
  2. https://manrs.org/2025/03/beyond-their-intended-scope-ddos-mitigation-leak/
  3. https://bgp.tools/as/3223
  4. https://bgp.tools/as/3356
  5. https://bgp.tools/as/7545
  6. https://bgp.tools/as/10310
  7. https://www.cenic.org/
  8. https://www.routeviews.org/routeviews/
  9. https://ris.ripe.net/docs/
  10. https://www.rfc-editor.org/rfc/rfc4271
  11. https://www.rfc-editor.org/rfc/rfc7908
  12. https://www.rfc-editor.org/rfc/rfc7454
  13. https://www.rfc-editor.org/rfc/rfc8212
  14. https://www.rfc-editor.org/rfc/rfc9234
  15. https://www.rfc-editor.org/rfc/rfc6811
  16. https://www.rfc-editor.org/rfc/rfc8893
  17. https://manrs.org/isps/guide/
  18. https://www.kentik.com/blog/a-brief-history-of-the-internets-biggest-bgp-incidents/