tech-invite   World Map
3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search     Home

RFC 8046

 
 
 

Host Mobility with the Host Identity Protocol

Part 2 of 2, p. 19 to 37
Prev Section

 


prevText      Top      ToC       Page 19 
5.  Processing Rules

   This section describes rules for sending and receiving the
   LOCATOR_SET parameter, testing address reachability, and using CBA on
   UNVERIFIED locators.

5.1.  Locator Data Structure and Status

   Each locator announced in a LOCATOR_SET parameter is represented by a
   piece of state that contains the following data:

   o  the actual bit pattern representing the locator,

Top      Up      ToC       Page 20 
   o  the lifetime (seconds),

   o  the status (UNVERIFIED, ACTIVE, DEPRECATED),

   o  the Traffic Type scope of the locator, and

   o  whether the locator is preferred for any particular scope.

   The status is used to track the reachability of the address embedded
   within the LOCATOR_SET parameter:

   UNVERIFIED:  indicates that the reachability of the address has not
      been verified yet,

   ACTIVE:  indicates that the reachability of the address has been
      verified and the address has not been deprecated, and

   DEPRECATED:  indicates that the locator's lifetime has expired.

   The following state changes are allowed:

   UNVERIFIED to ACTIVE:  The reachability procedure completes
      successfully.

   UNVERIFIED to DEPRECATED:  The locator's lifetime expires while the
      locator is UNVERIFIED.

   ACTIVE to DEPRECATED:  The locator's lifetime expires while the
      locator is ACTIVE.

   ACTIVE to UNVERIFIED:  There has been no traffic on the address for
      some time, and the local policy mandates that the address
      reachability needs to be verified again before starting to use it
      again.

   DEPRECATED to UNVERIFIED:  The host receives a new lifetime for the
      locator.

   A DEPRECATED address MUST NOT be changed to ACTIVE without first
   verifying its reachability.

   Note that the state of whether or not a locator is preferred is not
   necessarily the same as the value of the preferred bit in the Locator
   sub-parameter received from the peer.  Peers may recommend certain
   locators to be preferred, but the decision on whether to actually use
   a locator as a preferred locator is a local decision, possibly
   influenced by local policy.

Top      Up      ToC       Page 21 
   In addition to state maintained about status and remaining lifetime
   for each locator learned from the peer, an implementation would
   typically maintain similar state about its own locators that have
   been offered to the peer.

   A locator lifetime that is unbounded (does not expire) can be
   signified by setting the value of the lifetime field to the maximum
   (unsigned) value.

   Finally, the locators used to establish the HIP association are by
   default assumed to be the initial preferred locators in ACTIVE state,
   with an unbounded lifetime.

5.2.  Sending the LOCATOR_SET

   The decision of when to send the LOCATOR_SET is a local policy issue.
   However, it is RECOMMENDED that a host send a LOCATOR_SET whenever it
   recognizes a change of its IP addresses in use on an active HIP
   association and assumes that the change is going to last at least for
   a few seconds.  Rapidly sending LOCATOR_SETs that force the peer to
   change the preferred address SHOULD be avoided.

   The sending of a new LOCATOR_SET parameter replaces the locator
   information from any previously sent LOCATOR_SET parameter;
   therefore, if a host sends a new LOCATOR_SET parameter, it needs to
   continue to include all active locators.  Hosts MUST NOT announce
   broadcast or multicast addresses in LOCATOR_SETs.

   We now describe a few cases introduced in Section 3.2.  We assume
   that the Traffic Type for each locator is set to "0" (other values
   for Traffic Type may be specified in documents that separate the HIP
   control plane from data-plane traffic).  Other mobility cases are
   possible but are left for further study.

   1.  Host mobility with no multihoming and no rekeying.  The mobile
       host creates a single UPDATE containing a single ESP_INFO with a
       single LOCATOR_SET parameter.  The ESP_INFO contains the current
       value of the SPI in both the OLD SPI and NEW SPI fields.  The
       LOCATOR_SET contains a single Locator with a Locator Type of "1";
       the SPI MUST match that of the ESP_INFO.  The preferred bit
       SHOULD be set and the "Locator Lifetime" is set according to
       local policy.  The UPDATE also contains a SEQ parameter as usual.
       This packet is retransmitted as defined in the HIP specification
       [RFC7401].  The UPDATE should be sent to the peer's preferred IP
       address with an IP source address corresponding to the address in
       the LOCATOR_SET parameter.

