A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization
draft-arkko-mip6-ro-enhancements-00

Versions: 00                                                            
Network Working Group                                           J. Arkko
Internet-Draft                              Ericsson Research NomadicLab
Expires: April 1, 2005                                           C. Vogt
                                                 University of Karlsruhe
                                                            October 2004



      A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route
                              Optimization
                  draft-arkko-mip6-ro-enhancements-00


Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on April 1, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004). All Rights Reserved.















Arkko & Vogt             Expires April 1, 2005                  [Page 1]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



Abstract


   The Mobile IPv6 mobility-management protocol enables minimum routing
   paths between a mobile node and a correspondent node, which may
   itself be mobile. This feature is called route optimization. Route
   optimization requires authorization of initially unacquainted and
   untrusted parties. A so-called return-routability procedure was
   integrated into the Mobile IPv6 in order to do this securely. The
   return-routability procedure equips the mobile node with
   cryptographic tokens that authenticate the mobile node and prove the
   mobile node's presence at a claimed new location after movement.
   Recently, a number of improvements or optional alternatives have been
   suggested to the standard procedure. The primary driver between these
   improvements is oftentimes further reduction of signaling messages
   and latency, but other improvements such as better security have also
   been suggested. This document discusses the potential goals for
   future enhancements of route optimization, the security threats that
   such enhancements must consider, and the various enhancement
   proposals and their key ideas. An evaluation of some recent proposals
   is included, as well as a discussion of how significant the Mobile
   IPv6 related optimizations are related to other ongoing optimization
   efforts. Finally, needs for future research are outlined.






























Arkko & Vogt             Expires April 1, 2005                  [Page 2]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



Table of Contents


   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Mobility-Related Security Threats  . . . . . . . . . . . . .   6
     2.1  Impersonation Attacks  . . . . . . . . . . . . . . . . . .   6
     2.2  Resource-Exhaustion Attacks  . . . . . . . . . . . . . . .   7
     2.3  Flooding Attacks . . . . . . . . . . . . . . . . . . . . .   8
   3.   Mobile IPv6 Route Optimization . . . . . . . . . . . . . . .   9
     3.1  Goals and Assumptions  . . . . . . . . . . . . . . . . . .  10
     3.2  Return Routability Procedure . . . . . . . . . . . . . . .  11
     3.3  Security Analysis  . . . . . . . . . . . . . . . . . . . .  16
   4.   Objectives for Enhancement . . . . . . . . . . . . . . . . .  17
     4.1  Latency Optimizations  . . . . . . . . . . . . . . . . . .  17
     4.2  Signaling Optimizations  . . . . . . . . . . . . . . . . .  18
     4.3  Security Enhancements  . . . . . . . . . . . . . . . . . .  19
     4.4  Applicability Enhancements . . . . . . . . . . . . . . . .  20
   5.   The Toolbox  . . . . . . . . . . . . . . . . . . . . . . . .  20
     5.1  Address Tests  . . . . . . . . . . . . . . . . . . . . . .  21
     5.2  Protected Tunnels  . . . . . . . . . . . . . . . . . . . .  21
     5.3  Optimistic Behaviour . . . . . . . . . . . . . . . . . . .  22
     5.4  Proactive Tests  . . . . . . . . . . . . . . . . . . . . .  22
     5.5  Concurrent Tests . . . . . . . . . . . . . . . . . . . . .  23
     5.6  Diverted Routing . . . . . . . . . . . . . . . . . . . . .  24
     5.7  Credit-Based Authorization . . . . . . . . . . . . . . . .  25
     5.8  Heuristic Monitoring . . . . . . . . . . . . . . . . . . .  26
     5.9  Cryptographically Generated Addresses  . . . . . . . . . .  27
     5.10   Semi-Permanent Security Associations . . . . . . . . . .  28
     5.11   Pre-Configuration  . . . . . . . . . . . . . . . . . . .  29
     5.12   Infrastructure . . . . . . . . . . . . . . . . . . . . .  29
     5.13   Cryptographically Bound Identifiers  . . . . . . . . . .  30
     5.14   Local Mobility . . . . . . . . . . . . . . . . . . . . .  30
     5.15   Local Repair . . . . . . . . . . . . . . . . . . . . . .  31
     5.16   Processing Improvements  . . . . . . . . . . . . . . . .  32
     5.17   Delegation . . . . . . . . . . . . . . . . . . . . . . .  33
   6.   Analysis . . . . . . . . . . . . . . . . . . . . . . . . . .  33
     6.1  Categorization of Techniques . . . . . . . . . . . . . . .  33
     6.2  Evaluation of Some Proposals . . . . . . . . . . . . . . .  34
     6.3  Further Research . . . . . . . . . . . . . . . . . . . . .  42
   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  44
   8.   Conclusions  . . . . . . . . . . . . . . . . . . . . . . . .  44
   9.   References . . . . . . . . . . . . . . . . . . . . . . . . .  47
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  50
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  50
        Intellectual Property and Copyright Statements . . . . . . .  51








Arkko & Vogt             Expires April 1, 2005                  [Page 3]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



1.  Introduction


   Traditionally, an IP address combines identification and location
   semantics. The address prefix locates a node's point of network
   attachment. It is used by routers to forward IP packets towards the
   correct destination. At the same time, existing transport protocols
   and applications, commonly termed "upper layers", use the IP address
   as part of a session identification. This naturally rules out
   mobility: Whenever a mobile node moves from one access network to
   another, its IP address must change to reflect the new location. The
   new "identity", however, causes sessions at upper layers to abort.


   Protocol designers thus had to decide whether to change transport
   protocols and applications, or to come up with a new IP-layer
   protocol that could separate location from identification
   functionality. Due to the prevalence of TCP and the significant base
   of existing applications, most people opted for the latter approach.
   Mobile IPv6 [15], its IPv4 counterpart [25], and the Host Identity
   Protocol [22] are three dominant mobility-management protocols that
   the IETF has developed to facilitate the continued use of existing
   transport protocols and applications in an Internet with mobility
   support. This document focuses on Mobile IPv6.


   Mobile IPv6 uses two IP addresses per mobile node in an attempt to
   separate location semantics from identification semantics: a
   transient "care-of address" is used for the purpose of routing. It is
   reconfigured whenever the mobile node moves to a new access network.
   A static "home address" is configured with the network prefix from a
   non-mobile "home agent's" network. The home address doesn't change
   when the mobile node moves, and it can be used for session
   identification at upper layers. The home address also serves as a
   node identifier for Mobile IPv6 itself. In the Mobile IPv6 base mode,
   "bidirectional tunneling", the home agent intercepts packets
   addressed to the mobile node's home address, and it tunnels those
   packets to the mobile node's current care-of address. After
   decapsulation at the mobile node, these packets bear the mobile
   node's home address and are as such accepted at upper layers. In the
   opposite direction, transport protocols and applications at the
   mobile node generate packets with the home address in the IPv6 Source
   Address field. The mobile node tunnels these packets to the home
   agent who, in turn, decapsulates them and forwards them on to the
   final recipient.


   Bidirectional tunneling through the home agent provides for location
   privacy, as a communication peer never sees the mobile node's care-of
   address. It is also a very safe approach to mobility, because all
   signaling between the mobile node and the home agent can easily be
   protected by means of a pre-established security association and




Arkko & Vogt             Expires April 1, 2005                  [Page 4]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   trust relationship. Last, but not least, the beauty of bidirectional
   tunneling is that it does not require support from a mobile node's
   correspondent peer. On the other hand, middle-box-style approaches
   like bidirectional tunneling loose attractiveness due to the
   additional overhead that a growing population of mobile nodes can
   pose on the Internet. A home agent can also be a single point of
   failure or a performance bottleneck. This leads to the concept of
   "route optimization".


   With Mobile IPv6 route optimization, packets can be directly relayed
   between a mobile node and its correspondent node. The mobile node
   keeps the correspondent node up to date about its current care-of
   address. When a route-optimized packets is received from the network,
   either at the mobile node or at the correspondent node, the Mobile
   IPv6 implementation replaces the care-of address in the packet's IPv6
   header by the mobile node's home address before the packet is handed
   to the upper layer. Vice versa, when a packet is received from the
   upper layer, the Mobile IPv6 implementation replaces the home address
   in the packet's IPv6 header by the mobile node's current care-of
   address before the packet is injected into the network.


   The need for routing efficiency was deemed important enough to
   outweigh a number of disadvantages that come along with route
   optimization. First of all, different than bidirectional tunneling,
   route optimization requires mobility support from the correspondent
   node. Also, route optimization reveals the mobile node's current
   care-of address to the correspondent node, and thus makes the mobile
   node tracable. Route optimization should therefore not be used when
   location privacy is an issue. Last, but not least, route optimization
   would impose significant security threats if it was not accompanied
   by a new security protocol: Although one can generally neither
   presuppose a security association nor a trust relationship between a
   mobile node and its communication peer, a correspondent node should
   be able to verify the origin, the integrity, and the validity of all
   received registration messages. Indeed, a mobile node must authorize
   its requests to the correspondent node, protect a registration
   message against tampering, and prove to the correspondent node that
   it is indeed reachable through the to-be-registered care-of address.
   Such protection is necessary to prevent impersonation and
   denial-of-service attacks [23].


   As part of the registration procedure, a correspondent node probes a
   mobile node's home address to verify the mobile node's identity. It
   also probes the mobile node's care-of address to gain assurance that
   the mobile node is reachable at this address. The two address tests
   are combined in the so-called "return-routability procedure".


   The return-routability procedure is to be executed for each




Arkko & Vogt             Expires April 1, 2005                  [Page 5]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   care-of-address update, or periodically in case the mobile node does
   not move for a while. This can lead to a handover delay unacceptable
   for many real-time or interactive applications like Voice over IP
   (VoIP) and audio or video streaming. Moreover, the periodic
   repetitions imply a hidden signaling overhead that may interfere with
   mobile nodes who intend to sleep during times of inactivity. Finally,
   the return-routability procedure uses "weak authentication" to bind a
   home address to the legitimate owner. It limits vulnerabilities to
   attackers that are on the path from the correspondent node to the
   mobile node or to the home agent. The residual vulnerabilities are
   similar to those that exist anyway in today's non-mobile Internet.
   But still, mechanisms that use strong authentication of IP addresses
   can provide a higher level of security than the return-routability
   procedure does.


   This document describes and classifies possible enhancements to the
   return-routability procedure. Following this introduction, section
   Section 2 shows which new security threats arise in an Internet with
   mobility support. Section 3 explains the care-of-address registration
   protocol as defined in RFC 3775 [15], including the
   return-routability procedure. A number of potential goals for
   enhancements (such as reducing latency) are discussed in Section 4.
   Known optimization techniques are discussed in Section 5. Section 6
   discusses how these techniques are used by existing optimization
   proposals, evaluates some of these proposals, and proposes some
   further work.


2.  Mobility-Related Security Threats


   Mobile IPv6 allows a node to redirect those packets, that a
   correspondent node would otherwise send to one IP address (the home
   address), to a second IP address (the care-of address). But the
   ability for redirection could also be misused by a malicious node for
   an arbitrary pair of IP addresses if no appropriate precautions were
   taken.


   Overall, there are three major families of mobility-related threats:
   impersonation attacks, resource-exhaustion attacks, and flooding
   attacks. The following subsections take a closer look at each of the
   categories. Threats are described in the light of Mobile IPv6, but
   some of them apply to other mobility-management protocols as well.


2.1  Impersonation Attacks


   The probably most obvious issue with mobility is how one can ensure
   that only a mobile node itself has the ability to change its care-of
   address. If care-of-address registrations were unauthenticated, an
   attacker could easily impersonate an arbitrary victim. For instance,




