Zusammenfassung

  • Der Last Call vom 17. September betrifft Version 21 eines für einen Informational RFC vorgesehenen SAVNET-Problemberichts; sachliche Kommentare sind bis 1. Oktober möglich.
  • An Kunden-, Peer- und Provider-Schnittstellen unterscheiden sich die Risiken unberechtigter Sperrung und unberechtigter Zulassung.
  • Die Zustimmung der Arbeitsgruppe ersetzt weder die IESG-Entscheidung noch einen späteren Mechanismus, eine lokale Betriebsfreigabe oder Verkehrsdaten.

Das Grenzinterface eines Netzes kennt nicht die gesamte Geschichte eines Quellpräfixes. Ein mehrfach angebundener Kunde kann eine Route nur begrenzt weitergeben und dennoch legitimen Verkehr über eine andere Verbindung senden. Bei Direct Server Return kann ein Edge-Server eine Anycast-Adresse als Antwortquelle verwenden, obwohl sein AS dieses Präfix dort nicht ankündigt. Das SAVNET-Dokument -21 zeigt an solchen konstruierten Topologien, warum eine strikt aus der Routingansicht berechnete Zulassung legitime Pakete verwerfen kann. Die Skizzen sind keine Berichte über reale Ausfälle.

Lockerung allein verschiebt den Fehler. Solange die Quellprüfung im Kundenkegel nur teilweise umgesetzt ist, kann ein Teilnehmer die Adresse eines anderen fälschen; ein entfernter Router sieht möglicherweise nur ein zugelassenes Präfix. An Peer-Schnittstellen erschwert asymmetrisches Routing den Schluss aus dem Rückweg. Auf Provider-Seite kann Loose uRPF ein gefälschtes Paket durchlassen, weil die Quellroute in der FIB vorhanden ist. Manuell gepflegte ACLs bieten andere Kontrollmöglichkeiten, müssen aber Änderungen in Präfixen und Geschäftsbeziehungen zeitnah nachführen.

Jede Schnittstelle verlangt eine eigene Begründung für Blockieren und Zulassen.

Die IESG-Mitteilung vom 17. September erbittet endgültige Einwände zu Problembeschreibung, Lückenanalyse und Anforderungen für eine informative Veröffentlichung. Im Datatracker steht weiterhin „Publication Requested“ für einen aktiven Internet-Draft. Anforderungen für künftige Verfahren betreffen Genauigkeit, Betriebsaufwand, Nutzen bei teilweiser Einführung, Schutz SAV-spezifischer Informationen und Konvergenz nach Änderungen. Das ist weder ein beschlossener BGP-Zusatz noch die Anweisung, einen Filter zu aktivieren.

Der Shepherd-Bericht beschreibt zwei Last Calls innerhalb der Arbeitsgruppe und breite Zustimmung; zugleich verneint er ausdrücklich, dass hier ein Protokoll oder neue RPKI-Objekte spezifiziert würden. Eine frühe Routing-Review von Version 20 fragte nach der Verbindlichkeit des Ziels „null unberechtigte Sperren“ und dem Vertrauensmodell verschiedener Informationsquellen. Dieser Befund bezieht sich auf die ältere Fassung, nicht auf ein endgültiges Urteil über -21. Gerade deshalb lohnt die genaue Prüfung, welche Aussage die IESG nun tatsächlich übernehmen soll.

Quellen