tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7401

 
 
 

Host Identity Protocol Version 2 (HIPv2)

Part 5 of 5, p. 106 to 128
Prev RFC Part

 


prevText      Top      Up      ToC       Page 106 
7.  HIP Policies

   There are a number of variables that will influence the HIP base
   exchanges that each host must support.  All HIP implementations MUST
   support more than one simultaneous HI, at least one of which SHOULD
   be reserved for anonymous usage.  Although anonymous HIs will be
   rarely used as Responders' HIs, they will be common for Initiators.
   Support for more than two HIs is RECOMMENDED.

   Initiators MAY use a different HI for different Responders to provide
   basic privacy.  Whether such private HIs are used repeatedly with the
   same Responder, and how long these HIs are used, are decided by local
   policy and depend on the privacy requirements of the Initiator.

   The value of #K used in the HIP R1 must be chosen with care.  Values
   of #K that are too high will exclude clients with weak CPUs because
   these devices cannot solve the puzzle within a reasonable amount of
   time.  #K should only be raised if a Responder is under high load,
   i.e., it cannot process all incoming HIP handshakes any more.  If a
   Responder is not under high load, #K SHOULD be 0.

   Responders that only respond to selected Initiators require an Access
   Control List (ACL), representing for which hosts they accept HIP base
   exchanges, and the preferred transport format and local lifetimes.
   Wildcarding SHOULD be supported for such ACLs, and also for
   Responders that offer public or anonymous services.

8.  Security Considerations

   HIP is designed to provide secure authentication of hosts.  HIP also
   attempts to limit the exposure of the host to various denial-of-
   service and man-in-the-middle (MitM) attacks.  In doing so, HIP
   itself is subject to its own DoS and MitM attacks that potentially
   could be more damaging to a host's ability to conduct business as
   usual.

   Denial-of-service attacks often take advantage of asymmetries in the
   cost of starting an association.  One example of such asymmetry is
   the need of a Responder to store local state while a malicious
   Initiator can stay stateless.  HIP makes no attempt to increase the
   cost of the start of state at the Initiator, but makes an effort to
   reduce the cost for the Responder.  This is accomplished by having
   the Responder start the 3-way exchange instead of the Initiator,
   making the HIP exchange 4 packets long.  In doing this, the first
   packet from the Responder, R1, becomes a 'stock' packet that the
   Responder MAY use many times, until some Initiator has provided a
   valid response to such an R1 packet.  During an I1 packet storm, the
   host may reuse the same DH value also, even if some Initiator has

Top      Up      ToC       Page 107 
   provided a valid response using that particular DH value.  However,
   such behavior is discouraged and should be avoided.  Using the same
   Diffie-Hellman values and random puzzle #I value has some risks.
   This risk needs to be balanced against a potential storm of HIP I1
   packets.

   This shifting of the start of state cost to the Initiator in creating
   the I2 HIP packet presents another DoS attack.  The attacker can
   spoof the I1 packet, and the Responder sends out the R1 HIP packet.
   This could conceivably tie up the 'Initiator' with evaluating the R1
   HIP packet, and creating the I2 packet.  The defense against this
   attack is to simply ignore any R1 packet where a corresponding I1
   packet was not sent (as defined in Section 6.8, step 1).

   The R1 packet is considerably larger than the I1 packet.  This
   asymmetry can be exploited in a reflection attack.  A malicious
   attacker could spoof the IP address of a victim and send a flood of
   I1 messages to a powerful Responder.  For each small I1 packet, the
   Responder would send a larger R1 packet to the victim.  The
   difference in packet sizes can further amplify a flooding attack
   against the victim.  To avoid such reflection attacks, the Responder
   SHOULD rate-limit the sending of R1 packets in general or SHOULD
   rate-limit the sending of R1 packets to a specific IP address.

   Floods of forged I2 packets form a second kind of DoS attack.  Once
   the attacking Initiator has solved the puzzle, it can send packets
   with spoofed IP source addresses with either an invalid HIP signature
   or invalid encrypted HIP payload (in the ENCRYPTED parameter).  This
   would take resources in the Responder's part to reach the point to
   discover that the I2 packet cannot be completely processed.  The
   defense against this attack is that after N bad I2 packets with the
   same puzzle solution, the Responder would discard any I2 packets that
   contain the given solution.  This will shut down the attack.  The
   attacker would have to request another R1 packet and use that to
   launch a new attack.  The Responder could increase the value of #K
   while under attack.  Keeping a list of solutions from malformed
   packets requires that the Responder keeps state for these malformed
   I2 packets.  This state has to be kept until the R1 counter is
   increased.  As malformed packets are generally filtered by their
   checksum before signature verification, only solutions in packets
   that are forged to pass the checksum and puzzle are put into the
   blacklist.  In addition, a valid puzzle is required before a new list
   entry is created.  Hence, attackers that intend to flood the
   blacklist must solve puzzles first.

