idnits 2.17.1 draft-ietf-ntp-interleaved-modes-02.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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 224 has weird spacing: '... Server t2 ...' -- The document date (May 23, 2019) is 1799 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 517 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: RFC5905 (if approved) A. Malhotra 5 Intended status: Standards Track Boston University 6 Expires: November 24, 2019 May 23, 2019 8 NTP Interleaved Modes 9 draft-ietf-ntp-interleaved-modes-02 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 November 24, 2019. 38 Copyright Notice 40 Copyright (c) 2019 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 1. Introduction 55 RFC 5905 [RFC5905] describes the operations of NTPv4 in a client/ 56 server, symmetric, and broadcast mode. The transmit and receive 57 timestamps are two of the four timestamps included in every NTPv4 58 packet used for time synchronization. 60 For a highly accurate and stable synchronization, the transmit and 61 receive timestamp should be captured close to the beginning of the 62 actual transmission and the end of the reception respectively. An 63 asymmetry in the timestamping causes the offset measured by NTP to 64 have an error. 66 There are at least four options where a timestamp of an NTP packet 67 may be captured with a software NTP implementation running on an 68 operating system: 70 1. User space (software) 72 2. Network device driver or kernel (software) 74 3. Data link layer (hardware - MAC chip) 76 4. Physical layer (hardware - PHY chip) 78 Software timestamps captured in the user space in the NTP 79 implementation itself are least accurate. They do not include system 80 calls used for sending and receiving packets, processing and queuing 81 delays in the system, network device drivers, and hardware. Hardware 82 timestamps captured at the physical layer are most accurate. 84 A transmit timestamp captured in the driver or hardware is more 85 accurate than the user-space timestamp, but it is available to the 86 NTP implementation only after it sent the packet using a system call. 87 The timestamp cannot be included in the packet itself unless the 88 driver or hardware supports NTP and can modify the packet before or 89 during the actual transmission. 91 The protocol described in RFC 5905 does not specify any mechanism for 92 a server to provide its clients and peers with a more accurate 93 transmit timestamp that is known only after the transmission. A 94 packet that strictly follows RFC 5905, i.e. it contains a transmit 95 timestamp corresponding to the packet itself, is said to be in basic 96 mode. 98 Different mechanisms could be used to exchange timestamps known after 99 the transmission. The server could respond to each request with two 100 packets. The second packet would contain the transmit timestamp 101 corresponding to the first packet. However, such a protocol would 102 enable a traffic amplification, or it would use packets with an 103 asymmetric length, which would cause an asymmetry in the network 104 delay and an error in the measured offset. 106 This document describes an interleaved client/server, interleaved 107 symmetric, and interleaved broadcast mode. In these modes, the 108 server sends a single packet, which contains a transmit timestamp 109 corresponding to the previous packet that was sent to the client or 110 peer. This transmit timestamp can be captured at any of the four 111 places mentioned above. Both servers and clients/peers are required 112 to keep some state specific to the interleaved mode. 114 The protocol does not change the NTP packet header format. Only the 115 semantics of some timestamp fields is different. NTPv4 that supports 116 client/server and broadcast interleaved modes is compatible with 117 NTPv4 without this capability as well as with all previous NTP 118 versions. 120 This document assumes familiarity with RFC 5905. 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2. Interleaved Client/server mode 130 The interleaved client/server mode is similar to the basic client/ 131 server mode. The only difference between the two modes is in the 132 meaning of the transmit and origin timestamp fields. 134 A client request in the basic mode has an origin timestamp equal to 135 the transmit timestamp from the previous server response, or is zero. 136 A server response in the basic mode has an origin timestamp equal to 137 the transmit timestamp from the client's request. The transmit 138 timestamps correspond to the packets in which they are included. 140 A client request in the interleaved mode has an origin timestamp 141 equal to the receive timestamp from the previous server response. A 142 server response in the interleaved mode has an origin timestamp equal 143 to the receive timestamp from the client's request. The transmit 144 timestamps correspond to the previous packets that were sent to the 145 server or client. 147 A server which supports the interleaved mode needs to save pairs of 148 local receive and transmit timestamps. The server SHOULD discard old 149 timestamps to limit the amount of memory needed to support clients 150 using the interleaved mode. The server MAY separate the timestamps 151 by IP addresses, but it SHOULD NOT separate them by port numbers, 152 i.e. clients are allowed to change their source port between 153 requests. 155 The server MAY restrict the interleaved mode to specific IP addresses 156 and/or authenticated clients. 158 Both servers and clients that support the interleaved mode MUST NOT 159 send a packet that has a transmit timestamp equal to the receive 160 timestamp in order to reliably detect whether received packets 161 conform to the interleaved mode. 163 The transmit and receive timestamps in server responses need to be 164 unique to prevent two different clients from sending requests with 165 the same origin timestamp and the server responding in the 166 interleaved mode with an incorrect transmit timestamp. If the 167 timestamps are not guaranteed to be monotonically increasing, the 168 server SHOULD check that the transmit and receive timestamp is not 169 already saved as a receive timestamp of a previous request (from the 170 same IP address if the server separates timestamps by addresses), and 171 generate a new timestamp if necessary. 173 When the server receives a request from a client, it SHOULD respond 174 in the interleaved mode if the following conditions are met: 176 1. The request does not have a receive timestamp equal to the 177 transmit timestamp. 179 2. The origin timestamp from the request matches the local receive 180 timestamp of a previous request that the server has saved (for 181 the IP address if it separates timestamps by addresses). 183 A response in the interleaved mode MUST contain the transmit 184 timestamp of the response which contained the receive timestamp 185 matching the origin timestamp from the request. The server SHOULD 186 drop the timestamps after sending the response. The receive 187 timestamp MUST NOT be used again to detect a request conforming to 188 the interleaved mode. 190 If the conditions are not met, the server MUST NOT respond in the 191 interleaved mode. The server MAY always respond in the basic mode. 192 In any case, the server SHOULD save the new receive and transmit 193 timestamps. 195 The first request from a client is always in the basic mode and so is 196 the server response. It has a zero origin timestamp and zero receive 197 timestamp. Only when the client receives a valid response from the 198 server, it will be able to send a request in the interleaved mode. 200 The protocol recovers from packet loss. When a client request or 201 server response is lost, the client will use the same origin 202 timestamp in the next request. The server can respond in the 203 interleaved mode if it still has the timestamps corresponding to the 204 origin timestamp. If the server already responded to the timestamp 205 in the interleaved mode, or it had to drop the timestamps for other 206 reasons, it will respond in the basic mode and save new timestamps, 207 which will enable an interleaved response to the following request. 208 The client SHOULD limit the number of requests in the interleaved 209 mode between server responses to prevent processing of very old 210 timestamps in case a large number of consecutive requests is lost. 212 An example of packets in a client/server exchange using the 213 interleaved mode is shown in Figure 1. The packets in the basic and 214 interleaved mode are indicated with B and I respectively. The 215 timestamps t1', t3' and t11' point to the same transmissions as t1, 216 t3 and t11, but they may be less accurate. The first exchange is in 217 the basic mode followed by a second exchange in the interleaved mode. 218 For the third exchange, the client request is in the interleaved 219 mode, but the server response is in the basic mode, because the 220 server did not have the pair of timestamps t6 and t7 (e.g. they were 221 dropped to save timestamps for other clients using the interleaved 222 mode). 224 Server t2 t3 t6 t7 t10 t11 225 -----+----+----------------+----+----------------+----+----- 226 / \ / \ / \ 227 Client / \ / \ / \ 228 --+----------+----------+----------+----------+----------+-- 229 t1 t4 t5 t8 t9 t12 231 Mode: B B I I I B 232 +----+ +----+ +----+ +----+ +----+ +----+ 233 Org | 0 | | t1'| | t2 | | t4 | | t6 | | t5 | 234 Rx | 0 | | t2 | | t4 | | t6 | | t8 | |t10 | 235 Tx | t1'| | t3'| | t1 | | t3 | | t5 | |t11'| 236 +----+ +----+ +----+ +----+ +----+ +----+ 238 Figure 1: Packet timestamps in interleaved client/server mode 240 When the client receives a response from the server, it performs the 241 tests described in RFC 5905. Two of the tests are modified for the 242 interleaved mode: 244 1. The check for duplicate packets SHOULD compare both receive and 245 transmit timestamps in order to not drop a valid response in the 246 interleaved mode if it follows a response in the basic mode and 247 they contain the same transmit timestamp. 249 2. The check for bogus packets SHOULD compare the origin timestamp 250 with both transmit and receive timestamps from the request. If 251 the origin timestamp is equal to the transmit timestamp, the 252 response is in the basic mode. If the origin timestamp is equal 253 to the receive timestamp, the response is in the interleaved 254 mode. 256 The client SHOULD NOT update its NTP state when an invalid response 257 is received to not lose the timestamps which will be needed to 258 complete a measurement when the following response in the interleaved 259 mode is received. 261 If the packet passed the tests and conforms to the interleaved mode, 262 the client can compute the offset and delay using the formulas from 263 RFC 5905 and one of two different sets of timestamps. The first set 264 is RECOMMENDED for clients that filter measurements based on the 265 delay. The corresponding timestamps from Figure 1 are written in 266 parentheses. 268 T1 - local transmit timestamp of the previous request (t1) 270 T2 - remote receive timestamp from the previous response (t2) 272 T3 - remote transmit timestamp from the latest response (t3) 274 T4 - local receive timestamp of the previous response (t4) 276 The second set gives a more accurate measurement of the current 277 offset, but the delay is much more sensitive to a frequency error 278 between the server and client due to a much longer interval between 279 T1 and T4. 281 T1 - local transmit timestamp of the latest request (t5) 283 T2 - remote receive timestamp from the latest response (t6) 285 T3 - remote transmit timestamp from the latest response (t3) 287 T4 - local receive timestamp of the previous response (t4) 289 Clients MAY filter measurements based on the mode. The maximum 290 number of dropped measurements in the basic mode SHOULD be limited in 291 case the server does not support or is not able to respond in the 292 interleaved mode. Clients that filter measurements based on the 293 delay will implicitly prefer measurements in the interleaved mode 294 over the basic mode, because they have a shorter delay due to a more 295 accurate transmit timestamp (T3). 297 The server MAY limit saving of the receive and transmit timestamps to 298 requests which have an origin timestamp specific to the interleaved 299 mode in order to not waste resources on clients using the basic mode. 300 Such an optimization will delay the first interleaved response of the 301 server to a client by one exchange. 303 A check for a non-zero origin timestamp works with clients that 304 implement NTP data minimization [I-D.ietf-ntp-data-minimization]. To 305 detect requests in the basic mode from clients that do not implement 306 the data minimization, the server can encode in low-order bits of the 307 receive and transmit timestamps below precision of the clock a bit 308 indicating whether the timestamp is a receive timestamp. If the 309 server receives a request with a non-zero origin timestamp which does 310 not indicate it is a receive timestamp of the server, the request is 311 in the basic mode and it is not necessary to save the new receive and 312 transmit timestamp. 314 3. Interleaved Symmetric mode 316 The interleaved symmetric mode uses the same principles as the 317 interleaved client/server mode. A packet in the interleaved 318 symmetric mode has a transmit timestamp which corresponds to the 319 previous packet sent to the peer and an origin timestamp equal to the 320 receive timestamp from the last packet received from the peer. 322 In order to prevent the peer from matching the transmit timestamp 323 with an incorrect packet when the peers' transmissions do not 324 alternate (e.g. they use different polling intervals) and a previous 325 packet was lost, the use of the interleaved mode in symmetric 326 associations requires additional restrictions. 328 Peers which have an association need to count valid packets received 329 between their transmissions to determine in which mode a packet 330 should be formed. A valid packet in this context is a packet which 331 passed all NTP tests for duplicate, replayed, bogus, and 332 unauthenticated packets. Other received packets may update the NTP 333 state to allow the (re)initialization of the association, but they do 334 not change the selection of the mode. 336 A peer A SHOULD send a peer B a packet in the interleaved mode only 337 when the following conditions are met: 339 1. The peer A has an active association with the peer B which was 340 specified with an option enabling the interleaved mode, OR the 341 peer A received at least one valid packet in the interleaved mode 342 from the peer B. 344 2. The peer A did not send a packet to the peer B since it received 345 the last valid packet from the peer B. 347 3. The previous packet that the peer A sent to the peer B was the 348 only response to a packet received from the peer B. 350 An example of packets exchanged in a symmetric association is shown 351 in Figure 2. The minimum polling interval of the peer A is twice as 352 long as the maximum polling interval of the peer B. The first 353 packets sent by the peers are in the basic mode. The second and 354 third packet sent by the peer A is in the interleaved mode. The 355 second packet sent by the peer B is in the interleaved mode, but the 356 following packets sent by the peer are in the basic mode, because 357 multiple responses are sent per request. 359 Peer A t2 t3 t6 t8 t9 t12 t14 t15 360 -----+--+--------+-----------+--+--------+-----------+--+----- 361 / \ / / \ / / \ 362 Peer B / \ / / \ / / \ 363 --+--------+--+-----------+--------+--+-----------+--------+-- 364 t1 t4 t5 t7 t10 t11 t13 t16 366 Mode: B B I B I B B I 367 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ 368 Org | 0 | | t1'| | t2 | | t3'| | t4 | | t3 | | t3 | |t10 | 369 Rx | 0 | | t2 | | t4 | | t4 | | t8 | |t10 | |t10 | |t14 | 370 Tx | t1'| | t3'| | t1 | | t7'| | t3 | |t11'| |t13'| | t9 | 371 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ 373 Figure 2: Packet timestamps in interleaved symmetric mode 375 If the peer A has no association with the peer B and it responds with 376 symmetric passive packets, it does not need to count the packets in 377 order to meet the restrictions, because each request has at most one 378 response. The peer SHOULD process the requests in the same way as a 379 server which supports the interleaved client/server mode. It MUST 380 NOT respond in the interleaved mode if the request was not in the 381 interleaved mode. 383 The peers SHOULD compute the offset and delay using one the two sets 384 of timestamps specified in the client/server section. They MAY 385 switch between them to minimize the interval between T1 and T4 in 386 order to reduce the error in the measured delay. 388 4. Interleaved Broadcast mode 390 A packet in the interleaved broadcast mode contains two transmit 391 timestamps. One corresponds to the packet itself and is saved in the 392 transmit timestamp field. The other corresponds to the previous 393 packet and is saved in the origin timestamp field. The packet is 394 compatible with the basic mode, which uses a zero origin timestamp. 396 An example of packets sent in the broadcast mode is shown in 397 Figure 3. 399 Server t1 t3 t5 t7 400 ------+------------+------------+------------+--------- 401 \ \ \ \ 402 Client \ \ \ \ 403 ---------+------------+------------+------------+------ 404 t2 t4 t6 t8 406 Mode: B I I I 407 +----+ +----+ +----+ +----+ 408 Org | 0 | | t1 | | t3 | | t5 | 409 Rx | 0 | | 0 | | 0 | | 0 | 410 Tx | t1'| | t3'| | t5'| | t7'| 411 +----+ +----+ +----+ +----+ 413 Figure 3: Packet timestamps in interleaved broadcast mode 415 A client which does not support the interleaved mode ignores the 416 origin timestamp and processes all packets as if they were in the 417 basic mode. 419 A client which supports the interleaved mode SHOULD check if the 420 origin timestamp is not zero to detect packets in the interleaved 421 mode. The client SHOULD also compare the origin timestamp with the 422 transmit timestamp from the previous packet to detect lost packets. 423 If the difference is larger than a specified maximum (e.g. 1 second), 424 the packet SHOULD NOT be used for synchronization. 426 The client SHOULD compute the offset using the origin timestamp from 427 the received packet and the local receive timestamp of the previous 428 packet. If the client needs to measure the network delay, it SHOULD 429 use the interleaved client/server mode. 431 5. Acknowledgements 433 The interleaved modes described in this document are based on the 434 implementation written by David Mills in the NTP project [1]. The 435 specification of the broadcast mode is based purely on this 436 implementation. The specification of the symmetric mode has some 437 modifications. The client/server mode is specified as a new mode 438 compatible with the symmetric mode, similarly to the basic symmetric 439 and client/server modes. 441 The authors would like to thank Tal Mizrahi, Steven Sommars, Harlan 442 Stenn, and Kristof Teichel for their useful comments. 444 6. IANA Considerations 446 This memo includes no request to IANA. 448 7. Security Considerations 450 The security considerations of time protocols in general are 451 discussed in RFC 7384 [RFC7384], and specifically the security 452 considerations of NTP are discussed in RFC 5905. 454 Security issues that apply to the basic modes apply also to the 455 interleaved modes. They are described in The Security of NTP's 456 Datagram Protocol [SECNTP]. 458 Clients and peers SHOULD NOT leak the receive timestamp in packets 459 sent to other peers or clients (e.g. as a reference timestamp) to 460 prevent off-path attackers from easily getting the origin timestamp 461 needed to make a valid response in the interleaved mode. 463 Clients using the interleaved mode SHOULD randomize all bits of both 464 receive and transmit timestamps, as recommended for the transmit 465 timestamp in the NTP client data minimization 466 [I-D.ietf-ntp-data-minimization], to make it more difficult for off- 467 path attackers to guess the origin timestamp. It is not possible to 468 zero the origin timestamp to prevent passive observers from easily 469 tracking clients moving between different networks. 471 Attackers can force the server to drop its timestamps in order to 472 prevent clients from getting an interleaved response. They can send 473 a large number of requests, send requests with a spoofed source 474 address, or replay an authenticated request if the interleaved mode 475 is enabled only for authenticated clients. Clients SHOULD NOT rely 476 on servers to be able to respond in the interleaved mode. 478 Protecting symmetric associations in the interleaved mode against 479 replay attacks is even more difficult than in the basic mode. The 480 NTP state needs to be protected not only between the reception and 481 transmission in order to send the peer a packet with a valid origin 482 timestamp, but all the time to not lose the timestamps which will be 483 needed to complete a measurement when the following packet in the 484 interleaved mode is received. 486 8. References 488 8.1. Normative References 490 [I-D.ietf-ntp-data-minimization] 491 Franke, D. and A. Malhotra, "NTP Client Data 492 Minimization", draft-ietf-ntp-data-minimization-04 (work 493 in progress), March 2019. 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, 497 DOI 10.17487/RFC2119, March 1997, 498 . 500 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 501 "Network Time Protocol Version 4: Protocol and Algorithms 502 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 503 . 505 8.2. Informative References 507 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 508 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 509 October 2014, . 511 [SECNTP] Malhotra, A., Gundy, M., Varia, M., Kennedy, H., Gardner, 512 J., and S. Goldberg, "The Security of NTP's Datagram 513 Protocol", 2016, . 515 8.3. URIs 517 [1] http://www.ntp.org 519 Authors' Addresses 521 Miroslav Lichvar 522 Red Hat 523 Purkynova 115 524 Brno 612 00 525 Czech Republic 527 Email: mlichvar@redhat.com 528 Aanchal Malhotra 529 Boston University 530 111 Cummington St 531 Boston 02215 532 USA 534 Email: aanchal4@bu.edu