Zusammenfassung

  • RFC 791 legte Typ 130 als elf Oktette lange, feste Option mit Sicherheitsstufe, Compartments, Handhabungsbeschränkungen und Transmission Control Code an; spätere RFCs behielten den Typwert, ersetzten aber das Format.
  • RFC 1108 machte Klassifikation und Protection Authorities zu Eingaben einer schnittstellenspezifischen MLS-Regel und ließ je nach Netz explizite oder implizite Markierungen zu.
  • Obwohl solche Pakete im öffentlichen Internet normalerweise nicht vorkommen sollten und RFC 1108 Historic wurde, warnte RFC 7126 vor pauschalem Entfernen: In geschlossenen MLS-Netzen konnte dadurch eine falsche Sensitivität entstehen.

Die leere Stelle übernimmt eine lokale Bedeutung

Der entscheidende Mechanismus steht in RFC 7126. Entfernt ein Zwischengerät die Basic Security Option, kann ein Empfänger das Paket wegen der fehlenden Pflichtmarkierung abweisen. Er kann es aber auch annehmen und ihm die an der Eingangsschnittstelle konfigurierte implizite Markierung geben.

Damit ist Löschen keine neutrale Reduktion. Eine zu hohe Einstufung blockiert legitime Nutzung und kann höher geschützte Systeme mit falsch eingeordneten Daten belasten. Eine zu niedrige Einstufung öffnet Informationen für einen Bereich, der sie nicht erhalten sollte. Die Firewall beseitigt keine Authentisierung; sie tauscht eine explizite Eingabe gegen eine unbekannte lokale Ersatzregel aus.

Die Option verschlüsselt nichts, beweist weder Absender noch Freigabe und stellt selbst keine Clearance aus. Sie ist ein Label, dessen Wirksamkeit von vertrauenswürdiger Zuweisung, geschützten Komponenten und korrekt konfigurierten Grenzen abhängt.

Elf Oktette sollten vier Kontrollachsen tragen

RFC 791 definierte Security als Optionstyp 130 mit fester Länge von elf Oktetten. Auf Typ und Länge folgten 16 Bit Security, 16 Bit Compartments, 16 Bit Handling Restrictions und 24 Bit Transmission Control Code.

Security wählte eine benannte Stufe. Compartments trennten kontrollierte Sachgebiete. Handling Restrictions standen für Kontroll- und Freigabemarkierungen. Der TCC bezeichnete kontrollierte Interessengemeinschaften. Das Feld war also mehr als eine lineare Skala: Mehrere Dimensionen eines externen Informationsregimes sollten im IP-Header mitreisen.

Das Copy-Bit war gesetzt. Bei Fragmentierung gehörte die Option in jedes Fragment, und sie durfte pro Datagramm höchstens einmal vorkommen. Das Zerlegen eines Pakets sollte seine Teile nicht von der Sicherheitskennzeichnung trennen.

RFC 791 unterschied außerdem zwischen dem optionalen Auftreten in einem einzelnen Datagramm und der Implementierung durch IP-Module. Manche Umgebungen könnten Security in jedem Datagramm verlangen. Ein globales Paketformat enthielt damit Unterstützung für eine Pflicht, die nur der lokale Sicherheitskontext auslöste.

Keines der Felder bot kryptografische Integrität. Eine kopierte Behauptung wird nicht wahr, weil alle Fragmente sie tragen. Erst vertrauenswürdige Quellen, Wege und Empfänger konnten daraus eine verbindliche Kontrolle machen.

Unter derselben 130 lag später eine andere Grammatik

1988 machte RFC 1038 aus Typ 130 eine Basic Security Option variabler Länge. Die feste Folge aus Compartments, Handling Restrictions und TCC wich einer Classification Level und Flags für Protection Authorities.

Für Parser ist diese Trennung grundlegend. Der Zahlenwert 130 identifiziert nicht allein den Aufbau; Länge und maßgebende Spezifikation entscheiden, wie die folgenden Oktette zu lesen sind. Ein Registerwert kann stabil bleiben, während sein Datenkörper inkompatibel ersetzt wird.

