idnits 2.17.1 draft-ietf-ntp-interleaved-modes-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5905, but the abstract doesn't seem to directly say this. It does mention RFC5905 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 269 has weird spacing: '... Server t2 ...' (Using the creation date from RFC5905, updated by this document, for RFC5378 checks: 2005-07-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Jul 1, 2021) is 1029 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 577 == Outdated reference: A later version (-08) exists of draft-ietf-ntp-port-randomization-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Lichvar 3 Internet-Draft Red Hat 4 Updates: 5905 (if approved) A. Malhotra 5 Intended status: Standards Track Boston University 6 Expires: January 2, 2022 Jul 1, 2021 8 NTP Interleaved Modes 9 draft-ietf-ntp-interleaved-modes-06 11 Abstract 13 This document extends the specification of Network Time Protocol 14 (NTP) version 4 in RFC 5905 with special modes called the NTP 15 interleaved modes, that enable NTP servers to provide their clients 16 and peers with more accurate transmit timestamps that are available 17 only after transmitting NTP packets. More specifically, this 18 document describes three modes: interleaved client/server, 19 interleaved symmetric, and interleaved broadcast. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 2, 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 57 2. Interleaved Client/server mode . . . . . . . . . . . . . . . 4 58 3. Interleaved Symmetric mode . . . . . . . . . . . . . . . . . 8 59 4. Interleaved Broadcast mode . . . . . . . . . . . . . . . . . 10 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 65 8.2. Informative References . . . . . . . . . . . . . . . . . 12 66 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 69 1. Introduction 71 RFC 5905 [RFC5905] describes the operations of NTPv4 in a client/ 72 server, symmetric, and broadcast mode. The transmit and receive 73 timestamps are two of the four timestamps included in every NTPv4 74 packet used for time synchronization. 76 For a highly accurate and stable synchronization, the transmit and 77 receive timestamp should be captured close to the beginning of the 78 actual transmission and the end of the reception respectively. An 79 asymmetry in the timestamping causes the offset measured by NTP to 80 have an error. 82 There are at least four options where a timestamp of an NTP packet 83 may be captured with a software NTP implementation running on an 84 operating system: 86 1. User space (software) 88 2. Network device driver or kernel (software) 90 3. Data link layer (hardware - MAC chip) 92 4. Physical layer (hardware - PHY chip) 94 Software timestamps captured in user space in the NTP implementation 95 itself are least accurate. They do not include system calls used for 96 sending and receiving packets, processing and queuing delays in the 97 system, network device drivers, and hardware. Hardware timestamps 98 captured at the physical layer are most accurate. 100 A transmit timestamp captured in the driver or hardware is more 101 accurate than the user-space timestamp, but it is available to the 102 NTP implementation only after it sent the packet using a system call. 103 The timestamp cannot be included in the packet itself unless the 104 driver or hardware supports NTP and can modify the packet before or 105 during the actual transmission. 107 The protocol described in RFC 5905 does not specify any mechanism for 108 a server to provide its clients and peers with a more accurate 109 transmit timestamp that is known only after the transmission. A 110 packet that strictly follows RFC 5905, i.e. it contains a transmit 111 timestamp corresponding to the packet itself, is said to be in basic 112 mode. 114 Different mechanisms could be used to exchange timestamps known after 115 the transmission. The server could respond to each request with two 116 packets. The second packet would contain the transmit timestamp 117 corresponding to the first packet. However, such a protocol would 118 enable a traffic amplification attack, or it would use packets with 119 an asymmetric length, which would cause an asymmetry in the network 120 delay and an error in the measured offset. 122 This document describes an interleaved client/server, interleaved 123 symmetric, and interleaved broadcast mode. In these modes, the 124 server sends a single packet, which contains a transmit timestamp 125 corresponding to the previous packet that was sent to the client or 126 peer. This transmit timestamp can be captured at any of the four 127 places mentioned above. Both servers and clients/peers are required 128 to keep some state specific to the interleaved mode. 130 The protocol does not change the NTP packet header format, only the 131 semantics of some timestamp fields. An NTPv4 implementation that 132 supports the client/server and broadcast interleaved modes 133 interoperates with NTPv4 implementations without this capability. A 134 peer using the symmetric interleaved mode does not fully interoperate 135 with a peer which does not support it. The mode needs to be 136 configured specifically for each symmetric association. 138 The negotiation in the protocol is implicit. The origin timestamp 139 enables servers and peers to detect requests conforming to the 140 interleaved mode. A response can be valid only in one mode. If a 141 client or peer that does not support interleaved mode received a 142 response conforming to the interleaved mode, it would be rejected as 143 bogus. An explicit negotiation would require a new extension field, 144 which would not work well with implementations that do not respond to 145 requests with unknown extension fields. 147 Requests and responses cannot always be formed in interleaved mode. 148 Servers, clients, and peers are required to support both interleaved 149 and basic modes. 151 This document assumes familiarity with RFC 5905. 153 1.1. Requirements Language 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 2. Interleaved Client/server mode 163 The interleaved client/server mode is similar to the basic client/ 164 server mode. The only difference between the two modes is in the 165 meaning of the transmit and origin timestamp fields. 167 The origin timestamp is a cookie which is used to detect that a 168 received packet is a response to the last packet sent in the other 169 direction of the association. It is a copy of one of the timestamps 170 from the packet to which it is responding, or zero if it is not a 171 response. Servers following RFC 5905 ignore the origin timestamp in 172 client requests. A server response which does not have a matching 173 origin timestamp is called bogus. 175 A client request in the basic mode has an origin timestamp equal to 176 the transmit timestamp from the previous server response, or is zero. 177 A server response in the basic mode has an origin timestamp equal to 178 the transmit timestamp from the client's request. The transmit 179 timestamps correspond to the packets in which they are included. 181 A client request in the interleaved mode has an origin timestamp 182 equal to the receive timestamp from the previous server response. A 183 server response in the interleaved mode has an origin timestamp equal 184 to the receive timestamp from the client's request. The transmit 185 timestamps correspond to the previous packets that were sent to the 186 server or client. 188 A server which supports the interleaved mode needs to save pairs of 189 local receive and transmit timestamps. The server SHOULD discard old 190 timestamps to limit the amount of memory needed to support clients 191 using the interleaved mode. The server MAY separate the timestamps 192 by IP addresses, but it SHOULD NOT separate them by port numbers to 193 support clients that change their port between requests, as 194 recommended by [I-D.ietf-ntp-port-randomization]. 196 The server MAY restrict the interleaved mode to specific IP addresses 197 and/or authenticated clients. 199 Both servers and clients that support the interleaved mode MUST NOT 200 send a packet that has a transmit timestamp equal to the receive 201 timestamp in order to reliably detect whether received packets 202 conform to the interleaved mode. One way to ensure that is to 203 increment the transmit timestamp by 1 unit (i.e. about 1/4 of a 204 nanosecond) if the two timestamps are equal, or a new timestamp can 205 be generated. 207 The transmit and receive timestamps in server responses need to be 208 unique to prevent two different clients from sending requests with 209 the same origin timestamp and the server responding in the 210 interleaved mode with an incorrect transmit timestamp. If the 211 timestamps are not guaranteed to be monotonically increasing, the 212 server SHOULD check that the transmit and receive timestamp is not 213 already saved as a receive timestamp of a previous request (from the 214 same IP address if the server separates timestamps by addresses), and 215 generate a new timestamp if necessary. 217 When the server receives a request from a client, it SHOULD respond 218 in the interleaved mode if the following conditions are met: 220 1. The request does not have a receive timestamp equal to the 221 transmit timestamp. 223 2. The origin timestamp from the request matches the local receive 224 timestamp of a previous request that the server has saved (for 225 the IP address if it separates timestamps by addresses). 227 A response in the interleaved mode MUST contain the transmit 228 timestamp of the response which contained the receive timestamp 229 matching the origin timestamp from the request. The server SHOULD 230 drop the timestamps after sending the response. The receive 231 timestamp MUST NOT be used again to detect a request conforming to 232 the interleaved mode. 234 If the conditions are not met (i.e. the request is not detected to 235 conform to the interleaved mode), the server MUST NOT respond in the 236 interleaved mode. The server MAY always respond in the basic mode. 237 In any case, the server SHOULD save the new receive and transmit 238 timestamps. 240 The first request from a client is always in the basic mode and so is 241 the server response. It has a zero origin timestamp and zero receive 242 timestamp. Only when the client receives a valid response from the 243 server, it will be able to send a request in the interleaved mode. 245 The protocol recovers from packet loss. When a client request or 246 server response is lost, the client will use the same origin 247 timestamp in the next request. The server can respond in the 248 interleaved mode if it still has the timestamps corresponding to the 249 origin timestamp. If the server already responded to the timestamp 250 in the interleaved mode, or it had to drop the timestamps for other 251 reasons, it will respond in the basic mode and save new timestamps, 252 which will enable an interleaved response to the subsequent request. 253 The client SHOULD limit the number of requests in the interleaved 254 mode between server responses to prevent processing of very old 255 timestamps in case a large number of consecutive requests is lost. 257 An example of packets in a client/server exchange using the 258 interleaved mode is shown in Figure 1. The packets in the basic and 259 interleaved mode are indicated with B and I respectively. The 260 timestamps t1~, t3~ and t11~ point to the same transmissions as t1, 261 t3 and t11, but they may be less accurate. The first exchange is in 262 the basic mode followed by a second exchange in the interleaved mode. 263 For the third exchange, the client request is in the interleaved 264 mode, but the server response is in the basic mode, because the 265 server did not have the pair of timestamps t6 and t7 (e.g. they were 266 dropped to save timestamps for other clients using the interleaved 267 mode). 269 Server t2 t3 t6 t7 t10 t11 270 -----+----+----------------+----+----------------+----+----- 271 / \ / \ / \ 272 Client / \ / \ / \ 273 --+----------+----------+----------+----------+----------+-- 274 t1 t4 t5 t8 t9 t12 276 Mode: B B I I I B 277 +----+ +----+ +----+ +----+ +----+ +----+ 278 Org | 0 | | t1~| | t2 | | t4 | | t6 | | t5 | 279 Rx | 0 | | t2 | | t4 | | t6 | | t8 | |t10 | 280 Tx | t1~| | t3~| | t1 | | t3 | | t5 | |t11~| 281 +----+ +----+ +----+ +----+ +----+ +----+ 283 Figure 1: Packet timestamps in interleaved client/server mode 285 When the client receives a response from the server, it performs the 286 tests described in RFC 5905. Two of the tests are modified for the 287 interleaved mode: 289 1. The check for duplicate packets SHOULD compare both receive and 290 transmit timestamps in order to not drop a valid response in the 291 interleaved mode if it follows a response in the basic mode and 292 they contain the same transmit timestamp. 294 2. The check for bogus packets SHOULD compare the origin timestamp 295 with both transmit and receive timestamps from the request. If 296 the origin timestamp is equal to the transmit timestamp, the 297 response is in the basic mode. If the origin timestamp is equal 298 to the receive timestamp, the response is in the interleaved 299 mode. 301 The client SHOULD NOT update its NTP state when an invalid response 302 is received to not lose the timestamps which will be needed to 303 complete a measurement when the subsequent response in the 304 interleaved mode is received. 306 If the packet passed the tests and conforms to the interleaved mode, 307 the client can compute the offset and delay using the formulas from 308 RFC 5905 and one of two different sets of timestamps. The first set 309 is RECOMMENDED for clients that filter measurements based on the 310 delay. The corresponding timestamps from Figure 1 are written in 311 parentheses. 313 T1 - local transmit timestamp of the previous request (t1) 315 T2 - remote receive timestamp from the previous response (t2) 317 T3 - remote transmit timestamp from the latest response (t3) 319 T4 - local receive timestamp of the previous response (t4) 321 The second set gives a more accurate measurement of the current 322 offset, but the delay is much more sensitive to a frequency error 323 between the server and client due to a much longer interval between 324 T1 and T4. 326 T1 - local transmit timestamp of the latest request (t5) 328 T2 - remote receive timestamp from the latest response (t6) 330 T3 - remote transmit timestamp from the latest response (t3) 332 T4 - local receive timestamp of the previous response (t4) 334 Clients MAY filter measurements based on the mode. The maximum 335 number of dropped measurements in the basic mode SHOULD be limited in 336 case the server does not support or is not able to respond in the 337 interleaved mode. Clients that filter measurements based on the 338 delay will implicitly prefer measurements in the interleaved mode 339 over the basic mode, because they have a shorter delay due to a more 340 accurate transmit timestamp (T3). 342 The server MAY limit saving of the receive and transmit timestamps to 343 requests which have an origin timestamp specific to the interleaved 344 mode in order to not waste resources on clients using the basic mode. 345 Such an optimization will delay the first interleaved response of the 346 server to a client by one exchange. 348 A check for a non-zero origin timestamp works with clients that 349 implement NTP data minimization [I-D.ietf-ntp-data-minimization]. To 350 detect requests in the basic mode from clients that do not implement 351 the data minimization, the server can encode in low-order bits of the 352 receive and transmit timestamps below precision of the clock a bit 353 indicating whether the timestamp is a receive timestamp. If the 354 server receives a request with a non-zero origin timestamp which does 355 not indicate it is a receive timestamp of the server, the request is 356 in the basic mode and it is not necessary to save the new receive and 357 transmit timestamp. 359 3. Interleaved Symmetric mode 361 The interleaved symmetric mode uses the same principles as the 362 interleaved client/server mode. A packet in the interleaved 363 symmetric mode has a transmit timestamp which corresponds to the 364 previous packet sent to the peer and an origin timestamp equal to the 365 receive timestamp from the last packet received from the peer. 367 To enable synchronization in both directions of a symmetric 368 association, both peers need to support the interleaved mode. For 369 this reason, it SHOULD be disabled by default and enabled with an 370 option in the configuration of the active side of the association. 372 In order to prevent the peer from matching the transmit timestamp 373 with an incorrect packet when the peers' transmissions do not 374 alternate (e.g. they use different polling intervals) and a previous 375 packet was lost, the use of the interleaved mode in symmetric 376 associations requires additional restrictions. 378 Peers which have an association need to count valid packets received 379 between their transmissions to determine in which mode a packet 380 should be formed. A valid packet in this context is a packet which 381 passed all NTP tests for duplicate, replayed, bogus, and 382 unauthenticated packets. Other received packets may update the NTP 383 state to allow the (re)initialization of the association, but they do 384 not change the selection of the mode. 386 A peer A SHOULD send a peer B a packet in the interleaved mode only 387 when all of the following conditions are met: 389 1. The peer A has an active association with the peer B which was 390 specified with the option enabling the interleaved mode, OR the 391 peer A received at least one valid packet in the interleaved mode 392 from the peer B. 394 2. The peer A did not send a packet to the peer B since it received 395 the last valid packet from the peer B. 397 3. The previous packet that the peer A sent to the peer B was the 398 only response to a packet received from the peer B. 400 An example of packets exchanged in a symmetric association is shown 401 in Figure 2. The minimum polling interval of the peer A is twice as 402 long as the maximum polling interval of the peer B. The first 403 packets sent by the peers are in the basic mode. The second and 404 third packet sent by the peer A is in the interleaved mode. The 405 second packet sent by the peer B is in the interleaved mode, but the 406 following packets sent by the peer are in the basic mode, because 407 multiple responses are sent per request. 409 Peer A t2 t3 t6 t8 t9 t12 t14 t15 410 -----+--+--------+-----------+--+--------+-----------+--+----- 411 / \ / / \ / / \ 412 Peer B / \ / / \ / / \ 413 --+--------+--+-----------+--------+--+-----------+--------+-- 414 t1 t4 t5 t7 t10 t11 t13 t16 416 Mode: B B I B I B B I 417 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ 418 Org | 0 | | t1~| | t2 | | t3~| | t4 | | t3 | | t3 | |t10 | 419 Rx | 0 | | t2 | | t4 | | t4 | | t8 | |t10 | |t10 | |t14 | 420 Tx | t1~| | t3~| | t1 | | t7~| | t3 | |t11~| |t13~| | t9 | 421 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ 423 Figure 2: Packet timestamps in interleaved symmetric mode 425 If the peer A has no association with the peer B and it responds with 426 symmetric passive packets, it does not need to count the packets in 427 order to meet the restrictions, because each request has at most one 428 response. The peer SHOULD process the requests in the same way as a 429 server which supports the interleaved client/server mode. It MUST 430 NOT respond in the interleaved mode if the request was not in the 431 interleaved mode. 433 The peers SHOULD compute the offset and delay using one of the two 434 sets of timestamps specified in the client/server section. They MAY 435 switch between them to minimize the interval between T1 and T4 in 436 order to reduce the error in the measured delay. 438 4. Interleaved Broadcast mode 440 A packet in the interleaved broadcast mode contains two transmit 441 timestamps. One corresponds to the packet itself and is saved in the 442 transmit timestamp field. The other corresponds to the previous 443 packet and is saved in the origin timestamp field. The packet is 444 compatible with the basic mode, which uses a zero origin timestamp. 446 An example of packets sent in the broadcast mode is shown in 447 Figure 3. 449 Server t1 t3 t5 t7 450 ------+------------+------------+------------+--------- 451 \ \ \ \ 452 Client \ \ \ \ 453 ---------+------------+------------+------------+------ 454 t2 t4 t6 t8 456 Mode: B I I I 457 +----+ +----+ +----+ +----+ 458 Org | 0 | | t1 | | t3 | | t5 | 459 Rx | 0 | | 0 | | 0 | | 0 | 460 Tx | t1~| | t3~| | t5~| | t7~| 461 +----+ +----+ +----+ +----+ 463 Figure 3: Packet timestamps in interleaved broadcast mode 465 A client which does not support the interleaved mode ignores the 466 origin timestamp and processes all packets as if they were in the 467 basic mode. 469 A client which supports the interleaved mode SHOULD check if the 470 origin timestamp is not zero to detect packets in the interleaved 471 mode. The client SHOULD also compare the origin timestamp with the 472 transmit timestamp from the previous packet to detect lost packets. 473 If the difference is larger than a specified maximum (e.g. 1 second), 474 the packet SHOULD NOT be used for synchronization. 476 The client SHOULD compute the offset using the origin timestamp from 477 the received packet and the local receive timestamp of the previous 478 packet. If the client needs to measure the network delay, it SHOULD 479 use the interleaved client/server mode. 481 5. Acknowledgements 483 The interleaved modes described in this document are based on the 484 implementation written by David Mills in the NTP project [1]. The 485 specification of the broadcast mode is based purely on this 486 implementation. The specification of the symmetric mode has some 487 modifications. The client/server mode is specified as a new mode 488 compatible with the symmetric mode, similarly to the basic symmetric 489 and client/server modes. 491 The authors would like to thank Theresa Enghardt, Daniel Franke, Erik 492 Kline, Tal Mizrahi, Steven Sommars, Harlan Stenn, and Kristof Teichel 493 for their useful comments. 495 6. IANA Considerations 497 This memo includes no request to IANA. 499 7. Security Considerations 501 The security considerations of time protocols in general are 502 discussed in RFC 7384 [RFC7384], and specifically the security 503 considerations of NTP are discussed in RFC 5905. 505 Security issues that apply to the basic modes apply also to the 506 interleaved modes. They are described in The Security of NTP's 507 Datagram Protocol [SECNTP]. 509 Clients and peers SHOULD NOT leak the receive timestamp in packets 510 sent to other peers or clients (e.g. as a reference timestamp) to 511 prevent off-path attackers from easily getting the origin timestamp 512 needed to make a valid response in the interleaved mode. 514 Clients using the interleaved mode SHOULD randomize all bits of both 515 receive and transmit timestamps, as recommended for the transmit 516 timestamp in the NTP client data minimization 517 [I-D.ietf-ntp-data-minimization], to make it more difficult for off- 518 path attackers to guess the origin timestamp. It is not possible to 519 zero the origin timestamp to prevent passive observers from easily 520 tracking clients moving between different networks. 522 Attackers can force the server to drop its timestamps in order to 523 prevent clients from getting an interleaved response. They can send 524 a large number of requests, send requests with a spoofed source 525 address, or replay an authenticated request if the interleaved mode 526 is enabled only for authenticated clients. Clients SHOULD NOT rely 527 on servers to be able to respond in the interleaved mode. 529 Protecting symmetric associations in the interleaved mode against 530 replay attacks is even more difficult than in the basic mode. The 531 NTP state needs to be protected not only between the reception and 532 transmission in order to send the peer a packet with a valid origin 533 timestamp, but all the time to not lose the timestamps which will be 534 needed to complete a measurement when the following packet in the 535 interleaved mode is received. 537 8. References 539 8.1. Normative References 541 [I-D.ietf-ntp-data-minimization] 542 Franke, D. F. and A. Malhotra, "NTP Client Data 543 Minimization", draft-ietf-ntp-data-minimization-04 (work 544 in progress), March 2019. 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, 548 DOI 10.17487/RFC2119, March 1997, 549 . 551 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 552 "Network Time Protocol Version 4: Protocol and Algorithms 553 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 554 . 556 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 557 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 558 May 2017, . 560 8.2. Informative References 562 [I-D.ietf-ntp-port-randomization] 563 Gont, F., Gont, G., and M. Lichvar, "Port Randomization in 564 the Network Time Protocol Version 4", draft-ietf-ntp-port- 565 randomization-06 (work in progress), September 2020. 567 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 568 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 569 October 2014, . 571 [SECNTP] Malhotra, A., Gundy, M., Varia, M., Kennedy, H., Gardner, 572 J., and S. Goldberg, "The Security of NTP's Datagram 573 Protocol", 2016, . 575 8.3. URIs 577 [1] http://www.ntp.org 579 Authors' Addresses 581 Miroslav Lichvar 582 Red Hat 583 Purkynova 115 584 Brno 612 00 585 Czech Republic 587 Email: mlichvar@redhat.com 589 Aanchal Malhotra 590 Boston University 591 111 Cummington St 592 Boston 02215 593 USA 595 Email: aanchal4@bu.edu