Arkko & Vogt             Expires April 1, 2005                  [Page 6]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   the attacker could contact the victim's correspondent node and
   register its own IP address on behalf of its victim. The
   correspondent node would assume that the victim's care-of address has
   changed, and it would redirect all packets intended for the victim to
   the attacker instead. The attacker could forward the packets to the
   victim after analyzing, or even tampering with, their payloads. In a
   related offense, the perpetrator could simply cause havoc at its
   victim by directing the victim's packets to a random or non-existent
   IP address. These attacks are jointly referred to as "impersonation
   attacks". Impersonation attacks can be prevented through proper
   authentication techniques that keep an outsider from assuming another
   node's identity.


   It is important to recognize that impersonation attacks not only
   impact those nodes that have an interest in mobility. Although the
   attacker makes the correspondent node believe that the victim is
   mobile, neither the attacker nor the victim do have to be mobile.
   Indeed, mobile nodes, non-moving nodes with mobility support, as well
   as traditional stationary nodes are potentially endangered because
   they all share the same IPv6 identifier namespace. (Actually, even
   IPv4 nodes are jeopardized when IPv4-to-IPv6 translation occurs on
   the path between these nodes and their correspondent peers.) This
   unfolds the need for mandatory protection of mobility-related
   signaling in order to safeguard the Internet community as a whole.


   Beyond their large group of potential victims, mobility-related
   impersonation attacks allow an attacker to choose the location from
   where to wage its attack. For example, the impersonator could
   position itself at a place where it is easier to inject spoofed
   care-of-address registration packets into the network than anywhere
   on the direct path between the victims. The attacker may also move to
   a place where it can remain unrecognized. In contrast to this, in the
   non-mobile Internet that we have today, an attacker can only listen
   to or tamper with packets while it is on the path between its
   victims. Similarly, a mobility-management protocol may give the
   attacker the possibility to shift the time for its attack. The
   attacker might be able to register false care-of addresses even
   before its victims' conversation begins, or attack a network long
   after it has visited it. In the non-mobile Internet, an attacker must
   strike at the same time as its victims communicate. The ability to
   choose the location and time for an attack constitutes a dangerous
   new degree of freedom for the attacker.


2.2  Resource-Exhaustion Attacks


   Mobility support at correspondent nodes can become an issue if it
   takes a lot of processing capacity to handle an incoming
   care-of-address registration. During times of increased signaling




Arkko & Vogt             Expires April 1, 2005                  [Page 7]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   load, a correspondent node may thus end up having to commit a
   significant fraction of its resources to mobility-related
   transactions. What is worse, an attacker may take advantage of this
   vulnerability. It could swamp the correspondent node with large
   quantities of bogus registrations messages, keeping it from doing
   useful work. Such denial-of-service attempts are called
   "resource-exhaustion attacks". Clearly, if mobility support is to be
   implemented on a large basis, handling care-of-address registrations
   must be lightweight in order to lessen the susceptibility to resource
   exhaustion. Another effective technique is to defer resource
   commitment until late in the registration process: Once the
   registrant has proven its identity or shown that it is willing to
   invest resources itself, it is less likely malicious. As a last
   resort, busy Internet servers should limit the resources they devote
   to registration processing, and they may give preference to those
   mobile nodes they know or have recently had meaningful communications
   with.


   It is worthwhile to stress the trade-off between effectiveness of
   signaling authentication and resilience against increased signaling
   load. On one hand, a strong authentication mechanism can effectively
   prevent certain impersonation attacks. On the other hand, the
   resources a correspondent node must spend on the verification of a
   registering node's authenticity increases with the complexity of the
   authentication algorithm. The susceptibility to resource exhaustion
   thus grows with the level of protection against impersonation
   attacks.


2.3  Flooding Attacks


   A third mobility-related security threat emanates from
   redirection-based flooding attacks. Redirection-based flooding
   attacks are characterized by a victim being bombarded with unwanted
   packets at a rate that the victim, and possibly the victim's access
   network, cannot handle. As with impersonation attacks, it is
   important to compare existing flooding attacks in today's non-mobile
   Internet with redirection-based flooding attacks that could be made
   possible through an insecure mobility-management protocol.


   Three types of flooding attacks can be identified in today's
   Internet. The simplest one is a "direct flooding attack". Here, the
   attacker itself sends bogus packets to the victim. In an indirect
   "reflection attack", the attacker tricks a third node, the
   "reflection point", to send the packets. It typically uses a known
   protocol vulnerability to make the reflection point generate these
   packets [24]. For example, the attacker may send spoofed ICMP Echo
   Request packets to the reflection point, using its victim's IP
   address in the packets' IPv6 Source Address field. For each such




Arkko & Vogt             Expires April 1, 2005                  [Page 8]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   request, the reflection point generates an ICMP Echo Reply message,
   which it sends "back" to the victim. The advantage of a reflection
   attack over a direct flooding attack is that the attacker is usually
   harder to track when flooding traffic comes from a third node.
   Another example for a reflection attack is TCP-SYN flooding. Here,
   the attacker sends TCP SYN packets, again with false source
   addresses, to the reflection point, which in turn sends TCP SYN-ACK
   packets to someone who does not expect these packets. Since most TCP
   servers are configured so that they re-send a TCP SYN packet multiple
   times when failing to receive an acknowledgement, this reflection
   attack can even produce a small amplification. Gaining higher
   amplification in today's Internet necessitates more complex
   strategies like "distributed flooding attacks". In a distributed
   flooding attack, the attacker typically gains control over other
   nodes by spreading viral software. Then, at a certain point of time,
   infected nodes simultaneously commence a joint flooding attack
   against a common victim.


   The introduction of mobility support renders amplified flooding
   attacks much less complex. Suppose a mobile node is allowed to change
   its care-of address without having to evidence that it is present at
   the new care-of address. Then, an attacker can subscribe, through its
   own IP address, to a large data flow (e.g., a video stream) offered
   by some server on the Internet. The attacker can easily accomplish
   the initial handshake procedure with the server while it uses its own
   IP address. Once data is flowing, the attacker can redirect the flow
   to the IP address of an arbitrary victim. The attacker can use the
   sequence numbers learned during the initial handshake procedure in
   order to spoof acknowledgements for packets that it assumes the
   server has sent to the victim. In this attack, not the attacker, but
   a faithful server on the Internet can be made generate packets used
   for an attack. The server does not have to be infected with
   compromised code, and neither the victim nor the server has to be
   mobile. The attacker produces as little as spoofed feedback
   information to keep the data flow alive. To make matters worse, the
   attacker can redirect data flows from multiple servers to the victim.


   Support for Mobile IPv6 route optimization is recommended to all IPv6
   nodes [19]. The base of correspondent nodes that an attacker could
   exploit for a redirection-based flooding attack would therefore be
   immense. Also note that no distribution of viral software would be
   necessary. The severity of this new type of flooding is that it would
   provide potentially unbounded amplification at comparably low cost.


3.  Mobile IPv6 Route Optimization


   The potential for new security threats necessitates the protection of
   mobility-related signaling in Mobile IPv6. The development of an




Arkko & Vogt             Expires April 1, 2005                  [Page 9]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   appropriate security design, however, is a challenge: Nodes that
   never met before must find a way to authenticate themselves,
   preferably without the need for a global PKI. Also, a trade-off
   between cryptographic complexity and resilience to resource
   exhaustion must be found.


   This section explains the security design for Mobile IPv6 route
   optimization in the light of the goals and assumptions based on which
   it was built.


3.1  Goals and Assumptions


   An important objective for the development of Mobile IPv6 was to
   provide for a wide, preferably universal, support for route
   optimization. In fact, support for Mobile IPv6 and, thus, route
   optimization is recommended in the requirements suite for IPv6 nodes
   [19]. It was, and still is, believed that the additional routing
   overhead associated with bidirectional tunneling is too much of a
   burden on the core Internet given that the number of connected mobile
   nodes is expected to grow substantially within the next years.


   The aspiration for wide-scale deployment of route optimization has an
   impact on how correspondent nodes can authenticate mobile nodes.
   Authentication can be performed based on a preconfigured shared
   secret or through a trusted public-key infrastructure (PKI).
   Unfortunately, both approaches turn out to be impractical for route
   optimization.


   Preconfiguration is not an option because there is usually no
   pre-existing relationship between communicating nodes. A PKI could
   assist unacquainted nodes in the authentication process. But a PKI
   for Mobile IPv6 would have to be able to authenticate all mobile
   nodes on the Internet. It is generally believed that no such PKIs can
   be constructed. More seriously, a PKI that simply authenticates users
   would not suffice to prevent mobility related attacks. It would be
   necessary to have authorization of specific IP addresses. This seems
   hard even for home addresses, as IP address assignment is usually
   handled by other network entities than the PKI nodes.  Moreover,
   authorization of care-of addresses would be infeasible, as these
   addresses change all the time. The global PKI would also constitute
   an attractive target for attacks, endangering the Internet as a
   whole.


   Due to these difficulties, the concept of "weak authentication" was
   elaborated for the use between nodes that have no a-priori
   relationship. The intent was to make an Internet with mobility
   support as secure as the non-mobile Internet is today.





Arkko & Vogt             Expires April 1, 2005                 [Page 10]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   It is important to recognize that some mobility-related attacks can
   be prevented through authentication/authorization of the used IP
   addresses, while others cannot. Impersonation attacks belong the the
   former class. Protection against resource-exhaustion attacks requires
   that the protocol is of low complexity, or delays state creation and
   computation in an appropriate manner until peer has shown its
   credentials. On the other hand, redirection-based flooding attacks
   are based on care-of-address spoofing. Mandatory authentication may
   lessen the attractiveness of such flooding, but certainly cannot
   prevent it. Care-of-address validity must therefore be ensured
   through different means.


   One option is to enforce proper use of care-of addresses already at
   the mobile node's point of network attachment. The correspondent node
   may then simply believe in the validity of a care-of address without
   doing any verification itself. Many access networks today provide
   this service through ingress filtering [11]. However, the crux with
   verifying a care-of address at the fringe of the Internet is that an
   attacker can choose the location from where to wage a flooding
   attack. As long as there are access networks where ingress filtering,
   or an equivalent technique, is not deployed, an attacker can always
   avoid care-of-address verification. Mobile IPv6 hence does not rely
   on ingress filtering.


   Another way to protect against care-of-address spoofing is to have a
   correspondent node probe a mobile node's new care-of address before
   it sends packet there. This verification strategy operates end to
   end, and it is independent of support from the access network. Mobile
   IPv6 uses care-of address probing during the return-routability
   procedure.


   It should be mentioned that care-of-address verification can be
   omitted in scenarios where the correspondent node has confidence in
   the mobile node's honesty. In fact, Mobile IPv6 assumes a trust
   relationship between mobile nodes and their respective home agents.
   It is believed that the mandatory security association between mobile
   nodes and home agents implicates the trust. This is certainly a
   feasible hypothesis in many cases, but one ought to bear that, in
   some scenarios, it may be not. If the home registration process had a
   care-of address verification, the extension of Mobile IPv6 for
   bootstrapping solutions would be easier [29].


3.2  Return Routability Procedure


   The security design for Mobile IPv6 route optimization is shaped from
   the assumptions outlined in the preceding section. At the heart of a
   correspondent registration is the return-routability procedure, a
   protocol for weak authentication and end-to-end care-of-address




Arkko & Vogt             Expires April 1, 2005                 [Page 11]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   verification [15]. This section gives a nutshell view on the standard
   Mobile IPv6 correspondent registration. A correspondent registration
   has two phases: First, the return-routability procedure is executed,
   then the registration proper is accomplished.


   Mobile Node                 Home Agent             Correspondent Node
        |                          |                          |
        | 1. Binding Update (BU)   |                          |
        |------------------------->|                          |
        |                          |                          |
        | 2. Binding Ack (BA)      |                          |
        |<-------------------------|                          |
        |                          |                          |
        | 3a. Home Test Init (HoTI)|                          |
        |------------------------->|------------------------->|
        |                                                     |
        | 3b. Care-of Test Init (CoTI)                        |
        |---------------------------------------------------->|
        |                                                     |
        |                          | 4a.Home Test (HoT)       |
        |<-------------------------|<-------------------------|
        |                          |                          |
        |                            4b.Care-of Test (CoT)    |
        |<----------------------------------------------------|
        |                                                     |
        | 5. Binding Update (BU)                              |
        |-----------------------------------------------------|
        |                                                     |
        |                            6. Binding Ack (BA)      |
        |<----------------------------------------------------|
        |                                                     |



        Note 1: Waiting for the Binding Acknowledgement from
        the home agent may proceed in parallel with the rest
        of the process.


        Note 2: The home and care-of tests can be done in
        parallel. That is, the Home Test Init and Care-of Test
        Init messages can be sent one after another, and the
        process completes when a response has been received
        to both.


        Note 3: Acknowledgements are optional (but often
        desirable).


      Figure 1. Correspondent registration process.





