< draft-ietf-hip-rfc5201-bis-11.txt		draft-ietf-hip-rfc5201-bis-12.txt >
	Network Working Group R. Moskowitz, Ed.		Network Working Group R. Moskowitz, Ed.
	Internet-Draft Verizon		Internet-Draft Verizon
	Obsoletes: 5201 (if approved) T. Heer		Obsoletes: 5201 (if approved) T. Heer
	Intended status: Standards Track Hirschmann Automation and		Intended status: Standards Track Hirschmann Automation and
	Expires: August 29, 2013 Control		Expires: January 1, 2014 Control
	P. Jokela		P. Jokela
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	T. Henderson		T. Henderson
	The Boeing Company		The Boeing Company
	February 25, 2013		June 30, 2013
	Host Identity Protocol Version 2 (HIPv2)		Host Identity Protocol Version 2 (HIPv2)
	draft-ietf-hip-rfc5201-bis-11		draft-ietf-hip-rfc5201-bis-12
	Abstract		Abstract
	This document specifies the details of the Host Identity Protocol		This document specifies the details of the Host Identity Protocol
	(HIP). HIP allows consenting hosts to securely establish and		(HIP). HIP allows consenting hosts to securely establish and
	maintain shared IP-layer state, allowing separation of the identifier		maintain shared IP-layer state, allowing separation of the identifier
	and locator roles of IP addresses, thereby enabling continuity of		and locator roles of IP addresses, thereby enabling continuity of
	communications across IP address changes. HIP is based on a SIGMA-		communications across IP address changes. HIP is based on a SIGMA-
	compliant Diffie-Hellman key exchange, using public key identifiers		compliant Diffie-Hellman key exchange, using public key identifiers
	from a new Host Identity namespace for mutual peer authentication.		from a new Host Identity namespace for mutual peer authentication.
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 August 29, 2013.		This Internet-Draft will expire on January 1, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 61		5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 61
	5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65		5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65
	5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 65		5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 65
	5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66		5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66
	5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67		5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67
	5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . 67		5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . 67
	5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 68		5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 68
	5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69		5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69
	5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72		5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72
	5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 73		5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 73
	5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 73		5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 74
	5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 74		5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 75
	5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 75		5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 75
	5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 75		5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 76
	5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . 76		5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . 76
	5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 76		5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 76
	5.4.2. Other Problems with the HIP Header and Packet		5.4.2. Other Problems with the HIP Header and Packet
	Structure . . . . . . . . . . . . . . . . . . . . . . 76		Structure . . . . . . . . . . . . . . . . . . . . . . 76
	5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 76		5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 77
	5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 77		5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 77
	6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 77		6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 77
	6.1. Processing Outgoing Application Data . . . . . . . . . . 78		6.1. Processing Outgoing Application Data . . . . . . . . . . 78
	6.2. Processing Incoming Application Data . . . . . . . . . . 79		6.2. Processing Incoming Application Data . . . . . . . . . . 79
	6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 79		6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 80
	6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 81		6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 81
	6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 81		6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 81
	6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84		6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84
	6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . 86		6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . 86
	6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . 87		6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . 87
	6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 88		6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 88
	6.6.2. Processing Incoming ICMP Protocol Unreachable		6.6.2. Processing Incoming ICMP Protocol Unreachable
	Messages . . . . . . . . . . . . . . . . . . . . . . 88		Messages . . . . . . . . . . . . . . . . . . . . . . 89
	6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 89		6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 89
	6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 90		6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 90
	6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 91		6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 91
	6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 91		6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 91
	6.8.1. Handling of Malformed Messages . . . . . . . . . . . 93		6.8.1. Handling of Malformed Messages . . . . . . . . . . . 94
	6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 94		6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 94
	6.9.1. Handling of Malformed Messages . . . . . . . . . . . 96		6.9.1. Handling of Malformed Messages . . . . . . . . . . . 97
	6.10. Processing of Incoming R2 Packets . . . . . . . . . . . 96		6.10. Processing of Incoming R2 Packets . . . . . . . . . . . 97
	6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 97		6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 97
	6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 98		6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 98
	6.12.1. Handling a SEQ Parameter in a Received UPDATE		6.12.1. Handling a SEQ Parameter in a Received UPDATE
	Message . . . . . . . . . . . . . . . . . . . . . . . 99		Message . . . . . . . . . . . . . . . . . . . . . . . 99
	6.12.2. Handling an ACK Parameter in a Received UPDATE		6.12.2. Handling an ACK Parameter in a Received UPDATE
	Packet . . . . . . . . . . . . . . . . . . . . . . . 100		Packet . . . . . . . . . . . . . . . . . . . . . . . 100
	6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 100		6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 101
	6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 100		6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 101
	6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 101		6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 101
	6.16. Handling State Loss . . . . . . . . . . . . . . . . . . 101		6.16. Handling State Loss . . . . . . . . . . . . . . . . . . 101
	7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 101		7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 102
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 102		8. Security Considerations . . . . . . . . . . . . . . . . . . . 102
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107
	11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 108		11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 108
	11.1. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 108		11.1. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 108
	11.2. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 108		11.2. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 109
	11.3. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 108		11.3. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 109
	11.4. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 108		11.4. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 109
	11.5. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 109		11.5. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 109
	11.6. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 109		11.6. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 109
	11.7. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 109		11.7. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 109
	11.8. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 111		11.8. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 110
	11.9. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 111		11.9. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 111
	11.10. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 112		11.10. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 112
	11.11. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 114		11.11. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 113
	11.12. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 114		11.12. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 114
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 114		11.13. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 115
	12.1. Normative References . . . . . . . . . . . . . . . . . . 114		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 115
			12.1. Normative References . . . . . . . . . . . . . . . . . . 115
	12.2. Informative References . . . . . . . . . . . . . . . . . 117		12.2. Informative References . . . . . . . . . . . . . . . . . 117
	Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 119		Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 120
	Appendix B. Generating a Public Key Encoding from an HI . . . . 120		Appendix B. Generating a Public Key Encoding from an HI . . . . 121
	Appendix C. Example Checksums for HIP Packets . . . . . . . . . 121		Appendix C. Example Checksums for HIP Packets . . . . . . . . . 121
	C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 121		C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 122
	C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . 121		C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . 122
	C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . 122		C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . 122
	Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 123		Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 123
	Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 123		Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 123
	1. Introduction		1. Introduction
	This document specifies the details of the Host Identity Protocol		This document specifies the details of the Host Identity Protocol
	(HIP). A high-level description of the protocol and the underlying		(HIP). A high-level description of the protocol and the underlying
	architectural thinking is available in the separate HIP architecture		architectural thinking is available in the separate HIP architecture
	description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP		description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP
	skipping to change at page 69, line 47 ¶		skipping to change at page 69, line 47 ¶
	DST HIT = Initiator's HIT		DST HIT = Initiator's HIT
	IP ( HIP ( [ R1_COUNTER, ]		IP ( HIP ( [ R1_COUNTER, ]
	PUZZLE,		PUZZLE,
	DIFFIE_HELLMAN,		DIFFIE_HELLMAN,
	HIP_CIPHER,		HIP_CIPHER,
	HOST_ID,		HOST_ID,
	HIT_SUITE_LIST,		HIT_SUITE_LIST,
	DH_GROUP_LIST,		DH_GROUP_LIST,
	[ ECHO_REQUEST_SIGNED, ]		[ ECHO_REQUEST_SIGNED, ]
			TRANSPORT_FORMAT_LIST,
	HIP_SIGNATURE_2 )		HIP_SIGNATURE_2 )
	<, ECHO_REQUEST_UNSIGNED >i)		<, ECHO_REQUEST_UNSIGNED >i)
	Valid control bits: A		Valid control bits: A
	If the Responder's HI is an anonymous one, the A control MUST be set.		If the Responder's HI is an anonymous one, the A control MUST be set.
	The Initiator's HIT MUST match the one received in the I1 packet if		The Initiator's HIT MUST match the one received in the I1 packet if
	the R1 is a response to an I1. If the Responder has multiple HIs,		the R1 is a response to an I1. If the Responder has multiple HIs,
	the Responder's HIT used MUST match Initiator's request. If the		the Responder's HIT used MUST match Initiator's request. If the
	Initiator used opportunistic mode, the Responder may select freely		Initiator used opportunistic mode, the Responder may select freely
	among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8).		among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8).
	The R1 packet generation counter is used to determine the currently		The R1 packet generation counter is used to determine the currently
	valid generation of puzzles. The value is increased periodically,		valid generation of puzzles. The value is increased periodically,
	skipping to change at page 71, line 47 ¶		skipping to change at page 71, line 50 ¶
	determine whether its own source HIT matches any suite supported by		determine whether its own source HIT matches any suite supported by
	the Responder.		the Responder.
	The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain		The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain
	data that the sender wants to receive unmodified in the corresponding		data that the sender wants to receive unmodified in the corresponding
	response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED		response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED
	parameter. The R1 packet may contain zero or more		parameter. The R1 packet may contain zero or more
	ECHO_REQUEST_UNSIGNED parameters as described in Section		ECHO_REQUEST_UNSIGNED parameters as described in Section
	Section 5.2.21.		Section 5.2.21.
			The TRANSPORT_FORMAT_LIST parameter is an ordered list of the
			Responder's preferred and supported transport format types. The list
			allows the Initiator and the Responder to agree on a common type for
			payload protection. This parameter is described in Section 5.2.11.
	The signature is calculated over the whole HIP packet as described in		The signature is calculated over the whole HIP packet as described in
	Section 5.2.15. This allows the Responder to use precomputed R1s.		Section 5.2.15. This allows the Responder to use precomputed R1s.
	The Initiator SHOULD validate this signature. It MUST check that the		The Initiator SHOULD validate this signature. It MUST check that the
	Responder's HI matches with the one expected, if any.		Responder's HI matches with the one expected, if any.
	5.3.3. I2 - the Second HIP Initiator Packet		5.3.3. I2 - the Second HIP Initiator Packet
	The HIP header values for the I2 packet:		The HIP header values for the I2 packet:
	Header:		Header:
	Type = 3		Type = 3
	SRC HIT = Initiator's HIT		SRC HIT = Initiator's HIT
	DST HIT = Responder's HIT		DST HIT = Responder's HIT
	IP ( HIP ( [R1_COUNTER,]		IP ( HIP ( [R1_COUNTER,]
	SOLUTION,		SOLUTION,
	DIFFIE_HELLMAN,		DIFFIE_HELLMAN,
	HIP_CIPHER,		HIP_CIPHER,
	ENCRYPTED { HOST_ID } or HOST_ID,		ENCRYPTED { HOST_ID } or HOST_ID,
	[ ECHO_RESPONSE_SIGNED ,]		[ ECHO_RESPONSE_SIGNED ,]
			TRANSPORT_FORMAT_LIST,
	HIP_MAC,		HIP_MAC,
	HIP_SIGNATURE		HIP_SIGNATURE
	<, ECHO_RESPONSE_UNSIGNED>i ) )		<, ECHO_RESPONSE_UNSIGNED>i ) )
	Valid control bits: A		Valid control bits: A
	The HITs used MUST match the ones used in the R1.		The HITs used MUST match the ones used in the R1.
	If the Initiator's HI is an anonymous one, the A control MUST be set.		If the Initiator's HI is an anonymous one, the A control MUST be set.
	skipping to change at page 73, line 6 ¶		skipping to change at page 73, line 14 ¶
	Responder in the R1. All implementations MUST support AES [RFC3602].		Responder in the R1. All implementations MUST support AES [RFC3602].
	The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption		The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption
	algorithm. The keying material is derived from the Diffie-Hellman		algorithm. The keying material is derived from the Diffie-Hellman
	exchanged as defined in Section 6.5.		exchanged as defined in Section 6.5.
	The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the		The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the
	unmodified Opaque data copied from the corresponding echo request		unmodified Opaque data copied from the corresponding echo request
	parameter(s).		parameter(s).
			The TRANSPORT_FORMAT_LIST contains the single transport format type
			selected by the Initiator. The chosen type MUST correspond to one of
			the types offered by the Responder in the R1. Currently, the only
			transport format defined is the ESP transport format
			([I-D.ietf-hip-rfc5202-bis]).
	The HMAC value in the HIP_MAC parameter is calculated over the whole		The HMAC value in the HIP_MAC parameter is calculated over the whole
	HIP packet, excluding any parameters after the HIP_MAC, as described		HIP packet, excluding any parameters after the HIP_MAC, as described
	in Section 6.4.1. The Responder MUST validate the HIP_MAC.		in Section 6.4.1. The Responder MUST validate the HIP_MAC.
	The signature is calculated over the whole HIP packet, excluding any		The signature is calculated over the whole HIP packet, excluding any
	parameters after the HIP_SIGNATURE, as described in Section 5.2.14.		parameters after the HIP_SIGNATURE, as described in Section 5.2.14.
	The Responder MUST validate this signature. The Responder uses the		The Responder MUST validate this signature. The Responder uses the
	HI in the packet or a HI acquired by some other means for verifying		HI in the packet or a HI acquired by some other means for verifying
	the signature.		the signature.
	skipping to change at page 90, line 25 ¶		skipping to change at page 90, line 31 ¶
	I1 packet, it sends an R1 with any suitable DH public key.		I1 packet, it sends an R1 with any suitable DH public key.
	5. If the received Responder's HIT in the I1 is NULL, the Responder		5. If the received Responder's HIT in the I1 is NULL, the Responder
	selects a HIT with a the same HIT Suite as the Initiator's HIT.		selects a HIT with a the same HIT Suite as the Initiator's HIT.
	If this HIT Suite is not supported by the Responder, it SHOULD		If this HIT Suite is not supported by the Responder, it SHOULD
	select a REQUIRED HIT Suite from Section 5.2.10, which is		select a REQUIRED HIT Suite from Section 5.2.10, which is
	currently RSA/DSA/SHA-256. Other than that, selecting the HIT is		currently RSA/DSA/SHA-256. Other than that, selecting the HIT is
	a local policy matter.		a local policy matter.
	6. The responder expresses its supported HIP transport formats in		6. The responder expresses its supported HIP transport formats in
	the TRANSPORT_FORMAT_LIST as described in Section 5.2.10. The		the TRANSPORT_FORMAT_LIST as described in Section 5.2.11. The
	Responder MUST at least provide one payload transport format		Responder MUST at least provide one payload transport format
	type.		type.
	7. The Responder sends the R1 packet to the source IP address of the		7. The Responder sends the R1 packet to the source IP address of the
	I1 packet.		I1 packet.
	6.7.1. R1 Management		6.7.1. R1 Management
	All compliant implementations MUST be able to produce R1 packets. An		All compliant implementations MUST be able to produce R1 packets. An
	R1 packet MAY be precomputed. An R1 packet MAY be reused for time		R1 packet MAY be precomputed. An R1 packet MAY be reused for time
	skipping to change at page 95, line 47 ¶		skipping to change at page 96, line 7 ¶
	11. The encrypted HOST_ID is decrypted by the Initiator's encryption		11. The encrypted HOST_ID is decrypted by the Initiator's encryption
	key defined in Section 6.5. If the decrypted data is not a		key defined in Section 6.5. If the decrypted data is not a
	HOST_ID parameter, the I2 packet is silently dropped.		HOST_ID parameter, the I2 packet is silently dropped.
	12. The implementation SHOULD also verify that the Initiator's HIT		12. The implementation SHOULD also verify that the Initiator's HIT
	in the I2 packet corresponds to the Host Identity sent in the I2		in the I2 packet corresponds to the Host Identity sent in the I2
	packet. (Note: some middleboxes may not able to make this		packet. (Note: some middleboxes may not able to make this
	verification.)		verification.)
	13. The system MUST verify the HIP_MAC according to the procedures		13. The system MUST process the TRANSPORT_FORMAT_LIST parameter.
			Other documents specifying transport formats (e.g.
			[I-D.ietf-hip-rfc5202-bis]) contain specifications for handling
			any specific transport selected.
			14. The system MUST verify the HIP_MAC according to the procedures
	in Section 5.2.12.		in Section 5.2.12.
	14. The system MUST verify the HIP_SIGNATURE according to		15. The system MUST verify the HIP_SIGNATURE according to
	Section 5.2.14 and Section 5.3.3.		Section 5.2.14 and Section 5.3.3.
	15. If the checks above are valid, then the system proceeds with		16. If the checks above are valid, then the system proceeds with
	further I2 processing; otherwise, it discards the I2 and its		further I2 processing; otherwise, it discards the I2 and its
	state machine remains in the same state.		state machine remains in the same state.
	16. The I2 packet may have the A bit set -- in this case, the system		17. The I2 packet may have the A bit set -- in this case, the system
	MAY choose to refuse it by dropping the I2 and the state machine		MAY choose to refuse it by dropping the I2 and the state machine
	returns to state UNASSOCIATED. If the A bit is set, the		returns to state UNASSOCIATED. If the A bit is set, the
	Initiator's HIT is anonymous and should not be stored		Initiator's HIT is anonymous and should not be stored
	permanently.		permanently.
	17. The system initializes the remaining variables in the associated		18. The system initializes the remaining variables in the associated
	state, including Update ID counters.		state, including Update ID counters.
	18. Upon successful processing of an I2 message when the system's		19. Upon successful processing of an I2 message when the system's
	state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2-		state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2-
	SENT, an R2 packet is sent and the system's state machine		SENT, an R2 packet is sent and the system's state machine
	transitions to state R2-SENT.		transitions to state R2-SENT.
	19. Upon successful processing of an I2 packet when the system's		20. Upon successful processing of an I2 packet when the system's
	state machine is in state ESTABLISHED, the old HIP association		state machine is in state ESTABLISHED, the old HIP association
	is dropped and a new one is installed, an R2 packet is sent, and		is dropped and a new one is installed, an R2 packet is sent, and
	the system's state machine transitions to R2-SENT.		the system's state machine transitions to R2-SENT.
	20. Upon the system's state machine transitioning to R2-SENT, the		21. Upon the system's state machine transitioning to R2-SENT, the
	system starts a timer. The state machine transitions to		system starts a timer. The state machine transitions to
	ESTABLISHED if some data has been received on the incoming HIP		ESTABLISHED if some data has been received on the incoming HIP
	association, or an UPDATE packet has been received (or some		association, or an UPDATE packet has been received (or some
	other packet that indicates that the peer system's state machine		other packet that indicates that the peer system's state machine
	has moved to ESTABLISHED). If the timer expires (allowing for		has moved to ESTABLISHED). If the timer expires (allowing for
	maximal amount of retransmissions of I2 packets), the state		maximal amount of retransmissions of I2 packets), the state
	machine transitions to ESTABLISHED.		machine transitions to ESTABLISHED.
	6.9.1. Handling of Malformed Messages		6.9.1. Handling of Malformed Messages
	skipping to change at page 108, line 19 ¶		skipping to change at page 108, line 44 ¶
	changes were introduced through the working group process. Most		changes were introduced through the working group process. Most
	notably, the original document was split in two, one containing the		notably, the original document was split in two, one containing the
	base exchange and the other one defining how to use ESP. Some		base exchange and the other one defining how to use ESP. Some
	modifications to the protocol proposed by Aura, et al., [AUR03] were		modifications to the protocol proposed by Aura, et al., [AUR03] were
	added at a later stage.		added at a later stage.
	11. Changes from RFC 5201		11. Changes from RFC 5201
	This section summarizes the changes made from [RFC5201].		This section summarizes the changes made from [RFC5201].
	11.1. Changes from draft-ietf-hip-rfc5201-bis-10		11.1. Changes from draft-ietf-hip-rfc5201-bis-11
			o Specify that TRANSFORM_FORMAT_LIST is mandatory in R1 and I2; fix
			incorrect section reference.
			11.2. Changes from draft-ietf-hip-rfc5201-bis-10
	o Issue 39: Text clarifying R1 counter rollover and Initiator		o Issue 39: Text clarifying R1 counter rollover and Initiator
	response to unexpected reset of the counter.		response to unexpected reset of the counter.
	11.2. Changes from draft-ietf-hip-rfc5201-bis-09		11.3. Changes from draft-ietf-hip-rfc5201-bis-09
	o Editorial changes based on working group last call.		o Editorial changes based on working group last call.
	11.3. Changes from draft-ietf-hip-rfc5201-bis-08		11.4. Changes from draft-ietf-hip-rfc5201-bis-08
	o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to		o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to
	REQUIRED status		REQUIRED status
	o Issue 35: limiting ECC cofactor to 1		o Issue 35: limiting ECC cofactor to 1
	o Changed text regarding issue 33 reusing DH values		o Changed text regarding issue 33 reusing DH values
	o Fix tracker issue 32 on Domain Identifier normative text		o Fix tracker issue 32 on Domain Identifier normative text
	11.4. Changes from draft-ietf-hip-rfc5201-bis-07		11.5. Changes from draft-ietf-hip-rfc5201-bis-07
	o Removed lingering references to SHA-1 as the mandatory hash		o Removed lingering references to SHA-1 as the mandatory hash
	algorithm (which was changed to SHA-256 in the -02 draft version).		algorithm (which was changed to SHA-256 in the -02 draft version).
	o For parameter type number changes, changed "IETF Review" to "IETF		o For parameter type number changes, changed "IETF Review" to "IETF
	Review or IESG Approval".		Review or IESG Approval".
	o Updated Appendix C checksum examples to conform to HIPv2 packets.		o Updated Appendix C checksum examples to conform to HIPv2 packets.
	11.5. Changes from draft-ietf-hip-rfc5201-bis-06		11.6. Changes from draft-ietf-hip-rfc5201-bis-06
	o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains		o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains
	an R1_COUNTER. This required to make the R1 counter a critical		an R1_COUNTER. This required to make the R1 counter a critical
	parameter. Hence, the parameter type number of the R1_COUNTER		parameter. Hence, the parameter type number of the R1_COUNTER
	changed from 128 to 129.		changed from 128 to 129.
	o Made KDF dependent on DH Group to enable negotiation of the KDF.		o Made KDF dependent on DH Group to enable negotiation of the KDF.
	11.6. Changes from draft-ietf-hip-rfc5201-bis-05		11.7. Changes from draft-ietf-hip-rfc5201-bis-05
	o Changed type number of DH_GROUP_LIST from 2151 to 511 because it		o Changed type number of DH_GROUP_LIST from 2151 to 511 because it
	was in the number space that is reserved for the HIP transport		was in the number space that is reserved for the HIP transport
	mode negotiations.		mode negotiations.
	o Added transport form type list parameter. Transport forms are now		o Added transport form type list parameter. Transport forms are now
	negotiated with this list instead of by their order in the HIP		negotiated with this list instead of by their order in the HIP
	packet. This allows to remove the exception of the transport		packet. This allows to remove the exception of the transport
	format parameters that were ordered by their preference instead of		format parameters that were ordered by their preference instead of
	by their type number. This should remove complexity from		by their type number. This should remove complexity from
	skipping to change at page 109, line 48 ¶		skipping to change at page 110, line 29 ¶
	o Permit using Anonymous HI control in packets other than R1/I2.		o Permit using Anonymous HI control in packets other than R1/I2.
	o Fixed minor reference error (RFC2418, RFC2410).		o Fixed minor reference error (RFC2418, RFC2410).
	o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable		o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable
	via the UI.		via the UI.
	o Editorial changes.		o Editorial changes.
	11.7. Changes from draft-ietf-hip-rfc5201-bis-04		11.8. Changes from draft-ietf-hip-rfc5201-bis-04
	o Clarifications of the Security Considerations section. One DoS		o Clarifications of the Security Considerations section. One DoS
	defense mechanism was changed to be more effective and less prone		defense mechanism was changed to be more effective and less prone
	to misuse.		to misuse.
	o Minor clarifications of the state machine.		o Minor clarifications of the state machine.
	o Clarified text on HIP puzzle.		o Clarified text on HIP puzzle.
	o Added names and references for figures.		o Added names and references for figures.
	skipping to change at page 111, line 12 ¶		skipping to change at page 111, line 45 ¶
	o Changed IETF Consensus to IETF Review or IESG Approval in IANA		o Changed IETF Consensus to IETF Review or IESG Approval in IANA
	section.		section.
	o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K		o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K
	throughout the document.		throughout the document.
	o Updated references.		o Updated references.
	o Editorial changes.		o Editorial changes.
	11.8. Changes from draft-ietf-hip-rfc5201-bis-03		11.9. Changes from draft-ietf-hip-rfc5201-bis-03
	o Editorial changes to improve clarity and readability.		o Editorial changes to improve clarity and readability.
	o Removed obsoleted (not applicable) attack from security		o Removed obsoleted (not applicable) attack from security
	consideration section.		consideration section.
	o Added a requirement that hosts MUST support processing of ACK		o Added a requirement that hosts MUST support processing of ACK
	parameters with several SEQ numbers even when they do not support		parameters with several SEQ numbers even when they do not support
	sending such parameters.		sending such parameters.
	skipping to change at page 111, line 48 ¶		skipping to change at page 112, line 34 ¶
	o Clarified the use of HITs in opportunistic mode.		o Clarified the use of HITs in opportunistic mode.
	o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as		o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as
	between SIGNATURE and SIGNATURE_2.		between SIGNATURE and SIGNATURE_2.
	o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to		o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to
	RESPONDER_BUSY_PLEASE_RETRY.		RESPONDER_BUSY_PLEASE_RETRY.
	o Mentioned that there are multiple valid puzzle solutions.		o Mentioned that there are multiple valid puzzle solutions.
	11.9. Changes from draft-ietf-hip-rfc5201-bis-02		11.10. Changes from draft-ietf-hip-rfc5201-bis-02
	o Added recommendation to not use puzzle #I twice for the same host		o Added recommendation to not use puzzle #I twice for the same host
	to avoid identical key material.		to avoid identical key material.
	o Revised state machine and added missing event handling.		o Revised state machine and added missing event handling.
	o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT		o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT
	suites.		suites.
	o Revised parameter type numbers (corresponding to IANA allocations)		o Revised parameter type numbers (corresponding to IANA allocations)
	and added missing "free for experimentation" range to the		and added missing "free for experimentation" range to the
	description.		description.
	o Clarifying note on the use of the C bit in the parameter type		o Clarifying note on the use of the C bit in the parameter type
	numbers.		numbers.
	11.10. Changes from draft-ietf-hip-rfc5201-bis-01		11.11. Changes from draft-ietf-hip-rfc5201-bis-01
	o Changed RHASH-len to RHASH_len to avoid confusion in calculations		o Changed RHASH-len to RHASH_len to avoid confusion in calculations
	(- could be minus)		(- could be minus)
	o Added RHASH_len to list of abbreviations		o Added RHASH_len to list of abbreviations
	o Fixed length of puzzle #I and #J to be 1*RHASH_len		o Fixed length of puzzle #I and #J to be 1*RHASH_len
	o Changed RHASH-len to RHASH_len to avoid confusion in calculations		o Changed RHASH-len to RHASH_len to avoid confusion in calculations
	(- could be minus)		(- could be minus)
	skipping to change at page 114, line 11 ¶		skipping to change at page 114, line 48 ¶
	o Added text about new ORCHID structure to HIT overview.		o Added text about new ORCHID structure to HIT overview.
	o Moved Editor role to Robert Moskowitz.		o Moved Editor role to Robert Moskowitz.
	o Added SHA-256 to puzzle parameter.		o Added SHA-256 to puzzle parameter.
	o Generalized LTRUNC to be hash-function agnostic.		o Generalized LTRUNC to be hash-function agnostic.
	o Added text about RHASH depending on OGA.		o Added text about RHASH depending on OGA.
	11.11. Changes from draft-ietf-hip-rfc5201-bis-00		11.12. Changes from draft-ietf-hip-rfc5201-bis-00
	o Added reasoning why BIS document is needed.		o Added reasoning why BIS document is needed.
	11.12. Contents of draft-ietf-hip-rfc5201-bis-00		11.13. Contents of draft-ietf-hip-rfc5201-bis-00
	o RFC5201 was submitted as draft-RFC.		o RFC5201 was submitted as draft-RFC.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[FIPS.180-2.2002] National Institute of Standards and		[FIPS.180-2.2002] National Institute of Standards and
	Technology, "Secure Hash Standard",		Technology, "Secure Hash Standard",
	FIPS PUB 180-2, August 2002, <http://		FIPS PUB 180-2, August 2002, <http://
	skipping to change at page 114, line 39 ¶		skipping to change at page 115, line 29 ¶
	[I-D.ietf-hip-rfc4843-bis] Laganier, J. and F. Dupont, "An IPv6		[I-D.ietf-hip-rfc4843-bis] Laganier, J. and F. Dupont, "An IPv6
	Prefix for Overlay Routable Cryptographic		Prefix for Overlay Routable Cryptographic
	Hash Identifiers Version 2 (ORCHIDv2)",		Hash Identifiers Version 2 (ORCHIDv2)",
	draft-ietf-hip-rfc4843-bis-02 (work in		draft-ietf-hip-rfc4843-bis-02 (work in
	progress), September 2012.		progress), September 2012.
	[I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., and J. Melen,		[I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., and J. Melen,
	"Using the Encapsulating Security Payload		"Using the Encapsulating Security Payload
	(ESP) Transport Format with the Host		(ESP) Transport Format with the Host
	Identity Protocol (HIP)",		Identity Protocol (HIP)",
	draft-ietf-hip-rfc5202-bis-01 (work in		draft-ietf-hip-rfc5202-bis-02 (work in
	progress), September 2012.		progress), June 2013.
	[NIST.800-131A.2011] National Institute of Standards and		[NIST.800-131A.2011] National Institute of Standards and
	Technology, "Transitions: Recommendation		Technology, "Transitions: Recommendation
	for Transitioning the Use of		for Transitioning the Use of
	Cryptographic Algorithms and Key		Cryptographic Algorithms and Key
	Lengths", NIST 800-131A, January 2011.		Lengths", NIST 800-131A, January 2011.
	[RFC0768] Postel, J., "User Datagram Protocol",		[RFC0768] Postel, J., "User Datagram Protocol",
	STD 6, RFC 768, August 1980.		STD 6, RFC 768, August 1980.
End of changes. 43 change blocks.
	58 lines changed or deleted		81 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/