Zusammenfassung

  • RFC 1455 belegte den IPv4-TOS-Wert 15 mit der Bitte um den Weg mit der höchsten verfügbaren physischen Verbindungssicherheit: Beobachtung durch Außenstehende sollte möglichst erschwert werden.
  • Router sollten diese Bitte anhand lokal festgelegter Kosten für Leitungen und Routerstandorte auswerten. Das Bitmuster belegte daher nur die Absicht des Senders, nicht eine einheitliche Richtlinie, den tatsächlich genommenen Weg, Verschlüsselung oder Vertraulichkeit.
  • Der bleibende Wert des Entwurfs liegt in seiner Beweisgrenze: Zwischen einer Dienstanforderung und einem Sicherheitsergebnis stehen Auslegung, Richtlinie, Berechnung, Weiterleitung, Anlagenzustand und Beobachtung.

Ein Superlativ mit eingebauter Einschränkung

RFC 1455 nannte den neuen Dienst „maximum physical link security“. Gemeint war keine absolute Untergrenze. Das Routing sollte aus den vorhandenen Möglichkeiten den Weg auswählen, bei dem die heimliche Beobachtung durch Akteure außerhalb des Netzes nach lokaler Einschätzung am wenigsten wahrscheinlich war.

Die Spezifikation sagte ausdrücklich, dass damit kein bestimmtes Sicherheitsniveau garantiert werde. „Maximal“ bezeichnete die Rangfolge innerhalb eines Angebots. Auch der beste verfügbare Pfad konnte für den Zweck des Absenders ungeeignet sein. Ressourcenreservierung oder Policy Routing wären nötig gewesen, um aus einer Präferenz eine verbindlichere Zusage zu machen; das damalige TOS-Feld konnte das nicht leisten.

Diese sprachliche Trennung ist technisch folgenreich. Eine Bezeichnung auf einem Paket wird leicht als Zustand des Netzes gelesen: sicher markiert, also sicher befördert. RFC 1455 erlaubte nur den ersten Satzteil. Sie definierte eine Bitte an das Routing, keine Bescheinigung über das Ergebnis.

Die Messlatte gehörte dem Betreiber

Für die Umsetzung verwies das Memo auf TOS-fähiges Routing, darunter die damaligen Möglichkeiten von OSPF. Ein Betreiber sollte für dieses Ziel eigene Kosten an Leitungen und Routerstandorte vergeben. Das Festlegen dieser Werte war ausdrücklich lokale Politik.

Die Beispieltabelle setzte starke Leitungsverschlüsselung mit sicherer Schlüsselverteilung auf 1. Eine physisch gesicherte Punkt-zu-Punkt-Leitung erhielt 2, eine gewöhnliche Punkt-zu-Punkt-Verbindung 6, ein lokales Mehrpunktmedium 8, ein städtisches Mehrpunktmedium 12, lokaler Funk 24 und eine Satellitenverbindung 32.

Das waren keine Messwerte. Die 32 bedeutete weder 32 Prozent Abhörwahrscheinlichkeit noch ein überall gültiges Verhältnis. Sie codierte die Annahmen eines hypothetischen Betreibers: In dessen Modell sollte ein Satellitenweg gegenüber der verschlüsselten Referenz stark benachteiligt werden.

Ein anderes Netz konnte dieselben Medien anders einordnen. Geografie, Gebäudeschutz, Schlüsselverwaltung, Funkreichweite und Gegnerbild veränderten die Bewertung. Im Paket standen weder die Version dieser Kostentabelle noch ihr Urheber oder ihre Gültigkeitsdauer. Dass zwei Netze denselben TOS-Wert verstanden, hieß deshalb noch nicht, dass sie dieselbe Dienstklasse lieferten.

Der Gegner sah auch verschlüsselte Kommunikation

Die Motivation begann bei der Verkehrsanalyse. Selbst wenn alles hinter dem IP-Header Ende-zu-Ende verschlüsselt war, mussten Quell- und Zieladresse für Router sichtbar bleiben. Wer den Datenstrom beobachten konnte, erfuhr möglicherweise, welche Systeme miteinander kommunizierten, wann sie aktiv wurden und wie sich das Volumen veränderte.

RFC 1455 betrachtete einen Außenstehenden, der physische Übertragungswege heimlich beobachtet. Ein Angreifer mit internem Netzzugang lag außerhalb dieses Schutzmodells. Der Mechanismus verbarg Endpunkte nicht vor Routern, authentisierte keine Kommunikationspartner und entschied nicht, ob ein Empfänger die Daten verwenden durfte.

