tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7401

 
 
 

Host Identity Protocol Version 2 (HIPv2)

Part 2 of 5, p. 12 to 38
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 12 
4.  Protocol Overview

   This section is a simplified overview of the HIP protocol operation,
   and does not contain all the details of the packet formats or the
   packet processing steps.  Sections 5 and 6 describe in more detail
   the packet formats and packet processing steps, respectively, and are
   normative in case of any conflicts with this section.

   The protocol number 139 has been assigned by IANA to the Host
   Identity Protocol.

   The HIP payload (Section 5.1) header could be carried in every IP
   datagram.  However, since HIP headers are relatively large
   (40 bytes), it is desirable to 'compress' the HIP header so that the
   HIP header only occurs in control packets used to establish or change
   HIP association state.  The actual method for header 'compression'
   and for matching data packets with existing HIP associations (if any)
   is defined in separate documents, describing transport formats and
   methods.  All HIP implementations MUST implement, at minimum, the ESP
   transport format for HIP [RFC7402].

4.1.  Creating a HIP Association

   By definition, the system initiating a HIP base exchange is the
   Initiator, and the peer is the Responder.  This distinction is
   typically forgotten once the base exchange completes, and either
   party can become the Initiator in future communications.

   The HIP base exchange serves to manage the establishment of state
   between an Initiator and a Responder.  The first packet, I1,
   initiates the exchange, and the last three packets, R1, I2, and R2,
   constitute an authenticated Diffie-Hellman [DIF76] key exchange for
   session-key generation.  In the first two packets, the hosts agree on
   a set of cryptographic identifiers and algorithms that are then used
   in and after the exchange.  During the Diffie-Hellman key exchange, a
   piece of keying material is generated.  The HIP association keys are
   drawn from this keying material by using a Key Derivation Function
   (KDF).  If other cryptographic keys are needed, e.g., to be used with
   ESP, they are expected to be drawn from the same keying material by
   using the KDF.

   The Initiator first sends a trigger packet, I1, to the Responder.
   The packet contains the HIT of the Initiator and possibly the HIT of
   the Responder, if it is known.  Moreover, the I1 packet initializes
   the negotiation of the Diffie-Hellman group that is used for
   generating the keying material.  Therefore, the I1 packet contains a
   list of Diffie-Hellman Group IDs supported by the Initiator.  Note
   that in some cases it may be possible to replace this trigger packet

Top      Up      ToC       Page 13 
   with some other form of a trigger, in which case the protocol starts
   with the Responder sending the R1 packet.  In such cases, another
   mechanism to convey the Initiator's supported DH groups (e.g., by
   using a default group) must be specified.

   The second packet, R1, starts the actual authenticated Diffie-Hellman
   exchange.  It contains a puzzle -- a cryptographic challenge that the
   Initiator must solve before continuing the exchange.  The level of
   difficulty of the puzzle can be adjusted based on the level of trust
   with the Initiator, the current load, or other factors.  In addition,
   the R1 contains the Responder's Diffie-Hellman parameter and lists of
   cryptographic algorithms supported by the Responder.  Based on these
   lists, the Initiator can continue, abort, or restart the base
   exchange with a different selection of cryptographic algorithms.
   Also, the R1 packet contains a signature that covers selected parts
   of the message.  Some fields are left outside the signature to
   support pre-created R1s.

   In the I2 packet, the Initiator MUST display the solution to the
   received puzzle.  Without a correct solution, the I2 message is
   discarded.  The I2 packet also contains a Diffie-Hellman parameter
   that carries needed information for the Responder.  The I2 packet is
   signed by the Initiator.

   The R2 packet acknowledges the receipt of the I2 packet and completes
   the base exchange.  The packet is signed by the Responder.

Top      Up      ToC       Page 14 
   The base exchange is illustrated below in Figure 1.  The term "key"
   refers to the Host Identity public key, and "sig" represents a
   signature using such a key.  The packets contain other parameters not
   shown in this figure.

      Initiator                              Responder

                   I1: DH list
                 -------------------------->
                                             select precomputed R1
                   R1: puzzle, DH, key, sig
                 <-------------------------
   check sig                                 remain stateless
   solve puzzle
                 I2: solution, DH, {key}, sig
                 -------------------------->
   compute DH                                check puzzle
                                             check sig
                           R2: sig
                 <--------------------------
   check sig                                 compute DH

                                 Figure 1

4.1.1.  HIP Puzzle Mechanism

   The purpose of the HIP puzzle mechanism is to protect the Responder
   from a number of denial-of-service threats.  It allows the Responder
   to delay state creation until receiving the I2 packet.  Furthermore,
   the puzzle allows the Responder to use a fairly cheap calculation to
   check that the Initiator is "sincere" in the sense that it has
   churned enough CPU cycles in solving the puzzle.

   The puzzle allows a Responder implementation to completely delay
   association-specific state creation until a valid I2 packet is
   received.  An I2 packet without a valid puzzle solution can be
   rejected immediately once the Responder has checked the solution.
   The solution can be checked by computing only one hash function, and
   invalid solutions can be rejected before state is created, and before
   CPU-intensive public-key signature verification and Diffie-Hellman
   key generation are performed.  By varying the difficulty of the
   puzzle, the Responder can frustrate CPU- or memory-targeted DoS
   attacks.

   The Responder can remain stateless and drop most spoofed I2 packets
   because puzzle calculation is based on the Initiator's Host Identity
   Tag.  The idea is that the Responder has a (perhaps varying) number
   of pre-calculated R1 packets, and it selects one of these based on

Top      Up      ToC       Page 15 
   the information carried in the I1 packet.  When the Responder then
   later receives the I2 packet, it can verify that the puzzle has been
   solved using the Initiator's HIT.  This makes it impractical for the
   attacker to first exchange one I1/R1 packet, and then generate a
   large number of spoofed I2 packets that seemingly come from different
   HITs.  This method does not protect the Responder from an attacker
   that uses fixed HITs, though.  Against such an attacker, a viable
   approach may be to create a piece of local state, and remember that
   the puzzle check has previously failed.  See Appendix A for one
   possible implementation.  Responder implementations SHOULD include
   sufficient randomness in the puzzle values so that algorithmic
   complexity attacks become impossible [CRO03].

   The Responder can set the puzzle difficulty for the Initiator, based
   on its level of trust of the Initiator.  Because the puzzle is not
   included in the signature calculation, the Responder can use
   pre-calculated R1 packets and include the puzzle just before sending
   the R1 to the Initiator.  The Responder SHOULD use heuristics to
   determine when it is under a denial-of-service attack, and set the
   puzzle difficulty value #K appropriately, as explained later.