Arkko & Vogt             Expires April 1, 2005                 [Page 12]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



            Figure 1: Mobile IPv6 Correspondent Registration



   When the mobile node detects that it has moved to a different access
   network, it configures an IP address with the prefix of the new
   network. The mobile node registers this IP address as its new care-of
   address with the home agent (home registration) and with each
   correspondent node capable of supporting route optimization
   (correspondent registration). The correspondent registration includes
   a return-routability procedure for authentication and care-of-address
   verification purposes. Figure Figure 1 depicts the overall process.
   The home and correspondent registrations may be interleaved as the
   mobile node can already initiate the correspondent registration while
   the home registration is still in progress. Messages (1) and (2)
   comprise the home registration; messages (3a) to (6) make up the
   correspondent registration. In the latter, messages (3a), (3b), (4a),
   and (4b) constitute the return-routability procedure. The following
   is a more detailed description of the registration process.


   When the mobile node has configured a care-of address after movement,
   it sends to its home agent a Binding Update message (1). The Binding
   Update message informs the home agent about the mobile node's new
   care-of address. The new care-of address is in the packet's IPv6
   source address, the home address is placed into the IPv6
   destination-options extension header. The Binding Update message is
   authenticated, and optionally encrypted, by means of an IPsec
   security association between the mobile node and the home agent.


   When the home agent receives the Binding Update message, it can
   determine the appropriate IPsec security association based on the
   mobile node's home address. Provided that the message is properly
   authenticated, the home agent registers the mobile node's new care-of
   address. In case the home agent maintains an IPsec tunnel for packets
   routed through the home network, it also updates the corresponding
   security association to the new care-of address [6]. The home agent
   sends back to the mobile node a Binding Acknowledgement message (2)
   to indicate successful care-of-address registration. Like the Binding
   Update message, the Binding Acknowledgement message is authenticated,
   and possibly encrypted, through IPsec.


   Once the home registration is complete, the mobile node initiates the
   correspondent registration. (In case the mobile nodes communicates
   with multiple correspondent nodes, it can register with all of them
   in parallel.) The mobile node sends to the correspondent node two
   messages in parallel: a Home Test Init message and a Care-of Test
   Init message. The Home Test Init message (3a) is tunneled to the
   mobile node's home agent, and forwarded on to the correspondent node.
   The Home Test Init message includes a random Home Init Cookie, which




Arkko & Vogt             Expires April 1, 2005                 [Page 13]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   the correspondent node will return in its Home Test message. This
   gives the mobile node reasonable assurance that the Home Test message
   was sent by the correspondent node itself rather than a hidden
   attacker impersonating the correspondent node. In fact, the returned
   cookie can only guarantee that the Home Test message was generated by
   some node on the path from the mobile node via the home agent to the
   correspondent node. The Home Test Init message and the Home Test
   message may (and should) be protected through IPsec on the path
   between the mobile node and the home agent, but they are unprotected
   on the path between the home agent and the correspondent node. On the
   latter path, a malicious node may thus eavesdrop on the Home Init
   Cookie and return it in a spoofed Home Test message.


   The Care-of Test Init message (3b) does not go through the mobile
   node's home agent. It takes the direct path to the correspondent
   node. Again, the Care-of Test Init message includes a random cookie,
   the Care-of Init Cookie, to be returned by the correspondent node in
   the Care-of Test message. Both the Care-of Test Init and the Care-of
   Test messages cannot be protected by IPsec in the general case, since
   there is usually no security association between the mobile node and
   the correspondent node. For this reason, the cookie mechanism can
   only restrict the sender of the Care-of Test message to the direct
   path between the mobile node and the correspondent node. Still, the
   mobile node considers this a sufficient proof that the Care-of Test
   message was generated by the correspondent node itself.


   In the above, the return-routability procedure was generated after
   the home registration was complete. This is not necessarily so. The
   mobile node may reduce the registration latency by sending messages
   (1), (3a), and (4b) simultaneously.


   When the correspondent node receives the Home Test Init message, it
   sends back to the mobile node a Home Test message (4a). The Home Test
   message is directed to the mobile node's home address, hence passes
   the mobile node's home agent. The Home Test message contains a Home
   Keygen Token, a Home Nonce Index, and the Home Init Cookie copied
   from the Home Test Init message. The mobile node needs the Home
   Keygen Token to authenticate the Binding Update message, as described
   below. The Home Nonce Index identifies a random value based on which
   the correspondent node has computed the Home Keygen Token. The mobile
   node will include the Home Nonce Index in the subsequent Binding
   Update message to allow the correspondent node to reproduce the Home
   Keygen Token without having to explicitly store it.


   Likewise, upon receiving the Care-of Test Init message, the
   correspondent node sends back to the mobile node a Care-of Test
   message (4b). The Care-of Test message is directed to the mobile
   node's new care-of address, hence does not pass the mobile node's




Arkko & Vogt             Expires April 1, 2005                 [Page 14]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   home agent. Similar to the Home Test message, the Care-of Test
   message contains a Care-of Keygen Token, a Care-of Nonce Index, and
   the Care-of Init Cookie copied from the Care-of Test Init message.
   The mobile node needs the Care-of Keygen Token for the Binding Update
   message in order to prove its reachability at the new care-of
   address. This is described below. When returned in the Binding Update
   message, the Care-of Nonce Index allows the correspondent node to
   reproduce the Care-of Keygen Token without having to store it.


   The mobile node then sends a Binding Update message (5) to the
   correspondent node. The Binding Update message contains a
   message-authentication code produced on the basis of the Home and the
   Care-of Keygen Tokens. It also contains the Home Nonce Index and the
   Care-of Nonce Index. The mobile node may request the correspondent
   node to return a Binding Acknowledgement message by raising the
   A-flag in the Binding Update message.


   When the correspondent node receives the Binding Update message, it
   can reproduce the Home Keygen Token and the Care-of Keygen Token with
   the help of the two nonce indices. The tokens, in turn, allow the
   correspondent node to verify the message-authentication code. If the
   message-authentication code is ok, the correspondent node can assume
   two things. First, the mobile node must have received the Home Keygen
   Token. Hence, the mobile node is the legitimate owner of the home
   address with high probability, since the Home Keygen Token was sent,
   as part of the Home Test message, to the mobile node's home address.
   Second, the mobile node must have received the Care-of Keygen Token.
   Therefore, the mobile node is apparently reachable through the new
   care-of address, since the Care-of Keygen Token was sent, as part of
   the Care-of Test message, to the mobile node's care-of address.
   Beyond this, the message-authentication code validates the Binding
   Update message's integrity.


   Provided that the verification of the message-authentication code
   succeeds, the correspondent node creates a binding-cache entry with
   the mobile node's new care-of address. The correspondent node uses
   the mobile node's new care-of address as soon as the binding-cache
   entry is in place. In case the A-flag in the Binding Update message
   is set, the correspondent node sends back to the mobile node a
   Binding Acknowledgement message (6) to indicate a successful
   care-of-address update.


   Both home and the correspondent registrations are valid for limited
   time only. For security reasons, these lifetimes are limited for
   correspondent nodes. If, after seven minutes, the mobile node did not
   move, it must refresh the existing registration with its
   correspondent nodes.





Arkko & Vogt             Expires April 1, 2005                 [Page 15]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



3.3  Security Analysis


   To analyse the security of the return-routability procedure, one
   should evaluate its protection against the tree types of attacks
   described in section Section 2: impersonation attacks against a
   mobile node, resource-exhaustion attacks against mobile nodes or
   correspondent nodes, and flooding attacks against third parties.


   Mobile IPv6 uses the home address as an identifier for a mobile node.
   Impersonation attacks are thus based on claiming ownership of another
   node's IP address. The return-routability procedure can prevent such
   attacks unless the attacker is on the path from the correspondent
   node to the victim (in the case of a stationary victim) or from the
   correspondent node to the victim's home agent (if the victim is
   mobile). However, if an attacker happens to be on the critical path,
   it can spoof a Home Test Init message on behalf of the victim,
   eavesdrop on the returning Home Test message, and thus illegitimately
   acquire a Home Keygen Token. The impersonator can produce its own
   Care-of Keygen Token by sending the victim's correspondent peer a
   Care-of Test Init message with a care-of address the impersonator
   itself is reachable through. Both tokens allow the attacker to send
   an authenticated Binding Update message on behalf of the victim.


   The described susceptibility to attacks from the routing path between
   two communicating nodes conforms with the design objective to make
   the security of a mobile Internet as secure as the current,
   non-mobile Internet. After all, an on-path attacker can compromise
   the communications of two nodes already today. It can block
   communications, or it can interfere by ingesting its own packets.


   The similarity between the home-address test and the care-of-address
   test belies the different purpose of these exchanges. While the
   former is to prevent impersonation attacks, the latter tackles the
   problem of flooding attacks by probing a mobile node's presence at a
   new care-of address. As with the home-address test, there are
   scenarios where the care-of-address test takes no effect. Namely, it
   cannot protect against attackers that are on the path between the
   victim and the correspondent node at which traffic is to be
   redirected. In this scenario, the attacker can perform a
   care-of-address test on behalf of the victim further down the path.


   Again, the exposure to on-path attacks corresponds to the objectives
   of the Mobile IPv6 security design. Flooding attacks initiated by an
   on-path attacker are already a threat in the non-mobile Internet: An
   on-path attacker could initiate, say, a large file download from an
   FTP server on behalf of a victim if the attacker is on the path from
   the FTP server to the victim. In this case, the attacker would
   probably do a TCP handshake using the victim's IP address. As it is




Arkko & Vogt             Expires April 1, 2005                 [Page 16]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   on path, the attacker could hear the messages from the FTP server,
   and it could respond to them. The attacker would so learn the TCP
   Initial Sequence Number, which it needs to later spoof
   acknowledgements on behalf of its victim. These things considered,
   the care-of-address test inherent in the return-routability procedure
   limits flooding attacks to exactly those situations in which
   comparable flooding attacks are already possible today.


   Yet, the limitation to on-path attacks alone is insufficient to
   prevent a related style of attack that is called "space- and
   time-shift attacks". In these attacks, the perpetrator taps the
   critical wire in order to obtain the secret information it needs, and
   it then moves to a saver place and starts an attack from there. The
   attacker could also wait for a better point of time. It may even
   install a binding on behalf of a victim before the victim starts
   communicating. Mobile IPv6 requires mobile nodes to refresh active
   care-of-address registrations in intervals of at most seven minutes
   in an attempt to mitigate the threat of space- and time-shift
   attacks.


   The return-routability procedure is such that the correspondent node
   does not need to explicitly store the Home or Care-of Keygen Tokens
   sent to a mobile node. Given the index of a random nonce that was
   used to create a token, the correspondent node can recalculate the
   token. This saves the correspondent node from attacks against its
   memory. On the other hand, it may open the door for attacks against
   the correspondent node's processing capacity. A token is a SHA-1 hash
   on the mobile node's care-of or home address, the correspondent
   node's address, a random nonce, and a secret known only to the
   correspondent node. The related processing overhead is hence rather
   moderate, although a correspondent node should implement its own
   policies to manage resources in a situation of increased processing
   workload.


4.  Objectives for Enhancement


   This section discusses the objectives for enhanced or alternative
   designs for route optimization. We discuss the objectives from a
   requirements perspective, such as the need for decreasing latency.
   The technical means to reach those objectives is not considered here,
   nor is the feasibility of achieving them.


4.1  Latency Optimizations


   A disadvantage of the return-routability procedure is that a mobile
   node must wait for both address tests to complete before it can
   register a new care-of address. Therefore, a correspondent
   registration consumes, at a minimum, one and a half round-trip times




Arkko & Vogt             Expires April 1, 2005                 [Page 17]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   between a mobile node and its correspondent node, counting the
   parallel address tests and the transfer of the Binding Update
   message. An additional one-way time elapses until the first packet
   from the correspondent node arrives at the new care-of address. Note
   that two different paths are employed: the direct path between the
   mobile node and the correspondent node, and the path via the home
   agent. The actual latency is governed by the path with a longer
   round-trip time.


   Direct communications to the correspondent node can optimistically
   start right after the Binding Update message has been sent (i.e.,
   after one round-trip time), but more generally are delayed until the
   Binding Acknowledgement message is received (i.e., after two
   round-trip times).


   Similarly, optimistic mobile nodes are allowed by RFC 3775 to start
   their return-routability procedure right after sending a Binding
   Update message to their home agent. They can so reduce the latency
   for the correspondent registration. But more generally, mobile nodes
   wait for the home registration to be completed and acknowledged
   before continuing with the correspondent registration.


   Depending on the type of application, the above delays can be an
   issue. For instance, this can be a problem in real-time voice-over-IP
   applications. Even fast bulk-data transfer can be affected if the
   lack of packets during the movement period is interpreted as
   congestion, leading to a new TCP slow start. There appears to be
   general consensus that faster mechanisms for route optimization are
   needed.


   Note that delays introduced by the rest of the stack can be
   significant as well (see Section 6.3.1). The sum of the delays from
   the link layer, IP layer, and IP mobility mechanisms must not exceed
   the requirements of the application.


4.2  Signaling Optimizations


   As stated in Section 3, one objective of the return-routability
   procedure is to prevent time-shift attacks. Time-shift attacks are
   prepared on the path between the victim and its correspondent node,
   but launched at a later time and from a different, probably more
   amenable location. Since authentication material is exchanged in
   unencrypted form during the return-routability procedure, an on-path
   eavesdropper can get hold of it. Mobile IPv6 requires that
   authentication material have limited lifetime in an attempt to
   prevent the eavesdropper from taking the stolen information to a
   different position. Registrations must be refreshed at least every
   seven minutes, even in the absent of handovers. Such periodic




