Mobile-IP Working Group Greg Daley
INTERNET-DRAFT Monash University CTIE
Expires: September 2003 JinHyoeck Choi
Samsung AIT
February 2003
Movement Detection Optimization in Mobile IPv6
draft-daley-mobileip-movedetect-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Definitions of requirements keywords are in accordance with the IETF
Best Current Practice - [RFC-2119]
Abstract
This draft describes the state of the art techniques in movement
detection and elaborates on their application to Mobile IPv6
networks. The aim of the draft is to describe the applicability of
each mechanism and stimulate discussion on such techniques.
Table of Contents
Status of this Memo.......................................... 1
Abstract..................................................... 1
Table of Contents............................................ 1
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 1]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
1.0 Introduction............................................. 2
2.0 Movement Detection Overview.............................. 3
2.1 Handoff Process.......................................... 3
2.2 Movement Detection Mechanism............................. 4
2.3 Movement Detection Performance with Neighbor Discovery... 4
3.0 Movement Detection Schemes............................... 5
3.1 Periodic Router Advertisement Beaconing.................. 5
3.2 RA caching in Layer 2 Access Points...................... 6
3.3 Solicitation on Interval Timeout......................... 7
3.4 Mobile Node Triggered Solicitation....................... 8
3.5 Fast Router Advertisement ............................... 8
4.0 Performance Considerations............................... 9
4.1 Effects of Solicitation Delays........................... 9
4.2 Performance Comparisons.................................. 10
4.3 Effects of Packet Loss................................... 11
5.0 Combining Movement Detection Optimizations............... 12
6.0 Predictive Handover Effects.............................. 12
7.0 IANA Considerations...................................... 12
8.0 Security Considerations.................................. 14
Normative References......................................... 15
Non-Normative References..................................... 15
Acknowledgements............................................. 15
Authors' Address............................................. 15
Appendix.....................................................
Changes Since Last Revision..................................
1.0 Introduction
Seamless handoff systems aim at reducing the disruption caused by
moving between IP networks. Movement Detection is a prerequisite
task necessary for a Mobile IPv6 (MIPv6) Mobile Node (MN) to perform
handover signaling[MIPv6-20]. As defined in the base MIPv6
specification, detection of movement is accomplished through
reception of Router Advertisements (RAs), and comparison of these
messages with previously received router information.
Other handover operations, such as Duplicate Address Detection(DAD)
and movement binding signaling occur subsequently to movement
detection. Since Movement Detection is a the first operation to
occur in a non-predicted handover, Movement detection optimizations
aim at reducing the time before the RA is received by the MN. This
reduction of movement detection time reduces handover duration.
The MN inspects RA messages to determine if a router on that
interface is providing routing information which supercedes or
invalidates a current Care-of-Address (CoA). The CoA may be
invalidated because a router retracts a prefix (valid lifetime=0),
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 2]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
timers expire which deprecate the existing CoA and Router entries or
a heuristic is in place assumes movement if an RA is received with a
new prefix, from a new router. In MIPv6, detection of movement
causes configuration or selection of new Care of Addresses, and
binding signaling is commenced.
2.0 Movement Detection Overview
Movement detection is one of a series of stages in accomplishing
MIPv6 handover. The section below indicates the steps required for
handovers to occur.
2.1. Handoff Process
When an active MN moves to a new IP subnet, it changes its point of
attachment to the network through the following handoff process.
First layer 2 handoff occurs to change the wireless AP to which MN is
associated. After a new layer 2 connection is established, layer 3
handoff is performed, which broadly involves movement detection, IP
address configuration and location update.
Initially, the MN's IP protocol implementation may be unaware of the
link change, or may have been informed of the arrival by a link-
trigger. Alternatively, the network itself may be aware of the MN's
movement and may make use of this information to aid movement
detection. Subsequently the MN receives a Router Advertisement which
indicates that movement has occurred. The RA may have been an
unsolicited `beacon' message which has been periodically sent by the
router, or it may be in response to a Router Solicitation.
Once the MN knows it has moved, stateless or stateful address
configuration including DAD is performed [RFC-2462]. This entails
waiting for validation to complete, before further packets may be
sent or received by the MN.
Mobility signaling procedures are then started, with the MN sending a
Binding Update (BU) to its Home Agent. Additionally Return
Routability (RR) procedures are started for route optimized
conversations with Correspondent Nodes (CNs). As the Return
Routability tests are completed, further BU messages are sent to CNs.
Because movement detection is prerequisite for other layer 3 handoff
operations, for seamless handoff, it is necessary to detect movement
as fast as possible given the underlying link technology.
Proposals for predictive handovers change these assumptions and
ordering. The role played by movement detection in predictive
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 3]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
handovers is defined in section 6.0.
2.2. Movement Detection Mechanism
The primary movement detection mechanism for Mobile IPv6 defined in
[MIPv6-20] uses the facilities of IPv6 Neighbor Discovery, including
Router Discovery (RD) and Neighbor Unreachability Detection (NUD).
Movement Detection is accomplished through reception of Router
Advertisements (RAs) and comparison of these messages with the
previously received ones.
When an RA arrives, MN compares the contained router information with
the current one. The MN inspects 'Prefix Information' options to
check whether the prefix of current CoA is still valid. If the
prefix of current CoA is not designated as the on-link prefix in any
Prefix Information Option, the MN assumes that it has moved to a new
IP subnet and starts IP address configuration and location update.
Access routers SHOULD include all their on-link prefixes in every RA
as designated in [RFC-2461]. If an access router sends an RA
omitting some on-link prefixes, the MNs using the CoAs with those
prefixes will mistake that they have moved.
An MN SHOULD NOT use the router address in RA for movement detection.
The source address field of RA contains the link-local address of the
interface on the router sending the RA. If MN is in a network with
multiple access routers, it will receive the RAs with different
router addresses. In this case, even though the router address in RA
has been changed, a MN has not moved.
On the other hand, because the router address in RA is link-local
address, its uniqueness is not guaranteed outside a link. Hence the
fact that MN receives the RA with the same router address doesn't
imply that it still remains in the same IP subnet.
2.3. Movement Detection Performance with Neighbor Discovery
Movement detection algorithms are based on Router Discovery
mechanisms, which allow the periodic multicast of RAs to node on a
(fixed) IPv6 network. Router Discovery forms a part of [RFC-2461]
the Neighbor Discovery Protocol. [RFC-2461] additionally allows
solicitation of RA's in order to confirm network identity, or speed
device configuration.
Neighbor Discovery protocol constants were sized for networks of many
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 4]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
nodes, where it was sufficient to provide configuration within a few
seconds. This has caused significant delays to be built into Router
Discovery[RFC-2461]. Networks supporting MIPv6 MNs need to be able
to receive RAs in shorter time intervals than are available for
standard Router Discovery. This is important because Mobile Nodes
may have existing higher-layer sessions when Router Discovery is
performed, which may be affected by slow handover times.
Movement detection performance is measured from the time when the new
Layer 2 connection is established until movement is discovered
through RA reception. The base MIPv6 document specifies two movement
detection algorithms one which uses periodic unsolicited router
advertisements and one which uses RA Interval Timer expiry as a
trigger for Router Solicitation(RS). Additionally, the MN can use
unsolicited RA information received from the network for movement
detection purposes.
In environments where the MN can receive an indication a link has
been joined, this information can be used to trigger an RS
immediately[MIPv6-20]. This is equivalent of the best performance
available for Interval Timer expiry, although these mechanisms are
subject to routers delaying 0-500 ms before responding to the RS, and
the advice that the MN delays 0-1000 ms before sending an RS
[RFC-2461]. Additionally, if there is no verified link-address
available for Router Solicitation, the router must respond with a
multicast RA. These multicast RAs have a minimum spacing of
MinDelayBetweenRAs[MIPv6-20].
Periodic RA beaconing transmits packets within an interval varying
randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds. In
[RFC-2461] these minimums for these values are 3 and 4 seconds,
respectively. Since MN movement is unrelated to the advertisement
time on the new network, the MN is expected to arrive, on average
half way through the interval. This is about 1.75 seconds with
[RFC-2461] advertisement rates. Worst case performance (without
packet loss) is when the MN arrives just after an RA, and the next RA
is scheduled close to MaxRtrAdvInterval.
Movement detection optimizations seek to lower the time taken to
perform Router Discovery, either through MN solicitation, or timely
unsolicited advertisement of router information. To achieve this
aim, modifications to Router Discovery are made on mobile-supporting
networks and MNs.
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 5]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
3.0 Movement Detection Schemes
3.1 Periodic Router Advertisement Beaconing
Beaconing is a term used to refer to multicasting of network
identification information at regular intervals. Mobile IPv6 reduces
the lower bound of the MinRtrAdvInterval and MaxRtrAdvIntervals to 30
and 70 ms respectively[MIPv6-20]. With these settings, beacons will
be sent no more closely than 30 ms apart, and with no greater
separation than 70ms. Routers are required to send the beacons at
random times within this interval. This means that an MN will
receive an RA within 70ms of arriving on the link, and may expect to
receive an RA within 25ms, if we assume MN entry into the network to
be randomly distributed in the interval.
This technique requires no action on the part of the MN other than
listening to RA multicasts. The bandwidth consumption by multicast
beacons is 14 kbps when RAs only include one Prefix Information
option. Addition of a Soure-Link-Layer-Address option and a MIPv6
Advertisement Interval option typically increase this to 16.6 kbps.
On some networks, such overhead (~20 multicast packets per second)
causes a serious burden on network bandwidth. In these cases,
[RFC-2461] specified intervals SHOULD be used, if other movement
detection mechanisms are available.
Additionally, the reduced interval between messages may have side
effects for non-MIPv6 nodes on the same networks. The
AdvDefaultLifetime value is used to set the lifetime of the default
router in seconds, as advertised in the Router Lifetime field of the
RA. The minimum value specified in [RFC-2461] for this value is
MaxRtrAdvInterval. This value is less than one second when using
MIPv6 specified advertisement intervals. Even if default router
lifetimes are rounded up to the nearest second, nodes which assume
MaxRtrAdvInterval is at [RFC-2461] values could be confused about the
lifetime of their default router. Routers SHOULD ensure that
AdvDefaultLifetime is greater than or equal to 4 seconds, in order to
avoid this confusion.
3.2 RA caching in Layer 2 Access Points (Fast Router Discovery [FRD-00])
One method which requires no solicitation from the MN is network
triggering of RA. Router advertisements are sent to the MN when it
attaches to an access point (AP) associated with this network.
In network deployments, the router may not be the link-layer device
which the MN connects to, and therefore may be unaware of MN link-
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 6]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
connection. Only in the case where the the AP advises the router of
connection or AAA state, can the router send (unscheduled)
unsolicited RAs before receiving packets from the MN.
The Fast Router Discovery (FRD) draft[FRD-00] places the
responsibility of sending triggered RA messages upon APs. The Access
Points cache RA's recently sent from the router, and deliver a frame
to the MN when it connects. This frame is datalink-unicast to the MN
and contains the most recent unsolicited RA.
In this case, less frequent transmission of unsolicited multicast RA
messages may be used. At the same time, the first frame which is
queued for the MN is the RA required for movement detection.
Deployment of FRD requires each of the APs for the network to be
capable of both the caching and triggered sending operations.
Analysis and experimental results indicate that this is potentially
the fastest movement detection optimization, dependent on AP
processing capacity.
3.3 Solicitation on Interval Timeout
As specified in MIPv6, the Advertisement Interval Option describes
the maximum time between unsolicited RA messages (MaxRtrAdvInterval).
This option is used in movement detection as a packet loss management
system, where after elapse of one or more Advertisement Intervals
without RA reception, the MN can send a router solicitation.
In the case where MNs send RSs after the loss of multicast RA
messages, all MN's which have not received the RAs will time out at
the same instant. [RFC-2461] specifies an additional delay of 0-1000
ms required for the purposes of desynchronizing RS messages sent
from many hosts. An MN which does not have other confirmation that
it has moved SHOULD follow this policy. Further details of this
issue, especially with regard to simultaneous movement, are presented
in section 4.1.
In the case where the MN moves by itself, this algorithm provides
best performance when the MN connects to a new network just before an
interval passes. If the MN is acting upon one packet's loss then
this provides an RS immediately. If the timer elapses when there is
no connection to a link, it is implementation dependent whether the
RS packet is lost. Typically though, the MN will leave the previous
access network on average half way through the mean RA interval. The
expected time left until the Advertisement Interval elapses upon the
MN leaving the network is:
ExpIval = 0.75*MaxRtrAdvInterval - 0.25*MinRtrAdvInterval
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 7]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
This does not account for the Link-layer handover time, which may be
tens or hundreds of milliseconds. When these values are the minimums
described by [RFC-2461], this value is 2.25 seconds and therefore
does not seem to provide significant benefit unless faster (MIPv6)
beacons are being sent. At the MN specified beacon rate, the
expected residual interval is 45 ms.
Any of the methods which require responses to router solicitations as
specified by [RFC-2461] also incur an additional delay of between 0
and 500 ms before a response is sent by the router. Section 3.5
describes a mechanism to cope with this issue.
3.4 Mobile Node Triggered Solicitation
For situations where RA packets have been transmitted correctly, the
Advertisement Interval's best case occurs when the timeout occurs
just after the MN joins a new link. In environments where the MN can
receive an indication a link has been joined, this information can be
used to trigger an RS immediately[MIPv6-20], although once again a
random delay before sending RS's is advised by [RFC-2461].
Upon entering a new subnet, there is a small chance that the MN will
have a duplicate address collision with another device's link-local
address[RFC-2462]. When an MN solicits an RA, it typically sends
from the link-local address, unless this address is
tentative[RFC-2461]. If the MN sends from the link-local address,
unicast responses are allowed, and in this case, rate limiting of
multicast RA messages is avoided.
If the MN joins a link, then until it knows the identity of the link
(has received an RA), it MUST assume that it is on a new link, where
its link-local address is tentative. This means that RS messages
will either be deferred until DAD operations have been performed on
the Link-Local address or the RS MUST be sent with an unspecified
address. A multicast response will be scheduled no sooner than:
Max(LastMcastRATime + MinDelayBetweenRAs,
now + 0-500 ms RS Response Delay)
Where MinDelayBetweenRAs could be as high as 3 seconds. Even if the
response is not multicast, the RS response delay is still incurred.
3.5 Fast Router Advertisement [FASTRA-02]
Fast Router Advertisement (FastRA) removes the random delay required
of a router before it responds to RS messages. It relies upon only
one router on a subnet being configured for FastRA, so that responses
are not simultaneous. FastRA principally aims at delivery of unicast
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 8]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
RA messages, since the rate limiting of multicast RA messages
specified in [RFC-2461] specifies that RA messages may not be sent
within 3 seconds of each other.
Similar action could be performed with multicast RA responses if
FastRA adopted the MinDelayBetweenRAs as in [MIPv6-20]. In this
case, the response would only be delayed if the last multicast RA
occurred more recently than MinDelayBetweenRAs ago (or MaxFastRAs has
been consumed). This could work well if the arrival of mobile nodes
occurred much less frequently than the unsolicited multicast RA
interval.
FastRA incorporates a rate limiting feature aimed at diminishing the
potential effect of FastRA traffic on nodes which are already
connected to the network. Routers may transmit no more than
MaxFastRAs advertisements in an interval before discarding
solicitations until the next unsolicited multicast RA.
Either of the solicitation mechanisms may be used to get FastRA
response from a router, although Advertisement Interval timeout will
only be invoked on packet loss if Link-triggers are available.
Movement detections times are bounded only by the time to send the
Multicast RS message and send the unicast RA response. Recent
testing has indicated 95% of RAs were received within 15 ms of
sending an RS on 802.11b networks, when Neighbor Discovery was being
performed on the MN's link-local address. If RS messages include
Source Link-Layer Address options[RFC-2461] or are multicast
responses with no timer delays, movement detection time will be
lower.
4.0 Performance Considerations
4.1 Effects of Solicitation Delays
[RFC-2461] specifies that a node SHOULD delay a random interval of
between 0 and 1000 (MAX_RTR_SOLICITATION_DELAY) ms before sending an
RS if it is the first packet the node sends on the link [RFC-2461].
A similar delay is stipulated for DAD packets in [RFC-2462], for the
same circumstances.
These delays are provided for the case where many devices are
configuring on the link at the same time. In a mobility environment,
this may occur if many MNs are traveling together, for example on a
train, or at peak hours on a freeway. For this environment, there is
some possibility that the MNs' simultaneous transmission of multicast
RS or DAD packets will will cause interference or backoff and
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 9]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
retransmission.
The effect of such simultaneous movement and subsequent multicast
transmission is the topic of current research. On several wireless
technologies, the effect is thought to be minimal, especially where
discrete codes or data channels are provided to each subscriber.
There are certainly other environments where many devices
simultaneously transmitting have a detrimental effect though, and in
these cases, the configuration by MNs SHOULD be serialized. The
serialization provided by a random timer is one mechanism by which
simultaneous transmission may be avoided. Other methods, are reliant
upon serializing effects in the Link-Layer, such as AAA operations.
These effects are link-dependent and where they provide protection,
MNs SHOULD take advantage of them to avoid random timer delays.
It should be noted that multicast bombing may occur even in when no
RS is performed, if many nodes simultaneously receive an RA beacon
from a new router. These MNs' first operation is to undertake DAD
procedures. Link procedures are unlikely to provide serialization in
this case, since all MNs will receive the multicast at approximately
the same time.
4.2 Performance Comparisons
These handovers do not include delays due to DAD for unicast
responses, nor do they include RS/DAD delays to avoid multicast link
bombing.
Presented times are on a wireless link of ~2 Mbps, which is capable
of multicast at 1 Mbps.
|--------------------------------------------------------------|
| | Uni/Multicast| overhead | Move Detection Time (ms) |
| | Advertisement| (kbps) | Avg | Max |
|--------------------------------------------------------------|
|Beacon | Multicast | >14 | 25 | 70 |
| | | | | |
|--------------------------------------------------------------|
|FRD | Multicast L3 | 0 | <10 | <20 |
| | (unicast L2?)| | | |
|--------------------------------------------------------------|
|Timer(a) | Unicast | 0 |ExpIval|MaxRtrAdvInterval |
| | | | +250 | +500 |
|--------------------------------------------------------------|
|LinkRS | Multicast | 0 | 250 | 530 |
|tentative| | | | |
|--------------------------------------------------------------|
|LinkRS | Unicast | 0 | 250 | 500 |
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 10]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
|unicast | | | | |
|--------------------------------------------------------------|
|FastRA | Multicast | 0 | <10 | 60 |
|tentative| | | | |
|--------------------------------------------------------------|
|FastRA | Unicast | 0 | <10 | <30 |
|unicast | | | | |
|--------------------------------------------------------------|
Notes:
(a) These duration value includes Link-Layer handover time,
where no other row does.
4.3 Effects of Packet Loss
Packet loss from (network and MN) triggered systems can be a
significant factor MIPv6 handovers performance. When a quickly
delivered RA message is lost, then the MN may wait until the next
unsolicited multicast RA message, which can take up to four seconds
(RFC-2461 MaxRtrAdvInterval).
In MN triggered systems, if RS messages are lost and have to be
resent, movement detection times are increased by up to four seconds.
This timeout is governed by the value of the Neighbor Discovery
constant RTR_SOLICITATION_INTERVAL.
In solicited RA environments, the exchange of RS/RA messages is
susceptible to loss of either packet, as is the case with NS/NA if
the router needs to perform Neighbor Discovery on the MN before
sending a unicast RA response.
Beacon systems which transmit RAs at high rate are less susceptible
to the adverse affects of packet loss, since replacement packets are
transmitted quickly after the packet loss event.
Backup effects from Advertisement Interval timers may play a part in
the solicitation of replacement RA messages, although unless link-
layer handover times are considered, these provide worse performance
than beacon based systems.
5.0 Combining Movement Detection Optimizations
When arriving on a network, an MN is unaware which movement detection
optimizations are in place on the network, or whether any are in use.
The MN may therefore choose to send an RS before it receives an
unsolicited RA, even though either FRD or RA beaconing are in place.
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 11]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
In all likelihood, both RA delivery mechanisms will be activated.
In this case, the movement detection time will typically not be
affected, except that more packets will be sent to the wireless
medium. Therefore, if an MN has received a link-trigger, and the MN
subsequently receives an RA before it has scheduled an RS packet to
be sent, the MN SHOULD NOT send the RS.
In most cases without packet loss, the presence of fast beacons will
not significantly affect the performance of FastRA or FRD systems.
As mentioned in section 4.3 though, the harm caused by packet loss is
significantly lowered if beacons are received within a short period.
If the overhead of running beaconing systems is sufficiently low for
the wireless link type, then beacons MAY be used with either of FRD
and FastRA.
Networks with either of FRD or FastRA capability are unlikely to also
use the other technology on their systems, since FRD and FastRA are
closely matched in performance and have low latency times. If the
network has both capabilities, there is some chance that RA messages
from AP and Router attempt to be delivered simultaneously to the MN.
Since there is no way for the MN to know that FRD is in use when
soliciting, it MAY send an RS in any case, if it has not received an
RA already from this link.
6.0 Predictive Handover Effects
Movement detection optimizations' applicability is principally in
non-predictive movement environments, although there may be some
benefit for anticipated/fast handover systems as movement
confirmation and correction mechanisms.
Handover prediction allows MNs to select the network to which they
move, and perform handover signaling in anticipation of this event.
This allows the tunneling and buffering of MN traffic within network
routers while the Link-layer handover is occurring.
With some link environments, it may not be possible to guarantee that
the MN will arrive on the selected link, nor that the MN has indeed
arrived on that link. In these cases, it is still necessary to
confirm that the MN is arrived on the link through movement detection
algorithms. This allows the MN to send corrective binding signaling
in the case that the network is a different one than was the
anticipated destination.
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 12]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
7.0 IANA Considerations
No new message formats or services are defined in this document.
8.0 Security Considerations
Movement detection optimizations are reliant upon reception of a
Router Advertisement with properly configured Prefix Information
Options [RFC-2461].
Since Movement Detection is based on Neighbor Discovery, its trust
models and threats are similar to the ones presented in [SEND-
psreq-01]. The attacks described in 4.0 of [SEND-psreq-01] can be
applied to Movement Detection too. Movement Detection schemes SHOULD
incorporate the solutions developed in IETF SEND Working Group if
available, where threat assessment indicates such procedures are
required.
Moreover the threats described in 4.2 of [SEND-psreq-01] may cause
more serious problems. When there is an indication that the current
IP connection has changed (Link down, New Router Advertisement et
cetera), non-mobile nodes will first perform NUD[RFC-2461]. The
MIPv6 handoff process (including Movement Detection) is time
sensitive. So mobile nodes may start handoff without Neighbor
Unreachability Detection.
If higher layer notification of connectivity is not available, and
eager handoff strategies are in place, any node or router which
advertises an RA with a false prefix will cause MNs to perform
spurious handover signaling and DAD operations.
For non-mobile case, if a node receives a bogus RA which doesn't
include the prefix of its current address, it doesn't assume that its
current prefix becomes off-link. In Neighbor Discovery, the only way
to cancel a previous on-link indication is to advertise that prefix
with the L-bit set and the Lifetime set to zero [RFC-2461]. Hence the
node keeps using the current address and not so much harm is done.
In the mobile case, the threat is more serious. Assume an attacker
sends an RA which includes only false Prefix Information Options. If
a MN receives a bogus RA which doesn't include the prefix of the
current CoA, it will assume that movement has occurred. The MN will
start DAD (with the bogus prefix) and send BUs (with a false CoA).
Hence MN will be disconnected, or its packets will be intercepted and
subject to man-in-the-middle attack[SEND-psreq-01].
Moreover if we configure MNs to send RS and DAD without delay, this
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 13]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
bogus RA attack may cause multicast bombing too. An attacker can
send a bogus RA without source Link-Layer Address option. Then all
MNs will receive the bogus RA at the same time and start Neighbor
Discovery simultaneously. They will send RS without delay at the
same time and cause RS congestion. An attacker can deceive all MNs
to believe they have moved simultaneously by sending a suitable bogus
RA. In this case, DAD would be performed by all nodes on the link
immediately on multicast RA reception.
The security issues described above are not specific to any Movement
Detection scheme presented in this draft but are inherent in any
mechanism which uses only Router Discovery for movement detection.
Information from lower layers will be useful to mitigate the above
threats. Assume there is an MN for which link-layer trigger is
provided to notify link-layer change. If the link-layer trigger
precedes a new RA, it is likely that the RA is valid and the MN has
actually moved.
When the MN moves to a new IP subnet, link-layer change usually
precede movement. So first link-layer change is notified to the MN
and it anticipates movement. Hence when a new RA arrives, the MN can
reasonably believe it.
On the other hand, if the MN receives a new RA without the
notification of link layer change, it is likely that the RA is bogus.
In this case, the MN SHOULD be suspicious:
Before initiating the handoff process, it SHOULD perform Neighbor
Unreachability Detection to request a RA from its default router.
Also, without link-layer information, RFC-2461 and 2462 delays before
sending RS and DAD messages SHOULD be performed, until NUD has
completed.
This document references several other documents, each of which
defines its own security considerations. Readers are referred to
these documents for further information.
Normative References
[RFC-2119] S. Bradner. Key words for use in RFCs to Indicate
Requirement Levels. Request for Comments (Best Current Practice)
2119 (BCP 14), Internet Engineering Task Force, March 1997
[RFC-2461] T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461,
Internet Engineering Task Force, December 1998.
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 14]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
[RFC-2462] S. Thomson, T. Narten. IPv6 Stateless Address
Autoconfiguration. Request for Comments (Draft Standard) 2462,
Internet Engineering Task Force, December 1998.
[FASTRA-02] M. Khalil, J. Kempf, B. Pentland. IPv6 Fast Router
Advertisement (FastRA), Internet Draft (work in progress),
October 2002.
[FRD-00] JinHyoeck Choi, DongYun Shin. Fast Router Discovery with RA
Caching in AP. Internet Draft (work in progress), Feb 2003.
[MIPv6-20] D. Johnson, C. Perkins, J. Arkko. Mobility Support in
IPv6. Internet Draft (work in progress), January 2003.
[SEND-psreq-01] P. Nikander (Ed.), J. Kempf, E. Nordmark. IPv6
Neighbor Discovery trust models and threats. Internet Draft
(work in progress), January 2003.
Non-Normative References
Acknowledgements
Thanks to the authors and editors of the MIPv6 (David Johnson,
Charles Perkins Jari Arkko), FastRA (Mohammed Khalil, James Kempf
and Brett Pentland), and FastRD (JinHyoeck Choi {thx from Greg} and
DongYun Shin) drafts. We have relied heavily upon their work and aim
only to illuminate their good ideas.
Authors' Addresses:
Greg Daley
E-mail: greg.daley@eng.monash.edu.au
Phone: +61-3-9905-4655
Address:
Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering
Monash University
Clayton 3800 Victoria
Australia
JinHyoeck Choi
E-mail: athene@sait.samsung.co.kr
Phone: +82-31-280-9233
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 15]
INTERNET-DRAFT MIPv6 Movement Detection Optimizations February 2003
Address:
i-Networking Lab, Samsung AIT (SAIT)
Appendix:
..
Changes Since Last Revision:
..
This document expires in September 2003.
Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 16]