4.1.2.  Puzzle Exchange

   The Responder starts the puzzle exchange when it receives an I1
   packet.  The Responder supplies a random number #I, and requires the
   Initiator to find a number #J.  To select a proper #J, the Initiator
   must create the concatenation of #I, the HITs of the parties, and #J,
   and calculate a hash over this concatenation using the RHASH
   algorithm.  The lowest-order #K bits of the result MUST be zeros.
   The value #K sets the difficulty of the puzzle.

   To generate a proper number #J, the Initiator will have to generate a
   number of #Js until one produces the hash target of zeros.  The
   Initiator SHOULD give up after exceeding the puzzle Lifetime in the
   PUZZLE parameter (as described in Section 5.2.4).  The Responder
   needs to re-create the concatenation of #I, the HITs, and the
   provided #J, and compute the hash once to prove that the Initiator
   completed its assigned task.

   To prevent precomputation attacks, the Responder MUST select the
   number #I in such a way that the Initiator cannot guess it.
   Furthermore, the construction MUST allow the Responder to verify that
   the value #I was indeed selected by it and not by the Initiator.  See
   Appendix A for an example on how to implement this.

   Using the Opaque data field in the PUZZLE (see Section 5.2.4) in an
   ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an
   ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder

Top      Up      ToC       Page 16 
   can include some data in R1 that the Initiator MUST copy unmodified
   in the corresponding I2 packet.  The Responder can use the opaque
   data to transfer a piece of local state information to the Initiator
   and back -- for example, to recognize that the I2 is a response to a
   previously sent R1.  The Responder can generate the opaque data in
   various ways, e.g., using encryption or hashing with some secret, the
   sent #I, and possibly using other related data.  With the same
   secret, the received #I (from the I2 packet), and the other related
   data (if any), the Responder can verify that it has itself sent the
   #I to the Initiator.  The Responder MUST periodically change such a
   secret.

   It is RECOMMENDED that the Responder generates new secrets for the
   puzzle and new R1s once every few minutes.  Furthermore, it is
   RECOMMENDED that the Responder is able to verify a valid puzzle
   solution at least Lifetime seconds after the puzzle secret has been
   deprecated.  This time value guarantees that the puzzle is valid for
   at least Lifetime and at most 2 * Lifetime seconds.  This limits the
   usability that an old, solved puzzle has to an attacker.  Moreover,
   it avoids problems with the validity of puzzles if the lifetime is
   relatively short compared to the network delay and the time for
   solving the puzzle.

   The puzzle value #I and the solution #J are inputs for deriving the
   keying material from the Diffie-Hellman key exchange (see
   Section 6.5).  Therefore, to ensure that the derived keying material
   differs, a Responder SHOULD NOT use the same puzzle #I with the same
   DH keys for the same Initiator twice.  Such uniqueness can be
   achieved, for example, by using a counter as an additional input for
   generating #I.  This counter can be increased for each processed I1
   packet.  The state of the counter can be transmitted in the Opaque
   data field in the PUZZLE (see Section 5.2.4), in an
   ECHO_REQUEST_SIGNED parameter (see Section 5.2.20), or in an
   ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21) without the need
   to establish state.

   NOTE: The protocol developers explicitly considered whether R1 should
   include a timestamp in order to protect the Initiator from replay
   attacks.  The decision was to NOT include a timestamp, to avoid
   problems with global time synchronization.

   NOTE: The protocol developers explicitly considered whether a memory-
   bound function should be used for the puzzle instead of a CPU-bound
   function.  The decision was to not use memory-bound functions.

Top      Up      ToC       Page 17 
4.1.3.  Authenticated Diffie-Hellman Protocol with DH Group Negotiation

   The packets R1, I2, and R2 implement a standard authenticated
   Diffie-Hellman exchange.  The Responder sends one of its public
   Diffie-Hellman keys and its public authentication key, i.e., its Host
   Identity, in R1.  The signature in the R1 packet allows the Initiator
   to verify that the R1 has been once generated by the Responder.
   However, since the R1 is precomputed and therefore does not cover
   association-specific information in the I1 packet, it does not
   protect against replay attacks.

   Before the actual authenticated Diffie-Hellman exchange, the
   Initiator expresses its preference regarding its choice of the DH
   groups in the I1 packet.  The preference is expressed as a sorted
   list of DH Group IDs.  The I1 packet is not protected by a signature.
   Therefore, this list is sent in an unauthenticated way to avoid
   costly computations for processing the I1 packet at the Responder
   side.  Based on the preferences of the Initiator, the Responder sends
   an R1 packet containing its most suitable public DH value.  The
   Responder also attaches a list of its own preferences to the R1 to
   convey the basis for the DH group selection to the Initiator.  This
   list is carried in the signed part of the R1 packet.  If the choice
   of the DH group value in the R1 does not match the preferences of the
   Initiator and the Responder, the Initiator can detect that the list
   of DH Group IDs in the I1 was manipulated (see below for details).

   If none of the DH Group IDs in the I1 packet are supported by the
   Responder, the Responder selects the DH group most suitable for it,
   regardless of the Initiator's preference.  It then sends the R1
   containing this DH group and its list of supported DH Group IDs to
   the Initiator.

   When the Initiator receives an R1, it receives one of the Responder's
   public Diffie-Hellman values and the list of DH Group IDs supported
   by the Responder.  This list is covered by the signature in the R1
   packet to avoid forgery.  The Initiator compares the Group ID of the
   public DH value in the R1 packet to the list of supported DH Group
   IDs in the R1 packets and to its own preferences expressed in the
   list of supported DH Group IDs.  The Initiator continues the BEX only
   if the Group ID of the public DH value of the Responder is the most
   preferred of the IDs supported by both the Initiator and Responder.
   Otherwise, the communication is subject to a downgrade attack, and
   the Initiator MUST either restart the base exchange with a new I1
   packet or abort the base exchange.  If the Responder's choice of the
   DH group is not supported by the Initiator, the Initiator MAY abort
   the handshake or send a new I1 packet with a different list of
   supported DH groups.  However, the Initiator MUST verify the

