Zusammenfassung

  • RFC 9868 verwendet den IP-Transportbereich hinter UDP Length als surplus area für UDP-Transportoptionen; dieser Teil ist von UDP-Nutzdaten getrennt.
  • DTLS schützt Nutzdaten und nicht Transportoptionen. Eine geschützte Nutzlast, ein OCS-Ergebnis oder eine ausgesendete Option ersetzen keinen Nachweis über Schutz, Verarbeitung oder Folge.

Die entscheidende Grenze liegt nicht in der Zeichnung des Pakets, sondern im Geltungsbereich einer Behauptung. RFC 9868 nutzt die mögliche Differenz zwischen UDP Length und dem von IP verfügbaren Transportbereich. Vor der UDP-Grenze liegen Nutzdaten; danach können optionbewusste Implementierungen eine Optionsfläche auswerten. Das erweitert UDP als Transportmechanismus, nicht als Zusage über einen entfernten Endpunkt, einen Pfad oder einen Anwendungserfolg.

Auch mit Optionsfläche bleibt UDP zustandslos und unidirektional. Die Optionen bilden ein Rahmenwerk, kein vollständiges Protokoll. Abgesehen von den für unterstützende Implementierungen vorgesehenen Pflichtoptionen kann der Sender beim Empfänger keine Bearbeitung erzwingen. Optionale Felder dürfen nach lokaler Konfiguration ignoriert werden. Ein Senderprotokoll belegt somit nur, dass ein lokaler Prozess etwas angefügt hat.

Für Schutz gilt dieselbe Enge. RFC 9868 stellt fest, dass TLS und DTLS nicht die Transportschicht schützen; DTLS arbeitet über UDP-Nutzdaten. Der Optionsmechanismus gibt auch keinen besonderen Manipulationsschutz für UDP-Header, Nutzdaten oder surplus area, sofern nicht OCS, AUTH, UENC oder eine andere Schicht wie IPsec ihn bereitstellt. Ohne passende Verschlüsselung bleiben Optionen im Netzpfad sichtbar. Ein DTLS-geschützter Datenstrom ist kein Nachweis für Geheimhaltung oder Unverändertheit einer danebenliegenden Option.

OCS erkennt Fehler in der Optionsfläche. Es ist keine Autorisierung, keine Pfadbestätigung und kein Entscheider. Um Altverhalten beizubehalten, kann ein Empfänger Nutzdaten ausliefern und andere Optionen ignorieren, wenn ein einschlägiger OCS fehlschlägt. Der prüfbare Befund lautet dann: Diese Implementierung hat unter dieser lokalen Regel so reagiert. Er lautet nicht: Die Option sei sicher oder erfolgreich gewesen.

RFC 9869 zeigt die fehlenden Schritte zum Messbefund: DPLPMTUD mit UDP Options verlangt Aktivierung auf beiden Seiten und eine ausdrückliche Antwort auf die Sonde. Die Formatdefinition allein misst keinen Pfad. RFC 9868 weist zusätzlich darauf hin, dass Pfade die surplus area entfernen oder Optionsdatagramme verwerfen können. Konstruktion, gewählter Schutz, Empfängerfähigkeit, korrelierte Antwort, Pfadbeobachtung und Anwendungsergebnis müssen getrennt erhalten bleiben.

Damit bleibt RFC 9868 im Sinn von Heng Lu ein gemeinsames, prüfbares Artefakt. Ob eine Option aktiviert wird, welche Absicherung verlangt wird und was eine Automatisierung später daraus folgern darf, sind lokale Entscheidungen. Die Grenze verhindert, dass eine nützliche Option als Stellvertreter für eine nie belegte Entscheidung oder Wirkung dient.

Sources