Arkko & Vogt             Expires April 1, 2005                 [Page 18]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   re-registrations limit the likelihood and feasibility of off-path
   attacks. After all, if a malicious node overheard authentication
   material on path and moved off path to launch the attack, it would
   have to get back on path when the authentication material is due to
   be refreshed.


   [5] shows that the seven-minute refreshment interval implies a
   signaling overhead of 7.16 bps [5] when one mobile node communicates
   with a stationary node. If both peers are mobile, the signaling
   overhead doubles. For two communicating nodes, this signaling
   overhead is certainly negligible. On the other hand, the accumulated
   overhead generated by a network provider's customer base can grow an
   issue. As an example, consider a mobile-phone provider that offers
   some sort of event-driven messenger service for its customers. For
   instant message delivery and reduced load on the core network, the
   provider may prescribe the use of route optimization. (Note that,
   with bi-directional tunneling, messages for all subscribers would
   have to be relayed through a home agent. This could drastically the
   increase network load.) On the other hand, even route optimization
   requires a home agent. For example, of the 716 Mbps signaling
   overhead generated by 100 million route-optimized mobile nodes, 220
   Mbps goes through the home agent.


   The signaling may also be an issue for mobile nodes that are inactive
   and stay at the same location for a while. Usually, these nodes have
   limited energy supply and prefer to go to standby mode when no
   transmissions are needed. Route optimization, however, would require
   them to continually wake up and re-register. This shows that an
   optimization for reduced signaling could be beneficial.


4.3  Security Enhancements


   In the current Internet, nodes can, and typically will, communicate
   even though they do not have a pre-existing relationship. This is
   usually not an issue, because most data exchanged on the Internet is
   non-confidential. On the other hand, recall from Section 2 that
   mobility does require authentication also for non-confidential
   communications, because mobility-related attacks may otherwise
   compromise the Internet community as a whole.


   The standard return-routability procedure takes a zero-configuration
   approach. This is lightway and prevents mobility-related attacks
   reasonably well. On the other hand, better security would be useful,
   particularly to limit what on-path attackers (including the nodes in
   the same network as the endpoints) can do.  There are existing
   proposals that offer higher security in Mobile IPv6 [32] and in other
   protocols such as HIP [27].





Arkko & Vogt             Expires April 1, 2005                 [Page 19]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   However, even with better security for mobility management, the
   Internet as a whole cannot get any safer than the non-mobile
   Internet. For instance, even with plain IPv6 can on-path attackers
   cause denial of service, or inspect and modify cleartext packets.
   Communications that are encrypted end-to-end are vulnerable only to
   denial of service. So, applications that require strong security are
   generally advised to end-to-end mechanisms such as IPsec or TLS.


   However, better route-optimization security may become necessary in
   the future, if improvements in other areas of Internet technology
   remove some of these plain IPv6 vulnerabilities. For instance, the
   use of Secure Neighbor Discovery [4] on the network where one of the
   endpoints resides removes some of the existing threats.


   Yet, a security association alone does not suffice as an enhanced
   security mechanism. General security associations typically do not
   show that a node owns a specific IP address, a property that is
   desired in the case of route optimization to authenticate home
   addresses. Certificate technology, for instance, usually does not
   track the correct IP-address assignments of a large group of users.
   Also, the validity of care-of addresses cannot be ensured by a
   security association alone. The security association must either be
   accompanied by a trust relationship, or care-of addresses must be
   checked otherwise. This shows that enhancements to the security of
   route optimization are likely to employ Mobile-IPv6-specific
   technology rather than general-purpose security tools.


4.4  Applicability Enhancements


   In Mobile IPv6, a mobile node's home address and current care-of
   address are carried in all route-optimized packets. The course of the
   mobile node may therefore easily be tracked by an observer. This can
   be an issue in situations where the mobile node prefers not to reveal
   its location. Location privacy, however, is inherently not supported
   by Mobile IPv6 route optimization. One solution is to fall back to
   bidirectional tunneling when location privacy is an issue. The path
   between the mobile node and its home agent can then be encrypted
   through IPsec ESP [16][17]. For full privacy protection the mobile
   node may have to re-establish its IPsec security associations,
   however, so that it cannot be tracked through its SPIs. On the path
   between the home agent and the correspondent node, all packets bear
   the mobile node's home address only. Hence, it is impossible for an
   outsider to realize when the mobile node is at home and when it is
   not.


5.  The Toolbox


   This section introduces a number of techniques (the "toolbox") that




Arkko & Vogt             Expires April 1, 2005                 [Page 20]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   can be used in the construction of a route optimization protocol. The
   section starts with the basic techniques used in RFC 3775 and
   continues with additional techniques that have been proposed as
   enhancements or alternatives.


   It is important to note that many of the specific techniques are
   insufficient or insecure on their own, as they address just one
   aspect of the problem. It is the combination of a set of techniques
   that makes a secure and efficient route optimization mechanism
   possible. Different techniques also have different trade-offs with
   respect to, say, universal applicability versus efficiency.


5.1  Address Tests


   An address test can be employed to ensure that the peer is live and
   at least on the path to a specific destination address. RFC 3775 uses
   address tests for two purposes, for ensuring (weak) ownership of the
   home address, and for preventing flooding attacks related to spoofed
   care-of addresses.


   As specified in RFC 3775, such address tests can also be stateless
   for the correspondent node, making their use in denial-of-service
   attacks harder.


   The limitations of address tests relate to their security properties
   and the required number of messages. The security provided by an
   address test can only guarantee that the peer is on the path, not
   that the peer truly owns its address or other identifier. On the
   other hand, on-path attackers are in any case capable of performing
   the same type of attacks as would be possible by misuse of route
   optimization, so this does not present a significant new threat in
   the Internet.


   The use of two address tests requires four messages although it can
   usually be completed in one roundtrip by employing parallelism.


5.2  Protected Tunnels


   An additional technique used in RFC 3775 is the protection of a part
   of the signaling communications through an encrypted tunneled to the
   home agent. This prevents other nodes, close to the mobile node, from
   seeing the home address tests.


   Given the starting point that we can not assume a security
   association with the correspondent node, this protection exists only
   for the mobile node side; an attacker close to the correspondent node
   would be able to perform various attacks (similar to those that an
   attacker in that position would be able to do even in the non-mobile




Arkko & Vogt             Expires April 1, 2005                 [Page 21]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   case). The use of security associations with correspondent nodes is
   discussed further in Section 5.11.


5.3  Optimistic Behaviour


   RFC 3775 leaves quite a bit of freedom for mobile nodes regarding
   when they initiate the different procedures, and when they start
   sending data packets. An optimistic mobile node can initiate the
   return routability procedure right after sending the Binding Update
   to the home agent, even before it has gotten an Acknowledgement back.


   Mobile nodes may also start sending data packets right after having
   sent the Binding Update to the correspondent node.


   The drawback of this behaviour is that a dropped, re-ordered, or
   rejected Binding Update can cause data packets to be dropped.


5.4  Proactive Tests


   One technique for reducing delay is to move some of the tasks from
   the critical path to an earlier stage. In particular,
   movement-related signaling that needs to complete before
   communications can resume is on the critical path.


   As discussed in [15] and [36], the home address test in standard
   Mobile IPv6 can be done "proactively". This eliminates the need to do
   a home address test after the movement.


   As described in Section 3, a mobile node must refresh an existing
   binding at least every seven minutes. Since a Home Keygen Token is
   generally valid for no longer than 3.5 minutes, the mobile node must
   acquire a fresh Home Keygen Token prior to a binding refreshment. If
   a mobile node seeks to have available a fresh Home Keygen Token at
   all times it needs to initiate a proactive home-address test every
   3.5 minutes even though it may not need to refresh its binding. Thus,
   upon a handover, the mobile node has already a fresh Home Keygen
   Token at hand when it arrives at the new link after handover.
   (Alternatively, the mobile node may be able to receive a trigger from
   its local link layer indicating that a handover is imminent. In this
   case, the mobile node may initiate the home-address test right in
   time instead of doing it periodically every 3.5 minutes.)


   Another optimization possibility is performing a care-of address test
   before the movement.  This is possible only if the mobile node is
   capable of attaching to two networks simultaneously.







Arkko & Vogt             Expires April 1, 2005                 [Page 22]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



5.5  Concurrent Tests


   Assuming a proactive home test has been performed but a care-of test
   has not, the mobile node cannot send a Binding Update immediately
   after the handover because it is still missing a valid Care-of Keygen
   Token for the new care-of address. On the other hand, the mobile node
   already has the Home Keygen Token. Recall from Section 3 that the
   Home Keygen Token authenticates the mobile node, through certifying
   the mobile node's ownership of the home address. In the concurrent
   test technique, the mobile node sends to the correspondent node an
   Early Binding Update. This message is is similar to the Binding
   Update used in standard Mobile IPv6 except that it is authenticated
   with the Home Keygen Token only.


   When the correspondent node receives the Early Binding Update, it can
   be confident that the mobile node uses the correct home address,
   because a valid Home Keygen Token was used to sign the message. On
   the other hand, the message-authentication code does not bear a
   Care-of Keygen Token, so the correspondent node cannot be sure
   whether the mobile node is actually present at the claimed new
   care-of address. The correspondent node thus registers the mobile
   node's new care-of address, labeling it "unconfirmed" for the time
   being.


   The mobile node can use the new care-of address as soon as it has
   dispatched the Early Binding Update. The mobile node then initiates a
   care-of-address test. When it receives the Care-of Keygen Token, it
   can send to the correspondent node a standard Binding Update. The
   message-authentication code is produced with the new Care-of Keygen
   Token and the Home Keygen Token from the proactive home-address test.
   When the correspondent node receives the standard Binding Update
   message, it can be confident that the mobile node uses the correct
   home address, and that the mobile node is actually present at the new
   care-of address. The correspondent node then changes the status of
   the new care-of address from "unconfirmed" to "confirmed".


   Due to the lack of care-of-address authentication in the Early
   Binding Update message, there needs to be additional protection while
   a mobile node's care-of address is unconfirmed. If no such protection
   is provided, a malicious node may misuse Early Binding Updates to
   register, as an unconfirmed care-of address, the IP address of a
   third party. This implies a vulnerability to flooding attacks (c.f.
   Section 2). Albeit the vulnerability is limited to a short period
   after handover, there needs to be additional protection while a
   mobile node's care-of address is unconfirmed. Heuristics could be
   used, but are per definition reactive. Heuristics may also result in
   false positives or, even worse, false negatives. (An enhancement to
   concurrent tests that avoids these problems is discussed in Section




Arkko & Vogt             Expires April 1, 2005                 [Page 23]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   5.7.)


   The concurrent tests avoid the delay that emanates from the home- and
   care-of-address test by moving both tests to more suitable phases.
   This saves one round-trip time between the mobile node and the
   correspondent node, potentially through the home agent due to
   bidirectional tunneling for the home-address test. A disadvantage,
   however, is the increase in signaling that comes with the proactive
   home-address test: Unless the mobile node cannot anticipate a
   handover through link-layer triggers, the home-address test must be
   performed roughly every 3.5 minutes instead of the minimum rate of
   once every seven minutes prescribed by the Mobile IPv6 base
   specification. ([5] describes an signaling-reduction technique that
   can mitigate this impact when combined with Early Binding Updates.)


5.6  Diverted Routing


   Given that the per-movement signaling takes some time, mobile nodes
   can optionally request their traffic to be routed through their home
   address while this signaling is being completed.


   The performance impact of this approach depends on the length of the
   signaling period and the capacity and latency of the path through the
   home agent. We can generally analyze the fate of the different parts
   of the inbound payload traffic stream as follows:


   Packets sent before movement is known


      The correspondent node does not know the mobile node has moved
      until it has been told about this. In addition, being able to tell
      the correspondent node may itself involve some security-related
      signalling. The packets sent before the movement is are going to
      be lost, unless the mobile node is still connected also to its
      previous attachment point or local repair techniques (see Section
      5.15) are used.


   Packets sent during the early part of signaling


      Assuming that the route optimization signaling involves messages
      through the home agent, it can be expected that at least the first
      packets sent from the correspondent will make it to the mobile
      node before the registration process is complete. This is because
      they have to travel the same path.


   Packets sent during the later part of signaling


      The fate of the packets sent via the home agent close to the end
      of the signaling period depends on the relative capacity and




