Summary

  • NTP made a negative response legible by assigning Stratum 0 and the Reference Identifier to Kiss-o'-Death codes: the packet could explain refusal or overload but could not supply clock evidence.
  • The client first had to bind the response to its own request, discard its time-bearing fields and grant only the action named by the code; because that signal was often unauthenticated, obedience also became a denial-of-service risk.

A response that must not become a sample

For an ordinary NTP exchange, the receive and transmit timestamps are the server's contribution to a measurement. Joined with the client's send and receive times, they help estimate offset and round-trip delay. A Kiss-o'-Death, or KoD, deliberately borrows the response envelope while withdrawing that evidentiary promise.

RFC 5905 gives the decisive rule. When Stratum is 0, the value is unspecified or invalid and the Reference Identifier may carry a status or access-control message. The server-set Receive and Transmit timestamps are undefined. A client must not rely on them and must discard them.

This is more than defensive parsing. It separates two kinds of authority that arrive over the same UDP conversation. A normal reply offers observations that may enter the clock-selection machinery. A KoD requests a change in client behaviour. Its meaning lies in the negative control code, not in the apparent time values surrounding it.

The empty field acquired a job

The opening existed because an older specification had left room. RFC 1305 described Stratum 0 as unspecified but did not define the Reference Identifier's status-message role in that case. RFC 4330, published in 2006, turned that spare combination into an operational channel.

Its motivation was not theoretical elegance. The RFC records an incident in which many home and office routers had been configured to use one university time server. Under some error conditions, a substantial fraction queried once per second. The traffic spike was dramatic, and the operator needed extreme measures to diagnose and contain it. A server could drop packets, but silence gave a cooperative client no instruction about what to change.

KoD made refusal expressible without creating a separate protocol. The server set Stratum to 0 and wrote a four-character ASCII kiss code into the Reference Identifier, left-justified and zero-padded. The response path already reached the requester. The new semantic let it carry “access denied,” “restricted by local policy,” “rate exceeded” or another registered condition.

The name is theatrical; the control surface is narrow. The message does not kill a process, revoke an identity or prove wrongdoing. It asks the recipient to perform a defined local action concerning its association with that server.

Recognition came before compliance

A negative instruction is useful only if it belongs to the request in flight. In client/server NTP, a reply's Origin Timestamp echoes the Transmit Timestamp from the request. RFC 5905 uses the comparison to detect a bogus or replayed packet. RFC 8633 applies the boundary directly to KoD: a client must accept one only when the Origin Timestamp is valid.

That check prevents a random packet from gaining authority merely by using UDP port 123 and a recognizable code. It does not supply cryptographic identity. An observer able to learn expected state, or an attacker within the relevant path and threat model, may still have more opportunities than an off-path guesser. Request binding says “this response corresponds to what I sent,” not “every claim made by this server is true.”

The processing order therefore matters:

  1. establish that the packet belongs to an outstanding exchange;
  2. recognize Stratum 0 and the code;
  3. exclude the undefined server timestamps from time discipline;
  4. apply only the local state transition assigned to that code.

If those steps are collapsed, a parser can either treat refusal as bad time or grant an unauthenticated status string more power than the protocol intended.

Four letters, different consequences

RFC 5905 makes three cases especially consequential. DENY means the remote server denies access; RSTR expresses a local-policy restriction. For either, the client must demobilize associations to that server and stop sending packets. RATE means the server has temporarily denied access because the client crossed a request threshold. The client must reduce its polling rate and continue backing off if RATE packets recur.

Those actions are not interchangeable. RATE preserves the possibility of a later measurement from the same server. DENY and RSTR end the association. None authorizes a clock correction. An unfamiliar code does not create an open-ended instruction language: codes beginning with X are reserved for experimentation, and unknown meanings have no standard protocol consequence.

The current IANA NTP Parameters registry lists the shared vocabulary, including DENY, RSTR, RATE and the later NTSN. It also contains codes for association state, authentication failure and resynchronization conditions. Registration makes implementations more likely to attach the same label to the same bytes. It does not authenticate the packet or verify that the asserted condition exists.

