draft-ietf-hip-rfc5202-bis-01.txt		draft-ietf-hip-rfc5202-bis-02.txt
	Network Working Group P. Jokela		Network Working Group P. Jokela
	Internet-Draft Ericsson Research NomadicLab		Internet-Draft Ericsson Research NomadicLab
	Intended status: Standards Track R. Moskowitz		Intended status: Standards Track R. Moskowitz
	Expires: March 31, 2013 ICSAlabs, An Independent		Expires: December 12, 2013 ICSAlabs, An Independent
	Division of Verizon Business		Division of Verizon Business
	Systems		Systems
	J. Melen		J. Melen
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	September 27, 2012		June 10, 2013
	Using the Encapsulating Security Payload (ESP) Transport Format with the		Using the Encapsulating Security Payload (ESP) Transport Format with the
	Host Identity Protocol (HIP)		Host Identity Protocol (HIP)
	draft-ietf-hip-rfc5202-bis-01		draft-ietf-hip-rfc5202-bis-02
	Abstract		Abstract
	This memo specifies an Encapsulated Security Payload (ESP) based		This memo specifies an Encapsulated Security Payload (ESP) based
	mechanism for transmission of user data packets, to be used with the		mechanism for transmission of user data packets, to be used with the
	Host Identity Protocol (HIP).		Host Identity Protocol (HIP).
	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
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 March 31, 2013.		This Internet-Draft will expire on December 12, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Conventions Used in This Document . . . . . . . . . . . . . . 4		2. Conventions Used in This Document . . . . . . . . . . . . . . 4
	3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 4		3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 5		3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 5
	3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 5		3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 5
	3.2.1. Semantics of the Security Parameter Index (SPI) . . . 6		3.2.1. Semantics of the Security Parameter Index (SPI) . . . 6
	3.3. Security Association Establishment and Maintenance . . . . 6		3.3. Security Association Establishment and Maintenance . . . . 7
	3.3.1. ESP Security Associations . . . . . . . . . . . . . . 6		3.3.1. ESP Security Associations . . . . . . . . . . . . . . 7
	3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 7		3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3.3. Security Association Management . . . . . . . . . . . 8		3.3.3. Security Association Management . . . . . . . . . . . 8
	3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 8		3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 8
	3.3.5. Supported Transforms . . . . . . . . . . . . . . . . . 8		3.3.5. Supported Ciphers . . . . . . . . . . . . . . . . . . 9
	3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 9		3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 9
	3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 9		3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 9
	3.4. IPsec and HIP ESP Implementation Considerations . . . . . 9		3.4. IPsec and HIP ESP Implementation Considerations . . . . . 9
	3.4.1. Data Packet Processing Considerations . . . . . . . . 10		3.4.1. Data Packet Processing Considerations . . . . . . . . 10
	3.4.2. HIP Signaling Packet Considerations . . . . . . . . . 10		3.4.2. HIP Signaling Packet Considerations . . . . . . . . . 10
	4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 11		4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1.1. Setting Up an ESP Security Association . . . . . . . . 11		4.1.1. Setting Up an ESP Security Association . . . . . . . . 11
	4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 12		4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 12
	5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 12		5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 13
	5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 12		5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 13
	5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 13		5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 13
	5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 15		5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 14
	5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 16		5.1.3. NOTIFICATION Parameter . . . . . . . . . . . . . . . . 16
	5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 16		5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 16
	5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 16		5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 16
	5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 18		5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 18
	5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18		5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18
	5.3.2. Responding to the Rekeying Initialization . . . . . . 19		5.3.2. Responding to the Rekeying Initialization . . . . . . 19
	5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 19		5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 19
	5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19		5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19
	6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 19		6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 19
	6.1. Processing Outgoing Application Data . . . . . . . . . . . 20		6.1. Processing Outgoing Application Data . . . . . . . . . . . 20
	6.2. Processing Incoming Application Data . . . . . . . . . . . 20		6.2. Processing Incoming Application Data . . . . . . . . . . . 20
	skipping to change at page 3, line 21		skipping to change at page 3, line 21
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 26		8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	11.1. Normative references . . . . . . . . . . . . . . . . . . . 28		11.1. Normative references . . . . . . . . . . . . . . . . . . . 28
	11.2. Informative references . . . . . . . . . . . . . . . . . . 28		11.2. Informative references . . . . . . . . . . . . . . . . . . 28
	Appendix A. A Note on Implementation Options . . . . . . . . . . 29		Appendix A. A Note on Implementation Options . . . . . . . . . . 29
	Appendix B. Bound End-to-End Tunnel mode for ESP . . . . . . . . 29		Appendix B. Bound End-to-End Tunnel mode for ESP . . . . . . . . 29
	B.1. Protocol definition . . . . . . . . . . . . . . . . . . . 30		B.1. Protocol definition . . . . . . . . . . . . . . . . . . . 30
	B.1.1. Changes to Security Association data structures . . . 30		B.1.1. Changes to Security Association data structures . . . 30
	B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 30		B.1.2. Packet format . . . . . . . . . . . . . . . . . . . . 31
	B.1.3. Cryptographic processing . . . . . . . . . . . . . . . 32		B.1.3. Cryptographic processing . . . . . . . . . . . . . . . 32
	B.1.4. IP header processing . . . . . . . . . . . . . . . . . 32		B.1.4. IP header processing . . . . . . . . . . . . . . . . . 33
	B.1.5. Handling of outgoing packets . . . . . . . . . . . . . 33		B.1.5. Handling of outgoing packets . . . . . . . . . . . . . 33
	B.1.6. Handling of incoming packets . . . . . . . . . . . . . 34		B.1.6. Handling of incoming packets . . . . . . . . . . . . . 34
	B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 35		B.1.7. IPv4 options handling . . . . . . . . . . . . . . . . 35
	1. Introduction		1. Introduction
	In the Host Identity Protocol Architecture		In the Host Identity Protocol Architecture
	[I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys.		[I-D.ietf-hip-rfc4423-bis], hosts are identified with public keys.
	The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] base exchange		The Host Identity Protocol [I-D.ietf-hip-rfc5201-bis] base exchange
	allows any two HIP-supporting hosts to authenticate each other and to		allows any two HIP-supporting hosts to authenticate each other and to
	skipping to change at page 4, line 40		skipping to change at page 4, line 40
	update an existing ESP Security Association.		update an existing ESP Security Association.
	It should be noted that representations of Host Identity are not		It should be noted that representations of Host Identity are not
	carried explicitly in the headers of user data packets. Instead, the		carried explicitly in the headers of user data packets. Instead, the
	ESP Security Parameter Index (SPI) is used to indicate the right host		ESP Security Parameter Index (SPI) is used to indicate the right host
	context. The SPIs are selected during the HIP ESP setup exchange.		context. The SPIs are selected during the HIP ESP setup exchange.
	For user data packets, ESP SPIs (in possible combination with IP		For user data packets, ESP SPIs (in possible combination with IP
	addresses) are used indirectly to identify the host context, thereby		addresses) are used indirectly to identify the host context, thereby
	avoiding any additional explicit protocol headers.		avoiding any additional explicit protocol headers.
			HIP and ESP traffic have known issues with middlebox traversal RFC
			5207 [RFC5207]. Other specifications exist for operating HIP and ESP
			over UDP (RFC 5770 [RFC5770] is an experimental specification, and
			others are being developed). Middlebox traversal is out of scope for
			this document.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Using ESP with HIP		3. Using ESP with HIP
	The HIP base exchange is used to set up a HIP association between two		The HIP base exchange is used to set up a HIP association between two
	hosts. The base exchange provides two-way host authentication and		hosts. The base exchange provides two-way host authentication and
	key material generation, but it does not provide any means for		key material generation, but it does not provide any means for
	protecting data communication between the hosts. In this document,		protecting data communication between the hosts. In this document,
	we specify the use of ESP for protecting user data traffic after the		we specify the use of ESP for protecting user data traffic after the
	HIP base exchange. Note that this use of ESP is intended only for		HIP base exchange. Note that this use of ESP is intended only for
	host-to-host traffic; security gateways are not supported.		host-to-host traffic; security gateways are not supported.
	To support ESP use, the HIP base exchange messages require some minor		To support ESP use, the HIP base exchange messages require some minor
	additions to the parameters transported. In the R1 packet, the		additions to the parameters transported. In the R1 packet, the
	Responder adds the possible ESP transforms in a npew ESP_TRANSFORM		Responder adds the possible ESP transforms in an ESP_TRANSFORM
	parameter before sending it to the Initiator. The Initiator gets the		parameter before sending it to the Initiator. The Initiator gets the
	proposed transforms, selects one of those proposed transforms, and		proposed transforms, selects one of those proposed transforms, and
	adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2		adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2
	packet, the Initiator also sends the SPI value that it wants to be		packet, the Initiator also sends the SPI value that it wants to be
	used for ESP traffic flowing from the Responder to the Initiator.		used for ESP traffic flowing from the Responder to the Initiator.
	This information is carried using the new ESP_INFO parameter. When		This information is carried using the ESP_INFO parameter. When
	finalizing the ESP SA setup, the Responder sends its SPI value to the		finalizing the ESP SA setup, the Responder sends its SPI value to the
	Initiator in the R2 packet, again using ESP_INFO.		Initiator in the R2 packet, again using ESP_INFO.
	3.1. ESP Packet Format		3.1. ESP Packet Format
	The ESP specification [RFC4303] defines the ESP packet format for		The ESP specification [RFC4303] defines the ESP packet format for
	IPsec. The HIP ESP packet looks exactly the same as the IPsec ESP		IPsec. The HIP ESP packet looks exactly the same as the IPsec ESP
	transport format packet. The semantics, however, are a bit different		transport format packet. The semantics, however, are a bit different
	and are described in more detail in the next subsection.		and are described in more detail in the next subsection.
	3.2. Conceptual ESP Packet Processing		3.2. Conceptual ESP Packet Processing
	ESP packet processing can be implemented in different ways in HIP.		ESP packet processing can be implemented in different ways in HIP.
	It is possible to implement it in a way that a standards compliant,		It is possible to implement it in a way that a standards compliant,
	unmodified IPsec implementation [RFC4303] can be used.		unmodified IPsec implementation [RFC4303] can be used in conjunction
			with some additional transport checksum processing above it, and if
			IP addresses are used as indexes to the right host context.
	When a standards compliant IPsec implementation that uses IP		When a standards compliant IPsec implementation that uses IP
	addresses in the SPD and Security Association Database (SAD) is used,		addresses in the SPD and Security Association Database (SAD) is used,
	the packet processing may take the following steps. For outgoing		the packet processing may take the following steps. For outgoing
	packets, assuming that the upper-layer pseudoheader has been built		packets, assuming that the upper-layer pseudoheader has been built
	using IP addresses, the implementation recalculates upper-layer		using IP addresses, the implementation recalculates upper-layer
	checksums using Host Identity Tags (HITs) and, after that, changes		checksums using Host Identity Tags (HITs) and, after that, changes
	the packet source and destination addresses back to corresponding IP		the packet source and destination addresses back to corresponding IP
	addresses. The packet is sent to the IPsec ESP for transport mode		addresses. The packet is sent to the IPsec ESP for transport mode
	handling and from there the encrypted packet is sent to the network.		handling and from there the encrypted packet is sent to the network.
	skipping to change at page 8, line 34		skipping to change at page 8, line 43
	An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote		An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote
	HITs since a system can have more than one HIT). An inactivity timer		HITs since a system can have more than one HIT). An inactivity timer
	is RECOMMENDED for all SAs. If the state dictates the deletion of an		is RECOMMENDED for all SAs. If the state dictates the deletion of an
	SA, a timer is set to allow for any late arriving packets.		SA, a timer is set to allow for any late arriving packets.
	3.3.4. Security Parameter Index (SPI)		3.3.4. Security Parameter Index (SPI)
	The SPIs in ESP provide a simple compression of the HIP data from all		The SPIs in ESP provide a simple compression of the HIP data from all
	packets after the HIP exchange. This does require a per HIT-pair		packets after the HIP exchange. This does require a per HIT-pair
	Security Association (and SPI), and a decrease of policy granularity		Security Association (and SPI), and a decrease of policy granularity
	over other Key Management Protocols like IKE.		over other Key Management Protocols like Internet Key Exchange (IKE)
			[RFC5996].
	When a host updates the ESP SA, it provides a new inbound SPI to and		When a host updates the ESP SA, it provides a new inbound SPI to and
	gets a new outbound SPI from its partner.		gets a new outbound SPI from its peer.
	3.3.5. Supported Transforms		3.3.5. Supported Ciphers
	All HIP implementations MUST support AES-128-CBC [RFC3602] and HMAC-		All HIP implementations MUST support AES-128-CBC and AES-256-CBC
	SHA1 [RFC2404]. If the Initiator does not support any of the		[RFC3602]. If the Initiator does not support any of the transforms
	transforms offered by the Responder, it should abandon the		offered by the Responder, it should abandon the negotiation and
	negotiation and inform the peer with a NOTIFY message about a non-		inform the peer with a NOTIFY message about a non-supported
	supported transform.		transform.
	In addition to AES-128-CBC, all implementations MUST implement the		In addition to AES-128-CBC, all implementations MUST implement the
	ESP NULL encryption algorithm. When the ESP NULL encryption is used,		ESP NULL encryption algorithm. When the ESP NULL encryption is used,
	it MUST be used together with SHA1 authentication as specified in		it MUST be used together with SHA-256 authentication as specified in
	Section 5.1.2		Section 5.1.2
	3.3.6. Sequence Number		3.3.6. Sequence Number
	The Sequence Number field is MANDATORY when ESP is used with HIP.		The Sequence Number field is MANDATORY when ESP is used with HIP.
	Anti-replay protection MUST be used in an ESP SA established with		Anti-replay protection MUST be used in an ESP SA established with
	HIP. When ESP is used with HIP, a 64-bit sequence number MUST be		HIP. When ESP is used with HIP, a 64-bit sequence number MUST be
	used. This means that each host MUST rekey before its sequence		used. This means that each host MUST rekey before its sequence
	number reaches 2^64.		number reaches 2^64.
	When using a 64-bit sequence number, the higher 32 bits are NOT		When using a 64-bit sequence number, the higher 32 bits are NOT
	included in the ESP header, but are simply kept local to both peers.		included in the ESP header, but are simply kept local to both peers.
	See [RFC4301].		See [RFC4301].
	3.3.7. Lifetimes and Timers		3.3.7. Lifetimes and Timers
	HIP does not negotiate any lifetimes. All ESP lifetimes are local		HIP does not negotiate any lifetimes. All ESP lifetimes are local
	policy. The only lifetimes a HIP implementation MUST support are		policy. The only lifetimes a HIP implementation MUST support are
	sequence number rollover (for replay protection), and SHOULD support		sequence number rollover (for replay protection), and SHOULD support
	timing out inactive ESP SAs. An SA times out if no packets are		timing out inactive ESP SAs. An SA times out if no packets are
	received using that SA. The default timeout value is 15 minutes.		received using that SA. Implementations SHOULD support a
	Implementations MAY support lifetimes for the various ESP transforms.		configurable SA timeout value. Implementations MAY support lifetimes
	Each implementation SHOULD implement per-HIT configuration of the		for the various ESP transforms. Each implementation SHOULD implement
	inactivity timeout, allowing statically configured HIP associations		per-HIT configuration of the inactivity timeout, allowing statically
	to stay alive for days, even when inactive.		configured HIP associations to stay alive for days, even when
			inactive.
	3.4. IPsec and HIP ESP Implementation Considerations		3.4. IPsec and HIP ESP Implementation Considerations
	When HIP is run on a node where a standards compliant IPsec is used,		When HIP is run on a node where a standards compliant IPsec is used,
	some issues have to be considered.		some issues have to be considered.
	The HIP implementation must be able to co-exist with other IPsec		The HIP implementation must be able to co-exist with other IPsec
	keying protocols. When the HIP implementation selects the SPI value,		keying protocols. When the HIP implementation selects the SPI value,
	it may lead to a collision if not implemented properly. To avoid the		it may lead to a collision if not implemented properly. To avoid the
	possibility for a collision, the HIP implementation MUST ensure that		possibility for a collision, the HIP implementation MUST ensure that
	skipping to change at page 12, line 51		skipping to change at page 13, line 14
	5. Parameter and Packet Formats		5. Parameter and Packet Formats
	In this section, new and modified HIP parameters are presented, as		In this section, new and modified HIP parameters are presented, as
	well as modified HIP packets.		well as modified HIP packets.
	5.1. New Parameters		5.1. New Parameters
	Two new HIP parameters are defined for setting up ESP transport		Two new HIP parameters are defined for setting up ESP transport
	format associations in HIP communication and for rekeying existing		format associations in HIP communication and for rekeying existing
	ones. Also, the NOTIFY parameter, described in		ones. Also, the NOTIFICATION parameter, described in
	[I-D.ietf-hip-rfc5201-bis], has two new error parameters.		[I-D.ietf-hip-rfc5201-bis], has two new error parameters.
	Parameter Type Length Data		Parameter Type Length Data
	ESP_INFO 65 12 Remote's old SPI,		ESP_INFO 65 12 Remote's old SPI,
	new SPI, and other info		new SPI, and other info
	ESP_TRANSFORM 4095 variable ESP Encryption and		ESP_TRANSFORM 4095 variable ESP Encryption and
	Authentication Transform(s)		Authentication Transform(s)
	5.1.1. ESP_INFO		5.1.1. ESP_INFO
	During the establishment and update of an ESP SA, the SPI value of		During the establishment and update of an ESP SA, the SPI value of
	both hosts must be transmitted between the hosts. During the		both hosts must be transmitted between the hosts. In addition, hosts
	establishment and update of an ESP SA, the SPI value of both hosts		need the index value to the KEYMAT when they are drawing keys from
	must be transmitted between the hosts. In addition, hosts need the		the generated keying material. The ESP_INFO parameter is used to
	index value to the KEYMAT when they are drawing keys from the
	generated keying material. The ESP_INFO parameter is used to
	transmit the SPI values and the KEYMAT index information between the		transmit the SPI values and the KEYMAT index information between the
	hosts.		hosts.
	During the initial ESP SA setup, the hosts send the SPI value that		During the initial ESP SA setup, the hosts send the SPI value that
	they want the peer to use when sending ESP data to them. The value		they want the peer to use when sending ESP data to them. The value
	is set in the NEW SPI field of the ESP_INFO parameter. In the		is set in the NEW SPI field of the ESP_INFO parameter. In the
	initial setup, an old value for the SPI does not exist, thus the OLD		initial setup, an old value for the SPI does not exist, thus the OLD
	SPI value field is set to zero. The OLD SPI field value may also be		SPI value field is set to zero. The OLD SPI field value may also be
	zero when additional SAs are set up between HIP hosts, e.g., in case		zero when additional SAs are set up between HIP hosts, e.g., in case
	of multihomed HIP hosts [RFC5206]. However, such use is beyond the		of multihomed HIP hosts [RFC5206]. However, such use is beyond the
	scope of this specification.		scope of this specification.
	RFC 4301 [RFC4301] describes how to establish multiple SAs to
	properly support QoS. If different classes of traffic (distinguished
	by Differentiated Services Code Point (DSCP) bits [RFC3474],
	[RFC3260]) are sent on the same SA, and if the receiver is employing
	the optional anti-replay feature available in ESP, this could result
	in inappropriate discarding of lower priority packets due to the
	windowing mechanism used by this feature. Therefore, a sender SHOULD
	put traffic of different classes but with the same selector values on
	different SAs to support Quality of Service (QoS) appropriately. To
	permit this, the implementation MUST permit establishment and
	maintenance of multiple SAs between a given sender and receiver with
	the same selectors. Distribution of traffic among these parallel SAs
	to support QoS is locally determined by the sender and is not
	negotiated by HIP. The receiver MUST process the packets from the
	different SAs without prejudice. It is possible that the DSCP value
	changes en route, but this should not cause problems with respect to
	IPsec processing since the value is not employed for SA selection and
	MUST NOT be checked as part of SA/packet validation.
	The KEYMAT index value points to the place in the KEYMAT from where		The KEYMAT index value points to the place in the KEYMAT from where
	the keying material for the ESP SAs is drawn. The KEYMAT index value		the keying material for the ESP SAs is drawn. The KEYMAT index value
	is zero only when the ESP_INFO is sent during a rekeying process and		is zero only when the ESP_INFO is sent during a rekeying process and
	new keying material is generated.		new keying material is generated.
	During the life of an SA established by HIP, one of the hosts may		During the life of an SA established by HIP, one of the hosts may
	need to reset the Sequence Number to one and rekey. The reason for		need to reset the Sequence Number to one and rekey. The reason for
	rekeying might be an approaching sequence number wrap in ESP, or a		rekeying might be an approaching sequence number wrap in ESP, or a
	local policy on use of a key. Rekeying ends the current SAs and		local policy on use of a key. Rekeying ends the current SAs and
	starts new ones on both peers.		starts new ones on both peers.
	skipping to change at page 15, line 36		skipping to change at page 15, line 29
	padding		padding
	Reserved zero when sent, ignored when received		Reserved zero when sent, ignored when received
	Suite ID defines the ESP Suite to be used		Suite ID defines the ESP Suite to be used
	The following Suite IDs can be used:		The following Suite IDs can be used:
	Suite ID Value		Suite ID Value
	RESERVED 0		RESERVED 0
	AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404]		AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404]
	3DES-CBC with HMAC-SHA1 2 [RFC2451], [RFC2404]		DEPRECATED 2
	DEPRECATED 3		DEPRECATED 3
	DEPRECATED 4		DEPRECATED 4
	NULL-ENCRYPT with HMAC-SHA1 5 [RFC2410], [RFC2404]		DEPRECATED 5
	DEPRECATED 6		DEPRECATED 6
	NULL-ENCRYPT with HMAC-SHA2 7 [RFC2410], [RFC4868]		NULL-ENCRYPT with HMAC-SHA-256 7 [RFC2410], [RFC4868]
	AES-128-CBC with HMAC-SHA2 8 [RFC3602], [RFC4868]		AES-128-CBC with HMAC-SHA-256 8 [RFC3602], [RFC4868]
	AES-256-CBC with HMAC-SHA2 9 [RFC3602], [RFC4868]		AES-256-CBC with HMAC-SHA-256 9 [RFC3602], [RFC4868]
	AES-CCM-8 10 [RFC4309]		AES-CCM-8 10 [RFC4309]
	AES-CCM-16 11 [RFC4309]		AES-CCM-16 11 [RFC4309]
	AES-GCM with a 8 octet ICV 12 [RFC4106]		AES-GCM with a 8 octet ICV 12 [RFC4106]
	AES-GCM with a 16 octet ICV 13 [RFC4106]		AES-GCM with a 16 octet ICV 13 [RFC4106]
	The sender of an ESP transform parameter MUST make sure that there		The sender of an ESP transform parameter MUST make sure that there
	are no more than six (6) Suite IDs in one ESP transform parameter.		are no more than six (6) Suite IDs in one ESP transform parameter.
	Conversely, a recipient MUST be prepared to handle received transform		Conversely, a recipient MUST be prepared to handle received transform
	parameters that contain more than six Suite IDs. The limited number		parameters that contain more than six Suite IDs. The limited number
	of Suite IDs sets the maximum size of the ESP_TRANSFORM parameter.		of Suite IDs sets the maximum size of the ESP_TRANSFORM parameter.
	As the default configuration, the ESP_TRANSFORM parameter MUST		As the default configuration, the ESP_TRANSFORM parameter MUST
	contain at least one of the mandatory Suite IDs. There MAY be a		contain at least one of the mandatory Suite IDs. There MAY be a
	configuration option that allows the administrator to override this		configuration option that allows the administrator to override this
	default.		default.
	Mandatory implementations: AES-CBC with HMAC-SHA1 and NULL with HMAC-		Mandatory implementations: AES-128-CBC with HMAC-SHA-256 and NULL
	SHA1.		with HMAC-SHA-256.
	Under some conditions, it is possible to use Traffic Flow		Under some conditions, it is possible to use Traffic Flow
	Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the		Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the
	definition of such operation is future work and must be done in a		definition of such operation is future work and must be done in a
	separate specification.		separate specification.
	5.1.3. NOTIFY Parameter		5.1.3. NOTIFICATION Parameter
	The HIP base specification defines a set of NOTIFY error types. The		The HIP base specification defines a set of NOTIFICATION error types.
	following error types are required for describing errors in ESP		The following error types are required for describing errors in ESP
	Transform crypto suites during negotiation.		Transform crypto suites during negotiation.
	NOTIFY PARAMETER - ERROR TYPES Value		NOTIFICATION PARAMETER - ERROR TYPES Value
	------------------------------ -----		------------------------------------ -----
	NO_ESP_PROPOSAL_CHOSEN 18		NO_ESP_PROPOSAL_CHOSEN 18
	None of the proposed ESP Transform crypto suites was		None of the proposed ESP Transform crypto suites was
	acceptable.		acceptable.
	INVALID_ESP_TRANSFORM_CHOSEN 19		INVALID_ESP_TRANSFORM_CHOSEN 19
	The ESP Transform crypto suite does not correspond to		The ESP Transform crypto suite does not correspond to
	one offered by the Responder.		one offered by the Responder.
	skipping to change at page 16, line 48		skipping to change at page 16, line 41
	The ESP Security Association is set up during the base exchange. The		The ESP Security Association is set up during the base exchange. The
	following subsections define the ESP SA setup procedure using both		following subsections define the ESP SA setup procedure using both
	base exchange messages (R1, I2, R2) and UPDATE messages.		base exchange messages (R1, I2, R2) and UPDATE messages.
	5.2.1. Setup During Base Exchange		5.2.1. Setup During Base Exchange
	5.2.1.1. Modifications in R1		5.2.1.1. Modifications in R1
	The ESP_TRANSFORM contains the ESP modes supported by the sender, in		The ESP_TRANSFORM contains the ESP modes supported by the sender, in
	the order of preference. All implementations MUST support AES-CBC		the order of preference. All implementations MUST support AES-128-
	[RFC3602] with HMAC-SHA1 [RFC2404].		CBC [RFC3602] with HMAC-SHA-256 [RFC4868].
	The following figure shows the resulting R1 packet layout.		The following figure shows the resulting R1 packet layout.
	The HIP parameters for the R1 packet:		The HIP parameters for the R1 packet:
	IP ( HIP ( [ R1_COUNTER, ]		IP ( HIP ( [ R1_COUNTER, ]
	PUZZLE,		PUZZLE,
	DIFFIE_HELLMAN,		DIFFIE_HELLMAN,
	HIP_TRANSFORM,		HIP_CIPHER,
	ESP_TRANSFORM,		ESP_TRANSFORM,
	HOST_ID,		HOST_ID,
	[ ECHO_REQUEST, ]		[ ECHO_REQUEST, ]
	HIP_SIGNATURE_2 )		HIP_SIGNATURE_2 )
	[, ECHO_REQUEST ])		[, ECHO_REQUEST ])
	5.2.1.2. Modifications in I2		5.2.1.2. Modifications in I2
	The ESP_INFO contains the sender's SPI for this association as well		The ESP_INFO contains the sender's SPI for this association as well
	as the KEYMAT index from where the ESP SA keys will be drawn. The		as the KEYMAT index from where the ESP SA keys will be drawn. The
	old SPI value is set to zero.		old SPI value is set to zero.
	The ESP_TRANSFORM contains the ESP mode selected by the sender of R1.		The ESP_TRANSFORM contains the ESP mode selected by the sender of R1.
	All implementations MUST support AES-CBC [RFC3602] with HMAC-SHA1		All implementations MUST support AES-128-CBC [RFC3602] with HMAC-SHA-
	[RFC2404].		256 [RFC4868].
	The following figure shows the resulting I2 packet layout.		The following figure shows the resulting I2 packet layout.
	The HIP parameters for the I2 packet:		The HIP parameters for the I2 packet:
	IP ( HIP ( ESP_INFO,		IP ( HIP ( ESP_INFO,
	[R1_COUNTER,]		[R1_COUNTER,]
	SOLUTION,		SOLUTION,
	DIFFIE_HELLMAN,		DIFFIE_HELLMAN,
	HIP_TRANSFORM,		HIP_CIPHER,
	ESP_TRANSFORM,		ESP_TRANSFORM,
	ENCRYPTED { HOST_ID },		ENCRYPTED { HOST_ID },
	[ ECHO_RESPONSE ,]		[ ECHO_RESPONSE ,]
	HMAC,		HMAC,
	HIP_SIGNATURE		HIP_SIGNATURE
	[, ECHO_RESPONSE] ) )		[, ECHO_RESPONSE] ) )
	5.2.1.3. Modifications in R2		5.2.1.3. Modifications in R2
	The R2 contains an ESP_INFO parameter, which has the SPI value of the		The R2 contains an ESP_INFO parameter, which has the SPI value of the
	skipping to change at page 19, line 48		skipping to change at page 19, line 47
	If a HIP implementation receives an ESP packet that has an		If a HIP implementation receives an ESP packet that has an
	unrecognized SPI number, it MAY respond (subject to rate limiting the		unrecognized SPI number, it MAY respond (subject to rate limiting the
	responses) with an ICMP packet with type "Parameter Problem", with		responses) with an ICMP packet with type "Parameter Problem", with
	the pointer pointing to the beginning of SPI field in the ESP header.		the pointer pointing to the beginning of SPI field in the ESP header.
	6. Packet Processing		6. Packet Processing
	Packet processing is mainly defined in the HIP base specification		Packet processing is mainly defined in the HIP base specification
	[I-D.ietf-hip-rfc5201-bis]. This section describes the changes and		[I-D.ietf-hip-rfc5201-bis]. This section describes the changes and
	new requirements for packet handling when the ESP transport format is		new requirements for packet handling when the ESP transport format is
	used. Note that all HIP packets (currently protocol 253) MUST bypass		used. Note that all HIP packets (currently protocol 139) MUST bypass
	ESP processing.		ESP processing.
	6.1. Processing Outgoing Application Data		6.1. Processing Outgoing Application Data
	Outgoing application data handling is specified in the HIP base		Outgoing application data handling is specified in the HIP base
	specification [I-D.ietf-hip-rfc5201-bis]. When the ESP transport		specification [I-D.ietf-hip-rfc5201-bis]. When the ESP transport
	format is used, and there is an active HIP session for the given <		format is used, and there is an active HIP session for the given <
	source, destination > HIT pair, the outgoing datagram is protected		source, destination > HIT pair, the outgoing datagram is protected
	using the ESP security association. The following additional steps		using the ESP security association. The following additional steps
	define the conceptual processing rules for outgoing ESP protected		define the conceptual processing rules for outgoing ESP protected
	skipping to change at page 28, line 12		skipping to change at page 28, line 12
	also valid for this document. Many people have given valuable		also valid for this document. Many people have given valuable
	feedback, and our apologies to anyone whose name is missing.		feedback, and our apologies to anyone whose name is missing.
	11. References		11. References
	11.1. Normative references		11.1. Normative references
	[I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and		[I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and
	T. Henderson, "Host Identity Protocol		T. Henderson, "Host Identity Protocol
	Version 2 (HIPv2)",		Version 2 (HIPv2)",
	draft-ietf-hip-rfc5201-bis-09 (work in		draft-ietf-hip-rfc5201-bis-11 (work in
	progress), July 2012.		progress), February 2013.
	[RFC2119] Bradner, S., "Key words for use in RFCs		[RFC2119] Bradner, S., "Key words for use in RFCs
	to Indicate Requirement Levels", BCP 14,		to Indicate Requirement Levels", BCP 14,
	RFC 2119, March 1997.		RFC 2119, March 1997.
	[RFC2404] Madson, C. and R. Glenn, "The Use of		[RFC2404] Madson, C. and R. Glenn, "The Use of
	HMAC-SHA-1-96 within ESP and AH",		HMAC-SHA-1-96 within ESP and AH",
	RFC 2404, November 1998.		RFC 2404, November 1998.
	[RFC3602] Frankel, S., Glenn, R., and S. Kelly,		[RFC3602] Frankel, S., Glenn, R., and S. Kelly,
	"The AES-CBC Cipher Algorithm and Its Use		"The AES-CBC Cipher Algorithm and Its Use
	with IPsec", RFC 3602, September 2003.		with IPsec", RFC 3602, September 2003.
	[RFC4303] Kent, S., "IP Encapsulating Security		[RFC4303] Kent, S., "IP Encapsulating Security
	Payload (ESP)", RFC 4303, December 2005.		Payload (ESP)", RFC 4303, December 2005.
			[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-
			SHA-256, HMAC-SHA-384, and HMAC-SHA-512
			with IPsec", RFC 4868, May 2007.
			[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P.
			Eronen, "Internet Key Exchange Protocol
			Version 2 (IKEv2)", RFC 5996,
			September 2010.
	11.2. Informative references		11.2. Informative references
	[I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol		[I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol
	Architecture",		Architecture",
	draft-ietf-hip-rfc4423-bis-04 (work in		draft-ietf-hip-rfc4423-bis-05 (work in
	progress), July 2012.		progress), September 2012.
	[RFC0791] Postel, J., "Internet Protocol", STD 5,		[RFC0791] Postel, J., "Internet Protocol", STD 5,
	RFC 791, September 1981.		RFC 791, September 1981.
	[RFC2401] Kent, S. and R. Atkinson, "Security		[RFC2401] Kent, S. and R. Atkinson, "Security
	Architecture for the Internet Protocol",		Architecture for the Internet Protocol",
	RFC 2401, November 1998.		RFC 2401, November 1998.
	[RFC3260] Grossman, D., "New Terminology and
	Clarifications for Diffserv", RFC 3260,
	April 2002.
	[RFC3474] Lin, Z. and D. Pendarakis, "Documentation
	of IANA assignments for Generalized
	MultiProtocol Label Switching (GMPLS)
	Resource Reservation Protocol - Traffic
	Engineering (RSVP-TE) Usage and
	Extensions for Automatically Switched
	Optical Network (ASON)", RFC 3474,
	March 2003.
	[RFC4301] Kent, S. and K. Seo, "Security		[RFC4301] Kent, S. and K. Seo, "Security
	Architecture for the Internet Protocol",		Architecture for the Internet Protocol",
	RFC 4301, December 2005.		RFC 4301, December 2005.
	[RFC4306] Kaufman, C., "Internet Key Exchange		[RFC4306] Kaufman, C., "Internet Key Exchange
	(IKEv2) Protocol", RFC 4306,		(IKEv2) Protocol", RFC 4306,
	December 2005.		December 2005.
	[RFC5206] Henderson, T., Ed., "End-Host Mobility		[RFC5206] Henderson, T., Ed., "End-Host Mobility
	and Multihoming with the Host Identity		and Multihoming with the Host Identity
	Protocol", RFC 5206, April 2008.		Protocol", RFC 5206, April 2008.
			[RFC5207] Stiemerling, M., Quittek, J., and L.
			Eggert, "NAT and Firewall Traversal
			Issues of Host Identity Protocol (HIP)
			Communication", RFC 5207, April 2008.
			[RFC5770] Komu, M., Henderson, T., Tschofenig, H.,
			Melen, J., and A. Keranen, "Basic Host
			Identity Protocol (HIP) Extensions for
			Traversal of Network Address
			Translators", RFC 5770, April 2010.
	Appendix A. A Note on Implementation Options		Appendix A. A Note on Implementation Options
	It is possible to implement this specification in multiple different		It is possible to implement this specification in multiple different
	ways. As noted above, one possible way of implementing this is to		ways. As noted above, one possible way of implementing this is to
	rewrite IP headers below IPsec. In such an implementation, IPsec is		rewrite IP headers below IPsec. In such an implementation, IPsec is
	used as if it was processing IPv6 transport mode packets, with the		used as if it was processing IPv6 transport mode packets, with the
	IPv6 header containing HITs instead of IP addresses in the source and		IPv6 header containing HITs instead of IP addresses in the source and
	destination address fields. In outgoing packets, after IPsec		destination address fields. In outgoing packets, after IPsec
	processing, the HITs are replaced with actual IP addresses, based on		processing, the HITs are replaced with actual IP addresses, based on
	the HITs and the SPI. In incoming packets, before IPsec processing,		the HITs and the SPI. In incoming packets, before IPsec processing,
End of changes. 42 change blocks.
	94 lines changed or deleted		89 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/