Physische Eigenschaften konnten die Beobachtung erschweren. Glasfaser galt als schwieriger anzuzapfen als Metallkabel; Punkt-zu-Punkt-Medien als weniger offen als geteiltes Ethernet oder FDDI; bewachte oder überwachte Leitungswege als besser als frei zugängliche; Spreizspektrum als weniger leicht mitzuhören als gewöhnlicher Funk. Leitungsverschlüsselung konnte abgefangene Signale weniger nützlich machen. Keine einzelne Eigenschaft bewies jedoch ein vertrauliches Ende-zu-Ende-Ergebnis.

Warum ausgerechnet 1111?

Das Dokument wählte den Dezimalwert 15, hexadezimal F, binär 1111 im vier Bit breiten TOS-Feld. Gegenüber den anderen damals definierten TOS-Werten lag dieses Muster in maximaler Hamming-Distanz. Dadurch sollte eine Verwechslung von Codes unwahrscheinlicher werden.

Vier gesetzte Bits standen nicht für vier addierte Leistungen. RFC 1349 hatte TOS bereits als Aufzählung ganzer Werte beschrieben, nicht als Sammlung unabhängiger Schalter, die man per logischem OR kombinieren durfte. 1111 hieß also nicht gleichzeitig minimale Verzögerung, maximaler Durchsatz, maximale Zuverlässigkeit und minimale Kosten. Es war genau die neue Anforderung.

Die Grammatik schützt nur vor einer bestimmten Fehlinterpretation. Sie belegt nicht, dass ein Router den Wert kannte, dass er die passende Tabelle geladen hatte oder dass die errechnete Route später wirklich benutzt wurde. Ein syntaktisch erhaltener Code kann seine operative Bedeutung an der nächsten Verwaltungsgrenze verlieren.

Mehr als fünfzig sichere Abschnitte konnten zwei unsichere schlagen

Die Beispielkosten erzeugten eine bewusst überraschende Wahl. Mehr als fünfzig sehr sichere Verbindungen konnten günstiger sein als zwei unsichere Abschnitte, etwa eine unverschlüsselte Satellitenstrecke gefolgt von Funk. Der kürzeste Weg war nicht zwingend der am wenigsten beobachtbare.

Mit jedem zusätzlichen Abschnitt kam aber ein Router hinzu: ein Standort, Personal, Software, Konfiguration und physischer Zugang. Ein Modell, das nur Kabel bewertete, konnte eine lange Kette guter Leitungen durch schlecht geschützte Betriebsräume wählen. RFC 1455 verlangte deshalb, auch die Sicherheit der Routerstandorte zu berücksichtigen.

Das Gedankenexperiment bewies nicht die Sicherheit einer Route mit fünfzig Hops. Es zeigte, welche Objekte der Nachweis umfassen musste. Medienklasse ohne Routerzustand blieb unvollständig; eine berechnete Route ohne beobachtete Weiterleitung ebenfalls; und ein Pfad ohne zeitgleichen Anlagenzustand konnte nur eine historische Möglichkeit, nicht die Beförderung des Pakets belegen.

Addiert wurde, was eigentlich multipliziert werden sollte

Routingverfahren addierten Linkkosten. Für das Sicherheitsziel wäre laut RFC das Produkt der Wahrscheinlichkeiten sicherer Übertragung sachlich passender gewesen. Trotzdem akzeptierte sie die Summe als für die meisten Zwecke brauchbare Näherung, ähnlich wie RFC 1349 beim Ziel hoher Zuverlässigkeit.

Diese Offenheit begrenzt den Anspruch des Ergebnisses. Der Algorithmus maß die gewünschte Wirkung nicht direkt. Er ordnete Wege nach relativen Schätzungen in einer bequemen additiven Skala. Die Schätzungen konnten veraltet, nicht vergleichbar oder dem falschen Betriebsmittel zugeordnet sein.

Eine solche Metrik kann Entscheidungen dennoch verbessern. Ihr Ergebnis muss nur richtig benannt werden: unter dieser Konfiguration und diesem Näherungsmodell bevorzugt. Es ist weder eine gemessene Wahrscheinlichkeit noch ein kryptografischer Nachweis oder eine Gewährleistung.

Zustellung konnte auch Fallback bedeuten

RFC 1349 sprach vom „requested TOS“. Wörter wie „minimize“ und „maximize“ beschrieben den Versuch des Netzes, mit oft unvollkommenen Informationen den besten verfügbaren Weg zu finden. Sie legte schwaches TOS-Routing fest: Gab es keine Route für eine nicht standardmäßige Anforderung, durfte stattdessen eine Standard-TOS-Route verwendet werden.