Top      Up      ToC       Page 22 
   2.  Host mobility with no multihoming but with rekeying.  The mobile
       host creates a single UPDATE containing a single ESP_INFO with a
       single LOCATOR_SET parameter (with a single address).  The
       ESP_INFO contains the current value of the SPI in the OLD SPI,
       the new value of the SPI in the NEW SPI, and a KEYMAT Index as
       selected by local policy.  Optionally, the host may choose to
       initiate a Diffie-Hellman rekey by including a DIFFIE_HELLMAN
       parameter.  The LOCATOR_SET contains a single Locator with a
       Locator Type of "1"; the SPI MUST match that of the NEW SPI in
       the ESP_INFO.  Otherwise, the steps are identical to the case in
       which no rekeying is initiated.

5.3.  Handling Received LOCATOR_SETs

   A host SHOULD be prepared to receive a single LOCATOR_SET parameter
   in a HIP UPDATE packet.  Reception of multiple LOCATOR_SET parameters
   in a single packet, or in HIP packets other than UPDATE, is outside
   of the scope of this specification.

   Because a host sending the LOCATOR_SET may send the same parameter in
   different UPDATE messages to different destination addresses,
   including possibly the RVS of the host, the host receiving the
   LOCATOR_SET MUST be prepared to handle the possibility of duplicate
   LOCATOR_SETs sent to more than one of the host's addresses.  As a
   result, the host MUST detect and avoid reprocessing a LOCATOR_SET
   parameter that is redundant with a LOCATOR_SET parameter that has
   been recently received and processed.

   This document describes sending both ESP_INFO and LOCATOR_SET
   parameters in an UPDATE.  The ESP_INFO parameter is included when
   there is a need to rekey or key a new SPI, and is otherwise included
   for the possible benefit of HIP-aware NATs and firewalls.  The
   LOCATOR_SET parameter contains a complete listing of the locators
   that the host wishes to make or keep active for the HIP association.

   In general, the processing of a LOCATOR_SET depends upon the packet
   type in which it is included.  Here, we describe only the case in
   which ESP_INFO is present and a single LOCATOR_SET and ESP_INFO are
   sent in an UPDATE message; other cases are for further study.  The
   steps below cover each of the cases described in Section 5.2.

   The processing of ESP_INFO and LOCATOR_SET parameters is intended to
   be modular and support future generalization to the inclusion of
   multiple ESP_INFO and/or multiple LOCATOR_SET parameters.  A host
   SHOULD first process the ESP_INFO before the LOCATOR_SET, since the
   ESP_INFO may contain a new SPI value mapped to an existing SPI, while
   a Locator Type of "1" will only contain a reference to the new SPI.

Top      Up      ToC       Page 23 
   When a host receives a validated HIP UPDATE with a LOCATOR_SET and
   ESP_INFO parameter, it processes the ESP_INFO as follows.  The
   ESP_INFO parameter indicates whether an SA is being rekeyed, created,
   deprecated, or just identified for the benefit of HIP-aware NATs and
   firewalls.  The host examines the OLD SPI and NEW SPI values in the
   ESP_INFO parameter:

   1.  (no rekeying) If the OLD SPI is equal to the NEW SPI and both
       correspond to an existing SPI, the ESP_INFO is gratuitous
       (provided for HIP-aware NATs and firewalls) and no rekeying is
       necessary.

   2.  (rekeying) If the OLD SPI indicates an existing SPI and the NEW
       SPI is a different non-zero value, the existing SA is being
       rekeyed and the host follows HIP ESP rekeying procedures by
       creating a new outbound SA with an SPI corresponding to the NEW
       SPI, with no addresses bound to this SPI.  Note that locators in
       the LOCATOR_SET parameter will reference this new SPI instead of
       the old SPI.

   3.  (new SA) If the OLD SPI value is zero and the NEW SPI is a new
       non-zero value, then a new SA is being requested by the peer.
       This case is also treated like a rekeying event; the receiving
       host MUST create a new SA and respond with an UPDATE ACK.

   4.  (deprecating the SA) If the OLD SPI indicates an existing SPI and
       the NEW SPI is zero, the SA is being deprecated and all locators
       uniquely bound to the SPI are put into the DEPRECATED state.

   If none of the above cases apply, a protocol error has occurred and
   the processing of the UPDATE is stopped.

   Next, the locators in the LOCATOR_SET parameter are processed.  For
   each locator listed in the LOCATOR_SET parameter, check that the
   address therein is a legal unicast or anycast address.  That is, the
   address MUST NOT be a broadcast or multicast address.  Note that some
   implementations MAY accept addresses that indicate the local host,
   since it may be allowed that the host runs HIP with itself.

   The below assumes that all Locators are of Type "1" with a Traffic
   Type of "0"; other cases are for further study.

   For each Type "1" address listed in the LOCATOR_SET parameter, the
   host checks whether the address is already bound to the SPI
   indicated.  If the address is already bound, its lifetime is updated.
   If the status of the address is DEPRECATED, the status is changed to
   UNVERIFIED.  If the address is not already bound, the address is

Top      Up      ToC       Page 24 
   added, and its status is set to UNVERIFIED.  Mark all addresses
   corresponding to the SPI that were NOT listed in the LOCATOR_SET
   parameter as DEPRECATED.

   As a result, at the end of processing, the addresses listed in the
   LOCATOR_SET parameter have a state of either UNVERIFIED or ACTIVE,
   and any old addresses on the old SA not listed in the LOCATOR_SET
   parameter have a state of DEPRECATED.

   Once the host has processed the locators, if the LOCATOR_SET
   parameter contains a new preferred locator, the host SHOULD initiate
   a change of the preferred locator.  This requires that the host first
   verify reachability of the associated address, and only then change
   the preferred locator; see Section 5.5.

   If a host receives a locator with an unsupported Locator Type, and
   when such a locator is also declared to be the preferred locator for
   the peer, the host SHOULD send a NOTIFY error with a Notify Message
   Type of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field
   containing the locator(s) that the receiver failed to process.
   Otherwise, a host MAY send a NOTIFY error if a (non-preferred)
   locator with an unsupported Locator Type is received in a LOCATOR_SET
   parameter.

   A host MAY add the source IP address of a received HIP packet as a
   candidate locator for the peer even if it is not listed in the peer's
   LOCATOR_SET, but it SHOULD prefer locators explicitly listed in the
   LOCATOR_SET.

5.4.  Verifying Address Reachability

   A host MUST verify the reachability of an UNVERIFIED address.  The
   status of a newly learned address MUST initially be set to UNVERIFIED
   unless the new address is advertised in an R1 packet as a new
   preferred locator.  A host MAY also want to verify the reachability
   of an ACTIVE address again after some time, in which case it would
   set the status of the address to UNVERIFIED and reinitiate address
   verification.  A typical verification that is protected by
   retransmission timers is to include an ECHO REQUEST within an UPDATE
   sent to the new address.

   A host typically starts the address-verification procedure by sending
   a nonce to the new address.  A host MAY choose from different message
   exchanges or different nonce values so long as it establishes that
   the peer has received and replied to the nonce at the new address.

