draft-ietf-mip6-ro-sec-00.txt   draft-ietf-mip6-ro-sec-01.txt 
Network Working Group P. Nikander Network Working Group P. Nikander
Internet-Draft J. Arkko Internet-Draft J. Arkko
Expires: October 3, 2004 Ericsson Research Nomadic Lab Expires: January 17, 2005 Ericsson Research Nomadic Lab
T. Aura T. Aura
Microsoft Research Microsoft Research
G. Montenegro G. Montenegro
E. Nordmark E. Nordmark
Sun Microsystems Sun Microsystems
April 4, 2004 July 19, 2004
Mobile IP version 6 Route Optimization Security Design Background Mobile IP version 6 Route Optimization Security Design Background
draft-ietf-mip6-ro-sec-00 draft-ietf-mip6-ro-sec-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 3, 2004. This Internet-Draft will expire on January 17, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document is a succint account of the rationale behind the Mobile This document is a succint account of the rationale behind the Mobile
IPv6 (MIPv6) Route Optimization Security Design. The purpose of this IPv6 (MIPv6) Route Optimization Security Design. The purpose of this
document is to present the thinking and to preserve the reasoning document is to present the thinking and to preserve the reasoning
skipping to change at page 2, line 13 skipping to change at page 2, line 18
they can better understand the design choices in MIPv6 security they can better understand the design choices in MIPv6 security
procedures; and (2) people dealing with mobility or multi-homing so procedures; and (2) people dealing with mobility or multi-homing so
that they can avoid a number of potential security pitfalls in their that they can avoid a number of potential security pitfalls in their
design. design.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Assumptions about the Existing IP Infrastructure . . . . . 5 1.1 Assumptions about the Existing IP Infrastructure . . . . . 5
1.1.1 A note on source addresses and ingress filtering . . . 6 1.1.1 A note on source addresses and ingress filtering . . . 6
1.2 The Mobility Problem and the Mobile IPv6 Solution . . . . 6 1.2 The Mobility Problem and the Mobile IPv6 Solution . . . . 7
1.3 Design Principles and Goals . . . . . . . . . . . . . . . 8 1.3 Design Principles and Goals . . . . . . . . . . . . . . . 8
1.3.1 End-to-end principle . . . . . . . . . . . . . . . . . 8 1.3.1 End-to-end principle . . . . . . . . . . . . . . . . . 9
1.3.2 Trust assumptions . . . . . . . . . . . . . . . . . . 9 1.3.2 Trust assumptions . . . . . . . . . . . . . . . . . . 9
1.3.3 Protection level . . . . . . . . . . . . . . . . . . . 9 1.3.3 Protection level . . . . . . . . . . . . . . . . . . . 9
1.4 About Mobile IPv6 Mobility and its Variations . . . . . . 9 1.4 About Mobile IPv6 Mobility and its Variations . . . . . . 10
2. Dimensions of Danger . . . . . . . . . . . . . . . . . . . . . 11 2. Dimensions of Danger . . . . . . . . . . . . . . . . . . . . . 11
2.1 Target . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 Target . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Location . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3 Location . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Threats and limitations . . . . . . . . . . . . . . . . . . . 13 3. Threats and limitations . . . . . . . . . . . . . . . . . . . 13
3.1 Attacks against address 'owners' aka. address 3.1 Attacks against address 'owners' aka. address
'stealing' . . . . . . . . . . . . . . . . . . . . . . . . 13 'stealing' . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1 Basic address stealing . . . . . . . . . . . . . . . . 14 3.1.1 Basic address stealing . . . . . . . . . . . . . . . . 14
3.1.2 Stealing addresses of stationary nodes . . . . . . . . 15 3.1.2 Stealing addresses of stationary nodes . . . . . . . . 15
3.1.3 Future address stealing . . . . . . . . . . . . . . . 15 3.1.3 Future address stealing . . . . . . . . . . . . . . . 15
3.1.4 Attacks against Secrecy and Integrity . . . . . . . . 16 3.1.4 Attacks against Secrecy and Integrity . . . . . . . . 16
3.1.5 Basic Denial of Service Attacks . . . . . . . . . . . 17 3.1.5 Basic Denial of Service Attacks . . . . . . . . . . . 17
3.1.6 Replaying and Blocking Binding Updates . . . . . . . . 17 3.1.6 Replaying and Blocking Binding Updates . . . . . . . . 17
3.2 Attacks against other nodes and networks (flooding) . . . 18 3.2 Attacks against other nodes and networks (flooding) . . . 18
3.2.1 Basic flooding . . . . . . . . . . . . . . . . . . . . 18 3.2.1 Basic flooding . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Return-to-home flooding . . . . . . . . . . . . . . . 19 3.2.2 Return-to-home flooding . . . . . . . . . . . . . . . 19
3.3 Attacks against binding update protocols . . . . . . . . . 20 3.3 Attacks against binding update protocols . . . . . . . . . 20
3.3.1 Inducing Unnecessary Binding Updates . . . . . . . . . 20 3.3.1 Inducing Unnecessary Binding Updates . . . . . . . . . 20
3.3.2 Forcing Non-Optimized Routing . . . . . . . . . . . . 21 3.3.2 Forcing Non-Optimized Routing . . . . . . . . . . . . 21
3.3.3 Reflection and Amplification . . . . . . . . . . . . . 22 3.3.3 Reflection and Amplification . . . . . . . . . . . . . 22
3.4 Classification of attacks . . . . . . . . . . . . . . . . 23 3.4 Classification of attacks . . . . . . . . . . . . . . . . 24
3.5 Problems with infrastructure based authorization . . . . . 24 3.5 Problems with infrastructure based authorization . . . . . 24
4. The solution selected for Mobile IPv6 . . . . . . . . . . . . 26 4. The solution selected for Mobile IPv6 . . . . . . . . . . . . 26
4.1 Return Routability . . . . . . . . . . . . . . . . . . . . 26 4.1 Return Routability . . . . . . . . . . . . . . . . . . . . 26
4.1.1 Home Address check . . . . . . . . . . . . . . . . . . 28 4.1.1 Home Address check . . . . . . . . . . . . . . . . . . 28
4.1.2 Care-of-Address check . . . . . . . . . . . . . . . . 29 4.1.2 Care-of-Address check . . . . . . . . . . . . . . . . 29
4.1.3 Forming the first Binding Update . . . . . . . . . . . 29 4.1.3 Forming the first Binding Update . . . . . . . . . . . 29
4.2 Creating state safely . . . . . . . . . . . . . . . . . . 29 4.2 Creating state safely . . . . . . . . . . . . . . . . . . 29
4.2.1 Retransmissions and state machine . . . . . . . . . . 31 4.2.1 Retransmissions and state machine . . . . . . . . . . 31
4.3 Quick expiration of the Binding Cache Entries . . . . . . 31 4.3 Quick expiration of the Binding Cache Entries . . . . . . 31
5. Security considerations . . . . . . . . . . . . . . . . . . . 33 5. Security considerations . . . . . . . . . . . . . . . . . . . 33
5.1 Residual Threats as Compared to IPv4 . . . . . . . . . . . 33 5.1 Residual Threats as Compared to IPv4 . . . . . . . . . . . 33
5.2 Interaction with IPsec . . . . . . . . . . . . . . . . . . 34 5.2 Interaction with IPsec . . . . . . . . . . . . . . . . . . 34
5.3 Pretending to be your neighbor . . . . . . . . . . . . . . 34 5.3 Pretending to be one's neighbor . . . . . . . . . . . . . 35
5.4 Two mobile nodes talking to each other . . . . . . . . . . 35 5.4 Two mobile nodes talking to each other . . . . . . . . . . 35
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 36 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
8. References (informative) . . . . . . . . . . . . . . . . . . . 37 8. Informative References . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . 40
1. Introduction 1. Introduction
Mobile IPv4 is based on the idea of supporting mobility on top of Mobile IPv4 is based on the idea of supporting mobility on top of
existing IP infrastructure, without requiring any modifications to existing IP infrastructure, without requiring any modifications to
the routers, the applications, or the stationary end hosts. However, the routers, the applications, or the stationary end hosts. However,
in Mobile IPv6 [7] (as opposed to Mobile IPv4) the stationary end in Mobile IPv6 [7] (as opposed to Mobile IPv4) the stationary end
hosts may provide support for mobility, i.e., route optimization. In hosts may provide support for mobility, i.e., route optimization. In
route optimization a correspondent node (CN), i.e., a peer for a route optimization a correspondent node (CN), i.e., a peer for a
mobile node, learns a binding between the mobile node's stationary mobile node, learns a binding between the mobile node's stationary
home address and its current temporary care-of-address. This binding home address and its current temporary care-of-address. This binding
is then used to modify the handling of outgoing (as well as the is then used to modify the handling of outgoing (as well as the
processing of incoming) packets, leading to security risks. The processing of incoming) packets, leading to security risks. The
purpose of this document is the provide a relatively compact source purpose of this document is the provide a relatively compact source
of the background assumptions, design choices, and other information of the background assumptions, design choices, and other information
needed to understand the route optimization security design. This needed to understand the route optimization security design. This
document does not seek to compare the relative security of Mobile document does not seek to compare the relative security of Mobile
IPv6 and other mobility protocols, or to list all the alternative IPv6 and other mobility protocols, or to list all the alternative
security mechanisms that were discussed during the Mobile IPv6 design security mechanisms that were discussed during the Mobile IPv6 design
process. For a summary of the latter, we refer the reader to [1]. process. For a summary of the latter, we refer the reader to [1].
The goal of this document is to explain the design choices and Even though incidental implementation suggestions are included for
rationale behind the current route optimization design. The authors illustrative purposes, the goal of this document is not to provide a
participated in the design team which produced the design, and hope, guide to implementors. The goal of this document is to explain the
via this note, to capture some of the lessons and reasoning behind design choices and rationale behind the current route optimization
that effort. design. The authors participated in the design team which produced
the design, and hope, via this note, to capture some of the lessons
and reasoning behind that effort.
The intent is to document the thinking behind that design effort, as
it was. Even though this note may incorporate more recent
developments in order to illustrate the issues, it is not our intent
to present a new design. Rather, along with the lessons learned,
there is some effort to clarify differing opinions, questionable
assumptions, or newly discovered vulnerabilities, should such new
information be available today. This is also very important, because
it may benefit the working group's hindsight as it revises or
improves the Mobile IPv6 specification.
To fully understand the security implications of the relevant design To fully understand the security implications of the relevant design
constraints it is necessary to briefly explore the nature of the constraints it is necessary to briefly explore the nature of the
existing IP infrastructure, the problems Mobile IP aims to solve, and existing IP infrastructure, the problems Mobile IP aims to solve, and
the design principles applied. In the light of this background, we the design principles applied. In the light of this background, we
can then explore IP based mobility in more detail, and have a brief can then explore IP based mobility in more detail, and have a brief
look at the security problems. The background is given in the rest of look at the security problems. The background is given in the rest
this section, starting from Section 1.1. of this section, starting from Section 1.1.
While the introduction in Section 1.1 may appear redundant to those While the introduction in Section 1.1 may appear redundant to those
readers who are already familiar with Mobile IPv6, it may be valuable readers who are already familiar with Mobile IPv6, it may be valuable
to read it anyway. The approach taken in this document is very to read it anyway. The approach taken in this document is very
different from the one in the Mobile IPv6 specification. That is, we different from the one in the Mobile IPv6 specification. That is, we
have explicitly aimed to expose the implicit assumptions and design have explicitly aimed to expose the implicit assumptions and design
choices made in the base Mobile IPv6 design, while the Mobile IPv6 choices made in the base Mobile IPv6 design, while the Mobile IPv6
specification aims to state the result of the design. By specification aims to state the result of the design. By
understanding the background it is much easier to understand the understanding the background it is much easier to understand the
source of some of the related security problems, and to understand source of some of the related security problems, and to understand
skipping to change at page 5, line 17 skipping to change at page 5, line 29
introductory section, we start by considering the dimensions of the introductory section, we start by considering the dimensions of the
danger in Section 2. The security problems and countermeasures are danger in Section 2. The security problems and countermeasures are
studied in detail in Section 3. Section 4 explains the overall studied in detail in Section 3. Section 4 explains the overall
operation and design choices behind the current security design. In operation and design choices behind the current security design. In
Section 5 we analyze the design and discuss the remaining threats. Section 5 we analyze the design and discuss the remaining threats.
Finally Section 6 concludes this document. Finally Section 6 concludes this document.
1.1 Assumptions about the Existing IP Infrastructure 1.1 Assumptions about the Existing IP Infrastructure
One of the design goals in the Mobile IP design was to make mobility One of the design goals in the Mobile IP design was to make mobility
possible without changing too much. This was especially important for possible without changing too much. This was especially important
IPv4, with its large installed base, but the same design goals was for IPv4, with its large installed base, but the same design goals
inherited by Mobile IPv6. Some alternative proposals take a were inherited by Mobile IPv6. Some alternative proposals take a
different approach and propose larger modifications to the Internet different approach and propose larger modifications to the Internet
architecture (see Section 1.4). architecture (see Section 1.4).
To understand Mobile IPv6, it is important to understand the MIPv6 To understand Mobile IPv6, it is important to understand the MIPv6
design view to the base IPv6 protocol and infrastructure. The most design view to the base IPv6 protocol and infrastructure. The most
important base assumptions can be expressed as follows: important base assumptions can be expressed as follows:
The routing prefixes available to a node are determined by its The routing prefixes available to a node are determined by its
current location, and therefore the node must change its IP current location, and therefore the node must change its IP
address as its moves. address as its moves.
The routing infrastructure is assumed to be secure and well The routing infrastructure is assumed to be secure and well
functioning, delivering packets to their intended destinations as functioning, delivering packets to their intended destinations as
identified by the destination address. identified by the destination address.
While these may appear as trivial, let us explore them a little While these may appear as trivial, let us explore them a little
further. Firstly, in the current IPv6 operational practise the IP further. Firstly, in the current IPv6 operational practice the IP
address prefixes are distributed in a hierarchical manner. This address prefixes are distributed in a hierarchical manner. This
limits the amount of routing table entries each single router needs limits the amount of routing table entries each single router needs
to handle. An important implication is that the topology determines to handle. An important implication is that the topology determines
what globally routable IP addresses are available at a given what globally routable IP addresses are available at a given
location. That is, the nodes cannot freely decide what globally location. That is, the nodes cannot freely decide what globally
routable IP address to use, but must rely on the routing prefixes routable IP address to use, but must rely on the routing prefixes
served by the local routers via Router Advertisements or by a DHCP served by the local routers via Router Advertisements or by a DHCP
server. In other words, IP addresses are just what the name says, server. In other words, IP addresses are just what the name says,
addresses, i.e., locators. addresses, i.e., locators.
Secondly, in the current Internet structure, the routers collectively Secondly, in the current Internet structure, the routers collectively
maintain a distributed database of the network topology, and forward maintain a distributed database of the network topology, and forward
each packet towards the location determined by the destination each packet towards the location determined by the destination
address carried in the packet. To maintain the topology information, address carried in the packet. To maintain the topology information,
the routers must trust each other, at least to a certain extent. The the routers must trust each other, at least to a certain extent. The
routers learn the topology information from the other routers, and routers learn the topology information from the other routers, and
they have no option but to trust their neighbor routers about distant they have no option but to trust their neighbor routers about distant
topology. At the borders of administrative domains, policy rules are topology. At the borders of administrative domains, policy rules are
used to limit the amount of perhaps faulty routing table information used to limit the amount of perhaps faulty routing table information
received from the peer domains. While this is mostly used to weed out received from the peer domains. While this is mostly used to weed
administrative mistakes, it also helps with security. The aim is to out administrative mistakes, it also helps with security. The aim is
maintain a reasonably accurate idea of the network topology even if to maintain a reasonably accurate idea of the network topology even
someone is feeding faulty information to the routing system. if someone is feeding faulty information to the routing system.
In the current Mobile IPv6 design it is explicitly assumed that the In the current Mobile IPv6 design it is explicitly assumed that the
routers and the policy rules are configured in a reasonable way, and routers and the policy rules are configured in a reasonable way, and
that the resulting routing infrastructure is trustworthy enough. That that the resulting routing infrastructure is trustworthy enough.
is, it is assumed that the routing system maintains accurate That is, it is assumed that the routing system maintains accurate
information of the network topology, and that it is therefore able to information of the network topology, and that it is therefore able to
route packets to their destination locations. If this assumption is route packets to their destination locations. If this assumption is
broken, the Internet itself is broken in the sense that packets go to broken, the Internet itself is broken in the sense that packets go to
wrong locations. Such a fundamental malfunction of the Internet would wrong locations. Such a fundamental malfunction of the Internet
render hopeless any other effort to assure correct packet delivery would render hopeless any other effort to assure correct packet
(e.g., any efforts due to Mobile IP security considerations). delivery (e.g., any efforts due to Mobile IP security
considerations).
1.1.1 A note on source addresses and ingress filtering 1.1.1 A note on source addresses and ingress filtering
Some of the threats and attacks discussed in this document take Some of the threats and attacks discussed in this document take
advantage of the ease of source address spoofing. That is, in the advantage of the ease of source address spoofing. That is, in the
current Internet it is possible to send packets with false source IP current Internet it is possible to send packets with false source IP
address. Ingress filtering is assumed to eventually prevent this. address. Ingress filtering is assumed to eventually prevent this.
When ingress filtering is used, the source address of all packets are When ingress filtering is used, traffic with spoofed addresses is not
screened by the Internet service provider, and if the source address forwarded. This filtering can be applied at different network
has a routing prefix that should not be used by the customer, the borders like those between an Internet service provider (ISP) and its
packets are dropped. customers, between downstream and upstream ISPs, between peer ISPs,
etc [6]. Obviously, the granularity of ingress filters specifies how
much you can "spoof inside a prefix". For example, if an ISP ingress
filters a customer's link, but the customer does nothing, anything
inside the customer's /48 prefix could be spoofed, or if the customer
does filtering at LAN subnets, anything inside the /64 prefixes could
be spoofed. Despite the limitations imposed by such "in-prefix
spoofing", in general, ingress filtering enables traffic to be
traceable to its real source network [6].
It should be noted that ingress filtering is relatively easy to apply However, ingress filtering helps if and only if a large part of the
at the edges of the network, but almost impossible in the core Internet uses it. Unfortunately, there are still some issues (e.g.
network. Basically, ingress filtering is easy only when the network in the presence of site multi-homing) which, although not
topology and prefix assignment do follow the same hierarchical insurmountable, do require careful handling, and are likely to limit
structure. Secondly, ingress filtering helps if and only if a large or delay its usefulness [6].
part of the Internet uses it. Thirdly, ingress filtering has its own
technical problems, e.g. with respect to site multi-homing, and these
problems are likely to limit its usefulness.
1.2 The Mobility Problem and the Mobile IPv6 Solution 1.2 The Mobility Problem and the Mobile IPv6 Solution
The Mobile IP design aims to solve two problems at the same time. The Mobile IP design aims to solve two problems at the same time.
Firstly, it allows transport layer sessions (TCP connections, Firstly, it allows transport layer sessions (TCP connections,
UDP-based transactions) to continue even if the underlying host(s) UDP-based transactions) to continue even if the underlying host(s)
move and change their IP addresses. Secondly, it allows a node to be move and change their IP addresses. Secondly, it allows a node to be
reached through a static IP address, a home address (HoA). reached through a static IP address, a home address (HoA).
The latter design choice can also be stated in other words: Mobile The latter design choice can also be stated in other words: Mobile
IPv6 aims to preserve the identifier nature of IP addresses. That is, IPv6 aims to preserve the identifier nature of IP addresses. That
Mobile IPv6 takes the view that IP addresses can be used as natural is, Mobile IPv6 takes the view that IP addresses can be used as
identifiers of nodes, as they have been used since the beginning of natural identifiers of nodes, as they have been used since the
the Internet. This must be contrasted to proposed and existing beginning of the Internet. This must be contrasted to proposed and
alternative designs where the identifier and locator natures of the existing alternative designs where the identifier and locator natures
IP addresses have been separated (see Section 1.4) of the IP addresses have been separated (see Section 1.4)
The basic idea in Mobile IP is to allow a home agent (HA) to work as The basic idea in Mobile IP is to allow a home agent (HA) to work as
a stationary proxy for a mobile node (MN). Whenever the mobile node a stationary proxy for a mobile node (MN). Whenever the mobile node
is away from its home network, the home agent intercepts packets is away from its home network, the home agent intercepts packets
destined to the node, and forwards the packets by tunneling them to destined to the node, and forwards the packets by tunneling them to
the node's current address, the care-of-address (CoA). The transport the node's current address, the care-of-address (CoA). The transport
layer (e.g., TCP, UDP) uses the home address as a stationary layer (e.g., TCP, UDP) uses the home address as a stationary
identifier for the mobile node. Figure 1 illustrates this basic identifier for the mobile node. Figure 1 illustrates this basic
arrangement. arrangement.
skipping to change at page 7, line 46 skipping to change at page 8, line 18
The basic solution requires tunneling through the home agent, thereby The basic solution requires tunneling through the home agent, thereby
leading to longer paths and degraded performance. This tunneling is leading to longer paths and degraded performance. This tunneling is
sometimes called triangular routing since it was originally planned sometimes called triangular routing since it was originally planned
that the packets from the mobile node to its peer could still that the packets from the mobile node to its peer could still
traverse directly, bypassing the home agent. traverse directly, bypassing the home agent.
To alleviate the performance penalty, Mobile IPv6 includes a mode of To alleviate the performance penalty, Mobile IPv6 includes a mode of
operation that allows the mobile node and its peer, a correspondent operation that allows the mobile node and its peer, a correspondent
node (CN), to exchange packets directly, bypassing the home agent node (CN), to exchange packets directly, bypassing the home agent
completely after the initial setup phase. This mode of operation is completely after the initial setup phase. This mode of operation is
called route optimization (RO). When route optimization is used, the called route optimization (RO). When route optimization is used,
mobile node sends its current care-of-address to the correspondent the mobile node sends its current care-of-address to the
node using binding update (BU) messages. The correspondent node correspondent node using binding update (BU) messages. The
stores the binding between the home address and care-of address into correspondent node stores the binding between the home address and
its Binding Cache. care-of address into its Binding Cache.
Whenever MIPv6 route optimization is used, the correspondent node Whenever MIPv6 route optimization is used, the correspondent node
effectively functions in two roles. Firstly, it is the source of the effectively functions in two roles. Firstly, it is the source of the
packets it sends, as usual. Secondly, it acts as the first router for packets it sends, as usual. Secondly, it acts as the first router
the packets, effectively performing source routing. That is, when the for the packets, effectively performing source routing. That is,
correspondent node is sending out packets, it consults its MIPv6 when the correspondent node is sending out packets, it consults its
route optimization data structures, and reroutes the packets if MIPv6 route optimization data structures, and reroutes the packets if
necessary. A Binding Cache Entry (BCE) contains the home address and necessary. A Binding Cache Entry (BCE) contains the home address and
the care-of-address of the mobile node, and records the fact that the care-of-address of the mobile node, and records the fact that
packets destined to the home address should now be sent to the packets destined to the home address should now be sent to the
destination address. Thus, it represents a local routing exception. destination address. Thus, it represents a local routing exception.
The packets leaving the correspondent node are source routed to the The packets leaving the correspondent node are source routed to the
care-of-address. Each packet includes a routing header that contains care-of-address. Each packet includes a routing header that contains
the home address of the mobile node. Thus, logically, the packet is the home address of the mobile node. Thus, logically, the packet is
first routed to the care-of-address, and then virtually from the first routed to the care-of-address, and then virtually from the
care-of-address to the home address. In practise, of course, the care-of-address to the home address. In practice, of course, the
packet is consumed by the mobile node at the care-of-address, and the packet is consumed by the mobile node at the care-of-address, and the
header just allows the mobile node to select a socket associated with header just allows the mobile node to select a socket associated with
the home address instead of one with the care-of-address. However, the home address instead of one with the care-of-address. However,
the mechanism resembles source routing since there is routing state the mechanism resembles source routing since there is routing state
involved at the correspondent node, and a routing header is used. involved at the correspondent node, and a routing header is used.
Nevertheless, this routing header is special (type 2) to avoid the Nevertheless, this routing header is special (type 2) to avoid the
risks associated with using the more general (type 0) variant. risks associated with using the more general (type 0) variant.
1.3 Design Principles and Goals 1.3 Design Principles and Goals
The MIPv6 design and security design aimed to follow the end-to-end The MIPv6 design and security design aimed to follow the end-to-end
principle, to duly notice the differences in trust relationships principle, to duly notice the differences in trust relationships
between the nodes, and to establish an explicit goal in the provided between the nodes, and to establish an explicit goal in the provided
level of protection. level of protection.
1.3.1 End-to-end principle 1.3.1 End-to-end principle
Perhaps the leading design principle for Internet protocols is the so Perhaps the leading design principle for Internet protocols is the so
called end-to-end principle [2][3]. According to this principle, it called end-to-end principle [4][9]. According to this principle, it
is beneficial to avoid polluting the network with state, and to limit is beneficial to avoid polluting the network with state, and to limit
new state creation to the involved end nodes. new state creation to the involved end nodes.
In the case of Mobile IPv6, the end-to-end principle is applied by In the case of Mobile IPv6, the end-to-end principle is applied by
restricting mobility related state primarily to the home agent. restricting mobility related state primarily to the home agent.
Additionally, if route optimization is used, the correspondent nodes Additionally, if route optimization is used, the correspondent nodes
also maintain a soft state about the mobile nodes' current also maintain a soft state about the mobile nodes' current
care-of-addresses, the Binding Cache. This can be contrasted to an care-of-addresses, the Binding Cache. This can be contrasted to an
approach that would use individual host routes within the basic approach that would use individual host routes within the basic
routing system. Such an approach would create state on a huge number routing system. Such an approach would create state on a huge number
of routers around the network. In Mobile IPv6, only the home agent of routers around the network. In Mobile IPv6, only the home agent
and the communicating nodes need to create state. and the communicating nodes need to create state.
1.3.2 Trust assumptions 1.3.2 Trust assumptions
In the Mobile IPv6 security design, different approaches were chosen In the Mobile IPv6 security design, different approaches were chosen
for securing the communication between the mobile node and its home for securing the communication between the mobile node and its home
agent and between the mobile node and its correspondent nodes. In the agent and between the mobile node and its correspondent nodes. In
home agent case it was assumed that the mobile node and the home the home agent case it was assumed that the mobile node and the home
agent know each other through a prior arrangement, e.g., due to a agent know each other through a prior arrangement, e.g., due to a
business relationships. In contrast, it was strictly assumed that the business relationships. In contrast, it was strictly assumed that
mobile node and the correspondent node do not need to have any prior the mobile node and the correspondent node do not need to have any
arrangement, thereby allowing Mobile IPv6 to function in a scalable prior arrangement, thereby allowing Mobile IPv6 to function in a
manner, without requiring any configuration at the correspondent scalable manner, without requiring any configuration at the
nodes. correspondent nodes.
1.3.3 Protection level 1.3.3 Protection level
As a security goal, Mobile IPv6 design aimed to be "as secure as the As a security goal, Mobile IPv6 design aimed to be "as secure as the
(non-mobile) IPv4 Internet" was at the time of the design, in the (non-mobile) IPv4 Internet" was at the time of the design, in the
period 2001-2002. In particular, that means that there is little period 2001-2002. In particular, that means that there is little
protection against attackers that are able to attach themselves protection against attackers that are able to attach themselves
between a correspondent node and a home agent. The rational is between a correspondent node and a home agent. The rational is
simple: in the 2001 Internet, if a node was able to attach itself to simple: in the 2001 Internet, if a node was able to attach itself to
the communication path between two arbitrary nodes, it was able to the communication path between two arbitrary nodes, it was able to
skipping to change at page 9, line 44 skipping to change at page 10, line 14
flow of bogus data) to a third party. flow of bogus data) to a third party.
1.4 About Mobile IPv6 Mobility and its Variations 1.4 About Mobile IPv6 Mobility and its Variations
Taking a more abstract angle, IPv6 mobility can be defined as a Taking a more abstract angle, IPv6 mobility can be defined as a
mechanism for managing local exceptions to routing information in mechanism for managing local exceptions to routing information in
order to direct packets that are sent to one address (the home order to direct packets that are sent to one address (the home
address) to another address (the care-of-address). It is managing in address) to another address (the care-of-address). It is managing in
the sense that the local routing exceptions (source routes) are the sense that the local routing exceptions (source routes) are
created and deleted dynamically, based on the instructions sent by created and deleted dynamically, based on the instructions sent by
the mobile node. It is local in the sense that the routing exceptions the mobile node. It is local in the sense that the routing
are valid only at the home agent, and in the correspondent nodes if exceptions are valid only at the home agent, and in the correspondent
route optimization is used. The created pieces of state are nodes if route optimization is used. The created pieces of state are
exceptions in the sense that they override the normal topological exceptions in the sense that they override the normal topological
routing information carried collectively by the routers. routing information carried collectively by the routers.
Using the terminology introduced by J. Noel Chiappa [6], we can say Using the terminology introduced by J. Noel Chiappa [12], we can say
that the home address functions in the dual role of being an that the home address functions in the dual role of being an
end-point identifier (EID) and a permanent locator. The end-point identifier (EID) and a permanent locator. The
care-of-address is a pure, temporary locator, which identifies the care-of-address is a pure, temporary locator, which identifies the
current location of the mobile node. The correspondent nodes current location of the mobile node. The correspondent nodes
effectively perform source routing, redirecting traffic destined to effectively perform source routing, redirecting traffic destined to
the home address to the care-of-address. This is even reflected in the home address to the care-of-address. This is even reflected in
the packet structure: the packets carry an explicit routing header. the packet structure: the packets carry an explicit routing header.
The relationshiop between EID's and permanent locators has been The relationshiop between EID's and permanent locators has been
exploited by other proposals. Their technical merits and security exploited by other proposals. Their technical merits and security
problems, however, are beyond the scope of this document. problems, however, are beyond the scope of this document.
2. Dimensions of Danger 2. Dimensions of Danger
Based on the discussion above it should now be clear that the dangers Based on the discussion above it should now be clear that the dangers
in Mobile IPv6 lie in creation (or deletion) of the local routing in Mobile IPv6 lie in creation (or deletion) of the local routing
exceptions. In Mobile IPv6 terms, the danger is in the possibility of exceptions. In Mobile IPv6 terms, the danger is in the possibility
unauthorized creation of Binding Cache Entries (BCE). The effects of of unauthorized creation of Binding Cache Entries (BCE). The effects
an attack differ depending on the target of the attack, the timing of of an attack differ depending on the target of the attack, the timing
the attack, and the location of the attacker. of the attack, and the location of the attacker.
2.1 Target 2.1 Target
Basically, the target of an attack can be any node or network in the Basically, the target of an attack can be any node or network in the
Internet (stationary or mobile). The basic differences lie in the Internet (stationary or mobile). The basic differences lie in the
goals of the attack: does the attacker aim to divert (steal) the goals of the attack: does the attacker aim to divert (steal) the
traffic destined to and/or sourced at the target node, or does it aim traffic destined to and/or sourced at the target node, or does it aim
to cause denial-of-service to the target node or network. The target to cause denial-of-service to the target node or network. The target
does not typically play much of an active role attack. As an example, does not typically play much of an active role attack. As an
an attacker may launch a denial-of-service attack on a given node A example, an attacker may launch a denial-of-service attack on a given
by contacting a large number of nodes, claiming to be A, and node A by contacting a large number of nodes, claiming to be A, and
subsequently diverting the traffic at these other nodes so that A is subsequently diverting the traffic at these other nodes so that A is
harmed by no longer being able to receive packets from those nodes. A harmed by no longer being able to receive packets from those nodes.
itself need not be involved at all before its communications start to A itself need not be involved at all before its communications start
break. Furthermore, A is not necessarily a mobile node; it may very to break. Furthermore, A is not necessarily a mobile node; it may
well be stationary. very well be stationary.
Mobile IPv6 uses the same class of IP addresses for both mobile nodes Mobile IPv6 uses the same class of IP addresses for both mobile nodes
(i.e., home and care-of addresses) and stationary nodes. That is, (i.e., home and care-of addresses) and stationary nodes. That is,
mobile and stationary addresses are indistinguishable from each mobile and stationary addresses are indistinguishable from each
other. Attackers can take advantage of this by taking any IP address other. Attackers can take advantage of this by taking any IP address
and using it in a context where normally only mobile (home or care-of and using it in a context where normally only mobile (home or care-of
addresses) appear. This means that attacks that otherwise would only addresses) appear. This means that attacks that otherwise would only
concern mobiles are, in fact, a threat to all IPv6 nodes. concern mobiles are, in fact, a threat to all IPv6 nodes.
In fact, the role of being a mobile node appears to be most In fact, the role of being a mobile node appears to be most
skipping to change at page 12, line 8 skipping to change at page 12, line 8
something similar. On the other hand, since it is possible to attack something similar. On the other hand, since it is possible to attack
a node indirectly by first targetting its peers, all nodes are a node indirectly by first targetting its peers, all nodes are
equally vulnerable in some sense. Furthermore, a (usually) mobile equally vulnerable in some sense. Furthermore, a (usually) mobile
node often also plays the role of being a correspondent node, since node often also plays the role of being a correspondent node, since
it can exchange packets with other mobile nodes (see also Section it can exchange packets with other mobile nodes (see also Section
5.4). 5.4).
2.2 Timing 2.2 Timing
An important aspect in understanding Mobile IPv6 related dangers is An important aspect in understanding Mobile IPv6 related dangers is
timing. In a stationary IPv4 network, an attacker must be between the timing. In a stationary IPv4 network, an attacker must be between
communication nodes at the same time as the nodes communicate. With the communication nodes at the same time as the nodes communicate.
the Mobile IPv6 ability of creating binding cache entries, the With the Mobile IPv6 ability of creating binding cache entries, the
situation changes. A new danger is created. Without proper situation changes. A new danger is created. Without proper
protection, an attacker could attach itself between the home agent protection, an attacker could attach itself between the home agent
and a correspondent node for a while, create a BCE at the and a correspondent node for a while, create a BCE at the
correspondent node, leave the position, and continuously update the correspondent node, leave the position, and continuously update the
correspondent node about the mobile node's whereabouts. This would correspondent node about the mobile node's whereabouts. This would
make the correspondent node send packets destined to the mobile node make the correspondent node send packets destined to the mobile node
to an incorrect address as long as the BCE remained valid, i.e., to an incorrect address as long as the BCE remained valid, i.e.,
typically until the correspondent node is rebooted. The converse typically until the correspondent node is rebooted. The converse
would also be possible: an attacker could also launch an attack by would also be possible: an attacker could also launch an attack by
first creating a BCE and then letting it expire at a carefully first creating a BCE and then letting it expire at a carefully
skipping to change at page 12, line 35 skipping to change at page 12, line 35
2.3 Location 2.3 Location
In a static IPv4 Internet, an attacker can only receive packets In a static IPv4 Internet, an attacker can only receive packets
destined to a given address if it is able to attach itself to or destined to a given address if it is able to attach itself to or
control a node on the topological path between the sender and the control a node on the topological path between the sender and the
recipient. On the other hand, an attacker can easily send spoofed recipient. On the other hand, an attacker can easily send spoofed
packets from almost anywhere. If Mobile IPv6 allowed sending packets from almost anywhere. If Mobile IPv6 allowed sending
unprotected Binding Updates, an attacker could create a BCE on any unprotected Binding Updates, an attacker could create a BCE on any
correspondent node from anywhere in the Internet, simply by sending a correspondent node from anywhere in the Internet, simply by sending a
fraudulent Binding Update to the correspondent node. Instead of being fraudulent Binding Update to the correspondent node. Instead of
required to be between the two target nodes, the attacker could act being required to be between the two target nodes, the attacker could
from anywhere in the Internet. act from anywhere in the Internet.
In summary, by introducing the new routing exception (binding cache) In summary, by introducing the new routing exception (binding cache)
at the correspondent nodes, Mobile IPv6 introduces the dangers of at the correspondent nodes, Mobile IPv6 introduces the dangers of
time and space shifting. Without proper protection, Mobile IPv6 would time and space shifting. Without proper protection, Mobile IPv6
allow an attacker to act from anywhere in the Internet and well would allow an attacker to act from anywhere in the Internet and well
before the time of the actual attack. In contrast, in the static IPv4 before the time of the actual attack. In contrast, in the static
Internet the attacking nodes must be present at the time of the IPv4 Internet the attacking nodes must be present at the time of the
attack and they must be positioned in a suitable way, or the attack attack and they must be positioned in a suitable way, or the attack
would not be possible in the first place. would not be possible in the first place.
3. Threats and limitations 3. Threats and limitations
This section describes attacks against Mobile IPv6 Route Optimization This section describes attacks against Mobile IPv6 Route Optimization
and related protection mechanisms. The goal of the attacker can be to and related protection mechanisms. The goal of the attacker can be
corrupt the correspondent node's binding cache and to cause packets to corrupt the correspondent node's binding cache and to cause
to be delivered to a wrong address. This can compromise secrecy and packets to be delivered to a wrong address. This can compromise
integrity of communication and cause denial-of-service (DoS) both at secrecy and integrity of communication and cause denial-of-service
the communicating parties and at the address that receives the (DoS) both at the communicating parties and at the address that
unwanted packets. The attacker may also exploit features of the receives the unwanted packets. The attacker may also exploit
Binding Update (BU) mechanism to exhaust the resources of the mobile features of the Binding Update (BU) mechanism to exhaust the
node, the home agent, or the correspondent nodes. The aim of this resources of the mobile node, the home agent, or the correspondent
section is to describe the major attacks and to overview various nodes. The aim of this section is to describe the major attacks and
protocol mechanisms and their limitations. The details of the to overview various protocol mechanisms and their limitations. The
mechanisms are covered in Section 4. details of the mechanisms are covered in Section 4.
It is essential to understand that some of the threats are more It is essential to understand that some of the threats are more
serious than others, some can be mitigated but not removed, some serious than others, some can be mitigated but not removed, some
threats may represent acceptable risk, and some threats may be threats may represent acceptable risk, and some threats may be
considered too expensive to be prevented. considered too expensive to be prevented.
We consider only active attackers. The rationale behind this is that We consider only active attackers. The rationale behind this is that
in order to corrupt the binding cache, the attacker must sooner or in order to corrupt the binding cache, the attacker must sooner or
later send one or more messages. Thus, it makes little sense to later send one or more messages. Thus, it makes little sense to
consider attackers that only observe messages but do not send any. In consider attackers that only observe messages but do not send any.
fact, some active attacks are easier, for the average attacker, to In fact, some active attacks are easier, for the average attacker, to
launch than a passive one would be. That is, in many active attacks launch than a passive one would be. That is, in many active attacks
the attacker can initiate binding update processing at any time, the attacker can initiate binding update processing at any time,
while most passive attacks require the attacker to wait for suitable while most passive attacks require the attacker to wait for suitable
messages to be sent by the targets nodes. messages to be sent by the targets nodes.
Nevertheless, an important class of passive attacks remains, namely,
attacks on privacy. It is well known that by simply examining
packets, eavesdroppers can track the movements of individual nodes
(and potentially, users) [3] Mobile IPv6 exacerbates the problem by
adding more potentially sensitive information into the packets (e.g.,
Binding Updates, routing headers or home address options). This
document does not address these attacks.
We first consider attacks against nodes that are supposed to have a We first consider attacks against nodes that are supposed to have a
specified address (Section 3.1), continuing with flooding attacks specified address (Section 3.1), continuing with flooding attacks
(Section 3.2) and attacks against the basic Binding Update protocol (Section 3.2) and attacks against the basic Binding Update protocol
(Section 3.3). After that we present a classification of the attacks (Section 3.3). After that we present a classification of the attacks
(Section 3.4). Finally, we considering the applicability of solutions (Section 3.4). Finally, we considering the applicability of
relying on some kind of a global security infrastructure (Section solutions relying on some kind of a global security infrastructure
3.5). (Section 3.5).
3.1 Attacks against address 'owners' aka. address 'stealing' 3.1 Attacks against address 'owners' aka. address 'stealing'
The most obvious danger in Mobile IPv6 is address "stealing", i.e., The most obvious danger in Mobile IPv6 is address "stealing", i.e.,
an attacker illegitimately claiming to be a given node at a given an attacker illegitimately claiming to be a given node at a given
address, and then trying to "steal" traffic destined to that address. address, and then trying to "steal" traffic destined to that address.
There are several variants of this attack. We first describe the There are several variants of this attack. We first describe the
basic variant, followed by a description how the situation is basic variant, followed by a description how the situation is
affected if the target is a stationary node, and continuing more affected if the target is a stationary node, and continuing more
complicated issues related to timing (the so called "future" complicated issues related to timing (the so called "future"
attacks), confidentiality and integrity, and DoS aspects. attacks), confidentiality and integrity, and DoS aspects.
3.1.1 Basic address stealing 3.1.1 Basic address stealing
If Binding Updates were not authenticated at all, an attacker could If Binding Updates were not authenticated at all, an attacker could
fabricate and send spoofed binding updates from anywhere in the fabricate and send spoofed binding updates from anywhere in the
Internet. All nodes that support the correspondent node functionality Internet. All nodes that support the correspondent node
would become unwitting accomplices to this attack. As explained in functionality would become unwitting accomplices to this attack. As
Section 2.1, there is no way of telling which addresses belong to explained in Section 2.1, there is no way of telling which addresses
mobile nodes that really could send binding updates and which belong to mobile nodes that really could send binding updates and
addresses belong to stationary nodes (see below), so potentially any which addresses belong to stationary nodes (see below), so
node (including "static" nodes) are vulnerable. potentially any node (including "static" nodes) are vulnerable.
+---+ original +---+ new packet +---+ +---+ original +---+ new packet +---+
| B |<----------------| A |- - - - - - ->| C | | B |<----------------| A |- - - - - - ->| C |
+---+ packet flow +---+ flow +---+ +---+ packet flow +---+ flow +---+
^ ^
| |
| False BU: B -> C | False BU: B -> C
| |
+----------+ +----------+
| Attacker | | Attacker |
skipping to change at page 14, line 38 skipping to change at page 14, line 49
Consider an IP node A sending IP packets to another IP node B. The Consider an IP node A sending IP packets to another IP node B. The
attacker could redirect the packets to an arbitrary address C by attacker could redirect the packets to an arbitrary address C by
sending a Binding Update to A. The home address (HoA) in the binding sending a Binding Update to A. The home address (HoA) in the binding
update would be B and the care-of address (CoA) would be C. After update would be B and the care-of address (CoA) would be C. After
receiving this binding update, A would send all packets intended for receiving this binding update, A would send all packets intended for
the node B to the address C. See Figure 2. the node B to the address C. See Figure 2.
The attacker might select the care-of address to be either its own The attacker might select the care-of address to be either its own
current address, another address in its local network, or any other current address, another address in its local network, or any other
IP address. If the attacker selected a local care-of address allowing IP address. If the attacker selected a local care-of address
it to receive the packets, it would be able to send replies to the allowing it to receive the packets, it would be able to send replies
correspondent node. Ingress filtering at the attacker's local network to the correspondent node. Ingress filtering at the attacker's local
does not prevent the spoofing of Binding Updates but forces the network does not prevent the spoofing of Binding Updates but forces
attacker either to choose a care-of address from inside its own the attacker either to choose a care-of address from inside its own
network or to use the Alternate care-of address sub-option. network or to use the Alternate care-of address sub-option.
The binding update authorization mechanism used in the MIPv6 security The binding update authorization mechanism used in the MIPv6 security
design is primarily intended to mitigate this threat, and to limit design is primarily intended to mitigate this threat, and to limit
the location of attackers to the path between a correspondent node the location of attackers to the path between a correspondent node
and the home agent. and the home agent.
3.1.2 Stealing addresses of stationary nodes 3.1.2 Stealing addresses of stationary nodes
The attacker needs to know or guess the IP addresses of both the The attacker needs to know or guess the IP addresses of both the
source of the packets to be diverted (A in the example above) and the source of the packets to be diverted (A in the example above) and the
destination of the packets (B). This means that it is difficult to destination of the packets (B). This means that it is difficult to
redirect all packets to or from a specific node because the attacker redirect all packets to or from a specific node because the attacker
would need to know the IP addresses of all the nodes with which it is would need to know the IP addresses of all the nodes with which it is
communicating. communicating.
Nodes with well-known addresses, such as servers and those using Nodes with well-known addresses, such as servers and those using
stateful configuration, are most vulnerable. Nodes that are a part of stateful configuration, are most vulnerable. Nodes that are a part
the network infrastructure, such as DNS servers, are particularly of the network infrastructure, such as DNS servers, are particularly
interesting targets for attackers, and particularly easy to identify. interesting targets for attackers, and particularly easy to identify.
Nodes that frequently change their address and use random addresses Nodes that frequently change their address and use random addresses
are relatively safe. However, if they register their address into are relatively safe. However, if they register their address into
Dynamic DNS, they become more exposed. Similarly, nodes that visit Dynamic DNS, they become more exposed. Similarly, nodes that visit
publicly accessible networks such as airport wireless LANs risk publicly accessible networks such as airport wireless LANs risk
revealing their addresses. IPv6 addressing privacy features [ND01] revealing their addresses. IPv6 addressing privacy features [3]
mitigate these risks to an extent but it should be noted that mitigate these risks to an extent but it should be noted that
addresses cannot be completely recycled while there are still open addresses cannot be completely recycled while there are still open
sessions that use those addresses. sessions that use those addresses.
Thus, it is not the mobile nodes that are most vulnerable to address Thus, it is not the mobile nodes that are most vulnerable to address
stealing attacks, it is the well known static servers. Furthermore, stealing attacks, it is the well known static servers. Furthermore,
the servers often run old or heavily optimized operating systems, and the servers often run old or heavily optimized operating systems, and
may not have any mobility related code at all. Thus, the security may not have any mobility related code at all. Thus, the security
design cannot be based on the idea that mobile nodes might somehow be design cannot be based on the idea that mobile nodes might somehow be
able to detect if someone has stolen their address, and reset the able to detect if someone has stolen their address, and reset the
skipping to change at page 15, line 45 skipping to change at page 16, line 5
make reasonable measures to prevent the creation of fraudulent make reasonable measures to prevent the creation of fraudulent
binding cache entries in the first place. binding cache entries in the first place.
3.1.3 Future address stealing 3.1.3 Future address stealing
If an attacker knows an address that a node is likely to select in If an attacker knows an address that a node is likely to select in
the future, it can launch a "future" address stealing attack. The the future, it can launch a "future" address stealing attack. The
attacker creates a Binding Cache Entry using the home address that it attacker creates a Binding Cache Entry using the home address that it
anticipates the target node will use. If the Home Agent allows anticipates the target node will use. If the Home Agent allows
dynamic home addresses, the attacker may be able to do this dynamic home addresses, the attacker may be able to do this
legitimately. That is, if the attacker is a client of the Home Agent, legitimately. That is, if the attacker is a client of the Home
and able to acquire the home address temporarily, it may be able to Agent, and able to acquire the home address temporarily, it may be
do so, and then return the home address back to the Home Agent once able to do so, and then return the home address back to the Home
the BCE is in place. Agent once the BCE is in place.
Now, if the BCE state had a long expiration time, the target node Now, if the BCE state had a long expiration time, the target node
would acquire the same home address while the BCE is still effective, would acquire the same home address while the BCE is still effective,
and the attacker would be able to launch a successful and the attacker would be able to launch a successful
man-in-the-middle or denial-of-service attack. The mechanism applied man-in-the-middle or denial-of-service attack. The mechanism applied
in the MIPv6 security design is to limit the lifetime of Binding in the MIPv6 security design is to limit the lifetime of Binding
Cache Entries to a few minutes. Cache Entries to a few minutes.
Note that this attack applies only to fairly specific conditions. Note that this attack applies only to fairly specific conditions.
There are also some variations of this attack that are theoretically There are also some variations of this attack that are theoretically
skipping to change at page 17, line 47 skipping to change at page 18, line 6
In a related attack, the attacker blocks binding updates from the In a related attack, the attacker blocks binding updates from the
mobile at its new location, e.g., by jamming the radio link or by mobile at its new location, e.g., by jamming the radio link or by
mounting a flooding attack, and takes over its connections at the old mounting a flooding attack, and takes over its connections at the old
location. The attacker will be able to capture the packets sent to location. The attacker will be able to capture the packets sent to
the mobile and to impersonate the mobile until the correspondent's the mobile and to impersonate the mobile until the correspondent's
Binding Cache entry expires. Binding Cache entry expires.
Both of the above attacks require the attacker to be on the same Both of the above attacks require the attacker to be on the same
local network with the mobile, where it can relatively easily observe local network with the mobile, where it can relatively easily observe
packets and block them even if the mobile does not move to a new packets and block them even if the mobile does not move to a new
location. Therefore, we believe that these attacks are not as serious location. Therefore, we believe that these attacks are not as
as ones that can be mounted from remote locations. The limited serious as ones that can be mounted from remote locations. The
lifetime of the Binding Cache entry and the associated nonces limit limited lifetime of the Binding Cache entry and the associated nonces
the time frame within which the replay attacks are possible. limit the time frame within which the replay attacks are possible.
3.2 Attacks against other nodes and networks (flooding) 3.2 Attacks against other nodes and networks (flooding)
By sending spoofed binding updates, an attacker could redirect By sending spoofed binding updates, an attacker could redirect
traffic to an arbitrary IP address. This could be used to bomb an traffic to an arbitrary IP address. This could be used to bomb an
arbitrary Internet address with excessive amounts of packets. The arbitrary Internet address with excessive amounts of packets. The
attacker could also target a network by redirecting data to one or attacker could also target a network by redirecting data to one or
more IP addresses within the network. There are two main variations more IP addresses within the network. There are two main variations
of flooding: basic flooding and return-to-the-home flooding. We of flooding: basic flooding and return-to-the-home flooding. We
consider them separately. consider them separately.
skipping to change at page 18, line 34 skipping to change at page 18, line 40
+---+ original +---+ flooding packet +---+ +---+ original +---+ flooding packet +---+
| B |<================| A |==================>| C | | B |<================| A |==================>| C |
+---+ packet flow +---+ flow +---+ +---+ packet flow +---+ flow +---+
| ^ | ^
\ / \ /
\__________________/ \__________________/
False binding update + false acknowledgements False binding update + false acknowledgements
Figure 4 Figure 4
A more sophisticated attacker would act itself as B; see Figure 4. It A more sophisticated attacker would act itself as B; see Figure 4.
would first subscribe to a data stream (e.g. a video stream) and then It would first subscribe to a data stream (e.g. a video stream) and
redirects this stream to the target address C. The attacker would then redirects this stream to the target address C. The attacker
even be able to spoof the acknowledgements. For example, consider a would even be able to spoof the acknowledgements. For example,
TCP stream. The attacker would perform the TCP handshake itself and consider a TCP stream. The attacker would perform the TCP handshake
thus know the initial sequence numbers. After redirecting the data to itself and thus know the initial sequence numbers. After redirecting
C, the attacker would continue to send spoofed acknowledgments. It the data to C, the attacker would continue to send spoofed
would even be able to accelerate the data rate by simulating a fatter acknowledgments. It would even be able to accelerate the data rate
pipe [4]. by simulating a fatter pipe [10].
This attack might be even easier with UDP/RTP. The attacker could This attack might be even easier with UDP/RTP. The attacker could
create spoofed RTCP acknowledgements. Either way, the attacker would create spoofed RTCP acknowledgements. Either way, the attacker would
be able to redirect an increasing stream of unwanted data to the be able to redirect an increasing stream of unwanted data to the
target address without doing much work itself. It could carry on target address without doing much work itself. It could carry on
opening more streams and refreshing the Binding Cache entries by opening more streams and refreshing the Binding Cache entries by
sending a new binding update every few minutes. Thus, the limitation sending a new binding update every few minutes. Thus, the limitation
of BCE lifetime to a few minutes does not help here alone. of BCE lifetime to a few minutes does not help here alone.
During the Mobile IPv6 design process, the effectiveness of this During the Mobile IPv6 design process, the effectiveness of this
skipping to change at page 19, line 17 skipping to change at page 19, line 25
would send a TCP Reset to the source of the unwanted data stream, would send a TCP Reset to the source of the unwanted data stream,
which would then stop sending. In reality, all practical TCP/IP which would then stop sending. In reality, all practical TCP/IP
implementations fail to send the Reset. The target node drops the implementations fail to send the Reset. The target node drops the
unwanted packets at the IP layer because it does not have a Binding unwanted packets at the IP layer because it does not have a Binding
Update List entry corresponding to the Routing Header on the incoming Update List entry corresponding to the Routing Header on the incoming
packet. Thus, the flooding data is never processed at the TCP layer packet. Thus, the flooding data is never processed at the TCP layer
of the target node and no Reset is sent. This means that the attack of the target node and no Reset is sent. This means that the attack
using TCP streams is more effective than was originally believed. using TCP streams is more effective than was originally believed.
This attack is serious because the target can be any node or network, This attack is serious because the target can be any node or network,
not only a mobile one. What makes it particularly serious compared to not only a mobile one. What makes it particularly serious compared
the other attacks is that the target itself cannot do anything to to the other attacks is that the target itself cannot do anything to
prevent the attack. For example, it does not help if the target prevent the attack. For example, it does not help if the target
network stops using Route Optimization. The damage is the worst if network stops using Route Optimization. The damage is the worst if
these techniques are used to amplify the effect of other distributed these techniques are used to amplify the effect of other distributed
denial of service (DDoS) attacks. Ingress filtering in the attacker's denial of service (DDoS) attacks. Ingress filtering in the
local network prevents the spoofing of source addresses but the attacker's local network prevents the spoofing of source addresses
attack would still be possible by setting the Alternate care-of but the attack would still be possible by setting the Alternate
address sub-option to the target address. care-of address sub-option to the target address.
Again, the protection mechanism adopted for MIPv6 is return Again, the protection mechanism adopted for MIPv6 is return
routability. This time it is necessary to check that there is indeed routability. This time it is necessary to check that there is indeed
a node at the new care-of-address, and that the node is the one that a node at the new care-of-address, and that the node is the one that
requested redirecting packets to that very address (see Section requested redirecting packets to that very address (see Section
4.1.2). 4.1.2).
3.2.2 Return-to-home flooding 3.2.2 Return-to-home flooding
A variation of the bombing attack targets the home address or the A variation of the bombing attack targets the home address or the
home network instead of the care-of-address or a visited network. The home network instead of the care-of-address or a visited network.
attacker would claim to be a mobile with the home address equal to The attacker would claim to be a mobile with the home address equal
the target address. While claiming to be away from home, the attacker to the target address. While claiming to be away from home, the
would start downloading a data stream. The attacker would then send a attacker would start downloading a data stream. The attacker would
binding update cancellation (i.e. a request to delete the binding then send a binding update cancellation (i.e. a request to delete
from the Binding Cache), or just allow the cache entry to expire. the binding from the Binding Cache), or just allow the cache entry to
Either would redirect the data stream to the home network. Just like expire. Either would redirect the data stream to the home network.
when bombing a care-of-address, the attacker can keep the stream Just like when bombing a care-of-address, the attacker can keep the
alive and even increase data rate by spoofing acknowledgments. When stream alive and even increase data rate by spoofing acknowledgments.
successful, the bombing attack against the home network is just as
serious as the one against a care-of-address. When successful, the bombing attack against the home network is just
as serious as the one against a care-of-address.
The basic protection mechanism adopted is return routability. The basic protection mechanism adopted is return routability.
However, it is hard to fully protect against this attack; see Section However, it is hard to fully protect against this attack; see Section
4.1.1. 4.1.1.
3.3 Attacks against binding update protocols 3.3 Attacks against binding update protocols
Security protocols that successfully protect the secrecy and Security protocols that successfully protect the secrecy and
integrity of data can sometimes make the participants more vulnerable integrity of data can sometimes make the participants more vulnerable
to denial-of-service attacks. In fact, the stronger the to denial-of-service attacks. In fact, the stronger the
skipping to change at page 20, line 33 skipping to change at page 20, line 40
binding update procedure may depend on several factors (including binding update procedure may depend on several factors (including
heuristics, cross layer information, configuration options, etc) and heuristics, cross layer information, configuration options, etc) and
is not specified by Mobile IPv6. Not initiating the binding update is not specified by Mobile IPv6. Not initiating the binding update
procedure automatically may alleviate these attacks, but will not, in procedure automatically may alleviate these attacks, but will not, in
general, avoid them completely. general, avoid them completely.
In a real attack the attacker would induce the mobile node to In a real attack the attacker would induce the mobile node to
initiate binding update protocols with a large number of initiate binding update protocols with a large number of
correspondent nodes at the same time. If the correspondent addresses correspondent nodes at the same time. If the correspondent addresses
are real addresses of existing IP nodes, then most instances of the are real addresses of existing IP nodes, then most instances of the
binding update protocol might even complete successfully. The entries binding update protocol might even complete successfully. The
created in the Binding Cache are correct but useless. This way, the entries created in the Binding Cache are correct but useless. This
attacker can induce the mobile to execute the binding update protocol way, the attacker can induce the mobile to execute the binding update
unnecessarily, which can drain the mobile's resources. protocol unnecessarily, which can drain the mobile's resources.
A correspondent node (i.e., any IP node) can also be attacked in a A correspondent node (i.e., any IP node) can also be attacked in a
similar way. The attacker sends spoofed IP packets to a large number similar way. The attacker sends spoofed IP packets to a large number
of mobiles with the target node's address as the source address. of mobiles with the target node's address as the source address.
These mobiles will initiate the binding update protocol with the These mobiles will initiate the binding update protocol with the
target node. Again, most of the binding update protocol executions target node. Again, most of the binding update protocol executions
will complete successfully. By inducing a large number of unnecessary will complete successfully. By inducing a large number of
binding updates, the attacker is able to consume the target node's unnecessary binding updates, the attacker is able to consume the
resources. target node's resources.
This attack is possible against any binding update authentication This attack is possible against any binding update authentication
protocol. The more resources the binding update protocol consumes, protocol. The more resources the binding update protocol consumes,
the more serious the attack. Hence, strong cryptographic the more serious the attack. Hence, strong cryptographic
authentication protocol is more vulnerable to the attack than a weak authentication protocol is more vulnerable to the attack than a weak
one or unauthenticated binding updates. Ingress filtering helps a one or unauthenticated binding updates. Ingress filtering helps a
little, since it makes it harder to forge the source address of the little, since it makes it harder to forge the source address of the
spoofed packets, but it does not completely eliminate this threat. spoofed packets, but it does not completely eliminate this threat.
A node should protect itself from the attack by setting a limit on A node should protect itself from the attack by setting a limit on
the amount of resources, i.e., processing time, memory, and the amount of resources, i.e., processing time, memory, and
communications bandwidth, which it uses for processing binding communications bandwidth, which it uses for processing binding
updates. When the limit is exceeded, the node can simply stop updates. When the limit is exceeded, the node can simply stop
attempting route optimization. Sometimes it is possible to process attempting route optimization. Sometimes it is possible to process
some binding updates even when a node is under the attack. A mobile some binding updates even when a node is under the attack. A mobile
node may have a local security policy listing a limited number of node may have a local security policy listing a limited number of
addresses to which binding updates will be sent even when the mobile addresses to which binding updates will be sent even when the mobile
node is under DoS attack. A correspondent node (i.e. any IP node) may node is under DoS attack. A correspondent node (i.e. any IP node)
similarly have a local security policy listing a limited set of may similarly have a local security policy listing a limited set of
addresses from which binding updates will be accepted even when the addresses from which binding updates will be accepted even when the
correspondent is under a binding update DoS attack. correspondent is under a binding update DoS attack.
The node may also recognize addresses with which they have had The node may also recognize addresses with which they have had
meaningful communication in the past and sent binding updates to or meaningful communication in the past and sent binding updates to or
accept them from those addresses. Since it may be impossible for the accept them from those addresses. Since it may be impossible for the
IP layer to know about the protocol state in higher protocol layers, IP layer to know about the protocol state in higher protocol layers,
a good measure of the meaningfulness of the past communication is a good measure of the meaningfulness of the past communication is
probably per-address packet counts. probably per-address packet counts. Alternatively, Neighbor
Discovery [2] (section 5.1, Conceptual Data Structures) defines the
Destination Cache as a set of entries about destinations to which
traffic has been sent recently. Thus, implementors may wish to use
the information in the Destination Cache.
Section 11.7.2 ("Correspondent Registration") in [7] does not specify Section 11.7.2 ("Correspondent Registration") in [7] does not specify
when such a route optimization procedure should be initiated. It does when such a route optimization procedure should be initiated. It
indicate when it may justifiable to do so, but these hints are not does indicate when it may justifiable to do so, but these hints are
enough. This remains an area where more work is needed. Obviously, not enough. This remains an area where more work is needed.
given that route optimization is optional, any node that finds the Obviously, given that route optimization is optional, any node that
processing load excessive or unjustified may simply turn it off finds the processing load excessive or unjustified may simply turn it
(either selectively or completely). off (either selectively or completely).
3.3.2 Forcing Non-Optimized Routing 3.3.2 Forcing Non-Optimized Routing
As a variant of the previous attack, the attacker can prevent a As a variant of the previous attack, the attacker can prevent a
correspondent node from using route optimization by filling its correspondent node from using route optimization by filling its
Binding Cache with unnecessary entries so that most entries for real Binding Cache with unnecessary entries so that most entries for real
mobiles are dropped. mobiles are dropped.
Any successful DoS attack against a mobile or a correspondent node Any successful DoS attack against a mobile or a correspondent node
can also prevent the processing of binding updates. We have can also prevent the processing of binding updates. We have
repeatedly suggested that the target of a DoS attack may respond by repeatedly suggested that the target of a DoS attack may respond by
stopping route optimization for all or some communication. Obviously, stopping route optimization for all or some communication.
an attacker can exploit this fallback mechanism and force the target Obviously, an attacker can exploit this fallback mechanism and force
to use the less efficient home agent based routing. The attacker only the target to use the less efficient home agent based routing. The
needs to mount a noticeable DoS attack against the mobile or attacker only needs to mount a noticeable DoS attack against the
correspondent, and the target will default to non-optimized routing. mobile or correspondent, and the target will default to non-optimized
routing.
The target node can mitigate the effects of the attack by reserving The target node can mitigate the effects of the attack by reserving
more space for the Binding Cache, by reverting to non-optimized more space for the Binding Cache, by reverting to non-optimized
routing only when it cannot otherwise cope with the DoS attack, by routing only when it cannot otherwise cope with the DoS attack, by
trying aggressively to return to optimized routing, or by favoring trying aggressively to return to optimized routing, or by favoring
mobiles with which it has an established relationship. This attack is mobiles with which it has an established relationship. This attack
not as serious as the ones described earlier, but applications that is not as serious as the ones described earlier, but applications
rely on Route Optimization could still be affected. For instance, that rely on Route Optimization could still be affected. For
conversational multimedia sessions can suffer drastically from the instance, conversational multimedia sessions can suffer drastically
additional delays caused by triangle routing. from the additional delays caused by triangle routing.
3.3.3 Reflection and Amplification 3.3.3 Reflection and Amplification
Attackers sometimes try to hide the source of a packet flooding Attackers sometimes try to hide the source of a packet flooding
attack by reflecting the traffic from other nodes [Sav02]. That is, attack by reflecting the traffic from other nodes [1]. That is,
instead of sending the flood of packets directly to the target, the instead of sending the flood of packets directly to the target, the
attacker sends data to other nodes, tricking them to send the same attacker sends data to other nodes, tricking them to send the same
number, or more, packets to the target. Such reflection can hide the number, or more, packets to the target. Such reflection can hide the
attacker's address even when ingress filtering prevents source attacker's address even when ingress filtering prevents source
address spoofing. Reflection is particularly dangerous if the packets address spoofing. Reflection is particularly dangerous if the
can be reflected multiple times, if they can be sent into a looping packets can be reflected multiple times, if they can be sent into a
path, or if the nodes can be tricked into sending many more packets looping path, or if the nodes can be tricked into sending many more
than they receive from the attacker, because such features can be packets than they receive from the attacker, because such features
used to amplify the traffic by a significant factor. When designing can be used to amplify the traffic by a significant factor. When
protocols, one should avoid creating services that can be used for designing protocols, one should avoid creating services that can be
reflection and amplification. used for reflection and amplification.
Triangle routing would easily create opportunities for reflection: a Triangle routing would easily create opportunities for reflection: a
correspondent node receives packets (e.g. TCP SYN) from the mobile correspondent node receives packets (e.g. TCP SYN) from the mobile
node and replies to the home address given by the mobile node in the node and replies to the home address given by the mobile node in the
Home Address Option (HAO). The mobile might not really be a mobile Home Address Option (HAO). The mobile might not really be a mobile
and the home address could actually be the target address. The target and the home address could actually be the target address. The
would only see the packets sent by the correspondent and could not target would only see the packets sent by the correspondent and could
see the attacker's address (even if ingress filtering prevents the not see the attacker's address (even if ingress filtering prevents
attacker from spoofing its source address). the attacker from spoofing its source address).
+----------+ TCP SYN with HAO +-----------+ +----------+ TCP SYN with HAO +-----------+
| Attacker |-------------------->| Reflector | | Attacker |-------------------->| Reflector |
+----------+ +-----------+ +----------+ +-----------+
| |
| TCP SYN-ACK to HoA | TCP SYN-ACK to HoA
V V
+-----------+ +-----------+
| Flooding | | Flooding |
| target | | target |
skipping to change at page 24, line 8 skipping to change at page 24, line 32
Figure 6 Figure 6
Figure 6 gives a summary of the discussed attacks. As it stands Figure 6 gives a summary of the discussed attacks. As it stands
today, the return-to-the-home flooding and the induction of today, the return-to-the-home flooding and the induction of
unnecessary binding updates look like the threats that we have the unnecessary binding updates look like the threats that we have the
least amount of protection, compared to their severity. least amount of protection, compared to their severity.
3.5 Problems with infrastructure based authorization 3.5 Problems with infrastructure based authorization
Early in the MIPv6 design process it was assumed that plain IPsec Early in the MIPv6 design process it was assumed that plain IPsec
could be used for securing Binding Updates. However, this turned out could be the default way to secure Binding Updates with arbitrary
to be impossible for two reasons. The first reason can be inferred correspondent nodes. However, this turned out to be impossible.
from the attack descriptions above: IPsec is not designed to protect Plain IPsec relies on an infrastructure for key management, which, to
against the kinds of DoS attacks that would be possible with MIPv6. be usable with any arbitrary pair of nodes, would need to be global
Protecting against the flooding attacks would be very difficult or in scope. Such a "global PKI" does not exist, nor is it expected to
even impossible with plain vanilla IPsec. The second reason is come into existence any time soon.
scalability.
Relying on IPsec requires key management, and key management requires Other more minor issues that also surfaced at the time were: (1)
infrastructure to distribute the keys. Furthermore, in MIPv6 it is insufficient filtering granularity for the state of IPsec at the
important to show whom an IP address belongs to, i.e., who has the time, (2) cost to establish a security association (in terms of CPU
authority to control where packets destined to the given address may and round trip times) and (3) expressing the proper authorization (as
be redirected to. Only the "owner" of an address may send Binding opposed to just authentication) for binding updates [11]. These
Updates to redirect packets to a care-of-address. [5] issues are solvable, and, in particular, (1) and (3) have been
addressed for IPsec usage with binding updates between the mobile
node and the home agent [8].
On way of providing a global key infrastructure for mobile IP would But the lack of a global PKI remains unsolved.
be DNSSEC. If there was secure reverse DNS that provided a public key
for each IP address, that could be used for verifying that a binding
update is indeed signed by an authorized party. However, in order to
be secure, each link in such a system must be secure. That is, there
must be a chain of keys and signatures all the way down from the root
to the given IP address. Furthermore, it is not enough that each key
is signed by the key above, it is also necessary that each signature
carries the meaning of authorizing the lower key to manage the
address block below it.
For example, consider the reverse DNS entry e.f.f.3.ip6.arpa . It One way of providing a global key infrastructure for mobile IP could
could be associated with a key, say K_3ffe. In order to be valid, be DNSSEC. Such a scheme is not completely supported by the existing
that key should be signed by an upper level key, let's say K_3ff, specifications, as it constitutes a new application of the KEY RR,
etc., up to the top level. Similarly, any subrange of addresses below something explicitly limited to DNSSEC [5]. Nevertheless, if one
3ff0::/16 would need to be signed by K_3ffe. Additionally, when the were to define it, one could proceed along the following lines: A
human managing the K_3ffe key signs subkeys, he or she should make secure reverse DNS that provided a public key for each IP address
sure that the signed subkey really belongs to a party that is could be used to verify that a binding update is indeed signed by an
authorized to assign address blocks in the said address range. In authorized party. However, in order to be secure, each link in such
other words, the keys and signatures should form a tree reflecting a system must be secure. That is, there must be a chain of keys and
the actual address allocations. signatures all the way down from the root (or at least starting from
a trust anchor common to the mobile node and the correspondent node)
to the given IP address. Furthermore, it is not enough that each key
be signed by the key above it in the chain. It is also necessary
that each signature explicitly authorize the lower key to manage the
corresponding address block below.
Even though it would be theoretically possible to build a secure Even though it would be theoretically possible to build a secure
reverse DNS infrastructure along the lines show above, the practical reverse DNS infrastructure along the lines shown above, the practical
problems would be insurmountable. That is, while the delegation and problems would be daunting. Whereas the delegation and key signing
key signing might work close to the root of the tree, it would might work close to the root of the tree, it would probably break
probably break down somewhere between the root and the individual down somewhere along the path to the individual nodes. Notice that a
nodes. Furthermore, checking all the signatures up the tree would similar delegation tree is currently being proposed for Secure
place a considerable burden to the correspondent nodes, making route Neighbor Discovery [13], although in this case only routers (not
optimization computationally very expensive. As the last nail on the necessarily every single potential mobile node) need to secure such a
coffin, checking just that the mobile node is authorized to send certificate. Furthermore, checking all the signatures on the tree
binding updates containing a given Home Address would not be enough, would place a considerable burden on the correspondent nodes, making
since a malicious mobile node would still be able to launch flooding route optimization prohibitive, or at least justifiable only in very
attacks. On the other hand, relying on such an infrastructure to particular circumstances. Finally, it is not enough to simply check
assign and verify "ownership" of care-of-addresses would be even if the mobile node is authorized to send binding updates containing a
harder than verifying home address "ownership". given Home Address, because to protect against flooding attacks the
care-of address must also be verified.
Relying on this same secure DNS infrastructure to verify
care-of-addresses would be even harder than verifying home addresses.
Instead, a different method would be required, e.g., a return
routability procedure. If so, the obvious question is whether the
gargantuan cost of deploying the global secure DNS infrastructure is
worth the additional protection it affords, as compared to simply
using return routability for both home address and care-of address
verification.
4. The solution selected for Mobile IPv6 4. The solution selected for Mobile IPv6
The current Mobile IPv6 route optimization security has been The current Mobile IPv6 route optimization security has been
carefully designed to prevent or mitigate the threats that were carefully designed to prevent or mitigate the threats that were
discussed in Section 3. The goal has been to produce a design whose discussed in <threats>. The goal has been to produce a design whose
security is close to that of a static IPv4 based Internet, and whose security is close to that of a static IPv4 based Internet, and whose
cost in terms of packets, delay and processing is not excessive. The cost in terms of packets, delay and processing is not excessive. The
result is not what one would expect: the result is definitely not a result is not what one would expect: the result is definitely not a
traditional cryptographic protocol. Instead, the result relies traditional cryptographic protocol. Instead, the result relies
heavily on the assumption of an uncorrupted routing infrastructure, heavily on the assumption of an uncorrupted routing infrastructure,
and builds upon the idea of checking that an alleged mobile node is and builds upon the idea of checking that an alleged mobile node is
indeed reachable both through its home address and its indeed reachable both through its home address and its
care-of-address. Furthermore, the lifetime of the state created at care-of-address. Furthermore, the lifetime of the state created at
the corresponded nodes is deliberately restricted to a few minutes, the corresponded nodes is deliberately restricted to a few minutes,
in order to limit the potential ability of time shifting. in order to limit the potential ability of time shifting.
skipping to change at page 26, line 35 skipping to change at page 26, line 35
description with a discussion about the lifetime of Binding Cache description with a discussion about the lifetime of Binding Cache
Entries (Section 4.3). Entries (Section 4.3).
4.1 Return Routability 4.1 Return Routability
Return Routability (RR) is the name of the basic mechanism deployed Return Routability (RR) is the name of the basic mechanism deployed
by Mobile IPv6 route optimization security design. Basically, it by Mobile IPv6 route optimization security design. Basically, it
means that a node verifies that there is a node that is able to means that a node verifies that there is a node that is able to
respond to packets sent to a given address. The check yields false respond to packets sent to a given address. The check yields false
positives if the routing infrastructure is compromised or if there is positives if the routing infrastructure is compromised or if there is
an attacker between the verifier and the address to be verified. With an attacker between the verifier and the address to be verified.
these exceptions, it is assumed that a successful reply indicates With these exceptions, it is assumed that a successful reply
that there is indeed a node at the given address, and that the node indicates that there is indeed a node at the given address, and that
is willing to reply to the probes sent to it. the node is willing to reply to the probes sent to it.
The basic return routability mechanism consist of two checks, a Home The basic return routability mechanism consist of two checks, a Home
Address check (see Section 4.1.1) and a care-of-address check (see Address check (see Section 4.1.1) and a care-of-address check (see
Section 4.1.2). The packet flow is depicted in Figure 7. First the Section 4.1.2). The packet flow is depicted in Figure 7. First the
mobile node sends two packets to the correspondent node: a Home Test mobile node sends two packets to the correspondent node: a Home Test
Init (HoTI) packet is sent through the home agent, and a Care-of Test Init (HoTI) packet is sent through the home agent, and a Care-of Test
Init (CoTI) directly. The correspondent node replies to both of these Init (CoTI) directly. The correspondent node replies to both of
independently by sending a Home Test (HoT) in response to the Home these independently by sending a Home Test (HoT) in response to the
Test Init and a Care-of Test (CoT) in response to the Care-of Test Home Test Init and a Care-of Test (CoT) in response to the Care-of
Init. Finally, once the mobile node has received both the Home Test Test Init. Finally, once the mobile node has received both the Home
and Care-of Test packets, it sends a Binding Update to the Test and Care-of Test packets, it sends a Binding Update to the
correspondent node. correspondent node.
+------+ 1a) HoTI +------+ +------+ 1a) HoTI +------+
| |---------------------->| | | |---------------------->| |
| MN | 2a) HoT | HA | | MN | 2a) HoT | HA |
| |<----------------------| | | |<----------------------| |
+------+ +------+ +------+ +------+
1b) CoTI | ^ | / ^ 1b) CoTI | ^ | / ^
| |2b| CoT / / | |2b| CoT / /
| | | / / | | | / /
skipping to change at page 27, line 25 skipping to change at page 27, line 25
+------+ 1a) HoTI / / +------+ 1a) HoTI / /
| |<----------------/ / | |<----------------/ /
| CN | 2a) HoT / | CN | 2a) HoT /
| |------------------/ | |------------------/
+------+ +------+
Figure 7 Figure 7
It might appear that the actual design was somewhat convoluted. That It might appear that the actual design was somewhat convoluted. That
is, the real return routability checks are the message pairs < Home is, the real return routability checks are the message pairs < Home
Test, Binding Update > and < Care-of Test, Binding Update >. The Home Test, Binding Update > and < Care-of Test, Binding Update >. The
Test Init and Care-of Test Init packets are only needed to trigger Home Test Init and Care-of Test Init packets are only needed to
the test packets, and the Binding Update acts as a combined trigger the test packets, and the Binding Update acts as a combined
routability response to both of the tests. routability response to both of the tests.
There are two main reasons behind this design: There are two main reasons behind this design:
avoidance of reflection and amplification (see Section 3.3.3), and avoidance of reflection and amplification (see Section 3.3.3), and
avoidance of state exhaustion DoS attacks (see Section 4.2). avoidance of state exhaustion DoS attacks (see Section 4.2).
The reason for sending two Init packets instead of one is the The reason for sending two Init packets instead of one is the
avoidance of amplication. The correspondent node does not know avoidance of amplication. The correspondent node does not know
anything about the mobile node, and therefore it just suddenly anything about the mobile node, and therefore it just suddenly
receives an IP packet from some arbitrary IP address. In a way, this receives an IP packet from some arbitrary IP address. In a way, this
skipping to change at page 28, line 36 skipping to change at page 28, line 36
allowing the correspondent node to easier find the appropriate nonce. allowing the correspondent node to easier find the appropriate nonce.
The token allows the correspondent node to make sure that the The token allows the correspondent node to make sure that the
subsequently received binding update is created by a node that has subsequently received binding update is created by a node that has
seen the Home Test packet; see Section 4.2. seen the Home Test packet; see Section 4.2.
In most cases the Home Test packet is forwarded over two different In most cases the Home Test packet is forwarded over two different
segments of the Internet. It first traverses from the correspondent segments of the Internet. It first traverses from the correspondent
node to the Home Agent. On this trip, it is not protected and any node to the Home Agent. On this trip, it is not protected and any
eavesdropper on the path can learn its contents. The Home Agent then eavesdropper on the path can learn its contents. The Home Agent then
forwards the packet to the mobile node. This path is taken inside the forwards the packet to the mobile node. This path is taken inside
IPsec ESP protected tunnel, making it impossible for the outsiders to the IPsec ESP protected tunnel, making it impossible for the
learn the contents of the packet. outsiders to learn the contents of the packet.
At first it may sound unnecessary to protect the packet between the At first it may sound unnecessary to protect the packet between the
home agent and the mobile node since it travelled unprotected between home agent and the mobile node since it travelled unprotected between
the correspondent node and the mobile node. If all links in the the correspondent node and the mobile node. If all links in the
Internet were equally insecure, the situation would indeed be so, Internet were equally insecure, the situation would indeed be so,
that would be unnecessary. However, in most practical settings the that would be unnecessary. However, in most practical settings the
network is likely to be more secure near the Home Agent than near the network is likely to be more secure near the Home Agent than near the
Mobile Node. For example, if the home agent hosts a virtual home link Mobile Node. For example, if the home agent hosts a virtual home
and the mobile nodes are never actually at home, an eavesdropper link and the mobile nodes are never actually at home, an eavesdropper
should be close to the correspondent node or on the path between the should be close to the correspondent node or on the path between the
correspondent node and the home agent, since it could not eavesdrop correspondent node and the home agent, since it could not eavesdrop
at the home agent. If the correspondent node is a big server, all the at the home agent. If the correspondent node is a big server, all
links on the path between it and the Home Agent are likely to be the links on the path between it and the Home Agent are likely to be
fairly secure. On the other hand, the Mobile Node is probably using fairly secure. On the other hand, the Mobile Node is probably using
wireless access technology, making it sometimes trivial to eavesdrop wireless access technology, making it sometimes trivial to eavesdrop
its access link. Thus, it is fairly easy to eavesdrop packets that its access link. Thus, it is fairly easy to eavesdrop packets that
arrive at the mobile node. Consequently, protecting the HA-MN path is arrive at the mobile node. Consequently, protecting the HA-MN path
likely to provide real security benefits even when the CN-HA path is likely to provide real security benefits even when the CN-HA path
remains unprotected. remains unprotected.
4.1.2 Care-of-Address check 4.1.2 Care-of-Address check
From the correspondent node's point of view, the Care-of check is From the correspondent node's point of view, the Care-of check is
very similar to the Home check. The only difference is that now the very similar to the Home check. The only difference is that now the
source address of the received Care-of Test Init packet is assumed to source address of the received Care-of Test Init packet is assumed to
be the care-of-address of the mobile node. Furthermore, the token is be the care-of-address of the mobile node. Furthermore, the token is
created in a slightly different manner in order to make it impossible created in a slightly different manner in order to make it impossible
to use home tokens for care-of tokens or vice versa. to use home tokens for care-of tokens or vice versa.
skipping to change at page 30, line 9 skipping to change at page 30, line 9
The Home Test Init/Home Test and Care-of Test Init/Care-of Test The Home Test Init/Home Test and Care-of Test Init/Care-of Test
exchanges take place in parallel but independently from each other. exchanges take place in parallel but independently from each other.
Thus, the correspondent can respond to each message immediately and Thus, the correspondent can respond to each message immediately and
it does not need to remember doing that. This helps in potential it does not need to remember doing that. This helps in potential
Denial-of-Service situations: no memory needs to be reserved when Denial-of-Service situations: no memory needs to be reserved when
processing Home Test Init and Care-of Test Init messages. processing Home Test Init and Care-of Test Init messages.
Furthermore, Home Test Init and Care-of Test Init processing is Furthermore, Home Test Init and Care-of Test Init processing is
designed to be lightweight, and it can be rate limited if necessary. designed to be lightweight, and it can be rate limited if necessary.
When receiving a first binding update, the correspondent node goes When receiving a first binding update, the correspondent node goes
through a rather complicated procedure. The purpose of this procedure through a rather complicated procedure. The purpose of this
is to ensure that there is indeed a mobile node that has recently procedure is to ensure that there is indeed a mobile node that has
received a Home Test and a Care-of Test that were sent to the claimed recently received a Home Test and a Care-of Test that were sent to
home and care-of-addresses, respectively, and to make sure that the the claimed home and care-of-addresses, respectively, and to make
correspondent node does not unnecessarily spend CPU or other sure that the correspondent node does not unnecessarily spend CPU or
resources while performing this check. other resources while performing this check.
Since the correspondent node does not have any state when the binding Since the correspondent node does not have any state when the binding
update arrives, the binding update itself must contain enough update arrives, the binding update itself must contain enough
information so that relevant state can be created. The binding update information so that relevant state can be created. The binding
contains the following pieces of information for that: update contains the following pieces of information for that:
The care-of address specified in the Binding Update must be equal The care-of address specified in the Binding Update must be equal
to the source address used in the Care-of Test Init message. to the source address used in the Care-of Test Init message.
Notice that this applies to the effective Care-of Address of the Notice that this applies to the effective Care-of Address of the
Binding Update. In particular, if the Binding Update includes an Binding Update. In particular, if the Binding Update includes an
Alternate Care-of Address (AltCoA) [7], the effective CoA is, of Alternate Care-of Address (AltCoA) [7], the effective CoA is, of
course, this AltCoA. Thus, the Care-of Test Init must have course, this AltCoA. Thus, the Care-of Test Init must have
originated from the AltCoA. originated from the AltCoA.
The home address specified in the Binding Update must be equal to The home address specified in the Binding Update must be equal to
the source address used in the Home Test Init message. the source address used in the Home Test Init message.
These are copied over from the Home Test and Care-of Test These are copied over from the Home Test and Care-of Test
skipping to change at page 31, line 9 skipping to change at page 31, line 9
used to verify the MAC that protects integrity and origin of the used to verify the MAC that protects integrity and origin of the
actual Binding Update. Note that the same Kbm may be used for a actual Binding Update. Note that the same Kbm may be used for a
while, until either the mobile node moves (and needs to get a new while, until either the mobile node moves (and needs to get a new
care-of-address token), the care-of token expires, or the home token care-of-address token), the care-of token expires, or the home token
expires. expires.
4.2.1 Retransmissions and state machine 4.2.1 Retransmissions and state machine
Note that since the correspondent node may remain stateless until it Note that since the correspondent node may remain stateless until it
receives a valid binding update, the mobile node is solely receives a valid binding update, the mobile node is solely
responsible for retransmissions. That is, the mobile node should keep responsible for retransmissions. That is, the mobile node should
sending the Home Test Init / Care-of Test Init messages until it keep sending the Home Test Init / Care-of Test Init messages until it
receives a Home Test / Care-of Test, respectively. Similarly, it may receives a Home Test / Care-of Test, respectively. Similarly, it may
need to send the binding update a few times in the case it is lost need to send the binding update a few times in the case it is lost
while in transit. while in transit.
4.3 Quick expiration of the Binding Cache Entries 4.3 Quick expiration of the Binding Cache Entries
A Binding Cache Entry, along the key Kbm, represents the return A Binding Cache Entry, along the key Kbm, represents the return
routability state of the network at the time when the Home Test and routability state of the network at the time when the Home Test and
Care-of Test messages were sent out. Now, it is possible that a Care-of Test messages were sent out. Now, it is possible that a
specific attacker is able to eavesdrop a Home Test message at some specific attacker is able to eavesdrop a Home Test message at some
skipping to change at page 31, line 33 skipping to change at page 31, line 33
shifting attack (see Section 2.2). That is, in the current IPv4 shifting attack (see Section 2.2). That is, in the current IPv4
architecture an attacker at the path between the correspondent node architecture an attacker at the path between the correspondent node
and the home agent is able to perform attacks only as long as the and the home agent is able to perform attacks only as long as the
attacker is able to eavesdrop (and possibly disrupt) communications attacker is able to eavesdrop (and possibly disrupt) communications
on that particular path. A long living Home Test, and consequently on that particular path. A long living Home Test, and consequently
the ability to send valid binding updates for a long time, would the ability to send valid binding updates for a long time, would
allow the attacker to continue its attack even after the attacker is allow the attacker to continue its attack even after the attacker is
not any more able to eavesdrop the path. not any more able to eavesdrop the path.
To limit the seriousness of this and other similar time shifting To limit the seriousness of this and other similar time shifting
threats, the validity of the tokens is limited to a few minutes. This threats, the validity of the tokens is limited to a few minutes.
effectively limits the validity of the key Kbm and the lifetime of This effectively limits the validity of the key Kbm and the lifetime
the resulting binding updates and binding cache entries. of the resulting binding updates and binding cache entries.
While short life times are necessary given the other aspects of the While short life times are necessary given the other aspects of the
security design and the goals, they are clearly detrimental for security design and the goals, they are clearly detrimental for
efficiency and robustness. That is, a Home Test Init / Home Test efficiency and robustness. That is, a Home Test Init / Home Test
message pair must be exchanged through the home agent every few message pair must be exchanged through the home agent every few
minutes. These messages are unnecessary from a pure functional point minutes. These messages are unnecessary from a pure functional point
of view, thereby representing overhead. What is worse, though, is of view, thereby representing overhead. What is worse, though, is
that they make the home agent a single point of failure. That is, if that they make the home agent a single point of failure. That is, if
the Home Test Init / Home Test messages were not needed, the existing the Home Test Init / Home Test messages were not needed, the existing
connections from a mobile node to other nodes could continue even connections from a mobile node to other nodes could continue even
skipping to change at page 33, line 9 skipping to change at page 33, line 9
routability idea in the Home Test, Care-of Test and binding update routability idea in the Home Test, Care-of Test and binding update
messages, the ability to remain stateless until a valid binding messages, the ability to remain stateless until a valid binding
update is received, and the limiting of the binding life times to a update is received, and the limiting of the binding life times to a
few minutes. Next we briefly discuss some of the remaining threats few minutes. Next we briefly discuss some of the remaining threats
and other problems inherent to the design. and other problems inherent to the design.
5. Security considerations 5. Security considerations
In this section we give a brief analysis of the security design, In this section we give a brief analysis of the security design,
mostly in the light of what was know at the time the design was mostly in the light of what was know at the time the design was
completed in fall 2002. It should be noted that this section does not completed in fall 2002. It should be noted that this section does
present a proper security analysis of the protocol, but merely not present a proper security analysis of the protocol, but merely
discusses a few issues that were known at the time the design was discusses a few issues that were known at the time the design was
completed. completed.
It should be kept in mind that the MIPv6 RO security design was never It should be kept in mind that the MIPv6 RO security design was never
intended to be fully secure. Instead, as we stated earlier, to goal intended to be fully secure. Instead, as we stated earlier, to goal
was to be roughly as secure as non-mobile IPv4 was known to be at the was to be roughly as secure as non-mobile IPv4 was known to be at the
time of the design. As it turns out, the result is slightly less time of the design. As it turns out, the result is slightly less
secure than IPv4, but the difference is small and most likely to be secure than IPv4, but the difference is small and most likely to be
insignificant in real life. insignificant in real life.
skipping to change at page 33, line 35 skipping to change at page 33, line 35
5.4 deals with the special case of two mobile nodes conversing and 5.4 deals with the special case of two mobile nodes conversing and
performing the route optimization procedure with each other. performing the route optimization procedure with each other.
5.1 Residual Threats as Compared to IPv4 5.1 Residual Threats as Compared to IPv4
As we mentioned in Section 4.2, the lifetime of a binding represents As we mentioned in Section 4.2, the lifetime of a binding represents
a potential time shift in an attack. That is, an attacker that is a potential time shift in an attack. That is, an attacker that is
able to create a false binding is able to reap the benefits of the able to create a false binding is able to reap the benefits of the
binding as long as the binding lasts, or, alternatively, is able to binding as long as the binding lasts, or, alternatively, is able to
delay a return-to-the-home flooding attack (Section 3.2.2) until the delay a return-to-the-home flooding attack (Section 3.2.2) until the
binding expires. This is a difference from IPv4 where an attacker may binding expires. This is a difference from IPv4 where an attacker
continue an attack only as long as it is at the path between the two may continue an attack only as long as it is at the path between the
hosts. two hosts.
Since the binding lifetimes are severely restricted in the current Since the binding lifetimes are severely restricted in the current
design, the ability to do a time shifting attack is respectively design, the ability to do a time shifting attack is respectively
restricted. restricted.
Threats possible because of the introduction of route optimization Threats possible because of the introduction of route optimization
are, of course, not present in a baseline IPv4 internet (Section are, of course, not present in a baseline IPv4 internet (Section
3.3). In particular, inducing unnecessary binding updates could 3.3). In particular, inducing unnecessary binding updates could
potentially be a severe attack, but this would be more due to faulty potentially be a severe attack, but this would be more due to faulty
implementations. As an extreme measure, a correspondent node can implementations. As an extreme measure, a correspondent node can
skipping to change at page 34, line 12 skipping to change at page 34, line 12
there is no clear-cut prevention (other than its severe limitation as there is no clear-cut prevention (other than its severe limitation as
currently specified) is the time shifting attack mentioned above. currently specified) is the time shifting attack mentioned above.
5.2 Interaction with IPsec 5.2 Interaction with IPsec
A major motivation behind the current binding update design was A major motivation behind the current binding update design was
scalability, the ability to run the protocol without any existing scalability, the ability to run the protocol without any existing
security infrastructure. An alternative would have been to rely on security infrastructure. An alternative would have been to rely on
existing trust relationships, perhaps in the form of a special existing trust relationships, perhaps in the form of a special
purpose Public Key Infrastructure and IPsec. That would have limited purpose Public Key Infrastructure and IPsec. That would have limited
scalability, making route optimization available in environments scalability, making route optimization available only in environments
where it is possible to create appropriately authorized IPsec where it is possible to create appropriately authorized IPsec
security associations between the mobile nodes and the corresponding security associations between the mobile nodes and the corresponding
nodes. nodes.
There clearly are situations where there exists an appropriate There clearly are situations where there exists an appropriate
relationship between a mobile node and the correspondent node. For relationship between a mobile node and the correspondent node. For
example, if the correspondent node is a server that has example, if the correspondent node is a server that has
pre-established keys with the mobile node, that would be the case. pre-established keys with the mobile node, that would be the case.
However, entity authentication or an authenticated session key is not However, entity authentication or an authenticated session key is not
necessarily sufficient for accepting Binding Updates. If one wants necessarily sufficient for accepting Binding Updates.
to replace the home address check with some cryptographic
credentials, the credentials must carry proper authorization for the
specific home address. For example, if the mobile nodes hands out a
certificate to the correspondent node and they consequently create a
pair of IPsec security associations, it is not necessarily clear that
those security associations could be used to replace the home address
check. Instead, if and only if the certificate explicitly states what
the mobile node's home address is and that the mobile node is
authorized to create bindings for its home address, home address
checks may be dropped. Furthermore, care must be taken to make sure
that the issuer of the certificate is entitled to express such
authorization.
In practise, it seems highly unlikely that the nodes were ever able Home Address Check: If one wants to replace the home address check
to replace the care-of address check with credentials. The care-of with cryptographic credentials, these must carry proper
addresses are ephemeral, and it is highly unlikely that a mobile node authorization for the specific home address, and care must be
would be able to present credentials that show it authorized to use taken to make sure that the issuer of the certificate is entitled
the care of address without any check. to express such authorization. At the time of the design work,
the route optimization security design team was not aware of
standardized certificate formats to do this, although more recent
efforts within the IETF are addressing this issue. Notice that
there is plenty of motivation to do so, as any pre-existing
relationship with a correspondent node would involve the mobile
node's home address (instead of any of its possible care-of
addresses). Accordingly, the IKE exchange would most naturally
run between the correspondent node and the mobile node's home
address. This still leaves open the issue of checking the mobile
node's care-of address.
Mobile IPv6 [7] does not specify how to use IPsec together with the Care-of Address Check: As for the care-of address check, in
mobility procedures between the mobile node and correspondent node. practice, it seems highly unlikely that nodes could completely
Hence, currently there are no standard way of replacing the home replace the care-of address check with credentials. Since the
address check. On the other hand, the specification is carefully care-of addresses are ephemeral, in general it is very difficult
written to allow the creation of the binding management key Kbm for a mobile node to present credentials that taken at face value
through some different means. (by an arbitrary correspondent node) guarantee no misuse for, say,
flooding attacks (Section 3.2). As discussed before, a
reachability check goes a long way to alleviate such attacks.
Notice that, as part of the normal protocol exchange, establishing
an IPsec security association via IKE includes one such
reachability test. However, as per the previous section, the
natural IKE protocol exchange runs between the correspondent node
and the mobile node's home address. Hence, another reachability
check is needed to check the care-of address at which the node is
currently reachable. If this address changes, such a reachability
test is likewise necessary, and is included in ongoing work aimed
at securely updating the node's current address.
5.3 Pretending to be your neighbor Nevertheless, the Mobile IPv6 base specification [7] does not specify
how to use IPsec together with the mobility procedures between the
mobile node and correspondent node. On the other hand, the
specification is carefully written to allow the creation of the
binding management key Kbm through some different means.
Accordingly, where an appropriate relationship exists between a
mobile node and a correspondent node, the use of IPsec is possible,
and is, in fact, being pursued in more recent work.
5.3 Pretending to be one's neighbor
One possible attack against the security design is to pretend to be a One possible attack against the security design is to pretend to be a
neighboring node. To launch this attack, the mobile nodes establishes neighboring node. To launch this attack, the mobile nodes
route optimization with some arbitrary correspondent node. While establishes route optimization with some arbitrary correspondent
performing the return routability tests and creating the binding node. While performing the return routability tests and creating the
management key Kbm, the attacker uses its real home address but a binding management key Kbm, the attacker uses its real home address
faked care-of address. Indeed, the care-of address would be the but a faked care-of address. Indeed, the care-of address would be
address of the neighboring node on the local link. The attacker is the address of the neighboring node on the local link. The attacker
able to create the binding since it receives a valid Home Test is able to create the binding since it receives a valid Home Test
normally, and it is able to eavesdrop the Care-of Test as it appears normally, and it is able to eavesdrop the Care-of Test as it appears
on the local link. on the local link.
This attack would allow the mobile node to divert unwanted traffic This attack would allow the mobile node to divert unwanted traffic
towards the neighboring node, resulting in an flooding attack. towards the neighboring node, resulting in an flooding attack.
However, this attack is not very serious in practise. Firstly, it is However, this attack is not very serious in practice. Firstly, it is
limited in the terms of location, since it is only possible against limited in the terms of location, since it is only possible against
neighbors. Secondly, the attack works also against the attacker, neighbors. Secondly, the attack works also against the attacker,
since it shares the local link with the target. Thirdly, a similar since it shares the local link with the target. Thirdly, a similar
attack is possible with Neighbor Discovery spoofing. attack is possible with Neighbor Discovery spoofing.
5.4 Two mobile nodes talking to each other 5.4 Two mobile nodes talking to each other
When two mobile nodes want to establish route optimization with each When two mobile nodes want to establish route optimization with each
other, some care must be exercised in order not to reveal the reverse other, some care must be exercised in order not to reveal the reverse
tokens to an attacker. In this situation, both mobile nodes act tokens to an attacker. In this situation, both mobile nodes act
skipping to change at page 37, line 9 skipping to change at page 38, line 9
We have also briefly covered some of the known subtleties and We have also briefly covered some of the known subtleties and
shortcomings, but that discussion cannot be exhaustive. It is quite shortcomings, but that discussion cannot be exhaustive. It is quite
probable that new subtle problems will be discovered from the design. probable that new subtle problems will be discovered from the design.
As a consequence, it is most likely that the design needs to be As a consequence, it is most likely that the design needs to be
revised in the light of experience and insights. revised in the light of experience and insights.
7. Acknowledgements 7. Acknowledgements
Hesham Soliman for reminding us about the threat explained in Section Hesham Soliman for reminding us about the threat explained in Section
5.3. Francis Dupont for first discussing the case of two mobile 5.3. Francis Dupont for first discussing the case of two mobile
nodes talking to each other Section 5.4. nodes talking to each other (Section 5.4) and sundry other comments.
Pekka Savola for his help in Section 1.1.1.
8 References (informative) 8 Informative References
[1] Aura, T., Roe, M. and J. Arkko, "Security of Internet Location [1] Aura, T., Roe, M. and J. Arkko, "Security of Internet Location
Management", Proc. 18th Annual Computer Security Applications Management", Proc. 18th Annual Computer Security Applications
Conference, pages 78-87, Las Vegas, NV USA, IEEE Press., Conference, pages 78-87, Las Vegas, NV USA, IEEE Press.,
December 2002. December 2002.
[2] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[3] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[4] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines
and Philosophy", RFC 3439, December 2002. and Philosophy", RFC 3439, December 2002.
[3] Chiappa, J., "Will The Real "End-End Principle" Please Stand [5] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record (RR)", RFC 3445, December 2002.
[6] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[8] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[9] Chiappa, J., "Will The Real "End-End Principle" Please Stand
Up?", date unknown. Up?", date unknown.
[4] Savage, S., Cardwell, N., Wetherall, D. and T. Anderson, "TCP [10] Savage, S., Cardwell, N., Wetherall, D. and T. Anderson, "TCP
Congestion Control with a Misbehaving Receiver", Computer Congestion Control with a Misbehaving Receiver", Computer
Communication Review 29:5, 1999. Communication Review 29:5, 1999.
[5] Nikander, P., "Denial-of-Service, Address Ownership, and Early [11] Nikander, P., "Denial-of-Service, Address Ownership, and
Authentication in the IPv6 World", Security Protocols 9th Early Authentication in the IPv6 World", Security Protocols 9th
International Workshop, Cambridge, UK, April 25-27 2001, LNCS International Workshop, Cambridge, UK, April 25-27 2001, LNCS
2467, pages 12-26, Springer, 2002. 2467, pages 12-26, Springer, 2002.
[6] Chiappa, J., "Endpoints and Endpoint Names: A Proposed [12] Chiappa, J., "Endpoints and Endpoint Names: A Proposed
Enhancement to the Internet Architecture", date unknown. Enhancement to the Internet Architecture", date unknown.
[7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in [13] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05
2003. (work in progress), April 2004.
Authors' Addresses Authors' Addresses
Pekka Nikander Pekka Nikander
Ericsson Research Nomadic Lab Ericsson Research Nomadic Lab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone: +358 9 299 1 Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com EMail: pekka.nikander@nomadiclab.com
Jari Arkko Jari Arkko
Ericsson Research Nomadic Lab Ericsson Research Nomadic Lab
Tuomas Aura Tuomas Aura
Microsoft Research Microsoft Research
Gabriel Montenegro Gabriel Montenegro
Sun Microsystems Sun Microsystems
Montbonnot 38240
France
Phone:
EMail: gab@sun.com
Erik Nordmark Erik Nordmark
Sun Microsystems Sun Microsystems
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/