Zusammenfassung

  • Im Fall von 2025 zeigte das Looking Glass von SEACOM den legitimen SingNet-Präfix 203.127.0.0/16, nicht aber den unbefugt von Innove angekündigten 203.127.225.0/24. Ein Traceroute aus SEACOM erreichte dennoch Hops in Innoves AS.
  • ROV bewertet den Ursprung einer empfangenen Route. Die Entscheidung, Invalid zu verwerfen, ist lokal; sie verpflichtet den benachbarten Transitbetreiber nicht zur selben Wahl.
  • BMP kann die gewählten BGP-Sichten eines überwachten Routers übermitteln. Die Nachbar-RIB und das tatsächliche Paket-Forwarding sind damit nicht automatisch beobachtet.

Ein leerer Eintrag als trügerische Entwarnung

„Network not in table“ meldete das SEACOM-Looking-Glass für 203.127.225.0/24. Den umfassenden 203.127.0.0/16 kannte es dagegen als gültige Route mit SingNet (AS3758) am Ursprung. Li und Kollegen dokumentieren die Originalausgaben in einem Internet-Draft. Der engere Präfix kam von Innove Communications (AS17894), das dafür nicht als Ursprung autorisiert war. Die Forscher ordnen SEACOM (AS37100) eine funktionierende ROV-Filterung zu.

Ein zweiter Befehl prüfte nicht die BGP-Tabelle, sondern den Weg zu 203.127.225.1. Der Traceroute aus SEACOM lief über TISparkle (AS6762), FLAG Telecom (AS15412) und Globe Telecom (AS4775) bis zu Hops in AS17894. Die lokale Ablehnung und dieser Pfad können gleichzeitig zutreffen: Nach der Übergabe an AS6762 galt dessen eigene Routenauswahl. Die Messung belegt eine eingegrenzte Strecke, nicht sämtliche Kundenpakete oder die Erreichbarkeit des Ziel-Dienstes.

Die Autoren berichten von einer Meldung an Globe am 10. Februar 2025 und einer letzten Beobachtung am 24. April. Sie halten eine harmlose Fehlkonfiguration für plausibel; Absicht ist nicht belegt. Ihr individuelles Internet-Draft ist ein Arbeitsdokument, kein gebilligter IETF-Standard. Auf der APNIC 62 nahm Nokias Ritesh Mukherjee den Befund als Beispiel für das „Good Neighbor Problem“ auf. Er fragt, was der Schutz des eigenen Netzes noch aussagt, sobald ein Transitnachbar anders filtert.

Die Grenze einer gültigen ROA

SingNet kündigte den /16 legitim an. Innoves /24 hatte einen nicht autorisierten Ursprung. RFC 6811 bestimmt anhand validierter ROA-Daten die Zustände Valid, Invalid und NotFound; über den Ausschluss einer Invalid-Route entscheidet ausdrücklich die lokale Policy. SEACOM konnte den /24 verwerfen und für das Ziel die /16-Route in Richtung AS6762 wählen. Hatte TISparkle den /24 angenommen, konnte dort die längere Präfix-Übereinstimmung gewinnen. Weder ROA noch lokales ROV validieren die ganze AS-Kette oder konfigurieren einen fremden Router.

Mukherjees Vortragsfolien nennen weitere Fälle, die andere Kontrollen betreffen. Für Telegram zeigte BGPHorizon am 16. Juni 2026 91.108.4.0/22 mit AS18101 statt des autorisierten AS62041 als Ursprung: eine Erkennung um 07:17:27 UTC bei vier Peer-Netzen über fünf Kollektoren und später weitere spezifischere Ankündigungen. Das belegt einen sichtbaren Ursprungskonflikt, aber keine universelle Verkehrsbeeinträchtigung und kein Motiv. Beim massenhaften Vodafone-Idea-Ereignis von 2021 wäre eine Präfix-Obergrenze auf einer Sitzung eine andere Sicherung gewesen; sie entscheidet nicht über die Rechtmäßigkeit eines einzelnen /24.

Eine BMP-Sitzung ist kein Paketpfad

RFC 7854 lässt einen Router vor und nach der Import-Policy empfangene BGP-Informationen für konfigurierte Peers an eine BMP-Station senden. Der Vor-Policy-Strom kann eine später abgewiesene Route sichtbar lassen, sofern sie an diesem Router und auf einem überwachten Peer einging. Ein Router darf aber nur ausgewählte Peers beobachten; Zwischenstände können komprimiert werden, Quell-Zeitstempel fehlen und Kollektorverbindungen Lücken haben. Eine nur bei AS6762 eingegangene Route lässt sich aus dem BMP-Strom von AS37100 nicht herbeizaubern.

Der Weg eines Pakets erfordert zusätzliche Messung und nach Möglichkeit Aufzeichnungen des Nachbarn: dort empfangener Pfad, Auswahl, FIB und zeitlich eingegrenzter aktiver Test. Das Nokia-Projekt RAVEN beschreibt die Kombination von BMP, ROV und ASPA. Seine Dokumentation ist kein Nachweis einer Installation bei den beteiligten Betreibern. Die Folien kennzeichnen ihre Beispielausgabe selbst als illustrativ, nicht als Live-Demonstration oder Beweis einer Erkennung in Sekunden.

RFC 7454 empfiehlt je Peering eine angemessene maximale Präfixzahl mit Wachstumsspielraum. Sie ist ein Schutz gegen ungewöhnliche Mengen, nicht gegen einen einzelnen falschen Subpräfix. ASPA-Pfadprüfung behandelt Provider-Beziehungen in einem noch laufenden Standardisierungsprozess; eine rückwirkende Schutzwirkung für 2025 ist damit nicht nachgewiesen. Ursprungskontrolle, Mengenbegrenzung, Pfadprüfung und Beobachtung sind unterschiedliche Quittungen.

Quellen und Grenzen

Der Entwurf von Li et al., Abschnitt 4 und Anhang A enthält die entscheidenden Looking-Glass- und Traceroute-Daten. APNICs Sitzungsbericht dokumentiert den Vortrag, BGPHorizon den unabhängigen Telegram-Befund. Die technischen Grenzen ergeben sich aus RFC 6811, RFC 7854 und RFC 7454. Keine dieser Quellen liefert eine vollständige Schadensbilanz, Absichtsnachweise, eine aktuelle universelle Einsatzquote oder gemessene Schutzleistung von RAVEN.