Top      Up      ToC       Page 108 
   A third form of DoS attack is emulating the restart of state after a
   reboot of one of the peers.  A restarting host would send an I1
   packet to the peers, which would respond with an R1 packet even if it
   were in the ESTABLISHED state.  If the I1 packet were spoofed, the
   resulting R1 packet would be received unexpectedly by the spoofed
   host and would be dropped, as in the first case above.

   A fourth form of DoS attack is emulating the closing of the HIP
   association.  HIP relies on timers and a CLOSE/CLOSE_ACK handshake to
   explicitly signal the end of a HIP association.  Because both CLOSE
   and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a
   connection.  The presence of an additional SIGNATURE allows
   middleboxes to inspect these messages and discard the associated
   state (e.g., for firewalling, SPI-based NATing, etc.).  However, the
   optional behavior of replying to CLOSE with an ICMP Parameter Problem
   packet (as described in Section 5.4.4) might allow an attacker
   spoofing the source IP address to send CLOSE messages to launch
   reflection attacks.

   A fifth form of DoS attack is replaying R1s to cause the Initiator to
   solve stale puzzles and become out of synchronization with the
   Responder.  The R1 generation counter is a monotonically increasing
   counter designed to protect against this attack, as described in
   Section 4.1.4.

   Man-in-the-middle attacks are difficult to defend against, without
   third-party authentication.  A skillful MitM could easily handle all
   parts of HIP, but HIP indirectly provides the following protection
   from a MitM attack.  If the Responder's HI is retrieved from a signed
   DNS zone, a certificate, or through some other secure means, the
   Initiator can use this to validate the R1 HIP packet.

   Likewise, if the Initiator's HI is in a secure DNS zone, a trusted
   certificate, or otherwise securely available, the Responder can
   retrieve the HI (after having got the I2 HIP packet) and verify that
   the HI indeed can be trusted.

   The HIP "opportunistic mode" concept has been introduced in this
   document, but this document does not specify what the semantics of
   such a connection setup are for applications.  There are certain
   concerns with opportunistic mode, as discussed in Section 4.1.8.

   NOTIFY messages are used only for informational purposes, and they
   are unacknowledged.  A HIP implementation cannot rely solely on the
   information received in a NOTIFY message because the packet may have
   been replayed.  An implementation SHOULD NOT change any state
   information purely based on a received NOTIFY message.

Top      Up      ToC       Page 109 
   Since not all hosts will ever support HIP, ICMP 'Destination Protocol
   Unreachable' messages are to be expected and may be used for a DoS
   attack.  Against an Initiator, the attack would look like the
   Responder does not support HIP, but shortly after receiving the ICMP
   message, the Initiator would receive a valid R1 HIP packet.  Thus, to
   protect against this attack, an Initiator SHOULD NOT react to an ICMP
   message until a reasonable delta time to get the real Responder's R1
   HIP packet.  A similar attack against the Responder is more involved.
   Normally, if an I1 message received by a Responder was a bogus one
   sent by an attacker, the Responder may receive an ICMP message from
   the IP address the R1 message was sent to.  However, a sophisticated
   attacker can try to take advantage of such behavior and try to break
   up the HIP base exchange by sending such an ICMP message to the
   Responder before the Initiator has a chance to send a valid I2
   message.  Hence, the Responder SHOULD NOT act on such an ICMP
   message.  Especially, it SHOULD NOT remove any minimal state created
   when it sent the R1 HIP packet (if it did create one), but wait for
   either a valid I2 HIP packet or the natural timeout (that is, if R1
   packets are tracked at all).  Likewise, the Initiator SHOULD ignore
   any ICMP message while waiting for an R2 HIP packet, and SHOULD
   delete any pending state only after a natural timeout.

9.  IANA Considerations

   IANA has reserved protocol number 139 for the Host Identity Protocol
   and included it in the "IPv6 Extension Header Types" registry
   [RFC7045] and the "Assigned Internet Protocol Numbers" registry.  The
   reference in both of these registries has been updated from [RFC5201]
   to this specification.

   The reference to the 128-bit value under the CGA Message Type
   namespace [RFC3972] of "0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA"
   has been changed from [RFC5201] to this specification.

   The following changes to the "Host Identity Protocol (HIP)
   Parameters" have been made.  In many cases, the changes involved
   updating the reference from [RFC5201] to this specification, but
   there are some differences as outlined below.  Allocation terminology
   is defined in [RFC5226]; any existing references to "IETF Consensus"
   can be replaced with "IETF Review" as per [RFC5226].

Top      Up      ToC       Page 110 
   HIP Version

      This document adds the value "2" to the existing registry.  The
      value of "1" has been left with a reference to [RFC5201].

   Packet Type

      The 7-bit Packet Type field in a HIP protocol packet describes the
      type of a HIP protocol message.  It is defined in Section 5.1.
      All existing values referring to [RFC5201] have been updated to
      refer to this specification.  Other values have been left
      unchanged.

   HIT Suite ID

      This specification creates a new registry for "HIT Suite ID".
      This is different than the existing registry for "Suite ID", which
      can be left unmodified for version 1 of the protocol ([RFC5201]).
      The registry has been closed to new registrations.

      The four-bit HIT Suite ID uses the OGA ID field in the ORCHID to
      express the type of the HIT.  This document defines three HIT
      Suites (see Section 5.2.10).

      The HIT Suite ID is also carried in the four higher-order bits of
      the ID field in the HIT_SUITE_LIST parameter.  The four
      lower-order bits are reserved for future extensions of the HIT
      Suite ID space beyond 16 values.

      For the time being, the HIT Suite uses only four bits because
      these bits have to be carried in the HIT.  Using more bits for the
      HIT Suite ID reduces the cryptographic strength of the HIT.  HIT
      Suite IDs must be allocated carefully to avoid namespace
      exhaustion.  Moreover, deprecated IDs should be reused after an
      appropriate time span.  If 15 Suite IDs (the zero value is
      initially reserved) prove to be insufficient and more HIT Suite
      IDs are needed concurrently, more bits can be used for the HIT
      Suite ID by using one HIT Suite ID (0) to indicate that more bits
      should be used.  The HIT_SUITE_LIST parameter already supports
      8-bit HIT Suite IDs, should longer IDs be needed.  However,
      RFC 7343 [RFC7343] does not presently support such an extension.
      We suggest trying the rollover approach described in Appendix E
      first.  Possible extensions of the HIT Suite ID space to
      accommodate eight bits and new HIT Suite IDs are defined through
      IETF Review.

Top      Up      ToC       Page 111 
      Requests to register reused values should include a note that the
      value is being reused after a deprecation period, to ensure
      appropriate IETF review and approval.

   Parameter Type

      The 16-bit Type field in a HIP parameter describes the type of the
      parameter.  It is defined in Section 5.2.1.  The current values
      are defined in Sections 5.2.3 through 5.2.23.  The existing
      "Parameter Types" registry has been updated as follows.

      A new value (129) for R1_COUNTER has been introduced, with a
      reference to this specification, and the existing value (128) for
      R1_COUNTER has been left in place with a reference to [RFC5201].
      This documents the change in value that has occurred in version 2
      of this protocol.  For clarity, the name for the value 128 has
      been changed from "R1_COUNTER" to "R1_Counter (v1 only)".

      A new value (579) for a new Parameter Type HIP_CIPHER has been
      added, with reference to this specification.  This Parameter Type
      functionally replaces the HIP_TRANSFORM Parameter Type
      (value 577), which has been left in the table with the existing
      reference to [RFC5201].  For clarity, the name for the
      value 577 has been changed from "HIP_TRANSFORM" to
      "HIP_TRANSFORM (v1 only)".

      A new value (715) for a new Parameter Type HIT_SUITE_LIST has been
      added, with reference to this specification.

      A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST
      has been added, with reference to this specification.

      The name of the HMAC Parameter Type (value 61505) has been changed
      to HIP_MAC.  The name of the HMAC_2 Parameter Type (value 61569)
      has been changed to HIP_MAC_2.  The reference has been changed to
      this specification.

      All other Parameter Types that reference [RFC5201] have been
      updated to refer to this specification, and Parameter Types that
      reference other RFCs are unchanged.

      The Type codes 32768 through 49151 (not 49141: a value corrected
      from a previous version of this table) have been Reserved for
      Private Use.  Implementors SHOULD select types in a random fashion
      from this range, thereby reducing the probability of collisions.
      A method employing genuine randomness (such as flipping a coin)
      SHOULD be used.

Top      Up      ToC       Page 112 
      Where the existing ranges once stated "First Come First Served
      with Specification Required", this has been changed to
      "Specification Required".

   Group ID

      The eight-bit Group ID values appear in the DIFFIE_HELLMAN
      parameter and the DH_GROUP_LIST parameter and are defined in
      Section 5.2.7.  This registry has been updated based on the new
      values specified in Section 5.2.7; values noted as being
      DEPRECATED can be left in the table with reference to [RFC5201].
      New values are assigned through IETF Review.

   HIP Cipher ID

      The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined
      in Section 5.2.8.  This is a new registry.  New values from either
      the reserved or unassigned space are assigned through IETF Review.

   DI-Type

      The four-bit DI-Type values in a HOST_ID parameter are defined in
      Section 5.2.9.  New values are assigned through IETF Review.  All
      existing values referring to [RFC5201] have been updated to refer
      to this specification.

   HI Algorithm

      The 16-bit Algorithm values in a HOST_ID parameter are defined in
      Section 5.2.9.  This is a new registry.  New values from either
      the reserved or unassigned space are assigned through IETF Review.

   ECC Curve Label

      When the HI Algorithm values in a HOST_ID parameter are defined to
      the values of either "ECDSA" or "ECDSA_LOW", a new registry is
      needed to maintain the values for the ECC Curve Label as defined
      in Section 5.2.9.  This might be handled by specifying two
      algorithm-specific subregistries named "ECDSA Curve Label" and
      "ECDSA_LOW Curve Label".  New values are to be assigned through
      IETF Review.

