draft-ietf-ippm-checksum-trailer-00.txt		draft-ietf-ippm-checksum-trailer-01.txt
	Network Working Group T. Mizrahi		Network Working Group T. Mizrahi
	Internet Draft Marvell		Internet Draft Marvell
	Intended status: Informational		Intended status: Informational
	Expires: June 2015 December 17, 2014		Expires: September 2015 March 9, 2015
	UDP Checksum Trailer in OWAMP and TWAMP		UDP Checksum Complement in OWAMP and TWAMP
	draft-ietf-ippm-checksum-trailer-00.txt		draft-ietf-ippm-checksum-trailer-01.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,
	the UDP checksum field is then updated to reflect this modification.		the UDP checksum field is then updated to reflect this modification.
	This document proposes to use the last 2 octets of every test packet		This document proposes to use the last 2 octets of every test packet
	as a Checksum Trailer, allowing timestamping engines to reflect the		as a Checksum Complement, allowing timestamping engines to reflect
	checksum modification in the last 2 octets rather than in the UDP		the 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		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	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 June 17, 2015.		This Internet-Draft will expire on September 9, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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 Trailer 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 Trailer ........ 5		3.2. OWAMP / TWAMP Test Packets with Checksum Complement ..... 5
	3.2.1. Transmission of OWAMP/TWAMP with Checksum Trailer .. 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
	Trailer ................................................... 9		Complement ................................................ 9
	3.2.3. Reception of OWAMP/TWAMP with Checksum Trailer ..... 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 Trailer with or without Authentication 9		3.4. Using the Checksum Complement with or without Authentication
			............................................................ 9
			3.4.1. Checksum Complement in Authenticated Mode........... 9
			3.4.2. Checksum Complement in Encrypted Mode .............. 9
	4. Security Considerations ..................................... 10		4. Security Considerations ..................................... 10
	5. IANA Considerations ......................................... 10		5. IANA Considerations ......................................... 10
	6. Acknowledgments ............................................. 10		6. Acknowledgments ............................................. 11
	7. References .................................................. 10		7. References .................................................. 11
	7.1. Normative References ................................... 10		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
	skipping to change at page 4, line 24		skipping to change at page 4, line 28
	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
	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 2
	octets of the packet.		octets of the packet.
	The term Checksum Trailer is used throughout this document and refers		The term Checksum Complement is used throughout this document and
	to the 2 octets at the end of the UDP payload, used for updating the		refers to the 2 octets at the end of the UDP payload, used for
	UDP checksum by intermediate entities.		updating the UDP checksum by intermediate entities.
	The usage of the Checksum Trailer 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, since if the packet data is processed in a 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 Trailer rather than to update the timestamp and		update the Checksum Complement rather than to update the timestamp
	then update the UDP checksum, residing at the UDP header.		and then update the UDP checksum, residing at the UDP header.
	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
	OWAMP One-Way Active Measurement Protocol		HMAC Hashed Message Authentication Code
			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 Trailer in OWAMP and TWAMP		3. Using the UDP Checksum Complement in OWAMP and TWAMP
	3.1. Overview		3.1. Overview
	The UDP Checksum Trailer is a two-octet trailer that is piggybacked		The UDP Checksum Complement is a two-octet field that is piggybacked
	at the end of the test packet. It resides in the last 2 octets of the		at 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 Trailer (2 octets) |		| |UDP Checksum Complement (2 octets)|
	v +--------------------------------+		v +----------------------------------+
	Figure 2 Checksum Trailer in OWAMP/TWAMP Test Packet		Figure 2 Checksum Complement in OWAMP/TWAMP Test Packet
	3.2. OWAMP / TWAMP Test Packets with Checksum Trailer		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. The formats of these packets are defined in [OWAMP] and in		packets. A Checksum Complement MAY be used in the following cases:
	[TWAMP].
			o In OWAMP test packets, sent by the sender to the receiver.
			o In TWAMP test packets, sent by the sender to the reflector.
			o In TWAMP test packets, sent by the reflector to the sender.
	OWAMP/TWAMP test packets are transported over UDP, either over IPv4		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 Trailer. In this case the Checksum Trailer is		field as the Checksum Complement. In this case the Checksum
	always the last 2 octets of the UDP payload, and thus the trailer is		Complement is always the last 2 octets of the UDP payload, and thus
	located UDP Length - 2 octets after the beginning of the UDP header.		the field is located UDP Length - 2 octets after the beginning 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 trailer.		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 Trailer |		| | Checksum Complement |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3 Checksum Trailer 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 trailer.		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 | MBZ |		| Error Estimate | MBZ |
	skipping to change at page 7, line 32		skipping to change at page 7, line 32
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender Error Estimate | MBZ |		| Sender Error Estimate | MBZ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender TTL | |		| Sender TTL | |
	+-+-+-+-+-+-+-+-+ +		+-+-+-+-+-+-+-+-+ +
	| |		| |
	. .		. .
	. Packet Padding .		. Packet Padding .
	. .		. .
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Checksum Trailer |		| | Checksum Complement |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4 Checksum Trailer 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 Trailer is included, the <Padding Length> MUST be		When a Checksum Complement is included, the <Padding Length> MUST be
	sufficiently long to include the Checksum Trailer:		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 trailer in the last 2 octets of		sender to incorporate the Checksum Complement in the last 2 octets
	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
	trailer.		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 trailer 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.
	As described in Section 1. , the extensions described in this		As described in Section 1. , the extensions described in this
	document are implemented by two logical layers, a protocol layer and		document are implemented by two logical layers, a protocol layer and
	a timestamping layer. It is assumed that the two layers are		a timestamping layer. It is assumed that the two layers are
	synchronized about whether the usage of the Checksum Trailer is		synchronized about whether the usage of the Checksum Complement is
	enabled or not; since both logical layers reside in the same network		enabled or not; since both logical layers reside in the same network
	device, it is assumed there is no need for a protocol that		device, it is assumed there is no need for a protocol that
	synchronizes this information between the two layers. When Checksum		synchronizes this information between the two layers. When Checksum
	Trailer usage is enabled, the protocol layer must take care to verify		Complement usage is enabled, the protocol layer must take care to
	that test packets include the necessary padding, and avoiding the		verify that test packets include the necessary padding, and avoiding
	need for the timestamping layer to verify that en-route test packets		the need for the timestamping layer to verify that en-route test
	include the necessary padding.		packets include the necessary padding.
	3.2.1. Transmission of OWAMP/TWAMP with Checksum Trailer		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
	Trailer field, incorporated in the last 2 octets of the Packet		Complement field, incorporated in the last 2 octets of the Packet
	Padding.		Padding.
	A transmitter that includes a Checksum Trailer in its outgoing test		A transmitter that includes a Checksum Complement in its outgoing
	packets MUST include a Packet Padding in these packets, the length of		test packets MUST include a Packet Padding in these packets, the
	which MUST be sufficient to include the checksum trailer. The length		length of which MUST be sufficient to include the Checksum
	of the padding field is negotiated during session initiation, as		Complement. The length of the padding field is negotiated during
	described in Section 3.2.		session initiation, as described in Section 3.2.
	3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum Trailer		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 Trailer field in order to maintain the		packet MAY alter the Checksum Complement field in order to maintain
	correctness of the UDP checksum value.		the correctness of the UDP checksum value.
	3.2.3. Reception of OWAMP/TWAMP with Checksum Trailer		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 Trailer as part of the Packet Padding.		Checksum Complement as part of the Packet 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 an OWAMP receiver or a		requirements on the reception behavior of an OWAMP receiver or a
	TWAMP reflector, since the existence of the checksum trailer is		TWAMP reflector, since the existence of the Checksum Complement is
	transparent from the perspective of the receiver/reflector. Thus, the		transparent from the perspective of the receiver/reflector. Thus, the
	functionality described in this document allows interoperability with		functionality described in this document allows interoperability with
	existing implementations that comply to [OWAMP] or [TWAMP].		existing implementations that comply to [OWAMP] or [TWAMP].
	3.4. Using the Checksum Trailer with or without Authentication		3.4. Using the Checksum Complement with or without Authentication
	Both OWAMP and TWAMP may use authentication, as defined in [OWAMP] or		Both OWAMP and TWAMP may use authentication or encryption, as defined
	[TWAMP]. A Checksum Trailer SHOULD NOT be used when authentication is		in [OWAMP] and [TWAMP].
	enabled. The Checksum Trailer is effective in unauthenticated mode,
	allowing the intermediate entity to perform serial processing of the
	packet without storing-and-forwarding it.
	On the other hand, when message authentication is used, an		3.4.1. Checksum Complement in Authenticated Mode
	intermediate entity that alters test packets must also re-compute the
	Message Authentication Code (MAC) accordingly. The MAC update		OWAMP and TWAMP test packets can be authenticated using an HMAC
	typically requires the intermediate entity to store the packet, re-		(Hashed Message Authentication Code). The HMAC covers some of the
	compute its MAC, and then forward it. Thus, the benefit of the		fields in the test packet header. The HMAC does not cover the
	checksum trailer is effectively irrelevant when a MAC is used.		Timestamp field and 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 is effective in unauthenticated and in
			authenticated mode, allowing the intermediate entity to perform
			serial processing of the packet without storing-and-forwarding it.
			On the other hand, in encrypted mode an intermediate entity that
			timestamps a test packet must also re-encrypt the packet accordingly.
			Re-encryption typically requires the intermediate entity to store the
			packet, re-encrypt it, and then forward it. Thus, the benefit of the
			Checksum Complement is effectively irrelevant in encrypted mode.
	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
	Trailer 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 Trailer extension can be used		This document describes how a Checksum Complement extension can be
	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 described 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 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
	trailer 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 mode. As described in Section 3.4. , the benefits of		unauthenticated or in authenticated mode. As described in Section
	the Checksum Trailer do not apply when authentication is enabled.		3.4. , the benefits of the Checksum Complement do not apply when
			encryption is enabled.
	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
			Baillargeon for their helpful comments.
	This document was prepared using 2-Word-v2.0.template.dot.		This document was prepared using 2-Word-v2.0.template.dot.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[IPv6] Deering, S., Hinden, R., "Internet Protocol, Version 6		[IPv6] Deering, S., Hinden, R., "Internet Protocol, Version 6
	skipping to change at page 11, line 27		skipping to change at page 11, line 47
	Measurement Protocol (TWAMP) Reflect Octets and		Measurement Protocol (TWAMP) Reflect Octets and
	Symmetrical Size Features", RFC 6038, October 2010.		Symmetrical Size Features", RFC 6038, October 2010.
	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., Cui, Y., Zhang, E., "Network		[IPPMIPsec] Pentikousis, K., Zhang, E., Cui, Y., "IKEv2-based
	Performance Measurement for IPsec", draft-ietf-ippm-		Shared Secret Key for O/TWAMP", draft-ietf-ippm-ipsec
	ipsec (work in progress), September 2014.		(work in progress), February 2015.
	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. 51 change blocks.
	96 lines changed or deleted		127 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/