Internet Engineering Task Force (IETF) T. Mizrahi Request for Comments: 7820 Marvell Category: Experimental March 2016 ISSN: 2070-1721 UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
AbstractThe 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 time into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP Checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7820.
Copyright Notice Copyright (c) 2016 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. 1. Introduction ....................................................3 2. Conventions Used in This Document ...............................5 2.1. Terminology ................................................5 2.2. Abbreviations ..............................................5 3. Using the UDP Checksum Complement in OWAMP and TWAMP ............6 3.1. Overview ...................................................6 3.2. OWAMP/TWAMP Test Packets with Checksum Complement ..........6 3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement .........................................10 3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum Complement ................................10 3.2.3. Reception of OWAMP/TWAMP with Checksum Complement ..10 3.3. Interoperability with Existing Implementations ............10 3.4. Using the Checksum Complement with or without Authentication ............................................11 3.4.1. Checksum Complement in Authenticated Mode ..........11 3.4.2. Checksum Complement in Encrypted Mode ..............11 4. Security Considerations ........................................12 5. References .....................................................12 5.1. Normative References ......................................12 5.2. Informative References ....................................13 Appendix A. Checksum Complement Usage Example .....................14 Acknowledgments ...................................................15 Author's Address ..................................................15
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. Measurement is performed using timestamped test packets. In some use cases, such as carrier networks, these two metrics are an essential aspect of the Service Level Agreement (SLA) and therefore must be measured with a high degree of accuracy. If packets are timestamped in hardware as they exit the host, then greater accuracy is possible in comparison to higher-layer timestamps (as explained further below). The accuracy of delay measurements relies on the timestamping method and its implementation. In order to facilitate accurate timestamping, an implementation can use a hardware-based timestamping engine, as shown in Figure 1. In such cases, the OWAMP/TWAMP 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 Timestamp field in the packet.
OWAMP/TWAMP-enabled Node +-------------------+ | | | +-----------+ | Software | |OWAMP/TWAMP| | | | protocol | | | +-----+-----+ | | | | +-----------------------+ | +-----+-----+ | / Intermediate entity | | | Accurate | | / in charge of: | ASIC/FPGA | | Timestamp | | /__ - Timestamping | | | engine | | |- Updating checksum or | | +-----------+ | | Checksum Complement | | | | +-----------------------+ +---------+---------+ | |test packets | ___ v _ / \_/ \__ / \_ / IP / \_ Network / / \ \__/\_ ___/ \_/ ASIC: Application-Specific Integrated Circuit FPGA: Field-Programmable Gate Array 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 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, 2 octets are appended to the end of the PTP payload for UDP Checksum updates. The value of these 2 octets can be updated by an intermediate entity, causing the value of the UDP Checksum field to remain correct. This document defines a similar concept for [OWAMP] and [TWAMP], allowing intermediate entities to update OWAMP/TWAMP test packets and maintain the correctness of the UDP Checksum by modifying the last 2 octets of the packet. The term "Checksum Complement" is used throughout this document and refers to the 2 octets at the end of the UDP payload, used for updating the UDP Checksum by intermediate entities. The usage of the Checksum Complement can in some cases simplify the implementation, because if the packet data is processed in serial order, it is simpler to first update the Timestamp field and then update the Checksum Complement, rather than to update the timestamp and then update the UDP Checksum residing at the UDP header. The Checksum Complement mechanism is also defined for the Network Time Protocol in [RFC7821]. KEYWORDS].
+----------------------------------+ | IPv4/IPv6 Header | +----------------------------------+ | UDP Header | +----------------------------------+ ^ | | | | OWAMP/TWAMP | UDP | packet | Payload +----------------------------------+ | |UDP Checksum Complement (2 octets)| v +----------------------------------+ Figure 2: Checksum Complement in OWAMP/TWAMP Test Packets The Checksum Complement is used to compensate for changes performed in the packet by intermediate entities, as described in the Introduction (Section 1). An example of the usage of the Checksum Complement is provided in Appendix A. OWAMP] and the Two-Way Active Measurement Protocol [TWAMP] both make use of timestamped test packets. A Checksum Complement MAY be used in the following cases: o In OWAMP test packets sent by the sender to the receiver. o In TWAMP test packets sent by the sender to the reflector. o In TWAMP test packets sent by the reflector to the sender. OWAMP/TWAMP test packets are transported over UDP, either over IPv4 or over IPv6. This document applies to both OWAMP and TWAMP over IPv4 and over IPv6.
OWAMP/TWAMP test packets contain a Packet Padding field. This document proposes to use the last 2 octets of the Packet Padding field as the Checksum Complement. In this case, the Checksum Complement is always the last 2 octets of the UDP payload, and thus the field is located at (UDP Length - 2 octets) after the beginning of the UDP header. Figure 3 illustrates the OWAMP test packet format, including the UDP Checksum Complement. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . Packet Padding . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Checksum Complement | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Checksum Complement in OWAMP Test Packets
Figure 4 illustrates the TWAMP test packet format, including the UDP Checksum Complement. ("TTL" means "Time to Live", and "MBZ" refers to the "MUST be zero" field [IPPMIPsec].) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Error Estimate | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender TTL | | +-+-+-+-+-+-+-+-+ + | | . . . Packet Padding . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Checksum Complement | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Checksum Complement in TWAMP Test Packets The length of the Packet Padding field in test packets is announced during the session initiation through the <Padding Length> field in the Request-Session message [OWAMP] or in the Request-TW-Session message [TWAMP].
When a Checksum Complement is included, the padding length MUST be sufficiently long to include the Checksum Complement: o In OWAMP, the padding length is at least 2 octets, allowing the sender to incorporate the Checksum Complement in the last 2 octets of the padding. o In TWAMP, the padding length is at least 29 octets in unauthenticated mode and at least 58 octets in authenticated mode. The additional padding is required, since the header of reflector test packets is longer than the header of sender test packets. The difference between the sender packet and the reflector packet is 27 octets in unauthenticated mode and 56 octets in authenticated mode. Thus, the padding in reflector test packets is shorter than the padding in sender packets. Using at least 29 octets of padding (58 in authenticated mode) in sender test packets allows both the sender and the reflector to use a 2-octet Checksum Complement. Note: If the minimal length requirement is not met, the reflector cannot use a Checksum Complement in the reflected test packets, but the sender can use a Checksum Complement in the test packets it transmits. o Two optional TWAMP features are defined in [TWAMP-Reflect]: octet reflection and symmetrical size. When at least one of these features is enabled, the Request-TW-Session message includes the <Padding Length> field, as well as a <Length of padding to reflect> field. In this case, both fields must be sufficiently long to allow at least 2 octets of padding in both sender test packets and reflector test packets. Specifically, when octet reflection is enabled, the two Length fields must be defined such that the padding expands at least 2 octets beyond the end of the reflected octets. As described in Section 1, the extensions described in this document are implemented by two logical layers -- a protocol layer and a timestamping layer. It is assumed that the two layers are synchronized regarding whether the usage of the Checksum Complement is enabled or not; since both logical layers reside in the same network device, it is assumed that there is no need for a protocol that synchronizes this information between the two layers. When Checksum Complement usage is enabled, the protocol layer must take care to verify that test packets include the necessary padding, thereby avoiding the need for the timestamping layer to verify that en-route test packets include the necessary padding.
Section 3.2. OWAMP] or [TWAMP].
Figure 1. The extension is intended to be used internally in an OWAMP/TWAMP-enabled node, and not intended to be used by intermediate switches and routers that reside between the sender and the receiver/reflector. Any modification of a test packet by intermediate switches or routers should be considered a malicious man-in-the-middle (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 attacker 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 mode or authenticated mode. As described in Section 3.4.2, using the Checksum Complement in encrypted mode does not simplify the implementation compared to using the conventional checksum, and therefore the Checksum Complement should not be used. [Checksum] Rijsinghani, A., Ed., "Computation of the Internet Checksum via Incremental Update", RFC 1624, DOI 10.17487/RFC1624, May 1994, <http://www.rfc-editor.org/info/rfc1624>. [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <http://www.rfc-editor.org/info/rfc4656>.
[TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <http://www.rfc-editor.org/info/rfc5357>. [TWAMP-Reflect] Morton, A. and L. Ciavattone, "Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, <http://www.rfc-editor.org/info/rfc6038>. [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, August 1980, <http://www.rfc-editor.org/info/rfc768>. [IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July 2008. [IPPMIPsec] Pentikousis, K., Ed., Zhang, E., and Y. Cui, "IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)", RFC 7717, DOI 10.17487/RFC7717, December 2015, <http://www.rfc-editor.org/info/rfc7717>. [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 2016, <http://www.rfc-editor.org/info/rfc7821>. [ZeroChecksum] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <http://www.rfc-editor.org/info/rfc6936>.