RFC 7820

UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)

📅 published March 2016, from ietf

RFC 7820 🎀 UDP Checksum Complement in OWAMP and TWAMP

Okay bestie, the title block is giving RFC 7820 💅 and the title is UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) ✨. It's an Experimental doc, published by the Internet Engineering Task Force (IETF) in March 2016 (ISSN 2070-1721). T. Mizrahi from Marvell wrote it 🧚. The title block doesn't list any obsoletes or updates, so it doesn't replace or change any other RFCs 🌸.

Abstract ✨

So the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are the tools people use to keep an eye on performance in IP networks 👀. Delay gets measured by stamping test packets with times 🕰️. Some implementations use hardware timestamping engines that put the accurate transmission time into every outgoing OWAMP/TWAMP test packet as it leaves 🔥. Because these packets ride on UDP, the UDP Checksum field has to be updated to match that change 🙈.

This doc proposes using the last 2 octets of every test packet as a Checksum Complement 💜. That way the timestamping engine can fix up the checksum change in those last 2 octets, instead of touching the UDP Checksum field 🦋. The behavior defined here is completely interoperable with existing OWAMP/TWAMP implementations 🫶.

Status of This Memo 📝

Real talk, this doc is not an Internet Standards Track spec. It's published for examination, experimental implementation, and evaluation 🧪.

It defines an Experimental Protocol for the Internet community. It's a product of the IETF and represents IETF community consensus 🤝. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 💖.

For the latest status, errata, and feedback info, go to http://www.rfc-editor.org/info/rfc7820 ✨.

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for 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 they're provided without warranty as described in the Simplified BSD License ⚖️.

Table of Contents 📚

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

1. Introduction 🦋

Okay so the One-Way Active Measurement Protocol [OWAMP] and the Two-Way Active Measurement Protocol [TWAMP] are the performance-monitoring protocols for IP networks 📊.

Delay and delay variation are two of the metrics OWAMP/TWAMP can measure 🕰️. Measurement is done with timestamped test packets. In some use cases, like carrier networks, these two metrics are a huge part of the Service Level Agreement (SLA), so they must be measured with a high degree of accuracy 😤. If packets get timestamped in hardware as they exit the host, you get more accuracy than with higher-layer timestamps (more on that below) 🔥.

The accuracy of delay measurements depends on the timestamping method and how it's implemented 🤓. To get accurate timestamps, an implementation can use a hardware-based timestamping engine, as shown in Figure 1 💅. In that setup, the OWAMP/TWAMP packets are sent and received by a software layer, while the timestamping engine changes every outgoing test packet by putting its accurate transmission time into the Timestamp field 🫶.

                  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 ride on UDP 📦. When an intermediate entity like the timestamping engine changes the UDP payload, the UDP Checksum field must be updated to reflect the new payload 🔄. When you're using UDP over IPv4 [UDP], an intermediate entity that can't update the UDP Checksum value has no choice but to set the Checksum field to zero 😬. That makes the receiver ignore the Checksum field, so it might accept corrupted packets 💀. UDP over IPv6, as defined in [IPv6], doesn't allow a zero checksum, except in specific cases [ZeroChecksum]. As [ZeroChecksum] discusses, a zero checksum is generally not recommended and should be avoided to the extent possible 🙅‍♀️.

Since an intermediate entity only modifies one specific field in the packet, the Timestamp field, the UDP Checksum update can be done incrementally, using the concepts in [Checksum] 🧮.

A similar problem gets solved in Annex E of [IEEE1588] 🌸. When the Precision Time Protocol (PTP) runs over IPv6, 2 octets get appended to the end of the PTP payload for UDP Checksum updates. An intermediate entity can update the value of those 2 octets, so the UDP Checksum field stays correct ✨.

This document defines a similar concept for [OWAMP] and [TWAMP] 💖. It lets intermediate entities update OWAMP/TWAMP test packets and keep the UDP Checksum correct by modifying the last 2 octets of the packet 🎀.

The term "Checksum Complement" shows up all over this document. It refers to the 2 octets at the end of the UDP payload that intermediate entities use to update the UDP Checksum 🧚.

The Checksum Complement can make implementation simpler in some cases. If the packet data is processed in serial order, it's easier to update the Timestamp field first and then the Checksum Complement, instead of updating the timestamp and then the UDP Checksum sitting in the UDP header 🧠.

The Checksum Complement mechanism is also defined for the Network Time Protocol in [RFC7821] 🕰️💜.

2. Conventions Used in This Document 📖

2.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS] 🔑.

2.2. Abbreviations 🔤

HMAC     Hashed Message Authentication Code

OWAMP    One-Way Active Measurement Protocol

PTP      Precision Time Protocol

TWAMP    Two-Way Active Measurement Protocol

UDP      User Datagram Protocol

3. Using the UDP Checksum Complement in OWAMP and TWAMP 🧩

3.1. Overview 🌈

Here's the vibe: the UDP Checksum Complement is a 2-octet field that gets piggybacked at the end of the test packet 💅. It lives in the last 2 octets of the UDP payload 🫶.

                   +----------------------------------+
                   |         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 compensates for changes that intermediate entities make to the packet, as the Introduction (Section 1) explained 🔁. You can see a worked example in Appendix A 👀✨.

3.2. OWAMP/TWAMP Test Packets with Checksum Complement ✨

okay so OWAMP and TWAMP are both obsessed with timestamped test packets 🕰️💖 The [OWAMP] and [TWAMP] protocols both use them, and a Checksum Complement MAY be used in these spots:

  • 🎀 OWAMP test packets the sender sends to the receiver.
  • 🌸 TWAMP test packets the sender sends to the reflector.
  • 🦋 TWAMP test packets the reflector sends back to the sender.

OWAMP/TWAMP test packets ride on UDP, whether that's over IPv4 or IPv6, and this document covers both OWAMP and TWAMP over IPv4 and over IPv6 💅

OWAMP/TWAMP test packets have a Packet Padding field, and this document proposes using the last 2 octets of that field as the Checksum Complement 🧚 So the Checksum Complement is always the last 2 octets of the UDP payload, which means it sits at (UDP Length - 2 octets) counted from the start of the UDP header. Main character placement fr 👑

Figure 3 shows the OWAMP test packet format with the UDP Checksum Complement tucked in:

 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 shows the TWAMP test packet format with 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 gets announced during session setup, 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 long enough to fit the Checksum Complement 🫶

  • In OWAMP, the padding length is at least 2 octets, so the sender can tuck the Checksum Complement into the last 2 octets of the padding.
  • In TWAMP, the padding length is at least 29 octets in unauthenticated mode and at least 58 octets in authenticated mode. The extra padding is needed because 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, so the padding in reflector test packets ends up shorter than the padding in sender packets. Using at least 29 octets of padding (58 in authenticated mode) in sender test packets lets both the sender and the reflector 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 still use a Checksum Complement in the test packets it transmits.
  • 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 long enough 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 so the padding extends at least 2 octets beyond the end of the reflected octets 🌈

As described in Section 1, the extensions in this document are built from two logical layers: a protocol layer and a timestamping layer ⭐ Both layers are assumed to agree on whether Checksum Complement usage is enabled. Since both logical layers live in the same network device, no protocol is assumed to be needed to keep that information in sync between them. When Checksum Complement usage is enabled, the protocol layer must take care to verify that test packets include the necessary padding, which means the timestamping layer doesn't need to check that en-route test packets include it 🧚

3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement 🚀

The transmitter of an OWAMP/TWAMP test packet MAY include a Checksum Complement field, tucked into the last 2 octets of the padding.

A transmitter that includes a Checksum Complement in its outgoing test packets MUST include a Packet Padding field in those packets, and the length of that field MUST be enough to hold the Checksum Complement. The length of the Packet 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 can alter either the UDP Checksum field or the Checksum Complement field, so that the UDP Checksum value stays correct ✨

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 padding.

3.3. Interoperability with Existing Implementations 🤝

The behavior defined in this document does not impose new requirements on the reception behavior of OWAMP/TWAMP test packets. The receiving host's protocol stack does the usual UDP Checksum verification, so from the receiving host's point of view, the Checksum Complement is totally invisible 🫥 That means the functionality in this document works with existing implementations that comply with [OWAMP] or [TWAMP]. Iconic compatibility 💖

3.4. Using the Checksum Complement with or without Authentication 🔐

Both OWAMP and TWAMP may use authentication or encryption, as defined in [OWAMP] and [TWAMP] 🎀

