idnits 2.17.1 draft-ietf-ntp-interleaved-modes-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 185 has weird spacing: '... Server t2 ...' -- The document date (June 28, 2018) is 2122 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) == Outdated reference: A later version (-04) exists of draft-ietf-ntp-data-minimization-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 Intended status: Standards Track A. Malhotra 5 Expires: December 30, 2018 Boston University 6 June 28, 2018 8 NTP Interleaved Modes 9 draft-ietf-ntp-interleaved-modes-00 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 December 30, 2018. 38 Copyright Notice 40 Copyright (c) 2018 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 basic client/ 56 server, symmetric, and broadcast mode. The transmit timestamp is one 57 of the four timestamps included in every NTP packet used for time 58 synchronization. A packet that strictly follows RFC 5905, i.e. it 59 contains a transmit timestamp corresponding to the packet itself, is 60 said to be in basic mode. 62 There are, at least, four options where a transmit timestamp can be 63 captured i.e. by NTP daemon, by network drivers, or at the MAC or 64 physical layer of the OSI model. A typical transmit timestamp in a 65 software NTP implementation in the basic mode is the one captured by 66 the NTP daemon using the system clock, before the computation of 67 message digest and before the packet is passed to the operating 68 system, and does not include any processing and queuing delays in the 69 system, network drivers, and hardware. These delays may add a 70 significant error to the offset and network delay measured by clients 71 and peers of the server. 73 For best accuracy, the transmit timestamp should be captured as close 74 to the wire as possible, but that is difficult to implement in the 75 current packet since this timestamp is available only after the 76 packet transmission. The protocol described in RFC 5905 does not 77 specify any mechanism for the server to provide its clients and peers 78 with this more accurate timestamp. 80 Different mechanisms could be used to exchange this more accurate 81 timestamp. This document describes interleaved modes, in which an 82 NTP packet contains a transmit timestamp corresponding to the 83 previous packet that was sent to the client or peer. This transmit 84 timestamp could be captured at one of the any four places mentioned 85 above. More specifically, this document: 87 1. Introduces and specifies a new interleaved client/server mode. 89 2. Specifies the interleaved symmetric mode based on the NTP 90 reference implementation with some modifications. 92 3. Specifies the interleaved broadcast mode based purely on the NTP 93 reference implementation. 95 The protocol does not change the NTP packet header format. Only the 96 semantics of some timestamp fields is different. NTPv4 that supports 97 client/server and broadcast interleaved modes is compatible with 98 NTPv4 without this capability as well as with all previous NTP 99 versions. 101 The protocol requires both servers and clients/peers to keep some 102 state specific to the interleaved mode. It prevents traffic 103 amplification that would be possible if the timestamp was sent in a 104 separate message in order to keep the servers stateless. 106 This document assumes familiarity with RFC 5905. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2. Interleaved Client/server mode 116 The interleaved client/server mode is similar to the basic client/ 117 server mode. The only difference between the two modes is in the 118 meaning of the transmit and origin timestamp fields. 120 A client request in the basic mode has an origin timestamp equal to 121 the transmit timestamp from the previous server response, or is zero. 122 A server response in the basic mode has an origin timestamp equal to 123 the transmit timestamp from the client's request. The transmit 124 timestamps correspond to the packets in which they are included. 126 A client request in the interleaved mode has an origin timestamp 127 equal to the receive timestamp from the previous server response. A 128 server response in the interleaved mode has an origin timestamp equal 129 to the receive timestamp from the client's request. The transmit 130 timestamps correspond to the previous packets that were sent to the 131 server or client. 133 A server which supports the interleaved mode needs to save pairs of 134 local receive and transmit timestamps. The server SHOULD discard old 135 timestamps to limit the amount of memory needed to support clients 136 using the interleaved mode. The server MAY separate the timestamps 137 by IP addresses, but it SHOULD NOT separate them by port numbers, 138 i.e. clients are allowed to change their source port between 139 requests. 141 Both servers and clients that support the interleaved mode MUST NOT 142 send a packet that has a transmit timestamp equal to the receive 143 timestamp in order to reliably detect whether received packets 144 conform to the interleaved mode. 146 When the server receives a request from a client, it SHOULD respond 147 in the interleaved mode if the following conditions are met: 149 1. The request does not have a receive timestamp equal to the 150 transmit timestamp. 152 2. The origin timestamp from the request matches the local receive 153 timestamp of a previous request that the server has saved (for 154 the client if it separates timestamps by IP addresses). 156 A response in the interleaved mode MUST contain the transmit 157 timestamp of the response which contained the receive timestamp 158 matching the origin timestamp from the request. 160 If the conditions are not met, the server MUST NOT respond in the 161 interleaved mode. The server MAY always respond in the basic mode. 162 In any case, the server SHOULD save the new receive and transmit 163 timestamps. 165 The first request from a client is always in the basic mode and so is 166 the server response. It has a zero origin timestamp and zero receive 167 timestamp. Only when the client receives a valid response from the 168 server, it will be able to send a request in the interleaved mode. 169 The client SHOULD limit the number of requests in the interleaved 170 mode per server response to prevent processing of very old timestamps 171 in case a large number of packets is lost. 173 An example of packets in a client/server exchange using the 174 interleaved mode is shown in Figure 1. The packets in the basic and 175 interleaved mode are indicated with B and I respectively. The 176 timestamps t1', t3' and t11' point to the same transmissions as t1, 177 t3 and t11, but they may be less accurate. The first exchange is in 178 the basic mode followed by a second exchange in the interleaved mode. 179 For the third exchange, the client request is in the interleaved 180 mode, but the server response is in the basic mode, because the 181 server did not have the pair of timestamps t6 and t7 (e.g. they were 182 dropped to save timestamps for other clients using the interleaved 183 mode). 185 Server t2 t3 t6 t7 t10 t11 186 -----+----+----------------+----+----------------+----+----- 187 / \ / \ / \ 188 Client / \ / \ / \ 189 --+----------+----------+----------+----------+----------+-- 190 t1 t4 t5 t8 t9 t12 192 Mode: B B I I I B 193 +----+ +----+ +----+ +----+ +----+ +----+ 194 Org | 0 | | t1'| | t2 | | t4 | | t6 | | t5 | 195 Rx | 0 | | t2 | | t4 | | t6 | | t8 | |t10 | 196 Tx | t1'| | t3'| | t1 | | t3 | | t5 | |t11'| 197 +----+ +----+ +----+ +----+ +----+ +----+ 199 Figure 1: Packet timestamps in interleaved client/server mode 201 When the client receives a response from the server, it performs the 202 tests described in RFC 5905. Two of the tests are modified for the 203 interleaved mode: 205 1. The check for duplicate packets SHOULD compare both receive and 206 transmit timestamps in order to not drop a valid response in the 207 interleaved mode if it follows a response in the basic mode and 208 they contain the same transmit timestamp. 210 2. The check for bogus packets SHOULD compare the origin timestamp 211 with both transmit and receive timestamps from the request. If 212 the origin timestamp is equal to the transmit timestamp, the 213 response is in the basic mode. If the origin timestamp is equal 214 to the receive timestamp, the response is in the interleaved 215 mode. 217 The client SHOULD NOT update its NTP state when an invalid response 218 is received to not lose the timestamps which will be needed to 219 complete a measurement when the following response in the interleaved 220 mode is received. 222 If the packet passed the tests and conforms to the interleaved mode, 223 the client can compute the offset and delay using the formulas from 224 RFC 5905 and one of two different sets of timestamps. The first set 225 is RECOMMENDED for clients that filter measurements based on the 226 delay. The corresponding timestamps from Figure 1 are written in 227 parentheses. 229 T1 - local transmit timestamp of the previous request (t1) 231 T2 - remote receive timestamp from the previous response (t2) 232 T3 - remote transmit timestamp from the latest response (t3) 234 T4 - local receive timestamp of the previous response (t4) 236 The second set gives a more accurate measurement of the current 237 offset, but the delay is much more sensitive to a frequency error 238 between the server and client due to a much longer interval between 239 T1 and T4. 241 T1 - local transmit timestamp of the latest request (t5) 243 T2 - remote receive timestamp from the latest response (t6) 245 T3 - remote transmit timestamp from the latest response (t3) 247 T4 - local receive timestamp of the previous response (t4) 249 Clients MAY filter measurements based on the mode. The maximum 250 number of dropped measurements in the basic mode SHOULD be limited in 251 case the server does not support or is not able to respond in the 252 interleaved mode. Clients that filter measurements based on the 253 delay will implicitly prefer measurements in the interleaved mode 254 over the basic mode, because they have a shorter delay due to a more 255 accurate transmit timestamp (T3). 257 The server MAY limit saving of the receive and transmit timestamps to 258 requests which have an origin timestamp specific to the interleaved 259 mode in order to not waste resources on clients using the basic mode. 260 Such an optimization will delay the first interleaved response of the 261 server to a client by one exchange. 263 A check for a non-zero origin timestamp works with clients that 264 implement NTP data minimization [I-D.ietf-ntp-data-minimization]. To 265 detect requests in the basic mode from clients that do not implement 266 the data minimization, the server can encode in low-order bits of the 267 receive and transmit timestamps below precision of the clock a bit 268 indicating whether the timestamp is a receive timestamp. If the 269 server receives a request with a non-zero origin timestamp which does 270 not indicate it is receive timestamp of the server, the request is in 271 the basic mode and it is not necessary to save the new receive and 272 transmit timestamp. 274 3. Interleaved Symmetric mode 276 The interleaved symmetric mode uses the same principles as the 277 interleaved client/server mode. A packet in the interleaved 278 symmetric mode has a transmit timestamp which corresponds to the 279 previous packet sent to the peer and an origin timestamp equal to the 280 receive timestamp from the last packet received from the peer. 282 In order to prevent the peer from matching the transmit timestamp 283 with an incorrect packet when the peers' transmissions do not 284 alternate (e.g. they use different polling intervals) and a previous 285 packet was lost, the use of the interleaved mode in symmetric 286 associations requires additional restrictions. 288 Peers which have an association need to count valid packets received 289 between their transmissions to determine in which mode a packet 290 should be formed. A valid packet in this context is a packet which 291 passed all NTP tests for duplicate, replayed, bogus, and 292 unauthenticated packets. Other received packets may update the NTP 293 state to allow the (re)initialization of the association, but they do 294 not change the selection of the mode. 296 A peer A SHOULD send a peer B a packet in the interleaved mode only 297 when the following conditions are met: 299 1. The peer A has an active association with the peer B which was 300 specified with an option enabling the interleaved mode, OR the 301 peer A received at least one valid packet in the interleaved mode 302 from the peer B. 304 2. The peer A did not send a packet to the peer B since it received 305 the last valid packet from the peer B. 307 3. The previous packet that the peer A sent to the peer B was the 308 only response to a packet received from the peer B. 310 An example of packets exchanged in a symmetric association is shown 311 in Figure 2. The minimum polling interval of the peer A is twice as 312 long as the maximum polling interval of the peer B. The first 313 packets sent by the peers are in the basic mode. The second and 314 third packet sent by the peer A is in the interleaved mode. The 315 second packet sent by the peer B is in the interleaved mode, but the 316 following packets sent by the peer are in the basic mode, because 317 multiple responses are sent per request. 319 Peer A t2 t3 t6 t8 t9 t12 t14 t15 320 -----+--+--------+-----------+--+--------+-----------+--+----- 321 / \ / / \ / / \ 322 Peer B / \ / / \ / / \ 323 --+--------+--+-----------+--------+--+-----------+--------+-- 324 t1 t4 t5 t7 t10 t11 t13 t16 326 Mode: B B I B I B B I 327 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ 328 Org | 0 | | t1'| | t2 | | t3'| | t4 | | t3 | | t3 | |t10 | 329 Rx | 0 | | t2 | | t4 | | t4 | | t8 | |t10 | |t10 | |t14 | 330 Tx | t1'| | t3'| | t1 | | t7'| | t3 | |t11'| |t13'| | t9 | 331 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ 333 Figure 2: Packet timestamps in interleaved symmetric mode 335 If the peer A has no association with the peer B and it responds with 336 symmetric passive packets, it does not need to count the packets in 337 order to meet the restrictions, because each request has at most one 338 response. The peer SHOULD process the requests in the same way as a 339 server which supports the interleaved client/server mode. It MUST 340 NOT respond in the interleaved mode if the request was not in the 341 interleaved mode. 343 The peers SHOULD compute the offset and delay using one the two sets 344 of timestamps specified in the client/server section. They MAY 345 switch between them to minimize the interval between T1 and T4 in 346 order to reduce the error in the measured delay. 348 4. Interleaved Broadcast mode 350 A packet in the interleaved broadcast mode contains two transmit 351 timestamps. One corresponds to the packet itself and is saved in the 352 transmit timestamp field. The other corresponds to the previous 353 packet and is saved in the origin timestamp field. The packet is 354 compatible with the basic mode, which uses a zero origin timestamp. 356 An example of packets sent in the broadcast mode is shown in 357 Figure 3. 359 Server t1 t3 t5 t7 360 ------+------------+------------+------------+--------- 361 \ \ \ \ 362 Client \ \ \ \ 363 ---------+------------+------------+------------+------ 364 t2 t4 t6 t8 366 Mode: B I I I 367 +----+ +----+ +----+ +----+ 368 Org | 0 | | t1 | | t3 | | t5 | 369 Rx | 0 | | 0 | | 0 | | 0 | 370 Tx | t1'| | t3'| | t5'| | t7'| 371 +----+ +----+ +----+ +----+ 373 Figure 3: Packet timestamps in interleaved broadcast mode 375 A client which does not support the interleaved mode ignores the 376 origin timestamp and processes all packets as if they were in the 377 basic mode. 379 A client which supports the interleaved mode SHOULD check if the 380 origin timestamp is not zero to detect packets in the interleaved 381 mode. The client SHOULD also compare the origin timestamp with the 382 transmit timestamp from the previous packet to detect lost packets. 383 If the difference is larger than a specified maximum (e.g. 1 second), 384 the packet SHOULD NOT be used for synchronization. 386 The client SHOULD compute the offset using the origin timestamp from 387 the received packet and the local receive timestamp of the previous 388 packet. If the client needs to measure the network delay, it SHOULD 389 use the interleaved client/server mode. 391 5. Acknowledgements 393 The interleaved modes described in this document are based on the 394 reference NTP implementation written by David Mills. 396 The authors would like to thank Kristof Teichel for his useful 397 comments. 399 6. IANA Considerations 401 This memo includes no request to IANA. 403 7. Security Considerations 405 Security issues that apply to the basic modes apply also to the 406 interleaved modes. They are described in The Security of NTP's 407 Datagram Protocol [SECNTP]. 409 Clients and peers SHOULD NOT leak the receive timestamp in packets 410 sent to other peers or clients (e.g. as a reference timestamp) to 411 prevent off-path attackers from easily getting the origin timestamp 412 needed to make a valid response in the interleaved mode. 414 Clients SHOULD randomize all bits of both receive and transmit 415 timestamps, as recommended for the transmit timestamp in the NTP 416 client data minimization [I-D.ietf-ntp-data-minimization], to make it 417 more difficult for off-path attackers to guess the origin timestamp. 419 Protecting symmetric associations in the interleaved mode against 420 replay attacks is even more difficult than in the basic mode, because 421 the NTP state needs to be protected not only between the reception 422 and transmission in order to send the peer a packet with a valid 423 origin timestamp, but all the time to not lose the timestamps which 424 will be needed to complete a measurement when the following packet in 425 the interleaved mode is received. 427 8. References 429 8.1. Normative References 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, 433 DOI 10.17487/RFC2119, March 1997, 434 . 436 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 437 "Network Time Protocol Version 4: Protocol and Algorithms 438 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 439 . 441 8.2. Informative References 443 [I-D.ietf-ntp-data-minimization] 444 Franke, D. and A. Malhotra, "NTP Client Data 445 Minimization", draft-ietf-ntp-data-minimization-01 (work 446 in progress), July 2017. 448 [SECNTP] Malhotra, A., Gundy, M., Varia, M., Kennedy, H., Gardner, 449 J., and S. Goldberg, "The Security of NTP's Datagram 450 Protocol", 2016, . 452 Authors' Addresses 454 Miroslav Lichvar 455 Red Hat 456 Purkynova 115 457 Brno 612 00 458 Czech Republic 460 Email: mlichvar@redhat.com 462 Aanchal Malhotra 463 Boston University 464 111 Cummington St 465 Boston 02215 466 USA 468 Email: aanchal4@bu.edu