Top      Up      ToC       Page 18 
   signature of the R1 packet before restarting or aborting the
   handshake.  It MUST silently ignore the R1 packet if the signature is
   not valid.

   If the preferences regarding the DH Group ID match, the Initiator
   computes the Diffie-Hellman session key (Kij).  The Initiator creates
   a HIP association using keying material from the session key (see
   Section 6.5) and may use the HIP association to encrypt its public
   authentication key, i.e., the Host Identity.  The resulting I2 packet
   contains the Initiator's Diffie-Hellman key and its (optionally
   encrypted) public authentication key.  The signature of the I2
   message covers all parameters of the signed parameter ranges (see
   Section 5.2) in the packet without exceptions, as in the R1.

   The Responder extracts the Initiator's Diffie-Hellman public key from
   the I2 packet, computes the Diffie-Hellman session key, creates a
   corresponding HIP association, and decrypts the Initiator's public
   authentication key.  It can then verify the signature using the
   authentication key.

   The final message, R2, completes the BEX and protects the Initiator
   against replay attacks, because the Responder uses the shared key
   from the Diffie-Hellman exchange to create a Hashed Message
   Authentication Code (HMAC) and also uses the private key of its Host
   Identity to sign the packet contents.

4.1.4.  HIP Replay Protection

   HIP includes the following mechanisms to protect against malicious
   packet replays.  Responders are protected against replays of I1
   packets by virtue of the stateless response to I1 packets with
   pre-signed R1 messages.  Initiators are protected against R1 replays
   by a monotonically increasing "R1 generation counter" included in
   the R1.  Responders are protected against replays of forged I2
   packets by the puzzle mechanism (see Section 4.1.1 above), and
   optional use of opaque data.  Hosts are protected against replays of
   R2 packets and UPDATEs by use of a less expensive HMAC verification
   preceding the HIP signature verification.

   The R1 generation counter is a monotonically increasing 64-bit
   counter that may be initialized to any value.  The scope of the
   counter MAY be system-wide, but there SHOULD be a separate counter
   for each Host Identity, if there is more than one local Host
   Identity.  The value of this counter SHOULD be preserved across
   system reboots and invocations of the HIP base exchange.  This
   counter indicates the current generation of puzzles.  Implementations
   MUST accept puzzles from the current generation and MAY accept
   puzzles from earlier generations.  A system's local counter MUST be

Top      Up      ToC       Page 19 
   incremented at least as often as every time old R1s cease to be
   valid.  The local counter SHOULD never be decremented; otherwise, the
   host exposes its peers to the replay of previously generated, higher-
   numbered R1s.

   A host may receive more than one R1, either due to sending multiple
   I1 packets (see Section 6.6.1) or due to a replay of an old R1.  When
   sending multiple I1 packets to the same host, an Initiator SHOULD
   wait for a small amount of time (a reasonable time may be
   2 * expected RTT) after the first R1 reception to allow possibly
   multiple R1s to arrive, and it SHOULD respond to an R1 among the set
   with the largest R1 generation counter.  If an Initiator is
   processing an R1 or has already sent an I2 packet (still waiting for
   the R2 packet) and it receives another R1 with a larger R1 generation
   counter, it MAY elect to restart R1 processing with the fresher R1,
   as if it were the first R1 to arrive.

   The R1 generation counter may roll over or may become reset.  It is
   important for an Initiator to be robust to the loss of state about
   the R1 generation counter of a peer or to a reset of the peer's
   counter.  It is recommended that, when choosing between multiple R1s,
   the Initiator prefer to use the R1 that corresponds to the current R1
   generation counter, but that if it is unable to make progress with
   that R1, the Initiator may try the other R1s, beginning with the R1
   packet with the highest counter.

4.1.5.  Refusing a HIP Base Exchange

   A HIP-aware host may choose not to accept a HIP base exchange.  If
   the host's policy is to only be an Initiator and policy allows the
   establishment of a HIP association with the original Initiator, it
   should begin its own HIP base exchange.  A host MAY choose to have
   such a policy since only the privacy of the Initiator's HI is
   protected in the exchange.  It should be noted that such behavior can
   introduce the risk of a race condition if each host's policy is to
   only be an Initiator, at which point the HIP base exchange will fail.

   If the host's policy does not permit it to enter into a HIP exchange
   with the Initiator, it should send an ICMP 'Destination Unreachable,
   Administratively Prohibited' message.  A more complex HIP packet is
   not used here as it actually opens up more potential DoS attacks than
   a simple ICMP message.  A HIP NOTIFY message is not used because no
   HIP association exists between the two hosts at that time.

Top      Up      ToC       Page 20 
4.1.6.  Aborting a HIP Base Exchange

   Two HIP hosts may encounter situations in which they cannot complete
   a HIP base exchange because of insufficient support for cryptographic
   algorithms, in particular the HIT Suites and DH groups.  After
   receiving the R1 packet, the Initiator can determine whether the
   Responder supports the required cryptographic operations to
   successfully establish a HIP association.  The Initiator can abort
   the BEX silently after receiving an R1 packet that indicates an
   unsupported set of algorithms.  The specific conditions are described
   below.

   The R1 packet contains a signed list of HIT Suite IDs as supported by
   the Responder.  Therefore, the Initiator can determine whether its
   source HIT is supported by the Responder.  If the HIT Suite ID of the
   Initiator's HIT is not contained in the list of HIT Suites in the R1,
   the Initiator MAY abort the handshake silently or MAY restart the
   handshake with a new I1 packet that contains a source HIT supported
   by the Responder.

   During the handshake, the Initiator and the Responder agree on a
   single DH group.  The Responder selects the DH group and its DH
   public value in the R1 based on the list of DH Group IDs in the I1
   packet.  If the Responder supports none of the DH groups requested by
   the Initiator, the Responder selects an arbitrary DH and replies with
   an R1 containing its list of supported DH Group IDs.  In such a case,
   the Initiator receives an R1 packet containing the DH public value
   for an unrequested DH group and also the Responder's DH group list in
   the signed part of the R1 packet.  At this point, the Initiator MAY
   abort the handshake or MAY restart the handshake by sending a new I1
   packet containing a selection of DH Group IDs that is supported by
   the Responder.

