Zusammenfassung

  • Bei einem Kiss-o’-Death ist Stratum null: Empfangs- und Sendezeitstempel sind undefiniert und werden verworfen; der Reference Identifier trägt stattdessen einen kurzen Statuscode.
  • RATE, DENY und RSTR waren keine Fernsteuerung. Nur eine noch offene Anfrage, korrekte Reaktion, begrenzte Pollwerte und tatsächliche Kooperation konnten aus der Meldung Entlastung machen.

Netzwerkprotokolle enthalten viele Rückmeldungen, aber nicht jede Rückmeldung übt Kontrolle aus. Ein Server kann Überlastung melden. Ob ein Client danach langsamer fragt, entscheidet Code, der auf einer anderen Maschine läuft. NTPs Kiss-o’-Death, kurz KoD, machte diese Trennung sichtbar: Die Nachricht war standardisiert, die Ausführung blieb lokal.

Das Paketformat wartete vierzehn Jahre auf diese Bedeutung

RFC 1305 definierte 1992 für NTPv3 ein acht Bit großes Stratum-Feld und einen vier Oktette langen Reference Identifier. Stratum null hieß „unspecified“; für Stratum null und eins ließ sich der Bezeichner als vier ASCII-Zeichen darstellen. RFC 2030 übernahm die Form 1996 für SNTPv4.

Die spätere KoD-Bedeutung stand dort noch nicht. Ein vorgesehenes Feld ist keine soziale oder technische Vereinbarung. Erst RFC 4330 erklärte 2006 ausdrücklich, dass RFC 1305 die Semantik des Reference Identifier bei Stratum null offen gelassen hatte, und ordnete ihm Status-, Zugangs- und Ratencodes zu.

Der Anlass war konkrete Betriebslast. Viele Heim- und Bürorouter waren auf denselben universitären Zeitserver voreingestellt; einige fragten im Sekundentakt. Mit der installierten Basis wuchs der Verkehr dramatisch, bis der Betreiber extreme Abwehrmaßnahmen ergreifen musste.

Ein Hersteller hatte eine bequeme Voreinstellung gewählt, ohne die späteren Kosten selbst zu tragen. Der Betreiber konnte die ausgelieferte Firmware nicht ändern. Paketverlust allein sagte einem kooperationsfähigen Client nicht, ob der Server unerreichbar, überlastet oder grundsätzlich nicht zuständig war. KoD sollte den Grund in der bestehenden Antwortform ausdrücken.

Die Antwort verließ den Messpfad

RFC 5905 nahm KoD in NTPv4 auf. Bei Stratum null ist die Antwort für die Zeitsynchronisation ungültig; der Reference Identifier wird als kiss code gelesen. Receive Timestamp und Transmit Timestamp eines KoD sind undefiniert und müssen verworfen werden.

Der Client darf daraus weder Offset noch Laufzeit berechnen. KoD ist keine schwache Zeitquelle, die nur ein schlechteres Gewicht erhält. Die Antwort transportiert überhaupt keine verwertbare Zeit. Sie wechselt vom Messpfad in den Steuerpfad der Client-Server-Beziehung.

DENY und RSTR verlangen, die Association zu demobilisieren und keine weiteren Pakete an diesen Server zu senden. RATE verlangt größere Pollabstände. INIT und STEP bezeichneten in RFC 4330 vorübergehende Serverzustände. Keiner der Codes beweist, dass eine Sperre gerechtfertigt oder der Absender authentisch ist. Er benennt nur den vorgesehenen Übergang.

Der veröffentlichte Text drehte RATE zunächst um

In RFC 5905 stand, ein Client solle nach RATE das Pollintervall verkleinern. Das hätte mehr Abfragen erzeugt. Verified Errata 3007 korrigiert die Richtung: Das Intervall ist zu vergrößern, damit die Frequenz sinkt.

Der Fehler zeigt, warum ein Regelkreis durch Messung geprüft werden muss. Der Logeintrag „RATE erkannt“ ist kein Erfolg. Entscheidend ist, ob der Poll-Exponent steigt, das nächste Paket später kommt und die Serverlast fällt. Ein einziges falsches Verb kann die gleiche standardisierte Nachricht zum Verstärker machen.

Der Server kann den entfernten Zustandsübergang nicht erzwingen. Alte Clients ignorieren KoD möglicherweise; fehlerhafte Clients reagieren umgekehrt. Die Spezifikation koordiniert willige Implementierungen und besitzt keine Ausführungsgewalt über sie.

Eine offene Anfrage gab Relevanz, aber keine Identität

RFC 8633 verlangt, ein KoD nur bei gültigem Origin Timestamp zu akzeptieren. Dieser Wert muss zur noch offenen Anfrage des Clients gehören. Ein altes oder unaufgefordertes Paket soll keine Association verändern.

