Zusammenfassung

  • Der begrenzte Gegenstand ist der BGP-Route-Leak vom 25. Mai 2023 im Zusammenhang mit AS37468 [1][2].
  • BGP verteilt Erreichbarkeitsinformationen, ist aber kein zentrales Berechtigungssystem für jeden weitergegebenen Pfad.
  • RPKI-Origin-Validation kann einen Ursprung prüfen, validiert aber nicht den gesamten AS-Pfad oder die Beziehung, über die eine Route exportiert wurde [14][15].
  • AFRINIC RDAP, bgp.tools und PeeringDB liefern Identitäts- und Registerkontext, keine Schuldbeweise [4][5][6].
  • Eine belastbare Aufarbeitung braucht Exportabsicht, tatsächliche Ankündigungen, Nachbarentscheidungen, Collector-Zeitlinien, Validierungsstatus und einen testbaren Präventionsmechanismus.

Was geschah

Für betroffene Nutzer zeigt sich ein Routingproblem oft nur als langsame Anwendung. Der Dienst in den USA kann funktionieren und trotzdem schwer erreichbar sein, weil der gewählte Weg schlechter geworden ist. Ein Netz kündigt eine Route an, ein Nachbar akzeptiert sie, weitere Netze wählen sie, und der Datenverkehr folgt einer ungeplanten Strecke. Genau deshalb sind Route Leaks keine interne Kleinigkeit von Netzbetreibern.

Die öffentlichen Quellen legen nicht offen, welcher Routerbefehl ausgeführt wurde, welche Prefixe vollständig betroffen waren oder welche internen Alarme ausgelöst wurden. Sie beweisen auch keine Absicht. Das schränkt die Sprache ein. Es verhindert aber nicht die technische Verantwortungsfrage: Welche Import-, Export- und Beziehungsrichtlinien hätten diese Propagation stoppen oder begrenzen sollen?

Warum Pfadvalidierung mehr ist als Ursprung

RPKI und ROAs beantworten eine wichtige Frage: Darf ein bestimmtes AS einen bestimmten Prefix originieren? Das hilft bei falschen Ursprüngen. Ein Route Leak kann jedoch entstehen, obwohl der Ursprung plausibel bleibt. Dann liegt der Fehler im Weg, in der Beziehung oder im Exportumfang. Eine Route kann syntaktisch gültig aussehen und trotzdem über eine Grenze laufen, die sie nicht überschreiten sollte.

RFC 7908 beschreibt Route Leaks als Verletzungen des vorgesehenen Propagationsbereichs. RFC 8212 betont explizite Import- und Exportrichtlinien. RFC 9234 beschreibt BGP-Rollen und Only-to-Customer als Beziehungssignale. Diese Dokumente beweisen nicht, welche Technik am 25. Mai 2023 aktiv war. Sie zeigen, welche Kontrollen in einer Untersuchung gesucht werden müssen.

Identität und Register

AS37468 gibt der Analyse ein technisches Objekt. bgp.tools zeigt Routingkontext, AFRINIC RDAP liefert den autnum-Registereintrag, und PeeringDB beschreibt Teile der deklarierten Interconnection-Oberfläche [4][5][6]. Diese Datensätze sind Belegbücher. Sie sagen nicht, welche Route ein Nachbar angenommen hat und ob eine konkrete Richtlinie fehlte.

Das ist der entscheidende Punkt: Ein Register konfiguriert keinen Router. Die operative Realität liegt in laufender Policy, exportierten Routen, akzeptierenden Nachbarn und öffentlichen Beobachtungen. Register sind notwendig, weil sie Identität und Ressourcen sauber verbinden. Sie ersetzen keine Logs und keine Pfadbeweise.

Collector-Beweise

RouteViews und RIPE RIS geben der Öffentlichkeit einen Blick auf den Kontrollplan [7][8]. Sie sind nicht allwissend. Sie sehen, was teilnehmende Peers senden. Ein sichtbarer Pfad beweist nicht, dass jedes Netz ihn gewählt hat. Trotzdem sind sie unverzichtbar, weil sie Aussagen über Routingzustand überprüfbar machen.

Eine gute Aufarbeitung verbindet Collector-Daten mit internen Logs. Wann wurde der abweichende Pfad sichtbar? Welche AS-Pfade tauchten auf? Wann kamen Withdrawals? War der Pfad nach der angeblichen Reparatur noch sichtbar? Diese Fragen trennen eine echte Wiederherstellung von einer bloßen Behauptung.

Was Reparatur beweisen sollte

Der Betreiber sollte zeigen, welche Routen AS37468 exportieren wollte und was tatsächlich in Adj-RIB-Out stand. Nachbarn sollten zeigen, was sie empfingen, was sie ablehnten, was sie weitergaben und welche Regeln dafür galten. Validierungsstatus, IRR-Daten, Maximum-Prefix-Grenzen, Beziehungspolitik und Alarmierung gehören zur Beweiskette.

Die Prävention muss testbar sein. Strengere Exportlisten, generierte Kundenfilter, Default-Deny auf eBGP-Sitzungen, sinnvolle Prefix-Grenzen, RPKI-Policy, BGP-Rollen oder Collector-Monitoring können helfen. Wichtig ist nicht nur, dass der schlechte Pfad verschwunden ist. Wichtig ist, dass dieselbe Fehlerklasse künftig geschlossen scheitert.

Schluss

Der Fall zeigt, dass Routingverantwortung aus mehreren Schichten besteht. Register geben Identität, RPKI gibt Ursprungssignale, BGP-Policy bestimmt Beziehungen, Collector zeigen sichtbare Zustände, und Betreiberlogs erklären Ursache und Reparatur. Erst zusammen bilden sie eine belastbare Wirklichkeitsschicht.

Quellen

  1. https://manrs.org/2023/05/bgp-route-leak-at-angola-cables-slows-connectivity-for-many-australians/
  2. https://pulse.internetsociety.org/en/news/2023/05/bgp-route-leak-at-angola-cables-slows-connectivity-for-many-australians/
  3. https://seclists.org/nanog/2023/May/368
  4. https://bgp.tools/as/37468
  5. https://rdap.afrinic.net/rdap/autnum/37468
  6. https://www.peeringdb.com/net?asn=37468
  7. https://www.routeviews.org/routeviews/
  8. https://ris.ripe.net/docs/
  9. https://www.rfc-editor.org/rfc/rfc4271
  10. https://www.rfc-editor.org/rfc/rfc7908
  11. https://www.rfc-editor.org/rfc/rfc7454
  12. https://www.rfc-editor.org/rfc/rfc8212
  13. https://www.rfc-editor.org/rfc/rfc9234
  14. https://www.rfc-editor.org/rfc/rfc6811
  15. https://www.rfc-editor.org/rfc/rfc8893
  16. https://www.rfc-editor.org/rfc/rfc9319
  17. https://manrs.org/isps/guide/
  18. https://www.kentik.com/blog/a-brief-history-of-the-internets-biggest-bgp-incidents/