3.4.1. Checksum Complement in Authenticated Mode

OWAMP and TWAMP test packets can be authenticated using an HMAC (Hashed Message Authentication Code). The HMAC covers some of the fields in the test packet header. The HMAC does not cover the Timestamp field or the Packet Padding field.

A Checksum Complement MAY be used when authentication is enabled. In this case, an intermediate entity can timestamp test packets and update their Checksum Complement field without modifying the HMAC 🫶

3.4.2. Checksum Complement in Encrypted Mode 🙈

When OWAMP and TWAMP are used in encrypted mode, the Timestamp field is encrypted.

A Checksum Complement SHOULD NOT be used in encrypted mode. The Checksum Complement works in both unauthenticated mode and authenticated mode, letting the intermediate entity process the packet serially 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 to match. Re-encryption typically means the intermediate entity has to store the packet, re-encrypt it, and then forward it. So from an implementer's perspective, the Checksum Complement has very little value in encrypted mode, because it doesn't 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 reasons similar to those described above, a Checksum Complement SHOULD NOT be used in this case. 💀

4. Security Considerations ✨

okay bestie, this section is literally about keeping the UDP Checksum correct 🫶 The whole point of the Checksum Complement extension is to make accurate timestamping engines easier to build 💅 It's illustrated in Figure 1, and it's meant to be used inside an OWAMP/TWAMP-enabled node. It is NOT meant for intermediate switches and routers sitting between the sender and the receiver/reflector 🙅‍♀️ Any change to a test packet made by those in-between devices should be considered a malicious man-in-the-middle (MITM) attack 😭🚨

It's important to say this out loud: the scheme in this document does not make the protocol more vulnerable to MITM attacks 🛡️ An attacker who maliciously changes a packet and its Checksum Complement is basically doing the same thing as an attacker who changes a packet and its UDP Checksum field. Same energy, same result, no new hole 💀

This concept is meant to be used only in unauthenticated mode or authenticated mode 🔐 As Section 3.4.2 explains, using the Checksum Complement in encrypted mode doesn't make implementation any simpler than using the conventional checksum, so the Checksum Complement should not be used there 🙈 Not worth it, periodt 💜

5. References

5.1. Normative References

5.2. Informative References

  • [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.

Appendix A. Checksum Complement Usage Example 🎀

okay this one is my favourite, so let's walk through it together 🦋 Picture a session between an OWAMP sender and an OWAMP receiver, where the sender keeps firing test packets at the receiver 💌

The sender's software layer makes an OWAMP test packet with a timestamp T and a UDP Checksum value U. The value of U is the checksum of the UDP header, UDP payload, and pseudo-header, so U works out to:

                        U = Const + checksum(T)                      (1)

Here "Const" is the checksum of all the fields that are covered by the checksum, except the timestamp T. Basically, everything that isn't the timestamp goes in that bucket 🪣

Quick reminder: the sender's software sends the test packet with a Checksum Complement field, which is just the last 2 octets of the padding ✨ For this example, we assume the sender starts by setting those 2 octets to zero 🌸

Now the sender's timestamping engine updates the Timestamp field to the accurate time, changing it from T to T'. At the same time, it updates the Checksum Complement field from zero to a new value C, chosen so that:

                  checksum(C) = checksum(T) - checksum(T')           (2)

When the timestamping engine transmits the test packet, the checksum still comes out to U, just like before 🔥 Here's the math, slow and steady:

      U = Const + checksum(T) = Const + checksum(T) + checksum(T') -
          checksum(T') = Const + checksum(T') + checksum(C)          (3)

So after the timestamping engine has updated the timestamp, U is still the correct checksum for the packet 🥹 Iconic.

When the test packet arrives at the receiver, the receiver does a regular UDP Checksum computation, and the computed value is U. Since the Checksum Complement lives inside the padding, checksum(C) gets counted automatically, as shown in Equation (3). The receiver doesn't need any special handling for it 🧚 No extra work, no drama, just vibes 💖

Acknowledgments

The author is so grateful to Al Morton, Greg Mirsky, Steve Baillargeon, Brian Haberman, and Spencer Dawkins for their helpful comments 🫶🌈

Author's Address

Tal Mizrahi
Marvell
6 Hamada St.
Yokneam, 20692
Israel

Email: talmi@marvell.com
📦 where this page comes from