draft-ietf-ippm-ipsec-00.txt		draft-ietf-ippm-ipsec-01.txt
	IPPM WG K. Pentikousis, Ed.		IPPM WG K. Pentikousis, Ed.
	Internet-Draft Y. Cui		Internet-Draft EICT
	Intended status: Standards Track E. Zhang		Intended status: Standards Track Y. Cui
	Expires: January 06, 2014 Huawei Technologies		Expires: April 24, 2014 E. Zhang
	July 05, 2013		Huawei Technologies
			October 21, 2013
	Network Performance Measurement for IPsec		Network Performance Measurement for IPsec
	draft-ietf-ippm-ipsec-00		draft-ietf-ippm-ipsec-01
	Abstract		Abstract
	IPsec is a mature technology with several interoperable		IPsec is a mature technology with several interoperable
	implementations. Indeed, the use of IPsec tunnels is increasingly		implementations. Indeed, the use of IPsec tunnels is increasingly
	gaining popularity in several deployment scenarios, not the least in		gaining popularity in several deployment scenarios, not the least in
	what used to be solely areas of traditional telecommunication		what used to be solely areas of traditional telecommunication
	protocols. Wider deployment calls for mechanisms and methods that		protocols. Wider IPsec deployment calls for mechanisms and methods
	enable tunnel end-users, as well as operators, to measure one-way and		that enable tunnel end-users, as well as operators, to measure one-
	two-way network performance. Unfortunately, however, standard IP		way and two-way network performance in a standardized manner.
	performance measurement security mechanisms cannot be readily used		Unfortunately, however, standard IP performance measurement security
	with IPsec. This document makes the case for employing IPsec to		mechanisms cannot be readily used with IPsec. This document makes
	protect the One-way and Two-Way Active Measurement Protocols (O/		the case for employing IPsec to protect the One-way and Two-Way
	TWAMP) and proposes a method which combines IKEv2 and O/TWAMP as		Active Measurement Protocols (O/TWAMP) and proposes a method which
	defined in RFC 4656 and RFC 5357, respectively. This specification		combines IKEv2 and O/TWAMP as defined in RFC 4656 and RFC 5357,
	aims, on the one hand, to ensure that O/TWAMP can be secured with the		respectively. This specification aims, on the one hand, to ensure
	best mechanisms we have at our disposal today while, on the other		that O/TWAMP can be secured with the best mechanisms we have at our
	hand, it facilitates the applicability of O/TWAMP to networks that		disposal today while, on the other hand, it facilitates the
	have already deployed IPsec.		applicability of O/TWAMP to networks that have already deployed
			IPsec.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted 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). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on January 06, 2014.		This Internet-Draft will expire on April 24, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	skipping to change at page 2, line 24		skipping to change at page 2, line 27
	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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. O/TWAMP-Control Security . . . . . . . . . . . . . . . . 5		3.1. O/TWAMP-Control Security . . . . . . . . . . . . . . . . 5
	3.2. O/TWAMP-Test Security . . . . . . . . . . . . . . . . . . 6		3.2. O/TWAMP-Test Security . . . . . . . . . . . . . . . . . . 6
	3.3. O/TWAMP Security Root . . . . . . . . . . . . . . . . . . 6		3.3. O/TWAMP Security Root . . . . . . . . . . . . . . . . . . 7
	3.4. O/TWAMP and IPsec . . . . . . . . . . . . . . . . . . . . 7		3.4. O/TWAMP and IPsec . . . . . . . . . . . . . . . . . . . . 7
	4. O/TWAMP for IPsec Networks . . . . . . . . . . . . . . . . . 8		4. O/TWAMP for IPsec Networks . . . . . . . . . . . . . . . . . 8
	4.1. Shared Key Derivation . . . . . . . . . . . . . . . . . . 8		4.1. Shared Key Derivation . . . . . . . . . . . . . . . . . . 8
	4.2. Optimizations . . . . . . . . . . . . . . . . . . . . . . 10		4.2. Server Greeting Message Update . . . . . . . . . . . . . 9
	4.2.1. Alternative 1 . . . . . . . . . . . . . . . . . . . . 11		4.3. Session Key Derivation . . . . . . . . . . . . . . . . . 11
	4.2.2. Alternative 2 . . . . . . . . . . . . . . . . . . . . 13		4.3.1. Alternative 1 . . . . . . . . . . . . . . . . . . . . 12
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		4.3.2. Alternative 2 . . . . . . . . . . . . . . . . . . . . 14
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	8.1. Normative References . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.2. Informative References . . . . . . . . . . . . . . . . . 15		8.1. Normative References . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		8.2. Informative References . . . . . . . . . . . . . . . . . 16
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	The One-way Active Measurement Protocol (OWAMP) [RFC4656] and the		The One-way Active Measurement Protocol (OWAMP) [RFC4656] and the
	Two-Way Active Measurement Protocol (TWAMP) [RFC5357] can be used to		Two-Way Active Measurement Protocol (TWAMP) [RFC5357] can be used to
	measure network performance parameters, such as latency, bandwidth,		measure network performance parameters, such as latency, bandwidth,
	and packet loss by sending probe packets and monitoring their		and packet loss by sending probe packets and monitoring their
	experience in the network. In order to guarantee the accuracy of		experience in the network. In order to guarantee the accuracy of
	network measurement results, security aspects must be considered.		network measurement results, security aspects must be considered.
	Otherwise, attacks may occur and the authenticity of the measurement		Otherwise, attacks may occur and the authenticity of the measurement
	skipping to change at page 3, line 15		skipping to change at page 3, line 17
	Cryptographic security mechanisms, such as IPsec, have been		Cryptographic security mechanisms, such as IPsec, have been
	considered during the early stage of the specification of the two		considered during the early stage of the specification of the two
	active measurement protocols mentioned above. However, due to		active measurement protocols mentioned above. However, due to
	several reasons, it was decided to avoid tying the development and		several reasons, it was decided to avoid tying the development and
	deployment of O/TWAMP to such security mechanisms. In practice, for		deployment of O/TWAMP to such security mechanisms. In practice, for
	many networks, the issues listed in [RFC4656], Sec. 6.6 with respect		many networks, the issues listed in [RFC4656], Sec. 6.6 with respect
	to IPsec are still valid. However, we expect that in the near future		to IPsec are still valid. However, we expect that in the near future
	IPsec will be deployed in many more hosts and networks than today.		IPsec will be deployed in many more hosts and networks than today.
	For example, IPsec tunnels may be used to secure wireless channels.		For example, IPsec tunnels may be used to secure wireless channels.
	In this case, what we are interested in is measuring network		In this case, what we are interested in is measuring network
	performance specifically for the traffic carried by the tunnel, not		performance specifically for the traffic carried by the secured
	in general over the wireless channel. This document makes the case		tunnel, not over the wireless channel in general. This document
	that O/TWAMP should be cognizant when IPsec and other security		makes the case that O/TWAMP should be cognizant when IPsec and other
	mechanisms are in place and can be leveraged upon. In other words,		security mechanisms are in place and can be leveraged upon. In other
	it is now time to specify how O/TWAMP is used in a network		words, it is now time to specify how O/TWAMP is used in a network
	environment where IPsec is already deployed. We expect that in such		environment where IPsec is already deployed. We expect that in such
	an environment, measuring IP performance over IPsec tunnels with O/		an environment, measuring IP performance over IPsec tunnels with O/
	TWAMP is an important tool for operators.		TWAMP is an important tool for operators.
	For example, when considering the use of O/TWAMP in networks with		For example, when considering the use of O/TWAMP in networks with
	IPsec deployed, we can take advantage of the IPsec key exchange		IPsec deployed, we can take advantage of the IPsec key exchange
	protocol [RFC5996]. In particular, we note that it is not necessary		protocol [RFC5996]. In particular, we note that it is not necessary
	to use distinct keys in OWAMP-Control and OWAMP-Test layers. One key		to use distinct keys in OWAMP-Control and OWAMP-Test layers. One key
	for encryption and another for authentication is sufficient for both		for encryption and another for authentication is sufficient for both
	Control and Test layers. This obviates the need to generate two keys		Control and Test layers. This obviates the need to generate two keys
	skipping to change at page 3, line 42		skipping to change at page 3, line 44
	separate session keys in the OWAMP-Control and OWAMP-Test layers were		separate session keys in the OWAMP-Control and OWAMP-Test layers were
	designed for preventing reflection attacks when employing the current		designed for preventing reflection attacks when employing the current
	mechanism. Once IPsec is employed, such a potential threat is		mechanism. Once IPsec is employed, such a potential threat is
	alleviated.		alleviated.
	The remainder of this document is organized as follows. Section 3		The remainder of this document is organized as follows. Section 3
	motivates this work by revisiting the arguments made in [RFC4656]		motivates this work by revisiting the arguments made in [RFC4656]
	against the use of IPsec; this section also summarizes protocol		against the use of IPsec; this section also summarizes protocol
	operation with respect to security. Section 4 presents a method of		operation with respect to security. Section 4 presents a method of
	binding O/TWAMP and IKEv2 for network measurements between a sender		binding O/TWAMP and IKEv2 for network measurements between a sender
	and a receiver which both support IPsec. Finally, Section 3		and a receiver which both support IPsec. Finally, Section 5
	discusses the security considerations arising from the proposed		discusses the security considerations arising from the proposed
	mechanisms.		mechanisms.
	2. Terminology		2. 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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Motivation		3. Motivation
	In order to motivate the solutions proposed in this document, let us		In order to motivate the solutions proposed in this document, let us
	first revisit Section 6.6 of [RFC4656]. As we explain below, the		first revisit Section 6.6 of [RFC4656]. As we explain below, the
	reasons originally listed therein may not apply in many cases today.		reasons originally listed therein may not apply in many cases today.
	skipping to change at page 4, line 29		skipping to change at page 4, line 32
	the operational complexity of OWAMP (and TWAMP) in networks where		the operational complexity of OWAMP (and TWAMP) in networks where
	IPsec is actively used and may in practice limit its applicability.		IPsec is actively used and may in practice limit its applicability.
	The second argument made is the need to keep separate deployment		The second argument made is the need to keep separate deployment
	paths between OWAMP and IPsec. In several currently deployed types		paths between OWAMP and IPsec. In several currently deployed types
	of networks IPsec is widely used to protect the data and signaling		of networks IPsec is widely used to protect the data and signaling
	planes. For example, in mobile telecommunication networks, the		planes. For example, in mobile telecommunication networks, the
	deployment rate of IPsec exceeds 95% with respect to the LTE serving		deployment rate of IPsec exceeds 95% with respect to the LTE serving
	network. In older technology cellular networks, such as UMTS and		network. In older technology cellular networks, such as UMTS and
	GSM, IPsec use penetration is lower, but still quite significant.		GSM, IPsec use penetration is lower, but still quite significant.
	Additionally, there is a great number of IPSec-based VPN applications		Additionally, there is a great number of IPsec-based VPN applications
	which are widely used in business applications to provide end-to-end		which are widely used in business applications to provide end-to-end
	security over untrusted IEEE 802.11 wireless LANs. At the same time,		security over, for instance, publicly open or otherwise untrusted
	many IETF-standardized protocols make use of IPsec/IKE, including		IEEE 802.11 wireless LANs. At the same time, many IETF-standardized
	MIPv4/v6, HIP, SCTP, BGP, NAT and SIP, just to name a few.		protocols make use of IPsec/IKE, including MIPv4/v6, HIP, SCTP, BGP,
			NAT and SIP, just to name a few.
	The third argument in [RFC4656] is that, effectively, the adoption of		The third argument in [RFC4656] is that, effectively, the adoption of
	IPsec in OWAMP may be problematic for "lightweight embedded devices".		IPsec in OWAMP may be problematic for "lightweight embedded devices."
	However, since the publication of RFC 4656, a large number of		However, since the publication of RFC 4656, a large number of
	limited-resource and low-cost hardware, such as Ethernet switches,		limited-resource and low-cost hardware, such as Ethernet switches,
	DSL modems, and other such devices come with support for IPsec "out		DSL modems, set-top boxes and other such devices come with support
	of the box". Therefore concerns about implementation, although		for IPsec "out of the box". Therefore concerns about implementation,
	likely valid a decade ago, are not well founded today.		although likely valid a decade ago, are not well founded today.
	Finally, everyday use of IPsec applications by field technicians and		Finally, everyday use of IPsec applications by field technicians and
	good understanding of the IPsec API by many programmers should no		good understanding of the IPsec API by many programmers should no
	longer be a reason for concern. On the contrary: By now, IPsec open		longer be a reason for concern. On the contrary: By now, IPsec open
	source code is available for anyone who wants to use it. Therefore,		source code is available for anyone who wants to use it. Therefore,
	although IPsec does need a certain level of expertise to deal with		although IPsec does need a certain level of expertise to deal with
	it, in practice, most competent technical personnel and programmers		it, in practice, most competent technical personnel and programmers
	have no problems using it on a daily basis.		have no problems using it on a daily basis.
	OWAMP and TWAMP actually consist of two inter-related protocols: O/		OWAMP and TWAMP actually consist of two inter-related protocols: O/
	skipping to change at page 5, line 30		skipping to change at page 5, line 35
	o HMAC-SHA1 truncated to 128 bits for message authentication		o HMAC-SHA1 truncated to 128 bits for message authentication
	Three modes of operation are supported: unauthenticated,		Three modes of operation are supported: unauthenticated,
	authenticated, and encrypted. The authenticated and encrypted modes		authenticated, and encrypted. The authenticated and encrypted modes
	require that endpoints possess a shared secret, typically a		require that endpoints possess a shared secret, typically a
	passphrase. The secret key is derived from the passphrase using a		passphrase. The secret key is derived from the passphrase using a
	password-based key derivation function PBKDF2 (PKCS#5) [RFC2898].		password-based key derivation function PBKDF2 (PKCS#5) [RFC2898].
	In the unauthenticated mode, the security parameters are left unused.		In the unauthenticated mode, the security parameters are left unused.
	In the authenticated and encrypted modes, security parameters are		In the authenticated and encrypted modes, security parameters are
	negotiated during the control connection establishment. In short,		negotiated during the control connection establishment.
	the client opens a TCP connection to the server in order to be able
	to send OWAMP-Control commands. The server responds with a server		Figure 1 illustrates the initiation stage of the O/TWAMP-Control
	greeting, which contains the Challenge, Mode, Salt and Count. If the		protocol between a client and the server. In short, the client opens
	client-requested mode is available, the client responds with a Set-		a TCP connection to the server in order to be able to send OWAMP-
	Up-Response message, wherein the KeyID, Token and Client IV are		Control commands. The server responds with a Server Greeting, which
	included. The Token is the concatenation of a 16-octet challenge, a		contains the Modes, Challenge, Salt, Count, and MBZ fields (see
	16-octet AES Session-key used for encryption, and a 32-octet HMAC-		Section 3.1 of [RFC4656]). If the client-preferred mode is
	SHA1 Session-key used for authentication. The Token is encrypted		available, the client responds with a Set-Up-Response message,
	using AES-CBC.		wherein the selected Mode, as well as the KeyID, Token and Client IV
			are included. The Token is the concatenation of a 16-octet
			Challenge, a 16-octet AES Session-key used for encryption, and a
			32-octet HMAC-SHA1 Session-key used for authentication. The Token is
			encrypted using AES-CBC.
			+--------+ +--------+
			| Client | | Server |
			+--------+ +--------+
			| |
			|<---- TCP Connection ----->|
			| |
			|<---- Greeting message ----|
			| |
			|----- Set-Up-Response ---->|
			| |
			|<---- Server-Start --------|
			| |
			Figure 1: Initiation of O/TWAMP-Control
	Encryption uses a key derived from the shared secret associated with		Encryption uses a key derived from the shared secret associated with
	KeyID. In the authenticated and encrypted modes, all further		KeyID. In the authenticated and encrypted modes, all further
	communication is encrypted using the AES Session-key and		communication is encrypted using the AES Session-key and
	authenticated with the HMAC Session-key. The client encrypts		authenticated with the HMAC Session-key. The client encrypts
	everything it transmits through the just-established O/TWAMP-Control		everything it transmits through the just-established O/TWAMP-Control
	connection using stream encryption with Client-IV as the IV.		connection using stream encryption with Client-IV as the IV.
	Correspondingly, the server encrypts its side of the connection using		Correspondingly, the server encrypts its side of the connection using
	Server-IV as the IV. The IVs themselves are transmitted in		Server-IV as the IV. The IVs themselves are transmitted in
	cleartext. Encryption starts with the block immediately following		cleartext. Encryption starts with the block immediately following
	skipping to change at page 6, line 27		skipping to change at page 7, line 6
	session mode.		session mode.
	The O/TWAMP-Test packet format is the same in authenticated and		The O/TWAMP-Test packet format is the same in authenticated and
	encrypted modes. The encryption and authentication operations are,		encrypted modes. The encryption and authentication operations are,
	however, different. Similarly with the respective O/TWAMP-Control		however, different. Similarly with the respective O/TWAMP-Control
	session, each O/TWAMP-Test session has two keys: an AES Session-key		session, each O/TWAMP-Test session has two keys: an AES Session-key
	and an HMAC Session-key. However, there is a difference in how the		and an HMAC Session-key. However, there is a difference in how the
	keys are obtained:		keys are obtained:
	O/TWAMP-Control: the keys are generated by the client and		O/TWAMP-Control: the keys are generated by the client and
	communicated (as part of the Token) during connection		communicated to the server during the control connection
	establishment with the Set-Up-Response message.		establishment with the Set-Up-Response message (as part of
			the Token).
	O/TWAMP-Test: the keys are derived from the O/TWAMP-Control keys and		O/TWAMP-Test: the keys are derived from the O/TWAMP-Control keys and
	the session identifier (SID), which serve as inputs of the		the session identifier (SID), which serve as inputs of the
	key derivation function (KDF). The O/TWAMP-Test AES Session-		key derivation function (KDF). The O/TWAMP-Test AES Session-
	key is generated using the O/TWAMP-Control AES Session-key,		key is generated using the O/TWAMP-Control AES Session-key,
	with the 16-octet session identifier (SID), for encrypting		with the 16-octet session identifier (SID), for encrypting
	and decrypting the packets of the particular O/TWAMP-Test		and decrypting the packets of the particular O/TWAMP-Test
	session. The O/TWAMP-Test HMAC Session-key is generated		session. The O/TWAMP-Test HMAC Session-key is generated
	using the O/TWAMP-Control HMAC Session-key, with the 16-octet		using the O/TWAMP-Control HMAC Session-key, with the 16-octet
	session identifier (SID), for authenticating the packets of		session identifier (SID), for authenticating the packets of
	the particular O/TWAMP-Test session.		the particular O/TWAMP-Test session.
	3.3. O/TWAMP Security Root		3.3. O/TWAMP Security Root
	As discussed above, the AES Session-key and HMAC Session-key used in		As discussed above, the AES Session-key and HMAC Session-key used in
	the O/TWAMP-Test protocol are derived from the AES Session-key and		the O/TWAMP-Test protocol are derived from the AES Session-key and
	HMAC Session-key which are used in O/TWAMP-Control protocol. The AES		HMAC Session-key which are used in O/TWAMP-Control protocol. The AES
	Session-key and HMAC Session-key used in the O/TWAMP-Control protocol		Session-key and HMAC Session-key used in the O/TWAMP-Control protocol
	are generated randomly by the client, and encrypted with the shared		are generated randomly by the client, and encrypted with the shared
	secret associated with KeyID. Therefore, the security root is the		secret associated with KeyID. Therefore, the security root is the
	shared secret key. Thus, key provision and management may become		shared secret key. Thus, for large deployments, key provision and
	overly complicated. Comparatively, a certificate-based approach		management may become overly complicated. Comparatively, a
	using IKEv2/IPsec can automatically manage the security root and		certificate-based approach using IKEv2/IPsec can automatically manage
	solve this problem, as we explain in Section 4.		the security root and solve this problem, as we explain in Section 4.
	3.4. O/TWAMP and IPsec		3.4. O/TWAMP and IPsec
	According to RFC 4656 the "deployment paths of IPsec and OWAMP could		According to [RFC4656] the "deployment paths of IPsec and OWAMP could
	be separate if OWAMP does not depend on IPsec." However, the problem		be separate if OWAMP does not depend on IPsec." However, the problem
	that arises in practice is that the security mechanism of O/TWAMP and		that arises in practice is that the security mechanism of O/TWAMP and
	IPsec cannot coexist at the same time without adding overhead or		IPsec cannot coexist at the same time without adding overhead or
	increasing complexity.		increasing complexity.
	IPsec provides confidentiality and data integrity to IP datagrams.		IPsec provides confidentiality and data integrity to IP datagrams.
	Distinct protocols are provided: Authentication Header (AH),		Distinct protocols are provided: Authentication Header (AH),
	Encapsulating Security Payload (ESP) and Internet Key Exchange (IKE		Encapsulating Security Payload (ESP) and Internet Key Exchange (IKE
	v1/v2). AH provides only integrity protection, while ESP can also		v1/v2). AH provides only integrity protection, while ESP can also
	provide encryption. IKE is used for dynamical key negotiation and		provide encryption. IKE is used for dynamical key negotiation and
	skipping to change at page 7, line 51		skipping to change at page 8, line 32
	performance in an IPsec tunnel with O/TWAMP. Without this		performance in an IPsec tunnel with O/TWAMP. Without this
	functionality, the use of OWAMP and TWAMP over IPsec is hindered.		functionality, the use of OWAMP and TWAMP over IPsec is hindered.
	Of course, backward compatibility should be considered as well. That		Of course, backward compatibility should be considered as well. That
	is, the intrinsic security method based on shared key as specified in		is, the intrinsic security method based on shared key as specified in
	the O/TWAMP standards can also still be suitable for other network		the O/TWAMP standards can also still be suitable for other network
	settings. There should be no impact on the current security		settings. There should be no impact on the current security
	mechanisms defined in O/TWAMP for other use cases. This document		mechanisms defined in O/TWAMP for other use cases. This document
	describes possible solutions to this problem which take advantage of		describes possible solutions to this problem which take advantage of
	the secret key derived by IPsec, in order to provision the key needed		the secret key derived by IPsec, in order to provision the key needed
	for active network measurements based on RFC 4656 and RFC 5357.		for active network measurements based on [RFC4656] and [RFC5357].
	4. O/TWAMP for IPsec Networks		4. O/TWAMP for IPsec Networks
	This section presents a method of binding O/TWAMP and IKEv2 for		This section presents a method of binding O/TWAMP and IKEv2 for
	network measurements between a sender and a receiver which both		network measurements between a client and a server which both support
	support IPsec. In short, the shared key used for securing O/TWAMP		IPsec. In short, the shared key used for securing O/TWAMP traffic is
	traffic is derived using IKEv2 [RFC5996].		derived using IKEv2 [RFC5996].
	4.1. Shared Key Derivation		4.1. Shared Key Derivation
	If the AH protocol is used, the IP packets are transmitted in		If the AH protocol is used, the IP packets are transmitted in
	plaintext, but all O/TWAMP traffic is integrity-protected by IPsec.		plaintext, but all O/TWAMP traffic is integrity-protected by IPsec.
	Therefore, even if the peers choose to opt for the unauthenticated		Therefore, even if the peers choose to opt for the unauthenticated
	mode, IPsec integrity protection is extended to O/TWAMP.		mode, IPsec integrity protection is extended to O/TWAMP. In the
			authenticated and encrypted modes, the shared secret can be derived
	In the authenticated and encrypted modes, the shared secret can be		from the IKEv2 Security Association (SA), or IPsec SA.
	derived from the IKEv2 Security Association (SA), or IPsec SA. If
	the shared secret key is derived from the IKEv2 SA, SKEYSEED must be
	generated firstly.
	SKEYSEED and its derivatives are computed as per [RFC5996], where prf		If the shared secret key is derived from the IKEv2 SA, SKEYSEED must
	is a pseudorandom function:		be generated firstly. SKEYSEED and its derivatives are computed as
			per [RFC5996], where prf is a pseudorandom function:
	SKEYSEED = prf( Ni | Nr, g^ir )		SKEYSEED = prf( Ni | Nr, g^ir )
	Ni and Nr are nonces negotiated during the initial exchange. g^ir is		Ni and Nr are, respectively, the initiator and responder nonces,
	the shared secret from the ephemeral Diffie-Hellman exchange and is		which are negotiated during the initial exchange (see Section 1.2 of
	represented as a string of octets. Note that this SKEYSEED can be		[RFC5996]). g^ir is the shared secret from the ephemeral Diffie-
	used as the O/TWAMP shared secret key directly.		Hellman exchange and is represented as a string of octets. Note that
			this SKEYSEED can be used as the O/TWAMP shared secret key directly.
	Alternatively, the shared secret key can be generated as follows:		Alternatively, the shared secret key can be generated as follows:
	Shared secret key = PRF{ SKEYSEED, Session ID }		Shared secret key = PRF{ SKEYSEED, Session ID }
	wherein the Session ID is the O/TWAMP-Test SID.		wherein the Session ID is the O/TWAMP-Test SID.
	If the shared secret key is derived from the IPsec SA, the shared		If the shared secret key is derived from the IPsec SA, instead, the
	secret key can be equal to KEYMAT, wherein		shared secret key can be equal to KEYMAT, wherein
	KEYMAT = prf+( SK_d, Ni | Nr )		KEYMAT = prf+( SK_d, Ni | Nr )
	The term "prf+" stands for a function that outputs a pseudorandom		The term "prf+" stands for a function that outputs a pseudorandom
	stream based on the inputs to a prf, while SK_d is defined in		stream based on the inputs to a prf, while SK_d is defined in
	[RFC5996] (Sections 2.13 and 1.2, respectively). The shared secret		[RFC5996] (Sections 2.13 and 1.2, respectively). The shared secret
	key can alternatively be generated as follows:		key can alternatively be generated as follows:
	Shared secret key = PRF{ KEYMAT, Session ID }		Shared secret key = PRF{ KEYMAT, Session ID }
	wherein the session ID is is the O/TWAMP-Test SID.		wherein the session ID is is the O/TWAMP-Test SID.
	If rekeying for the IKE SA and IPsec SA occurs, the corresponding key		If rekeying for the IKE SA and IPsec SA occurs, the corresponding key
	of the SA is updated. Generally, ESP and AH SAs always exist in		of the SA is updated. Generally, ESP and AH SAs always exist in
	pairs, with one SA in each direction. If the SA is deleted, the key		pairs, with one SA in each direction. If the SA is deleted, the key
	generated from the IKE SA or IPsec SA should also be updated.		generated from the IKE SA or IPsec SA should also be updated.
			4.2. Server Greeting Message Update
	As discussed above, a binding association between the key generated		As discussed above, a binding association between the key generated
	from IPsec and the O/TWAMP shared secret key needs to be considered.		from IPsec and the O/TWAMP shared secret key needs to be considered.
	The Security Association can be identified by the Security Parameter		The Security Association (SA) can be identified by the Security
	Index (SPI) and protocol uniquely for a given sender and receiver		Parameter Index (SPI) and protocol uniquely for a given sender and
	pair. So these parameters should be agreed upon during the		receiver pair. Therefore, these parameters should be agreed upon
	initiation of O/TWAMP. At the stage that the sender and receiver		during the initiation stage of O/TWAMP-Control. At the stage that
	negotiate the integrity key, the IPsec protocol and SPI SHOULD be		the sender and receiver negotiate the integrity key, the IPsec
	checked. Only if the two parameters are matched with the IPsec		protocol and SPI MUST be checked. Only if the two parameters are
	information, should the O/TWAMP connection be established.		matched with the IPsec information, MUST the O/TWAMP connection be
			established.
	The SPI and protocol type are included in the Server Greeting of the
	O/TWAMP-Control protocol (Figure 1). After the client receives the
	greeting, it MUST close the connection if it receives a greeting with
	an erroneous SPI and protocol value (Figure 2). Otherwise, the
	client SHOULD respond with the following Set-Up-Response message and
	generates the shared secret key.
	+--------+ +--------+
	| Client | | Server |
	+--------+ +--------+
	| |
	|<---- TCP Connection ----->|
	| |
	|<---- Greeting message ----|
	| |
	|----- Set-Up-Response ---->|
	| |
	|<---- Server-Start --------|
	| |
	Figure 1: Initiation of O/TWAMP-Control		The Security Parameter Index (SPI) and protocol type (see [RFC4301]
			[RFC5996]) will need to be included in the Server Greeting of the O/
			TWAMP-Control protocol depicted in Figure 1. After the client
			receives the greeting, it MUST close the connection if it receives a
			greeting with an erroneous SPI and protocol value (Figure 2).
			Otherwise, the client SHOULD generate the shared secret key as
			discussed in Section 4.1 and respond with the server-expected Set-Up-
			Response message.
	When using ESP, all IP packets are encrypted, and therefore only the		The Modes field in Figure 2 will need to allow for support of key
	receiver can use the IPsec key to decrypt the IP active measurement		derivation as discussed in Section 4.1. As such, pending discussion
	packets. In this case, the IPsec tunnel between the sender and		in the IPPM WG, Modes value 8 MUST be supported by compatible
	receiver provides additional security: even if the peers choose the		implementations, indicating support for IPsec. Server
	unauthenticated mode, IPsec encryption and integrity protection is		implementations compatible with this document MUST set the first 28
	provided to O/TWAMP. If the sender and receiver decide to use the		bits of the Modes field to zero. A client compatible with this
	authenticated or encrypted mode, the shared secret can also be		specification MUST ignore the first 28 bits of the Modes field. For
	derived from IKE SA or IPsec SA. The method for key generation and		backward compatibility, the server is obviously allowed to indicate
	binding association is the same discussed above for the AH protocol		support for the Modes defined in [RFC4656]
	mode.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Protocol |		| Protocol |
	|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SPIi |		| SPIi |
	|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SPIr |		| SPIr |
	|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mode |		| Modes |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Challenge (16 octets) |		| Challenge (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Salt (16 octets) |		| Salt (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Count (4 octets) |		| Count (4 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| MBZ (12 octets) |		| MBZ (12 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Server Greeting format		Figure 2: Server Greeting format
			A compatible O/TWAMP client implementation would then interpret the
			originally unused 12 bits of the Server Greeting (see sec. 3.1 of
			[RFC4656]) as follows: The first 4 octets of the Server Greeting
			message indicate the protocol type, while the following 8 octets
			indicate the initiator (SPIi) and responder (SPIr) SPIs as
			illustrated in Figure 2. Note that in this case, the remaining
			fields of the Server Greeting message remain as per [RFC4656].
			EDITOR'S NOTE:
			We expect that this implementation option would pose the least
			backwards compatibility problems to existing O/TWAMP clients.
			Robust client implementations of [RFC4656] would disregard that
			the 29th Modes bit in the Server Greeting is set, and should
			ignore the information contained in the newly defined fields
			(Protocol, SPIi, SPIr). If the server supports other Modes, as
			one would assume, the client would then indicate any of the
			Modes defined in [RFC4656] and effectively indicate that it
			does not support the IPsec mode. At this point, the Server
			would need to use the Modes defined in [RFC4656] only.
			When using ESP, all IP packets are encrypted, and therefore only the
			receiver can use the IPsec key to decrypt the IP active measurement
			packets. In this case, the IPsec tunnel between the sender and
			receiver provides additional security: even if the peers choose the
			unauthenticated mode, IPsec encryption and integrity protection is
			provided to O/TWAMP. If the sender and receiver decide to use the
			authenticated or encrypted mode, the shared secret can also be
			derived from IKE SA or IPsec SA. The method for key generation and
			binding association is the same discussed above for the AH protocol
			mode.
	There is an encryption-only configuration in ESP, though this is not		There is an encryption-only configuration in ESP, though this is not
	recommended due to its limitations. Since it does not produce		recommended due to its limitations. Since it does not produce
	integrity key in this case, either encryption-only ESP should be		integrity key in this case, either encryption-only ESP should be
	prohibited for O/TWAMP, or a decryption failure should be		prohibited for O/TWAMP, or a decryption failure should be
	distinguished due to possible integrity attack.		distinguished due to possible integrity attack.
	4.2. Optimizations		4.3. Session Key Derivation
	The previous subsection described a method for deriving the shared		Section 4.1 described a method for deriving the shared key for O/
	key for O/TWAMP by capitalizing on IPsec. We note, however, that the		TWAMP by capitalizing on IPsec. This is a step forward in terms of
	O/TWAMP protocol uses distinct encryption and integrity keys for O/		facilitating O/TWAMP deployment at scale in IPsec networks as it
	TWAMP-Control and O/TWAMP-Test. Consequently, four keys are		allows for greater and secure automation of standardized network
	generated to protect O/TWAMP-Control and O/TWAMP-Test messages.		performance measurements. We note, however, that the O/TWAMP
			protocol uses distinct encryption and integrity keys for O/TWAMP-
			Control and O/TWAMP-Test. Consequently, four keys are generated to
			protect O/TWAMP-Control and O/TWAMP-Test messages.
	In fact, once IPsec is employed, one key for encryption and another		In fact, once IPsec is employed, one key for encryption and another
	for authentication is sufficient for both the Control and Test		for authentication is sufficient for both the Control and Test
	protocols. Therefore, in an IPsec environment we can reduce the		protocols. Therefore, in an IPsec environment we can further reduce
	operational complexity of O/TWAMP protocols in a straightforward		the operational complexity of O/TWAMP protocols in a straightforward
	manner, as discussed below.		manner, as discussed below.
	EDITOR'S NOTE:		EDITOR'S NOTE:
	We expect that both optimization alternatives will be discussed		We expect that both session key derivation proposals and
	in the IPPM working group and we are looking forward to		optimization alternatives will be discussed in the IPPM working
	community comments and feedback.		group and we are looking forward to community comments and
			feedback.
	4.2.1. Alternative 1		4.3.1. Alternative 1
	If an IPsec SA is established between the server and the client, or		If an IPsec SA is established between the server and the client, or
	both server and client support IPsec, the root key for O/TWAMP-based		both server and client support IPsec, the root key for O/TWAMP-based
	active network measurements can be derived from the IKE or IPsec SA.		active network measurements can be derived from the IKE or IPsec SA.
	If the root key that will be used in O/TWAMP network performance		If the root key that will be used in O/TWAMP network performance
	measurements is derived from the IKE SA, SKEYSEED must be generated		measurements is derived from the IKE SA, SKEYSEED must be generated
	first. SKEYSEED and its derivatives are computed as per [RFC5996].		first. SKEYSEED and its derivatives are computed as per [RFC5996].
	SKEYSEED can be used as the root key of O/TWAMP directly; then the		SKEYSEED can be used as the root key of O/TWAMP directly; then the
	root key of O/TWAMP is equal to SKEYSEED.		root key of O/TWAMP is equal to SKEYSEED. If the root key of O/TWAMP
			is derived from the IPsec SA, the shared secret key can be equal to
			KEYMAT. KEYMAT and its derivatives are computed as per usual
			[RFC5996].
	If the root key of O/TWAMP is derived from the IPsec SA, the shared		Then, the session keys for encryption and authentication can be
	secret key can be equal to KEYMAT. KEYMAT and its derivatives are		derived from the root key of O/TWAMP, wherein:
	computed as per usual [RFC5996]. Then, the session keys for
	encryption and authentication can be derived from the root key of O/
	TWAMP, wherein:
	Session key for enc = PRF{ root key of O/TWAMP, "O/TWAMP enc" }		Session key for enc = PRF{ root key of O/TWAMP, "O/TWAMP enc" }
	Session key for auth = PRF{ root key of O/TWAMP, "O/TWAMP auth" }		Session key for auth = PRF{ root key of O/TWAMP, "O/TWAMP auth" }
	The former can provide encryption protection for O/TWAMP-Control and		The former can provide encryption protection for O/TWAMP-Control and
	O/TWAMP-Test messages, while the latter can provide integrity		O/TWAMP-Test messages, while the latter can provide integrity
	protection.		protection.
	Note that there are cases where rekeying the IKE SA and IPsec SA is		Note that there are cases where rekeying the IKE SA and IPsec SA is
	necessary, and after which the corresponding key of SA is updated.		necessary, and after which the corresponding key of SA is updated.
	If the SA is deleted, the O/TWAMP shared key generated from the IKE		If the SA is deleted, the O/TWAMP shared key generated from the IKE
	SA or IPsec SA should also be updated.		SA or IPsec SA should also be updated.
			EDITOR'S NOTE:
			In addition to optimizing session key derivation, we can also
			reduce the verbosity of the Server Greeting and Set-Up-Response
			messages, as explained below. Note, however, that such O/TWAMP
			message simplification poses backward compatibility challenges,
			which should be discussed in the IPPM WG.
	In this optimization, the O/TWAMP-Control message exchange flow		In this optimization, the O/TWAMP-Control message exchange flow
	remains as per Figure 1. However, the optimized Server Greeting		remains as per Figure 1. However, the optimized Server Greeting
	(Figure 3) can do without the Salt and Count parameters (cf. Figure		(Figure 3) can do without the Salt and Count parameters (cf. Figure
	2) since the root key of O/TWAMP is derived from IKE SA or IPsec SA.		2) since the root key of O/TWAMP is derived from IKE SA or IPsec SA.
	O/TWAMP security can rely on IPsec and the SPI can uniquely identify		O/TWAMP security can rely on IPsec and the SPI can uniquely identify
	the IPsec SA from which the root key was derived from.		the IPsec SA from which the root key was derived from.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Protocol |		| Protocol |
	|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SPIi |		| SPIi |
	|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SPIr |		| SPIr |
	|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mode |		| Modes |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Challenge (16 octets) |		| Challenge (16 octets) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| MBZ (12 octets) |		| MBZ (12 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 13, line 8		skipping to change at page 14, line 20
	| |		| |
	| Client-IV (12 octets) |		| Client-IV (12 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Set-Up-Response in Alternative 1		Figure 4: Set-Up-Response in Alternative 1
	If the server authenticates the token successfully, then the O/TWAMP-		If the server authenticates the token successfully, then the O/TWAMP-
	Control message exchange flow can continue.		Control message exchange flow can continue.
	4.2.2. Alternative 2		4.3.2. Alternative 2
	Another way for optimizing the shared key use is to set the O/TWAMP		Another way for optimizing the shared key use is to set the O/TWAMP
	session keys equal to the keys of the IPsec SA directly, i.e:		session keys equal to the keys of the IPsec SA directly, i.e:
	Session key for enc = encryption key of the IPsec SA		Session key for enc = encryption key of the IPsec SA
	Session key for auth = integrity key of the IPsec SA		Session key for auth = integrity key of the IPsec SA
	The former session key can provide encryption protection for O/TWAMP-		The former session key can provide encryption protection for O/TWAMP-
	Control and O/TWAMP-Test messages, while the latter can provide		Control and O/TWAMP-Test messages, while the latter can provide
	integrity protection. The point made in the previous subsection		integrity protection. The point made in the previous subsection
	about rekeying the IPsec SA applies here too.		about rekeying the IPsec SA applies here too.
			EDITOR'S NOTE:
			As noted in the previous subsection, here too we can reduce the
			verbosity of the Server Greeting and Set-Up-Response messages
			even further, as explained below. Note, however, that such O/
			TWAMP message simplification poses backward compatibility
			challenges, which should be discussed in the IPPM WG.
			The O/TWAMP control message exchange flow remains the same (i.e. as
			per Figure 1), while the Server Greeting format is illustrated in
			Figure 5. The Challenge, Salt, and Count parameters can be
			eliminated since the session keys of O/TWAMP are equal to the keys of
			an IPsec SA directly. SPI can identify the IPsec SA where the
			session keys derived from. The similarly optimized Set-Up-Response
			message is illustrated in Figure 6.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Protocol |		| Protocol |
	|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SPIi |		| SPIi |
	|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SPIr |		| SPIr |
	|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mode |		| Modes |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| MBZ (12 octets) |		| MBZ (12 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: Optimized Server Greeting format		Figure 5: Optimized Server Greeting format
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mode |		| Mode |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Client-IV (12 octets) |		| Client-IV (12 octets) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: Set-Up-Response in Alternative 2		Figure 6: Set-Up-Response in Alternative 2
	The O/TWAMP control message exchange flow is the same (Figure 1),
	while the Server Greeting format is illustrated in Figure 5. The
	Salt, Count and Challenge parameters can be eliminated since the
	session keys of O/TWAMP are equal to keys of an IPsec SA directly.
	SPI can identify the IPsec SA where the session keys derived from.
	The Set-Up-Response is illustrated in Figure 6.
	5. Security Considerations		5. Security Considerations
	As the shared secret key is derived from IPsec, the key derivation		As the shared secret key is derived from IPsec, the key derivation
	algorithm strength and limitations are as per [RFC5996]. The		algorithm strength and limitations are as per [RFC5996]. The
	strength of a key derived from a Diffie-Hellman exchange using any of		strength of a key derived from a Diffie-Hellman exchange using any of
	the groups defined here depends on the inherent strength of the		the groups defined here depends on the inherent strength of the
	group, the size of the exponent used, and the entropy provided by the		group, the size of the exponent used, and the entropy provided by the
	random number generator employed. The strength of all keys and		random number generator employed. The strength of all keys and
	implementation vulnerabilities, particularly Denial of Service (DoS)		implementation vulnerabilities, particularly Denial of Service (DoS)
	attacks are as defined in [RFC5996].		attacks are as defined in [RFC5996].
	EDITOR'S NOTE:		EDITOR'S NOTE:
	The IPPM community may want to revisit the arguments listed in		As a general note, the IPPM community may want to revisit the
	[RFC4656], Sec. 6.6. Other widely-used Internet security		arguments listed in [RFC4656], Sec. 6.6. Other widely-used
	mechanisms, such as TLS and DTLS, may also be considered for		Internet security mechanisms, such as TLS and DTLS, may also be
	future use over and above of what is already specified in		considered for future use over and above of what is already
	[RFC4656] [RFC5357].		specified in [RFC4656] [RFC5357].
	6. IANA Considerations		6. IANA Considerations
			IANA may need to allocate additional values for the Modes options
	IANA may need to allocate additional values for the options presented		presented in this document. The values of the protocol field may
	in this document. The values of the protocol field needed to be		need to be assigned from the numbering space.
	assigned from the numbering space.
	7. Acknowledgments		7. Acknowledgments
	Emily Bi contributed to an earlier version of this document.		Emily Bi contributed to an earlier version of this document.
	We thank Eric Chen and Yakov Stein for their comments on this draft,		We thank Eric Chen and Yakov Stein for their comments on this draft,
	and Al Morton for the discussion on related earlier work in IPPM WG.		and Al Morton for the discussion on related earlier work in IPPM WG.
	8. References		8. References
	skipping to change at page 15, line 18		skipping to change at page 16, line 39
	[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
	"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC		"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
	5996, September 2010.		5996, September 2010.
	8.2. Informative References		8.2. Informative References
	[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography		[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
	Specification Version 2.0", RFC 2898, September 2000.		Specification Version 2.0", RFC 2898, September 2000.
			[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
			Internet Protocol", RFC 4301, December 2005.
	Authors' Addresses		Authors' Addresses
	Kostas Pentikousis (editor)		Kostas Pentikousis (editor)
	Huawei Technologies		EICT GmbH
	Carnotstrasse 4		Torgauer Strasse 12-15
	10587 Berlin		10829 Berlin
	Germany		Germany
	Email: k.pentikousis@huawei.com		Email: k.pentikousis@eict.de
	Yang Cui		Yang Cui
	Huawei Technologies		Huawei Technologies
	Huawei Building, Q20, No.156, Rd. BeiQing		Otemachi First Square 1-5-1 Otemachi
	Haidian District , Beijing 100095		Chiyoda-ku, Tokyo 100-0004
	P. R. China		Japan
	Email: cuiyang@huawei.com		Email: cuiyang@huawei.com
	Emma Zhang		Emma Zhang
	Huawei Technologies		Huawei Technologies
	Huawei Building, Q20, No.156, Rd. BeiQing		Huawei Building, Q20, No.156, Rd. BeiQing
	Haidian District , Beijing 100095		Haidian District , Beijing 100095
	P. R. China		P. R. China
	Email: emma.zhanglijia@huawei.com		Email: emma.zhanglijia@huawei.com
End of changes. 50 change blocks.
	164 lines changed or deleted		228 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/