diff options
Diffstat (limited to 'doc/rfc/rfc4225.txt')
| -rw-r--r-- | doc/rfc/rfc4225.txt | 2075 |
1 files changed, 2075 insertions, 0 deletions
diff --git a/doc/rfc/rfc4225.txt b/doc/rfc/rfc4225.txt new file mode 100644 index 0000000..cea0c81 --- /dev/null +++ b/doc/rfc/rfc4225.txt @@ -0,0 +1,2075 @@ + + + + + + +Network Working Group P. Nikander +Request for Comments: 4225 J. Arkko +Category: Informational Ericsson Research NomadicLab + T. Aura + Microsoft Research + G. Montenegro + Microsoft Corporation + E. Nordmark + Sun Microsystems + December 2005 + + + Mobile IP Version 6 Route Optimization Security Design Background + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document is an account of the rationale behind the Mobile IPv6 + (MIPv6) Route Optimization security design. The purpose of this + document is to present the thinking and to preserve the reasoning + behind the Mobile IPv6 security design in 2001 - 2002. + + The document has two target audiences: (1) helping MIPv6 implementors + to better understand the design choices in MIPv6 security procedures, + and (2) allowing people dealing with mobility or multi-homing to + avoid a number of potential security pitfalls in their designs. + + + + + + + + + + + + + + + + +Nikander, et al. Informational [Page 1] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + +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 .........................................34 + + + + +Nikander, et al. Informational [Page 2] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + +1. Introduction + + Mobile IPv4 is based on the idea of supporting mobility on top of + existing IP infrastructure, without requiring any modifications to + the routers, the applications, or the stationary end hosts. However, + in Mobile IPv6 [6] (as opposed to Mobile IPv4), the stationary end + hosts may provide support for mobility, i.e., route optimization. In + route optimization, a correspondent node (CN) (i.e., a peer for a + mobile node) learns a binding between the mobile node's stationary + home address and its current temporary care-of address. This binding + is then used to modify the handling of outgoing (as well as the + processing of incoming) packets, leading to security risks. The + purpose of this document is to provide a relatively compact source + for the background assumptions, design choices, and other information + needed to understand the route optimization security design. This + document does not seek to compare the relative security of Mobile + IPv6 and other mobility protocols, or to list all the alternative + security mechanisms that were discussed during the Mobile IPv6 design + process. For a summary of the latter, we refer the reader to [1]. + Even though incidental implementation suggestions are included for + illustrative purposes, the goal of this document is not to provide a + guide to implementors. Instead, it is to explain the design choices + and rationale behind the current route optimization design. The + authors participated in the design team that produced the design and + hope, via this note, to capture some of the lessons and reasoning + behind that effort. + + The authors' intent is to document the thinking behind that design + effort as it was. Even though this note may incorporate more recent + developments in order to illustrate the issues, it is not our intent + to present a new design. Rather, along with the lessons learned, + there is some effort to clarify differing opinions, questionable + assumptions, or newly discovered vulnerabilities, should such new + information be available today. This is also very important, because + it may benefit the working group's hindsight as it revises or + improves the Mobile IPv6 specification. + + To fully understand the security implications of the relevant design + constraints, it is necessary to explore briefly the nature of the + existing IP infrastructure, the problems Mobile IP aims to solve, and + the design principles applied. In the light of this background, we + can then explore IP-based mobility in more detail and have a brief + look at the security problems. The background is given in the rest + of this section, starting from Section 1.1. + + Although the introduction in Section 1.1 may appear redundant to + readers who are already familiar with Mobile IPv6, it may be valuable + to read it anyway. The approach taken in this document is very + + + +Nikander, et al. Informational [Page 3] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + different from that in the Mobile IPv6 specification. That is, we + have explicitly aimed to expose the implicit assumptions and design + choices made in the base Mobile IPv6 design, while the Mobile IPv6 + specification aims to state the result of the design. By + understanding the background, it is much easier to understand the + source of some of the related security problems, and to understand + the limitations intrinsic to the provided solutions. + + In particular, this document explains how the adopted design for + "Return Routability" (RR) protects against the identified threats + (Section 3). This is true except for attacks on the RR protocol + itself, which require other countermeasures based on heuristics and + judicious implementation (Section 3.3). + + The rest of this document is organized as follows: after this + introductory section, we start by considering the avenues of attack + in Section 2. The security problems and countermeasures are studied + in detail in Section 3. Section 4 explains the overall operation and + design choices behind the current security design. Section 5 + analyzes the design and discuss the remaining threats. Finally, + Section 6 concludes this document. + +1.1. Assumptions about the Existing IP Infrastructure + + One of the design goals in the Mobile IP design was to make mobility + possible without changing too much. This was especially important + for IPv4, with its large installed base, but the same design goals + were inherited by Mobile IPv6. Some alternative proposals take a + different approach and propose larger modifications to the Internet + architecture (see Section 1.4). + + To understand Mobile IPv6, it is important to understand the MIPv6 + design view of the base IPv6 protocol and infrastructure. The most + important base assumptions can be expressed as follows: + + 1. 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. + + 2. The routing infrastructure is assumed to be secure and well + functioning, delivering packets to their intended destinations as + identified by destination address. + + Although these assumptions may appear to be trivial, let us explore + them a little further. First, in current IPv6 operational practice + the IP address prefixes are distributed in a hierarchical manner. + This limits the number of routing table entries each individual + router needs to handle. An important implication is that the + + + +Nikander, et al. Informational [Page 4] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + topology determines what globally routable IP addresses are available + at a given location. That is, the nodes cannot freely decide what + globally routable IP address to use; they must rely on the routing + prefixes served by the local routers via Router Advertisements or by + a DHCP server. In other words, IP addresses are just what the name + says, addresses (i.e., locators). + + Second, in the current Internet structure, the routers collectively + maintain a distributed database of the network topology and forward + each packet towards the location determined by the destination + address carried in the packet. To maintain the topology information, + the routers must trust each other, at least to a certain extent. The + routers learn the topology information from the 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 the amount of perhaps faulty routing table information + received from the peer domains. While this is mostly used to weed + out administrative mistakes, it also helps with security. The aim is + to maintain a reasonably accurate idea of the network topology even + if someone is feeding faulty information to the routing system. + + In the current Mobile IPv6 design, it is 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 is, it is assumed that the routing system maintains accurate + information of the network topology, and that it is therefore able to + route packets to their destination locations. If this assumption is + broken, the Internet itself is broken in the sense that packets go to + wrong locations. Such a fundamental malfunction of the Internet + would render hopeless any other effort to assure correct packet + delivery (e.g., any efforts due to Mobile IP security + considerations). + +1.1.1. A Note on Source Addresses and Ingress Filtering + + Some of the threats and attacks discussed in this document take + advantage of the ease of source address spoofing. That is, in the + current Internet it is 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 be + applied at different network borders, such as those 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 specifies 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 does + + + +Nikander, et al. Informational [Page 5] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + filtering at LAN subnets, anything inside the /64 prefixes could be + spoofed. Despite the limitations imposed by such "in-prefix + spoofing", in general, ingress filtering enables traffic to be + traceable to its real source network [5]. + + However, ingress filtering 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, although not + insurmountable, do require careful handling, and that are likely to + limit or delay its usefulness [5]. + +1.2. The Mobility Problem and the Mobile IPv6 Solution + + The Mobile IP design aims to solve two problems at the same time. + First, it allows transport layer sessions (TCP connections, UDP- + based transactions) to continue even if the underlying host(s) move + and change their IP addresses. Second, it allows a node to be + reached through a static IP address, a home address (HoA). + + The latter design choice can also be stated in other words: Mobile + IPv6 aims to preserve the identifier nature of IP addresses. That + is, Mobile IPv6 takes the view that IP addresses can be used as + natural identifiers of nodes, as they have been used since the + beginning of the Internet. This must be contrasted to proposed and + existing alternative designs where the identifier and locator natures + of the IP addresses have been separated (see Section 1.4). + + The basic idea in Mobile IP is to allow a home agent (HA) to work 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 to the node and forwards the packets 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 illustrates this basic + arrangement. + + The basic solution requires tunneling through the home agent, thereby + leading to longer paths and degraded performance. This tunneling is + sometimes called triangular routing since it was originally planned + that the packets from the mobile node to its peer could still + traverse directly, bypassing the home agent. + + + + + + + + + + +Nikander, et al. Informational [Page 6] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + +----+ +----+ + | 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 IPv6 + + To alleviate the performance penalty, Mobile IPv6 includes a mode of + operation that allows the mobile node and its peer, a correspondent + node (CN), to exchange packets directly, bypassing the home agent + completely after the initial setup phase. This mode of operation 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 into + its Binding Cache. + + Whenever MIPv6 route optimization is used, the correspondent node + effectively functions in two roles. Firstly, it is the source of the + packets it sends, as usual. Secondly, it acts as the first router + for the packets, effectively performing source routing. That is, + when the correspondent node is sending out packets, it consults its + MIPv6 route optimization data structures and reroutes the packets, if + necessary. A Binding Cache Entry (BCE) contains 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. Thus, it represents 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. Thus, 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 + packet is consumed by the mobile node at the care-of address; the + header just allows the mobile node to select a socket associated with + the home address instead of one with the care-of address. However, + the mechanism resembles source routing, as there is routing state + involved at the correspondent node, and a routing header is used. + + + +Nikander, et al. Informational [Page 7] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + Nevertheless, this routing header is special (type 2) to avoid the + risks associated with using the more general (type 0) variant. + +1.3. Design Principles and Goals + + The MIPv6 design and security design aimed to follow the end-to-end + principle, to notice the differences in trust relationships between + the nodes, and to be explicit about delivering a practical (instead + of an over-ambitious) level of protection. + +1.3.1. End-to-End Principle + + Perhaps the leading design principle for Internet protocols is the + so-called end-to-end principle [4][11]. According to this principle, + it is beneficial to avoid polluting the network with state, and to + limit new state creation to the involved end nodes. + + In the case of Mobile IPv6, the end-to-end principle is applied by + restricting mobility-related state primarily to the home agent. + Additionally, if route optimization is used, the correspondent nodes + also maintain a soft state relating to the mobile nodes' current + care-of addresses, the Binding Cache. This can be contrasted to an + approach that would use individual host routes within the basic + routing system. Such an 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 + + In the Mobile IPv6 security design, different approaches were chosen + for securing the 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., due to a + business relationship. In contrast, it was strictly assumed that the + mobile node and the correspondent node do not need to have any prior + arrangement, thereby allowing Mobile IPv6 to function in a scalable + manner, without requiring any configuration at the correspondent + nodes. + +1.3.3. Protection Level + + As a security goal, Mobile IPv6 design aimed to be "as secure as the + (non-mobile) IPv4 Internet" was at the time of the design, in the + period 2001 - 2002. In particular, that means that there is little + protection against attackers that are able to attach themselves + between a correspondent node and a home agent. The rationale is + simple: in the 2001 Internet, if a node was able to attach itself to + + + +Nikander, et al. Informational [Page 8] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + the communication path between two arbitrary nodes, it was able to + disrupt, modify, and eavesdrop all the traffic between the two nodes, + unless IPsec protection was used. Even when IPsec was used, the + attacker was still able to block communication selectively by simply + dropping the packets. The attacker in control of a router between + the two nodes could also mount a flooding attack by redirecting the + data flows between the two nodes (or, more practically, an equivalent + flow of bogus data) to a third party. + +1.4. About Mobile IPv6 Mobility and its Variations + + Taking a more abstract angle, IPv6 mobility can be defined as a + mechanism for managing local exceptions to routing information in + order to direct packets that are sent to one address (the home + address) to another address (the care-of address). It is managing in + the sense that the local routing exceptions (source routes) are + created and deleted dynamically, according to instructions sent by + the mobile node. It is local in the sense that the routing + exceptions are valid only at the home agent, and in the correspondent + nodes if route optimization is used. The created pieces of state are + exceptions in the sense that they override the normal topological + routing information carried collectively by the routers. + + Using the terminology introduced by J. Noel Chiappa [14], we can say + that the home address functions in the dual role of being an end- + point identifier (EID) and a permanent locator. The care-of address + is a pure, temporary locator, which identifies the current location + of the mobile node. The correspondent nodes effectively perform + source routing, redirecting traffic destined to the home address to + the care-of address. This is even reflected in the packet structure: + 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, however, are beyond the scope of this document. + +2. Avenues of Attack + + From the discussion above, it should now be clear that the dangers + that Mobile IPv6 must protect from lie in creation (or deletion) of + the local routing exceptions. In Mobile IPv6 terms, the danger is in + the possibility of unauthorized creation of Binding Cache Entries + (BCE). The effects of an attack differ depending on the target of + the attack, the timing of the attack, and the location of the + attacker. + + + + + + +Nikander, et al. Informational [Page 9] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + +2.1. Target + + Basically, the target of an attack can be any node or network in the + Internet (stationary or mobile). The basic differences lie in the + goals of the attack: does the attacker aim to divert (steal) the + traffic destined to and/or sourced at the target node, or does it aim + to cause denial-of-service to the target node or network? The target + does not typically play much of an active role attack. As an + example, an attacker may launch a denial-of-service attack on a given + node, A, by contacting a large number of nodes, claiming to be A, and + subsequently diverting the traffic at these other nodes so that A is + no longer able to receive packets from those nodes. A itself need + not be involved at all before its communications start to break. + Furthermore, A is not necessarily a mobile node; it may well be + stationary. + + Mobile IPv6 uses the same class of IP addresses for both mobile nodes + (i.e., home and care-of addresses) and stationary nodes. That is, + mobile and stationary addresses are indistinguishable from each + other. Attackers can take advantage of this by taking any IP address + and using it in a context where, normally, only mobile (home or + care-of) addresses appear. This means that attacks that otherwise + would only concern mobile nodes are, in fact, a threat to all IPv6 + nodes. + + In fact, a mobile node appears to be best protected, since a mobile + node does not need to maintain state about the whereabouts of some + remote nodes. Conversely, the role of being a correspondent node + appears to be the weakest, since there are very few assumptions upon + which it can base its state formation. That is, an attacker has a + much easier task in fooling a correspondent node to believe that a + presumably mobile node is somewhere it is not, than in fooling a + mobile node itself into believing something similar. On the other + hand, since it is possible to attack a node indirectly by first + targeting its peers, all nodes are equally vulnerable in some sense. + Furthermore, a (usually) mobile node often also plays the role of + being a correspondent node, since it can exchange packets with other + mobile nodes (see also Section 5.4). + +2.2. Timing + + An important aspect in understanding Mobile IPv6-related dangers is + timing. In a stationary IPv4 network, an attacker must be between + the communication nodes at the same time as the nodes communicate. + With the Mobile IPv6 ability of creating binding cache entries, the + situation changes. A new danger is created. Without proper + protection, an attacker could attach itself between the home agent + and a correspondent node for a while, create a BCE at the + + + +Nikander, et al. Informational [Page 10] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + correspondent node, leave the position, and continuously update the + correspondent node about the mobile node's whereabouts. This would + make the correspondent node send packets destined to the mobile node + to an incorrect address as long as the BCE remained valid, i.e., + typically until the correspondent node is rebooted. The converse + would also be possible: an attacker could also launch an attack by + first creating a BCE and then letting it expire at a carefully + selected time. If a large number of active BCEs carrying large + amounts of traffic expired at the same time, the result might be an + overload towards the home agent or the home network. (See Section + 3.2.2 for a more detailed explanation.) + +2.3. Location + + In a static IPv4 Internet, an attacker can only receive packets + destined to a given address if it is able to attach itself to, or to + control, a node on the topological path between the sender and the + recipient. On the other hand, an attacker can easily send spoofed + packets from almost anywhere. If Mobile IPv6 allowed sending + unprotected Binding Updates, an attacker could create a BCE on any + correspondent node from anywhere in the Internet, simply by sending a + fraudulent Binding Update to the correspondent node. Instead of + being required to be between the two target nodes, the attacker could + act from anywhere in the Internet. + + In summary, by introducing the new routing exception (binding cache) + at the correspondent nodes, Mobile IPv6 introduces the dangers of + time and space shifting. Without proper protection, Mobile IPv6 + would allow an attacker to act from anywhere in the Internet and well + before the time of the actual attack. In contrast, in the static + IPv4 Internet, the attacking nodes must be present at the time of the + attack and they must be positioned in a suitable way, or the attack + would not be possible in the first place. + +3. Threats and Limitations + + This section describes attacks against Mobile IPv6 Route Optimization + and what protection mechanisms Mobile IPv6 applies against them. The + goal of the attacker can be to corrupt the correspondent node's + binding cache and to cause packets to be delivered to a wrong + address. This can compromise secrecy and integrity of communication + and cause denial-of-service (DoS) both at the communicating parties + and at the address that receives the unwanted packets. The attacker + may also exploit features of the Binding Update (BU) mechanism to + exhaust the resources of the mobile node, the home agent, or the + correspondent nodes. The aim of this section is to provide an + overview of the various protocol mechanisms and their limitations. + The details of the mechanisms are covered in Section 4. + + + +Nikander, et al. Informational [Page 11] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + It is essential to understand that some of the threats are more + serious than others, that some can be mitigated but not removed, that + some threats may represent acceptable risk, and that some threats may + be considered too expensive to the attacker to be worth preventing. + + We consider only active attackers. The rationale behind this is that + in order to corrupt the binding cache, the attacker must sooner or + later send one or more messages. Thus, it makes little sense to + consider attackers that only observe messages but do not send any. + In fact, some active attacks are easier, for the average attacker, to + launch than a passive one would be. That is, in many active attacks + the attacker can initiate binding update processing at any time, + while most passive attacks require the attacker to wait for suitable + messages to be sent by the target nodes. + + Nevertheless, an important class of passive attacks remains: attacks + on privacy. It is well known that simply by examining packets, + eavesdroppers can track the movements of individual nodes (and + potentially, users) [3]. Mobile IPv6 exacerbates the problem by + adding more potentially sensitive information into the packets (e.g., + Binding Updates, routing headers or home address options). This + document does not address these attacks. + + We first consider attacks against nodes that are supposed to have a + specified address (Section 3.1), continuing with flooding attacks + (Section 3.2) and attacks against the basic Binding Update protocol + (Section 3.3). After that, we present a classification of the + attacks (Section 3.4). Finally, we consider the applicability of + solutions relying on some kind of a global security infrastructure + (Section 3.5). + +3.1. Attacks Against Address 'Owners' ("Address Stealing") + + The most obvious danger in Mobile IPv6 is address "stealing", when an + attacker illegitimately claims to be a given node at a given address + and tries to "steal" traffic destined to that address. We first + describe the basic variant of this attack, follow with a description + of how the situation is affected if the target is a stationary node, + and continue with more complicated issues related to timing (so + called "future" attacks), confidentiality and integrity, and DoS + aspects. + +3.1.1. Basic Address Stealing + + If Binding Updates were not authenticated at all, an attacker could + fabricate and send spoofed binding updates from anywhere in the + Internet. All nodes that support the correspondent node + functionality would become unwitting accomplices to this attack. As + + + +Nikander, et al. Informational [Page 12] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + explained in Section 2.1, there is no way of telling which addresses + belong to mobile nodes that really could send binding updates and + which addresses belong to stationary nodes (see below), so + potentially any node (including "static" nodes) is vulnerable. + + +---+ original +---+ new packet +---+ + | B |<----------------| A |- - - - - - ->| C | + +---+ packet flow +---+ flow +---+ + ^ + | + | False BU: B -> C + | + +----------+ + | Attacker | + +----------+ + + Figure 2. Basic Address Stealing + + Consider an IP node, A, sending IP packets to another IP node, B. + The attacker could redirect the packets to an arbitrary address, C, + by sending a Binding Update to A. The home address (HoA) in the + binding update would be B and the care-of address (CoA) would be C. + After receiving this binding update, A 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 either its own + current address, another address in its local network, or any other + IP address. If the attacker selected a local care-of address + allowing it to receive the packets, it would be able to send replies + to the correspondent node. Ingress filtering at the attacker's + local+ network does not prevent the spoofing of Binding Updates but + forces the attacker either to choose a care-of address from inside + its own network or to use the Alternate care-of address sub-option. + + The binding update authorization mechanism used in the MIPv6 security + design is primarily intended 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). This means that it is + difficult to redirect all packets to or from a specific node because + the attacker would need to know the IP addresses of all the nodes + with which it is communicating. + + + + +Nikander, et al. Informational [Page 13] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + Nodes with well-known addresses, such as servers and those using + stateful configuration, are most vulnerable. Nodes that are a part + of the network infrastructure, such as 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. + + Thus, 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 to 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. + + + +Nikander, et al. Informational [Page 14] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + +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 highjack 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 Attack + + Strong 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). + + + + +Nikander, et al. Informational [Page 15] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + +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, + to 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 + + + +Nikander, et al. Informational [Page 16] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + 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 + + In the simplest attack, the attacker knows that there is a heavy data + stream from node A to B and redirects this to the target address C. + However, A would soon stop sending the data because it is not + receiving acknowledgements from B. + + (B is attacker) + + +---+ original +---+ flooding packet +---+ + | B |<================| A |==================>| C | + +---+ packet flow +---+ flow +---+ + | ^ + \ / + \__________________/ + False binding update + false acknowledgements + + Figure 4. Basic Flooding Attack + + A more sophisticated attacker would act itself as B; see Figure 4. + It would first subscribe to a data stream (e.g., a video stream) and + redirect this stream to the target address C. The attacker would + even be able to spoof the acknowledgements. For example, consider a + TCP stream. The attacker would perform the TCP handshake itself and + thus know the initial sequence numbers. After redirecting the data + to C, the attacker would continue to send spoofed acknowledgements. + It would even be able to accelerate the data rate by simulating a + fatter pipe [12]. + + This attack might be even easier with UDP/RTP. The attacker could + create spoofed RTCP acknowledgements. Either way, the attacker would + be able to redirect an increasing stream of unwanted data to the + target address without doing much work itself. It could carry on + opening more streams and refreshing the Binding Cache entries by + sending a new binding update every few minutes. Thus, the limitation + of BCE lifetime to a few minutes does not help here without + additional measures. + + During the Mobile IPv6 design process, the effectiveness of this + attack was debated. It was mistakenly assumed that the target node + would send a TCP Reset to the source of the unwanted data stream, + which would then stop sending. In reality, all practical TCP/IP + implementations fail to send the Reset. The target node drops the + unwanted packets at the IP layer because it does not have a Binding + + + +Nikander, et al. Informational [Page 17] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + Update List entry corresponding to the Routing Header on the incoming + packet. Thus, the flooding data is never processed at the TCP layer + of the target node, and no Reset is sent. This means that the attack + using TCP streams is more effective than was originally believed. + + This attack is serious because the target can be any node or network, + not only a mobile one. What makes it particularly serious compared + to the other attacks is that the target itself cannot do anything to + prevent the attack. For example, it does not help if the target + network stops using Route Optimization. The damage is compounded if + these techniques are used to amplify the effect of other distributed + denial-of-service (DDoS) attacks. Ingress filtering in the + attacker's local network prevents the spoofing of source addresses + but the attack would still be possible by setting the Alternate + care-of address sub-option to the target address. + + Again, the protection mechanism adopted for MIPv6 is return + routability. This time it is necessary to check that there is indeed + a node at the new care-of address, and that the node is the one that + requested redirecting packets to that very address (see Section + 4.1.2). + +3.2.2. Return-to-Home Flooding + + A variation of the bombing attack would target the home address or + the home network instead of the care-of address or a visited network. + The attacker would claim to be a mobile with the home address equal + to the target address. While claiming to be away from home, the + attacker would start downloading a data stream. The attacker would + then send a binding update cancellation (i.e., a request to delete + the binding from the Binding Cache) or just allow the cache entry to + expire. Either would redirect the data stream to the home network. + As when bombing a care-of address, the attacker can keep the stream + alive and even increase the data rate by spoofing acknowledgements. + When successful, the bombing attack against the home network is just + as serious as that against a care-of address. + + The basic protection mechanism adopted is return routability. + However, it is hard to fully protect against this attack; see Section + 4.1.1. + +3.3. Attacks against Binding Update Protocols + + Security protocols that successfully protect the secrecy and + integrity of data can sometimes make the participants more vulnerable + to denial-of-service attacks. In fact, the stronger the + authentication, the easier it may be for an attacker to use the + + + + +Nikander, et al. Informational [Page 18] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + protocol features to exhaust the mobile's or the correspondent's + resources. + +3.3.1. Inducing Unnecessary Binding Updates + + When a mobile node receives an IP packet from a new correspondent via + the home agent, it may initiate the binding update protocol. An + attacker can exploit this by sending the mobile node a spoofed IP + packet (e.g., ping or TCP SYN packet) that appears to come from a new + correspondent node. Since the packet arrives via the home agent, the + mobile node may start the binding update protocol with the + correspondent node. The decision as to whether to initiate the + binding update procedure may depend on several factors (including + heuristics, cross layer information, and configuration options) and + is not specified by Mobile IPv6. Not initiating the binding update + procedure automatically may alleviate these attacks, but it will not, + in general, prevent them completely. + + In a real attack the attacker would induce the mobile node to + initiate binding update protocols with a large number of + correspondent nodes at the same time. If the correspondent addresses + are real addresses of existing IP nodes, then most instances of the + binding update protocol might even complete successfully. The + entries created in the Binding Cache are correct but useless. In + this way, the attacker can induce the mobile to execute the binding + update protocol unnecessarily, which can drain the mobile's + resources. + + A correspondent node (i.e., any IP node) can also be attacked in a + similar way. The attacker sends spoofed IP packets to a large number + of mobiles, with the target node's address as the source address. + These mobiles will initiate the binding update protocol with the + target node. Again, most of the binding update protocol executions + will complete successfully. By inducing a large number of + unnecessary binding updates, the attacker is able to consume the + target node's resources. + + This attack is possible against any binding update authentication + protocol. The more resources the binding update protocol consumes, + the more serious the attack. Therefore, strong cryptographic + authentication protocol is more vulnerable to the attack than a weak + one 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 does not completely eliminate this threat. + + A node should protect itself from the attack by setting a limit on + the amount of resources (i.e., processing time, memory, and + communications bandwidth) that it uses for processing binding + + + +Nikander, et al. Informational [Page 19] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + updates. When the limit is exceeded, the node can simply stop + attempting route optimization. Sometimes it is possible to process + some binding updates even when a node is under the attack. A mobile + node may have a local security policy listing a limited number of + addresses to which binding updates will be sent even when the mobile + node is under DoS attack. A correspondent node (i.e., any IP node) + may similarly have a local security policy listing a limited set of + addresses from which binding updates will be accepted even when the + correspondent is under a binding update DoS attack. + + The node may also recognize addresses with it had meaningful + communication in the past and only send binding updates to, or accept + them from, those addresses. Since it may be impossible for the IP + layer to know about the protocol state in higher protocol layers, a + good measure of the meaningfulness of the past communication 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 to which + traffic has been sent recently. Thus, implementors may wish to use + the information in the Destination Cache. + + Section 11.7.2 ("Correspondent Registration") in [6] does not specify + when such a route optimization procedure should be initiated. It + does indicate when it may justifiable to do so, but these hints are + not enough. This remains an area where more work is needed. + Obviously, given that route optimization is optional, any node that + finds the processing load excessive or unjustified may simply turn it + off (either selectively or completely). + +3.3.2. Forcing Non-Optimized Routing + + As a variant of the previous attack, the attacker can prevent a + correspondent node from using route optimization by filling its + Binding Cache with unnecessary entries so that most entries for real + mobiles are dropped. + + Any successful DoS attack against a mobile or correspondent node can + also prevent the processing of binding updates. We have previously + suggested that the target of a DoS attack may 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 mitigate the effects of the attack by reserving + more space for the Binding Cache, by reverting to non-optimized + routing only when it cannot otherwise cope with the DoS attack, by + + + +Nikander, et al. Informational [Page 20] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + trying aggressively to return to optimized routing, or by favoring + mobiles with which it has an established relationship. This attack + is not as serious as the ones described earlier, but applications + that rely on Route Optimization could still be affected. For + instance, conversational multimedia sessions can suffer drastically + from the additional delays caused by triangle routing. + +3.3.3. Reflection and Amplification + + Attackers sometimes try to hide the source of a packet-flooding + attack by reflecting the traffic from other nodes [1]. That is, + instead of sending the flood of packets directly to the target, the + attacker sends data to other nodes, tricking them to send the same + number, or more, packets to the target. Such reflection can hide the + attacker's address even when ingress filtering prevents source + address spoofing. Reflection is particularly dangerous if the + packets can be reflected multiple times, if they can be sent into a + looping path, or if the nodes can be tricked into sending many more + packets than they receive from the attacker, because such features + can be used to amplify the traffic by a significant factor. When + designing protocols, one should avoid creating services that can be + used for reflection and amplification. + + Triangle routing would easily create opportunities for reflection: a + correspondent node receives packets (e.g., TCP SYN) from the mobile + node and replies to the home address given by the mobile node 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 could + not see the attacker's address (even if ingress filtering prevents + the attacker from spoofing its source address). + + +----------+ TCP SYN with HAO +-----------+ + | Attacker |-------------------->| Reflector | + +----------+ +-----------+ + | + | TCP SYN-ACK to HoA + V + +-----------+ + | Flooding | + | target | + +-----------+ + + Figure 5. Reflection Attack + + A 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 + + + +Nikander, et al. Informational [Page 21] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + 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 Attacks + + Figure 6 gives a summary of the attacks discussed. As it stands at + the time of writing, the return-to-the-home flooding and the + induction of unnecessary binding updates look like the threats + against which we have the least amount of protection, compared to + their severity. + + + + +Nikander, et al. Informational [Page 22] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + +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. + + More minor issues that also surfaced at the time were: (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 + + + +Nikander, et al. Informational [Page 23] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + 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 + + Return Routability (RR) is the name of the basic mechanism deployed + by Mobile IPv6 route optimization security design. RR is based on + the idea that a node should be able to verify that there is a node + that is able to respond to packets sent to a given address. The + check yields false positives if the routing infrastructure is + compromised or if there is an attacker between the verifier and the + address to be verified. With these exceptions, it is assumed that a + successful reply indicates that there is indeed a node at the given + + + + +Nikander, et al. Informational [Page 24] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + address, and that the node is willing to reply to the probes sent to + it. + + The basic return routability mechanism consists of 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 depicted in Figure 7. First, the + mobile node sends two packets to the correspondent node: a Home Test + Init (HoTI) packet is sent through the home agent, and a Care-of Test + Init (CoTI) directly. The correspondent node replies to both of + these independently by sending 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. Finally, once the mobile node has received both the Home + Test and Care-of Test packets, 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 appear that the actual design was somewhat convoluted. That + is, 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 are only needed to + trigger the test packets, and the Binding Update acts as a combined + routability response to both of the tests. + + There are two main reasons behind this design: + + o avoidance of reflection and amplification (see Section 3.3.3), and + + o avoidance of state exhaustion DoS attacks (see Section 4.2). + + The reason for sending two Init packets instead of one is to avoid + amplification. The correspondent node does not know anything about + + + +Nikander, et al. Informational [Page 25] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + the mobile node, and therefore it just receives an unsolicited IP + packet from some arbitrary IP address. In a way, this is similar to + a server receiving a TCP SYN from a previously unknown client. If + the correspondent node were to send two packets in response to an + initial trigger, that would provide the potential for a DoS + amplification effect, as discussed in Section 3.3.3. + + This scheme also avoids providing for a potential reflection attack. + If the correspondent node were to reply to an address other than the + source address of the packet, that would create a reflection effect. + Thus, the only safe mechanism possible for a naive correspondent is + to reply to each received packet with just one packet, and to send + the reply to the source address of the received packet. Hence, two + initial triggers are needed instead of just one. + + Let us now consider the two return routability tests separately. In + the following sections, the derivation of cryptographic material from + each of these is shown in a simplified manner. For the real formulas + and more detail, please refer to [6]. + +4.1.1. Home Address Check + + The Home Address check consists of a Home Test (HoT) packet and a + subsequent Binding Update (BU). It is triggered by the arrival of a + Home Test Init (HoTI). A correspondent node replies to a Home Test + Init by sending a Home Test to the source address of the Home Test + Init. The source address is assumed to be the home address of a + mobile node, and therefore the Home Test is assumed to be tunneled by + the Home Agent to the mobile node. The Home Test contains a + cryptographically generated token, 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, + allowing the correspondent node to find the appropriate nonce more + easily. + + The token allows the correspondent node to make sure that any binding + update received subsequently has been created by a node that has seen + the Home Test packet; see Section 4.2. + + In most cases, the Home Test packet is forwarded over two different + segments of the Internet. It first traverses from the correspondent + node to the Home Agent. On this trip, it is not protected and any + eavesdropper on the path can learn its contents. The Home Agent then + + + +Nikander, et al. Informational [Page 26] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + forwards the packet to the mobile node. This path is taken inside an + IPsec ESP protected tunnel, making it impossible for the outsiders to + learn the contents of the packet. + + At first, it may sound unnecessary to protect the packet between the + home agent and the mobile node, since it travelled unprotected + between the correspondent node and the mobile node. If all links in + the Internet were equally insecure, the additional protection would + be unnecessary. However, in most practical settings 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 should + be close to the correspondent node or on the path between the + correspondent node and the home agent, since it could not 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, making it sometimes trivial to eavesdrop + on its access link. Thus, it is fairly easy to eavesdrop on packets + that arrive at the mobile node. Consequently, protecting the HA-MN + path is likely to provide real security benefits even when the CN-HA + path remains 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 + now the source address of the received Care-of Test Init packet is + assumed to be the care-of address of the mobile node. Furthermore, + the token is created in a slightly different manner in order to make + it impossible to use home tokens for care-of tokens or vice versa. + + care-of keygen token = hash(Kcn | care-of address | nonce | 1) + + The Care-of Test traverses only one leg, directly from the + correspondent node to the mobile node. It remains unprotected all + along the way, making 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 + + When the mobile node has received both the Home Test and Care-of Test + messages, it creates a binding key, Kbm, by computing a hash function + over the concatenation of the tokens received. + + This key is used to protect the first and the subsequent binding + updates, as long as the key remains valid. + + + +Nikander, et al. Informational [Page 27] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + Note that the key Kbm is available to anyone who is able to receive + both the Care-of Test and Home Test messages. However, they are + normally routed by different routes through the network, and the Home + Test is transmitted 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 may remain stateless until it receives the + first Binding Update. That is, it does not 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 take place in parallel but independently of each other. + Thus, the correspondent can respond to each message immediately, and + it does not need to remember doing that. This helps in potential + denial-of-service situations: no memory needs to be reserved for + processing Home Test Init and Care-of Test Init messages. + Furthermore, Home Test Init and Care-of Test Init processing is + designed to be lightweight, and it can be rate limited if necessary. + + When receiving a first binding update, the correspondent node goes + through a rather complicated procedure. The purpose of this + procedure is to ensure that there is indeed 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, and to make + sure that the correspondent node does not unnecessarily spend CPU or + other resources while performing this check. + + Since the correspondent node does not have any state when the binding + update arrives, the binding update itself must contain enough + information so that relevant state can be created. To that end, 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, and together with the other information + they allow the correspondent node to re-create the tokens sent in + the Home Test and Care-of Test messages and used for creating Kbm. + + + +Nikander, et al. Informational [Page 28] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + Without them, the correspondent node might need to try the 2-3 + latest nonces, leading 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 thereby 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 computation of one + MAC and one hash function. + + Once the correspondent node has re-created the tokens, it hashes the + tokens together, giving the key Kbm. If the Binding Update is + authentic, Kbm is cached together with the binding. This key is then + used to verify the MAC that protects 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- + address token), the care-of token expires, or the home token expires. + +4.2.1. Retransmissions and State Machine + + Note that since the correspondent node may remain stateless until it + receives a valid binding update, the mobile node is solely + responsible for retransmissions. That is, 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. Similarly, it may + need to send the binding update a few times in the case it is lost + while 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 when the Home Test and + Care-of Test messages were sent out. It is possible that a specific + attacker is able to eavesdrop a Home Test message at some point of + time, but not later. If the Home Test had an infinite or a long + lifetime, that would allow the attacker to perform a time shifting + attack (see Section 2.2). That is, in the current IPv4 architecture + an attacker on the path between the correspondent node and the home + agent is able to perform attacks only as long as the attacker is able + to eavesdrop (and possibly disrupt) communications on that particular + path. A long living Home Test, and consequently the ability to send + valid binding updates for a long time, would allow the attacker to + continue its attack even after the attacker is no longer able to + eavesdrop on the path. + + + + +Nikander, et al. Informational [Page 29] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + 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 the goals, they are clearly detrimental for + efficiency and robustness. That is, a Home Test Init / Home Test + message pair must be exchanged through the home agent every few + minutes. These messages are unnecessary from a purely functional + point of view, thereby representing overhead. What is worse, though, + is that they make the home agent a single point of failure. That is, + if the Home Test Init / Home Test messages were not needed, the + existing connections from a mobile node to other nodes could continue + 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 of the design were the employment of 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 the limiting of the binding lifetimes to a + few minutes. Next we briefly discuss 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. It should be noted that this section does not present a proper + security analysis of the protocol; it merely discusses a few issues + that were known at the time the design was completed. + + It should be kept in mind that the MIPv6 RO security design was never + intended to be fully secure. Instead, as we stated earlier, 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 as compared with IPv4 are discussed in + Section 5.1. Considerations related to the application of IPsec to + authorize route optimization are discussed in Section 5.2. Section + 5.3 discusses 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. + + + + + +Nikander, et al. Informational [Page 30] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + +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. That is, an attacker that is + able to create a false binding is able to reap the benefits of the + binding as long as the binding lasts. Alternatively, the attacker is + able to delay a return-to-home flooding attack (Section 3.2.2) until + the binding expires. This is different from IPv4, where an attacker + may continue an attack only as long as it is 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 equivalently + restricted. + + Threats possible because of the introduction of route optimization + 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 this would be most likely due to + faulty implementations. As an extreme measure, a correspondent node + can protect against these attacks by turning off route optimization. + If so, it becomes obvious that the only residual attack against which + there is 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 implied the ability to run the protocol without + any existing security infrastructure. An alternative would have been + to rely on existing trust relationships, perhaps in the form of a + special-purpose Public Key Infrastructure in conjunction with IPsec. + That would have limited scalability, making route optimization + available only in environments where it is possible to create + appropriate IPsec security associations between the mobile nodes and + the corresponding nodes. + + There clearly are situations where there exists an appropriate + relationship 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 would be the case. + However, entity authentication or an authenticated session key is not + necessarily sufficient for accepting Binding Updates. + + Home Address Check: If one wants to replace the home address check + with cryptographic credentials, these must carry proper + authorization for the specific home address, and care must be + taken to make sure that the issuer of the certificate is entitled + + + +Nikander, et al. Informational [Page 31] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + to express such authorization. At the time of the design work, + the route optimization security design team was not aware of + standardized certificate formats to do this, although more recent + efforts within the IETF are addressing this issue. Note that + there is plenty of motivation to do so, as 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). Accordingly, the IKE exchange would most naturally + run between the correspondent node and the mobile node's home + address. This 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 the care-of-address check with credentials. Since the + care-of addresses are ephemeral, in general it is very difficult + for a mobile node to present credentials that taken at face value + (by an arbitrary correspondent node) guarantee no misuse for, say, + flooding attacks (Section 3.2). As discussed before, a + reachability check goes a long way to alleviate 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 + protocol exchange runs between the correspondent node and the + mobile node's home address. Hence, another reachability check is + needed to check the care-of address at which the node is currently + reachable. If this address changes, such a reachability test is + likewise necessary, and it is 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 correspondent node. On the other hand, the + specification is carefully written to allow the creation of the + binding management key Kbm through some different means. + Accordingly, where an appropriate relationship exists between a + mobile node and a correspondent node, the use of IPsec is possible, + and is, in fact, being pursued in more recent work. + +5.3. Pretending to Be One's Neighbor + + One possible attack against the security design is to pretend to be a + neighboring node. To launch this attack, 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. Indeed, the care-of address would be the + address of the neighboring node on the local link. The attacker is + + + +Nikander, et al. Informational [Page 32] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + able to create the binding since it receives a valid Home Test + normally, and it is able to eavesdrop on the Care-of Test, as it + appears on the local link. + + This attack would allow the mobile node to divert unwanted traffic + towards the neighboring node, resulting in an flooding attack. + + However, this attack is not very serious in practice. First, it is + limited in the terms of location, since it is only possible against + neighbors. Second, the attack works also against the attacker, since + it 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 exercised in order not to reveal the reverse + tokens 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 at the same link. Such an attacker is able to + learn both the Home Test and Care-of Test sent by the mobile node, + and therefore it is able to spoof the location of the other mobile + host to the neighboring one. What is worse is that the attacker can + obtain a valid Care-of Test itself, combine it with the Home Test, + and then claim to the neighboring node that the other node has just + arrived at the same link. + + There is an easy way to avoid this attack. In the correspondent node + role, the mobile node should tunnel the Home Test messages that it + sends through its home agent. This prevents the co-located attacker + from learning any valid Home Test messages. + +6. Conclusions + + This document discussed the security design rationale for the Mobile + IPv6 Route Optimization. We have tried to describe the dangers + created by Mobile IP Route Optimization, the security goals and + background of the design, and the actual mechanisms employed. + + We started the discussion with a background tour to the IP routing + architecture the definition of the mobility problem. After that, we + covered the avenues of attack: the targets, the time shifting + abilities, and the possible locations of an attacker. We outlined a + number of identified threat scenarios, and discussed how they are + mitigated in the current design. Finally, in Section 4 we gave an + overview of the actual mechanisms employed, and the rational behind + them. + + + +Nikander, et al. Informational [Page 33] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + + As far as we know today, the only significant difference between the + security of an IPv4 Internet and that of an Internet with Mobile IPv6 + (and route optimization) concerns time shifting attacks. + Nevertheless, these are severely restricted in the current design. + + We have also briefly covered some of the known subtleties and + shortcomings, but that discussion cannot be exhaustive. It is quite + probable that new subtle problems will be discovered with the design. + As a consequence, it is most likely that the design needs to be + revised in the light of experience and insight. + +7. Acknowledgements + + We are grateful for: 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. + + + +Nikander, et al. Informational [Page 34] + +RFC 4225 Mobile IPv6 RO Security Design December 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Nikander, et al. Informational [Page 35] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + +Authors' Addresses + + Pekka Nikander + Ericsson Research NomadicLab + JORVAS FIN-02420 + FINLAND + + Phone: +358 9 299 1 + EMail: pekka.nikander@nomadiclab.com + + + Jari Arkko + Ericsson Research NomadicLab + JORVAS FIN-02420 + FINLAND + + EMail: jari.arkko@ericsson.com + + + Tuomas Aura + Microsoft Research Ltd. + Roger Needham Building + 7 JJ Thomson Avenue + Cambridge CB3 0FB + United Kingdom + + EMail: Tuomaura@microsoft.com + + + Gabriel Montenegro + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + USA + + EMail: gabriel_montenegro_2000@yahoo.com + + + Erik Nordmark + Sun Microsystems + 17 Network Circle + Menlo Park, CA 94025 + USA + + EMail: erik.nordmark@sun.com + + + + + + +Nikander, et al. Informational [Page 36] + +RFC 4225 Mobile IPv6 RO Security Design December 2005 + + +Full 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. + + + + + + + +Nikander, et al. Informational [Page 37] + |