Top      Up      ToC       Page 25 
   For example, when the host is changing its SPI and sending an
   ESP_INFO to the peer, the NEW SPI value SHOULD be random and the
   random value MAY be copied into an ECHO_REQUEST sent in the rekeying
   UPDATE.  However, if the host is not changing its SPI, it MAY still
   use the ECHO_REQUEST parameter for verification but with some other
   random value.  A host MAY also use other message exchanges as
   confirmation of the address reachability.

   In some cases, it MAY be sufficient to use the arrival of data on a
   newly advertised SA as implicit address reachability verification as
   depicted in Figure 7, instead of waiting for the confirmation via a
   HIP packet.  In this case, a host advertising a new SPI as part of
   its address reachability check SHOULD be prepared to receive traffic
   on the new SA.

     Mobile Host                                   Peer Host

                  UPDATE(ESP_INFO, LOCATOR_SET, ...)
                ---------------------------------->

                                                   prepare incoming SA
                  UPDATE(ESP_INFO, ...) with new SPI
                <-----------------------------------
   switch to new outgoing SA
                           data on new SA
                ----------------------------------->
                                                   mark address ACTIVE
                  UPDATE(ACK, ECHO_RESPONSE) later arrives
                ----------------------------------->

             Figure 7: Address Activation via Use of a New SA

   When address verification is in progress for a new preferred locator,
   the host SHOULD select a different locator listed as ACTIVE, if one
   such locator is available, to continue communications until address
   verification completes.  Alternatively, the host MAY use the new
   preferred locator while in UNVERIFIED status to the extent CBA
   permits.  CBA is explained in Section 5.6.  Once address verification
   succeeds, the status of the new preferred locator changes to ACTIVE.

Top      Up      ToC       Page 26 
5.5.  Changing the Preferred Locator

   A host MAY want to change the preferred outgoing locator for
   different reasons, e.g., because traffic information or ICMP error
   messages indicate that the currently used preferred address may have
   become unreachable.  Another reason may be due to receiving a
   LOCATOR_SET parameter that has the "P" bit set.

   To change the preferred locator, the host initiates the following
   procedure:

   1.  If the new preferred locator has an ACTIVE status, the preferred
       locator is changed and the procedure succeeds.

   2.  If the new preferred locator has an UNVERIFIED status, the host
       starts to verify its reachability.  The host SHOULD use a
       different locator listed as ACTIVE until address verification
       completes if one such locator is available.  Alternatively, the
       host MAY use the new preferred locator, even though in UNVERIFIED
       status, to the extent CBA permits.  Once address verification
       succeeds, the status of the new preferred locator changes to
       ACTIVE, and its use is no longer governed by CBA.

   3.  If the peer host has not indicated a preference for any address,
       then the host picks one of the peer's ACTIVE addresses randomly
       or according to local policy.  This case may arise if, for
       example, ICMP error messages that deprecate the preferred locator
       arrive, but the peer has not yet indicated a new preferred
       locator.

   4.  If the new preferred locator has a DEPRECATED status and there is
       at least one non-deprecated address, the host selects one of the
       non-deprecated addresses as a new preferred locator and
       continues.  If the selected address is UNVERIFIED, the address
       verification procedure described above will apply.

5.6.  Credit-Based Authorization

   To prevent redirection-based flooding attacks, the use of a CBA
   approach MUST be used when a host sends data to an UNVERIFIED
   locator.  The following algorithm addresses the security
   considerations for prevention of amplification and time-shifting
   attacks.  Other forms of credit aging, and other values for the
   CreditAgingFactor and CreditAgingInterval parameters in particular,
   are for further study, and so are the advanced CBA techniques
   specified in [CBA-MIPv6].

Top      Up      ToC       Page 27 
5.6.1.  Handling Payload Packets

   A host maintains a "credit counter" for each of its peers.  Whenever
   a packet arrives from a peer, the host SHOULD increase that peer's
   credit counter by the size of the received packet.  When the host has
   a packet to be sent to the peer, and when the peer's preferred
   locator is listed as UNVERIFIED and no alternative locator with
   status ACTIVE is available, the host checks whether it can send the
   packet to the UNVERIFIED locator.  The packet SHOULD be sent if the
   value of the credit counter is higher than the size of the outbound
   packet.  If the credit counter is too low, the packet MUST be
   discarded or buffered until address verification succeeds.  When a
   packet is sent to a peer at an UNVERIFIED locator, the peer's credit
   counter MUST be reduced by the size of the packet.  The peer's credit
   counter is not affected by packets that the host sends to an ACTIVE
   locator of that peer.

   Figure 8 depicts the actions taken by the host when a packet is
   received.  Figure 9 shows the decision chain in the event a packet is
   sent.

       Inbound
       Packet
          |
          |       +----------------+               +---------------+
          |       |    Increase    |               |    Deliver    |
          +-----> | credit counter |-------------> |   packet to   |
                  | by packet size |               |  application  |
                  +----------------+               +---------------+

        Figure 8: Receiving Packets with Credit-Based Authorization

