Network Working Group C. Vogt Internet-Draft Universitaet Karlsruhe (TH) Expires: April 11, 2006 J. Arkko Ericsson Research NomadicLab October 8, 2005 A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization draft-irtf-mobopts-ro-enhancements-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 11, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes and evaluates strategies to enhance Mobile IPv6 route optimization, on the basis of existing proposals, in order to motivate and guide further research in this context. Vogt & Arkko Expires April 11, 2006 [Page 1] Internet-Draft MIP6 Route Optimization Enhancements October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 A Note on Public Key Infrastructures . . . . . . . . . . . 4 1.2 A Note on Source Address Filtering . . . . . . . . . . . . 5 2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 3. Mobility-Related Security Threats . . . . . . . . . . . . . 7 4. Mobile IPv6 Route Optimization . . . . . . . . . . . . . . . 8 4.1 Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 4.2 Analysis of Correspondent Registrations . . . . . . . . . 10 5. Objectives for Enhancement . . . . . . . . . . . . . . . . . 11 5.1 Latency Optimizations . . . . . . . . . . . . . . . . . . 11 5.2 Security Enhancements . . . . . . . . . . . . . . . . . . 12 5.3 Signaling Optimizations . . . . . . . . . . . . . . . . . 13 5.4 Robustness Enhancements . . . . . . . . . . . . . . . . . 13 5.5 Functionality Enhancements . . . . . . . . . . . . . . . . 14 6. Enhancements Toolbox . . . . . . . . . . . . . . . . . . . . 14 6.1 IP-Address Tests . . . . . . . . . . . . . . . . . . . . . 14 6.2 Protected Tunnels . . . . . . . . . . . . . . . . . . . . 15 6.3 Optimistic Behavior . . . . . . . . . . . . . . . . . . . 16 6.4 Proactive IP-Address Tests . . . . . . . . . . . . . . . . 16 6.5 Concurrent IP-Address Tests . . . . . . . . . . . . . . . 17 6.6 Diverted Routing . . . . . . . . . . . . . . . . . . . . . 19 6.7 Credit-Based Authorization . . . . . . . . . . . . . . . . 20 6.8 Heuristic Monitoring . . . . . . . . . . . . . . . . . . . 23 6.9 Crypto-Based Idendifiers . . . . . . . . . . . . . . . . . 23 6.10 Pre-Configuration . . . . . . . . . . . . . . . . . . . 25 6.11 Opportunistic Security Associations . . . . . . . . . . 27 6.12 Prefix-Based Certificates . . . . . . . . . . . . . . . 27 6.13 Mobile and Correspondent Routers . . . . . . . . . . . . 28 7. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.1 Categorization of Techniques . . . . . . . . . . . . . . . 29 7.2 Static Configuration . . . . . . . . . . . . . . . . . . . 30 7.3 CGA-Based Optimizations . . . . . . . . . . . . . . . . . 30 7.4 Credit-Based Improvements . . . . . . . . . . . . . . . . 30 7.5 New Approaches To Certificates . . . . . . . . . . . . . . 31 8. Future Research . . . . . . . . . . . . . . . . . . . . . . 31 8.1 Research at Other Protocol Layers . . . . . . . . . . . . 32 8.2 Further Route Optimization Research . . . . . . . . . . . 32 8.3 Experimentation and Simulation . . . . . . . . . . . . . . 33 9. Security Considerations . . . . . . . . . . . . . . . . . . 34 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . 43 Vogt & Arkko Expires April 11, 2006 [Page 2] Internet-Draft MIP6 Route Optimization Enhancements October 2005 1. Introduction RFC 3775 [39] specifies mobility support for IPv6, or Mobile IPv6, which allows mobile nodes to migrate active transport connections and application sessions from one IPv6 address to another. For backward compatibility with correspondent nodes that do not implement the recommended mobility extensions, RFC 3775 introduces a "home agent", which proxies a mobile node at a permanent "home address". A roaming mobile node connects to the home agent through a bidirectional tunnel and can so communicate, from its local "care-of address", as if it was present at the home address. The mobile node keeps the home agent updated on its current care-of address. Signaling messages are protected through IPsec. In order to reduce the increased packet-propagation delays of bidirectional tunneling, RFC 3775 defines route optimization. This enables nodes to communicate on the direct path provided that the correspondent node can cache a binding between the mobile node's home address and current care-of address. The challenge with route optimization is that an administrative relationship between the mobile node and the correspondent node can generally not be presupposed. So how can the two authenticate and authorize the signaling messages that they exchange? Mobile IPv6 solves this problem by verifying a routing property of the mobile node. Specifically, the mobile node is checked to be reachable at its home address and current care-of address. This is called the "return-routability procedure". It takes place right before a mobile node registers a new care-of address with a correspondent node and is periodically repeated in case the mobile node does not move for a while. The advantage of the return-routability procedure is that it is lightweight and does not require pre-shared authentication material. It also requires no state at the correspondent node. On the other hand, the two reachability tests can lead to a handoff delay unacceptable for many real-time or interactive applications like voice over IP (VoIP) and video conferencing. Also, the security that the return-routability procedure guarantees might not be sufficient for security-sensitive applications. And finally, periodically refreshing a registration at a correspondent node implies a hidden signaling overhead that may prevent mobile nodes from hibernation during times of inactivity. Accordingly, a willingness to enhance Mobile IPv6 route optimization can be observed. This document describes and evaluates different route-optimization enhancement strategies on the basis of existing proposals. It is meant to provide a conceptual framework for further Vogt & Arkko Expires April 11, 2006 [Page 3] Internet-Draft MIP6 Route Optimization Enhancements October 2005 work, which was found to be inevitable in the context of route optimization. Many scientists volunteered to review this document. Their names are duely recorded in Section 2. Section 3 describes the security threats that route-optimization protocols need to take into account. Section 4 explains and analyzes how route optimization is realized in RFC 3775, and Section 5 identifies potential objectives for enhancement. Different enhancement strategies are discussed, based on existing proposals, in Section 6. Section 7 analyzes the different approaches, and Section 8 identifies opportunities for further research. Section 9 and Section 10 conclude the document. 1.1 A Note on Public Key Infrastructures Mobile IPv6 route optimization verifies a mobile node's authenticity through a routing property. An alternative is cryptographic authentication, which requires a binding between a node's identity and some sort of secret information. While some proposals suggest to install shared secrets into end nodes when possible (cf. Section 6.10), pre-configuration is not an option for general Internet use for scalability reasons. Authentication based on a public-key infrastructure (PKI) does not require pair-wise pre- configuration. Here, the secret information is the private component of a public/private key pair, and the binding between a node's identity and private key exists indirectly through the cryptographic properties of public/private key pairs and a binding between the identity and the public key. An authority trusted by both end nodes issues a certificate which effects this latter binding. Large-scale use of a PKI, however, was considered insuitable for mobility management due to the following reasons. o There are differing opinions on whether a PKI could scale up to hundreds of millions of mobile nodes. Some people argue they do, as there are already examples of certification authorities responsible for millions of certificates. But more important than the expected increase in the number of certificates would be a shift in application patterns. Nowadays, public-key cryptography is used only for those applications that require strong, cryptographic authentication. If it was used for mobility management as well, certificate checks would become mandatory for any type of application, leading to more checks per user. Busy servers with mobility support might not be reluctant to spent the processing resources required for this depending on the service they provide. o Revoked certificates are identified on Certificate Revocation Lists (CRLs), which correspondent nodes with mobility support would have to acquire from certification authorities. CRLs must Vogt & Arkko Expires April 11, 2006 [Page 4] Internet-Draft MIP6 Route Optimization Enhancements October 2005 be kept up to date, requiring periodic downloads. This and the act of checking a certificate against a CRL create overhead which some correspondent nodes might be unwilling to spend. o Certificate verification may take some time and hence interrupt ongoing applications. This can be disturbing from the user's perspective, especially when route optimization starts in the middle of a session, or the session is very short-term anyway. o The bigger a PKI grows, the more attractive it becomes as an attack target, endangering the Internet as a whole. o There is little experience with using home addresses as identifiers in the certificates. Although the home address could theoretically be placed into a certificate's Alternate Name field, the entities responsible for IP-address assignment and certification are usually not the same, and it may not be easy to coordinate the two. For these reasons, this document does not consider direct authentication of mobile nodes based on a PKI. Nevertheless, it does evaluate certificate-based techniques which make the problems identified above more tractable (cf. Section 6.12). 1.2 A Note on Source Address Filtering RFC 3775 uses care-of-address tests to probe a mobile node's presence at its claimed location. Alternatively, verification of care-of addresses may be based on infrastructure in the mobile node's local access network. For instance, the infrastructure can verify that the IP source addresses of all packets leaving the network are correct. "Ingress filtering" [49][47] provides this feature to the extent that it inspects the prefix of IP source addresses and ensures topological correctness. Network-access providers who use ingress filtering normally deploy the technique in their first-hop and site-exit routers. Similarly, ISPs may filter packets originating from a downstream network. Ingress filtering may eventually provide a way to replace care-of- address tests. But there are still a number of uncertainties today: o By definition, ingress filtering can prevent source-address spoofing only from those networks that do deploy the technique. As a consequence, ingress filtering needs to be widely, preferably universally, deployed in order to constitute Internet-wide protection. As long as an attacker can get network access without filters, all Internet nodes remain vulnerable. Vogt & Arkko Expires April 11, 2006 [Page 5] Internet-Draft MIP6 Route Optimization Enhancements October 2005 o There is little incentive for ISPs to deploy ingress filtering other than conscientiousness. Legal or regulatory prescription as well as financial motivation does not exist. A corrupt ISP might even have a financial incentive to not deploy the technique, if redirection-based DoS attacks using route optimization ever become possible and are exploited for financial gain. A similar issue was, e.g., observed with email spam. o Ingress filtering is most effective, and easiest to configure, at the first-hop router. However, since only prefixes are checked, the filters inevitably get less precise the further upstream they are enforced. This issue is inherent in the technique, so the best solution is checking packets as close to the originating nodes as possible, preferably in the first-hop routers themselves. o A popular implementation of ingress filtering is "Reverse Path Forwarding" (RPF). This technique relies on routes to be symmetric, which is oftentimes the case between edge networks and ISPs, but far less often between peering ISPs. Alternatives to RPF are either manual configured access lists, or dynamic approaches which are more relaxed, and thereby less secure, than RPF [47]. o Another problem with ingress filtering is multi-homing. When a router attempts to forward to one ISP a packet with a source- address prefix from another ISP, filters at the second ISP would block the packet. The IETF seeks to find a way around this [38]. For instance, one could tunnel the packet to the topologically correct ISP, or one could allow source-address changes by means of a locator-identifier split [23]. o Finally, RFC 3775 defines an Alternative Care-of Address option that mobile nodes can use to carry a care-of address within a BU outside of the IPv6 header. Such an address is not subject to inspection by ingress filtering and would have to be verified through other means [6]. Although these problems are expected to get solved eventually, there is currently little knowledge on how applicable and deployable, as a candidate for care-of-address verification, ingress filtering will be. High investments or administrative hurdles could prevent a large, preferably universal deployment of ingress filtering, which would hinder Internet-wide protection, as mentioned in the first bullet. For these reasons, this document does not consider ingress filtering as a viable alternative to care-of-address tests, although things may be different in the future. Vogt & Arkko Expires April 11, 2006 [Page 6] Internet-Draft MIP6 Route Optimization Enhancements October 2005 2. Acknowledgements This document was thoroughly reviewed, in alphabetical order, by Samita Chakrabarti, Francis Dupont, Thierry Ernst, Gerardo Giaretta, James Kempf, Rajeev Koodli, Gabriel Montenegro, Vidya Narayanan, and Fan Zhao. The authors wish to thank these folks for their valuable comments and suggestions. 3. Mobility-Related Security Threats Route optimization 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 current care-of address). A route optimization protocol must incorporate appropriate measures to prevent misuse of this ability. There is a number of threats that emanate from unprotected route optimization, all of which are explained and analyzed in detail in [20]. Below is a high-level categorization of mobility-related attacks, confined to the information necessary to understand the remainder of this document. Impersonation attacks An attack in which the perpetrator claims to own a victim's home address and binds this to a care-of address of its own choice. This allows the attacker to impersonate the victim to the victim's correspondent node without being on the path between those peers. This is called "space-shifting". The attacker can also install the illegitimate binding well before it eventually launches the attack. This is accordingly known as "time-shifting". There are different flavors of impersonation attack in the context of mobility. The attacker can communicate on behalf of the victim without involving the victim. The attacker can eavesdrop on packets exchanged between the victim and its correspondent node without interacting, or it can modify those packets and act as a man in the middle. Finally, the attacker can simply divert the victim's packets to an arbitrary, possibly non-existent IP address so that attempts of the victim and its peer to reach each other are without effect. Resource-exhaustion attacks An attack in which the perpetrator exploits memory or processing resources at a victim which the mobility protocol requires the victim to allocate. The victim could be a mobile node, a home agent, or a stationary correspondent node implementing mobility support. One example of a resource-exhaustion attack is a flood of bogus Binding Update messages that the attacker sends to a mobility-enabled, albeit stationary media server. Vogt & Arkko Expires April 11, 2006 [Page 7] Internet-Draft MIP6 Route Optimization Enhancements October 2005 Flooding attacks An attack in which the perpetrator redirects its own packets to a victim in order to clog the victim's network access. In contrast to resource-exhaustion attacks, flooding attacks primarily target network attachment rather than memory or processing resources. Yet, the adverse effects on the ability to communicate can be very similar in both attack types. 4. Mobile IPv6 Route Optimization Mobile IPv6 route optimization requires the mobile node to bind its current care-of address to its home address at both the home agent and the correspondent node. This is called a "home registration" and a "correspondent registration", respectively. The following is a brief summary and analysis of the registration processes as a minimum basis for deriving objectives for enhancement. Details on the Mobile IPv6 protocol can be found in [39]; [20] provides a more elaborate security analysis. 4.1 Protocol Overview Figure 1 illustrates the home and correspondent registration. The former is a two-way handshake between the mobile node, which sends a Binding Update message with its home and current care-of address, and the home agent, which responds with a Binding Acknowledgement message. Home registrations are protected through IPsec, typically using ESP authentication and encryption. Establishment of a IPsec security associations requires external knowledge for mutual authentication. This may be pre-configured into mobile nodes and home agents as it is assumed that the nodes have an administrative relationship. Vogt & Arkko Expires April 11, 2006 [Page 8] Internet-Draft MIP6 Route Optimization Enhancements October 2005 Mobile Correspondent Node Home Agent Node | | | | | | ~~+~~ Handover | | | | | |--Binding Update---------->| | | | | | | | |<-------------Binding Ack--| | | | | | | | |--Home Test Init---------->|-------------------------->| |--Care-of Test Init----------------------------------->| | | | | | | |<--------------------------|<---------------Home Test--| |<----------------------------------------Care-of Test--| | | | | |--Binding Update-------------------------------------->| | | | | |<-----------------------------------------Binding Ack--| | | Figure 1: Mobile IPv6 Registration Procedure Pre-configuration is impossible for general Internet use, however, so correspondent registrations must be protected differently. The key observation is that, for the purpose of Mobile IPv6 route optimization, authentication boils down to verifying that a mobile node is reachable at its home address, by which transport protocols and applications evenually identify the mobile node. Successful authentication together with a proven reachability at the current care-of address authorizes the mobile node to bind its home address to that care-of address. This implies two address tests, the "return-routability procedure", which the mobile node initiates with the Home Test Init and Care-of Test Init messages. The correspondent node responds by returning two tokens, one with the Home Test message, another with the Care-of Test message. The Home Test Init and Home Test messages are sent via the home address. An IPsec tunnel between the mobile node and the home agent, based on the existing security association, protects these messages part-way. The Care-of Test Init and Care-of Test messages take the direct path and are consequently unprotected. Finally, the mobile node derives a key from both received tokens and and sends to the correspondent node a Vogt & Arkko Expires April 11, 2006 [Page 9] Internet-Draft MIP6 Route Optimization Enhancements October 2005 Binding Update message authenticated with that key. The correspondent node returns a Binding Acknowledgement message. According to Figure 1, the mobile node awaits a successful home registration before it initiates the correspondent registration. In contrast to such "conservative" behavior, a more "optimistic" approach is to execute the home registration and the return- routability procedure in parallel [56]. The correspondent node does not need to explicitly store the tokens which it sends to the mobile node during the return-routability procedure. Accillary information is communicated in the protocol so that it can re-calculate the tokens. Correspondent registrations are valid for up to seven minutes after which they must be refreshed. There is no upper lifetime for home registrations. 4.2 Analysis of Correspondent Registrations The two address tests increase the latency of correspondent registrations. Even though the return-routability procedure may be initiated in parallel with the home registration, it still takes longer than the home registration, typically due to the home-address test, and so has an undesired effect on applications. Conservative behavior avoids a useless return-routability procedure in case the home registration fails. This comes at the cost of an additional round trip when the home registration is successful. Optimistic behavior requires one round-trip time of signaling time less, but the return-routability procedure will be in vain should the corresponding home registration fail. The return-routability procedure prevents impersonation attacks unless the attacker is on the path between its victim and the victim's correspondent node (in the case of a stationary victim) or from the correspondent node to the victim's home agent (if the victim is mobile). In case the attacker has access to the critical path, it can spoof a Home Test Init message on behalf of the victim and eavesdrop on the returning Home Test message. Then, the impersonator can send the victim's peer a Care-of Test Init message with a care-of address through which it is itself reachable. The attacker thus learns the tokens necessary to generate an authenticated Binding Update message on behalf of the victim. However, this vulnerability to perpetrators on the routing path conforms with an objective to prevent new attack types introduced by mobility support, but to disregard threats that already exist in an Internet without mobility support. Similarly, the return-routability procedure does not protect against redirection-based flooding attacks if the attacker is already on the Vogt & Arkko Expires April 11, 2006 [Page 10] Internet-Draft MIP6 Route Optimization Enhancements October 2005 path between the victim and the correspondent node. Such an attacker can launch a flooding attack already without the help of Mobile IPv6, simply by establishing an upper-layer connection on behalf of the victim. For instance, an on-path attacker can effect a large file download from an FTP server, using its victim's IP address during the initial TCP handshake. Periodic correspondent registrations ensure that a mobile node remains reachable at both its home and care-of addresses. This prevents space- and time-shift attacks. A correspondent node does not need to explicitly store any information during the return-routability procedure. This saves the correspondent node from attacks against memory resources, but may lead to malicious exhaustion of its processing capacities. The computational overhead necessary to re-calculate a token is rather moderate, however. This allows the correspondent node to implement its own resource-management policies for situations of increased workload. 5. Objectives for Enhancement This section identifies three goals for enhancement of RFC-3775 route optimization: reduced signaling latency, higher security, lower signaling overhead, increased protocol robustness, additional functionality. The objectives are herein discussed from a requirements perspective; the technical means to reach the objectives is not considered, nor is the feasibility of achieving them. 5.1 Latency Optimizations A disadvantage of route optimization is that a mobile node must run a return-routability procedure before it can inform the correspondent node about its new care-of address. Therefore, a correspondent registration takes more time than a home registration. It consumes, at a minimum, one and a half round-trip times until the correspondent node receives the BU, assuming that the mobile node performs the home-address and care-of-address tests in parallel. An additional one-way time is needed until the first packet from the correspondent node, and possibly an optional BA, arrives at the new care-of address. Note that the CoTI, CoT, BU are transmitted on the direct path between the mobile node and the correspondent node, whereas the HoTI and HoT go through the home agent. The actual latency of the return-routability procedure is governed by the path with a longer round-trip time. Note that the delay for the return-routability procedure is sometimes estimated as 1.5 round-trip times. This includes an additional one- Vogt & Arkko Expires April 11, 2006 [Page 11] Internet-Draft MIP6 Route Optimization Enhancements October 2005 way time to compensate for the longer delay of the HoTI/HoT exchange, which goes through the home agent. However, this simple estimation does not reflect situations in which the home agent is far away or on-path. The analysis in this document therefore uses a single round-trip time for the return-routability procedure and differentiates between the two address tests where necessary. Direct communications to the correspondent node can optimistically start right after the BU has been sent (i.e., once the return- routability procedure is complete). But if the mobile node requests a BA, communications are usually delayed until the BA is received. 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 initiating the correspondent registration. Depending on the type of application, the above delays can be an issue. Interactive, real-time applications, like voice over IP, are an example where the delays may cause perceptible quality degradations. Even fast bulk-data transfer can be affected if the lack of packets during the movement period is interpreted as congestion and leads to a new TCP slow start. There appears to be general consensus that faster mechanisms for route optimization are needed. Note that the handover delay from an application's perspective is not just the latency of the IP mobility mechanism, but also includes delays at the IP layer and the link layer. The delays introduced by the rest of the stack can be significant (cf. Section 8.1). 5.2 Security Enhancements The return-routability procedure is lightweight and prevents mobility-related attacks reasonably well. The level of security it provides is sometimes insufficient, however. One may in particular attempt to limit what on-path attackers can do. Attackers that operate in the same networks as one of the communication end points are also a threat that one may want to avoid. There are existing proposals that offer higher security in Mobile IPv6 [30] and in other mobility-management protocols such as HIP [28]. However, even with better security for mobility management, the Internet as a whole cannot become any safer than the non-mobile Internet. For instance, on-path attackers can cause denial of service, or inspect and modify cleartext packets, already without Vogt & Arkko Expires April 11, 2006 [Page 12] Internet-Draft MIP6 Route Optimization Enhancements October 2005 misusing a mobility-management protocol. Applications that require strong security are therefore generally advised to end-to-end mechanisms such as IPsec or TLS. But even communications that are protected on an end-to-end basis are vulnerable to denial of service. Better route-optimization security may become necessary in the future, if technological improvements remove some of the existing mobility-unrelated vulnerabilities of the Internet. For instance, the use of Secure Neighbor Discovery [24] in a network where one of the communication end points resides can remove some of the existing threats. 5.3 Signaling Optimizations As mentioned in Section 4, correspondent registrations have a maximum lifetime of seven minutes and must be refreshed in case they are not updated to a different care-of address in the meantime. The reason for this is to reasonably reduce the window of vulnerability to time- and space-shift attacks, where an attacker eavesdrops on unencrypted authentication material exchanged during the return-routability procedure and launches an impersonation attack at a later time and from a different, probably more amenable location. Periodic re- registrations limit the likelihood and feasibility of such off-path attacks, since the attacker would have to get back on path whenever the authentication material is due to be refreshed. A calculation in [2] shows that the seven-minute refreshment interval implies a signaling overhead of 7.16 bits per second when a mobile node communicates with a stationary node. The overhead doubles if both peers are mobile. On one hand, this signaling overhead is certainly negligible when the nodes actually communicate. On the other hand, it may cause problems for mobile nodes that are inactive and stay at the same location for a while, but still want to have route optimization ready with some correspondent node. These nodes typically prefer to go to standby mode to conserve battery power. Finally, the periodic refreshments consume a fraction of the wireless bandwidth that one could use more efficiently. This shows that an optimization for reduced signaling would be benefical and could have an impact on the deployment of Mobile IPv6. 5.4 Robustness Enhancements Route optimization has the potential to allow the mobile node and correspondent node to continue communication during a period of home- agent unavailability. This could be due to failure of the home agent, e.g. The protocol defined in RFC 3775 does not achieve this independence from the home agent because correspondent registrations involve the home agent and are limited in their lifetime (cf. Vogt & Arkko Expires April 11, 2006 [Page 13] Internet-Draft MIP6 Route Optimization Enhancements October 2005 Section 4). 5.5 Functionality Enhancements As per RFC 3775, a mobile node's home address and current care-of address are carried in all route-optimized packets. The course of the mobile node is therefore trackable, both by the correspondent node as well as by a third party. 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. A workaround is to fall back to bidirectional tunneling when location privacy becomes an issue. Packets that carry the mobile node's care-of address are then only transferred between the mobile node and the home agent, and they can be encrypted through IPsec ESP [36][14] on that path. However, the mobile node may have to periodically re-establish its IPsec security associations so that it cannot be tracked through its SPIs. Scenarios where location privacy is desired are one example where Mobile IPv6 proves insufficient. Early improvement efforts have already started in this area [11][5][26][27]. There may also be other deployment scenarios where the applicability of Mobile IPv6 is limited and could be extended. 6. Enhancements Toolbox This section introduces a number of techniques, a "toolbox", that can be used in the construction of an efficient and secure route- optimization protocol. The section starts with the standard mechanisms used in RFC 3775 and continues with additional techniques that have been proposed as enhancements or alternatives. It is important to mention that many enhancement techniques are insufficient or insecure when applied on their own, because the scope of each of them is usually limited to a certain sub-issue. It is the combination of a set of techniques that makes an efficient and secure route-optimization mechanism possible. Different techniques also have different trade-offs with respect to, say, universal applicability versus efficiency. 6.1 IP-Address Tests RFC 3775 uses IP-address tests to ensure that a mobile node is live and on the path to a specific destination address: The home-address test provides evidence that the mobile node owns the home address it wants to use; the care-of-address test serves to preventing flooding attacks related to spoofed care-of addresses. The use of two IP- address tests requires four messages. Both tests can be performed in Vogt & Arkko Expires April 11, 2006 [Page 14] Internet-Draft MIP6 Route Optimization Enhancements October 2005 parallel, so they can be completed in one round-trip time. As specified in RFC 3775, IP-address tests can be stateless for the correspondent node, making their use in denial-of-service attacks harder. A home-address test can most efficiently be initiated by the mobile node itself, as the correspondent node can thus delay state creation until the mobile node has authenticated. Yet, conceptually, either the mobile node or the correspondent node could start a care-of- address test. RFC 3775 uses mobile-node-initiated IP-address tests, whereas [8] proposes a way to have the correspondent node send the first message. [13] follows this latter approach as well. The correspondent-node-driven approach has advantages when authentication is done through other means than a home-address test. Since RFC 3775 does use the home-address test for authentication, letting the mobile node initiate both IP-address test allows for more efficient parallelization. IP-address tests are a zero-configuration approach that is independent of ancillary infrastructure. The subsequent disadvantage is that IP-address tests can only guarantee that a peer is on the path to the probed IP address, not that the peer truly owns this IP address. On the other hand, the types of attacks that an on-path attacker can do with route optimization are the same that an on-path attacker can do without route optimization anyway, so there is actually no significant new threat. 6.2 Protected Tunnels RFC 3775 protects part of the signaling communications between a mobile node and its home agent through an authorized and, optionally, encrypted tunnel. This prevents other nodes on the path between the mobile node and the home agent---potentially eavesdroppers in the mobile node's wireless access network---from seeing a home-address test. Given the starting point that we cannot assume a pre-existing end-to- end security relationship between the mobile node and the correspondent node, this protection exists only for the mobile node's side. In case the correspondent node is stationary, the path between the home agent and the correspondent node remains unprotected. An attacker on that path can still perform attacks, but these attacks are similar to those that an on-path attacker can anyway do without route optimization. So, as with IP-address tests, the intent here is not to introduce any significant new threat to the Internet. The same is true in case the correspondent node is mobile. It then has its own home agent, and it is the path between the two home agents that stays unprotected. Vogt & Arkko Expires April 11, 2006 [Page 15] Internet-Draft MIP6 Route Optimization Enhancements October 2005 6.3 Optimistic Behavior RFC 3775 leaves quite a bit of freedom for a mobile node with respect to scheduling signaling and data packets. An optimistic mobile node can initiate the return-routability procedure right after sending the BU to its home agent, even before it has gotten a BA back. The mobile node must wait for the home agent's BA before it can send a BU to the correspondent node. However, the mobile node may start sending data packets to the correspondent node right after it has sent this BU without having to wait for a BA from the correspondent node. The drawback of the described optimistic behavior is that a dropped, re-ordered, or rejected BU can cause data packets to be dropped. Such packet loss would also have an effect on pessimistic signaling, however. As a result, further experimentation and simulation may be needed to quantify to the effects of optimistic techniques under different conditions. 6.4 Proactive IP-Address Tests Let the post-movement time period during which a mobile node and correspondent node cannot fully communicate be the "critical phase". The critical phase spans a home registration and a correspondent registration including a return-routability procedure. One technique to shorten the critical phase is to move some of these tasks to an earlier stage. In particular, the home-address test can be done proactively before a handover, instead of doing it afterwards, without violating the base specification. This is discussed in [31]. A Home Keygen Token is generally valid for 3.5 minutes. Consequently, the mobile node must initiate a proactive home-address test at least every 3.5 minutes if it seeks to have available a fresh Home Keygen Token at all times. This is especially helpful if the mobile node cannot foresee the next 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. Note, however, that the mobile node must re-initiate the correspondent registration anyway-- and, thus, the home-address test--after the maximum binding lifetime of seven minutes. Link-layer triggers can therefore save the mobile node at most every second home-address test. The frequency of proactive home-address tests could be reduced by additional techniques such as [2]. Another optimization possibility is performing a care-of address test Vogt & Arkko Expires April 11, 2006 [Page 16] Internet-Draft MIP6 Route Optimization Enhancements October 2005 before the movement. This is possible only if the mobile node is capable of attaching to two networks simultaneously. 6.5 Concurrent IP-Address Tests If one assumes that a mobile node can attach to only a single network at a time, executing the care-of-address test proactively before a handover is not an option. However, one may authorize a mobile node to start using a new care-of address right after the handover, without doing the care-of-address test first, with the restriction that a care-of-address test be initiated rightaway. The peers could then already exchange packets through the new care-of address while the test is being executed. In recent literature, one refers to the care-of address as "unverified" when the correspondent node does not yet know the result of the concurrent care-of-address test, and one calls it "verified" thereafter. The lifetime of the associated binding can be limited to a few seconds as long as the care-of address is unverified, and it can be extended once it becomes verified. It is important to understand that concurrency is legitimate only for care-of-address tests. In contrast, home-address tests are done for mobile-node authentication, which must be done before any signaling messages are accepted. Authentication guarantees that only the legitimate mobile node can create or update a binding pertaining to its home address. However, both IP-address tests are in general simultaneously performed during the critical handover period, and one can expect the home-address test to have a longer latency than the care-of-address test. The full benefit of eliminating the care-of- address tests from the critical handover period by means of concurrency can therefore only unfold if some other mechanism is used to move the home-address tests out of the critical handover period as well. For instance, one can do the home-address tests proactively before a handover as suggested in Section 6.4, or one may use cryptographically generated home addresses as proposed further down in Section 6.9. Figure 2 illustrates concurrent care-of-address tests as used in [31]. Vogt & Arkko Expires April 11, 2006 [Page 17] Internet-Draft MIP6 Route Optimization Enhancements October 2005 Mobile Correspondent Node Home Agent Node | | | | | | |--Home Test Init (HoTI)--->|-------------------------->| | | | | | | |<--------------------------|<---------Home Test (HoT)--| | | | | | ~~+~~ Handover | | | |--Early Binding Update (EBU)-------------------------->| |<==========Resume Upper-Layer Communications==========>| |--Care-of Test Init (CoTI)---------------------------->| | | | | |<----------------------------Early Binding Ack (EBA)---| |<---------------------------------Care-of Test (CoT)---| | | | | |--Binding Update (BU)--------------------------------->| | | | | |<------------------------------------Binding Ack (BA)--| | | Figure 2: Concurrent Care-of Address Tests Concurrent care-of-address tests were first proposed in [31] where they were combined with proactive home-address tests. In [31], as soon as the mobile node has configured a new care-of address after a handover, it sends to the correspondent node an Early Binding Update (EBU) message. The mobile node signs the EBU with a message- authentication code keyed only with the Home Keygen Token that the mobile node has previously retrieved through a proactive home-address test. Upon reception of the EBU, the correspondent node creates a tentative binding for the new care-of address, which can then be used while the care-of-address test is being executed. When the care-of- address is done, the mobile node sends a standard BU to the correspondent node, concluding the registration procedure. From the reception of an EBU to the reception of the corresponding standard BU, the correspondent node cannot be sure whether the mobile node is actually present at the claimed new care-of address. A malicious node may misuse this property to redirect packets to a third party's IP address during this phase of uncertainty. Under Vogt & Arkko Expires April 11, 2006 [Page 18] Internet-Draft MIP6 Route Optimization Enhancements October 2005 many circumstances, this will not be acceptable even if the lifetime for an unverified care-of address is tentative only, and there needs to be external protection. Techniques like those described in Section 6.7 or Section 6.8 can help. 6.6 Diverted Routing Given that the per-movement signaling takes some time, a mobile node can optionally request its traffic to be routed through its home address while this signaling is being completed. The performance impact of this technique depends on the length of the critical phase as well as on the capacity and latency of the direct path and the path through the home agent. With respect to the packets that the correspondent node sends, the following analysis can be made. The correspondent node does not know that the mobile node has moved until it has been told. It continues to send packets to the mobile node's old care-of address until that time. These packets are usually lost and must be retransmitted by upper-layer mechanisms. In addition, even the request to delete or deactivate a binding requires some security-related signaling to prevent misuse by unauthorized nodes. Zero packet loss can generally only be achieved through local repair techniques in the mobile node's access network, or if the mobile node can simultaneously attach to two IP networks. Once the correspondent node knows that the old care-of address is stale, it can send further packets to the home address. If one assumes that the correspondent registration for the new care-of address involves messages through the home agent, it is obvious that at least some of these packets reach the mobile node before the new binding is set up. After all, signaling and data packets travel the same path. It depends on the capacity and latency of the path through the home agent relative to the latency of the direct path for how long the correspondent node should continue to send packets to the home address. If the former path has a high latency, it might be better to queue some of the packets until the correspondent registration is complete and packets can be directly sent to the mobile node. 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 packets that the mobile node sends is similar: Although the mobile node knows immediately that it has moved, RFC 3775 does not allow the mobile node to route-optimize packets from new care-of address until it has formally updated the correspondent Vogt & Arkko Expires April 11, 2006 [Page 19] Internet-Draft MIP6 Route Optimization Enhancements October 2005 node about the new care-of address. Of course, the mobile node may buffer packets until the correspondent registration is done so that no packets get lost. Diverted routing appeared originally in [31] and has since been used also in [9]. 6.7 Credit-Based Authorization As described in Section 6.5, handover latency may be reduced by already using a new care-of address while the care-of-address test is in progress. The prerequesite is that sufficient protection is provided against redirection-based third-party flooding. One way of doing this is through Credit-Based Authorization. Credit-Based Authorization for concurrent care-of-address tests prevents illegitimate packet redirection until the validity of the address has been established. This is accomplished based on the following three hypotheses: 1. A flooding attacker typically seeks to somehow multiply the packets it generates itself for the purpose of its attack because bandwidth is an ample resource for many attractive victims. 2. An attacker can always cause unamplified flooding by sending packets to its victim directly. 3. Consequently, the additional effort required to set up a redirection-based flooding attack would pay off for the attacker only if amplification could be obtained this way. On this basis, rather than eliminating malicious packet redirection in the first place, Credit-Based Authorization prevents any amplification that can be reached through it. This is accomplished by limiting the data a correspondent node can send to an unverified care-of address of a mobile node by the data recently received from that mobile node. (See Section 6.5 for a definition on when a care-of address is verified and when it is unverified.) Redirection- based flooding attacks thus become less attractive than, e.g., pure direct flooding, where the attacker itself sends bogus packets to the victim. Figure 3 illustrates Credit-Based Authorization: The correspondent node measures the bytes received from the mobile node. When the mobile node changes to a new care-of address, the correspondent node labels this address UNVERIFIED and sends packets there as long as the sum of the packet sizes does not exceed the measured, received data volume. The mobile node's reachability at the new care-of address meanwhile gets verified. When the care-of-address test completes with success, the correspondent node relabels the care-of address from UNVERIFIED to VERIFIED. As of then, packets can be sent to the Vogt & Arkko Expires April 11, 2006 [Page 20] Internet-Draft MIP6 Route Optimization Enhancements October 2005 new care-of address without restrictions. When insufficient credit is left while the care-of address is still UNVERIFIED, the correspondent node stops sending further packets until address verification completes. +-------------+ +--------------------+ | Mobile Node | | Correspondent Node | +-------------+ +--------------------+ | | address |----------------------->| credit += size(packet) verified | | |----------------------->| credit += size(packet) |<-----------------------| don't change credit | | + address change | address |<-----------------------| credit -= size(packet) unverified |----------------------->| credit += size(packet) |<-----------------------| credit -= size(packet) | | |<-----------------------| credit -= size(packet) | X credit < size(packet) ==> drop! | | + address change | address | | verified |<-----------------------| don't change credit | | Figure 3: Credit-Based Authorization The correspondent node ensures that the mobile node's acquired credit gradually decrease over time. Such "credit aging" prevents a malicious node from building up credit at a very slow speed and using this, all at once, for a severe burst of redirected packets. Allocating a mobile node's credit based on the packets that the mobile node sends and reducing the credit based on packets that the mobile node receives is defined as "CBA Inbound Mode". (The correspondent node is in control of credit allocation, and it computes the credit based on inbound packets received from the mobile node.) A nice property of CBA Inbound Mode is that it does not require support from the mobile node. The 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. With applications that send comparable data volumes into both directions, CBA Inbound Mode works fine. On the other hand, in Inbound Mode, CBA may prevent the mobile node from collecting the Vogt & Arkko Expires April 11, 2006 [Page 21] Internet-Draft MIP6 Route Optimization Enhancements October 2005 amount of credit it needs for a handover when applications with asymmetric traffic patterns are in use. For instance, file transfers and media streaming are characterized by high throughput towards the client, typically the mobile node, and comparably little throughput towards the serving correspondent node. To better accommodate such applications, "CBA Outbound Mode" was designed. With CBA Outbound Mode, credit allocation is based on packets that the mobile node receives from the correspondent node rather than on packets that the mobile node sends. New credit is allocated while the mobile node's current care-of address is verified; existing credit is used up while the care-of address is unverified. Thus, it is the data flow from the correspondent node to the mobile node that is responsible for both credit allocation and reduction, resolving the issue with applications producing asymmetric traffic patterns. It is less obvious for CBA Outbound Mode why it outrules flooding- attack amplification than it is for CBA Inbound Mode. The key observation is that a mobile node invests comparable effort for packet reception as for packet transmission in terms of bandwidth, memory, and processing capacity. It is therefore legitimate to give a mobile node credit for packets that it has received and processed. The question is, though, how the correspondent node can determine how many of the packets sent to a mobile node are actually received and processed by that mobile node. Relying on transport-layer acknowledgements is not an option as such messages can easily be faked. CBA Outbound Mode hence defines its own feedback mechanism, Care-of Address Spot Checks, which is robust to spoofing. With Care-of Address Spot Checks, the correspondent node periodically tags packets that it sends to the mobile node with a random, unguessable number, a so-called Spot Check Token. When the mobile node receives a packet with an attached Spot Check Token, it buffers the token until it sends the next packet to the correspondent node. The Spot Check Token is then included in this packet. Upon reception, the correspondent node verifies whether the returned Spot Check Token matches a token recently sent to the mobile node. New credit is allocated in proportion to the ratio between the number of successfully returned Spot Check Tokens and the total number of tokens sent. This implies that new credit is approximately proportional to the fraction of packets have made their way at least up to the mobile node's IPv6 stack. The preciseness of Care-of Address Spot Checks can be traded with overhead through the frequency with which packets are tagged with Spot Check Tokens. An interesting question is whether CBA Outbound Mode could be misused by an attacker that has an asymmetric connection to the Internet. Wide-spread digital subscriber lines (DSL), for instance, typically have a much higher download rate than upload rate. The limited Vogt & Arkko Expires April 11, 2006 [Page 22] Internet-Draft MIP6 Route Optimization Enhancements October 2005 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. The reason why this has so far not been considered an issue is that, in order to build up enough credit at the remote end, the attacker would first have to expose itself to the same packet flood that it could then redirect towards the victim. 6.8 Heuristic Monitoring Heuristic approaches to protect concurrent care-of-address tests are conceivable as well. For instance, one may consider a lifetime limit for unverified 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 other side. On the other hand, it should not have a negative impact on a fair-minded mobile node's communications. Another problem with heuristics is that they are usually reactive. The correspondent node can only respond to misbehavior after it appeared. If the response comes quickly, attacks may simply not be worthwhile. But premature actions should be avoided, of course. One must also bear in mind that an attacker may be able to use different home addresses, and it is in general impossible for the correspondent node to see that the set of home addresses belongs to the same node. The attacker may also use multiple correspondent nodes for its attack in an attempt to amplify the result. 6.9 Crypto-Based Idendifiers A crypto-based identifier (CBID) is an identifier with a strong cryptographic binding to the public component of its owner's public/ private key pair [51]. CBIDs offer three main advantages: First, spoofing attacks against a CBID are much harder than attacks against a non-cryptographic identifier like a domain name or a Mobile IPv6 home address. Though an attacker may always create its own CBID, it is unlikely to find a public/private key pair that produces someone else's. Second, CBIDs fulfill exactly the purpose that certificates do, so they do not depend on a certification infrastructure. Third, CBID can be used to bind a public key to an IP address, in which case they are called Cryptographically Generated Addresses (CGA) [52][53]. A CGA is syntactically just an ordinary IPv6 address. It has a standard routing prefix and an interface identifier generated from a Vogt & Arkko Expires April 11, 2006 [Page 23] Internet-Draft MIP6 Route Optimization Enhancements October 2005 hash on the CGA owner's public key and some additional parameters. A CGA allows the owner to assert a claim on its address: It can sign a to-be-authenticated message with its private key and attach its public key along with the parameters necessary to recompute the CGA. The recipient of this message can then verify whether the address is correct. Many applications are conceivable where CGAs can be advantageous. In Mobile IPv6, CGAs can bind a mobile node's home or care-of address to its public key. CGAs were originally described in [52] and in [53], and they have later been used in [30], [42], [9], and others. It should be mentioned that, although CGAs are a replacement for the home-address test in most cases, at least one initial home-address test must be made. This ensures that the network prefix of the home address is correct, and that the mobile node is really reachable at this address. Being able to omit the home-address test in subsequent correspondent registrations allows the peers to communicate independently of home-agent availability. Since only the interface identifier of a CGA is cryptographically generated, flooding a network or a link is still an issue. As a result, CGAs should be employed together with a care-of-address test in scenarios where redirection-based flooding attacks are a concern. An initial home-address test is typically required, too, in order to avoid that the deletion of a binding causes a flood upon a faked home address. One limitation of CGAs compared to other types of CBIDs is that the hash on the CGA owner's public key can only be 62 bits long. The rest of the address is occupied by a 64-bit routing prefix as well as the universal/local and individual/group bits. A brute-force attacker might thus be able to find a public/private key pair that produces a certain CGA. It could then claim ownership over this CGA. The threat can usually be contained by including the address prefix in the hash computation, so that an attacker, in case it did find the right public/private key pair, could not form CGAs for multiple networks from it. To resolve collisions in case CGAs are used as care-of addresses, a collision count is part of the input to the CGA hash function. Increasing the collision count by one changes the result of the hash function, so new CGAs can be successively tried until an unused one is found. On the other hand, the collision count also helps an attacker in faking a CGA: It may use the same private/public-key pair to efficiently generate multiple CGAs. For this reason, the collision count is usually limited to a few bytes only. Higher security can be achieved through longer CBIDs. For instance, Vogt & Arkko Expires April 11, 2006 [Page 24] Internet-Draft MIP6 Route Optimization Enhancements October 2005 a node's primary identifier in the "Host Identity Protocol" (HIP) [28] is a 128-bit hash on the node's public key. It is used as an IP-address replacement at stack layers above IP. This CBID is not routable, so there needs to be some external location mechanism if a node wants to contact a peer of which it only knows the identifier. 6.10 Pre-Configuration The return-routability procedure was designed for communication peers that do not share an a-priori security association. In order to thwart off-path attacks nonetheless, the procedure can establish only very short-living security associations. However, in certain, restricted scenarios, it may be possible to pre-configure mobile and correspondent nodes with security associations. Such security associations can have much longer lifetimes because pre-configuration is inherently more secure than the plaintext token exchange from the return-routability procedure. Pre-configuration has two major benefits. The first one is strong, cryptographic authentication and encryption, which can be applied to both signaling and data packets. The second advantage is lower signaling delay, because the additional round-trip time otherwise needed for the return-routability procedure can be spared. The obvious disadvantage of pre-configuration is its limited applicability. It is important to recognize the necessity to unambiguously bind a security association to the home address that it is to protect. With regards to the return-routability procedure, this binding is realized by routing the HoTI and HoT through the home address. In the case of a pre-configured security association, the association must be related to the home address as part of the configuration. Note that this affects both secret-key and public-key cryptography. Two proposals for pre-configuration are currently under discussion in the IETF as optional enhancements to RFC 3775. [19] re-uses most from the standard authentication and authorization procedure defined in RFC 3775. The only difference is that mobile nodes are endowed with the information they need to compute Home and Care-of Keygen Tokens themselves rather than having to obtain them through the return- routability procedure. [7] replaces the standard RFC-3775 concepts with IPsec and the Internet Key Exchange (IKE) protocol. From a technical standpoint, a pre-configured security association can only replace a home-address test, not a care-of-address test. After all, a correspondent node cannot verify, based on the association alone, whether a mobile node is actually present at the announced care-of address. The problem is circumvented in [19] by Vogt & Arkko Expires April 11, 2006 [Page 25] Internet-Draft MIP6 Route Optimization Enhancements October 2005 postulating that the correspondent node has sufficient trust in the mobile node to believe that the care-of address is correct. However, this assumption discourages the use of pre-configuration in scenarios where such trust is unavailable. For instance, a mobile-phone operator may be able to configure subscribers with secret keys for authorization to a particular service, but it may not be able to vouch that all subscribers use this service in a trustworthy manner. And even if peers initially trust each other, subsequently one or the other can be infected with malware and become untrustworthy. Another way to avoid the problem of care-of-address verification is to rely on access networks to filter out packets with incorrect IP source addresses (cf. Section 1.2). This approach is taken in [7]. However, the problem with local filtering is that it must be deployed everywhere an attacker may possibly access the Internet in order to be fully protective. Otherwise, an attacker can always find a place from where a spoofing attack is possible, endangering IP nodes anywhere. As things stand, the assumption that deployment of filtering techniques be universal is speculative. Both of the above two assumptions can be eliminated through care-of- address tests, facilitating the use of pre-configuration in spite of lacking trust relationships or the existence of access networks without local filtering techniques. Of course, using a care-of- address test partly vitiates the handover-latency improvement that can be reached otherwise. But there may still be a positive impact on handover latency, because pre-configuration eliminates the triangular home-address test through the home agent, whereas the care-of-address test uses the direct, and typically faster, path between the communicating nodes. For increased performance, a concurrent care-of-address test can be used in combination with credit-based authorization or heuristic monitoring. It should also be noted that pre-configuration facilitates stronger authentication mechanisms than the return-routability procedure, and thus the use of route optimization may become more suitable for applications with high security requirements. That said, it seems like a good idea to make the pre-configuration protocol customizable to different environments. Is there a small group of people who trust each other? Then group members are unlikely to spoof care-of addresses, and the care-of-address test might be omitted. Or is the group of users large and users are primarily unknown to each other like the customer base of a big ISP? Then, proper authentication does usually not imply trust, and it is infeasible to use pre-configured keys without checking a mobile node's reachability. Traceability techniques are not necessarily 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. Vogt & Arkko Expires April 11, 2006 [Page 26] Internet-Draft MIP6 Route Optimization Enhancements October 2005 6.11 Opportunistic Security Associations An intermediate approach between short-term security associations from the return-routability procedure on one hand, and static security associations available via pre-configuration on the other, is to set up an "opportunistic", medium-term security association upon first contact. Subsequent signaling can then be unambiguously bound to the initial contact. Such security associations can be used over a longer period of time than those afforded by the return- routability procedure. On-demand security associations for IPsec are traditionally established by executing IKE between two peers. This works well when the negotiated keys are securely bound to the entity that they are to protect. However, the to-be-protected entity in Mobile IPv6 is a plain IPv6 home address, which is syntactically indistinguishable from other IPv6 addresses. Given that no direct authentication between the peers is generally feasible, there is no way for a mobile node to prove possession of its home address either. This would allow an attacker to do the IKE exchange pretending to own an arbitrary victim's IP address, and to at will redirect the victim's traffic from that time on. Although the attacker would have to be on the path between the victim and the correspondent node while running IKE, it could move off the path once the keys have been exchanged. As the victim lacks the keys, it cannot even re-claim its IP address. As a result, opportunistic security associations must be bound to the right home addresses through some additional technique when used in the context of Mobile IPv6. For instance, they can be combined with an initial, one-time home-address test, or IKE can be run through the home address. Another way is using CGAs as proposed in [9]. No matter how they are secured, opportunistic security associations cannot be leveraged to prove the correctness of a care-of address. They hence fail to solve the problem with redirection-based flooding attacks, and should only be applied in conjunction with care-of- address tests. Semi-permanent security associations were first developed in [4] where they were called "Purpose Built Keys" (PBK). 6.12 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 that PKI for general Internet use has generally been considered impossible to set up. This is primarily due to the current separation of IP-address assignment and security infrastructures. Another reason is that limited power resources and processing capacity at the mobile nodes generally rule out any Vogt & Arkko Expires April 11, 2006 [Page 27] Internet-Draft MIP6 Route Optimization Enhancements October 2005 complex cryptographic operations. Robustness to resource-exhaustion attacks requires a similar restrictiveness on the correspondent-node side. However, Certificate-based Binding Updates (CBU) [29] are a useful simplification: A home agent is assigned a certificate that binds the home-network prefix to the home agent's public key. Correspondent nodes can trust the home agent based on the certificate, and the home agent vouches for the trustworthiness of the mobile nodes it serves. The advantage is that, rather than having to issue a certificate per mobile node, only a certificate per home-network prefix is required. This makes the infrastructure problem more tractable. The reduction in the number of potentially required certificates makes certificate-based approaches to mobile-node authentication more feasible than it is today. The approach also avoids heavy computations at mobile nodes since public-key cryptography is handled by the home agent. On the other hand, 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. But it may be an issue if the correspondent node is a popular web server or other central resource that cannot afford doing complex cryptographic operations. One should, however, bear in mind that the increased overhand implies a higher risk to resource-exhaustion attacks. 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 6.7) can be used to keep the signaling delay during handover as low as it currently is in [29]. 6.13 Mobile and Correspondent Routers A special scenario where mobility optimizations are useful is one where an entire network moves. Mobile nodes within a moving network stick together and connect to the Internet through a single "mobile router". It is relatively straightforward to support network mobility [41] by using a single home agent and a single tunnel between the mobile router and that home agent. Mobile nodes then don't have to be mobility-aware. On the other hand, supporting route optimization for moving networks [34][35][3][33] is more complicated. One way of doing this is to have the mobile router handle route Vogt & Arkko Expires April 11, 2006 [Page 28] Internet-Draft MIP6 Route Optimization Enhancements October 2005 optimization on behalf of the mobile nodes. This requires the mobile router to modify incoming and outgoing packets such that they can be routed on the direct path between the end nodes. The mobile router would also have to perform Mobile IPv6 signaling on behalf of the mobile nodes. A similar optimization applies to a network of correspondent nodes. Those could communicate with mobile nodes, through a "correspondent router", in a route-optimized way without themselves being mobility- aware. While RFC 3775 route optimization requires all correspondent nodes to be modified, this can be avoided if mobility is managed by a router in the correspondent nodes' network. Note that neither a mobile router nor a correspondent router needs to be the first-hop router. It may also be located further down the path between the communicating end nodes. 7. Analysis This section analyzes the techniques presented in Section 6 in relation to each other and in the context of the enhancement objectives described in Section 5. The techniques are categorized first. Some recent proposals for route-optimization enhancement, which rely on one or combine multiple of these techniques, are subsequently evaluated. The section concludes with a number of opportunities for further research in the area of route optimization. 7.1 Categorization of Techniques The techniques presented in Section 6 can be charactized in three respects: (a) their benefit, in terms of reduced latency, increased security, or lower signaling overhead; (b) their costs, in terms of hardware upgrades, software modifications, and manual configuration; and (c) their applicability to different scenarios and ease of deployability. Certainly, the objective for route-optimization improvement is to gain significant improvement in many scenarios at low costs. But it seems that trade-offs are oftentimes necessary. For instance, IP-address tests don't require any upgrades to the network infrastructure and work well for peers who do not know each other. At the other end, pre-configuration has high benefits in terms of reduced signaling latency and overhead as well as increased security. But these advantages apply to acquainted nodes only. The following sections elaborate on this categorization considering a subset of the techniques described in Section 6. Vogt & Arkko Expires April 11, 2006 [Page 29] Internet-Draft MIP6 Route Optimization Enhancements October 2005 7.2 Static Configuration The Home Keygen Token exchange from the return-routability procedure is the default authentication technique used in Mobile IPv6. It facilitates reasonable security even between 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 if the secret is tied to the home address in use. 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. Note that a pre-configured shared secret alone cannot replace the care-of-address test. Eliminating the care-of-address test requires additional mechanisms for address authorization and/or a means for identification of the responsible node in case of misbehavior. It is evident that pre-configuration is most effective when both the home- and the care-of-address test can be eliminated. Alternatively, one could retain the care-of-address test, but avoid its latency by doing it in a concurrent way (cf. Section 6.5). This is a good example of how multiple improvement proposals can be combined into a single, more applicable optimization. 7.3 CGA-Based Optimizations CGAs can guarantee that a mobile node is the legitimate owner of its home address. They provide higher assurance than the pure use of routing paths. This facilitates a significant reduction in the number of signaling messages per correspondent registration as well as the periodicity of these registrations. In addition, the public keys used in the CGA technique allow packets to be transferred privately, a feature that can be used for both data encryption and for other route-optimization enhancements. CGAs use complexer algorithms compared to pre-configuration techniques, but don't require peers to be acquainted. This greatly increased applicability and deployability. As with pre- configuration, CGA-based optimizations still depend on a care-of- address test, but may do it in a concurrent way to reduce latency. 7.4 Credit-Based Improvements CBA allows peers to use a new care-of address early after a handover and to verify the address in parallel with already using it. This eliminates the handover latency that the reachability check entails when performed during the critical handover period. Too rapid movements may lessen the improvement CBA can yield, as the Vogt & Arkko Expires April 11, 2006 [Page 30] Internet-Draft MIP6 Route Optimization Enhancements October 2005 average time a mobile node's care-of address is verified should be at least as long as it is unverified. CBA Inbound Mode may also be problematic when the mobile node sends too little data to acquire sufficient credit. But a simple analysis shows that a TCP download where a mobile node sends acknowledgements only (one every two segments) works fine with CBA given handover frequencies do not exceed one every 15 seconds. This gives the peers 500 milliseconds for accomplishing the concurrent care-of-address test. CBA can be integrated into any mobility protocol that verifies IP addresses through probing. Protocols that may benefit are, for instance, other Mobile IPv6 optimization techniques described in this paper such those based on CGAs or pre-configuration. Moreover, 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 for home registrations. The same is true for Hierarchical Mobile IPv6, which, as it stands, assumes that a MAP can be confident that mobile nodes use correct on- link care-of addresses, and so gets around the care-of-address test. Finally, CBA can be used to relax requirements for periodic re- authorization as proposed in [2]. 7.5 New Approaches To Certificates CBU effect a compromise between the strong authentication facilitated through certificates on one side and applicability and ease of deployability on the other side. This is achieved through "trust indirection": The CN may trust a certain operator's home agent, who in turn is supposed to enforce correct behavior of its mobile nodes. There is ongoing work on the integration of AAA with Mobile IPv6 [17]. The current focus is on authentication between mobile nodes and home agents with the intention to replace the IPsec-based authentication protocol for home registrations. But the concept of security proxies proposed in [29] may as well be re-used for enhancements to the AAA infrastructure. 8. Future Research Mobility-related optimizations are currently actively studied by many researchers at different protocol layers. The preceding sections identify ideas and existing proposals for enhancing route optimization. While some of the basic methods 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 research directions that appear fruitful, or necessary in the future, and that go beyond the existing proposals Vogt & Arkko Expires April 11, 2006 [Page 31] Internet-Draft MIP6 Route Optimization Enhancements October 2005 described so far. 8.1 Research at Other Protocol Layers The efficiency and security related to movements does not depend on Mobile IPv6 route optimization alone, 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 mechanisms such as negotiation, authentication, and key agreement; IPv6 Router and Neighbor Discovery; as well as IPv6 Address Autoconfiguration and Duplicate Address Detection. A complete network attachment typically requires over twenty link- and IP-layer messages, assuming that features necessary for a commercial deployment (such as security) are turned on. A significant research question is the performance of the network- access stack as a whole. Current protocol stacks have a number of limitations in addition to the long attachment delays [44], such as denial-of-service vulnerabilities, difficulties in trusting a set of access nodes distributed to physically insecure locations, or the inability to retrieve sufficient information for making a handoff decision. A number attempts are ongoing to improve various parts of the stack, mostly focusing on handover performance. These include link-layer enhancements, parameter tuning [55], network-access authentication mechanisms [1], fast-handover mechanisms [50], AAA architectures [25], and IP-layer attachment improvements [16]. It is uncertain how far this optimization can be taken by only looking at the different parts individually. An integrated approach may be necessary to gain more significant improvements [45]. It is also unclear at this time which components are the most critical ones. [44] suggests that mobility-related signaling contributes only under 10% of the overall delay in an IEEE 802.11 environment. The most significant delays are caused at the link layer and for IPv6 attachment. However, the results are not conclusive due to the high deviation between the measurements. 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 for Mobile IPv6 home registrations. 8.2 Further Route Optimization Research 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. Vogt & Arkko Expires April 11, 2006 [Page 32] Internet-Draft MIP6 Route Optimization Enhancements October 2005 Ongoing work addresses these aspects already quite well, and many of the suggested methods are reasonably stable in this regard. It is expected that further, perhaps smaller improvements will continue to be achieved through research and parameter tuning far into the future. Research on infrastructure-based route optimization like [43] is clearly a longer-term project. Mobile and correspondent routers can be advantageous in large networks of mobile or correspondent nodes, respectively, especially if the end nodes don't support route optimization themselves. It would also be interesting to investigate into how mobile and correspondent routers can be integrated with infrastructure-based security solutions, such as [48]. Also, the ideas of the Certificate-Based Binding Update Protocol could be useful in this light. The following is a list of interesting ideas for new route- optimization research. 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 link-layer mobility solutions. o The extension of the developed techniques to full multi- addressing, including also multi-homing. o Further development of techniques that are based on "asymmetric cost wars" [46], such as CBA. o Integrated techniques taking into account both link and IP layer mobility tasks. 8.3 Experimentation and Simulation As discussed earlier, the contribution of different stack parts to the overall movement latency is still unclear. The following is a list of areas where measurements and experimentation can yield further, valuable insight. Vogt & Arkko Expires April 11, 2006 [Page 33] Internet-Draft MIP6 Route Optimization Enhancements October 2005 o Measurements of a realistic network scenario, enabling all features that would likely be needed in a commercial deployment. These features include link-layer access control, for instance. Similarly, it is necessary to consider support for existing enhancement proposals. o Measurements and simulations of the performance impacts that existing enhancement proposals have on the different parts of the stack. o Measurements and comparisons of different implementations that are based on the same specification. For instance, it would be valuable to know how much implementations differ with regards to the use of parallelism that RFC 3775 allows in home and correspondent registrations, or with respect to early packet transmission before reception of a BA. o Measurements of the impact that network conditions such as packet loss can have on existing and new route-optimization mechanisms. o Statistical data collection on the behavior of mobile nodes in different networks. Route-optimization techniques behave differently depending on what the frequency of movements is, or what traffic streams appear during a mobile node's lifetime. o Measurements or simulations of the performance that existing route-optimization schemes show under different application scenarios, such as the use of applications with symmetric vs. asymmetric traffic patterns. 9. Security Considerations Security issues related to route optimization are an integral part of this paper and are as such discussed throughout the paper. 10. Conclusions Mobility-related optimizations are currently actively studied by many researchers. Some of the basic techniques--such as the return- routability procedure, pre-configured keys, or CGAs--are either already being deployed or can expected to be in the near future. A growing number of new proposals are being studied that attempt to optimize these basic techniques further, or to make them better applicable to a particular scenario. Many of the current proposals are mature enough to withstand close scrutiny. Their relative advantages are rather subjective, however. For instance, some proposals are very efficient, but have a high cost Vogt & Arkko Expires April 11, 2006 [Page 34] Internet-Draft MIP6 Route Optimization Enhancements October 2005 in terms of configuration, whereas others do not require configuration, but are slower. It hence appears likely that more than one new method will have to be standardized. Deployment experience is also important, so publication of a few alternative methods as RFCs would be desirable. It is interesting to see that most if not all current proposals had predecessors that were shown to be insecure. For instance, the initial return-routability procedure as well as the first versions of CGAs were published before the threat of flooding attacks was fully understood. Concurrent care-of-address tests were also first suggested with insufficient protection against flooding attacks. And several proposals employing semi-permanent security associations have initially suffered from impersonation attacks. This shows the need to reserve a sufficient amount of time for community analysis and review of new methods. Another interesting observation is that most mature proposals combine a number of techniques and do not rely on any single approach. This is due to the intricate nature of the problem: to build a mechanism that is efficient and at the same time avoids a quite significant number of potential security vulnerabilities. On the other hand, it is also necessary to avoid overly expensive or complex solutions. For instance, in evaluating the security needs for route optimization, it is important to compare these needs to other vulnerabilities, e.g., denial-of-service attacks, that already exist for on-path attackers in an Internet without mobility support. Of course, a mobility-management protocol should not make these vulnerabilities worse. But since the issues already exist, it is not necessarily a requirement that they be solved by a mobility- management protocol. There is a natural performance limit of route optimization due to end-to-end signaling. Future applications may have latency requirements that route optimization cannot satisfy. This is where local optimizations such as FMIPv6 and HMIPv6 become necessary. While HMIPv6 still benefits from enhancements to route optimization, FMIPv6 allows peers to postpone global signaling and parallelize it with upper-layer communications. This is an exemplar for the trade- off between good performance and high investment costs. A significant research question is the overall performance of the network stack in a mobile setting. This includes mobility management at the IP layer, but is not limited to it. Current network-access protocol stacks have a number of limitations, such as long attachment and movement latencies or significant denial-of-service vulnerabilities. It is uncertain whether further, significant Vogt & Arkko Expires April 11, 2006 [Page 35] Internet-Draft MIP6 Route Optimization Enhancements October 2005 benefits can be achieved if one continues to look at the different parts of the network stack individually. Most likely, a more comprehensive approach is needed. It is also unclear at this time which components of the network stack are the most critical ones to optimize. Other significant research questions include what effect network conditions such as packet loss can have on current proposals, and to what degree proposals depend on specific application patterns. Our current understanding about the different traffic patterns and their effects on mobility is limited, and experiments, modelling, and simulations will be needed. Finally, an interesting piece of research would be to measure the performance of route optimization relative to bidirectional tunneling from a user's perspective. Vogt & Arkko Expires April 11, 2006 [Page 36] Internet-Draft MIP6 Route Optimization Enhancements October 2005 11. References [1] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001. [2] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding Lifetime Extension", draft-arkko-mipv6-binding-lifetime-extension-00 (work in progress), May 2004. [3] Bernardos, C., "Mobile IPv6 Route Optimisation for Network Mobility (MIRON)", draft-bernardos-nemo-miron-00 (work in progress), July 2005. [4] Bradner, S., Mankin, A., and J. Schiller, "A Framework for Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in progress), June 2003. [5] Daley, G., "Location Privacy and Mobile IPv6", draft-daley-mip6-locpriv-00 (work in progress), January 2004. [6] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", draft-dupont-mipv6-3bombing-01 (work in progress), January 2005. [7] Dupont, F. and J. Combes, "Using IPsec between Mobile and Correspondent IPv6 Nodes", draft-dupont-mipv6-cn-ipsec-01 (work in progress), June 2004. [8] Dupont, F. and J. Combes, "Care-of Address Test for MIPv6 using a State Cookie", draft-dupont-mipv6-rrcookie-00 (work in progress), January 2005. [9] 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. [10] Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)", draft-haddad-mipv6-omipv6-01 (work in progress), February 2004. [11] Haddad, W., "Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement", draft-haddad-momipriv-problem-statement-00 (work in progress), October 2004. [12] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00 (work in progress), June 2004. Vogt & Arkko Expires April 11, 2006 [Page 37] Internet-Draft MIP6 Route Optimization Enhancements October 2005 [13] Nikander, P., "End-Host Mobility and Multi-Homing with Host Identity Protocol", draft-ietf-hip-mm-01 (work in progress), February 2005. [14] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-esp-v3-08 (work in progress), March 2004. [15] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node-requirements-11 (work in progress), August 2004. [16] Moore, N., "Optimistic Duplicate Address Detection for IPv6", draft-ietf-ipv6-optimistic-dad-01 (work in progress), June 2004. [17] 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. [18] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004. [19] Perkins, C., "Preconfigured Binding Management Keys for Mobile IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress), April 2004. [20] 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. [21] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-02 (work in progress), July 2004. [22] 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. [23] Huston, G., "Architectural Approaches to Multi-Homing for IPv6", draft-ietf-multi6-architecture-04 (work in progress), February 2005. [24] 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. [25] Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to RADIUS", draft-irtf-aaaarch-handoff-04 (work in progress), Vogt & Arkko Expires April 11, 2006 [Page 38] Internet-Draft MIP6 Route Optimization Enhancements October 2005 November 2003. [26] Koodli, R., "IP Address Location Privacy and IP Mobility", draft-koodli-mip6-location-privacy-00 (work in progress), February 2005. [27] Koodli, R., "Solutions for IP Address Location Privacy in the presence of IP Mobility", draft-koodli-mip6-location-privacy-solutions-00 (work in progress), February 2005. [28] Moskowitz, R., Nikander, P., and P. Jokela, "Host Identity Protocol", draft-moskowitz-hip-09 (work in progress), February 2004. [29] Bao, F., "Certificate-based Binding Update Protocol (CBU)", draft-qiu-mip6-certificated-binding-update-02 (work in progress), August 2004. [30] 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. [31] 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. [32] 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. [33] Wakikawa, R., "Optimized Route Cache Protocol (ORC)", draft-wakikawa-nemo-orc-01 (work in progress), November 2004. [34] Zhao, F., Wu, F., and S. Jung, "NEMO Route Optimization Problem Statement and Analysis", draft-zhao-nemo-ro-ps-01 (work in progress), February 2005. [35] "NEMO Route Optimisation Problem Statement", draft-clausen-nemo-ro-problem-statement-00 (work in progress), October 2004. [36] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. Vogt & Arkko Expires April 11, 2006 [Page 39] Internet-Draft MIP6 Route Optimization Enhancements October 2005 [37] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [38] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. [39] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [40] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [41] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [42] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [43] Vadali, R., Li, J., Wu, Y., and G. Cao, "Agent-Based Route Optimization for Mobile IP", Proceedings of the IEEE Vehicular Technology Conference, October 2001. [44] Alimian, A. and B. Aboba, "Analysis of Roaming Techniques", IEEE Contribution 11-04-0377r1 2004. [45] 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. [46] 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. [47] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [48] Castelluccia, Claude., Montenegro, Gabriel., Laganier, Julien., and Christoph. Neumann, "Hindering Eavesdropping via IPv6 Opportunistic Encryption", Proceedings of the European Symposium on Research in Computer Security , September 2004. [49] 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. Vogt & Arkko Expires April 11, 2006 [Page 40] Internet-Draft MIP6 Route Optimization Enhancements October 2005 [50] 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. [51] Montenegro, G. and Claude. Castelluccia, "Crypto-Based Identifiers (CBIDs): Concepts and Applications", ACM Transactions on Information and System Security Vol. 7, No. 1, February 2004. [52] Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", Proceedings of the Cambridge Security Protocols Workshop, April 2001. [53] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", Computer Communications Review, April 2001. [54] Paxson, V., "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks", Computer Communication Review 31(3)., July 2001. [55] 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. [56] Vogt, C., "Samitas Review of draft-irtf-mobopts-ro-enhancements-00", IETF MIP6 and Mobopts mailing lists, http://www.atm.tut.fi/list-archive/MIPv6-2005/ msg00677.html, June 2005. Authors' Addresses Christian Vogt Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Email: chvogt@tm.uka.de URI: http://www.tm.uka.de/~chvogt/ Vogt & Arkko Expires April 11, 2006 [Page 41] Internet-Draft MIP6 Route Optimization Enhancements October 2005 Jari Arkko Ericsson Research NomadicLab FI-02420 Jorvas Finland Email: jari.arkko@ericsson.com Vogt & Arkko Expires April 11, 2006 [Page 42] Internet-Draft MIP6 Route Optimization Enhancements October 2005 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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 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 (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vogt & Arkko Expires April 11, 2006 [Page 43]