idnits 2.17.1 draft-ietf-ntp-interleaved-modes-05.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 262 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 (Apr 8, 2021) is 1115 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 565 Summary: 0 errors (**), 0 flaws (~~), 2 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: October 10, 2021 Apr 8, 2021 8 NTP Interleaved Modes 9 draft-ietf-ntp-interleaved-modes-05 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 October 10, 2021. 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 . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 a packet 168 which is not a response to the last packet sent in the other 169 direction. Such packets are called bogus packets in RFC 5905. 171 A client request in the basic mode has an origin timestamp equal to 172 the transmit timestamp from the previous server response, or is zero. 173 A server response in the basic mode has an origin timestamp equal to 174 the transmit timestamp from the client's request. The transmit 175 timestamps correspond to the packets in which they are included. 177 A client request in the interleaved mode has an origin timestamp 178 equal to the receive timestamp from the previous server response. A 179 server response in the interleaved mode has an origin timestamp equal 180 to the receive timestamp from the client's request. The transmit 181 timestamps correspond to the previous packets that were sent to the 182 server or client. 184 A server which supports the interleaved mode needs to save pairs of 185 local receive and transmit timestamps. The server SHOULD discard old 186 timestamps to limit the amount of memory needed to support clients 187 using the interleaved mode. The server MAY separate the timestamps 188 by IP addresses, but it SHOULD NOT separate them by port numbers, 189 i.e. clients are allowed to change their source port between 190 requests. 192 The server MAY restrict the interleaved mode to specific IP addresses 193 and/or authenticated clients. 195 Both servers and clients that support the interleaved mode MUST NOT 196 send a packet that has a transmit timestamp equal to the receive 197 timestamp in order to reliably detect whether received packets 198 conform to the interleaved mode. 200 The transmit and receive timestamps in server responses need to be 201 unique to prevent two different clients from sending requests with 202 the same origin timestamp and the server responding in the 203 interleaved mode with an incorrect transmit timestamp. If the 204 timestamps are not guaranteed to be monotonically increasing, the 205 server SHOULD check that the transmit and receive timestamp is not 206 already saved as a receive timestamp of a previous request (from the 207 same IP address if the server separates timestamps by addresses), and 208 generate a new timestamp if necessary. 210 When the server receives a request from a client, it SHOULD respond 211 in the interleaved mode if the following conditions are met: 213 1. The request does not have a receive timestamp equal to the 214 transmit timestamp. 216 2. The origin timestamp from the request matches the local receive 217 timestamp of a previous request that the server has saved (for 218 the IP address if it separates timestamps by addresses). 220 A response in the interleaved mode MUST contain the transmit 221 timestamp of the response which contained the receive timestamp 222 matching the origin timestamp from the request. The server SHOULD 223 drop the timestamps after sending the response. The receive 224 timestamp MUST NOT be used again to detect a request conforming to 225 the interleaved mode. 227 If the conditions are not met (i.e. the request is not detected to 228 conform to the interleaved mode), the server MUST NOT respond in the 229 interleaved mode. The server MAY always respond in the basic mode. 230 In any case, the server SHOULD save the new receive and transmit 231 timestamps. 233 The first request from a client is always in the basic mode and so is 234 the server response. It has a zero origin timestamp and zero receive 235 timestamp. Only when the client receives a valid response from the 236 server, it will be able to send a request in the interleaved mode. 238 The protocol recovers from packet loss. When a client request or 239 server response is lost, the client will use the same origin 240 timestamp in the next request. The server can respond in the 241 interleaved mode if it still has the timestamps corresponding to the 242 origin timestamp. If the server already responded to the timestamp 243 in the interleaved mode, or it had to drop the timestamps for other 244 reasons, it will respond in the basic mode and save new timestamps, 245 which will enable an interleaved response to the subsequent request. 246 The client SHOULD limit the number of requests in the interleaved 247 mode between server responses to prevent processing of very old 248 timestamps in case a large number of consecutive requests is lost. 250 An example of packets in a client/server exchange using the 251 interleaved mode is shown in Figure 1. The packets in the basic and 252 interleaved mode are indicated with B and I respectively. The 253 timestamps t1~, t3~ and t11~ point to the same transmissions as t1, 254 t3 and t11, but they may be less accurate. The first exchange is in 255 the basic mode followed by a second exchange in the interleaved mode. 256 For the third exchange, the client request is in the interleaved 257 mode, but the server response is in the basic mode, because the 258 server did not have the pair of timestamps t6 and t7 (e.g. they were 259 dropped to save timestamps for other clients using the interleaved 260 mode). 262 Server t2 t3 t6 t7 t10 t11 263 -----+----+----------------+----+----------------+----+----- 264 / \ / \ / \ 265 Client / \ / \ / \ 266 --+----------+----------+----------+----------+----------+-- 267 t1 t4 t5 t8 t9 t12 269 Mode: B B I I I B 270 +----+ +----+ +----+ +----+ +----+ +----+ 271 Org | 0 | | t1~| | t2 | | t4 | | t6 | | t5 | 272 Rx | 0 | | t2 | | t4 | | t6 | | t8 | |t10 | 273 Tx | t1~| | t3~| | t1 | | t3 | | t5 | |t11~| 274 +----+ +----+ +----+ +----+ +----+ +----+ 276 Figure 1: Packet timestamps in interleaved client/server mode 278 When the client receives a response from the server, it performs the 279 tests described in RFC 5905. Two of the tests are modified for the 280 interleaved mode: 282 1. The check for duplicate packets SHOULD compare both receive and 283 transmit timestamps in order to not drop a valid response in the 284 interleaved mode if it follows a response in the basic mode and 285 they contain the same transmit timestamp. 287 2. The check for bogus packets SHOULD compare the origin timestamp 288 with both transmit and receive timestamps from the request. If 289 the origin timestamp is equal to the transmit timestamp, the 290 response is in the basic mode. If the origin timestamp is equal 291 to the receive timestamp, the response is in the interleaved 292 mode. 294 The client SHOULD NOT update its NTP state when an invalid response 295 is received to not lose the timestamps which will be needed to 296 complete a measurement when the subsequent response in the 297 interleaved mode is received. 299 If the packet passed the tests and conforms to the interleaved mode, 300 the client can compute the offset and delay using the formulas from 301 RFC 5905 and one of two different sets of timestamps. The first set 302 is RECOMMENDED for clients that filter measurements based on the 303 delay. The corresponding timestamps from Figure 1 are written in 304 parentheses. 306 T1 - local transmit timestamp of the previous request (t1) 308 T2 - remote receive timestamp from the previous response (t2) 310 T3 - remote transmit timestamp from the latest response (t3) 312 T4 - local receive timestamp of the previous response (t4) 314 The second set gives a more accurate measurement of the current 315 offset, but the delay is much more sensitive to a frequency error 316 between the server and client due to a much longer interval between 317 T1 and T4. 319 T1 - local transmit timestamp of the latest request (t5) 321 T2 - remote receive timestamp from the latest response (t6) 323 T3 - remote transmit timestamp from the latest response (t3) 325 T4 - local receive timestamp of the previous response (t4) 327 Clients MAY filter measurements based on the mode. The maximum 328 number of dropped measurements in the basic mode SHOULD be limited in 329 case the server does not support or is not able to respond in the 330 interleaved mode. Clients that filter measurements based on the 331 delay will implicitly prefer measurements in the interleaved mode 332 over the basic mode, because they have a shorter delay due to a more 333 accurate transmit timestamp (T3). 335 The server MAY limit saving of the receive and transmit timestamps to 336 requests which have an origin timestamp specific to the interleaved 337 mode in order to not waste resources on clients using the basic mode. 338 Such an optimization will delay the first interleaved response of the 339 server to a client by one exchange. 341 A check for a non-zero origin timestamp works with clients that 342 implement NTP data minimization [I-D.ietf-ntp-data-minimization]. To 343 detect requests in the basic mode from clients that do not implement 344 the data minimization, the server can encode in low-order bits of the 345 receive and transmit timestamps below precision of the clock a bit 346 indicating whether the timestamp is a receive timestamp. If the 347 server receives a request with a non-zero origin timestamp which does 348 not indicate it is a receive timestamp of the server, the request is 349 in the basic mode and it is not necessary to save the new receive and 350 transmit timestamp. 352 3. Interleaved Symmetric mode 354 The interleaved symmetric mode uses the same principles as the 355 interleaved client/server mode. A packet in the interleaved 356 symmetric mode has a transmit timestamp which corresponds to the 357 previous packet sent to the peer and an origin timestamp equal to the 358 receive timestamp from the last packet received from the peer. 360 To enable synchronization in both directions of a symmetric 361 association, both peers need to support the interleaved mode. For 362 this reason, it SHOULD be disabled by default and enabled with an 363 option in the configuration of the active side of the association. 365 In order to prevent the peer from matching the transmit timestamp 366 with an incorrect packet when the peers' transmissions do not 367 alternate (e.g. they use different polling intervals) and a previous 368 packet was lost, the use of the interleaved mode in symmetric 369 associations requires additional restrictions. 371 Peers which have an association need to count valid packets received 372 between their transmissions to determine in which mode a packet 373 should be formed. A valid packet in this context is a packet which 374 passed all NTP tests for duplicate, replayed, bogus, and 375 unauthenticated packets. Other received packets may update the NTP 376 state to allow the (re)initialization of the association, but they do 377 not change the selection of the mode. 379 A peer A SHOULD send a peer B a packet in the interleaved mode only 380 when the following conditions are met: 382 1. The peer A has an active association with the peer B which was 383 specified with the option enabling the interleaved mode, OR the 384 peer A received at least one valid packet in the interleaved mode 385 from the peer B. 387 2. The peer A did not send a packet to the peer B since it received 388 the last valid packet from the peer B. 390 3. The previous packet that the peer A sent to the peer B was the 391 only response to a packet received from the peer B. 393 An example of packets exchanged in a symmetric association is shown 394 in Figure 2. The minimum polling interval of the peer A is twice as 395 long as the maximum polling interval of the peer B. The first 396 packets sent by the peers are in the basic mode. The second and 397 third packet sent by the peer A is in the interleaved mode. The 398 second packet sent by the peer B is in the interleaved mode, but the 399 following packets sent by the peer are in the basic mode, because 400 multiple responses are sent per request. 402 Peer A t2 t3 t6 t8 t9 t12 t14 t15 403 -----+--+--------+-----------+--+--------+-----------+--+----- 404 / \ / / \ / / \ 405 Peer B / \ / / \ / / \ 406 --+--------+--+-----------+--------+--+-----------+--------+-- 407 t1 t4 t5 t7 t10 t11 t13 t16 409 Mode: B B I B I B B I 410 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ 411 Org | 0 | | t1~| | t2 | | t3~| | t4 | | t3 | | t3 | |t10 | 412 Rx | 0 | | t2 | | t4 | | t4 | | t8 | |t10 | |t10 | |t14 | 413 Tx | t1~| | t3~| | t1 | | t7~| | t3 | |t11~| |t13~| | t9 | 414 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ 416 Figure 2: Packet timestamps in interleaved symmetric mode 418 If the peer A has no association with the peer B and it responds with 419 symmetric passive packets, it does not need to count the packets in 420 order to meet the restrictions, because each request has at most one 421 response. The peer SHOULD process the requests in the same way as a 422 server which supports the interleaved client/server mode. It MUST 423 NOT respond in the interleaved mode if the request was not in the 424 interleaved mode. 426 The peers SHOULD compute the offset and delay using one of the two 427 sets of timestamps specified in the client/server section. They MAY 428 switch between them to minimize the interval between T1 and T4 in 429 order to reduce the error in the measured delay. 431 4. Interleaved Broadcast mode 433 A packet in the interleaved broadcast mode contains two transmit 434 timestamps. One corresponds to the packet itself and is saved in the 435 transmit timestamp field. The other corresponds to the previous 436 packet and is saved in the origin timestamp field. The packet is 437 compatible with the basic mode, which uses a zero origin timestamp. 439 An example of packets sent in the broadcast mode is shown in 440 Figure 3. 442 Server t1 t3 t5 t7 443 ------+------------+------------+------------+--------- 444 \ \ \ \ 445 Client \ \ \ \ 446 ---------+------------+------------+------------+------ 447 t2 t4 t6 t8 449 Mode: B I I I 450 +----+ +----+ +----+ +----+ 451 Org | 0 | | t1 | | t3 | | t5 | 452 Rx | 0 | | 0 | | 0 | | 0 | 453 Tx | t1~| | t3~| | t5~| | t7~| 454 +----+ +----+ +----+ +----+ 456 Figure 3: Packet timestamps in interleaved broadcast mode 458 A client which does not support the interleaved mode ignores the 459 origin timestamp and processes all packets as if they were in the 460 basic mode. 462 A client which supports the interleaved mode SHOULD check if the 463 origin timestamp is not zero to detect packets in the interleaved 464 mode. The client SHOULD also compare the origin timestamp with the 465 transmit timestamp from the previous packet to detect lost packets. 466 If the difference is larger than a specified maximum (e.g. 1 second), 467 the packet SHOULD NOT be used for synchronization. 469 The client SHOULD compute the offset using the origin timestamp from 470 the received packet and the local receive timestamp of the previous 471 packet. If the client needs to measure the network delay, it SHOULD 472 use the interleaved client/server mode. 474 5. Acknowledgements 476 The interleaved modes described in this document are based on the 477 implementation written by David Mills in the NTP project [1]. The 478 specification of the broadcast mode is based purely on this 479 implementation. The specification of the symmetric mode has some 480 modifications. The client/server mode is specified as a new mode 481 compatible with the symmetric mode, similarly to the basic symmetric 482 and client/server modes. 484 The authors would like to thank Theresa Enghardt, Daniel Franke, Erik 485 Kline, Tal Mizrahi, Steven Sommars, Harlan Stenn, and Kristof Teichel 486 for their useful comments. 488 6. IANA Considerations 490 This memo includes no request to IANA. 492 7. Security Considerations 494 The security considerations of time protocols in general are 495 discussed in RFC 7384 [RFC7384], and specifically the security 496 considerations of NTP are discussed in RFC 5905. 498 Security issues that apply to the basic modes apply also to the 499 interleaved modes. They are described in The Security of NTP's 500 Datagram Protocol [SECNTP]. 502 Clients and peers SHOULD NOT leak the receive timestamp in packets 503 sent to other peers or clients (e.g. as a reference timestamp) to 504 prevent off-path attackers from easily getting the origin timestamp 505 needed to make a valid response in the interleaved mode. 507 Clients using the interleaved mode SHOULD randomize all bits of both 508 receive and transmit timestamps, as recommended for the transmit 509 timestamp in the NTP client data minimization 510 [I-D.ietf-ntp-data-minimization], to make it more difficult for off- 511 path attackers to guess the origin timestamp. It is not possible to 512 zero the origin timestamp to prevent passive observers from easily 513 tracking clients moving between different networks. 515 Attackers can force the server to drop its timestamps in order to 516 prevent clients from getting an interleaved response. They can send 517 a large number of requests, send requests with a spoofed source 518 address, or replay an authenticated request if the interleaved mode 519 is enabled only for authenticated clients. Clients SHOULD NOT rely 520 on servers to be able to respond in the interleaved mode. 522 Protecting symmetric associations in the interleaved mode against 523 replay attacks is even more difficult than in the basic mode. The 524 NTP state needs to be protected not only between the reception and 525 transmission in order to send the peer a packet with a valid origin 526 timestamp, but all the time to not lose the timestamps which will be 527 needed to complete a measurement when the following packet in the 528 interleaved mode is received. 530 8. References 532 8.1. Normative References 534 [I-D.ietf-ntp-data-minimization] 535 Franke, D. and A. Malhotra, "NTP Client Data 536 Minimization", draft-ietf-ntp-data-minimization-04 (work 537 in progress), March 2019. 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, 541 DOI 10.17487/RFC2119, March 1997, 542 . 544 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 545 "Network Time Protocol Version 4: Protocol and Algorithms 546 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 547 . 549 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 550 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 551 May 2017, . 553 8.2. Informative References 555 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 556 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 557 October 2014, . 559 [SECNTP] Malhotra, A., Gundy, M., Varia, M., Kennedy, H., Gardner, 560 J., and S. Goldberg, "The Security of NTP's Datagram 561 Protocol", 2016, . 563 8.3. URIs 565 [1] http://www.ntp.org 567 Authors' Addresses 568 Miroslav Lichvar 569 Red Hat 570 Purkynova 115 571 Brno 612 00 572 Czech Republic 574 Email: mlichvar@redhat.com 576 Aanchal Malhotra 577 Boston University 578 111 Cummington St 579 Boston 02215 580 USA 582 Email: aanchal4@bu.edu