draft-ietf-ippm-checksum-trailer-01.txt   draft-ietf-ippm-checksum-trailer-02.txt 
Network Working Group T. Mizrahi Network Working Group T. Mizrahi
Internet Draft Marvell Internet Draft Marvell
Intended status: Informational Intended status: Informational
Expires: September 2015 March 9, 2015 Expires: January 2016 July 20, 2015
UDP Checksum Complement in OWAMP and TWAMP UDP Checksum Complement in OWAMP and TWAMP
draft-ietf-ippm-checksum-trailer-01.txt draft-ietf-ippm-checksum-trailer-02.txt
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 use
hardware-based timestamping engines that integrate the accurate hardware-based timestamping engines that integrate the accurate
transmission timestamp into every outgoing OWAMP/TWAMP test packet transmission timestamp into every outgoing OWAMP/TWAMP test packet
during transmission. Since these packets are transported over UDP, during transmission. Since these packets are transported over UDP,
skipping to change at page 1, line 47 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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...................................................2
2. Conventions used in this document ............................ 4 2. Conventions used in this document..............................4
2.1. Terminology ............................................. 4 2.1. Terminology...............................................4
2.2. Abbreviations ........................................... 4 2.2. Abbreviations.............................................4
3. Using the UDP Checksum Complement in OWAMP and TWAMP ......... 5 3. Using the UDP Checksum Complement in OWAMP and TWAMP...........5
3.1. Overview ................................................ 5 3.1. Overview..................................................5
3.2. OWAMP / TWAMP Test Packets with Checksum Complement ..... 5 3.2. OWAMP / TWAMP Test Packets with Checksum Complement.......5
3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement 8 3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement.8
3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum 3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum
Complement ................................................ 9 Complement..................................................9
3.2.3. Reception 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 3.3. Interoperability with Existing Implementations............9
3.4. Using the Checksum Complement with or without Authentication 3.4. Using the Checksum Complement with or without Authentication
............................................................ 9 ...............................................................9
3.4.1. Checksum Complement in Authenticated Mode........... 9 3.4.1. Checksum Complement in Authenticated Mode............9
3.4.2. Checksum Complement in Encrypted Mode .............. 9 3.4.2. Checksum Complement in Encrypted Mode................9
4. Security Considerations ..................................... 10 4. Security Considerations.......................................10
5. IANA Considerations ......................................... 10 5. IANA Considerations...........................................10
6. Acknowledgments ............................................. 11 6. Acknowledgments...............................................11
7. References .................................................. 11 7. References....................................................11
7.1. Normative References ................................... 11 7.1. Normative References.....................................11
7.2. Informative References ................................. 11 7.2. Informative References...................................11
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. This measurement is performed using timestamped test
packets. packets.
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 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 shown in Figure 1. In such cases, the OWAMP/TWMAP packets are sent
and received by a software layer, whereas the timestamping engine and received by a software layer, whereas the timestamping engine
modifies every outgoing test packet by incorporating its accurate modifies every outgoing test packet by incorporating its accurate
transmission time into the <Timestamp> field in the packet. transmission time into the <Timestamp> field in the packet.
OWAMP/TWAMP-enabled Node OWAMP/TWAMP-enabled Node
+-------------------+ +-------------------+
| | | |
| +-----------+ | | +-----------+ |
Software | |OWAMP/TWAMP| | Software | |OWAMP/TWAMP| |
skipping to change at page 4, line 6 skipping to change at page 4, line 6
/ \ / \
\__/\_ ___/ \__/\_ ___/
\_/ \_/
Figure 1 Accurate Timestamping in OWAMP/TWAMP Figure 1 Accurate Timestamping in OWAMP/TWAMP
OWAMP/TWAMP test packets are transported over UDP. When the UDP 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 cannot update the value of the UDP checksum can assign a value that cannot update the value of the UDP checksum has no choice except
of zero to the checksum field, causing the receiver to ignore the to assign a value of zero to the checksum field, causing the receiver
checksum field. UDP over IPv6, as defined in [IPv6], does not allow a to ignore the checksum field and potentially accept corrupted
zero checksum, and requires the UDP checksum field to contain a packets. UDP over IPv6, as defined in [IPv6], does not allow a zero
correct checksum of the UDP payload. 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 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, two octets
are appended to the end of the PTP payload for UDP checksum updates. 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 The value of these two octets can be updated by an intermediate
entity, causing the value of the UDP checksum field to remain entity, causing the value of the UDP checksum field to remain
skipping to change at page 5, line 38 skipping to change at page 5, line 40
v +----------------------------------+ v +----------------------------------+
Figure 2 Checksum Complement in OWAMP/TWAMP Test Packet Figure 2 Checksum Complement in OWAMP/TWAMP Test Packet
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/TWAMP over IPv4 and
over IPv6. 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 UDP Length - 2 octets after the beginning of the
skipping to change at page 6, line 31 skipping to change at page 6, line 31
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | | | Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
. Packet Padding . . Packet Padding .
. . . .
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Checksum Complement | | | Checksum Complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Checksum Complement in OWAMP Test Packets Figure 3 Checksum Complement in OWAMP Test Packets
Figure 4 illustrates the TWAMP test packet format including the UDP Figure 4 illustrates the TWAMP 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 |
skipping to change at page 7, line 34 skipping to change at page 7, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | | | Sender TTL | |
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Checksum Complement | | | Checksum Complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Checksum Complement in TWAMP Test Packets 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]. [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. The additional o In TWAMP the padding length is at least 29 octets. The additional
padding is required since the header of reflector test packets is padding is required since the header of reflector test packets is
27 octets longer than the header of sender test packets. Thus, the 27 octets longer than the header of sender test packets. Thus, the
padding in reflector test packets is 27 octets shorter than in padding in reflector test packets is 27 octets shorter than in
sender packet. Using 29 octets of padding in sender test packets sender packet. Using 29 octets of padding in sender test packets
allows both the sender and the reflector to use a 2-octet Checksum allows both the sender and the reflector to use a 2-octet Checksum
Complement. Complement.
Note: the 27-octet difference between the sender packet and the Note: the 27-octet difference between the sender packet and the
reflector packet is specifically in unauthenticated mode, whereas reflector packet is specifically in unauthenticated mode, whereas
in authenticated mode the difference between the sender and in authenticated mode the difference between the sender and
receiver packets is 56 octets. As specified in Section 3.4. , the receiver packets is 56 octets. As specified in Section 3.4. , the
Checksum Complement should only be used in unauthenticated mode. Checksum Complement should only be used in unauthenticated mode.
o Two optional TWAMP features are defined in [RFC6038]: octet o Two optional TWAMP features are defined in [RFC6038]: octet
reflection and symmetrical size. When at least one of these 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 includes the <Padding
Length> field, as well as a <Length of padding to reflect> field. Length> field, as well as a <Length of padding to reflect> field.
In this case both fields must be sufficiently long to allow at In this case both fields must be sufficiently long to allow at
least 2 octets of padding in both sender test packets and least 2 octets of padding in both sender test packets and
reflector test packets. reflector test packets.
Specifically, when octet reflection is enabled, the two length Specifically, when octet reflection is enabled, the two length
fields must be defined such that the padding expands at least 2 fields must be defined such that the padding expands at least 2
octets beyond the end of the reflected octets. octets beyond the end of the reflected octets.
skipping to change at page 9, line 8 skipping to change at page 9, line 8
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 in these packets, the
length of which MUST be sufficient to include the Checksum 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 padding field is negotiated during
session initiation, as described in Section 3.2. 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 test
packet MAY alter the Checksum Complement field in order to maintain packet can alter either the UDP Checksum field or the Checksum
the correctness of the UDP checksum value. Complement field in order to maintain the correctness of the 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 Packet Padding.
skipping to change at page 10, line 10 skipping to change at page 10, line 13
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 unauthenticated and in
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, the benefit of the packet, re-encrypt it, and then forward it. Thus, from an
Checksum Complement is effectively irrelevant in encrypted mode. 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 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 similar reasons as described above, a Checksum
Complement SHOULD NOT be used in this case. 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.
skipping to change at page 10, line 39 skipping to change at page 10, line 44
should be considered a malicious MITM attack. should be considered a malicious 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 who maliciously modifies a packet and its Checksum
Complement is logically equivalent to a MITM attacker who modifies a Complement is logically equivalent to a MITM attacker who modifies a
packet and its UDP Checksum field. 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 or in authenticated mode. As described in Section
3.4. , the benefits of the Checksum Complement do not apply when 3.4.2. , in encrypted mode using the Checksum Complement does not
encryption is enabled. simplify the implementation compared to using the conventional
Checksum, and therefore the Checksum Complement should not be used.
5. IANA Considerations 5. IANA Considerations
There are no IANA actions required by this document. There are no IANA actions required by this document.
RFC Editor: please delete this section before publication. RFC Editor: please delete this section before publication.
6. Acknowledgments 6. Acknowledgments
The authors gratefully acknowledge Al Morton, Greg Mirsky, and Steve The authors gratefully acknowledge Al Morton, Greg Mirsky, and Steve
skipping to change at page 11, line 49 skipping to change at page 11, line 51
7.2. Informative References 7.2. Informative References
[IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society,
"1588 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 Version 2", IEEE Standard, 2008. Control Systems Version 2", IEEE Standard, 2008.
[IPPMIPsec] Pentikousis, K., Zhang, E., Cui, Y., "IKEv2-based [IPPMIPsec] Pentikousis, K., Zhang, E., Cui, Y., "IKEv2-based
Shared Secret Key for O/TWAMP", draft-ietf-ippm-ipsec 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 Authors' Addresses
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. 20 change blocks. 
44 lines changed or deleted 54 lines changed or added

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