Top      Up      ToC       Page 28 
    Outbound
     Packet
        |          _________________
        |         /                 \                 +---------------+
        |        /  Is the preferred \       No       |  Send packet  |
        +-----> | destination address |-------------> |  to preferred |
                 \    UNVERIFIED?    /                |    address    |
                  \_________________/                 +---------------+
                           |
                           | Yes
                           |
                           v
                   _________________
                  /                 \                 +---------------+
                 /   Does an ACTIVE  \      Yes       |  Send packet  |
                | destination address |-------------> |   to ACTIVE   |
                 \       exist?      /                |    address    |
                  \_________________/                 +---------------+
                           |
                           | No
                           |
                           v
                   _________________
                  /                 \                 +---------------+
                 / Is credit counter \       No       |               |
                |          >=         |-------------> | Drop or       |
                 \    packet size?   /                | buffer packet |
                  \_________________/                 +---------------+
                           |
                           | Yes
                           |
                           v
                   +---------------+                  +---------------+
                   | Reduce credit |                  |  Send packet  |
                   |  counter by   |----------------> | to preferred  |
                   |  packet size  |                  |    address    |
                   +---------------+                  +---------------+

         Figure 9: Sending Packets with Credit-Based Authorization

Top      Up      ToC       Page 29 
5.6.2.  Credit Aging

   A host ensures that the credit counters it maintains for its peers
   gradually decrease over time.  Such "credit aging" prevents a
   malicious peer from building up credit at a very slow speed and using
   this, all at once, for a severe burst of redirected packets.

   Credit aging may be implemented by multiplying credit counters with a
   factor, CreditAgingFactor (a fractional value less than one), in
   fixed-time intervals of CreditAgingInterval length.  Choosing
   appropriate values for CreditAgingFactor and CreditAgingInterval is
   important to ensure that a host can send packets to an address in
   state UNVERIFIED even when the peer sends at a lower rate than the
   host itself.  When CreditAgingFactor or CreditAgingInterval are too
   small, the peer's credit counter might be too low to continue sending
   packets until address verification concludes.

   The parameter values proposed in this document are as follows:

      CreditAgingFactor        7/8
      CreditAgingInterval      5 seconds

   These parameter values work well when the host transfers a file to
   the peer via a TCP connection, and the end-to-end round-trip time
   does not exceed 500 milliseconds.  Alternative credit-aging
   algorithms may use other parameter values or different parameters,
   which may even be dynamically established.

6.  Security Considerations

   The HIP mobility mechanism provides a secure means of updating a
   host's IP address via HIP UPDATE packets.  Upon receipt, a HIP host
   cryptographically verifies the sender of an UPDATE, so forging or
   replaying a HIP UPDATE packet is very difficult (see [RFC7401]).
   Therefore, security issues reside in other attack domains.  The two
   we consider are malicious redirection of legitimate connections as
   well as redirection-based flooding attacks using this protocol.  This
   can be broken down into the following:

      1) Impersonation attacks

         - direct conversation with the misled victim

         - man-in-the-middle (MitM) attack

Top      Up      ToC       Page 30 
      2) Denial-of-service (DoS) attacks

         - flooding attacks (== bandwidth-exhaustion attacks)

            * tool 1: direct flooding

            * tool 2: flooding by botnets

            * tool 3: redirection-based flooding

         - memory-exhaustion attacks

         - computational-exhaustion attacks

      3) Privacy concerns

   We consider these in more detail in the following sections.

   In Sections 6.1 and 6.2, we assume that all users are using HIP.  In
   Section 6.3, we consider the security ramifications when we have both
   HIP and non-HIP hosts.