Top      Up      ToC       Page 113 
   Notify Message Type

      The 16-bit Notify Message Type values in a NOTIFICATION parameter
      are defined in Section 5.2.19.

      Notify Message Type values 1-10 are used for informing about
      errors in packet structures, values 11-20 for informing about
      problems in parameters containing cryptographic related material,
      and values 21-30 for informing about problems in authentication or
      packet integrity verification.  Parameter numbers above 30 can be
      used for informing about other types of errors or events.

      The existing registration procedures have been updated as follows.
      The range from 1-50 can remain as "IETF Review".  The range from
      51-8191 has been marked as "Specification Required".  Values
      8192-16383 remain as "Reserved for Private Use".  Values
      16384-40959 have been marked as "Specification Required".  Values
      40960-65535 remain as "Reserved for Private Use".

      The following updates to the values have been made to the existing
      registry.  All existing values referring to [RFC5201] have been
      updated to refer to this specification.

      INVALID_HIP_TRANSFORM_CHOSEN has been renamed to
      INVALID_HIP_CIPHER_CHOSEN with the same value (17).

      A new value of 20 for the type UNSUPPORTED_HIT_SUITE has been
      added.

      HMAC_FAILED has been renamed to HIP_MAC_FAILED with the same
      value (28).

      SERVER_BUSY_PLEASE_RETRY has been renamed to
      RESPONDER_BUSY_PLEASE_RETRY with the same value (44).

10.  Differences from RFC 5201

   This section summarizes the technical changes made from [RFC5201].
   This section is informational, intended to help implementors of the
   previous protocol version.  If any text in this section contradicts
   text in other portions of this specification, the text found outside
   of this section should be considered normative.

   This document specifies the HIP Version 2 protocol, which is not
   interoperable with the HIP Version 1 protocol specified in [RFC5201].
   The main technical changes are the inclusion of additional
   cryptographic agility features, and an update of the mandatory and
   optional algorithms, including Elliptic Curve support via the

Top      Up      ToC       Page 114 
   Elliptic Curve DSA (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH)
   algorithms.  The mandatory cryptographic algorithm implementations
   have been updated, such as replacing HMAC-SHA-1 with HMAC-SHA-256 and
   the RSA/SHA-1 signature algorithm with RSASSA-PSS, and adding ECDSA
   to RSA as mandatory public key types.  This version of HIP is also
   aligned with the ORCHID revision [RFC7343].

   The following changes have been made to the protocol operation.

   o  Section 4.1.3 describes the new process for Diffie-Hellman group
      negotiation, an aspect of cryptographic agility.  The Initiator
      may express a preference for the choice of a DH group in the I1
      packet and may suggest multiple possible choices.  The Responder
      replies with a preference based on local policy and the options
      provided by the Initiator.  The Initiator may restart the base
      exchange if the option chosen by the Responder is unsuitable
      (unsupported algorithms).

   o  Another aspect of cryptographic agility that has been added is the
      ability to use different cryptographic hash functions to generate
      the HIT.  The Responder's HIT hash algorithm (RHASH) terminology
      was introduced to support this.  In addition, HIT Suites have been
      introduced to group the set of cryptographic algorithms used
      together for public key signature, hash function, and hash
      truncation.  The use of HIT Suites constrains the combinatorial
      possibilities of algorithm selection for different functions.  HIT
      Suite IDs are related to the ORCHID OGA ID field ([RFC7343]).

   o  The puzzle mechanism has been slightly changed, in that the #I
      parameter depends on the HIT hash function (RHASH) selected, and
      the specification now advises against reusing the same #I value to
      the same Initiator; more details are provided in Sections 4.1.2
      and 5.2.4).

   o  Section 4.1.4 was extended to cover details about R1 generation
      counter rollover or reset.

   o  Section 4.1.6 was added to describe procedures for aborting a HIP
      base exchange.

   o  Section 4.1.7 provides guidance on avoiding downgrade attacks on
      the cryptographic algorithms.

   o  Section 4.1.8 on opportunistic mode has been updated to account
      for cryptographic agility by adding HIT selection procedures.

Top      Up      ToC       Page 115 
   o  The HIP KEYMAT generation has been updated as described in
      Section 6.5 to make the key derivation function a negotiable
      aspect of the protocol.

   o  Packet processing for the I1, R1, and I2 packets has been updated
      to account for new parameter processing.

   o  This specification adds a requirement that hosts MUST support
      processing of ACK parameters with several SEQ sequence numbers
      even when they do not support sending such parameters.

   o  This document now clarifies that several ECHO_REQUEST_UNSIGNED
      parameters may be present in an R1 and that several ECHO_RESPONSE
      parameters may be present in an I2.

   o  Procedures for responding to version mismatches with an ICMP
      Parameter Problem have been added.

   o  The security considerations section (Section 8) has been updated
      to remove possible attacks no longer considered applicable.

   o  The use of the Anonymous bit for making the sender's Host Identity
      anonymous is now supported in packets other than the R1 and I2.

   o  Support for the use of a NULL HIP CIPHER is explicitly limited to
      debugging and testing HIP and is no longer a mandatory algorithm
      to support.

   The following changes have been made to the parameter types and
   encodings (Section 5.2).

   o  Four new parameter types have been added: DH_GROUP_LIST,
      HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST.

   o  Two parameter types have been renamed: HMAC has been renamed to
      HIP_MAC, and HMAC2 has been renamed to HIP_MAC_2.

   o  One parameter type is deprecated: HIP_TRANSFORM.  Functionally, it
      has been replaced by the HIP_CIPHER but with slightly different
      semantics (hashes have been removed and are now determined by
      RHASH).

   o  The TRANSPORT_FORMAT_LIST parameter allows transports to be
      negotiated with the list instead of by their order in the
      HIP packet.