Die Prüfung stellt Transaktionsbezug her, nicht automatisch Authentizität. Sie beantwortet: „Passt die Antwort zu meiner aktuellen Frage?“ Ohne kryptografischen Schutz bleibt offen: „Kam sie vom legitimen Server?“ Ein Angreifer, der Anfragewerte beobachten oder hinreichend vorhersagen kann, kann eine plausible Ablehnung versuchen.

Das genügt für einen Denial of Service, ohne falsche Uhrzeit zu liefern. Ein gefälschtes DENY entfernt eine funktionierende Quelle; ein gefälschtes RATE verschiebt die nächste Messung. Angegriffen wird der Zugang zu künftiger Evidenz.

Telemetrie muss deshalb Empfang, Anfrageübereinstimmung, Authentifizierung, Akzeptanz und angewandten Zustandswechsel getrennt abbilden. „KoD erhalten“ darf nicht stillschweigend zu „Server hat autorisiert gesperrt“ werden.

Der lokale Grenzwert hielt den Timer beim Client

Auch ein legitimer Server kann einen ungeeigneten Pollwert vorschlagen. Blindes Übernehmen eines sehr großen Werts würde Fehlern oder Fälschern erlauben, einen Client lange zum Schweigen zu bringen. RFC 8633 nennt einen vernünftigen Maximalwert von höchstens Poll-Exponent 13, ungefähr zwei Stunden.

Der Server darf seinen Lastdruck mitteilen; der Client behält die Grenze seiner Reaktion. Diese Aufteilung schützt zugleich Serverkapazität und die Kontinuität der Zeitversorgung.

Nicht kooperationsfähige Geräte bleiben außerhalb dieses Kreises. RFC 8633 weist darauf hin, dass Clients KoD ignorieren oder falsch umsetzen können. Server benötigen weiterhin Paketverwerfung, Ratefilter und Queue-Schutz. Die Rückmeldung erklärt die Grenze. Der Filter setzt sie lokal durch.

NTSN begrenzte eine notwendige unauthentifizierte Ausnahme

Network Time Security schützt normale Antworten. Wenn ein Server jedoch Cookie oder Authenticator des Clients nicht mehr validieren kann, kann er gerade die geschützte Antwort nicht erzeugen, die den Verlust des Zustands erklären würde.

RFC 8915 definiert dafür NTSN. Der Server soll ein KoD senden und muss NTS Cookie sowie NTS Authenticator and Encrypted Extension Fields weglassen. Hat der Client zuvor authentische Antworten erhalten, muss der Unique Identifier zu einer offenen Anfrage passen; sonst verwirft er die Meldung.

Eine passende Meldung löst nicht sofort eine schnelle Schlüsselaufbauschleife aus. Der Client wartet bis zum nächsten regulären Poll. Fehlt dann eine gültige geschützte Antwort, wiederholt er NTS-KE mit begrenzter Rate und verwendet die alten Pollparameter weiter, bis der Neuaufbau gelingt.

NTSN ist deshalb keine Behauptung, jedes KoD sei durch NTS authentifiziert. Es ist ein schmaler Wiederherstellungsweg: ungeschützte Meldung, enger Anfragebezug, verzögerte und gebremste Folgeaktion.

Ein Register schließt Namens-, nicht Vertrauenslücken

RFC 5905 schuf ein IANA-Register, damit mehrere Spezifikationen dieselben vier Zeichen nicht unterschiedlich belegen. RFC 9748 aktualisierte 2025 die Regeln: bis zu vier ASCII-Zeichen, Nullauffüllung kürzerer Werte, X für Experimente sowie Großbuchstaben und Ziffern für neue Codes unter Specification Required.

Das Register macht Bedeutungen auffindbar und verhindert Kollisionen. Es authentifiziert keine Pakete, prüft keine Firmware und rechtfertigt keine konkrete Zugangssperre. Registrierte Syntax ist noch kein laufendes Verhalten.

Die institutionelle Grenze blieb damit klar. IETF und IANA koordinieren die gemeinsame Drahtbedeutung. Der Server entscheidet über Antwort oder Filter. Der Client besitzt Anfragezustand, Obergrenzen und alternative Quellen. Ein globaler Zeit- oder Pollregler entstand nicht.

Der bereits veröffentlichte BTW-Text über NTP behandelte vier Zeitstempel, widersprechende Quellen und lokale Uhrdisziplin. Dieser Beitrag wiederholt das Auswahlverfahren nicht. Er beginnt beim absichtlich fehlenden Messwert und untersucht, wie weit eine standardisierte Bitte um Rückzug reichen durfte.