Das schützte Erreichbarkeit und erleichterte eine schrittweise Einführung. Gleichzeitig vergrößerte es die Beweislücke. Aus der Ankunft eines markierten Pakets ließ sich nicht ablesen, ob das Netz die Anforderung erfüllt, auf den Standard zurückgefallen oder an einem Knoten vorbeigekommen war, der den Wert ignorierte.

RFC 1455 hielt es selbst für unrealistisch, dass das gesamte Internet den neuen Wert in absehbarer Zeit implementieren würde. Eine Ende-zu-Ende-Aussage brauchte somit Belege je Verwaltungsbereich oder Hop. Das Headerfeld war kein stillschweigendes Empfangsprotokoll.

Ein Sicherheitslabel sagte etwas anderes

RFC 1108 macht sichtbar, was der neue TOS-Wert nicht enthielt. Ihre Basic Security Option führte eine Klassifikationsstufe und Kennzeichen für Schutzbehörden. Systeme konnten prüfen, ob ein Datagramm für Quelle, Ziel und geschützten Weg zulässig war; Routingprotokolle benötigten dazu Informationen über Sicherheitslabels.

Die Mechanismen konnten zusammenwirken, waren aber nicht austauschbar. Das Label beschrieb Schutzstufe und zuständige Regeln. RFC 1455 bat um den physisch am schwersten beobachtbaren verfügbaren Weg. Aus dem einen folgte das andere nicht.

Auch ein anerkanntes Label verschlüsselte den Inhalt nicht von selbst. Schlüsselzustand, Endpunktschutz und tatsächliche Exposition blieben eigene Tatsachen mit eigenen Nachweisen.

Das Oktett bekam eine neue Grammatik

RFC 2474 erklärte die alten TOS-Definitionen später für überholt und definierte das Differentiated-Services-Feld. Ein DSCP wählte ein Verhalten pro Hop; Klassifizierer, Traffic Conditioner und administrative Richtlinien an Domänengrenzen formten den Dienst.

Die Nachfolgeregel beweist keine Verbreitung von RFC 1455. Sie zeigt einen Lebenszyklusbruch: Die Position im Header kann bestehen bleiben, während sich ihr Vertrag ändert. Eine Paketaufzeichnung lässt sich nur mit Datum, Domäne, Semantik und damaliger Richtlinie auslegen. Bits allein tragen ihre Geschichte nicht mit.

Vom Wunsch zur beobachteten Vertraulichkeit

Die notwendige Beweiskette lautet:

Wunsch des Senders → erkannter Code → gültige lokale Richtlinie → berechnete Route → tatsächliche Weiterleitung → Schutz von Leitung und Router → kryptografischer Zustand → Berechtigung am Endpunkt → beobachtetes Ergebnis

An jedem Pfeil wechseln Zuständigkeit und Aussage. Der Sender kann seinen Wunsch belegen. Der Router kann die geladene Richtlinie dokumentieren. Telemetrie kann den Weg zeigen. Anlagen- und Schlüsselaufzeichnungen können Schutzmerkmale zu einem Zeitpunkt belegen. Erst eine abgegrenzte Beobachtung kann sagen, was ein benannter Gegner erlangte.

RFC 1455 löste Vertraulichkeit nicht. Ihre historische Präzision bestand darin, einen Sicherheitswunsch im Paket sichtbar zu machen und zugleich festzuhalten, dass der erste Nachweis nicht die Autorität des letzten besitzt.

Quellen und Grenzen

Status, Erscheinungsdatum und Ablösung stehen im RFC-Editor-Eintrag zu RFC 1455. Anforderung, Bedrohungsmodell, Kostenbeispiel, Routenvergleich und Näherung enthält RFC 1455. Die Aufzählungssemantik, der Anforderungscharakter und das schwache Fallback folgen aus RFC 1349. Die getrennte Klassifikation und Schutzbehördenstruktur beschreibt RFC 1108. Die spätere Ersetzung der Feldsemantik bestätigt der RFC-Editor-Eintrag zu RFC 2474.

Diese Quellen belegen Entwürfe und ausdrücklich genannte Grenzen. Sie belegen keine Implementierung von RFC 1455, keine realen Kostentabellen, keine gemessenen Abhörraten, keinen geschützten historischen Pfad, keine erreichte Vertraulichkeit und keine heutige Betriebsempfehlung.