6.1.  Impersonation Attacks

   An attacker wishing to impersonate another host will try to mislead
   its victim into directly communicating with them or carry out a MitM
   attack between the victim and the victim's desired communication
   peer.  Without mobility support, such attacks are possible only if
   the attacker resides on the routing path between its victim and the
   victim's desired communication peer or if the attacker tricks its
   victim into initiating the connection over an incorrect routing path
   (e.g., by acting as a router or using spoofed DNS entries).

   The HIP extensions defined in this specification change the situation
   in that they introduce an ability to redirect a connection, both
   before and after establishment.  If no precautionary measures are
   taken, an attacker could potentially misuse the redirection feature
   to impersonate a victim's peer from any arbitrary location.  However,
   the authentication and authorization mechanisms of the HIP base
   exchange [RFC7401] and the signatures in the UPDATE message prevent
   this attack.  Furthermore, ownership of a HIP association is securely
   linked to a HIP HI/HIT.  If an attacker somehow uses a bug in the
   implementation to redirect a HIP connection, the original owner can
   always reclaim their connection (they can always prove ownership of
   the private key associated with their public HI).

Top      Up      ToC       Page 31 
   MitM attacks are possible if an on-path attacker is present during
   the initial HIP base exchange and if the hosts do not authenticate
   each other's identities.  However, once such an opportunistic base
   exchange has taken place, a MitM attacker that comes later to the
   path cannot steal the HIP connection because it is very difficult for
   an attacker to create an UPDATE packet (or any HIP packet) that will
   be accepted as a legitimate update.  UPDATE packets use HMAC and are
   signed.  Even when an attacker can snoop packets to obtain the SPI
   and HIT/HI, they still cannot forge an UPDATE packet without
   knowledge of the secret keys.  Also, replay attacks on the UPDATE
   packet are prevented as described in [RFC7401].

6.2.  Denial-of-Service Attacks

6.2.1.  Flooding Attacks

   The purpose of a DoS attack is to exhaust some resource of the victim
   such that the victim ceases to operate correctly.  A DoS attack can
   aim at the victim's network attachment (flooding attack), its memory,
   or its processing capacity.  In a flooding attack, the attacker
   causes an excessive number of bogus or unwanted packets to be sent to
   the victim, which fills their available bandwidth.  Note that the
   victim does not necessarily need to be a node; it can also be an
   entire network.  The attack functions the same way in either case.

   An effective DoS strategy is distributed denial of service (DDoS).
   Here, the attacker conventionally distributes some viral software to
   as many nodes as possible.  Under the control of the attacker, the
   infected nodes (e.g., nodes in a botnet) jointly send packets to the
   victim.  With such an "army", an attacker can take down even very
   high bandwidth networks/victims.

   With the ability to redirect connections, an attacker could realize a
   DDoS attack without having to distribute viral code.  Here, the
   attacker initiates a large download from a server and subsequently
   uses the HIP mobility mechanism to redirect this download to its
   victim.  The attacker can repeat this with multiple servers.  This
   threat is mitigated through reachability checks and CBA.  When
   conducted using HIP, reachability checks can leverage the built-in
   authentication properties of HIP.  They can also prevent redirection-
   based flooding attacks.  However, the delay of such a check can have
   a noticeable impact on application performance.  To reduce the impact
   of the delay, CBA can be used to send a limited number of packets to
   the new address while the validity of the IP address is still in
   question.  Both strategies do not eliminate flooding attacks per se,
   but they preclude: (i) their use from a location off the path towards
   the flooded victim; and (ii) any amplification in the number and size

Top      Up      ToC       Page 32 
   of the redirected packets.  As a result, the combination of a
   reachability check and CBA lowers a HIP redirection-based flooding
   attack to the level of a direct flooding attack in which the attacker
   itself sends the flooding traffic to the victim.

6.2.2.  Memory/Computational-Exhaustion DoS Attacks

   We now consider whether or not the proposed extensions to HIP add any
   new DoS attacks (consideration of DoS attacks using the base HIP
   exchange and updates is discussed in [RFC7401]).  A simple attack is
   to send many UPDATE packets containing many IP addresses that are not
   flagged as preferred.  The attacker continues to send such packets
   until the number of IP addresses associated with the attacker's HI
   crashes the system.  Therefore, a HIP association SHOULD limit the
   number of IP addresses that can be associated with any HI.  Other
   forms of memory/computationally exhausting attacks via the HIP UPDATE
   packet are handled in the base HIP document [RFC7401].

   A central server that has to deal with a large number of mobile
   clients MAY consider increasing the SA lifetimes to try to slow down
   the rate of rekeying UPDATEs or increasing the cookie difficulty to
   slow down the rate of attack-oriented connections.

6.3.  Mixed Deployment Environment

   We now assume an environment with hosts that are both HIP and non-HIP
   aware.  Four cases exist:

   1.  A HIP host redirects its connection onto a non-HIP host.  The
       non-HIP host will drop the reachability packet, so this is not a
       threat unless the HIP host is a MitM that could somehow respond
       successfully to the reachability check.

   2.  A non-HIP host attempts to redirect their connection onto a HIP
       host.  This falls into IPv4 and IPv6 security concerns, which are
       outside the scope of this document.

   3.  A non-HIP host attempts to steal a HIP host's session (assume
       that Secure Neighbor Discovery is not active for the following).
       The non-HIP host contacts the service that a HIP host has a
       connection with and then attempts to change its IP address to
       steal the HIP host's connection.  What will happen in this case
       is implementation dependent, but such a request should fail by
       being ignored or dropped.  Even if the attack were successful,
       the HIP host could reclaim its connection via HIP.

Top      Up      ToC       Page 33 
   4.  A HIP host attempts to steal a non-HIP host's session.  A HIP
       host could spoof the non-HIP host's IP address during the base
       exchange or set the non-HIP host's IP address as its preferred
       address via an UPDATE.  Other possibilities exist, but a solution
       is to prevent the local redirection of sessions that were
       previously using an unverified address, but outside of the
       existing HIP context, into the HIP SAs until the address change
       can be verified.

6.4.  Privacy Concerns

   The exposure of a host's IP addresses through HIP mobility extensions
   may raise privacy concerns.  The administrator of a host may be
   trying to hide its location in some context through the use of a VPN
   or other virtual interfaces.  Similar privacy issues also arise in
   other frameworks such as WebRTC and are not specific to HIP.
   Implementations SHOULD provide a mechanism to allow the host
   administrator to block the exposure of selected addresses or address
   ranges.  While this issue may be more relevant in a host multihoming
   scenario in which multiple IP addresses might be exposed [RFC8047],
   it is worth noting also here that mobility events might cause an
   implementation to try to inadvertently use a locator that the
   administrator would rather avoid exposing to the peer host.

7.  IANA Considerations

   [RFC5206], obsoleted by this document, specified an allocation for a
   LOCATOR parameter in the "Parameter Types" subregistry of the "Host
   Identity Protocol (HIP) Parameters" registry, with a type value of
   193.  IANA has renamed the parameter to "LOCATOR_SET" and has updated
   the reference from [RFC5206] to this specification.

   [RFC5206], obsoleted by this document, specified an allocation for a
   LOCATOR_TYPE_UNSUPPORTED type in the "Notify Message Types" registry,
   with a type value of 46.  IANA has updated the reference from
   [RFC5206] to this specification.

8.  Differences from RFC 5206

   This section summarizes the technical changes made from [RFC5206].
   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.

Top      Up      ToC       Page 34 
   This document specifies extensions to the HIP Version 2 protocol,
   while [RFC5206] specifies extensions to the HIP Version 1 protocol.
   [RFC7401] documents the differences between these two protocol
   versions.

   [RFC5206] included procedures for both HIP host mobility and basic
   host multihoming.  In this document, only host mobility procedures
   are included; host multihoming procedures are now specified in
   [RFC8047].  In particular, multihoming-related procedures related to
   the exposure of multiple locators in the base exchange packets; the
   transmission, reception, and processing of multiple locators in a
   single UPDATE packet; handovers across IP address families; and other
   multihoming-related specifications have been removed.

   The following additional changes have been made:

   o  The LOCATOR parameter in [RFC5206] has been renamed to
      LOCATOR_SET.

   o  Specification text regarding the handling of mobility when both
      hosts change IP addresses at nearly the same time (a "double-jump"
      mobility scenario) has been added.

   o  Specification text regarding the mobility event in which the host
      briefly has an active new locator and old locator at the same time
      (a "make-before-break" mobility scenario) has been added.

   o  Specification text has been added to note that a host may add the
      source IP address of a received HIP packet as a candidate locator
      for the peer even if it is not listed in the peer's LOCATOR_SET,
      but that it should prefer locators explicitly listed in the
      LOCATOR_SET.

   o  This document clarifies that the HOST_ID parameter may be included
      in UPDATE messages containing LOCATOR_SET parameters, for the
      possible benefit of HIP-aware firewalls.

   o  The previous specification mentioned that it may be possible to
      include multiple LOCATOR_SET and ESP_INFO parameters in an UPDATE.
      This document only specifies the case of a single LOCATOR_SET and
      ESP_INFO parameter in an UPDATE.

   o  The previous specification mentioned that it may be possible to
      send LOCATOR_SET parameters in packets other than the UPDATE.
      This document only specifies the use of the UPDATE packet.

   o  This document describes a simple heuristic for setting the credit
      value for CBA.

