draft-ietf-ippm-checksum-trailer-06.txt   rfc7820.txt 
Network Working Group T. Mizrahi
Internet Draft Marvell
Intended status: Experimental
Expires: August 2016 February 9, 2016
UDP Checksum Complement in OWAMP and TWAMP Internet Engineering Task Force (IETF) T. Mizrahi
draft-ietf-ippm-checksum-trailer-06.txt 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)
Abstract Abstract
The One-Way Active Measurement Protocol (OWAMP) and the Two-Way The One-Way Active Measurement Protocol (OWAMP) and the Two-Way
Active Measurement Protocol (TWAMP) are used for performance Active Measurement Protocol (TWAMP) are used for performance
monitoring in IP networks. Delay measurement is performed in these monitoring in IP networks. Delay measurement is performed in these
protocols by using timestamped test packets. Some implementations use protocols by using timestamped test packets. Some implementations
hardware-based timestamping engines that integrate the accurate use hardware-based timestamping engines that integrate the accurate
transmission timestamp into every outgoing OWAMP/TWAMP test packet transmission time into every outgoing OWAMP/TWAMP test packet during
during transmission. Since these packets are transported over UDP, transmission. Since these packets are transported over UDP, the UDP
the UDP checksum field is then updated to reflect this modification. Checksum field is then updated to reflect this modification. This
This document proposes to use the last 2 octets of every test packet document proposes to use the last 2 octets of every test packet as a
as a Checksum Complement, allowing timestamping engines to reflect Checksum Complement, allowing timestamping engines to reflect the
the checksum modification in the last 2 octets rather than in the UDP checksum modification in the last 2 octets rather than in the UDP
checksum field. The behavior defined in this document is completely Checksum field. The behavior defined in this document is completely
interoperable with existing OWAMP/TWAMP implementations. interoperable with existing OWAMP/TWAMP implementations.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
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 This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for examination, experimental implementation, and
evaluation.
The list of Internet-Draft Shadow Directories can be accessed at This document defines an Experimental Protocol for the Internet
http://www.ietf.org/shadow.html. 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.
This Internet-Draft will expire on August 9, 2016. 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 Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction ....................................................3
2. Conventions used in this document..............................5 2. Conventions Used in This Document ...............................5
2.1. Terminology...............................................5 2.1. Terminology ................................................5
2.2. Abbreviations.............................................5 2.2. Abbreviations ..............................................5
3. Using the UDP Checksum Complement in OWAMP and TWAMP...........6 3. Using the UDP Checksum Complement in OWAMP and TWAMP ............6
3.1. Overview..................................................6 3.1. Overview ...................................................6
3.2. OWAMP / TWAMP Test Packets with Checksum Complement.......6 3.2. OWAMP/TWAMP Test Packets with Checksum Complement ..........6
3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement.9 3.2.1. Transmission of OWAMP/TWAMP with Checksum
3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum Complement .........................................10
Complement.................................................10 3.2.2. Intermediate Updates of OWAMP/TWAMP with
3.2.3. Reception of OWAMP/TWAMP with Checksum Complement...10 Checksum Complement ................................10
3.3. Interoperability with Existing Implementations...........10 3.2.3. Reception of OWAMP/TWAMP with Checksum Complement ..10
3.4. Using the Checksum Complement with or without Authentication 3.3. Interoperability with Existing Implementations ............10
..............................................................10 3.4. Using the Checksum Complement with or without
3.4.1. Checksum Complement in Authenticated Mode...........10 Authentication ............................................11
3.4.2. Checksum Complement in Encrypted Mode...............11 3.4.1. Checksum Complement in Authenticated Mode ..........11
4. Security Considerations.......................................11 3.4.2. Checksum Complement in Encrypted Mode ..............11
5. IANA Considerations...........................................12 4. Security Considerations ........................................12
6. Acknowledgments...............................................12 5. References .....................................................12
7. References....................................................12 5.1. Normative References ......................................12
7.1. Normative References.....................................12 5.2. Informative References ....................................13
7.2. Informative References...................................13 Appendix A. Checksum Complement Usage Example .....................14
Appendix A. Checksum Complement Usage Example....................13 Acknowledgments ...................................................15
Author's Address ..................................................15
1. Introduction 1. Introduction
The One-Way Active Measurement Protocol ([OWAMP]) and the Two-Way The One-Way Active Measurement Protocol [OWAMP] and the Two-Way
Active Measurement Protocol ([TWAMP]) are used for performance Active Measurement Protocol [TWAMP] are used for performance
monitoring in IP networks. monitoring in IP networks.
Delay and delay variation are two of the metrics that OWAMP/TWAMP can Delay and delay variation are two of the metrics that OWAMP/TWAMP can
measure. This measurement is performed using timestamped test measure. Measurement is performed using timestamped test packets.
packets. In some use cases, such as carrier networks, these two In some use cases, such as carrier networks, these two metrics are an
metrics are an essential aspect of the Service Level Agreement (SLA), essential aspect of the Service Level Agreement (SLA) and therefore
and therefore must be measured with a high degree of accuracy. If must be measured with a high degree of accuracy. If packets are
packets are timestamped in hardware as they exit the host, then timestamped in hardware as they exit the host, then greater accuracy
greater accuracy is possible in comparison to higher-layer timestamps is possible in comparison to higher-layer timestamps (as explained
(as explained further below). further below).
The accuracy of delay measurements relies on the timestamping method The accuracy of delay measurements relies on the timestamping method
and its implementation. In order to facilitate accurate timestamping, and its implementation. In order to facilitate accurate
an implementation can use a hardware based timestamping engine, as timestamping, an implementation can use a hardware-based timestamping
shown in Figure 1. In such cases, the OWAMP/TWMAP packets are sent engine, as shown in Figure 1. In such cases, the OWAMP/TWAMP packets
and received by a software layer, whereas the timestamping engine are sent and received by a software layer, whereas the timestamping
modifies every outgoing test packet by incorporating its accurate engine modifies every outgoing test packet by incorporating its
transmission time into the <Timestamp> field in the packet. accurate transmission time into the Timestamp field in the packet.
OWAMP/TWAMP-enabled Node OWAMP/TWAMP-enabled Node
+-------------------+ +-------------------+
| | | |
| +-----------+ | | +-----------+ |
Software | |OWAMP/TWAMP| | Software | |OWAMP/TWAMP| |
| | protocol | | | | protocol | |
| +-----+-----+ | | +-----+-----+ |
| | | +---------------------+ | | | +-----------------------+
| +-----+-----+ | / Intermediate entity | | +-----+-----+ | / Intermediate entity |
| | Accurate | | / in charge of: | | | Accurate | | / in charge of: |
ASIC/FPGA | | Timestamp | | /__ -Timestamping | ASIC/FPGA | | Timestamp | | /__ - Timestamping |
| | engine | | |-Updating checksum or| | | engine | | |- Updating checksum or |
| +-----------+ | | Checksum Complement | | +-----------+ | | Checksum Complement |
| | | +---------------------+ | | | +-----------------------+
+---------+---------+ +---------+---------+
| |
|test packets |test packets
| |
___ v _ ___ v _
/ \_/ \__ / \_/ \__
/ \_ / \_
/ IP / / IP /
\_ Network / \_ Network /
/ \ / \
\__/\_ ___/ \__/\_ ___/
\_/ \_/
Figure 1 Accurate Timestamping in OWAMP/TWAMP ASIC: Application-Specific Integrated Circuit
FPGA: Field-Programmable Gate Array
OWAMP/TWAMP test packets are transported over UDP. When the UDP 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 payload is changed by an intermediate entity such as the timestamping
engine, the UDP Checksum field must be updated to reflect the new engine, the UDP Checksum field must be updated to reflect the new
payload. When using UDP over IPv4 ([UDP]), an intermediate entity payload. When using UDP over IPv4 [UDP], an intermediate entity that
that cannot update the value of the UDP checksum has no choice except cannot update the value of the UDP Checksum has no choice except to
to assign a value of zero to the checksum field, causing the receiver assign a value of zero to the Checksum field, causing the receiver to
to ignore the checksum field and potentially accept corrupted ignore the Checksum field and potentially accept corrupted packets.
packets. UDP over IPv6, as defined in [IPv6], does not allow a zero UDP over IPv6, as defined in [IPv6], does not allow a zero checksum,
checksum, except in specific cases [ZeroChecksum]. As discussed in except in specific cases [ZeroChecksum]. As discussed in
[ZeroChecksum], the use of a zero checksum is generally not [ZeroChecksum], the use of a zero checksum is generally not
recommended, and should be avoided to the extent possible. recommended and should be avoided to the extent possible.
Since an intermediate entity only modifies a specific field in the Since an intermediate entity only modifies a specific field in the
packet, i.e. the timestamp field, the UDP checksum update can be packet, i.e., the Timestamp field, the UDP Checksum update can be
performed incrementally, using the concepts presented in [Checksum]. performed incrementally, using the concepts presented in [Checksum].
A similar problem is addressed in Annex E of [IEEE1588]. When the A similar problem is addressed in Annex E of [IEEE1588]. When the
Precision Time Protocol (PTP) is transported over IPv6, two octets Precision Time Protocol (PTP) is transported over IPv6, 2 octets are
are appended to the end of the PTP payload for UDP checksum updates. appended to the end of the PTP payload for UDP Checksum updates. The
The value of these two octets can be updated by an intermediate value of these 2 octets can be updated by an intermediate entity,
entity, causing the value of the UDP checksum field to remain causing the value of the UDP Checksum field to remain correct.
correct.
This document defines a similar concept for [OWAMP] and [TWAMP], This document defines a similar concept for [OWAMP] and [TWAMP],
allowing intermediate entities to update OWAMP/TWAMP test packets and allowing intermediate entities to update OWAMP/TWAMP test packets and
maintain the correctness of the UDP checksum by modifying the last 2 maintain the correctness of the UDP Checksum by modifying the last
octets of the packet. 2 octets of the packet.
The term Checksum Complement is used throughout this document and The term "Checksum Complement" is used throughout this document and
refers to the 2 octets at the end of the UDP payload, used for refers to the 2 octets at the end of the UDP payload, used for
updating the UDP checksum by intermediate entities. updating the UDP Checksum by intermediate entities.
The usage of the Checksum Complement can in some cases simplify the The usage of the Checksum Complement can in some cases simplify the
implementation, since if the packet data is processed in a serial implementation, because if the packet data is processed in serial
order, it is simpler to first update the timestamp field, and then order, it is simpler to first update the Timestamp field and then
update the Checksum Complement rather than to update the timestamp update the Checksum Complement, rather than to update the timestamp
and then update the UDP checksum, residing at the UDP header. and then update the UDP Checksum residing at the UDP header.
The Checksum Complement mechanism is also defined for the Network The Checksum Complement mechanism is also defined for the Network
Time Protocol in [NTPComp]. Time Protocol in [RFC7821].
2. Conventions used in this document 2. Conventions Used in This Document
2.1. Terminology 2.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
2.2. Abbreviations 2.2. Abbreviations
HMAC Hashed Message Authentication Code HMAC Hashed Message Authentication Code
OWAMP One-Way Active Measurement Protocol OWAMP One-Way Active Measurement Protocol
PTP Precision Time Protocol PTP Precision Time Protocol
TWAMP Two-Way Active Measurement Protocol TWAMP Two-Way Active Measurement Protocol
UDP User Datagram Protocol UDP User Datagram Protocol
3. Using the UDP Checksum Complement in OWAMP and TWAMP 3. Using the UDP Checksum Complement in OWAMP and TWAMP
3.1. Overview 3.1. Overview
The UDP Checksum Complement is a two-octet field that is piggybacked The UDP Checksum Complement is a 2-octet field that is piggybacked at
at the end of the test packet. It resides in the last 2 octets of the the end of the test packet. It resides in the last 2 octets of the
UDP payload. UDP payload.
+----------------------------------+ +----------------------------------+
| IPv4 / IPv6 Header | | IPv4/IPv6 Header |
+----------------------------------+ +----------------------------------+
| UDP Header | | UDP Header |
+----------------------------------+ +----------------------------------+
^ | | ^ | |
| | OWAMP / TWAMP | | | OWAMP/TWAMP |
UDP | packet | UDP | packet |
Payload +----------------------------------+ Payload +----------------------------------+
| |UDP Checksum Complement (2 octets)| | |UDP Checksum Complement (2 octets)|
v +----------------------------------+ v +----------------------------------+
Figure 2 Checksum Complement in OWAMP/TWAMP Test Packet Figure 2: Checksum Complement in OWAMP/TWAMP Test Packets
The Checksum Complement is used to compensate for changes performed The Checksum Complement is used to compensate for changes performed
in the packet by intermediate entities, as described in the in the packet by intermediate entities, as described in the
introduction. An example of the usage of the Checksum Complement is Introduction (Section 1). An example of the usage of the Checksum
provided in Appendix A. Complement is provided in Appendix A.
3.2. OWAMP / TWAMP Test Packets with Checksum Complement 3.2. OWAMP/TWAMP Test Packets with Checksum Complement
The One-Way Active Measurement Protocol [OWAMP], and the Two-Way The One-Way Active Measurement Protocol [OWAMP] and the Two-Way
Active Measurement Protocol [TWAMP] both make use of timestamped test Active Measurement Protocol [TWAMP] both make use of timestamped test
packets. A Checksum Complement MAY be used in the following cases: 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 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 sender to the reflector.
o In TWAMP test packets, sent by the reflector to the sender. o In TWAMP test packets sent by the reflector to the sender.
OWAMP/TWAMP test packets are transported over UDP, either over IPv4 OWAMP/TWAMP test packets are transported over UDP, either over IPv4
or over IPv6. This document applies to both OWAMP/TWAMP over IPv4 and or over IPv6. This document applies to both OWAMP and TWAMP over
over IPv6. IPv4 and over IPv6.
OWAMP/TWAMP test packets contain a Packet Padding field. This OWAMP/TWAMP test packets contain a Packet Padding field. This
document proposes to use the last 2 octets of the Packet Padding document proposes to use the last 2 octets of the Packet Padding
field as the Checksum Complement. In this case the Checksum field as the Checksum Complement. In this case, the Checksum
Complement is always the last 2 octets of the UDP payload, and thus Complement is always the last 2 octets of the UDP payload, and thus
the field is located UDP Length - 2 octets after the beginning of the the field is located at (UDP Length - 2 octets) after the beginning
UDP header. of the UDP header.
Figure 3 illustrates the OWAMP test packet format including the UDP Figure 3 illustrates the OWAMP test packet format, including the UDP
Checksum Complement. Checksum Complement.
0 1 2 3 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 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 | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | | | Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
. Packet Padding . . Packet Padding .
. . . .
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Checksum Complement | | | Checksum Complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Checksum Complement in OWAMP Test Packets
Figure 4 illustrates the TWAMP test packet format including the UDP Figure 3: Checksum Complement in OWAMP Test Packets
Checksum Complement.
0 1 2 3 Figure 4 illustrates the TWAMP test packet format, including the UDP
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 Checksum Complement. ("TTL" means "Time to Live", and "MBZ" refers
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ to the "MUST be zero" field [IPPMIPsec].)
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3
| Timestamp | 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 |
| Error Estimate | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp |
| Receive Timestamp | | |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | MBZ |
| Sender Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp |
| Sender Timestamp | | |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Sequence Number |
| Sender Error Estimate | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Timestamp |
| Sender TTL | | | |
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Sender Error Estimate | MBZ |
. . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Packet Padding . | Sender TTL | |
. . +-+-+-+-+-+-+-+-+ +
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Checksum Complement | . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Packet Padding .
Figure 4 Checksum Complement in TWAMP Test Packets . .
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Checksum Complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Checksum Complement in TWAMP Test Packets
The length of the Packet Padding field in test packets is announced The length of the Packet Padding field in test packets is announced
during the session initiation through the <Padding Length> field in during the session initiation through the <Padding Length> field in
the Request-Session message [OWAMP], or in the Request-TW-Session the Request-Session message [OWAMP] or in the Request-TW-Session
[TWAMP]. message [TWAMP].
When a Checksum Complement is included, the <Padding Length> MUST be When a Checksum Complement is included, the padding length MUST be
sufficiently long to include the Checksum Complement: sufficiently long to include the Checksum Complement:
o In OWAMP the padding length is at least 2 octets, allowing the o In OWAMP, the padding length is at least 2 octets, allowing the
sender to incorporate the Checksum Complement in the last 2 octets sender to incorporate the Checksum Complement in the last 2 octets
of the padding. of the padding.
o In TWAMP the padding length is at least 29 octets in o In TWAMP, the padding length is at least 29 octets in
unauthenticated mode, and at least 58 octets long in authenticated unauthenticated mode and at least 58 octets in authenticated mode.
mode. The additional padding is required since the header of The additional padding is required, since the header of reflector
reflector test packets is longer than the header of sender test test packets is longer than the header of sender test packets.
packets. The difference between the sender packet and the The difference between the sender packet and the reflector packet
reflector packet is 27 octets in unauthenticated mode, and 56 is 27 octets in unauthenticated mode and 56 octets in
octets in authenticated mode. authenticated mode. Thus, the padding in reflector test packets
Thus, the padding in reflector test packets is shorter than in is shorter than the padding in sender packets. Using at least
sender packet. Using at least 29 octets of padding (58 in 29 octets of padding (58 in authenticated mode) in sender test
authenticated mode) in sender test packets allows both the sender packets allows both the sender and the reflector to use a 2-octet
and the reflector to use a 2-octet Checksum Complement. Checksum Complement. Note: If the minimal length requirement is
Note: if the minimal length requirement is not met, the reflector not met, the reflector cannot use a Checksum Complement in the
cannot use a Checksum Complement in the reflected test packets, reflected test packets, but the sender can use a Checksum
but the sender can use a Checksum Complement in the test packets Complement in the test packets it transmits.
it transmits.
o Two optional TWAMP features are defined in [RFC6038]: octet o Two optional TWAMP features are defined in [TWAMP-Reflect]:
reflection and symmetrical size. When at least one of these octet reflection and symmetrical size. When at least one of these
features is enabled, the Request-TW-Session includes the <Padding features is enabled, the Request-TW-Session message includes the
Length> field, as well as a <Length of padding to reflect> field. <Padding Length> field, as well as a <Length of padding to
In this case both fields must be sufficiently long to allow at reflect> field. In this case, both fields must be sufficiently
least 2 octets of padding in both sender test packets and long to allow at least 2 octets of padding in both sender test
reflector test packets. packets and reflector test packets. Specifically, when octet
Specifically, when octet reflection is enabled, the two length reflection is enabled, the two Length fields must be defined such
fields must be defined such that the padding expands at least 2 that the padding expands at least 2 octets beyond the end of the
octets beyond the end of the reflected octets. reflected octets.
As described in Section 1. , the extensions described in this As described in Section 1, the extensions described in this document
document are implemented by two logical layers, a protocol layer and are implemented by two logical layers -- a protocol layer and a
a timestamping layer. It is assumed that the two layers are timestamping layer. It is assumed that the two layers are
synchronized about whether the usage of the Checksum Complement is synchronized regarding whether the usage of the Checksum Complement
enabled or not; since both logical layers reside in the same network is enabled or not; since both logical layers reside in the same
device, it is assumed there is no need for a protocol that network device, it is assumed that there is no need for a protocol
synchronizes this information between the two layers. When Checksum that synchronizes this information between the two layers. When
Complement usage is enabled, the protocol layer must take care to Checksum Complement usage is enabled, the protocol layer must take
verify that test packets include the necessary padding, and avoiding care to verify that test packets include the necessary padding,
the need for the timestamping layer to verify that en-route test thereby avoiding the need for the timestamping layer to verify that
packets include the necessary padding. en-route test packets include the necessary padding.
3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement 3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement
The transmitter of an OWAMP/TWAMP test packet MAY include a Checksum The transmitter of an OWAMP/TWAMP test packet MAY include a Checksum
Complement field, incorporated in the last 2 octets of the Packet Complement field, incorporated in the last 2 octets of the padding.
Padding.
A transmitter that includes a Checksum Complement in its outgoing A transmitter that includes a Checksum Complement in its outgoing
test packets MUST include a Packet Padding in these packets, the test packets MUST include a Packet Padding field in these packets,
length of which MUST be sufficient to include the Checksum the length of which MUST be sufficient to include the Checksum
Complement. The length of the padding field is negotiated during Complement. The length of the Packet Padding field is negotiated
session initiation, as described in Section 3.2. during session initiation, as described in Section 3.2.
3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum Complement 3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum Complement
An intermediate entity that receives and alters an OWAMP/TWAMP test An intermediate entity that receives and alters an OWAMP/TWAMP
packet can alter either the UDP Checksum field or the Checksum test packet can alter either the UDP Checksum field or the Checksum
Complement field in order to maintain the correctness of the UDP Complement field in order to maintain the correctness of the
checksum value. UDP Checksum value.
3.2.3. Reception of OWAMP/TWAMP with Checksum Complement 3.2.3. Reception of OWAMP/TWAMP with Checksum Complement
This document does not impose new requirements on the receiving end This document does not impose new requirements on the receiving end
of an OWAMP/TWAMP test packet. of an OWAMP/TWAMP test packet.
The UDP layer at the receiving end verifies the UDP Checksum of The UDP layer at the receiving end verifies the UDP Checksum of
received test packets, and the OWAMP/TWAMP layer should treat the received test packets, and the OWAMP/TWAMP layer should treat the
Checksum Complement as part of the Packet Padding. Checksum Complement as part of the padding.
3.3. Interoperability with Existing Implementations 3.3. Interoperability with Existing Implementations
The behavior defined in this document does not impose new The behavior defined in this document does not impose new
requirements on the reception behavior of OWAMP/TWAMP test packets. requirements on the reception behavior of OWAMP/TWAMP test packets.
The protocol stack of the receiving host performs the conventional The protocol stack of the receiving host performs the conventional
UDP checksum verification, and thus the existence of the Checksum UDP Checksum verification; thus, from the perspective of the
Complement is transparent from the perspective of the receiving host. receiving host, the existence of the Checksum Complement is
Therefore, the functionality described in this document allows transparent. Therefore, the functionality described in this document
interoperability with existing implementations that comply to [OWAMP] allows interoperability with existing implementations that comply
or [TWAMP]. with [OWAMP] or [TWAMP].
3.4. Using the Checksum Complement with or without Authentication 3.4. Using the Checksum Complement with or without Authentication
Both OWAMP and TWAMP may use authentication or encryption, as defined Both OWAMP and TWAMP may use authentication or encryption, as defined
in [OWAMP] and [TWAMP]. in [OWAMP] and [TWAMP].
3.4.1. Checksum Complement in Authenticated Mode 3.4.1. Checksum Complement in Authenticated Mode
OWAMP and TWAMP test packets can be authenticated using an HMAC OWAMP and TWAMP test packets can be authenticated using an HMAC
(Hashed Message Authentication Code). The HMAC covers some of the (Hashed Message Authentication Code). The HMAC covers some of the
fields in the test packet header. The HMAC does not cover the fields in the test packet header. The HMAC does not cover the
Timestamp field and the Packet Padding field. Timestamp field and the Packet Padding field.
A Checksum Complement MAY be used when authentication is enabled. In A Checksum Complement MAY be used when authentication is enabled. In
this case an intermediate entity can timestamp test packets and this case, an intermediate entity can timestamp test packets and
update their Checksum Complement field without modifying the HMAC. update their Checksum Complement field without modifying the HMAC.
3.4.2. Checksum Complement in Encrypted Mode 3.4.2. Checksum Complement in Encrypted Mode
When OWAMP and TWAMP are used in encrypted mode, the Timestamp field When OWAMP and TWAMP are used in encrypted mode, the Timestamp field
is encrypted. is encrypted.
A Checksum Complement SHOULD NOT be used in encrypted mode. The A Checksum Complement SHOULD NOT be used in encrypted mode. The
Checksum Complement is effective in unauthenticated and in Checksum Complement is effective in both unauthenticated mode and
authenticated mode, allowing the intermediate entity to perform authenticated mode, allowing the intermediate entity to perform
serial processing of the packet without storing-and-forwarding it. serial processing of the packet without storing and forwarding it.
On the other hand, in encrypted mode an intermediate entity that On the other hand, in encrypted mode, an intermediate entity that
timestamps a test packet must also re-encrypt the packet accordingly. timestamps a test packet must also re-encrypt the packet accordingly.
Re-encryption typically requires the intermediate entity to store the Re-encryption typically requires the intermediate entity to store the
packet, re-encrypt it, and then forward it. Thus, from an packet, re-encrypt it, and then forward it. Thus, from an
implementer's perspective, the Checksum Complement has very little implementer's perspective, the Checksum Complement has very little
value in encrypted mode, as it does not necessarily simplify the value in encrypted mode, as it does not necessarily simplify the
implementation. implementation.
Note: while [OWAMP] and [TWAMP] include an inherent security Note: While [OWAMP] and [TWAMP] include an inherent security
mechanism, these protocols can be secured by other measures, e.g., mechanism, these protocols can be secured by other measures, e.g.,
[IPPMIPsec]. For similar reasons as described above, a Checksum [IPPMIPsec]. For reasons similar to those described above, a
Complement SHOULD NOT be used in this case. Checksum Complement SHOULD NOT be used in this case.
4. Security Considerations 4. Security Considerations
This document describes how a Checksum Complement extension can be This document describes how a Checksum Complement extension can be
used for maintaining the correctness of the UDP checksum. used for maintaining the correctness of the UDP Checksum.
The purpose of this extension is to ease the implementation of The purpose of this extension is to ease the implementation of
accurate timestamping engines, as described in Figure 1. The accurate timestamping engines, as illustrated in Figure 1. The
extension is intended to be used internally in an OWAMP/TWAMP enabled extension is intended to be used internally in an OWAMP/TWAMP-enabled
node, and not intended to be used by intermediate switches and node, and not intended to be used by intermediate switches and
routers that reside between the sender and the receiver/reflector. routers that reside between the sender and the receiver/reflector.
Any modification of a test packet by intermediate switches or routers Any modification of a test packet by intermediate switches or routers
should be considered a malicious MITM attack. should be considered a malicious man-in-the-middle (MITM) attack.
It is important to emphasize that the scheme described in this It is important to emphasize that the scheme described in this
document does not increase the protocol's vulnerability to MITM document does not increase the protocol's vulnerability to MITM
attacks; a MITM who maliciously modifies a packet and its Checksum attacks; a MITM attacker who maliciously modifies a packet and its
Complement is logically equivalent to a MITM attacker who modifies a Checksum Complement is logically equivalent to a MITM attacker who
packet and its UDP Checksum field. modifies a packet and its UDP Checksum field.
The concept described in this document is intended to be used only in The concept described in this document is intended to be used only in
unauthenticated or in authenticated mode. As described in Section unauthenticated mode or authenticated mode. As described in
3.4.2. , in encrypted mode using the Checksum Complement does not Section 3.4.2, using the Checksum Complement in encrypted mode does
simplify the implementation compared to using the conventional not simplify the implementation compared to using the conventional
Checksum, and therefore the Checksum Complement should not be used. 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, Steve
Baillargeon, Brian Haberman, and Spencer Dawkins for their helpful
comments.
This document was prepared using 2-Word-v2.0.template.dot.
7. References 5. References
7.1. Normative References 5.1. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [Checksum] Rijsinghani, A., Ed., "Computation of the Internet
Requirement Levels", BCP 14, RFC 2119, March 1997. Checksum via Incremental Update", RFC 1624,
DOI 10.17487/RFC1624, May 1994,
<http://www.rfc-editor.org/info/rfc1624>.
[IPv6] Deering, S., Hinden, R., "Internet Protocol, Version 6 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[Checksum] Rijsinghani, A., "Computation of the Internet Checksum [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
via Incremental Update", RFC 1624, May 1994. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[UDP] Postel, J., "User Datagram Protocol", RFC 768, August [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
1980. Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<http://www.rfc-editor.org/info/rfc4656>.
[OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Zekauskas, M., "A One-way Active Measurement Protocol Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
(OWAMP)", RFC 4656, September 2006. RFC 5357, DOI 10.17487/RFC5357, October 2008,
<http://www.rfc-editor.org/info/rfc5357>.
[TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and [TWAMP-Reflect]
Babiarz, J., "A Two-Way Active Measurement Protocol Morton, A. and L. Ciavattone, "Two-Way Active Measurement
(TWAMP)", RFC 5357, October 2008. Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, DOI 10.17487/RFC6038, October 2010,
<http://www.rfc-editor.org/info/rfc6038>.
[RFC6038] Morton, A., Ciavattone, L., "Two-Way Active [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
Measurement Protocol (TWAMP) Reflect Octets and DOI 10.17487/RFC768, August 1980,
Symmetrical Size Features", RFC 6038, October 2010. <http://www.rfc-editor.org/info/rfc768>.
7.2. Informative References 5.2. Informative References
[IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, [IEEE1588] IEEE, "IEEE Standard for a Precision Clock
"1588 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and
Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2008,
Control Systems Version 2", IEEE Standard, 2008. DOI 10.1109/IEEESTD.2008.4579760, July 2008.
[IPPMIPsec] Pentikousis, K., Zhang, E., Cui, Y., "IKEv2-Derived [IPPMIPsec] Pentikousis, K., Ed., Zhang, E., and Y. Cui,
Shared Secret Key for the One-Way Active Measurement "IKEv2-Derived Shared Secret Key for the One-Way Active
Protocol (OWAMP) and Two-Way Active Measurement Measurement Protocol (OWAMP) and Two-Way Active
Protocol (TWAMP)", RFC 7717, December 2015. Measurement Protocol (TWAMP)", RFC 7717,
DOI 10.17487/RFC7717, December 2015,
<http://www.rfc-editor.org/info/rfc7717>.
[NTPComp] Mizrahi, T., "UDP Checksum Complement in the Network [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time
Time Protocol (NTP)", draft-ietf-ntp-checksum-trailer Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821,
(work in progress), October 2015. March 2016, <http://www.rfc-editor.org/info/rfc7821>.
[ZeroChecksum] Fairhurst, G., Westerlund, M., "Applicability [ZeroChecksum]
Statement for the Use of IPv6 UDP Datagrams with Zero Fairhurst, G. and M. Westerlund, "Applicability Statement
Checksums", RFC 6936, April 2013. 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 Appendix A. Checksum Complement Usage Example
Consider a session between an OWAMP sender and an OWAMP receiver, in Consider a session between an OWAMP sender and an OWAMP receiver, in
which the sender transmits test packets to the receiver. which the sender transmits test packets to the receiver.
The sender's software layer generates an OWAMP test packet with a The sender's software layer generates an OWAMP test packet with a
timestamp T, and a UDP checksum value U. The value of U is the timestamp T and a UDP Checksum value U. The value of U is the
checksum of the UDP header, UDP payload, and pseudo-header. Thus, U checksum of the UDP header, UDP payload, and pseudo-header. Thus,
is equal to: U is equal to:
U = Const + checksum(T) (1) U = Const + checksum(T) (1)
Where 'Const' is the checksum of all the fields that are covered by Where "Const" is the checksum of all the fields that are covered by
the checksum except the timestamp T. the checksum, except the timestamp T.
Recall that the sender's software emits the test packet with a Recall that the sender's software emits the test packet with a
Checksum Complement field, which is simply the last two bytes of the Checksum Complement field, which is simply the last 2 octets of the
padding. In this example it is assumed that the sender initially padding. In this example, it is assumed that the sender initially
assigns zero to these two bytes. assigns zero to these 2 octets.
The sender's timestamping engine updates the timestamp field to the The sender's timestamping engine updates the Timestamp field to the
accurate time, changing its value from T to T'. The sender also accurate time, changing its value from T to T'. The sender also
updates the Checksum Complement field from zero to a new value C, updates the Checksum Complement field from zero to a new value C,
such that: such that:
checksum(C) = checksum(T) - checksum(T') (2) checksum(C) = checksum(T) - checksum(T') (2)
When the test packet is transmitted by the sender's timestamping When the test packet is transmitted by the sender's timestamping
engine, the value of the checksum remains U as before: engine, the value of the checksum remains U as before:
U = Const + checksum(T) = Const + checksum(T)+ checksum(T')- U = Const + checksum(T) = Const + checksum(T) + checksum(T') -
checksum(T') = Const + checksum(T') + checksum(C) (3) checksum(T') = Const + checksum(T') + checksum(C) (3)
Thus, after the timestamping engine has updated the timestamp, U Thus, after the timestamping engine has updated the timestamp,
remains the correct checksum of the packet. U remains the correct checksum of the packet.
When the test packet reaches the receiver, the receiver performs a When the test packet reaches the receiver, the receiver performs a
conventional UDP checksum computation, and the computed value is U. conventional UDP Checksum computation, and the computed value is U.
Since the Checksum Complement is part of the padding, the value of Since the Checksum Complement is part of the padding, the value of
checksum(C) is transparently included in the computation, as per checksum(C) is transparently included in the computation, as per
Equation (3), without requiring special treatment by the receiver. Equation (3), without requiring special treatment by the receiver.
Authors' Addresses Acknowledgments
The author gratefully acknowledges Al Morton, Greg Mirsky, Steve
Baillargeon, Brian Haberman, and Spencer Dawkins for their helpful
comments.
Author's Address
Tal Mizrahi Tal Mizrahi
Marvell Marvell
6 Hamada St. 6 Hamada St.
Yokneam, 20692 Israel Yokneam, 20692
Israel
Email: talmi@marvell.com Email: talmi@marvell.com
 End of changes. 110 change blocks. 
338 lines changed or deleted 347 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/