4.1.7.  HIP Downgrade Protection

   In a downgrade attack, an attacker attempts to unnoticeably
   manipulate the packets of an Initiator and/or a Responder to
   influence the result of the cryptographic negotiations in the BEX in
   its favor.  As a result, the victims select weaker cryptographic
   algorithms than they would otherwise have selected without the
   attacker's interference.  Downgrade attacks can only be successful if
   they remain undetected by the victims and the victims falsely assume
   a secure communication channel.

   In HIP, almost all packet parameters related to cryptographic
   negotiations are covered by signatures.  These parameters cannot be
   directly manipulated in a downgrade attack without invalidating the
   signature.  However, signed packets can be subject to replay attacks.

Top      Up      ToC       Page 21 
   In such a replay attack, the attacker could use an old BEX packet
   with an outdated and weak selection of cryptographic algorithms and
   replay it instead of a more recent packet with a collection of
   stronger cryptographic algorithms.  Signed packets that could be
   subject to this replay attack are the R1 and I2 packet.  However,
   replayed R1 and I2 packets cannot be used to successfully establish a
   HIP BEX because these packets also contain the public DH values of
   the Initiator and the Responder.  Old DH values from replayed packets
   lead to invalid keying material and mismatching shared secrets
   because the attacker is unable to derive valid keying material from
   the DH public keys in the R1 and cannot generate a valid HMAC and
   signature for a replayed I2.

   In contrast to the first version of HIP [RFC5201], version 2 of HIP
   as defined in this document begins the negotiation of the DH groups
   already in the first BEX packet, the I1.  The I1 packet is, by
   intention, not protected by a signature, to avoid CPU-intensive
   cryptographic operations processing floods of I1 packets targeted at
   the Responder.  Hence, the list of DH Group IDs in the I1 packet is
   vulnerable to forgery and manipulation.  To thwart an unnoticed
   manipulation of the I1 packet, the Responder chooses the DH group
   deterministically and includes its own list of DH Group IDs in the
   signed part of the R1 packet.  The Initiator can detect an attempted
   downgrade attack by comparing the list of DH Group IDs in the R1
   packet to its own preferences in the I1 packet.  If the choice of the
   DH group in the R1 packet does not equal the best match of the two
   lists (the highest-priority DH ID of the Responder that is present in
   the Initiator's DH list), the Initiator can conclude that its list in
   the I1 packet was altered by an attacker.  In this case, the
   Initiator can restart or abort the BEX.  As mentioned before, the
   detection of the downgrade attack is sufficient to prevent it.

4.1.8.  HIP Opportunistic Mode

   It is possible to initiate a HIP BEX even if the Responder's HI (and
   HIT) is unknown.  In this case, the initial I1 packet contains all
   zeros as the destination HIT.  This kind of connection setup is
   called opportunistic mode.

   The Responder may have multiple HITs due to multiple supported HIT
   Suites.  Since the Responder's HIT Suite in the opportunistic mode is
   not determined by the destination HIT of the I1 packet, the Responder
   can freely select a HIT of any HIT Suite.  The complete set of HIT
   Suites supported by the Initiator is not known to the Responder.
   Therefore, the Responder SHOULD select its HIT from the same HIT
   Suite as the Initiator's HIT (indicated by the HIT Suite information
   in the OGA ID field of the Initiator's HIT) because this HIT Suite is
   obviously supported by the Initiator.  If the Responder selects a

Top      Up      ToC       Page 22 
   different HIT that is not supported by the Initiator, the Initiator
   MAY restart the BEX with an I1 packet with a source HIT that is
   contained in the list of the Responder's HIT Suites in the R1 packet.

   Note that the Initiator cannot verify the signature of the R1 packet
   if the Responder's HIT Suite is not supported.  Therefore, the
   Initiator MUST treat R1 packets with unsupported Responder HITs as
   potentially forged and MUST NOT use any parameters from the
   unverified R1 besides the HIT_SUITE_LIST.  Moreover, an Initiator
   that uses an unverified HIT_SUITE_LIST from an R1 packet to determine
   a possible source HIT MUST verify that the HIT_SUITE_LIST in the
   first unverified R1 packet matches the HIT_SUITE_LIST in the second
   R1 packet for which the Initiator supports the signature algorithm.
   The Initiator MUST restart the BEX with a new I1 packet for which the
   algorithm was mentioned in the verifiable R1 if the two lists do not
   match.  This procedure is necessary to mitigate downgrade attacks.

   There are both security and API issues involved with the
   opportunistic mode.  These issues are described in the remainder of
   this section.

   Given that the Responder's HI is not known by the Initiator, there
   must be suitable API calls that allow the Initiator to request,
   directly or indirectly, that the underlying system initiates the HIP
   base exchange solely based on locators.  The Responder's HI will be
   tentatively available in the R1 packet, and in an authenticated form
   once the R2 packet has been received and verified.  Hence, the
   Responder's HIT could be communicated to the application via new API
   mechanisms.  However, with a backwards-compatible API the application
   sees only the locators used for the initial contact.  Depending on
   the desired semantics of the API, this can raise the following
   issues:

   o  The actual locators may later change if an UPDATE message is used,
      even if from the API perspective the association still appears to
      be between two specific locators.  However, the locator update is
      still secure, and the association is still between the same nodes.

   o  Different associations between the same two locators may result in
      connections to different nodes, if the implementation no longer
      remembers which identifier the peer had in an earlier association.
      This is possible when the peer's locator has changed for
      legitimate reasons or when an attacker pretends to be a node that
      has the peer's locator.  Therefore, when using opportunistic mode,
      HIP implementations MUST NOT place any expectation that the peer's
      HI returned in the R1 message matches any HI previously seen from
      that address.