Top      Up      ToC       Page 116 
   o  The type code for the R1_COUNTER has been changed from 128 to 129
      to reflect that it is now considered a Critical parameter and must
      be echoed when present in R1.

   o  The PUZZLE and SOLUTION parameter lengths are now variable and
      dependent on the RHASH length.

   o  The Diffie-Hellman Group IDs supported have been updated.

   o  The HOST_ID parameter now requires specification of an Algorithm.

   o  The NOTIFICATION parameter supports new Notify Message Type
      values.

   o  The HIP_SIGNATURE algorithm field has been changed from 8 bits to
      16 bits to achieve alignment with the HOST_ID parameters.

   o  The specification clarifies that the SEQ parameter always contains
      one update ID but that the ACK parameter may acknowledge several
      update IDs.

   o  The restriction that only one ECHO_RESPONSE_UNSIGNED parameter
      must be present in each HIP packet has been removed.

   o  The document creates a new type range allocation for parameters
      that are only covered by a signature if a signature is present and
      applies it to the newly created DH_GROUP_LIST parameter.

   o  The document clarifies that several NOTIFY parameters may be
      present in a packet.

   The following changes have been made to the packet contents
   (Section 5.3).

   o  The I1 packet now carries the Initiator's DH_GROUP_LIST.

   o  The R1 packet now carries the HIP_CIPHER, HIT_SUITE_LIST,
      DH_GROUP_LIST, and TRANSPORT_FORMAT_LIST parameters.

   o  The I2 packet now carries the HIP_CIPHER and TRANSPORT_FORMAT_LIST
      parameters.

   o  This document clarifies that UPDATE packets that do not contain
      either a SEQ or ACK parameter are invalid.

Top      Up      ToC       Page 117 
11.  References

11.1.  Normative References

   [FIPS.180-4.2012]
              National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", FIPS PUB 180-4, March 2012,
              <http://csrc.nist.gov/publications/fips/fips180-4/
              fips-180-4.pdf>.

   [NIST.800-131A.2011]
              National Institute of Standards and Technology,
              "Transitions: Recommendation for Transitioning the Use of
              Cryptographic Algorithms and Key Lengths", NIST
              SP 800-131A, January 2011, <http://csrc.nist.gov/
              publications/nistpubs/800-131A/sp800-131A.pdf>.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980, <http://www.rfc-editor.org/info/rfc768>.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981, <http://www.rfc-editor.org/
              info/rfc793>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987,
              <http://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, November 1998,
              <http://www.rfc-editor.org/info/rfc2404>.

   [RFC2410]  Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
              Its Use With IPsec", RFC 2410, November 1998,
              <http://www.rfc-editor.org/info/rfc2410>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998,
              <http://www.rfc-editor.org/info/rfc2460>.

   [RFC2536]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
              System (DNS)", RFC 2536, March 1999,
              <http://www.rfc-editor.org/info/rfc2536>.

Top      Up      ToC       Page 118 
   [RFC3110]  Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
              Domain Name System (DNS)", RFC 3110, May 2001,
              <http://www.rfc-editor.org/info/rfc3110>.

   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
              Diffie-Hellman groups for Internet Key Exchange (IKE)",
              RFC 3526, May 2003, <http://www.rfc-editor.org/
              info/rfc3526>.

   [RFC3602]  Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
              Algorithm and Its Use with IPsec", RFC 3602,
              September 2003, <http://www.rfc-editor.org/info/rfc3602>.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005, <http://www.rfc-editor.org/
              info/rfc3972>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005, <http://www.rfc-editor.org/
              info/rfc4034>.

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005,
              <http://www.rfc-editor.org/info/rfc4282>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006,
              <http://www.rfc-editor.org/info/rfc4443>.

   [RFC4754]  Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
              the Elliptic Curve Digital Signature Algorithm (ECDSA)",
              RFC 4754, January 2007, <http://www.rfc-editor.org/
              info/rfc4754>.

   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
              HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868,
              May 2007, <http://www.rfc-editor.org/info/rfc4868>.

   [RFC5702]  Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
              and RRSIG Resource Records for DNSSEC", RFC 5702,
              October 2009, <http://www.rfc-editor.org/info/rfc5702>.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012,
              <http://www.rfc-editor.org/info/rfc6724>.

Top      Up      ToC       Page 119 
   [RFC7343]  Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
              Routable Cryptographic Hash Identifiers Version 2
              (ORCHIDv2)", RFC 7343, September 2014,
              <http://www.rfc-editor.org/info/rfc7343>.

   [RFC7402]  Jokela, P., Moskowitz, R., and J. Melen, "Using the
              Encapsulating Security Payload (ESP) Transport Format with
              the Host Identity Protocol (HIP)", RFC 7402, April 2015,
              <http://www.rfc-editor.org/info/rfc7402>.

