Network Working Group J. Arkko Internet-Draft Ericsson Research NomadicLab Expires: April 1, 2005 C. Vogt University of Karlsruhe October 2004 A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization draft-arkko-mip6-ro-enhancements-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 1, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Arkko & Vogt Expires April 1, 2005 [Page 1] Internet-Draft MIP6 Route Optimization Enhancements October 2004 Abstract The Mobile IPv6 mobility-management protocol enables minimum routing paths between a mobile node and a correspondent node, which may itself be mobile. This feature is called route optimization. Route optimization requires authorization of initially unacquainted and untrusted parties. A so-called return-routability procedure was integrated into the Mobile IPv6 in order to do this securely. The return-routability procedure equips the mobile node with cryptographic tokens that authenticate the mobile node and prove the mobile node's presence at a claimed new location after movement. Recently, a number of improvements or optional alternatives have been suggested to the standard procedure. The primary driver between these improvements is oftentimes further reduction of signaling messages and latency, but other improvements such as better security have also been suggested. This document discusses the potential goals for future enhancements of route optimization, the security threats that such enhancements must consider, and the various enhancement proposals and their key ideas. An evaluation of some recent proposals is included, as well as a discussion of how significant the Mobile IPv6 related optimizations are related to other ongoing optimization efforts. Finally, needs for future research are outlined. Arkko & Vogt Expires April 1, 2005 [Page 2] Internet-Draft MIP6 Route Optimization Enhancements October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Mobility-Related Security Threats . . . . . . . . . . . . . 6 2.1 Impersonation Attacks . . . . . . . . . . . . . . . . . . 6 2.2 Resource-Exhaustion Attacks . . . . . . . . . . . . . . . 7 2.3 Flooding Attacks . . . . . . . . . . . . . . . . . . . . . 8 3. Mobile IPv6 Route Optimization . . . . . . . . . . . . . . . 9 3.1 Goals and Assumptions . . . . . . . . . . . . . . . . . . 10 3.2 Return Routability Procedure . . . . . . . . . . . . . . . 11 3.3 Security Analysis . . . . . . . . . . . . . . . . . . . . 16 4. Objectives for Enhancement . . . . . . . . . . . . . . . . . 17 4.1 Latency Optimizations . . . . . . . . . . . . . . . . . . 17 4.2 Signaling Optimizations . . . . . . . . . . . . . . . . . 18 4.3 Security Enhancements . . . . . . . . . . . . . . . . . . 19 4.4 Applicability Enhancements . . . . . . . . . . . . . . . . 20 5. The Toolbox . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1 Address Tests . . . . . . . . . . . . . . . . . . . . . . 21 5.2 Protected Tunnels . . . . . . . . . . . . . . . . . . . . 21 5.3 Optimistic Behaviour . . . . . . . . . . . . . . . . . . . 22 5.4 Proactive Tests . . . . . . . . . . . . . . . . . . . . . 22 5.5 Concurrent Tests . . . . . . . . . . . . . . . . . . . . . 23 5.6 Diverted Routing . . . . . . . . . . . . . . . . . . . . . 24 5.7 Credit-Based Authorization . . . . . . . . . . . . . . . . 25 5.8 Heuristic Monitoring . . . . . . . . . . . . . . . . . . . 26 5.9 Cryptographically Generated Addresses . . . . . . . . . . 27 5.10 Semi-Permanent Security Associations . . . . . . . . . . 28 5.11 Pre-Configuration . . . . . . . . . . . . . . . . . . . 29 5.12 Infrastructure . . . . . . . . . . . . . . . . . . . . . 29 5.13 Cryptographically Bound Identifiers . . . . . . . . . . 30 5.14 Local Mobility . . . . . . . . . . . . . . . . . . . . . 30 5.15 Local Repair . . . . . . . . . . . . . . . . . . . . . . 31 5.16 Processing Improvements . . . . . . . . . . . . . . . . 32 5.17 Delegation . . . . . . . . . . . . . . . . . . . . . . . 33 6. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.1 Categorization of Techniques . . . . . . . . . . . . . . . 33 6.2 Evaluation of Some Proposals . . . . . . . . . . . . . . . 34 6.3 Further Research . . . . . . . . . . . . . . . . . . . . . 42 7. Security Considerations . . . . . . . . . . . . . . . . . . 44 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 44 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 50 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 Intellectual Property and Copyright Statements . . . . . . . 51 Arkko & Vogt Expires April 1, 2005 [Page 3] Internet-Draft MIP6 Route Optimization Enhancements October 2004 1. Introduction Traditionally, an IP address combines identification and location semantics. The address prefix locates a node's point of network attachment. It is used by routers to forward IP packets towards the correct destination. At the same time, existing transport protocols and applications, commonly termed "upper layers", use the IP address as part of a session identification. This naturally rules out mobility: Whenever a mobile node moves from one access network to another, its IP address must change to reflect the new location. The new "identity", however, causes sessions at upper layers to abort. Protocol designers thus had to decide whether to change transport protocols and applications, or to come up with a new IP-layer protocol that could separate location from identification functionality. Due to the prevalence of TCP and the significant base of existing applications, most people opted for the latter approach. Mobile IPv6 [15], its IPv4 counterpart [25], and the Host Identity Protocol [22] are three dominant mobility-management protocols that the IETF has developed to facilitate the continued use of existing transport protocols and applications in an Internet with mobility support. This document focuses on Mobile IPv6. Mobile IPv6 uses two IP addresses per mobile node in an attempt to separate location semantics from identification semantics: a transient "care-of address" is used for the purpose of routing. It is reconfigured whenever the mobile node moves to a new access network. A static "home address" is configured with the network prefix from a non-mobile "home agent's" network. The home address doesn't change when the mobile node moves, and it can be used for session identification at upper layers. The home address also serves as a node identifier for Mobile IPv6 itself. In the Mobile IPv6 base mode, "bidirectional tunneling", the home agent intercepts packets addressed to the mobile node's home address, and it tunnels those packets to the mobile node's current care-of address. After decapsulation at the mobile node, these packets bear the mobile node's home address and are as such accepted at upper layers. In the opposite direction, transport protocols and applications at the mobile node generate packets with the home address in the IPv6 Source Address field. The mobile node tunnels these packets to the home agent who, in turn, decapsulates them and forwards them on to the final recipient. Bidirectional tunneling through the home agent provides for location privacy, as a communication peer never sees the mobile node's care-of address. It is also a very safe approach to mobility, because all signaling between the mobile node and the home agent can easily be protected by means of a pre-established security association and Arkko & Vogt Expires April 1, 2005 [Page 4] Internet-Draft MIP6 Route Optimization Enhancements October 2004 trust relationship. Last, but not least, the beauty of bidirectional tunneling is that it does not require support from a mobile node's correspondent peer. On the other hand, middle-box-style approaches like bidirectional tunneling loose attractiveness due to the additional overhead that a growing population of mobile nodes can pose on the Internet. A home agent can also be a single point of failure or a performance bottleneck. This leads to the concept of "route optimization". With Mobile IPv6 route optimization, packets can be directly relayed between a mobile node and its correspondent node. The mobile node keeps the correspondent node up to date about its current care-of address. When a route-optimized packets is received from the network, either at the mobile node or at the correspondent node, the Mobile IPv6 implementation replaces the care-of address in the packet's IPv6 header by the mobile node's home address before the packet is handed to the upper layer. Vice versa, when a packet is received from the upper layer, the Mobile IPv6 implementation replaces the home address in the packet's IPv6 header by the mobile node's current care-of address before the packet is injected into the network. The need for routing efficiency was deemed important enough to outweigh a number of disadvantages that come along with route optimization. First of all, different than bidirectional tunneling, route optimization requires mobility support from the correspondent node. Also, route optimization reveals the mobile node's current care-of address to the correspondent node, and thus makes the mobile node tracable. Route optimization should therefore not be used when location privacy is an issue. Last, but not least, route optimization would impose significant security threats if it was not accompanied by a new security protocol: Although one can generally neither presuppose a security association nor a trust relationship between a mobile node and its communication peer, a correspondent node should be able to verify the origin, the integrity, and the validity of all received registration messages. Indeed, a mobile node must authorize its requests to the correspondent node, protect a registration message against tampering, and prove to the correspondent node that it is indeed reachable through the to-be-registered care-of address. Such protection is necessary to prevent impersonation and denial-of-service attacks [23]. As part of the registration procedure, a correspondent node probes a mobile node's home address to verify the mobile node's identity. It also probes the mobile node's care-of address to gain assurance that the mobile node is reachable at this address. The two address tests are combined in the so-called "return-routability procedure". The return-routability procedure is to be executed for each Arkko & Vogt Expires April 1, 2005 [Page 5] Internet-Draft MIP6 Route Optimization Enhancements October 2004 care-of-address update, or periodically in case the mobile node does not move for a while. This can lead to a handover delay unacceptable for many real-time or interactive applications like Voice over IP (VoIP) and audio or video streaming. Moreover, the periodic repetitions imply a hidden signaling overhead that may interfere with mobile nodes who intend to sleep during times of inactivity. Finally, the return-routability procedure uses "weak authentication" to bind a home address to the legitimate owner. It limits vulnerabilities to attackers that are on the path from the correspondent node to the mobile node or to the home agent. The residual vulnerabilities are similar to those that exist anyway in today's non-mobile Internet. But still, mechanisms that use strong authentication of IP addresses can provide a higher level of security than the return-routability procedure does. This document describes and classifies possible enhancements to the return-routability procedure. Following this introduction, section Section 2 shows which new security threats arise in an Internet with mobility support. Section 3 explains the care-of-address registration protocol as defined in RFC 3775 [15], including the return-routability procedure. A number of potential goals for enhancements (such as reducing latency) are discussed in Section 4. Known optimization techniques are discussed in Section 5. Section 6 discusses how these techniques are used by existing optimization proposals, evaluates some of these proposals, and proposes some further work. 2. Mobility-Related Security Threats Mobile IPv6 allows a node to redirect those packets, that a correspondent node would otherwise send to one IP address (the home address), to a second IP address (the care-of address). But the ability for redirection could also be misused by a malicious node for an arbitrary pair of IP addresses if no appropriate precautions were taken. Overall, there are three major families of mobility-related threats: impersonation attacks, resource-exhaustion attacks, and flooding attacks. The following subsections take a closer look at each of the categories. Threats are described in the light of Mobile IPv6, but some of them apply to other mobility-management protocols as well. 2.1 Impersonation Attacks The probably most obvious issue with mobility is how one can ensure that only a mobile node itself has the ability to change its care-of address. If care-of-address registrations were unauthenticated, an attacker could easily impersonate an arbitrary victim. For instance, Arkko & Vogt Expires April 1, 2005 [Page 6] Internet-Draft MIP6 Route Optimization Enhancements October 2004 the attacker could contact the victim's correspondent node and register its own IP address on behalf of its victim. The correspondent node would assume that the victim's care-of address has changed, and it would redirect all packets intended for the victim to the attacker instead. The attacker could forward the packets to the victim after analyzing, or even tampering with, their payloads. In a related offense, the perpetrator could simply cause havoc at its victim by directing the victim's packets to a random or non-existent IP address. These attacks are jointly referred to as "impersonation attacks". Impersonation attacks can be prevented through proper authentication techniques that keep an outsider from assuming another node's identity. It is important to recognize that impersonation attacks not only impact those nodes that have an interest in mobility. Although the attacker makes the correspondent node believe that the victim is mobile, neither the attacker nor the victim do have to be mobile. Indeed, mobile nodes, non-moving nodes with mobility support, as well as traditional stationary nodes are potentially endangered because they all share the same IPv6 identifier namespace. (Actually, even IPv4 nodes are jeopardized when IPv4-to-IPv6 translation occurs on the path between these nodes and their correspondent peers.) This unfolds the need for mandatory protection of mobility-related signaling in order to safeguard the Internet community as a whole. Beyond their large group of potential victims, mobility-related impersonation attacks allow an attacker to choose the location from where to wage its attack. For example, the impersonator could position itself at a place where it is easier to inject spoofed care-of-address registration packets into the network than anywhere on the direct path between the victims. The attacker may also move to a place where it can remain unrecognized. In contrast to this, in the non-mobile Internet that we have today, an attacker can only listen to or tamper with packets while it is on the path between its victims. Similarly, a mobility-management protocol may give the attacker the possibility to shift the time for its attack. The attacker might be able to register false care-of addresses even before its victims' conversation begins, or attack a network long after it has visited it. In the non-mobile Internet, an attacker must strike at the same time as its victims communicate. The ability to choose the location and time for an attack constitutes a dangerous new degree of freedom for the attacker. 2.2 Resource-Exhaustion Attacks Mobility support at correspondent nodes can become an issue if it takes a lot of processing capacity to handle an incoming care-of-address registration. During times of increased signaling Arkko & Vogt Expires April 1, 2005 [Page 7] Internet-Draft MIP6 Route Optimization Enhancements October 2004 load, a correspondent node may thus end up having to commit a significant fraction of its resources to mobility-related transactions. What is worse, an attacker may take advantage of this vulnerability. It could swamp the correspondent node with large quantities of bogus registrations messages, keeping it from doing useful work. Such denial-of-service attempts are called "resource-exhaustion attacks". Clearly, if mobility support is to be implemented on a large basis, handling care-of-address registrations must be lightweight in order to lessen the susceptibility to resource exhaustion. Another effective technique is to defer resource commitment until late in the registration process: Once the registrant has proven its identity or shown that it is willing to invest resources itself, it is less likely malicious. As a last resort, busy Internet servers should limit the resources they devote to registration processing, and they may give preference to those mobile nodes they know or have recently had meaningful communications with. It is worthwhile to stress the trade-off between effectiveness of signaling authentication and resilience against increased signaling load. On one hand, a strong authentication mechanism can effectively prevent certain impersonation attacks. On the other hand, the resources a correspondent node must spend on the verification of a registering node's authenticity increases with the complexity of the authentication algorithm. The susceptibility to resource exhaustion thus grows with the level of protection against impersonation attacks. 2.3 Flooding Attacks A third mobility-related security threat emanates from redirection-based flooding attacks. Redirection-based flooding attacks are characterized by a victim being bombarded with unwanted packets at a rate that the victim, and possibly the victim's access network, cannot handle. As with impersonation attacks, it is important to compare existing flooding attacks in today's non-mobile Internet with redirection-based flooding attacks that could be made possible through an insecure mobility-management protocol. Three types of flooding attacks can be identified in today's Internet. The simplest one is a "direct flooding attack". Here, the attacker itself sends bogus packets to the victim. In an indirect "reflection attack", the attacker tricks a third node, the "reflection point", to send the packets. It typically uses a known protocol vulnerability to make the reflection point generate these packets [24]. For example, the attacker may send spoofed ICMP Echo Request packets to the reflection point, using its victim's IP address in the packets' IPv6 Source Address field. For each such Arkko & Vogt Expires April 1, 2005 [Page 8] Internet-Draft MIP6 Route Optimization Enhancements October 2004 request, the reflection point generates an ICMP Echo Reply message, which it sends "back" to the victim. The advantage of a reflection attack over a direct flooding attack is that the attacker is usually harder to track when flooding traffic comes from a third node. Another example for a reflection attack is TCP-SYN flooding. Here, the attacker sends TCP SYN packets, again with false source addresses, to the reflection point, which in turn sends TCP SYN-ACK packets to someone who does not expect these packets. Since most TCP servers are configured so that they re-send a TCP SYN packet multiple times when failing to receive an acknowledgement, this reflection attack can even produce a small amplification. Gaining higher amplification in today's Internet necessitates more complex strategies like "distributed flooding attacks". In a distributed flooding attack, the attacker typically gains control over other nodes by spreading viral software. Then, at a certain point of time, infected nodes simultaneously commence a joint flooding attack against a common victim. The introduction of mobility support renders amplified flooding attacks much less complex. Suppose a mobile node is allowed to change its care-of address without having to evidence that it is present at the new care-of address. Then, an attacker can subscribe, through its own IP address, to a large data flow (e.g., a video stream) offered by some server on the Internet. The attacker can easily accomplish the initial handshake procedure with the server while it uses its own IP address. Once data is flowing, the attacker can redirect the flow to the IP address of an arbitrary victim. The attacker can use the sequence numbers learned during the initial handshake procedure in order to spoof acknowledgements for packets that it assumes the server has sent to the victim. In this attack, not the attacker, but a faithful server on the Internet can be made generate packets used for an attack. The server does not have to be infected with compromised code, and neither the victim nor the server has to be mobile. The attacker produces as little as spoofed feedback information to keep the data flow alive. To make matters worse, the attacker can redirect data flows from multiple servers to the victim. Support for Mobile IPv6 route optimization is recommended to all IPv6 nodes [19]. The base of correspondent nodes that an attacker could exploit for a redirection-based flooding attack would therefore be immense. Also note that no distribution of viral software would be necessary. The severity of this new type of flooding is that it would provide potentially unbounded amplification at comparably low cost. 3. Mobile IPv6 Route Optimization The potential for new security threats necessitates the protection of mobility-related signaling in Mobile IPv6. The development of an Arkko & Vogt Expires April 1, 2005 [Page 9] Internet-Draft MIP6 Route Optimization Enhancements October 2004 appropriate security design, however, is a challenge: Nodes that never met before must find a way to authenticate themselves, preferably without the need for a global PKI. Also, a trade-off between cryptographic complexity and resilience to resource exhaustion must be found. This section explains the security design for Mobile IPv6 route optimization in the light of the goals and assumptions based on which it was built. 3.1 Goals and Assumptions An important objective for the development of Mobile IPv6 was to provide for a wide, preferably universal, support for route optimization. In fact, support for Mobile IPv6 and, thus, route optimization is recommended in the requirements suite for IPv6 nodes [19]. It was, and still is, believed that the additional routing overhead associated with bidirectional tunneling is too much of a burden on the core Internet given that the number of connected mobile nodes is expected to grow substantially within the next years. The aspiration for wide-scale deployment of route optimization has an impact on how correspondent nodes can authenticate mobile nodes. Authentication can be performed based on a preconfigured shared secret or through a trusted public-key infrastructure (PKI). Unfortunately, both approaches turn out to be impractical for route optimization. Preconfiguration is not an option because there is usually no pre-existing relationship between communicating nodes. A PKI could assist unacquainted nodes in the authentication process. But a PKI for Mobile IPv6 would have to be able to authenticate all mobile nodes on the Internet. It is generally believed that no such PKIs can be constructed. More seriously, a PKI that simply authenticates users would not suffice to prevent mobility related attacks. It would be necessary to have authorization of specific IP addresses. This seems hard even for home addresses, as IP address assignment is usually handled by other network entities than the PKI nodes. Moreover, authorization of care-of addresses would be infeasible, as these addresses change all the time. The global PKI would also constitute an attractive target for attacks, endangering the Internet as a whole. Due to these difficulties, the concept of "weak authentication" was elaborated for the use between nodes that have no a-priori relationship. The intent was to make an Internet with mobility support as secure as the non-mobile Internet is today. Arkko & Vogt Expires April 1, 2005 [Page 10] Internet-Draft MIP6 Route Optimization Enhancements October 2004 It is important to recognize that some mobility-related attacks can be prevented through authentication/authorization of the used IP addresses, while others cannot. Impersonation attacks belong the the former class. Protection against resource-exhaustion attacks requires that the protocol is of low complexity, or delays state creation and computation in an appropriate manner until peer has shown its credentials. On the other hand, redirection-based flooding attacks are based on care-of-address spoofing. Mandatory authentication may lessen the attractiveness of such flooding, but certainly cannot prevent it. Care-of-address validity must therefore be ensured through different means. One option is to enforce proper use of care-of addresses already at the mobile node's point of network attachment. The correspondent node may then simply believe in the validity of a care-of address without doing any verification itself. Many access networks today provide this service through ingress filtering [11]. However, the crux with verifying a care-of address at the fringe of the Internet is that an attacker can choose the location from where to wage a flooding attack. As long as there are access networks where ingress filtering, or an equivalent technique, is not deployed, an attacker can always avoid care-of-address verification. Mobile IPv6 hence does not rely on ingress filtering. Another way to protect against care-of-address spoofing is to have a correspondent node probe a mobile node's new care-of address before it sends packet there. This verification strategy operates end to end, and it is independent of support from the access network. Mobile IPv6 uses care-of address probing during the return-routability procedure. It should be mentioned that care-of-address verification can be omitted in scenarios where the correspondent node has confidence in the mobile node's honesty. In fact, Mobile IPv6 assumes a trust relationship between mobile nodes and their respective home agents. It is believed that the mandatory security association between mobile nodes and home agents implicates the trust. This is certainly a feasible hypothesis in many cases, but one ought to bear that, in some scenarios, it may be not. If the home registration process had a care-of address verification, the extension of Mobile IPv6 for bootstrapping solutions would be easier [29]. 3.2 Return Routability Procedure The security design for Mobile IPv6 route optimization is shaped from the assumptions outlined in the preceding section. At the heart of a correspondent registration is the return-routability procedure, a protocol for weak authentication and end-to-end care-of-address Arkko & Vogt Expires April 1, 2005 [Page 11] Internet-Draft MIP6 Route Optimization Enhancements October 2004 verification [15]. This section gives a nutshell view on the standard Mobile IPv6 correspondent registration. A correspondent registration has two phases: First, the return-routability procedure is executed, then the registration proper is accomplished. Mobile Node Home Agent Correspondent Node | | | | 1. Binding Update (BU) | | |------------------------->| | | | | | 2. Binding Ack (BA) | | |<-------------------------| | | | | | 3a. Home Test Init (HoTI)| | |------------------------->|------------------------->| | | | 3b. Care-of Test Init (CoTI) | |---------------------------------------------------->| | | | | 4a.Home Test (HoT) | |<-------------------------|<-------------------------| | | | | 4b.Care-of Test (CoT) | |<----------------------------------------------------| | | | 5. Binding Update (BU) | |-----------------------------------------------------| | | | 6. Binding Ack (BA) | |<----------------------------------------------------| | | Note 1: Waiting for the Binding Acknowledgement from the home agent may proceed in parallel with the rest of the process. Note 2: The home and care-of tests can be done in parallel. That is, the Home Test Init and Care-of Test Init messages can be sent one after another, and the process completes when a response has been received to both. Note 3: Acknowledgements are optional (but often desirable). Figure 1. Correspondent registration process. Arkko & Vogt Expires April 1, 2005 [Page 12] Internet-Draft MIP6 Route Optimization Enhancements October 2004 Figure 1: Mobile IPv6 Correspondent Registration When the mobile node detects that it has moved to a different access network, it configures an IP address with the prefix of the new network. The mobile node registers this IP address as its new care-of address with the home agent (home registration) and with each correspondent node capable of supporting route optimization (correspondent registration). The correspondent registration includes a return-routability procedure for authentication and care-of-address verification purposes. Figure Figure 1 depicts the overall process. The home and correspondent registrations may be interleaved as the mobile node can already initiate the correspondent registration while the home registration is still in progress. Messages (1) and (2) comprise the home registration; messages (3a) to (6) make up the correspondent registration. In the latter, messages (3a), (3b), (4a), and (4b) constitute the return-routability procedure. The following is a more detailed description of the registration process. When the mobile node has configured a care-of address after movement, it sends to its home agent a Binding Update message (1). The Binding Update message informs the home agent about the mobile node's new care-of address. The new care-of address is in the packet's IPv6 source address, the home address is placed into the IPv6 destination-options extension header. The Binding Update message is authenticated, and optionally encrypted, by means of an IPsec security association between the mobile node and the home agent. When the home agent receives the Binding Update message, it can determine the appropriate IPsec security association based on the mobile node's home address. Provided that the message is properly authenticated, the home agent registers the mobile node's new care-of address. In case the home agent maintains an IPsec tunnel for packets routed through the home network, it also updates the corresponding security association to the new care-of address [6]. The home agent sends back to the mobile node a Binding Acknowledgement message (2) to indicate successful care-of-address registration. Like the Binding Update message, the Binding Acknowledgement message is authenticated, and possibly encrypted, through IPsec. Once the home registration is complete, the mobile node initiates the correspondent registration. (In case the mobile nodes communicates with multiple correspondent nodes, it can register with all of them in parallel.) The mobile node sends to the correspondent node two messages in parallel: a Home Test Init message and a Care-of Test Init message. The Home Test Init message (3a) is tunneled to the mobile node's home agent, and forwarded on to the correspondent node. The Home Test Init message includes a random Home Init Cookie, which Arkko & Vogt Expires April 1, 2005 [Page 13] Internet-Draft MIP6 Route Optimization Enhancements October 2004 the correspondent node will return in its Home Test message. This gives the mobile node reasonable assurance that the Home Test message was sent by the correspondent node itself rather than a hidden attacker impersonating the correspondent node. In fact, the returned cookie can only guarantee that the Home Test message was generated by some node on the path from the mobile node via the home agent to the correspondent node. The Home Test Init message and the Home Test message may (and should) be protected through IPsec on the path between the mobile node and the home agent, but they are unprotected on the path between the home agent and the correspondent node. On the latter path, a malicious node may thus eavesdrop on the Home Init Cookie and return it in a spoofed Home Test message. The Care-of Test Init message (3b) does not go through the mobile node's home agent. It takes the direct path to the correspondent node. Again, the Care-of Test Init message includes a random cookie, the Care-of Init Cookie, to be returned by the correspondent node in the Care-of Test message. Both the Care-of Test Init and the Care-of Test messages cannot be protected by IPsec in the general case, since there is usually no security association between the mobile node and the correspondent node. For this reason, the cookie mechanism can only restrict the sender of the Care-of Test message to the direct path between the mobile node and the correspondent node. Still, the mobile node considers this a sufficient proof that the Care-of Test message was generated by the correspondent node itself. In the above, the return-routability procedure was generated after the home registration was complete. This is not necessarily so. The mobile node may reduce the registration latency by sending messages (1), (3a), and (4b) simultaneously. When the correspondent node receives the Home Test Init message, it sends back to the mobile node a Home Test message (4a). The Home Test message is directed to the mobile node's home address, hence passes the mobile node's home agent. The Home Test message contains a Home Keygen Token, a Home Nonce Index, and the Home Init Cookie copied from the Home Test Init message. The mobile node needs the Home Keygen Token to authenticate the Binding Update message, as described below. The Home Nonce Index identifies a random value based on which the correspondent node has computed the Home Keygen Token. The mobile node will include the Home Nonce Index in the subsequent Binding Update message to allow the correspondent node to reproduce the Home Keygen Token without having to explicitly store it. Likewise, upon receiving the Care-of Test Init message, the correspondent node sends back to the mobile node a Care-of Test message (4b). The Care-of Test message is directed to the mobile node's new care-of address, hence does not pass the mobile node's Arkko & Vogt Expires April 1, 2005 [Page 14] Internet-Draft MIP6 Route Optimization Enhancements October 2004 home agent. Similar to the Home Test message, the Care-of Test message contains a Care-of Keygen Token, a Care-of Nonce Index, and the Care-of Init Cookie copied from the Care-of Test Init message. The mobile node needs the Care-of Keygen Token for the Binding Update message in order to prove its reachability at the new care-of address. This is described below. When returned in the Binding Update message, the Care-of Nonce Index allows the correspondent node to reproduce the Care-of Keygen Token without having to store it. The mobile node then sends a Binding Update message (5) to the correspondent node. The Binding Update message contains a message-authentication code produced on the basis of the Home and the Care-of Keygen Tokens. It also contains the Home Nonce Index and the Care-of Nonce Index. The mobile node may request the correspondent node to return a Binding Acknowledgement message by raising the A-flag in the Binding Update message. When the correspondent node receives the Binding Update message, it can reproduce the Home Keygen Token and the Care-of Keygen Token with the help of the two nonce indices. The tokens, in turn, allow the correspondent node to verify the message-authentication code. If the message-authentication code is ok, the correspondent node can assume two things. First, the mobile node must have received the Home Keygen Token. Hence, the mobile node is the legitimate owner of the home address with high probability, since the Home Keygen Token was sent, as part of the Home Test message, to the mobile node's home address. Second, the mobile node must have received the Care-of Keygen Token. Therefore, the mobile node is apparently reachable through the new care-of address, since the Care-of Keygen Token was sent, as part of the Care-of Test message, to the mobile node's care-of address. Beyond this, the message-authentication code validates the Binding Update message's integrity. Provided that the verification of the message-authentication code succeeds, the correspondent node creates a binding-cache entry with the mobile node's new care-of address. The correspondent node uses the mobile node's new care-of address as soon as the binding-cache entry is in place. In case the A-flag in the Binding Update message is set, the correspondent node sends back to the mobile node a Binding Acknowledgement message (6) to indicate a successful care-of-address update. Both home and the correspondent registrations are valid for limited time only. For security reasons, these lifetimes are limited for correspondent nodes. If, after seven minutes, the mobile node did not move, it must refresh the existing registration with its correspondent nodes. Arkko & Vogt Expires April 1, 2005 [Page 15] Internet-Draft MIP6 Route Optimization Enhancements October 2004 3.3 Security Analysis To analyse the security of the return-routability procedure, one should evaluate its protection against the tree types of attacks described in section Section 2: impersonation attacks against a mobile node, resource-exhaustion attacks against mobile nodes or correspondent nodes, and flooding attacks against third parties. Mobile IPv6 uses the home address as an identifier for a mobile node. Impersonation attacks are thus based on claiming ownership of another node's IP address. The return-routability procedure can prevent such attacks unless the attacker is on the path from the correspondent node to the victim (in the case of a stationary victim) or from the correspondent node to the victim's home agent (if the victim is mobile). However, if an attacker happens to be on the critical path, it can spoof a Home Test Init message on behalf of the victim, eavesdrop on the returning Home Test message, and thus illegitimately acquire a Home Keygen Token. The impersonator can produce its own Care-of Keygen Token by sending the victim's correspondent peer a Care-of Test Init message with a care-of address the impersonator itself is reachable through. Both tokens allow the attacker to send an authenticated Binding Update message on behalf of the victim. The described susceptibility to attacks from the routing path between two communicating nodes conforms with the design objective to make the security of a mobile Internet as secure as the current, non-mobile Internet. After all, an on-path attacker can compromise the communications of two nodes already today. It can block communications, or it can interfere by ingesting its own packets. The similarity between the home-address test and the care-of-address test belies the different purpose of these exchanges. While the former is to prevent impersonation attacks, the latter tackles the problem of flooding attacks by probing a mobile node's presence at a new care-of address. As with the home-address test, there are scenarios where the care-of-address test takes no effect. Namely, it cannot protect against attackers that are on the path between the victim and the correspondent node at which traffic is to be redirected. In this scenario, the attacker can perform a care-of-address test on behalf of the victim further down the path. Again, the exposure to on-path attacks corresponds to the objectives of the Mobile IPv6 security design. Flooding attacks initiated by an on-path attacker are already a threat in the non-mobile Internet: An on-path attacker could initiate, say, a large file download from an FTP server on behalf of a victim if the attacker is on the path from the FTP server to the victim. In this case, the attacker would probably do a TCP handshake using the victim's IP address. As it is Arkko & Vogt Expires April 1, 2005 [Page 16] Internet-Draft MIP6 Route Optimization Enhancements October 2004 on path, the attacker could hear the messages from the FTP server, and it could respond to them. The attacker would so learn the TCP Initial Sequence Number, which it needs to later spoof acknowledgements on behalf of its victim. These things considered, the care-of-address test inherent in the return-routability procedure limits flooding attacks to exactly those situations in which comparable flooding attacks are already possible today. Yet, the limitation to on-path attacks alone is insufficient to prevent a related style of attack that is called "space- and time-shift attacks". In these attacks, the perpetrator taps the critical wire in order to obtain the secret information it needs, and it then moves to a saver place and starts an attack from there. The attacker could also wait for a better point of time. It may even install a binding on behalf of a victim before the victim starts communicating. Mobile IPv6 requires mobile nodes to refresh active care-of-address registrations in intervals of at most seven minutes in an attempt to mitigate the threat of space- and time-shift attacks. The return-routability procedure is such that the correspondent node does not need to explicitly store the Home or Care-of Keygen Tokens sent to a mobile node. Given the index of a random nonce that was used to create a token, the correspondent node can recalculate the token. This saves the correspondent node from attacks against its memory. On the other hand, it may open the door for attacks against the correspondent node's processing capacity. A token is a SHA-1 hash on the mobile node's care-of or home address, the correspondent node's address, a random nonce, and a secret known only to the correspondent node. The related processing overhead is hence rather moderate, although a correspondent node should implement its own policies to manage resources in a situation of increased processing workload. 4. Objectives for Enhancement This section discusses the objectives for enhanced or alternative designs for route optimization. We discuss the objectives from a requirements perspective, such as the need for decreasing latency. The technical means to reach those objectives is not considered here, nor is the feasibility of achieving them. 4.1 Latency Optimizations A disadvantage of the return-routability procedure is that a mobile node must wait for both address tests to complete before it can register a new care-of address. Therefore, a correspondent registration consumes, at a minimum, one and a half round-trip times Arkko & Vogt Expires April 1, 2005 [Page 17] Internet-Draft MIP6 Route Optimization Enhancements October 2004 between a mobile node and its correspondent node, counting the parallel address tests and the transfer of the Binding Update message. An additional one-way time elapses until the first packet from the correspondent node arrives at the new care-of address. Note that two different paths are employed: the direct path between the mobile node and the correspondent node, and the path via the home agent. The actual latency is governed by the path with a longer round-trip time. Direct communications to the correspondent node can optimistically start right after the Binding Update message has been sent (i.e., after one round-trip time), but more generally are delayed until the Binding Acknowledgement message is received (i.e., after two round-trip times). Similarly, optimistic mobile nodes are allowed by RFC 3775 to start their return-routability procedure right after sending a Binding Update message to their home agent. They can so reduce the latency for the correspondent registration. But more generally, mobile nodes wait for the home registration to be completed and acknowledged before continuing with the correspondent registration. Depending on the type of application, the above delays can be an issue. For instance, this can be a problem in real-time voice-over-IP applications. Even fast bulk-data transfer can be affected if the lack of packets during the movement period is interpreted as congestion, leading to a new TCP slow start. There appears to be general consensus that faster mechanisms for route optimization are needed. Note that delays introduced by the rest of the stack can be significant as well (see Section 6.3.1). The sum of the delays from the link layer, IP layer, and IP mobility mechanisms must not exceed the requirements of the application. 4.2 Signaling Optimizations As stated in Section 3, one objective of the return-routability procedure is to prevent time-shift attacks. Time-shift attacks are prepared on the path between the victim and its correspondent node, but launched at a later time and from a different, probably more amenable location. Since authentication material is exchanged in unencrypted form during the return-routability procedure, an on-path eavesdropper can get hold of it. Mobile IPv6 requires that authentication material have limited lifetime in an attempt to prevent the eavesdropper from taking the stolen information to a different position. Registrations must be refreshed at least every seven minutes, even in the absent of handovers. Such periodic Arkko & Vogt Expires April 1, 2005 [Page 18] Internet-Draft MIP6 Route Optimization Enhancements October 2004 re-registrations limit the likelihood and feasibility of off-path attacks. After all, if a malicious node overheard authentication material on path and moved off path to launch the attack, it would have to get back on path when the authentication material is due to be refreshed. [5] shows that the seven-minute refreshment interval implies a signaling overhead of 7.16 bps [5] when one mobile node communicates with a stationary node. If both peers are mobile, the signaling overhead doubles. For two communicating nodes, this signaling overhead is certainly negligible. On the other hand, the accumulated overhead generated by a network provider's customer base can grow an issue. As an example, consider a mobile-phone provider that offers some sort of event-driven messenger service for its customers. For instant message delivery and reduced load on the core network, the provider may prescribe the use of route optimization. (Note that, with bi-directional tunneling, messages for all subscribers would have to be relayed through a home agent. This could drastically the increase network load.) On the other hand, even route optimization requires a home agent. For example, of the 716 Mbps signaling overhead generated by 100 million route-optimized mobile nodes, 220 Mbps goes through the home agent. The signaling may also be an issue for mobile nodes that are inactive and stay at the same location for a while. Usually, these nodes have limited energy supply and prefer to go to standby mode when no transmissions are needed. Route optimization, however, would require them to continually wake up and re-register. This shows that an optimization for reduced signaling could be beneficial. 4.3 Security Enhancements In the current Internet, nodes can, and typically will, communicate even though they do not have a pre-existing relationship. This is usually not an issue, because most data exchanged on the Internet is non-confidential. On the other hand, recall from Section 2 that mobility does require authentication also for non-confidential communications, because mobility-related attacks may otherwise compromise the Internet community as a whole. The standard return-routability procedure takes a zero-configuration approach. This is lightway and prevents mobility-related attacks reasonably well. On the other hand, better security would be useful, particularly to limit what on-path attackers (including the nodes in the same network as the endpoints) can do. There are existing proposals that offer higher security in Mobile IPv6 [32] and in other protocols such as HIP [27]. Arkko & Vogt Expires April 1, 2005 [Page 19] Internet-Draft MIP6 Route Optimization Enhancements October 2004 However, even with better security for mobility management, the Internet as a whole cannot get any safer than the non-mobile Internet. For instance, even with plain IPv6 can on-path attackers cause denial of service, or inspect and modify cleartext packets. Communications that are encrypted end-to-end are vulnerable only to denial of service. So, applications that require strong security are generally advised to end-to-end mechanisms such as IPsec or TLS. However, better route-optimization security may become necessary in the future, if improvements in other areas of Internet technology remove some of these plain IPv6 vulnerabilities. For instance, the use of Secure Neighbor Discovery [4] on the network where one of the endpoints resides removes some of the existing threats. Yet, a security association alone does not suffice as an enhanced security mechanism. General security associations typically do not show that a node owns a specific IP address, a property that is desired in the case of route optimization to authenticate home addresses. Certificate technology, for instance, usually does not track the correct IP-address assignments of a large group of users. Also, the validity of care-of addresses cannot be ensured by a security association alone. The security association must either be accompanied by a trust relationship, or care-of addresses must be checked otherwise. This shows that enhancements to the security of route optimization are likely to employ Mobile-IPv6-specific technology rather than general-purpose security tools. 4.4 Applicability Enhancements In Mobile IPv6, a mobile node's home address and current care-of address are carried in all route-optimized packets. The course of the mobile node may therefore easily be tracked by an observer. This can be an issue in situations where the mobile node prefers not to reveal its location. Location privacy, however, is inherently not supported by Mobile IPv6 route optimization. One solution is to fall back to bidirectional tunneling when location privacy is an issue. The path between the mobile node and its home agent can then be encrypted through IPsec ESP [16][17]. For full privacy protection the mobile node may have to re-establish its IPsec security associations, however, so that it cannot be tracked through its SPIs. On the path between the home agent and the correspondent node, all packets bear the mobile node's home address only. Hence, it is impossible for an outsider to realize when the mobile node is at home and when it is not. 5. The Toolbox This section introduces a number of techniques (the "toolbox") that Arkko & Vogt Expires April 1, 2005 [Page 20] Internet-Draft MIP6 Route Optimization Enhancements October 2004 can be used in the construction of a route optimization protocol. The section starts with the basic techniques used in RFC 3775 and continues with additional techniques that have been proposed as enhancements or alternatives. It is important to note that many of the specific techniques are insufficient or insecure on their own, as they address just one aspect of the problem. It is the combination of a set of techniques that makes a secure and efficient route optimization mechanism possible. Different techniques also have different trade-offs with respect to, say, universal applicability versus efficiency. 5.1 Address Tests An address test can be employed to ensure that the peer is live and at least on the path to a specific destination address. RFC 3775 uses address tests for two purposes, for ensuring (weak) ownership of the home address, and for preventing flooding attacks related to spoofed care-of addresses. As specified in RFC 3775, such address tests can also be stateless for the correspondent node, making their use in denial-of-service attacks harder. The limitations of address tests relate to their security properties and the required number of messages. The security provided by an address test can only guarantee that the peer is on the path, not that the peer truly owns its address or other identifier. On the other hand, on-path attackers are in any case capable of performing the same type of attacks as would be possible by misuse of route optimization, so this does not present a significant new threat in the Internet. The use of two address tests requires four messages although it can usually be completed in one roundtrip by employing parallelism. 5.2 Protected Tunnels An additional technique used in RFC 3775 is the protection of a part of the signaling communications through an encrypted tunneled to the home agent. This prevents other nodes, close to the mobile node, from seeing the home address tests. Given the starting point that we can not assume a security association with the correspondent node, this protection exists only for the mobile node side; an attacker close to the correspondent node would be able to perform various attacks (similar to those that an attacker in that position would be able to do even in the non-mobile Arkko & Vogt Expires April 1, 2005 [Page 21] Internet-Draft MIP6 Route Optimization Enhancements October 2004 case). The use of security associations with correspondent nodes is discussed further in Section 5.11. 5.3 Optimistic Behaviour RFC 3775 leaves quite a bit of freedom for mobile nodes regarding when they initiate the different procedures, and when they start sending data packets. An optimistic mobile node can initiate the return routability procedure right after sending the Binding Update to the home agent, even before it has gotten an Acknowledgement back. Mobile nodes may also start sending data packets right after having sent the Binding Update to the correspondent node. The drawback of this behaviour is that a dropped, re-ordered, or rejected Binding Update can cause data packets to be dropped. 5.4 Proactive Tests One technique for reducing delay is to move some of the tasks from the critical path to an earlier stage. In particular, movement-related signaling that needs to complete before communications can resume is on the critical path. As discussed in [15] and [36], the home address test in standard Mobile IPv6 can be done "proactively". This eliminates the need to do a home address test after the movement. As described in Section 3, a mobile node must refresh an existing binding at least every seven minutes. Since a Home Keygen Token is generally valid for no longer than 3.5 minutes, the mobile node must acquire a fresh Home Keygen Token prior to a binding refreshment. If a mobile node seeks to have available a fresh Home Keygen Token at all times it needs to initiate a proactive home-address test every 3.5 minutes even though it may not need to refresh its binding. Thus, upon a handover, the mobile node has already a fresh Home Keygen Token at hand when it arrives at the new link after handover. (Alternatively, the mobile node may be able to receive a trigger from its local link layer indicating that a handover is imminent. In this case, the mobile node may initiate the home-address test right in time instead of doing it periodically every 3.5 minutes.) Another optimization possibility is performing a care-of address test before the movement. This is possible only if the mobile node is capable of attaching to two networks simultaneously. Arkko & Vogt Expires April 1, 2005 [Page 22] Internet-Draft MIP6 Route Optimization Enhancements October 2004 5.5 Concurrent Tests Assuming a proactive home test has been performed but a care-of test has not, the mobile node cannot send a Binding Update immediately after the handover because it is still missing a valid Care-of Keygen Token for the new care-of address. On the other hand, the mobile node already has the Home Keygen Token. Recall from Section 3 that the Home Keygen Token authenticates the mobile node, through certifying the mobile node's ownership of the home address. In the concurrent test technique, the mobile node sends to the correspondent node an Early Binding Update. This message is is similar to the Binding Update used in standard Mobile IPv6 except that it is authenticated with the Home Keygen Token only. When the correspondent node receives the Early Binding Update, it can be confident that the mobile node uses the correct home address, because a valid Home Keygen Token was used to sign the message. On the other hand, the message-authentication code does not bear a Care-of Keygen Token, so the correspondent node cannot be sure whether the mobile node is actually present at the claimed new care-of address. The correspondent node thus registers the mobile node's new care-of address, labeling it "unconfirmed" for the time being. The mobile node can use the new care-of address as soon as it has dispatched the Early Binding Update. The mobile node then initiates a care-of-address test. When it receives the Care-of Keygen Token, it can send to the correspondent node a standard Binding Update. The message-authentication code is produced with the new Care-of Keygen Token and the Home Keygen Token from the proactive home-address test. When the correspondent node receives the standard Binding Update message, it can be confident that the mobile node uses the correct home address, and that the mobile node is actually present at the new care-of address. The correspondent node then changes the status of the new care-of address from "unconfirmed" to "confirmed". Due to the lack of care-of-address authentication in the Early Binding Update message, there needs to be additional protection while a mobile node's care-of address is unconfirmed. If no such protection is provided, a malicious node may misuse Early Binding Updates to register, as an unconfirmed care-of address, the IP address of a third party. This implies a vulnerability to flooding attacks (c.f. Section 2). Albeit the vulnerability is limited to a short period after handover, there needs to be additional protection while a mobile node's care-of address is unconfirmed. Heuristics could be used, but are per definition reactive. Heuristics may also result in false positives or, even worse, false negatives. (An enhancement to concurrent tests that avoids these problems is discussed in Section Arkko & Vogt Expires April 1, 2005 [Page 23] Internet-Draft MIP6 Route Optimization Enhancements October 2004 5.7.) The concurrent tests avoid the delay that emanates from the home- and care-of-address test by moving both tests to more suitable phases. This saves one round-trip time between the mobile node and the correspondent node, potentially through the home agent due to bidirectional tunneling for the home-address test. A disadvantage, however, is the increase in signaling that comes with the proactive home-address test: Unless the mobile node cannot anticipate a handover through link-layer triggers, the home-address test must be performed roughly every 3.5 minutes instead of the minimum rate of once every seven minutes prescribed by the Mobile IPv6 base specification. ([5] describes an signaling-reduction technique that can mitigate this impact when combined with Early Binding Updates.) 5.6 Diverted Routing Given that the per-movement signaling takes some time, mobile nodes can optionally request their traffic to be routed through their home address while this signaling is being completed. The performance impact of this approach depends on the length of the signaling period and the capacity and latency of the path through the home agent. We can generally analyze the fate of the different parts of the inbound payload traffic stream as follows: Packets sent before movement is known The correspondent node does not know the mobile node has moved until it has been told about this. In addition, being able to tell the correspondent node may itself involve some security-related signalling. The packets sent before the movement is are going to be lost, unless the mobile node is still connected also to its previous attachment point or local repair techniques (see Section 5.15) are used. Packets sent during the early part of signaling Assuming that the route optimization signaling involves messages through the home agent, it can be expected that at least the first packets sent from the correspondent will make it to the mobile node before the registration process is complete. This is because they have to travel the same path. Packets sent during the later part of signaling The fate of the packets sent via the home agent close to the end of the signaling period depends on the relative capacity and Arkko & Vogt Expires April 1, 2005 [Page 24] Internet-Draft MIP6 Route Optimization Enhancements October 2004 latency of the home agent and direct paths. If former path has a high latency, it might be better to queue the packets and wait for the signalling to be completed. One potential research direction is to look at whether the properties of the paths could be learned during the signaling and then used to decide the optimal time when the correspondent node should start queueing packets. The situation for the outbound traffic stream is similar, except that the mobile node knows immediately that it has moved, and thus first packets do not get lost. This technique appeared originally in [36] and has since then be used also in [13]. 5.7 Credit-Based Authorization Credit-Based Authorization (CBA) [35] is a technique that allows a correspondent node to already send packets to a new care-of address while the care-of-address test is in progress. The mobile node registers the new care-of address first, and it initiates the care-of-address test thereafter. CBA ensures that the mobile node still cannot wage an amplified flooding attack. The attraction of a redirection-based flooding attack emanates from its inherent potential for amplification. This is to say, the flooded victim sees itself confronted with a much higher data load than the attacker generates itself. The idea of CBA is that a correspondent node, when requested by a mobile node to switch to an unconfirmed care-of address, weighs the volume and rate of packets recently received from the mobile node against the volume and rate of packet that it sends to the mobile node's unconfirmed care-of address. Thus, if an attacker decided to misuse an unconfirmed care-of address for malicious redirection, it would not gain any amplification. Indeed, it would take less coordinative effort, and be at least equally effective, to send bogus packets to the victim directly. With CBA, a correspondent node maintains a credit account for each entry in its binding cache. When the correspondent receives a packet from a mobile node, it increases the credit in that mobile node's binding-cache entry by the size of the inbound packet. While the binding-cache entry holds a confirmed care-of address, the credit does not change when the correspondent node sends a packet that care-of address. However, when the care-of address is unconfirmed, the credit decreases by the size of each packet sent to that address. If the credit would be decreased to a negative value for a particular packet, that packet cannot be sent to the care-of address. With Arkko & Vogt Expires April 1, 2005 [Page 25] Internet-Draft MIP6 Route Optimization Enhancements October 2004 Mobile IPv6 and concurrent tests, the correspondent node can send such packets to the mobile node's home address. This is legitimate because the home address has been proactively verified before. For other protocols that do not provide an equivalent static IP address through which a mobile node is reachable, such packets may either be buffered for later transmission, or they may simply be discarded. HIP [27] and Mobike belong to the latter protocol category, although, in HIP, rendez-vous servers may theoretically be extended to provide mobile nodes with static IP addresses for constant reachability. The correspondent node exponentially ages existing credit, thereby giving precedence to credit obtained recently. This guarantees that a mobile node cannot collect credit over an extended time period at a very slow speed and use this credit, all at once, for a short but potent data burst towards a fraudulent unconfirmed care-of address. It is believed that a fair-minded mobile node sends packets to the correspondent node as part of its normal operation. Under many circumstances, the mobile node should thus automatically earn credit due to its normal behavior. Still, the proposal for CBA specifies an alternative mode that better accommodates applications with asymmetric traffic patterns such as file transfers and media streaming. Those applications are characterized by high throughput towards the client, typically the mobile node, and comparably little throughput towards the serving correspondent node. In the second mode, the correspondent node allocates credit for packets that it sends to a confirmed care-of address of the mobile node, rather than for packets that it receives. It is perspicuous that a mobile node, as well as an attacker, invests comparable effort for data reception as for transmission, in terms of bandwidth, memory, and processing capacity. In-band care-of-address spot checks allow the correspondent node to determine the approximate packet loss on the path towards the mobile node, and to derive the mobile node's average reception rate. An interesting property of the first version of CBA is that it does not require support from a mobile node. A mobile node neither needs to understand that CBA is effective at the correspondent node, nor does it have to have an idea of how much credit it currently has. If packet loss is not an issue, care-of-address spot checks may be omitted so that the second version of CBA is transparent as well. 5.8 Heuristic Monitoring Heuristic approaches are conceivable as well. For instance, one may consider a lifetime limit for unconfirmed care-of addresses which, supplemented by a heuristic for misuse detection, can prevent, or at least effectually discourage, misuse of such addresses. The challenge here seems to be a feasible heuristic: On one hand, the heuristic must be sufficiently rigid to catch any malicious intents at the Arkko & Vogt Expires April 1, 2005 [Page 26] Internet-Draft MIP6 Route Optimization Enhancements October 2004 other side. On the other hand, however, it must not have a negative impact on a fair-minded mobile node's communications. Correspondent nodes could also track the behaviour of mobile nodes over a longer period of time, and refuse communicating with them if they misbehave. The problem with this approach is that attackers can invent new addresses and other correspondent nodes to use in their attacks. 5.9 Cryptographically Generated Addresses Public-key cryptography is a powerful mechanism for mutual authentication between two nodes that do not know each other. Yet, the key question with public-key cryptography is how the nodes can trust in the respective other node's public key. How can an attacker be stopped to spoof its identity and use a false public key? The crux is that, generally, one cannot see from an identifier to which public key it belongs. There may not even be a one-to-one relationship between the identifier and the public key. In today's Internet, the identity-key matching problem is solved through certification authorities that have a reputation to be trustworthy. Nodes that want to mutually authenticate send each other their identities and public keys. Each node can then contact a trusted certification authority and have it verify whether the two parameters match. Once a node knows that its peer's public key is correct, it can verify whether the peer actually knows the right private key by decrypting the encrypted version of a certain piece of data. This mechanism has two disadvantages: First, it relies on the trusted certification authorities. If the certification authorities fail or are target of an attack, public-key cryptography is seriously compromised. Second, authorities usually delegate certain requests to other authorities. So, going through the authentication process can be time and resource consuming for the querier. These two drawbacks made public-key cryptography little attractive for Mobile IPv6. On the other hand, the described mechanism was designed to authenticate arbitrary transactions. This level of generality is actually not needed for mobility support. For example, a proof of home-address ownership would be sufficient in Mobile IPv6. This is where Cryptographically Generated Addresses (CGA) is helpful [8]. A CGA is an IPv6 address, which contains a set of bits generated by hashing the IPv6 address owner's public key. Such feature allows the user to proof that it is the legitimate owner of the its IPv6 Arkko & Vogt Expires April 1, 2005 [Page 27] Internet-Draft MIP6 Route Optimization Enhancements October 2004 address. The CGA offers three main advantages: First, it makes the spoofing attack against the IPv6 address much harder. Second, it allows to sign messages with the owner's private key. Third, CGA does not require any upgrade or modification in the infrastructure. The CGA offers a method for binding a public key to an IPv6 address. The binding between the public key and the CGA can be verified by re-computing and comparing the hash value of the public key and other parameters with the interface identifier from the owner's IPv6 address. Both the public and the additional parameters are sent with the message that requires authentication. Note that an attacker can always create its own CGA address but he will not be able to spoof someone else's address since he needs to sign the message with the corresponding private key, which is supposed to be known only by the real owner. The CGA technique was originally described in [28] and in [31], and it has later been used in [32], [8], and [13], among others. 5.10 Semi-Permanent Security Associations In the above techniques each movement involves a new, complete round of signaling. In the semi-permanent security association technique a key is established upon first contact, and then this key is later used in movements later, making the signaling efficient and secure. The primary security benefit of this approach is that the subsequent communications can be securely bound to the initial contact. Another way to look at this technique is that a key is created for a specific purpose or resource, and that all requests relating to that resource have to be authenticated by the same key. This technique works well in applications where the secured resource can be identified by the key. For instance, in HIP [27], opportunistic security can be achieved through binding all communications to the public keys generated by the participants. This technique is less secure when the resource is identified by some other means. For instance, if solely this technique is used for route optimization security in Mobile IPv6, there is nothing that prevents a malicious node from grabbing someone else's address and claiming that all subsequent signaling related to that address has to be authenticated through the attacker's public key. As a result, this technique is typically applied together with some other means to ensure the ownership of the resource, such as CGA as was done in [13]. Arkko & Vogt Expires April 1, 2005 [Page 28] Internet-Draft MIP6 Route Optimization Enhancements October 2004 Semi-permanent security associations were first developed in [10] where they were called Purpose Built Keys (PBKs). They have since then been applied in [12] and [13]. 5.11 Pre-Configuration The currently standardized route optimization method is based on the assumption that no security association or configuration can be expected between mobile and correspondent nodes either directly or via an infrastructure. However, in situations where such configuration is possible, efficiency and security improvements become possible. Perhaps the simplest route optimization security mechanism is the use of a shared secret between the mobile and correspondent nodes, as defined in [26]. 5.12 Infrastructure Infrastructure can provide assistance by vouching for the correctness of the home address, correctness of the care-of address, or the trustworthiness of the mobile node. This infrastructure can take many forms, such as a PKI tailored for for the route optimization problem or AAA enhanced with the required features. In its basic form, the infrastructure hands out home addresses and associates some keys with these addresses. It could produce certificates that could be used by others to verify the binding of the used key to the right home address, or it could provide a query interface where this verification is performed within the infrastructure. Setting up such infrastructure has generally been considered impossible for general Internet use. One of the problems is the current separation of address assignment and security infrastructures. However, [9] suggests a useful simplification: only home agents need to be assigned such prefix-based certificates, as they can vouch for their own mobile nodes. This makes the infrastructure problem more tractable. The infrastructure could also just identify the trustworthy mobile nodes. Together with an identifier for each mobile node, this could be used to retroactively track down misbehaving nodes. The use of infrastructure for care-of address verification could be based on the querying local network access system about the existence Arkko & Vogt Expires April 1, 2005 [Page 29] Internet-Draft MIP6 Route Optimization Enhancements October 2004 of a node at a claimed address. The mobile node would be identified by some means (such as a public key) known both to the correspondent node and the AAA network. The problem with this is that a global AAA system would have to be provided in order for a correspondent node to find out whether a mobile node connecting to it from the other side of the world is legitimate. 5.13 Cryptographically Bound Identifiers The primary problem in route optimization is to ensure that the home address is owned by the node that claims it. While the Mobile IPv6 architecture can not easily be changed with respect to the use of the home address as an identifier, other protocols have avoided some of these problems through the use of a cryptographic identifier. For instance, in HIP [27] a cryptographic identity is the primary identifier that binds all communications and upper layer protocols to the lower-level signaling exchanges. In HIP this identifier is a public key compressed to a 128-bit value through a hash function. The use of this type of identifiers avoids the home address ownership problem, but it is still necessary to verify the correctness of care-of addresses to avoid flooding attacks. 5.14 Local Mobility Local mobility can be provided via protocols such as Hierarchical Mobile IPv6 [33]. Local mobility supplements the end-to-end mobility support of standard Mobile IPv6. It brings performance improvements in terms of signaling overhead and handover latency. Hierarchical Mobile IPv6 introduces the concept of a regional Mobile Anchor Point (MAP). A MAP acts as a local home agent towards a visiting mobile node, and it proxies the mobile node towards the mobile node's home agent and correspondent nodes. Typically, a MAP serves multiple access networks, which are together referred to as the MAP's domain. Access routers in the MAP domain distribute the MAP's IP address in Router Advertisement extensions. The MAP is a router at a preferably central position within its domain. When a mobile node enters a visited network, it configures an "on-link care-of address" with the local network prefix through standard IPv6 Address Autoconfiguration. The mobile node may also configure a wider-scope "regional care-of address" with the MAP's network prefix and register the on-link and regional care-of addresses with the MAP. The MAP treats a mobile node's regional care-of address as a home agent treats the mobile node's home address. In particular, it performs Duplicate Address Detection for the regional care-of address. A bidirectional tunnel is established between the MAP and the mobile node. Arkko & Vogt Expires April 1, 2005 [Page 30] Internet-Draft MIP6 Route Optimization Enhancements October 2004 The mobile node registers the regional care-of address with its home agent and correspondent nodes. The MAP is prepared to intercept packets addressed the regional care-of address. It tunnels these packets to the mobile node's on-link care-of address. Vice versa, the mobile node may--or may have to if administratively prescribed in the access network--tunnel outbound packets to the MAP, which in turn decapsulates these packets and forwards them on to the recipient. When the mobile node moves to a different network within the same MAP domain, it updates the binding at the MAP, but it can leave the existing bindings at its home agent and correspondent nodes in place. 5.15 Local Repair A local repair technique involves reducing the ill effects of a movement, such as the ability to redirect packets received at a previous location to the new location. Fast Handovers for Mobile IPv6 [18] is one such optimization. It provides support from the access network that assists a mobile node during handover. Fast Handovers packages three functions: proxy router discovery, proactive IPv6 address configuration and proxy neighbor discovery, and provision against packet loss during handover. When a mobile node recognizes that a handover to a new access point is imminent--for instance, through a trigger from its local link layer--the mobile node can inquire of its current, old access router about a router attached to the detected new access point. For this, the mobile node sends a Router Solicitation for Proxy Advertisement to the old access router along with the MAC address of the new access point. Access routers are configured with tables matching near-by access points' MAC addresses to information about attached access routers. When the old access router hears a Router Solicitation for Proxy Advertisement, it looks up its table for an access router on the prospective new link, and it sends a Proxy Router Advertisement on behalf of that router. With the Proxy Router Advertisement at hand, the mobile node can configure a care-of address for the new link, even though it is still connected to the old link. Preferably right before handover, the mobile node signals the new care-of address to its old access router. The old access router verifies the new care-of address with the new access router and sends to the mobile node an acknowledgement indicating the result. If the suggested care-of address is acceptable, the new access router starts proxying the address. Otherwise, it signals an alternate care-of address to the old access router which, in turn, includes that address in its acknowledgement. Arkko & Vogt Expires April 1, 2005 [Page 31] Internet-Draft MIP6 Route Optimization Enhancements October 2004 Packets for the mobile node may still arrive at the old care-of address after the mobile node has switched to the new link. The old access router tunnels those packets to the mobile node's new care-of address. There are two exceptions that are worthwhile mentioning. During proxy router discovery, the old access router may not be configured with information about an appropriate new access router. No proxy router discovery can then be provided. Nonetheless may the mobile node request the old access router, from the new link, to forward any packets that subsequently arrive at the old care-of address. Furthermore, during proactive IPv6 address configuration, it may turn out that the mobile node's suggested care-of address is unacceptable, and the mobile node may no longer be at the old link when the old access router sends the acknowledgement with the alternate care-of address. In this case, the mobile node fails when attempting to connect to the new network with the unacceptable care-of address. The new access router may then install a host route for the old care-of address and set up a bidirectional tunnel with the old access router between the old and new care-of addresses. (Note that outbound tunneling is necessary to ensure topological correctness of the packets' IPv6 source addresses.) Thus, the mobile node may continue to use its old care-of address at the new link until it has successfully configured a new care-of address through standard IPv6 Address Autoconfiguration. In a non-optimized environment, standard router discovery and IPv6 Address Autoconfiguration can cause substantial disruption to ongoing communications during a handover. With Fast Handovers, a mobile node can accomplish these tasks proactively before the handover. Moreover, the mobile node's communication peers typically continue to use an outdated care-of address for some time after a handover due to the natural latency of global Mobile IPv6 signaling. In a standard setting, packets sent to a stale care-of address are typically dropped. Fast Handovers salvage these packets by means of the tunneling service from the old to the new access router. This enables lossless handovers. Fast Handovers can nicely be integrated with Hierarchical Mobile IPv6 [33]. The mobile node then registers a prospective new care-of address directly through the MAP, rather than through the old access router, for efficiency reasons. The forwarding service for packets sent to an outdated care-of address is also provided by the MAP. 5.16 Processing Improvements Processing power is in general not as significant issue in route optimization as the amount of signaling and latency. However, this Arkko & Vogt Expires April 1, 2005 [Page 32] Internet-Draft MIP6 Route Optimization Enhancements October 2004 can still be an issue for busy servers or proposals that are based on public key operations. For these cases, new types of cryptographic algorithms (such as ECC instead of RSA) might provide some assistance. 5.17 Delegation Given that the home agent does not need to move or conserve battery energy, it can be used for performing computationally expensive tasks. It can also be used for parts of the signaling, to reduce communications over slow wireless links. Some work relating to delegation has been done in [32] and [9]. 6. Analysis This section analyzes the previously presented techniques in relation to each other and the enhancement objectives. We start by looking at how the techniques can be categorized, continue by studying a number of proposals that apply a number of techniques to reach a goal, and conclude with some subjects for further research in this area. 6.1 Categorization of Techniques Local techniques require support from the access network that the mobile node is attached to. HMIP and FMIP are examples of local techniques. They can significantly mitigate the disruptive impact that movements have on ongoing communications. Yet, they require investments at the access network and thus imply additional costs for the network operator. Also, local optimizations are ineffective for handovers across administrative domains unless providers have mutual agreements to interconnect their networks. End-to-end techniques do without the need infrastructure in the access network. They also work across administrative domains. On the other hand, end-to-end approaches cannot leverage the short distances to local network entities, but have to cope with global, thus potentially long, round-trip times. Hence, end-to-end techniques cannot usually catch up with the high performance gains that are characteristical for local optimizations. Zero-configuration techniques require no preconfiguration or assistance from a managed infrastructure. Address tests, proactive tests, concurrent tests, diverted routing, credit-based schemes, monitoring, CGA, semi-permanent, cryptographically bound identifiers, processing improvements, and delegation are zero-configuration techniques. Arkko & Vogt Expires April 1, 2005 [Page 33] Internet-Draft MIP6 Route Optimization Enhancements October 2004 Pre-configuration and infrastructure-based methods are not zero-configuration techniques. Local techniques have traditionally been implemented in a manner that requires configuration, but there appears to be no fundamental reason why this would have to be so. 6.2 Evaluation of Some Proposals 6.2.1 Local Assistance IETF's two current protocols for localized assistance to mobile nodes have been described in Section 5.14 and Section 5.15. Hierarchical Mobile IPv6 (HMIPv6) screens a mobile node's movements within a MAP domain from nodes not inside that domain. In case standard Mobile IPv6 is used end-to-end, this eliminates most of the global signaling: While its regional care-of address does not change, a mobile node does not need to update its home agent or correspondent nodes beyond the mandatory periodic refreshments. Not having to signal on a global basis also reduces handover latency. Updates to the home agent and to correspondent nodes are necessary only when the mobile node leaves the current MAP domain. The mobile node may then register a new regional care-of address with a different MAP if one is available. Note that switching MAPs usually requires the mobile node to signal more than if standard Mobile IPv6 was used alone. Local and end-to-end signaling then comes together because, as it stands, a mobile node must contact the new MAP seperately from its home agent and correspondent nodes. Due to dependencies between a MAP registration and a contemporary home or correspondent registration, a mobile node may want to wait for the MAP registration to complete before it initiates the standard Mobile IPv6 registration procedure. Handover latency is then increased in addition to the signaling overhead. Future work should thus go into the integration of MAP registrations with standard Mobile IPv6 signaling. Another interesting research opportunity seems to be a mechanism that tells neighboring MAPs from different administrative sites that their domains overlap. The MAPs could then mutually advertise each other throughout certain parts of their domains. The cost for an inter-MAP handover in terms of signaling load and delay strongly depends on the network topology. In an optimal layout, a MAP is located somewhere on the path from the mobile node to its home agent and correspondent nodes. This may be the case if the MAP is co-located with an Internet gateway. Then, switching MAPs is Arkko & Vogt Expires April 1, 2005 [Page 34] Internet-Draft MIP6 Route Optimization Enhancements October 2004 cheap. On the other hand, if the MAP is way off the direct path between a mobile node and its peers, the additional overhead might become noticeable. Indeed, a good topological layout is crucial for the performance of HMIPv6. Fast Handovers for Mobile IPv6 (FMIPv6) streamlines the router-discovery and IPv6-address-configuration processes, and it facilitates lossless handovers. FMIPv6 assumes that access routers are capable of matching a neighboring access point to the access router to which it attaches. The capability is a prerequisite for proxy router discovery. Yet, it is still an open issue how access routers learn about this information. Manual configuration is one option, though it can be extremely expensive. More attractive would be an automated mechanism that allows access routers to dynamically recognize access points to which mobile nodes may want to switch. A related issue is how such knowledge can be securely obtained across the borders of administrative sites. These are opportunities for future research. Note that Hierarchical Mobile IPv6 may be used even when the no Mobile IPv6 is used beyond the local domain. I.e., a mobile node may use its regional care-of address as a temporary home address. The mobile node would thus appear to a correspondent node as a stationary node in the MAP's network. The same is true for a combination between HMIPv6 and FMIPv6, but FMIPv6 alone cannot be used without standard Mobile IPv6. It should also be mentioned that HMIPv6 provides location privacy for mobile nodes as long as the mobile nodes do not move across MAP domains. In fact, a mobile node appears to parties outside its current MAP domain as a stationary host located in the MAP's network because it does not advertise its link-local addresses to those nodes. Of course, there are disadvantages with HMIPv6 and FMIPv6. Local optimizations in general require investments in the access network and thus imply additional costs for the network operator. Also, as mentioned, localized mobility support may even cause increased overhead in certain situations. And local mechanisms are to date ineffective for handovers across administrative domains unless providers have mutual agreements to interconnect their networks. 6.2.2 Preconfigured Secret Method It has been explained in section Section 3 that the return-routability procedure serves two purposes: The home-address test allows the nodes to authenticate mobility-related signaling, and the care-of-address test is needed to verify a mobile node's reachability. Preconfigured shared secrets allow nodes to authenticate without the home-address test. But without further Arkko & Vogt Expires April 1, 2005 [Page 35] Internet-Draft MIP6 Route Optimization Enhancements October 2004 assumptions, preconfiguration cannot streamline the care-of-address verification process. The Home Keygen Token exchange from the return-routability procedure is the default authentication technique used in Mobile IPv6. It facilitates reasonable security even for nodes that have no pre-existing relationship. On the other hand, nodes that do share a common secret should be allowed to omit the home-address test. This can be beneficial in certain scenarios where the home-address test causes a long handover latency due to packet redirection through the home agent. On the other hand, the latency improvement can be much higher if not only the Home Keygen Token exchange, but also the Care-of Keygen Token exchange is ignored. Eliminating the latter, however, requires some sort of trust into mobile nodes not to spoof a care-of address. In fact, [26], a method being standardized by the IETF MIP6 Working Group, is based on this trust model. The assumption that mobile nodes be fair-minded turns out to be quite far stretching. On on side, it affords the elimination of the entire return-routability procedure, not just the Home Keygen Token exchange. As explained in [26], and can also be inferred from figure Figure 1, this can cut handover latency in half. On the other hand, the assumption significantly limits the applicability of the optimization. There are certainly scenarios where preconfiguration per se would be possible, but no trust model can be assumed. For instance, an ISP may configure its media servers with the keys of its customers. The customers could then use their keys and Mobile IPv6 for communications with the media servers, but some customers might misuse the lack of a care-of-address test to wage a re-direction-based flooding attack against an arbitrary IP host. This example reveals the difference between a security association for authentication and a trust relationship for misuse prevention. In an effort to extend preconfiguration to scenarios where no trust relationship can be presupposed, one may combine it with care-of-address tests. Of course, the care-of-address test would partly vitiate the handover-latency improvement that preconfigured keys brings without the care-of-address test. But handover latency may still improve over the standard return-routability procedure because a care-of-address test is usually faster than a complete return-routability procedure. (This is because the complete return-routability procedure includes a home-address test, which is usually more expensive than the care-of-address test because it is directed through a home agent.) Also pre-authentication facilitates stronger authentication mechanisms and thus the use of route optimization for applications that would otherwise opt for Arkko & Vogt Expires April 1, 2005 [Page 36] Internet-Draft MIP6 Route Optimization Enhancements October 2004 bidirectional tunneling due to security concerns. Moreover, preconfiguration can be used along with a combination of a concurrent care-of-address test and credit-based authorization or heuristic monitoring. This approach eliminates the home-address test and makes the care-of-address test transparent to applications. It also keeps the possibility to use an alternative authentication mechanism. These things said, it seems like a good idea to make the preconfiguration protocol bendable to different environments. Is there a small group of people who trust each other? Then, of course, group members are unlikely to spoof care-of addresses, and we can go without the care-of-address test. Or are we talking about the customer base of a big ISP? Then, proper authentication does usually not imply trust, and it may not be feasible to use preconfigured keys without checking a mobile node's reachability. Tracability techniques are not a compensation for the missing care-of-address test, because they are a reactive measure, whereas a care-of-address test is a proactive one. Specifically, the integration of key preconfiguration with care-of-address test could be done as follows. In case the care-of-address test is deemed necessary, a preconfigured 64-bit key can substitute the Home Keygen Token. The Home Keygen Token may also be derived in some defined way from the preconfigured key. Either way, signaling messages can then be authenticated in the same way as defined in the Mobile IPv6 specification. This amendment to [26] helps to broaden the scope of key preconfiguration to environments where end-hosts have administrative relationships with each other, but do not necessarily trust each other. 6.2.3 CGA-Based Optimizations CGA assures that a mobile node is the legitimate owner of its home address. As far as the correctness of home addresses go, CGA provides more assurance than the pure use of routing paths. This makes it possible to have a significant decrease in the signaling frequency. In addition, the public keys used in the CGA technique allow certain data to be communicated privately between the nodes, which makes some of our other techniques possible. GA could also be used to reduce the risk of flooding attacks via care-of addresses, as attackers would be unable to manufacture victim addresses for a specific host. However, only the interface-identifier part of an IPv6 address is cryptographically generated, so flooding a network or a link is still an issue. As a result, CGA needs to be employed together with a reachability test in scenarios where Arkko & Vogt Expires April 1, 2005 [Page 37] Internet-Draft MIP6 Route Optimization Enhancements October 2004 redirection-based flooding attacks are a concern. An interesting future path for research would be to consider the combination of concurrent care-of-address tests together with CGA-based care-of addresses. CGA is typically used to assure the correctness of the home address that the mobile node claims to own, and combined together with other techniques to prevent flooding attacks. Note that this implies that an initial home address test is typically required too in order to avoid the deletion of a binding to flood an unconfirmed home address. The crux with using cryptographically generated care-of addresses is address collisions: A given public key hashes to exactly one value. CGA uses modifiers in the case of collisions. But as such modifiers weaken the cryptographic strength of CGAs, only a few (usually four) modifiers are allowed. 6.2.4 CBA-Based Latency Reduction As shown in Section 2, the ability to change a packet flows destination IP address can potentially be misused for a malicious redirection-based flooding attack. Mobile IPv6 and similar mobility-management protocols like Host Identity Protocol (HIP) [27] and current Mobike proposals solve this issue by probing a new IP address before that IP address is used as a destination for payload packets. Unfortunately, by definition, IP-address probing cannot be done in a proactive style. After all, a handover involving an IP-address change invalidates any previous probes. Instead, a new care-of address may be probed while packets are already flowing to that care-of address. This concept of concurrent care-of-address tests was first mentioned in [36]. CBA was added to secure the time phase during which a mobile node's reachability at the new care-of address is not yet verified, but the new care-of address is already in use. After all, this time phase could otherwise introduce a susceptibility to malicious redirection, if but for an albeit short time. As shown in Section 2, the attraction to redirection-based flooding attacks is its potential for easy-to-get amplification. Note that CBA does not prevent an attacker from spoofing its care-of address. But the attacker will not be able to wage an amplified flooding attack. More specifically, the amount of data that can be redirected to an unconfirmed care-of address is sufficient for a fair-minded mobile node to continue communications during the care-of-address test, but it is far from satisfactory for an attacker planning denial of service. Arkko & Vogt Expires April 1, 2005 [Page 38] Internet-Draft MIP6 Route Optimization Enhancements October 2004 The challenge with CBA is how much data the correspondent node may exactly send to a care-of address while it is unconfirmed. If it sends too much, an attacker could take advantage of this. If it sends to little, a fair-minded mobile node might suffer performance degradations during the handover phase. As shown in Section 5.7, there are two modes for Credit-Based Authorization. In the first mode, the correspondent node weighs the data volume that it has recently received from a mobile node with the data volume that it may maximally send to an unconfirmed care-of address of that mobile node. This is the most straightforward way to make redirection-based flooding attacks comparable to direct flooding attacks, which are, after all, already possible and easy to perform in today's non-mobile Internet. The second mode takes the data volume a mobile node has recently received at a confirmed care-of address as a limit on how much data the mobile node can receive after handover to a new, unconfirmed care-of address. This second mode gives away some of the first mode's straightforwardness in exchange for a better support for applications with asymmetric data throughput. This was deemed necessary in consideration of applications like media streaming, television broadcasts, and file transfers, where the mobile node typically receives multiple orders of magnitude more data than it sends. One should evaluate whether the second mode of Credit-Based Authorization could be misused by an attacker that has an asymmetric connection to the Internet. Wide-spread digital subscriber lines (DSL) usually have a much higher download rate than upload rate. The limited upload rate would render most denial-of-service attempts through direct flooding meaningless. But the strong download rate could be misused to illegitimately build up credit at one or many correspondent nodes. The credit could then be used for a more potent, redirection-based flooding attack. It turns out that this issue is less serious than it may seem at first glance. The reason is that, in order to build up enough credit at the remote end, the attacker would initially have to expose itself to exactly the same packet flood that it could then redirect towards the victim. Note that this is true for both data volume and data rate: While data volume directly affects how much credit the correspondent node allocates, the data rate is indirectly taken into account through credit aging. The second CBA mode requires some sort of feedback for the correspondent node about how many packets that the correspondent node sends to a mobile node actually make it all the way to that mobile node. As mentioned in Section 5.7, care-of-address spot checks provide this feedback. But they require more significant modifications to the Mobile IPv6 base specification than the first Arkko & Vogt Expires April 1, 2005 [Page 39] Internet-Draft MIP6 Route Optimization Enhancements October 2004 mode of CBA does. Moreover, while the first mode operates completely transparent to the mobile node, the second obviously does not. CBA uses exponential aging to gradually reduce credit that has been earned in the past. This way, an attacker is prevented to collect credit over a long time interval and use this credit, all at once, for a short but potent data burst towards a victim. Care must be taken to set the aging factor to an appropriate value. Finally, one should mention that CBA-based concurrent care-of-address tests can be used to improve other mobility-management protocols that verify a new IP address through probing. This includes HIP and certain Mobike proposals. Also, CBA-based concurrent care-of-address tests can be integrated into other Mobile IPv6 optimization techniques described in this document. Approaches that may benefit are, for example, CGA-based ones (cf. Section 6.2.3) as well as those that use shared-secret preconfiguration (cf. Section 6.2.2). Last, but not least, in scenarios where a home agent cannot trust in the correctness of the registered mobile nodes' care-of addresses, CBA-based concurrent care-of-address tests could be proscribed even for home registrations. The same is true for Hierarchical Mobile IPv6, which, as it stands, assumes a MAP can be confident that mobile nodes use correct on-link care-of addresses, and so gets around the care-of-address test. 6.2.5 Prefix-Based Certificates The Mobile IPv6 base specification avoids strong authentication cryptography for signaling between mobile nodes and correspondent nodes. One reason for this is the impracticality of a global trusted PKI that could approve bindings between the mobile nodes' identities and public keys. Another reason is that limited power resources and processing capacity at the mobile nodes generally rule out any complex cryptographic operations. Robustness to resource-exhaustion attacks requires a similar restrictiveness on the correspondent-node side. [9] suggest promoting the home agent to a security proxy operating on behalf of its mobile nodes. Correspondent nodes can trust a home agent based on a certificate that binds the home-network prefix to the public key of the home agent. The home agent, in turn, vouches for the correctness of its mobile nodes' home addresses. This approach is called Certificate-based Binding Update (CBU). CBU circumvents the lack of a global PKI in an elegant way. Rather than having to issue a certificate per mobile node, only a certificate per home-network prefix is required. This reduction in complexity makes certificate-based approaches to mobile-node Arkko & Vogt Expires April 1, 2005 [Page 40] Internet-Draft MIP6 Route Optimization Enhancements October 2004 authentication more feasible than it is today. The approach also avoids heavy computations at mobile nodes since all such computations are performed by the home agent. This mitigates the issue with resource limitations at mobile nodes. As a side effect, once the end-to-end security association between a mobile node and a correspondent node has been created, CBU allows for improved signaling delay during all subsequent handovers. On the other hand, it should be mentioned that the processing overhead at correspondent nodes actually increases compared to standard correspondent registrations. This may not be an issue since resources at stationary correspondent nodes are usually higher than those of many mobile devices, and home agents would do the cryptographic operations for mobile correspondent nodes. Correspondent nodes should hence be provided with sufficient resources, at least where the correspondent node is not a popular web server or other central resource. One should, however, bear in mind that the increased overhand implies a higher risk to resource-exhaustion attacks. The identity of a mobile node may in certain scenarios also be verifiable through an AAA infrastructure. A home AAA server, which may or may not be co-located with the home agent, can then contact a remote AAA server in the correspondent node's network. Note that this moves some of the authentication overhead from the correspondent node to the remote AAA server. An AAA-based approach can also dynamically assign mobile-node requests to different correspondent nodes while keeping secret authenticating material local at a single AAA server. There is ongoing work on the integration of AAA with Mobile IPv6 [30]. The current focus is on authentication between mobile nodes and home agents. The proposal is thus a replacement for the IPsec-based authentication protocol for home registrations. But the concept of security proxies presented in [9] may as well be re-used for enhancements to the AAA infrastructure. CBU does not solve the issue with care-of-address spoofing: A vouching home agent does not prevent a malicious mobile node from faking its care-of address. The culprit could cheat its home agent, or it could cooperate with it. This said, CBU should be combined with a care-of-address test that rules out redirection-based flooding attacks. A combination of concurrent care-of-address tests and CBA (cf. Section 5.7) can be used to keep the signaling delay during handover as low as it currently is in [9]. Arkko & Vogt Expires April 1, 2005 [Page 41] Internet-Draft MIP6 Route Optimization Enhancements October 2004 6.3 Further Research Mobility-related optimizations are currently actively studied by many researchers, looking at a number of different protocol layers. The preceding section also identifies some worthwhile amendments to the existing proposals that require further work. While some of the basic methods for route optimization are fairly well understood and are being deployed, there are a number of interesting, newer approaches that deserve to be studied in more detail. This section discusses some research directions that appear fruitful, or necessary in the future, and that go beyond the existing proposals described so far. 6.3.1 Related Research in Other Protocol Layers The efficiency, security, and other functionality related to movements is not dependent only on Mobile IPv6 route optimization (even if researchers often pose their analysis in that light). A movement that is visible at the IP layer involves all lower layers as well; this includes layer 2 attachment procedures, layer 2 security mechanism negotiation, authentication and key agreement, IP router and neighbor discovery, address autoconfiguration, duplicate address detection and so forth. A complete network attachment typically requires over twenty link and IP layer messages, assuming features necessary for a commercial deployment (such as security) are turned on. A significant research question is the overall performance of the network access stack as a whole. Current protocol stacks have a number of limitations in addition to the long attachment delays [1], such as denial-of-service vulnerabilities, difficulties in trusting a set of access nodes distributed to physically insecure locations, inability to get enough information for a handoff decision, and so on. A number attempts are ongoing to improve various parts of the stack, in particular focusing on performance of movements. These attempts include link-layer enhancements, parameter tuning [34], network access authentication mechanisms [14], fast handover mechanisms [20], [2], and IP layer attachment improvements (such as Optimistic DAD [21]). It is uncertain how far this optimization can be taken by only looking at the different parts individually. It is possible that a more integrated approach would be necessary to gain a more significant improvement [3]. It is also unclear at this time which components are the most critical ones. Reference [1] suggests that IP mobility related Arkko & Vogt Expires April 1, 2005 [Page 42] Internet-Draft MIP6 Route Optimization Enhancements October 2004 signaling contributes only under 10% of the overall delay in an IEEE 802.11 environment. The most significant delays are caused by link layer and IPv6 attachment. However, the results are not conclusive, as there is a factor five difference between the best and worst cases. The results can also be affected by a number of conditions, such as the availability of specific link layer optimizations, or the type of security mechanism used in the Mobile IPv6 home registrations. 6.3.2 New Route Optimization Work The primary driver to improve route optimization appears to be better efficiency for a few usage scenarios, such as fast movements or the ability to reduce signaling frequencies for hosts in standby mode. Ongoing work addresses these aspects already quite well; most of the suggested methods are quite stable in this regard. It is expected that further (perhaps smaller) improvements continue to be achieved through research and parameter tuning far into the future. This is particularly true because the optimizations are often targeted to a specific usage situation, and may not give the same improvement in another situation. As a result, the publication of a few enhanced methods for different situations seems more reasonable than expecting to define a final, single method. The development of an infrastructure-based route optimization method is clearly a longer-term project. At this stage, it is not even clear that such a mechanism is needed. We believe the prefix-based certificate approach shows some promise in this area, particularly if it can be combined with the deployment of these certificates for some other purposes, such as Secure Neighbor Discovery [4]. The pre-shared method being standardized at the IETF is simple and efficient, but we do not expect it to be applicable in wide enough number of cases to make a significant difference in practice. In the following we list some potentially interesting research ideas for new route optimization methods: o Local mobility or local repair optimizations that require no configuration. o Care-of address verification mechanisms that employ lower layer assistance or Secure Neighbor Discovery. o The introduction of optimizations developed in the context of Mobile IPv6 to HIP or other mobility protocols, or to layer 2 mobility solutions. o Extension of the developed techniques to full multiaddressing, i.e., including also multi-homing. o Further development of techniques based on "asymmetric cost wars" [7], such as CBA. Arkko & Vogt Expires April 1, 2005 [Page 43] Internet-Draft MIP6 Route Optimization Enhancements October 2004 6.3.3 Experimentation and Simulation As discussed earlier, even the contribution of different stack parts to overall movement delays is unclear. More measurements are needed, particularly ones that o Measure a realistic network scenario, enabling all features that would likely be needed in commercial deployment. These features include link-layer access control, for instance. Similarly, it is necessary to include support for already specified optimizations. o Measure or simulate the performance impacts of various suggested improvements to the different parts of the stack. o Measure implementation differences between systems based on the same specifications. It would be valuable to know how much implementations differ with regards to, for instance, the use of the parallelism that RFC 3775 allows in the home and correspondent registrations, the return routability procedure, and transmission of packets before Binding Acknowledgements have arrived. o Measure the effect of network conditions, such as packet loss, and their effect to existing and new route optimization mechanisms. o Collect data about the behaviour of mobile nodes in different networks. Different route optimization mechanisms behave differently depending on what the frequency of movements is, or what payload traffic streams exist at the different stages of the mobile node's existence. o Measure or simulate the performance of different route optimization schemes under different application scenarios, such as symmetric/asymmetric applications, only seldomly active mobile nodes, and so on. 7. Security Considerations Security issues related to route optimization are an integral part of the problem and have been discussed in the body of the document. 8. Conclusions Mobility related optimizations are currently actively studied by many researchers. Some of the basic Mobile IPv6 related methods, such as the return routability method, pre-shared secrets, CGAs are either already being applied in practical systems or will be soon. A growing number of new proposals are being studied that attempt to optimize these methods further, or make them better applicable to a particular situation. Many of the current proposals are mature enough to withstand close scrutiny. Their relative advantages are somewhat subjective, however. For instance, some may have a high cost in terms of configuration while others do not need configuration but are slower. It is expected Arkko & Vogt Expires April 1, 2005 [Page 44] Internet-Draft MIP6 Route Optimization Enhancements October 2004 that more than one new method is needed for this reason. Deployment experience will also be needed, so publication of a few alternative methods as RFCs would be desirable. It is interesting to note, however, that historically most if not all current proposals had predecessors that were shown to be insecure. For instance, the initial return routabality and CGA methods were proposed before the need for flooding attack protection was understood, concurrent tests were first proposed with a limited form of flooding protection, and several proposals employing semi-permanent security associations have suffered from address stealing attacks. This shows the need to reserve sufficient amount of time for community analysis and review of new methods. Another interesting observation is that mature proposals combine a number of techniques and do not rely on a single approach. This is due to the nature of the problem, where several different types of vulnerabilities have to be avoided. But it is also necessary to avoid overly expensive or complex solutions. For instance, in evaluating the security needs for the route optimization problem, it is important to compare these needs to other vulnerabilities, such as denial-of-service, that already exist for on path attackers. These vulnerabilities should not be made worse, but it is not necessarily a requirement to use managed, expensive security either. A significant research question is the overall performance of the whole stack in a mobile setting. This includes but is not limited to IP mobility. Current network access protocol stacks have a number of limitations, such as long attachment and movement latencies [1] -- an attachment typically requires over twenty link and IP layer messages -- denial-of-service vulnerabilities, and so on. A number attempts are currently being made to improve various parts of the stack, in particular focusing on high-performance movements. These attempts include link-layer enhancements, parameter tuning [34], network access authentication mechanisms [14], fast handover mechanisms [20][2], and IP layer attachment improvements such as Optimistic DAD [21]. It is uncertain how far this optimization can be taken by only looking at the different parts individually. It is also unclear at this time which components are the most critical ones. Other significant research questions include the effect of various network conditions such as packet loss to the current methods and whether different application situations require different optimization methods. Our current understanding about the different traffic patterns and their effects in mobility is limited, and Arkko & Vogt Expires April 1, 2005 [Page 45] Internet-Draft MIP6 Route Optimization Enhancements October 2004 experiments, modelling, and simulations will be needed. Arkko & Vogt Expires April 1, 2005 [Page 46] Internet-Draft MIP6 Route Optimization Enhancements October 2004 9 References [1] Alimian, A. and B. Aboba, "Analysis of Roaming Techniques", IEEE Contribution 11-04-0377r1 2004. [2] Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to RADIUS", draft-irtf-aaaarch-handoff-04 (work in progress), November 2003. [3] Arkko, J., Eronen, P., Nikander, P. and V. Torvinen, "Secure and Efficient Network Access", Extended abstract to be presented in the DIMACS workshop, November 2004. [4] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 (work in progress), July 2004. [5] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding Lifetime Extension", draft-arkko-mipv6-binding-lifetime-extension-00 (work in progress), May 2004. [6] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [7] Arkko, J. and P. Nikander, "Weak Authentication: How to Authenticate Unknown Principals without Trusted Parties", Proceedings of Security Protocols Workshop 2002, Cambridge, UK, April 16-19, 2002. [8] Aura, T., "Cryptographically Generated Addresses (CGA)", draft-ietf-send-cga-06 (work in progress), April 2004. [9] Bao, F., "Certificate-based Binding Update Protocol (CBU)", draft-qiu-mip6-certificated-binding-update-02 (work in progress), August 2004. [10] Bradner, S., Mankin, A. and J. Schiller, "A Framework for Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in progress), June 2003. [11] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [12] Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)", draft-haddad-mipv6-omipv6-01 (work in progress), February 2004. Arkko & Vogt Expires April 1, 2005 [Page 47] Internet-Draft MIP6 Route Optimization Enhancements October 2004 [13] Haddad, W., Madour, L., Arkko, J. and F. Dupont, "Applying Cryptographically Generated Addresses to Optimize MIPv6 (CGA-OMIPv6)", draft-haddad-mip6-cga-omipv6-02 (work in progress), June 2004. [14] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001. [15] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [16] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [17] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-esp-v3-08 (work in progress), March 2004. [18] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-02 (work in progress), July 2004. [19] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node-requirements-11 (work in progress), August 2004. [20] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key Distribution to support fast and secure roaming", IEEE Contribution 11-03-084r1-I, January 2003. [21] Moore, N., "Optimistic Duplicate Address Detection for IPv6", draft-ietf-ipv6-optimistic-dad-01 (work in progress), June 2004. [22] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00 (work in progress), June 2004. [23] Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", draft-ietf-mip6-ro-sec-01 (work in progress), July 2004. [24] Paxson, V., "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks", Computer Communication Review 31(3)., July 2001. [25] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. Arkko & Vogt Expires April 1, 2005 [Page 48] Internet-Draft MIP6 Route Optimization Enhancements October 2004 [26] Perkins, C., "Preconfigured Binding Management Keys for Mobile IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress), April 2004. [27] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity Protocol", draft-moskowitz-hip-09 (work in progress), February 2004. [28] Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", Proceedings of the Cambridge Security Protocols Workshop, April 2001. [29] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004. [30] Patel, A., Leung, K., Khalil, M., Akhtar, H. and K. Chowdhury, "Authentication Protocol for Mobile IPv6", draft-ietf-mip6-auth-protocol-00 (work in progress), July 2004. [31] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", Computer Communications Review, April 2001. [32] Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", draft-roe-mobileip-updateauth-02 (work in progress), March 2002. [33] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mipshop-hmipv6-02 (work in progress), June 2004. [34] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b MAC Layer Handover Time", Laboratory for Communication Networks, KTH, Royal Institute of Technology, Stockholm, Sweden, TRITA-IMIT-LCN R 03:02, April 2003. [35] Vogt, C., Arkko, J., Bless, R., Doll, M. and T. Kuefner, "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", draft-vogt-mipv6-credit-based-authorization-00 (work in progress), May 2004. [36] Vogt, C., Bless, R., Doll, M. and T. Kuefner, "Early Binding Updates for Mobile IPv6", draft-vogt-mip6-early-binding-updates-00 (work in progress), February 2004. Arkko & Vogt Expires April 1, 2005 [Page 49] Internet-Draft MIP6 Route Optimization Enhancements October 2004 Authors' Addresses Jari Arkko Ericsson Research NomadicLab FI-02420 Jorvas Finland EMail: jari.arkko@ericsson.com Christian Vogt Institute of Telematics University of Karlsruhe P.O. Box 6980 76128 Karlsruhe Germany EMail: chvogt@tm.uka.de URI: http://www.tm.uka.de/~chvogt/ Appendix A. Acknowledgements The authors wish to thank Gabriel Montenegro and Rajeev Koodli for their support, review, and suggestions related to this paper. Arkko & Vogt Expires April 1, 2005 [Page 50] Internet-Draft MIP6 Route Optimization Enhancements October 2004 Intellectual Property Statement 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 IETF's procedures with respect to rights in IETF 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Arkko & Vogt Expires April 1, 2005 [Page 51]