RFC 5206
End-Host Mobility and Multihoming with the Host Identity Protocol
RFC 5206: End-Host Mobility and Multihoming with the Host Identity Protocol 💖
okay bestie, this is RFC 5206 (part 1 of 9) 🦋 and it's so cute. The title is End-Host Mobility and Multihoming with the Host Identity Protocol. It's from the Network Working Group and was published in April 2008. It's labelled Experimental, which means "try it, test it, tell us what breaks," not an Internet standard 🧪. The authors are P. Nikander (Ericsson Research NomadicLab), T. Henderson, Ed. (The Boeing Company), C. Vogt (Ericsson Research NomadicLab), and J. Arkko (Ericsson Research NomadicLab) 👑. The header doesn't list anything it obsoletes or updates, so there's no drama there 🫶
Status of This Memo ✨
This memo defines an Experimental Protocol for the Internet community, and it does not specify an Internet standard of any kind 🧪. Discussion and suggestions for improvement are requested, so bring your ideas. Distribution of this memo is unlimited 💜
Abstract 🦋
okay so this doc adds mobility and multihoming extensions to the Host Identity Protocol (HIP) 🌸. The main thing is a general LOCATOR parameter for HIP messages, which lets a HIP host tell its peers about alternate addresses where it can be reached. It also lays out the steps for mobility, which is when a host dynamically changes the primary locator it uses to receive packets. The same LOCATOR parameter could also support end-host multihoming, but the detailed procedures for that are left for later study 🔮
Table of Contents 📋
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5
3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 8
3.1.3. Multihoming Overview . . . . . . . . . . . . . . . . . 8
3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . . 9
3.2.2. Mobility with a Single SA Pair (Mobile-Initiated
Rekey) . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Host Multihoming . . . . . . . . . . . . . . . . . . . 11
3.2.4. Site Multihoming . . . . . . . . . . . . . . . . . . . 13
3.2.5. Dual host multihoming . . . . . . . . . . . . . . . . 14
3.2.6. Combined Mobility and Multihoming . . . . . . . . . . 14
3.2.7. Using LOCATORs across Addressing Realms . . . . . . . 14
3.2.8. Network Renumbering . . . . . . . . . . . . . . . . . 15
3.2.9. Initiating the Protocol in R1 or I2 . . . . . . . . . 15
3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 16
3.3.1. Address Verification . . . . . . . . . . . . . . . . . 16
3.3.2. Credit-Based Authorization . . . . . . . . . . . . . . 17
3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 18
3.3.4. Interaction with Security Associations . . . . . . . . 18
4. LOCATOR Parameter Format . . . . . . . . . . . . . . . . . . . 21
4.1. Traffic Type and Preferred Locator . . . . . . . . . . . . 23
4.2. Locator Type and Locator . . . . . . . . . . . . . . . . . 23
4.3. UPDATE Packet with Included LOCATOR . . . . . . . . . . . 24
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Locator Data Structure and Status . . . . . . . . . . . . 24
5.2. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 25
5.3. Handling Received LOCATORs . . . . . . . . . . . . . . . . 28
5.4. Verifying Address Reachability . . . . . . . . . . . . . . 30
5.5. Changing the Preferred Locator . . . . . . . . . . . . . . 31
5.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 32
5.6.1. Handling Payload Packets . . . . . . . . . . . . . . . 32
5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 35
6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 36
6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 36
6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 36
6.3. Mixed Deployment Environment . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative references . . . . . . . . . . . . . . . . . . . 38
9.2. Informative references . . . . . . . . . . . . . . . . . . 381. Introduction and Scope 🌈
okay so the Host Identity Protocol [RFC4423] (HIP) is giving decoupling 💅. It separates 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 🔑. When a host uses HIP, the protocol sublayers above it (like transport layer sockets and Encapsulating Security Payload (ESP) Security Associations (SAs)) get bound to representations of those host identities instead, and IP addresses are only used for packet forwarding 📦. The catch is that each host still has to know at least one IP address where its peers can be reached. At first, those IP addresses are the ones used during the HIP base exchange [RFC5201] 🤝
This decoupling means new solutions for network-layer mobility and host multihoming are possible, and honestly that's iconic 🦋. There are potentially lots of variations of mobility and multihoming. This document covers the messaging and procedures for basic network-level mobility and simple multihoming, and it leaves the more complicated scenarios and other variations for later study. Specifically:
- This document defines a generalized
LOCATORparameter for use in HIP messages. TheLOCATORparameter lets a HIP host tell a peer about alternate addresses where it can be reached. The LOCATORs may be just IP addresses, or they may carry extra multiplexing and demultiplexing context to help the lower layers handle packets. For instance, an IP address may need to be paired with an ESP Security Parameter Index (SPI) so that packets go out on the correct SA for a given address 🧩 - This document also specifies the messaging and procedures for end-host mobility of a HIP host, which is the sequential change in the preferred IP address used to reach a host. Message flows that enable successful host mobility, including address verification methods, are defined here 🏃♀️
- The same
LOCATORparameter is intended to support host multihoming (parallel support for a number of addresses), and experimentation is encouraged. However, detailed procedures for host multihoming are left for further study 🔮
HIP can potentially be used with transports other than the ESP transport format [RFC5202], but this document mostly assumes ESP and leaves other transport formats for later study 💜
There are some situations where simple end-to-end readdressing isn't enough. These include the initial reachability of a mobile host, location privacy, simultaneous mobility of both hosts, and some modes of NAT traversal 🙈. In those cases you need some helper functionality in the network, like a HIP rendezvous server [RFC5204]. That helper functionality is out of scope for this document ✋. This document also doesn't cover localized mobility management extensions (mobility management techniques that don't directly signal the correspondent node). It's all about end-to-end mobility 🎯. Last thing: making the underlying IP mobility transparent to the transport layer affects 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 mobility or multihoming address change, are also outside the scope of this document 💀
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] 📜
- LOCATOR. The name of a HIP parameter that contains zero or more Locator fields. The parameter's name is told apart from the Locator fields inside it by being written in all capital letters 🔠
- Locator. A name that controls how a packet is routed through the network and demultiplexed by the end host. It can include a combo of traditional network addresses (like an IPv6 address) and end-to-end identifiers (like an ESP SPI). It can also include transport port numbers or IPv6 Flow Labels as demultiplexing context, or it can simply be a network address 🧠
- Address. A name that denotes a point-of-attachment to the network. The two most common examples are an IPv4 address and an IPv6 address. The set of possible addresses is a subset of the set of possible locators 📍
- Preferred locator. A locator on which a host prefers to receive data. For a given peer, a host always has one active Preferred locator, unless there are no active locators. By default, the locators used in the HIP base exchange are the Preferred locators 👑
- Credit Based Authorization. A host must verify a mobile or multihomed peer's reachability at a new locator. Credit-Based Authorization lets the peer receive a certain amount of data at the new locator before the result of that verification is known 💸
3. Protocol Model 🌸
This section is an overview; more detailed specification follows this section 🧚
3.1. Operating Environment ✨
Okay so the Host Identity Protocol (HIP) [RFC5201] is a key establishment and parameter negotiation protocol 🔐 Its main jobs are authenticating host messages based on host identities, and setting up security associations (SAs) for the ESP transport format [RFC5202], plus maybe other protocols down the line 🧚
+--------------------+ +--------------------+
| | | |
| +------------+ | | +------------+ |
| | Key | | HIP | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec | | ESP | | IPsec | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
Figure 1: HIP Deployment ModelThe general deployment model for HIP is shown above, assuming it runs in an end-to-end fashion 💖 This document specifies extensions to the HIP protocol so that end hosts can do mobility and basic multihoming 🦋 Basically, these extensions let a host signal new addressing information to its peer inside HIP messages 📨 The messages are authenticated with either a signature or a keyed hash message authentication code (HMAC), based on the Host Identity. This document specifies the format of this new addressing (LOCATOR) parameter, the procedures for sending and processing it to get basic host mobility, and a procedure for a concurrent address verification mechanism 🫶
---------
| TCP | (sockets bound to HITs)
---------
|
---------
----> | ESP | {HIT_s, HIT_d} <-> SPI
| ---------
| |
---- ---------
| MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI}
---- ---------
|
---------
| IP |
---------
Figure 2: Architecture for HIP Mobility and Multihoming (MH)Figure 2 shows a layered view of a HIP-enabled stack that uses the ESP transport format 🎀 In HIP, upper-layer protocols (TCP and ESP in this figure) are bound to Host Identity Tags (HITs), not IP addresses. The HIP sublayer is the one in charge of keeping the binding between HITs and IP addresses 💅 The SPI is used to link an incoming packet to the right HITs. The block labeled "MH" gets introduced below.
Let's start with the case where there's no mobility or multihoming, as laid out in the base protocol specification [RFC5201] 🌸 The HIP base exchange sets up the HITs in use between the hosts, the SPIs to use for ESP, and the IP addresses (used in both the HIP signaling packets and the ESP data packets). Note that there can only be one such set of bindings in the outbound direction for any given packet 👑 The only fields used for the binding at the HIP layer are the ones ESP exposes (the SPI and HITs). For the inbound direction, the SPI is all you need to find the right host context. ESP rekeying events change the mapping between the HIT pair and SPI, but they don't change the IP addresses 🙈
Next up is a mobility event, where a host is still single-homed but moves to another IP address 🏃♀️ Two things must happen here. First, the peer has to be notified of the address change using a HIP UPDATE message. Second, each host has to change its local bindings at the HIP sublayer to the new IP addresses. It may be that both the SPIs and the IP addresses change at the same time in a single UPDATE, and the protocol described here supports that 🔥 However, simultaneous movement of both hosts, notifying transport layer protocols of the path change, and procedures for possibly traversing middleboxes are not covered by this document 🙅♀️
Finally, consider a host that is multihomed (it has more than one globally routable address) and has multiple addresses available at the HIP layer as alternative locators for fault tolerance 🌈 Examples include using (possibly multiple) IPv4 and IPv6 addresses on the same interface, or using multiple interfaces attached to different service providers. Multihoming like this generally means a separate ESP SA has to be maintained for each interface, so that packets arriving over different paths don't fall outside the ESP anti-replay window [RFC4303] 😭 So multihoming makes it possible that the bindings on the right side of Figure 2 are one-to-many (in the outbound direction, one HIT pair maps to multiple SPIs, and possibly then to multiple IP addresses). But only one SPI and address pair can be used for any given packet, so the job of the "MH" block is to dynamically manage these bindings ✨ Beyond managing those multiple bindings locally, the peer-to-peer HIP signaling protocol needs to be flexible enough to define the desired mappings between HITs, SPIs, and addresses. It also needs to make sure UPDATE messages are sent along the right network paths, so that any HIP-aware middleboxes can observe the SPIs 🧚 This document does not specify the "MH" block, and it doesn't specify detailed procedures for handling various multihoming (perhaps combined with mobility) scenarios. The "MH" block may apply to more general problems outside of HIP. However, this document does describe a basic multihoming case (one host adds one address to its initial address and notifies the peer), and it leaves more complicated scenarios for experimentation and future documents 🍓
3.1.1. Locator 📍
This document defines a generalization of an address called a "locator" 💜 A locator specifies a point-of-attachment to the network, but it may also include extra end-to-end tunneling or per-host demultiplexing context that affects how packets are handled below the logical HIP sublayer of the stack. This generalization is useful because IP addresses alone may not be enough to describe how packets should be handled below HIP 🙌 For example, in a host multihoming context, certain IP addresses may need to be associated with certain ESP SPIs so that the ESP anti-replay window doesn't get violated. Addresses may also be affiliated with transport ports in certain tunneling scenarios. Locators may simply be traditional network addresses. The format of the locator fields in the LOCATOR parameter is defined in Section 4 📚
3.1.2. Mobility Overview 🏃♀️
When a host moves to another address, it tells its peer about the new address by sending a HIP UPDATE packet that contains a LOCATOR parameter 📨 The peer acknowledges this UPDATE packet. For reliability when packets get lost, the UPDATE packet is retransmitted as defined in the HIP protocol specification [RFC5201] 🔁 The peer can authenticate the contents of the UPDATE packet based on the signature and keyed hash of the packet 🔐
When using the ESP Transport Format [RFC5202], the host may at the same time decide to rekey its security association and possibly generate a new Diffie-Hellman key 🗝️ All of these actions are triggered by including additional parameters in the UPDATE packet, as defined in the base protocol specification [RFC5201] and the ESP extension [RFC5202] 💅
When using ESP (and possibly other transport modes in the future), the host is able to receive packets protected using a HIP-created ESP SA from any address 🦋 So a host can change its IP address and keep sending packets to its peers without necessarily rekeying. However, the peers can't send packets to these new addresses until they can reliably and securely update the set of addresses they associate with the sending host 😬 And mobility may change the path characteristics in such a way that reordering happens and packets fall outside the ESP anti-replay window for the SA, which then requires rekeying 💀
3.1.3. Multihoming Overview 🌸
A related configuration is host multihoming, where a host has multiple locators at the same time rather than one after another, like in the mobility case 👯 By using the LOCATOR parameter defined here, a host can tell its peers about additional (multiple) locators where it can be reached, and it can declare a particular locator as a "preferred" locator 💖 Although this document defines a basic mechanism for multihoming, it does not define detailed policies and procedures. That includes which locators to choose when more than one pair is available, how simultaneous mobility and multihoming work together, source address selection policies (beyond those specified in [RFC3484]), and the implications of multihoming for transport protocols and ESP anti-replay windows 🫠 Additional definitions of HIP-based multihoming are expected to show up in future documents ✨
3.2. Protocol Overview 🦋
okay bestie, so this section is a quick tour of some usage scenarios for HIP mobility and multihoming 💖 These scenarios assume HIP is being used with the ESP transform [RFC5202], though other scenarios might get defined later 🧚. To get the most out of them, you should be at least minimally familiar with the HIP protocol specification [RFC5201]. But ngl, if you're new to all this, the biggest thing to remember is that in HIP the actual payload traffic is protected with ESP, and the ESP SPI acts as an index to the right host-to-host context ✨. More specification details come later in Section 4 and Section 5 🎀.
The scenarios below assume that the two hosts have finished a single HIP base exchange with each other 🫶. So both hosts have one incoming and one outgoing SA. Further, each SA uses the same pair of IP addresses, which are the ones from the base exchange.
The readdressing protocol is asymmetric 💅. A mobile or multihomed host tells a peer host about IP address changes on the affected SPIs. It's designed to be piggybacked on existing HIP exchanges. Most of the packets carrying LOCATOR parameters are expected to be UPDATE packets. However, some implementations may want to experiment with sending LOCATOR parameters on other packets too, such as R1, I2, and NOTIFY 🌈.
The scenarios below sometimes 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 removed by the peer get moved into a deprecated state. Under limited conditions (Section 5.6), an UNVERIFIED address may be used. The addressing states get defined more formally in Section 5.1.
Hosts that use link-local addresses as source addresses in their HIP handshakes might not be reachable by a mobile peer 🙈. Such hosts SHOULD provide a globally routable address, either in the initial handshake or via the LOCATOR parameter.
3.2.1. Mobility with a Single SA Pair (No Rekeying) 💜
A mobile host has to change an IP address bound to an interface sometimes 🚗. That change might be needed because of a change in the advertised IPv6 prefixes on the link, a reconnected PPP link, a new DHCP lease, or an actual move to another subnet. To keep its communication context, the host has to tell its peers about the new IP address. This first example looks at the case where the mobile host has only one interface and IP address, a single pair of SAs (one inbound, one outbound), and no rekeying on the SAs. We also assume the new IP addresses are in the same address family (IPv4 or IPv6) as the first one. This is the simplest scenario, shown in Figure 3 ✨.
Mobile Host Peer Host
UPDATE(ESP_INFO, LOCATOR, SEQ)
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
Figure 3: Readdress without Rekeying, but with Address CheckHere's how the packet processing goes, step by step 👑:
- The mobile host gets disconnected from the peer host for a brief moment while it swaps from one IP address to another 😭. Once it has a new IP address, the mobile host sends a LOCATOR parameter to the peer host in an UPDATE message. That UPDATE also carries an ESP_INFO parameter with the old and new SPIs for a security association. In this case, the OLD SPI and NEW SPI both get set to the value of the preexisting incoming SPI. This ESP_INFO doesn't trigger a rekeying event. It's only there for possible parameter-inspecting middleboxes on the path 🧚. The LOCATOR parameter holds the new IP address (Locator Type of "1", defined below) and a locator lifetime. The mobile host waits for this UPDATE to be acknowledged, and retransmits if necessary, as specified in the base specification [RFC5201] 🔥.
- The peer host receives the UPDATE, validates it, and updates any local bindings between the HIP association and the mobile host's destination address 💖. The peer host MUST perform an address verification by putting a nonce in the ECHO_REQUEST parameter of the UPDATE message it sends back to the mobile host. It also includes an ESP_INFO parameter with the OLD SPI and NEW SPI both set to the value of the preexisting incoming SPI, and it sends this UPDATE (with piggybacked acknowledgment) to the mobile host at its new address 🦋. The peer MAY use the new address immediately, but it MUST limit the amount of data it sends to that address until address verification completes 🙈.
- The mobile host finishes the readdress by processing the UPDATE ACK and echoing the nonce in an ECHO_RESPONSE 🎀. Once the peer host receives this ECHO_RESPONSE, it considers the new address verified and can put that address into full use 🫶.
While the peer host is verifying the new address, the new address is marked as UNVERIFIED in the meantime, and the old address is DEPRECATED 🌸. Once the peer host has received a correct reply to its UPDATE challenge, it marks the new address as ACTIVE and removes the old address ✨.
3.2.2. Mobility with a Single SA Pair (Mobile-Initiated Rekey) 🌈
The mobile host may decide to rekey the SAs at the same time it tells the peer about the new address 🍓. In that case, the procedure described above for Figure 3 gets slightly modified. The UPDATE message sent from the mobile host includes an ESP_INFO with the OLD SPI set to the previous SPI, the NEW SPI set to the desired new SPI value for the incoming SA, and the KEYMAT Index that's wanted. Optionally, the host may include a DIFFIE_HELLMAN parameter for a new Diffie-Hellman key 🔐. The peer completes the rekey request the same way it normally does for HIP rekeying, except that the new address is kept as UNVERIFIED until the UPDATE nonce challenge is received, as described above 💅. Figure 4 illustrates this scenario.
Mobile Host Peer Host
UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
Figure 4: Readdress with Mobile-Initiated Rekey3.2.3. Host Multihoming 🧚
A host (mobile or stationary) can have more than one interface or global address, and that's giving main character energy 👑. The host may tell the peer host about the extra interface or address by using the LOCATOR parameter. To avoid problems with the ESP anti-replay window, a host SHOULD use a different SA for each interface or address it uses to receive packets from the peer host when multiple locator pairs are in use simultaneously rather than sequentially 💜.
When more than one locator is given to the peer host, the host SHOULD indicate which locator is preferred, meaning the locator on which the host prefers to receive traffic ✨. By default, the addresses used in the base exchange are preferred until the host indicates otherwise 🎀.
The sender may also have multiple valid locators to send traffic from 🦋. In practice, a HIP association in a multihoming setup may have both a preferred peer locator and a preferred local locator. Still, the rules for source address selection should ultimately decide which source locator gets picked, based on the destination locator 🫶.
Although the protocol may allow setups where the number of SAs is asymmetric between the hosts (for example, one host has two interfaces and two inbound SAs, while the peer has one interface and one inbound SA), it is RECOMMENDED 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. Asymmetric SA configurations might be experimented with, but their usage may constrain interoperability at this time 💀. Still, it is recommended that implementations attempt to support peers that prefer to use non-paired SAs. This section and its behavior are expected to change in future revisions of this protocol, once the issue and its implications are better understood 🔥.
Consider the case between two hosts, one single-homed and one multihomed 🍓. The multihomed host may decide to tell the single-homed host about its other address. It is RECOMMENDED that the multihomed host set up a new SA pair for use on this new address 🌈. To do that, the multihomed host sends a LOCATOR with an ESP_INFO, requesting a new SA by setting the OLD SPI value to zero and the NEW SPI value to the newly created incoming SPI. A Locator Type of "1" is used to associate the new address with the new SPI. The LOCATOR parameter also contains a second Type "1" locator, the one for the original address and SPI. To simplify parameter processing and avoid explicit protocol extensions to remove locators, each LOCATOR parameter MUST list all locators in use on a connection (a complete listing of the inbound locators and SPIs for the host) 🙈. The multihomed host then waits for an ESP_INFO (new outbound SA) from the peer and an ACK of its own UPDATE. Just like in the mobility case, the peer host must perform an address verification before actively using the new address 💖. Figure 5 illustrates this scenario.
Multi-homed Host Peer Host
UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
Figure 5: Basic Multihoming ScenarioIn multihoming scenarios, it's really 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 LOCATORs that establish new security associations on an interface with multiple addresses, it uses the destination address of the UPDATE containing the LOCATOR as the local address that the LOCATOR plus ESP_INFO is aimed at. This is because hosts may send UPDATEs with the same (locator) IP address to different peer addresses -- which has the effect of creating multiple inbound SAs implicitly affiliated with different peer source addresses 🌸.
3.2.4. Site Multihoming ✨
okay so a host can have an interface with multiple globally routable IP addresses 🌸 That can happen because the site has more than one upper Internet Service Provider, 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 they were provided 🫶
This case is handled the same as if there were different IP addresses, described above in Section 3.2.3. Note that a single interface may experience site multihoming while the host itself may have multiple interfaces. 💅
Note that a host may be multihomed and mobile simultaneously 🦋 and that a multihomed host may want to protect the location of some of its interfaces while revealing the real IP address of some others. That's main character energy for real 💜
This document does not presently specify additional site multihoming extensions to HIP. Further alignment with the IETF shim6 working group may be considered in the future 🧚
3.2.5. Dual host multihoming
Okay, now picture this: both hosts want to add an extra address after the base exchange is done 👯 In Figure 6, host1 used addr1a during the base exchange to set up SPI1a and SPI2a, and now it wants to add addr1b. It sends an UPDATE with LOCATOR (containing addr1b) to host2, using destination address addr2a. A new set of SPIs gets added between hosts 1 and 2 (call them SPI1b and SPI2b, which aren't 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. It may choose addr1a, addr1b, or both. If it sends to both, you end up with a full mesh of four SA pairs between the two hosts. That's the most general case, and honestly it may often be that hosts only set up new SAs with the peer's Preferred locator. The readdressing protocol is flexible enough to handle either choice, so it's giving options 🌈
-<- SPI1a -- -- SPI2a ->-
host1 < > addr1a <---> addr2a < > host2
->- SPI2a -- -- SPI1a -<-
addr1b <---> addr2a (second SA pair)
addr1a <---> addr2b (third SA pair)
addr1b <---> addr2b (fourth SA pair)
Figure 6: Dual Multihoming Case in Which Each Host Uses LOCATOR to
Add a Second Address3.2.6. Combined Mobility and Multihoming 🌙
It looks likely that in the future, lots of mobile hosts will be mobile and multihomed at the same time, meaning they'll have multiple mobile interfaces 📱 Plus, if the interfaces use different access technologies, one of them may look stable (keeping its current IP address) while another one is out here experiencing mobility (changing its IP address) 😭
The use of LOCATOR plus ESP_INFO should be flexible enough to handle most of these scenarios. More complicated scenarios haven't been studied so far, so bestie, that's still an open question 🔥
3.2.7. Using LOCATORs across Addressing Realms
It's possible for HIP associations to end up in a state where both parties are only using locators in different addressing realms 🙈 For example, the two hosts might start the HIP association while both are using IPv6 locators. Then one host loses its IPv6 connectivity and gets an IPv4 address instead. In a case like this, some kind of mechanism for interworking between the different realms must be employed. Those techniques are outside the scope of this text, so we're not diving in here 🚫
The basic problem in this example is that the host readdressing to IPv4 doesn't know a corresponding IPv4 address for its peer. This may be handled (experimentally) by configuring that address information manually or in the DNS. Or the hosts could exchange both IPv4 and IPv6 addresses in the locator 🧩
3.2.8. Network Renumbering
It's expected that IPv6 networks will be renumbered way more often than most IPv4 networks 🔄 From an end host's point of view, network renumbering is pretty similar to mobility. Same vibes, different vibes 🦋
3.2.9. Initiating the Protocol in R1 or I2
A Responder host MAY tuck a LOCATOR parameter into the R1 packet it sends to the Initiator 🎁 That parameter MUST be protected by the R1 signature. If the R1 packet has LOCATOR parameters with a new Preferred locator, the Initiator SHOULD set that new Preferred locator straight to status ACTIVE, without doing address verification first. It MUST then 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 ✅
Initiator Responder
R1 with LOCATOR
<-----------------------------------
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 7: LOCATOR Inclusion in R1An Initiator MAY include one or more LOCATOR parameters in the I2 packet, whether or not there was a LOCATOR parameter in the R1 💜 These parameters MUST be protected by the I2 signature. Even if the I2 packet has LOCATOR parameters, the Responder MUST still send the R2 packet to the source address of the I2. The new Preferred locator SHOULD be identical to the I2 source address. If the I2 packet has LOCATOR 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
----------------------------------->
(process normally)
record additional addresses
R2 sent to source address of I2
<-----------------------------------
(process normally)
Figure 8: LOCATOR Inclusion in I2The I1 and I2 may come from different source addresses if the LOCATOR parameter is present in R1. In that case, implementations that are simultaneously using multiple pre-created R1s, indexed by Initiator IP addresses, may accidentally fail the puzzle solution of I2 packets because of a perceived puzzle mismatch 😵💫 See, for instance, the example in Appendix A of [RFC5201]. The fix is that the Responder's puzzle indexing mechanism must be flexible enough to handle the situation where R1 includes a LOCATOR parameter. Flexibility is everything, periodt 💖
3.3. Other Considerations
3.3.1. Address Verification 🔍
When a HIP host gets a set of locators from another HIP host in a LOCATOR, it doesn't necessarily know whether the other host is actually reachable at the claimed addresses. In fact, a malicious peer host may be deliberately giving bogus addresses to cause a packet flood toward the target addresses [RFC4225] 😱 Likewise, viral software may have compromised the peer host and programmed it to redirect packets to the target addresses. So the HIP host must first check that the peer is reachable at the new address. No skipping this step, bestie 🚨
Performing address verification has another potential perk too: it lets middleboxes along the new path learn the peer host's inbound SPI 🧚
Address verification works like this: the challenger sends some piece of unguessable information to the new address, then waits for an acknowledgment from the Responder that shows the information was received at the new address. That acknowledgment might come from an exchange of a nonce, or from generating a new SPI and seeing data arrive on that new SPI ✨
3.3.2. Credit-Based Authorization 💖
Okay so, Credit-Based Authorization (CBA) 🦋 lets a host securely use a brand-new locator even though the peer hasn't been verified as reachable at the address embedded in that locator yet. It's built on three hypotheses:
- A flooding attacker usually tries to multiply the packets it generates, because bandwidth is an ample resource for many victims.
- An attacker can often cause unamplified flooding by sending packets to its victim, either by directly addressing the victim in the packets, or by guiding the packets along a specific path by means of an IPv6 Routing header, if Routing headers are not filtered by firewalls.
- So the extra effort needed to set up a redirection-based flooding attack (without CBA and return routability checks) would only pay off for the attacker if amplification could be obtained that way.
On this basis, CBA doesn't bother eliminating malicious packet redirection in the first place. It prevents amplification instead 🛡️. It does this by limiting how much data a host can send to an unverified address of a peer, based on the data it recently received from that peer. So redirection-based flooding attacks become way less attractive than, say, pure direct flooding, where the attacker just sends bogus packets to the victim itself 🙄.
Figure 9 shows the whole vibe ✨: Host B measures how much data it recently received from peer A. When A readdresses, B sends packets to A's new, unverified address for as long as the sum of the packet sizes doesn't exceed the measured, received data volume. When there's not enough credit left, B stops sending packets to A until A's address becomes ACTIVE. The address changes may be due to mobility, multihoming, or any other reason. Not shown in Figure 9 are the results of credit aging (Section 5.6.2), a mechanism used to dampen possible time-shifting attacks ⏳.
+-------+ +-------+
| A | | B |
+-------+ +-------+
| |
address |------------------------------->| credit += size(packet)
ACTIVE | |
|------------------------------->| credit += size(packet)
|<-------------------------------| do not change credit
| |
+ address change |
+ address verification starts |
address |<-------------------------------| credit -= size(packet)
UNVERIFIED |------------------------------->| credit += size(packet)
|<-------------------------------| credit -= size(packet)
| |
|<-------------------------------| credit -= size(packet)
| X credit < size(packet)
| | => do not send packet!
+ address verification concludes |
address | |
ACTIVE |<-------------------------------| do not change credit
| |
Figure 9: Readdressing Scenario3.3.3. Preferred Locator 🎀
So when a host has multiple locators, the peer host has to decide which one to use for outbound packets 📬. Sometimes a host would rather receive data on a particular inbound interface, and that's where this comes in. HIP lets a particular locator be designated as a Preferred locator and communicated to the peer (see Section 4) 💅.
Also, when multiple locators are used for a session, there's the question of whether to use them for failover only or for load-balancing. Load-balancing has implications on the transport layer that still need to be worked out 🤷♀️, so this document assumes that multiple locators are used primarily for failover. An implementation may use ICMP interactions, reachability checks, or other means to detect the failure of a locator.
3.3.4. Interaction with Security Associations 🧚
This document specifies a new HIP protocol parameter, the LOCATOR parameter (see Section 4). It lets the hosts exchange information about their locator(s) and any changes in their locator(s) 🗺️. The logical structure created with LOCATOR parameters has three levels: hosts, Security Associations (SAs) indexed by Security Parameter Indices (SPIs), and addresses. Lowkey a lot, but it's so clean once you see it.
The relation between these levels for an association constructed as defined in the base specification [RFC5201] and ESP transform [RFC5202] is shown in Figure 10 👀.
-<- SPI1a -- -- SPI2a ->-
host1 < > addr1a <---> addr2a < > host2
->- SPI2a -- -- SPI1a -<-
Figure 10: Relation between Hosts, SPIs,
and Addresses (Base Specification)In Figure 10, host1 and host2 negotiate two unidirectional SAs, and each host selects the SPI value for its inbound SA. The addresses addr1a and addr2a are the source addresses that the hosts use in the base HIP exchange. These are the "preferred" (and only) addresses conveyed to the peer for use on each SA. So even though packets sent to any of the hosts' interfaces may be accepted on the inbound SA, the peer host in general only knows the single destination address learned in the base exchange. For example, host1 sends a packet on SPI2a to addr2a to reach host2, unless other mechanisms exist to learn of new addresses 📍.
In general, the bindings that exist in an implementation corresponding to this document can be depicted as shown in Figure 11 🧩. In this figure, a host can have multiple inbound SPIs (and, not shown, multiple outbound SPIs) associated with another host. Furthermore, each SPI may have multiple addresses associated with it. These addresses bound to an SPI are not used to look up the incoming SA. Instead, they're the addresses provided to the peer host, as hints for which addresses to use to reach the host on that SPI. The LOCATOR parameter is used to change the set of addresses that a peer associates with a particular SPI.
address11
/
SPI1 - address12
/
/ address21
host -- SPI2 <
\ address22
\
SPI3 - address31
\
address32Figure 11: Relation between Hosts, SPIs, and Addresses (General Case)
A host may establish any number of security associations (or SPIs) with a peer. The main purpose of having multiple SPIs with a peer is to group the addresses into collections that are likely to experience fate sharing 🤝. For example, if the host needs to change its addresses on SPI2, it's likely that both address21 and address22 will become obsolete at the same time. In a typical case, such SPIs may correspond with physical interfaces (see below). Note, however, that especially in the case of site multihoming, one of the addresses may become unreachable while the other one still works. In the typical case, though, this doesn't require the host to inform its peers about the situation, since even the non-working address still logically exists 🙃.
A basic property of HIP SAs is that the inbound IP address is not used to look up the incoming SA. So in Figure 11, it may seem unnecessary for address31, for example, to be associated only with SPI3. In practice, though, a packet may arrive to SPI1 via destination address address31 as well. The thing is, using different source and destination addresses typically leads to different paths with different latencies in the network. If packets were to arrive via an arbitrary destination IP address (or path) for a given SPI, the reordering due to different latencies could push some packets outside of the ESP anti-replay window 😬. For this reason, HIP provides a mechanism to affiliate destination addresses with inbound SPIs, when there's a concern that anti-replay windows might be violated. In this sense, a given inbound SPI has an "affinity" for certain inbound IP addresses, and this affinity is communicated to the peer host 💜. Each physical interface SHOULD have a separate SA, unless the ESP anti-replay window is loose.
Moreover, even when the destination addresses used for a particular SPI are held constant, using different source interfaces may also push packets outside of the ESP anti-replay window, since the path traversed is often affected by the source address or interface used. A host has no way to influence the source interface on which a peer sends its packets on a given SPI. A host SHOULD consistently use the same source interface and address when sending to a particular destination IP address and SPI. For this reason, a host may find it useful to change its SPI, or at least reset its ESP anti-replay window, when the peer host readdresses 🔄.
An address may appear on more than one SPI. This creates no ambiguity, since the receiver will ignore the IP addresses during SA lookup anyway. However, this document does not specify such cases.
When the LOCATOR parameter is sent in an UPDATE packet, the receiver will respond with an UPDATE acknowledgment. When the LOCATOR parameter is sent in an R1 or I2 packet, the base exchange retransmission mechanism will confirm its successful delivery ✅. LOCATORs may experimentally be used in NOTIFY packets. In this case, the recipient MUST consider the LOCATOR as informational and not immediately change the current preferred address, but it can test the additional locators when the need arises. Heads up, though: the use of the LOCATOR in a NOTIFY message may not be compatible with middleboxes 🚧.
4. LOCATOR Parameter Format ✨
okay so the LOCATOR parameter is a critical parameter, as defined by [RFC5201] 💅. It's got the usual HIP Type and Length fields, plus zero or more Locator sub-parameters. Each Locator sub-parameter carries a Traffic Type, a Locator Type, a Locator Length, the Preferred locator bit, a Locator Lifetime, and a Locator encoding. A LOCATOR with zero Locator fields is allowed, but it basically deprecates every address 💀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: LOCATOR Parameter Format
Here's the field breakdown, bestie 🎀
- Type:
193 - Length: Length in octets, excluding Type and Length fields, and excluding padding.
- Traffic Type: Defines whether the locator pertains to HIP signaling, user data, or both.
- Locator Type: Defines the semantics of the Locator field.
- Locator Length: Defines the length of the Locator field, in units of 4-byte words (Locators up to a maximum of
4*255octets are supported). - Reserved: Zero when sent, ignored when received.
- P: Preferred locator. Set to one if the locator is preferred for that Traffic Type; otherwise, set to zero.
- Locator Lifetime: Locator lifetime, in seconds.
- Locator: The locator whose semantics and encoding are indicated by the Locator Type field. All Locator sub-fields are integral multiples of four octets in length.
The Locator Lifetime tells you how long the following locator is expected to stay valid 🕰️ It's measured in seconds. Each locator MUST have a non-zero lifetime. The address is expected to become deprecated once that many seconds have passed since the message was received. A deprecated address SHOULD NOT be used as a destination address if an alternate (non-deprecated) one is available and has sufficient scope. Not me being all about the lifetimes 😭🫶
4.1. Traffic Type and Preferred Locator
These are the Traffic Type values that are defined 🦋
0: Both signaling (HIP control packets) and user data.1: Signaling packets only.2: Data packets only.
The "P" bit, when set, has scope over the corresponding Traffic Type. So if a "P" bit is set for Traffic Type "2", for example, it means the locator is preferred for data packets. If there's a conflict (like the "P" bit is set for an address of Type "0" and a different address of Type "2"), the more specific Traffic Type rule applies, which in this case is "2" ✨ By default, the IP addresses used in the base exchange are Preferred locators for both signaling and user data, unless a new Preferred locator supersedes them. If no locators are indicated as preferred for a given Traffic Type, the implementation may use an arbitrary locator from the set of active locators.
4.2. Locator Type and Locator
These are the Locator Type values that are defined, along with the semantics of the Locator field attached to each one 🌸
0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [RFC4291] (128 bits long). This locator type is defined primarily for non-ESP-based usage.1: The concatenation of an ESP SPI (first 32 bits) followed by an IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional 128 bits). This IP address is defined primarily for ESP-based usage.
4.3. UPDATE Packet with Included LOCATOR
There are a bunch of ways the parameters in an UPDATE packet can combine (see Section 3.2 for those) 🧩 But in this document, procedures are only defined for the case where one LOCATOR and one ESP_INFO parameter are used in any HIP packet. The LOCATOR SHOULD list all of the locators that are active on the HIP association, including the ones on SAs not covered by the ESP_INFO parameter. Any UPDATE packet that includes a LOCATOR parameter SHOULD include both an HMAC and a HIP_SIGNATURE parameter. The relationship between the announced Locators and any ESP_INFO parameters in the packet is defined in Section 5.2. Sending multiple LOCATOR and/or ESP_INFO parameters is still for further study, so receivers may wish to experiment with supporting it 🔬💜
5. Processing Rules 👑
This section is the rulebook for sending and receiving the LOCATOR parameter, testing address reachability, and using Credit-Based Authorization (CBA) on UNVERIFIED locators.
5.1. Locator Data Structure and Status
In a typical implementation, each outgoing locator is represented by a piece of state holding:
- the actual bit pattern representing the locator,
- the lifetime (seconds),
- the status (UNVERIFIED, ACTIVE, DEPRECATED),
- the Traffic Type scope of the locator, and
- whether the locator is preferred for any particular scope.
The status is used to track the reachability of the address embedded within the LOCATOR 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.
- DEPRECATED indicates that the locator lifetime has expired.
The following state changes are allowed 🔄
- UNVERIFIED to ACTIVE: The reachability procedure completes successfully.
- UNVERIFIED to DEPRECATED: The locator lifetime expires while the locator is UNVERIFIED.
- ACTIVE to DEPRECATED: The locator 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 must 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. That's a hard no, bestie 🚫
Heads up: whether 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. Your device gets the final say 💅🌈
5.2. Sending LOCATORs
okay so deciding when to send LOCATORs is basically a local policy thing 💅 But it is RECOMMENDED that a host sends a LOCATOR whenever it notices its IP addresses in use on an active HIP association have changed and it assumes the change is going to last at least a few seconds ✨ Rapidly sending LOCATORs that make the peer keep swapping its preferred address SHOULD be avoided 🙈
When a host decides to tell its peers about IP changes, it has to figure out how to group the various addresses with SPIs 🧩 The grouping should also consider whether middlebox interaction requires sending the same LOCATOR in separate UPDATEs on different paths. 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 actual kernel level physical and logical interfaces may be the best policy. Grouping policy is outside of the scope of this document. 🌸
Now, the whole point of announcing IP addresses in a LOCATOR is to get the communicating hosts connected 🦋 In most cases, tunnels or virtual interfaces such as IPsec tunnel interfaces or Mobile IP home addresses give sub-optimal connectivity, which is kinda sad 😭 Furthermore, it should be possible to replace most tunnels with HIP based "non-tunneling", so most virtual interfaces become fairly unnecessary in the future. Therefore, virtual interfaces SHOULD NOT be announced in general. On the other hand, there are clearly situations where tunnels are used for diagnostic and/or testing purposes. In such and other similar cases, announcing the IP addresses of virtual interfaces may be appropriate 🧪
Hosts MUST NOT announce broadcast or multicast addresses in LOCATORs. 🚫 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, because link-local addresses used as Preferred locators will create reachability problems when the host moves to another link 🥺 In any case, 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 the assignment of addresses to the SPIs, it creates a LOCATOR parameter that serves as a complete representation of the addresses and affiliated SPIs intended for active use 👑 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 and multihoming cases are possible but are left for further experimentation 🔮
- Host mobility with no multihoming and no rekeying. The mobile host creates a single UPDATE containing a single ESP_INFO with a single LOCATOR parameter. The ESP_INFO contains the current value of the SPI in both the
OLD SPIandNEW SPIfields. The LOCATOR 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 protocol specification [RFC5201]. The UPDATE should be sent to the peer's preferred IP address with an IP source address corresponding to the address in the LOCATOR parameter. 🦋 - Host mobility with no multihoming but with rekeying. The mobile host creates a single UPDATE containing a single ESP_INFO with a single LOCATOR parameter (with a single address). The ESP_INFO contains the current value of the SPI in the
OLD SPIand the new value of the SPI in theNEW SPI, plus a KEYMAT Index as selected by local policy. Optionally, the host may choose to initiate a Diffie Hellman rekey by including aDIFFIE_HELLMANparameter. The LOCATOR contains a single Locator with a"Locator Type"of"1"; the SPI must match that of theNEW SPIin the ESP_INFO. Otherwise, the steps are identical to the case in which no rekeying is initiated. 🔁 - Host multihoming (addition of an address). We only describe the simple case of adding an additional address to a (previously) single-homed, non-mobile host. The host SHOULD set up a new SA pair between this new address and the preferred address of the peer host. To do this, the multihomed host creates a new inbound SA and creates a new SPI. For the outgoing UPDATE message, it inserts an ESP_INFO parameter with an
OLD SPIfield of"0", aNEW SPIfield corresponding to the new SPI, and a KEYMAT Index as selected by local policy. The host adds to the UPDATE message a LOCATOR 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 theNEW SPIcontained in the ESP_INFO). The Preferred bit SHOULD be set depending on the policy, to tell the peer host which of the two locators is preferred. The UPDATE also contains a SEQ parameter and, optionally, aDIFFIE_HELLMANparameter, and follows rekeying procedures with respect to this new address. The UPDATE message SHOULD be sent to the peer's Preferred address with a source address corresponding to the new locator. 🌈
The sending of multiple LOCATORs, locators with "Locator Type" "0", and multiple ESP_INFO parameters is for further study. Note that including a LOCATOR in an R1 packet requires the use of Type "0" locators, since no SAs are set up at that point 🧚
5.3. Handling Received LOCATORs
A host SHOULD be prepared to receive a LOCATOR parameter in the following HIP packets: R1, I2, UPDATE, and NOTIFY 📬
This document describes sending both ESP_INFO and LOCATOR 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 middleboxes 🛡️ The LOCATOR parameter contains a complete map of the locators that the host wishes to make or keep active for the HIP association 🗺️
In general, the processing of a LOCATOR depends on the packet type in which it is included. Here, we only describe the case where ESP_INFO is present and a single LOCATOR 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 parameters is intended to be modular and to support future generalization to the inclusion of multiple ESP_INFO and/or multiple LOCATOR parameters. A host SHOULD first process the ESP_INFO before the LOCATOR, since the ESP_INFO may contain a new SPI value mapped to an existing SPI, while a Type "1" locator will only contain a reference to the new SPI 🧠
When a host receives a validated HIP UPDATE with a LOCATOR 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 middleboxes. The host examines the OLD SPI and NEW SPI values in the ESP_INFO parameter 🔍
- (no rekeying) If the
OLD SPIis equal to theNEW SPIand both correspond to an existing SPI, the ESP_INFO is gratuitous (provided for middleboxes) and no rekeying is necessary. ✅ - (rekeying) If the
OLD SPIindicates an existing SPI and theNEW SPIis a different non-zero value, the existing SA is being rekeyed. The host follows HIP ESP rekeying procedures by creating a new outbound SA with an SPI corresponding to theNEW SPI, with no addresses bound to this SPI. Note that locators in the LOCATOR parameter will reference this new SPI instead of the old SPI. 🔄 - (new SA) If the
OLD SPIvalue is zero and theNEW SPIis 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. 🆕 - (deprecating the SA) If the
OLD SPIindicates an existing SPI and theNEW SPIis 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 parameter are processed. For each locator listed in the LOCATOR 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 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 added and its status is set to UNVERIFIED. Mark all addresses corresponding to the SPI that were NOT listed in the LOCATOR parameter as DEPRECATED. 🏷️
As a result, at the end of processing, the addresses listed in the LOCATOR parameter have either a state of UNVERIFIED or ACTIVE, and any old addresses on the old SA not listed in the LOCATOR parameter have a state of DEPRECATED. 💜
Once the host has processed the locators, if the LOCATOR parameter contains a new Preferred locator, the host SHOULD initiate a change of the Preferred locator. This requires that the host first verifies reachability of the associated address, and only then changes 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 parameter. 📣🫶
5.4. Verifying Address Reachability
okay bestie, this part is all about checking that a new address actually works before you trust it 🦋✨ the rule is a host MUST verify the reachability of an UNVERIFIED address 💅 and a newly learned address MUST start out as UNVERIFIED, unless it shows up in an R1 packet as a new Preferred locator 🫶 a host MAY also want to re-check an ACTIVE address after some time, and if it does, it flips the status back to UNVERIFIED and restarts address verification 🔥
so how do you actually start? usually a host sends a nonce to the new address 🌸 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 value MAY be copied into an ECHO_REQUEST sent in the rekeying UPDATE 🧚 but if the host is NOT changing its SPI, it MAY still use the ECHO_REQUEST parameter in an UPDATE message sent to the new address 💜 a host MAY also use other message exchanges as confirmation of the address reachability ⭐
now the lowkey genius part 😭 if you got a LOCATOR in an R1 and you reply with an I2 to the new address in that LOCATOR, getting the matching R2 back is sufficient proof of reachability for the Responder's preferred address 👑 and since extra verification could slow down the HIP-base exchange, a host MUST NOT separately verify reachability of a new Preferred locator that was received on an R1 🙈
sometimes it MAY be sufficient to use the arrival of data on a newly advertised SA as implicit address reachability verification, as shown in Figure 13, instead of waiting for a HIP packet to confirm it 🍓 in that 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
prepare incoming SA
NEW SPI in ESP_INFO (UPDATE)
<-----------------------------------
switch to new outgoing SA
data on new SA
----------------------------------->
mark address ACTIVE
Figure 13: Address Activation Via Use of a New SAwhen address verification is still going for a new Preferred locator, the host SHOULD pick a different locator that's listed as ACTIVE, if one is available, to keep talking 🌈 or it MAY use the new Preferred locator while it's still UNVERIFIED, but only to the extent Credit-Based Authorization permits 💅 that stuff is explained in Section 5.6. once verification succeeds, the new Preferred locator becomes ACTIVE 🎉✨
5.5. Changing the Preferred Locator
ok so a host MAY want to change its Preferred outgoing locator for different reasons 🦋 like, traffic information or ICMP error messages might show that the current preferred address may have become unreachable 😭 another reason is receiving a LOCATOR parameter that has the "P" bit set 🍓
to change the Preferred locator, the host runs this procedure 🧚
- if the new Preferred locator is ACTIVE, the Preferred locator is changed and the procedure succeeds 💖
- if the new Preferred locator is UNVERIFIED, the host starts verifying its reachability 🔥 it SHOULD use a different ACTIVE locator until verification completes, if one is available 🫶 or it MAY use the new Preferred locator, even though it's UNVERIFIED, to the extent Credit-Based Authorization permits 💅 once verification succeeds, the new Preferred locator becomes 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 can happen if, for example, ICMP error messages deprecate the Preferred locator but the peer hasn't yet indicated a new one 🙈
- if the new Preferred locator is DEPRECATED and there's at least one non-deprecated address, the host selects one of the non-deprecated addresses as a new Preferred locator and keeps going 🎀 if the selected address is UNVERIFIED, the address verification procedure described above applies 💜
5.6. Credit-Based Authorization
okay this is the anti-flooding bit 🛡️💅 to stop redirection-based flooding attacks, Credit-Based Authorization (CBA) is mandatory when a host sends data to an UNVERIFIED locator 😭 the following algorithm meets the security considerations for preventing 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] 🧚
5.6.1. Handling Payload Packets
so every host keeps 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 for the peer, and the peer's Preferred locator is UNVERIFIED with no ACTIVE alternative available, the host checks whether it can send the packet to the UNVERIFIED locator 👑 the packet SHOULD be sent if 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 🔥 and the peer's credit counter is NOT affected by packets the host sends to an ACTIVE locator of that peer 🫶
figure 14 shows what the host does when a packet comes in 🎀 and figure 15 shows the decision chain when a packet goes out ✨
Inbound
packet
|
| +----------------+ +---------------+
| | Increase | | Deliver |
+-----> | credit counter |-------------> | packet to |
| by packet size | | application |
+----------------+ +---------------+
Figure 14: Receiving Packets with Credit-Based Authorization 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
_________________
/ \ +---------------+
/ Credit counter \ No | |
| >= |-------------> | Drop packet |
\ packet size? / | |
\_________________/ +---------------+
|
| Yes
|
v
+---------------+ +---------------+
| Reduce credit | | Send packet |
| counter by |----------------> | to preferred |
| packet size | | address |
+---------------+ +---------------+
Figure 15: Sending Packets with Credit-Based Authorization5.6.2. Credit Aging
so a host makes sure the credit counters it keeps for its peers gradually go down over time 🌈 this "credit aging" stops a sneaky peer from building up credit really slowly and then spending it all at once in a big burst of redirected packets 😈💅
credit aging can be done by multiplying the credit counters by a factor, CreditAgingFactor (a fractional value less than one), at fixed time intervals of CreditAgingInterval length 🦋 picking good values for these is a big deal 🔥 a host needs to be able to keep sending to an UNVERIFIED address even when the peer sends at a slower rate than the host itself 🫶 if CreditAgingFactor or CreditAgingInterval are too small, the peer's credit counter might get too low to keep sending packets until address verification wraps up 😭
the parameter values proposed in this document are:
CreditAgingFactor 7/8
CreditAgingInterval 5 secondsthese values work well when the host transfers a file to the peer over a TCP connection and the end-to-end round-trip time does not exceed 500 milliseconds ⏱️✨ other credit-aging algorithms may use different values or different parameters, which may even be set up dynamically 🧚
- Security Considerations
okay bestie, this one is SERIOUS 💀🔥 the HIP mobility mechanism gives a secure way to update a host's IP address through HIP UPDATE packets 🔐 when a HIP UPDATE arrives, a HIP host cryptographically verifies the sender, so forging or replaying a HIP UPDATE packet is very difficult (see [RFC5201]) 💅 which means the security issues live in other attack domains 👀 the two we're looking at are malicious redirection of legitimate connections, and redirection-based flooding attacks using this protocol 😱 it breaks down like this 🦋
- Impersonation attacks
- direct conversation with the misled victim 🙈
- man-in-the-middle attack 💀
- DoS attacks
- flooding attacks (== bandwidth-exhaustion attacks)
- tool 1: direct flooding 🌸
- tool 2: flooding by zombies 🧟♀️
- tool 3: redirection-based flooding 💜
- memory-exhaustion attacks 🫠
- computational-exhaustion attacks 🫠
- flooding attacks (== bandwidth-exhaustion attacks)
we dig into each of these in the following sections 🔍✨ in Section 6.1 and Section 6.2, we assume that all users are using HIP 🫶 in Section 6.3 we look at the security ramifications when we have both HIP and non-HIP users 🌈 security considerations for Credit-Based Authorization are discussed in [SIMPLE-CBA] 🎀
6.1. Impersonation Attacks ✨
okay so an attacker who wants to be someone they're not has two main moves 😈. They can trick the victim into talking straight to them, or they can sit in the middle as a MitM (man-in-the-middle) between the victim and the peer they actually want to chat with. Without mobility support, both only work if the attacker is on the routing path between the victim and the peer, or if they trick the victim into starting the connection over a sketchy path (like by acting as a router or using spoofed DNS entries). 🕵️
The HIP extensions in this spec change the game 🎀. They add the ability to redirect a connection (like IPv6), both before and after it's established. If nobody takes precautions, an attacker could abuse redirection to impersonate a victim's peer from literally anywhere. Thankfully, the authentication and authorization mechanisms of the HIP base exchange [RFC5201] and the signatures in the UPDATE message shut that down. Also, owning a HIP association is securely linked to a HIP HI/HIT. If an attacker somehow uses a bug in an implementation or a weakness in some protocol to redirect a HIP connection, the original owner can always reclaim it, because they can always prove they own the private key tied to their public HI. 👑
MitM attacks are always possible if the attacker is around during the initial HIP base exchange and the hosts don't authenticate each other's identities. 💀 But once the opportunistic base exchange has happened, even a MitM can't steal the HIP connection anymore, because it's super hard to craft an UPDATE packet (or any HIP packet) that gets accepted as a legitimate update. UPDATE packets use HMAC and are signed. Even if an attacker can snoop packets to grab the SPI and HIT/HI, they still can't forge an UPDATE packet without knowing the secret keys. 🔐
6.2. Denial-of-Service Attacks 🌊
6.2.1. Flooding Attacks
the whole point of a denial-of-service attack is to drain some resource of the victim so they stop working properly. The attack can target the victim's network attachment (flooding attack), their memory, or their processing capacity. In a flooding attack, the attacker makes an excessive number of bogus or unwanted packets get sent to the victim, which fills up their available bandwidth. Note that the victim doesn't have to be a single node; it can also be an entire network. The attack basically works the same way in either case. 🌸
An effective DoS strategy is distributed denial of service (DDoS) 😤. The attacker conventionally spreads some viral software to as many nodes as possible. Under the attacker's control, the infected nodes, or "zombies", jointly send packets to the victim. With an 'army' like that, an attacker can take down even very high bandwidth networks/victims. 🧟
With the ability to redirect connections, an attacker could pull off a DDoS attack without distributing any viral code 🙈. Here, the attacker starts a large download from a server, then redirects that download to its victim. The attacker can repeat this with multiple servers. This threat is mitigated through reachability checks and credit-based authorization. Neither strategy eliminates 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 of the redirected packets. So the combo of a reachability check and credit-based authorization lowers a HIP redirection-based flooding attack to the level of a direct flooding attack, where the attacker itself sends the flood traffic to the victim. 💅
6.2.2. Memory/Computational-Exhaustion DoS Attacks
now we check whether the proposed extensions to HIP add any new DoS attacks (DoS attacks using the base HIP exchange and updates are discussed in [RFC5201]) 🧐. A simple attack is to send tons of UPDATE packets containing many IP addresses that aren't flagged as preferred. The attacker keeps sending these until the number of IP addresses associated with the attacker's HI crashes the system 😱. Therefore, there SHOULD be a limit to 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 [RFC5201].
a central server that has to handle a lot of mobile clients may consider increasing the SA lifetimes 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're now assuming an environment with both HIP and non-HIP aware hosts. Four cases exist:
- A HIP host redirects its connection onto a non-HIP host. The non-HIP host will drop the reachability packet, so this isn't a threat unless the HIP host is a MitM that could somehow respond successfully to the reachability check.
- 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.
- 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 happens 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. 🔄
- 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 simple solution is to prevent the use of HIP address check information to influence non-HIP sessions. 🚫
7. IANA Considerations 📋
this document defines a LOCATOR parameter for the Host Identity Protocol [RFC5201]. This parameter is defined in Section 4 with a Type of 193. 💖
this document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message Type, as defined in the Host Identity Protocol specification [RFC5201]. This parameter is defined in Section 5.3 with a value of 46. 🎀
8. Authors and Acknowledgments 🫶
Pekka Nikander and Jari Arkko originated this document 🌈. Christian Vogt and Thomas Henderson (editor) later joined as co-authors. Greg Perkins contributed the initial draft of the security section. Petri Jokela was a co-author of the initial individual submission.
the authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan Melen for many improvements to the document. 🙌
9. References 📚
9.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201,
April 2008.
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
ESP Transport Format with the Host Identity Protocol
(HIP)", RFC 5202, April 2008.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol
(HIP) Rendezvous Extension", RFC 5204, April 2008.9.2. Informative references
[CBA-MIPv6] Vogt, C. and J. Arkko, "Credit-Based Authorization for
Mobile IPv6 Early Binding Updates", Work in Progress,
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, December 2005.
[SIMPLE-CBA] Vogt, C. and J. Arkko, "Credit-Based Authorization for
Concurrent Reachability Verification", Work
in Progress, February 2006.Authors' Addresses 📮
Pekka Nikander
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Thomas R. Henderson (editor)
The Boeing Company
P.O. Box 3707
Seattle, WA
USA
EMail: thomas.r.henderson@boeing.com
Christian Vogt
Ericsson Research NomadicLab
Hirsalantie 11
JORVAS FIN-02420
FINLAND
Phone:
EMail: christian.vogt@ericsson.com
Jari Arkko
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.comFull Copyright Statement ⚖️
the IETF Trust holds the copyright for this one: Copyright (C) The IETF Trust (2008) 🧾.
this document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth there, the authors keep all their rights.
this document and the information in it are provided on an "AS IS" basis. The contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust and the Internet Engineering Task Force all disclaim every warranty, express or implied, including (but not limited to) any warranty that using the information won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. 💀
Intellectual Property 🔍
the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under those rights might or might not be available. It also doesn't claim to have made any independent effort to identify such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79. 📜
Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for implementers or users to use such proprietary rights, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 🦋
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Please address that information to the IETF at ietf-ipr@ietf.org. 💜
📦 where this page comes from
- ietf: rfc5206 2008-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms