rfc9769v1.txt   rfc9769.txt 
Internet Engineering Task Force (IETF) M. Lichvar Internet Engineering Task Force (IETF) M. Lichvar
Request for Comments: 9769 Red Hat Request for Comments: 9769 Red Hat
Updates: 5905 A. Malhotra Updates: 5905 A. Malhotra
Category: Standards Track Boston University Category: Standards Track Boston University
ISSN: 2070-1721 April 2025 ISSN: 2070-1721 May 2025
NTP Interleaved Modes NTP Interleaved Modes
Abstract Abstract
This document specifies interleaved modes for the Network Time This document specifies interleaved modes for the Network Time
Protocol (NTP). These new modes improve the accuracy of time Protocol (NTP). These new modes improve the accuracy of time
synchronization by enabling the use of more accurate transmit synchronization by enabling the use of more accurate transmit
timestamps that are available only after the transmission of NTP timestamps that are available only after the transmission of NTP
messages. These enhancements are intended to improve timekeeping in messages. These enhancements are intended to improve timekeeping in
skipping to change at line 78 skipping to change at line 78
server mode, symmetric mode, and broadcast mode. The transmit and server mode, symmetric mode, and broadcast mode. The transmit and
receive timestamps are two of the four timestamps included in every receive timestamps are two of the four timestamps included in every
NTPv4 packet used for time synchronization. NTPv4 packet used for time synchronization.
For a highly accurate and stable synchronization, the transmit and For a highly accurate and stable synchronization, the transmit and
receive timestamps should be captured close to the beginning of the receive timestamps should be captured close to the beginning of the
actual transmission and the end of the reception, respectively. An actual transmission and the end of the reception, respectively. An
asymmetry in the timestamping causes the offset measured by NTP to asymmetry in the timestamping causes the offset measured by NTP to
have an error. have an error.
There are at least four options where a timestamp of an NTP packet Four options where a timestamp of an NTP packet may be captured with
may be captured with a software NTP implementation running on a a software NTP implementation running on a general-purpose operating
general-purpose operating system: system are as follows:
1. User space (software) 1. User space (software)
2. Network device driver or kernel (software) 2. Network device driver or kernel (software)
3. Data link layer (hardware - MAC chip) 3. Data link layer (hardware - MAC chip)
4. Physical layer (hardware - PHY chip) 4. Physical layer (hardware - PHY chip)
Software timestamps captured in the user space in the NTP Software timestamps captured in the user space in the NTP
skipping to change at line 128 skipping to change at line 128
This document describes an interleaved client/server mode, This document describes an interleaved client/server mode,
interleaved symmetric mode, and interleaved broadcast mode. In these interleaved symmetric mode, and interleaved broadcast mode. In these
modes, the server sends a packet that contains a transmit timestamp modes, the server sends a packet that contains a transmit timestamp
corresponding to the transmission of the previous packet that was corresponding to the transmission of the previous packet that was
sent to the client or peer. This transmit timestamp can be captured sent to the client or peer. This transmit timestamp can be captured
in any software or hardware component involved in the transmission of in any software or hardware component involved in the transmission of
the packet. Both servers and clients/peers are required to keep some the packet. Both servers and clients/peers are required to keep some
state specific to the interleaved mode. state specific to the interleaved mode.
An NTPv4 implementation that supports the client/server and broadcast An NTPv4 implementation that supports the interleaved client/server
interleaved modes interoperates with NTPv4 implementations without and interleaved broadcast modes interoperates with NTPv4
this capability. A peer using the symmetric interleaved mode does implementations without this capability. A peer using the
not fully interoperate with a peer that does not support it. The interleaved symmetric mode does not fully interoperate with a peer
mode needs to be configured specifically for each symmetric that does not support it. The mode needs to be configured
association. specifically for each symmetric association.
The interleaved modes do not change the NTP packet header format and The interleaved modes do not change the NTP packet header format and
do not use new extension fields. The negotiation is implicit. The do not use new extension fields. The negotiation is implicit. The
protocol is extended with new values that can be assigned to the protocol is extended with new values that can be assigned to the
origin and transmit timestamps. Servers and peers check the origin origin and transmit timestamps. Servers and peers check the origin
timestamp to detect requests conforming to the interleaved mode. A timestamp to detect requests conforming to the interleaved mode. A
response can only be valid in one mode. If a client or peer that response can only be valid in one mode. If a client or peer that
does not support the interleaved mode received a response conforming does not support the interleaved mode received a response conforming
to the interleaved mode, it would be rejected as bogus. to the interleaved mode, it would be rejected as bogus.
skipping to change at line 283 skipping to change at line 283
interleaved modes are indicated with B and I, respectively. The interleaved modes are indicated with B and I, respectively. The
timestamps t1~, t3~, and t11~ point to the same transmissions as t1, timestamps t1~, t3~, and t11~ point to the same transmissions as t1,
t3, and t11, but they may be less accurate. The first exchange is in t3, and t11, but they may be less accurate. The first exchange is in
the basic mode followed by a second exchange in the interleaved mode. the basic mode followed by a second exchange in the interleaved mode.
For the third exchange, the client request is in the interleaved For the third exchange, the client request is in the interleaved
mode, but the server response is in the basic mode, because the mode, but the server response is in the basic mode, because the
server did not have the pair of timestamps t6 and t7 (e.g., they were server did not have the pair of timestamps t6 and t7 (e.g., they were
dropped to save timestamps for other clients using the interleaved dropped to save timestamps for other clients using the interleaved
mode). mode).
Server t2 t3 t6 t7 t10 t11 t2 t3 t6 t7 t10 t11
-----+----+----------------+----+----------------+----+----- Server -----+----+----------------+----+----------------+----+-----
/ \ / \ / \ / \ / \ / \
Client / \ / \ / \ / \ / \ / \
--+----------+----------+----------+----------+----------+-- Client --+----------+----------+----------+----------+----------+--
t1 t4 t5 t8 t9 t12 t1 t4 t5 t8 t9 t12
Mode: B B I I I B Mode B B I I I B
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Org | 0 | | t1~| | t2 | | t4 | | t6 | | t5 | Origin | 0 | | t1~| | t2 | | t4 | | t6 | | t5 |
Rx | 0 | | t2 | | t4 | | t6 | | t8 | |t10 | Rx | 0 | | t2 | | t4 | | t6 | | t8 | |t10 |
Tx | t1~| | t3~| | t1 | | t3 | | t5 | |t11~| Tx | t1~| | t3~| | t1 | | t3 | | t5 | |t11~|
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 1: Packet Timestamps in Interleaved Client/Server Mode Figure 1: Packet Timestamps in Interleaved Client/Server Mode
When the client receives a response from the server, it performs the When the client receives a response from the server, it performs the
tests described in RFC 5905 [RFC5905]. Two of the tests are modified tests described in RFC 5905 [RFC5905]. Two of the tests are modified
for the interleaved mode: for the interleaved mode:
1. The check for duplicate packets compares both receive and 1. The check for duplicate packets compares both receive and
transmit timestamps in order to not drop a valid response in the transmit timestamps in order to not drop a valid response in the
interleaved mode if it follows a response in the basic mode and interleaved mode if it follows a response in the basic mode and
skipping to change at line 389 skipping to change at line 389
symmetric mode has a transmit timestamp that corresponds to the symmetric mode has a transmit timestamp that corresponds to the
transmission of the previous packet sent to the peer and an origin transmission of the previous packet sent to the peer and an origin
timestamp equal to the receive timestamp from the last packet timestamp equal to the receive timestamp from the last packet
received from the peer. received from the peer.
To enable synchronization in both directions of a symmetric To enable synchronization in both directions of a symmetric
association, both peers need to support the interleaved mode. For association, both peers need to support the interleaved mode. For
this reason, it SHOULD be disabled by default and enabled with an this reason, it SHOULD be disabled by default and enabled with an
option in the configuration of the active side of the association. option in the configuration of the active side of the association.
In order to prevent the peer from matching the transmit timestamp In order to prevent a peer from matching transmit timestamps with
with an incorrect packet when the peers' transmissions do not incorrect packets when its transmissions do not alternate with
alternate (e.g., they use different polling intervals) and a previous transmissions of its peer (e.g., they use different polling
packet was lost, the use of the interleaved mode in symmetric intervals) and one or more previous packets were lost, the use of the
associations requires additional restrictions. interleaved mode in symmetric associations requires additional
restrictions.
Peers that have an association need to count valid packets received Peers that have an association need to count valid packets received
between their transmissions to determine in which mode a packet between their transmissions to determine in which mode a packet
should be formed. A valid packet in this context is a packet that should be formed. A valid packet in this context is a packet that
passed all NTP tests for duplicate, replayed, bogus, and passed all NTP tests for duplicate, replayed, bogus, and
unauthenticated packets. Other received packets may update the NTP unauthenticated packets. Other received packets may update the NTP
state to allow the (re)initialization of the association, but they do state to allow the (re)initialization of the association, but they do
not change the selection of the mode. not change the selection of the mode.
A Peer A MUST NOT send a Peer B a packet in the interleaved mode A Peer A MUST NOT send a Peer B a packet in the interleaved mode
skipping to change at line 432 skipping to change at line 433
An example of packets exchanged in a symmetric association is shown An example of packets exchanged in a symmetric association is shown
in Figure 2. The minimum polling interval of Peer A is twice as long in Figure 2. The minimum polling interval of Peer A is twice as long
as the maximum polling interval of Peer B. The first packet sent by as the maximum polling interval of Peer B. The first packet sent by
each peer is in the basic mode. The second and third packets sent by each peer is in the basic mode. The second and third packets sent by
Peer A are in the interleaved mode. The second packet sent by Peer B Peer A are in the interleaved mode. The second packet sent by Peer B
is in the interleaved mode, but subsequent packets sent by Peer B are is in the interleaved mode, but subsequent packets sent by Peer B are
in the basic mode, because multiple responses are sent for each in the basic mode, because multiple responses are sent for each
request. request.
Peer A t2 t3 t6 t8 t9 t12 t14 t15 t2 t3 t6 t8 t9 t12 t14 t15
-----+--+--------+-----------+--+--------+-----------+--+----- Peer A -----+--+--------+-----------+--+--------+-----------+--+----
/ \ / / \ / / \ / \ / / \ / / \
Peer B / \ / / \ / / \ / \ / / \ / / \
--+--------+--+-----------+--------+--+-----------+--------+-- Peer B --+--------+--+-----------+--------+--+-----------+--------+-
t1 t4 t5 t7 t10 t11 t13 t16 t1 t4 t5 t7 t10 t11 t13 t16
Mode: B B I B I B B I Mode B B I B I B B I
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Org | 0 | | t1~| | t2 | | t3~| | t4 | | t3 | | t3 | |t10 | Origin | 0 | | t1~| | t2 | | t3~| | t4 | | t3 | | t3 | |t10 |
Rx | 0 | | t2 | | t4 | | t4 | | t8 | |t10 | |t10 | |t14 | Rx | 0 | | t2 | | t4 | | t4 | | t8 | |t10 | |t10 | |t14 |
Tx | t1~| | t3~| | t1 | | t7~| | t3 | |t11~| |t13~| | t9 | Tx | t1~| | t3~| | t1 | | t7~| | t3 | |t11~| |t13~| | t9 |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 2: Packet Timestamps in Interleaved Symmetric Mode Figure 2: Packet Timestamps in Interleaved Symmetric Mode
If Peer A has no association with Peer B and it responds with If Peer A has no association with Peer B and it responds with
symmetric passive packets, it does not need to count the packets in symmetric passive packets, it does not need to count the packets in
order to meet the restrictions, because each request has at most one order to meet the restrictions, because each request has at most one
response. The processing of the requests can be implemented in the response. The processing of the requests can be implemented in the
same way as a server handling requests in the interleaved client/ same way as a server handling requests in the interleaved client/
server mode. server mode.
skipping to change at line 471 skipping to change at line 472
A packet in the interleaved broadcast mode contains two transmit A packet in the interleaved broadcast mode contains two transmit
timestamps. One corresponds to the packet itself and is saved in the timestamps. One corresponds to the packet itself and is saved in the
transmit timestamp field. The other corresponds to the previous transmit timestamp field. The other corresponds to the previous
packet and is saved in the origin timestamp field. The packet is packet and is saved in the origin timestamp field. The packet is
compatible with the basic mode, which uses a zero origin timestamp. compatible with the basic mode, which uses a zero origin timestamp.
An example of packets sent in the broadcast mode is shown in An example of packets sent in the broadcast mode is shown in
Figure 3. Figure 3.
Server t1 t3 t5 t7 t1 t3 t5 t7
------+------------+------------+------------+--------- Server ------+------------+------------+------------+---------
\ \ \ \ \ \ \ \
Client \ \ \ \ \ \ \ \
---------+------------+------------+------------+------ Client ---------+------------+------------+------------+------
t2 t4 t6 t8 t2 t4 t6 t8
Mode: B I I I Mode B I I I
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Org | 0 | | t1 | | t3 | | t5 | Origin | 0 | | t1 | | t3 | | t5 |
Rx | 0 | | 0 | | 0 | | 0 | Rx | 0 | | 0 | | 0 | | 0 |
Tx | t1~| | t3~| | t5~| | t7~| Tx | t1~| | t3~| | t5~| | t7~|
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 3: Packet Timestamps in Interleaved Broadcast Mode Figure 3: Packet Timestamps in Interleaved Broadcast Mode
A client that does not support the interleaved mode ignores the A client that does not support the interleaved mode ignores the
origin timestamp and processes all packets as if they were in the origin timestamp and processes all packets as if they were in the
basic mode. basic mode.
skipping to change at line 552 skipping to change at line 553
mode as interleaved and respond in the interleaved mode. The mode as interleaved and respond in the interleaved mode. The
response would be dropped by the client as bogus. response would be dropped by the client as bogus.
A duplicated server receive timestamp can cause an expected A duplicated server receive timestamp can cause an expected
interleaved response to contain a transmit timestamp that does not interleaved response to contain a transmit timestamp that does not
correspond to the transmission of the previous response from which correspond to the transmission of the previous response from which
the client copied the receive timestamp to the origin timestamp in the client copied the receive timestamp to the origin timestamp in
the request, but a different response that contained the same receive the request, but a different response that contained the same receive
timestamp. The response would be accepted by the client with a small timestamp. The response would be accepted by the client with a small
error in the transmit timestamp equal to the difference between the error in the transmit timestamp equal to the difference between the
transmit timestamps of the two different responses. As the two transmit timestamps of the two different responses. As the requests
requests to which the responses responded were received at the same corresponding to the two different responses were received at the
time (according to the server's clock), the two transmissions would same time (according to the server's clock), the two transmissions
be expected to be close to each other and the difference between them would be expected to be close to each other and the difference
would be comparable to the error a basic response normally has in its between them would be comparable to the error a basic response
transmit timestamp. normally has in its transmit timestamp.
6. Security Considerations 6. Security Considerations
The security considerations for time protocols in general are The security considerations for time protocols in general are
discussed in RFC 7384 [RFC7384]. Security considerations specific to discussed in RFC 7384 [RFC7384]. Security considerations specific to
NTP are discussed in RFC 5905 [RFC5905]. NTP are discussed in RFC 5905 [RFC5905].
Security issues that apply to the basic modes also apply to the Security issues that apply to the basic modes discussed in RFC 5905
interleaved modes. They are described in "The Security of NTP's [RFC5905] also apply to the interleaved modes. These issues are
Datagram Protocol" [SECNTP]. described in "The Security of NTP's Datagram Protocol" [SECNTP].
Clients and peers SHOULD NOT leak the receive timestamp in packets Clients and peers SHOULD NOT leak the receive timestamp in packets
sent to other peers or clients (e.g., as a reference timestamp) to sent to other peers or clients (e.g., as a reference timestamp) to
prevent off-path attackers from easily getting the origin timestamp prevent off-path attackers from easily getting the origin timestamp
needed to make a valid response in the interleaved mode. needed to make a valid response in the interleaved mode.
Clients using the interleaved mode SHOULD randomize all bits of Clients using the interleaved mode SHOULD randomize all bits of
receive and transmit timestamps in their requests (i.e., use a receive and transmit timestamps in their requests (i.e., provide a
precision of 32) to make it more difficult for off-path attackers to precision of 2^32 seconds) to make it more difficult for off-path
guess the origin timestamp in the server response. attackers to guess the origin timestamp in the server response.
Unlike in the basic client/server mode, clients using the interleaved Unlike in the basic client/server mode, clients using the interleaved
mode cannot set the origin timestamp in their requests to zero (i.e., mode cannot set the origin timestamp in their requests to zero (i.e.,
reset the NTP association with every request) to make it more reset the NTP association with every request) to make it more
difficult to track them as they move between networks. difficult to track them as they move between networks.
Attackers can force the server to drop its timestamps in order to Attackers can force the server to drop its timestamps in order to
prevent clients from getting an interleaved response. They can send prevent clients from getting an interleaved response. They can send
a large number of requests, send requests with a spoofed source a large number of requests, send requests with a spoofed source
address, or replay an authenticated request if the interleaved mode address, or replay an authenticated request if the interleaved mode
skipping to change at line 654 skipping to change at line 655
Datagram Protocol", Cryptology ePrint Archive, Paper Datagram Protocol", Cryptology ePrint Archive, Paper
2016/1006, 2016, <https://eprint.iacr.org/2016/1006>. 2016/1006, 2016, <https://eprint.iacr.org/2016/1006>.
Acknowledgements Acknowledgements
The interleaved modes described in this document are based on the The interleaved modes described in this document are based on the
implementation written by David Mills in the NTP project implementation written by David Mills in the NTP project
(https://www.ntp.org). The specification of the broadcast mode is (https://www.ntp.org). The specification of the broadcast mode is
based purely on this implementation. The specification of the based purely on this implementation. The specification of the
symmetric mode has some modifications. The client/server mode is symmetric mode has some modifications. The client/server mode is
specified as a new mode compatible with the symmetric mode, similarly specified as a new mode compatible with the symmetric mode. It is a
to the basic symmetric and client/server modes. simplified special case of the symmetric mode, analogously to how the
basic client/server mode is a special case of the basic symmetric
mode.
The authors would like to thank Doug Arnold, Roman Danyliw, Reese The authors would like to thank Doug Arnold, Roman Danyliw, Reese
Enghardt, Daniel Franke, Benjamin Kaduk, Erik Kline, Catherine Enghardt, Daniel Franke, Benjamin Kaduk, Erik Kline, Catherine
Meadows, Tal Mizrahi, Steven Sommars, Harlan Stenn, Kristof Teichel, Meadows, Tal Mizrahi, Steven Sommars, Harlan Stenn, Kristof Teichel,
and Gunter Van de Velde for their useful comments and suggestions. and Gunter Van de Velde for their useful comments and suggestions.
Authors' Addresses Authors' Addresses
Miroslav Lichvar Miroslav Lichvar
Red Hat Red Hat
 End of changes. 16 change blocks. 
59 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.48.