Zusammenfassung

  • draft-geng-grow-bmp-monitor-options-00 schlägt Enable- und Disable-Erklärungen für BMP-RIB-Sichten und Statistiken vor. Revision 00 ist ein individueller Arbeitsentwurf; der Nachrichtentyp TBD2 ist noch nicht zugeteilt.
  • Bei einem RIB-Disable muss der Collector die gespeicherte Sicht für <Peer, AFI, SAFI> sofort leeren. Gegenseitige Authentisierung schützt den Transport, ersetzt aber weder Betreiberfreigabe und Bereichsprüfung noch einen Löschbeleg und den Nachweis eines vollständigen Wiederaufbaus.

Seit einer Stunde trifft keine Route ein. Vielleicht hat sich die Tabelle nicht verändert. Vielleicht wurde die Überwachung einer Adressfamilie administrativ abgeschaltet. Die BMP-Sitzung kann in beiden Fällen intakt erscheinen, während eine alte Sicht weiterhin als Gegenwart gelesen wird.

Der Entwurf BMP Extension for Monitoring Options (MO) Notification vom 30. September 2026 will diesen Unterschied auf dem Draht ausdrücken. Es ist ein individueller Internet-Draft mit beabsichtigtem Standards-Track-Status und Ablaufdatum 3. April 2027. Er ist weder RFC noch Arbeitsgruppenkonsens oder Implementierungsnachweis. TBD2 ist ein Platzhalter für eine beantragte IANA-Zuteilung.

Schweigen braucht einen erklärten Zustand

RFC 7854 liefert strukturierte BGP-Beobachtungen zu Peers, Routen und Statistiken. RFC 8671 erweiterte BMP um Adj-RIB-Out, RFC 9069 um die Local RIB. Eine Konfigurationsänderung der Überwachung kann der Sender bislang jedoch nicht innerhalb der Sitzung mitteilen.

MO soll diese Lücke schließen. Das RIB-PDU benennt Adj-RIB-In, Adj-RIB-Out oder Loc-RIB, unterscheidet Pre-Policy und Post-Policy, führt ein Enable/Disable-Flag und listet AFI/SAFI-Paare auf. Nach dem Common Header kann ein Per-Peer Header stehen. Für Statistiken gibt es ein eigenes Format.

Diese Felder bilden gemeinsam den Wirkungsbereich. Der Satz „BMP deaktiviert“ reicht als Beleg nicht aus. Er lässt Sender, Peer, RIB-Oberfläche, Policy-Stufe, AFI, SAFI und Zeitpunkt offen.

Aus Metadaten wird eine Datenbankmutation

Wird die Überwachung einer Familie abgeschaltet, muss der Sender laut Entwurf sofort ein MO Disable senden. Der Collector muss daraufhin sämtliche gespeicherten RIB-Einträge der betroffenen <Peer, AFI, SAFI>-Sicht sofort entfernen.

Das verhindert, dass unbeobachtete Routen weiterhin als aktuell gelten. Zugleich ist die Nachricht damit ein destruktiver Verwaltungsbefehl. Topologiekarten, Leak-Erkennung, Policy-Prüfungen und Forensik können von einer richtigen Löschung profitieren oder durch eine falsche Löschung erblinden. Eine grüne Sitzungsanzeige unterscheidet beides nicht.

Der Sicherheitsabschnitt nennt den Angriff ausdrücklich: Unbefugte MO-Nachrichten könnten mit falschen Disable-Optionen einen Collector zur Löschung seiner gesamten überwachten Datenbank verleiten. Deshalb verlangt der Entwurf gegenseitige Authentisierung und geschützten Transport, etwa TLS.

TLS belegt die Identität des Sitzungsgegenübers und die Integrität des Kanals. Es belegt nicht, wer die Änderung genehmigt hat, ob AFI/SAFI richtig gewählt wurden oder ob ein authentisierter Router kompromittiert ist. Die Identität des Boten ist nicht gleichbedeutend mit der Berechtigung jeder von ihm benannten Löschung.

