Zusammenfassung

  • Eine BGP-Policy kann vor und nach einer Änderung korrekt sein und währenddessen dennoch Schutz verlieren. Auf Systemen mit sofortiger Befehlsausführung wird eine Erlaubnis womöglich aktiv, bevor ihre Bedingungen existieren; eine gelöschte Regel kann bei einem Abbruch dauerhaft fehlen.
  • Revision 03 verbindet dieses Übergangsrisiko mit Regelreihenfolge, Rechenaufwand, atomarem Austausch, Idempotenz und Fehlern der Filtererzeugung. Entscheidend sind der wirksame Zustand und die beobachtete Routendifferenz, nicht nur eine erfolgreiche Commit-Antwort.

Im Change-Request stand lediglich: zwei Prüfungen vertauschen. Für einen Router ohne atomare Konfigurationsänderungen konnte derselbe Wunsch bedeuten, eine Regel zu löschen, eine zweite neu einzufügen, deren alte Instanz zu entfernen und anschließend die erste wieder anzulegen. Nach dem ersten Löschen existierte ein Zustand, den niemand freigegeben hatte.

Der fertige Konfigurationsauszug verriet davon nichts.

Genau diese Lücke untersucht Revision 03 von Current Options for Securing Global Routing. Der am 2. Oktober 2026 veröffentlichte Text ist ein aktiver Internet-Draft der GROW Working Group im IETF-Stream, mit beabsichtigtem Status Informational und Ablaufdatum 5. April 2027. Er ist weder RFC noch endgültiger IETF-Konsens, Best Current Practice, Produktzertifizierung oder Nachweis eines Vorfalls bei einem benannten Netz. Der Entwurf bezeichnet sich selbst als zeitgenössische, nicht vollständige und nicht autoritative Sammlung von Optionen.

Seine stärkste Aussage bleibt dennoch belastbar: Sicherheit ist eine Eigenschaft des Übergangs, nicht nur des Zielbilds.

Wenn ein halbfertiger Eintrag bereits entscheidet

Manche Plattformen erlauben es, mehrere Änderungen in einem Candidate-Datastore vorzubereiten, zu prüfen und gemeinsam zu übernehmen. Andere machen jeden einzelnen Befehl sofort wirksam. Beide können am Ende dieselbe gewünschte Policy zeigen und zwischendurch völlig unterschiedliche Entscheidungen treffen.

Der Entwurf demonstriert das an einer Route-Map. Zuerst wird eine neue Regel erstellt, danach action permit gesetzt und erst anschließend eine Large Community als Bedingung ergänzt. Bei sofortiger Ausführung gilt die Erlaubnis bereits nach dem zweiten Schritt. Steht sie vor der Regel, die von Upstreams gelernte Routen abweist, kann der unvollständige Eintrag alles akzeptieren und Upstream-Routen an Peers weitergeben.

Das ist nicht bloß ungeschickte Befehlsreihenfolge. Die Bedienoberfläche macht einen Zwischenstand zur produktiven Autorität. Die Prüfung vor dem Change bewertet die Absicht. Der Snapshot danach bewertet den konvergierten Zustand. Dazwischen entschied jedoch eine dritte Policy über reale Routen.

Die Desired Policy gehört zum Kontrollsystem. Die Effective Policy gehört zum Router und bestimmt, was er in diesem Augenblick annimmt oder exportiert. Bei einer Änderung im laufenden Objekt können beide auseinanderfallen. Autorität besitzt dann nicht das sorgfältig geprüfte Dokument, sondern der tatsächlich ausgewertete Zustand.

Eine Umordnung besteht aus mehreren Ereignissen

Das ausführlichere Beispiel beginnt mit einer Export-Policy, die Upstream-Präfixe, Bogons und RPKI-invalides NLRI zurückweist und den Rest akzeptiert. Geändert werden soll nur die Reihenfolge der Bogon- und RPKI-Prüfung.

Ohne atomare Anwendung kann daraus eine vierteilige Sequenz werden: alte Bogon-Regel löschen, RPKI-Regel an der freien Position hinzufügen, alte RPKI-Regel löschen, Bogon-Regel an der neuen Position anlegen. Zwischen dem ersten und zweiten Schritt kann eine Bogon-Route passieren. Bricht der Vorgang nach dem Löschen ab, ist die Lücke kein kurzes Fenster mehr, sondern die laufende Konfiguration.

Die Behauptung, dieses Fenster sei vernachlässigbar, ist kein Beleg. Ein belasteter oder knapp dimensionierter Control Plane kann die Wirkung einzelner Befehle verzögern. Ein Timeout beim Management-Client sagt nicht, dass der Router zurückgerollt hat. Ein Retry kann auf einen bereits teilweise veränderten Zustand treffen.

