RFC 7401
Host Identity Protocol Version 2 (HIPv2)
Pages: 128
Proposed Standard
→ Errata
Obsoletes: 5201
Updated by: 8002 9374
Proposed Standard
→ Errata
Obsoletes: 5201
Updated by: 8002 9374
Part 4 of 5 – Pages 70 to 105
5.3. HIP Packets
There are eight basic HIP packets (see Table 11). Four are for the HIP base exchange, one is for updating, one is for sending notifications, and two are for closing a HIP association. Support for the NOTIFY packet type is optional, but support for all other HIP packet types listed below is mandatory. +------------------+------------------------------------------------+ | Packet type | Packet name | +------------------+------------------------------------------------+ | 1 | I1 - the HIP Initiator Packet | | | | | 2 | R1 - the HIP Responder Packet | | | | | 3 | I2 - the Second HIP Initiator Packet | | | | | 4 | R2 - the Second HIP Responder Packet | | | | | 16 | UPDATE - the HIP Update Packet | | | | | 17 | NOTIFY - the HIP Notify Packet | | | | | 18 | CLOSE - the HIP Association Closing Packet | | | | | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | | | Packet | +------------------+------------------------------------------------+ Table 11: HIP Packets and Packet Type Values Packets consist of the fixed header as described in Section 5.1, followed by the parameters. The parameter part, in turn, consists of zero or more TLV-coded parameters. In addition to the base packets, other packet types may be defined later in separate specifications. For example, support for mobility and multihoming is not included in this specification. See "Notation" (Section 2.2) for the notation used in the operations.
In the future, an optional upper-layer payload MAY follow the HIP header. The Next Header field in the header indicates if there is additional data following the HIP header. The HIP packet, however, MUST NOT be fragmented into multiple extension headers by setting the Next Header field in a HIP header to the HIP protocol number. This limits the size of the possible additional data in the packet.5.3.1. I1 - the HIP Initiator Packet
The HIP header values for the I1 packet: Header: Packet Type = 1 SRC HIT = Initiator's HIT DST HIT = Responder's HIT, or NULL IP ( HIP ( DH_GROUP_LIST ) ) The I1 packet contains the fixed HIP header and the Initiator's DH_GROUP_LIST. Valid control bits: None The Initiator receives the Responder's HIT from either a DNS lookup of the Responder's FQDN (see [HIP-DNS-EXT]), some other repository, or a local table. If the Initiator does not know the Responder's HIT, it may attempt to use opportunistic mode by using NULL (all zeros) as the Responder's HIT. See also "HIP Opportunistic Mode" (Section 4.1.8). Since the I1 packet is so easy to spoof even if it were signed, no attempt is made to add to its generation or processing cost. The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to inform the Responder of its preferred DH Group IDs. Note that the DH_GROUP_LIST in the I1 packet is not protected by a signature. Implementations MUST be able to handle a storm of received I1 packets, discarding those with common content that arrive within a small time delta.
5.3.2. R1 - the HIP Responder Packet
The HIP header values for the R1 packet: Header: Packet Type = 2 SRC HIT = Responder's HIT DST HIT = Initiator's HIT IP ( HIP ( [ R1_COUNTER, ] PUZZLE, DIFFIE_HELLMAN, HIP_CIPHER, HOST_ID, HIT_SUITE_LIST, DH_GROUP_LIST, [ ECHO_REQUEST_SIGNED, ] TRANSPORT_FORMAT_LIST, HIP_SIGNATURE_2 ) <, ECHO_REQUEST_UNSIGNED >i) Valid control bits: A 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 R1 is a response to an I1. If the Responder has multiple HIs, the Responder's HIT used MUST match the Initiator's request. If the Initiator used opportunistic mode, the Responder may select freely among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8). The R1 packet generation counter is used to determine the currently valid generation of puzzles. The value is increased periodically, and it is RECOMMENDED that it is increased at least as often as solutions to old puzzles are no longer accepted. The puzzle contains a Random #I and the difficulty #K. The difficulty #K indicates the number of lower-order bits, in the puzzle hash result, that must be zeros; see Section 4.1.2. The Random #I is not covered by the signature and must be zeroed during the signature calculation, allowing the sender to select and set the #I into a precomputed R1 packet just prior to sending it to the peer. The Responder selects the DIFFIE_HELLMAN Group ID and Public Value based on the Initiator's preference expressed in the DH_GROUP_LIST parameter in the I1 packet. The Responder sends back its own preference based on which it chose the DH public value as
DH_GROUP_LIST. This allows the Initiator to determine whether its own DH_GROUP_LIST in the sent I1 packet was manipulated by an attacker. The Diffie-Hellman public value is ephemeral, and values SHOULD NOT be reused across different HIP associations. Once the Responder has received a valid response to an R1 packet, that Diffie-Hellman value SHOULD be deprecated. It is possible that the Responder has sent the same Diffie-Hellman value to different hosts simultaneously in corresponding R1 packets, and those responses should also be accepted. However, as a defense against I1 packet storms, an implementation MAY propose, and reuse unless avoidable, the same Diffie-Hellman value for a period of time -- for example, 15 minutes. By using a small number of different puzzles for a given Diffie-Hellman value, the R1 packets can be precomputed and delivered as quickly as I1 packets arrive. A scavenger process should clean up unused Diffie-Hellman values and puzzles. Reusing Diffie-Hellman public values opens up the potential security risk of more than one Initiator ending up with the same keying material (due to faulty random number generators). Also, more than one Initiator using the same Responder public key half may lead to potentially easier cryptographic attacks and to imperfect forward security. However, these risks involved in reusing the same public value are statistical; that is, the authors are not aware of any mechanism that would allow manipulation of the protocol so that the risk of the reuse of any given Responder Diffie-Hellman public key would differ from the base probability. Consequently, it is RECOMMENDED that Responders avoid reusing the same DH key with multiple Initiators, but because the risk is considered statistical and not known to be manipulable, the implementations MAY reuse a key in order to ease resource-constrained implementations and to increase the probability of successful communication with legitimate clients even under an I1 packet storm. In particular, when it is too expensive to generate enough precomputed R1 packets to supply each potential Initiator with a different DH key, the Responder MAY send the same DH key to several Initiators, thereby creating the possibility of multiple legitimate Initiators ending up using the same Responder-side public key. However, as soon as the Responder knows that it will use a particular DH key, it SHOULD stop offering it. This design is aimed to allow resource-constrained Responders to offer services under I1 packet storms and to simultaneously make the probability of DH key reuse both statistical and as low as possible.
If the Responder uses the same DH key pair for multiple handshakes, it must take care to avoid small subgroup attacks [RFC2785]. To avoid these attacks, when receiving the I2 message, the Responder SHOULD validate the Initiator's DH public key as described in [RFC2785], Section 3.1. If the validation fails, the Responder MUST NOT generate a DH shared key and MUST silently abort the HIP BEX. The HIP_CIPHER parameter contains the encryption algorithms supported by the Responder to encrypt the contents of the ENCRYPTED parameter, in the order of preference. All implementations MUST support AES [RFC3602]. The HIT_SUITE_LIST parameter is an ordered list of the Responder's preferred and supported HIT Suites. The list allows the Initiator to determine whether its own source HIT matches any suite supported by the Responder. The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain data that the sender wants to receive unmodified in the corresponding response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero or more ECHO_REQUEST_UNSIGNED parameters as described in 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 Section 5.2.15. This allows the Responder to use precomputed R1s. The Initiator SHOULD validate this signature. It MUST check that the Responder's HI matches with the one expected, if any.
5.3.3. I2 - the Second HIP Initiator Packet
The HIP header values for the I2 packet: Header: Packet Type = 3 SRC HIT = Initiator's HIT DST HIT = Responder's HIT IP ( HIP ( [R1_COUNTER,] SOLUTION, DIFFIE_HELLMAN, HIP_CIPHER, ENCRYPTED { HOST_ID } or HOST_ID, [ ECHO_RESPONSE_SIGNED, ] TRANSPORT_FORMAT_LIST, HIP_MAC, HIP_SIGNATURE <, ECHO_RESPONSE_UNSIGNED>i ) ) Valid control bits: A The HITs used MUST match the ones used in the R1. If the Initiator's HI is an anonymous one, the A control bit MUST be set. If present in the I1 packet, the Initiator MUST include an unmodified copy of the R1_COUNTER parameter received in the corresponding R1 packet into the I2 packet. The Solution contains the Random #I from R1 and the computed #J. The low-order #K bits of the RHASH( #I | ... | #J ) MUST be zero. The Diffie-Hellman value is ephemeral. If precomputed, a scavenger process should clean up unused Diffie-Hellman values. The Responder MAY reuse Diffie-Hellman values under some conditions as specified in Section 5.3.2. The HIP_CIPHER contains the single encryption suite selected by the Initiator, that it uses to encrypt the ENCRYPTED parameters. The chosen cipher MUST correspond to one of the ciphers offered by the Responder in the R1. All implementations MUST support AES [RFC3602]. The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption algorithm. The keying material is derived from the Diffie-Hellman exchange as defined in Section 6.5.
The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the unmodified opaque data copied from the corresponding echo request 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 ([RFC7402]). The HMAC value in the HIP_MAC parameter is calculated over the whole HIP packet, excluding any parameters after the HIP_MAC, as described in Section 6.4.1. The Responder MUST validate the HIP_MAC. The signature is calculated over the whole HIP packet, excluding any parameters after the HIP_SIGNATURE, as described in Section 5.2.14. The Responder MUST validate this signature. The Responder uses the HI in the packet or an HI acquired by some other means for verifying the signature.5.3.4. R2 - the Second HIP Responder Packet
The HIP header values for the R2 packet: Header: Packet Type = 4 SRC HIT = Responder's HIT DST HIT = Initiator's HIT IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) ) Valid control bits: None The HIP_MAC_2 is calculated over the whole HIP packet, with the Responder's HOST_ID parameter concatenated with the HIP packet. The HOST_ID parameter is removed after the HMAC calculation. The procedure is described in Section 6.4.1. The signature is calculated over the whole HIP packet. The Initiator MUST validate both the HIP_MAC and the signature.
5.3.5. UPDATE - the HIP Update Packet
The HIP header values for the UPDATE packet: Header: Packet Type = 16 SRC HIT = Sender's HIT DST HIT = Recipient's HIT IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) ) Valid control bits: None The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE parameters, and other optional parameters. The UPDATE packet contains zero or one SEQ parameter. The presence of a SEQ parameter indicates that the receiver MUST acknowledge the UPDATE. An UPDATE that does not contain a SEQ but only an ACK parameter is simply an acknowledgment of a previous UPDATE and itself MUST NOT be acknowledged by a separate ACK parameter. Such UPDATE packets containing only an ACK parameter do not require processing in relative order to other UPDATE packets. An UPDATE packet without either a SEQ or an ACK parameter is invalid; such unacknowledged updates MUST instead use a NOTIFY packet. An UPDATE packet contains zero or one ACK parameter. The ACK parameter echoes the SEQ sequence number of the UPDATE packet being ACKed. A host MAY choose to acknowledge more than one UPDATE packet at a time; e.g., the ACK parameter may contain the last two SEQ values received, for resilience against packet loss. ACK values are not cumulative; each received unique SEQ value requires at least one corresponding ACK value in reply. Received ACK parameters that are redundant are ignored. Hosts MUST implement the processing of ACK parameters with multiple SEQ sequence numbers even if they do not implement sending ACK parameters with multiple SEQ sequence numbers. The UPDATE packet may contain both a SEQ and an ACK parameter. In this case, the ACK parameter is being piggybacked on an outgoing UPDATE. In general, UPDATEs carrying SEQ SHOULD be ACKed upon completion of the processing of the UPDATE. A host MAY choose to hold the UPDATE carrying an ACK parameter for a short period of time to allow for the possibility of piggybacking the ACK parameter, in a manner similar to TCP delayed acknowledgments.
A sender MAY choose to forego reliable transmission of a particular UPDATE (e.g., it becomes overcome by events). The semantics are such that the receiver MUST acknowledge the UPDATE, but the sender MAY choose to not care about receiving the ACK parameter. UPDATEs MAY be retransmitted without incrementing SEQ. If the same subset of parameters is included in multiple UPDATEs with different SEQs, the host MUST ensure that the receiver's processing of the parameters multiple times will not result in a protocol error.5.3.6. NOTIFY - the HIP Notify Packet
The NOTIFY packet MAY be used to provide information to a peer. Typically, NOTIFY is used to indicate some type of protocol error or negotiation failure. NOTIFY packets are unacknowledged. The receiver can handle the packet only as informational, and SHOULD NOT change its HIP state (see Section 4.4.2) based purely on a received NOTIFY packet. The HIP header values for the NOTIFY packet: Header: Packet Type = 17 SRC HIT = Sender's HIT DST HIT = Recipient's HIT, or zero if unknown IP ( HIP (<NOTIFICATION>i, [HOST_ID, ] HIP_SIGNATURE) ) Valid control bits: None The NOTIFY packet is used to carry one or more NOTIFICATION parameters.5.3.7. CLOSE - the HIP Association Closing Packet
The HIP header values for the CLOSE packet: Header: Packet Type = 18 SRC HIT = Sender's HIT DST HIT = Recipient's HIT IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) Valid control bits: None
The sender MUST include an ECHO_REQUEST_SIGNED used to validate CLOSE_ACK received in response, and both a HIP_MAC and a signature (calculated over the whole HIP packet). The receiver peer MUST reply with a CLOSE_ACK containing an ECHO_RESPONSE_SIGNED corresponding to the received ECHO_REQUEST_SIGNED.5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet
The HIP header values for the CLOSE_ACK packet: Header: Packet Type = 19 SRC HIT = Sender's HIT DST HIT = Recipient's HIT IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) ) Valid control bits: None The sender MUST include both an HMAC and signature (calculated over the whole HIP packet). The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate both the HIP_MAC and the signature if the receiver has state for a HIP association.5.4. ICMP Messages
When a HIP implementation detects a problem with an incoming packet, and it either cannot determine the identity of the sender of the packet or does not have any existing HIP association with the sender of the packet, it MAY respond with an ICMP packet. Any such replies MUST be rate-limited as described in [RFC4443]. In most cases, the ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for ICMPv6), with the Pointer pointing to the field that caused the ICMP message to be generated.5.4.1. Invalid Version
If a HIP implementation receives a HIP packet that has an unrecognized HIP version number, it SHOULD respond, rate-limited, with an ICMP packet with type Parameter Problem, with the Pointer pointing to the Version/RES. byte in the HIP header.
5.4.2. Other Problems with the HIP Header and Packet Structure
If a HIP implementation receives a HIP packet that has other unrecoverable problems in the header or packet format, it MAY respond, rate-limited, with an ICMP packet with type Parameter Problem, with the Pointer pointing to the field that failed to pass the format checks. However, an implementation MUST NOT send an ICMP message if the checksum fails; instead, it MUST silently drop the packet.5.4.3. Invalid Puzzle Solution
If a HIP implementation receives an I2 packet that has an invalid puzzle solution, the behavior depends on the underlying version of IP. If IPv6 is used, the implementation SHOULD respond with an ICMP packet with type Parameter Problem, with the Pointer pointing to the beginning of the Puzzle solution #J field in the SOLUTION payload in the HIP message. If IPv4 is used, the implementation MAY respond with an ICMP packet with the type Parameter Problem, copying enough bytes from the I2 message so that the SOLUTION parameter fits into the ICMP message, with the Pointer pointing to the beginning of the Puzzle solution #J field, as in the IPv6 case. Note, however, that the resulting ICMPv4 message exceeds the typical ICMPv4 message size as defined in [RFC0792].5.4.4. Non-existing HIP Association
If a HIP implementation receives a CLOSE or UPDATE packet, or any other packet whose handling requires an existing association, that has either a Receiver or Sender HIT that does not match with any existing HIP association, the implementation MAY respond, rate- limited, with an ICMP packet with the type Parameter Problem. The Pointer of the ICMP Parameter Problem packet is set pointing to the beginning of the first HIT that does not match. A host MUST NOT reply with such an ICMP if it receives any of the following messages: I1, R2, I2, R2, and NOTIFY packet. When introducing new packet types, a specification SHOULD define the appropriate rules for sending or not sending this kind of ICMP reply.6. Packet Processing
Each host is assumed to have a single HIP implementation that manages the host's HIP associations and handles requests for new ones. Each HIP association is governed by a conceptual state machine, with states defined above in Section 4.4. The HIP implementation can
simultaneously maintain HIP associations with more than one host. Furthermore, the HIP implementation may have more than one active HIP association with another host; in this case, HIP associations are distinguished by their respective HITs. It is not possible to have more than one HIP association between any given pair of HITs. Consequently, the only way for two hosts to have more than one parallel association is to use different HITs, at least at one end. The processing of packets depends on the state of the HIP association(s) with respect to the authenticated or apparent originator of the packet. A HIP implementation determines whether it has an active association with the originator of the packet based on the HITs. In the case of user data carried in a specific transport format, the transport format document specifies how the incoming packets are matched with the active associations.6.1. Processing Outgoing Application Data
In a HIP host, an application can send application-level data using an identifier specified via the underlying API. The API can be a backwards-compatible API (see [RFC5338]), using identifiers that look similar to IP addresses, or a completely new API, providing enhanced services related to Host Identities. Depending on the HIP implementation, the identifier provided to the application may be different; for example, it can be a HIT or an IP address. The exact format and method for transferring the user data from the source HIP host to the destination HIP host are defined in the corresponding transport format document. The actual data is transferred in the network using the appropriate source and destination IP addresses. In this document, conceptual processing rules are defined only for the base case where both hosts have only single usable IP addresses; the multi-address multihoming case is specified separately. The following conceptual algorithm describes the steps that are required for handling outgoing datagrams destined to a HIT. 1. If the datagram has a specified source address, it MUST be a HIT. If it is not, the implementation MAY replace the source address with a HIT. Otherwise, it MUST drop the packet. 2. If the datagram has an unspecified source address, the implementation MUST choose a suitable source HIT for the datagram. Selecting the source HIT is subject to local policy.
3. If there is no active HIP association with the given <source,
destination> HIT pair, one MUST be created by running the base
exchange. While waiting for the base exchange to complete, the
implementation SHOULD queue at least one user data packet per HIP
association to be formed, and it MAY queue more than one.
4. Once there is an active HIP association for the given <source,
destination> HIT pair, the outgoing datagram is passed to
transport handling. The possible transport formats are defined
in separate documents, of which the ESP transport format for HIP
is mandatory for all HIP implementations.
5. Before sending the packet, the HITs in the datagram are replaced
with suitable IP addresses. For IPv6, the rules defined in
[RFC6724] SHOULD be followed. Note that this HIT-to-IP-address
conversion step MAY also be performed at some other point in the
stack, e.g., before wrapping the packet into the output format.
6.2. Processing Incoming Application Data
The following conceptual algorithm describes the incoming datagram
handling when HITs are used at the receiving host as application-
level identifiers. More detailed steps for processing packets are
defined in corresponding transport format documents.
1. The incoming datagram is mapped to an existing HIP association,
typically using some information from the packet. For example,
such mapping may be based on the ESP Security Parameter Index
(SPI).
2. The specific transport format is unwrapped, in a way depending on
the transport format, yielding a packet that looks like a
standard (unencrypted) IP packet. If possible, this step SHOULD
also verify that the packet was indeed (once) sent by the remote
HIP host, as identified by the HIP association.
Depending on the used transport mode, the verification method can
vary. While the HI (as well as the HIT) is used as the higher-
layer identifier, the verification method has to verify that the
data packet was sent by the correct node identity and that the
actual identity maps to this particular HIT. When using the ESP
transport format [RFC7402], the verification is done using the
SPI value in the data packet to find the corresponding SA with
associated HIT and key, and decrypting the packet with that
associated key.
3. The IP addresses in the datagram are replaced with the HITs
associated with the HIP association. Note that this IP-address-
to-HIT conversion step MAY also be performed at some other point
in the stack.
4. The datagram is delivered to the upper layer (e.g., UDP or TCP).
When demultiplexing the datagram, the right upper-layer socket is
selected based on the HITs.
6.3. Solving the Puzzle
This subsection describes the details for solving the puzzle.
In the R1 packet, the values #I and #K are sent in network byte
order. Similarly, in the I2 packet, the values #I and #J are sent in
network byte order. The hash is created by concatenating, in network
byte order, the following data, in the following order and using the
RHASH algorithm:
n-bit random value #I (where n is RHASH_len), in network byte
order, as appearing in the R1 and I2 packets.
128-bit Initiator's HIT, in network byte order, as appearing in
the HIP Payload in the R1 and I2 packets.
128-bit Responder's HIT, in network byte order, as appearing in
the HIP Payload in the R1 and I2 packets.
n-bit random value #J (where n is RHASH_len), in network byte
order, as appearing in the I2 packet.
In a valid response puzzle, the #K low-order bits of the resulting
RHASH digest MUST be zero.
Notes:
i) The length of the data to be hashed is variable, depending on
the output length of the Responder's hash function RHASH.
ii) All the data in the hash input MUST be in network byte order.
iii) The orderings of the Initiator's and Responder's HITs are
different in the R1 and I2 packets; see Section 5.1. Care
must be taken to copy the values in the right order to the
hash input.
iv) For a puzzle #I, there may exist multiple valid puzzle
solutions #J.
The following procedure describes the processing steps involved,
assuming that the Responder chooses to precompute the R1 packets:
Precomputation by the Responder:
Sets up the puzzle difficulty #K.
Creates a signed R1 and caches it.
Responder:
Selects a suitable cached R1.
Generates a random number #I.
Sends #I and #K in an R1.
Saves #I and #K for a delta time.
Initiator:
Generates repeated attempts to solve the puzzle until a matching
#J is found:
Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0
Sends #I and #J in an I2.
Responder:
Verifies that the received #I is a saved one.
Finds the right #K based on #I.
Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K )
Rejects if V != 0
Accepts if V == 0
6.4. HIP_MAC and SIGNATURE Calculation and Verification
The following subsections define the actions for processing HIP_MAC,
HIP_MAC_2, HIP_SIGNATURE, and HIP_SIGNATURE_2 parameters. The
HIP_MAC_2 parameter is contained in the R2 packet. The
HIP_SIGNATURE_2 parameter is contained in the R1 packet. The
HIP_SIGNATURE and HIP_MAC parameters are contained in other HIP
packets.
6.4.1. HMAC Calculation
The HMAC uses RHASH as the underlying hash function. The type of
RHASH depends on the HIT Suite of the Responder. Hence, HMAC-SHA-256
[RFC4868] is used for HIT Suite RSA/DSA/SHA-256, HMAC-SHA-1 [RFC2404]
is used for HIT Suite ECDSA_LOW/SHA-1, and HMAC-SHA-384 [RFC4868] is
used for HIT Suite ECDSA/SHA-384.
The following process applies both to the HIP_MAC and HIP_MAC_2
parameters. When processing HIP_MAC_2, the difference is that the
HIP_MAC calculation includes a pseudo HOST_ID field containing the
Responder's information as sent in the R1 packet earlier.
Both the Initiator and the Responder should take some care when
verifying or calculating the HIP_MAC_2. Specifically, the Initiator
has to preserve the HOST_ID exactly as it was received in the R1
packet until it receives the HIP_MAC_2 in the R2 packet.
The scope of the calculation for HIP_MAC is as follows:
HMAC: { HIP header | [ Parameters ] }
where Parameters include all of the packet's HIP parameters with type
values ranging from 1 to (HIP_MAC's type value - 1), and excluding
those parameters with type values greater than or equal to HIP_MAC's
type value.
During HIP_MAC calculation, the following apply:
o In the HIP header, the Checksum field is set to zero.
o In the HIP header, the Header Length field value is calculated to
the beginning of the HIP_MAC parameter.
Parameter order is described in Section 5.2.1.
The scope of the calculation for HIP_MAC_2 is as follows:
HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID }
where Parameters include all of the packet's HIP parameters with type
values from 1 to (HIP_MAC_2's type value - 1), and excluding those
parameters with type values greater than or equal to HIP_MAC_2's type
value.
During HIP_MAC_2 calculation, the following apply:
o In the HIP header, the Checksum field is set to zero.
o In the HIP header, the Header Length field value is calculated to
the beginning of the HIP_MAC_2 parameter and increased by the
length of the concatenated HOST_ID parameter length (including the
Type and Length fields).
o The HOST_ID parameter is exactly in the form it was received in
the R1 packet from the Responder.
Parameter order is described in Section 5.2.1, except that the
HOST_ID parameter in this calculation is added to the end.
The HIP_MAC parameter is defined in Section 5.2.12 and the HIP_MAC_2 parameter in Section 5.2.13. The HMAC calculation and verification process (the process applies both to HIP_MAC and HIP_MAC_2, except where HIP_MAC_2 is mentioned separately) is as follows: Packet sender: 1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, HIP_SIGNATURE_2, or any other parameter with greater type value than the HIP_MAC parameter has. 2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) parameter to the end of the packet. 3. Calculate the Header Length field in the HIP header, including the added HOST_ID parameter in case of HIP_MAC_2. 4. Compute the HMAC using either the HIP-gl or HIP-lg integrity key retrieved from KEYMAT as defined in Section 6.5. 5. In case of HIP_MAC_2, remove the HOST_ID parameter from the packet. 6. Add the HIP_MAC parameter to the packet and any parameter with greater type value than the HIP_MAC's (HIP_MAC_2's) that may follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 parameters. 7. Recalculate the Length field in the HIP header. Packet receiver: 1. Verify the HIP Header Length field. 2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other parameters that follow it with greater type value including possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the contents if they are needed later. 3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with Responder information) to the packet. The HOST_ID parameter should be identical to the one previously received from the Responder. 4. Recalculate the HIP packet length in the HIP header and clear the Checksum field (set it to all zeros). In case of HIP_MAC_2, the length is calculated with the added HOST_ID parameter.
5. Compute the HMAC using either the HIP-gl or HIP-lg integrity key
as defined in Section 6.5 and verify it against the received
HMAC.
6. Set the Checksum and Header Length fields in the HIP header to
original values. Note that the Checksum and Length fields
contain incorrect values after this step.
7. In case of HIP_MAC_2, remove the HOST_ID parameter from the
packet before further processing.
6.4.2. Signature Calculation
The following process applies both to the HIP_SIGNATURE and
HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2
parameter, the only difference is that instead of the HIP_SIGNATURE
parameter, the HIP_SIGNATURE_2 parameter is used, and the Initiator's
HIT and PUZZLE Opaque and Random #I fields are cleared (set to all
zeros) before computing the signature. The HIP_SIGNATURE parameter
is defined in Section 5.2.14 and the HIP_SIGNATURE_2 parameter in
Section 5.2.15.
The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 is
as follows:
HIP_SIGNATURE: { HIP header | [ Parameters ] }
where Parameters include all of the packet's HIP parameters with type
values from 1 to (HIP_SIGNATURE's type value - 1).
During signature calculation, the following apply:
o In the HIP header, the Checksum field is set to zero.
o In the HIP header, the Header Length field value is calculated to
the beginning of the HIP_SIGNATURE parameter.
Parameter order is described in Section 5.2.1.
HIP_SIGNATURE_2: { HIP header | [ Parameters ] }
where Parameters include all of the packet's HIP parameters with type
values ranging from 1 to (HIP_SIGNATURE_2's type value - 1).
During signature calculation, the following apply:
o In the HIP header, both the Checksum and the Receiver's HIT fields
are set to zero.
o In the HIP header, the Header Length field value is calculated to
the beginning of the HIP_SIGNATURE_2 parameter.
o The PUZZLE parameter's Opaque and Random #I fields are set to
zero.
Parameter order is described in Section 5.2.1.
The signature calculation and verification process (the process
applies both to HIP_SIGNATURE and HIP_SIGNATURE_2, except in the case
where HIP_SIGNATURE_2 is separately mentioned) is as follows:
Packet sender:
1. Create the HIP packet without the HIP_SIGNATURE parameter or any
other parameters that follow the HIP_SIGNATURE parameter.
2. Calculate the Length field and zero the Checksum field in the HIP
header. In case of HIP_SIGNATURE_2, set the Initiator's HIT
field in the HIP header as well as the PUZZLE parameter's Opaque
and Random #I fields to zero.
3. Compute the signature using the private key corresponding to the
Host Identifier (public key).
4. Add the HIP_SIGNATURE parameter to the packet.
5. Add any parameters that follow the HIP_SIGNATURE parameter.
6. Recalculate the Length field in the HIP header, and calculate the
Checksum field.
Packet receiver:
1. Verify the HIP Header Length field and checksum.
2. Save the contents of the HIP_SIGNATURE parameter and any other
parameters following the HIP_SIGNATURE parameter, and remove them
from the packet.
3. Recalculate the HIP packet Length in the HIP header and clear the
Checksum field (set it to all zeros). In case of
HIP_SIGNATURE_2, set the Initiator's HIT field in the HIP header
as well as the PUZZLE parameter's Opaque and Random #I fields
to zero.
4. Compute the signature and verify it against the received
signature using the packet sender's Host Identity (public key).
5. Restore the original packet by adding removed parameters (in
step 2) and resetting the values that were set to zero (in
step 3).
The verification can use either the HI received from a HIP packet;
the HI retrieved from a DNS query, if the FQDN has been received in
the HOST_ID parameter; or an HI received by some other means.
6.5. HIP KEYMAT Generation
HIP keying material is derived from the Diffie-Hellman session key,
Kij, produced during the HIP base exchange (see Section 4.1.3). The
Initiator has Kij during the creation of the I2 packet, and the
Responder has Kij once it receives the I2 packet. This is why I2 can
already contain encrypted information.
The KEYMAT is derived by feeding Kij into the key derivation function
defined by the DH Group ID. Currently, the only key derivation
function defined in this document is the Hash-based Key Derivation
Function (HKDF) [RFC5869] using the RHASH hash function. Other
documents may define new DH Group IDs and corresponding key
distribution functions.
In the following, we provide the details for deriving the keying
material using HKDF.
where
info = sort(HIT-I | HIT-R)
salt = #I | #J
Sort(HIT-I | HIT-R) is defined as the network byte order
concatenation of the two HITs, with the smaller HIT preceding the
larger HIT, resulting from the numeric comparison of the two HITs
interpreted as positive (unsigned) 128-bit integers in network byte
order. The #I and #J values are from the puzzle and its solution
that were exchanged in R1 and I2 messages when this HIP association
was set up. Both hosts have to store #I and #J values for the HIP
association for future use.
The initial keys are drawn sequentially in the order that is
determined by the numeric comparison of the two HITs, with the
comparison method described in the previous paragraph. HOST_g
denotes the host with the greater HIT value, and HOST_l the host with
the lower HIT value.
The drawing order for the four initial keys is as follows:
HIP-gl encryption key for HOST_g's ENCRYPTED parameter
HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets
HIP-lg encryption key for HOST_l's ENCRYPTED parameter
HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets
The number of bits drawn for a given algorithm is the "natural" size
of the keys. For the mandatory algorithms, the following sizes
apply:
AES 128 or 256 bits
SHA-1 160 bits
SHA-256 256 bits
SHA-384 384 bits
NULL 0 bits
If other key sizes are used, they MUST be treated as different
encryption algorithms and defined separately.
6.6. Initiation of a HIP Base Exchange
An implementation may originate a HIP base exchange to another host
based on a local policy decision, usually triggered by an application
datagram, in much the same way that an IPsec IKE key exchange can
dynamically create a Security Association. Alternatively, a system
may initiate a HIP exchange if it has rebooted or timed out, or
otherwise lost its HIP state, as described in Section 4.5.4.
The implementation prepares an I1 packet and sends it to the IP
address that corresponds to the peer host. The IP address of the
peer host may be obtained via conventional mechanisms, such as DNS
lookup. The I1 packet contents are specified in Section 5.3.1. The
selection of which source or destination Host Identity to use, if an
Initiator or Responder has more than one to choose from, is typically
a policy decision.
The following steps define the conceptual processing rules for
initiating a HIP base exchange:
1. The Initiator receives one or more of the Responder's HITs and
one or more addresses from either a DNS lookup of the Responder's
FQDN, some other repository, or a local database. If the
Initiator does not know the Responder's HIT, it may attempt
opportunistic mode by using NULL (all zeros) as the Responder's
HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the
Initiator can choose from multiple Responder HITs, it selects a
HIT for which the Initiator supports the HIT Suite.
2. The Initiator sends an I1 packet to one of the Responder's
addresses. The selection of which address to use is a local
policy decision.
3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The
selection and order of DH Group IDs in the DH_GROUP_LIST MUST be
stored by the Initiator, because this list is needed for later R1
processing. In most cases, the preferences regarding the DH
groups will be static, so no per-association storage is
necessary.
4. Upon sending an I1 packet, the sender transitions to state
I1-SENT and starts a timer for which the timeout value SHOULD be
larger than the worst-case anticipated RTT. The sender SHOULD
also increment the trial counter associated with the I1.
5. Upon timeout, the sender SHOULD retransmit the I1 packet and
restart the timer, up to a maximum of I1_RETRIES_MAX tries.
6.6.1. Sending Multiple I1 Packets in Parallel
For the sake of minimizing the association establishment latency, an
implementation MAY send the same I1 packet to more than one of the
Responder's addresses. However, it MUST NOT send to more than three
(3) Responder addresses in parallel. Furthermore, upon timeout, the
implementation MUST refrain from sending the same I1 packet to
multiple addresses. That is, if it retries to initialize the
connection after a timeout, it MUST NOT send the I1 packet to more
than one destination address. These limitations are placed in order
to avoid congestion of the network, and potential DoS attacks that
might occur, e.g., because someone's claim to have hundreds or thousands of addresses could generate a huge number of I1 packets from the Initiator. As the Responder is not guaranteed to distinguish the duplicate I1 packets it receives at several of its addresses (because it avoids storing states when it answers back an R1 packet), the Initiator may receive several duplicate R1 packets. The Initiator SHOULD then select the initial preferred destination address using the source address of the selected received R1, and use the preferred address as a source address for the I2 packet. Processing rules for received R1s are discussed in Section 6.8.6.6.2. Processing Incoming ICMP Protocol Unreachable Messages
A host may receive an ICMP 'Destination Protocol Unreachable' message as a response to sending a HIP I1 packet. Such a packet may be an indication that the peer does not support HIP, or it may be an attempt to launch an attack by making the Initiator believe that the Responder does not support HIP. When a system receives an ICMP 'Destination Protocol Unreachable' message while it is waiting for an R1 packet, it MUST NOT terminate waiting. It MAY continue as if it had not received the ICMP message, and send a few more I1 packets. Alternatively, it MAY take the ICMP message as a hint that the peer most probably does not support HIP, and return to state UNASSOCIATED earlier than otherwise. However, at minimum, it MUST continue waiting for an R1 packet for a reasonable time before returning to UNASSOCIATED.6.7. Processing of Incoming I1 Packets
An implementation SHOULD reply to an I1 with an R1 packet, unless the implementation is unable or unwilling to set up a HIP association. If the implementation is unable to set up a HIP association, the host SHOULD send an 'ICMP Destination Protocol Unreachable, Administratively Prohibited' message to the I1 packet source IP address. If the implementation is unwilling to set up a HIP association, the host MAY ignore the I1 packet. This latter case may occur during a DoS attack such as an I1 packet flood. The implementation SHOULD be able to handle a storm of received I1 packets, discarding those with common content that arrive within a small time delta.
A spoofed I1 packet can result in an R1 attack on a system. An R1
packet sender MUST have a mechanism to rate-limit R1 packets sent to
an address.
It is RECOMMENDED that the HIP state machine does not transition upon
sending an R1 packet.
The following steps define the conceptual processing rules for
responding to an I1 packet:
1. The Responder MUST check that the Responder's HIT in the received
I1 packet is either one of its own HITs or NULL. Otherwise, it
must drop the packet.
2. If the Responder is in ESTABLISHED state, the Responder MAY
respond to this with an R1 packet, prepare to drop an existing
HIP security association with the peer, and stay at ESTABLISHED
state.
3. If the Responder is in I1-SENT state, it MUST make a comparison
between the sender's HIT and its own (i.e., the receiver's) HIT.
If the sender's HIT is greater than its own HIT, it should drop
the I1 packet and stay at I1-SENT. If the sender's HIT is
smaller than its own HIT, it SHOULD send the R1 packet and stay
at I1-SENT. The HIT comparison is performed as defined in
Section 6.5.
4. If the implementation chooses to respond to the I1 packet with an
R1 packet, it creates a new R1 or selects a precomputed R1
according to the format described in Section 5.3.2. It creates
or chooses an R1 that contains its most preferred DH public value
that is also contained in the DH_GROUP_LIST in the I1 packet. If
no suitable DH Group ID was contained in the DH_GROUP_LIST in the
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
selects a HIT with the same HIT Suite as the Initiator's HIT. If
this HIT Suite is not supported by the Responder, it SHOULD
select a REQUIRED HIT Suite from Section 5.2.10, which is
currently RSA/DSA/SHA-256. Other than that, selecting the HIT is
a local policy matter.
6. The Responder expresses its supported HIP transport formats in
the TRANSPORT_FORMAT_LIST as described in Section 5.2.11. The
Responder MUST provide at least one payload transport format
type.
7. The Responder sends the R1 packet to the source IP address of the
I1 packet.
6.7.1. R1 Management
All compliant implementations MUST be able to produce R1 packets;
even if a device is configured by policy to only initiate
associations, it must be able to process I1s in cases of recovery
from loss of state or key exhaustion. An R1 packet MAY be
precomputed. An R1 packet MAY be reused for a short time period,
denoted here as "Delta T", which is implementation dependent, and
SHOULD be deprecated and not used once a valid response I2 packet has
been received from an Initiator. During an I1 message storm, an R1
packet MAY be reused beyond the normal Delta T. R1 information MUST
NOT be discarded until a time period "Delta S" (again, implementation
dependent) after the R1 packet is no longer being offered. Delta S
is the assumed maximum time needed for the last I2 packet in response
to the R1 packet to arrive back at the Responder.
Implementations that support multiple DH groups MAY precompute R1
packets for each supported group so that incoming I1 packets with
different DH Group IDs in the DH_GROUP_LIST can be served quickly.
An implementation MAY keep state about received I1 packets and match
the received I2 packets against the state, as discussed in
Section 4.1.1.
6.7.2. Handling of Malformed Messages
If an implementation receives a malformed I1 packet, it SHOULD NOT
respond with a NOTIFY message, as such a practice could open up a
potential denial-of-service threat. Instead, it MAY respond with an
ICMP packet, as defined in Section 5.4.
6.8. Processing of Incoming R1 Packets
A system receiving an R1 packet MUST first check to see if it has
sent an I1 packet to the originator of the R1 packet (i.e., it is in
state I1-SENT). If so, it SHOULD process the R1 as described below,
send an I2 packet, and transition to state I2-SENT, setting a timer
to protect the I2 packet. If the system is in state I2-SENT, it MAY
respond to the R1 packet if the R1 packet has a larger R1 generation
counter; if so, it should drop its state due to processing the
previous R1 packet and start over from state I1-SENT. If the system
is in any other state with respect to that host, the system SHOULD
silently drop the R1 packet.
When sending multiple I1 packets, an Initiator SHOULD wait for a
small amount of time after the first R1 reception to allow possibly
multiple R1 packets to arrive, and it SHOULD respond to an R1 packet
among the set with the largest R1 generation counter.
The following steps define the conceptual processing rules for
responding to an R1 packet:
1. A system receiving an R1 MUST first check to see if it has sent
an I1 packet to the originator of the R1 packet (i.e., it has a
HIP association that is in state I1-SENT and that is associated
with the HITs in the R1). Unless the I1 packet was sent in
opportunistic mode (see Section 4.1.8), the IP addresses in the
received R1 packet SHOULD be ignored by the R1 processing and,
when looking up the right HIP association, the received R1
packet SHOULD be matched against the associations using only the
HITs. If a match exists, the system should process the R1
packet as described below.
2. Otherwise, if the system is in any state other than I1-SENT or
I2-SENT with respect to the HITs included in the R1 packet, it
SHOULD silently drop the R1 packet and remain in the current
state.
3. If the HIP association state is I1-SENT or I2-SENT, the received
Initiator's HIT MUST correspond to the HIT used in the original
I1. Also, the Responder's HIT MUST correspond to the one used
in the I1, unless the I1 packet contained a NULL HIT.
4. The system SHOULD validate the R1 signature before applying
further packet processing, according to Section 5.2.15.
5. If the HIP association state is I1-SENT, and multiple valid R1
packets are present, the system MUST select from among the R1
packets with the largest R1 generation counter.
6. The system MUST check that the Initiator's HIT Suite is
contained in the HIT_SUITE_LIST parameter in the R1 packet
(i.e., the Initiator's HIT Suite is supported by the Responder).
If the HIT Suite is supported by the Responder, the system
proceeds normally. Otherwise, the system MAY stay in state
I1-SENT and restart the BEX by sending a new I1 packet with an
Initiator HIT that is supported by the Responder and hence is
contained in the HIT_SUITE_LIST in the R1 packet. The system
MAY abort the BEX if no suitable source HIT is available. The
system SHOULD wait for an acceptable time span to allow further
R1 packets with higher R1 generation counters or different HIT
and HIT Suites to arrive before restarting or aborting the BEX.
7. The system MUST check that the DH Group ID in the DIFFIE_HELLMAN
parameter in the R1 matches the first DH Group ID in the
Responder's DH_GROUP_LIST in the R1 packet, and also that this
Group ID corresponds to a value that was included in the
Initiator's DH_GROUP_LIST in the I1 packet. If the DH Group ID
of the DIFFIE_HELLMAN parameter does not express the Responder's
best choice, the Initiator can conclude that the DH_GROUP_LIST
in the I1 packet was adversely modified. In such a case, the
Initiator MAY send a new I1 packet; however, it SHOULD NOT
change its preference in the DH_GROUP_LIST in the new I1 packet.
Alternatively, the Initiator MAY abort the HIP base exchange.
8. If the HIP association state is I2-SENT, the system MAY re-enter
state I1-SENT and process the received R1 packet if it has a
larger R1 generation counter than the R1 packet responded to
previously.
9. The R1 packet may have the A-bit set -- in this case, the system
MAY choose to refuse it by dropping the R1 packet and returning
to state UNASSOCIATED. The system SHOULD consider dropping the
R1 packet only if it used a NULL HIT in the I1 packet. If the
A-bit is set, the Responder's HIT is anonymous and SHOULD NOT be
stored permanently.
10. The system SHOULD attempt to validate the HIT against the
received Host Identity by using the received Host Identity to
construct a HIT and verify that it matches the Sender's HIT.
11. The system MUST store the received R1 generation counter for
future reference.
12. The system attempts to solve the puzzle in the R1 packet. The
system MUST terminate the search after exceeding the remaining
lifetime of the puzzle. If the puzzle is not successfully
solved, the implementation MAY either resend the I1 packet
within the retry bounds or abandon the HIP base exchange.
13. The system computes standard Diffie-Hellman keying material
according to the public value and Group ID provided in the
DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material
Kij is used for key extraction as specified in Section 6.5.
14. The system selects the HIP_CIPHER ID from the choices presented
in the R1 packet and uses the selected values subsequently when
generating and using encryption keys, and when sending the I2
packet. If the proposed alternatives are not acceptable to the
system, it may either resend an I1 within the retry bounds or
abandon the HIP base exchange.
15. The system chooses one suitable transport format from the
TRANSPORT_FORMAT_LIST and includes the respective transport
format parameter in the subsequent I2 packet.
16. The system initializes the remaining variables in the associated
state, including Update ID counters.
17. The system prepares and sends an I2 packet, as described in
Section 5.3.3.
18. The system SHOULD start a timer whose timeout value SHOULD be
larger than the worst-case anticipated RTT, and MUST increment a
trial counter associated with the I2 packet. The sender SHOULD
retransmit the I2 packet upon a timeout and restart the timer,
up to a maximum of I2_RETRIES_MAX tries.
19. If the system is in state I1-SENT, it SHALL transition to state
I2-SENT. If the system is in any other state, it remains in the
current state.
6.8.1. Handling of Malformed Messages
If an implementation receives a malformed R1 message, it MUST
silently drop the packet. Sending a NOTIFY or ICMP would not help,
as the sender of the R1 packet typically doesn't have any state. An
implementation SHOULD wait for some more time for a possibly well-
formed R1, after which it MAY try again by sending a new I1 packet.
6.9. Processing of Incoming I2 Packets
Upon receipt of an I2 packet, the system MAY perform initial checks
to determine whether the I2 packet corresponds to a recent R1 packet
that has been sent out, if the Responder keeps such state. For
example, the sender could check whether the I2 packet is from an
address or HIT for which the Responder has recently received an I1.
The R1 packet may have had opaque data included that was echoed back
in the I2 packet. If the I2 packet is considered to be suspect, it
MAY be silently discarded by the system.
Otherwise, the HIP implementation SHOULD process the I2 packet. This
includes validation of the puzzle solution, generating the
Diffie-Hellman key, possibly decrypting the Initiator's Host
Identity, verifying the signature, creating state, and finally
sending an R2 packet.
The following steps define the conceptual processing rules for
responding to an I2 packet:
1. The system MAY perform checks to verify that the I2 packet
corresponds to a recently sent R1 packet. Such checks are
implementation dependent. See Appendix A for a description of
an example implementation.
2. The system MUST check that the Responder's HIT corresponds to
one of its own HITs and MUST drop the packet otherwise.
3. The system MUST further check that the Initiator's HIT Suite is
supported. The Responder SHOULD silently drop I2 packets with
unsupported Initiator HITs.
4. If the system's state machine is in the R2-SENT state, the
system MAY check to see if the newly received I2 packet is
similar to the one that triggered moving to R2-SENT. If so, it
MAY retransmit a previously sent R2 packet and reset the R2-SENT
timer, and the state machine stays in R2-SENT.
5. If the system's state machine is in the I2-SENT state, the
system MUST make a comparison between its local and sender's
HITs (similar to the comparison method described in
Section 6.5). If the local HIT is smaller than the sender's
HIT, it should drop the I2 packet, use the peer Diffie-Hellman
key and nonce #I from the R1 packet received earlier, and get
the local Diffie-Hellman key and nonce #J from the I2 packet
sent to the peer earlier. Otherwise, the system should process
the received I2 packet and drop any previously derived
Diffie-Hellman keying material Kij it might have formed upon
sending the I2 packet previously. The peer Diffie-Hellman key
and the nonce #J are taken from the I2 packet that just arrived.
The local Diffie-Hellman key and the nonce #I are the ones that
were sent earlier in the R1 packet.
6. If the system's state machine is in the I1-SENT state, and the
HITs in the I2 packet match those used in the previously sent I1
packet, the system uses this received I2 packet as the basis for
the HIP association it was trying to form, and stops
retransmitting I1 packets (provided that the I2 packet passes
the additional checks below).
7. If the system's state machine is in any state other than
R2-SENT, the system SHOULD check that the echoed R1 generation
counter in the I2 packet is within the acceptable range if the
counter is included. Implementations MUST accept puzzles from
the current generation and MAY accept puzzles from earlier
generations. If the generation counter in the newly received I2
packet is outside the accepted range, the I2 packet is stale
(and perhaps replayed) and SHOULD be dropped.
8. The system MUST validate the solution to the puzzle by computing
the hash described in Section 5.3.3 using the same RHASH
algorithm.
9. The I2 packet MUST have a single value in the HIP_CIPHER
parameter, which MUST match one of the values offered to the
Initiator in the R1 packet.
10. The system must derive Diffie-Hellman keying material Kij based
on the public value and Group ID in the DIFFIE_HELLMAN
parameter. This key is used to derive the HIP association keys,
as described in Section 6.5. If the Diffie-Hellman Group ID is
unsupported, the I2 packet is silently dropped.
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
HOST_ID parameter, the I2 packet is silently dropped.
12. The implementation SHOULD also verify that the Initiator's HIT
in the I2 packet corresponds to the Host Identity sent in the I2
packet. (Note: some middleboxes may not be able to make this
verification.)
13. The system MUST process the TRANSPORT_FORMAT_LIST parameter.
Other documents specifying transport formats (e.g., [RFC7402])
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.
15. The system MUST verify the HIP_SIGNATURE according to
Sections 5.2.14 and 5.3.3.
16. If the checks above are valid, then the system proceeds with
further I2 processing; otherwise, it discards the I2 and its
state machine remains in the same state.
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
returns to state UNASSOCIATED. If the A-bit is set, the
Initiator's HIT is anonymous and should not be stored
permanently.
18. The system initializes the remaining variables in the associated
state, including Update ID counters.
19. Upon successful processing of an I2 message when the system's
state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or
R2-SENT, an R2 packet is sent and the system's state machine
transitions to state R2-SENT.
20. Upon successful processing of an I2 packet when the system's
state machine is in state ESTABLISHED, the old HIP association
is dropped and a new one is installed, an R2 packet is sent, and
the system's state machine transitions to R2-SENT.
21. Upon the system's state machine transitioning to R2-SENT, the
system starts a timer. The state machine transitions to
ESTABLISHED if some data has been received on the incoming HIP
association, or an UPDATE packet has been received (or some
other packet that indicates that the peer system's state machine
has moved to ESTABLISHED). If the timer expires (allowing for a
maximal amount of retransmissions of I2 packets), the state
machine transitions to ESTABLISHED.
6.9.1. Handling of Malformed Messages
If an implementation receives a malformed I2 message, the behavior
SHOULD depend on how many checks the message has already passed. If
the puzzle solution in the message has already been checked, the
implementation SHOULD report the error by responding with a NOTIFY
packet. Otherwise, the implementation MAY respond with an ICMP
message as defined in Section 5.4.
6.10. Processing of Incoming R2 Packets
An R2 packet received in state UNASSOCIATED, I1-SENT, or ESTABLISHED results in the R2 packet being dropped and the state machine staying in the same state. If an R2 packet is received in state I2-SENT, it MUST be processed. The following steps define the conceptual processing rules for an incoming R2 packet: 1. If the system is in any state other than I2-SENT, the R2 packet is silently dropped. 2. The system MUST verify that the HITs in use correspond to the HITs that were received in the R1 packet that caused the transition to the I1-SENT state. 3. The system MUST verify the HIP_MAC_2 according to the procedures in Section 5.2.13. 4. The system MUST verify the HIP signature according to the procedures in Section 5.2.14. 5. If any of the checks above fail, there is a high probability of an ongoing man-in-the-middle or other security attack. The system SHOULD act accordingly, based on its local policy. 6. Upon successful processing of the R2 packet, the state machine transitions to state ESTABLISHED.6.11. Sending UPDATE Packets
A host sends an UPDATE packet when it intends to update some information related to a HIP association. There are a number of possible scenarios when this can occur, e.g., mobility management and rekeying of an existing ESP Security Association. The following paragraphs define the conceptual rules for sending an UPDATE packet to the peer. Additional steps can be defined in other documents where the UPDATE packet is used. The sequence of UPDATE messages is indicated by their SEQ parameter. Before sending an UPDATE message, the system first determines whether there are any outstanding UPDATE messages that may conflict with the new UPDATE message under consideration. When multiple UPDATEs are outstanding (not yet acknowledged), the sender must assume that such UPDATEs may be processed in an arbitrary order by the receiver. Therefore, any new UPDATEs that depend on a previous outstanding UPDATE being successfully received and acknowledged MUST be postponed
until reception of the necessary ACK(s) occurs. One way to prevent
any conflicts is to only allow one outstanding UPDATE at a time.
However, allowing multiple UPDATEs may improve the performance of
mobility and multihoming protocols.
The following steps define the conceptual processing rules for
sending UPDATE packets:
1. The first UPDATE packet is sent with an Update ID of zero.
Otherwise, the system increments its own Update ID value by one
before continuing the steps below.
2. The system creates an UPDATE packet that contains a SEQ parameter
with the current value of the Update ID. The UPDATE packet MAY
also include zero or more ACKs of the peer's Update ID(s) from
previously received UPDATE SEQ parameter(s).
3. The system sends the created UPDATE packet and starts an UPDATE
timer. The default value for the timer is 2 * RTT estimate. If
multiple UPDATEs are outstanding, multiple timers are in effect.
4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE
can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be
exponentially backed off for subsequent retransmissions. If no
acknowledgment is received from the peer after UPDATE_RETRY_MAX
times, the HIP association is considered to be broken and the
state machine SHOULD move from state ESTABLISHED to state CLOSING
as depicted in Section 4.4.4. The UPDATE timer is cancelled upon
receiving an ACK from the peer that acknowledges receipt of the
UPDATE.
6.12. Receiving UPDATE Packets
When a system receives an UPDATE packet, its processing depends on
the state of the HIP association and the presence and values of the
SEQ and ACK parameters. Typically, an UPDATE message also carries
optional parameters whose handling is defined in separate documents.
For each association, a host stores the peer's next expected
in-sequence Update ID ("peer Update ID"). Initially, this value is
zero. Update ID comparisons of "less than" and "greater than" are
performed with respect to a circular sequence number space. Hence, a
wraparound after 2^32 updates has to be expected and MUST be handled
accordingly.
The sender MAY send multiple outstanding UPDATE messages. These
messages are processed in the order in which they are received at the
receiver (i.e., no resequencing is performed). When processing
UPDATEs out of order, the receiver MUST keep track of which UPDATEs
were previously processed, so that duplicates or retransmissions are
ACKed and not reprocessed. A receiver MAY choose to define a receive
window of Update IDs that it is willing to process at any given time,
and discard received UPDATEs falling outside of that window.
The following steps define the conceptual processing rules for
receiving UPDATE packets:
1. If there is no corresponding HIP association, the implementation
MAY reply with an ICMP Parameter Problem, as specified in
Section 5.4.4.
2. If the association is in the ESTABLISHED state and the SEQ (but
not ACK) parameter is present, the UPDATE is processed and
replied to as described in Section 6.12.1.
3. If the association is in the ESTABLISHED state and the ACK (but
not SEQ) parameter is present, the UPDATE is processed as
described in Section 6.12.2.
4. If the association is in the ESTABLISHED state and there are both
an ACK and SEQ in the UPDATE, the ACK is first processed as
described in Section 6.12.2, and then the rest of the UPDATE is
processed as described in Section 6.12.1.
6.12.1. Handling a SEQ Parameter in a Received UPDATE Message
The following steps define the conceptual processing rules for
handling a SEQ parameter in a received UPDATE packet:
1. If the Update ID in the received SEQ is not the next in the
sequence of Update IDs and is greater than the receiver's window
for new UPDATEs, the packet MUST be dropped.
2. If the Update ID in the received SEQ corresponds to an UPDATE
that has recently been processed, the packet is treated as a
retransmission. The HIP_MAC verification (next step) MUST NOT be
skipped. (A byte-by-byte comparison of the received packet and a
stored packet would be acceptable, though.) It is recommended
that a host caches UPDATE packets sent with ACKs to avoid the
cost of generating a new ACK packet to respond to a replayed
UPDATE. The system MUST acknowledge, again, such (apparent)
UPDATE message retransmissions but SHOULD also consider rate-
limiting such retransmission responses to guard against replay
attacks.
3. The system MUST verify the HIP_MAC in the UPDATE packet. If the
verification fails, the packet MUST be dropped.
4. The system MAY verify the SIGNATURE in the UPDATE packet. If the
verification fails, the packet SHOULD be dropped and an error
message logged.
5. If a new SEQ parameter is being processed, the parameters in the
UPDATE are then processed. The system MUST record the Update ID
in the received SEQ parameter, for replay protection.
6. An UPDATE acknowledgment packet with the ACK parameter is
prepared and sent to the peer. This ACK parameter MAY be
included in a separate UPDATE or piggybacked in an UPDATE with
the SEQ parameter, as described in Section 5.3.5. The ACK
parameter MAY acknowledge more than one of the peer's Update IDs.
6.12.2. Handling an ACK Parameter in a Received UPDATE Packet
The following steps define the conceptual processing rules for
handling an ACK parameter in a received UPDATE packet:
1. The sequence number reported in the ACK must match with an UPDATE
packet sent earlier that has not already been acknowledged. If
no match is found or if the ACK does not acknowledge a new
UPDATE, then either the packet MUST be dropped if no SEQ
parameter is present, or the processing steps in Section 6.12.1
are followed.
2. The system MUST verify the HIP_MAC in the UPDATE packet. If the
verification fails, the packet MUST be dropped.
3. The system MAY verify the SIGNATURE in the UPDATE packet. If the
verification fails, the packet SHOULD be dropped and an error
message logged.
4. The corresponding UPDATE timer is stopped (see Section 6.11) so
that the now-acknowledged UPDATE is no longer retransmitted. If
multiple UPDATEs are acknowledged, multiple timers are stopped.
6.13. Processing of NOTIFY Packets
Processing of NOTIFY packets is OPTIONAL. If processed, any errors
in a received NOTIFICATION parameter SHOULD be logged. Received
errors MUST be considered only as informational, and the receiver
SHOULD NOT change its HIP state (see Section 4.4.2) purely based on
the received NOTIFY message.
6.14. Processing of CLOSE Packets
When the host receives a CLOSE message, it responds with a CLOSE_ACK message and moves to the CLOSED state. (The authenticity of the CLOSE message is verified using both HIP_MAC and SIGNATURE.) This processing applies whether or not the HIP association state is CLOSING, in order to handle simultaneous CLOSE messages from both ends that cross in flight. The HIP association is not discarded before the host moves to the UNASSOCIATED state. Once the closing process has started, any new need to send data packets triggers the creation and establishment of a new HIP association, starting with sending an I1 packet. If there is no corresponding HIP association, the CLOSE packet is dropped.6.15. Processing of CLOSE_ACK Packets
When a host receives a CLOSE_ACK message, it verifies that it is in the CLOSING or CLOSED state and that the CLOSE_ACK was in response to the CLOSE. A host can map CLOSE_ACK messages to CLOSE messages by comparing the value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to the value of ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet). The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for verification. The state is discarded when the state changes to UNASSOCIATED and, after that, the host MAY respond with an ICMP Parameter Problem to an incoming CLOSE message (see Section 5.4.4).6.16. Handling State Loss
In the case of a system crash and unanticipated state loss, the system SHOULD delete the corresponding HIP state, including the keying material. That is, the state SHOULD NOT be stored in long-term storage. If the implementation does drop the state (as RECOMMENDED), it MUST also drop the peer's R1 generation counter value, unless a local policy explicitly defines that the value of that particular host is stored. An implementation MUST NOT store a peer's R1 generation counters by default, but storing R1 generation counter values, if done, MUST be configured by explicit HITs.
(next page on part 5)