RFC 8047
Host Multihoming with the Host Identity Protocol
RFC 8047: Host Multihoming with the Host Identity Protocol 🎀
okay bestie, this is RFC 8047 (part 1 of 6 💅) and the title says it all: Host Multihoming with the Host Identity Protocol. It's a Standards Track document from the IETF, dated February 2017, with ISSN 2070-1721. The authors are T. Henderson, Ed. (University of Washington), C. Vogt (Independent), and J. Arkko (Ericsson) 🫶. The header doesn't list anything it obsoletes or updates, so it's standing on its own 🦋.
Abstract ✨
this doc defines host multihoming extensions to the Host Identity Protocol (HIP), and it gets there by leveraging protocol pieces that were already built for host mobility. glow-up energy 🧚
Status of This Memo 📜
This is an Internet Standards Track document. ✨
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 💜
Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc8047.
Copyright Notice 🌈
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License.
Table of Contents 🗂️
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Multiple Addresses . . . . . . . . . . . . . . . . . 6
4.2.2. Multiple Security Associations . . . . . . . . . . . 6
4.2.3. Host Multihoming for Fault Tolerance . . . . . . . . 7
4.2.4. Host Multihoming for Load Balancing . . . . . . . . . 9
4.2.5. Site Multihoming . . . . . . . . . . . . . . . . . . 10
4.2.6. Dual-Host Multihoming . . . . . . . . . . . . . . . . 10
4.2.7. Combined Mobility and Multihoming . . . . . . . . . . 11
4.2.8. Initiating the Protocol in R1, I2, or R2 . . . . . . 11
4.2.9. Using LOCATOR_SETs across Addressing Realms . . . . . 13
4.3. Interaction with Security Associations . . . . . . . . . 13
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 14
5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 16
5.3. Verifying Address Reachability . . . . . . . . . . . . . 18
5.4. Changing the Preferred Locator . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 221. Introduction and Scope 🌸
okay so the Host Identity Protocol (HIP) [RFC7401] supports an architecture that decouples the transport layer (TCP, UDP, etc.) from the internetworking layer (IPv4 and IPv6) by using public/private key pairs, instead of IP addresses, as host identities. 🔑 With HIP, the overlying protocol sublayers (like transport-layer sockets and Encapsulating Security Payload (ESP) Security Associations (SAs)) get bound to representations of these host identities, and IP addresses are only used for packet forwarding 🚚. However, every host has to know at least one IP address where its peers can be reached. At first, those are the IP addresses used during the HIP base exchange.
one consequence of this decoupling is that new solutions to network-layer mobility and host multihoming become possible ✨. Basic host mobility is defined in [RFC8046] and covers the case where a host has a single address and changes its network point of attachment while wanting to keep the HIP-enabled security association. Host multihoming is kind of the dual case to mobility, since a host can have more than one network point of attachment at the same time 🦋. There are potentially many variations of host multihoming. [RFC8046] specifies the format of the HIP parameter (LOCATOR_SET parameter) used to convey IP addressing information between peers, the procedures for sending and processing this parameter to enable basic host mobility, and procedures for an address verification mechanism. The scope of this document covers messaging and elements of procedure for some basic host multihoming scenarios of interest 💅
another variation of multihoming that gets a LOT of attention is site multihoming 👀. Solutions for host multihoming in multihomed IPv6 networks were specified by the IETF shim6 working group. The Shim6 protocol [RFC5533] has lots of architectural similarities to HIP, but the security model and the protocol itself are different.
HIP can potentially be used with transports other than the ESP transport format [RFC7402], but this document mostly assumes ESP and leaves other transport formats for further study 🧚
finally, making underlying IP multihoming transparent to the transport layer has implications for how transport congestion control, path MTU selection, and Quality of Service (QoS) should respond 🌈. Transport-layer mobility triggers, and the proper transport response to a HIP multihoming address change, are outside the scope of this document 🙈
this specification relies on implementing Sections 4 ("LOCATOR_SET Parameter Format") and 5 ("Processing Rules") of [RFC8046] as a starting point for this implementation 🎀
2. Terminology and Conventions 💜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖
The following terms used in this document are defined in [RFC8046]: LOCATOR_SET, Locator, locator, Address, preferred locator, and Credit-Based Authorization.
3. Protocol Model 🍓
The protocol model for HIP support of host multihoming extends the model for host mobility described in Section 3 of [RFC8046]. This section only highlights the differences 🔍
in host multihoming, a host has multiple locators at the same time, rather than one after another like in mobility 🙌. Using the LOCATOR_SET parameter defined in [RFC8046], a host can tell its peers about additional (multiple) locators where it can be reached. When multiple locators are available and announced to the peer, a host can designate one of them as a "preferred" locator, which means the host prefers that its peer send packets to that address before trying an alternative address 💖. Although this document defines a basic mechanism for multihoming, it does not define all possible policies and procedures. For example, it doesn't say which locators to choose when more than one is available, how simultaneous mobility and multihoming operate, what source address selection policies apply (beyond those specified in [RFC6724]), or what the implications of multihoming are for transport protocols 🤷♀️
4. Protocol Overview 🦋
in this section, we briefly introduce a number of usage scenarios for HIP multihoming 🗺️. These scenarios assume that HIP is being used with the ESP transport [RFC7402], although other scenarios may be defined in the future. To understand these usage scenarios, the reader should be at least minimally familiar with the HIP protocol specification [RFC7401], the use of the ESP transport format [RFC7402], and the HIP mobility specification [RFC8046]. However, if you're (relatively) new to this, the most important thing to remember is that in HIP, the actual payload traffic is protected with ESP, and the ESP Security Parameter Index (SPI) acts as an index to the right host-to-host context 🔐✨
4.1. Background
okay so before we get into the multihoming drama, we need the basics 💅 Multihoming makes way more sense when you compare it to the non-multihoming case from the base protocol spec [RFC7401], so let's recap that real quick 🧚 In the base spec, when you use the ESP transport format, the HIP base exchange sets up a single SA in each direction. The IP addresses on those SAs are the same ones used to carry the HIP packets. For data traffic, you'll likely have an SPD and a SAD, because that's just how the IPsec architecture works 🎀
Here's the twist that makes HIP iconic: the host IDs are conceptually used as selectors in the SPD, not the IP addresses 🦋 On the outbound side, once SPD processing selects an outbound SA, the correct IP destination address for the peer also has to be assigned. So outbound SAs are conceptually tied to the peer IP address that must be used as the destination IP address below the HIP layer. On the inbound side, the IP addresses may be used as selectors in the SAD to look up the SA, but they aren't strictly required. The ESP SPI can be used alone 🙈 So, to sum it up: in the non-multihoming case, there's only one source IP address, one destination IP address, one inbound SA, and one outbound SA. Simple, bestie 💖
Next up is the HIP readdressing protocol [RFC8046], which is asymmetric. A mobile or multihomed host tells its peer about IP address changes on the affected SPIs ✨ That info rides in Locator fields inside a HIP parameter called a LOCATOR_SET. The HIP mobility specification [RFC8046] also covers how the LOCATOR_SET gets carried in a HIP UPDATE packet 📦
Quick mobility recap, since it's the foundation for multihoming 🌸 The core idea is that when active HIP-maintained SAs are in use, a host communicates a local IP address change to its peer. To pull that off, the IP address has to be conveyed. Any association between the IP address and an inbound SA (via the SPI index) may be conveyed too, and protection against flooding attacks must be ensured 🔥 An IP address gets tied to an SPI using a Locator Type of "1", which is a concatenation of an ESP SPI with an IP address.
Address verification is specified in [RFC8046], and it's expected that addresses learned in multihoming scenarios follow those same verification rules 👑 Sometimes the scenarios describe addresses as being in an ACTIVE, VERIFIED, or DEPRECATED state. From a host's point of view, newly learned addresses of the peer must be verified before they're put into active service, and addresses the peer removes get moved into a deprecated state 😭 Under limited conditions described in [RFC8046], an UNVERIFIED address may be used. Those conditions are the exception, not the vibe 🙃
With all that in mind, we can now describe an additional protocol for scenarios where one or both hosts have multiple IP addresses available. Honestly, this is the common case now for network-connected hosts on the Internet 🌈
4.2. Usage Scenarios
4.2.1. Multiple Addresses
Hosts may have multiple IP addresses in different address families (IPv4 and IPv6) and scopes available to support HIP messaging and HIP-enabled SAs 🦋 Those addresses can sit on a single network interface or on multiple network interfaces. How a host decides which of its possibly many addresses can support a HIP association is outside the scope of this document, so we're not getting into that here 🫶 Some IP addresses may also be held back from usage because of privacy, security, or cost considerations. Valid reasons, no notes 💅
When multiple IP addresses are shared with a peer, the procedures in the HIP mobility specification [RFC8046] let a host set a preferred locator ("P") bit. That's a way of requesting that one of the addresses be preferred for control- or data-plane traffic 🎀 It's also allowed to leave the preferred bit unset for all addresses, which lets the peer make the address selection decisions instead 🧚
Now, a heads-up for anyone using link-local addresses as source addresses in their HIP handshakes 👀 Those hosts may not be reachable by a mobile peer. So such hosts SHOULD provide a globally routable address, either in the initial handshake or via the LOCATOR_SET parameter. Don't leave your bestie stranded 😭
To support mobility, as described in the HIP mobility specification [RFC8046], the LOCATOR_SET may be sent in a HIP UPDATE packet 📦 To support multihoming, the LOCATOR_SET may also be sent in R1, I2, or R2 packets defined in the HIP protocol specification [RFC7401]. The reason to think about sending LOCATOR_SET parameters during the base exchange is to convey all usable addresses for fault-tolerance or load-balancing considerations ✨
4.2.2. Multiple Security Associations
When multiple addresses are available between peer hosts, the big question is whether to use one SA or multiple SAs 🤔 This specification's intent is to support different use cases, but to leave the policy decision up to the hosts. Main character hosts making their own calls 👑
If one host has n addresses and the other has m addresses, it's possible to set up as many as (n * m) SAs in each direction 🌸 In that case, every combination of source and destination IP addresses would get a unique SA. That lowers the chance of datagrams getting reordered on each SA, since ESP SAs may have an anti-replay window [RFC4303] that's sensitive to reordering 🔥 But the downside of a mesh of SAs is the signaling overhead needed (for exchanging UPDATE messages that convey ESP_INFO parameters) and the state maintenance required in the SPD/SAD. It's a lot, ngl 😩
For load balancing, when multiple paths are used in parallel, it may make sense to create different SAs for different paths 🦋 In this use case, a full mesh of 2 * (n * m) SAs may not be required. Still, it may be beneficial to create one SA pair per load-balanced path to avoid anti-replay window issues 💜
For fault tolerance, it's more likely that a single SA works, with multiple IP addresses associated with that SA 🧚 The alternative addresses only come into play when a failure is detected on the addresses in use. Techniques for path failure detection are outside the scope of this specification. An implementation may use ICMP interactions, reachability checks, or other means to detect the failure of a locator 🎀
In summary, whether and how a host decides to use extra addresses for load balancing or fault tolerance is outside the scope of the specification 🌈 (Though the academic literature on multipath TCP schedulers may give some guidance on designing that policy 📚) Still, in general, this document recommends that for fault tolerance, it's likely sufficient to use a single SA pair for all addresses. For load balancing, it recommends supporting a different SA pair for all active paths being balanced across. Two clean strategies, periodt 💅
4.2.3. Host Multihoming for Fault Tolerance
A host, mobile or stationary, may have more than one interface or global address 🌸 It can choose to notify the peer host about the extra interface or address by using the LOCATOR_SET parameter. That LOCATOR_SET parameter may be included in an I2, R1, or R2 packet, or it may be conveyed after the base exchange completes, in an UPDATE packet 📦
When more than one locator is provided to the peer host, the host MAY indicate which locator is preferred (the locator it prefers to receive traffic on) 🫶 By default, the address a host uses in the base exchange is its preferred locator (for the address family and address scope in use during the base exchange) until it's told otherwise. It's also possible that the host doesn't express any preferred locators at all 🤷♀️
In the multihoming case, the sender may also have multiple valid locators to source traffic from 🦋 In practice, a HIP association in a multihoming setup may have both a preferred peer locator and a preferred local locator. The host should try to use the peer's preferred locator unless policy or other circumstances prevent it 💖 A preferred local locator can be overridden if the source address selection rules on the destination address (the peer's preferred locator) suggest using a different source address ✨
The protocol may allow configurations with an asymmetric number of SAs between the hosts. For example, one host has two interfaces and two inbound SAs, while its peer has one interface and one inbound SA 👀 Even so, it's suggested that inbound and outbound SAs be created pairwise between hosts 💜 When an ESP_INFO arrives to rekey a particular outbound SA, the corresponding inbound SA should also be rekeyed at that time. Section 4.3 digs into the interaction between addresses and security associations in more detail, so go check that out next 🧚
Let's walk through two hosts, one single-homed and one multihomed 🌈 The multihomed host may decide to tell the single-homed host about its other address(es). It can do that as follows.
If the multihomed host wants to convey the additional address(es) for fault tolerance, it should include all of its addresses in Locator fields. Each one indicates the Traffic Type, Locator Type, and whether the locator is a preferred locator 🎀 If it wants to bind any particular address to an existing SPI, it may do that by using a Locator Type of "1" as specified in the HIP mobility specification [RFC8046]. It doesn't need to rekey the existing SA or request additional SAs at this time. Low drama, high reward 😌
Figure 1 illustrates this scenario. The conventions for message parameter notations in figures (use of parentheses and brackets) are defined in Section 2.2 of [RFC7401] 📐
Multihomed Host Peer Host
UPDATE(LOCATOR_SET, SEQ)
----------------------------------->
UPDATE(ACK)
<-----------------------------------
Figure 1: Basic Multihoming ScenarioIn this scenario, the peer host associates the multiple addresses with the SA pair between it and the multihomed host 🦋 It may also go through address verification procedures to move the addresses into the ACTIVE state. For inbound data traffic, it may choose to use the addresses along with the SPI as selectors 🧚 For outbound data traffic, it must choose among the available addresses of the multihomed host. It has to consider the state of address verification [RFC8046] for each address, and also consider available information about whether an address is in a working state. Careful choosing is giving responsible networking energy 💅🌸
4.2.4. Host Multihoming for Load Balancing ✨
okay bestie, so a multihomed host can set up brand new SA pairs for its new addresses to load balance 💅 but whether to load balance at all, and how to split traffic across the SAs, is out of scope for this doc 🙈. The move is to send a LOCATOR_SET with one or more ESP_INFO parameters to kick off new ESP SAs. Specifically, the multihomed host sends a LOCATOR_SET with an ESP_INFO, asking for a new SA by setting OLD SPI to zero and NEW SPI to the newly created incoming SPI. A Locator Type of "1" links the new address to the new SPI 🦋. The LOCATOR_SET also carries a second Type "1" Locator for the original address and SPI, so both are visible together.
Here's the lowkey important bit 🫶: to keep parameter processing simple and skip extra protocol extensions just for removing locators, each LOCATOR_SET parameter MUST list all locators in use on a connection (a complete listing of inbound locators and SPIs for the host). After that, the multihomed host waits for a matching ESP_INFO (new outbound SA) from the peer and an ACK of its own UPDATE. And just like in the mobility case, the peer host must perform an address verification before actively using the new address 🔥.
Figure 2 shows how it all plays out 👑:
Multihomed Host Peer Host
UPDATE(ESP_INFO, LOCATOR_SET, SEQ, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->Figure 2: Host Multihoming for Load Balancing
In multihoming scenarios, it's super important that hosts receiving UPDATEs match them up correctly with the destination address used in the packet carrying the UPDATE 🎀. When a host processes inbound LOCATOR_SETs that establish new security associations on an interface with multiple addresses, it uses the destination address of the UPDATE containing the LOCATOR_SET as the local address that the LOCATOR_SET plus ESP_INFO is targeted at. Why? Because hosts may send UPDATEs with the same (locator) IP address to different peer addresses. That creates multiple inbound SAs that are implicitly affiliated with different peer source addresses 🧚.
4.2.5. Site Multihoming 🌸
A host may have an interface with multiple globally routable IP addresses. This can happen because the site has multiple upper Internet Service Providers, or just because the site gives every host both IPv4 and IPv6 addresses. The host should stay reachable at all or any subset of the currently available globally routable addresses, no matter how those addresses were provided 💖.
This case is handled the same way as the different-IP-addresses case described above in Sections 4.2.3 and 4.2.4. Also, a single interface may have addresses that correspond to site multihoming, while the host itself also has multiple network interfaces 🍓.
Note that a host can be multihomed and mobile at the same time 🌈. A multihomed host may also want to protect the location of some of its interfaces while revealing the real IP address of some others 🙈.
This document doesn't present additional site multihoming extensions to HIP. Those extensions are for further study 🔮.
4.2.6. Dual-Host Multihoming 👯♀️
Let's look at the case where both hosts are multihomed and want to tell the peer about an additional address after the base exchange completes 💅. Both hosts might choose to simply announce the second address in a LOCATOR_SET parameter using an UPDATE message exchange. Or one or both hosts might decide to ask for new SA pairs to be created using the newly announced address. If both hosts request this, the result is a full mesh of SAs, as shown in Figure 3 🕸️✨.
Here's the walkthrough. Say host1, which used address addr1a in the base exchange to set up SPI1a and SPI2a, wants to add address addr1b. It sends an UPDATE with a LOCATOR_SET (containing the address addr1b) to host2, using destination address addr2a, plus a new ESP_INFO. A new set of SPIs gets added between hosts 1 and 2 (call them SPI1b and SPI2b; they're not shown in the figure) 🦋. Next, host2 decides to add addr2b to the relationship. Host2 MUST select one of host1's addresses to send its UPDATE to. Hmm, wait, let me be precise here: the original says "must select," so it's a must in lowercase-land, and host2 must select one of host1's addresses towards which to initiate an UPDATE. It may choose to initiate an UPDATE to addr1a, addr1b, or both. If it sends to both, a full mesh (four SA pairs) of SAs exists between the two hosts. This is the most general case, and the protocol is flexible enough to accommodate this choice 👑.
-<- SPI1a -- -- SPI2a ->-
host1 < > addr1a <---> addr2a < > host2
->- SPI2a -- -- SPI1a -<-
addr1b <---> addr2a (second SA pair)
addr1a <---> addr2b (third SA pair)
addr1b <---> addr2b (fourth SA pair)Figure 3: Dual-Multihoming Case in which Each Host Uses LOCATOR_SET to Add a Second Address
4.2.7. Combined Mobility and Multihoming 🚀
Mobile hosts may be mobile and multihomed at the same time, meaning they have multiple mobile interfaces 📱. And if the interfaces use different access technologies, it's pretty likely that one interface stays stable (retaining its current IP address) while others go through mobility (an IP address change) 💫.
The use of LOCATOR_SET plus ESP_INFO should be flexible enough to handle most of these scenarios. More complicated scenarios haven't been studied so far 🧐.
4.2.8. Initiating the Protocol in R1, I2, or R2 💌
A Responder host MAY include a LOCATOR_SET parameter in the R1 packet it sends to the Initiator. This parameter MUST be protected by the R1 signature 🔐. 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 🏃♀️. The I1 destination address and the new preferred locator may be identical. All new non-preferred locators must still undergo address verification once the base exchange completes 🧾. It's also possible for the host to send the LOCATOR_SET without any preferred bits set. In that case, the exchange continues as normal, and the newly learned addresses sit in an UNVERIFIED state at the initiator 🫠.
Initiator Responder
R1 with LOCATOR_SET
<-----------------------------------
record additional addresses
change Responder address
I2 sent to newly indicated preferred address
----------------------------------->
(process normally)
R2
<-----------------------------------
(process normally, later verification of non-preferred locators)Figure 4: LOCATOR_SET Inclusion in R1
An Initiator MAY include one or more LOCATOR_SET parameters in the I2 packet, whether or not there was a LOCATOR_SET parameter in the R1 🎀. These parameters MUST be protected by the I2 signature. Even if the I2 packet contains LOCATOR_SET parameters, the Responder MUST still send the R2 packet to the source address of the I2 📮. The new preferred locator, if set, SHOULD be identical to the I2 source address. If the I2 packet contains LOCATOR_SET parameters, all new locators must undergo address verification as usual, and the ESP traffic that follows should use the preferred locator 💅.
Initiator Responder
I2 with LOCATOR_SET
----------------------------------->
(process normally)
record additional addresses
R2 sent to source address of I2
<-----------------------------------
(process normally)Figure 5: LOCATOR_SET Inclusion in I2
The I1 and I2 may arrive from different source addresses if the LOCATOR_SET parameter is present in R1 🌀. In this case, implementations that use multiple pre-created R1s simultaneously, indexed by Initiator IP addresses, may inadvertently fail the puzzle solution of I2 packets because of a perceived puzzle mismatch 😭. See, for instance, the example in Appendix A of [RFC7401]. As a solution, the Responder's puzzle indexing mechanism must be flexible enough to accommodate the situation where R1 includes a LOCATOR_SET parameter 🧩.
Finally, the R2 may be used to carry the LOCATOR_SET parameter. In that case, the LOCATOR_SET is covered by the HIP_MAC_2 and HIP_SIGNATURE 🔏. Putting LOCATOR_SET in R2 instead of R1 may have some advantages when a host prefers not to divulge additional locators until after the I2 is successfully processed 🤫.
When the LOCATOR_SET parameter is sent in an UPDATE packet, the receiver responds with an UPDATE acknowledgment ✅. When the LOCATOR_SET parameter is sent in an R1, I2, or R2 packet, the base exchange retransmission mechanism confirms its successful delivery 🌷.
4.2.9. Using LOCATOR_SETs across Addressing Realms 🌍
HIP associations can use these mechanisms to migrate their HIP associations and security associations from addresses in the IPv4 addressing realm to IPv6, or vice versa 🦋. It may be possible for a state to arise in which both hosts are only using locators in different addressing realms. But in that case, some type of mechanism for interworking between the realms must be employed. Those techniques are outside the scope of the present text 🙃.
4.3. Interaction with Security Associations 🔐
Okay bestie, so a host can set up as many security associations (or SPIs) with a peer as it wants 💜. The main reason to have multiple SPIs with the same peer is to group addresses into collections that are likely to experience fate sharing, or to do load balancing ⚖️.
Here's the big thing about HIP SAs: the inbound IP address is not used to look up the incoming SA 👀. But different source and destination addresses usually mean different paths, with different latencies. If packets came in through some random destination IP address (or path) for a given SPI, the reordering from those latency differences could push some packets outside of the ESP anti-replay window 😭. So HIP gives you a way to affiliate destination addresses with inbound SPIs, for when anti-replay windows might get violated 🛡️. That means a given inbound SPI has an "affinity" for certain inbound IP addresses, and that affinity gets communicated to the peer host 🫶. Each physical interface SHOULD have a separate SA, unless the ESP anti-replay window is extended or disabled.
Even when the destination addresses for a particular SPI stay the same, using different source interfaces can still push packets outside of the ESP anti-replay window 🙈. The path is often affected by the source address or interface you use, after all. A host has no way to control which source interface a peer uses to send its packets on a given SPI, so it's kind of out of your hands 💀. A host SHOULD consistently use the same source interface and address when sending to a particular destination IP address and SPI. And since that's the case, a host may find it useful to change its SPI, or at least reset its ESP anti-replay window, when the peer host readdresses 🦋.
5. Processing Rules ✨
The basic processing rules for the LOCATOR_SET parameter are laid out in [RFC8046] 📖. This document is all about the multihoming-specific rules 🌸.
5.1. Sending LOCATOR_SETs
Deciding when to send a LOCATOR_SET, and which addresses to include, is a local policy issue 💅. [RFC8046] recommends that a host "send a LOCATOR_SET whenever it recognizes a change of its IP addresses in use on an active HIP association and [when it] assumes that the change is going to last at least for a few seconds." It's also possible to hold off on exposing extra locators to the peer, and to send data from locators that haven't been announced yet, which can come up in certain mobility or multihoming situations 🧚.
When a host decides to tell its peers about changes in its IP addresses, it has to decide how to group the various addresses with SPIs 🍓. If hosts are deployed somewhere with HIP-aware NATs and firewalls (which may perform parameter inspection), and different devices like that might sit on different paths, hosts can take that into account when grouping addresses. They may even send the same LOCATOR_SET in separate UPDATEs on the different paths 🌈. Still, more detailed guidelines for operating around those HIP-aware NATs and firewalls are a topic for further study 🔭. Since each SPI is tied to a different security association, the grouping policy may also be based on ESP anti-replay protection considerations 🛡️. In the typical case, just basing the grouping on the actual kernel-level physical and logical interfaces may be the best policy 👑. The grouping policy is outside the scope of this document, so that's on you, bestie 💜.
Locators that correspond to tunnel interfaces (like IPsec tunnel interfaces or Mobile IP home addresses) or other virtual interfaces MAY be announced in a LOCATOR_SET 🎀. Still, implementations SHOULD avoid announcing those locators as preferred locators if a more direct path is available by preferring locators from non-tunneling interfaces that give a more direct path to the HIP peer 🚀.
[RFC8046] says hosts MUST NOT announce broadcast or multicast addresses in LOCATOR_SETs. That's a hard no 🙅♀️.
Link-local addresses MAY be announced to peers that are known to be neighbors on the same link, such as when the IP destination address of a peer is also link local 🧸. Announcing link-local addresses in this case is a policy decision. Link-local addresses used as preferred locators will create reachability problems when the host moves to another link, so keep that in mind 😭. Either way, link-local addresses MUST NOT be announced to a peer unless that peer is known to be on the same link 🔒.
Once the host has decided on the groups and how addresses map to the SPIs, it creates a LOCATOR_SET parameter that completely represents the addresses and associated SPIs meant for active use 💖. We're now going to walk through a few cases from Section 4 ✨. We assume that the Traffic Type for each locator is set to "0" (other values for Traffic Type may be specified in documents that split the HIP control plane from data-plane traffic). Other mobility and multihoming cases are possible, but they're left for further experimentation 🧪.
- Host multihoming (addition of an address). We only describe the simple case of adding an extra address to a (previously) single-homed, non-mobile host 🌱. The host MAY choose to simply announce this address to the peer, for fault tolerance. To do this, the multihomed host creates a LOCATOR_SET parameter that includes the existing address and SPI as a Type
"1"Locator, and the new address as a Type"0"Locator. It sends this in an UPDATE message with the SEQ parameter, which the peer acknowledges 💌. - The host MAY set up a new SA pair between this new address and an address of the peer host 🦋. To do this, the multihomed host creates a new inbound SA and a new SPI. For the outgoing UPDATE message, it inserts an ESP_INFO parameter with an OLD SPI field of
"0", a NEW SPI field matching the new SPI, and a KEYMAT Index selected by local policy. The host adds to the UPDATE message a LOCATOR_SET with two Type"1"Locators: the original address and SPI active on the association, and the new address and new SPI being added (with the SPI matching the NEW SPI in the ESP_INFO). The preferred bit SHOULD be set depending on policy, so the peer knows which of the two locators is preferred 👑. The UPDATE also contains a SEQ parameter and, optionally, a DIFFIE_HELLMAN parameter, and it follows the rekeying procedures with respect to this new address 🔑. The UPDATE message SHOULD be sent to the peer's preferred address, with a source address matching the new locator 💫.
Sending multiple LOCATOR_SETs is unsupported, so don't even try it 🙅♀️. Also, including a LOCATOR_SET in an R1 packet requires the use of Type "0" Locators, since no SAs are set up at that point 🥺.
5.2. Handling Received LOCATOR_SETs 💖
Okay bestie, first up: a host SHOULD be ready to receive a LOCATOR_SET parameter in R1, I2, R2, and UPDATE packets. Every one of those is a valid place for it to show up 💅
This doc describes sending both ESP_INFO and LOCATOR_SET parameters in an UPDATE. ESP_INFO shows up when there's a need to rekey or key a new SPI 🔑. It can also be included just for the possible benefit of HIP-aware middleboxes, which is such a cute little bonus 🎀. The LOCATOR_SET parameter is the full map of locators the host wants to make active or keep active for the HIP association 🗺️
Processing a LOCATOR_SET depends on which packet type it's in 👀. Here we only cover the case where ESP_INFO is present and a single LOCATOR_SET and a single ESP_INFO are sent together in an UPDATE message. Everything else is "for further study," so that's a future adventure 🧚. The steps below walk through each of the cases from Section 5.1.
Processing ESP_INFO and LOCATOR_SET is meant to be modular, so it can grow later to support multiple ESP_INFO and/or multiple LOCATOR_SET parameters 🌈. A host SHOULD process the ESP_INFO first, before the LOCATOR_SET. Why? Because the ESP_INFO might carry a new SPI value mapped to an existing SPI, while a Type "1" Locator only contains a reference to the new SPI 🧩.
When a host gets a validated HIP UPDATE with a LOCATOR_SET and ESP_INFO parameter, it processes the ESP_INFO like this 💌. The ESP_INFO parameter tells the host whether an SA is being rekeyed, created, deprecated, or just identified for the benefit of middleboxes. The host looks at the OLD SPI and NEW SPI values in the ESP_INFO parameter:
- (no rekeying) If the OLD SPI is equal to the NEW SPI and both correspond to an existing SPI, the
ESP_INFOis gratuitous (provided for middleboxes), and no rekeying is necessary. 😌 - (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. The host follows the 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_SETparameter will reference this new SPI instead of the old SPI 👉 - (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, so the receiving host must create a new SA and respond with an UPDATE ACK 🙌
- (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 happened and processing of the UPDATE stops 🚨. Yikes, no cap.
Next up, the locators in the LOCATOR_SET parameter get processed 🔍. For each locator listed, check that the address is a legal unicast or anycast address. 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 for the host to run HIP with itself 🪞.
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 it's already bound, its lifetime gets updated ⏳. If the address status is DEPRECATED, the status changes to UNVERIFIED. If the address isn't already bound, it gets added and its status is set to UNVERIFIED 🆕. If there are leftover addresses for the SPI that were NOT listed in the LOCATOR_SET parameter, the host sets the status of those addresses to DEPRECATED 🥀
For each Type "0" address listed in the LOCATOR_SET parameter, if the status is DEPRECATED, or the address wasn't previously known, the status changes to UNVERIFIED 🔁. The host MAY choose to associate this address with one or more SAs 💫. Which SAs it picks is a local policy decision, unless the peer has indicated that the address is preferred. In that case, the address should be put into use on an SA that's prioritized in the security policy database 🏆.
So 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 that weren't listed in the LOCATOR_SET parameter have a state of DEPRECATED 📋. Clean!
Once the host has processed the locators, if the LOCATOR_SET parameter has a new preferred locator, the host SHOULD start a change of the preferred locator 🌟. This needs the host to verify reachability of the associated address first, and only then switch the preferred locator. See Section 5.4 for the details 🦋.
If a host receives a locator with an unsupported Locator Type, and that locator is also declared as the peer's preferred locator, the host SHOULD send a NOTIFY error. That NOTIFY error has a Notify Message Type of LOCATOR_TYPE_UNSUPPORTED, and its Notification Data field contains the locator(s) the receiver failed to process 🚩. Otherwise, a host MAY send a NOTIFY error if a (non-preferred) locator with an unsupported Locator Type shows up in a LOCATOR_SET parameter 🤷♀️.
5.3. Verifying Address Reachability 🔎
Address verification is defined in [RFC8046]. Go read that one for the full scoop 📖
When address verification is in progress for a new preferred locator, the host SHOULD select a different locator listed as ACTIVE, if one is available, to keep communications going until address verification finishes 🛣️. Alternatively, the host MAY use the new preferred locator while it's in UNVERIFIED status, to the extent Credit-Based Authorization permits 🎟️. Credit-Based Authorization is explained in [RFC8046]. Once address verification succeeds, the status of the new preferred locator changes to ACTIVE 🥳
5.4. Changing the Preferred Locator 🔀
A host MAY want to change its preferred outgoing locator for different reasons 💭. For example, traffic information or ICMP error messages might show that the currently used preferred address has become unreachable 🙀. Another reason could be receiving a LOCATOR_SET parameter that has the preferred bit set 🎯.
To change the preferred locator, the host kicks off this procedure 🪄:
- If the new preferred locator has ACTIVE status, the preferred locator changes and the procedure succeeds. Easy win 🏅
- If the new preferred locator has UNVERIFIED status, the host starts verifying 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 it's in UNVERIFIED status, to the extent Credit-Based Authorization permits 🎫. Once address verification succeeds, the status of the new preferred locator changes to ACTIVE, and its use is no longer governed by Credit-Based Authorization 🎉
- If the peer host hasn't indicated a preference for any address, the host picks one of the peer's ACTIVE addresses randomly or according to policy 🎲. This case might come up if, for example, ICMP error messages deprecate the preferred locator but the peer hasn't indicated a new preferred locator yet 🙈
- If the new preferred locator has DEPRECATED status and there's at least one non-deprecated address, the host selects one of the non-deprecated addresses as the new preferred locator and continues 🫶. If the selected address is UNVERIFIED, the address verification procedure described above applies 🔁
6. Security Considerations 🔐
okay bestie, this is the serious part 😭 this doc takes the host mobility stuff from [RFC8046] and extends it to cover host multihoming too, so a lot of the same security considerations for mobility also apply to multihoming 💅. [RFC8046] explains how HIP host mobility is resistant to different types of impersonation attacks and denial-of-service (DoS) attacks 🛡️.
the security considerations here are pretty similar to [RFC8046] because the strong authentication capabilities for mobility also carry over to end-host multihoming 🫶. [RFC4218] gives a threat analysis for IPv6 multihoming. the rest of this section first explains how HIP host multihoming handles those previously described threats, and then it covers some extra security stuff 🧚.
the high-level threats in [RFC4218] involve redirection attacks for packet recording, data manipulation, and availability 👀. there are a few types of attackers to think about: on-path attackers, off-path attackers, and malicious hosts.
[RFC4218] also points out that in identifier/locator split solutions like HIP, application security mechanisms should be tied to the identifier, not the locator, and that attacks on the identifier mechanism and on the mechanism binding locators to the identifier are a concern 🪪. this doc does not consider the former issue (application-layer security bindings) to be in scope 🙅. the latter issue (locator bindings to identifier) is directly addressed by the cryptographic protections of the HIP protocol, since the locators associated to an identifier are listed in HIP packets that are signed using the identifier key 🔑.
Section 3.1 of [RFC4218] lists several classes of security configurations in use across the Internet 📚. HIP maps to the fourth (strong identifier) and fifth ("leap-of-faith") categories, and the latter is tied to the optional opportunistic mode of HIP operation 🌈. the rest of Section 3 describes existing security problems on the Internet and says the goal of a multihoming solution isn't to solve them specifically, but to not make any of them worse 🙏. HIP multihoming should not increase the severity of the identified risks. one concern for both HIP mobility and multihoming is how easily the mechanisms could be misused through flooding-based redirections from a malicious host 🚨. the mechanisms described in [RFC8046] for address verification are important in this regard.
now for the new types of threats that multihoming brings in (Section 4 of [RFC4218]) 🆕. HIP multihoming should not introduce new concerns. classic and premeditated redirection are prevented by the strong authentication in HIP messages 💪. third-party DoS attacks are prevented by the address verification mechanism. replay attacks can be avoided by using replay protection in ESP SAs 🔁. also, accepting packets from unknown locators is protected either by the strong authentication in the HIP control packets or by the ESP-based encryption used for data packets 🔐.
the HIP mechanisms are designed to limit the ability to introduce DoS on the mechanisms themselves (Section 7 of [RFC4218]) 🛡️. care is taken in the HIP base exchange to avoid creating state or doing much work before hosts can authenticate one another ⏳. a malicious host involved in HIP multihoming with another host might try to misuse the multihoming mechanisms by, for instance, increasing the state required or inducing a resource limitation attack by sending too many candidate locators to the peer host 😤. therefore, implementations supporting the multihoming extensions should consider avoiding accepting large numbers of peer locators and rate limiting any UPDATE messages being exchanged 🚦.
the exposure of a host's IP addresses through HIP mobility and multihoming extensions may raise the following privacy concern 🙈. the administrator of a host may be trying to hide its location in some context by using a VPN or other virtual interfaces 🕵️♀️. similar privacy issues also come up in other frameworks such as WebRTC and aren't specific to HIP. Implementations SHOULD provide a mechanism to allow the host administrator to block the exposure of selected addresses or address ranges 🧱.
finally, some implementations of VPN tunneling have experienced instances of 'leakage' of flows that were meant to be protected by a security tunnel but were instead sent in the clear 😱. this can happen perhaps because some of the addresses used fall outside the range of addresses configured for the tunnel in the security policy or association database. Implementors are advised to take steps to ensure that the usage of multiple addresses between hosts does not cause accidental leakage of some data session traffic outside of the ESP-protected envelope 🚨.
7. References 📚
7.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>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
[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>.
[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility
with the Host Identity Protocol", RFC 8046,
DOI 10.17487/RFC8046, February 2017,
<http://www.rfc-editor.org/info/rfc8046>.7.2. Informative References
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218,
October 2005, <http://www.rfc-editor.org/info/rfc4218>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
June 2009, <http://www.rfc-editor.org/info/rfc5533>.Acknowledgments 🫶
this document contains content that was originally included in RFC 5206 💌. Pekka Nikander and Jari Arkko originated RFC 5206, and Christian Vogt and Thomas Henderson (editor) later joined as coauthors. also in RFC 5206, Greg Perkins contributed the initial draft of the security section, and Petri Jokela was a coauthor of the initial individual submission.
the authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan Melen for many improvements to the document 🙌. concepts from a paper on host multihoming across address families, by Samu Varjonen, Miika Komu, and Andrei Gurtov, contributed to this revised specification 📄.
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📦 where this page comes from
- ietf: rfc8047 2017-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms