Zusammenfassung

  • IPv4-Option 68 stellte im Paket einen endlichen Schreibraum für Zeitstempel oder Adress-Zeitstempel-Paare bereit.
  • Host- und Routerregeln hielten an der Kooperation fest, doch fehlende Authentisierung, unsynchrone Uhren, Informationsabfluss und Filterung schmälerten ihren Nutzen.

Ein Protokoll mit eingebautem Platzmangel

Der Internet Timestamp aus RFC 791 war kein unveränderlicher Absenderwert. Unter Typ 68 reservierte das Paket einen Bereich, den verarbeitende Systeme ergänzen konnten. Das Copy-Bit war null; nach einer Fragmentierung blieb die Option daher nur im ersten Fragment. In einem Datagramm durfte sie höchstens einmal vorkommen.

Ihr Aufbau begrenzte jede Beobachtung. Ein Längenoktett setzte 40 Oktette als Obergrenze. Der Zeiger wies auf den nächsten freien Eintrag, wobei 5 der kleinste gültige Wert war. Vier Bit zählten Überläufe, vier weitere bestimmten den Modus. Reichte der Platz nicht mehr, erhöhte ein Teilnehmer den Zähler, statt über das Ende hinauszuschreiben. War die Länge oder der Zeiger ungültig oder lief auch der Vier-Bit-Zähler über, galt das Datagramm als fehlerhaft und wurde verworfen; eine ICMP-Parameter-Problem-Meldung konnte folgen.

Modus 0 sammelte aufeinanderfolgende 32-Bit-Zeitstempel. Modus 1 ließ jedes System zuerst seine Internetadresse und danach die Zeit eintragen. Modus 3 enthielt vorgegebene Adressen; ein Zeitstempel entstand nur, wenn die nächste Adresse zum gerade verarbeitenden System passte. Der bevorzugte Wert waren Millisekunden seit Mitternacht Universal Time. War diese Zeit nicht verfügbar, durfte eine andere Referenz verwendet werden, aber nur mit gesetztem höchstwertigem Bit als Kennzeichen des nicht standardisierten Werts.

Damit dokumentierte die Option Beteiligung, nicht den vollständig beglaubigten Weg. Vierzig Oktette waren schnell verbraucht, besonders bei Adress-Zeit-Paaren. Kein Feld authentisierte den Schreiber oder bewies, dass schweigende Hops die Anfrage gesehen hatten. Ein Datum fehlte, und ohne synchronisierte Uhren waren Werte verschiedener Geräte nur eingeschränkt vergleichbar.

Unterstützung bedeutete nicht dasselbe für jedes System

RFC 1122 stellte Hosts sowohl die Erzeugung als auch die Verarbeitung frei. Wer sie implementierte, musste jedoch die Regeln einhalten: Der Ursprung trug im passenden Modus die eigene Zeit ein; das Ziel ergänzte nach Möglichkeit die aktuelle Zeit, bevor es die Option nach oben weitergab. Bevorzugt blieben Millisekunden seit Mitternacht UT, während abweichende Werte markiert werden mussten.

RFC 1812 verlangte von Routern die Unterstützung in weitergeleiteten Paketen. Im Modus 3 genügte die Übereinstimmung mit irgendeiner Routeradresse; es musste nicht die Ein- oder Ausgangsschnittstelle sein. Eine Schaltmöglichkeit durfte Modus 0 oder 1 unverändert passieren lassen, musste aber standardmäßig ausgeschaltet sein. Zugleich hielt das Dokument fest, dass ein Eintrag nahe am Empfang nützlicher sei und unsynchrone Uhren die Aussagekraft begrenzten.

Vom Diagnosewert zur Offenlegung

RFC 7126 beschrieb Verarbeitungszeiten und Adressen weiterhin als mögliche Diagnosehilfe, betrachtete sie aber ebenso als Informationsabfluss. Sie konnten Topologie, Systemzeit und Implementierungsmerkmale sichtbar machen; Uhrendrift konnte möglicherweise sogar physische Geräte unterscheiden. Was Betreibern Einblick gab, war auch für unerwünschte Beobachter lesbar.

Die Diagnose hing außerdem von jeder administrativen Grenze ab. Gewöhnliches Ping funktionierte ohne IPv4-Optionen, ein Timestamp-Verfahren dagegen scheiterte an einem einzigen Filter. RFC 7126 sah solche Verfahren wegen weitverbreiteten Verwerfens bereits als praktisch unbrauchbar an und empfahl Routern, Sicherheitsgateways und Firewalls, Pakete mit dieser Option zu verwerfen.

Quellen