Top      Up      ToC       Page 23 
      If the HIP implementation and application do not have the same
      understanding of what constitutes an association, this may even
      happen within the same association.  For instance, an
      implementation may not know when HIP state can be purged for
      UDP-based applications.

   In addition, the following security considerations apply.  The
   generation counter mechanism will be less efficient in protecting
   against replays of the R1 packet, given that the Responder can choose
   a replay that uses an arbitrary HI, not just the one given in the I1
   packet.

   More importantly, the opportunistic exchange is vulnerable to
   man-in-the-middle attacks, because the Initiator does not have any
   public key information about the peer.  To assess the impacts of this
   vulnerability, we compare it to vulnerabilities in current,
   non-HIP-capable communications.

   An attacker on the path between the two peers can insert itself as a
   man-in-the-middle by providing its own identifier to the Initiator
   and then initiating another HIP association towards the Responder.
   For this to be possible, the Initiator must employ opportunistic
   mode, and the Responder must be configured to accept a connection
   from any HIP-enabled node.

   An attacker outside the path will be unable to do so, given that it
   cannot respond to the messages in the base exchange.

   These security properties are characteristic also of communications
   in the current Internet.  A client contacting a server without
   employing end-to-end security may find itself talking to the server
   via a man-in-the-middle, assuming again that the server is willing to
   talk to anyone.

   If end-to-end security is in place, then the worst that can happen in
   both the opportunistic HIP and non-HIP (normal IP) cases is denial-
   of-service; an entity on the path can disrupt communications, but
   will be unable to successfully insert itself as a man-in-the-middle.

   However, once the opportunistic exchange has successfully completed,
   HIP provides confidentiality and integrity protection for the
   communications, and can securely change the locators of the
   endpoints.

   As a result, opportunistic mode in HIP offers a "better than nothing"
   security model.  Initially, a base exchange authenticated in the
   opportunistic mode involves a leap of faith subject to man-in-the-
   middle attacks, but subsequent datagrams related to the same HIP

Top      Up      ToC       Page 24 
   association cannot be compromised by a new man-in-the-middle attack.
   Further, if the man-in-the-middle moves away from the path of the
   active association, the attack would be exposed after the fact.
   Thus, it can be stated that opportunistic mode in HIP is at least as
   secure as unprotected IP-based communications.

4.2.  Updating a HIP Association

   A HIP association between two hosts may need to be updated over time.
   Examples include the need to rekey expiring security associations,
   add new security associations, or change IP addresses associated with
   hosts.  The UPDATE packet is used for those and other similar
   purposes.  This document only specifies the UPDATE packet format and
   basic processing rules, with mandatory parameters.  The actual usage
   is defined in separate specifications.

   HIP provides a general-purpose UPDATE packet, which can carry
   multiple HIP parameters, for updating the HIP state between two
   peers.  The UPDATE mechanism has the following properties:

      UPDATE messages carry a monotonically increasing sequence number
      and are explicitly acknowledged by the peer.  Lost UPDATEs or
      acknowledgments may be recovered via retransmission.  Multiple
      UPDATE messages may be outstanding under certain circumstances.

      UPDATE is protected by both HIP_MAC and HIP_SIGNATURE parameters,
      since processing UPDATE signatures alone is a potential DoS attack
      against intermediate systems.

      UPDATE packets are explicitly acknowledged by the use of an
      acknowledgment parameter that echoes an individual sequence number
      received from the peer.  A single UPDATE packet may contain both a
      sequence number and one or more acknowledgment numbers (i.e.,
      piggybacked acknowledgment(s) for the peer's UPDATE).

   The UPDATE packet is defined in Section 5.3.5.

4.3.  Error Processing

   HIP error processing behavior depends on whether or not there exists
   an active HIP association.  In general, if a HIP association exists
   between the sender and receiver of a packet causing an error
   condition, the receiver SHOULD respond with a NOTIFY packet.  On the
   other hand, if there are no existing HIP associations between the
   sender and receiver, or the receiver cannot reasonably determine the
   identity of the sender, the receiver MAY respond with a suitable ICMP
   message; see Section 5.4 for more details.

Top      Up      ToC       Page 25 
   The HIP protocol and state machine are designed to recover from one
   of the parties crashing and losing its state.  The following
   scenarios describe the main use cases covered by the design.

      No prior state between the two systems.

         The system with data to send is the Initiator.  The process
         follows the standard four-packet base exchange, establishing
         the HIP association.

      The system with data to send has no state with the receiver, but
      the receiver has a residual HIP association.

         The system with data to send is the Initiator.  The Initiator
         acts as in no prior state, sending an I1 packet and receiving
         an R1 packet.  When the Responder receives a valid I2 packet,
         the old association is 'discovered' and deleted, and the new
         association is established.

      The system with data to send has a HIP association, but the
      receiver does not.

         The system sends data on the outbound user data security
         association.  The receiver 'detects' the situation when it
         receives a user data packet that it cannot match to any HIP
         association.  The receiving host MUST discard this packet.

         The receiving host SHOULD send an ICMP packet, with the type
         Parameter Problem, to inform the sender that the HIP
         association does not exist (see Section 5.4), and it MAY
         initiate a new HIP BEX.  However, responding with these
         optional mechanisms is implementation or policy dependent.  If
         the sending application doesn't expect a response, the system
         could possibly send a large number of packets in this state, so
         for this reason, the sending of one or more ICMP packets is
         RECOMMENDED.  However, any such responses MUST be rate-limited
         to prevent abuse (see Section 5.4).

4.4.  HIP State Machine

   HIP itself has little state.  In the HIP base exchange, there is an
   Initiator and a Responder.  Once the security associations (SAs) are
   established, this distinction is lost.  If the HIP state needs to be
   re-established, the controlling parameters are which peer still has
   state and which has a datagram to send to its peer.  The following
   state machine attempts to capture these processes.

Top      Up      ToC       Page 26 
   The state machine is symmetric and is presented in a single system
   view, representing either an Initiator or a Responder.  The state
   machine is not a full representation of the processing logic.
   Additional processing rules are presented in the packet definitions.
   Hence, both are needed to completely implement HIP.

   This document extends the state machine as defined in [RFC5201] and
   introduces a restart option to allow for the negotiation of
   cryptographic algorithms.  The extension to the previous state
   machine in [RFC5201] is a transition from state I1-SENT back again to
   I1-SENT; namely, the restart option.  An Initiator is required to
   restart the HIP base exchange if the Responder does not support the
   HIT Suite of the Initiator.  In this case, the Initiator restarts the
   HIP base exchange by sending a new I1 packet with a source HIT
   supported by the Responder.

   Implementors must understand that the state machine, as described
   here, is informational.  Specific implementations are free to
   implement the actual processing logic differently.  Section 6
   describes the packet processing rules in more detail.  This state
   machine focuses on the HIP I1, R1, I2, and R2 packets only.  New
   states and state transitions may be introduced by mechanisms in other
   specifications (such as mobility and multihoming).

4.4.1.  State Machine Terminology

   Unused Association Lifetime (UAL):  Implementation-specific time for
      which, if no packet is sent or received for this time interval, a
      host MAY begin to tear down an active HIP association.

   Maximum Segment Lifetime (MSL):  Maximum time that a HIP packet is
      expected to spend in the network.  A default value of 2 minutes
      has been borrowed from [RFC0793] because it is a prevailing
      assumption for packet lifetimes.

   Exchange Complete (EC):  Time that the host spends at the R2-SENT
      state before it moves to the ESTABLISHED state.  The time is n *
      I2 retransmission timeout, where n is about I2_RETRIES_MAX.

   Receive ANYOTHER:  Any received packet for which no state transitions
      or processing rules are defined for a given state.

Top      Up      ToC       Page 27 
4.4.2.  HIP States

   +---------------------+---------------------------------------------+
   | State               | Explanation                                 |
   +---------------------+---------------------------------------------+
   | UNASSOCIATED        | State machine start                         |
   |                     |                                             |
   | I1-SENT             | Initiating base exchange                    |
   |                     |                                             |
   | I2-SENT             | Waiting to complete base exchange           |
   |                     |                                             |
   | R2-SENT             | Waiting to complete base exchange           |
   |                     |                                             |
   | ESTABLISHED         | HIP association established                 |
   |                     |                                             |
   | CLOSING             | HIP association closing, no data can be     |
   |                     | sent                                        |
   |                     |                                             |
   | CLOSED              | HIP association closed, no data can be sent |
   |                     |                                             |
   | E-FAILED            | HIP base exchange failed                    |
   +---------------------+---------------------------------------------+

                            Table 1: HIP States

Top      Up      ToC       Page 28 
4.4.3.  HIP State Processes

   System behavior in state UNASSOCIATED, Table 2.

   +----------------------------+--------------------------------------+
   | Trigger                    | Action                               |
   +----------------------------+--------------------------------------+
   | User data to send,         | Send I1 and go to I1-SENT            |
   | requiring a new HIP        |                                      |
   | association                |                                      |
   |                            |                                      |
   | Receive I1                 | Send R1 and stay at UNASSOCIATED     |
   |                            |                                      |
   | Receive I2, process        | If successful, send R2 and go to     |
   |                            | R2-SENT                              |
   |                            |                                      |
   |                            | If fail, stay at UNASSOCIATED        |
   |                            |                                      |
   | Receive user data for an   | Optionally send ICMP as defined in   |
   | unknown HIP association    | Section 5.4 and stay at UNASSOCIATED |
   |                            |                                      |
   | Receive CLOSE              | Optionally send ICMP Parameter       |
   |                            | Problem and stay at UNASSOCIATED     |
   |                            |                                      |
   | Receive ANYOTHER           | Drop and stay at UNASSOCIATED        |
   +----------------------------+--------------------------------------+

                    Table 2: UNASSOCIATED - Start State

Top      Up      ToC       Page 29 
   System behavior in state I1-SENT, Table 3.

   +---------------------+---------------------------------------------+
   | Trigger             | Action                                      |
   +---------------------+---------------------------------------------+
   | Receive I1 from     | If the local HIT is smaller than the peer   |
   | Responder           | HIT, drop I1 and stay at I1-SENT (see       |
   |                     | Section 6.5 for HIT comparison)             |
   |                     |                                             |
   |                     | If the local HIT is greater than the peer   |
   |                     | HIT, send R1 and stay at I1-SENT            |
   |                     |                                             |
   | Receive I2, process | If successful, send R2 and go to R2-SENT    |
   |                     |                                             |
   |                     | If fail, stay at I1-SENT                    |
   |                     |                                             |
   | Receive R1, process | If the HIT Suite of the local HIT is not    |
   |                     | supported by the peer, select supported     |
   |                     | local HIT, send I1, and stay at I1-SENT     |
   |                     |                                             |
   |                     | If successful, send I2 and go to I2-SENT    |
   |                     |                                             |
   |                     | If fail, stay at I1-SENT                    |
   |                     |                                             |
   | Receive ANYOTHER    | Drop and stay at I1-SENT                    |
   |                     |                                             |
   | Timeout             | Increment trial counter                     |
   |                     |                                             |
   |                     | If counter is less than I1_RETRIES_MAX,     |
   |                     | send I1 and stay at I1-SENT                 |
   |                     |                                             |
   |                     | If counter is greater than I1_RETRIES_MAX,  |
   |                     | go to E-FAILED                              |
   +---------------------+---------------------------------------------+

            Table 3: I1-SENT - Initiating the HIP Base Exchange

Top      Up      ToC       Page 30 
   System behavior in state I2-SENT, Table 4.

   +---------------------+---------------------------------------------+
   | Trigger             | Action                                      |
   +---------------------+---------------------------------------------+
   | Receive I1          | Send R1 and stay at I2-SENT                 |
   |                     |                                             |
   | Receive R1, process | If successful, send I2 and stay at I2-SENT  |
   |                     |                                             |
   |                     | If fail, stay at I2-SENT                    |
   |                     |                                             |
   | Receive I2, process | If successful and local HIT is smaller than |
   |                     | the peer HIT, drop I2 and stay at I2-SENT   |
   |                     |                                             |
   |                     | If successful and local HIT is greater than |
   |                     | the peer HIT, send R2 and go to R2-SENT     |
   |                     |                                             |
   |                     | If fail, stay at I2-SENT                    |
   |                     |                                             |
   | Receive R2, process | If successful, go to ESTABLISHED            |
   |                     |                                             |
   |                     | If fail, stay at I2-SENT                    |
   |                     |                                             |
   | Receive CLOSE,      | If successful, send CLOSE_ACK and go to     |
   | process             | CLOSED                                      |
   |                     |                                             |
   |                     | If fail, stay at I2-SENT                    |
   |                     |                                             |
   | Receive ANYOTHER    | Drop and stay at I2-SENT                    |
   |                     |                                             |
   | Timeout             | Increment trial counter                     |
   |                     |                                             |
   |                     | If counter is less than I2_RETRIES_MAX,     |
   |                     | send I2 and stay at I2-SENT                 |
   |                     |                                             |
   |                     | If counter is greater than I2_RETRIES_MAX,  |
   |                     | go to E-FAILED                              |
   +---------------------+---------------------------------------------+

        Table 4: I2-SENT - Waiting to Finish the HIP Base Exchange

Top      Up      ToC       Page 31 
   System behavior in state R2-SENT, Table 5.

   +------------------------+------------------------------------------+
   | Trigger                | Action                                   |
   +------------------------+------------------------------------------+
   | Receive I1             | Send R1 and stay at R2-SENT              |
   |                        |                                          |
   | Receive I2, process    | If successful, send R2 and stay at       |
   |                        | R2-SENT                                  |
   |                        |                                          |
   |                        | If fail, stay at R2-SENT                 |
   |                        |                                          |
   | Receive R1             | Drop and stay at R2-SENT                 |
   |                        |                                          |
   | Receive R2             | Drop and stay at R2-SENT                 |
   |                        |                                          |
   | Receive data or UPDATE | Move to ESTABLISHED                      |
   |                        |                                          |
   | Exchange Complete      | Move to ESTABLISHED                      |
   | Timeout                |                                          |
   |                        |                                          |
   | Receive CLOSE, process | If successful, send CLOSE_ACK and go to  |
   |                        | CLOSED                                   |
   |                        |                                          |
   |                        | If fail, stay at ESTABLISHED             |
   |                        |                                          |
   | Receive CLOSE_ACK      | Drop and stay at R2-SENT                 |
   |                        |                                          |
   | Receive NOTIFY         | Process and stay at R2-SENT              |
   +------------------------+------------------------------------------+

                 Table 5: R2-SENT - Waiting to Finish HIP

Top      Up      ToC       Page 32 
   System behavior in state ESTABLISHED, Table 6.

   +---------------------+---------------------------------------------+
   | Trigger             | Action                                      |
   +---------------------+---------------------------------------------+
   | Receive I1          | Send R1 and stay at ESTABLISHED             |
   |                     |                                             |
   | Receive I2          | Process with puzzle and possible Opaque     |
   |                     | data verification                           |
   |                     |                                             |
   |                     | If successful, send R2, drop old HIP        |
   |                     | association, establish a new HIP            |
   |                     | association, and go to R2-SENT              |
   |                     |                                             |
   |                     | If fail, stay at ESTABLISHED                |
   |                     |                                             |
   | Receive R1          | Drop and stay at ESTABLISHED                |
   |                     |                                             |
   | Receive R2          | Drop and stay at ESTABLISHED                |
   |                     |                                             |
   | Receive user data   | Process and stay at ESTABLISHED             |
   | for HIP association |                                             |
   |                     |                                             |
   | No packet           | Send CLOSE and go to CLOSING                |
   | sent/received       |                                             |
   | during UAL minutes  |                                             |
   |                     |                                             |
   | Receive UPDATE      | Process and stay at ESTABLISHED             |
   |                     |                                             |
   | Receive CLOSE,      | If successful, send CLOSE_ACK and go to     |
   | process             | CLOSED                                      |
   |                     |                                             |
   |                     | If fail, stay at ESTABLISHED                |
   |                     |                                             |
   | Receive CLOSE_ACK   | Drop and stay at ESTABLISHED                |
   |                     |                                             |
   | Receive NOTIFY      | Process and stay at ESTABLISHED             |
   +---------------------+---------------------------------------------+

            Table 6: ESTABLISHED - HIP Association Established

Top      Up      ToC       Page 33 
   System behavior in state CLOSING, Table 7.

   +----------------------------+--------------------------------------+
   | Trigger                    | Action                               |
   +----------------------------+--------------------------------------+
   | User data to send,         | Send I1 and go to I1-SENT            |
   | requires the creation of   |                                      |
   | another incarnation of the |                                      |
   | HIP association            |                                      |
   |                            |                                      |
   | Receive I1                 | Send R1 and stay at CLOSING          |
   |                            |                                      |
   | Receive I2, process        | If successful, send R2 and go to     |
   |                            | R2-SENT                              |
   |                            |                                      |
   |                            | If fail, stay at CLOSING             |
   |                            |                                      |
   | Receive R1, process        | If successful, send I2 and go to     |
   |                            | I2-SENT                              |
   |                            |                                      |
   |                            | If fail, stay at CLOSING             |
   |                            |                                      |
   | Receive CLOSE, process     | If successful, send CLOSE_ACK,       |
   |                            | discard state, and go to CLOSED      |
   |                            |                                      |
   |                            | If fail, stay at CLOSING             |
   |                            |                                      |
   | Receive CLOSE_ACK, process | If successful, discard state and go  |
   |                            | to UNASSOCIATED                      |
   |                            |                                      |
   |                            | If fail, stay at CLOSING             |
   |                            |                                      |
   | Receive ANYOTHER           | Drop and stay at CLOSING             |
   |                            |                                      |
   | Timeout                    | Increment timeout sum and reset      |
   |                            | timer.  If timeout sum is less than  |
   |                            | UAL+MSL minutes, retransmit CLOSE    |
   |                            | and stay at CLOSING.                 |
   |                            |                                      |
   |                            | If timeout sum is greater than       |
   |                            | UAL+MSL minutes, go to UNASSOCIATED  |
   +----------------------------+--------------------------------------+

   Table 7: CLOSING - HIP Association Has Not Been Used for UAL Minutes

Top      Up      ToC       Page 34 
   System behavior in state CLOSED, Table 8.

   +----------------------------------------+--------------------------+
   | Trigger                                | Action                   |
   +----------------------------------------+--------------------------+
   | Datagram to send, requires the         | Send I1 and stay at      |
   | creation of another incarnation of the | CLOSED                   |
   | HIP association                        |                          |
   |                                        |                          |
   | Receive I1                             | Send R1 and stay at      |
   |                                        | CLOSED                   |
   |                                        |                          |
   | Receive I2, process                    | If successful, send R2   |
   |                                        | and go to R2-SENT        |
   |                                        |                          |
   |                                        | If fail, stay at CLOSED  |
   |                                        |                          |
   | Receive R1, process                    | If successful, send I2   |
   |                                        | and go to I2-SENT        |
   |                                        |                          |
   |                                        | If fail, stay at CLOSED  |
   |                                        |                          |
   | Receive CLOSE, process                 | If successful, send      |
   |                                        | CLOSE_ACK and stay at    |
   |                                        | CLOSED                   |
   |                                        |                          |
   |                                        | If fail, stay at CLOSED  |
   |                                        |                          |
   | Receive CLOSE_ACK, process             | If successful, discard   |
   |                                        | state and go to          |
   |                                        | UNASSOCIATED             |
   |                                        |                          |
   |                                        | If fail, stay at CLOSED  |
   |                                        |                          |
   | Receive ANYOTHER                       | Drop and stay at CLOSED  |
   |                                        |                          |
   | Timeout (UAL+2MSL)                     | Discard state and go to  |
   |                                        | UNASSOCIATED             |
   +----------------------------------------+--------------------------+

    Table 8: CLOSED - CLOSE_ACK Sent, Resending CLOSE_ACK if Necessary

Top      Up      ToC       Page 35 
   System behavior in state E-FAILED, Table 9.

   +-------------------------+-----------------------------------------+
   | Trigger                 | Action                                  |
   +-------------------------+-----------------------------------------+
   | Wait for                | Go to UNASSOCIATED.  Renegotiation is   |
   | implementation-specific | possible after moving to UNASSOCIATED   |
   | time                    | state.                                  |
   +-------------------------+-----------------------------------------+

     Table 9: E-FAILED - HIP Failed to Establish Association with Peer

4.4.4.  Simplified HIP State Diagram

   The following diagram (Figure 2) shows the major state transitions.
   Transitions based on received packets implicitly assume that the
   packets are successfully authenticated or processed.

Top      Up      ToC       Page 36 
                               +--+       +----------------------------+
              recv I1, send R1 |  |       |                            |
                               |  v       v                            |
                             +--------------+  recv I2, send R2        |
            +----------------| UNASSOCIATED |----------------+         |
   datagram |  +--+          +--------------+                |         |
   to send, |  |  | Alg. not supported,                      |         |
    send I1 |  |  | send I1                                  |         |
     .      v  |  v                                          |         |
     .   +---------+  recv I2, send R2                       |         |
   +---->| I1-SENT |--------------------------------------+  |         |
   |     +---------+            +----------------------+  |  |         |
   |          | recv R2,        | recv I2, send R2     |  |  |         |
   |          v send I2         |                      v  v  v         |
   |       +---------+          |                    +---------+       |
   |  +--->| I2-SENT |----------+     +--------------| R2-SENT |<---+  |
   |  |    +---------+                |              +---------+    |  |
   |  |          |  |recv R2          |        data or|             |  |
   |  |recv R1,  |  |                 |     EC timeout|             |  |
   |  |send I2   +--|-----------------+               |  receive I2,|  |
   |  |          |  |       +-------------+           |      send R2|  |
   |  |          |  +------>| ESTABLISHED |<----------+             |  |
   |  |          |          +-------------+                         |  |
   |  |          |            |  |  |      receive I2, send R2      |  |
   |  |          +------------+  |  +-------------------------------+  |
   |  |          |               +-----------+                      |  |
   |  |          |    no packet sent/received|    +---+             |  |
   |  |          |    for UAL min, send CLOSE|    |   |timeout      |  |
   |  |          |                           v    v   |(UAL+MSL)    |  |
   |  |          |                        +---------+ |retransmit   |  |
   +--|----------|------------------------| CLOSING |-+CLOSE        |  |
      |          |                        +---------+               |  |
      |          |                         | |   | |                |  |
      +----------|-------------------------+ |   | +----------------+  |
      |          |               +-----------+   +------------------|--+
      |          |               |recv CLOSE,      recv CLOSE_ACK   |  |
      |          +-------------+ |send CLOSE_ACK   or timeout       |  |
      |     recv CLOSE,        | |                 (UAL+MSL)        |  |
      |     send CLOSE_ACK     v v                                  |  |
      |                     +--------+  receive I2, send R2         |  |
      +---------------------| CLOSED |------------------------------+  |
                            +--------+                                 |
                             ^ |  |                                    |
   recv CLOSE, send CLOSE_ACK| |  |              timeout (UAL+2MSL)    |
                             +-+  +------------------------------------+

                                 Figure 2

Top      Up      ToC       Page 37 
4.5.  User Data Considerations

4.5.1.  TCP and UDP Pseudo Header Computation for User Data

   When computing TCP and UDP checksums on user data packets that flow
   through sockets bound to HITs, the IPv6 pseudo header format
   [RFC2460] MUST be used, even if the actual addresses in the header of
   the packet are IPv4 addresses.  Additionally, the HITs MUST be used
   in place of the IPv6 addresses in the IPv6 pseudo header.  Note that
   the pseudo header for actual HIP payloads is computed differently;
   see Section 5.1.1.

4.5.2.  Sending Data on HIP Packets

   Other documents may define how to include user data in various HIP
   packets.  However, currently the HIP header is a terminal header, and
   not followed by any other headers.

4.5.3.  Transport Formats

   The actual data transmission format, used for user data after the HIP
   base exchange, is not defined in this document.  Such transport
   formats and methods are described in separate specifications.  All
   HIP implementations MUST implement, at minimum, the ESP transport
   format for HIP [RFC7402].  The transport format to be chosen is
   negotiated in the base exchange.  The Responder expresses its
   preference regarding the transport format in the
   TRANSPORT_FORMAT_LIST in the R1 packet, and the Initiator selects one
   transport format and adds the respective HIP parameter to the I2
   packet.

4.5.4.  Reboot, Timeout, and Restart of HIP

   Simulating a loss of state is a potential DoS attack.  The following
   process has been crafted to manage state recovery without presenting
   a DoS opportunity.

   If a host reboots or the HIP association times out, it has lost its
   HIP state.  If the host that lost state has a datagram to send to the
   peer, it simply restarts the HIP base exchange.  After the base
   exchange has completed, the Initiator can create a new payload
   association and start sending data.  The peer does not reset its
   state until it receives a valid I2 packet.

   If a system receives a user data packet that cannot be matched to any
   existing HIP association, it is possible that it has lost the state
   and its peer has not.  It MAY send an ICMP packet with the Parameter
   Problem type, and with the Pointer pointing to the referred

Top      Up      ToC       Page 38 
   HIP-related association information.  Reacting to such traffic
   depends on the implementation and the environment where the
   implementation is used.

   If the host that apparently has lost its state decides to restart the
   HIP base exchange, it sends an I1 packet to the peer.  After the base
   exchange has been completed successfully, the Initiator can create a
   new HIP association, and the peer drops its old payload associations
   and creates a new one.

4.6.  Certificate Distribution

   This document does not define how to use certificates or how to
   transfer them between hosts.  These functions are expected to be
   defined in a future specification, as was done for HIP version 1 (see
   [RFC6253]).  A parameter type value, meant to be used for carrying
   certificates, is reserved, though: CERT, Type 768; see Section 5.2.



(page 38 continued on part 3)

Next RFC Part