idnits 2.17.1 draft-mizrahi-ippm-checksum-trailer-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 (January 14, 2014) is 3727 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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 Tal Mizrahi 2 Internet Draft Marvell 3 Intended status: Informational 4 Expires: July 2014 January 14, 2014 6 UDP Checksum Trailer in OWAMP and TWAMP 7 draft-mizrahi-ippm-checksum-trailer-00.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 Trailer, allowing timestamping engines to reflect the 21 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 July 14, 2014. 48 Copyright Notice 50 Copyright (c) 2014 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 ........................................... 4 69 3. Using the UDP Checksum Trailer in OWAMP and TWAMP ............ 5 70 3.1. Overview ................................................ 5 71 3.2. OWAMP / TWAMP Test Packets with Checksum Trailer ........ 5 72 3.2.1. Transmission of OWAMP/TWAMP with Checksum Trailer .. 8 73 3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum 74 Trailer ................................................... 9 75 3.2.3. Reception of OWAMP/TWAMP with Checksum Trailer ..... 9 76 3.3. Interoperability with Existing Implementations........... 9 77 3.4. Using the Checksum Trailer with or without Authentication 9 78 4. Security Considerations ..................................... 10 79 5. IANA Considerations ......................................... 10 80 6. Acknowledgments ............................................. 10 81 7. References .................................................. 10 82 7.1. Normative References ................................... 10 83 7.2. Informative References ................................. 11 85 1. Introduction 87 The One-Way Active Measurement Protocol ([OWAMP]) and the Two-Way 88 Active Measurement Protocol ([TWAMP]) are used for performance 89 monitoring in IP networks. 91 Delay and delay variation are two of the metrics that OWAMP/TWAMP can 92 measure. This measurement is performed using timestamped test 93 packets. 95 The accuracy of delay measurements relies on the timestamping method 96 and its implementation. In order to facilitate accurate timestamping, 97 an implementation MAY use a hardware based timestamping engine, as 98 shown in Figure 1. In such cases, the OWAMP/TWMAP packets are sent 99 and received by a software layer, whereas the timestamping engine 100 modifies every outgoing test packet by incorporating its accurate 101 transmission time into the field in the packet. 103 OWAMP/TWAMP-enabled Node 104 +-------------------+ 105 | | 106 | +-----------+ | 107 Software | |OWAMP/TWAMP| | 108 | | protocol | | 109 | +-----+-----+ | 110 | | | 111 | +-----+-----+ | 112 | | Accurate | | 113 ASIC/FPGA | | Timestamp | | 114 | | engine | | 115 | +-----------+ | 116 | | | 117 +---------+---------+ 118 | 119 |test packets 120 | 121 ___ v _ 122 / \_/ \__ 123 / \_ 124 / IP / 125 \_ Network / 126 / \ 127 \__/\_ ___/ 128 \_/ 130 Figure 1 Accurate Timestamping in OWAMP/TWAMP 132 OWAMP/TWAMP test packets are transported over UDP. When the UDP 133 payload is changed by an intermediate entity such as the timestamping 134 engine, the UDP Checksum field must be updated to reflect the new 135 payload. When using UDP over IPv4 ([UDP]), an intermediate entity 136 that cannot update the value of the UDP checksum can assign a value 137 of zero to the checksum field, causing the receiver to ignore the 138 checksum field. UDP over IPv6, as defined in [IPv6], does not allow a 139 zero checksum, and requires the UDP checksum field to contain a 140 correct checksum of the UDP payload. 142 Since an intermediate entity only modifies a specific field in the 143 packet, i.e. the timestamp field, the UDP checksum update can be 144 performed incrementally, using the concepts presented in [Checksum]. 146 A similar problem is addressed in Annex E of [IEEE1588]. When the 147 Precision Time Protocol (PTP) is transported over IPv6, two octets 148 are appended to the end of the PTP payload for UDP checksum updates. 149 The value of these two octets can be updated by an intermediate 150 entity, causing the value of the UDP checksum field to remain 151 correct. 153 This document defines a similar concept for [OWAMP] and [TWAMP], 154 allowing intermediate entities to update OWAMP/TWAMP test packets and 155 maintain the correctness of the UDP checksum by modifying the last 2 156 octets of the packet. 158 The term Checksum Trailer is used throughout this document and refers 159 to the 2 octets at the end of the UDP payload, used for updating the 160 UDP checksum by intermediate entities. 162 The usage of the Checksum Trailer can in some cases simplify the 163 implementation, since if the packet data is processed in a serial 164 order, it is simpler to first update the timestamp field, and then 165 update the Checksum Trailer rather than to update the timestamp and 166 then update the UDP checksum, residing at the UDP header. 168 2. Conventions used in this document 170 2.1. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [KEYWORDS]. 176 2.2. Abbreviations 178 OWAMP One-Way Active Measurement Protocol 180 PTP Precision Time Protocol 182 TWAMP Two-Way Active Measurement Protocol 184 UDP User Datagram Protocol 186 3. Using the UDP Checksum Trailer in OWAMP and TWAMP 188 3.1. Overview 190 The UDP Checksum Trailer is a two-octet trailer that is piggybacked 191 at the end of the test packet. It resides in the last 2 octets of the 192 UDP payload. 194 +--------------------------------+ 195 | IPv4 / IPv6 Header | 196 +--------------------------------+ 197 | UDP Header | 198 +--------------------------------+ 199 ^ | | 200 | | OWAMP / TWAMP | 201 UDP | packet | 202 Payload +--------------------------------+ 203 | |UDP Checksum Trailer (2 octets) | 204 v +--------------------------------+ 206 Figure 2 Checksum Trailer in OWAMP/TWAMP Test Packet 208 3.2. OWAMP / TWAMP Test Packets with Checksum Trailer 210 The One-Way Active Measurement Protocol [OWAMP], and the Two-Way 211 Active Measurement Protocol [TWAMP] both make use of timestamped test 212 packets. The formats of these packets are defined in [OWAMP] and in 213 [TWAMP]. 215 OWAMP/TWAMP test packets are transported over UDP, either over IPv4 216 or over IPv6. This document applies to both OWAMP/TWAMP over IPv4 and 217 over IPv6. 219 OWAMP/TWAMP test packets contain a Packet Padding field. This 220 document proposes to use the last 2 octets of the Packet Padding 221 field as the Checksum Trailer. In this case the Checksum Trailer is 222 always the last 2 octets of the UDP payload, and thus the trailer is 223 located UDP Length - 2 octets after the beginning of the UDP header. 225 Figure 3 illustrates the OWAMP test packet format including the UDP 226 checksum trailer. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Sequence Number | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Timestamp | 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Error Estimate | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 238 | | 239 . Packet Padding . 240 . . 241 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | Checksum Trailer | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 3 Checksum Trailer in OWAMP Test Packets 246 Figure 4 illustrates the TWAMP test packet format including the UDP 247 checksum trailer. 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 | Sequence Number | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Timestamp | 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Error Estimate | MBZ | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Receive Timestamp | 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Sender Sequence Number | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Sender Timestamp | 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Sender Error Estimate | MBZ | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Sender TTL | | 270 +-+-+-+-+-+-+-+-+ + 271 | | 272 . . 273 . Packet Padding . 274 . . 275 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | | Checksum Trailer | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 4 Checksum Trailer in TWAMP Test Packets 280 The length of the Packet Padding field in test packets is announced 281 during the session initiation through the field in 282 the Request-Session message [OWAMP], or in the Request-TW-Session 283 [TWAMP]. 285 When a Checksum Trailer is included, the MUST be 286 sufficiently long to include the Checksum Trailer: 288 o In OWAMP the padding length is at least 2 octets, allowing the 289 sender to incorporate the checksum trailer in the last 2 octets of 290 the padding. 292 o In TWAMP the padding length is at least 29 octets. The additional 293 padding is required since the header of reflector test packets is 294 27 octets longer than the header of sender test packets. Thus, the 295 padding in reflector test packets is 27 octets shorter than in 296 sender packet. Using 29 octets of padding in sender test packets 297 allows both the sender and the reflector to use a 2-octet checksum 298 trailer. 299 Note: the 27-octet difference between the sender packet and the 300 reflector packet is specifically in unauthenticated mode, whereas 301 in authenticated mode the difference between the sender and 302 receiver packets is 56 octets. As specified in Section 3.4. , the 303 checksum trailer should only be used in unauthenticated mode. 305 o Two optional TWAMP features are defined in [RFC6038]: octet 306 reflection and symmetrical size. When at least one of these 307 features is enabled, the Request-TW-Session includes the field, as well as a field. 309 In this case both fields must be sufficiently long to allow at 310 least 2 octets of padding in both sender test packets and 311 reflector test packets. 312 Specifically, when octet reflection is enabled, the two length 313 fields must be defined such that the padding expands at least 2 314 octets beyond the end of the reflected octets. 316 As described in Section 1. , the extensions described in this 317 document are implemented by two logical layers, a protocol layer and 318 a timestamping layer. It is assumed that the two layers are 319 synchronized about whether the usage of the Checksum Trailer is 320 enabled or not; since both logical layers reside in the same network 321 device, it is assumed there is no need for a protocol that 322 synchronizes this information between the two layers. When Checksum 323 Trailer usage is enabled, the protocol layer must take care to verify 324 that test packets include the necessary padding, and avoiding the 325 need for the timestamping layer to verify that en-route test packets 326 include the necessary padding. 328 3.2.1. Transmission of OWAMP/TWAMP with Checksum Trailer 330 The transmitter of an OWAMP/TWAMP test packet MAY include a Checksum 331 Trailer field, incorporated in the last 2 octets of the Packet 332 Padding. 334 A transmitter that includes a Checksum Trailer in its outgoing test 335 packets MUST include a Packet Padding in these packets, the length of 336 which MUST be sufficient to include the checksum trailer. The length 337 of the padding field is negotiated during session initiation, as 338 described in Section 3.2. 340 3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum Trailer 342 An intermediate entity that receives and alters an OWAMP/TWAMP test 343 packet MAY alter the Checksum Trailer field in order to maintain the 344 correctness of the UDP checksum value. 346 3.2.3. Reception of OWAMP/TWAMP with Checksum Trailer 348 This document does not impose new requirements on the receiving end 349 of an OWAMP/TWAMP test packet. 351 The UDP layer at the receiving end verifies the UDP Checksum of 352 received test packets, and the OWAMP/TWAMP layer SHOULD treat the 353 Checksum Trailer as part of the Packet Padding. 355 3.3. Interoperability with Existing Implementations 357 The behavior defined in this document does not impose new 358 requirements on the reception behavior of an OWAMP receiver or a 359 TWAMP reflector, since the existence of the checksum trailer is 360 transparent from the perspective of the receiver/reflector. Thus, the 361 functionality described in this document allows interoperability with 362 existing implementations that comply to [OWAMP] or [TWAMP]. 364 3.4. Using the Checksum Trailer with or without Authentication 366 Both OWAMP and TWAMP may use authentication, as defined in [OWAMP] or 367 [TWAMP]. A Checksum Trailer SHOULD NOT be used when authentication is 368 enabled. The Checksum Trailer is effective in unauthenticated mode, 369 allowing the intermediate entity to perform serial processing of the 370 packet without storing-and-forwarding it. 372 On the other hand, when message authentication is used, an 373 intermediate entity that alters test packets must also re-compute the 374 Message Authentication Code (MAC) accordingly. The MAC update 375 typically requires the intermediate entity to store the packet, re- 376 compute its MAC, and then forward it. Thus, the benefit of the 377 checksum trailer is effectively irrelevant when a MAC is used. 379 Note: while [OWAMP] and [TWAMP] include an inherent security 380 mechanism, these protocols can be secured by other measures, e.g., 381 [IPPMIPsec]. For similar reasons as described above, a Checksum 382 Trailer SHOULD NOT be used in this case. 384 4. Security Considerations 386 This document describes how a Checksum Trailer extension can be used 387 for maintaining the correctness of the UDP checksum. 389 The purpose of this extension is to ease the implementation of 390 accurate timestamping engines, as described in Figure 1. The 391 extension is intended to be used internally in an OWAMP/TWAMP enabled 392 node, and not intended to be used by intermediate switches and 393 routers that reside between the sender and the receiver/reflector. 394 Any modification of a test packet by intermediate switches or routers 395 should be considered a malicious MITM attack. 397 It is important to emphasize that the scheme described in this 398 document does not increase the protocol's vulnerability to MITM 399 attacks; a MITM who maliciously modifies a packet and its checksum 400 trailer is logically equivalent to a MITM attacker who modifies a 401 packet and its UDP Checksum field. 403 The concept described in this document is intended to be used only in 404 unauthenticated mode. As described in Section 3.4. , the benefits of 405 the Checksum Trailer do not apply when authentication is enabled. 407 5. IANA Considerations 409 There are no IANA actions required by this document. 411 RFC Editor: please delete this section before publication. 413 6. Acknowledgments 415 This document was prepared using 2-Word-v2.0.template.dot. 417 7. References 419 7.1. Normative References 421 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 [IPv6] Deering, S., Hinden, R., "Internet Protocol, Version 6 425 (IPv6) Specification", RFC 2460, December 1998. 427 [Checksum] Rijsinghani, A., "Computation of the Internet Checksum 428 via Incremental Update", RFC 1624, May 1994. 430 [UDP] Postel, J., "User Datagram Protocol", RFC 768, August 431 1980. 433 [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and 434 Zekauskas, M., "A One-way Active Measurement Protocol 435 (OWAMP)", RFC 4656, September 2006. 437 [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and 438 Babiarz, J., "A Two-Way Active Measurement Protocol 439 (TWAMP)", RFC 5357, October 2008. 441 [RFC6038] Morton, A., Ciavattone, L., "Two-Way Active 442 Measurement Protocol (TWAMP) Reflect Octets and 443 Symmetrical Size Features", RFC 6038, October 2010. 445 7.2. Informative References 447 [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, 448 "1588 IEEE Standard for a Precision Clock 449 Synchronization Protocol for Networked Measurement and 450 Control Systems Version 2", IEEE Standard, 2008. 452 [IPPMIPsec] Pentikousis, K., Cui, Y., Zhang, E., "Network 453 Performance Measurement for IPsec", draft-ietf-ippm- 454 ipsec (work in progress), October 2013. 456 Authors' Addresses 458 Tal Mizrahi 459 Marvell 460 6 Hamada St. 461 Yokneam, 20692 Israel 463 Email: talmi@marvell.com