NTP Interleaved Modes
updates
- rfc-5905 — Network Time Protocol Version 4: Protocol and Algorithms Specification
Extracted elements (29)
A server may encode a flag in low-order sub-precision bits of receive and transmit timestamps to distinguish receive timestamps, allowing it to quickly skip the saved-timestamp search for requests in basic mode and avoid wasting resources.
Interleaved modes use implicit negotiation rather than a new extension field because RFC 5905 does not specify how servers handle unknown extension fields, and some existing implementations do not respond to requests with unknown extension fields, which would prevent reliable detection of interleaved mode support.
The alternative of responding with two packets per request was rejected because it would enable a traffic amplification attack, or would require asymmetric packet lengths causing asymmetric network delay and offset errors.
The server SHOULD ensure receive and transmit timestamps are unique in a sufficiently long interval; a duplicated receive timestamp could cause a basic-mode request to be misidentified as interleaved, producing a bogus response dropped by the client, or could produce a slightly inaccurate interleaved response comparable in error to a basic-mode transmit timestamp.
A client that does not support interleaved mode but accidentally sets the origin timestamp to the server's receive timestamp will still synchronize: it drops interleaved responses as bogus, and since the server MUST NOT respond twice to the same origin timestamp in interleaved mode, at least every other response will be in basic mode.
A peer using interleaved symmetric mode does NOT fully interoperate with a peer that does not support it; the mode must be explicitly configured per symmetric association.
An NTPv4 implementation supporting interleaved client/server and broadcast modes fully interoperates with NTPv4 implementations that do not support those modes; interleaved responses are rejected as bogus by non-supporting clients, which then proceed in basic mode.
A broadcast client supporting interleaved mode MUST check that the origin timestamp is non-zero to detect interleaved packets. It SHOULD also compare the origin timestamp with the previous packet's transmit timestamp to detect lost packets, and SHOULD NOT use the packet for synchronization if the difference exceeds a maximum (e.g., 1 second).
A client SHOULD limit the number of consecutive requests sent in interleaved mode between server responses to prevent processing of very old timestamps when many consecutive requests are lost.
A client SHOULD NOT update its NTP state when it receives an invalid response, so that timestamps needed to complete a measurement when a subsequent interleaved response arrives are not lost.
A server MUST NOT respond in interleaved mode unless: (1) the request does not have a receive timestamp equal to the transmit timestamp, and (2) the request's origin timestamp matches a saved local receive timestamp from a previous request.
A server supporting interleaved mode SHOULD discard old receive/transmit timestamp pairs to limit memory usage, for example via a fixed-length queue that drops old entries as new ones arrive.
An interleaved response MUST contain the transmit timestamp of the previous response whose receive timestamp matches the origin timestamp of the current request. The saved receive timestamp MUST NOT be reused to detect a subsequent interleaved request.
Both servers and clients that support interleaved mode MUST NOT send a packet whose transmit timestamp equals its receive timestamp, so that the mode can be reliably detected. One remedy is to increment the transmit timestamp by 1 unit (~0.25 ns) when equality occurs.
If a request does not conform to interleaved mode, the server MUST NOT respond in interleaved mode; if it responds, it MUST use the basic mode. In all cases, the server SHOULD save new receive and transmit timestamps for future interleaved responses.
Interleaved symmetric mode SHOULD be disabled by default and enabled only via explicit configuration of the active side of the association, because a peer using it does not fully interoperate with peers that do not support it.
Peer A MUST NOT send Peer B a packet in interleaved mode unless three conditions are all met: (1) an active configured association or prior interleaved receipt, (2) no packet sent since last valid receipt, and (3) the previous sent packet was the sole response to a received packet.
The server MAY separate saved timestamps by IP addresses but SHOULD NOT separate them by port numbers, to support clients that change ports between requests as recommended by RFC 9109.
Unlike basic client/server mode, clients using interleaved mode cannot set the origin timestamp to zero on each request to reset the NTP association, which eliminates a technique used to prevent tracking of clients as they move between networks.
In interleaved broadcast mode, each packet carries two transmit timestamps: the current transmission's timestamp in the transmit timestamp field and the previous packet's transmit timestamp in the origin timestamp field. The first broadcast packet uses a zero origin timestamp and is compatible with basic mode.
In interleaved client/server mode, a client request carries an origin timestamp equal to the receive timestamp from the last valid server response; the server response carries an origin timestamp equal to the client request's receive timestamp, and the transmit timestamp corresponds to the previous response (not the current one).
In interleaved symmetric mode, both peers must support the mode; Peer A MUST NOT send a packet in interleaved mode unless it has an active configured association or received a valid interleaved packet from Peer B, did not send a packet since the last valid reception, and the previous packet was the only response to a received packet.
The origin timestamp acts as a cookie to detect that a received packet is a response to the last packet sent. In the basic mode it echoes the transmit timestamp; in interleaved mode it echoes the receive timestamp.
Two timestamp sets are available to compute offset and delay in interleaved client/server mode. The first set (T1=prev-request-tx, T2=prev-response-rx, T3=latest-response-tx, T4=prev-response-rx) is RECOMMENDED for clients that filter on delay; the second set gives a more accurate current offset but is sensitive to frequency error.
Attackers can force the server to drop saved timestamps—by flooding with requests, spoofing source addresses, or replaying authenticated requests—preventing clients from receiving interleaved responses. Clients MUST NOT rely on servers to respond in the interleaved mode.
Clients and peers SHOULD NOT leak the receive timestamp in packets sent to other peers (e.g., as a reference timestamp) because off-path attackers could use it to craft a valid origin timestamp and inject a forged interleaved response.
Clients using interleaved mode SHOULD randomize all bits of receive and transmit timestamps in their requests (providing an effective precision of 2^32 seconds) to make it harder for off-path attackers to guess the origin timestamp used in the server response.
Protecting interleaved symmetric associations against replay attacks requires the NTP state to be protected at all times (not just around a single response), because completing a measurement requires two consecutive valid responses rather than one.
Client detection of response mode: if origin timestamp equals request's transmit timestamp, response is in basic mode; if origin timestamp equals request's receive timestamp, response is in interleaved mode; otherwise the response is bogus.