Skip to content

Instantly share code, notes, and snippets.

@mlichvar

mlichvar/draft-ntp-interleaved-modes.diff

Created August 31, 2021 15:01
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mlichvar/39990dccb8256cb645eadfa8f03082ef to your computer and use it in GitHub Desktop.
Save mlichvar/39990dccb8256cb645eadfa8f03082ef to your computer and use it in GitHub Desktop.
Download ZIP
Raw
draft-ntp-interleaved-modes.diff
--- draft-ntp-interleaved-modes-06.txt 2021-08-31 16:57:06.663149949 +0200
+++ draft-ntp-interleaved-modes.txt 2021-08-31 16:56:53.181118901 +0200
@@ -61,13 +61,14 @@
2. Interleaved Client/server mode
3. Interleaved Symmetric mode
4. Interleaved Broadcast mode
- 5. Acknowledgements
- 6. IANA Considerations
- 7. Security Considerations
- 8. References
- 8.1. Normative References
- 8.2. Informative References
- 8.3. URIs
+ 5. Protocol Failures
+ 6. Security Considerations
+ 7. IANA Considerations
+ 8. Acknowledgements
+ 9. References
+ 9.1. Normative References
+ 9.2. Informative References
+ 9.3. URIs
Authors' Addresses
1. Introduction
@@ -84,8 +85,8 @@
have an error.
There are at least four options where a timestamp of an NTP packet
- may be captured with a software NTP implementation running on an
- operating system:
+ may be captured with a software NTP implementation running on a
+ general-purpose operating system:
1. User space (software)
@@ -125,32 +126,40 @@
This document describes an interleaved client/server, interleaved
symmetric, and interleaved broadcast mode. In these modes, the
- server sends a single packet, which contains a transmit timestamp
- corresponding to the previous packet that was sent to the client or
- peer. This transmit timestamp can be captured at any of the four
- places mentioned above. Both servers and clients/peers are required
- to keep some state specific to the interleaved mode.
-
- The protocol does not change the NTP packet header format, only the
- semantics of some timestamp fields. An NTPv4 implementation that
- supports the client/server and broadcast interleaved modes
- interoperates with NTPv4 implementations without this capability. A
- peer using the symmetric interleaved mode does not fully interoperate
- with a peer which does not support it. The mode needs to be
- configured specifically for each symmetric association.
-
- The negotiation in the protocol is implicit. The origin timestamp
- enables servers and peers to detect requests conforming to the
- interleaved mode. A response can be valid only in one mode. If a
- client or peer that does not support interleaved mode received a
- response conforming to the interleaved mode, it would be rejected as
- bogus. An explicit negotiation would require a new extension field,
- which would not work well with implementations that do not respond to
- requests with unknown extension fields.
+ server sends a packet which contains a transmit timestamp
+ corresponding to the transmission of the previous packet that was
+ sent to the client or peer. This transmit timestamp can be captured
+ in any software or hardware component involved in the transmission of
+ the packet. Both servers and clients/peers are required to keep some
+ state specific to the interleaved mode.
+
+ An NTPv4 implementation that supports the client/server and broadcast
+ interleaved modes interoperates with NTPv4 implementations without
+ this capability. A peer using the symmetric interleaved mode does
+ not fully interoperate with a peer which does not support it. The
+ mode needs to be configured specifically for each symmetric
+ association.
+
+ The interleaved modes do not change the NTP packet header format and
+ do not use new extension fields. The negotiation is implicit. The
+ protocol is extended with new values that can be assigned to the
+ origin and transmit timestamp. Servers and peers check the origin
+ timestamp to detect requests conforming to the interleaved mode. A
+ response can be valid only in one mode. If a client or peer that
+ does not support interleaved mode received a response conforming to
+ the interleaved mode, it would be rejected as bogus.
+
+ An explicit negotiation would require a new extension field. RFC
+ 5905 does not specify how servers should handle requests with an
+ unknown extension field. The original use of extension fields was
+ authentication with Autokey [RFC5906], which cannot be negotiated.
+ Some existing implementations do not respond to requests with unknown
+ extension fields. This behavior would prevent clients from reliably
+ detecting support for the interleaved mode.
Requests and responses cannot always be formed in interleaved mode.
- Servers, clients, and peers are required to support both interleaved
- and basic modes.
+ It cannot be used exclusively. Servers, clients, and peers that
+ support the interleaved mode need to support also the basic mode.
This document assumes familiarity with RFC 5905.
@@ -165,8 +174,8 @@
2. Interleaved Client/server mode
The interleaved client/server mode is similar to the basic client/
- server mode. The only difference between the two modes is in the
- meaning of the transmit and origin timestamp fields.
+ server mode. The difference between the two modes is in the values
+ saved to the origin and transmit timestamp fields.
The origin timestamp is a cookie which is used to detect that a
received packet is a response to the last packet sent in the other
@@ -177,17 +186,20 @@
origin timestamp is called bogus.
A client request in the basic mode has an origin timestamp equal to
- the transmit timestamp from the previous server response, or is zero.
- A server response in the basic mode has an origin timestamp equal to
- the transmit timestamp from the client's request. The transmit
- timestamps correspond to the packets in which they are included.
+ the transmit timestamp from the last valid server response, or is
+ zero (which indicates the first request of the association). A
+ server response in the basic mode has an origin timestamp equal to
+ the transmit timestamp from the client request. The transmit
+ timestamp in the response corresponds to the transmission of the
+ response in which the timestamp is contained.
A client request in the interleaved mode has an origin timestamp
- equal to the receive timestamp from the previous server response. A
- server response in the interleaved mode has an origin timestamp equal
- to the receive timestamp from the client's request. The transmit
- timestamps correspond to the previous packets that were sent to the
- server or client.
+ equal to the receive timestamp from the last valid server response.
+ A server response in the interleaved mode has an origin timestamp
+ equal to the receive timestamp from the client request. The transmit
+ timestamp in the response corresponds to the transmission of the
+ previous response which had the receive timestamp equal to the origin
+ timestamp from the request.
A server which supports the interleaved mode needs to save pairs of
local receive and transmit timestamps. The server SHOULD discard old
@@ -195,7 +207,7 @@
using the interleaved mode. The server MAY separate the timestamps
by IP addresses, but it SHOULD NOT separate them by port numbers to
support clients that change their port between requests, as
- recommended by [I-D.ietf-ntp-port-randomization].
+ recommended in RFC 9109 [RFC9109].
The server MAY restrict the interleaved mode to specific IP addresses
and/or authenticated clients.
@@ -213,7 +225,7 @@
the same origin timestamp and the server responding in the
interleaved mode with an incorrect transmit timestamp. If the
timestamps are not guaranteed to be monotonically increasing, the
- server SHOULD check that the transmit and receive timestamp is not
+ server SHOULD check that the transmit and receive timestamps are not
already saved as a receive timestamp of a previous request (from the
same IP address if the server separates timestamps by addresses), and
generate a new timestamp if necessary.
@@ -303,7 +315,7 @@
mode.
The client SHOULD NOT update its NTP state when an invalid response
- is received to not lose the timestamps which will be needed to
+ is received, to not lose the timestamps which will be needed to
complete a measurement when the subsequent response in the
interleaved mode is received.
@@ -349,24 +361,30 @@
Such an optimization will delay the first interleaved response of the
server to a client by one exchange.
- A check for a non-zero origin timestamp works with clients that
- implement NTP data minimization [I-D.ietf-ntp-data-minimization]. To
- detect requests in the basic mode from clients that do not implement
- the data minimization, the server can encode in low-order bits of the
- receive and transmit timestamps below precision of the clock a bit
- indicating whether the timestamp is a receive timestamp. If the
- server receives a request with a non-zero origin timestamp which does
- not indicate it is a receive timestamp of the server, the request is
- in the basic mode and it is not necessary to save the new receive and
- transmit timestamp.
+ A check for a non-zero origin timestamp works with SNTP clients that
+ always set the timestamp to zero and clients that implement NTP data
+ minimization [I-D.ietf-ntp-data-minimization]. From the server's
+ point of view, such clients start a new association with each
+ request.
+
+ To avoid searching the saved receive timestamps for non-zero origin
+ timestamps from requests conforming to the basic mode, the server can
+ encode in low-order bits of the receive and transmit timestamps below
+ precision of the clock a flag indicating whether the timestamp is a
+ receive timestamp. If the server receives a request with a non-zero
+ origin timestamp which does not indicate it is a receive timestamp of
+ the server, the request does not conform to the interleaved mode and
+ it is not necessary to perform the search and/or save the new receive
+ and transmit timestamp.
3. Interleaved Symmetric mode
The interleaved symmetric mode uses the same principles as the
interleaved client/server mode. A packet in the interleaved
symmetric mode has a transmit timestamp which corresponds to the
- previous packet sent to the peer and an origin timestamp equal to the
- receive timestamp from the last packet received from the peer.
+ transmission of the previous packet sent to the peer and an origin
+ timestamp equal to the receive timestamp from the last packet
+ received from the peer.
To enable synchronization in both directions of a symmetric
association, both peers need to support the interleaved mode. For
@@ -401,13 +419,20 @@
3. The previous packet that the peer A sent to the peer B was the
only response to a packet received from the peer B.
+ The first condition is needed for compatibility with implementations
+ that do not support or are not configured for the interleaved mode.
+ The other conditions prevent a missing response from causing a
+ mismatch between the remote transmit (T2) and local receive timestamp
+ (T3), which would cause a large error in the measured offset and
+ delay.
+
An example of packets exchanged in a symmetric association is shown
in Figure 2. The minimum polling interval of the peer A is twice as
long as the maximum polling interval of the peer B. The first
packets sent by the peers are in the basic mode. The second and
third packet sent by the peer A is in the interleaved mode. The
second packet sent by the peer B is in the interleaved mode, but the
- following packets sent by the peer are in the basic mode, because
+ following packets sent by the peer B are in the basic mode, because
multiple responses are sent per request.
Peer A t2 t3 t6 t8 t9 t12 t14 t15
@@ -475,32 +500,83 @@
mode. The client SHOULD also compare the origin timestamp with the
transmit timestamp from the previous packet to detect lost packets.
If the difference is larger than a specified maximum (e.g. 1 second),
- the packet SHOULD NOT be used for synchronization.
+ the packet SHOULD NOT be used for synchronization in the interleaved
+ mode.
The client SHOULD compute the offset using the origin timestamp from
the received packet and the local receive timestamp of the previous
packet. If the client needs to measure the network delay, it SHOULD
use the interleaved client/server mode.
-5. Acknowledgements
-
- The interleaved modes described in this document are based on the
- implementation written by David Mills in the NTP project [1]. The
- specification of the broadcast mode is based purely on this
- implementation. The specification of the symmetric mode has some
- modifications. The client/server mode is specified as a new mode
- compatible with the symmetric mode, similarly to the basic symmetric
- and client/server modes.
-
- The authors would like to thank Theresa Enghardt, Daniel Franke, Erik
- Kline, Tal Mizrahi, Steven Sommars, Harlan Stenn, and Kristof Teichel
- for their useful comments.
+5. Protocol Failures
-6. IANA Considerations
+ An incorrect client implementation of the basic mode (RFC 5905) can
+ work reliably with servers that implement only the basic mode, but
+ the protocol can fail intermittently with servers that implement the
+ interleaved mode.
- This memo includes no request to IANA.
+ If the client sets the origin timestamp to other values than the
+ transmit timestamp from the last valid server response, or zero, the
+ origin timestamp can match a receive timestamp of a previous server
+ response (possibly to a different client), causing an unexpected
+ interleaved response. The client is expected to drop the response as
+ bogus. If it did not check for bogus packets, it would be vulnerable
+ to off-path attacks.
+
+ If the client set the origin timestamp to a constant non-zero value,
+ this mismatch would be expected to happen once per the NTP era (about
+ 136 years) if the NTP server was responding at the maximum rate
+ needed to go through all timestamp values (about 2 billion responses
+ per second). With lower rates of requests the chance of hitting a
+ server timestamp decreases proportionally.
+
+ The worst case of this failure would be a client that specifically
+ sets the origin timestamp to the server's receive timestamp, i.e. the
+ client accidentally implemented the interleaved mode, but it does not
+ accept interleaved responses. This client would still be able to
+ synchronize its clock. It would drop interleaved responses as bogus
+ and set the origin timestamp to the receive timestamp from the last
+ valid response in the basic mode. As servers are required to not
+ respond twice to the same origin timestamp in the interleaved mode,
+ at least every other response would be in the basic mode and accepted
+ by the client.
+
+ Intermittent protocol failures can be caused also by an incorrect
+ server implementation of the interleaved mode. A server which does
+ not ensure the receive and transmit timestamps in its responses are
+ unique in a sufficiently long interval can misinterpret requests
+ formed correctly in the basic mode as interleaved and respond in the
+ interleaved mode. The response would be dropped by the client as
+ bogus.
+
+ A duplicated server receive timestamp can cause an expected
+ interleaved response to contain a transmit timestamp which does not
+ correspond to the transmission of the previous response from which
+ the client copied the receive timestamp to the origin timestamp in
+ the request, but a different response which contained the same
+ receive timestamp. The response would be accepted by the client with
+ a small error in the transmit timestamp equal to the difference
+ between the transmit timestamps of the two different responses. As
+ the two requests to which the responses responded were received at
+ the same time (according to the server's clock), the two
+ transmissions would be expected to be close to each other and the
+ difference between them would be comparable to the error a basic
+ response normally has in its transmit timestamp.
+
+ One reason for a duplicated server timestamp can be a large backward
+ step of the server's clock. If the timestamps the server has saved
+ do not fully cover the second pass of the clock over the repeated
+ interval, two requests received in different passes of the clock can
+ get the same receive timestamp. The client which made the first
+ request can get the transmit timestamp corresponding to the
+ transmission of the second response. From the server's point of
+ view, the error of the transmit timestamp would be still small, but
+ from the client's point of view the server already failed when it
+ made the step as it was serving wrong time before or after the step
+ with a much larger error than the error caused by the protocol
+ failure.
-7. Security Considerations
+6. Security Considerations
The security considerations of time protocols in general are
discussed in RFC 7384 [RFC7384], and specifically the security
@@ -519,9 +595,12 @@
receive and transmit timestamps, as recommended for the transmit
timestamp in the NTP client data minimization
[I-D.ietf-ntp-data-minimization], to make it more difficult for off-
- path attackers to guess the origin timestamp. It is not possible to
- zero the origin timestamp to prevent passive observers from easily
- tracking clients moving between different networks.
+ path attackers to guess the origin timestamp in the server response.
+
+ The client data minimization cannot be fully implemented in the
+ interleaved mode. The origin timestamp cannot be zeroed out, which
+ makes the clients more vulnerable to tracking as they move between
+ networks.
Attackers can force the server to drop its timestamps in order to
prevent clients from getting an interleaved response. They can send
@@ -531,16 +610,39 @@
on servers to be able to respond in the interleaved mode.
Protecting symmetric associations in the interleaved mode against
- replay attacks is even more difficult than in the basic mode. The
- NTP state needs to be protected not only between the reception and
- transmission in order to send the peer a packet with a valid origin
- timestamp, but all the time to not lose the timestamps which will be
- needed to complete a measurement when the following packet in the
- interleaved mode is received.
+ replay attacks is even more difficult than in the basic mode. In
+ both modes, the NTP state needs to be protected between the reception
+ of the last non-replayed response and transmission of the next
+ request in order for the request to contain the origin timestamp
+ expected by the peer. The difference is in the timestamps needed to
+ complete a measurement. In the basic mode only one valid response is
+ needed at a time and it is used as soon as it is received, but the
+ interleaved mode needs two consecutive valid responses. The NTP
+ state needs to be protected all the time to not lose the timestamps
+ which are needed to complete the measurement when the second response
+ is received.
-8. References
+7. IANA Considerations
-8.1. Normative References
+ This memo includes no request to IANA.
+
+8. Acknowledgements
+
+ The interleaved modes described in this document are based on the
+ implementation written by David Mills in the NTP project [1]. The
+ specification of the broadcast mode is based purely on this
+ implementation. The specification of the symmetric mode has some
+ modifications. The client/server mode is specified as a new mode
+ compatible with the symmetric mode, similarly to the basic symmetric
+ and client/server modes.
+
+ The authors would like to thank Theresa Enghardt, Daniel Franke, Erik
+ Kline, Tal Mizrahi, Steven Sommars, Harlan Stenn, and Kristof Teichel
+ for their useful comments.
+
+9. References
+
+9.1. Normative References
[I-D.ietf-ntp-data-minimization]
Franke, D. F. and A. Malhotra, "NTP Client Data
@@ -561,22 +663,27 @@
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
-8.2. Informative References
+9.2. Informative References
- [I-D.ietf-ntp-port-randomization]
- Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol
- Version 4: Port Randomization", draft-ietf-ntp-port-
- randomization-08 (work in progress), June 2021.
+ [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol
+ Version 4: Autokey Specification", RFC 5906,
+ DOI 10.17487/RFC5906, June 2010,
+ <https://www.rfc-editor.org/info/rfc5906>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
+ [RFC9109] Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol
+ Version 4: Port Randomization", RFC 9109,
+ DOI 10.17487/RFC9109, August 2021,
+ <https://www.rfc-editor.org/info/rfc9109>.
+
[SECNTP] Malhotra, A., Gundy, M., Varia, M., Kennedy, H., Gardner,
J., and S. Goldberg, "The Security of NTP's Datagram
Protocol", 2016, <http://eprint.iacr.org/2016/1006>.
-8.3. URIs
+9.3. URIs
[1] http://www.ntp.org
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment