idnits 2.17.1 draft-mlichvar-ntp-correction-field-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 : ---------------------------------------------------------------------------- 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 (June 18, 2018) is 2138 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-11 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 June 18, 2018 5 Expires: December 20, 2018 7 NTP Correction Field 8 draft-mlichvar-ntp-correction-field-02 10 Abstract 12 This document specifies an extension field for the Network Time 13 Protocol (NTP) which improves resolution of specific fields in the 14 NTP header and allows network devices such as switches and routers to 15 modify NTP packets with corrections to improve accuracy of the 16 synchronization in the network. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 20, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 Processing and queueing delays in network switches and routers may be 53 a significant source of jitter and asymmetry in network delay, which 54 has a negative impact on accuracy and stability of clocks 55 synchronized by NTP [RFC5905]. 57 If all network devices on the paths between NTP clients and servers 58 implemented NTP and supported an operation as a server and client, 59 the impact of the delays could be avoided by configuring NTP to make 60 measurements only between devices and hosts that are directly 61 connected to one another. In the Precision Time Protocol (PTP) 62 [IEEE1588], which is a different protocol for synchronization of 63 clocks in networks, such devices are called Boundary Clocks (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 a similar correction in forwarded NTP packets. 76 To better support a highly accurate synchronization, the extension 77 field also improves resolution of the following fields in the NTP 78 header: root delay, root dispersion, receive timestamp, transmit 79 timestamp. 81 1.1. Requirements Language 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 2. Format of Correction Field 89 The Correction Field is an NTP extension field following RFC 7822 90 [RFC7822]. The format of the extension field is shown in Figure 1. 92 0 1 2 3 93 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 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Field Type | Length (28) | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Root Delay Correction | Root Dispersion Correction | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Receive Corr. | Transmit Corr.| | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 101 | Origin Correction | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Origin ID | | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 105 | Delay Correction | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Path ID | Checksum complement | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 Figure 1: Format of Correction Field 112 The extension field has the following fields: 114 Field Type 115 The type which identifies the Correction extension field. 116 TBD 118 Length 119 The length of the extension field, which is 28 octets. 121 Root Delay Correction 122 A 16-bit extension of the root delay in the NTP header 123 increasing its resolution. The extended root delay has 16 124 integer bits and 32 fractional bits. 126 Root Dispersion Correction 127 A 16-bit extension of the root dispersion in the NTP header 128 increasing its resolution. The extended root dispersion has 129 16 integer bits and 32 fractional bits. 131 Receive Correction 132 An 8-bit extension of the receive timestamp in the NTP header 133 increasing its resolution. The extended receive timestamp 134 has 32 integer bits and 40 fractional bits. 136 Transmit Correction 137 An 8-bit extension of the transmit timestamp in the NTP 138 header increasing its resolution. The extended transmit 139 timestamp has 32 integer bits and 40 fractional bits. 141 Origin Correction 142 A field which contains a copy of the final delay correction 143 from the previous packet in the NTP exchange. 145 Origin ID 146 A field which contains a copy of the final path ID from the 147 previous packet in the NTP exchange. 149 Delay Correction 150 A signed fixed-point number of seconds with 8 integer bits 151 and 40 fractional bits, which represents the current 152 correction of the network delay that has accumulated for this 153 packet on the path from the source to the destination. 155 Path ID 156 A 16-bit identification number of the path where the delay 157 correction was updated. 159 Checksum Complement 160 A field which can be modified to not change the UDP checksum 161 after updating the other fields. The same field is described 162 in RFC 7821 [RFC7821]. 164 3. Network devices 166 A network device which is forwarding a packet and supports the 167 Correction Field MUST NOT modify the packet unless all of the 168 following applies: 170 1. The packet is an IPv4 or IPv6 UDP packet. 172 2. The source port or destination port is 123. 174 3. The NTP version is 4. 176 4. The NTP mode is 1, 2, 3, 4, or 5. 178 5. The format of the packet is valid per RFC 7822. 180 6. The packet contains an extension field which has a type of TBD 181 and length of 28 octets. 183 The device SHOULD add to the current value in the delay correction 184 field the length of an interval between the reception and 185 transmission of the packet. If the packet is transmitted at the same 186 speed as it was received and the length of the packet does not change 187 (e.g. due to adding or removing a VLAN tag), the beginning and end of 188 the interval may correspond to any point of the reception and 189 transmission as long as it is consistent for all forwarded packets of 190 the same length. If the transmission speed or length of the packet 191 is different, the beginning and end of the interval SHOULD correspond 192 to the end of the reception and beginning of the transmission 193 respectively. 195 If the transmission starts before the reception ends, a negative 196 value may need to be added to the delay correction. The end of the 197 reception SHOULD be determined using the length field of the UDP 198 header and the speed at which the packet is received. 200 If the device updates the delay correction, it SHOULD also add the 201 identification numbers of the incoming and outgoing port to the path 202 ID. 204 If the device modified any field of the extension field, it MUST 205 update the checksum complement field in order to keep the current UDP 206 checksum valid, or update the UDP checksum itself. 208 4. NTP hosts 210 When an NTP client sends a request to a server and the association is 211 configured to use the Correction Field, it SHOULD add the extension 212 field to the packet. All fields of the extension field except type 213 and length SHOULD be set to zero. 215 When the server receives a packet which includes the extension field, 216 the response SHOULD also include the extension field. 218 The server SHOULD use the root delay and root dispersion correction 219 fields to save additional bits of the root delay and dispersion below 220 the resolution of the 32-bit fixed-point fields in the NTP header. 221 These corrections allow the server to provide the client with root 222 delay and root dispersion in resolution of about 1/4 of a nanosecond. 224 If the server's clock has a better precision than resolution of the 225 64-bit NTP timestamp format, the server SHOULD save the additional 226 bits in the receive and transmit correction fields and set the 227 precision field to the corresponding number, which is smaller than 228 -32. Otherwise, the receive and transmit correction fields SHOULD be 229 zero. 231 The origin correction and origin ID fields SHOULD be set to the delay 232 correction and path ID from the request. The other fields of the 233 Correction Field SHOULD be zero. 235 When the client receives a response which contains the extension 236 field, it SHOULD check the value of both the origin and delay 237 correction fields. If a correction is larger than a specified 238 maximum (e.g. 1 second), the extension field SHOULD be ignored. 240 The client MAY log a warning if the origin ID and path ID are not 241 equal, which indicates the network path between the server and client 242 is not symmetric. 244 The client SHOULD extend the root delay and root dispersion from the 245 NTP header with bits from the root delay and root dispersion 246 correction fields respectively. 248 If the client's clock has a better precision than resolution of the 249 64-bit NTP format and the precision field in the response contains a 250 number smaller than -32, the client SHOULD extend the receive and 251 transmit timestamp from the NTP header with the additional bits from 252 the receive and transmit correction fields respectively. 254 When the client computes the offset and delay using the formulas from 255 RFC 5905, the origin correction is subtracted from the receive 256 timestamp and the delay correction is added to the transmit 257 timestamp. 259 An NTP peer follows the rules of both servers and clients. It 260 processes Correction Fields in received packets as a client and sends 261 Correction Fields as a server. A packet which has a zero origin 262 timestamp (i.e. it is not a response to a request) SHOULD have a zero 263 origin correction and zero origin ID in the Correction Field. 265 A broadcast server using the Correction Field SHOULD always set the 266 origin correction and origin ID fields to zero. 268 5. Acknowledgements 270 The Correction Field extension is based on the PTP correction field 271 specified in IEEE 1588-2008. 273 The author would like to thank Tal Mizrahi and Harlan Stenn for their 274 useful comments. 276 6. IANA Considerations 278 IANA is requested to allocate an Extension Field Type for the 279 Correction Field. 281 7. Security Considerations 283 NTP packets including the Correction Field cannot be authenticated by 284 a legacy MAC, because the MAC has to cover all extension fields in 285 the packet and devices which are supposed to modify the field are not 286 able to update the MAC. 288 It is recommended to authenticate NTP packets using an authentication 289 extension field, e.g. the NTS Authenticator and Encrypted Extensions 290 [I-D.ietf-ntp-using-nts-for-ntp] extension field, and add the 291 Correction Field to the packet after the authentication field. 293 A man-in-the-middle attacker can delay packets in the network in 294 order to increase the measured delay and shift the measured offset by 295 up to half of the extra delay. If the packets contain the Correction 296 Field, the attacker can reduce the delay calculated by the client or 297 peer and shift the offset even more. The maximum correction should 298 be limited (e.g. to 1 second) to prevent the attacker from injecting 299 a larger offset to the measurements. 301 8. References 303 8.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 311 "Network Time Protocol Version 4: Protocol and Algorithms 312 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 313 . 315 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 316 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 317 March 2016, . 319 8.2. Informative References 321 [I-D.ietf-ntp-using-nts-for-ntp] 322 Franke, D., Sibold, D., and K. Teichel, "Network Time 323 Security for the Network Time Protocol", draft-ietf-ntp- 324 using-nts-for-ntp-11 (work in progress), March 2018. 326 [IEEE1588] 327 IEEE std. 1588-2008, "IEEE Standard for a Precision Clock 328 Synchronization Protocol for Networked Measurement and 329 Control Systems", 2008. 331 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 332 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 333 2016, . 335 Author's Address 337 Miroslav Lichvar 338 Red Hat 339 Purkynova 115 340 Brno 612 00 341 Czech Republic 343 Email: mlichvar@redhat.com