< draft-ietf-hip-esp-05.txt		draft-ietf-hip-esp-06.txt >
	Network Working Group P. Jokela		Network Working Group P. Jokela
	Internet-Draft Ericsson Research NomadicLab		Internet-Draft Ericsson Research NomadicLab
	Expires: August 18, 2007 R. Moskowitz		Expires: December 13, 2007 R. Moskowitz
	ICSAlabs, a Division of TruSecure		ICSAlabs, a Division of TruSecure
	Corporation		Corporation
	P. Nikander		P. Nikander
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	February 14, 2007		June 11, 2007
	Using ESP transport format with HIP		Using ESP transport format with HIP
	draft-ietf-hip-esp-05		draft-ietf-hip-esp-06
	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 August 18, 2007.		This Internet-Draft will expire on December 13, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	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 15, line 12 ¶		skipping to change at page 15, line 12 ¶
	To permit this, the implementation MUST permit establishment and		To permit this, the implementation MUST permit establishment and
	maintenance of multiple SAs between a given sender and receiver, with		maintenance of multiple SAs between a given sender and receiver, with
	the same selectors. Distribution of traffic among these parallel SAs		the same selectors. Distribution of traffic among these parallel SAs
	to support QoS is locally determined by the sender and is not		to support QoS is locally determined by the sender and is not
	negotiated by HIP. The receiver MUST process the packets from the		negotiated by HIP. The receiver MUST process the packets from the
	different SAs without prejudice. It is possible that the DSCP value		different SAs without prejudice. It is possible that the DSCP value
	changes en route, but this should not cause problems with respect to		changes en route, but this should not cause problems with respect to
	IPsec processing since the value is not employed for SA selection and		IPsec processing since the value is not employed for SA selection and
	MUST NOT be checked as part of SA/packet validation.		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.
	During the rekeying process, the ESP_INFO parameter is used to		During the rekeying process, the ESP_INFO parameter is used to
	transmit the changed SPI values and the keying material index.		transmit the changed SPI values and the keying material index.
	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 | Keymat Index |		| Reserved | KEYMAT Index |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Old SPI |		| Old SPI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| New SPI |		| New SPI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type 65		Type 65
	Length 12		Length 12
	Keymat Index Index, in bytes, where to continue to draw ESP keys		KEYMAT Index Index, in bytes, where to continue to draw ESP keys
	from KEYMAT. If the packet includes a new		from KEYMAT. If the packet includes a new
	Diffie-Hellman key and the ESP_INFO is sent in an		Diffie-Hellman key and the ESP_INFO is sent in an
	UPDATE packet, the field MUST be zero. If the		UPDATE packet, the field MUST be zero. If the
	ESP_INFO is included in base exchange messages, the		ESP_INFO is included in base exchange messages, the
	Keymat Index must have the index value of the point		KEYMAT Index must have the index value of the point
	from where the ESP SA keys are drawn. Note that the		from where the ESP SA keys are drawn. Note that the
	length of this field limits the amount of		length of this field limits the amount of
	keying material that can be drawn from KEYMAT. If		keying material that can be drawn from KEYMAT. If
	that amount is exceeded, the packet MUST contain		that amount is exceeded, the packet MUST contain
	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.
	skipping to change at page 19, line 8 ¶		skipping to change at page 19, line 8 ¶
	HIP_TRANSFORM,		HIP_TRANSFORM,
	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-SHA-1-96		All implementations MUST support AES-CBC [RFC3602] with HMAC-SHA-1-96
	[RFC2404].		[RFC2404].
	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:
	skipping to change at page 19, line 35 ¶		skipping to change at page 19, line 35 ¶
	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
	sender of the R2 for this association. The ESP_INFO also has the		sender of the R2 for this association. The ESP_INFO also has the
	keymat index value specifying where the ESP SA keys are drawn.		KEYMAT index value specifying where the ESP SA keys are drawn.
	The following figure shows the resulting R2 packet layout.		The following figure shows the resulting R2 packet layout.
	The HIP parameters for the R2 packet:		The HIP parameters for the R2 packet:
	IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) )		IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) )
	5.3. HIP ESP Rekeying		5.3. HIP ESP Rekeying
	In this section, the procedure for rekeying an existing ESP SA is		In this section, the procedure for rekeying an existing ESP SA is
	presented.		presented.
	Conceptually, the process can be represented by the following message		Conceptually, the process can be represented by the following message
	sequence using the host names I' and R' defined in Section 3.3.2.		sequence using the host names I' and R' defined in Section 3.3.2.
	For simplicity, HMAC and HIP_SIGNATURE are not depicted, and		For simplicity, HMAC and HIP_SIGNATURE are not depicted, and
	DIFFIE_HELLMAN keys are optional. The UPDATE with ACK_I need not be		DIFFIE_HELLMAN keys are optional. The UPDATE with ACK_I need not be
	piggybacked with the UPDATE with SEQ_R; it may be acked separately		piggybacked with the UPDATE with SEQ_R; it may be ACKed separately
	(in which case the sequence would include four packets).		(in which case the sequence would include four packets).
	I' R'		I' R'
	UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN])		UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN])
	----------------------------------->		----------------------------------->
	UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN])		UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN])
	<-----------------------------------		<-----------------------------------
	UPDATE(ACK_R)		UPDATE(ACK_R)
	----------------------------------->		----------------------------------->
	skipping to change at page 24, line 19 ¶		skipping to change at page 24, line 19 ¶
	been accepted for processing (e.g., has not been dropped due to HIT		been accepted for processing (e.g., has not been dropped due to HIT
	comparisons as described in [I-D.ietf-hip-base]).		comparisons as described in [I-D.ietf-hip-base]).
	o The ESP_TRANSFORM parameter is verified and it MUST contain a		o The ESP_TRANSFORM parameter is verified and it MUST contain a
	single value in the parameter and it MUST match one of the values		single value in the parameter and it MUST match one of the values
	offered in the initialization packet.		offered in the initialization packet.
	o The ESP_INFO New SPI field is parsed to obtain the SPI that will		o The ESP_INFO New SPI field is parsed to obtain the SPI that will
	be used for the Security Association outbound from the Responder		be used for the Security Association outbound from the Responder
	and inbound to the Initiator. For this initial ESP SA		and inbound to the Initiator. For this initial ESP SA
	establishment, the Old SPI value MUST be zero. The Keymat Index		establishment, the Old SPI value MUST be zero. The KEYMAT Index
	field MUST contain the index value to the KEYMAT from where the		field MUST contain the index value to the KEYMAT from where the
	ESP SA keys are drawn.		ESP SA keys are drawn.
	o The system prepares and creates both incoming and outgoing ESP		o The system prepares and creates both incoming and outgoing ESP
	security associations.		security associations.
	o Upon successful processing of the initialization reply message,		o Upon successful processing of the initialization reply message,
	the possible old Security Associations (as left over from an		the possible old Security Associations (as left over from an
	earlier incarnation of the HIP association) are dropped and the		earlier incarnation of the HIP association) are dropped and the
	new ones are installed, and a finalizing packet, R2, is sent.		new ones are installed, and a finalizing packet, R2, is sent.
	skipping to change at page 25, line 34 ¶		skipping to change at page 25, line 34 ¶
	The following steps define the processing rules for initiating an ESP		The following steps define the processing rules for initiating an ESP
	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 new KEYMAT. In the latter case, the system MUST		or to generate 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 UDPATE 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 or equal to the index of the next byte to be drawn		be greater or equal to the index of the next byte to be drawn
	from the current KEYMAT.		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
	be initiated early enough to make sure that the SA replay		be initiated early enough to make sure that the SA replay
	counters do not overflow.		counters do not overflow.
	5. In case a protocol error occurs and the peer system acknowledges		5. In case a protocol error occurs and the peer system acknowledges
	the UPDATE but does not itself send an ESP_INFO, the system may		the UPDATE but does not itself send an ESP_INFO, the system may
	not finalize the outstanding ESP SA update request. To guard		not finalize the outstanding ESP SA update request. To guard
	against this, a system MAY re-initiate the ESP SA update		against this, a system MAY re-initiate the ESP SA update
	procedure after some time waiting for the peer to respond, or it		procedure after some time waiting for the peer to respond, or it
	MAY decide to abort the ESP SA after waiting for an		MAY decide to abort the ESP SA after waiting for an
	implementation-dependent time. The system MUST NOT keep an		implementation-dependent time. The system MUST NOT keep an
	oustanding ESP SA update request for an indefinite time.		outstanding ESP SA update request for an indefinite time.
	To simplify the state machine, a host MUST NOT generate new UPDATEs		To simplify the state machine, a host MUST NOT generate new UPDATEs
	while it has an outstanding ESP SA update request, unless it is		while it has an outstanding ESP SA update request, unless it is
	restarting the update process.		restarting the update process.
	6.9. Processing Incoming UPDATE Packets		6.9. Processing Incoming UPDATE Packets
	When a system receives an UPDATE packet, it must be processed if the		When a system receives an UPDATE packet, it must be processed if the
	following conditions hold (in addition to the generic conditions		following conditions hold (in addition to the generic conditions
	specified for UPDATE processing in Section 6.12 of		specified for UPDATE processing in Section 6.12 of
	skipping to change at page 26, line 31 ¶		skipping to change at page 26, line 31 ¶
	1. A corresponding HIP association must exist. This is usually		1. A corresponding HIP association must exist. This is usually
	ensured by the underlying UPDATE mechanism.		ensured by the underlying UPDATE mechanism.
	2. The state of the HIP association is ESTABLISHED or R2-SENT.		2. The state of the HIP association is ESTABLISHED or R2-SENT.
	If the above conditions hold, the following steps define the		If the above conditions hold, the following steps define the
	conceptual processing rules for handling the received UPDATE packet:		conceptual processing rules for handling the received UPDATE packet:
	1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the		1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the
	received Keymat Index MUST be zero and the Group ID must match		received KEYMAT Index MUST be zero and the Group ID must match
	the Group ID in use on the association. If this test fails, the		the Group ID in use on the association. If this test fails, the
	packet SHOULD be dropped and the system SHOULD log an error		packet SHOULD be dropped and the system SHOULD log an error
	message.		message.
	2. If there is no outstanding rekeying request, the packet		2. If there is no outstanding rekeying request, the packet
	processing continues as specified in Section 6.9.1.		processing continues as specified in Section 6.9.1.
	3. If there is an outstanding rekeying request, the UPDATE MUST be		3. If there is an outstanding rekeying request, the UPDATE MUST be
	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
	skipping to change at page 27, line 9 ¶		skipping to change at page 27, line 9 ¶
	handling a received UPDATE packet with ESP_INFO parameter:		handling a received UPDATE packet with 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 Group
	ID) if needed. The system records any newly generated or		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		step, or if it received a DIFFIE_HELLMAN parameter, it sets
	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 or equal to the index of the next byte to		Index MUST be greater or equal to the index of the next byte to
	be drawn from the current KEYMAT. In this case, it is		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.
	3. The system creates an UPDATE packet, which contains an ESP_INFO		3. The system creates an UPDATE packet, which contains an ESP_INFO
	parameter, and the optional DIFFIE_HELLMAN parameter. This		parameter, and the optional DIFFIE_HELLMAN parameter. This
	UPDATE would also typically acknowledge the peer's UPDATE with an		UPDATE would also typically acknowledge the peer's UPDATE with an
	ACK parameter, although a separate UPDATE ACK may be sent.		ACK parameter, although a separate UPDATE ACK may be sent.
	4. The system sends the UPDATE packet and stores any received		4. The system sends the UPDATE packet and stores any received
	ESP_INFO, and DIFFIE_HELLMAN parameters. At this point, it only		ESP_INFO, and DIFFIE_HELLMAN parameters. At this point, it only
	needs to receive an acknowledgement for the newly sent UPDATE to		needs to receive an acknowledgement for the newly sent UPDATE to
	skipping to change at page 27, line 40 ¶		skipping to change at page 27, line 40 ¶
	successfully received the peer's UPDATE. The following steps are		successfully received the peer's UPDATE. The following steps are
	taken:		taken:
	1. If the received UPDATE messages contains a new Diffie-Hellman		1. If the received UPDATE messages contains a new Diffie-Hellman
	key, the system has a new Diffie-Hellman key due to initiating		key, the system has a new Diffie-Hellman key due to initiating
	ESP SA update, or both, the system generates new KEYMAT. If		ESP SA update, or both, the system generates new KEYMAT. If
	there is only one new Diffie-Hellman key, the old existing key is		there is only one new Diffie-Hellman key, the old existing key is
	used as the other key.		used as the other key.
	2. If the system generated new KEYMAT in the previous step, it sets		2. If the system generated new KEYMAT in the previous step, it sets
	Keymat Index to zero, independent of whether the received UPDATE		KEYMAT Index to zero, independent of whether the received UPDATE
	included a Diffie-Hellman key or not. If the system did not		included a Diffie-Hellman key or not. If the system did not
	generate new KEYMAT, it uses the greater Keymat Index of the two		generate new KEYMAT, it uses the greater KEYMAT Index of the two
	(sent and received) ESP_INFO parameters.		(sent and received) ESP_INFO parameters.
	3. The system draws keys for new incoming and outgoing ESP SAs,		3. The system draws keys for new incoming and outgoing ESP SAs,
	starting from the Keymat Index, and prepares new incoming and		starting from the KEYMAT Index, and prepares new incoming and
	outgoing ESP SAs. The SPI for the outgoing SA is the new SPI		outgoing ESP SAs. The SPI for the outgoing SA is the new SPI
	value received in an ESP_INFO parameter. The SPI for the		value received in an ESP_INFO parameter. The SPI for the
	incoming SA was generated when the ESP_INFO was sent to the peer.		incoming SA was generated when the ESP_INFO was sent to the peer.
	The order of the keys retrieved from the KEYMAT during rekeying		The order of the keys retrieved from the KEYMAT during rekeying
	process is similar to that described in Section 7. Note, that		process is similar to that described in Section 7. Note, that
	only IPsec ESP keys are retrieved during rekeying process, not		only IPsec ESP keys are retrieved during rekeying process, not
	the HIP keys.		the HIP keys.
	4. The system starts to send to the new outgoing SA and prepares to		4. The system starts to send to the new outgoing SA and prepares to
	start receiving data on the new incoming SA. Once the system		start receiving data on the new incoming SA. Once the system
	skipping to change at page 30, line 24 ¶		skipping to change at page 30, line 24 ¶
	ESP Security Associations.		ESP Security Associations.
	The following issues are new, or changed from the standard ESP usage:		The following issues are new, or changed from the standard ESP usage:
	o Initial keying material generation		o Initial keying material generation
	o Updating the keying material		o Updating the keying material
	The initial keying material is generated using the Host Identity		The initial keying material is generated using the Host Identity
	Protocol [I-D.ietf-hip-base] using Diffie-Hellman procedure. This		Protocol [I-D.ietf-hip-base] using Diffie-Hellman procedure. This
	document extends the usage of UDPATE packet, defined in the base		document extends the usage of UPDATE packet, defined in the base
	specification, to modify existing ESP SAs. The hosts may rekey, i.e.		specification, to modify existing ESP SAs. The hosts may rekey, i.e.
	force the generation of new keying material using Diffie-Hellman		force the generation of new keying material using Diffie-Hellman
	procedure. The initial setup of ESP SA between the hosts is done		procedure. The initial setup of ESP SA between the hosts is done
	during the base ecxhange and the message exchange is protected with		during the base exchange and the message exchange is protected with
	using methods provided by base exchange. Changing of connection		using methods provided by base exchange. Changing of connection
	parameters means basically that the old ESP SA is removed and a new		parameters means basically that the old ESP SA is removed and a new
	one is generated once the UPDATE message exchange has been completed.		one is generated once the UPDATE message exchange has been completed.
	The message exchange is protected using the HIP association keys.		The message exchange is protected using the HIP association keys.
	Both HMAC and signing of packets is used.		Both HMAC and signing of packets is used.
	9. IANA Considerations		9. IANA Considerations
	This document defines additional parameters and NOTIFY error types		This document defines additional parameters and NOTIFY error types
	for the Host Identity Protocol [I-D.ietf-hip-base].		for the Host Identity Protocol [I-D.ietf-hip-base].
	The new parameters and their type numbers are defined in		The new parameters and their type numbers are defined in
	Section 5.1.1 and Section 5.1.2 and they are added in the Parameter		Section 5.1.1 and Section 5.1.2 and they are added in the Parameter
	Type namespace, specified in [I-D.ietf-hip-base].		Type namespace, specified in [I-D.ietf-hip-base].
	The new NOTFY error types and their values are defined in		The new NOTIFY error types and their values are defined in
	Section 5.1.3 and they are added in Notify Message Type namespace,		Section 5.1.3 and they are added in Notify Message Type namespace,
	specified in [I-D.ietf-hip-base].		specified in [I-D.ietf-hip-base].
	10. Acknowledgments		10. 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 giving comments and		people have contributed to the text by giving comments and
	modification proposals. The list of people include Tom Henderson,		modification proposals. The list of people include Tom Henderson,
	Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. Authors		Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. Authors
	want also thank Charlie Kaufman for reviewing the document with the		want also thank Charlie Kaufman for reviewing the document with the
	eye on the usage of crypto algorithms.		eye on the usage of crypto algorithms.
	Due to the history of this document, most of the ideas are inherited		Due to the history of this document, most of the ideas are inherited
	from the base "Host Identity Protocol" specification. Thus the list		from the base "Host Identity Protocol" specification. Thus the list
	of people in the Acknowledgments section of that specification is		of people in the Acknowledgments section of that specification is
	also valid for this document. Many people have given valueable		also valid for this document. Many people have given valuable
	feedback, and our apologies for anyone whose name is missing.		feedback, and our apologies for anyone whose name is missing.
	11. References		11. References
	11.1. Normative references		11.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
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within		[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
	skipping to change at page 33, line 24 ¶		skipping to change at page 33, line 24 ¶
	[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher		[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
	Algorithm and Its Use with IPsec", RFC 3602,		Algorithm and Its Use with IPsec", RFC 3602,
	September 2003.		September 2003.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, December 2005.		RFC 4303, December 2005.
	[I-D.ietf-hip-base]		[I-D.ietf-hip-base]
	Moskowitz, R., "Host Identity Protocol",		Moskowitz, R., "Host Identity Protocol",
	draft-ietf-hip-base-06 (work in progress), June 2006.		draft-ietf-hip-base-07 (work in progress), February 2007.
	11.2. Informative references		11.2. Informative references
	[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher		[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
	Algorithms", RFC 2451, November 1998.		Algorithms", RFC 2451, November 1998.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
	February 1997.		February 1997.
	skipping to change at page 33, line 48 ¶		skipping to change at page 33, line 48 ¶
	in progress), April 2005.		in progress), April 2005.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	RFC 4306, December 2005.		RFC 4306, December 2005.
	[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.
	[I-D.nikander-esp-beet-mode]		[I-D.nikander-esp-beet-mode]
	Melen, J. and P. Nikander, "A Bound End-to-End Tunnel		Melen, J. and P. Nikander, "A Bound End-to-End Tunnel
	(BEET) mode for ESP", draft-nikander-esp-beet-mode-06		(BEET) mode for ESP", draft-nikander-esp-beet-mode-07
	(work in progress), August 2006.		(work in progress), February 2007.
	[I-D.ietf-hip-mm]		[I-D.ietf-hip-mm]
	Nikander, P., "End-Host Mobility and Multihoming with the		Henderson, T., "End-Host Mobility and Multihoming with the
	Host Identity Protocol", draft-ietf-hip-mm-04 (work in		Host Identity Protocol", draft-ietf-hip-mm-05 (work in
	progress), June 2006.		progress), March 2007.
	[RFC3260] Grossman, D., "New Terminology and Clarifications for		[RFC3260] Grossman, D., "New Terminology and Clarifications for
	Diffserv", RFC 3260, April 2002.		Diffserv", RFC 3260, April 2002.
	[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA		[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA
	assignments for Generalized MultiProtocol Label Switching		assignments for Generalized MultiProtocol Label Switching
	(GMPLS) Resource Reservation Protocol - Traffic		(GMPLS) Resource Reservation Protocol - Traffic
	Engineering (RSVP-TE) Usage and Extensions for		Engineering (RSVP-TE) Usage and Extensions for
	Automatically Switched Optical Network (ASON)", RFC 3474,		Automatically Switched Optical Network (ASON)", RFC 3474,
	March 2003.		March 2003.
	skipping to change at page 35, line 12 ¶		skipping to change at page 35, line 12 ¶
	[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol		[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
	(HIP) Architecture", RFC 4423, May 2006.		(HIP) Architecture", RFC 4423, May 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		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,
	the IP addresses are replaced with HITs, based on the SPI in the		the IP addresses are replaced with HITs, based on the SPI in the
	incoming packet. In such an implementation, all IPsec policies are		incoming packet. In such an implementation, all IPsec policies are
	based on HITs and the upper layers only see packets with HITs in the		based on HITs and the upper layers only see packets with HITs in the
	place of IP addresses. Consequently, support of HIP does not		place of IP addresses. Consequently, support of HIP does not
	conflict with other use of IPsec as long as the SPI spaces are kept		conflict with other use of IPsec as long as the SPI spaces are kept
	separate.		separate.
	Another way for implementing is to use the proposed BEET mode (A		Another way for implementing is to use the proposed BEET mode (A
End of changes. 29 change blocks.
	34 lines changed or deleted		34 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/