Host Mobility with the Host Identity Protocol
obsoletes
- rfc-5206 — End-Host Mobility and Multihoming with the Host Identity Protocol
Extracted elements (26)
CBA was chosen over strict return-routability checks because it allows ongoing data transfer to proceed with minimal interruption while address verification completes. Rather than eliminating malicious redirection entirely, CBA prevents amplification, making redirection-based flooding no more effective than direct flooding that the attacker could perform anyway.
The locator concept generalizes beyond a plain IP address to include an ESP SPI (Locator Type 1) because in multihoming contexts certain IP addresses must be paired with specific SPIs to avoid violating the ESP anti-replay window. Plain IP addresses alone are insufficient to unambiguously describe packet handling below HIP when multiple SAs are in use.
This specification only defines procedures for a single LOCATOR_SET and single ESP_INFO parameter per UPDATE packet; reception of multiple LOCATOR_SET parameters in one packet, or in HIP packets other than UPDATE, is outside the scope of this specification.
A DEPRECATED address MUST NOT be changed to ACTIVE without first verifying its reachability.
A host MUST verify the reachability of any UNVERIFIED address. The status of a newly learned address MUST initially be set to UNVERIFIED unless it was advertised in an R1 packet as a new preferred locator.
A host receiving a UPDATE packet via an RVS MUST be prepared to process the FROM and RVS_HMAC parameters and MUST include a VIA_RVS parameter in the UPDATE reply that contains the ACK of the UPDATE SEQ.
An RVS supporting UPDATE forwarding MUST rewrite the UPDATE's IP source and destination addresses, recompute the IP checksum, and include FROM and RVS_HMAC parameters, mirroring how it handles I1 packets per RFC 8004.
Any UPDATE packet that includes a LOCATOR_SET parameter SHOULD include both an HMAC and a HIP_SIGNATURE parameter. If a HOST_ID parameter is also included, the receiving host MUST verify it matches the HOST_ID used to establish the association.
Credit-Based Authorization (CBA) MUST be used when a host sends data to an UNVERIFIED locator. If the credit counter is too low to cover the outbound packet size, the packet MUST be discarded or buffered; when sent to an UNVERIFIED locator, the credit counter MUST be reduced by the packet size.
Each Locator in a LOCATOR_SET MUST have a non-zero lifetime. A deprecated address SHOULD NOT be used as a destination if an alternate non-deprecated address is available.
Hosts MUST NOT announce broadcast or multicast addresses in LOCATOR_SETs; each received address MUST be checked to be a legal unicast or anycast address before being added to the locator data structure.
Hosts using link-local addresses as source addresses in their HIP handshakes SHOULD provide a globally routable address either in the initial handshake or via the LOCATOR_SET parameter, because link-local addresses may not be reachable by a mobile peer.
The host receiving a LOCATOR_SET MUST detect and avoid reprocessing a LOCATOR_SET parameter that is redundant with one recently received and processed, because the same UPDATE may be sent in parallel to multiple peer addresses including an RVS.
The LOCATOR_SET parameter is a critical parameter as defined in RFC 7401; it MUST be recognized and processed by the recipient.
When processing an UPDATE containing both ESP_INFO and LOCATOR_SET, a host SHOULD process the ESP_INFO before the LOCATOR_SET, since the ESP_INFO may introduce a new SPI value that Locator Type 1 entries reference.
Advertising IP addresses in LOCATOR_SET parameters may expose a host's location even when the host uses a VPN or virtual interface for privacy. Implementations SHOULD provide a mechanism for the administrator to block exposure of selected addresses or address ranges.
Credit-Based Authorization allows a host to send data to a peer's newly announced but UNVERIFIED locator, bounded by a credit counter that is incremented by inbound packet sizes and decremented by outbound packet sizes sent to the UNVERIFIED address. Credit aging periodically multiplies counters by CreditAgingFactor (7/8) every CreditAgingInterval (5 seconds) to prevent slow credit buildup for time-shifting attacks.
The basic mobility exchange (without rekeying) uses three UPDATE messages: mobile host sends UPDATE(ESP_INFO, LOCATOR_SET, SEQ); peer replies with UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST) containing a nonce challenge sent to the new address; mobile host completes with UPDATE(ACK, ECHO_RESPONSE) echoing the nonce.
The preferred locator is indicated by the P bit in the LOCATOR_SET Locator sub-parameter. By default, the IP addresses used in the HIP base exchange are the preferred locators for both signaling and user data. Multiple preferred locators of different Traffic Types may coexist; the more specific Traffic Type takes precedence.
Three Traffic Type values are defined: 0 for both HIP signaling and user data, 1 for signaling packets only, and 2 for data packets only. The P bit's scope is restricted to the corresponding Traffic Type; the more specific Traffic Type rule takes precedence when conflicts arise.
Two Locator Type values are defined: Type 0 is a 128-bit IPv6 address or IPv4-in-IPv6 format address (for non-ESP usage), and Type 1 is a 32-bit ESP SPI concatenated with a 128-bit IPv6 or IPv4-in-IPv6 address (for ESP-based usage).
IANA has renamed the LOCATOR parameter (type 193) to LOCATOR_SET in the HIP Parameter Types subregistry and updated the reference from RFC 5206 to this document. IANA has also updated the reference for the LOCATOR_TYPE_UNSUPPORTED Notify Message Type (value 46) from RFC 5206 to this document.
Impersonation attacks via forged LOCATOR_SET redirection are prevented by HIP UPDATE authentication: UPDATE packets use HMAC and carry a signature, so an attacker cannot create an accepted UPDATE without the target host's secret keys. Replay attacks on UPDATE are also prevented as described in RFC 7401.
Redirection-based flooding attacks are mitigated by the combination of address reachability checks and CBA. CBA prevents amplification by bounding redirected traffic to the volume recently received from the peer, lowering a redirection-based flood to the level of direct flooding. A HIP association SHOULD also limit the number of IP addresses associatable with any HI to prevent memory/computational exhaustion via crafted UPDATEs.
Each learned locator has one of three states: UNVERIFIED (reachability not yet confirmed), ACTIVE (reachability verified and not deprecated), or DEPRECATED (lifetime expired). Allowed transitions are UNVERIFIED→ACTIVE (reachability verified), UNVERIFIED→DEPRECATED (lifetime expires), ACTIVE→DEPRECATED (lifetime expires), ACTIVE→UNVERIFIED (local policy re-verification), and DEPRECATED→UNVERIFIED (new lifetime received). A DEPRECATED address MUST NOT transition directly to ACTIVE.
The LOCATOR_SET parameter (Type 193) encodes zero or more Locator sub-parameters, each containing an 8-bit Traffic Type, 8-bit Locator Type, 8-bit Locator Length (in 4-byte words), 7-bit Reserved field, 1-bit P (preferred) flag, a 32-bit Locator Lifetime in seconds, and a variable-length Locator field whose length is Locator Length × 4 octets.