Top      Up      ToC       Page 35 
   o  This specification mandates that a host must be able to receive
      and avoid reprocessing redundant LOCATOR_SET parameters that may
      have been sent in parallel to multiple addresses of the host.

9.  References

9.1.  Normative References

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

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
              RFC 7401, DOI 10.17487/RFC7401, April 2015,
              <http://www.rfc-editor.org/info/rfc7401>.

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

   [RFC8003]  Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
              Registration Extension", RFC 8003, DOI 10.17487/RFC8003,
              October 2016, <http://www.rfc-editor.org/info/rfc8003>.

   [RFC8004]  Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
              Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
              October 2016, <http://www.rfc-editor.org/info/rfc8004>.

9.2.  Informative References

   [CBA-MIPv6]
              Vogt, C. and J. Arkko, "Credit-Based Authorization for
              Mobile IPv6 Early Binding Updates", Work in Progress,
              draft-vogt-mobopts-credit-based-authorization-00, February
              2005.

   [RFC4225]  Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
              Nordmark, "Mobile IP Version 6 Route Optimization Security
              Design Background", RFC 4225, DOI 10.17487/RFC4225,
              December 2005, <http://www.rfc-editor.org/info/rfc4225>.

Top      Up      ToC       Page 36 
   [RFC5206]  Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko,
              "End-Host Mobility and Multihoming with the Host Identity
              Protocol", RFC 5206, DOI 10.17487/RFC5206, April 2008,
              <http://www.rfc-editor.org/info/rfc5206>.

   [RFC5207]  Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
              Firewall Traversal Issues of Host Identity Protocol (HIP)
              Communication", RFC 5207, DOI 10.17487/RFC5207, April
              2008, <http://www.rfc-editor.org/info/rfc5207>.

   [RFC8047]  Henderson, T., Ed., Vogt, C., and J. Arkko, "Host
              Multihoming with the Host Identity Protocol", RFC 8047,
              DOI 10.17487/RFC8047, February 2017,
              <http://www.rfc-editor.org/info/rfc8047>.

   [SIMPLE-CBA]
              Vogt, C. and J. Arkko, "Credit-Based Authorization for
              Concurrent Reachability Verification", Work in Progress,
              draft-vogt-mobopts-simple-cba-00, February 2006.

Acknowledgments

   Pekka Nikander and Jari Arkko originated this document; Christian
   Vogt and Thomas Henderson (editor) later joined as coauthors.  Greg
   Perkins contributed the initial text of the security section.  Petri
   Jokela was a coauthor of the initial individual submission.

   CBA was originally introduced in [SIMPLE-CBA], and portions of this
   document have been adopted from that earlier document.

   The authors thank Jeff Ahrenholz, Baris Boyvat, Rene Hummen, Miika
   Komu, Mika Kousa, Jan Melen, and Samu Varjonen for improvements to
   the document.

Top      Up      ToC       Page 37 
Authors' Addresses

   Thomas R. Henderson (editor)
   University of Washington
   Campus Box 352500
   Seattle, WA
   United States of America

   Email: tomhend@u.washington.edu


   Christian Vogt
   Independent
   3473 North First Street
   San Jose, CA  95134
   United States of America

   Email: mail@christianvogt.net


   Jari Arkko
   Ericsson
   Jorvas,  FIN-02420
   Finland

   Phone: +358 40 5079256
   Email: jari.arkko@piuha.net