Arkko & Vogt             Expires April 1, 2005                 [Page 24]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



      latency of the home agent and direct paths. If former path has a
      high latency, it might be better to queue the packets and wait for
      the signalling to be completed.


      One potential research direction is to look at whether the
      properties of the paths could be learned during the signaling and
      then used to decide the optimal time when the correspondent node
      should start queueing packets.


   The situation for the outbound traffic stream is similar, except that
   the mobile node knows immediately that it has moved, and thus first
   packets do not get lost.


   This technique appeared originally in [36] and has since then be used
   also in [13].


5.7  Credit-Based Authorization


   Credit-Based Authorization (CBA) [35] is a technique that allows a
   correspondent node to already send packets to a new care-of address
   while the care-of-address test is in progress. The mobile node
   registers the new care-of address first, and it initiates the
   care-of-address test thereafter. CBA ensures that the mobile node
   still cannot wage an amplified flooding attack.


   The attraction of a redirection-based flooding attack emanates from
   its inherent potential for amplification. This is to say, the flooded
   victim sees itself confronted with a much higher data load than the
   attacker generates itself. The idea of CBA is that a correspondent
   node, when requested by a mobile node to switch to an unconfirmed
   care-of address, weighs the volume and rate of packets recently
   received from the mobile node against the volume and rate of packet
   that it sends to the mobile node's unconfirmed care-of address. Thus,
   if an attacker decided to misuse an unconfirmed care-of address for
   malicious redirection, it would not gain any amplification. Indeed,
   it would take less coordinative effort, and be at least equally
   effective, to send bogus packets to the victim directly.


   With CBA, a correspondent node maintains a credit account for each
   entry in its binding cache. When the correspondent receives a packet
   from a mobile node, it increases the credit in that mobile node's
   binding-cache entry by the size of the inbound packet. While the
   binding-cache entry holds a confirmed care-of address, the credit
   does not change when the correspondent node sends a packet that
   care-of address. However, when the care-of address is unconfirmed,
   the credit decreases by the size of each packet sent to that address.
   If the credit would be decreased to a negative value for a particular
   packet, that packet cannot be sent to the care-of address. With




Arkko & Vogt             Expires April 1, 2005                 [Page 25]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   Mobile IPv6 and concurrent tests, the correspondent node can send
   such packets to the mobile node's home address. This is legitimate
   because the home address has been proactively verified before. For
   other protocols that do not provide an equivalent static IP address
   through which a mobile node is reachable, such packets may either be
   buffered for later transmission, or they may simply be discarded. HIP
   [27] and Mobike belong to the latter protocol category, although, in
   HIP, rendez-vous servers may theoretically be extended to provide
   mobile nodes with static IP addresses for constant reachability.


   The correspondent node exponentially ages existing credit, thereby
   giving precedence to credit obtained recently. This guarantees that a
   mobile node cannot collect credit over an extended time period at a
   very slow speed and use this credit, all at once, for a short but
   potent data burst towards a fraudulent unconfirmed care-of address.


   It is believed that a fair-minded mobile node sends packets to the
   correspondent node as part of its normal operation. Under many
   circumstances, the mobile node should thus automatically earn credit
   due to its normal behavior. Still, the proposal for CBA specifies an
   alternative mode that better accommodates applications with
   asymmetric traffic patterns such as file transfers and media
   streaming. Those applications are characterized by high throughput
   towards the client, typically the mobile node, and comparably little
   throughput towards the serving correspondent node. In the second
   mode, the correspondent node allocates credit for packets that it
   sends to a confirmed care-of address of the mobile node, rather than
   for packets that it receives. It is perspicuous that a mobile node,
   as well as an attacker, invests comparable effort for data reception
   as for transmission, in terms of bandwidth, memory, and processing
   capacity. In-band care-of-address spot checks allow the correspondent
   node to determine the approximate packet loss on the path towards the
   mobile node, and to derive the mobile node's average reception rate.
   An interesting property of the first version of CBA is that it does
   not require support from a mobile node. A mobile node neither needs
   to understand that CBA is effective at the correspondent node, nor
   does it have to have an idea of how much credit it currently has. If
   packet loss is not an issue, care-of-address spot checks may be
   omitted so that the second version of CBA is transparent as well.


5.8  Heuristic Monitoring


   Heuristic approaches are conceivable as well. For instance, one may
   consider a lifetime limit for unconfirmed care-of addresses which,
   supplemented by a heuristic for misuse detection, can prevent, or at
   least effectually discourage, misuse of such addresses. The challenge
   here seems to be a feasible heuristic: On one hand, the heuristic
   must be sufficiently rigid to catch any malicious intents at the




Arkko & Vogt             Expires April 1, 2005                 [Page 26]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   other side. On the other hand, however, it must not have a negative
   impact on a fair-minded mobile node's communications.


   Correspondent nodes could also track the behaviour of mobile nodes
   over a longer period of time, and refuse communicating with them if
   they misbehave. The problem with this approach is that attackers can
   invent new addresses and other correspondent nodes to use in their
   attacks.


5.9  Cryptographically Generated Addresses


   Public-key cryptography is a powerful mechanism for mutual
   authentication between two nodes that do not know each other. Yet,
   the key question with public-key cryptography is how the nodes can
   trust in the respective other node's public key. How can an attacker
   be stopped to spoof its identity and use a false public key? The crux
   is that, generally, one cannot see from an identifier to which public
   key it belongs. There may not even be a one-to-one relationship
   between the identifier and the public key.


   In today's Internet, the identity-key matching problem is solved
   through certification authorities that have a reputation to be
   trustworthy. Nodes that want to mutually authenticate send each other
   their identities and public keys. Each node can then contact a
   trusted certification authority and have it verify whether the two
   parameters match. Once a node knows that its peer's public key is
   correct, it can verify whether the peer actually knows the right
   private key by decrypting the encrypted version of a certain piece of
   data.


   This mechanism has two disadvantages: First, it relies on the trusted
   certification authorities. If the certification authorities fail or
   are target of an attack, public-key cryptography is seriously
   compromised. Second, authorities usually delegate certain requests to
   other authorities. So, going through the authentication process can
   be time and resource consuming for the querier.


   These two drawbacks made public-key cryptography little attractive
   for Mobile IPv6. On the other hand, the described mechanism was
   designed to authenticate arbitrary transactions. This level of
   generality is actually not needed for mobility support. For example,
   a proof of home-address ownership would be sufficient in Mobile IPv6.
   This is where Cryptographically Generated Addresses (CGA) is helpful
   [8].


   A CGA is an IPv6 address, which contains a set of bits generated by
   hashing the IPv6 address owner's public key. Such feature allows the
   user to proof that it is the legitimate owner of the its IPv6




Arkko & Vogt             Expires April 1, 2005                 [Page 27]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   address.


   The CGA offers three main advantages: First, it makes the spoofing
   attack against the IPv6 address much harder. Second, it allows to
   sign messages with the owner's private key. Third, CGA does not
   require any upgrade or modification in the infrastructure.


   The CGA offers a method for binding a public key to an IPv6 address.
   The binding between the public key and the CGA can be verified by
   re-computing and comparing the hash value of the public key and other
   parameters with the interface identifier from the owner's IPv6
   address. Both the public and the additional parameters are sent with
   the message that requires authentication. Note that an attacker can
   always create its own CGA address but he will not be able to spoof
   someone else's address since he needs to sign the message with the
   corresponding private key, which is supposed to be known only by the
   real owner.


   The CGA technique was originally described in [28] and in [31], and
   it has later been used in [32], [8], and [13], among others.


5.10  Semi-Permanent Security Associations


   In the above techniques each movement involves a new, complete round
   of signaling. In the semi-permanent security association technique a
   key is established upon first contact, and then this key is later
   used in movements later, making the signaling efficient and secure.
   The primary security benefit of this approach is that the subsequent
   communications can be securely bound to the initial contact.


   Another way to look at this technique is that a key is created for a
   specific purpose or resource, and that all requests relating to that
   resource have to be authenticated by the same key.


   This technique works well in applications where the secured resource
   can be identified by the key. For instance, in HIP [27],
   opportunistic security can be achieved through binding all
   communications to the public keys generated by the participants.


   This technique is less secure when the resource is identified by some
   other means. For instance, if solely this technique is used for route
   optimization security in Mobile IPv6, there is nothing that prevents
   a malicious node from grabbing someone else's address and claiming
   that all subsequent signaling related to that address has to be
   authenticated through the attacker's public key. As a result, this
   technique is typically applied together with some other means to
   ensure the ownership of the resource, such as CGA as was done in
   [13].




Arkko & Vogt             Expires April 1, 2005                 [Page 28]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   Semi-permanent security associations were first developed in [10]
   where they were called Purpose Built Keys (PBKs). They have since
   then been applied in [12] and [13].


5.11  Pre-Configuration


   The currently standardized route optimization method is based on the
   assumption that no security association or configuration can be
   expected between mobile and correspondent nodes either directly or
   via an infrastructure. However, in situations where such
   configuration is possible, efficiency and security improvements
   become possible.


   Perhaps the simplest route optimization security mechanism is the use
   of a shared secret between the mobile and correspondent nodes, as
   defined in [26].


5.12  Infrastructure


   Infrastructure can provide assistance by vouching for the correctness
   of the home address, correctness of the care-of address, or the
   trustworthiness of the mobile node.


   This infrastructure can take many forms, such as a PKI tailored for
   for the route optimization problem or AAA enhanced with the required
   features.


   In its basic form, the infrastructure hands out home addresses and
   associates some keys with these addresses. It could produce
   certificates that could be used by others to verify the binding of
   the used key to the right home address, or it could provide a query
   interface where this verification is performed within the
   infrastructure.


   Setting up such infrastructure has generally been considered
   impossible for general Internet use. One of the problems is the
   current separation of address assignment and security
   infrastructures.  However, [9] suggests a useful simplification: only
   home agents need to be assigned such prefix-based certificates, as
   they can vouch for their own mobile nodes. This makes the
   infrastructure problem more tractable.


   The infrastructure could also just identify the trustworthy mobile
   nodes. Together with an identifier for each mobile node, this could
   be used to retroactively track down misbehaving nodes.


   The use of infrastructure for care-of address verification could be
   based on the querying local network access system about the existence




Arkko & Vogt             Expires April 1, 2005                 [Page 29]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   of a node at a claimed address. The mobile node would be identified
   by some means (such as a public key) known both to the correspondent
   node and the AAA network. The problem with this is that a global AAA
   system would have to be provided in order for a correspondent node to
   find out whether a mobile node connecting to it from the other side
   of the world is legitimate.


5.13  Cryptographically Bound Identifiers


   The primary problem in route optimization is to ensure that the home
   address is owned by the node that claims it. While the Mobile IPv6
   architecture can not easily be changed with respect to the use of the
   home address as an identifier, other protocols have avoided some of
   these problems through the use of a cryptographic identifier.  For
   instance, in HIP [27] a cryptographic identity is the primary
   identifier that binds all communications and upper layer protocols to
   the lower-level signaling exchanges. In HIP this identifier is a
   public key compressed to a 128-bit value through a hash function. The
   use of this type of identifiers avoids the home address ownership
   problem, but it is still necessary to verify the correctness of
   care-of addresses to avoid flooding attacks.


5.14  Local Mobility


   Local mobility can be provided via protocols such as Hierarchical
   Mobile IPv6 [33]. Local mobility supplements the end-to-end mobility
   support of standard Mobile IPv6. It brings performance improvements
   in terms of signaling overhead and handover latency. Hierarchical
   Mobile IPv6 introduces the concept of a regional Mobile Anchor Point
   (MAP). A MAP acts as a local home agent towards a visiting mobile
   node, and it proxies the mobile node towards the mobile node's home
   agent and correspondent nodes. Typically, a MAP serves multiple
   access networks, which are together referred to as the MAP's domain.
   Access routers in the MAP domain distribute the MAP's IP address in
   Router Advertisement extensions. The MAP is a router at a preferably
   central position within its domain.


   When a mobile node enters a visited network, it configures an
   "on-link care-of address" with the local network prefix through
   standard IPv6 Address Autoconfiguration. The mobile node may also
   configure a wider-scope "regional care-of address" with the MAP's
   network prefix and register the on-link and regional care-of
   addresses with the MAP. The MAP treats a mobile node's regional
   care-of address as a home agent treats the mobile node's home
   address. In particular, it performs Duplicate Address Detection for
   the regional care-of address. A bidirectional tunnel is established
   between the MAP and the mobile node.





Arkko & Vogt             Expires April 1, 2005                 [Page 30]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   The mobile node registers the regional care-of address with its home
   agent and correspondent nodes. The MAP is prepared to intercept
   packets addressed the regional care-of address. It tunnels these
   packets to the mobile node's on-link care-of address. Vice versa, the
   mobile node may--or may have to if administratively prescribed in the
   access network--tunnel outbound packets to the MAP, which in turn
   decapsulates these packets and forwards them on to the recipient.
   When the mobile node moves to a different network within the same MAP
   domain, it updates the binding at the MAP, but it can leave the
   existing bindings at its home agent and correspondent nodes in place.


