RFC 4225
Mobile IP Version 6 Route Optimization Security Design Background
Part 1 of 9 🧩
RFC 4225 💖 Mobile IP Version 6 Route Optimization Security Design Background
Okay bestie, this one is from the Network Working Group 🎀 and it was written by P. Nikander, J. Arkko (Ericsson Research NomadicLab), T. Aura (Microsoft Research), G. Montenegro (Microsoft Corporation), and E. Nordmark (Sun Microsystems) 👑. It's dated December 2005 📅, and it's Informational 🧠, which means it gives background and doesn't set a standard. The header doesn't list anything it obsoletes or updates, so it's just vibing on its own ✨.
Status of This Memo ✨
Okay so this memo gives information to the Internet community 💅. It does not specify an Internet standard of any kind 🙈. Distribution is unlimited 🦋.
Copyright Notice 🌸
Copyright (C) The Internet Society (2005) 💜.
Abstract 🧚
This doc explains the reasoning behind the security design for Route Optimization in Mobile IPv6 (MIPv6) 🔥. The whole point is to write down the thinking and keep the reasoning behind the Mobile IPv6 security design from 2001 to 2002 📚, so it doesn't get lost 🫶.
It has two target audiences 🎯. First, it helps MIPv6 implementors understand why the MIPv6 security procedures look the way they do 🛠️. Second, it helps people working on mobility or multi-homing dodge a bunch of security pitfalls in their own designs 🙌.
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Assumptions about the Existing IP Infrastructure ...........4
1.2. The Mobility Problem and the Mobile IPv6 Solution ..........6
1.3. Design Principles and Goals ................................8
1.3.1. End-to-End Principle ..................................8
1.3.2. Trust Assumptions .....................................8
1.3.3. Protection Level ......................................8
1.4. About Mobile IPv6 Mobility and its Variations ..............9
2. Avenues of Attack ...............................................9
2.1. Target ....................................................10
2.2. Timing ....................................................10
2.3. Location ..................................................11
3. Threats and Limitations ........................................11
3.1. Attacks Against Address 'Owners' ("Address Stealing").. ...12
3.1.1. Basic Address Stealing ...............................12
3.1.2. Stealing Addresses of Stationary Nodes ...............13
3.1.3. Future Address Sealing ...............................14
3.1.4. Attacks against Secrecy and Integrity ................15
3.1.5. Basic Denial-of-Service Attacks ......................16
3.1.6. Replaying and Blocking Binding Updates ...............16
3.2. Attacks Against Other Nodes and Networks (Flooding) .......16
3.2.1. Basic Flooding .......................................17
3.2.2. Return-to-Home Flooding ..............................18
3.3. Attacks against Binding Update Protocols ..................18
3.3.1. Inducing Unnecessary Binding Updates .................19
3.3.2. Forcing Non-Optimized Routing ........................20
3.3.3. Reflection and Amplification .........................21
3.4. Classification of Attacks .................................22
3.5. Problems with Infrastructure-Based Authorization ..........23
4. Solution Selected for Mobile IPv6 ..............................24
4.1. Return Routability ........................................24
4.1.1. Home Address Check ...................................26
4.1.2. Care-of-Address Check ................................27
4.1.3. Forming the First Binding Update .....................27
4.2. Creating State Safely .....................................28
4.2.1. Retransmissions and State Machine ....................29
4.3. Quick expiration of the Binding Cache Entries .............29
5. Security Considerations ........................................30
5.1. Residual Threats as Compared to IPv4 ......................31
5.2. Interaction with IPsec ....................................31
5.3. Pretending to Be One's Neighbor ...........................32
5.4. Two Mobile Nodes Talking to Each Other ....................33
6. Conclusions ....................................................33
7. Acknowledgements ...............................................34
8. Informative References .........................................341. Introduction 🌈
Okay so, Mobile IPv4 is built on the idea of doing mobility on top of the IP infrastructure that already exists 🌍. The big win is that it doesn't need changes to the routers, the applications, or the stationary end hosts 💅. Mobile IPv6 [6] is different, though 🦋. In Mobile IPv6, the stationary end hosts can help out with mobility, which is called route optimization 🔥.
Here's how route optimization works 🧠. A correspondent node (CN), which is just a peer that a mobile node is talking to, learns a binding between the mobile node's stationary home address and its current temporary care-of address 🎀. That binding then changes how outgoing packets get handled, and also how incoming packets get processed 📦. And that's where the security risks come from 😭.
This doc is meant to be a fairly compact source for the background assumptions, the design choices, and the other info you need to understand the route optimization security design 📚✨. It's not trying to compare how secure Mobile IPv6 is against other mobility protocols 🙅♀️. It also doesn't list every alternative security mechanism that got thrown around during the Mobile IPv6 design process 🙈. For a summary of those, the reader is pointed to [1] 💜. Some implementation suggestions are included, but only to illustrate things, so this isn't a guide for implementors 🛠️. The actual goal is to explain the design choices and the reasoning behind the current route optimization design 🫶.
The authors were on the design team that produced the design 👑. They hope this note captures some of the lessons and reasoning from that effort 🍓.
The authors' intent is to document the thinking behind that design effort exactly as it was 🧚. Even though this note might bring in newer developments to illustrate the issues, it is not a new design 🙅♀️. What it does do is clarify differing opinions, questionable assumptions, and newly discovered vulnerabilities, if that new info is available today 🔍. This matters a lot, because it could help the working group's hindsight as it revises or improves the Mobile IPv6 specification 💅.
To really get the security implications of the design constraints, we need to briefly look at three things: the nature of the existing IP infrastructure, the problems Mobile IP is trying to solve, and the design principles that got applied 🧩. With that background, we can dig into IP-based mobility more closely and take a quick look at the security problems 🔎. The background starts in the rest of this section, beginning at Section 1.1 🦋.
Section 1.1 might look redundant if you already know Mobile IPv6, but it's honestly worth reading anyway 💖. This doc's approach is really different from the Mobile IPv6 specification's 🎀. The specification states the result of the design, while this doc explicitly exposes the implicit assumptions and design choices underneath it 🌸. Knowing the background makes it way easier to see where some of the related security problems come from, and to understand the limits built into the solutions 🙈✨.
Specifically, this doc explains how the "Return Routability" (RR) design protects against the threats identified in Section 3 💅. That protection holds except for attacks on the RR protocol itself 😭. Those need other countermeasures, based on heuristics and careful implementation (Section 3.3) 🧠.
The rest of the doc is organized like this 🗺️. After this intro, Section 2 covers the avenues of attack 🚪. Section 3 studies the security problems and countermeasures in detail 🔬. Section 4 explains how the current security design works overall and why it's built that way 🛠️. Section 5 analyzes the design and talks about the threats that remain 👀. Finally, Section 6 wraps everything up 👑.
1.1. Assumptions about the Existing IP Infrastructure
okay so one of the big goals in the Mobile IP design was making mobility happen without changing too much 🧚 this mattered SO much for IPv4 because it has a massive installed base, and Mobile IPv6 inherited the same vibe 💖 some alternative proposals take a totally different route and make much bigger changes to the Internet architecture (see Section 1.4) 👀
to get Mobile IPv6, you first need the MIPv6 view of the base IPv6 protocol and infrastructure 💅 the most important base assumptions look like this:
- The routing prefixes available to a node are determined by its current location, and therefore the node must change its IP address as it moves.
- The routing infrastructure is assumed to be secure and well functioning, delivering packets to their intended destinations as identified by destination address.
okay but these might sound trivial, so let's dig in a little more 🔍 first, in current IPv6 operational practice, the IP address prefixes get distributed in a hierarchical manner 🌸 this limits how many routing table entries each router has to handle. the big implication is that the topology decides which globally routable IP addresses are available at a given location. so nodes can't freely pick whatever globally routable IP address they want 🙅♀️ they have to rely on the routing prefixes served by their local routers, either via Router Advertisements or from a DHCP server. basically, IP addresses are just what the name says: addresses (i.e., locators) 🦋
second, in the current Internet structure, the routers together maintain a distributed database of the network topology, and they forward each packet toward the location determined by the destination address carried in that packet 🌈 to keep the topology info accurate, the routers have to trust each other, at least to a certain extent. routers learn topology info from other routers, and they have no option but to trust their neighbor routers about distant topology 😭 at the borders of administrative domains, policy rules are used to limit how much possibly faulty routing table info is accepted from peer domains. this is mostly used to weed out administrative mistakes, but it also helps with security ✨ the goal is to keep a reasonably accurate idea of the network topology even if someone is feeding faulty info into the routing system 🛡️
now, in the current Mobile IPv6 design, it's explicitly assumed that the routers and the policy rules are configured in a reasonable way, and that the resulting routing infrastructure is trustworthy enough 🫶 that means it's assumed the routing system keeps accurate topology info, so it can route packets to their destination locations. if this assumption breaks, the Internet itself is broken in the sense that packets go to the wrong locations 💀 a fundamental malfunction like that would make any other effort to assure correct packet delivery hopeless (e.g., any efforts due to Mobile IP security considerations). so yeah, it's a big deal 😤
1.1.1. A Note on Source Addresses and Ingress Filtering
some of the threats and attacks discussed in this document take advantage of how easy it is to spoof a source address 🙈 in the current Internet, it's possible to send packets with a false source IP address. the eventual introduction of ingress filtering is assumed to prevent this. when ingress filtering is used, traffic with spoofed addresses is not forwarded 🚫 this filtering can happen at different network borders, like between an Internet service provider (ISP) and its customers, between downstream and upstream ISPs, or between peer ISPs [5]. obviously, the granularity of ingress filters decides how much you can "spoof inside a prefix" 👀 for example, if an ISP ingress filters a customer's link but the customer does nothing, anything inside the customer's /48 prefix could be spoofed 😬 if the customer filters at LAN subnets, anything inside the /64 prefixes could be spoofed. even with the limits of this "in-prefix spoofing," ingress filtering generally makes traffic traceable to its real source network [5] 🔎
however, ingress filtering only helps if and only if a large part of the Internet uses it 😩 unfortunately, there are still some issues (e.g., in the presence of site multi-homing) that, while not insurmountable, do need careful handling, and they're likely to limit or delay its usefulness [5] 🥲
1.2. The Mobility Problem and the Mobile IPv6 Solution
the Mobile IP design is trying to solve two problems at once 💜 first, it lets transport layer sessions (TCP connections, UDP-based transactions) keep going even when the underlying host(s) move and change their IP addresses. second, it lets a node be reached through a static IP address, a home address (HoA) 🏠
you can also say that same design choice another way: Mobile IPv6 is trying to preserve the identifier nature of IP addresses 🎀 Mobile IPv6 takes the view that IP addresses can be used as natural identifiers of nodes, just like they've been used since the very beginning of the Internet. this is different from proposed and existing alternative designs where the identifier and locator natures of IP addresses have been separated (see Section 1.4) ✨
the basic idea in Mobile IP is to let a home agent (HA) act as a stationary proxy for a mobile node (MN) 🧚♀️ whenever the mobile node is away from its home network, the home agent intercepts packets destined for the node and forwards them by tunneling them to the node's current address, the care-of address (CoA). the transport layer (e.g., TCP, UDP) uses the home address as a stationary identifier for the mobile node. Figure 1 shows this basic setup 👇
+----+ +----+
| MN |=#=#=#=#=#=#=#=#=tunnel=#=#=#=#=#=#=#=#|#HA |
+----+ ____________ +-#--+
| CoA ___/ \_____ # Home Link
-+-------/ Internet * * *-*-*-*-#-#-#-#-----
| * * | * Home Address
\___ * * _____/ + * -+
\_____*______/ | MN |
* + - -+
+----+
| CN | Data path as * * * *
+----+ it appears to correspondent node
Real data path # # # #
Figure 1. Basic Mode of Operation in Mobile IPv6the basic solution needs tunneling through the home agent, and that leads to longer paths and worse performance 😵 this tunneling is sometimes called triangular routing, because it was originally planned that packets from the mobile node to its peer could still go directly, bypassing the home agent 🔺
to ease that performance hit, Mobile IPv6 has a mode of operation that lets the mobile node and its peer, a correspondent node (CN), exchange packets directly 🚀 they bypass the home agent completely after the initial setup phase. this mode is called route optimization (RO). when route optimization is used, the mobile node sends its current care-of address to the correspondent node using binding update (BU) messages 📨 the correspondent node stores the binding between the home address and care-of address in its Binding Cache 🗂️
whenever MIPv6 route optimization is used, the correspondent node is effectively playing two roles 👑 firstly, it's the source of the packets it sends, as usual. secondly, it acts as the first router for those packets, effectively doing source routing. so when the correspondent node sends packets out, it checks its MIPv6 route optimization data structures and reroutes the packets if necessary 🛣️ a Binding Cache Entry (BCE) holds the home address and the care-of address of the mobile node, and records the fact that packets destined to the home address should now be sent to the destination address. so it's a local routing exception 🌟
the packets leaving the correspondent node are source routed to the care-of address 🎯 each packet includes a routing header that contains the home address of the mobile node. logically, the packet is first routed to the care-of address and then, virtually, from the care-of address to the home address. in practice, of course, the mobile node consumes the packet at the care-of address; the header just lets the mobile node pick a socket associated with the home address instead of one with the care-of address 🧩 still, the mechanism resembles source routing, since there's routing state at the correspondent node and a routing header is in use 🤓
but this routing header is special (type 2) to avoid the risks that come with the more general (type 0) variant 🛡️ no thanks to type 0, bestie 🙅♀️
1.3. Design Principles and Goals
the MIPv6 design and security design both aimed to follow the end-to-end principle 🌷 they also aimed to notice the differences in trust relationships between nodes, and to be explicit about delivering a practical (instead of an over-ambitious) level of protection 💅
1.3.1. End-to-End Principle
the leading design principle for Internet protocols is the so-called end-to-end principle [4][11] 🧠 according to this principle, it's beneficial to avoid polluting the network with state, and to limit new state creation to the involved end nodes 🌿
in Mobile IPv6, the end-to-end principle is applied by restricting mobility-related state mainly to the home agent 🏡 additionally, if route optimization is used, the correspondent nodes also maintain soft state about the mobile nodes' current care-of addresses, the Binding Cache 🗃️ this is different from an approach that would use individual host routes within the basic routing system. that approach would create state on a huge number of routers around the network 😱 in Mobile IPv6, only the home agent and the communicating nodes need to create state 💖
1.3.2. Trust Assumptions
the Mobile IPv6 security design chose different approaches for securing communication between the mobile node and its home agent, and between the mobile node and its correspondent nodes 🔐 in the home agent case, it was assumed that the mobile node and the home agent know each other through a prior arrangement, e.g., because of a business relationship 🤝 in contrast, it was strictly assumed that the mobile node and the correspondent node don't need any prior arrangement 🙌 that lets Mobile IPv6 work in a scalable manner, without requiring any configuration at the correspondent nodes ✨
1.3.3. Protection Level 🛡️
okay so the security goal for Mobile IPv6 was to be "as secure as the (non-mobile) IPv4 Internet" 🔐, and that's how things looked when it was designed, back in the 2001 - 2002 era. 💅 That means there's honestly not a ton of protection against attackers who can wedge themselves between a correspondent node and a home agent 😬. The logic is pretty simple: in 2001, if a node could slide into the path between any two random nodes, it could disrupt, modify, and eavesdrop on all the traffic between them, unless IPsec was in use 🫣. And even with IPsec, the attacker could still block communication selectively just by dropping packets 🙅♀️. The attacker sitting on a router between the two nodes could also pull off a flooding attack by redirecting the data flows (or, more practically, a matching flow of bogus data) to some third party 🌊.
1.4. About Mobile IPv6 Mobility and its Variations 🦋
Taking a more abstract view, IPv6 mobility is basically a mechanism for managing local exceptions to routing information, so that packets sent to one address (the home address) get directed to another address (the care-of address) 🗺️. It's "managing" in the sense that these local routing exceptions (source routes) get created and deleted dynamically, based on instructions from the mobile node 🔄. It's "local" because the routing exceptions are only valid at the home agent, and at the correspondent nodes too if route optimization is being used 📍. The state that gets created counts as "exceptions" because it overrides the normal topological routing information that the routers carry collectively 👑.
Using the terminology introduced by J. Noel Chiappa [14], the home address is doing double duty: it's an end-point identifier (EID) and a permanent locator 🤯. The care-of address is a pure, temporary locator that says where the mobile node is right now 📦. The correspondent nodes are basically doing source routing, redirecting traffic meant for the home address to the care-of address 🎯. You can even see it in the packet structure, since the packets carry an explicit routing header 💜.
The relationship between EIDs and permanent locators has been exploited by other proposals 💡. Their technical merits and security problems, though, are beyond the scope of this document, so we're leaving that tea for another day 🫖.
2. Avenues of Attack 🗡️
From everything above, it should be clear that the dangers Mobile IPv6 has to protect against come from creating (or deleting) those local routing exceptions 🚨. In Mobile IPv6 terms, the danger is an unauthorized creation of Binding Cache Entries (BCE) 🙅. How bad an attack is depends on its target, its timing, and where the attacker is sitting 🎭.
2.1. Target 🎯
Basically, the target of an attack can be any node or network on the Internet, stationary or mobile 🌐. The big difference is what the attacker wants. Do they want to divert (steal) traffic going to and/or coming from the target node, or cause denial-of-service to the target node or network 😈? The target usually isn't doing much in the attack, ngl. For example, an attacker could DoS node A by contacting a bunch of other nodes while pretending to be A, then diverting the traffic at those nodes so A can't receive packets from them anymore 💀. A doesn't have to do anything at all for its comms to start breaking 😭. And A doesn't even have to be mobile; it could be totally stationary 🧱.
Mobile IPv6 uses the same class of IP addresses for mobile nodes (home and care-of addresses) and for stationary nodes 🙈. So mobile and stationary addresses look identical to each other 👯. Attackers can grab any IP address and use it somewhere that normally only mobile (home or care-of) addresses would show up 🕵️♀️. That means attacks that would otherwise only affect mobile nodes are actually a threat to all IPv6 nodes 😱.
Here's a fun twist: a mobile node is actually the best protected, since it doesn't need to keep state about where some remote nodes are 🛡️. The correspondent node role is the weakest, though, since there are very few assumptions it can base its state on 😬. So it's way easier for an attacker to convince a correspondent node that a presumably mobile node is somewhere it isn't, than to fool the mobile node itself 🎣. BUT since you can attack a node indirectly by going after its peers first, all nodes are equally vulnerable in some sense 🔁. And a (usually) mobile node often plays the correspondent role too, since it can exchange packets with other mobile nodes (see also Section 5.4) 🤝.
2.2. Timing ⏰
Timing is a huge deal when it comes to Mobile IPv6 dangers ⌛. In a stationary IPv4 network, the attacker has to be between the communicating nodes at the same time they're talking 🕰️. Mobile IPv6's ability to create binding cache entries changes the game and creates a new danger 🎲. Without proper protection, an attacker could insert itself between the home agent and a correspondent node for a while, create a BCE at the correspondent node, leave, and keep updating the correspondent node about the mobile node's whereabouts 🏃♀️. The correspondent node would keep sending packets for the mobile node to an incorrect address for as long as the BCE stayed valid, which is typically until the correspondent node is rebooted 🔌. The reverse also works: an attacker could create a BCE and then let it expire at a carefully chosen moment ⏳. If a bunch of active BCEs carrying lots of traffic all expired at once, the home agent or home network could get overloaded 📉. (See Section 3.2.2 for a more detailed explanation 📖.)
2.3. Location 📍
In a static IPv4 Internet, an attacker can only receive packets for a given address if it can attach itself to, or control, a node on the topological path between sender and recipient 🛤️. Spoofing packets, on the other hand? Easy, from almost anywhere 🎭. If Mobile IPv6 allowed unprotected Binding Updates, an attacker could create a BCE on any correspondent node from anywhere on the Internet, just by sending a fraudulent Binding Update to it 📨. The attacker wouldn't need to be between the two target nodes. They could act from anywhere 🌍.
To sum up: by adding the new routing exception (binding cache) at correspondent nodes, Mobile IPv6 brings the dangers of time and space shifting 🌀. Without proper protection, Mobile IPv6 would let an attacker act from anywhere on the Internet and well before the actual attack 🕒. In contrast, in the static IPv4 Internet, the attacking nodes have to be present at attack time and positioned properly, or the attack wouldn't be possible at all 🙌.
3. Threats and Limitations ⚠️
This section covers attacks against Mobile IPv6 Route Optimization and the protection mechanisms Mobile IPv6 uses against them 🔍. The attacker's goal can be to corrupt the correspondent node's binding cache and make packets go to the wrong address 🗑️. This can compromise the secrecy and integrity of communication, and cause denial-of-service (DoS) both to the communicating parties and to the address receiving the unwanted packets 💔. The attacker might also abuse features of the Binding Update (BU) mechanism to exhaust resources on the mobile node, the home agent, or the correspondent nodes 🪫. The point of this section is to give an overview of the various protocol mechanisms and their limitations, and the details are in Section 4 📚.
It's essential to get that some threats are more serious than others, some can be mitigated but not removed, some threats might be an acceptable risk, and some might be too expensive for the attacker to bother with 💸.
We only consider active attackers 🙋♀️. Why? To corrupt the binding cache, the attacker has to send one or more messages sooner or later, so it makes little sense to consider attackers who only observe and never send 👀. Also, some active attacks are actually easier for the average attacker than passive ones. In many active attacks, the attacker can start binding update processing at any time, while most passive attacks mean waiting for suitable messages from the target nodes ⏳.
Still, one important class of passive attacks remains: attacks on privacy 🔒. It's well known that just by examining packets, eavesdroppers can track the movements of individual nodes (and potentially, users) [3] 👣. Mobile IPv6 makes this worse by putting more potentially sensitive info into packets (e.g., Binding Updates, routing headers or home address options) 📬. This document doesn't address these attacks 🙃.
We'll first look at attacks against nodes that are supposed to have a specified address (Section 3.1), then flooding attacks (Section 3.2) and attacks against the basic Binding Update protocol (Section 3.3) 🧩. After that we classify the attacks (Section 3.4) 🗂️. Finally, we look at whether solutions relying on some kind of global security infrastructure are applicable (Section 3.5) 🌐.
3.1. Attacks Against Address 'Owners' ("Address Stealing") 🏴☠️
The most obvious danger in Mobile IPv6 is address "stealing": an attacker illegitimately claims to be a given node at a given address and tries to "steal" traffic destined for that address 💰. We'll start with the basic version, then look at how things change if the target is a stationary node, and then move on to trickier stuff related to timing (so-called "future" attacks), confidentiality and integrity, and DoS aspects 🧠✨.
3.1.1. Basic Address Stealing 🎀
okay so if Binding Updates weren't authenticated at all 💀, an attacker could fabricate and send spoofed binding updates from literally anywhere on the Internet. Every node that supports the correspondent node functionality would become an unwitting accomplice 🙈. As we covered in Section 2.1, there's no way to tell which addresses belong to mobile nodes that could really send binding updates and which belong to stationary nodes (see below), so potentially any node, even the "static" ones, is vulnerable 😭.
+---+ original +---+ new packet +---+
| B |<----------------| A |- - - - - - ->| C |
+---+ packet flow +---+ flow +---+
^
|
| False BU: B -> C
|
+----------+
| Attacker |
+----------+
Figure 2. Basic Address StealingPicture an IP node, A, sending IP packets to another IP node, B. The attacker could redirect those packets to an arbitrary address, C, by sending a Binding Update to A. The home address (HoA) in that binding update would be B and the care-of address (CoA) would be C. After A receives this binding update, it would send all packets intended for the node B to the address C. See Figure 2 🦋.
The attacker might select the care-of address to be its own current address, another address in its local network, or any other IP address at all. If it picked a local care-of address so it could receive the packets, it would also be able to send replies to the correspondent node 💅. Ingress filtering at the attacker's local network doesn't prevent the spoofing of Binding Updates, but it does force the attacker to either choose a care-of address from inside its own network or use the Alternate care-of address sub-option ✨.
The binding update authorization mechanism used in the MIPv6 security design is primarily meant to mitigate this threat, and to limit the location of attackers to the path between a correspondent node and the home agent 🌸.
3.1.2. Stealing Addresses of Stationary Nodes 👑
The attacker needs to know or guess the IP addresses of both the source of the packets to be diverted (A in the example above) and the destination of the packets (B, above). So it's hard to redirect all packets to or from a specific node, because the attacker would need to know the IP addresses of every node that node is talking to 🧚.
Nodes with well-known addresses, like servers and nodes using stateful configuration, are the most vulnerable. Nodes that are part of the network infrastructure, like DNS servers, are particularly interesting targets for attackers and particularly easy to identify 👀.
Nodes that frequently change their address and use random addresses are relatively safe 🌈. However, if they register their address into Dynamic DNS, they become more exposed. Similarly, nodes that visit publicly accessible networks, such as airport wireless LANs, risk revealing their addresses ✈️. IPv6 addressing privacy features [3] mitigate these risks to an extent, but note that addresses cannot be completely recycled while there are still open sessions that use those addresses 🔐.
So it is not the mobile nodes that are most vulnerable to address stealing attacks; it is the well-known static servers 🫶. Furthermore, the servers often run old or heavily optimized operating systems and may not have any mobility related code at all 💀. Thus, the security design cannot be based on the idea that mobile nodes might somehow be able to detect whether someone has stolen their address, and reset the state at the correspondent node. Instead, the security design must make reasonable measures to prevent the creation of fraudulent binding cache entries in the first place 🔥.
3.1.3. Future Address Sealing 🔮
If an attacker knows an address that a node is likely to select in the future, it can launch a "future" address stealing attack. The attacker creates a Binding Cache Entry with the home address that it anticipates the target node will use. If the Home Agent allows dynamic home addresses, the attacker may be able to do this legitimately. That is, if the attacker is a client of the Home Agent and is able to acquire the home address temporarily, it may be able to do so and then return the home address to the Home Agent once the BCE is in place 🥹.
Now, if the BCE state had a long expiration time, the target node would acquire the same home address while the BCE is still effective, and the attacker would be able to launch a successful man-in-the-middle or denial-of-service attack 😱. The mechanism applied in the MIPv6 security design is to limit the lifetime of Binding Cache Entries to a few minutes ⏰.
Note that this attack applies only to fairly specific conditions. There are also some variations of this attack that are theoretically possible under some other conditions. However, all of these attacks are limited by the Binding Cache Entry lifetime, and therefore they are not a real concern with the current design 💖.
3.1.4. Attacks against Secrecy and Integrity 🔐
By spoofing Binding Updates, an attacker could redirect all packets between two IP nodes to itself. By sending a spoofed binding update to A, it could capture the data intended to B. That is, it could pretend to be B and hijack A's connections with B, or it could establish new spoofed connections. The attacker could also send spoofed binding updates to both A and B and insert itself in the middle of all connections between them (man-in-the-middle attack). Consequently, the attacker would be able to see and modify the packets sent between A and B. See Figure 3.
Original data path, before man-in-the-middle attack
+---+ +---+
| A | | B |
+---+ +---+
\___________________________________/
Modified data path, after the falsified binding updates
+---+ +---+
| A | | B |
+---+ +---+
\ /
\ /
\ +----------+ /
\---------| Attacker |-------/
+----------+
Figure 3. Man-in-the-Middle AttackStrong end-to-end encryption and integrity protection, such as authenticated IPsec, can prevent all the attacks against data secrecy and integrity. When the data is cryptographically protected, spoofed binding updates could result in denial of service (see below) but not in disclosure or corruption of sensitive data beyond revealing the existence of the traffic flows. Two fixed nodes could also protect communication between themselves by refusing to accept binding updates from each other. Ingress filtering, on the other hand, does not help, as the attacker is using its own address as the care-of address and is not spoofing source IP addresses 🙃.
The protection adopted in MIPv6 Security Design is to authenticate (albeit weakly) the addresses by return routability (RR), which limits the topological locations from which the attack is possible (see Section 4.1) 🧭.
3.1.5. Basic Denial-of-Service Attacks 🚫
By sending spoofed binding updates, the attacker could redirect all packets sent between two IP nodes to a random or nonexistent address (or addresses). As a result, it might be able to stop or disrupt communication between the nodes. This attack is serious because any Internet node could be targeted, including fixed nodes belonging to the infrastructure (e.g., DNS servers) that are also vulnerable 😤. Again, the selected protection mechanism is return routability (RR).
3.1.6. Replaying and Blocking Binding Updates 🔁
Any protocol for authenticating binding updates has to consider replay attacks. That is, an attacker may be able to replay recently authenticated binding updates to the correspondent and, consequently, direct packets to the mobile node's previous location. As with spoofed binding updates, this could be used both for capturing packets and for DoS. The attacker could capture the packets and impersonate the mobile node if it reserved the mobile's previous address after the mobile node has moved away and then replayed the previous binding update to redirect packets back to the previous location.
In a related attack, the attacker blocks binding updates from the mobile at its new location, e.g., by jamming the radio link or by mounting a flooding attack. The attacker then takes over the mobile's connections at the old location. The attacker will be able to capture the packets sent to the mobile and to impersonate the mobile until the correspondent's Binding Cache entry expires.
Both of the above attacks require that the attacker be on the same local network with the mobile, where it can relatively easily observe packets and block them even if the mobile does not move to a new location. Therefore, we believe that these attacks are not as serious as ones that can be mounted from remote locations. The limited lifetime of the Binding Cache entry and the associated nonces limit the time frame within which the replay attacks are possible. Replay protection is provided by the sequence number and MAC in the Binding Update. To not undermine this protection, correspondent nodes must exercise care upon deleting a binding cache entry, as per section 5.2.8 ("Preventing Replay Attacks") in [6].
3.2. Attacks Against Other Nodes and Networks (Flooding) 🌊
By sending spoofed binding updates, an attacker could redirect traffic to an arbitrary IP address. This could be used to overload an arbitrary Internet address with an excessive volume of packets (known as a 'bombing attack'). The attacker could also target a network by redirecting data to one or more IP addresses within the network. There are two main variations of flooding: basic flooding and return-to-home flooding. We consider them separately 💜.
3.2.1. Basic Flooding ✨
okay so the simplest attack is giving villain energy 😈. The attacker knows there's a heavy data stream going from node A to B, and they redirect it to the target address C. The catch is that A would soon stop sending, because it's not getting acknowledgements back from B 💀.
(B is attacker)
+---+ original +---+ flooding packet +---+
| B |<================| A |==================>| C |
+---+ packet flow +---+ flow +---+
| ^
\ /
\__________________/
False binding update + false acknowledgements
Figure 4. Basic Flooding AttackA more sophisticated attacker just becomes B themselves, see Figure 4 🦋. They first subscribe to a data stream (like a video stream) and then redirect that stream to the target address C. They can even spoof the acknowledgements, which is so unbothered of them 🙈. Let's take a TCP stream as an example. The attacker does the TCP handshake themselves, so they already know the initial sequence numbers. After redirecting the data to C, they just keep sending spoofed acknowledgements. They can even speed up the data rate by pretending to be a fatter pipe [12] 🔥.
This attack might be even easier with UDP/RTP 🌸. The attacker could create spoofed RTCP acknowledgements. Either way, they can redirect a growing stream of unwanted data at the target address without doing much work at all 😤. They can keep opening more streams and refresh the Binding Cache entries by sending a new binding update every few minutes. So limiting BCE lifetime to a few minutes doesn't help here, not without extra measures 🙃.
Here's the tea 🍵. While MIPv6 was being designed, people argued about how bad this attack actually was. The assumption was that the target node would send a TCP Reset to the source of the unwanted stream, and then the stream would stop. In reality, all practical TCP/IP implementations fail to send that Reset 😭. The target node drops the unwanted packets at the IP layer, because it doesn't have a Binding Update List entry matching the Routing Header on the incoming packet. So the flooding data never gets processed at the target's TCP layer, and no Reset goes out. That means the TCP version of this attack is way more effective than people first believed 💀🔥.
This attack is seriously dangerous because the target can be any node or network, not just a mobile one 🫶. What makes it worse than the other attacks is that the target can't do anything to stop it on its own. For example, it doesn't help if the target network stops using Route Optimization 🙅♀️. The damage gets even worse if these techniques are used to boost other distributed denial-of-service (DDoS) attacks 👑. Ingress filtering in the attacker's local network stops them from spoofing source addresses, but the attack still works by setting the Alternate care-of address sub-option to the target address. Not a good look for the filter 🥀.
Again, the protection mechanism picked for MIPv6 is return routability 🛡️💖. This time it's necessary to check that there really is a node at the new care-of address, and that this node is the one that asked for packets to be redirected to that exact address (see Section 4.1.2) ✨.
3.2.2. Return-to-Home Flooding 🏠
A twist on the bombing attack targets the home address or home network, instead of the care-of address or visited network 🧚. The attacker claims to be a mobile node whose home address equals the target address. While pretending to be away from home, they start downloading a data stream. Then they either send a binding update cancellation (basically a request to delete the binding from the Binding Cache), or they just let the cache entry expire 🙈. Either way, the data stream gets redirected to the home network. Same as when bombing a care-of address, the attacker can keep the stream alive and even crank up the data rate by spoofing acknowledgements 💅. When it works, bombing the home network is just as serious as bombing a care-of address 😭.
The basic protection mechanism is return routability again 🎀. The catch is that it's really hard to fully protect against this one, so see Section 4.1.1 🙃.
3.3. Attacks against Binding Update Protocols 🔐
Okay, this is the ironic part 🙃. Security protocols that do a great job of protecting the secrecy and integrity of data can sometimes make the participants easier to hit with denial-of-service attacks 😬. In fact, the stronger the authentication is, the easier it may be for an attacker to use the protocol's own features to drain the mobile's or the correspondent's resources 🥺.
3.3.1. Inducing Unnecessary Binding Updates
When a mobile node gets an IP packet from a new correspondent through the home agent, it may start the binding update protocol 📦. An attacker can abuse this by sending the mobile node a spoofed IP packet (like a ping or a TCP SYN packet) that looks like it came from a new correspondent node 👀. Since the packet arrives via the home agent, the mobile node might start the binding update protocol with that correspondent node. Whether to start the binding update procedure can depend on several factors (heuristics, cross layer information, and configuration options), and Mobile IPv6 doesn't specify it 🤷♀️. Not starting the binding update procedure automatically might ease these attacks, but it won't, in general, stop them completely 💔.
In a real attack, the attacker would get the mobile node to start binding update protocols with a huge number of correspondent nodes all at once 😱. If the correspondent addresses are real addresses of existing IP nodes, most of those binding update protocol runs might even finish successfully. The Binding Cache entries created are correct, but totally useless 🫠. This way the attacker tricks the mobile into running the binding update protocol for no reason, which can drain the mobile's resources 🪫.
Any IP node can be attacked in a similar way too 🌈. The attacker sends spoofed IP packets to a large number of mobiles, using the target node's address as the source address. Those mobiles will then start the binding update protocol with the target node. Again, most of these protocol runs will complete successfully. By causing a flood of unnecessary binding updates, the attacker can eat up the target node's resources 🍽️.
This attack works against any binding update authentication protocol 🔓. The more resources the binding update protocol uses, the more serious the attack gets. So, strong cryptographic authentication protocols are more vulnerable to the attack than weak ones or unauthenticated binding updates 🤯. Ingress filtering helps a little, since it makes it harder to forge the source address of the spoofed packets, but it doesn't completely get rid of this threat 🙃.
A node should protect itself by setting a limit on how many resources (processing time, memory, and communications bandwidth) it uses to process binding updates 🛑. When that limit is exceeded, the node can simply stop trying route optimization. Sometimes it's still possible to process some binding updates even while a node is under attack 🫶. A mobile node may have a local security policy that lists a limited number of addresses it will still send binding updates to, even while under a DoS attack. A correspondent node (any IP node) may similarly have a local security policy listing a limited set of addresses it will accept binding updates from, even while it's under a binding update DoS attack 🛡️.
The node can also recognize addresses it had meaningful communication with in the past, and only send binding updates to those addresses, or accept them from them 💜. Since the IP layer may not be able to know about protocol state in higher layers, a good measure of how meaningful past communication was is probably per-address packet counts 🔢. Alternatively, Neighbor Discovery [2] (Section 5.1, Conceptual Data Structures) defines the Destination Cache as a set of entries about destinations that traffic has recently been sent to 📒. So implementors may want to use the information in the Destination Cache ✨.
Section 11.7.2 ("Correspondent Registration") in [6] doesn't specify when a route optimization procedure should be started 🤔. It does hint at when it might be justifiable to do so, but those hints aren't enough. This is still an area where more work is needed 🛠️. Obviously, since route optimization is optional, any node that finds the processing load excessive or unjustified can just turn it off, either selectively or completely 🔌.
3.3.2. Forcing Non-Optimized Routing 🐢
As a variant of the previous attack, the attacker can stop a correspondent node from using route optimization by filling its Binding Cache with unnecessary entries, so that most entries for real mobiles get dropped 🗑️.
Any successful DoS attack against a mobile or correspondent node can also stop it from processing binding updates 😩. We've already suggested that the target of a DoS attack might respond by stopping route optimization for all or some communication. Obviously, an attacker can exploit this fallback mechanism and force the target to use the less efficient home agent-based routing 🥴. The attacker only needs to mount a noticeable DoS attack against the mobile or correspondent, and the target will default to non-optimized routing 🫠.
The target node can soften the effects of this attack by reserving more space for the Binding Cache 📈. It can also revert to non-optimized routing only when it truly can't cope with the DoS attack, try aggressively to get back to optimized routing, or favor mobiles it already has an established relationship with 💖. This attack isn't as serious as the ones described earlier, but applications that rely on Route Optimization can still be affected 📞. For instance, conversational multimedia sessions can suffer badly from the extra delays caused by triangle routing 🎥😭.
3.3.3. Reflection and Amplification 🔁✨
Okay bestie, so attackers sometimes try to hide where a packet flood is coming from by bouncing the traffic off other nodes [1] 🦋. Instead of blasting packets straight at the target, the attacker sends data to other nodes and tricks them into sending the same number of packets, or even more, to the target. This kind of reflection can hide the attacker's address even when ingress filtering stops source address spoofing 🙈. It's extra dangerous if packets can get reflected multiple times, if they can be sent around a looping path, or if the nodes can be tricked into sending way more packets than they got from the attacker, because any of those can amplify the traffic by a big factor 💀. When designing protocols, one should avoid creating services that can be used for reflection and amplification 🫶.
Triangle routing would easily create chances for reflection 🔺: a correspondent node gets packets (e.g., TCP SYN) from the mobile node and replies to the home address the mobile gave in the Home Address Option (HAO). The mobile might not really be a mobile, and the home address could actually be the target address 😱. The target would only see the packets sent by the correspondent and couldn't see the attacker's address (even if ingress filtering stops the attacker from spoofing its source address).
+----------+ TCP SYN with HAO +-----------+
| Attacker |-------------------->| Reflector |
+----------+ +-----------+
|
| TCP SYN-ACK to HoA
V
+-----------+
| Flooding |
| target |
+-----------+
Figure 5. Reflection AttackA badly designed binding update protocol could also be used for reflection 🪞: the correspondent would respond to a data packet by initiating the binding update authentication protocol, which usually involves sending a packet to the home address. In that case, the reflection attack can be discouraged by copying the mobile's address into the messages sent by the mobile to the correspondent. (The mobile's source address is usually the same as the care-of address, but an Alternative Care-of Address sub-option can specify a different care-of address.) Some of the early proposals for MIPv6 security used this approach and were prone to reflection attacks.
In some of the proposals for binding update authentication protocols, the correspondent node responded to an initial message from the mobile with two packets (one to the home address, one to the care-of address). It would have been possible to use this to amplify a flooding attack by a factor of two. Furthermore, with public-key authentication, the packets sent by the correspondent might have been significantly larger than the one that triggers them 📦.
These types of reflection and amplification can be avoided by ensuring that the correspondent only responds to the same address from which it received a packet, and only with a single packet of the same size. These principles have been applied to MIPv6 security design 💜.
3.4. Classification of Attacks 🗂️
Sect. Attack name Target Sev. Mitigation
---------------------------------------------------------------------
3.1.1 Basic address stealing MN Med. RR
3.1.2 Stealing addresses of stationary nodes Any High RR
3.1.3 Future address stealing MN Low RR, lifetime
3.1.4 Attacks against secrecy and integrity MN Low RR, IPsec
3.1.5 Basic denial-of-service attacks Any Med. RR
3.1.6 Replaying and blocking binding updates MN Low lifetime,
seq number,
MAC
3.2.1 Basic flooding Any High RR
3.2.2 Return-to-home flooding Any High RR
3.3.1 Inducing unnecessary binding updates MN, CN Med. heuristics
3.3.2 Forcing non-optimized routing MN Low heuristics
3.3.3 Reflection and amplification N/A Med. BU design
Figure 6. Summary of Discussed AttacksFigure 6 gives a summary of the attacks we've discussed 📋. As things stand at the time of writing, the return-to-the-home flooding and the induction of unnecessary binding updates look like the threats we have the least protection against, compared to how severe they are 😬.
3.5. Problems with Infrastructure-Based Authorization 🔐
Early in the MIPv6 design process, it was assumed that plain IPsec could be the default way to secure Binding Updates with arbitrary correspondent nodes. However, this turned out to be impossible 💔. Plain IPsec relies on an infrastructure for key management, which, to be usable with any arbitrary pair of nodes, would need to be global in scope. Such a "global PKI" does not exist, nor is it expected to come into existence any time soon.
There were also some more minor issues that surfaced at the time: (1) insufficient filtering granularity for the state of IPsec at the time, (2) cost to establish a security association (in terms of CPU and round trip times), and (3) expressing the proper authorization (as opposed to just authentication) for binding updates [13]. These issues are solvable, and, in particular, (1) and (3) have been addressed for IPsec usage with binding updates between the mobile node and the home agent [7] ✅.
However, the lack of a global PKI remains unsolved 😤.
One way to provide a global key infrastructure for mobile IP could be DNSSEC 🌐. Such a scheme is not completely supported by the existing specifications, as it constitutes a new application of the KEY RR, something explicitly limited to DNSSEC [8] [9] [10]. Nevertheless, if one were to define it, one could proceed along the following lines: a secure reverse DNS that provided a public key for each IP address could be used to verify that a binding update is indeed signed by an authorized party. However, in order to be secure, each link in such a system must be secure. That is, there must be a chain of keys and signatures all the way down from the root (or at least starting from a trust anchor common to the mobile node and the correspondent node) to the given IP address. Furthermore, it is not enough that each key be signed by the key above it in the chain. It is also necessary that each signature explicitly authorize the lower key to manage the corresponding address block below 🔗.
Even though it would be theoretically possible to build a secure reverse DNS infrastructure along the lines shown above, the practical problems would be daunting 😵. Whereas the delegation and key signing might work close to the root of the tree, it would probably break down somewhere along the path to the individual nodes. Note that a similar delegation tree is currently being proposed for Secure Neighbor Discovery [15], although in this case only routers (not necessarily every single potential mobile node) need to secure such a certificate. Furthermore, checking all the signatures on the tree would place a considerable burden on the correspondent nodes, making route optimization prohibitive, or at least justifiable only in very particular circumstances 🐢. Finally, it is not enough simply to check whether the mobile node is authorized to send binding updates containing a given home address, because to protect against flooding attacks, the care-of address must also be verified.
Relying on this same secure DNS infrastructure to verify care-of addresses would be even harder than verifying home addresses 🫠. Instead, a different method would be required, e.g., a return routability procedure. If so, the obvious question is whether the gargantuan cost of deploying the global secure DNS infrastructure is worth the additional protection it affords, as compared to simply using return routability for both home address and care-of address verification 🤔.
4. Solution Selected for Mobile IPv6 🌸
The current Mobile IPv6 route optimization security has been carefully designed to prevent or mitigate the threats that were discussed in Section 3 🛡️. The goal has been to produce a design with a level of security close to that of a static IPv4-based Internet, and with an acceptable cost in terms of packets, delay, and processing. The result is not what one would expect: it is definitely not a traditional cryptographic protocol 🙃. Instead, the result relies heavily on the assumption of an uncorrupted routing infrastructure and builds upon the idea of checking that an alleged mobile node is indeed reachable through both its home address and its care-of address. Furthermore, the lifetime of the state created at the corresponded nodes is deliberately restricted to a few minutes, in order to limit the potential threat from time shifting ⏳.
This section describes the solution in reasonable detail (for further details see the specification), starting from Return Routability (Section 4.1), continuing with a discussion about state creation at the correspondent node (Section 4.2), and completing the description with a discussion about the lifetime of Binding Cache Entries (Section 4.3) 👑.
4.1. Return Routability 🦋
okay so Return Routability (RR) is the name of the basic mechanism behind Mobile IPv6 route optimization security design, and it's giving main character energy 👑. The idea is that a node should be able to check that some node is actually able to respond to packets sent to a given address. The check gives false positives if the routing infrastructure is compromised, or if there's an attacker sitting between the verifier and the address being verified. Apart from those exceptions, a successful reply is taken to mean there really is a node at that address, and that the node is willing to reply to the probes sent to it ✨.
The basic return routability mechanism has two checks: a Home Address check (see Section 4.1.1) and a care-of-address check (see Section 4.1.2). The packet flow is shown in Figure 7 🎀. First, the mobile node sends two packets to the correspondent node. A Home Test Init (HoTI) packet goes through the home agent, and a Care-of Test Init (CoTI) goes straight there. The correspondent node replies to both independently: a Home Test (HoT) in response to the Home Test Init, and a Care-of Test (CoT) in response to the Care-of Test Init. Last step, once the mobile node has received both the Home Test and the Care-of Test, it sends a Binding Update to the correspondent node 💌.
+------+ 1a) HoTI +------+
| |---------------------->| |
| MN | 2a) HoT | HA |
| |<----------------------| |
+------+ +------+
1b) CoTI | ^ | / ^
| |2b| CoT / /
| | | / /
| | | 3) BU / /
V | V / /
+------+ 1a) HoTI / /
| |<----------------/ /
| CN | 2a) HoT /
| |------------------/
+------+Figure 7. Return Routability Packet Flow
It might look a bit convoluted, honestly 🙈. The real return routability checks are the message pairs < Home Test, Binding Update > and < Care-of Test, Binding Update >. The Home Test Init and Care-of Test Init packets only exist to trigger the test packets, and the Binding Update works as a combined routability response to both tests 🧚.
There are two main reasons for this design:
- avoidance of reflection and amplification (see Section 3.3.3), and
- avoidance of state exhaustion DoS attacks (see Section 4.2).
Why two Init packets instead of one? To avoid amplification 💅. The correspondent node doesn't know anything about the mobile node, so it just gets an unsolicited IP packet from some arbitrary IP address. It's kind of like a server getting a TCP SYN from a client it has never met before. If the correspondent node sent two packets back in response to one initial trigger, that would open the door to a DoS amplification effect, as discussed in Section 3.3.3 😭.
This scheme also dodges a potential reflection attack 🔥. If the correspondent node replied to some address other than the packet's source address, that would create a reflection effect. So the only safe option for a naive correspondent is to reply to each received packet with just one packet, sent to the source address of the received packet. That's why two initial triggers are needed instead of just one 🍓.
Let's look at the two return routability tests separately now. In the following sections, the derivation of cryptographic material from each of them is shown in a simplified way. For the real formulas and more detail, please refer to [6] 🌸.
4.1.1. Home Address Check
The Home Address check is made up of a Home Test (HoT) packet and a subsequent Binding Update (BU) 🫶. It gets triggered when a Home Test Init (HoTI) arrives. The correspondent node answers a Home Test Init by sending a Home Test to the source address of that Home Test Init. The source address is assumed to be the home address of a mobile node, so the Home Test is assumed to be tunneled by the Home Agent to the mobile node. The Home Test carries a cryptographically generated token, the home keygen token, which is formed by calculating a hash function over the concatenation of a secret key, Kcn (known only by the correspondent node), the source address of the Home Test Init packet, and a nonce.
home keygen token = hash(Kcn | home address | nonce | 0)An index to the nonce is also included in the Home Test packet, so the correspondent node can find the right nonce more easily 🔍.
The token lets the correspondent node make sure that any binding update received afterwards was created by a node that has seen the Home Test packet. See Section 4.2 for more on that ✨.
In most cases, the Home Test packet gets forwarded over two different segments of the Internet. First it travels from the correspondent node to the Home Agent. On this trip it's not protected, so any eavesdropper on the path can learn what's in it 👀. The Home Agent then forwards the packet to the mobile node, and this path goes inside an IPsec ESP protected tunnel, which makes it impossible for outsiders to learn the contents of the packet 🔒.
At first you might think it's unnecessary to protect the packet between the home agent and the mobile node, since it already travelled unprotected between the correspondent node and the mobile node. Here's the thing though: if every link in the Internet were equally insecure, the extra protection really would be pointless. But in most practical setups the network is likely to be more secure near the home agent than near the mobile node 🌈. For example, if the home agent hosts a virtual home link and the mobile nodes are never actually at home, an eavesdropper would have to be close to the correspondent node, or on the path between the correspondent node and the home agent, since they couldn't eavesdrop at the home agent. If the correspondent node is a major server, all the links on the path between it and the home agent are likely to be fairly secure. On the other hand, the Mobile Node is probably using wireless access technology, which can make it sometimes trivial to eavesdrop on its access link 📡. So it's fairly easy to eavesdrop on packets that arrive at the mobile node. That's why protecting the HA-MN path is likely to provide real security benefits, even when the CN-HA path stays unprotected 🦋.
4.1.2. Care-of-Address Check
From the correspondent node's point of view, the Care-of-Address check is very similar to the home check 💖. The only difference is that the source address of the received Care-of Test Init packet is now assumed to be the care-of address of the mobile node. The token is also created in a slightly different way, so that home tokens can't be used as care-of tokens, or the other way around 🙅.
care-of keygen token = hash(Kcn | care-of address | nonce | 1)The Care-of Test only travels one leg, directly from the correspondent node to the mobile node. It stays unprotected the whole way, which makes it vulnerable to eavesdroppers near the correspondent node, on the path from the correspondent node to the mobile node, or near the mobile node 👂.
4.1.3. Forming the First Binding Update
Once the mobile node has received both the Home Test and the Care-of Test messages, it creates a binding key, Kbm, by computing a hash function over the concatenation of the tokens it received 🔑.
This key protects the first binding update and the subsequent ones too, for as long as the key stays valid ⏳.
Heads up: the key Kbm is available to anyone who is able to receive both the Care-of Test and Home Test messages. But they're normally routed over different routes through the network, and the Home Test is sent over an encrypted tunnel from the home agent to the mobile node (see also Section 5.4) 🫣.
4.2. Creating State Safely
The correspondent node can stay stateless until it receives the first Binding Update 🧘. That means it doesn't need to record receiving and replying to the Home Test Init and Care-of Test Init messages. The Home Test Init/Home Test and Care-of Test Init/Care-of Test exchanges happen in parallel but independently of each other. So the correspondent can respond to each message right away, and it doesn't need to remember doing that. This helps in potential denial-of-service situations, because no memory needs to be reserved for processing Home Test Init and Care-of Test Init messages 💪. Also, Home Test Init and Care-of Test Init processing is designed to be lightweight, and it can be rate limited if necessary 🚦.
When a first binding update arrives, the correspondent node goes through a rather complicated procedure 🤯. The purpose is to make sure there really is a mobile node that has recently received a Home Test and a Care-of Test that were sent to the claimed home and care-of addresses, respectively. It also makes sure the correspondent node doesn't spend CPU or other resources unnecessarily while doing this check.
Since the correspondent node has no state when the binding update arrives, the binding update itself has to carry enough information for the relevant state to be created. So the binding update contains the following pieces of information:
- Source address: The care-of address specified in the Binding Update must be equal to the source address used in the Care-of Test Init message. Notice that this applies to the effective Care-of Address of the Binding Update. In particular, if the Binding Update includes an Alternate Care-of Address (AltCoA) [6], the effective CoA is, of course, this AltCoA. Thus, the Care-of Test Init must have originated from the AltCoA ✨.
- Home address: The home address specified in the Binding Update must be equal to the source address used in the Home Test Init message 🏠.
- Two nonce indices: These are copied over from the Home Test and Care-of Test messages. Together with the other information, they let the correspondent node re-create the tokens sent in the Home Test and Care-of Test messages, which are used for creating Kbm. Without them, the correspondent node might need to try the 2-3 latest nonces, which would lead to unnecessary resource consumption 🫠.
- Message Authentication Code (MAC): The binding update is authenticated by computing a MAC function over the care-of address, the correspondent node's address and the binding update message itself. The MAC is keyed with the key Kbm 🔐.
Given the addresses, the nonce indices (and therefore the nonces) and the key Kcn, the correspondent node can re-create the home and care-of tokens at the cost of a few memory lookups and the computation of one MAC and one hash function 🧮.
Once the correspondent node has re-created the tokens, it hashes the tokens together to get the key Kbm. If the Binding Update is authentic, Kbm is cached together with the binding. That key is then used to verify the MAC that protects the integrity and origin of the actual Binding Update 💜. Note that the same Kbm may be used for a while, until the mobile node moves (and needs to get a new care-of token), the care-of token expires, or the home token expires ⭐.
4.2.1. Retransmissions and State Machine ✨
Okay bestie, so the correspondent node can stay totally stateless until it gets a valid binding update 🧚. That means the mobile node is solely responsible for retransmissions 💅. The mobile node should keep sending the Home Test Init / Care-of Test Init messages until it receives a Home Test / Care-of Test, respectively. It may also need to send the binding update a few times in case it gets lost in transit 😭
4.3. Quick expiration of the Binding Cache Entries 🦋
A Binding Cache Entry, along with the key Kbm, represents the return routability state of the network at the time the Home Test and Care-of Test messages were sent out. It's possible that a specific attacker can eavesdrop on a Home Test message at one point in time but not later 👀. If the Home Test had an infinite or a long lifetime, that would let the attacker do a time shifting attack (see Section 2.2). Basically, in the current IPv4 architecture, an attacker on the path between the correspondent node and the home agent can only attack for as long as they can eavesdrop on (and maybe disrupt) communications on that particular path. A long-living Home Test, and the ability to send valid binding updates for a long time because of it, would let the attacker keep attacking even after they've lost access to the path. Main villain energy 🙈
To limit the seriousness of this and other similar time shifting threats, the validity of the tokens is limited to a few minutes ⏱️. This effectively limits the validity of the key Kbm and the lifetime of the resulting binding updates and binding cache entries.
Although short lifetimes are required by other aspects of the security design and goals, they are clearly bad for efficiency and robustness 😩. A Home Test Init / Home Test message pair must be exchanged through the home agent every few minutes. These messages aren't needed from a purely functional point of view, so they're just overhead. What's worse is that they make the home agent a single point of failure 💀. If the Home Test Init / Home Test messages weren't needed, the existing connections from a mobile node to other nodes could keep going even when the home agent fails. But the current design forces the bindings to expire after a few minutes.
This concludes our walk-through of the selected security design 🎀. The cornerstones were using the return routability idea in the Home Test, Care-of Test, and binding update messages, the ability to remain stateless until a valid binding update is received, and limiting binding lifetimes to a few minutes. Next, we'll briefly talk about some of the remaining threats and other problems inherent to the design.
5. Security Considerations 🔥
This section gives a brief analysis of the security design, mostly in the light of what was known when the design was completed in Fall 2002. Let me be clear: this section does not present a proper security analysis of the protocol. It just discusses a few issues that were known at the time the design was finished 🙏.
It's important to remember that the MIPv6 RO security design was never meant to be fully secure. The goal was to be roughly as secure as non-mobile IPv4 was known to be at the time of the design. As it turns out, the result is slightly less secure than IPv4, but the difference is small and most likely insignificant in real life 🌸.
The known residual threats compared with IPv4 are discussed in Section 5.1. Considerations related to using IPsec to authorize route optimization are discussed in Section 5.2. Section 5.3 covers an attack against neighboring nodes. Finally, Section 5.4 deals with the special case of two mobile nodes conversing and performing the route optimization procedure with each other 💜.
5.1. Residual Threats as Compared to IPv4
As we mentioned in Section 4.2, the lifetime of a binding represents a potential time shift in an attack. An attacker who can create a false binding can reap the benefits of that binding for as long as it lasts. Alternatively, the attacker can delay a return-to-home flooding attack (Section 3.2.2) until the binding expires 😈. This is different from IPv4, where an attacker can only keep attacking as long as it's on the path between the two hosts.
Since the binding lifetimes are severely restricted in the current design, the ability to do a time shifting attack is restricted to the same degree 🙌.
Threats that exist because route optimization was introduced are, of course, not present in a baseline IPv4 internet (Section 3.3). In particular, inducing unnecessary binding updates could potentially be a severe attack, but that would most likely come from faulty implementations 🫠. As an extreme measure, a correspondent node can protect against these attacks by turning off route optimization. If it does, it becomes obvious that the only residual attack with no clear-cut prevention (other than its severe limitation as currently specified) is the time shifting attack mentioned above 🥀.
5.2. Interaction with IPsec
A major motivation behind the current binding update design was scalability, which meant the protocol had to run without any existing security infrastructure 🏗️. An alternative would have been to rely on existing trust relationships, perhaps through a special-purpose Public Key Infrastructure used together with IPsec. That would have limited scalability, making route optimization available only in environments where it's possible to create appropriate IPsec security associations between the mobile nodes and the corresponding nodes.
There are definitely situations where an appropriate relationship exists between a mobile node and the correspondent node. For example, if the correspondent node is a server that has pre-established keys with the mobile node, that's the case 🔑. However, entity authentication or an authenticated session key is not necessarily sufficient for accepting Binding Updates.
Home Address Check: If you want to replace the home address check with cryptographic credentials, those credentials must carry proper authorization for the specific home address. Care must be taken to make sure the issuer of the certificate is entitled to express that authorization 📜. When the design work was happening, the route optimization security design team wasn't aware of standardized certificate formats for doing this, though more recent efforts within the IETF are addressing this issue. There's plenty of motivation to do so, since any pre-existing relationship with a correspondent node would involve the mobile node's home address (instead of any of its possible care-of addresses). So the IKE exchange would most naturally run between the correspondent node and the mobile node's home address. That still leaves open the issue of checking the mobile node's care-of address 🤔.
Care-of Address Check: As for the care-of-address check, in practice it seems highly unlikely that nodes could completely replace it with credentials. Care-of addresses are ephemeral, so in general it's very difficult for a mobile node to present credentials that, taken at face value by an arbitrary correspondent node, guarantee no misuse for things like flooding attacks (Section 3.2). As discussed before, a reachability check goes a long way toward alleviating such attacks. Notice that, as part of the normal protocol exchange, establishing IPsec security associations via IKE includes one such reachability test 👍. However, as per the previous section, the natural IKE exchange runs between the correspondent node and the mobile node's home address. So another reachability check is needed to check the care-of address where the node is currently reachable. If that address changes, a similar reachability test is likewise necessary, and it's included in ongoing work aimed at securely updating the node's current address 🌈.
Nevertheless, the Mobile IPv6 base specification [6] does not specify how to use IPsec together with the mobility procedures between the mobile node and the correspondent node. On the other hand, the specification is carefully written to allow the binding management key Kbm to be created through some different means ✨. So where an appropriate relationship exists between a mobile node and a correspondent node, using IPsec is possible, and it's actually being pursued in more recent work 🦋.
5.3. Pretending to Be One's Neighbor
One possible attack against the security design is pretending to be a neighboring node 🥷. To launch it, the mobile node establishes route optimization with some arbitrary correspondent node. While performing the return routability tests and creating the binding management key Kbm, the attacker uses its real home address but a faked care-of address. In fact, the care-of address would be the address of the neighboring node on the local link. The attacker can create the binding because it receives a valid Home Test normally, and it can eavesdrop on the Care-of Test because that test appears on the local link 👂.
This attack would let the mobile node divert unwanted traffic toward the neighboring node, resulting in a flooding attack 🌊.
However, this attack isn't very serious in practice. First, it's limited in terms of location, since it's only possible against neighbors. Second, the attack also works against the attacker, since the attacker shares the local link with the target 🙃. Third, a similar attack is possible with Neighbor Discovery spoofing.
5.4. Two Mobile Nodes Talking to Each Other
When two mobile nodes want to establish route optimization with each other, some care must be taken so the reverse tokens aren't revealed to an attacker 🕵️♀️. In this situation, both mobile nodes act simultaneously in the mobile node and the correspondent node roles. In the correspondent node role, the nodes are vulnerable to attackers that are co-located on the same link. Such an attacker can learn both the Home Test and Care-of Test sent by the mobile node, so it can spoof the location of the other mobile host to the neighboring one 😱. What's worse is that the attacker can obtain a valid Care-of Test itself, combine it with the Home Test, and then tell the neighboring node that the other node has just arrived on the same link.
There's an easy way to avoid this attack 💖. In the correspondent node role, the mobile node should tunnel the Home Test messages it sends through its home agent. This stops the co-located attacker from learning any valid Home Test messages 🫶.
6. Conclusions ✨
okay so this doc was all about the security design behind Mobile IPv6 Route Optimization 🦋 we looked at the dangers that Mobile IP Route Optimization creates, the security goals and background of the design, and the actual mechanisms it uses. we talked about the IP routing architecture first, then the definition of the mobility problem, and that set the stage for everything else 💅
after that we covered the avenues of attack: the targets, the time shifting abilities, and where an attacker could be sitting. we listed a bunch of threat scenarios and showed how the current design mitigates them 🔥 and finally, in Section 4, we walked through the mechanisms that are actually used and the reasoning behind each one 🧚
as far as we know today, the only big difference between security on an IPv4 Internet and security on an Internet with Mobile IPv6 (and route optimization) is time shifting attacks 😭 but honestly, these are super restricted in the current design, so it's not as scary as it sounds 🫶
we also briefly covered some known subtleties and shortcomings, but that discussion can't be exhaustive, so don't come at me for that 🙈 it's quite likely that new subtle problems will turn up with the design. so it's most likely that the design will need to be revised in light of experience and new insight. this is literally how protocols grow up 🌱✨
7. Acknowledgements 🎀
we are so grateful to: Hesham Soliman, for reminding us about the threat explained in Section 5.3 🫶 Francis Dupont, for first discussing the case of two mobile nodes talking to each other (Section 5.4) and for sundry other comments 💜 Pekka Savola, for his help in Section 1.1.1 🌸 and Elwyn Davies, for his thorough editorial review 👑
8. Informative References 📚
[1] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", Proc. 18th Annual Computer Security Applications Conference, pages 78-87, Las Vegas, NV, USA, IEEE Press, December 2002.
[2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[3] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[4] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002.
[5] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[7] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[11] Chiappa, J., "Will The Real 'End-End Principle' Please Stand Up?", Private Communication, April 2002.
[12] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29:5, October 1999.
[13] Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", Security Protocols 9th International Workshop, Cambridge, UK, April 25-27 2001, LNCS 2467, pages 12-26, Springer, 2002.
[14] Chiappa, J., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", Private Communication, 1999.
[15] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
Authors' Addresses 🌈
Pekka Nikander
Pekka Nikander
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.comJari Arkko
Jari Arkko
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
EMail: jari.arkko@ericsson.comTuomas Aura
Tuomas Aura
Microsoft Research Ltd.
Roger Needham Building
7 JJ Thomson Avenue
Cambridge CB3 0FB
United Kingdom
EMail: Tuomaura@microsoft.comGabriel Montenegro
Gabriel Montenegro
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: gabriel_montenegro_2000@yahoo.comErik Nordmark
Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, CA 94025
USA
EMail: erik.nordmark@sun.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 💼
The IETF takes no position regarding 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 the extent to which any license under such rights might or might not be available. Nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to 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 made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, 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 that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💖
Funding for the RFC Editor function is currently provided by the Internet Society. 🌸✨
📦 where this page comes from
- ietf: rfc4225 2005-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms