Zusammenfassung

  • Fassung 03 des GROW-Arbeitsgruppenentwurfs Current Options for Securing Global Routing vom 2. Oktober enthält neu den Abschnitt „Impact of the Configuration Paradigm“. Er trennt atomar bestätigte Transaktionen von Systemen, die jeden Befehl sofort ausführen. Der Text ist weiterhin ein Internet-Draft, kein verabschiedeter RFC.
  • Im Beispiel wird action permit aktiv, bevor set large-community add 65536:0:0 folgt. Steht die neue Erlaubnis vor einer Regel, die vom Upstream gelernte Routen zurückweist, können solche Routen zwischenzeitlich an Peers gelangen. Der Entwurf beschreibt einen möglichen Fehlerpfad, keinen belegten Vorfall.

Ein Änderungsprotokoll enthält gewöhnlich den genehmigten Zielzustand. Es zeigt seltener, welche wirksamen Zustände der Router bis dahin durchlaufen hat. Genau diese Lücke benennt draft-ietf-grow-routing-ops-sec-inform-03. Im Datatracker steht das Dokument als aktiver Entwurf der GROW-Arbeitsgruppe mit IESG-Status I-D Exists; vorgesehen ist ein informatorischer Text. Der Entwurf selbst versteht sich als unvollständige Sammlung von Schutzoptionen für das globale Routing, ohne einzelne Techniken abschließend zu bewerten oder eine bestimmte Implementierung vorzuschreiben.

Der neue Abschnitt stellt zwei Bedienmodelle gegenüber. In einer transaktionalen Oberfläche werden Befehle vorbereitet und als Einheit übernommen. Bei unmittelbarer Ausführung kann jeder Schritt bereits Produktionsverhalten auslösen. Die Beispielsequenz setzt in einer Route-Map zuerst action permit und ergänzt später eine Large Community mit dem Wert 65536:0:0. Befindet sich diese Erlaubnis vor einer Ablehnungsregel für upstream-gelernte Routen, können die Routen während des ersten Schritts an Peers exportiert werden. Die Zahl der Community ist Bestandteil des Beispiels und für sich weder Berechtigungsnachweis noch Nachweis einer wirksamen Exportbegrenzung.

Worin liegt die Änderung gegenüber Fassung 02? Dort warnte bereits ein Abschnitt zur Konsistenz von Präfixfiltern vor nicht atomaren Aktualisierungen: Unerwünschte Präfixe könnten kurzzeitig passieren, und ein abgebrochener Eingriff könne eine inkonsistente Policy hinterlassen. Fassung 03 erfindet dieses Risiko nicht, sondern macht das Konfigurationsmodell zum eigenen Thema und zeigt die Reihenfolgegefahr anhand einer Route-Map. Aus dem Text folgt kein produktübergreifender Befehlssatz für die Umstellung.

Auch RFC 8212 setzt eine engere Grenze, als das Schlagwort „Default Deny“ vermuten lässt. Für EBGP fordert er explizite Import- und Export-Policies sowie Ablehnung, wenn eine solche Policy fehlt. Gleichzeitig weist er darauf hin, dass eine fehlerhafte explizite Konfiguration dadurch nicht verhindert wird. Ein voreilig wirksames permit ist eben eine explizite Konfiguration. Dass im endgültigen Dokument eine Ablehnung steht, beweist daher nicht, dass ein Peer während der Bearbeitung nie eine unzulässige UPDATE-Nachricht sah.

Für die Abnahme sind drei Belege auseinanderzuhalten: Der Router hat einen Befehl angenommen; die vollständige beabsichtigte Policy ist an der richtigen Stelle aktiv; der Peer hat nur zulässige Routen erhalten. Ein Endzustands-Diff erfasst vor allem den zweiten Punkt. Eine vollständig vorbereitete Ersatzpolicy mit anschließender Referenzumschaltung kann auf geeigneten Plattformen helfen. Aber auch die Umschaltung muss auf ihre tatsächliche Atomizität geprüft werden; ein einzelner Befehl garantiert sie nicht. Das sind aus dem Fehlerbild abgeleitete Betriebsvorschläge, keine neuen IETF-Messpflichten.

Die geprüften Quellen nennen weder ein betroffenes Netz noch einen Produktfehler oder eine gemessene Verbreitung. Ihr belastbarer Beitrag ist eine präzisere Frage an die Freigabe: Welche Zwischenstände der Exportpolicy waren erreichbar, und konnte in einem davon eine Route das Netz verlassen?

Quellen