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 == 06.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.