11.2.  Informative References

   [AUR05]    Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the
              HIP Base Exchange Protocol", in Proceedings of the 10th
              Australasian Conference on Information Security and
              Privacy, July 2005.

   [CRO03]    Crosby, S. and D. Wallach, "Denial of Service via
              Algorithmic Complexity Attacks", in Proceedings of the
              12th USENIX Security Symposium, Washington, D.C.,
              August 2003.

   [DIF76]    Diffie, W. and M. Hellman, "New Directions in
              Cryptography", IEEE Transactions on Information Theory
              Volume IT-22, Number 6, pages 644-654, November 1976.

   [FIPS.186-4.2013]
              National Institute of Standards and Technology, "Digital
              Signature Standard (DSS)", FIPS PUB 186-4, July 2013,
              <http://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.186-4.pdf>.

   [FIPS.197.2001]
              National Institute of Standards and Technology, "Advanced
              Encryption Standard (AES)", FIPS PUB 197, November 2001,
              <http://csrc.nist.gov/publications/fips/fips197/
              fips-197.pdf>.

   [HIP-ARCH] Moskowitz, R., Ed., and M. Komu, "Host Identity Protocol
              Architecture", Work in Progress,
              draft-ietf-hip-rfc4423-bis-09, October 2014.

   [HIP-DNS-EXT]
              Laganier, J., "Host Identity Protocol (HIP) Domain Name
              System (DNS) Extension", Work in Progress,
              draft-ietf-hip-rfc5205-bis-06, January 2015.

Top      Up      ToC       Page 120 
   [HIP-HOST-MOB]
              Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility
              with the Host Identity Protocol", Work in Progress,
              draft-ietf-hip-rfc5206-bis-08, January 2015.

   [HIP-REND-EXT]
              Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
              Rendezvous Extension", Work in Progress,
              draft-ietf-hip-rfc5204-bis-05, December 2014.

   [KAU03]    Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS
              protection for UDP-based protocols", in Proceedings of the
              10th ACM Conference on Computer and Communications
              Security, October 2003.

   [KRA03]    Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to
              Authenticated Diffie-Hellman and Its Use in the IKE
              Protocols", in Proceedings of CRYPTO 2003, pages 400-425,
              August 2003.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981, <http://www.rfc-editor.org/
              info/rfc792>.

   [RFC2785]  Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
              Attacks on the Diffie-Hellman Key Agreement Method for
              S/MIME", RFC 2785, March 2000,
              <http://www.rfc-editor.org/info/rfc2785>.

   [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
              Specification Version 2.0", RFC 2898, September 2000,
              <http://www.rfc-editor.org/info/rfc2898>.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003,
              <http://www.rfc-editor.org/info/rfc3447>.

   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
              Reserved for Documentation", RFC 3849, July 2004,
              <http://www.rfc-editor.org/info/rfc3849>.

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", RFC 5201, April 2008,
              <http://www.rfc-editor.org/info/rfc5201>.

Top      Up      ToC       Page 121 
   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008, <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5338]  Henderson, T., Nikander, P., and M. Komu, "Using the Host
              Identity Protocol with Legacy Applications", RFC 5338,
              September 2008, <http://www.rfc-editor.org/info/rfc5338>.

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, June 2009,
              <http://www.rfc-editor.org/info/rfc5533>.

   [RFC5737]  Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
              Reserved for Documentation", RFC 5737, January 2010,
              <http://www.rfc-editor.org/info/rfc5737>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869, May 2010,
              <http://www.rfc-editor.org/info/rfc5869>.

   [RFC5903]  Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
              Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
              June 2010, <http://www.rfc-editor.org/info/rfc5903>.

   [RFC6090]  McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
              Curve Cryptography Algorithms", RFC 6090, February 2011,
              <http://www.rfc-editor.org/info/rfc6090>.

   [RFC6253]  Heer, T. and S. Varjonen, "Host Identity Protocol
              Certificates", RFC 6253, May 2011,
              <http://www.rfc-editor.org/info/rfc6253>.

   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
              of IPv6 Extension Headers", RFC 7045, December 2013,
              <http://www.rfc-editor.org/info/rfc7045>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, October 2014,
              <http://www.rfc-editor.org/info/rfc7296>.

   [RSA]      Rivest, R., Shamir, A., and L. Adleman, "A Method for
              Obtaining Digital Signatures and Public-Key
              Cryptosystems", Communications of the ACM 21 (2),
              pp. 120-126, February 1978.

   [SECG]     SECG, "Recommended Elliptic Curve Domain Parameters",
              SEC 2 Version 2.0, January 2010, <http://www.secg.org/>.

