draft-ietf-ippm-ipsec-08.txt		draft-ietf-ippm-ipsec-09.txt
	IPPM WG K. Pentikousis, Ed.		IPPM WG K. Pentikousis, Ed.
	Internet-Draft EICT		Internet-Draft EICT
	Intended status: Standards Track E. Zhang		Intended status: Standards Track E. Zhang
	Expires: July 30, 2015 Y. Cui		Expires: August 15, 2015 Y. Cui
	Huawei Technologies		Huawei Technologies
	January 26, 2015		February 11, 2015
	IKEv2-based Shared Secret Key for O/TWAMP		IKEv2-based Shared Secret Key for O/TWAMP
	draft-ietf-ippm-ipsec-08		draft-ietf-ippm-ipsec-09
	Abstract		Abstract
	The O/TWAMP security mechanism requires that both the client and		The One-way Active Measurement Protocol (OWAMP) and Two-Way Active
	server endpoints possess a shared secret. Since the currently-		Measurement Protocol (TWAMP) security mechanism require that both the
	standardized O/TWAMP security mechanism only supports a pre-shared		client and server endpoints possess a shared secret. Since the
	key mode, large scale deployment of O/TWAMP is hindered		currently-standardized O/TWAMP security mechanism only supports a
	significantly. At the same time, recent trends point to wider IKEv2		pre-shared key mode, large scale deployment of O/TWAMP is hindered
	deployment which, in turn, calls for mechanisms and methods that		significantly. At the same time, recent trends point to wider
	enable tunnel end-users, as well as operators, to measure one-way and		Internet Key Exchange Protocol Version 2 (IKEv2) deployment which, in
	two- way network performance in a standardized manner. This document		turn, calls for mechanisms and methods that enable tunnel end-users,
	describes the use of keys derived from an IKEv2 SA as the shared key		as well as operators, to measure one-way and two- way network
	in O/TWAMP. If the shared key can be derived from the IKEv2 SA, O/		performance in a standardized manner. This document describes the
	TWAMP can support certificate-based key exchange, which would allow		use of keys derived from an IKEv2 security association (SA) as the
	for more operational flexibility and efficiency. The key derivation		shared key in O/TWAMP. If the shared key can be derived from the
	presented in this document can also facilitate automatic key		IKEv2 SA, O/TWAMP can support certificate-based key exchange, which
	management.		would allow for more operational flexibility and efficiency. The key
			derivation presented in this document can also facilitate automatic
			key management.
	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 July 30, 2015.		This Internet-Draft will expire on August 15, 2015.
	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
	skipping to change at page 2, line 26		skipping to change at page 2, line 26
	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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Scope and Applicability . . . . . . . . . . . . . . . . . . . 4		3. Scope and Applicability . . . . . . . . . . . . . . . . . . . 4
	4. O/TWAMP Security . . . . . . . . . . . . . . . . . . . . . . 4		4. O/TWAMP Security . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. O/TWAMP-Control Security . . . . . . . . . . . . . . . . 4		4.1. O/TWAMP-Control Security . . . . . . . . . . . . . . . . 5
	4.2. O/TWAMP-Test Security . . . . . . . . . . . . . . . . . . 6		4.2. O/TWAMP-Test Security . . . . . . . . . . . . . . . . . . 6
	4.3. O/TWAMP Security Root . . . . . . . . . . . . . . . . . . 7		4.3. O/TWAMP Security Root . . . . . . . . . . . . . . . . . . 7
	5. O/TWAMP for IPsec Networks . . . . . . . . . . . . . . . . . 7		5. O/TWAMP for IPsec Networks . . . . . . . . . . . . . . . . . 7
	5.1. Shared Key Derivation . . . . . . . . . . . . . . . . . . 7		5.1. Shared Key Derivation . . . . . . . . . . . . . . . . . . 7
	5.2. Server Greeting Message Update . . . . . . . . . . . . . 8		5.2. Server Greeting Message Update . . . . . . . . . . . . . 8
	5.3. Set-Up-Response Update . . . . . . . . . . . . . . . . . 9		5.3. Set-Up-Response Update . . . . . . . . . . . . . . . . . 10
	5.4. O/TWAMP over an IPsec tunnel . . . . . . . . . . . . . . 11		5.4. O/TWAMP over an IPsec tunnel . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 12		9.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	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,
	skipping to change at page 3, line 15		skipping to change at page 3, line 15
	altering the measurement results.		altering the measurement results.
	The currently-standardized O/TWAMP security mechanism [RFC4656]		The currently-standardized O/TWAMP security mechanism [RFC4656]
	[RFC5357] requires that endpoints (i.e. both the client and the		[RFC5357] requires that endpoints (i.e. both the client and the
	server) possess a shared secret. In today's network deployments,		server) possess a shared secret. In today's network deployments,
	however, the use of pre-shared keys is far from optimal. For		however, the use of pre-shared keys is far from optimal. For
	example, in wireless infrastructure networks, certain network		example, in wireless infrastructure networks, certain network
	elements, which can be seen as the two endpoints from an O/TWAMP		elements, which can be seen as the two endpoints from an O/TWAMP
	perspective, support certificate-based security. For instance,		perspective, support certificate-based security. For instance,
	consider the case in which one wants to measure IP performance		consider the case in which one wants to measure IP performance
	between an eNB and SeGW. Both eNB and SeGW are 3GPP/LTE nodes and		between a E-UTRAN Evolved Node B (eNB) and Security Gateway (SeGW).
	support certificate mode and IKEv2. Since the currently standardized		Both eNB and SeGW are 3GPP Long Term Evolution (LTE) nodes and
	O/TWAMP security mechanism only supports the pre-shared key mode,		support certificate mode and the Internet Key Exchange Protocol
	large scale deployment of O/TWAMP is hindered significantly.		Version 2 (IKEv2). Since the currently standardized O/TWAMP security
	Furthermore, deployment and management of "shared secrets" for		mechanism only supports pre-shared key mode, large scale deployment
	massive equipment installation consumes a tremendous amount of effort		of O/TWAMP is hindered significantly. Furthermore, deployment and
	and is prone to human error.		management of "shared secrets" for massive equipment installation
			consumes a tremendous amount of effort and is prone to human error.
	With IKEv2 widely used, employing keys derived from IKEv2 SA as		With IKEv2 widely used, employing keys derived from IKEv2 security
	shared key can be considered as a viable alternative. In mobile		association (SA) as shared key can be considered as a viable
	telecommunication networks, the deployment rate of IPsec exceeds 95%		alternative. In mobile telecommunication networks, the deployment
	with respect to the LTE serving network. In older-technology		rate of IPsec exceeds 95% with respect to the LTE serving network.
	cellular networks, such as UMTS and GSM, IPsec use penetration is		In older-technology cellular networks, such as UMTS and GSM, IPsec
	lower, but still quite significant. If the shared key can be derived		use penetration is lower, but still quite significant. If the shared
	from the IKEv2 SA, O/TWAMP can support cert-based key exchange and		key can be derived from the IKEv2 SA, O/TWAMP can support cert-based
	practically increase flexibility and efficiency. The use of IKEv2		key exchange and practically increase operational flexibility and
	also makes it easier to extend automatic key management. In general,		efficiency. The use of IKEv2 also makes it easier to extend
	O/TWAMP measurement packets can be transmitted inside the IPsec		automatic key management. In general, O/TWAMP measurement packets
	tunnel, as it occurs with typical user traffic, or transmitted		can be transmitted inside the IPsec tunnel, as it occurs with typical
	outside the IPsec tunnel. This may depend on the operator's policy		user traffic, or transmitted outside the IPsec tunnel. This may
	and is orthogonal to the mechanism described in this document.		depend on the operator's policy and is orthogonal to the mechanism
			described in this document.
	When IPsec is deployed, protecting O/TWAMP traffic in unauthenticated		When IPsec is deployed, protecting O/TWAMP traffic in unauthenticated
	mode using IPsec is one option. Another option is to protect O/TWAMP		mode using IPsec is one option. Another option is to protect O/TWAMP
	traffic using O/TWAMP layer security established using the PSK		traffic using O/TWAMP layer security established using the PSK
	derived from IKEv2 but bypassing the IPsec tunnel. Protecting		derived from IKEv2 but bypassing the IPsec tunnel. Protecting
	unauthenticated O/TWAMP control and/or test traffic via AH or ESP		unauthenticated O/TWAMP control and/or test traffic via
	cannot provide various security options, e.g. it cannot authenticate		Authentication Header (AH) [RFC4302] or Encapsulating Security
	part of a O/TWAMP packet as mentioned in [RFC4656]. For measuring		Payload (ESP) [RFC4303] cannot provide various security options,
	latency, the timestamp is carried in O/TWAMP traffic. The sender has		e.g. it cannot authenticate part of a O/TWAMP packet as mentioned in
	to fetch the timestamp, encrypt it, and send it. In this case, the		[RFC4656]. For measuring latency, timestamp is carried in O/TWAMP
	middle step can be skipped, potentially improving accuracy as the		traffic. The sender has to fetch the timestamp, encrypt it, and send
	sequence number can be encrypted and authenticated before the		it. In this case, the middle step can be skipped, potentially
	timestamp is fetched. It is the same case for the receiver since it		improving accuracy as the sequence number can be encrypted and
	can obtain the timestamp by skipping the decryption step. In such		authenticated before the timestamp is fetched. It is the same case
	cases, protecting O/TWAMP traffic using O/TWAMP layer security but		for the receiver since it can obtain the timestamp by skipping the
	bypassing the IPsec tunnel has its advantages.		decryption step. In such cases, protecting O/TWAMP traffic using O/
			TWAMP layer security but bypassing IPsec tunnel has its advantages.
	This document specifies a method for enabling network measurements		This document specifies a method for enabling network measurements
	between a TWAMP client and a TWAMP server which both support IPsec.		between a TWAMP client and a TWAMP server, as discussed in Section 3.
	In short, the shared key used for securing TWAMP traffic is derived		In short, the shared key used for securing TWAMP traffic is derived
	using IKEv2 [RFC7296]. This method SHOULD be used when O/TWAMP		using IKEv2 [RFC7296]. From an operations and management perspective
	traffic is bypassing IPsec protection and is running over an external		[RFC5706], the mechanism described in this document requires that
	network exactly between two IKEv2 systems.		both the TWAMP client and server support IPsec. This method SHOULD
			be used when O/TWAMP traffic is bypassing IPsec protection and is
			running over an external network exactly between two IKEv2 systems.
	After clarifying the terminology and scope in the subsequent		After clarifying the terminology and scope in the subsequent
	sections, the remainder of this document is organized as follows.		sections, the remainder of this document is organized as follows.
	Section 4 summarizes O/TWAMP protocol operation with respect to		Section 4 summarizes O/TWAMP protocol operation with respect to
	security. Section 5 presents the method for binding TWAMP and IKEv2		security. Section 5 presents the method for binding TWAMP and IKEv2
	for network measurements between the client and the server which both		for network measurements between the client and the server which both
	support IKEv2. Finally, Section 6 discusses the security		support IKEv2. Finally, Section 6 discusses the security
	considerations arising from the proposed mechanisms.		considerations arising from the proposed 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. Scope and Applicability		3. Scope and Applicability
	This document reserves from the TWAMP-Modes registry the Mode value		This document reserves from the TWAMP-Modes registry the Mode value
	IKEv2Derived which is equal to 128 (i.e. bit set in position 7) [NOTE		IKEv2Derived which is equal to 128 (i.e. bit set in position 7) and
	to IANA: remove before allocation and final publication] and MUST be		MUST be used by TWAMP implementations compatible with this
	used by TWAMP implementations compatible with this specification.		specification.
	Although the control procedures described in this document are		Although the control procedures described in this document are
	applicable to OWAMP per se, the lack of an established IANA registry		applicable to OWAMP per se, the lack of an established IANA registry
	for OWAMP Mode values technically prevents us from extending OWAMP		for OWAMP Mode values technically prevents us from extending OWAMP
	Mode values. Therefore, independent OWAMP implementations SHOULD be		Mode values. Therefore, independent OWAMP implementations SHOULD be
	checked for full compatibility with respect to the use of this Mode		checked for full compatibility with respect to the use of this Mode
	value. Until an IANA registry for OWAMP Mode values is established,		value. Until an IANA registry for OWAMP Mode values is established,
	the use this feature in OWAMP implementations MUST be arranged		the use this feature in OWAMP implementations MUST be arranged
	privately among consenting OWAMP users.		privately among consenting OWAMP users.
	skipping to change at page 5, line 28		skipping to change at page 5, line 35
	parameters are negotiated during the control connection		parameters are negotiated during the control connection
	establishment.		establishment.
	Figure 1 illustrates the initiation stage of the O/TWAMP-Control		Figure 1 illustrates the initiation stage of the O/TWAMP-Control
	protocol between a client and the server. In short, the client opens		protocol between a client and the server. In short, the client opens
	a TCP connection to the server in order to be able to send O/TWAMP-		a TCP connection to the server in order to be able to send O/TWAMP-
	Control commands. The server responds with a Server Greeting, which		Control commands. The server responds with a Server Greeting, which
	contains the Modes, Challenge, Salt, Count, and MBZ fields (see		contains the Modes, Challenge, Salt, Count, and MBZ fields (see
	Section 3.1 of [RFC4656]). If the client-preferred mode is		Section 3.1 of [RFC4656]). If the client-preferred mode is
	available, the client responds with a Set-Up- Response message,		available, the client responds with a Set-Up- Response message,
	wherein the selected Mode, as well as the KeyID, Token and Client IV		wherein the selected Mode, as well as the KeyID, Token and Client
	are included. The Token is the concatenation of a 16-octet		initialization vector (IV) are included. The Token is the
	Challenge, a 16-octet AES Session-key used for encryption, and a		concatenation of a 16-octet Challenge, a 16-octet AES Session-key
	32-octet HMAC-SHA1 Session-key used for authentication. The Token is		used for encryption, and a 32-octet HMAC-SHA1 Session-key used for
	encrypted using AES-CBC.		authentication. The Token is encrypted using AES-CBC.
	+--------+ +--------+		+--------+ +--------+
	| Client | | Server |		| Client | | Server |
	+--------+ +--------+		+--------+ +--------+
	| |		| |
	|<---- TCP Connection ----->|		|<---- TCP Connection ----->|
	| |		| |
	|<---- Greeting message ----|		|<---- Greeting message ----|
	| |		| |
	|----- Set-Up-Response ---->|		|----- Set-Up-Response ---->|
	skipping to change at page 9, line 11		skipping to change at page 9, line 39
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Server Greeting format		Figure 2: Server Greeting format
	The Modes field in Figure 2 will need to allow for support of key		The Modes field in Figure 2 will need to allow for support of key
	derivation as discussed in Section 5.1. As such, the Modes value		derivation as discussed in Section 5.1. As such, the Modes value
	extension MUST be supported by implementations compatible with this		extension MUST be supported by implementations compatible with this
	document, indicating support for deriving the shared key from the		document, indicating support for deriving the shared key from the
	IKEv2 SA. The new Modes value indicating support for this		IKEv2 SA. The new Modes value indicating support for this
	specification is IKEv2Derived and is equal to 128 (i.e. bit set in		specification is IKEv2Derived and is equal to 128 (i.e. bit set in
	position 7) [NOTE to IANA: remove before allocation and final		position 7). Clearly, an implementation compatible with this
	publication]. Clearly, an implementation compatible with this
	specification MUST support the authenticated, encrypted and mixed		specification MUST support the authenticated, encrypted and mixed
	modes as per [RFC4656][RFC5357][RFC5618].		modes as per [RFC4656][RFC5357][RFC5618].
	The choice of this set of Modes values poses no backwards		The choice of this set of Modes values poses no backwards
	compatibility problems to existing O/TWAMP clients. Robust legacy		compatibility problems to existing O/TWAMP clients. Robust legacy
	client implementations would disregard the fact that the IKEv2Derived		client implementations would disregard the fact that the IKEv2Derived
	Modes bit in the Server Greeting is set. On the other hand, a client		Modes bit in the Server Greeting is set. On the other hand, a client
	compatible with this specification can easily identify that the O/		compatible with this specification can easily identify that the O/
	TWAMP server contacted does not support this specification. If the		TWAMP server contacted does not support this specification. If the
	server supports other Modes, as one could assume, the client would		server supports other Modes, as one could assume, the client would
	skipping to change at page 9, line 36		skipping to change at page 10, line 15
	purely [RFC4656]/[RFC5357] compatible client.		purely [RFC4656]/[RFC5357] compatible client.
	5.3. Set-Up-Response Update		5.3. Set-Up-Response Update
	The Set-Up-Response Message should be updated as in Figure 3. When a		The Set-Up-Response Message should be updated as in Figure 3. When a
	O/TWAMP client compatible with this specification receives a Server		O/TWAMP client compatible with this specification receives a Server
	Greeting indicating support for Mode IKEv2Derived it SHOULD reply to		Greeting indicating support for Mode IKEv2Derived it SHOULD reply to
	the O/TWAMP server with a Set-Up response that indicates so. For		the O/TWAMP server with a Set-Up response that indicates so. For
	example, a compatible O/TWAMP client choosing the authenticated mode		example, a compatible O/TWAMP client choosing the authenticated mode
	with IKEv2 shared secret key derivation should set Mode to 130, i.e.		with IKEv2 shared secret key derivation should set Mode to 130, i.e.
	set the bits in positions 1 and 7 (TBD IANA) to one.		set the bits in positions 1 and 7 to one.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Key ID (80 octets) |		| Key ID (80 octets) |
	| |		| |
	| |		| |
	skipping to change at page 10, line 33		skipping to change at page 10, line 45
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Set-Up-Response Message		Figure 3: Set-Up-Response Message
	The Security Parameter Index (SPI)(see [RFC4301] [RFC7296]) can		The Security Parameter Index (SPI)(see [RFC4301] [RFC7296]) can
	uniquely identify the Security Association (SA). If the client		uniquely identify the Security Association (SA). If the client
	supports the derivation of shared secret key from IKEv2 SA, it will		supports the derivation of shared secret key from IKEv2 SA, it will
	choose the corresponding mode value and carry SPIi and SPIr in the		choose the corresponding mode value and carry SPIi and SPIr in the
	Key ID field. SPIi and SPIr MUST be included in the Key ID field of		Key ID field. SPIi and SPIr MUST be included in the Key ID field of
	Set-Up-Response Message to indicate the IKEv2 SA from which the O/		Set-Up-Response Message to indicate the IKEv2 SA from which the O/
	TWAMP shared secret key derived from. The length of SPI is 4 octets.		TWAMP shared secret key derived from. The length of SPI is 8 octets.
	Therefore, the first 4 octets of Key ID field MUST carry SPIi and the		Therefore, the first 8 octets of Key ID field MUST carry SPIi and the
	second 4 octets MUST carry SPIr. The remaining bits of the Key ID		second 8 octets MUST carry SPIr. The remaining bits of the Key ID
	field MUST set to zero.		field MUST set to zero.
	A O/TWAMP server which supports the specification of this document,		A O/TWAMP server which supports the specification of this document,
	MUST obtain the SPIi and SPIr from the first 8 octets and ignore the		MUST obtain the SPIi and SPIr from the first 16 octets and ignore the
	remaining octets of the Key ID field. Then, the client and the		remaining octets of the Key ID field. Then, the client and the
	server can derive the shared secret key based on the mode value and		server can derive the shared secret key based on the mode value and
	SPI. If the O/TWAMP server cannot find the IKEv2 SA corresponding to		SPI. If the O/TWAMP server cannot find the IKEv2 SA corresponding to
	the SPIi and SPIr received, it MUST log the event for operational		the SPIi and SPIr received, it MUST log the event for operational
	management purposes. In addition, the O/TWAMP server SHOULD set the		management purposes. In addition, the O/TWAMP server SHOULD set the
	Accept field of the Server-Start message to the value 6 to indicate		Accept field of the Server-Start message to the value 6 to indicate
	that server is not willing to conduct further transactions in this O/		that server is not willing to conduct further transactions in this O/
	TWAMP-Control session since it can not find the corresponding IKEv2		TWAMP-Control session since it can not find the corresponding IKEv2
	SA.		SA.
	5.4. O/TWAMP over an IPsec tunnel		5.4. O/TWAMP over an IPsec tunnel
	IPsec AH [RFC4302] and ESP [RFC4303] provide confidentiality and		IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security
	data integrity to IP datagrams. Thus an IPsec tunnel can be used to		Payload (ESP) [RFC4303] provide confidentiality and data integrity to
	provide the protection needed for O/TWAMP Control and Test packets,		IP datagrams. An IPsec tunnel can be used to provide the protection
	even if the peers choose the unauthenticated mode of operation. If		needed for O/TWAMP Control and Test packets, even if the peers choose
	the two endpoints are already connected through an IPSec tunnel it is		the unauthenticated mode of operation. In order to ensure
	RECOMMENDED that the O/TWAMP measurement packets are forwarded over		authenticity and security, the IPsec tunnel SHOULD be configured to
	the IPSec tunnel if the peers choose the unauthenticated mode in		include O/TWAMP measurement packets even when using the
	order to ensure authenticity and security.		unauthenticated mode.
	6. Security Considerations		6. Security Considerations
	As the shared secret key is derived from the IKEv2 SA, the key		As the shared secret key is derived from the IKEv2 SA, the key
	derivation algorithm strength and limitations are as per [RFC7296].		derivation algorithm strength and limitations are as per [RFC7296].
	The strength of a key derived from a Diffie-Hellman exchange using		The strength of a key derived from a Diffie-Hellman exchange using
	any of the groups defined here depends on the inherent strength of		any of 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		the 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 [RFC7296].		attacks are as defined in [RFC7296].
	As a more general note, the IPPM community may want to revisit the
	arguments listed in [RFC4656], Sec. 6.6. Other widely-used Internet
	security mechanisms, such as TLS and DTLS, may also be considered for
	future use over and above of what is already specified in [RFC4656]
	[RFC5357].
	7. IANA Considerations		7. IANA Considerations
	IANA is requested to allocate the IKEv2Derived Mode bit that is equal		IANA is requested to allocate the IKEv2Derived Mode bit that is equal
	to 128 (i.e. bit set in position 7) in the TWAMP-Modes registry. The		to 128 (i.e. bit set in position 7) in the TWAMP-Modes registry. The
	TWAMP-Modes registry should be augmented as follows:		TWAMP-Modes registry should be augmented as follows:
	Value Description Semantics Definition		Value Description Semantics Definition
	--------------------------------------------------------		--------------------------------------------------------
	128 IKEv2 Derived This memo, Section 5.2		128 IKEv2 Derived This memo, Section 5.2
	Mode Capability new bit position 7		Mode Capability new bit position 7
	Figure 4: IKEv2 Modes Capability		Figure 4: IKEv2 Modes Capability
	8. Acknowledgments		8. Acknowledgments
	We thank Eric Chen, Yaakov Stein, Brian Trammell, Emily Bi, John		We thank Eric Chen, Yaakov Stein, Brian Trammell, Emily Bi, John
	Mattsson, and Steve Baillargeon for their comments and text		Mattsson, Steve Baillargeon, Spencer Dawkins, Tero Kivinen, Fred
	suggestions. We also thank Spencer Dawkins for his AD evaluation of		Baker, Meral Shirazipour, and Hannes Tschofenig for their reviews,
	this document.		comments and text suggestions.
	Al Morton deserves a special mention for his thorough reviews and		Al Morton deserves a special mention for his thorough reviews and
	text contributions to this document as well as the constructive		text contributions to this document as well as the constructive
	discussions over several IPPM meetings.		discussions over several IPPM meetings.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 12, line 46		skipping to change at page 13, line 5
	(IKEv2)", STD 79, RFC 7296, October 2014.		(IKEv2)", STD 79, RFC 7296, October 2014.
	9.2. Informative References		9.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		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
			[RFC5706] Harrington, D., "Guidelines for Considering Operations and
			Management of New Protocols and Protocol Extensions", RFC
			5706, November 2009.
	[RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A		[RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A
	Childless Initiation of the Internet Key Exchange Version		Childless Initiation of the Internet Key Exchange Version
	2 (IKEv2) Security Association (SA)", RFC 6023, October		2 (IKEv2) Security Association (SA)", RFC 6023, October
	2010.		2010.
	Authors' Addresses		Authors' Addresses
	Kostas Pentikousis (editor)		Kostas Pentikousis (editor)
	EICT GmbH		EICT GmbH
	EUREF-Campus Haus 13		EUREF-Campus Haus 13
End of changes. 23 change blocks.
	88 lines changed or deleted		92 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/