5.15  Local Repair


   A local repair technique involves reducing the ill effects of a
   movement, such as the ability to redirect packets received at a
   previous location to the new location.


   Fast Handovers for Mobile IPv6 [18] is one such optimization. It
   provides support from the access network that assists a mobile node
   during handover. Fast Handovers packages three functions: proxy
   router discovery, proactive IPv6 address configuration and proxy
   neighbor discovery, and provision against packet loss during
   handover.


   When a mobile node recognizes that a handover to a new access point
   is imminent--for instance, through a trigger from its local link
   layer--the mobile node can inquire of its current, old access router
   about a router attached to the detected new access point. For this,
   the mobile node sends a Router Solicitation for Proxy Advertisement
   to the old access router along with the MAC address of the new access
   point. Access routers are configured with tables matching near-by
   access points' MAC addresses to information about attached access
   routers. When the old access router hears a Router Solicitation for
   Proxy Advertisement, it looks up its table for an access router on
   the prospective new link, and it sends a Proxy Router Advertisement
   on behalf of that router.


   With the Proxy Router Advertisement at hand, the mobile node can
   configure a care-of address for the new link, even though it is still
   connected to the old link. Preferably right before handover, the
   mobile node signals the new care-of address to its old access router.
   The old access router verifies the new care-of address with the new
   access router and sends to the mobile node an acknowledgement
   indicating the result. If the suggested care-of address is
   acceptable, the new access router starts proxying the address.
   Otherwise, it signals an alternate care-of address to the old access
   router which, in turn, includes that address in its acknowledgement.





