Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7401

Host Identity Protocol Version 2 (HIPv2)

Pages: 128
Proposed Standard
Errata
Obsoletes:  5201
Updated by:  80029374
Part 4 of 5 – Pages 70 to 105
First   Prev   Next

Top   ToC   RFC7401 - Page 70   prevText

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.
Top   ToC   RFC7401 - Page 71
   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.
Top   ToC   RFC7401 - Page 72

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
Top   ToC   RFC7401 - Page 73
   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.
Top   ToC   RFC7401 - Page 74
   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.
Top   ToC   RFC7401 - Page 75

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.
Top   ToC   RFC7401 - Page 76
   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.
Top   ToC   RFC7401 - Page 77

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.
Top   ToC   RFC7401 - Page 78
   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
Top   ToC   RFC7401 - Page 79
   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.
Top   ToC   RFC7401 - Page 80

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
Top   ToC   RFC7401 - Page 81
   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.
Top   ToC   RFC7401 - Page 82
   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.
Top   ToC   RFC7401 - Page 83
   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.
Top   ToC   RFC7401 - Page 84
   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.
Top   ToC   RFC7401 - Page 85
   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.
Top   ToC   RFC7401 - Page 86
   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.
Top   ToC   RFC7401 - Page 87
   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).
Top   ToC   RFC7401 - Page 88
   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.
Top   ToC   RFC7401 - Page 89
   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.
Top   ToC   RFC7401 - Page 90
   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
Top   ToC   RFC7401 - Page 91
   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
Top   ToC   RFC7401 - Page 92
   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.
Top   ToC   RFC7401 - Page 93
   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.
Top   ToC   RFC7401 - Page 94
   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
Top   ToC   RFC7401 - Page 95
   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
Top   ToC   RFC7401 - Page 96
        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.
Top   ToC   RFC7401 - Page 97
   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.
Top   ToC   RFC7401 - Page 98
   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).
Top   ToC   RFC7401 - Page 99
   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.
Top   ToC   RFC7401 - Page 100
   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.
Top   ToC   RFC7401 - Page 101

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
Top   ToC   RFC7401 - Page 102
   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
Top   ToC   RFC7401 - Page 103
   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.
Top   ToC   RFC7401 - Page 104
   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.
Top   ToC   RFC7401 - Page 105

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)

Next Section