--- 1/draft-ietf-ippm-checksum-trailer-01.txt 2015-07-20 00:16:02.063822016 -0700 +++ 2/draft-ietf-ippm-checksum-trailer-02.txt 2015-07-20 00:16:02.135823758 -0700 @@ -1,17 +1,17 @@ Network Working Group T. Mizrahi Internet Draft Marvell Intended status: Informational -Expires: September 2015 March 9, 2015 +Expires: January 2016 July 20, 2015 UDP Checksum Complement in OWAMP and TWAMP - draft-ietf-ippm-checksum-trailer-01.txt + draft-ietf-ippm-checksum-trailer-02.txt Abstract The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission timestamp into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, @@ -36,75 +36,75 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on September 9, 2015. + This Internet-Draft will expire on January 20, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction ................................................. 2 - 2. Conventions used in this document ............................ 4 - 2.1. Terminology ............................................. 4 - 2.2. Abbreviations ........................................... 4 - 3. Using the UDP Checksum Complement in OWAMP and TWAMP ......... 5 - 3.1. Overview ................................................ 5 - 3.2. OWAMP / TWAMP Test Packets with Checksum Complement ..... 5 - 3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement 8 + 1. Introduction...................................................2 + 2. Conventions used in this document..............................4 + 2.1. Terminology...............................................4 + 2.2. Abbreviations.............................................4 + 3. Using the UDP Checksum Complement in OWAMP and TWAMP...........5 + 3.1. Overview..................................................5 + 3.2. OWAMP / TWAMP Test Packets with Checksum Complement.......5 + 3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement.8 3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum - Complement ................................................ 9 - 3.2.3. Reception of OWAMP/TWAMP with Checksum Complement .. 9 - 3.3. Interoperability with Existing Implementations........... 9 + Complement..................................................9 + 3.2.3. Reception of OWAMP/TWAMP with Checksum Complement....9 + 3.3. Interoperability with Existing Implementations............9 3.4. Using the Checksum Complement with or without Authentication - ............................................................ 9 - 3.4.1. Checksum Complement in Authenticated Mode........... 9 - 3.4.2. Checksum Complement in Encrypted Mode .............. 9 - 4. Security Considerations ..................................... 10 - 5. IANA Considerations ......................................... 10 - 6. Acknowledgments ............................................. 11 - 7. References .................................................. 11 - 7.1. Normative References ................................... 11 - 7.2. Informative References ................................. 11 + ...............................................................9 + 3.4.1. Checksum Complement in Authenticated Mode............9 + 3.4.2. Checksum Complement in Encrypted Mode................9 + 4. Security Considerations.......................................10 + 5. IANA Considerations...........................................10 + 6. Acknowledgments...............................................11 + 7. References....................................................11 + 7.1. Normative References.....................................11 + 7.2. Informative References...................................11 1. Introduction The One-Way Active Measurement Protocol ([OWAMP]) and the Two-Way Active Measurement Protocol ([TWAMP]) are used for performance monitoring in IP networks. Delay and delay variation are two of the metrics that OWAMP/TWAMP can measure. This measurement is performed using timestamped test packets. The accuracy of delay measurements relies on the timestamping method and its implementation. In order to facilitate accurate timestamping, - an implementation MAY use a hardware based timestamping engine, as + an implementation can use a hardware based timestamping engine, as shown in Figure 1. In such cases, the OWAMP/TWMAP packets are sent and received by a software layer, whereas the timestamping engine modifies every outgoing test packet by incorporating its accurate transmission time into the field in the packet. OWAMP/TWAMP-enabled Node +-------------------+ | | | +-----------+ | Software | |OWAMP/TWAMP| | @@ -129,25 +129,27 @@ / \ \__/\_ ___/ \_/ Figure 1 Accurate Timestamping in OWAMP/TWAMP OWAMP/TWAMP test packets are transported over UDP. When the UDP payload is changed by an intermediate entity such as the timestamping engine, the UDP Checksum field must be updated to reflect the new payload. When using UDP over IPv4 ([UDP]), an intermediate entity - that cannot update the value of the UDP checksum can assign a value - of zero to the checksum field, causing the receiver to ignore the - checksum field. UDP over IPv6, as defined in [IPv6], does not allow a - zero checksum, and requires the UDP checksum field to contain a - correct checksum of the UDP payload. + that cannot update the value of the UDP checksum has no choice except + to assign a value of zero to the checksum field, causing the receiver + to ignore the checksum field and potentially accept corrupted + packets. UDP over IPv6, as defined in [IPv6], does not allow a zero + checksum, except in specific cases [ZeroChecksum]. As discussed in + [ZeroChecksum], the use of a zero checksum is generally not + recommended, and should be avoided to the extent possible. Since an intermediate entity only modifies a specific field in the packet, i.e. the timestamp field, the UDP checksum update can be performed incrementally, using the concepts presented in [Checksum]. A similar problem is addressed in Annex E of [IEEE1588]. When the Precision Time Protocol (PTP) is transported over IPv6, two octets are appended to the end of the PTP payload for UDP checksum updates. The value of these two octets can be updated by an intermediate entity, causing the value of the UDP checksum field to remain @@ -343,22 +345,23 @@ A transmitter that includes a Checksum Complement in its outgoing test packets MUST include a Packet Padding in these packets, the length of which MUST be sufficient to include the Checksum Complement. The length of the padding field is negotiated during session initiation, as described in Section 3.2. 3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum Complement An intermediate entity that receives and alters an OWAMP/TWAMP test - packet MAY alter the Checksum Complement field in order to maintain - the correctness of the UDP checksum value. + packet can alter either the UDP Checksum field or the Checksum + Complement field in order to maintain the correctness of the UDP + checksum value. 3.2.3. Reception of OWAMP/TWAMP with Checksum Complement This document does not impose new requirements on the receiving end of an OWAMP/TWAMP test packet. The UDP layer at the receiving end verifies the UDP Checksum of received test packets, and the OWAMP/TWAMP layer SHOULD treat the Checksum Complement as part of the Packet Padding. @@ -393,22 +396,24 @@ is encrypted. A Checksum Complement SHOULD NOT be used in encrypted mode. The Checksum Complement is effective in unauthenticated and in authenticated mode, allowing the intermediate entity to perform serial processing of the packet without storing-and-forwarding it. On the other hand, in encrypted mode an intermediate entity that timestamps a test packet must also re-encrypt the packet accordingly. Re-encryption typically requires the intermediate entity to store the - packet, re-encrypt it, and then forward it. Thus, the benefit of the - Checksum Complement is effectively irrelevant in encrypted mode. + packet, re-encrypt it, and then forward it. Thus, from an + implementer's perspective, the Checksum Complement has very little + value in encrypted mode, as it does not necessarily simplify the + implementation. Note: while [OWAMP] and [TWAMP] include an inherent security mechanism, these protocols can be secured by other measures, e.g., [IPPMIPsec]. For similar reasons as described above, a Checksum Complement SHOULD NOT be used in this case. 4. Security Considerations This document describes how a Checksum Complement extension can be used for maintaining the correctness of the UDP checksum. @@ -422,22 +427,23 @@ should be considered a malicious MITM attack. It is important to emphasize that the scheme described in this document does not increase the protocol's vulnerability to MITM attacks; a MITM who maliciously modifies a packet and its Checksum Complement is logically equivalent to a MITM attacker who modifies a packet and its UDP Checksum field. The concept described in this document is intended to be used only in unauthenticated or in authenticated mode. As described in Section - 3.4. , the benefits of the Checksum Complement do not apply when - encryption is enabled. + 3.4.2. , in encrypted mode using the Checksum Complement does not + simplify the implementation compared to using the conventional + Checksum, and therefore the Checksum Complement should not be used. 5. IANA Considerations There are no IANA actions required by this document. RFC Editor: please delete this section before publication. 6. Acknowledgments The authors gratefully acknowledge Al Morton, Greg Mirsky, and Steve @@ -475,20 +481,24 @@ 7.2. Informative References [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, "1588 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 2", IEEE Standard, 2008. [IPPMIPsec] Pentikousis, K., Zhang, E., Cui, Y., "IKEv2-based Shared Secret Key for O/TWAMP", draft-ietf-ippm-ipsec - (work in progress), February 2015. + (work in progress), May 2015. + + [ZeroChecksum] Fairhurst, G., Westerlund, M., "Applicability + Statement for the Use of IPv6 UDP Datagrams with Zero + Checksums", RFC 6936, April 2013. Authors' Addresses Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel Email: talmi@marvell.com