Zusammenfassung

  • Der CIPSO-Entwurf von 1992 setzte eine 32-Bit-Domain-of-Interpretation vor die Sicherheitstags, weil numerische Stufen und Kategorien nur unter Systemen mit derselben Zuordnungstabelle verständlich waren.
  • Hosts und Ports setzten konfigurierte Wertebereiche durch; an Domänengrenzen mussten Gateways die Option übersetzen. Eine syntaktisch gültige Zahl besaß keine universelle Autorität.

Ein kompaktes Etikett braucht ein lokales Wörterbuch

Die Commercial IP Security Option war für kommerzielle Systeme mit verbindlicher Zugriffskontrolle und mehreren Sicherheitsstufen gedacht. Damit unterschied der Entwurf sie von den auf das US-Verteidigungsumfeld zugeschnittenen Optionen BSO und ESO. CIPSO erhielt im IPv4-Header den Typ 134. Die Option hatte variable Länge, wurde in Fragmente kopiert und durfte in einem Datagramm höchstens einmal vorkommen.

Auf je ein Oktett für Typ und Gesamtlänge folgte eine vorzeichenlose 32-Bit-Domain-of-Interpretation, kurz DOI, danach eine Folge von Tags. Der DOI-Wert null blieb reserviert. Der DOI bezeichnete die Gemeinschaft, deren Tabelle kompakte numerische Stufen und Kategorien in jene Bezeichnungen übersetzte, die Menschen und Richtliniensysteme verstanden.

Diese Indirektion war keine Zierde. Der Entwurf führte vor, dass zwei unabhängige Gruppen „Unclassified“ mit 5 beziehungsweise 1 darstellen konnten. Erst der DOI verriet, welche Tabelle für die Zahl galt. Eine DOI-Autorität legte die Zuordnungen fest und verteilte sie innerhalb ihrer Domäne; weil selbst diese Tabelle sensibel sein konnte, musste sie außerhalb der Domäne nicht veröffentlicht werden.

Die Tags trugen die übrigen Angaben. Die Typen 0 bis 127 waren für standardisierte, zur Veröffentlichung als RFC vorgesehene Formate reserviert. Oberhalb von 127 durfte eine DOI-Autorität eigene Formate definieren, jedoch nur für geschlossene Netze ohne Anspruch auf externe Interoperabilität. Der Entwurf ordnete drei MAC-Sensitivity-Formate konkreten Nummern zu: Tag-Typ 1 nutzte eine Kategorien-Bitmap, Typ 2 eine aufsteigende Kategorienaufzählung und Typ 5 nicht überlappende aufsteigende Bereiche.

Eine konforme Implementierung musste den gewöhnlichen Tag-Typ 1 erzeugen und jeden gültigen Typ 1, einschließlich der optimierten Form, annehmen können.

Konfiguration machte aus Bedeutung eine Entscheidung

Korrekte Syntax war nur der Anfang. Ein Host, Gateway oder Router für mehrere Sicherheitsstufen benötigte konfigurierte Mindest- und Höchstwerte für System oder Schnittstelle. Ein Host verwarf Kennzeichnungen, zu deren Verarbeitung er nicht befugt war; ausgehende Pakete außerhalb des erlaubten Portbereichs wurden verworfen. Der DOI für den Ausgangsverkehr konnte nach Port, Zielnetz oder Zielhost gewählt werden.

Der Fehlerpfad unterschied Unverständliches von Verbotenem. Ein unbekanntes CIPSO-Feld führte zum Verwerfen und zu einer ICMP-Parameter-Problem-Antwort. War eine Kennzeichnung syntaktisch gültig, lag aber außerhalb des konfigurierten Bereichs, folgten Verwerfen und eine administrativ untersagte ICMP-Destination-Unreachable-Meldung. Ein Administrator konnte bestimmte unbekannte Tag-Typen ausdrücklich als gefahrlos ignorierbar konfigurieren; das blieb eine Ausnahme von der Standardreaktion.

Auch das Fehlen der Option war eine Richtlinienfrage. Ein empfangender Port durfte unmarkiertem Verkehr lokal eine Kennzeichnung zuweisen, etwa in einem einstufigen Netz oder einem gemischten Segment, dessen unmarkierte Hosts alle auf derselben Stufe arbeiteten. Wo CIPSO vorgeschrieben war, musste ein Paket ohne die Option verworfen und mit ICMP Parameter Problem wegen der fehlenden Option 134 beantwortet werden.

An der Grenze zweier DOIs wurde die institutionelle Abhängigkeit sichtbar. Ein System musste mindestens einen DOI unterstützen und sollte mehrere unterstützen. Leitete ein Gateway zwischen Netzen weiter, musste es CIPSO von einem DOI in den anderen übersetzen. Das Paket trug die kompakte Kennzeichnung; das Gateway trug die Verantwortung dafür, ihre Bedeutung über administrative Vokabulare hinweg zu bewahren.

Ein Entwurf, der kein RFC wurde

CIPSO 2.2 blieb ein abgelaufener Internet-Draft und wurde kein RFC. NIST standardisierte den Ansatz später als FIPS 188, veröffentlichte ihn 1994 und zog ihn 2015 zurück. RFC 7126 hielt 2014 fest, dass mehrere Betriebssysteme für mehrstufige Sicherheit CIPSO implementierten und die Option in einigen Hochsicherheitsnetzen vorkam. Das sind zeitgebundene Beobachtungen, kein Beleg für heutige Verbreitung.

RFC 7126 erklärte zudem das Risiko pauschalen Filterns. Das Entfernen von CIPSO konnte dazu führen, dass ein Empfänger ein Paket als falsch gekennzeichnet ablehnte – oder schlimmer, die Daten der falschen Sensitivität zuordnete. Die Standardempfehlung lautete deshalb, Pakete nicht allein wegen vorhandener CIPSO-Optionen zu entfernen oder zu verwerfen. Konfigurierbares Verwerfen nach bloßer Anwesenheit und Audit-Zähler je Schnittstelle blieben dennoch vorgesehen.

Die bleibende Einsicht steckt im DOI. Numerische Kennzeichnungen sparen Platz im Paket; gemeinsame Semantik schaffen sie nicht. Diese lag in der Zuordnung einer Autorität, in der Konfiguration jedes Systems und in der Übersetzung an der Grenze.

Quellen