Network Working Group C. Vogt
Internet-Draft Univ. of Karlsruhe, Germany
Expires: August 18, 2005 February 14, 2005
Early Binding Updates for Mobile IPv6
draft-vogt-mobopts-early-binding-updates-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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 August 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Mobile IPv6 defines a return-routability procedure for secure use of
route optimization between unacquainted nodes. The handover latency
caused by the procedure can significantly impact delay-sensitive
applications, however. This document presents an optimization to
Mobile IPv6 that eliminates the latency. The optimization is
realized as an optional, and fully backward-compatible, extension to
Mobile IPv6.
Vogt Expires August 18, 2005 [Page 1]
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 New Terminology . . . . . . . . . . . . . . . . . . . . . 5
2.2 New Message Types . . . . . . . . . . . . . . . . . . . . 5
2.3 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Optimization Components . . . . . . . . . . . . . . . . . . 7
3.1 Optimistic Behavior . . . . . . . . . . . . . . . . . . . 7
3.2 Proactive Home Address Tests . . . . . . . . . . . . . . . 8
3.3 Tentative Correspondent Registrations . . . . . . . . . . 8
3.4 Concurrent Care-of Address Tests . . . . . . . . . . . . . 9
3.5 Proactive Registrations . . . . . . . . . . . . . . . . . 9
4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Handling Unverified Care-of Addresses . . . . . . . . . . . 14
5.1 Dropping Packets . . . . . . . . . . . . . . . . . . . . . 14
5.2 Buffering Packets . . . . . . . . . . . . . . . . . . . . 14
5.3 Diverted Routing . . . . . . . . . . . . . . . . . . . . . 15
5.4 Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 15
5.5 Trusted Communities . . . . . . . . . . . . . . . . . . . 15
5.6 Credit-Based Authorization . . . . . . . . . . . . . . . . 15
5.7 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 16
6. Performance Analysis . . . . . . . . . . . . . . . . . . . . 16
6.1 Basic Mobile IPv6 . . . . . . . . . . . . . . . . . . . . 17
6.2 Optimistic Behavior . . . . . . . . . . . . . . . . . . . 18
6.3 Early Binding Updates . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . 21
7.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 21
7.2 Reachability . . . . . . . . . . . . . . . . . . . . . . . 21
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1 Normative References . . . . . . . . . . . . . . . . . . 23
10.2 Informational References . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . 25
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . 26
Vogt Expires August 18, 2005 [Page 2]
Internet-Draft Early Binding Updates February 2005
1. Introduction
Mobility Support in IPv6 (RFC 3775 [1]), or Mobile IPv6, enables
mobile nodes to change their point of IP attachment without loosing
active communications connections. It uses two IP addresses per
mobile node in order to separate localization semantics from
identification semantics: A transient "care-of address" routes to
the mobile node"s current point of IP attachment. A static "home
address" serves as an identifier at stack layers above IP. The
mobile node configures a new care-of address when it detects that it
has moved to a different subnet. The home address remains stable
across movements.
Correspondent nodes can send packets for the mobile node to either
address. When they send them to the care-of address, the packets
reach the mobile node directly. When they send them to the home
address, they will be routed to the mobile node's "home network".
There, a non-mobile "home agent" intercepts the packets, encapsulates
them, and tunnels them to the care-of address. Vice versa, the
mobile node may send its packets from the care-of address directly to
the correspondent node, or it may tunnel them to the home agent to
have them sent from the home address. Relaying packets through the
home agent is called "bidirectional tunneling", sending them directly
"route optimization".
Route optimization has the appealing property that it saves a lot of
routing overhead compared to bidirectional tunneling. Experts deem
this more and more important, in particular in the IPv6 Internet, due
to the increasing number of mobile nodes. However, route
optimization bears a security challenge, since two communication
peers do not necessarily have to be acquainted. One may think, e.g.,
of a mobile user streaming a news video from CNN. It is non-trivial
to secure mobility-related signaling between these peers. [11] gives
a detailed account on the Mobile IPv6 security design. Relevant to
this document are the following two questions.
o When the correspondent node receives a command to redirect node
X's packets, how can it be sure that it is X itself, rather than a
malicious third node, who has send this command?
o Assuming that the correspondent node can somehow identify X as the
originator of a certain redirection request, how can it rely on X
actually being present at the IP address to which packets are to
be redirected?
The first question raises an authentication issue, the second points
to the lack of trust between the peers. There are a variety of
possibilities how one could have realized authentication in Mobile
IPv6. Amongst them are certificate technology [8], DNSSEC [7], or
Vogt Expires August 18, 2005 [Page 3]
Internet-Draft Early Binding Updates February 2005
crypto-based identifiers [14][10]. But a desire to be independent
from a global, trusted infrastructure as well as IPR restrictions
paved the way for a different strategy: return routability. Testing
"return routability" of a node X at an IP address A means to check
whether X can receive packets sent to A. Since Mobile IPv6 uses the
home address as an identifier and the care-of address as a locator,
checking return routability of the former can authenticate a mobile
node, and checking return routability of the latter can validate a
mobile node's presence at the new destination for redirected packets.
The advantages of the return-routability procedure are low processing
and state requirements as well as an infrastructural independence. A
vulnerability to on-path attackers is acceptable because the issue
with on-path attacks already applies to the non-mobile Internet and
is not mobility-specific (cf. [11]). A disadvantage of the
return-routability procedure is its high latency, though: Both a
home-address test and a care-of-address test are potentially executed
over very long distances, so interactive real-time applications can
be significantly impacted by their delay.
This document proposes an optional extension to Mobile IPv6, Early
Binding Updates, which eliminates the delays caused by the
return-routability procedure. The improvement is achieved by doing a
home-address test proactively before a handover, allowing a mobile
node to optimistically pursue its home and correspondent
registrations in parallel, tentatively registering a new care-of
address immediately after movement detection and IPv6 Address
Autoconfiguration (i.e., without doing the care-of-address test
first), and postponing the care-of-address test to a time where usual
communications have already been resumed through the new care-of
address. This reduces the critical handover latency from two
round-trip times to one. Early Binding Updates also allow the mobile
node to proactively register a new care-of address with its home
agent and correspondent node before moving to that care-of address.
This requires an external mechanism to notify the mobile node, at its
old point of IP attachment, about an imminent handover and a valid
new care-of address [12]. Proactive registrations can eliminate
Mobile IPv6 handover signaling entirely.
Early Binding Updates for Mobile IPv6 were first presented at the
59th IETF meeting in Seoul, Republic of Korea, in February 2004.
2. Definitions
This document uses the terminology and message types specified in RFC
3775. It additionaly introduces a small set of new terminology and
Vogt Expires August 18, 2005 [Page 4]
Internet-Draft Early Binding Updates February 2005
defines two new message types. Some abbreviations are used for the
sake of brevity and preciseness throughout the document. This
section summarizes any terminology, message types, and acronyms not
already mentioned in RFC 3775.
2.1 New Terminology
Proactive Home Address Test
A home-address test initiated by a mobile node before handover,
the intention being to have a valid Home Keygen Token already
available during the critical handover period (cf. Section 3).
Tentative Correspondent Registration
A correspondent registration with limited lifetime that a mobile
node conducts before it initiates a standard correspondent
registration. A tentative correspondent registration does not
provide evidence to a correspondent node that the mobile node is
indeed reachable at the registered care-of address (cf.
Section 3).
Unverified Care-of Address
A care-of address registered by means of a tentative correspondent
registration. A mobile node's reachability at an unverified
care-of address is not known to a correspondent node, because no
care-of-address test has (yet) been done.
Verified Care-of Address
A care-of address registered by means of a standard correspondent
registration. A mobile node's reachability at a verified care-of
address has been determined through a care-of-address test.
Concurrent Care-of Address Test
A care-of-address test for an unverified care-of address executed
subsequent to a tentative correspondent registration. The
unverified care-of address is already in use during the concurrent
care-of-address test (cf. Section 3).
Proactive Registration
A method by which a mobile node may register a new care-of address
before moving to that care-of address (cf. Section 3).
2.2 New Message Types
Vogt Expires August 18, 2005 [Page 5]
Internet-Draft Early Binding Updates February 2005
Early Binding Update
A mobile node sends an Early Binding Update message to a
correspondent node for tentative correspondent registration.
Early Binding Acknowledgement
A correspondent node may return an Early Binding Acknowledgement
message to a mobile node in response to an Early Binding Update
message.
2.3 Acronyms
HoTI
The Home Test Init message that a mobile node sends to a
correspondent node during the home-address test.
HoT
The Home Test message that a correspondent node returns to a
mobile node during the home-address test.
CoTI
The Care-of Test Init message that a mobile node sends to a
correspondent node during the care-of-address test.
CoT
The Care-of Test message that a correspondent node returns to a
mobile node during the care-of-address test.
BU[HA]
The Binding Update message that a mobile node sends to its home
agent during home registration.
BA[HA]
The Binding Acknowledgement message that a home agent returns to a
mobile node during home registration.
BU[CN]
The Binding Update message that a mobile node sends to a
correspondent node during correspondent registration.
BA[CN]
The Binding Acknowledgement message that a correspondent node
returns to a mobile node during correspondent registration.
EBU
Vogt Expires August 18, 2005 [Page 6]
Internet-Draft Early Binding Updates February 2005
The Early Binding Update message that a mobile node sends to a
correspondent node during tentative correspondent registration.
EBA
The Early Binding Acknowledgement message that a correspondent
node may return to a mobile node during tentative correspondent
registration.
RTT[MN,HA]
One round-trip time between a mobile node and its home agent.
RTT[MN,CN]
One round-trip time between a mobile node and a correspondent
node, measured on the direct path between the peers.
RTT[MN,HA,CN]
One round-trip time between a mobile node and a correspondent node
for messages bidirectionally routed through the mobile node's home
agent.
3. Optimization Components
Early Binding Updates for Mobile IPv6 have four basic optimization
components: optimistic behavior, proactive home-address tests,
tentative correspondent registrations, and concurrent care-of-address
test. Optionally, proactive registrations may be used in addition.
This section introduces the optimization components.
3.1 Optimistic Behavior
RFC 3775 allows a mobile node to pursue a return-routability
procedure in parallel with the corresponding home registration. This
behavior is "optimistic" in the sense that the return-routability
procedure would have been accomplished in vain should the home
registration fail or be rejected. Conservative Mobile IPv6
implementations for mobile nodes execute the home registration and
the return-routability procedure in sequence. E.g., the current
version of Kame Shisa [16] activates its return-routability state
machine upon reception of a BA{HA}.
Optimistic behavior may be applied without Early Binding Updates, but
not vice versa. Early Binding Updates go one step further in that
they allow the mobile node to not only conduct the return-routability
procedure, but also a tentative correspondent registration (see
below) simultaneously with the home registration.
Vogt Expires August 18, 2005 [Page 7]
3.2 Proactive Home Address Tests
RFC 3775 defines a lifetime of 3.5 minutes for Home and Care-of
Keygen Tokens. This feature allows a mobile node to authenticate
itself during a handover based on a Home Keygen Token that it has
already acquired before the handover. Such a proactive home-address
test saves a possibly long round-trip time through the home agent
during the critical handover period.
There are essentially two ways to implement proactive home-address
tests. If the mobile node's local link layer provides a trigger that
tells the mobile node about an imminent handover, the mobile node can
invoke proactive home-address tests on a just-in-time basis.
Alternatively, the mobile node may repeat the proactive home-address
test whenever the most recently obtained Home Keygen Token is about
to expire. Either way, the mobile node has a valid token at hand
when a handover occurs.
A mobile node should also do proactive home-address tests while it
stays at home. This allows the mobile node to apply Early Binding
Updates when leaving the home network. The Binding Update List
contains information about the state of a home-address test, so the
mobile node may keep existing and create new entries in the Binding
Update List when at home, just as it does when not at home. Such
entries would have the current care-of address set to the mobile
node's home address.
Implementations must not confuse Binding Update List entries for
which a correspondent (de-)registration is pending or still to be
initiated from those for which (de-)registration is already complete.
In particular should the mobile node not automatically initiate
(de-)registration when receiving the HoT from a proactive
home-address test.
3.3 Tentative Correspondent Registrations
According to RFC 3775, a mobile node may initiate the
return-routability procedure for a planned correspondent registration
while it is waiting for a BA[HA] acknowledging successful home
registration. However, the mobile node must receive this BA[HA]
before it can register with the correspondent node. Early Binding
Updates allow the mobile node to also pursue a tentative
correspondent registration while waiting for the BA[HA]. A tentative
correspondent registration has a lifetime just long enough to bridge
the expected duration of the remaining registration procedure. It is
authenticated with the Home Keygen Token from the most recent
proactive home-address test, but lacks proof of a successful
care-of-address test. The mobile node replaces a tentative
Vogt Expires August 18, 2005 [Page 8]
Internet-Draft Early Binding Updates February 2005
correspondent registration with a standard one later during the
message exchange. A tentatively registered care-of address is called
"unverified", and a care-of address registered the standard way is
called "verified".
The correspondent node stops sending further packets to an old
care-of address once the mobile node has tentatively registered a
new, unverified care-of address. It accepts route-optimized packets
that the mobile node sends from the unverified care-of address from
that time on. However, whether or not the correspondent node sends
data packets to the unverified care-of address depends on its local
policies. Section 5 discusses a range of possible policies that the
correspondent node may apply in different scenarios.
3.4 Concurrent Care-of Address Tests
RFC 3775 requires a mobile node to support a correspondent
registration with proof of its reachability at the new care-of
address. Early Binding Updates allow the mobile node to tentatively
register an unverified care-of address without such evidence, and to
make up for the care-of-address test after data communications have
been resumed. The mobile node affects a standard correspondent
registration subsequent to this concurrent care-of-address test,
making the unverified care-of address a verified one.
3.5 Proactive Registrations
It is conceivable that external mechanisms assist a mobile node
before handover in learning a valid care-of address for the new link
[12]. This allows the mobile node to register the new care-of
address with its home agent and, tentatively, with its correspondent
node while it is still connected to the old link. The mobile node
initiates a concurrent care-of-address test as soon as it arrives at
the new link. It then proceeds with a standard correspondent
registration. Proactive home and correspondent registrations are an
optional feature of Early Binding Updates.
4. Protocol
This section describes the Mobile IPv6 registration procedure when
optimized with Early Binding Updates. Note that a mobile node may
wish to do route optimization with more than one correspondent node
at a time. In this case, the mobile node needs to run a separate
correspondent registration with each of them. For the sake of
Vogt Expires August 18, 2005 [Page 9]
Internet-Draft Early Binding Updates February 2005
simplicity, it is assumed henceforth that there is only a single
correspondent node. Figure 1 illustrates the optimized protocol.
Mobile Node Home Agent Correspondent Node
| | |
|=HoTI=========>|-HoTI--------->|
| | |
|<==========HoT=|<----------HoT-|
| | |
Handover ~ | |
|-BU[HA]------->| |
Use new CoA |-EBU-------------------------->| Use unverified CoA
|-CoTI------------------------->|
| | |
|<-------BA[HA]-| |
|<--------------------------EBA-|
|<--------------------------CoT-|
| | |
|-BU[CN]----------------------->| Use verified CoA
| | |
|<-----------------------BA[CN]-|
| | |
Figure 1: Registration Procedure with Early Binding Updates
The mobile node seeks to have a fresh Home Keygen Token acquired
prior to any handover. It does so by initiating the home-address
test in a proactive way. The test may run periodically whenever the
current Home Keygen Token is about to expire. According to RFC 3775,
tokens are valid for 3.5 minutes (MAX_TOKEN_LIFETIME [1]), so the
interval between successive proactive home-address tests should be a
little bit less (HOME_ADDR_TEST_INTERVAL, cf. Section 9).
Alternatively, the mobile node's local link layer may provide a
trigger indicating when a handover is about to happen. The mobile
node may do the proactive home-address test right in time in this
case.
When the mobile node detects that it has moved to a different
network, it configures a new care-of address. The mobile node then
sends three messages back to back: a BU[HA] to its home agent, and
an EBU and a CoTI to the correspondent node. The BU[HA] initiates
the home registration, which uses the same messages and proceeds in
exactly the same way as specified in RFC 3775. The EBU is a request
for a tentative registration at the correspondent node. It has the
same syntax as a standard BU[CN], but its authenticator is calculated
Vogt Expires August 18, 2005 [Page 10]
Internet-Draft Early Binding Updates February 2005
only with the Home Keygen Token obtained during the most recent
home-address test. An EBU is similar to the BU[CN] used during
deregistration when the mobile node returns to its home network. It
is a newmessage introduced by Early Binding Updates. The CoTI
initiates the concurrent care-of-address test. A concurrent
care-of-address test uses the same messages and follows the same
procedure as specified in RFC 3775, except that data packets may
already be exchanged through the new care-of address while the test
is in progress.
The home agent processes a received BU[HA] according to RFC 3775,
binds the mobile node's home address to the new care-of address, and
sends a BA[HA] back to the mobile node.
When the correspondent node receives the EBU, it tentatively binds
the mobile node's home address to the new care-of address. It labels
the new care-of address "unverified", because the EBU does not show
whether the mobile node is indeed reachable at this address. If the
A flag is set in the EBU, the correspondent node sends an EBA back to
the mobile node. The EBA is syntactically the same as a standard
BA{CN}.
The correspondent node may send route-optimized data packets to the
unverified care-of address from this time on. Whether or not it does
so depends on its local policies. Section 5 discusses various
policies that the correspondent node may apply. In any case, the
correspondent node should not send any further packets to an older
care-of address of the mobile node.
Vogt Expires August 18, 2005 [Page 11]
Internet-Draft Early Binding Updates February 2005
Mobile Node Home Agent Correspondent Node
| | |
L2-triggered | | |
notification |-BU[HA]------->| |
|=HoTI=========>|-HoTI--------->|
| | |
|<-------BA[HA]-| |
|<==========HoT=|<----------HoT-|
| | |
|-EBU-------------------------->| Use unverified CoA
| | |
L3-triggered |<--------------------------EBA-|
handover ~ | |
Use new CoA |-CoTI------------------------->|
| | |
|<--------------------------CoT-|
| | |
|-BU[CN]----------------------->| Use verified CoA
| | |
|<-----------------------BA[CN]-|
| | |
Figure 2: Registration Procedure with Early Binding Updates and
Proactive Registrations
The local access network may assist the mobile node in doing
proactive home and correspondent registrations. The registration
procedure is a bit different then, as shown in Figure 2. Proactive
registrations require that the mobile node is given a valid care-of
address for the new link (to which it wants to move) while it is
still connected to the old link. The mobile node can so send a
BU[HA], conduct a proactive home-address test, and send an EBU from
the old link. The BU[HA] and EBU have an attached Alternate Care-of
Address option carrying the new care-of address. Note that this
address differs from the source addresses in the messages' IP
headers. Moreover, both messages should have the A flag set. The
mobile node initiates handover to the new link when it receives the
returning EBA. It sends a CoTI as soon as it arrives at the new link
and proceeds as it would do if proactive registrations did not apply.
The correspondent node processes an incoming CoTI, and returns a
Care-of Test message (CoT), in the way described in RFC 3775.
RFC 3775 requires that the requested lifetime for a correspondent
registration must be less than or equal to the remaining lifetime of
the current home registration. The mobile node provides the former
Vogt Expires August 18, 2005 [Page 12]
Internet-Draft Early Binding Updates February 2005
in the EBU and BU[CN]; the home agent defines the latter in the
BA[HA]. As a consequence, the mobile node does not know the
home-registration lifetime at the time it sends the EBU. The
requested lifetime for a tentative correspondent registration should
therefore be very short. Specifically, it must not be greater than
TENTATIVE_RR_BINDING_LIFETIME (see Section 9).
The EBA is a confirmation that the correspondent node has tentatively
registered the mobile node's new care-of address. The correspondent
node sends an EBA only if the A flag in the EBU is set. The mobile
node should retransmit the EBU only when both an expected EBA and the
CoT fail to be delivered. Any retransmission of an EBU message must
be synchronized with a retransmission of the CoTI, and such
retransmissions must be subject to the rate limitations for CoTI's
defined in RFC 3775.
The mobile node handles an incoming CoT in the way defined in RFC
3775. Specifically, the mobile node sends the correspondent node a
BU[CN], the authenticator of which is calculated with the Care-of
Keygen Token from the received CoT and the Home Keygen Token from the
most recently received HoT.
When the correspondent node receives the BU[CN], it sets the lifetime
of the binding between the mobile node's home and care-of addresses
as specified in RFC 3775. This extends the lifetime from its
tentative value. The correspondent node also changes the state of
the care-of address from "unverified" to "verified". If the A flag
in the received BU[CN] is set, the correspondent node sends a BA[CN]
back to the mobile node. This concludes the correspondent
registration from the correspondent node's perspective.
A received BA[CN] concludes the correspondent registration from the
mobile node's perspective. If an expected BA[CN] fails to be
delivered, the mobile node resends the BU[CN] subject to the
retransmission limitations specified in RFC 3775. The mobile node
should not resend an EBU due to the missing BA, however.
Handover efficiency is highest when the correspondent node sends
packets to an unverified care-of address directly, but the
correspondent node may choose to send them to the home address until
it receives a BU[CN] from the mobile node (cf. Section 5). The
mobile node must expect to receive the correspondent node's packets
encapsulated by its home agent from the time it receives the EBA (or
from the time it sends the EBU in case it does not set the A flag in
this message) up to when it receives the correspondent node's BA[CN]
(or shortly after it has sent the BU[CN] in case it does not set the
A flag in this message). Reception of an EBA is not required, but
can reconfirm this expectation. The mobile node should not consider
Vogt Expires August 18, 2005 [Page 13]
Internet-Draft Early Binding Updates February 2005
the encapsulated packets as an indication of a failed correspondent
registration. Moreover, the mobile node may route-optimize its
packets for the correspondent node rather than reverse-tunneling them
through the home agent. The correspondent node accepts these packets
due to the tentative binding between the home address and the
unverified care-of address.
5. Handling Unverified Care-of Addresses
A care-of-address test serves to determine whether a mobile node can
really receive packets at the care-of address where it claims to be
reachable. This reachability check misses from a tentative
correspondent registration. There is hence a possibility that a node
illegitimately redirects packets to a third party, even though the
lifetime for tentative correspondent registrations is limited to
TENTATIVE_RR_BINDING_LIFETIME (cf. Section 9). The severity of such
"redirection-based flooding attacks" over conventional flooding
attacks not so much emanates from packet redirection per se, but
rather from the enormous potential for flooding amplification: Not
the attacker itself, but the correspondent node ends up flooding the
victim--unknowingly, of course.
A correspondent node may apply different policies for choosing the
destination address of data packets that it has to send while the
recipient's current care-of address is unverified. This section
compiles several such policies. Whether or not a particular one is
feasible in a given scenarios mainly depends on the level of trust
between the correspondent node and the mobile node. In any case must
the correspondent node stop sending further packets to an old care-of
address of the mobile node, and it must accept packets that the
mobile node sends to it from the unverified care-of address.
5.1 Dropping Packets
Local policies may prohibit the correspondent node to send data
packets to an unverified care-of address. The correspondent node may
simply drop such packets. It may rely on protocols at stack layers
above IP to retransmit the lost packets when the care-of address
becomes verified.
5.2 Buffering Packets
The correspondent node may buffer packets for a mobile node whoose
care-of address is unverified. It can send these packets as soon as
Vogt Expires August 18, 2005 [Page 14]
Internet-Draft Early Binding Updates February 2005
the care-of address gets verified.
5.3 Diverted Routing
The correspondent node may choose to send packets for a mobile node
to the home address while the care-of address is unverified. The
mobile node must expect to receive such packets encapsulated by its
home agent during handover. The mobile node may still send
route-optimized packets for the correspondent node directly instead
of reverse-tunneling them through the home agent. It may
reverse-tunnel the packets, however, if latency differences between
packets routed through the home agent and those sent directly would
otherwise cause disruption to the application.
5.4 Heuristics
The lifetime for tentative correspondent registrations is limited to
TENTATIVE_RR_BINDING_LIFETIME (cf. Section 9). If supplemented with
a heuristic for misuse detection, this restriction can be a
sufficient discouragement of malicious packet redirection. Mobile
nodes have to authenticate their home addresses during a tentative
correspondent registration, so an attacker can always be identified
by means of its home address. However, some damage from protocol
misuse may still occur, even if the heuristic is very responsive.
Reactive punishment of a perpetrator may also have little impact when
the administrative relationship between the perpetrator and the
correspondent node is loose or non-existant.
5.5 Trusted Communities
The correspondent node may use the home address as a criterion for
deciding whether a particular mobile node belongs to a trusted
community. If it can rely on the mobile node's trustworthiness, it
can send packets to an unverified care-of address of this mobile
node. If the mobile node is unknown, the correspondent node ought to
be more cautious while the care-of address is unverified. It may
then drop or buffer the packets, or send them to the mobile node's
home address. As an example, this strategy could be used by a
corporate server which trusts mobile nodes only if they are
affiliated to its own company.
5.6 Credit-Based Authorization
As previously mentioned, redirection-based flooding attacks are a
Vogt Expires August 18, 2005 [Page 15]
Internet-Draft Early Binding Updates February 2005
particular threat due to their potential for high amplification.
Malicious redirection would lose its attraction to simpler direct
flooding attacks if theamplification was by some means inhibited.
Such is the approach followed by Credit-Based Authorization for
concurrent care-of-address tests [13]. Here, the correspondent node
monitors a mobile node's effort for transmission or reception of data
packets. It gives credit to the mobile node proportionally to this
effort. Packets that the correspondent node sends to an unverified
care-of address of the mobile node reduce the credit. The
correspondent node discontinues sending further route-optimized
packets when no credit is left. It usually sends the packets to the
mobile node's home address instead, but it may apply one of the other
strategies discussed in this section.
It is worthwhile to mention that Credit-Based Authorization
facilitates secure use of Alternate Care-of Address options in
conjunction with concurrent care-of-address tests. This allows a
mobile node to proactively register a new care-of address with its
correspondent node before a handover, provided that it can anticipate
the handover and foresee a valid new care-of address through some
external mechanism.
5.7 Ingress Filtering
The correspondent node may be aware that ingress filtering [4] is
active on a certain set of IP addresses. E.g., these IP addresses
could be allocated to a trusted operator's network. The
correspondent node can then send packets to any unverified care-of
address from this set without risk and apply a different strategy for
other unverified care-of addresses. However, a shortfall of ingress
filtering is that it only checks a packet's source address. It hence
fails when a to-be-registered care-of address different than the
registration message's source address appears in an Alternate Care-of
Address option. Proactive correspondent registrations through
Alternate Care-of Address options and concurrent care-of-address
tests are hence not compatible with ingress filtering (cf.
Section 5.6).
6. Performance Analysis
This section evaluates the signaling delays of basic Mobile IPv6
without optimistic behavior, Mobile IPv6 with optimistic behavior,
and Mobile IPv6 with Early Binding Updates. There is explicit
mentioning of optimistic behavior because many Mobile IPv6
implementations for mobile nodes do not use this optimization
Vogt Expires August 18, 2005 [Page 16]
Internet-Draft Early Binding Updates February 2005
opportunity yet. Signaling delays are measured from the mobile
node's perspective, in terms of not being allowed to send and being
unable to receive. This document does not yet analyze the efficiency
of proactive registrations, but future versions will.
Section 5 discusses a number of strategies for handling unverified
care-of addresses. Some of them have implications on handover
performance. In this section, it is assumed that the correspondent
node sends route-optimized packets directly to the mobile node's new,
unverified care-of address as soon as it receives an EBU.
Note that the overall handover performance does not depend on Mobile
IPv6 signaling alone, but also on signaling at other layers of the
protocol stack. This includes link-layer authentication [3] and
attachment procedures [2], movement detection, IPv6 Neighbor
Discovery [5], as well as Address Autoconfiguration and Duplicate
Address Detection [6]. This document does not consider these
additional delays, however, as this would go beyond its scope. On
the other hand, delays at other stack layers are independent of
whether basic Mobile IPv6, optimistic behavior, or Early Binding
Updates are used. This makes it feasible to focus on Mobile IPv6
signaling.
6.1 Basic Mobile IPv6
This section evalates the signaling delay of basic Mobile IPv6 when
optimistic behavior is not applied. I.e., the return-routability
procedure does not begin until the mobile node has received a BA[HA]
acknowledging successful home registration.
RFC 3775 defines that a mobile node must do the following steps
before it can use the new care-of address: First, the mobile node
must register the new care-of address with its home agent. Second,
it must execute the return-routability procedure. Third, the mobile
node must register the new care-of address with its correspondent
node.
A home registration is an exchange of a BU[HA] and a BA[HA] between
the mobile node and its home agent. Let RTT[MN,HA] be the round-trip
time required for these messages. The home-address test is an
exchange of a HoTI and a HoT between the mobile node and the
correspondent node. Both of these messages are routed through the
home agent. Let their required round-trip time be RTT[MN,HA,CN].
The care-of-address test is an exchange of a CoTI and a CoT between
the mobile node and the correspondent node. These messages are
transmitted directly between the peers, i.e., they do not
(necessarily) pass the home agent. Let the round-trip time that
Vogt Expires August 18, 2005 [Page 17]
Internet-Draft Early Binding Updates February 2005
these messages need be RTT[MN,CN]. The mobile node must wait for
all, the BA[HA], the HoT, and the CoT, before it can register its
care-of address with the correspondent node. The correspondent
registration, in turn, is an exchange of a BU[CN] and an optional
BA[CN]. However, the mobile node does not need to wait for the
BA[CN]. It may resume sending route-optimized packets to the
correspondent node as soon as it has dispatched the BU[CN]. The
signaling delay observed by the mobile node in terms of packet
transmission thus amounts to
LATENCY[SEND] = RTT[MN,HA] + Max (RTT[MN,HA,CN], RTT[MN,CN])
Given that the end-to-end path through the home agent is typically
longest, LATENCY[SEND] = RTT[MN,HA] + RTT[MN,HA,CN] holds in most
cases.
The correspondent node starts using the mobile node's new care-of
address once it receives the BU[CN]. It then takes another 0.5
RTT[MN,CN] time until the first data packet arrives at this address.
This is independent of whether or not a BA[CN] is transmitted. Thus,
the mobile node's observed signaling delay for receiving packets can
be calculated as
LATENCY[RECEIVE] = RTT[MN,HA] + Max (RTT[MN,HA,CN], RTT[MN,CN]) +
RTT[MN,CN]
which should usually reduce to LATENCY[RECEIVE] = RTT[MN,HA] +
RTT[MN,HA,CN] + RTT[MN,CN].
If the mobile node has already recently changed its point of network
attachment, it may reuse its previously acquired Home Keygen Token
without running another home-address test. In this situation,
RTT[MN,HA,CN] reduces to zero, so LATENCY[SEND] = RTT[MN,HA] +
RTT[MN,CN] and LATENCY[RECEIVE] = RTT[MN,HA] + 2*RTT[MN,CN].
6.2 Optimistic Behavior
Many Mobile IPv6 implementations for mobile nodes execute a home
registration and the return-routability procedure in sequence. E.g.,
the current version of Kame Shisa [16] activates its
return-routability state machine upon reception of a BA[HA].
However, RFC 3775 leaves sufficient room for pursuing the
return-routability procedure already in parallel with the home
registration. This section explicitly considers the performance
benefit of this optimistic behavior.
As mentioned previously, the latencies for a home registration, a
Vogt Expires August 18, 2005 [Page 18]
Internet-Draft Early Binding Updates February 2005
home-address test, and a care-of-address test are RTT[MN,HA],
RTT[MN,HA,CN], and RTT[MN,CN], respectively. RFC 3775 defines that
the mobile node must wait for all, the BA[HA], the HoT, and the CoT,
before it can send the BU[CN]. As the mobile node may start sending
route-optimized packets to the correspondent node right after it has
dispatched the BU[CN], its observed handover latency for sending
packets amounts to
LATENCY[SEND,OPTIMISTIC] = Max (RTT[MN,HA], RTT[MN,HA,CN],
RTT[MN,CN])
Given that the end-to-end path through the home agent is typically
longest, LATENCY[SEND,OPTIMISTIC] = RTT[MN,HA,CN] holds in most
cases.
Adding another RTT[MN,CN] propagation delay for the BU[CN] and the
first data packet sent to the new care-of address yields the observed
handover latency for receiving packets:
LATENCY[RECEIVE,OPTIMISTIC] = Max (RTT[MN,HA], RTT[MN,HA,CN],
RTT[MN,CN]) + RTT[MN,CN]
which should be LATENCY[RECEIVE,OPTIMISTIC] = RTT[MN,HA,CN] +
RTT[MN,CN] in most scenarios.
If the mobile node is able to reuse a previously acquired Home Keygen
Token due to a handover that occurred just recently, RTT[MN,HA,CN]
becomes zero, and LATENCY[SEND,OPTIMISTIC] = Max (RTT[MN,HA],
RTT[MN,CN]) and LATENCY[RECEIVE,OPTIMISTIC] = Max (RTT[MN,HA],
RTT[MN,CN]) + RTT[MN,CN].
6.3 Early Binding Updates
This section compares the signaling delay of Mobile IPv6 optimized
with Early Binding Updates to Mobile IPv6 with optimistic behavior
alone.
A proactive home-address test does not affect the Mobile IPv6
signaling delay because it happens while communications are actively
ongoing at the mobile node's old IP attachment. A concurrent
care-of-address test does not add to the signaling delay either, but
the reason for this, explained next, is a bit more complicated. It
is clear that the mobile node can send throughout the entire test.
The correspondent node, however, becomes aware of the new care-of
address only when it receives the EBU, and the EBU is transmitted
during the concurrent care-of-address test. So, actually, the
correspondent node sends to the new care-of address for only half of
Vogt Expires August 18, 2005 [Page 19]
Internet-Draft Early Binding Updates February 2005
the test. On the other hand, the EBU's propagation latency equals
that of a BU[CN]'s. The one-way-time loss of the correspondent
node's packets during the first half concurrent care-of-address test
is therefore compensated in that the correspondent node can already
send to the new care-of address during the one-way-time propagation
of the BU[CN], which is not the case in standard Mobile IPv6. As a
consequence, the concurrent care-of-address test can be perceived as
having no effect on the Mobile IPv6 signaling delay.
The mobile node sends the BU[HA], the EBU, and the CoTI back to back,
and it may send route-optimized packets as of then. Outgoing packets
can thus be transmitted virtually immediately, and
LATENCY[SEND,EARLY] = 0
A tentative correspondent registration consists of an EBU and an
optional EBA exchanged between the mobile node and the correspondent
node. The correspondent node learns the new care-of address through
the EBU, and it may start sending route-optimized packets to the
mobile node right then. The first such packet arrives at the mobile
node 0.5 RTT[MN,CN] time later. This is independent of whether or
not an EBA is transmitted. Thus, the mobile node's observed
signaling delay for receiving packets can be calculated as
LATENCY[RECEIVE,EARLY] = RTT[MN,CN]
This evaluation shows that Early Binding Updates, when compared to
Mobile IPv6 with optimistic behavior, typically reduces the signaling
latency by RTT[MN,HA,CN]. Compared to basic, non-optimistic Mobile
IPv6, the signaling latency decreases by even RTT[MN,HA] +
RTT[MN,HA,CN]: one round-trip time for the home registration and
another for the return-routability procedure. The improvements are
RTT[MN,CN] and RTT[MN,HA] + RTT[MN,CN], respectively, in case the
mobile node has a fresh-enough Home Keygen Token from a recent
home-address test which it can reuse.
There may be situations in which the mobile node does not know a
valid Home Keygen Token during a handover. For instance, the mobile
node may not support proactive home-address tests while attached to
its home link, so it cannot leverage Early Binding Updates when it
leaves home. The mobile node may also be temporarily down or
disconnected, hence unable to execute proactive home-address tests
for a while. In cases like this, the mobile node must perform a
standard binding update, and there is no efficiency improvement.
Vogt Expires August 18, 2005 [Page 20]
Internet-Draft Early Binding Updates February 2005
7. Security Considerations
Early Binding Updates differ from standard Mobile IPv6 in the way a
mobile node authenticates itself to a correspondent node, and when it
provides evidence of its reachability. This section elaborates on
security implications that might originate from these differences.
7.1 Authentication
According to RFC 3775, a mobile node must have acquired valid Home
and Care-of Keygen Tokens before it can initiate a correspondent
registration. This requires the mobile node to execute both the
home-address test and the care-of-address test before it can notify
its correspondent node about a new care-of address. In contrast, the
home-address test alone is sufficient to tentatively register an
unverified care-of address when Early Binding Updates are used. The
unverified care-of address becomes verified once the mobile node has
provided proof to the correspondent node that it is indeed reachable
at this address.
The question is whether lack of a care-of-address test renders
authentication through EBU's less secure than authentication through
BU{CN}'s. At first glance, it may seem so: A BU{CN}'s authenticator
depends on two tokens transmitted via separate paths, so whoever
generates it must be on the intersection of both paths. Even if the
paths happen to coincide are they independent in a sense, because
only one of them is IPsec-protected between the mobile node and the
home agent. The point, however, is that only the Home Keygen Token
is bound to the mobile node's home address (which is the mobile
node's identifier in the context of Mobile IPv6). The Care-of Keygen
Token can be bound to any address. In particular may the attacker
choose an address through which it is itself reachable. The attacker
can consequently acquire both tokens once it is in a position to
intercept a HoT sent to the mobile node's home address. Due to the
IPsec tunnel between the mobile node and the home agent, this
position can only be somewhere on the path between the correspondent
node and the home agent. In summary, the Care-of Keygen Token does
not affect a BU{CN}'s authentication capability. An EBU is therefore
as secure as a BU{CN} with respect to authentication. It is
worthwhile emphasizing that the EBU is authenticated in just the same
way as a standard BU{CN} for deregistration.
7.2 Reachability
Early Binding Updates allow a mobile node to register a new care-of
address without yet having shown that it is reachable at that
Vogt Expires August 18, 2005 [Page 21]
Internet-Draft Early Binding Updates February 2005
address. A malicious node could potentially misuse this feature for
a redirection-based flooding attack against a third party.
Ingress filtering [4] is usually considered a possible solution to
this problem. If deployed close to the mobile node's IP attachment,
ingress filtering can provide reasonable insurance that an unverified
care-of address is correct. The technique has two disadvantages,
however. One is that it can provide full protection against address
spoofing only if it is deployed universally. As long as some
operators do not use it, redirection attacks can originate from their
networks. Another disadvantage is that ingress filtering checks only
a packet's IP source address. As a consequence, ingress filtering
fails when an EBU or BU{CN} has an Alternate Care-of Address option
with a care-of address different than the message's source address.
This makes ingress filtering incompatible with proactive
correspondent registrations.
Local policies at the correspondent node must hence be restrictive
enough to rule out misuse of unverified care-of addresses. Section 5
discusses a number of strategies that the correspondent node may
follow. It depends on the particular deployment scenario which of
these strategies applies best.
8. Conclusion
Mobile IPv6 uses the return-routability procedure for secure route
optimization between unacquainted nodes. The procedure verifies
whether a mobile node can receive packets at its claimed home and
care-of addresses. As these tests are executed during the critical
handover phase, their latency may have an adverse impact on
delay-sensitive applications.
This document proposes an optimization to Mobile IPv6, Early Binding
Updates, which eliminates the handover delay caused by the
return-routability procedure. Early Binding Updates move the
home-address test to the time before handover, and they postpone the
care-of-address test to a time when the new care-of address can
already be used. The performance of this optimization is analyzed
and compared to that of standard Mobile IPv6.
Early Binding Updates additionally allow a mobile node to proactively
register a new care-of address prior to handover. This can eliminate
the entire Mobile IPv6 handover delay. Proactive registrations
require assistance from the local access network for IPv6 Neighbor
Discovery and Duplicate Address Detection.
Vogt Expires August 18, 2005 [Page 22]
Internet-Draft Early Binding Updates February 2005
Early Binding Updates are realized as an optional, and fully
backward-compatible, extension to Mobile IPv6. Early Binding Updates
use two new messages, both of which have no effect if either
communication end-point does not support them.
There is, however, a price to pay for the reduced latency. First,
Early Binding Updates require transmission of one or two additional
messages: an EBU and, optionally, an EBA for confirmation. Second, a
mobile node must execute the home-address test periodically unless
the test can be more efficiently scheduled through link-layer
notifications. This generally increases the signaling overhead as
well. However, the additional overhead should be worth being spent
in exchange for the expected performance gain.
To gather more insight in this regard, Early Binding Updates have
been implemented based on the Kame-Shisa Mobile IPv6 extension for
FreeBSD. The source code is available at [15]. Practical
performance evaluations will supplement the analytical results shown
in this document.
9. Protocol Constants
Early Binding Updates use the protocol constants and variables
defined in RFC 3775 [1]. This section summarizes some additional
protocol constants.
HOME_ADDR_TEST_INTERVAL 200 seconds
TENTATIVE_RR_BINDING_LIFETIME 10 seconds
10. References
10.1 Normative References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
10.2 Informational References
[2] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications",
ANSI/IEEE Standard 802.11, R2003, June 2003.
Vogt Expires August 18, 2005 [Page 23]
Internet-Draft Early Binding Updates February 2005
[3] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.
[4] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", RFC 2827, May 2000.
[5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[6] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[7] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[8] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[9] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[10] Haddad, W., Madour, L., Arkko, J. and F. Dupont, "Applying
Cryptographically Generated Addresses to Optimize MIPv6
(CGA-OMIPv6)", Internet-Draft draft-haddad-mip6-cga-omipv6
(work in progress).
[11] Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E.
Nordmark, "Mobile IP version 6 Route Optimization Security
Design Background", Internet-Draft draft-ietf-mip6-ro-sec (work
in progress).
[12] Koodli, R., "Fast Handovers for Mobile IPv6",
Internet-Draft draft-ietf-mipshop-fast-mipv6 (work in
progress).
[13] Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile
IPv6 Early Binding Updates",
Internet-Draft draft-vogt-mobopts-credit-based-authorization
(work in progress).
[14] Montenegro, G. and C. Castelluccia, "Crypto-Based Identifiers
(CBIDs): Concepts and Applications", ACM Transactions on
Information and System Security Vol. 7, No. 1, February 2004.
[15] "Route Optimization Optimized", Project homepage, available
Vogt Expires August 18, 2005 [Page 24]
Internet-Draft Early Binding Updates February 2005
at http://www.tm.uka.de/~chvogt/ro2/.
[16] "Kame-Shisa Mobile IPv6 Implementation for FreeBSD", available
at http://www.mobileip.jp/.
Author's Address
Christian Vogt
Institute of Telematics
University of Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
Email: chvogt@tm.uka.de
URI: http://www.tm.uka.de/~chvogt/
Appendix A. Acknowledgements
For their interest and valuable feedback, the author thanks the MIP6
and MOBOPTS communities, in particular Jari Arkko, Roland Bless, Mark
Doll, Francis Dupont, Gregory Daley, James Kempf, Tobias Kuefner,
Lars Eggert, Nick (Sharkey) Moore, Pekka Nikander, Erik Nordmark,
Charles Perkins, and Kilian Weniger (listed in alphabetical order).
Thanks are also due to Keiichi Shima and his colleagues from the
Kame-Shisa development team.
Vogt Expires August 18, 2005 [Page 25]
Internet-Draft Early Binding Updates February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Vogt Expires August 18, 2005 [Page 26]