Summary

  • RFC 1108 machte Typ 133 zu einem mehrfach verwendbaren Container für zusätzliche Sicherheitslabels; jeder Formatcode brauchte eigene interoperable Regeln.
  • ESO durfte nur zusammen mit der Basic Security Option auftreten; Entfernen konnte zur Ablehnung oder zu einer falschen Sensitivitätszuordnung führen.

Erweiterung durch geregelte Delegation

Die Extended Security Option (ESO), IPv4-Option des Typs 133, hatte eine variable Länge von mindestens drei Oktetten und einen einoktettigen Additional Security Info Format Code. Das anschließende Feld folgte der vom Code bezeichneten Syntax und durfte je nach Definition sogar leer sein.

Für jeden registrierten Code sollte eine RFC erscheinen. Sie musste Syntax und algorithmische Annahme- oder Ablehnungsregeln so genau beschreiben, dass Hersteller interoperable Systeme bauen konnten. Nur die Zuordnung zu menschlichen Bezeichnungen durfte fehlen, wenn ihre Veröffentlichung eingeschränkt war.

ESO wurde in Fragmente kopiert und durfte mehrmals vorkommen, solange der IPv4-Header Platz bot. Dennoch blieb sie abhängig: Jedes Paket mit ESO brauchte auch die Basic Security Option (BSO). Fehlende BSO, ein nicht registrierter Code, widersprüchliche Längen oder formatwidrige Daten waren Fehler, für die RFC 1108 die Verarbeitung als ICMP Parameter Problem vorsah.

Unterstützung war selektiv. Ein System konnte nur BSO oder nur bestimmte ESO-Codes verstehen. Die Protection-Authority-Bits der BSO hatten keine Beziehung zu den ESO-Formatnummern. Gemeinsame Sicherheitsverarbeitung bedeutete nicht gemeinsames Zahlenregister.

Auch der Weg musste vorbereitet sein. Labelabhängige Routenwahl war erst möglich, wenn Routingprotokolle die entsprechenden Informationen verteilten. Header, Portparameter, unterstützte Formate und Routingzustand bildeten zusammen den Mechanismus.

Warum Entfernen die Bedeutung veränderte

RFC 7126 hielt begrenzte Nutzung in privaten Hochsicherheitsnetzen fest. Wurde ESO entfernt, konnte der Empfänger das nun unzureichend markierte Paket verwerfen oder den Daten eine falsche Sensitivität zuordnen. Sowohl Hoch- als auch Herabstufung waren problematisch.

Da ein Gerät seinen späteren Einsatzbereich nicht vorab kennt, sollte die Standardkonfiguration ESO nicht verändern und Pakete nicht allein deshalb verwerfen. In einem nachweislich unbeteiligten Netz durfte der Betreiber filtern; Zähler und Protokollierung sollten die Entscheidung überprüfbar machen.

Heutige Verbreitung, aktive Formatcodes und universelle Herstellerregeln bleiben in den Quellen unbelegt. Belegt ist die Architektur: Erweiterbarkeit verteilt Abhängigkeiten auf Registry, Spezifikation und Betrieb.

Sources