Top      Up      ToC       Page 122 
Appendix A.  Using Responder Puzzles

   As mentioned in Section 4.1.1, the Responder may delay state creation
   and still reject most spoofed I2 packets by using a number of
   pre-calculated R1 packets and a local selection function.  This
   appendix defines one possible implementation in detail.  The purpose
   of this appendix is to give the implementors an idea of how to
   implement the mechanism.  If the implementation is based on this
   appendix, it MAY contain some local modification that makes an
   attacker's task harder.

   The Responder creates a secret value S, that it regenerates
   periodically.  The Responder needs to remember the two latest values
   of S.  Each time the S is regenerated, the R1 generation counter
   value is incremented by one.

   The Responder generates a pre-signed R1 packet.  The signature for
   pre-generated R1s must be recalculated when the Diffie-Hellman key is
   recomputed or when the R1_COUNTER value changes due to S value
   regeneration.

   When the Initiator sends the I1 packet for initializing a connection,
   the Responder receives the HIT and IP address from the packet, and
   generates an #I value for the puzzle.  The #I value is set to the
   pre-signed R1 packet.

       #I value calculation:
       #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n)
       where n = RHASH_len

   The RHASH algorithm is the same as is used to generate the
   Responder's HIT value.

   From an incoming I2 packet, the Responder receives the required
   information to validate the puzzle: HITs, IP addresses, and the
   information of the used S value from the R1_COUNTER.  Using these
   values, the Responder can regenerate the #I, and verify it against
   the #I received in the I2 packet.  If the #I values match, it can
   verify the solution using #I, #J, and difficulty #K.  If the #I
   values do not match, the I2 is dropped.

       puzzle_check:
       V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K )
       if V != 0, drop the packet

   If the puzzle solution is correct, the #I and #J values are stored
   for later use.  They are used as input material when keying material
   is generated.

Top      Up      ToC       Page 123 
   Keeping state about failed puzzle solutions depends on the
   implementation.  Although it is possible for the Responder not to
   keep any state information, it still may do so to protect itself
   against certain attacks (see Section 4.1.1).

Appendix B.  Generating a Public Key Encoding from an HI

   The following pseudo-code illustrates the process to generate a
   public key encoding from an HI for both RSA and DSA.

   The symbol ":=" denotes assignment; the symbol "+=" denotes
   appending.  The pseudo-function "encode_in_network_byte_order" takes
   two parameters, an integer (bignum) and a length in bytes, and
   returns the integer encoded into a byte string of the given length.

   switch ( HI.algorithm )
   {

   case RSA:
      buffer := encode_in_network_byte_order ( HI.RSA.e_len,
                ( HI.RSA.e_len > 255 ) ? 3 : 1 )
      buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len )
      buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len )

      break;

   case DSA:
      buffer := encode_in_network_byte_order ( HI.DSA.T , 1 )
      buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 )
      buffer += encode_in_network_byte_order ( HI.DSA.P , 64 +
                                               8 * HI.DSA.T )
      buffer += encode_in_network_byte_order ( HI.DSA.G , 64 +
                                               8 * HI.DSA.T )
      buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 +
                                               8 * HI.DSA.T )

      break;

   }

Appendix C.  Example Checksums for HIP Packets

   The HIP checksum for HIP packets is specified in Section 5.1.1.
   Checksums for TCP and UDP packets running over HIP-enabled security
   associations are specified in Section 4.5.1.  The examples below use
   [RFC3849] and [RFC5737] addresses, and HITs with the prefix of
   2001:20 followed by zeros, followed by a decimal 1 or 2,
   respectively.

Top      Up      ToC       Page 124 
   The following example is defined only for testing the checksum
   calculation.

C.1.  IPv6 HIP Example (I1 Packet)

     Source Address:                 2001:db8::1
     Destination Address:            2001:db8::2
     Upper-Layer Packet Length:      48              0x30
     Next Header:                    139             0x8b
     Payload Protocol:               59              0x3b
     Header Length:                  5               0x5
     Packet Type:                    1               0x1
     Version:                        2               0x2
     Reserved:                       1               0x1
     Control:                        0               0x0
     Checksum:                       6750            0x1a5e
     Sender's HIT:                   2001:20::1
     Receiver's HIT:                 2001:20::2
     DH_GROUP_LIST type:             511             0x1ff
     DH_GROUP_LIST length:           3               0x3
     DH_GROUP_LIST Group IDs:        3,4,8

C.2.  IPv4 HIP Packet (I1 Packet)

   The IPv4 checksum value for the example I1 packet is shown below.

     Source Address:                 192.0.2.1
     Destination Address:            192.0.2.2
     Upper-Layer Packet Length:      48              0x30
     Next Header:                    139             0x8b
     Payload Protocol:               59              0x3b
     Header Length:                  5               0x5
     Packet Type:                    1               0x1
     Version:                        2               0x2
     Reserved:                       1               0x1
     Control:                        0               0x0
     Checksum:                       61902           0xf1ce
     Sender's HIT:                   2001:20::1
     Receiver's HIT:                 2001:20::2
     DH_GROUP_LIST type:             511             0x1ff
     DH_GROUP_LIST length:           3               0x3
     DH_GROUP_LIST Group IDs:        3,4,8

Top      Up      ToC       Page 125 
C.3.  TCP Segment

   Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets
   use the IPv6 pseudo header format [RFC2460], with the HITs used in
   place of the IPv6 addresses.

     Sender's HIT:                   2001:20::1
     Receiver's HIT:                 2001:20::2
     Upper-Layer Packet Length:      20              0x14
     Next Header:                    6               0x06
     Source port:                    65500           0xffdc
     Destination port:               22              0x0016
     Sequence number:                1               0x00000001
     Acknowledgment number:          0               0x00000000
     Data offset:                    5               0x5
     Flags:                          SYN             0x02
     Window size:                    65535           0xffff
     Checksum:                       28586           0x6faa
     Urgent pointer:                 0               0x0000