A server's safety signal could deny the client service

Backpressure shifts work to the sender. That is why it protects a public service, and why it must be bounded by the sender's own availability policy.

RFC 8633 recommends that devices respect KoD, especially embedded clients that may be deployed without a visible control interface. For RATE, it says a client should increase the polling interval to a reasonable maximum and should not exceed poll exponent 13, or two hours. It also warns against copying any interval value supplied by the server without validation. An extremely large value can turn compliance into a denial-of-service condition in which the client effectively stops asking for time.

There is a second asymmetry. KoD works only when clients implement it correctly. Some clients ignore RATE. Others have historically reacted badly enough to increase load. A server under pressure cannot treat protocol cooperation as its only defense; dropping, shaping and monitoring may remain necessary.

The negative response thus exposes a general Internet problem. A receiver needs enough authority to protect itself from abusive demand. A sender needs enough independence to prevent a forged or unreasonable backoff instruction from removing an essential service. KoD distributes that decision: the server names the condition, while the client validates the packet and owns the local bound.

NTS tied the negative response to stronger state

RFC 8915 added Network Time Security for NTP client/server mode. An NTS-protected response must carry a Unique Identifier matching an outstanding request and authenticate under the associated server-to-client key. If either check fails, the client discards it without further processing.

Negative responses have a special edge. When a server cannot validate a cookie or authenticate a request, it may send a KoD with code NTSN, meaning NTS negative acknowledgment. That packet omits the normal NTS Cookie and Authenticator fields because the server could not recover or validate the protected state.

The specification still prevents a free-floating NTSN from acquiring automatic authority. Once a server has returned authentic NTS-protected packets, a later KoD must contain the Unique Identifier of an outstanding request or the client discards it. A client may rerun NTS key establishment after forced disassociation, but must rate-limit retries so the recovery path does not become another traffic loop. The negative signal also does not authorize silent downgrade to unprotected NTP.

NTS therefore strengthens provenance without changing the older conceptual split. The KoD remains a control response, not a time sample. Matching and authentication decide whether it may be processed; the code decides the bounded reaction.

A registry can stabilize meaning, not trust

RFC 5905 created IANA registries for Reference Identifier and KoD codes. RFC 9748 later changed the registration policy to Specification Required, constrained new code characters to uppercase letters and digits with right-side zero padding, and reserved X-prefixed values for private experimentation. Three designated experts are appointed, with two approvals required for a registry change.

This governance matters because four bytes are scarce and durable. A new code can outlive an implementation and shape how many independent clients alter their state. Expert review asks whether a stable public specification exists and whether the purpose is clear.

But registration stops at syntax and documented meaning. IANA does not observe the packet, judge the server's access policy, select a safe backoff for the client or guarantee that implementations discard the timestamps. Runtime legitimacy is assembled locally from request state, authentication when available, a recognized code and a bounded consequence.

The refusal was useful because it was incomplete

KoD's lasting design lesson is not that servers should be obeyed. It is that negative feedback becomes safer when its authority can be decomposed.

The server may say that access is denied or the request rate is excessive. It may not use that same packet as a clock sample. The client must prove the response is associated with its request. It then grants only the transition defined for the code and keeps control over limits, alternatives and recovery. Operators still need defenses when clients refuse to cooperate, and clients still need protection when apparent servers demand too much restraint.

The time packet that was not time turned silence into a usable message. Its achievement was bounded refusal: enough shared meaning to reduce harm, but not enough delegated authority to make one unauthenticated four-byte word sovereign over a client's clock and availability.

Sources and limits

The unused earlier field boundary comes from RFC 1305. The incident and first explicit SNTP KoD behavior are in RFC 4330. Code-specific actions and timestamp discard are specified by RFC 5905; operational bounds and abuse warnings by RFC 8633; NTS processing by RFC 8915; and registry governance by RFC 9748 and IANA. These sources do not measure 2026 deployment, compliance or attack frequency.