idnits 2.17.1 draft-ietf-ippm-checksum-trailer-04.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 (November 9, 2015) is 3092 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Mizrahi 2 Internet Draft Marvell 3 Intended status: Experimental 4 Expires: May 2016 November 9, 2015 6 UDP Checksum Complement in OWAMP and TWAMP 7 draft-ietf-ippm-checksum-trailer-04.txt 9 Abstract 11 The One-Way Active Measurement Protocol (OWAMP) and the Two-Way 12 Active Measurement Protocol (TWAMP) are used for performance 13 monitoring in IP networks. Delay measurement is performed in these 14 protocols by using timestamped test packets. Some implementations use 15 hardware-based timestamping engines that integrate the accurate 16 transmission timestamp into every outgoing OWAMP/TWAMP test packet 17 during transmission. Since these packets are transported over UDP, 18 the UDP checksum field is then updated to reflect this modification. 19 This document proposes to use the last 2 octets of every test packet 20 as a Checksum Complement, allowing timestamping engines to reflect 21 the checksum modification in the last 2 octets rather than in the UDP 22 checksum field. The behavior defined in this document is completely 23 interoperable with existing OWAMP/TWAMP implementations. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on May 9, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction...................................................2 66 2. Conventions used in this document..............................4 67 2.1. Terminology...............................................4 68 2.2. Abbreviations.............................................5 69 3. Using the UDP Checksum Complement in OWAMP and TWAMP...........5 70 3.1. Overview..................................................5 71 3.2. OWAMP / TWAMP Test Packets with Checksum Complement.......5 72 3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement.8 73 3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum 74 Complement..................................................9 75 3.2.3. Reception of OWAMP/TWAMP with Checksum Complement....9 76 3.3. Interoperability with Existing Implementations............9 77 3.4. Using the Checksum Complement with or without Authentication 78 ...............................................................9 79 3.4.1. Checksum Complement in Authenticated Mode............9 80 3.4.2. Checksum Complement in Encrypted Mode................9 81 4. Security Considerations.......................................10 82 5. IANA Considerations...........................................10 83 6. Acknowledgments...............................................11 84 7. References....................................................11 85 7.1. Normative References.....................................11 86 7.2. Informative References...................................11 88 1. Introduction 90 The One-Way Active Measurement Protocol ([OWAMP]) and the Two-Way 91 Active Measurement Protocol ([TWAMP]) are used for performance 92 monitoring in IP networks. 94 Delay and delay variation are two of the metrics that OWAMP/TWAMP can 95 measure. This measurement is performed using timestamped test 96 packets. 98 The accuracy of delay measurements relies on the timestamping method 99 and its implementation. In order to facilitate accurate timestamping, 100 an implementation can use a hardware based timestamping engine, as 101 shown in Figure 1. In such cases, the OWAMP/TWMAP packets are sent 102 and received by a software layer, whereas the timestamping engine 103 modifies every outgoing test packet by incorporating its accurate 104 transmission time into the field in the packet. 106 OWAMP/TWAMP-enabled Node 107 +-------------------+ 108 | | 109 | +-----------+ | 110 Software | |OWAMP/TWAMP| | 111 | | protocol | | 112 | +-----+-----+ | 113 | | | 114 | +-----+-----+ | 115 | | Accurate | | 116 ASIC/FPGA | | Timestamp | | 117 | | engine | | 118 | +-----------+ | 119 | | | 120 +---------+---------+ 121 | 122 |test packets 123 | 124 ___ v _ 125 / \_/ \__ 126 / \_ 127 / IP / 128 \_ Network / 129 / \ 130 \__/\_ ___/ 131 \_/ 133 Figure 1 Accurate Timestamping in OWAMP/TWAMP 135 OWAMP/TWAMP test packets are transported over UDP. When the UDP 136 payload is changed by an intermediate entity such as the timestamping 137 engine, the UDP Checksum field must be updated to reflect the new 138 payload. When using UDP over IPv4 ([UDP]), an intermediate entity 139 that cannot update the value of the UDP checksum has no choice except 140 to assign a value of zero to the checksum field, causing the receiver 141 to ignore the checksum field and potentially accept corrupted 142 packets. UDP over IPv6, as defined in [IPv6], does not allow a zero 143 checksum, except in specific cases [ZeroChecksum]. As discussed in 144 [ZeroChecksum], the use of a zero checksum is generally not 145 recommended, and should be avoided to the extent possible. 147 Since an intermediate entity only modifies a specific field in the 148 packet, i.e. the timestamp field, the UDP checksum update can be 149 performed incrementally, using the concepts presented in [Checksum]. 151 A similar problem is addressed in Annex E of [IEEE1588]. When the 152 Precision Time Protocol (PTP) is transported over IPv6, two octets 153 are appended to the end of the PTP payload for UDP checksum updates. 154 The value of these two octets can be updated by an intermediate 155 entity, causing the value of the UDP checksum field to remain 156 correct. 158 This document defines a similar concept for [OWAMP] and [TWAMP], 159 allowing intermediate entities to update OWAMP/TWAMP test packets and 160 maintain the correctness of the UDP checksum by modifying the last 2 161 octets of the packet. 163 The term Checksum Complement is used throughout this document and 164 refers to the 2 octets at the end of the UDP payload, used for 165 updating the UDP checksum by intermediate entities. 167 The usage of the Checksum Complement can in some cases simplify the 168 implementation, since if the packet data is processed in a serial 169 order, it is simpler to first update the timestamp field, and then 170 update the Checksum Complement rather than to update the timestamp 171 and then update the UDP checksum, residing at the UDP header. 173 The Checksum Complement mechanism is also defined for the Network 174 Time Protocol in [NTPComp]. 176 2. Conventions used in this document 178 2.1. Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [KEYWORDS]. 184 2.2. Abbreviations 186 HMAC Hashed Message Authentication Code 188 OWAMP One-Way Active Measurement Protocol 190 PTP Precision Time Protocol 192 TWAMP Two-Way Active Measurement Protocol 194 UDP User Datagram Protocol 196 3. Using the UDP Checksum Complement in OWAMP and TWAMP 198 3.1. Overview 200 The UDP Checksum Complement is a two-octet field that is piggybacked 201 at the end of the test packet. It resides in the last 2 octets of the 202 UDP payload. 204 +----------------------------------+ 205 | IPv4 / IPv6 Header | 206 +----------------------------------+ 207 | UDP Header | 208 +----------------------------------+ 209 ^ | | 210 | | OWAMP / TWAMP | 211 UDP | packet | 212 Payload +----------------------------------+ 213 | |UDP Checksum Complement (2 octets)| 214 v +----------------------------------+ 216 Figure 2 Checksum Complement in OWAMP/TWAMP Test Packet 218 3.2. OWAMP / TWAMP Test Packets with Checksum Complement 220 The One-Way Active Measurement Protocol [OWAMP], and the Two-Way 221 Active Measurement Protocol [TWAMP] both make use of timestamped test 222 packets. A Checksum Complement MAY be used in the following cases: 224 o In OWAMP test packets, sent by the sender to the receiver. 226 o In TWAMP test packets, sent by the sender to the reflector. 228 o In TWAMP test packets, sent by the reflector to the sender. 230 OWAMP/TWAMP test packets are transported over UDP, either over IPv4 231 or over IPv6. This document applies to both OWAMP/TWAMP over IPv4 and 232 over IPv6. 234 OWAMP/TWAMP test packets contain a Packet Padding field. This 235 document proposes to use the last 2 octets of the Packet Padding 236 field as the Checksum Complement. In this case the Checksum 237 Complement is always the last 2 octets of the UDP payload, and thus 238 the field is located UDP Length - 2 octets after the beginning of the 239 UDP header. 241 Figure 3 illustrates the OWAMP test packet format including the UDP 242 Checksum Complement. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Sequence Number | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Timestamp | 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Error Estimate | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | | 255 . Packet Padding . 256 . . 257 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | Checksum Complement | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 3 Checksum Complement in OWAMP Test Packets 262 Figure 4 illustrates the TWAMP test packet format including the UDP 263 Checksum Complement. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Sequence Number | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Timestamp | 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Error Estimate | MBZ | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Receive Timestamp | 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Sender Sequence Number | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Sender Timestamp | 281 | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Sender Error Estimate | MBZ | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Sender TTL | | 286 +-+-+-+-+-+-+-+-+ + 287 | | 288 . . 289 . Packet Padding . 290 . . 291 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | Checksum Complement | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 4 Checksum Complement in TWAMP Test Packets 296 The length of the Packet Padding field in test packets is announced 297 during the session initiation through the field in 298 the Request-Session message [OWAMP], or in the Request-TW-Session 299 [TWAMP]. 301 When a Checksum Complement is included, the MUST be 302 sufficiently long to include the Checksum Complement: 304 o In OWAMP the padding length is at least 2 octets, allowing the 305 sender to incorporate the Checksum Complement in the last 2 octets 306 of the padding. 308 o In TWAMP the padding length is at least 29 octets. The additional 309 padding is required since the header of reflector test packets is 310 27 octets longer than the header of sender test packets. Thus, the 311 padding in reflector test packets is 27 octets shorter than in 312 sender packet. Using 29 octets of padding in sender test packets 313 allows both the sender and the reflector to use a 2-octet Checksum 314 Complement. 315 Note: the 27-octet difference between the sender packet and the 316 reflector packet is specifically in unauthenticated mode, whereas 317 in authenticated mode the difference between the sender and 318 receiver packets is 56 octets. As specified in Section 3.4. , the 319 Checksum Complement should only be used in unauthenticated mode. 321 o Two optional TWAMP features are defined in [RFC6038]: octet 322 reflection and symmetrical size. When at least one of these 323 features is enabled, the Request-TW-Session includes the field, as well as a field. 325 In this case both fields must be sufficiently long to allow at 326 least 2 octets of padding in both sender test packets and 327 reflector test packets. 328 Specifically, when octet reflection is enabled, the two length 329 fields must be defined such that the padding expands at least 2 330 octets beyond the end of the reflected octets. 332 As described in Section 1. , the extensions described in this 333 document are implemented by two logical layers, a protocol layer and 334 a timestamping layer. It is assumed that the two layers are 335 synchronized about whether the usage of the Checksum Complement is 336 enabled or not; since both logical layers reside in the same network 337 device, it is assumed there is no need for a protocol that 338 synchronizes this information between the two layers. When Checksum 339 Complement usage is enabled, the protocol layer must take care to 340 verify that test packets include the necessary padding, and avoiding 341 the need for the timestamping layer to verify that en-route test 342 packets include the necessary padding. 344 3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement 346 The transmitter of an OWAMP/TWAMP test packet MAY include a Checksum 347 Complement field, incorporated in the last 2 octets of the Packet 348 Padding. 350 A transmitter that includes a Checksum Complement in its outgoing 351 test packets MUST include a Packet Padding in these packets, the 352 length of which MUST be sufficient to include the Checksum 353 Complement. The length of the padding field is negotiated during 354 session initiation, as described in Section 3.2. 356 3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum Complement 358 An intermediate entity that receives and alters an OWAMP/TWAMP test 359 packet can alter either the UDP Checksum field or the Checksum 360 Complement field in order to maintain the correctness of the UDP 361 checksum value. 363 3.2.3. Reception of OWAMP/TWAMP with Checksum Complement 365 This document does not impose new requirements on the receiving end 366 of an OWAMP/TWAMP test packet. 368 The UDP layer at the receiving end verifies the UDP Checksum of 369 received test packets, and the OWAMP/TWAMP layer SHOULD treat the 370 Checksum Complement as part of the Packet Padding. 372 3.3. Interoperability with Existing Implementations 374 The behavior defined in this document does not impose new 375 requirements on the reception behavior of OWAMP/TWAMP test packets. 376 The protocol stack of the receiving host performs the conventional 377 UDP checksum verification, and thus the existence of the Checksum 378 Complement is transparent from the perspective of the receiving host. 379 Therefore, the functionality described in this document allows 380 interoperability with existing implementations that comply to [OWAMP] 381 or [TWAMP]. 383 3.4. Using the Checksum Complement with or without Authentication 385 Both OWAMP and TWAMP may use authentication or encryption, as defined 386 in [OWAMP] and [TWAMP]. 388 3.4.1. Checksum Complement in Authenticated Mode 390 OWAMP and TWAMP test packets can be authenticated using an HMAC 391 (Hashed Message Authentication Code). The HMAC covers some of the 392 fields in the test packet header. The HMAC does not cover the 393 Timestamp field and the Packet Padding field. 395 A Checksum Complement MAY be used when authentication is enabled. In 396 this case an intermediate entity can timestamp test packets and 397 update their Checksum Complement field without modifying the HMAC. 399 3.4.2. Checksum Complement in Encrypted Mode 401 When OWAMP and TWAMP are used in encrypted mode, the Timestamp field 402 is encrypted. 404 A Checksum Complement SHOULD NOT be used in encrypted mode. The 405 Checksum Complement is effective in unauthenticated and in 406 authenticated mode, allowing the intermediate entity to perform 407 serial processing of the packet without storing-and-forwarding it. 409 On the other hand, in encrypted mode an intermediate entity that 410 timestamps a test packet must also re-encrypt the packet accordingly. 411 Re-encryption typically requires the intermediate entity to store the 412 packet, re-encrypt it, and then forward it. Thus, from an 413 implementer's perspective, the Checksum Complement has very little 414 value in encrypted mode, as it does not necessarily simplify the 415 implementation. 417 Note: while [OWAMP] and [TWAMP] include an inherent security 418 mechanism, these protocols can be secured by other measures, e.g., 419 [IPPMIPsec]. For similar reasons as described above, a Checksum 420 Complement SHOULD NOT be used in this case. 422 4. Security Considerations 424 This document describes how a Checksum Complement extension can be 425 used for maintaining the correctness of the UDP checksum. 427 The purpose of this extension is to ease the implementation of 428 accurate timestamping engines, as described in Figure 1. The 429 extension is intended to be used internally in an OWAMP/TWAMP enabled 430 node, and not intended to be used by intermediate switches and 431 routers that reside between the sender and the receiver/reflector. 432 Any modification of a test packet by intermediate switches or routers 433 should be considered a malicious MITM attack. 435 It is important to emphasize that the scheme described in this 436 document does not increase the protocol's vulnerability to MITM 437 attacks; a MITM who maliciously modifies a packet and its Checksum 438 Complement is logically equivalent to a MITM attacker who modifies a 439 packet and its UDP Checksum field. 441 The concept described in this document is intended to be used only in 442 unauthenticated or in authenticated mode. As described in Section 443 3.4.2. , in encrypted mode using the Checksum Complement does not 444 simplify the implementation compared to using the conventional 445 Checksum, and therefore the Checksum Complement should not be used. 447 5. IANA Considerations 449 There are no IANA actions required by this document. 451 RFC Editor: please delete this section before publication. 453 6. Acknowledgments 455 The authors gratefully acknowledge Al Morton, Greg Mirsky, and Steve 456 Baillargeon for their helpful comments. 458 This document was prepared using 2-Word-v2.0.template.dot. 460 7. References 462 7.1. Normative References 464 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 [IPv6] Deering, S., Hinden, R., "Internet Protocol, Version 6 468 (IPv6) Specification", RFC 2460, December 1998. 470 [Checksum] Rijsinghani, A., "Computation of the Internet Checksum 471 via Incremental Update", RFC 1624, May 1994. 473 [UDP] Postel, J., "User Datagram Protocol", RFC 768, August 474 1980. 476 [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and 477 Zekauskas, M., "A One-way Active Measurement Protocol 478 (OWAMP)", RFC 4656, September 2006. 480 [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and 481 Babiarz, J., "A Two-Way Active Measurement Protocol 482 (TWAMP)", RFC 5357, October 2008. 484 [RFC6038] Morton, A., Ciavattone, L., "Two-Way Active 485 Measurement Protocol (TWAMP) Reflect Octets and 486 Symmetrical Size Features", RFC 6038, October 2010. 488 7.2. Informative References 490 [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, 491 "1588 IEEE Standard for a Precision Clock 492 Synchronization Protocol for Networked Measurement and 493 Control Systems Version 2", IEEE Standard, 2008. 495 [IPPMIPsec] Pentikousis, K., Zhang, E., Cui, Y., "IKEv2-based 496 Shared Secret Key for O/TWAMP", draft-ietf-ippm-ipsec 497 (work in progress), May 2015. 499 [NTPComp] Mizrahi, T., "UDP Checksum Complement in the Network 500 Time Protocol (NTP)", draft-ietf-ntp-checksum-trailer 501 (work in progress), October 2015. 503 [ZeroChecksum] Fairhurst, G., Westerlund, M., "Applicability 504 Statement for the Use of IPv6 UDP Datagrams with Zero 505 Checksums", RFC 6936, April 2013. 507 Authors' Addresses 509 Tal Mizrahi 510 Marvell 511 6 Hamada St. 512 Yokneam, 20692 Israel 514 Email: talmi@marvell.com