idnits 2.17.1 draft-ietf-ntp-interleaved-modes-04.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 242 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 (Sep 17, 2020) is 1316 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 537 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: March 21, 2021 Sep 17, 2020 8 NTP Interleaved Modes 9 draft-ietf-ntp-interleaved-modes-04 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 March 21, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . 3 57 2. Interleaved Client/server mode . . . . . . . . . . . . . . . 4 58 3. Interleaved Symmetric mode . . . . . . . . . . . . . . . . . 7 59 4. Interleaved Broadcast mode . . . . . . . . . . . . . . . . . 9 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 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 the user space in the NTP 95 implementation itself are least accurate. They do not include system 96 calls used for sending and receiving packets, processing and queuing 97 delays in the system, network device drivers, and hardware. Hardware 98 timestamps 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, or it would use packets with an 119 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 is different. NTPv4 that supports 132 client/server and broadcast interleaved modes is compatible with 133 NTPv4 without this capability as well as with all previous NTP 134 versions. 136 This document assumes familiarity with RFC 5905. 138 1.1. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 2. Interleaved Client/server mode 148 The interleaved client/server mode is similar to the basic client/ 149 server mode. The only difference between the two modes is in the 150 meaning of the transmit and origin timestamp fields. 152 A client request in the basic mode has an origin timestamp equal to 153 the transmit timestamp from the previous server response, or is zero. 154 A server response in the basic mode has an origin timestamp equal to 155 the transmit timestamp from the client's request. The transmit 156 timestamps correspond to the packets in which they are included. 158 A client request in the interleaved mode has an origin timestamp 159 equal to the receive timestamp from the previous server response. A 160 server response in the interleaved mode has an origin timestamp equal 161 to the receive timestamp from the client's request. The transmit 162 timestamps correspond to the previous packets that were sent to the 163 server or client. 165 A server which supports the interleaved mode needs to save pairs of 166 local receive and transmit timestamps. The server SHOULD discard old 167 timestamps to limit the amount of memory needed to support clients 168 using the interleaved mode. The server MAY separate the timestamps 169 by IP addresses, but it SHOULD NOT separate them by port numbers, 170 i.e. clients are allowed to change their source port between 171 requests. 173 The server MAY restrict the interleaved mode to specific IP addresses 174 and/or authenticated clients. 176 Both servers and clients that support the interleaved mode MUST NOT 177 send a packet that has a transmit timestamp equal to the receive 178 timestamp in order to reliably detect whether received packets 179 conform to the interleaved mode. 181 The transmit and receive timestamps in server responses need to be 182 unique to prevent two different clients from sending requests with 183 the same origin timestamp and the server responding in the 184 interleaved mode with an incorrect transmit timestamp. If the 185 timestamps are not guaranteed to be monotonically increasing, the 186 server SHOULD check that the transmit and receive timestamp is not 187 already saved as a receive timestamp of a previous request (from the 188 same IP address if the server separates timestamps by addresses), and 189 generate a new timestamp if necessary. 191 When the server receives a request from a client, it SHOULD respond 192 in the interleaved mode if the following conditions are met: 194 1. The request does not have a receive timestamp equal to the 195 transmit timestamp. 197 2. The origin timestamp from the request matches the local receive 198 timestamp of a previous request that the server has saved (for 199 the IP address if it separates timestamps by addresses). 201 A response in the interleaved mode MUST contain the transmit 202 timestamp of the response which contained the receive timestamp 203 matching the origin timestamp from the request. The server SHOULD 204 drop the timestamps after sending the response. The receive 205 timestamp MUST NOT be used again to detect a request conforming to 206 the interleaved mode. 208 If the conditions are not met, the server MUST NOT respond in the 209 interleaved mode. The server MAY always respond in the basic mode. 210 In any case, the server SHOULD save the new receive and transmit 211 timestamps. 213 The first request from a client is always in the basic mode and so is 214 the server response. It has a zero origin timestamp and zero receive 215 timestamp. Only when the client receives a valid response from the 216 server, it will be able to send a request in the interleaved mode. 218 The protocol recovers from packet loss. When a client request or 219 server response is lost, the client will use the same origin 220 timestamp in the next request. The server can respond in the 221 interleaved mode if it still has the timestamps corresponding to the 222 origin timestamp. If the server already responded to the timestamp 223 in the interleaved mode, or it had to drop the timestamps for other 224 reasons, it will respond in the basic mode and save new timestamps, 225 which will enable an interleaved response to the following request. 226 The client SHOULD limit the number of requests in the interleaved 227 mode between server responses to prevent processing of very old 228 timestamps in case a large number of consecutive requests is lost. 230 An example of packets in a client/server exchange using the 231 interleaved mode is shown in Figure 1. The packets in the basic and 232 interleaved mode are indicated with B and I respectively. The 233 timestamps t1', t3' and t11' point to the same transmissions as t1, 234 t3 and t11, but they may be less accurate. The first exchange is in 235 the basic mode followed by a second exchange in the interleaved mode. 236 For the third exchange, the client request is in the interleaved 237 mode, but the server response is in the basic mode, because the 238 server did not have the pair of timestamps t6 and t7 (e.g. they were 239 dropped to save timestamps for other clients using the interleaved 240 mode). 242 Server t2 t3 t6 t7 t10 t11 243 -----+----+----------------+----+----------------+----+----- 244 / \ / \ / \ 245 Client / \ / \ / \ 246 --+----------+----------+----------+----------+----------+-- 247 t1 t4 t5 t8 t9 t12 249 Mode: B B I I I B 250 +----+ +----+ +----+ +----+ +----+ +----+ 251 Org | 0 | | t1'| | t2 | | t4 | | t6 | | t5 | 252 Rx | 0 | | t2 | | t4 | | t6 | | t8 | |t10 | 253 Tx | t1'| | t3'| | t1 | | t3 | | t5 | |t11'| 254 +----+ +----+ +----+ +----+ +----+ +----+ 256 Figure 1: Packet timestamps in interleaved client/server mode 258 When the client receives a response from the server, it performs the 259 tests described in RFC 5905. Two of the tests are modified for the 260 interleaved mode: 262 1. The check for duplicate packets SHOULD compare both receive and 263 transmit timestamps in order to not drop a valid response in the 264 interleaved mode if it follows a response in the basic mode and 265 they contain the same transmit timestamp. 267 2. The check for bogus packets SHOULD compare the origin timestamp 268 with both transmit and receive timestamps from the request. If 269 the origin timestamp is equal to the transmit timestamp, the 270 response is in the basic mode. If the origin timestamp is equal 271 to the receive timestamp, the response is in the interleaved 272 mode. 274 The client SHOULD NOT update its NTP state when an invalid response 275 is received to not lose the timestamps which will be needed to 276 complete a measurement when the following response in the interleaved 277 mode is received. 279 If the packet passed the tests and conforms to the interleaved mode, 280 the client can compute the offset and delay using the formulas from 281 RFC 5905 and one of two different sets of timestamps. The first set 282 is RECOMMENDED for clients that filter measurements based on the 283 delay. The corresponding timestamps from Figure 1 are written in 284 parentheses. 286 T1 - local transmit timestamp of the previous request (t1) 288 T2 - remote receive timestamp from the previous response (t2) 289 T3 - remote transmit timestamp from the latest response (t3) 291 T4 - local receive timestamp of the previous response (t4) 293 The second set gives a more accurate measurement of the current 294 offset, but the delay is much more sensitive to a frequency error 295 between the server and client due to a much longer interval between 296 T1 and T4. 298 T1 - local transmit timestamp of the latest request (t5) 300 T2 - remote receive timestamp from the latest response (t6) 302 T3 - remote transmit timestamp from the latest response (t3) 304 T4 - local receive timestamp of the previous response (t4) 306 Clients MAY filter measurements based on the mode. The maximum 307 number of dropped measurements in the basic mode SHOULD be limited in 308 case the server does not support or is not able to respond in the 309 interleaved mode. Clients that filter measurements based on the 310 delay will implicitly prefer measurements in the interleaved mode 311 over the basic mode, because they have a shorter delay due to a more 312 accurate transmit timestamp (T3). 314 The server MAY limit saving of the receive and transmit timestamps to 315 requests which have an origin timestamp specific to the interleaved 316 mode in order to not waste resources on clients using the basic mode. 317 Such an optimization will delay the first interleaved response of the 318 server to a client by one exchange. 320 A check for a non-zero origin timestamp works with clients that 321 implement NTP data minimization [I-D.ietf-ntp-data-minimization]. To 322 detect requests in the basic mode from clients that do not implement 323 the data minimization, the server can encode in low-order bits of the 324 receive and transmit timestamps below precision of the clock a bit 325 indicating whether the timestamp is a receive timestamp. If the 326 server receives a request with a non-zero origin timestamp which does 327 not indicate it is a receive timestamp of the server, the request is 328 in the basic mode and it is not necessary to save the new receive and 329 transmit timestamp. 331 3. Interleaved Symmetric mode 333 The interleaved symmetric mode uses the same principles as the 334 interleaved client/server mode. A packet in the interleaved 335 symmetric mode has a transmit timestamp which corresponds to the 336 previous packet sent to the peer and an origin timestamp equal to the 337 receive timestamp from the last packet received from the peer. 339 In order to prevent the peer from matching the transmit timestamp 340 with an incorrect packet when the peers' transmissions do not 341 alternate (e.g. they use different polling intervals) and a previous 342 packet was lost, the use of the interleaved mode in symmetric 343 associations requires additional restrictions. 345 Peers which have an association need to count valid packets received 346 between their transmissions to determine in which mode a packet 347 should be formed. A valid packet in this context is a packet which 348 passed all NTP tests for duplicate, replayed, bogus, and 349 unauthenticated packets. Other received packets may update the NTP 350 state to allow the (re)initialization of the association, but they do 351 not change the selection of the mode. 353 A peer A SHOULD send a peer B a packet in the interleaved mode only 354 when the following conditions are met: 356 1. The peer A has an active association with the peer B which was 357 specified with an option enabling the interleaved mode, OR the 358 peer A received at least one valid packet in the interleaved mode 359 from the peer B. 361 2. The peer A did not send a packet to the peer B since it received 362 the last valid packet from the peer B. 364 3. The previous packet that the peer A sent to the peer B was the 365 only response to a packet received from the peer B. 367 An example of packets exchanged in a symmetric association is shown 368 in Figure 2. The minimum polling interval of the peer A is twice as 369 long as the maximum polling interval of the peer B. The first 370 packets sent by the peers are in the basic mode. The second and 371 third packet sent by the peer A is in the interleaved mode. The 372 second packet sent by the peer B is in the interleaved mode, but the 373 following packets sent by the peer are in the basic mode, because 374 multiple responses are sent per request. 376 Peer A t2 t3 t6 t8 t9 t12 t14 t15 377 -----+--+--------+-----------+--+--------+-----------+--+----- 378 / \ / / \ / / \ 379 Peer B / \ / / \ / / \ 380 --+--------+--+-----------+--------+--+-----------+--------+-- 381 t1 t4 t5 t7 t10 t11 t13 t16 383 Mode: B B I B I B B I 384 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ 385 Org | 0 | | t1'| | t2 | | t3'| | t4 | | t3 | | t3 | |t10 | 386 Rx | 0 | | t2 | | t4 | | t4 | | t8 | |t10 | |t10 | |t14 | 387 Tx | t1'| | t3'| | t1 | | t7'| | t3 | |t11'| |t13'| | t9 | 388 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ 390 Figure 2: Packet timestamps in interleaved symmetric mode 392 If the peer A has no association with the peer B and it responds with 393 symmetric passive packets, it does not need to count the packets in 394 order to meet the restrictions, because each request has at most one 395 response. The peer SHOULD process the requests in the same way as a 396 server which supports the interleaved client/server mode. It MUST 397 NOT respond in the interleaved mode if the request was not in the 398 interleaved mode. 400 The peers SHOULD compute the offset and delay using one the two sets 401 of timestamps specified in the client/server section. They MAY 402 switch between them to minimize the interval between T1 and T4 in 403 order to reduce the error in the measured delay. 405 4. Interleaved Broadcast mode 407 A packet in the interleaved broadcast mode contains two transmit 408 timestamps. One corresponds to the packet itself and is saved in the 409 transmit timestamp field. The other corresponds to the previous 410 packet and is saved in the origin timestamp field. The packet is 411 compatible with the basic mode, which uses a zero origin timestamp. 413 An example of packets sent in the broadcast mode is shown in 414 Figure 3. 416 Server t1 t3 t5 t7 417 ------+------------+------------+------------+--------- 418 \ \ \ \ 419 Client \ \ \ \ 420 ---------+------------+------------+------------+------ 421 t2 t4 t6 t8 423 Mode: B I I I 424 +----+ +----+ +----+ +----+ 425 Org | 0 | | t1 | | t3 | | t5 | 426 Rx | 0 | | 0 | | 0 | | 0 | 427 Tx | t1'| | t3'| | t5'| | t7'| 428 +----+ +----+ +----+ +----+ 430 Figure 3: Packet timestamps in interleaved broadcast mode 432 A client which does not support the interleaved mode ignores the 433 origin timestamp and processes all packets as if they were in the 434 basic mode. 436 A client which supports the interleaved mode SHOULD check if the 437 origin timestamp is not zero to detect packets in the interleaved 438 mode. The client SHOULD also compare the origin timestamp with the 439 transmit timestamp from the previous packet to detect lost packets. 440 If the difference is larger than a specified maximum (e.g. 1 second), 441 the packet SHOULD NOT be used for synchronization. 443 The client SHOULD compute the offset using the origin timestamp from 444 the received packet and the local receive timestamp of the previous 445 packet. If the client needs to measure the network delay, it SHOULD 446 use the interleaved client/server mode. 448 5. Acknowledgements 450 The interleaved modes described in this document are based on the 451 implementation written by David Mills in the NTP project [1]. The 452 specification of the broadcast mode is based purely on this 453 implementation. The specification of the symmetric mode has some 454 modifications. The client/server mode is specified as a new mode 455 compatible with the symmetric mode, similarly to the basic symmetric 456 and client/server modes. 458 The authors would like to thank Daniel Franke, Tal Mizrahi, Steven 459 Sommars, Harlan Stenn, and Kristof Teichel for their useful comments. 461 6. IANA Considerations 463 This memo includes no request to IANA. 465 7. Security Considerations 467 The security considerations of time protocols in general are 468 discussed in RFC 7384 [RFC7384], and specifically the security 469 considerations of NTP are discussed in RFC 5905. 471 Security issues that apply to the basic modes apply also to the 472 interleaved modes. They are described in The Security of NTP's 473 Datagram Protocol [SECNTP]. 475 Clients and peers SHOULD NOT leak the receive timestamp in packets 476 sent to other peers or clients (e.g. as a reference timestamp) to 477 prevent off-path attackers from easily getting the origin timestamp 478 needed to make a valid response in the interleaved mode. 480 Clients using the interleaved mode SHOULD randomize all bits of both 481 receive and transmit timestamps, as recommended for the transmit 482 timestamp in the NTP client data minimization 483 [I-D.ietf-ntp-data-minimization], to make it more difficult for off- 484 path attackers to guess the origin timestamp. It is not possible to 485 zero the origin timestamp to prevent passive observers from easily 486 tracking clients moving between different networks. 488 Attackers can force the server to drop its timestamps in order to 489 prevent clients from getting an interleaved response. They can send 490 a large number of requests, send requests with a spoofed source 491 address, or replay an authenticated request if the interleaved mode 492 is enabled only for authenticated clients. Clients SHOULD NOT rely 493 on servers to be able to respond in the interleaved mode. 495 Protecting symmetric associations in the interleaved mode against 496 replay attacks is even more difficult than in the basic mode. The 497 NTP state needs to be protected not only between the reception and 498 transmission in order to send the peer a packet with a valid origin 499 timestamp, but all the time to not lose the timestamps which will be 500 needed to complete a measurement when the following packet in the 501 interleaved mode is received. 503 8. References 504 8.1. Normative References 506 [I-D.ietf-ntp-data-minimization] 507 Franke, D. and A. Malhotra, "NTP Client Data 508 Minimization", draft-ietf-ntp-data-minimization-04 (work 509 in progress), March 2019. 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, 513 DOI 10.17487/RFC2119, March 1997, 514 . 516 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 517 "Network Time Protocol Version 4: Protocol and Algorithms 518 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 519 . 521 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 522 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 523 May 2017, . 525 8.2. Informative References 527 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 528 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 529 October 2014, . 531 [SECNTP] Malhotra, A., Gundy, M., Varia, M., Kennedy, H., Gardner, 532 J., and S. Goldberg, "The Security of NTP's Datagram 533 Protocol", 2016, . 535 8.3. URIs 537 [1] http://www.ntp.org 539 Authors' Addresses 541 Miroslav Lichvar 542 Red Hat 543 Purkynova 115 544 Brno 612 00 545 Czech Republic 547 Email: mlichvar@redhat.com 548 Aanchal Malhotra 549 Boston University 550 111 Cummington St 551 Boston 02215 552 USA 554 Email: aanchal4@bu.edu