Host Multihoming with the Host Identity Protocol
Extracted elements (29)
Each LOCATOR_SET provides a complete listing of all active locators rather than differential updates, simplifying parameter processing and eliminating the need for explicit protocol extensions to remove individual locators.
For fault tolerance, a single SA pair for all addresses is generally sufficient. For load balancing across parallel paths, a separate SA pair per active path is recommended because mixing traffic from different paths on a single SA may cause packets to fall outside the ESP anti-replay window due to differing path latencies.
Including LOCATOR_SET in R2 rather than R1 has the advantage that the host avoids divulging additional locators until after the I2 is successfully processed, providing a privacy benefit; the tradeoff is slightly delayed locator discovery compared to announcing in R1.
HIP associations can use the multihoming LOCATOR_SET mechanism to migrate between IPv4 and IPv6 addressing realms. However, if both hosts end up with locators only in different realms, an interworking mechanism must be employed; such techniques are outside the scope of this document.
Implementations that simultaneously use multiple pre-created R1 packets indexed by Initiator IP addresses may inadvertently fail the puzzle solution of I2 packets when R1 includes a LOCATOR_SET, because the I1 and I2 may arrive from different source addresses. The Responder's puzzle indexing mechanism must be flexible enough to accommodate this case.
A host SHOULD be prepared to receive a LOCATOR_SET parameter in R1, I2, R2, and UPDATE packets.
A host SHOULD consistently use the same source interface and address when sending to a particular destination IP address and SPI, because path is often determined by source address and differing paths can cause anti-replay window violations.
A host SHOULD first process the ESP_INFO before the LOCATOR_SET in a received UPDATE, since the ESP_INFO may contain a new SPI value mapped to an existing SPI while a Type 1 Locator only contains a reference to the new SPI.
A LOCATOR_SET parameter included in an R1 packet MUST be protected by the R1 signature. A LOCATOR_SET parameter included in an I2 packet MUST be protected by the I2 signature.
Each LOCATOR_SET parameter MUST list all locators in use on a connection (a complete listing of inbound locators and SPIs for the host). This avoids the need for explicit protocol extensions to remove locators.
Each physical interface SHOULD have a separate SA unless the ESP anti-replay window is extended or disabled, to prevent out-of-order packets arriving via different paths from falling outside the anti-replay window.
Even if the I2 packet contains LOCATOR_SET parameters, the Responder MUST still send the R2 packet to the source address of the I2.
Hosts MUST NOT announce broadcast or multicast addresses in LOCATOR_SETs. Link-local addresses MUST NOT be announced to a peer unless that peer is known to be on the same link.
Hosts using link-local addresses as source addresses in HIP handshakes SHOULD provide a globally routable address either in the initial handshake or via the LOCATOR_SET parameter, since such hosts may not be reachable by a mobile peer.
If the R1 packet contains LOCATOR_SET parameters with a new preferred locator, the Initiator SHOULD directly set the new preferred locator to status ACTIVE without performing address verification first, and it MUST send the I2 packet to the new preferred locator.
Implementations SHOULD provide a mechanism to allow the host administrator to block the exposure of selected addresses or address ranges, addressing privacy concerns about IP address disclosure through multihoming.
Implementations supporting multihoming extensions SHOULD avoid accepting large numbers of peer locators and SHOULD rate-limit UPDATE messages exchanged, to prevent resource-exhaustion attacks by a malicious multihomed peer.
When address verification is in progress for a new preferred locator, the host SHOULD select a different locator listed as ACTIVE to continue communications until verification completes. Alternatively, the host MAY use the new preferred locator while UNVERIFIED to the extent Credit-Based Authorization permits.
Advertising a host's IP addresses through HIP multihoming extensions may reveal its location even when the administrator intends to conceal it via VPN or virtual interfaces. Similar issues arise in WebRTC. Implementations SHOULD allow administrators to block exposure of selected addresses.
ESP_INFO processing when received with LOCATOR_SET in an UPDATE covers four cases: (1) OLD==NEW existing SPI is gratuitous for middleboxes; (2) OLD!=NEW non-zero means rekeying existing SA; (3) OLD SPI zero means new SA creation; (4) NEW SPI zero means SA deprecation, setting all uniquely bound locators to DEPRECATED.
For host multihoming for fault tolerance, a single SA pair is used for all addresses. The multihomed host creates a LOCATOR_SET including the existing address and SPI as a Type 1 Locator and the new address as a Type 0 Locator, sent in an UPDATE with SEQ, acknowledged by the peer.
For load balancing, a host sends LOCATOR_SET with ESP_INFO in an UPDATE to create new SA pairs. A new SA is requested by setting OLD SPI to zero and NEW SPI to the newly created incoming SPI, with a Type 1 Locator associating the new address with the new SPI.
LOCATOR_SET may be sent in R1, I2, or R2 packets (in addition to UPDATE packets defined in RFC 8046), enabling multihoming address advertisement during the HIP base exchange itself for fault-tolerance or load-balancing purposes.
When processing inbound LOCATOR_SETs that establish new SAs on an interface with multiple addresses, a host uses the destination address of the UPDATE containing the LOCATOR_SET as the local address to which the LOCATOR_SET plus ESP_INFO is targeted, because a host may send UPDATEs from the same locator IP to different peer addresses.
A malicious host engaged in HIP multihoming may attempt resource-exhaustion attacks by sending excessive candidate locators, inducing state bloat in the peer's SPD/SAD. Implementations should rate-limit UPDATEs and cap the number of accepted peer locators.
HIP multihoming is resistant to redirection attacks because locators are listed in HIP packets signed using the host's identifier key, cryptographically binding locators to the host identity. Address verification (from RFC 8046) prevents third-party flooding-based DoS redirection attacks.
VPN tunnel leakage risk: use of multiple addresses in HIP multihoming may cause data sessions intended to be ESP-protected to be sent in the clear if some addresses fall outside the configured security policy or association database range. Implementors must prevent such leakage.
Locators transition through states UNVERIFIED, ACTIVE, and DEPRECATED. Newly learned addresses start UNVERIFIED; after address verification they become ACTIVE; addresses not listed in a received LOCATOR_SET are set to DEPRECATED; a DEPRECATED address reappears as UNVERIFIED when re-listed in a LOCATOR_SET.
Preferred locator change procedure: (1) if ACTIVE, change immediately; (2) if UNVERIFIED, start verification and use another ACTIVE locator meanwhile or use UNVERIFIED under Credit-Based Authorization; (3) if no preference indicated, pick randomly from ACTIVE; (4) if DEPRECATED and non-deprecated exists, pick non-deprecated (applying verification if UNVERIFIED).