idnits 2.17.1 draft-mizrahi-ntp-checksum-trailer-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 (April 15, 2014) is 3662 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'NTP' is mentioned on line 167, but not defined ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NTP Working Group Tal Mizrahi 2 Internet Draft Marvell 3 Intended status: Experimental 4 Expires: October 2014 April 15, 2014 6 Using UDP Checksum Trailers in the Network Time Protocol (NTP) 7 draft-mizrahi-ntp-checksum-trailer-02.txt 9 Abstract 11 The Network Time Protocol (NTP) allows clients to synchronize to a 12 time server using timestamped protocol messages. To faciliate 13 accurate timestamping, some implementations use hardware-based 14 timestamping engines that integrate the accurate transmission time 15 into every outgoing NTP packet during transmission. Since these 16 packets are transported over UDP, the UDP checksum field is then 17 updated to reflect this modification. This document proposes an 18 extension field that includes a 2-octet Checksum Trailer, allowing 19 timestamping engines to reflect the checksum modification in the last 20 2 octets of the packet rather than in the UDP checksum field. The 21 behavior defined in this document is interoperable with existing NTP 22 implementations. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on October 15, 2014. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction ................................................. 2 65 1.1. Intermediate Entities ................................... 3 66 1.2. Updating the UDP Checksum ............................... 5 67 2. Conventions used in this document ............................ 5 68 2.1. Terminology ............................................. 5 69 2.2. Abbreviations ........................................... 6 70 3. Using UDP Checksum Trailers in NTP ........................... 6 71 3.1. Overview ................................................ 6 72 3.2. Checksum Trailer in NTP Packets ......................... 6 73 3.2.1. Transmission of NTP with Checksum Trailer........... 8 74 3.2.2. Intermediate Updates of NTP with Checksum Trailer .. 8 75 3.2.3. Reception of NTP with Checksum Trailer ............. 8 76 3.3. Interoperability with Existing Implementations........... 8 77 3.4. Using the Checksum Trailer with or without Authentication 8 78 4. Security Considerations ...................................... 9 79 5. IANA Considerations .......................................... 9 80 6. Acknowledgments .............................................. 9 81 7. References ................................................... 9 82 7.1. Normative References .................................... 9 83 7.2. Informative References ................................. 10 85 1. Introduction 87 The Network Time Protocol [NTPv4] allows clients to synchronize their 88 clocks to a time server by exchanging NTP packets. The increasing 89 demand for highly accurate clock synchronization motivates 90 implementations that provide accurate timestamping. 92 1.1. Intermediate Entities 94 In this document we use the term 'intermediate entity', referring to 95 an entity that reside on the path between the sender and the receiver 96 of an NTP packet, that modifies this NTP packet en-route. Two 97 examples of intermediate entities are presented below. 99 In order to facilitate accurate timestamping, an implementation MAY 100 use a hardware based timestamping engine, as shown in Figure 1. In 101 such cases, NTP packets are sent and received by a software layer, 102 whereas a timestamping engine modifies every outgoing NTP packet by 103 incorporating its accurate transmission time into the field in the packet. 106 NTP client/server 107 +-------------------+ 108 | | 109 | +-----------+ | 110 Software | | NTP | | 111 | | protocol | | 112 | +-----+-----+ | 113 | | | 114 | +-----+-----+ | 115 | | Accurate | | 116 ASIC/FPGA | | Timestamp | | 117 | | engine | | 118 | +-----------+ | 119 | | | 120 +---------+---------+ 121 | 122 |NTP packets 123 | 124 ___ v _ 125 / \_/ \__ 126 / \_ 127 / IP / 128 \_ Network / 129 / \ 130 \__/\_ ___/ 131 \_/ 133 Figure 1 Accurate Timestamping in NTP 135 The accuracy of clock synchronization over packet networks is highly 136 sensitive to delay jitters in the underlying network, which 137 dramatically affects the clock accuracy. To address this challenge, 138 the Precision Time Protocol (PTP) [IEEE1588] defines Transparent 139 Clocks (TCs), intermediate switches and routers that improve the end- 140 to-end accuracy by updating a "Correction Field" in the PTP packet by 141 adding the latency caused by the current TC. In NTP no equivalent 142 entity is currently defined, but future versions of NTP may define an 143 intermediate node that modifies en-route NTP packets using a 144 "Correction Field". 146 1.2. Updating the UDP Checksum 148 When the UDP payload is modified by an intermediate entity, the UDP 149 Checksum field needs to be updated to maintain its correctness. When 150 using UDP over IPv4 ([UDP]), an intermediate entity can assign a 151 value of zero in the checksum field, causing the receiver to ignore 152 the checksum field. UDP over IPv6, as defined in [IPv6], does not 153 allow a zero checksum, and requires the UDP checksum field to contain 154 a correct checksum of the UDP payload. 156 Since an intermediate entity only modifies a specific field in the 157 packet, i.e. the timestamp field, the UDP checksum update can be 158 performed incrementally, using the concepts presented in [Checksum]. 160 A similar problem is addressed in Annex E of [IEEE1588]. When the 161 Precision Time Protocol (PTP) is transported over IPv6, two octets 162 are appended to the end of the PTP payload for UDP checksum updates. 163 The value of these two octets can be updated by an intermediate 164 entity, causing the value of the UDP checksum field to remain 165 correct. 167 This document defines a similar concept for [NTP], allowing 168 intermediate entities to update NTP packets and maintain the 169 correctness of the UDP checksum by modifying the last 2 octets of the 170 packet. This is performed by adding an NTP extension field at the end 171 of the packet, in which the last two bytes are used as a checksum 172 trailer. 174 The term Checksum Trailer is used throughout this document and refers 175 to the 2 octets at the end of the UDP payload, used for updating the 176 UDP checksum by intermediate entities. 178 The usage of the Checksum Trailer can in some cases simplify the 179 implementation, since if the packet data is processed in a serial 180 order, it is simpler to first update the timestamp field, and then 181 update the Checksum Trailer rather than to update the timestamp and 182 then update the UDP checksum, residing at the UDP header. 184 2. Conventions used in this document 186 2.1. Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [KEYWORDS]. 192 2.2. Abbreviations 194 MAC Message Authentication Code 196 NTP Network Time Protocol 198 PTP Precision Time Protocol 200 UDP User Datagram Protocol 202 3. Using UDP Checksum Trailers in NTP 204 3.1. Overview 206 The UDP Checksum Trailer is a two-octet trailer that is appended at 207 the end of the UDP payload using an NTP extension field. Figure 2 208 illustrates the packet format of an NTP packet with a Checksum 209 Trailer extension. The figure illustrates an unauthenticated NTP 210 packet. Section 3.4. provides further details about using the 211 Checksum Trailer in authenticated packets. 213 +--------------------------------+ 214 | IPv4 / IPv6 Header | 215 +--------------------------------+ 216 | UDP Header | 217 +--------------------------------+ 218 ^ | | 219 | | NTP packet | 220 | | | 221 | +--------------------------------+ 222 UDP | Optional NTP Extension Fields | 223 Payload +--------------------------------+ 224 | | UDP Checksum Trailer | 225 | | Extension Field (28 octets) | 226 v +--------------------------------+ 228 Figure 2 Checksum Trailer in NTP Unauthenticated Packets 230 3.2. Checksum Trailer in NTP Packets 232 NTP is transported over UDP, either over IPv4 or over IPv6. This 233 document applies to both NTP over IPv4, and NTP over IPv6. 235 NTP packets may include one or more extension fields, as defined in 236 [NTPv4]. The Checksum Trailer in NTP packets resides in a dedicated 237 NTP extension field, as shown in Figure 2. 239 In unauthenticated mode, if the NTP packet includes more than one 240 extension field, the Checksum Trailer extension is always the last 241 extension field. Thus, when NTP authentication is disabled, the 242 Checksum Trailer is the last 2 octets in the UDP payload, and thus 243 the trailer is located at UDP Length - 2 octets after the beginning 244 of the UDP header. 246 When NTP authentication is enabled, the Checksum Trailer is the last 247 2 octets before the Message Authentication Code (MAC). 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Field Type | Length = 28 octets | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 | Padding | 256 | | 257 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | Checksum Trailer | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 3 NTP Checksum Trailer Extension Field 262 Field Type 264 A dedicated Field Type value is used to identify the Checksum 265 Trailer extension. See Section 6 for further details. 267 Length 269 The Checksum Trailer extension field length is 28 octets. 271 This length guarantees that the host that receives the packet 272 parses it correctly, whether the packet includes a MAC or not. 273 [NTP-Ext] provides further details about the length of an 274 extension field in the absence of a MAC. 276 Padding 278 The extension field includes 22 octets of padding. This field 279 SHOULD be set to 0, and SHOULD be ignored by the recipient. 281 Checksum Trailer 283 Includes the UDP Checksum Trailer field. 285 3.2.1. Transmission of NTP with Checksum Trailer 287 The transmitter of an NTP packet MAY include a Checksum Trailer 288 extension field. 290 3.2.2. Intermediate Updates of NTP with Checksum Trailer 292 An intermediate node that receives and alters an NTP packet 293 containing a Checksum Trailer extension MAY use the Checksum Trailer 294 to maintain a correct UDP checksum value. 296 3.2.3. Reception of NTP with Checksum Trailer 298 This document does not impose new requirements on the receiving end 299 of an NTP packet. 301 The UDP layer at the receiving end verifies the UDP Checksum of 302 received NTP packets, and the NTP layer SHOULD ignore the Checksum 303 Trailer extension field. 305 3.3. Interoperability with Existing Implementations 307 The behavior defined in this document does not impose new 308 requirements on the reception of NTP packets. Thus, transmitters and 309 intermediate nodes that support the Checksum Trailer can 310 transparently interoperate with existing implementations. 312 3.4. Using the Checksum Trailer with or without Authentication 314 A Checksum Trailer SHOULD NOT be used when authentication is enabled. 315 The Checksum Trailer is effective in unauthenticated mode, allowing 316 the intermediate entity to perform serial processing of the packet 317 without storing-and-forwarding it. 319 On the other hand, when message authentication is used, an 320 intermediate entity that alters NTP packets must also re-compute the 321 Message Authentication Code (MAC) accordingly. The MAC update 322 typically requires the intermediate entity to store the packet, re- 323 compute its MAC, and then forward it. Thus, the benefit of the 324 checksum trailer is effectively irrelevant when a MAC is used. 326 4. Security Considerations 328 This document describes how a Checksum Trailer extension can be used 329 for maintaining the correctness of the UDP checksum. 331 The purpose of this extension is to ease the implementation of 332 accurate timestamping engines, as described in Figure 1. The 333 extension is intended to be used internally in an NTP client or 334 server, and not intended to be used by intermediate switches and 335 routers that reside between the client and the server. As opposed to 336 PTP [IEEE1588], NTP does not require intermediate switches or routers 337 to modify the content of NTP messages, and thus any such modification 338 should be considered as a malicious MITM attack. 340 It is important to emphasize that the scheme described in this 341 document does not increase the protocol's vulnerabitliy to MITM 342 attacks; a MITM who maliciously modifies a packet and its checksum 343 trailer is logically equivalent to a MITM attacker who modifies a 344 packet and its UDP Checksum field. 346 The concept described in this document is intended to be used only in 347 unauthenticated mode. As described in Section 3.4. , the benefits of 348 the Checksum Trailer do not apply when authentication is enabled. 350 5. IANA Considerations 352 IANA is requested to allocate an NTP extension Field Type value for 353 the Checksum Trailer extension. 355 6. Acknowledgments 357 This document was prepared using 2-Word-v2.0.template.dot. 359 7. References 361 7.1. Normative References 363 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, March 1997. 366 [IPv6] Deering, S., Hinden, R., "Internet Protocol, Version 6 367 (IPv6) Specification", RFC 2460, December 1998. 369 [Checksum] Rijsinghani, A., "Computation of the Internet Checksum 370 via Incremental Update", RFC 1624, May 1994. 372 [UDP] Postel, J., "User Datagram Protocol", RFC 768, August 373 1980. 375 [NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W., 376 "Network Time Protocol Version 4: Protocol and 377 Algorithms Specification", RFC 5905, June 2010. 379 7.2. Informative References 381 [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society 382 2000, "1588 IEEE Standard for a Precision Clock 383 Synchronization Protocol for Networked Measurement and 384 Control Systems Version 2", IEEE Standard, 2008. 386 [NTP-Ext] Mizrahi, T., Mayer, D., "Using NTP Extension Fields 387 without Authentication", draft-mizrahi-ntp-extension- 388 field (work in progress), January 2014. 390 Authors' Addresses 392 Tal Mizrahi 393 Marvell 394 6 Hamada St. 395 Yokneam, 20692 Israel 397 Email: talmi@marvell.com