Zusammenfassung

  • In draft-ietf-ippm-stamp-ext-hdr-14 verpflichtet der neue Abschnitt 3.3 die Datenebene am Ausgangsknoten, empfangene IP- und IPv6-Erweiterungsheader an den lokalen Session-Reflector zu liefern. Bei einer Zweiwegmessung muss die Datenebene am Eingangsknoten auch die Header der Antwort an den Session-Sender liefern.
  • Der Text ist weiterhin ein Internet-Draft, kein RFC und kein Einsatznachweis. Längen- und Präfixabgleich sowie das C-Bit bei nicht nutzbarem TLV waren im Wesentlichen schon in Fassung 13 vorhanden. Neu ist die explizite Zuständigkeit für die Übergabe innerhalb des Knotens.

Die Schwachstelle liegt möglicherweise nicht auf der Leitung, sondern zwischen zwei Funktionen derselben Maschine. Die Weiterleitung hat ein Testpaket angenommen; der STAMP-Reflektor bekommt dessen Erweiterungsheader jedoch nicht. Dann kann er nichts zuverlässig zurückspiegeln, obwohl ein Eingangs-Zähler korrekt gestiegen ist. Eine Messung muss deshalb zwischen Paketempfang und Verfügbarkeit des Headers für die Messfunktion unterscheiden.

Die Version vom 18. September zieht genau diese Grenze. Ihr neuer Abschnitt 3.3 verlangt, dass die Datenebene des Ausgangsknotens dem dort betriebenen Reflektor die empfangenen IP- und IPv6-Erweiterungsheader aus dem Testpaket des Senders bereitstellt. Für Zweiwegmessungen gilt spiegelbildlich: Am Eingangsknoten muss die Datenebene die empfangenen Header der Reflektorantwort dem Sender übergeben. Ein eingetroffenes Antwortpaket beweist also nicht schon, dass die Messfunktion die Header des Rückwegs auswerten konnte. Aus der Normsprache eines Entwurfs folgt allerdings kein Befund über vorhandene Router oder Implementierungen.

Wie ein bestimmter Header ausgewählt wird, regeln die TLVs. Bei einem nichtnulligen Suchwert müssen Länge und erste acht Oktette eines IPv6-Erweiterungsheaders beziehungsweise die ersten vier eines festen IP-Headers übereinstimmen. Null wählt den ersten Header passender Länge. Fehlt eine Übereinstimmung, geht das TLV mit gesetztem Konformitätsbit C zurück. Die Fassung 14 ordnet diese Fälle in den Verfahrensabschnitten und präzisiert ihre Formulierung.

Fassung 13 enthielt die Grundregeln bereits in den Feldbeschreibungen, einschließlich eines C-Bits, wenn ein erkanntes TLV nicht zur Spiegelung verwendet werden konnte; fehlender Zugriff auf die empfangenen Header war dort ausdrücklich ein Beispiel. Der neue Abschnitt über die Datenebene ist daher die Nachricht, nicht ein vermeintlich neu erfundenes Fehlersignal.

Ein reflektierter Wert ist an diese Auswahl und die tatsächlich bereitgestellten Eingangsdaten gebunden. Er listet nicht sämtliche Header des Pfads auf und belegt nicht, dass IOAM-Informationen an jedem Zwischenpunkt vollständig geblieben sind. Umgekehrt nennt C=1 keine eindeutige Ursache für den Ausfall: Suchwert, lokale Übergabe oder andere Grenzen müssen anhand zusätzlicher Evidenz getrennt werden. Die ältere BTW-Analyse zum C-Bit befasste sich mit MTU-, Raten- und Mengengrenzen; hier geht es um die neue Pflicht an einer Komponenten-Schnittstelle.

Bei der Pfad-MTU nennt der Entwurf nun ausdrücklich das vollständige resultierende Paket einschließlich IP, UDP, STAMP und TLVs. Schon der Vorgänger begrenzte die Paketgröße, sodass dies eine genauere Bilanz und keine erstmalige Schutzmaßnahme ist. Der IETF-Datatracker führt Version 14 als aktiv, in AD Evaluation und beim IESG eingereicht. Weder ein endgültiger Standard noch Verbreitung im Betrieb sind damit nachgewiesen.

Quellen