Als Gegenmaßnahme beschreibt der Entwurf, einen neuen Regelsatz vollständig unter einem separaten Objekt aufzubauen, die Referenz des Nachbarn darauf umzuschalten und das alte Objekt erst nach der Verifikation zu löschen. Dadurch schrumpft die kritische Aktion von vielen In-place-Edits auf einen Referenzwechsel.

Ob dieser Wechsel selbst atomar ist, muss jedoch für die Plattform nachgewiesen werden. Candidate- und Running-Datastores samt Commit in NETCONF illustrieren ein Transaktionsmodell; sie beweisen keine gleichzeitige Wirkung aller Routingentscheidungen jedes Produkts. Die Trennung von Intended und Operational State im NMDA unterstreicht deshalb die richtige Frage: Was war tatsächlich aktiv, und wann?

Reihenfolge bestimmt auch die Sicherheitsreserve

Prädikate können dieselbe Endentscheidung mit sehr unterschiedlichem Aufwand erreichen. Revision 03 beschreibt einen hypothetischen Peer mit einer Million IPv4-NLRI, von denen nur 60 zum erlaubten Cone gehören.

In einer schlechten Reihenfolge fügt die Policy zunächst zwei Communities hinzu, prüft private AS-Nummern, Bogons und RPKI-Invalidität und verwirft erst danach die Routen außerhalb des Cones. Das Beispiel kommt auf 5.986.500 Operationen. Wird die hochselektive Cone-Prüfung zuerst ausgeführt, sinkt die Zahl auf 1.000.300.

Das sind illustrative Werte des Entwurfs und keine Benchmarks eines benannten Routers. Reale Kosten hängen von der Implementierung ab. Auch der Hinweis, skalare Operationen vor Baum- und Listensuchen sowie regulären Ausdrücken zu erwägen, ist keine universelle Leistungsgarantie.

Die Verbindung zur Übergangssicherheit ist trotzdem direkt. Arbeit an Routen, die eine billige frühe Prüfung verwerfen könnte, beansprucht denselben Control Plane, der die Änderung abschließen muss. Mehrere Nachbarn vervielfachen die Last. Je länger die Befehle bis zur Wirksamkeit brauchen, desto länger kann ein gefährlicher Zwischenzustand bestehen. Regelreihenfolge betrifft Semantik, Kapazität und Risikodauer zugleich.

Idempotent ist nicht atomar

Präfixfilter auf dedizierten Systemen zu erzeugen und nur bei tatsächlicher Änderung zu verteilen, ist sinnvoll. Unveränderte Eingaben verursachen dann nicht wiederholt Arbeit auf Routern.

Doch Idempotenz verspricht nur, dass Wiederholungen denselben Endzustand erreichen. Sie verspricht nicht, dass die erste Ausführung keine Zwischenzustände offenlegt. Ein Deployment kann vollkommen idempotent sein und bei jeder echten Änderung dieselbe gefährliche Sequenz durchlaufen. Ebenso wenig prüft Idempotenz den Inhalt: Eine unveränderte falsche Policy lässt sich sehr effizient überspringen.

Darum braucht die Beweiskette getrennte Nachweise: Eingangsdaten des Generators, gewünschte Policy, erzeugte Gerätekonfiguration, vorheriger Effective State, Staging-Prüfung, Aktivierungsantwort, nachheriger Effective State und beobachtetes Route Delta. Eigene Digests und Zeitstempel zeigen, welcher Grenzübergang wirklich geprüft wurde. Der Sammelstatus „deployed“ tut das nicht.

Der Fehlerfall des Generators ist Routingpolitik

Auch der Generator kann scheitern. Revision 03 empfiehlt, unerwartete Ausgaben zu erkennen: einen Regelsatz, der plötzlich stark wächst, schrumpft oder leer wird. Welche Reaktion richtig ist, lässt der Text bewusst beim Betreiber.

Accept-all bewahrt Erreichbarkeit, indem es Sicherheit ausgibt. Reject-all schützt die Grenze, kann jedoch Verkehr zu Upstreams verschieben und größeren Schaden erzeugen. Die alte Policy weiterzuverwenden stabilisiert den Betrieb, wird aber zunehmend falsch und kann neue Präfixe irrtümlich annehmen oder ablehnen. Keine Variante ist ein neutraler Software-Default.

Die Wahl sollte vorab nach Nachbarklasse getroffen werden. Kunde, Peer, Upstream und Route Server haben andere Konsequenzen. Zulässiges Alter, Verkehrsfolgen, Eskalationsverantwortung und die Belege für eine Rückkehr zur generierten Policy gehören in die Entscheidung.

Default Reject nach RFC 8212 bleibt eine wichtige Untergrenze für eBGP-Sitzungen ohne Policy. Daraus folgt jedoch nicht, dass der Wechsel zwischen zwei vorhandenen Policies sicher ist. RPKI Origin Validation, BGP Roles und OTC liefern wertvolle Prädikate; sie machen den Installationsvorgang nicht atomar.