RFC 1038 beschrieb, wie vertrauenswürdige Komponenten die Markierung zur Prüfung der Sendeberechtigung, der Pfad- und Zielabsicherung sowie als gemeinsame Darstellung verschiedener Kontrollmodelle verwenden könnten. Diese Wirkung setzte akkreditierte Komponenten und sicherheitsbewusstes Routing voraus. Das Label erzeugte die Vertrauenskette nicht selbst.

RFC 1108 erklärte RFC 1038 für obsolet und spezifizierte Basic und Extended Security Options. Typ 130 blieb Basic, doch sogar seine Mindestlänge verschob sich: Ohne Protection-Authority-Feld genügten drei Oktette. Die Nummer überdauerte zwei Formatwechsel.

Die Codes waren absichtlich schlechte Zahlen

RFC 1108 verwendete ein Oktett für Classification Level. Nur verstreute Bitmuster standen für Top Secret, Secret, Confidential oder Unclassified; weitere Muster blieben reserviert. Ihre numerische Reihenfolge bildete die Rangfolge nicht ab.

Software durfte daher nicht alle Werte zwischen Confidential und Secret als Zwischenstufen akzeptieren. Ein solcher arithmetischer Bereich würde ungültige oder nicht zugewiesene Muster einschließen. Zuerst war exakte Gleichheit mit der Tabelle festzustellen, erst danach deren politische Ordnung anzuwenden.

Zwischen gültigen Codes lag mindestens eine Hamming-Distanz von vier. Wenige zufällige Bitfehler sollten nicht leicht eine gültige Einstufung in eine andere gültige verwandeln. Das ist Fehlererkennung, keine Verschlüsselung und kein Herkunftsnachweis. Ein Angreifer kann weiterhin absichtlich einen gültigen Code setzen.

Der Entwurf lagerte die Ordnung in ein verwaltetes Vokabular aus. Die Größe des Bytes sagte nichts über die Sensitivität; die Bedeutung stammte aus der vereinbarten Tabelle.

Authority-Flags waren Regelverweise, keine Ausweise

Hinter der Klassifikation erlaubte RFC 1108 ein variables Protection-Authority-Feld. In jedem Oktett waren sieben Bits Flags; das niederwertige Bit kündigte eine Fortsetzung an. Mehrere Authorities konnten für ein Datagramm gelten, und eine minimale Implementierung musste wenigstens zwei Flag-Oktette verarbeiten.

Die Flags nannten Programme, deren Schutzregeln auf die Information anzuwenden waren. RFC 1108 betonte, dass dies keine Akkreditierungsstellen seien. Das Feld zertifizierte keinen Host, authentisierte keine Person und verlieh keine Freigabe.

Die Darstellung musste minimal sein: Ein abschließendes Fortsetzungsoktett ohne gesetzte Flags war unzulässig. Angezeigte Feldlänge und Optionslänge mussten zusammenpassen. Eine fehlerhafte Erweiterung war ein Protokollfehler, keine harmlose Liste unbekannter Plaketten.

Auch hier lag die Autorität außerhalb des Pakets. Flag-Zuweisungen mussten genehmigt und veröffentlicht werden. Der Header wählte Einträge eines verwalteten Namensraums aus; er enthielt weder die Regeln noch einen Beleg ihrer Befolgung.

Jede Schnittstelle konnte zur Klassifikationsgrenze werden

RFC 1108 beschrieb systemweite und „per-port“ gesetzte Parameter. Port meint hier eine Netzschnittstelle oder Anbindung, nicht eine TCP- oder UDP-Portnummer. Eine Grenze konnte BSO beim Senden, beim Empfangen, in beiden Richtungen oder gar nicht verlangen.

Systeme mit klassifizierten Daten sollten gewöhnlich ein explizites Label erzeugen. Eine Ausnahme bildeten dedizierte oder system-high Netze: Dort konnte die Schnittstelle allen unmarkierten Paketen einen impliziten Wert geben. Lokale Konfiguration ergänzte dann den fehlenden Header.

Gerade diese Abkürzung macht Strippen gefährlich. Dasselbe unmarkierte Paket kann an einer Schnittstelle gewöhnlichen Verkehr bedeuten und an einer anderen eine bestimmte geschützte Stufe. Das Entfernen setzt den Wert nicht auf neutral, sondern wechselt die Quelle der Einstufung.

Beim Eingang prüfte das System, ob der Code zugewiesen war, ob er das Schnittstellenmaximum einhielt und ob seine Authorities erlaubt waren. Beim Ausgang musste die Stufe zwischen konfiguriertem Minimum und Maximum liegen und die Flag-Menge zur Ausgangsregel passen.

Das Paket schlug ein Label vor; die Schnittstelle definierte den zulässigen Raum. Ohne deren Konfiguration kann ein Mitschnitt die tatsächliche Sicherheitsentscheidung nicht vollständig erklären.

Selbst die Fehlermeldung war klassifiziert

Wenn eine Schnittstelle BSO verlangte und keines erhielt, sah RFC 1108 ICMP Parameter Problem mit Code 1 für eine fehlende erforderliche Option vor. Fehlgeformte Labels benutzten die allgemeine Parameter-Problem-Form; unzulässige Werte konnten als administratively prohibited beantwortet werden.

Das waren die am wenigsten restriktiven zulässigen Reaktionen. Lokale Regeln konnten Protokollierung, Alarm an Sicherheitsverantwortliche oder völliges Schweigen verlangen. Sogar eine Diagnose musste zur Klassifikation der Ausgangsschnittstelle passen.

Daraus folgt keine allgemeine Regel für jede fehlende IPv4-Option. Der Fall zeigt vielmehr, dass Antwort, Schweigen und Kennzeichnung einer Antwort Teile der Zugriffskontrolle waren. Der ICMP-Code belegt die reale Pflichtstellung des Labels, ist aber nicht der Gegenstand dieser Geschichte.

Alte Formate waren obsolet, die revidierte Routerfunktion blieb

RFC 1122 nannte die Security Options aus RFC 791 und RFC 1038 obsolet. Für DoD-Anwendungen verwies es auf die Überarbeitung, aus der RFC 1108 hervorging. Das Urteil galt den alten Spezifikationen, nicht der Existenz sämtlicher markierter Netze.

RFC 1812 erhielt diese Differenz. Es wiederholte die Obsoleszenz der Vorgänger, sagte aber, Router sollten die revidierte Option aus RFC 1108 implementieren. Router für mehrere Sicherheitsstufen sollten nach IPSO-Labels filtern können.

Das Modell gab jeder Schnittstelle eine untere und obere Sensitivitätsgrenze. Pakete außerhalb der Spanne sollten still verworfen und in einem Zähler erfasst werden. Dies war keine Source Route, sondern ein lokaler Zulässigkeitstest an jeder Grenze.

Normativer Status verläuft folglich nicht als einfacher Ein-Aus-Schalter. Ein Format wird obsolet, sein Nachfolger bleibt bedingte Routerfunktion, dessen Dokument wird später Historic, und die operative Anforderung lebt in einem begrenzten Umfeld weiter.

Historic sagte nichts über die Zahl geschlossener Netze

RFC 7126 stellt fest, dass diese Optionen im globalen öffentlichen Internet normalerweise nicht auftauchen sollten. Zugleich nennt es private Multi-Level-Secure-Netze auf kommerziellen und offenen Systemen. Es hielt es sogar für möglich, dass MLS- und damit IPSO-Installationen seit der Entfernung vom Standards Track zugenommen hatten.

Ein Mechanismus kann aus dem öffentlichen Mainstream verschwinden und in einem spezialisierten Binnenraum fortbestehen. Historic bezeichnet den Status eines RFC. Es ist weder eine Verkehrsmessung noch die Feststellung null vorhandener Implementierungen.

Dasselbe Seriengerät kann in beiden Umgebungen stehen. Vor der Konfiguration weiß es nicht, ob Typ 130 nutzloser Ballast am öffentlichen Rand oder zwingendes Label im geschlossenen Netz ist. Daher muss der Standardzustand die Entscheidung des sachkundigen Betreibers erhalten.

Bewahren ist nicht dasselbe wie glauben

RFC 7126 begründet eine vorsichtige Voreinstellung. Wo BSO benötigt wird, verursacht Löschen oder Blockieren konkrete Fehler. Wo es nicht benötigt wird, richtet bloßes unverändertes Weitertragen keinen spezifischen neuen Schaden an. Ein generisches Gerät sollte deshalb weder strippen noch allein wegen der Anwesenheit verwerfen.

In einer nachweislich IPSO-freien Umgebung darf ein Administrator den Drop konfigurieren. Geräte sollten BSO-Pakete pro Schnittstelle zählen und nach Anwesenheit wie auch nach Werten filtern können. Das öffentliche Internet muss das Label nicht als glaubwürdig behandeln; ein Zwischenknoten soll nur nicht vor der lokalen Regel dessen Bedeutung zerstören.

Unverändertes Weiterleiten ist keine Validierung. Es trennt Transport von Vertrauen und überlässt die Auswertung dem Bereich, der dafür eine MLS-Politik besitzt.

Auch modernes TCP musste den Restbestand einhegen

RFC 9293 dokumentiert das unbequeme Erbe. Ältere TCP-Regeln bezogen IP-Sicherheits- und Compartment-Information in die Verbindungsverarbeitung ein. 2022 war RFC 1108 Historic, RFC 791 aber nie um die Security Option bereinigt worden.

Die moderne Spezifikation behandelt den Stoff in Implementierungshinweisen. Für MLS-Systeme kann er weiterhin relevant sein; Nicht-MLS-Systeme dürfen ihn ignorieren. Diese klare Domänengrenze ist ehrlicher als ein angeblich universelles Verhalten.

Sie erwähnt zudem, dass das Zurücksetzen von Verbindungen bei abweichenden Compartment- oder Precedence-Werten als möglicher Angriffsvektor erkannt wurde. Ein Label kann innerhalb seines Vertrauensmodells Aufnahme sichern und außerhalb davon über mechanisch geerbte Reaktionen zur Störfläche werden.

Was ein Mitschnitt belegt

Typ 130 in einem Paket belegt Bytes an einer historisch vergebenen Position. Länge und Form können zeigen, welcher Spezifikation der Sender offenbar folgt. Ein zugewiesener Klassifikationscode und eine korrekt aufgebaute Authority-Erweiterung belegen syntaktische Konformität.

Sie beweisen keine Freigabe des Senders, keine Wahrheit des Labels, keine Vertraulichkeit der Nutzlast, keinen geschützten Pfad und keine Annahme an der nächsten Schnittstelle. Dafür wären Belege über reale Zuweisungen, Konfigurationen und Vertrauensgrenzen nötig.

Auch Abwesenheit beweist nicht Unclassified. Eine Schnittstelle mit implizitem Label kann eine nicht im Paket sichtbare Stufe zuweisen. Wer Capture und Schnittstellenregel trennt, verliert einen Teil der Semantik.

Die bleibende Lehre des Typs 130 lautet daher nicht, jede Sicherheit in Header zu verlagern. Sie lautet, dass das Entfernen von Metadaten eine Bedeutungsänderung ist. Wo ein Feld in Mandatory Access Control eingeht, kann sein uninterpretierter Erhalt sicherer sein als eine künstlich erzeugte Leerstelle.

Quellen und Beweisgrenzen

Der geschlossene Quellenbestand umfasst RFC 791, RFC 1038, RFC 1108, RFC 1122, RFC 1812, RFC 7126 und RFC 9293. Er belegt Formate, Verarbeitung, Status und bedingte Filterempfehlung. Er verrät keine geheimen Installationen, misst keinen heutigen Verkehr, prüft keine Herstellerimplementierung und bestätigt kein beobachtetes Label als wahr.