Arkko & Vogt             Expires April 1, 2005                 [Page 31]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   Packets for the mobile node may still arrive at the old care-of
   address after the mobile node has switched to the new link. The old
   access router tunnels those packets to the mobile node's new care-of
   address.


   There are two exceptions that are worthwhile mentioning. During proxy
   router discovery, the old access router may not be configured with
   information about an appropriate new access router. No proxy router
   discovery can then be provided. Nonetheless may the mobile node
   request the old access router, from the new link, to forward any
   packets that subsequently arrive at the old care-of address.
   Furthermore, during proactive IPv6 address configuration, it may turn
   out that the mobile node's suggested care-of address is unacceptable,
   and the mobile node may no longer be at the old link when the old
   access router sends the acknowledgement with the alternate care-of
   address. In this case, the mobile node fails when attempting to
   connect to the new network with the unacceptable care-of address. The
   new access router may then install a host route for the old care-of
   address and set up a bidirectional tunnel with the old access router
   between the old and new care-of addresses. (Note that outbound
   tunneling is necessary to ensure topological correctness of the
   packets' IPv6 source addresses.) Thus, the mobile node may continue
   to use its old care-of address at the new link until it has
   successfully configured a new care-of address through standard IPv6
   Address Autoconfiguration.


   In a non-optimized environment, standard router discovery and IPv6
   Address Autoconfiguration can cause substantial disruption to ongoing
   communications during a handover. With Fast Handovers, a mobile node
   can accomplish these tasks proactively before the handover. Moreover,
   the mobile node's communication peers typically continue to use an
   outdated care-of address for some time after a handover due to the
   natural latency of global Mobile IPv6 signaling. In a standard
   setting, packets sent to a stale care-of address are typically
   dropped. Fast Handovers salvage these packets by means of the
   tunneling service from the old to the new access router. This enables
   lossless handovers.


   Fast Handovers can nicely be integrated with Hierarchical Mobile IPv6
   [33]. The mobile node then registers a prospective new care-of
   address directly through the MAP, rather than through the old access
   router, for efficiency reasons. The forwarding service for packets
   sent to an outdated care-of address is also provided by the MAP.


5.16  Processing Improvements


   Processing power is in general not as significant issue in route
   optimization as the amount of signaling and latency. However, this




Arkko & Vogt             Expires April 1, 2005                 [Page 32]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   can still be an issue for busy servers or proposals that are based on
   public key operations. For these cases, new types of cryptographic
   algorithms (such as ECC instead of RSA) might provide some
   assistance.


5.17  Delegation


   Given that the home agent does not need to move or conserve battery
   energy, it can be used for performing computationally expensive
   tasks. It can also be used for parts of the signaling, to reduce
   communications over slow wireless links.


   Some work relating to delegation has been done in [32] and [9].


6.  Analysis


   This section analyzes the previously presented techniques in relation
   to each other and the enhancement objectives. We start by looking at
   how the techniques can be categorized, continue by studying a number
   of proposals that apply a number of techniques to reach a goal, and
   conclude with some subjects for further research in this area.


6.1  Categorization of Techniques


   Local techniques require support from the access network that the
   mobile node is attached to. HMIP and FMIP are examples of local
   techniques. They can significantly mitigate the disruptive impact
   that movements have on ongoing communications.  Yet, they require
   investments at the access network and thus imply additional costs for
   the network operator. Also, local optimizations are ineffective for
   handovers across administrative domains unless providers have mutual
   agreements to interconnect their networks.


   End-to-end techniques do without the need infrastructure in the
   access network. They also work across administrative domains. On the
   other hand, end-to-end approaches cannot leverage the short distances
   to local network entities, but have to cope with global, thus
   potentially long, round-trip times. Hence, end-to-end techniques
   cannot usually catch up with the high performance gains that are
   characteristical for local optimizations.


   Zero-configuration techniques require no preconfiguration or
   assistance from a managed infrastructure. Address tests, proactive
   tests, concurrent tests, diverted routing, credit-based schemes,
   monitoring, CGA, semi-permanent, cryptographically bound identifiers,
   processing improvements, and delegation are zero-configuration
   techniques.





Arkko & Vogt             Expires April 1, 2005                 [Page 33]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   Pre-configuration and infrastructure-based methods are not
   zero-configuration techniques.


   Local techniques have traditionally been implemented in a manner that
   requires configuration, but there appears to be no fundamental reason
   why this would have to be so.


6.2  Evaluation of Some Proposals


6.2.1  Local Assistance


   IETF's two current protocols for localized assistance to mobile nodes
   have been described in Section 5.14 and Section 5.15.


   Hierarchical Mobile IPv6 (HMIPv6) screens a mobile node's movements
   within a MAP domain from nodes not inside that domain. In case
   standard Mobile IPv6 is used end-to-end, this eliminates most of the
   global signaling: While its regional care-of address does not change,
   a mobile node does not need to update its home agent or correspondent
   nodes beyond the mandatory periodic refreshments. Not having to
   signal on a global basis also reduces handover latency.


   Updates to the home agent and to correspondent nodes are necessary
   only when the mobile node leaves the current MAP domain. The mobile
   node may then register a new regional care-of address with a
   different MAP if one is available. Note that switching MAPs usually
   requires the mobile node to signal more than if standard Mobile IPv6
   was used alone. Local and end-to-end signaling then comes together
   because, as it stands, a mobile node must contact the new MAP
   seperately from its home agent and correspondent nodes. Due to
   dependencies between a MAP registration and a contemporary home or
   correspondent registration, a mobile node may want to wait for the
   MAP registration to complete before it initiates the standard Mobile
   IPv6 registration procedure. Handover latency is then increased in
   addition to the signaling overhead. Future work should thus go into
   the integration of MAP registrations with standard Mobile IPv6
   signaling.


   Another interesting research opportunity seems to be a mechanism that
   tells neighboring MAPs from different administrative sites that their
   domains overlap. The MAPs could then mutually advertise each other
   throughout certain parts of their domains.


   The cost for an inter-MAP handover in terms of signaling load and
   delay strongly depends on the network topology. In an optimal layout,
   a MAP is located somewhere on the path from the mobile node to its
   home agent and correspondent nodes. This may be the case if the MAP
   is co-located with an Internet gateway. Then, switching MAPs is




Arkko & Vogt             Expires April 1, 2005                 [Page 34]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   cheap. On the other hand, if the MAP is way off the direct path
   between a mobile node and its peers, the additional overhead might
   become noticeable. Indeed, a good topological layout is crucial for
   the performance of HMIPv6.


   Fast Handovers for Mobile IPv6 (FMIPv6) streamlines the
   router-discovery and IPv6-address-configuration processes, and it
   facilitates lossless handovers. FMIPv6 assumes that access routers
   are capable of matching a neighboring access point to the access
   router to which it attaches. The capability is a prerequisite for
   proxy router discovery. Yet, it is still an open issue how access
   routers learn about this information. Manual configuration is one
   option, though it can be extremely expensive. More attractive would
   be an automated mechanism that allows access routers to dynamically
   recognize access points to which mobile nodes may want to switch. A
   related issue is how such knowledge can be securely obtained across
   the borders of administrative sites. These are opportunities for
   future research.


   Note that Hierarchical Mobile IPv6 may be used even when the no
   Mobile IPv6 is used beyond the local domain. I.e., a mobile node may
   use its regional care-of address as a temporary home address. The
   mobile node would thus appear to a correspondent node as a stationary
   node in the MAP's network. The same is true for a combination between
   HMIPv6 and FMIPv6, but FMIPv6 alone cannot be used without standard
   Mobile IPv6. It should also be mentioned that HMIPv6 provides
   location privacy for mobile nodes as long as the mobile nodes do not
   move across MAP domains. In fact, a mobile node appears to parties
   outside its current MAP domain as a stationary host located in the
   MAP's network because it does not advertise its link-local addresses
   to those nodes.


   Of course, there are disadvantages with HMIPv6 and FMIPv6. Local
   optimizations in general require investments in the access network
   and thus imply additional costs for the network operator. Also, as
   mentioned, localized mobility support may even cause increased
   overhead in certain situations. And local mechanisms are to date
   ineffective for handovers across administrative domains unless
   providers have mutual agreements to interconnect their networks.


6.2.2  Preconfigured Secret Method


   It has been explained in section Section 3 that the
   return-routability procedure serves two purposes: The home-address
   test allows the nodes to authenticate mobility-related signaling, and
   the care-of-address test is needed to verify a mobile node's
   reachability. Preconfigured shared secrets allow nodes to
   authenticate without the home-address test. But without further




Arkko & Vogt             Expires April 1, 2005                 [Page 35]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   assumptions, preconfiguration cannot streamline the care-of-address
   verification process.


   The Home Keygen Token exchange from the return-routability procedure
   is the default authentication technique used in Mobile IPv6. It
   facilitates reasonable security even for nodes that have no
   pre-existing relationship. On the other hand, nodes that do share a
   common secret should be allowed to omit the home-address test. This
   can be beneficial in certain scenarios where the home-address test
   causes a long handover latency due to packet redirection through the
   home agent.


   On the other hand, the latency improvement can be much higher if not
   only the Home Keygen Token exchange, but also the Care-of Keygen
   Token exchange is ignored. Eliminating the latter, however, requires
   some sort of trust into mobile nodes not to spoof a care-of address.
   In fact, [26], a method being standardized by the IETF MIP6 Working
   Group, is based on this trust model.


   The assumption that mobile nodes be fair-minded turns out to be quite
   far stretching. On on side, it affords the elimination of the entire
   return-routability procedure, not just the Home Keygen Token
   exchange. As explained in [26], and can also be inferred from figure
   Figure 1, this can cut handover latency in half. On the other hand,
   the assumption significantly limits the applicability of the
   optimization. There are certainly scenarios where preconfiguration
   per se would be possible, but no trust model can be assumed. For
   instance, an ISP may configure its media servers with the keys of its
   customers. The customers could then use their keys and Mobile IPv6
   for communications with the media servers, but some customers might
   misuse the lack of a care-of-address test to wage a
   re-direction-based flooding attack against an arbitrary IP host. This
   example reveals the difference between a security association for
   authentication and a trust relationship for misuse prevention.


   In an effort to extend preconfiguration to scenarios where no trust
   relationship can be presupposed, one may combine it with
   care-of-address tests. Of course, the care-of-address test would
   partly vitiate the handover-latency improvement that preconfigured
   keys brings without the care-of-address test. But handover latency
   may still improve over the standard return-routability procedure
   because a care-of-address test is usually faster than a complete
   return-routability procedure. (This is because the complete
   return-routability procedure includes a home-address test, which is
   usually more expensive than the care-of-address test because it is
   directed through a home agent.) Also pre-authentication facilitates
   stronger authentication mechanisms and thus the use of route
   optimization for applications that would otherwise opt for




Arkko & Vogt             Expires April 1, 2005                 [Page 36]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   bidirectional tunneling due to security concerns.


   Moreover, preconfiguration can be used along with a combination of a
   concurrent care-of-address test and credit-based authorization or
   heuristic monitoring. This approach eliminates the home-address test
   and makes the care-of-address test transparent to applications. It
   also keeps the possibility to use an alternative authentication
   mechanism.


   These things said, it seems like a good idea to make the
   preconfiguration protocol bendable to different environments. Is
   there a small group of people who trust each other? Then, of course,
   group members are unlikely to spoof care-of addresses, and we can go
   without the care-of-address test. Or are we talking about the
   customer base of a big ISP? Then, proper authentication does usually
   not imply trust, and it may not be feasible to use preconfigured keys
   without checking a mobile node's reachability. Tracability techniques
   are not a compensation for the missing care-of-address test, because
   they are a reactive measure, whereas a care-of-address test is a
   proactive one.


   Specifically, the integration of key preconfiguration with
   care-of-address test could be done as follows. In case the
   care-of-address test is deemed necessary, a preconfigured 64-bit key
   can substitute the Home Keygen Token. The Home Keygen Token may also
   be derived in some defined way from the preconfigured key. Either
   way, signaling messages can then be authenticated in the same way as
   defined in the Mobile IPv6 specification. This amendment to [26]
   helps to broaden the scope of key preconfiguration to environments
   where end-hosts have administrative relationships with each other,
   but do not necessarily trust each other.


6.2.3  CGA-Based Optimizations


   CGA assures that a mobile node is the legitimate owner of its home
   address. As far as the correctness of home addresses go, CGA provides
   more assurance than the pure use of routing paths. This makes it
   possible to have a significant decrease in the signaling frequency.
   In addition, the public keys used in the CGA technique allow certain
   data to be communicated privately between the nodes, which makes some
   of our other techniques possible.


   GA could also be used to reduce the risk of flooding attacks via
   care-of addresses, as attackers would be unable to manufacture victim
   addresses for a specific host. However, only the interface-identifier
   part of an IPv6 address is cryptographically generated, so flooding a
   network or a link is still an issue. As a result, CGA needs to be
   employed together with a reachability test in scenarios where




Arkko & Vogt             Expires April 1, 2005                 [Page 37]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   redirection-based flooding attacks are a concern. An interesting
   future path for research would be to consider the combination of
   concurrent care-of-address tests together with CGA-based care-of
   addresses.


   CGA is typically used to assure the correctness of the home address
   that the mobile node claims to own, and combined together with other
   techniques to prevent flooding attacks. Note that this implies that
   an initial home address test is typically required too in order to
   avoid the deletion of a binding to flood an unconfirmed home address.


   The crux with using cryptographically generated care-of addresses is
   address collisions: A given public key hashes to exactly one value.
   CGA uses modifiers in the case of collisions. But as such modifiers
   weaken the cryptographic strength of CGAs, only a few (usually four)
   modifiers are allowed.


6.2.4  CBA-Based Latency Reduction


   As shown in Section 2, the ability to change a packet flows
   destination IP address can potentially be misused for a malicious
   redirection-based flooding attack. Mobile IPv6 and similar
   mobility-management protocols like Host Identity Protocol (HIP) [27]
   and current Mobike proposals solve this issue by probing a new IP
   address before that IP address is used as a destination for payload
   packets. Unfortunately, by definition, IP-address probing cannot be
   done in a proactive style. After all, a handover involving an
   IP-address change invalidates any previous probes.


   Instead, a new care-of address may be probed while packets are
   already flowing to that care-of address. This concept of concurrent
   care-of-address tests was first mentioned in [36]. CBA was added to
   secure the time phase during which a mobile node's reachability at
   the new care-of address is not yet verified, but the new care-of
   address is already in use. After all, this time phase could otherwise
   introduce a susceptibility to malicious redirection, if but for an
   albeit short time.


   As shown in Section 2, the attraction to redirection-based flooding
   attacks is its potential for easy-to-get amplification. Note that CBA
   does not prevent an attacker from spoofing its care-of address. But
   the attacker will not be able to wage an amplified flooding attack.
   More specifically, the amount of data that can be redirected to an
   unconfirmed care-of address is sufficient for a fair-minded mobile
   node to continue communications during the care-of-address test, but
   it is far from satisfactory for an attacker planning denial of
   service.





Arkko & Vogt             Expires April 1, 2005                 [Page 38]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   The challenge with CBA is how much data the correspondent node may
   exactly send to a care-of address while it is unconfirmed. If it
   sends too much, an attacker could take advantage of this. If it sends
   to little, a fair-minded mobile node might suffer performance
   degradations during the handover phase. As shown in Section 5.7,
   there are two modes for Credit-Based Authorization. In the first
   mode, the correspondent node weighs the data volume that it has
   recently received from a mobile node with the data volume that it may
   maximally send to an unconfirmed care-of address of that mobile node.
   This is the most straightforward way to make redirection-based
   flooding attacks comparable to direct flooding attacks, which are,
   after all, already possible and easy to perform in today's non-mobile
   Internet. The second mode takes the data volume a mobile node has
   recently received at a confirmed care-of address as a limit on how
   much data the mobile node can receive after handover to a new,
   unconfirmed care-of address. This second mode gives away some of the
   first mode's straightforwardness in exchange for a better support for
   applications with asymmetric data throughput. This was deemed
   necessary in consideration of applications like media streaming,
   television broadcasts, and file transfers, where the mobile node
   typically receives multiple orders of magnitude more data than it
   sends.


   One should evaluate whether the second mode of Credit-Based
   Authorization could be misused by an attacker that has an asymmetric
   connection to the Internet. Wide-spread digital subscriber lines
   (DSL) usually have a much higher download rate than upload rate. The
   limited upload rate would render most denial-of-service attempts
   through direct flooding meaningless. But the strong download rate
   could be misused to illegitimately build up credit at one or many
   correspondent nodes. The credit could then be used for a more potent,
   redirection-based flooding attack.


   It turns out that this issue is less serious than it may seem at
   first glance. The reason is that, in order to build up enough credit
   at the remote end, the attacker would initially have to expose itself
   to exactly the same packet flood that it could then redirect towards
   the victim. Note that this is true for both data volume and data
   rate: While data volume directly affects how much credit the
   correspondent node allocates, the data rate is indirectly taken into
   account through credit aging.


   The second CBA mode requires some sort of feedback for the
   correspondent node about how many packets that the correspondent node
   sends to a mobile node actually make it all the way to that mobile
   node. As mentioned in  Section 5.7, care-of-address spot checks
   provide this feedback. But they require more significant
   modifications to the Mobile IPv6 base specification than the first




Arkko & Vogt             Expires April 1, 2005                 [Page 39]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   mode of CBA does. Moreover, while the first mode operates completely
   transparent to the mobile node, the second obviously does not.


   CBA uses exponential aging to gradually reduce credit that has been
   earned in the past. This way, an attacker is prevented to collect
   credit over a long time interval and use this credit, all at once,
   for a short but potent data burst towards a victim. Care must be
   taken to set the aging factor to an appropriate value.


   Finally, one should mention that CBA-based concurrent care-of-address
   tests can be used to improve other mobility-management protocols that
   verify a new IP address through probing. This includes HIP and
   certain Mobike proposals. Also, CBA-based concurrent care-of-address
   tests can be integrated into other Mobile IPv6 optimization
   techniques described in this document. Approaches that may benefit
   are, for example, CGA-based ones (cf. Section 6.2.3) as well as those
   that use shared-secret preconfiguration (cf. Section 6.2.2). Last,
   but not least, in scenarios where a home agent cannot trust in the
   correctness of the registered mobile nodes' care-of addresses,
   CBA-based concurrent care-of-address tests could be proscribed even
   for home registrations. The same is true for Hierarchical Mobile
   IPv6, which, as it stands, assumes a MAP can be confident that mobile
   nodes use correct on-link care-of addresses, and so gets around the
   care-of-address test.


6.2.5  Prefix-Based Certificates


   The Mobile IPv6 base specification avoids strong authentication
   cryptography for signaling between mobile nodes and correspondent
   nodes. One reason for this is the impracticality of a global trusted
   PKI that could approve bindings between the mobile nodes' identities
   and public keys. Another reason is that limited power resources and
   processing capacity at the mobile nodes generally rule out any
   complex cryptographic operations. Robustness to resource-exhaustion
   attacks requires a similar restrictiveness on the correspondent-node
   side.


   [9] suggest promoting the home agent to a security proxy operating on
   behalf of its mobile nodes. Correspondent nodes can trust a home
   agent based on a certificate that binds the home-network prefix to
   the public key of the home agent. The home agent, in turn, vouches
   for the correctness of its mobile nodes' home addresses. This
   approach is called Certificate-based Binding Update (CBU).


   CBU circumvents the lack of a global PKI in an elegant way. Rather
   than having to issue a certificate per mobile node, only a
   certificate per home-network prefix is required. This reduction in
   complexity makes certificate-based approaches to mobile-node




Arkko & Vogt             Expires April 1, 2005                 [Page 40]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   authentication more feasible than it is today. The approach also
   avoids heavy computations at mobile nodes since all such computations
   are performed by the home agent. This mitigates the issue with
   resource limitations at mobile nodes.


   As a side effect, once the end-to-end security association between a
   mobile node and a correspondent node has been created, CBU allows for
   improved signaling delay during all subsequent handovers.


   On the other hand, it should be mentioned that the processing
   overhead at correspondent nodes actually increases compared to
   standard correspondent registrations. This may not be an issue since
   resources at stationary correspondent nodes are usually higher than
   those of many mobile devices, and home agents would do the
   cryptographic operations for mobile correspondent nodes.
   Correspondent nodes should hence be provided with sufficient
   resources, at least where the correspondent node is not a popular web
   server or other central resource. One should, however, bear in mind
   that the increased overhand implies a higher risk to
   resource-exhaustion attacks.


   The identity of a mobile node may in certain scenarios also be
   verifiable through an AAA infrastructure. A home AAA server, which
   may or may not be co-located with the home agent, can then contact a
   remote AAA server in the correspondent node's network. Note that this
   moves some of the authentication overhead from the correspondent node
   to the remote AAA server. An AAA-based approach can also dynamically
   assign mobile-node requests to different correspondent nodes while
   keeping secret authenticating material local at a single AAA server.


   There is ongoing work on the integration of AAA with Mobile IPv6
   [30]. The current focus is on authentication between mobile nodes and
   home agents. The proposal is thus a replacement for the IPsec-based
   authentication protocol for home registrations. But the concept of
   security proxies presented in [9] may as well be re-used for
   enhancements to the AAA infrastructure.


   CBU does not solve the issue with care-of-address spoofing: A
   vouching home agent does not prevent a malicious mobile node from
   faking its care-of address. The culprit could cheat its home agent,
   or it could cooperate with it. This said, CBU should be combined with
   a care-of-address test that rules out redirection-based flooding
   attacks. A combination of concurrent care-of-address tests and CBA
   (cf. Section 5.7) can be used to keep the signaling delay during
   handover as low as it currently is in [9].







Arkko & Vogt             Expires April 1, 2005                 [Page 41]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



6.3  Further Research


   Mobility-related optimizations are currently actively studied by many
   researchers, looking at a number of different protocol layers. The
   preceding section also identifies some worthwhile amendments to the
   existing proposals that require further work. While some of the basic
   methods for route optimization are fairly well understood and are
   being deployed, there are a number of interesting, newer approaches
   that deserve to be studied in more detail. This section discusses
   some research directions that appear fruitful, or necessary in the
   future, and that go beyond the existing proposals described so far.


6.3.1  Related Research in Other Protocol Layers


   The efficiency, security, and other functionality related to
   movements is not dependent only on Mobile IPv6 route optimization
   (even if researchers often pose their analysis in that light).  A
   movement that is visible at the IP layer involves all lower layers as
   well; this includes layer 2 attachment procedures, layer 2 security
   mechanism negotiation, authentication and key agreement, IP router
   and neighbor discovery, address autoconfiguration, duplicate address
   detection and so forth. A complete network attachment typically
   requires over twenty link and IP layer messages, assuming features
   necessary for a commercial deployment (such as security) are turned
   on.


   A significant research question is the overall performance of the
   network access stack as a whole. Current protocol stacks have a
   number of limitations in addition to the long attachment delays [1],
   such as denial-of-service vulnerabilities, difficulties in trusting a
   set of access nodes distributed to physically insecure locations,
   inability to get enough information for a handoff decision, and so
   on.


   A number attempts are ongoing to improve various parts of the stack,
   in particular focusing on performance of movements. These attempts
   include link-layer enhancements, parameter tuning [34], network
   access authentication mechanisms [14], fast handover mechanisms [20],
   [2], and IP layer attachment improvements (such as Optimistic DAD
   [21]).


   It is uncertain how far this optimization can be taken by only
   looking at the different parts individually. It is possible that a
   more integrated approach would be necessary to gain a more
   significant improvement [3].


   It is also unclear at this time which components are the most
   critical ones. Reference [1] suggests that IP mobility related




Arkko & Vogt             Expires April 1, 2005                 [Page 42]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   signaling contributes only under 10% of the overall delay in an IEEE
   802.11 environment. The most significant delays are caused by link
   layer and IPv6 attachment. However, the results are not conclusive,
   as there is a factor five difference between the best and worst
   cases. The results can also be affected by a number of conditions,
   such as the availability of specific link layer optimizations, or the
   type of security mechanism used in the Mobile IPv6 home
   registrations.


6.3.2  New Route Optimization Work


   The primary driver to improve route optimization appears to be better
   efficiency for a few usage scenarios, such as fast movements or the
   ability to reduce signaling frequencies for hosts in standby mode.
   Ongoing work addresses these aspects already quite well; most of the
   suggested methods are quite stable in this regard. It is expected
   that further (perhaps smaller) improvements continue to be achieved
   through research and parameter tuning far into the future. This is
   particularly true because the optimizations are often targeted to a
   specific usage situation, and may not give the same improvement in
   another situation. As a result, the publication of a few enhanced
   methods for different situations seems more reasonable than expecting
   to define a final, single method.


   The development of an infrastructure-based route optimization method
   is clearly a longer-term project. At this stage, it is not even clear
   that such a mechanism is needed. We believe the prefix-based
   certificate approach shows some promise in this area, particularly if
   it can be combined with the deployment of these certificates for some
   other purposes, such as Secure Neighbor Discovery [4]. The pre-shared
   method being standardized at the IETF is simple and efficient, but we
   do not expect it to be applicable in wide enough number of cases to
   make a significant difference in practice.


   In the following we list some potentially interesting research ideas
   for new route optimization methods:


   o  Local mobility or local repair optimizations that require no
      configuration.
   o  Care-of address verification mechanisms that employ lower layer
      assistance or Secure Neighbor Discovery.
   o  The introduction of optimizations developed in the context of
      Mobile IPv6 to HIP or other mobility protocols, or to layer 2
      mobility solutions.
   o  Extension of the developed techniques to full multiaddressing,
      i.e., including also multi-homing.
   o  Further development of techniques based on "asymmetric cost wars"
      [7], such as CBA.




Arkko & Vogt             Expires April 1, 2005                 [Page 43]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



6.3.3  Experimentation and Simulation


   As discussed earlier, even the contribution of different stack parts
   to overall movement delays is unclear. More measurements are needed,
   particularly ones that
   o  Measure a realistic network scenario, enabling all features that
      would likely be needed in commercial deployment. These features
      include link-layer access control, for instance. Similarly, it is
      necessary to include support for already specified optimizations.
   o  Measure or simulate the performance impacts of various suggested
      improvements to the different parts of the stack.
   o  Measure implementation differences between systems based on the
      same specifications. It would be valuable to know how much
      implementations differ with regards to, for instance, the use of
      the parallelism that RFC 3775 allows in the home and correspondent
      registrations, the return routability procedure, and transmission
      of packets before Binding Acknowledgements have arrived.
   o  Measure the effect of network conditions, such as packet loss, and
      their effect to existing and new route optimization mechanisms.
   o  Collect data about the behaviour of mobile nodes in different
      networks. Different route optimization mechanisms behave
      differently depending on what the frequency of movements is, or
      what payload traffic streams exist at the different stages of the
      mobile node's existence.
   o  Measure or simulate the performance of different route
      optimization schemes under different application scenarios, such
      as symmetric/asymmetric applications, only seldomly active mobile
      nodes, and so on.


7.  Security Considerations


   Security issues related to route optimization are an integral part of
   the problem and have been discussed in the body of the document.


8.  Conclusions


   Mobility related optimizations are currently actively studied by many
   researchers. Some of the basic Mobile IPv6 related methods, such as
   the return routability method, pre-shared secrets, CGAs are either
   already being applied in practical systems or will be soon. A growing
   number of new proposals are being studied that attempt to optimize
   these methods further, or make them better applicable to a particular
   situation.


   Many of the current proposals are mature enough to withstand close
   scrutiny. Their relative advantages are somewhat subjective, however.
   For instance, some may have a high cost in terms of configuration
   while others do not need configuration but are slower. It is expected




Arkko & Vogt             Expires April 1, 2005                 [Page 44]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   that more than one new method is needed for this reason. Deployment
   experience will also be needed, so publication of a few alternative
   methods as RFCs would be desirable.


   It is interesting to note, however, that historically most if not all
   current proposals had predecessors that were shown to be insecure.
   For instance, the initial return routabality and CGA methods were
   proposed before the need for flooding attack protection was
   understood, concurrent tests were first proposed with a limited form
   of flooding protection, and several proposals employing
   semi-permanent security associations have suffered from address
   stealing attacks. This shows the need to reserve sufficient amount of
   time for community analysis and review of new methods.


   Another interesting observation is that mature proposals combine a
   number of techniques and do not rely on a single approach. This is
   due to the nature of the problem, where several different types of
   vulnerabilities have to be avoided.


   But it is also necessary to avoid overly expensive or complex
   solutions. For instance, in evaluating the security needs for the
   route optimization problem, it is important to compare these needs to
   other vulnerabilities, such as denial-of-service, that already exist
   for on path attackers. These vulnerabilities should not be made
   worse, but it is not necessarily a requirement to use managed,
   expensive security either.


   A significant research question is the overall performance of the
   whole stack in a mobile setting. This includes but is not limited to
   IP mobility. Current network access protocol stacks have a number of
   limitations, such as long attachment and movement latencies [1] -- an
   attachment typically requires over twenty link and IP layer messages
   -- denial-of-service vulnerabilities, and so on.


   A number attempts are currently being made to improve various parts
   of the stack, in particular focusing on high-performance movements.
   These attempts include link-layer enhancements, parameter tuning
   [34], network access authentication mechanisms [14], fast handover
   mechanisms [20][2], and IP layer attachment improvements such as
   Optimistic DAD [21]. It is uncertain how far this optimization can be
   taken by only looking at the different parts individually. It is also
   unclear at this time which components are the most critical ones.


   Other significant research questions include the effect of various
   network conditions such as packet loss to the current methods and
   whether different application situations require different
   optimization methods.  Our current understanding about the different
   traffic patterns and their effects in mobility is limited, and




Arkko & Vogt             Expires April 1, 2005                 [Page 45]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   experiments, modelling, and simulations will be needed.



















































Arkko & Vogt             Expires April 1, 2005                 [Page 46]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



9  References


   [1]   Alimian, A. and B. Aboba, "Analysis of Roaming Techniques",
         IEEE Contribution 11-04-0377r1 2004.


   [2]   Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to
         RADIUS", draft-irtf-aaaarch-handoff-04 (work in progress),
         November 2003.


   [3]   Arkko, J., Eronen, P., Nikander, P. and V. Torvinen, "Secure
         and Efficient Network Access", Extended abstract to be
         presented in the DIMACS workshop, November 2004.


   [4]   Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
         "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06
         (work in progress), July 2004.


   [5]   Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
         Lifetime Extension",
         draft-arkko-mipv6-binding-lifetime-extension-00 (work in
         progress), May 2004.


   [6]   Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
         Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
         Agents", RFC 3776, June 2004.


   [7]   Arkko, J. and P. Nikander, "Weak Authentication:  How to
         Authenticate Unknown Principals without Trusted Parties",
         Proceedings of Security Protocols Workshop 2002, Cambridge, UK,
         April 16-19,  2002.


   [8]   Aura, T., "Cryptographically Generated Addresses (CGA)",
         draft-ietf-send-cga-06 (work in progress), April 2004.


   [9]   Bao, F., "Certificate-based Binding Update Protocol (CBU)",
         draft-qiu-mip6-certificated-binding-update-02 (work in
         progress), August 2004.


   [10]  Bradner, S., Mankin, A. and J. Schiller, "A Framework for
         Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in
         progress), June 2003.


   [11]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", BCP 38, RFC 2827, May 2000.


   [12]  Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)",
         draft-haddad-mipv6-omipv6-01 (work in progress), February 2004.




