skip to content

What do the NTP kiss-o'-death codes DENY, RSTR and RATE tell a client, and why must the client validate one before obeying it?

level: middleimportance: nice to knowfreq 8%

answer

  1. stratum 0 with an ASCII code
  2. stop versus slow down
  3. not authenticated by default
  4. origin timestamp must match
  5. a poll ceiling near two hours

basics

~20 s

A kiss-o'-death is an NTP reply with stratum 0 and a four-letter code in the Reference ID. DENY and RSTR mean stop using this server; RATE means poll less often. It is usually unauthenticated, so clients obey one only if it matches an outstanding request.

solid answer

~50 s

RFC 5905 lets a server signal a client with a packet whose stratum is 0 and whose `Reference ID` holds a four-character ASCII **kiss code**. For `DENY` (access denied by the remote server) and `RSTR` (access denied by local policy) the client MUST demobilise its associations with that server and stop sending; for `RATE` it must back off. RFC 5905's wording says "reduce its polling interval", and RFC 8633 reads that as lengthening the interval, to no more than a poll value of 13, about two hours. Its timestamps must never be used, and codes beginning with `X` are ignored if unknown. The danger is that KoD packets are normally unauthenticated, so a forged `DENY` or `RATE` can starve a client of time. RFC 8633 therefore says a client MUST accept a KoD only with a valid origin timestamp, and must not blindly adopt a large poll value.

go deeper

for a junior

Recall that a kiss-o'-death is a stratum 0 reply with a four-letter code, and that DENY and RSTR mean stop while RATE means slow down.

for a middle

Explain where the code sits in the header, what each code requires of the client, and why its timestamps are ignored.

for a senior

Describe how forged kiss-o'-death packets deny service, and the client checks that limit it: origin timestamp, poll cap, Unique Identifier and several sources.

for a principal

Weigh relying on clients to honour RATE against enforcing rate limits outside NTP, for a server with many unmanaged clients.

## What a kiss-o'-death packet is NTP has no separate error message. Instead, RFC 5905 section 7.4 lets a server reuse an ordinary reply: when the **Stratum** field is 0, meaning *unspecified or invalid*, the 32-bit **Reference ID** carries a four-character ASCII string, left-justified and zero-filled, called a **kiss code**. The packet is a **kiss-o'-death (KoD)**, named after an early use: telling clients to stop sending packets that violate a server's access controls. Its receive and transmit timestamps are undefined, MUST NOT be relied on and MUST be discarded, so a KoD never sets the clock. ## The codes and what the client must do | Code | Meaning (RFC 5905 or RFC 8915) | Required client action | |---|---|---| | `DENY` | access denied by remote server | MUST demobilise associations to that server and stop sending | | `RSTR` | access denied due to local policy | same as `DENY` | | `RATE` | rate exceeded; access temporarily denied | MUST back off its polling to that server, and again on each further `RATE` | | `NTSN` | NTS negative acknowledgement (RFC 8915) | wait a poll, then renew keys and cookies through NTS-KE | | `X...` | unregistered, experimental | MUST be ignored if not recognised | | others, e.g. `AUTH`, `CRYP`, `INIT`, `STEP` | status reports | no protocol significance; discard after inspection | A wording trap sits in the `RATE` row. RFC 5905 says the client MUST "reduce its polling interval", while the intent, made explicit by RFC 8633, is to **increase the poll interval** and so reduce the polling *rate*. RFC 8633 caps the back-off: it should not exceed a poll value of 13, which is 2^13 = 8,192 seconds, the "two hours" the BCP quotes. ## Why a client must not trust one blindly KoD packets carry no authentication by default. A forged `DENY` makes a client drop a good server; a forged `RATE` advertising an enormous poll value makes it stop asking for hours or days. RFC 8633 warns that KoD packets can be used in denial-of-service attacks and notes that even a single `RATE` with a high poll value may be a sign the client is under attack. Its rules for clients: 1. **Accept a KoD only if its origin timestamp is valid**, matching the transmit timestamp of the client's outstanding request. An off-path forger cannot see that value, so its KoD is discarded. 2. **Back off to a reasonable maximum**, not exceeding poll value 13, and if the client uses the poll value in the `RATE` packet, it MUST NOT simply accept any value. 3. **With NTS**, once a server has sent authentic protected replies, the client must also check that any KoD echoes the Unique Identifier of an outstanding request (RFC 8915), and should wait for the next poll before reacting to `NTSN`. None of these stops an attacker **on** the path, who sees the request and can copy whatever it needs. What keeps a client in time then is having several servers, so losing one association to a forged KoD does not leave it without a source. ## The server side For a server operator, `RATE` is NTP's built-in rate-management tool and `DENY` or `RSTR` its way of turning away clients its access policy refuses. RFC 8633 recommends that all NTP devices respect KoD packets, especially embedded devices with no exposed configuration. It also warns that the mechanism relies on clients behaving well: some clients ignore `RATE` entirely, and badly written ones may even poll faster. Servers should be ready to drop packets from such clients with filtering outside NTP. ## Summary - KoD is a normal NTP packet with stratum 0 and a kiss code in the Reference ID. - `DENY` and `RSTR` mean stop; `RATE` means slow down; `NTSN` means renew NTS keys. - Its timestamps are never used for time. - It is unauthenticated, so clients validate the origin timestamp (and, under NTS, the Unique Identifier), cap the back-off, and keep several servers. - For operators, `RATE` is a request, not enforcement: clients that ignore it are handled by filtering outside NTP.

  • A client receives a RATE kiss-o'-death that advertises a poll value of 17; what should it do?
    Back off, but not to 17. RFC 8633 says a client accepting RATE should lengthen its poll interval to a reasonable maximum not exceeding poll value 13, about two hours, and MUST NOT simply accept any value the server sends. Poll 17 is 2^17 seconds, roughly 36 hours, long enough to take that source out of use for a day and a half.
  • Why does the origin-timestamp check stop some forged kiss-o'-death packets but not all?
    An off-path forger never sees the client's request, so it cannot copy the transmit timestamp into the origin field, and its KoD is discarded. An attacker on the path reads the request and copies the value. Because KoD packets are not authenticated, what protects the client from that attacker is having several independent servers.

saying these in an interview costs you the question

  • RATE tells the client to stop using the NTP server permanently.
  • A client must obey any kiss-o'-death arriving from the server's address.
  • Kiss-o'-death packets are signed, so they cannot be forged.
  • Kiss codes travel in a dedicated NTP message type of their own.
  • A kiss-o'-death packet's timestamps can still be used to set the clock.