Aktuelle Hygiene und historische Verwahrung trennen

„Sofort löschen“ beschreibt das Verhalten der gespeicherten Live-RIB. Revision 00 formuliert keine vollständige Archivordnung und verbietet kein getrenntes, unveränderliches Verlaufsprotokoll.

Ein Betreiber kann die nicht mehr beobachtete Sicht daher sofort aus dem aktuellen Bestand entfernen und zugleich einen Vorher-Hash, eine historische Kopie oder einen unveränderlichen Änderungsbeleg aufbewahren. Historie darf nicht heimlich als Live-Zustand weitergereicht werden. Umgekehrt ist ein Logeintrag „erfolgreich“ wertlos, wenn er weder Sicht noch Anzahl der betroffenen Einträge nennt.

Ein belastbarer Beleg verbindet die genehmigte Änderung mit der authentisierten Sitzung und dem exakten Drahtbereich. Er hält Gelöschtes, bewusst Erhaltenes und das Transaktionsergebnis fest. Vor der Mutation muss der Collector fehlerhafte oder über die Rolle des Senders hinausgehende Befehle zurückweisen können.

Enable beginnt den Wiederaufbau

Bei erneuter Aktivierung sieht der Entwurf eine Enable-Nachricht und danach neue Route-Monitoring-Nachrichten vor. Der Collector baut daraus die Sicht wieder auf.

Nicht definiert sind jedoch Startmarke, erwartete Routenzahl, Endmarke oder eine Regel für Vollständigkeit. Die erste neue Route beweist nur, dass die Aufnahme wieder läuft. Sie beweist weder eine vollständige Tabelle noch eine lückenlose Übertragung seit der Löschung.

Deshalb braucht die lokale Zustandsmaschine mehr als enabled und disabled: Eine rebuilding-Phase verhindert, dass nachgelagerte Systeme eine teilweise frische Tabelle für vollständig halten. Erst ein erklärter Vollständigkeitsbeleg darf sie wieder auf current setzen.

Der getrennte Entwurf draft-geng-grow-bmp-rr-sync-00 schlägt für eine gezielte BMP-Resynchronisierung BoRR- und EoRR-Markierungen vor. Damit behandelt er genau die Begrenzung einer Wiederaufbau-Epoche als eigenes Problem. Er gehört nicht zu MO, ist ebenfalls Revision 00 und keine verfügbare Standardfunktion.

Löschbefugnis braucht eine Belegkette

Die Kette umfasst: genaue Spezifikations- und Implementierungsversion; gegenseitig authentisierte Endpunkte; genehmigte Betreiberänderung; Peer, RIB-Typ, Policy-Untertyp und AFI/SAFI; Befugnis des Senders für diesen Bereich; gelöschte und erhaltene Zeilen; historische Verwahrung; passendes Enable; Wiederaufbau-Epoche und Vollständigkeitskriterium; erst danach erneute Nutzung durch abhängige Systeme.

Kein Glied beweist das nächste. Ein Zertifikat validiert nicht den Bereich. Ein formal korrektes Disable belegt keine Genehmigung. Erfolgreiches Löschen garantiert keine historische Spur. Enable bedeutet nicht vollständig.

Lu Hengs Lehre trennt die Ebenen sinnvoll. Die minimale gemeinsame Spezifikation kann deterministische Felder und Übergänge für Interoperabilität definieren. Aufbewahrung, Freigabe, Wirkungsradius und Vertrauensschwelle bleiben lokale Entscheidungen der Risikoträger. Wirkliche Annahme zeigt sich in laufendem Code und seinen Belegen, nicht in der Veröffentlichung eines Entwurfs.

Sobald Telemetrie das Beobachtete löschen kann, ist sie Teil der Steuerung des Beweissystems.

Quellen