Skip to content

Instantly share code, notes, and snippets.

@mlichvar

mlichvar/draft-ntp-interleaved-modes.txt

Created August 31, 2021 15:02
Show Gist options
  • Save mlichvar/5583a78623a6a1129512c0bb89c99c3b to your computer and use it in GitHub Desktop.
Save mlichvar/5583a78623a6a1129512c0bb89c99c3b to your computer and use it in GitHub Desktop.
Download ZIP
Raw
draft-ntp-interleaved-modes.txt
Internet Engineering Task Force M. Lichvar
Internet-Draft Red Hat
Updates: 5905 (if approved) A. Malhotra
Intended status: Standards Track Boston University
Expires: January 2, 2022 Jul 1, 2021
NTP Interleaved Modes
draft-ietf-ntp-interleaved-modes-06
Abstract
This document extends the specification of Network Time Protocol
(NTP) version 4 in RFC 5905 with special modes called the NTP
interleaved modes, that enable NTP servers to provide their clients
and peers with more accurate transmit timestamps that are available
only after transmitting NTP packets. More specifically, this
document describes three modes: interleaved client/server,
interleaved symmetric, and interleaved broadcast.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
1.1. Requirements Language
2. Interleaved Client/server mode
3. Interleaved Symmetric mode
4. Interleaved Broadcast mode
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
RFC 5905 [RFC5905] describes the operations of NTPv4 in a client/
server, symmetric, and broadcast mode. The transmit and receive
timestamps are two of the four timestamps included in every NTPv4
packet used for time synchronization.
For a highly accurate and stable synchronization, the transmit and
receive timestamp should be captured close to the beginning of the
actual transmission and the end of the reception respectively. An
asymmetry in the timestamping causes the offset measured by NTP to
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 a
general-purpose operating system:
1. User space (software)
2. Network device driver or kernel (software)
3. Data link layer (hardware - MAC chip)
4. Physical layer (hardware - PHY chip)
Software timestamps captured in user space in the NTP implementation
itself are least accurate. They do not include system calls used for
sending and receiving packets, processing and queuing delays in the
system, network device drivers, and hardware. Hardware timestamps
captured at the physical layer are most accurate.
A transmit timestamp captured in the driver or hardware is more
accurate than the user-space timestamp, but it is available to the
NTP implementation only after it sent the packet using a system call.
The timestamp cannot be included in the packet itself unless the
driver or hardware supports NTP and can modify the packet before or
during the actual transmission.
The protocol described in RFC 5905 does not specify any mechanism for
a server to provide its clients and peers with a more accurate
transmit timestamp that is known only after the transmission. A
packet that strictly follows RFC 5905, i.e. it contains a transmit
timestamp corresponding to the packet itself, is said to be in basic
mode.
Different mechanisms could be used to exchange timestamps known after
the transmission. The server could respond to each request with two
packets. The second packet would contain the transmit timestamp
corresponding to the first packet. However, such a protocol would
enable a traffic amplification attack, or it would use packets with
an asymmetric length, which would cause an asymmetry in the network
delay and an error in the measured offset.
This document describes an interleaved client/server, interleaved
symmetric, and interleaved broadcast mode. In these modes, the
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.
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.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Interleaved Client/server mode
The interleaved client/server mode is similar to the basic client/
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
direction of the association. It is a copy of one of the timestamps
from the packet to which it is responding, or zero if it is not a
response. Servers following RFC 5905 ignore the origin timestamp in
client requests. A server response which does not have a matching
origin timestamp is called bogus.
A client request in the basic mode has an origin timestamp equal to
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 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
timestamps to limit the amount of memory needed to support clients
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 in RFC 9109 [RFC9109].
The server MAY restrict the interleaved mode to specific IP addresses
and/or authenticated clients.
Both servers and clients that support the interleaved mode MUST NOT
send a packet that has a transmit timestamp equal to the receive
timestamp in order to reliably detect whether received packets
conform to the interleaved mode. One way to ensure that is to
increment the transmit timestamp by 1 unit (i.e. about 1/4 of a
nanosecond) if the two timestamps are equal, or a new timestamp can
be generated.
The transmit and receive timestamps in server responses need to be
unique to prevent two different clients from sending requests with
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 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.
When the server receives a request from a client, it SHOULD respond
in the interleaved mode if the following conditions are met:
1. The request does not have a receive timestamp equal to the
transmit timestamp.
2. The origin timestamp from the request matches the local receive
timestamp of a previous request that the server has saved (for
the IP address if it separates timestamps by addresses).
A response in the interleaved mode MUST contain the transmit
timestamp of the response which contained the receive timestamp
matching the origin timestamp from the request. The server SHOULD
drop the timestamps after sending the response. The receive
timestamp MUST NOT be used again to detect a request conforming to
the interleaved mode.
If the conditions are not met (i.e. the request is not detected to
conform to the interleaved mode), the server MUST NOT respond in the
interleaved mode. The server MAY always respond in the basic mode.
In any case, the server SHOULD save the new receive and transmit
timestamps.
The first request from a client is always in the basic mode and so is
the server response. It has a zero origin timestamp and zero receive
timestamp. Only when the client receives a valid response from the
server, it will be able to send a request in the interleaved mode.
The protocol recovers from packet loss. When a client request or
server response is lost, the client will use the same origin
timestamp in the next request. The server can respond in the
interleaved mode if it still has the timestamps corresponding to the
origin timestamp. If the server already responded to the timestamp
in the interleaved mode, or it had to drop the timestamps for other
reasons, it will respond in the basic mode and save new timestamps,
which will enable an interleaved response to the subsequent request.
The client SHOULD limit the number of requests in the interleaved
mode between server responses to prevent processing of very old
timestamps in case a large number of consecutive requests is lost.
An example of packets in a client/server exchange using the
interleaved mode is shown in Figure 1. The packets in the basic and
interleaved mode are indicated with B and I respectively. The
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
the basic mode followed by a second exchange in the interleaved mode.
For the third exchange, the client request is in the interleaved
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
dropped to save timestamps for other clients using the interleaved
mode).
Server t2 t3 t6 t7 t10 t11
-----+----+----------------+----+----------------+----+-----
/ \ / \ / \
Client / \ / \ / \
--+----------+----------+----------+----------+----------+--
t1 t4 t5 t8 t9 t12
Mode: B B I I I B
+----+ +----+ +----+ +----+ +----+ +----+
Org | 0 | | t1~| | t2 | | t4 | | t6 | | t5 |
Rx | 0 | | t2 | | t4 | | t6 | | t8 | |t10 |
Tx | t1~| | t3~| | t1 | | t3 | | t5 | |t11~|
+----+ +----+ +----+ +----+ +----+ +----+
Figure 1: Packet timestamps in interleaved client/server mode
When the client receives a response from the server, it performs the
tests described in RFC 5905. Two of the tests are modified for the
interleaved mode:
1. The check for duplicate packets SHOULD compare both receive and
transmit timestamps in order to not drop a valid response in the
interleaved mode if it follows a response in the basic mode and
they contain the same transmit timestamp.
2. The check for bogus packets SHOULD compare the origin timestamp
with both transmit and receive timestamps from the request. If
the origin timestamp is equal to the transmit timestamp, the
response is in the basic mode. If the origin timestamp is equal
to the receive timestamp, the response is in the interleaved
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
complete a measurement when the subsequent response in the
interleaved mode is received.
If the packet passed the tests and conforms to the interleaved mode,
the client can compute the offset and delay using the formulas from
RFC 5905 and one of two different sets of timestamps. The first set
is RECOMMENDED for clients that filter measurements based on the
delay. The corresponding timestamps from Figure 1 are written in
parentheses.
T1 - local transmit timestamp of the previous request (t1)
T2 - remote receive timestamp from the previous response (t2)
T3 - remote transmit timestamp from the latest response (t3)
T4 - local receive timestamp of the previous response (t4)
The second set gives a more accurate measurement of the current
offset, but the delay is much more sensitive to a frequency error
between the server and client due to a much longer interval between
T1 and T4.
T1 - local transmit timestamp of the latest request (t5)
T2 - remote receive timestamp from the latest response (t6)
T3 - remote transmit timestamp from the latest response (t3)
T4 - local receive timestamp of the previous response (t4)
Clients MAY filter measurements based on the mode. The maximum
number of dropped measurements in the basic mode SHOULD be limited in
case the server does not support or is not able to respond in the
interleaved mode. Clients that filter measurements based on the
delay will implicitly prefer measurements in the interleaved mode
over the basic mode, because they have a shorter delay due to a more
accurate transmit timestamp (T3).
The server MAY limit saving of the receive and transmit timestamps to
requests which have an origin timestamp specific to the interleaved
mode in order to not waste resources on clients using the basic mode.
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 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
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
this reason, it SHOULD be disabled by default and enabled with an
option in the configuration of the active side of the association.
In order to prevent the peer from matching the transmit timestamp
with an incorrect packet when the peers' transmissions do not
alternate (e.g. they use different polling intervals) and a previous
packet was lost, the use of the interleaved mode in symmetric
associations requires additional restrictions.
Peers which have an association need to count valid packets received
between their transmissions to determine in which mode a packet
should be formed. A valid packet in this context is a packet which
passed all NTP tests for duplicate, replayed, bogus, and
unauthenticated packets. Other received packets may update the NTP
state to allow the (re)initialization of the association, but they do
not change the selection of the mode.
A peer A SHOULD send a peer B a packet in the interleaved mode only
when all of the following conditions are met:
1. The peer A has an active association with the peer B which was
specified with the option enabling the interleaved mode, OR the
peer A received at least one valid packet in the interleaved mode
from the peer B.
2. The peer A did not send a packet to the peer B since it received
the last valid packet from the peer B.
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 B are in the basic mode, because
multiple responses are sent per request.
Peer A t2 t3 t6 t8 t9 t12 t14 t15
-----+--+--------+-----------+--+--------+-----------+--+-----
/ \ / / \ / / \
Peer B / \ / / \ / / \
--+--------+--+-----------+--------+--+-----------+--------+--
t1 t4 t5 t7 t10 t11 t13 t16
Mode: B B I B I B B I
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Org | 0 | | t1~| | t2 | | t3~| | t4 | | t3 | | t3 | |t10 |
Rx | 0 | | t2 | | t4 | | t4 | | t8 | |t10 | |t10 | |t14 |
Tx | t1~| | t3~| | t1 | | t7~| | t3 | |t11~| |t13~| | t9 |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 2: Packet timestamps in interleaved symmetric mode
If the peer A has no association with the peer B and it responds with
symmetric passive packets, it does not need to count the packets in
order to meet the restrictions, because each request has at most one
response. The peer SHOULD process the requests in the same way as a
server which supports the interleaved client/server mode. It MUST
NOT respond in the interleaved mode if the request was not in the
interleaved mode.
The peers SHOULD compute the offset and delay using one of the two
sets of timestamps specified in the client/server section. They MAY
switch between them to minimize the interval between T1 and T4 in
order to reduce the error in the measured delay.
4. Interleaved Broadcast mode
A packet in the interleaved broadcast mode contains two transmit
timestamps. One corresponds to the packet itself and is saved in the
transmit timestamp field. The other corresponds to the previous
packet and is saved in the origin timestamp field. The packet is
compatible with the basic mode, which uses a zero origin timestamp.
An example of packets sent in the broadcast mode is shown in
Figure 3.
Server t1 t3 t5 t7
------+------------+------------+------------+---------
\ \ \ \
Client \ \ \ \
---------+------------+------------+------------+------
t2 t4 t6 t8
Mode: B I I I
+----+ +----+ +----+ +----+
Org | 0 | | t1 | | t3 | | t5 |
Rx | 0 | | 0 | | 0 | | 0 |
Tx | t1~| | t3~| | t5~| | t7~|
+----+ +----+ +----+ +----+
Figure 3: Packet timestamps in interleaved broadcast mode
A client which does not support the interleaved mode ignores the
origin timestamp and processes all packets as if they were in the
basic mode.
A client which supports the interleaved mode SHOULD check if the
origin timestamp is not zero to detect packets in the interleaved
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 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. Protocol Failures
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.
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.
6. Security Considerations
The security considerations of time protocols in general are
discussed in RFC 7384 [RFC7384], and specifically the security
considerations of NTP are discussed in RFC 5905.
Security issues that apply to the basic modes apply also to the
interleaved modes. They are described in The Security of NTP's
Datagram Protocol [SECNTP].
Clients and peers SHOULD NOT leak the receive timestamp in packets
sent to other peers or clients (e.g. as a reference timestamp) to
prevent off-path attackers from easily getting the origin timestamp
needed to make a valid response in the interleaved mode.
Clients using the interleaved mode SHOULD randomize all bits of both
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 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
a large number of requests, send requests with a spoofed source
address, or replay an authenticated request if the interleaved mode
is enabled only for authenticated clients. Clients SHOULD NOT rely
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. 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.
7. IANA Considerations
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
Minimization", draft-ietf-ntp-data-minimization-04 (work
in progress), March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
[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>.
9.3. URIs
[1] http://www.ntp.org
Authors' Addresses
Miroslav Lichvar
Red Hat
Purkynova 115
Brno 612 00
Czech Republic
Email: [email protected]
Aanchal Malhotra
Boston University
111 Cummington St
Boston 02215
USA
Email: [email protected]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment