idnits 2.17.1 draft-mlichvar-ntp-correction-field-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 -- The document date (October 30, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-ntp-using-nts-for-ntp-09 Summary: 0 errors (**), 0 flaws (~~), 2 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: Experimental October 30, 2017 5 Expires: May 3, 2018 7 NTP Correction Field 8 draft-mlichvar-ntp-correction-field-00 10 Abstract 12 This document specifies an extension field for the Network Time 13 Protocol (NTP) which allows network devices such as switches and 14 routers to modify NTP packets with corrections to improve accuracy of 15 the synchronization in the network. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 3, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 Processing and queueing delays in network switches and routers may be 52 a significant source of jitter and asymmetry in network delay, which 53 has a negative impact on accuracy and stability of synchronization of 54 clocks in local networks using NTP [RFC5905]. 56 If all network devices on the paths between NTP clients and servers 57 implemented NTP and supported an operation as a server and client, 58 the impact of the delays could be avoided by configuring NTP to make 59 measurements only between devices and hosts that are directly 60 connected to one another. In the Precision Time Protocol (PTP) 61 [IEEE1588], which is a different protocol for synchronization of 62 clocks in networks, such devices would be called Boundary Clocks 63 (BC). 65 A different approach supported by PTP to improve the accuracy uses 66 Transparent Clocks (TC). Instead of fully implementing PTP in order 67 to support an operation as a BC, the devices only modify a correction 68 field in forwarded PTP packets with the time that the packets had to 69 wait for transmission. The final value of the correction is included 70 in the calculation of the delay and offset, which may significantly 71 improve the accuracy and stability of the synchronization. 73 This document describes an NTP extension field which allows the 74 devices to make similar correction in forwarded NTP packets. 76 1.1. Requirements Language 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 2. Format of Correction Field 84 The Correction Field is an NTP extension field following RFC 7822 85 [RFC7822]. The format of the extension field is shown in Figure 1. 87 0 1 2 3 88 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | Field Type | Length (28) | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 | Receive Correction | Transmit Correction | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | | 95 | Origin Correction | 96 | | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | | 99 | Delay Correction | 100 | | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Origin ID | Path ID | Checksum complement | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 Figure 1: Format of Correction Field 107 The extension field has the following fields: 109 Field Type 110 The type which identifies the Correction extension field. 111 TBD 113 Length 114 The length of the extension field, which is 28 octets. 116 Receive Correction 117 A 16-bit extension of the receive timestamp in the NTP 118 header. 120 Transmit Correction 121 A 16-bit extension of the transmit timestamp in the NTP 122 header. 124 Origin Correction 125 A field which contains a copy of the final delay correction 126 from the previous packet in the NTP exchange. 128 Delay Correction 129 A fixed point number with 16 unsigned integer bits and 48 130 fractional bits, which represents the current correction of 131 the network delay that has accumulated for this packet on the 132 path from the source to the destination. 134 Origin ID 135 A field which contains a copy of the final path ID from the 136 previous packet in the NTP exchange. 138 Path ID 139 An 8-bit identification number of the path where the delay 140 correction was updated. 142 Checksum Complement 143 A field which can be modified to not change the UDP checksum 144 after updating the other fields. The same field is described 145 in RFC 7821 [RFC7821]. 147 3. Network devices 149 A network device which is forwarding a packet and supports the 150 Correction Field MUST NOT modify the packet unless all of the 151 following applies: 153 1. The packet is an IPv4 or IPv6 UDP packet. 155 2. The source port or destination port is 123. 157 3. The NTP version is 4. 159 4. The NTP mode is 1, 2, 3, 4, or 5. 161 5. The format of the packet is valid per RFC 7822. 163 6. The packet contains an extension field which has a type of TBD 164 and length of 28 octets. 166 The device SHOULD add to the delay correction field of the extension 167 field the time difference between the following points: 169 1. The end of the reception (trailer timestamp). 171 2. The beginning of the transmission (preamble timestamp). 173 If the device updates the delay correction, it SHOULD also add the 174 identification numbers of the incoming and outgoing port to the path 175 ID. 177 The device MAY update the checksum complement field in order to keep 178 the UDP checksum valid. 180 TBD: Requirements on frequency accuracy of the clock. 182 4. NTP hosts 184 When an NTP client sends a request to a server and the association is 185 configured to use the Correction Field, it SHOULD add the extension 186 field to the packet. All fields of the extension field except type 187 and length SHOULD be set to zero. 189 When the server receives a packet which includes the extension field, 190 the response SHOULD also include the extension field. 192 If the server's clock has a better precision than resolution of the 193 64-bit NTP timestamp format, the server SHOULD save the additional 194 bits in the receive and transmit correction fields and set the 195 precision field to the corresponding number, which is smaller than 196 -32. Otherwise, the receive and transmit correction fields SHOULD be 197 zero. 199 The origin correction and origin path ID SHOULD be set to the delay 200 correction and path ID from the request. The other fields of the 201 Correction Field SHOULD be zero. 203 When the client receives a response which contains the extension 204 field, it SHOULD check the value of both the origin and delay 205 correction fields. If a correction is larger than a specified 206 maximum (e.g. 1 second), the extension field SHOULD be ignored. 208 The client MAY log a warning if the origin ID and path ID are not 209 equal, which indicates the network path between the server and client 210 is not symmetric. 212 If the client's clock has a better precision than resolution of the 213 64-bit NTP format and the precision field in the response contains a 214 number smaller than -32, the client SHOULD extend the receive and 215 transmit timestamps with the additional bits in the receive and 216 transmit correction fields. 218 When the client computes the offset and delay using the formulas from 219 RFC 5905, the origin correction is substracted from the receive 220 timestamp and the delay correction is added to the transmit 221 timestamp. 223 TBD: Other modes. 225 5. Acknowledgements 227 The Correction Field extension is based on the PTP correction field 228 specified in IEEE 1588-2008. 230 6. IANA Considerations 232 IANA is requested to allocate an Extension Field Type for the 233 Correction Field. 235 7. Security Considerations 237 Packets using the Correction Field cannot be authenticated by legacy 238 MACs, because network devices which are supposed to update the field 239 do not have access to the key. 241 Packets can be partially protected if the Correction Field is placed 242 in the packet after an authentication extension field, e.g. the NTS 243 Authenticator and Encrypted Extensions extension field 244 [I-D.ietf-ntp-using-nts-for-ntp]. 246 A man-in-the-middle attacker can delay packets in the network in 247 order to increase the measured delay and shift the measured offset by 248 up to half of the extra delay. If the packets contain the Correction 249 Field, the attacker can reduce the delay calculated by the client or 250 peer and shift the offset even more. The maximum correction should 251 be limited (e.g. to 1 second) to prevent the attacker from injecting 252 a larger offset to the measurements. 254 8. References 256 8.1. Normative References 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 264 "Network Time Protocol Version 4: Protocol and Algorithms 265 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 266 . 268 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 269 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 270 March 2016, . 272 8.2. Informative References 274 [I-D.ietf-ntp-using-nts-for-ntp] 275 Franke, D., Sibold, D., and K. Teichel, "Network Time 276 Security for the Network Time Protocol", draft-ietf-ntp- 277 using-nts-for-ntp-09 (work in progress), June 2017. 279 [IEEE1588] 280 IEEE std. 1588-2008, "IEEE Standard for a Precision Clock 281 Synchronization Protocol for Networked Measurement and 282 Control Systems", 2008. 284 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 285 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 286 2016, . 288 Author's Address 290 Miroslav Lichvar 291 Red Hat 292 Purkynova 115 293 Brno 612 00 294 Czech Republic 296 Email: mlichvar@redhat.com