rfc7401v8.txt		rfc7401.txt
	skipping to change at page 3, line 6		skipping to change at page 3, line 6
	4.1.8. HIP Opportunistic Mode .............................21		4.1.8. HIP Opportunistic Mode .............................21
	4.2. Updating a HIP Association ................................24		4.2. Updating a HIP Association ................................24
	4.3. Error Processing ..........................................24		4.3. Error Processing ..........................................24
	4.4. HIP State Machine .........................................25		4.4. HIP State Machine .........................................25
	4.4.1. State Machine Terminology ..........................26		4.4.1. State Machine Terminology ..........................26
	4.4.2. HIP States .........................................27		4.4.2. HIP States .........................................27
	4.4.3. HIP State Processes ................................28		4.4.3. HIP State Processes ................................28
	4.4.4. Simplified HIP State Diagram .......................35		4.4.4. Simplified HIP State Diagram .......................35
	4.5. User Data Considerations ..................................37		4.5. User Data Considerations ..................................37
	4.5.1. TCP and UDP Pseudo-Header Computation for		4.5.1. TCP and UDP Pseudo Header Computation for
	User Data ..........................................37		User Data ..........................................37
	4.5.2. Sending Data on HIP Packets ........................37		4.5.2. Sending Data on HIP Packets ........................37
	4.5.3. Transport Formats ..................................37		4.5.3. Transport Formats ..................................37
	4.5.4. Reboot, Timeout, and Restart of HIP ................37		4.5.4. Reboot, Timeout, and Restart of HIP ................37
	4.6. Certificate Distribution ..................................38		4.6. Certificate Distribution ..................................38
	5. Packet Formats .................................................38		5. Packet Formats .................................................38
	5.1. Payload Format ............................................38		5.1. Payload Format ............................................38
	5.1.1. Checksum ...........................................40		5.1.1. Checksum ...........................................40
	5.1.2. HIP Controls .......................................40		5.1.2. HIP Controls .......................................40
	5.1.3. HIP Fragmentation Support ..........................40		5.1.3. HIP Fragmentation Support ..........................40
	skipping to change at page 6, line 32		skipping to change at page 6, line 32
	explained in the HIP architecture description [HIP-ARCH].		explained in the HIP architecture description [HIP-ARCH].
	There are two main representations of the Host Identity, the full		There are two main representations of the Host Identity, the full
	Host Identity (HI) and the Host Identity Tag (HIT). The HI is a		Host Identity (HI) and the Host Identity Tag (HIT). The HI is a
	public key and directly represents the Identity of a host. Since		public key and directly represents the Identity of a host. Since
	there are different public key algorithms that can be used with		there are different public key algorithms that can be used with
	different key lengths, the HI, as such, is unsuitable for use as a		different key lengths, the HI, as such, is unsuitable for use as a
	packet identifier, or as an index into the various state-related		packet identifier, or as an index into the various state-related
	implementation structures needed to support HIP. Consequently, a		implementation structures needed to support HIP. Consequently, a
	hash of the HI, the Host Identity Tag (HIT), is used as the		hash of the HI, the Host Identity Tag (HIT), is used as the
	operational representation. The HIT is 128 bits long and is used in		operational representation. The HIT is 128 bits long and is used
	the HIP headers and to index the corresponding state in the end		in the HIP headers and to index the corresponding state in the
	hosts. The HIT has an important security property in that it is		end hosts. The HIT has an important security property in that it
	self-certifying (see Section 3).		is self-certifying (see Section 3).
	1.2. The HIP Base Exchange (BEX)		1.2. The HIP Base Exchange (BEX)
	The HIP base exchange is a two-party cryptographic protocol used to		The HIP base exchange is a two-party cryptographic protocol used to
	establish communications context between hosts. The base exchange is		establish communications context between hosts. The base exchange is
	a SIGMA-compliant [KRA03] four-packet exchange. The first party is		a SIGMA-compliant [KRA03] four-packet exchange. The first party is
	called the Initiator and the second party the Responder. The		called the Initiator and the second party the Responder. The
	protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd		protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd
	packets, and authenticates the parties in the 3rd and 4th packets.		packets, and authenticates the parties in the 3rd and 4th packets.
	The four-packet design helps to make HIP resistant to DoS attacks.		The four-packet design helps to make HIP resistant to DoS attacks.
	skipping to change at page 9, line 8		skipping to change at page 9, line 8
	HIP packet: A control packet carrying a HIP packet header relating		HIP packet: A control packet carrying a HIP packet header relating
	to the establishment, maintenance, or termination of the HIP		to the establishment, maintenance, or termination of the HIP
	association.		association.
	Initiator: The host that initiates the BEX. This role is typically		Initiator: The host that initiates the BEX. This role is typically
	forgotten once the BEX is completed.		forgotten once the BEX is completed.
	Responder: The host that responds to the Initiator in the BEX. This		Responder: The host that responds to the Initiator in the BEX. This
	role is typically forgotten once the BEX is completed.		role is typically forgotten once the BEX is completed.
	Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for		Responder's HIT hash algorithm (RHASH): The hash algorithm used for
	various hash calculations in this document. The algorithm is the		various hash calculations in this document. The algorithm is the
	same as is used to generate the Responder's HIT. The RHASH is the		same as is used to generate the Responder's HIT. The RHASH is the
	hash function defined by the HIT Suite of the Responder's HIT		hash function defined by the HIT Suite of the Responder's HIT
	(cf. Section 5.2.10).		(cf. Section 5.2.10).
	Length of the Responder's HIT Hash Algorithm (RHASH_len): The		Length of the Responder's HIT hash algorithm (RHASH_len): The
	natural output length of RHASH in bits.		natural output length of RHASH in bits.
	Signed data: Data that is signed is protected by a digital signature		Signed data: Data that is signed is protected by a digital signature
	that was created by the sender of the data by using the private		that was created by the sender of the data by using the private
	key of its HI.		key of its HI.
	KDF: The Key Derivation Function (KDF) is used for deriving the		KDF: The Key Derivation Function (KDF) is used for deriving the
	symmetric keys from the Diffie-Hellman key exchange.		symmetric keys from the Diffie-Hellman key exchange.
	KEYMAT: The keying material derived from the Diffie-Hellman key		KEYMAT: The keying material derived from the Diffie-Hellman key
	skipping to change at page 37, line 7		skipping to change at page 37, line 7
	+---------------------| CLOSED |------------------------------+ |		+---------------------| CLOSED |------------------------------+ |
	+--------+ |		+--------+ |
	^ | | |		^ | | |
	recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) |		recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) |
	+-+ +------------------------------------+		+-+ +------------------------------------+
	Figure 2		Figure 2
	4.5. User Data Considerations		4.5. User Data Considerations
	4.5.1. TCP and UDP Pseudo-Header Computation for User Data		4.5.1. TCP and UDP Pseudo Header Computation for User Data
	When computing TCP and UDP checksums on user data packets that flow		When computing TCP and UDP checksums on user data packets that flow
	through sockets bound to HITs, the IPv6 pseudo-header format		through sockets bound to HITs, the IPv6 pseudo header format
	[RFC2460] MUST be used, even if the actual addresses in the header of		[RFC2460] MUST be used, even if the actual addresses in the header of
	the packet are IPv4 addresses. Additionally, the HITs MUST be used		the packet are IPv4 addresses. Additionally, the HITs MUST be used
	in place of the IPv6 addresses in the IPv6 pseudo-header. Note that		in place of the IPv6 addresses in the IPv6 pseudo header. Note that
	the pseudo-header for actual HIP payloads is computed differently;		the pseudo header for actual HIP payloads is computed differently;
	see Section 5.1.1.		see Section 5.1.1.
	4.5.2. Sending Data on HIP Packets		4.5.2. Sending Data on HIP Packets
	Other documents may define how to include user data in various HIP		Other documents may define how to include user data in various HIP
	packets. However, currently the HIP header is a terminal header, and		packets. However, currently the HIP header is a terminal header, and
	not followed by any other headers.		not followed by any other headers.
	4.5.3. Transport Formats		4.5.3. Transport Formats
	skipping to change at page 40, line 10		skipping to change at page 40, line 10
	protocol may need to check these bits in order to determine how to		protocol may need to check these bits in order to determine how to
	handle the packet.		handle the packet.
	The HIT fields are always 128 bits (16 bytes) long.		The HIT fields are always 128 bits (16 bytes) long.
	5.1.1. Checksum		5.1.1. Checksum
	Since the checksum covers the source and destination addresses in the		Since the checksum covers the source and destination addresses in the
	IP header, it MUST be recomputed on HIP-aware NAT devices.		IP header, it MUST be recomputed on HIP-aware NAT devices.
	If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460]		If IPv6 is used to carry the HIP packet, the pseudo header [RFC2460]
	contains the source and destination IPv6 addresses, HIP packet length		contains the source and destination IPv6 addresses, HIP packet length
	in the pseudo-header Length field, a zero field, and the HIP protocol		in the pseudo header Length field, a zero field, and the HIP protocol
	number (see Section 5.1) in the Next Header field. The Length field		number (see Section 5.1) in the Next Header field. The Length field
	is in bytes and can be calculated from the HIP Header Length field:		is in bytes and can be calculated from the HIP Header Length field:
	(HIP Header Length + 1) * 8.		(HIP Header Length + 1) * 8.
	In case of using IPv4, the IPv4 UDP pseudo-header format [RFC0768] is		In case of using IPv4, the IPv4 UDP pseudo header format [RFC0768] is
	used. In the pseudo-header, the source and destination addresses are		used. In the pseudo header, the source and destination addresses are
	those used in the IP header, the zero field is obviously zero, the		those used in the IP header, the zero field is obviously zero, the
	protocol is the HIP protocol number (see Section 4), and the length		protocol is the HIP protocol number (see Section 4), and the length
	is calculated as in the IPv6 case.		is calculated as in the IPv6 case.
	5.1.2. HIP Controls		5.1.2. HIP Controls
	The HIP Controls field conveys information about the structure of the		The HIP Controls field conveys information about the structure of the
	packet and capabilities of the host.		packet and capabilities of the host.
	The following fields have been defined:		The following fields have been defined:
	skipping to change at page 41, line 31		skipping to change at page 41, line 31
	[KAU03]. "Hash and URL" schemes as defined in [RFC6253] for HIP		[KAU03]. "Hash and URL" schemes as defined in [RFC6253] for HIP
	version 1 may be used to avoid fragmentation and mitigate resulting		version 1 may be used to avoid fragmentation and mitigate resulting
	DoS attacks.		DoS attacks.
	5.2. HIP Parameters		5.2. HIP Parameters
	The HIP parameters carry information that is necessary for		The HIP parameters carry information that is necessary for
	establishing and maintaining a HIP association. For example, the		establishing and maintaining a HIP association. For example, the
	peer's public keys as well as the signaling for negotiating ciphers		peer's public keys as well as the signaling for negotiating ciphers
	and payload handling are encapsulated in HIP parameters. Additional		and payload handling are encapsulated in HIP parameters. Additional
	information, meaningful for end-hosts or middleboxes, may also be		information, meaningful for end hosts or middleboxes, may also be
	included in HIP parameters. The specification of the HIP parameters		included in HIP parameters. The specification of the HIP parameters
	and their mapping to HIP packets and packet types is flexible to		and their mapping to HIP packets and packet types is flexible to
	allow HIP extensions to define new parameters and new protocol		allow HIP extensions to define new parameters and new protocol
	behavior.		behavior.
	In HIP packets, HIP parameters are ordered according to their numeric		In HIP packets, HIP parameters are ordered according to their numeric
	type number and encoded in TLV format.		type number and encoded in TLV format.
	The following parameter types are currently defined.		The following parameter types are currently defined.
	skipping to change at page 65, line 39		skipping to change at page 65, line 39
	attack using forged messages, this status may only be returned		attack using forged messages, this status may only be returned
	for packets whose HIP_MAC (if present) and SIGNATURE have been		for packets whose HIP_MAC (if present) and SIGNATURE have been
	verified. This status MUST be sent in response to any error not		verified. This status MUST be sent in response to any error not
	covered by one of the other status types and SHOULD NOT contain		covered by one of the other status types and SHOULD NOT contain
	details, to avoid leaking information to someone probing a node.		details, to avoid leaking information to someone probing a node.
	To aid debugging, more detailed error information SHOULD be		To aid debugging, more detailed error information SHOULD be
	written to a console or log.		written to a console or log.
	NO_DH_PROPOSAL_CHOSEN 14		NO_DH_PROPOSAL_CHOSEN 14
	None of the proposed group IDs were acceptable.		None of the proposed Group IDs were acceptable.
	INVALID_DH_CHOSEN 15		INVALID_DH_CHOSEN 15
	The DH Group ID field does not correspond to one offered		The DH Group ID field does not correspond to one offered
	by the Responder.		by the Responder.
	NO_HIP_PROPOSAL_CHOSEN 16		NO_HIP_PROPOSAL_CHOSEN 16
	None of the proposed HIT Suites or HIP Encryption Algorithms were		None of the proposed HIT Suites or HIP Encryption Algorithms were
	acceptable.		acceptable.
	skipping to change at page 68, line 32		skipping to change at page 68, line 32
	that the sender wants to get echoed back in the corresponding reply		that the sender wants to get echoed back in the corresponding reply
	packet.		packet.
	The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters		The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters
	MAY be used for any purpose where a node wants to carry some state in		MAY be used for any purpose where a node wants to carry some state in
	a request packet and get it back in a response packet. The		a request packet and get it back in a response packet. The
	ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A		ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A
	HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters.		HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters.
	It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters		It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters
	in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED		in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED
	(end-host or middlebox) has to create the Opaque field so that it can		(end host or middlebox) has to create the Opaque field so that it can
	later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED		later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED
	parameter.		parameter.
	The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an		The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an
	ECHO_RESPONSE_UNSIGNED parameter.		ECHO_RESPONSE_UNSIGNED parameter.
	5.2.22. ECHO_RESPONSE_SIGNED		5.2.22. ECHO_RESPONSE_SIGNED
	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
	skipping to change at page 114, line 24		skipping to change at page 114, line 24
	negotiation, an aspect of cryptographic agility. The Initiator		negotiation, an aspect of cryptographic agility. The Initiator
	may express a preference for the choice of a DH group in the I1		may express a preference for the choice of a DH group in the I1
	packet and may suggest multiple possible choices. The Responder		packet and may suggest multiple possible choices. The Responder
	replies with a preference based on local policy and the options		replies with a preference based on local policy and the options
	provided by the Initiator. The Initiator may restart the base		provided by the Initiator. The Initiator may restart the base
	exchange if the option chosen by the Responder is unsuitable		exchange if the option chosen by the Responder is unsuitable
	(unsupported algorithms).		(unsupported algorithms).
	o Another aspect of cryptographic agility that has been added is the		o Another aspect of cryptographic agility that has been added is the
	ability to use different cryptographic hash functions to generate		ability to use different cryptographic hash functions to generate
	the HIT. The Responder's HIT Hash Algorithm (RHASH) terminology		the HIT. The Responder's HIT hash algorithm (RHASH) terminology
	was introduced to support this. In addition, HIT Suites have been		was introduced to support this. In addition, HIT Suites have been
	introduced to group the set of cryptographic algorithms used		introduced to group the set of cryptographic algorithms used
	together for public key signature, hash function, and hash		together for public key signature, hash function, and hash
	truncation. The use of HIT Suites constrains the combinatorial		truncation. The use of HIT Suites constrains the combinatorial
	possibilities of algorithm selection for different functions. HIT		possibilities of algorithm selection for different functions. HIT
	Suite IDs are related to the ORCHID OGA ID field ([RFC7343]).		Suite IDs are related to the ORCHID OGA ID field ([RFC7343]).
	o The puzzle mechanism has been slightly changed, in that the #I		o The puzzle mechanism has been slightly changed, in that the #I
	parameter depends on the HIT Hash function (RHASH) selected, and		parameter depends on the HIT hash function (RHASH) selected, and
	the specification now advises against reusing the same #I value to		the specification now advises against reusing the same #I value to
	the same Initiator; more details are provided in Sections 4.1.2		the same Initiator; more details are provided in Sections 4.1.2
	and 5.2.4).		and 5.2.4).
	o Section 4.1.4 was extended to cover details about R1 generation		o Section 4.1.4 was extended to cover details about R1 generation
	counter rollover or reset.		counter rollover or reset.
	o Section 4.1.6 was added to describe procedures for aborting a HIP		o Section 4.1.6 was added to describe procedures for aborting a HIP
	base exchange.		base exchange.
	skipping to change at page 124, line 25		skipping to change at page 124, line 25
	Header Length: 5 0x5		Header Length: 5 0x5
	Packet Type: 1 0x1		Packet Type: 1 0x1
	Version: 2 0x2		Version: 2 0x2
	Reserved: 1 0x1		Reserved: 1 0x1
	Control: 0 0x0		Control: 0 0x0
	Checksum: 6750 0x1a5e		Checksum: 6750 0x1a5e
	Sender's HIT: 2001:20::1		Sender's HIT: 2001:20::1
	Receiver's HIT: 2001:20::2		Receiver's HIT: 2001:20::2
	DH_GROUP_LIST type: 511 0x1ff		DH_GROUP_LIST type: 511 0x1ff
	DH_GROUP_LIST length: 3 0x3		DH_GROUP_LIST length: 3 0x3
	DH_GROUP_LIST group IDs: 3,4,8		DH_GROUP_LIST Group IDs: 3,4,8
	C.2. IPv4 HIP Packet (I1 Packet)		C.2. IPv4 HIP Packet (I1 Packet)
	The IPv4 checksum value for the example I1 packet is shown below.		The IPv4 checksum value for the example I1 packet is shown below.
	Source Address: 192.0.2.1		Source Address: 192.0.2.1
	Destination Address: 192.0.2.2		Destination Address: 192.0.2.2
	Upper-Layer Packet Length: 48 0x30		Upper-Layer Packet Length: 48 0x30
	Next Header: 139 0x8b		Next Header: 139 0x8b
	Payload Protocol: 59 0x3b		Payload Protocol: 59 0x3b
	Header Length: 5 0x5		Header Length: 5 0x5
	Packet Type: 1 0x1		Packet Type: 1 0x1
	Version: 2 0x2		Version: 2 0x2
	Reserved: 1 0x1		Reserved: 1 0x1
	Control: 0 0x0		Control: 0 0x0
	Checksum: 61902 0xf1ce		Checksum: 61902 0xf1ce
	Sender's HIT: 2001:20::1		Sender's HIT: 2001:20::1
	Receiver's HIT: 2001:20::2		Receiver's HIT: 2001:20::2
	DH_GROUP_LIST type: 511 0x1ff		DH_GROUP_LIST type: 511 0x1ff
	DH_GROUP_LIST length: 3 0x3		DH_GROUP_LIST length: 3 0x3
	DH_GROUP_LIST group IDs: 3,4,8		DH_GROUP_LIST Group IDs: 3,4,8
	C.3. TCP Segment		C.3. TCP Segment
	Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets		Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets
	use the IPv6 pseudo-header format [RFC2460], with the HITs used in		use the IPv6 pseudo header format [RFC2460], with the HITs used in
	place of the IPv6 addresses.		place of the IPv6 addresses.
	Sender's HIT: 2001:20::1		Sender's HIT: 2001:20::1
	Receiver's HIT: 2001:20::2		Receiver's HIT: 2001:20::2
	Upper-Layer Packet Length: 20 0x14		Upper-Layer Packet Length: 20 0x14
	Next Header: 6 0x06		Next Header: 6 0x06
	Source port: 65500 0xffdc		Source port: 65500 0xffdc
	Destination port: 22 0x0016		Destination port: 22 0x0016
	Sequence number: 1 0x00000001		Sequence number: 1 0x00000001
	Acknowledgment number: 0 0x00000000		Acknowledgment number: 0 0x00000000
End of changes. 18 change blocks.
	23 lines changed or deleted		23 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/