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]