rfc7402v3.txt		rfc7402.txt
	skipping to change at page 2, line 7		skipping to change at page 2, line 7
	(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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction ....................................................3
	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 ..............................................4
	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 .........6
	3.3.1. ESP Security Associations . . . . . . . . . . . . . . 6		3.3.1. ESP Security Associations ...........................6
	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 Ciphers . . . . . . . . . . . . . . . . . . 8		3.3.5. Supported Ciphers ...................................8
	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 . . . . . . . . 9		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 . . . . . . . . . . . . . . . . . . . . . . . . 10		4. The Protocol ...................................................11
	4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . 11		4.1. ESP in HIP ................................................11
	4.1.1. IPsec ESP Transport Format Type . . . . . . . . . . . 11		4.1.1. IPsec ESP Transport Format Type ....................11
	4.1.2. Setting Up an ESP Security Association . . . . . . . 11		4.1.2. Setting Up an ESP Security Association .............11
	4.1.3. Updating an Existing ESP SA . . . . . . . . . . . . . 12		4.1.3. Updating an Existing ESP SA ........................12
	5. Parameter and Packet Formats . . . . . . . . . . . . . . . . 12		5. Parameter and Packet Formats ...................................13
	5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . 13		5.1. New Parameters ............................................13
	5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . 13		5.1.1. ESP_INFO ...........................................13
	5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 14		5.1.2. ESP_TRANSFORM ......................................15
	5.1.3. NOTIFICATION Parameter . . . . . . . . . . . . . . . 16		5.1.3. NOTIFICATION Parameter .............................16
	5.2. HIP ESP Security Association Setup . . . . . . . . . . . 16		5.2. HIP ESP Security Association Setup ........................17
	5.2.1. Setup during Base Exchange . . . . . . . . . . . . . 16		5.2.1. Setup during Base Exchange .........................17
	5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . 18		5.3. HIP ESP Rekeying ..........................................18
	5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18		5.3.1. Initializing Rekeying ..............................19
	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 .............................................20
	5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19		5.4.1. Unknown SPI ........................................20
	6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 20		6. Packet Processing ..............................................20
	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 ......................21
	6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 21		6.3. HMAC and SIGNATURE Calculation and Verification ...........21
	6.4. Processing Incoming ESP SA Initialization (R1) . . . . . 21		6.4. Processing Incoming ESP SA Initialization (R1) ............22
	6.5. Processing Incoming Initialization Reply (I2) . . . . . . 22		6.5. Processing Incoming Initialization Reply (I2) .............22
	6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . 22		6.6. Processing Incoming ESP SA Setup Finalization (R2) ........23
	6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 22		6.7. Dropping HIP Associations .................................23
	6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . 22		6.8. Initiating ESP SA Rekeying ................................23
	6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . 24		6.9. Processing Incoming UPDATE Packets ........................24
	6.9.1. Processing UPDATE Packet: No Outstanding		6.9.1. Processing UPDATE Packet: No Outstanding
	Rekeying Request . . . . . . . . . . . . . . . . . . 24		Rekeying Request ...................................25
	6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 25		6.10. Finalizing Rekeying ......................................26
	6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 26		6.11. Processing NOTIFY Packets ................................26
	7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 26		7. Keying Material ................................................27
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 26		8. Security Considerations ........................................27
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		9. IANA Considerations ............................................28
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		10. References ....................................................29
	10.1. Normative References . . . . . . . . . . . . . . . . . . 28		10.1. Normative References .....................................29
	10.2. Informative References . . . . . . . . . . . . . . . . . 29		10.2. Informative References ...................................30
	Appendix A. A Note on Implementation Options ......................		Appendix A. A Note on Implementation Options ......................32
	Appendix B. Bound End-to-End Tunnel Mode for ESP ..................		Appendix B. Bound End-to-End Tunnel Mode for ESP ..................32
	B.1. Protocol Definition ........................................		B.1. Protocol Definition ........................................33
	B.1.1. Changes to Security Association Data Structures .....		B.1.1. Changes to Security Association Data Structures .....33
	B.1.2. Packet Format .......................................		B.1.2. Packet Format .......................................34
	B.1.3. Cryptographic Processing ............................		B.1.3. Cryptographic Processing ............................36
	B.1.4. IP Header Processing ................................		B.1.4. IP Header Processing ................................36
	B.1.5. Handling of Outgoing Packets ........................		B.1.5. Handling of Outgoing Packets ........................37
	B.1.6. Handling of Incoming Packets ........................		B.1.6. Handling of Incoming Packets ........................38
	B.1.7. Handling of IPv4 Options ............................		B.1.7. Handling of IPv4 Options ............................39
	Acknowledgments ...................................................		Acknowledgments ...................................................40
	Authors' Addresses ................................................		Authors' Addresses ................................................40
	1. Introduction		1. Introduction
	In the Host Identity Protocol Architecture [HIP-ARCH], hosts are		In the Host Identity Protocol Architecture [HIP-ARCH], hosts are
	identified with public keys. The Host Identity Protocol (HIP)		identified with public keys. The Host Identity Protocol (HIP)
	[RFC7401] base exchange allows any two HIP-supporting hosts to		[RFC7401] base exchange allows any two HIP-supporting hosts to
	authenticate each other and to create a HIP association between		authenticate each other and to create a HIP association between
	themselves. During the base exchange, the hosts generate a piece of		themselves. During the base exchange, the hosts generate a piece of
	shared keying material using an authenticated Diffie-Hellman		shared keying material using an authenticated Diffie-Hellman
	exchange.		exchange.
	skipping to change at page 5, line 24		skipping to change at page 5, line 24
	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 in conjunction		unmodified IPsec implementation [RFC4303] can be used in conjunction
	with some additional transport checksum processing above it, and if		with some additional transport checksum processing above it, and if
	IP addresses are used as indexes to the right host context.		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 Security Policy Database (SPD) and Security		addresses in the Security Policy Database (SPD) and Security
	Association Database (SAD) is used, the packet processing may take		Association Database (SAD) is used, the packet processing may take
	the following steps. For outgoing packets, assuming that the		the following steps. For outgoing packets, assuming that the
	upper-layer pseudoheader has been built using IP addresses, the		upper-layer pseudo header has been built using IP addresses, the
	implementation recalculates upper-layer checksums using Host Identity		implementation recalculates upper-layer checksums using Host Identity
	Tags (HITs) and, after that, changes the packet source and		Tags (HITs) and, after that, changes the packet source and
	destination addresses back to corresponding IP addresses. The packet		destination addresses back to corresponding IP addresses. The packet
	is sent to the IPsec ESP for transport mode handling, and from there		is sent to the IPsec ESP for transport mode handling, and from there
	the encrypted packet is sent to the network. When an ESP packet is		the encrypted packet is sent to the network. When an ESP packet is
	received, the packet is first put through the IPsec ESP transport		received, the packet is first put through the IPsec ESP transport
	mode handling, and after decryption, the source and destination IP		mode handling, and after decryption, the source and destination IP
	addresses are replaced with HITs, and finally, upper-layer checksums		addresses are replaced with HITs, and finally, upper-layer checksums
	are verified before passing the packet to the upper layer.		are verified before passing the packet to the upper layer.
	skipping to change at page 24, line 16		skipping to change at page 24, line 16
	SA update:		SA update:
	1. The system decides whether to continue to use the existing KEYMAT		1. The system decides whether to continue to use the existing KEYMAT
	or to generate a new KEYMAT. In the latter case, the system MUST		or to generate a new KEYMAT. In the latter case, the system MUST
	generate a new Diffie-Hellman public key.		generate a new Diffie-Hellman public key.
	2. The system creates an UPDATE packet, which contains the ESP_INFO		2. The system creates an UPDATE packet, which contains the ESP_INFO
	parameter. In addition, the host may include the optional		parameter. In addition, the host may include the optional
	DIFFIE_HELLMAN parameter. If the UPDATE contains the		DIFFIE_HELLMAN parameter. If the UPDATE contains the
	DIFFIE_HELLMAN parameter, the KEYMAT Index in the ESP_INFO		DIFFIE_HELLMAN parameter, the KEYMAT Index in the ESP_INFO
	parameter MUST be zero, and the Diffie-Hellman group ID must be		parameter MUST be zero, and the Diffie-Hellman Group ID must be
	unchanged from that used in the initial handshake. If the UPDATE		unchanged from that used in the initial handshake. If the UPDATE
	does not contain DIFFIE_HELLMAN, the ESP_INFO KEYMAT Index MUST		does not contain DIFFIE_HELLMAN, the ESP_INFO KEYMAT Index MUST
	be greater than or equal to the index of the next byte to be		be greater than or equal to the index of the next byte to be
	drawn from the current KEYMAT.		drawn from the current KEYMAT.
	3. The system sends the UPDATE packet. For reliability, the		3. The system sends the UPDATE packet. For reliability, the
	underlying UPDATE retransmission mechanism MUST be used.		underlying UPDATE retransmission mechanism MUST be used.
	4. The system MUST NOT delete its existing SAs, but continue using		4. The system MUST NOT delete its existing SAs, but continue using
	them if its policy still allows. The rekeying procedure SHOULD		them if its policy still allows. The rekeying procedure SHOULD
	skipping to change at page 25, line 28		skipping to change at page 25, line 28
	acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN)		acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN)
	parameters must be saved, and the packet processing continues as		parameters must be saved, and the packet processing continues as
	specified in Section 6.10.		specified in Section 6.10.
	6.9.1. Processing UPDATE Packet: No Outstanding Rekeying Request		6.9.1. Processing UPDATE Packet: No Outstanding Rekeying Request
	The following steps define the conceptual processing rules for		The following steps define the conceptual processing rules for
	handling a received UPDATE packet with the ESP_INFO parameter:		handling a received UPDATE packet with the ESP_INFO parameter:
	1. The system consults its policy to see if it needs to generate a		1. The system consults its policy to see if it needs to generate a
	new Diffie-Hellman key, and generates a new key (with same Group		new Diffie-Hellman key, and generates a new key (with same
	ID) if needed. The system records any newly generated or		Group ID) if needed. The system records any newly generated or
	received Diffie-Hellman keys for use in KEYMAT generation upon		received Diffie-Hellman keys for use in KEYMAT generation upon
	finalizing the ESP SA update.		finalizing the ESP SA update.
	2. If the system generated a new Diffie-Hellman key in the previous		2. If the system generated a new Diffie-Hellman key in the previous
	step, or if it received a DIFFIE_HELLMAN parameter, it sets the		step, or if it received a DIFFIE_HELLMAN parameter, it sets the
	ESP_INFO KEYMAT Index to zero. Otherwise, the ESP_INFO KEYMAT		ESP_INFO KEYMAT Index to zero. Otherwise, the ESP_INFO KEYMAT
	Index MUST be greater than or equal to the index of the next byte		Index MUST be greater than or equal to the index of the next byte
	to be drawn from the current KEYMAT. In this case, it is		to be drawn from the current KEYMAT. In this case, it is
	RECOMMENDED that the host use the KEYMAT Index requested by the		RECOMMENDED that the host use the KEYMAT Index requested by the
	peer in the received ESP_INFO.		peer in the received ESP_INFO.
	skipping to change at page 32, line 45		skipping to change at page 32, line 45
	over the separate implementation, as it binds the identities,		over the separate implementation, as it binds the identities,
	encryption, and locators tightly together. It should be noted that		encryption, and locators tightly together. It should be noted that
	implementing BEET mode doesn't require that corresponding hosts		implementing BEET mode doesn't require that corresponding hosts
	implement it, as the behavior is only visible internally in a host.		implement it, as the behavior is only visible internally in a host.
	BEET mode is a combination of IPsec tunnel and transport modes, and		BEET mode is a combination of IPsec tunnel and transport modes, and
	it provides some of the features from both. HIP uses HITs as the		it provides some of the features from both. HIP uses HITs as the
	"inner" addresses and IP addresses as "outer" addresses, like IP		"inner" addresses and IP addresses as "outer" addresses, like IP
	addresses are used in tunnel mode. Instead of tunneling packets		addresses are used in tunnel mode. Instead of tunneling packets
	between hosts, a conversion between inner and outer addresses is made		between hosts, a conversion between inner and outer addresses is made
	at end-hosts, and the inner address is never sent on the wire after		at end hosts, and the inner address is never sent on the wire after
	the initial HIP negotiation. BEET provides IPsec transport mode		the initial HIP negotiation. BEET provides IPsec transport mode
	syntax (no inner headers) with limited tunnel mode semantics (fixed		syntax (no inner headers) with limited tunnel mode semantics (fixed
	logical inner addresses -- the HITs -- and changeable outer IP		logical inner addresses -- the HITs -- and changeable outer IP
	addresses).		addresses).
	B.1. Protocol Definition		B.1. Protocol Definition
	In this section, we define the exact protocol formats and operations.		In this section, we define the exact protocol formats and operations.
	B.1.1. Changes to Security Association Data Structures		B.1.1. Changes to Security Association Data Structures
	skipping to change at page 39, line 8		skipping to change at page 39, line 8
	Instead of literally discarding the IP header and constructing a new		Instead of literally discarding the IP header and constructing a new
	one, a conforming implementation MAY simply replace the addresses in		one, a conforming implementation MAY simply replace the addresses in
	an existing header. However, if the RECOMMENDED feature of allowing		an existing header. However, if the RECOMMENDED feature of allowing
	the inner and outer addresses from different address families is		the inner and outer addresses from different address families is
	used, this simple strategy does not work.		used, this simple strategy does not work.
	B.1.7. Handling of IPv4 Options		B.1.7. Handling of IPv4 Options
	In BEET mode, if IPv4 options are transported inside the tunnel, the		In BEET mode, if IPv4 options are transported inside the tunnel, the
	sender MUST include a pseudo-header after the ESP header. The		sender MUST include a pseudo header after the ESP header. The
	pseudo-header indicates that IPv4 options from the original packet		pseudo header indicates that IPv4 options from the original packet
	are to be applied to the packet on the input side.		are to be applied to the packet on the input side.
	The sender MUST set the Next Header field in the ESP header to 94.		The sender MUST set the Next Header field in the ESP header to 94.
	The resulting pseudo header, including the IPv4 options, MUST be		The resulting pseudo header, including the IPv4 options, MUST be
	padded to an 8-octet boundary. The padding length is expressed in		padded to an 8-octet boundary. The padding length is expressed in
	octets; valid padding lengths are 0 or 4 octets, as the original IPv4		octets; valid padding lengths are 0 or 4 octets, as the original IPv4
	options are already padded to a 4-octet boundary. The padding MUST		options are already padded to a 4-octet boundary. The padding MUST
	be filled with No Operation (NOP) options as defined in Section 3.1		be filled with No Operation (NOP) options as defined in Section 3.1
	("Internet Header Format") of [RFC0791] ("Internet Protocol"). The		("Internet Header Format") of [RFC0791] ("Internet Protocol"). The
	padding is added in front of the original options to ensure that the		padding is added in front of the original options to ensure that the
	skipping to change at page 39, line 40		skipping to change at page 39, line 40
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| IPv4 options ... |		| IPv4 options ... |
	| |		| |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Next Header identifies the data following this header.		Next Header identifies the data following this header.
	Length in octets 8-bit unsigned integer. Length of the		Length in octets 8-bit unsigned integer. Length of the
	pseudo header in 8-octet units, not		pseudo header in 8-octet units, not
	including the first 8 octets.		including the first 8 octets.
	The receiver MUST remove this pseudo-header and padding as a part of		The receiver MUST remove this pseudo header and padding as a part of
	BEET processing, in order to reconstruct the original IPv4 datagram.		BEET processing, in order to reconstruct the original IPv4 datagram.
	The IPv4 options included in the pseudo-header MUST be added after		The IPv4 options included in the pseudo header MUST be added after
	the reconstructed IPv4 (inner) header on the receiving side.		the reconstructed IPv4 (inner) header on the receiving side.
	Acknowledgments		Acknowledgments
	This document was separated from the base Host Identity Protocol		This document was separated from the base Host Identity Protocol
	specification in the beginning of 2005. Since then, a number of		specification in the beginning of 2005. Since then, a number of
	people have contributed to the text by providing comments and		people have contributed to the text by providing comments and
	modification proposals. The list of people includes Tom Henderson,		modification proposals. The list of people includes Tom Henderson,
	Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu.		Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu.
	Especially, the authors want to thank Pekka Nikander for his		Especially, the authors want to thank Pekka Nikander for his
End of changes. 8 change blocks.
	75 lines changed or deleted		75 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/