< draft-ietf-hip-esp-02.txt		draft-ietf-hip-esp-03.txt >
	Network Working Group P. Jokela		Network Working Group P. Jokela
	Internet-Draft Ericsson Research NomadicLab		Internet-Draft Ericsson Research NomadicLab
	Expires: September 3, 2006 R. Moskowitz		Expires: December 17, 2006 R. Moskowitz
	ICSAlabs, a Division of TruSecure		ICSAlabs, a Division of TruSecure
	Corporation		Corporation
	P. Nikander		P. Nikander
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	March 2, 2006		June 15, 2006
	Using ESP transport format with HIP		Using ESP transport format with HIP
	draft-ietf-hip-esp-02		draft-ietf-hip-esp-03
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 3, 2006.		This Internet-Draft will expire on December 17, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	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).
	skipping to change at page 10, line 10 ¶		skipping to change at page 10, line 10 ¶
	In addition to AES, all implementations MUST implement the ESP NULL		In addition to AES, all implementations MUST implement the ESP NULL
	encryption algorithm. When the ESP NULL encryption is used, it MUST		encryption algorithm. When the ESP NULL encryption is used, it MUST
	be used together with SHA1 or MD5 authentication as specified in		be used together with SHA1 or MD5 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. This means that each host MUST rekey before its sequence number		HIP. When ESP is used with HIP, a 64-bit sequence number MUST be
	reaches 2^32, or if extended sequence numbers are used, 2^64.		used. This means that each host MUST rekey before its sequence
			number reaches 2^64.
	In some instances, a 32-bit sequence number is inadequate. In the		When using a 64-bit sequence number, the higher 32 bits are NOT
	ESP_TRANSFORM parameter, a peer MAY require that a 64-bit sequence		included in the ESP header, but are simply kept local to both peers.
	numbers be used. In this case the higher 32 bits are NOT included in		See [9].
	the ESP header, but are simply kept local to both peers. The 64-bit
	sequence number is required in fast networks when there is a risk
	that the sequence number will rollover too often. See [9].
	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. The default timeout value is 15 minutes.
	Implementations MAY support lifetimes for the various ESP transforms.		Implementations MAY support lifetimes for the various ESP transforms.
	Each implementation SHOULD implement per-HIT configuration of the		Each implementation SHOULD implement per-HIT configuration of the
	skipping to change at page 14, line 42 ¶		skipping to change at page 14, line 42 ¶
	a new Diffie-Hellman key.		a new Diffie-Hellman key.
	Old SPI Old SPI for data sent to address(es) associated		Old SPI Old SPI for data sent to address(es) associated
	with this SA. If this is an initial SA setup, the		with this SA. If this is an initial SA setup, the
	Old SPI value is zero.		Old SPI value is zero.
	New SPI New SPI for data sent to address(es) associated		New SPI New SPI for data sent to address(es) associated
	with this SA.		with this SA.
	5.1.2. ESP_TRANSFORM		5.1.2. ESP_TRANSFORM
	The ESP_TRANSFORM parameter is used during ESP SA establishment. The		The ESP_TRANSFORM parameter is used during ESP SA establishment. The
	first party sends a selection of transfrom families in the		first party sends a selection of transform families in the
	ESP_TRANSFORM parameter and the peer must select one of the proposed		ESP_TRANSFORM parameter and the peer must select one of the proposed
	values and include it in the response ESP_TRANSFORM parameter.		values and include it in the response ESP_TRANSFORM parameter.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |E| Suite-ID #1 |		| Reserved | Suite-ID #1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Suite-ID #2 | Suite-ID #3 |		| Suite-ID #2 | Suite-ID #3 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Suite-ID #n | Padding |		| Suite-ID #n | Padding |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type 4095		Type 4095
	Length length in octets, excluding Type, Length, and		Length length in octets, excluding Type, Length, and
	padding		padding
	E One if the ESP transform requires 64-bit
	sequence numbers
	(see
	Section 3.3.6
	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 are defined ([6],[8]):		The following Suite-IDs are defined ([6],[8]):
	Suite-ID Value		Suite-ID Value
	RESERVED 0		RESERVED 0
	ESP-AES-CBC with HMAC-SHA1 1		ESP-AES-CBC with HMAC-SHA1 1
	ESP-3DES-CBC with HMAC-SHA1 2		ESP-3DES-CBC with HMAC-SHA1 2
	ESP-3DES-CBC with HMAC-MD5 3		ESP-3DES-CBC with HMAC-MD5 3
	ESP-BLOWFISH-CBC with HMAC-SHA1 4		ESP-BLOWFISH-CBC with HMAC-SHA1 4
	ESP-NULL with HMAC-SHA1 5		ESP-NULL with HMAC-SHA1 5
	ESP-NULL with HMAC-MD5 6		ESP-NULL with HMAC-MD5 6
	There MUST NOT be more than six (6) ESP Suite-IDs in one		The sender of an ESP transform parameter MUST make sure that there
	ESP_TRANSFORM parameter. The limited number of Suite-IDs sets the		are no more than six (6) Suite-IDs in one ESP transform parameter.
	maximum size of ESP_TRANSFORM parameter. The ESP_TRANSFORM MUST		Conversely, a recipient MUST be prepared to handle received transport
	contain at least one of the mandatory Suite-IDs.		parameters that contain more than six Suite-IDs. The limited number
			of Suite-IDs sets the maximum size of ESP_TRANSFORM parameter. As
			the default configuration, the ESP_TRANSFORM parameter MUST contain
			at least one of the mandatory Suite-IDs. There MAY be a
			configuration option that allows the administrator to override this
			default.
	Mandatory implementations: ESP-AES-CBC with HMAC-SHA1 and ESP-NULL		Mandatory implementations: ESP-AES-CBC with HMAC-SHA1 and ESP-NULL
	with HMAC-SHA1.		with HMAC-SHA1.
	5.1.3. NOTIFY Parameter		5.1.3. NOTIFY Parameter
	The HIP base specification defines a set of NOTIFY error types. The		The HIP base specification defines a set of NOTIFY error types. The
	following error types are required for describing errors in ESP		following error types are required for describing errors in ESP
	Transform crypto suites during negotiation.		Transform crypto suites during negotiation.
	skipping to change at page 30, line 21 ¶		skipping to change at page 30, line 21 ¶
	[2] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP		[2] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
	and AH", RFC 2404, November 1998.		and AH", RFC 2404, November 1998.
	[3] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher		[3] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
	Algorithm and Its Use with IPsec", RFC 3602, September 2003.		Algorithm and Its Use with IPsec", RFC 3602, September 2003.
	[4] Kent, S., "IP Encapsulating Security Payload (ESP)",		[4] Kent, S., "IP Encapsulating Security Payload (ESP)",
	draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005.		draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005.
	[5] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-04		[5] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-05
	(work in progress), October 2005.		(work in progress), March 2006.
	[6] Schiller, J., "Cryptographic Algorithms for use in the Internet		[6] Schiller, J., "Cryptographic Algorithms for use in the Internet
	Key Exchange Version 2", draft-ietf-ipsec-ikev2-algorithms-05		Key Exchange Version 2", draft-ietf-ipsec-ikev2-algorithms-05
	(work in progress), April 2004.		(work in progress), April 2004.
	[7] Moskowitz, R. and P. Nikander, "Host Identity Protocol		[7] Moskowitz, R. and P. Nikander, "Host Identity Protocol
	Architecture", draft-ietf-hip-arch-03 (work in progress),		Architecture", draft-ietf-hip-arch-03 (work in progress),
	August 2005.		August 2005.
	[8] Schneier, B., "Applied Cryptography Second Edition: protocols		[8] Schneier, B., "Applied Cryptography Second Edition: protocols
	skipping to change at page 30, line 45 ¶		skipping to change at page 30, line 45 ¶
	10.2. Informative references		10.2. Informative references
	[9] Kent, S. and K. Seo, "Security Architecture for the Internet		[9] Kent, S. and K. Seo, "Security Architecture for the Internet
	Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress),		Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress),
	April 2005.		April 2005.
	[10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",		[10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
	RFC 2409, November 1998.		RFC 2409, November 1998.
	[11] Melen, J. and P. Nikander, "A Bound End-to-End Tunnel (BEET)		[11] Melen, J. and P. Nikander, "A Bound End-to-End Tunnel (BEET)
	mode for ESP", draft-nikander-esp-beet-mode-04 (work in		mode for ESP", draft-nikander-esp-beet-mode-05 (work in
	progress), November 2005.		progress), February 2006.
	[12] Nikander, P., "End-Host Mobility and Multihoming with the Host		[12] Nikander, P., "End-Host Mobility and Multihoming with the Host
	Identity Protocol", draft-ietf-hip-mm-02 (work in progress),		Identity Protocol", draft-ietf-hip-mm-03 (work in progress),
	July 2005.		March 2006.
	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 is to rewrite		ways. As noted above, one possible way of implementing is to rewrite
	IP headers below IPsec. In such an implementation, IPsec is used as		IP headers below IPsec. In such an implementation, IPsec is used as
	if it was processing IPv6 transport mode packets, with the IPv6		if it was processing IPv6 transport mode packets, with the IPv6
	header containing HITs instead of IP addresses in the source and		header containing HITs instead of IP addresses in the source and
	destionation address fields. In outgoing packets, after IPsec		destionation 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
End of changes. 13 change blocks.
	29 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/