Appendix D.  ECDH and ECDSA 160-Bit Groups

   The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits
   symmetric strength.  This was once considered appropriate for one
   year of security.  Today, these groups should be used only when the
   host is not powerful enough (e.g., some embedded devices) and when
   security requirements are low (e.g., long-term confidentiality is not
   required).

Appendix E.  HIT Suites and HIT Generation

   The HIT as an ORCHID [RFC7343] consists of three parts: A 28-bit
   prefix, a 4-bit encoding of the ORCHID generation algorithm (OGA),
   and a hash that includes the Host Identity and a context ID.  The OGA
   is an index pointing to the specific algorithm by which the public
   key and the 96-bit hashed encoding are generated.  The OGA is
   protocol specific and is to be interpreted as defined below for all
   protocols that use the same context ID as HIP.  HIP groups sets of
   valid combinations of signature and hash algorithms into HIT Suites.
   These HIT Suites are addressed by an index, which is transmitted in
   the OGA ID field of the ORCHID.

   The set of used HIT Suites will be extended to counter the progress
   in computation capabilities and vulnerabilities in the employed
   algorithms.  The intended use of the HIT Suites is to introduce a new
   HIT Suite and phase out an old one before it becomes insecure.  Since
   the 4-bit OGA ID field only permits 15 HIT Suites to be used at the
   same time (the HIT Suite with ID 0 is reserved), phased-out HIT

Top      Up      ToC       Page 126 
   Suites must be reused at some point.  In such a case, there will be a
   rollover of the HIT Suite ID and the next newly introduced HIT Suite
   will start with a lower HIT Suite index than the previously
   introduced one.  The rollover effectively deprecates the reused HIT
   Suite.  For a smooth transition, the HIT Suite should be deprecated a
   considerable time before the HIT Suite index is reused.

   Since the number of HIT Suites is tightly limited to 16, the HIT
   Suites must be assigned carefully.  Hence, sets of suitable
   algorithms are grouped in a HIT Suite.

   The HIT Suite of the Responder's HIT determines the RHASH and the
   hash function to be used for the HMAC in HIP packets as well as the
   signature algorithm family used for generating the HI.  The list of
   HIT Suites is defined in Table 10.

Top      Up      ToC       Page 127 
Acknowledgments

   The drive to create HIP came to being after attending the MALLOC
   meeting at the 43rd IETF meeting.  Baiju Patel and Hilarie Orman
   really gave the original author, Bob Moskowitz, the assist to get HIP
   beyond 5 paragraphs of ideas.  It has matured considerably since the
   early versions thanks to extensive input from IETFers.  Most
   importantly, its design goals are articulated and are different from
   other efforts in this direction.  Particular mention goes to the
   members of the NameSpace Research Group of the IRTF.  Noel Chiappa
   provided valuable input at early stages of discussions about
   identifier handling and Keith Moore the impetus to provide
   resolvability.  Steve Deering provided encouragement to keep working,
   as a solid proposal can act as a proof of ideas for a research group.

   Many others contributed; extensive security tips were provided by
   Steve Bellovin.  Rob Austein kept the DNS parts on track.  Paul
   Kocher taught Bob Moskowitz how to make the puzzle exchange expensive
   for the Initiator to respond, but easy for the Responder to validate.
   Bill Sommerfeld supplied the Birthday concept, which later evolved
   into the R1 generation counter, to simplify reboot management.  Erik
   Nordmark supplied the CLOSE-mechanism for closing connections.
   Rodney Thayer and Hugh Daniels provided extensive feedback.  In the
   early times of this document, John Gilmore kept Bob Moskowitz
   challenged to provide something of value.

   During the later stages of this document, when the editing baton was
   transferred to Pekka Nikander, the input from the early implementors
   was invaluable.  Without having actual implementations, this document
   would not be on the level it is now.

   In the usual IETF fashion, a large number of people have contributed
   to the actual text or ideas.  The list of these people includes Jeff
   Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Xin Gu, Rene
   Hummen, Miika Komu, Mika Kousa, Julien Laganier, Andrew McGregor, Jan
   Melen, Henrik Petander, Michael Richardson, Tim Shepard, Jorma Wall,
   and Jukka Ylitalo.  Our apologies to anyone whose name is missing.

   Once the HIP Working Group was founded in early 2004, a number of
   changes were introduced through the working group process.  Most
   notably, the original document was split in two, one containing the
   base exchange and the other one defining how to use ESP.  Some
   modifications to the protocol proposed by Aura, et al. [AUR05] were
   added at a later stage.

Top      Up      ToC       Page 128 
Authors' Addresses

   Robert Moskowitz (editor)
   HTT Consulting
   Oak Park, MI
   United States

   EMail: rgm@labs.htt-consult.com


   Tobias Heer
   Hirschmann Automation and Control
   Stuttgarter Strasse 45-51
   Neckartenzlingen  72654
   Germany

   EMail: tobias.heer@belden.com


   Petri Jokela
   Ericsson Research NomadicLab
   Jorvas  FIN-02420
   Finland

   Phone: +358 9 299 1
   EMail: petri.jokela@nomadiclab.com


   Thomas R. Henderson
   University of Washington
   Campus Box 352500
   Seattle, WA
   United States

   EMail: tomhend@u.washington.edu