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/