Arkko & Vogt             Expires April 1, 2005                 [Page 47]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   [13]  Haddad, W., Madour, L., Arkko, J. and F. Dupont, "Applying
         Cryptographically Generated Addresses to Optimize MIPv6
         (CGA-OMIPv6)", draft-haddad-mip6-cga-omipv6-02 (work in
         progress), June 2004.


   [14]  Institute of Electrical and Electronics Engineers, "Local and
         Metropolitan Area Networks: Port-Based Network Access Control",
         IEEE Standard 802.1X, September 2001.


   [15]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.


   [16]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
         (ESP)", RFC 2406, November 1998.


   [17]  Kent, S., "IP Encapsulating Security Payload (ESP)",
         draft-ietf-ipsec-esp-v3-08 (work in progress), March 2004.


   [18]  Koodli, R., "Fast Handovers for Mobile IPv6",
         draft-ietf-mipshop-fast-mipv6-02 (work in progress), July 2004.


   [19]  Loughney, J., "IPv6 Node Requirements",
         draft-ietf-ipv6-node-requirements-11 (work in progress), August
         2004.


   [20]  Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
         "Proactive Key Distribution to support fast and secure
         roaming", IEEE Contribution 11-03-084r1-I, January 2003.


   [21]  Moore, N., "Optimistic Duplicate Address Detection for IPv6",
         draft-ietf-ipv6-optimistic-dad-01 (work in progress), June
         2004.


   [22]  Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00
         (work in progress), June 2004.


   [23]  Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E.
         Nordmark, "Mobile IP version 6 Route Optimization Security
         Design Background", draft-ietf-mip6-ro-sec-01 (work in
         progress), July 2004.


   [24]  Paxson, V., "An Analysis of Using Reflectors for Distributed
         Denial-of-Service Attacks",  Computer Communication Review
         31(3)., July 2001.


   [25]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
         2002.





Arkko & Vogt             Expires April 1, 2005                 [Page 48]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



   [26]  Perkins, C., "Preconfigured Binding Management Keys for Mobile
         IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress), April
         2004.


   [27]  Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity
         Protocol", draft-moskowitz-hip-09 (work in progress), February
         2004.


   [28]  Nikander, P., "Denial-of-Service, Address Ownership, and Early
         Authentication in the IPv6 World", Proceedings of the Cambridge
         Security Protocols Workshop, April 2001.


   [29]  Patel, A., "Problem Statement for bootstrapping Mobile IPv6",
         draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004.


   [30]  Patel, A., Leung, K., Khalil, M., Akhtar, H. and K. Chowdhury,
         "Authentication Protocol for Mobile IPv6",
         draft-ietf-mip6-auth-protocol-00 (work in progress), July 2004.


   [31]  O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6",
         Computer Communications Review, April 2001.


   [32]  Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of
         Mobile IPv6 Binding Updates and Acknowledgments",
         draft-roe-mobileip-updateauth-02 (work in progress), March
         2002.


   [33]  Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
         "Hierarchical Mobile IPv6 mobility management (HMIPv6)",
         draft-ietf-mipshop-hmipv6-02 (work in progress), June 2004.


   [34]  Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b
         MAC Layer Handover Time", Laboratory for Communication
         Networks, KTH, Royal Institute of Technology, Stockholm,
         Sweden, TRITA-IMIT-LCN R 03:02, April 2003.


   [35]  Vogt, C., Arkko, J., Bless, R., Doll, M. and T. Kuefner,
         "Credit-Based Authorization for Mobile IPv6 Early Binding
         Updates", draft-vogt-mipv6-credit-based-authorization-00 (work
         in progress), May 2004.


   [36]  Vogt, C., Bless, R., Doll, M. and T. Kuefner, "Early Binding
         Updates for Mobile IPv6",
         draft-vogt-mip6-early-binding-updates-00 (work in progress),
         February 2004.







Arkko & Vogt             Expires April 1, 2005                 [Page 49]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



Authors' Addresses


   Jari Arkko
   Ericsson Research NomadicLab


   FI-02420 Jorvas
   Finland


   EMail: jari.arkko@ericsson.com



   Christian Vogt
   Institute of Telematics
   University of Karlsruhe
   P.O. Box 6980
   76128 Karlsruhe
   Germany


   EMail: chvogt@tm.uka.de
   URI:   http://www.tm.uka.de/~chvogt/




Appendix A.  Acknowledgements


   The authors wish to thank Gabriel Montenegro and Rajeev Koodli for
   their support, review, and suggestions related to this paper.

























Arkko & Vogt             Expires April 1, 2005                 [Page 50]


Internet-Draft    MIP6 Route Optimization Enhancements      October 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Copyright Statement


   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Arkko & Vogt             Expires April 1, 2005                 [Page 51]