RFC 8046
Host Mobility with the Host Identity Protocol
Host Mobility with the Host Identity Protocol 🦋
okay bestie, this is RFC 8046 and it's giving mobility 💖 It's a Standards Track doc from the IETF, published February 2017, with ISSN 2070-1721. The main editor is T. Henderson (Ed.) from the University of Washington, and C. Vogt (Independent) and J. Arkko (Ericsson) are co-authors. It obsoletes RFC 5206 (so that one is retired now 🫶). It doesn't update any other RFCs.
Abstract
okay so this doc adds a mobility extension to the Host Identity Protocol (HIP) ✨ The big new piece is a "LOCATOR_SET" parameter for HIP messages. It lets a HIP host tell its peers about other addresses it can be reached at. It also explains how that parameter keeps the conversation going when the IP address on one or both sides changes 🏃♀️💨 The same LOCATOR_SET can also support end-host multihoming, which is covered in RFC 8047. And again, this doc obsoletes RFC 5206 💅
Status of This Memo
this is an Internet Standards Track document 🎀
it's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. it got 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 🌸
for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc8046 🔗
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 of publication. please read those carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⚖️
Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Operating Environment . . . . . . . . . . . . . . . . . . 7
3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 9
3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . 10
3.2.2. Mobility with a Single SA Pair (Mobile-Initiated
Rekey) . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. Mobility Messaging through the Rendezvous Server . . 13
3.2.4. Network Renumbering . . . . . . . . . . . . . . . . . 14
3.3. Other Considerations . . . . . . . . . . . . . . . . . . 14
3.3.1. Address Verification . . . . . . . . . . . . . . . . 14
3.3.2. Credit-Based Authorization . . . . . . . . . . . . . 15
3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 16
4. LOCATOR_SET Parameter Format . . . . . . . . . . . . . . . . 16
4.1. Traffic Type and Preferred Locator . . . . . . . . . . . 18
4.2. Locator Type and Locator . . . . . . . . . . . . . . . . 19
4.3. UPDATE Packet with Included LOCATOR_SET . . . . . . . . . 19
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Locator Data Structure and Status . . . . . . . . . . . . 19
5.2. Sending the LOCATOR_SET . . . . . . . . . . . . . . . . . 21
5.3. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 22
5.4. Verifying Address Reachability . . . . . . . . . . . . . 24
5.5. Changing the Preferred Locator . . . . . . . . . . . . . 26
5.6. Credit-Based Authorization . . . . . . . . . . . . . . . 26
5.6.1. Handling Payload Packets . . . . . . . . . . . . . . 27
5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 30
6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 31
6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . 31
6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 32
6.3. Mixed Deployment Environment . . . . . . . . . . . . . . 32
6.4. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 33
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Differences from RFC 5206 . . . . . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Normative References . . . . . . . . . . . . . . . . . . 35
9.2. Informative References . . . . . . . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 371. Introduction and Scope ✨
okay so here's the vibe. The Host Identity Protocol (HIP) [RFC7401] splits the transport layer (TCP, UDP, and friends) from the internetworking layer (IPv4 and IPv6) 🫧 It does this by using public/private key pairs as host identities instead of IP addresses. So the overlying sublayers, like transport sockets and Encapsulating Security Payload (ESP) Security Associations (SAs), get bound to those identities, and IP addresses are only used for packet forwarding. The catch is that each host still needs to know at least one IP address where its peers can be reached. At the start, those are the IP addresses used during the HIP base exchange 💅
that decoupling is what makes new network-layer mobility and host multihoming possible. There are a LOT of possible variations, and this doc only handles the messaging and procedure for basic network-level host mobility 🌈 The fancier mobility scenarios, multihoming, and other variations are left for later study. Here's what's in scope:
- This doc defines a
LOCATOR_SETparameter for HIP messages. It lets a HIP host tell a peer about alternate locators where it can be reached. A locator might be a plain IP address, or it might come with extra multiplexing and demultiplexing context so the lower layers can handle packets properly. For example, an IP address may need to be paired with an ESP Security Parameter Index (SPI) so packets go out on the correct SA for that address 🔐 - This doc also specifies the messaging and procedure for end-host mobility of a HIP host. The message flows that make host mobility work, including address verification methods, are defined here 🦋
- The HIP rendezvous server (RVS) [RFC8004] can help manage simultaneous mobility of both hosts, initial reachability of a mobile host, location privacy, and some modes of NAT traversal. Using the HIP RVS to manage simultaneous mobility of both hosts is specified in this doc 🧚
here's what's out of scope, so don't go looking for it here 🙈
- Even though the same
LOCATOR_SETparameter supports host multihoming (using a number of addresses at once), the multihoming procedures are out of scope and are specified in [RFC8047]. - HIP can potentially be used with transports other than the ESP transport format [RFC7402], but this doc mostly assumes ESP and leaves other transport formats for later study.
- Localized mobility management extensions are not considered. Those are mobility techniques that don't directly signal the correspondent node. This doc is about end-to-end mobility 🌸
- Making underlying IP mobility transparent to the transport layer has real consequences for transport congestion control, path MTU selection, and Quality of Service (QoS). Transport-layer mobility triggers, and the right transport response to a HIP mobility or multihoming address change, are also outside this doc's scope.
the main sections are organized like this 🗺️ Section 3 gives a summary overview of operations, scenarios, and other considerations. Section 4 specifies the messaging parameter syntax. Section 5 specifies the processing rules for messages. Section 6 describes security considerations for this spec.
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 [RFC2119]. these are the official BCP 14 vibes, so read them literally 💖
LOCATOR_SET. A HIP parameter containing zero or more Locator fields. 🎀
locator. A name that controls how the packet is routed through the network and how it gets demultiplexed by the end host. It can include a concatenation 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 🗝️
Locator. When it's capitalized in the middle of a sentence, this term refers to the encoding of a locator within the LOCATOR_SET parameter (in other words, the 'Locator' field of the parameter) ✨
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. Certain locators get labeled as preferred when a host advertises its locator set to its peer. By default, the locators used in the HIP base exchange are the preferred locators. How preferred locators work, including the case where multiple address scopes and families are in use, is defined more in [RFC8047] than in this doc 👑
Credit-Based Authorization (CBA). A mechanism that lets a host send a certain amount of data to a peer's newly announced locator before the result of mandatory address verification is known 💸
3. Protocol Model 🧚♀️
this section is an overview, and a more detailed specification follows it 🫶
3.1. Operating Environment ✨
okay so HIP [RFC7401] is a key establishment and parameter negotiation protocol 🔑 Its main jobs are authenticating host messages based on host identities and setting up SAs for the ESP transport format [RFC7402], and maybe other protocols later on 🦋
+--------------------+ +--------------------+
| | | |
| +------------+ | | +------------+ |
| | 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 operation in an end-to-end fashion. This document adds an extension to HIP so hosts can be mobile 🚀 The extensions to the HIP base protocol let a host signal new addressing information to its peer inside HIP messages. The messages are authenticated with a signature or a keyed Hash Message Authentication Code (HMAC), based on the sender's Host Identity (HI). This document specifies the format of the new addressing parameter (LOCATOR_SET), the procedures for sending and processing it to enable basic host mobility, and the procedures for a concurrent address verification mechanism. Iconic, honestly 💅
---------
| 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 Host Mobility and MultihomingFigure 2 is a layered view of a HIP-enabled stack using the ESP transport format 🧚 In HIP, upper-layer protocols (TCP and ESP in this figure) are bound to Host Identity Tags (HITs) and not IP addresses. The HIP sublayer is the one in charge of keeping the binding between HITs and IP addresses. The SPI is what tells you which HITs an incoming packet belongs to. The block labeled "MH" is the function that manages those bindings at the ESP and HIP sublayers for mobility (specified in this document) and multihoming (specified in [RFC8047]).
Let's start with the case where there's no mobility or multihoming, as specified in the base protocol [RFC7401] 💖 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, and the only fields used for the binding at the HIP layer are the fields exposed by ESP (the SPI and HITs). For the inbound direction, the SPI is all that is required to find the right host context. ESP rekeying events change the mapping between the HIT pair and SPI, but they do not change the IP addresses.
Now for the mobility event, where a host moves to another IP address 🏃♀️ Two things need to happen here. First, the peer has to be told about the address change using a HIP UPDATE message. Second, each host has to update its local bindings at the HIP sublayer (the new IP addresses). It's possible for both the SPIs and the IP addresses to change at once in a single UPDATE, and the protocol described here supports that. Telling the transport layer about the path change (for example, so it can reset congestion control variables) might be desired, but this specification does not address that internal notification. Also, the procedures for traversing network address translators (NATs) and firewalls, including NATs and firewalls that may understand HIP, can complicate the basic scenario above, and this document does not cover them 🙈
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 additional end-to-end tunneling or a 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 the ESP anti-replay window doesn't get violated 😭 Addresses may also be affiliated with transport ports in certain tunneling scenarios. Locators can simply be traditional network addresses too. The format of the Locator fields in the LOCATOR_SET 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 single LOCATOR_SET parameter and a single ESP_INFO parameter 📮 The peer acknowledges this UPDATE packet. For reliability when packets get lost, the UPDATE packet is retransmitted as defined in the HIP specification [RFC7401]. 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 [RFC7402], 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 [RFC7401] and the ESP extension [RFC7402] 🔥
When using ESP (and possibly other transport modes in the future), the host can receive packets protected by 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 those new addresses until they have reliably and securely updated the set of addresses they associate with the sending host. Also, mobility can change the path characteristics so much that reordering happens and packets fall outside the ESP anti-replay window for the SA, which means rekeying is required 💀
3.2. Protocol Overview
In this section, we quickly introduce a few usage scenarios for HIP host mobility ✨ These scenarios assume HIP is being used with the ESP transform [RFC7402], although other scenarios may be defined later. To get these scenarios, the reader should be at least minimally familiar with the HIP specification [RFC7401] and with using ESP with HIP [RFC7402]. According to these specifications, the data traffic in a HIP session is protected with ESP, and the ESP SPI acts as an index to the right host-to-host context. More specification details are found later in Sections 4 and 5.
The scenarios below assume the two hosts have completed a single HIP base exchange with each other. So both hosts have one incoming and one outgoing SA. Also, each SA uses the same pair of IP addresses, which are the ones used in the base exchange 👑
The readdressing protocol is asymmetric 🫶 A mobile host tells a peer host about changes of IP addresses on the affected SPIs. The readdressing exchange is designed to be piggybacked on existing HIP exchanges. To support mobility, the LOCATOR_SET parameter is carried in UPDATE packets.
The scenarios below sometimes describe addresses as being in an ACTIVE, UNVERIFIED, or DEPRECATED state 🌈 From a host's point of view, newly learned addresses of the peer need to be verified before they're put into active service, and addresses removed by the peer are put into a deprecated state. Under limited conditions described below (Section 5.6), an UNVERIFIED address may be used. The addressing states are defined more formally in Section 5.1.
Hosts that use link-local addresses as source addresses in their HIP handshakes may not be reachable by a mobile peer. Such hosts SHOULD provide a globally routable address either in the initial handshake or via the LOCATOR_SET parameter. Don't skip this one, bestie 😭🫶
3.2.1. Mobility with a Single SA Pair (No Rekeying) ✨
okay so bestie, sometimes a mobile host has to swap the IP address on its interface 🦋 That can happen because the IPv6 prefixes on the link changed, a PPP link reconnected, it got a new DHCP lease, or the device actually moved to a different subnet. To keep its communication context alive, the host has to tell its peers about the new address. This first example is the simplest possible setup: the mobile host has one interface, one IP address in use within the HIP session, one pair of SAs (one inbound, one outbound), and no rekeying on the SAs. We also assume the new address is in the same address family (IPv4 or IPv6) as the old one. Figure 3 shows this scenario. The conventions for message parameter notation in figures (the use of parentheses and brackets) are defined in Section 2.2 of [RFC7401] 💅
Mobile Host Peer Host
UPDATE(ESP_INFO, LOCATOR_SET, SEQ)
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->Figure 3: Readdress without Rekeying but with Address Check
Here's how the packet processing goes, step by step 🎀
- The mobile host might be disconnected from the peer for a brief moment while it switches from one IP address to another. This is sometimes called the "break-before-make" case 💀 The host may also grab its new IP address before it drops the old one ("make-before-break" case). Either way, once it has a new IP address, the mobile host sends a
LOCATOR_SETparameter to the peer in an UPDATE message. That UPDATE also carries anESP_INFOparameter with the values of the old and new SPIs for a security association. In this case, both theOLD SPIandNEW SPIparameters are set to the value of the preexisting incoming SPI. ThisESP_INFOdoes not trigger a rekeying event. It's only there for parameter-inspecting firewalls on the path (the [RFC5207] document describes some firewall scenarios where a HIP-aware firewall may want to associate ESP flows with host identities 🧚). TheLOCATOR_SETparameter holds the new IP address (embedded in a Locator Type of "1", defined below) and a lifetime for that locator. The mobile host waits for this UPDATE to be acknowledged, and retransmits if necessary, as specified in the base specification [RFC7401]. - 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_REQUESTparameter of the UPDATE it sends back to the mobile host. It also includes anESP_INFOparameter with both theOLD SPIandNEW SPIparameters 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. This UPDATE also acknowledges the mobile host's UPDATE that kicked off the exchange. The peer host waits for its UPDATE to be acknowledged, and retransmits if necessary, as specified in the base specification [RFC7401]. 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, which contains the ACK of the peer's UPDATE. This UPDATE is not protected by a retransmission timer, because it doesn't contain aSEQparameter requesting acknowledgment. Once the peer host receives thisECHO_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 (for the time being), 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 from Figure 3 gets a little tweak. The UPDATE 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 way it normally does for HIP rekeying, except that the new address stays UNVERIFIED until the UPDATE nonce challenge comes back, as described above. Figure 4 illustrates this scenario 🦋
Mobile 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 4: Readdress with Mobile-Initiated Rekey
3.2.3. Mobility Messaging through the Rendezvous Server 🧚
Section 6.11 of [RFC7401] lays out the procedures for sending HIP UPDATE packets. The UPDATE packets are protected by a timer that uses exponential backoff, and they get resent UPDATE_RETRY_MAX times. But here's the tricky part: the peer might itself be moving while the local host is trying to update the IP address bindings of the HIP association. This is sometimes called the "double-jump" mobility problem 😭 Each host's UPDATE packets get sent at the same time to a stale address of the peer, so the two hosts can no longer reach each other.
The HIP Rendezvous Extension [RFC8004] describes a rendezvous service that lets the I1 packet from the base exchange get relayed from a stable or well-known public IP address to the host's current IP address. You can support double-jump mobility with this rendezvous service if you follow these extensions to the specifications in [RFC8004] and [RFC7401] 🎀
- The mobile host sending an UPDATE to the peer, and not receiving an ACK, MAY resend the UPDATE to an RVS of the peer, if such a server is known. The host MAY try the RVS of the peer up to UPDATE_RETRY_MAX times, as specified in [RFC7401]. The host MAY try to use the peer's RVS before it has tried UPDATE_RETRY_MAX times to the last working address (i.e., the RVS MAY be tried in parallel with retries to the last working address). How aggressively a host replicates its UPDATEs to multiple destinations, trying candidates in parallel instead of one after another, is a policy choice outside of this specification.
- An RVS that supports the UPDATE forwarding extensions specified here MUST modify the UPDATE in the same manner as it modifies the I1 packet before forwarding. Specifically, it MUST rewrite the IP header source and destination addresses, recompute the IP header checksum, and include the
FROMandRVS_HMACparameters 💅 - A host receiving an UPDATE packet MUST be prepared to process the
FROMandRVS_HMACparameters, and MUST include aVIA_RVSparameter in the UPDATE reply that contains the ACK of the UPDATESEQ. 🫶 - An Initiator receiving a
VIA_RVSin the UPDATE reply should initiate address reachability tests (described later in this document) towards the end host's address and not towards the address included in theVIA_RVS. 👑
This scenario requires that hosts using RVSs also update their current address bindings with their RVS whenever a mobility event happens. [RFC8004] doesn't specify how to update the RVS with a client host's new address. Section 3.2 of [RFC8003] describes how a host may send a REG_REQUEST either in an I2 packet (if there is no active association) or in an UPDATE packet (if such an association exists). According to the procedures in [RFC8003], if a mobile host has an active registration, it may use the mobility updates specified here, within the context of that association, to readdress the association 🦋
3.2.4. Network Renumbering 🌈
It's expected that IPv6 networks will get renumbered way more often than most IPv4 networks. From an end-host point of view, network renumbering is basically like mobility, so the procedures described here also apply to notifying a peer of a changed address ✨
3.3. Other Considerations 💜
3.3.1. Address Verification 🔍
When a HIP host receives a set of locators from another HIP host in a LOCATOR_SET, it doesn't necessarily know whether the other host is actually reachable at the claimed addresses. In fact, a malicious peer host may be intentionally giving bogus addresses to cause a packet flood towards target addresses [RFC4225]. Therefore, the HIP host needs to check first that the peer is reachable at the new address 😤
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 arrived at the new address. This can include the exchange of a nonce, or the generation of a new SPI and observation of data arriving on that new SPI. More details are in Section 5.4 of this document 🧠
An extra potential benefit of performing address verification is that it lets NATs and firewalls along the new path obtain the peer host's inbound SPI 🌟
3.3.2. Credit-Based Authorization ✨
okay so CBA lets a host safely start using a new locator even though it hasn't confirmed that the peer can actually be reached at that address yet 🦋 It's built on three hypotheses:
- A flooding attacker usually wants to multiply the packets it sends for its attack, because bandwidth is an abundant resource for lots of victims. 💅
- An attacker can often cause unamplified flooding by sending packets straight at its victim, either by addressing the victim directly or by steering the packets along a specific path with an IPv6 Routing header, if Routing headers aren't filtered by firewalls. 😭
- So a redirection-based flooding attack (one without CBA and return routability checks) takes extra effort to set up, and that effort only pays off for the attacker if it can get amplification this way. 🧠
Based on that, CBA doesn't try to get rid of malicious packet redirection in the first place. Instead it stops the amplification. It does this by limiting how much data a host can send to a peer's unverified address, based on how much data it recently received from that peer. So redirection-based flooding attacks become less attractive than, for example, pure direct flooding, where the attacker sends bogus packets to the victim itself. 👑
Figure 5 shows CBA in action. Host B measures how much data it recently received from peer A. When A readdresses, B keeps sending packets to A's new, unverified address for as long as the sum of the packet sizes stays within the measured, received data volume. Once the credit runs low, B stops sending further packets to A until A's address becomes ACTIVE. The address change could be due to mobility, multihoming, or any other reason. 🌸 What the figure doesn't show is the effect of credit aging (Section 5.6.2), which is a mechanism for dampening 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 5: Readdressing Scenario
This document doesn't say how to set the credit limit value, but the goal is to let data transfers keep going without much interruption while the new address gets verified. 🎀 A simple heuristic, if the sender roughly knows its round-trip time (RTT) and its current sending rate to the host, is to allow enough credit to keep up that sending rate for a duration of two or three RTTs.
3.3.3. Preferred Locator 💜
When a host has multiple locators, the peer host needs to decide which one to use for outbound packets. A host might prefer to receive data on a particular inbound interface, and HIP lets it mark a particular locator as a preferred locator and tell the peer about it (see Section 4). 🫶
4. LOCATOR_SET Parameter Format 💖
The LOCATOR_SET parameter has a type number that counts as a "critical parameter" under the definition in [RFC7401], so such parameter types MUST be recognized and processed by the recipient. 🔥 The parameter is made up of the standard HIP parameter Type and Length fields, plus zero or more Locator sub-parameters. Each Locator sub-parameter contains a Traffic Type, Locator Type, Locator Length, preferred locator bit ("P" bit), Locator Lifetime, and a Locator encoding. A LOCATOR_SET with zero Locator fields is permitted, but it has the effect of deprecating all addresses. 💀
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 6: LOCATOR_SET Parameter Format
- 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: Lifetime of the locator, in seconds.
- Locator: The locator whose semantics and encoding are indicated by the Locator Type field. All sub-fields of the Locator field are integral multiples of four octets in length.
The Locator Lifetime (lifetime) tells you how long the following locator is expected to stay valid, measured in seconds. ⏳ Each locator MUST have a non-zero lifetime. The address is expected to become deprecated once the specified number of seconds has 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 address scope. 🙈
4.1. Traffic Type and Preferred Locator 🍓
These Traffic Type values are defined:
0: Both signaling (HIP control packets) and user data.1: Signaling packets only.2: Data packets only.
When the "P" bit is set, it has scope over the corresponding Traffic Type. So if the "P" bit is set for Traffic Type "2", for example, the locator is preferred for data packets. 📦 If there's a conflict (say the "P" bit is set for an address of Type "0" and for a different address of Type "2"), the more specific Traffic Type rule applies, which in this case means "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 destination locator from the set of active locators. 🧚
4.2. Locator Type and Locator 🌈
These Locator Type values are defined, along with the semantics of the Locator field they go with:
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_SET ⭐
A bunch of different parameter combinations are possible in an UPDATE packet (e.g., see Section 3.2). In this document, though, procedures are only defined for the case where one LOCATOR_SET and one ESP_INFO parameter are used in any HIP packet. 🙌 Any UPDATE packet that includes a LOCATOR_SET parameter SHOULD include both an HMAC and a HIP_SIGNATURE parameter.
The UPDATE MAY also include a HOST_ID parameter, which can be handy for HIP-aware firewalls that are inspecting the HIP messages for the first time. If the UPDATE includes the HOST_ID parameter, the receiving host MUST verify that the HOST_ID matches the one used to establish the HIP association, and the HIP_SIGNATURE MUST verify with the public key associated with this HOST_ID parameter. 🔐
The relationship between the announced Locators and any ESP_INFO parameters in the packet is defined in Section 5.2. This document doesn't support any elements of procedure for sending more than one LOCATOR_SET or ESP_INFO parameter in a single UPDATE. 🚫
5. Processing Rules 🎀
This section describes the rules for sending and receiving the LOCATOR_SET parameter, testing address reachability, and using CBA on UNVERIFIED locators. 🦋✨
5.1. Locator Data Structure and Status ✨
okay so every locator that shows up in a LOCATOR_SET parameter gets its own little bundle of state 🧳 Each one tracks:
- 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 basically the locator's reachability diary 📓
UNVERIFIED: nobody has checked yet whether this address is reachable.ACTIVE: reachability has been verified and the address hasn't been deprecated. 💖DEPRECATED: the locator's lifetime has run out. 💀
These are the state changes that are allowed 🦋
- UNVERIFIED to ACTIVE: the reachability procedure completes successfully.
- UNVERIFIED to DEPRECATED: the locator's lifetime expires while it's still UNVERIFIED.
- ACTIVE to DEPRECATED: the locator's lifetime expires while it's ACTIVE.
- ACTIVE to UNVERIFIED: there's been no traffic on the address for a while, and local policy says it has to be re-verified before it gets used again.
- DEPRECATED to UNVERIFIED: the host gets a fresh lifetime for the locator.
A DEPRECATED address MUST NOT be changed to ACTIVE without first verifying its reachability. Hard rule, no exceptions, periodt 🙅♀️
Heads up, the state of whether a locator is preferred is not necessarily the same as the preferred bit in the Locator sub-parameter the peer sent. 🙈 Peers can recommend certain locators as preferred, but whether you actually use one as a preferred locator is a local decision, possibly shaped by local policy. Your house, your rules 🏠
An implementation would typically keep similar state about its own locators that it has offered to the peer too, so you're tracking both sides of the convo 🪞
A locator lifetime that never expires can be signified by setting the lifetime field to the maximum (unsigned) value. ♾️
Last bit: the locators used to establish the HIP association are assumed, by default, to be the initial preferred locators in ACTIVE state, with an unbounded lifetime. They start out as the main characters 👑
5.2. Sending the LOCATOR_SET 📮
When to send the LOCATOR_SET is a local policy issue, so you get to decide the timing 🕰️ That said, it is RECOMMENDED that a host send a LOCATOR_SET whenever it notices its IP addresses in use on an active HIP association have changed and it assumes the change is going to stick around for at least a few seconds. Rapidly sending LOCATOR_SETs that force the peer to keep changing its preferred address SHOULD be avoided. Nobody wants a flickering address situation 😭
Sending a new LOCATOR_SET parameter replaces the locator information from any LOCATOR_SET you sent before. So if you send a new one, you have to keep including all your active locators, not just the new one 🧺 And hosts MUST NOT announce broadcast or multicast addresses in LOCATOR_SETs. Not allowed, bestie 🚫
We're now going to walk through a few cases from Section 3.2 🎀 For all of these, the Traffic Type for each locator is set to "0". (Other values for Traffic Type may be specified in documents that separate the HIP control plane from data-plane traffic.) Other mobility cases are possible, but they're left for further study 🔭
- Host mobility with no multihoming and no rekeying. The mobile host creates a single UPDATE containing a single ESP_INFO with a single LOCATOR_SET parameter. The ESP_INFO has the current SPI value in both the
OLD SPIandNEW SPIfields. The LOCATOR_SET has a single Locator with aLocator Typeof"1", and the SPI MUST match the one in the ESP_INFO. The preferred bit SHOULD be set, and theLocator Lifetimeis set according to local policy. The UPDATE also includes aSEQparameter like usual. This packet gets retransmitted as defined in the HIP specification [RFC7401]. The UPDATE should be sent to the peer's preferred IP address, with an IP source address that matches the address in the LOCATOR_SET 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_SET parameter (with a single address). The ESP_INFO has the current SPI value in the
OLD SPI, the new SPI value in theNEW SPI, and aKEYMAT Indexpicked by local policy. Optionally, the host can choose to start a Diffie-Hellman rekey by including aDIFFIE_HELLMANparameter. The LOCATOR_SET has a single Locator with aLocator Typeof"1", and the SPI MUST match theNEW SPIin the ESP_INFO. Otherwise, the steps are identical to the case where no rekeying is started. 🔁
5.3. Handling Received LOCATOR_SETs 📥
A host SHOULD be prepared to receive a single LOCATOR_SET parameter in a HIP UPDATE packet. Getting multiple LOCATOR_SET parameters in one packet, or in HIP packets that aren't UPDATEs, is outside the scope of this spec, so we're not touching that drama 🙅♀️
Here's the tricky part: a host sending the LOCATOR_SET might send the same parameter in different UPDATE messages to different destination addresses, including possibly the RVS of the host. So the host receiving the LOCATOR_SET MUST be prepared to handle duplicate LOCATOR_SETs sent to more than one of its addresses. Because of that, the host MUST detect and avoid reprocessing a LOCATOR_SET parameter that's redundant with one that was recently received and processed. Don't do the same work twice, babe 👯♀️
This document describes sending both ESP_INFO and LOCATOR_SET parameters in an UPDATE. The ESP_INFO is included when there's a need to rekey or key a new SPI. Otherwise it's included for the possible benefit of HIP-aware NATs and firewalls 🧱 The LOCATOR_SET contains a complete listing of the locators the host wants to make or keep active for the HIP association. 🗂️
In general, how a LOCATOR_SET gets processed depends on the packet type it's included in. Here, we only describe the case where ESP_INFO is present and a single LOCATOR_SET and ESP_INFO are sent in an UPDATE message. Other cases are for further study. The steps below cover each of the cases described in Section 5.2 ✅
The processing of ESP_INFO and LOCATOR_SET parameters is meant to be modular, so it can support future generalization to including 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 contain a new SPI value mapped to an existing SPI, while a Locator Type of "1" will only contain a reference to the new SPI. Order matters, bestie 🪜
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 says whether an SA is being rekeyed, created, deprecated, or just identified for the benefit of HIP-aware NATs and firewalls. The host looks at the OLD SPI and NEW SPI values in the ESP_INFO parameter:
- (no rekeying) If the
OLD SPIequals theNEW SPIand both correspond to an existing SPI, the ESP_INFO is gratuitous (provided for HIP-aware NATs and firewalls), 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 the HIP ESP rekeying procedures by creating a new outbound SA with an SPI that corresponds to theNEW SPI, with no addresses bound to this SPI. Note that locators in the LOCATOR_SET parameter will reference this new SPI instead of the old one. 🔑 - (new SA) If the
OLD SPIvalue is zero and theNEW SPIis a new non-zero value, then the peer is requesting a new SA. 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 get put into the DEPRECATED state. 🪦
If none of the above cases apply, a protocol error has happened, and processing of the UPDATE stops. 🚨
Next up, the locators in the LOCATOR_SET parameter get processed. For each locator listed there, check that the address in it is a legal unicast or anycast address. In other words, the address MUST NOT be a broadcast or multicast address. Note that some implementations MAY accept addresses that indicate the local host, since it might be allowed for the host to run HIP with itself 🪞
The rest of this assumes all Locators are of Type "1" with a Traffic Type of "0". Other cases are for further study 🔭
For each Type "1" address listed in the LOCATOR_SET parameter, the host checks whether the address is already bound to the SPI indicated. If it's already bound, its lifetime gets updated. If the address is DEPRECATED, its status changes to UNVERIFIED. If the address isn't already bound, it gets added, and its status is set to UNVERIFIED. Then, every address corresponding to the SPI that was NOT listed in the LOCATOR_SET parameter gets marked as DEPRECATED. Bye-bye 👋
So at the end of processing, the addresses listed in the LOCATOR_SET parameter are either UNVERIFIED or ACTIVE, and any old addresses on the old SA that aren't listed in the LOCATOR_SET parameter are DEPRECATED. Clean slate ✨
Once the host has processed the locators, if the LOCATOR_SET parameter contains a new preferred locator, the host SHOULD initiate a change of the preferred locator. This means the host has to verify reachability of the associated address first, and only then switch the preferred locator. See Section 5.5 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 with a Notify Message Type of LOCATOR_TYPE_UNSUPPORTED. The Notification Data field should contain 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. 🙋♀️
Quick reminder: a host MAY add the source IP address of a received HIP packet as a candidate locator for the peer, even if it's not listed in the peer's LOCATOR_SET. But it SHOULD prefer the locators that are explicitly listed in the LOCATOR_SET. Listed > guessed, always 💅
5.4. Verifying Address Reachability ✨
okay bestie, so first things first: a host MUST verify the reachability of an UNVERIFIED address 🔍 no cap, that's non-negotiable. A newly learned address starts out UNVERIFIED, and it MUST be set that way, unless the new address 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 🕰️ in which case it flips the status back to UNVERIFIED and kicks off address verification again. A typical check that's protected by retransmission timers is to tuck an ECHO REQUEST inside an UPDATE sent to the new address 🎀
A host usually starts verification by sending a nonce to the new address 🌸 A host MAY pick from different message exchanges or different nonce values, as long as it proves the peer got the nonce and replied to it at 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 that random value MAY be copied into an ECHO_REQUEST sent in the rekeying UPDATE ✨ But if the host isn't changing its SPI, it MAY still use the ECHO_REQUEST parameter for verification, just with some other random value 🦋 A host MAY also use other message exchanges to confirm address reachability 💜
Sometimes it MAY be enough to treat data arriving on a newly advertised SA as implicit address reachability verification 😭 as shown in Figure 7, so you don't have to wait for the confirmation via a HIP packet. In that case, a host advertising a new SPI as part of its address reachability check SHOULD be ready to receive traffic on the new SA 🧚
Mobile Host Peer Host
UPDATE(ESP_INFO, LOCATOR_SET, ...)
---------------------------------->
prepare incoming SA
UPDATE(ESP_INFO, ...) with new SPI
<-----------------------------------
switch to new outgoing SA
data on new SA
----------------------------------->
mark address ACTIVE
UPDATE(ACK, ECHO_RESPONSE) later arrives
----------------------------------->
Figure 7: Address Activation via Use of a New SAWhen address verification is running for a new preferred locator, the host SHOULD pick a different locator listed as ACTIVE 🏃♀️ to keep talking while verification finishes, if one is available. Or, the host MAY use the new preferred locator while it's still UNVERIFIED, but only to the extent CBA permits 🚦 CBA is explained in Section 5.6. Once address verification succeeds, the new preferred locator becomes ACTIVE 🎉👑
5.5. Changing the Preferred Locator 🦋
A host MAY want to change its preferred outgoing locator for different reasons 🌈 for example, because traffic information or ICMP error messages suggest the current preferred address may have become unreachable 😬 Another reason is receiving a LOCATOR_SET parameter with the "P" bit set 💌
To change the preferred locator, the host goes through this procedure 📋
- If the new preferred locator has an ACTIVE status, the preferred locator changes and the procedure succeeds ✅
- If the new preferred locator has an 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 💖 Or the host MAY use the new preferred locator, even while it's UNVERIFIED, to the extent CBA permits. Once address verification succeeds, the new preferred locator becomes ACTIVE and is no longer governed by CBA 🥳
- 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 local policy 🎰 This can happen when, for example, ICMP error messages deprecate the preferred locator but the peer hasn't yet indicated a new one 🙈
- If the new preferred locator has a DEPRECATED status and there's at least one non-deprecated address, the host selects one of the non-deprecated addresses as its new preferred locator and carries on ✨ If the selected address is UNVERIFIED, the address verification procedure described above applies 🫧
5.6. Credit-Based Authorization 💸
To prevent redirection-based flooding attacks, the use of a CBA approach MUST be used when a host sends data to an UNVERIFIED locator 🛡️ The following algorithm deals with 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 📦
A 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 to send to the peer, and the peer's preferred locator is UNVERIFIED with no alternative ACTIVE locator available, the host checks whether it can send the packet to the UNVERIFIED locator 🔍 The packet SHOULD be sent if the credit counter value is higher than the size of the outbound packet ✅ If the credit counter is too low, the packet MUST be discarded or buffered until address verification succeeds 🗑️📥 When a packet is sent to a peer at an UNVERIFIED locator, the peer's credit counter MUST be reduced by the size of the packet 📉 The peer's credit counter isn't affected by packets the host sends to an ACTIVE locator of that peer 🙌
Figure 8 shows what the host does when a packet is received 📬 and Figure 9 shows the decision chain for when a packet is sent 🗺️
Inbound
Packet
|
| +----------------+ +---------------+
| | Increase | | Deliver |
+-----> | credit counter |-------------> | packet to |
| by packet size | | application |
+----------------+ +---------------+
Figure 8: 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
_________________
/ \ +---------------+
/ Is credit counter \ No | |
| >= |-------------> | Drop or |
\ packet size? / | buffer packet |
\_________________/ +---------------+
|
| Yes
|
v
+---------------+ +---------------+
| Reduce credit | | Send packet |
| counter by |----------------> | to preferred |
| packet size | | address |
+---------------+ +---------------+
Figure 9: Sending Packets with Credit-Based Authorization5.6.2. Credit Aging 🕰️
A host makes sure the credit counters it keeps for its peers gradually decrease over time ⏳ This "credit aging" stops a malicious peer from building up credit very slowly and then spending it all at once on a severe burst of redirected packets 💥
Credit aging may be done by multiplying credit counters by a factor, CreditAgingFactor (a fractional value less than one), at fixed-time intervals of CreditAgingInterval length 🧁 Picking good values for CreditAgingFactor and CreditAgingInterval really matters 🎯 so a host can keep sending packets to an UNVERIFIED address even when the peer sends at a lower rate than the host itself. When CreditAgingFactor or CreditAgingInterval are too small, the peer's credit counter might get too low to keep sending packets until address verification concludes 😵
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 doesn't exceed 500 milliseconds 🌟 Alternative credit-aging algorithms may use other values or different parameters, which may even be dynamically established 🌈
6. Security Considerations 🔐
Heads up, this section is serious business 🚨 but we're going through it anyway, bestie 💪
The HIP mobility mechanism gives you a secure way to update a host's IP address via HIP UPDATE packets 🔒 When one arrives, a HIP host cryptographically verifies the sender of the UPDATE, so forging or replaying a HIP UPDATE packet is very difficult (see [RFC7401]) 🧱 That means the security issues live in other attack domains 🕵️♀️ The two we look at are malicious redirection of legitimate connections, and redirection-based flooding attacks using this protocol 🌊 This can be broken down into the following:
1) Impersonation attacks
- direct conversation with the misled victim
- man-in-the-middle (MitM) attack
2) Denial-of-service (DoS) attacks
- flooding attacks (== bandwidth-exhaustion attacks)
* tool 1: direct flooding
* tool 2: flooding by botnets
* tool 3: redirection-based flooding
- memory-exhaustion attacks
- computational-exhaustion attacks
3) Privacy concernsWe'll dig into each of these in the following sections 🔍 In Sections 6.1 and 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 hosts 🫂
6.1. Impersonation Attacks 🎭
okay so an attacker who wants to pretend to be someone else is going to try to trick the victim into talking straight to them, or sit in the middle as a MitM between the victim and the peer they actually want. Without mobility support, that only works 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 wrong path (like pretending to be a router or using spoofed DNS entries). 👀
The HIP extensions in this spec change the game 🔄 because they add the ability to redirect a connection, both before and after it's established. If nobody takes precautions, an attacker could abuse that redirect feature to impersonate a victim's peer from any random location. But the authentication and authorization mechanisms of the HIP base exchange [RFC7401] 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 to redirect a HIP connection, the original owner can always take it back, because they can always prove they own the private key tied to their public HI 🔑💖.
MitM attacks are possible if an on-path attacker is around during the initial HIP base exchange and the hosts don't authenticate each other's identities 😬. But once that opportunistic base exchange has happened, a MitM who shows up later can't steal the HIP connection, because it's very hard to craft an UPDATE packet (or any HIP packet) that gets accepted as a legit update. UPDATE packets use HMAC and are signed 🔏. Even if an attacker snoops packets to grab the SPI and HIT/HI, they still can't forge an UPDATE without knowing the secret keys. And replay attacks on the UPDATE packet are prevented as described in [RFC7401] 🙅♀️✨.
6.2. Denial-of-Service Attacks 🚨
6.2.1. Flooding Attacks 🌊
the whole point of a DoS attack is to drain some resource of the victim so they stop working properly 😩. It can target the victim's network attachment (flooding), their memory, or their processing capacity. In a flooding attack, the attacker sends an excessive number of bogus or unwanted packets to the victim, which fills up their available bandwidth. And the victim doesn't have to be a single node! It can be a whole network, and the attack works exactly the same way 🌐.
An especially effective version is distributed denial of service (DDoS) 💀. Here, the attacker spreads some viral software to as many nodes as possible. Under the attacker's control, the infected nodes (think a botnet) all send packets to the victim together. With that kind of "army", an attacker can take down even super high bandwidth networks and victims 🪖.
Now, with the ability to redirect connections, an attacker could pull off a DDoS without having to spread any viral code at all 🤯. They start a big download from a server, then use the HIP mobility mechanism to redirect that download to the victim. They can repeat this with multiple servers. This threat is mitigated through reachability checks and CBA ✅. When it's done over HIP, reachability checks can lean on HIP's built-in authentication properties, and they can also prevent redirection-based flooding attacks. The catch is that the delay from such a check can have a noticeable impact on application performance 🐢. To soften that delay, CBA can be used to send a limited number of packets to the new address while the validity of that IP address is still in question. 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 CBA brings a HIP redirection-based flood down 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 🧠
okay so we now look at whether the proposed HIP extensions add any new DoS attacks (DoS attacks using the base HIP exchange and updates are discussed in [RFC7401]) 🔍. A simple attack is to send lots of UPDATE packets containing lots of IP addresses that aren't flagged as preferred. The attacker keeps going until the number of IP addresses tied to the attacker's HI crashes the system 💥. So a HIP association SHOULD limit the number of IP addresses that can be associated with any HI 🙌. Other forms of memory- or computation-exhausting attacks via the HIP UPDATE packet are handled in the base HIP document [RFC7401].
A central server that has to deal with a large number of mobile clients MAY consider increasing the SA lifetimes to slow down the rate of rekeying UPDATEs, or increasing the cookie difficulty to slow down the rate of attack-oriented connections 🐌🔐.
6.3. Mixed Deployment Environment 🧩
We now assume an environment with hosts that are both HIP-aware and non-HIP-aware 🤝. 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 is not 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 its 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 solution is to prevent the local redirection of sessions that were previously using an unverified address (but outside of the existing HIP context) into the HIP SAs until the address change can be verified 🔒.
6.4. Privacy Concerns 👁️
Exposing a host's IP addresses through the HIP mobility extensions may raise privacy concerns 🙈. The administrator of a host may be trying to hide its location in some context through the use of a VPN or other virtual interfaces 🕶️. Similar privacy issues also show up in other frameworks, such as WebRTC, and aren't specific to HIP. Implementations SHOULD provide a mechanism that lets the host administrator block the exposure of selected addresses or address ranges 🛡️. While this issue may be more relevant in a host multihoming scenario, where multiple IP addresses might be exposed [RFC8047], it's worth noting here too that mobility events might cause an implementation to inadvertently use a locator that the administrator would rather avoid exposing to the peer host 🫠.
7. IANA Considerations 🗂️
[RFC5206], obsoleted by this document, specified an allocation for a LOCATOR parameter in the Parameter Types subregistry of the Host Identity Protocol (HIP) Parameters registry, with a type value of 193. IANA has renamed the parameter to LOCATOR_SET and has updated the reference from [RFC5206] to this specification ✏️.
[RFC5206], obsoleted by this document, specified an allocation for a LOCATOR_TYPE_UNSUPPORTED type in the Notify Message Types registry, with a type value of 46. IANA has updated the reference from [RFC5206] to this specification 📌.
8. Differences from RFC 5206 🔁
This section summarizes the technical changes made from [RFC5206] 📝. It's informational, meant to help implementors of the previous protocol version 🧑💻. If any text in this section contradicts text in other portions of this specification, the text found outside of this section should be considered normative 🫶.
This document specifies extensions to the HIP Version 2 protocol, while [RFC5206] specifies extensions to the HIP Version 1 protocol. [RFC7401] documents the differences between these two protocol versions 📚.
[RFC5206] included procedures for both HIP host mobility and basic host multihoming. In this document, only host mobility procedures are included, and host multihoming procedures are now specified in [RFC8047] 🌍. In particular, the multihoming-related procedures that were removed are the ones related to the exposure of multiple locators in the base exchange packets, the transmission, reception, and processing of multiple locators in a single UPDATE packet, handovers across IP address families, and other multihoming-related specifications 🧹.
The following additional changes have been made 💅:
- The LOCATOR parameter in [RFC5206] has been renamed to
LOCATOR_SET. - Specification text regarding the handling of mobility when both hosts change IP addresses at nearly the same time (a "double-jump" mobility scenario) has been added 🦘.
- Specification text regarding the mobility event in which the host briefly has an active new locator and old locator at the same time (a "make-before-break" mobility scenario) has been added 🌉.
- Specification text has been added to note that a host may add the source IP address of a received HIP packet as a candidate locator for the peer even if it is not listed in the peer's
LOCATOR_SET, but that it should prefer locators explicitly listed in theLOCATOR_SET🎯. - This document clarifies that the
HOST_IDparameter may be included in UPDATE messages containingLOCATOR_SETparameters, for the possible benefit of HIP-aware firewalls 🔥. - The previous specification mentioned that it may be possible to include multiple
LOCATOR_SETandESP_INFOparameters in an UPDATE. This document only specifies the case of a singleLOCATOR_SETandESP_INFOparameter in an UPDATE 1️⃣. - The previous specification mentioned that it may be possible to send
LOCATOR_SETparameters in packets other than the UPDATE. This document only specifies the use of the UPDATE packet 📦. - This document describes a simple heuristic for setting the credit value for CBA 🧮.
- This specification mandates that a host must be able to receive and avoid reprocessing redundant
LOCATOR_SETparameters that may have been sent in parallel to multiple addresses of the host 🪞.
9. References 📚
9.1. Normative References 📚
Okay bestie, these are the must-read references the spec leans on, so here's the full list exactly as written 💅
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 7402,
DOI 10.17487/RFC7402, April 2015,
<http://www.rfc-editor.org/info/rfc7402>.
[RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", RFC 8003, DOI 10.17487/RFC8003,
October 2016, <http://www.rfc-editor.org/info/rfc8003>.
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
October 2016, <http://www.rfc-editor.org/info/rfc8004>.9.2. Informative References 🦋
These ones are the background reading, the "ooh, tell me more" pile 🧚 Here they are, every single detail intact:
[CBA-MIPv6]
Vogt, C. and J. Arkko, "Credit-Based Authorization for
Mobile IPv6 Early Binding Updates", Work in Progress,
draft-vogt-mobopts-credit-based-authorization-00, February
2005.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, DOI 10.17487/RFC4225,
December 2005, <http://www.rfc-editor.org/info/rfc4225>.
[RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko,
"End-Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, DOI 10.17487/RFC5206, April 2008,
<http://www.rfc-editor.org/info/rfc5206>.
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, DOI 10.17487/RFC5207, April
2008, <http://www.rfc-editor.org/info/rfc5207>.
[RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host
Multihoming with the Host Identity Protocol", RFC 8047,
DOI 10.17487/RFC8047, February 2017,
<http://www.rfc-editor.org/info/rfc8047>.
[SIMPLE-CBA]
Vogt, C. and J. Arkko, "Credit-Based Authorization for
Concurrent Reachability Verification", Work in Progress,
draft-vogt-mobopts-simple-cba-00, February 2006.Acknowledgments 🎀
Huge shoutout to the people who made this doc happen 🫶 Pekka Nikander and Jari Arkko started the whole thing, and Christian Vogt and Thomas Henderson (editor) joined later as coauthors ✨ Greg Perkins wrote the first draft of the security section, which is seriously iconic 💀 And Petri Jokela was a coauthor of the very first individual submission 🌸
CBA first showed up in [SIMPLE-CBA], and a bunch of this document was adopted straight from that earlier one, so credit where it's due 💜
The authors also thank Jeff Ahrenholz, Baris Boyvat, Rene Hummen, Miika Komu, Mika Kousa, Jan Melen, and Samu Varjonen for helping make the document better 👑 Literally the dream team 😭
Authors' Addresses 💌
Here's where to find the authors, contact info exactly as listed 🧚
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.netThat's the whole RFC, bestie! 🌈💖 You made it through!
📦 where this page comes from
- ietf: rfc8046 2017-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms