draft-ietf-mip6-ro-sec-02.txt   draft-ietf-mip6-ro-sec-03.txt 
Network Working Group P. Nikander Network Working Group P. Nikander
Internet-Draft J. Arkko Internet-Draft J. Arkko
Expires: April 15, 2005 Ericsson Research Nomadic Lab Expires: December 3, 2005 Ericsson Research Nomadic Lab
T. Aura T. Aura
Microsoft Research Microsoft Research
G. Montenegro G. Montenegro
Sun Microsystems Laboratories Microsoft Corporation
E. Nordmark E. Nordmark
Sun Microsystems Sun Microsystems
October 15, 2004 June 2005
Mobile IP version 6 Route Optimization Security Design Background Mobile IP version 6 Route Optimization Security Design Background
draft-ietf-mip6-ro-sec-02 draft-ietf-mip6-ro-sec-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she becomes aware will be disclosed, in accordance with
RFC 3668. Section 6 of BCP 79.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://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 April 15, 2005. This Internet-Draft will expire on December 3, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document is an account of the rationale behind the Mobile IPv6
This document is a succint account of the rationale behind the Mobile (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
behind the Mobile IPv6 Security Design in 2001-2002. behind the Mobile IPv6 Security Design in 2001-2002.
The document has two target audiences: (1) MIPv6 implementors so that The document has two target audiences: (1) MIPv6 implementors so that
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 . . . . 7 1.2 The Mobility Problem and the Mobile IPv6 Solution . . . . 7
1.3 Design Principles and Goals . . . . . . . . . . . . . . . 8 1.3 Design Principles and Goals . . . . . . . . . . . . . . . 9
1.3.1 End-to-end principle . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 10
1.4 About Mobile IPv6 Mobility and its Variations . . . . . . 10 1.4 About Mobile IPv6 Mobility and its Variations . . . . . . 10
2. Dimensions of Danger . . . . . . . . . . . . . . . . . . . . . 11 2. Avenues of Attack . . . . . . . . . . . . . . . . . . . . . . 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' (also known as
'stealing' . . . . . . . . . . . . . . . . . . . . . . . . 14 address '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 . . . . . . . . 18
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 . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . 22
3.3.3 Reflection and Amplification . . . . . . . . . . . . . 22 3.3.3 Reflection and Amplification . . . . . . . . . . . . . 22
3.4 Classification of attacks . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . 27
4.1 Return Routability . . . . . . . . . . . . . . . . . . . . 26 4.1 Return Routability . . . . . . . . . . . . . . . . . . . . 27
4.1.1 Home Address check . . . . . . . . . . . . . . . . . . 28 4.1.1 Home Address check . . . . . . . . . . . . . . . . . . 29
4.1.2 Care-of-Address check . . . . . . . . . . . . . . . . 29 4.1.2 Care-of-Address check . . . . . . . . . . . . . . . . 30
4.1.3 Forming the first Binding Update . . . . . . . . . . . 29 4.1.3 Forming the first Binding Update . . . . . . . . . . . 30
4.2 Creating state safely . . . . . . . . . . . . . . . . . . 29 4.2 Creating state safely . . . . . . . . . . . . . . . . . . 30
4.2.1 Retransmissions and state machine . . . . . . . . . . 31 4.2.1 Retransmissions and state machine . . . . . . . . . . 32
4.3 Quick expiration of the Binding Cache Entries . . . . . . 31 4.3 Quick expiration of the Binding Cache Entries . . . . . . 32
5. Security considerations . . . . . . . . . . . . . . . . . . . 33 5. Security considerations . . . . . . . . . . . . . . . . . . . 34
5.1 Residual Threats as Compared to IPv4 . . . . . . . . . . . 33 5.1 Residual Threats as Compared to IPv4 . . . . . . . . . . . 34
5.2 Interaction with IPsec . . . . . . . . . . . . . . . . . . 34 5.2 Interaction with IPsec . . . . . . . . . . . . . . . . . . 35
5.3 Pretending to be one's neighbor . . . . . . . . . . . . . 35 5.3 Pretending to be one's neighbor . . . . . . . . . . . . . 36
5.4 Two mobile nodes talking to each other . . . . . . . . . . 35 5.4 Two mobile nodes talking to each other . . . . . . . . . . 36
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 38
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
8. Informative References . . . . . . . . . . . . . . . . . . . . 38 8. Informative References . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . . 41
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 to provide a relatively compact source
of the background assumptions, design choices, and other information for 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].
Even though incidental implementation suggestions are included for Even though incidental implementation suggestions are included for
illustrative purposes, the goal of this document is not to provide a illustrative purposes, the goal of this document is not to provide a
guide to implementors. The goal of this document is to explain the guide to implementors. The goal of this document is to explain the
design choices and rationale behind the current route optimization design choices and rationale behind the current route optimization
design. The authors participated in the design team which produced design. The authors participated in the design team which produced
skipping to change at page 5, line 18 skipping to change at page 5, line 18
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
the limitations intrinsic to the provided solutions. the limitations intrinsic to the provided solutions.
In particular, this document explains how the adopted design for In particular, this document explains how the adopted design for
"Return Routability" (RR) protects against the identified threats "Return Routability" (RR) protects against the identified threats
(Section 3). This is true except for attacks on the RR protocol (Section 3). This is true except for attacks on the RR protocol
itself, which require other countermeasures based on heuristics and itself, which require other countermeasures based on heuristics and
judicious implementation (Section 3.3). judicious implementation (Section 3.3).
The rest of this document is organized as follows. After this The rest of this document is organized as follows: after this
introductory section, we start by considering the dimensions of the introductory section, we start by considering the avenues of attack
danger in Section 2. The security problems and countermeasures are in Section 2. The security problems and countermeasures are studied
studied in detail in Section 3. Section 4 explains the overall in detail in Section 3. Section 4 explains the overall operation and
operation and design choices behind the current security design. In design choices behind the current security design. In Section 5 we
Section 5 we analyze the design and discuss the remaining threats. analyze the design and discuss the remaining threats. Finally
Finally Section 6 concludes this document. 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 possible without changing too much. This was especially important
for IPv4, with its large installed base, but the same design goals for IPv4, with its large installed base, but the same design goals
were 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 of 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
1. 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
2. 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 to be trivial, let us explore them a little
further. Firstly, in the current IPv6 operational practice the IP further. Firstly, in 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 number of routing table entries each individual router
to handle. An important implication is that the topology determines needs to handle. An important implication is that the topology
what globally routable IP addresses are available at a given determines what globally routable IP addresses are available at a
location. That is, the nodes cannot freely decide what globally given location. That is, the nodes cannot freely decide what
routable IP address to use, but must rely on the routing prefixes globally routable IP address to use, but must rely on the routing
served by the local routers via Router Advertisements or by a DHCP prefixes served by the local routers via Router Advertisements or by
server. In other words, IP addresses are just what the name says, a DHCP server. In other words, IP addresses are just what the name
addresses, i.e., locators. says, 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
skipping to change at page 6, line 39 skipping to change at page 6, line 41
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 wrong locations. Such a fundamental malfunction of the Internet
would render hopeless any other effort to assure correct packet would render hopeless any other effort to assure correct packet
delivery (e.g., any efforts due to Mobile IP security delivery (e.g., any efforts due to Mobile IP security
considerations). 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 a false source
address. Ingress filtering is assumed to eventually prevent this. IP address. The eventual introduction of ingress filtering is
When ingress filtering is used, traffic with spoofed addresses is not assumed to prevent this. When ingress filtering is used, traffic
forwarded. This filtering can be applied at different network with spoofed addresses is not forwarded. This filtering can be
borders like those between an Internet service provider (ISP) and its applied at different network borders such as those between an
customers, between downstream and upstream ISPs, between peer ISPs, Internet service provider (ISP) and its customers, between downstream
etc [6]. Obviously, the granularity of ingress filters specifies how and upstream ISPs, between peer ISPs, etc [6]. Obviously, the
much you can "spoof inside a prefix". For example, if an ISP ingress granularity of ingress filters specifies how much you can "spoof
filters a customer's link, but the customer does nothing, anything inside a prefix". For example, if an ISP ingress filters a
inside the customer's /48 prefix could be spoofed, or if the customer customer's link, but the customer does nothing, anything inside the
does filtering at LAN subnets, anything inside the /64 prefixes could customer's /48 prefix could be spoofed, or if the customer does
be spoofed. Despite the limitations imposed by such "in-prefix 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 spoofing", in general, ingress filtering enables traffic to be
traceable to its real source network [6]. traceable to its real source network [6].
However, ingress filtering helps if and only if a large part of the However, ingress filtering helps if and only if a large part of the
Internet uses it. Unfortunately, there are still some issues (e.g. Internet uses it. Unfortunately, there are still some issues (e.g.
in the presence of site multi-homing) which, although not in the presence of site multi-homing) which, although not
insurmountable, do require careful handling, and are likely to limit insurmountable, do require careful handling, and are likely to limit
or delay its usefulness [6]. or delay its usefulness [6].
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-
UDP-based transactions) to continue even if the underlying host(s) based transactions) to continue even if the underlying host(s) move
move and change their IP addresses. Secondly, it allows a node to be 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 IPv6 aims to preserve the identifier nature of IP addresses. That
is, Mobile IPv6 takes the view that IP addresses can be used as is, Mobile IPv6 takes the view that IP addresses can be used as
natural identifiers of nodes, as they have been used since the natural identifiers of nodes, as they have been used since the
beginning of the Internet. This must be contrasted to proposed and beginning of the Internet. This must be contrasted to proposed and
existing alternative designs where the identifier and locator natures existing alternative designs where the identifier and locator natures
of the IP addresses have been separated (see Section 1.4) of the IP addresses have been separated (see Section 1.4)
skipping to change at page 8, line 4 skipping to change at page 8, line 17
+----+ ____________ +-#--+ +----+ ____________ +-#--+
| CoA ___/ \_____ # Home Link | CoA ___/ \_____ # Home Link
-+-------/ Internet * * *-*-*-*-#-#-#-#----- -+-------/ Internet * * *-*-*-*-#-#-#-#-----
| * * | * Home Address | * * | * Home Address
\___ * * _____/ + * -+ \___ * * _____/ + * -+
\_____*______/ | MN | \_____*______/ | MN |
* + - -+ * + - -+
+----+ +----+
| CN | Data path as * * * * | CN | Data path as * * * *
+----+ it appears to correspondent node +----+ it appears to correspondent node
Real data path # # # # Real data path # # # #
Figure 1 Figure 1: Basic Mode of Operation in Mobile IPv6
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
skipping to change at page 9, line 4 skipping to change at page 9, line 17
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 be explicit about delivering a practical
level of protection. (instead of an over-ambitious) 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 [4][9]. 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 relating to 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 agent and between the mobile node and its correspondent nodes. In
the 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 business relationship. In contrast, it was strictly assumed that the
the mobile node and the correspondent node do not need to have any mobile node and the correspondent node do not need to have any prior
prior arrangement, thereby allowing Mobile IPv6 to function in a arrangement, thereby allowing Mobile IPv6 to function in a scalable
scalable manner, without requiring any configuration at the manner, without requiring any configuration at the correspondent
correspondent nodes. 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 rationale 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
disrupt, modify, and eavesdrop all the traffic between the two nodes, disrupt, modify, and eavesdrop all the traffic between the two nodes,
unless IPsec protection was used. Even when IPsec was used, the unless IPsec protection was used. Even when IPsec was used, the
attacker was still able to selectively block communication by simply attacker was still able to selectively block communication by simply
dropping the packets. The attacker in control of a router between dropping the packets. The attacker in control of a router between
the two nodes could also mount a flooding attack by redirecting the the two nodes could also mount a flooding attack by redirecting the
data flows between the two nodes (or, more practically, an equivalent data flows between the two nodes (or, more practically, an equivalent
flow of bogus data) to a third party. flow of bogus data) to a third party.
skipping to change at page 10, line 21 skipping to change at page 10, line 37
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 the mobile node. It is local in the sense that the routing
exceptions are valid only at the home agent, and in the correspondent exceptions are valid only at the home agent, and in the correspondent
nodes if 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 [12], 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-
end-point identifier (EID) and a permanent locator. The point identifier (EID) and a permanent locator. The care-of-address
care-of-address is a pure, temporary locator, which identifies the is a pure, temporary locator, which identifies the current location
current location of the mobile node. The correspondent nodes of the mobile node. The correspondent nodes effectively perform
effectively perform source routing, redirecting traffic destined to source routing, redirecting traffic destined to the home address to
the home address to the care-of-address. This is even reflected in the care-of-address. This is even reflected in the packet structure:
the packet structure: the packets carry an explicit routing header. the packets carry an explicit routing header.
The relationshiop between EID's and permanent locators has been The relationship between EIDs 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. Avenues of Attack
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 exceptions. In Mobile IPv6 terms, the danger is in the possibility
of unauthorized creation of Binding Cache Entries (BCE). The effects of unauthorized creation of Binding Cache Entries (BCE). The effects
of an attack differ depending on the target of the attack, the timing of an attack differ depending on the target of the attack, the timing
of the attack, and the location of the attacker. of the attack, and the location of the attacker.
2.1 Target 2.1 Target
skipping to change at page 11, line 50 skipping to change at page 11, line 50
about the whereabouts of some remote nodes. Conversely, the role of about the whereabouts of some remote nodes. Conversely, the role of
being a correspondent node appears to be the weakest point since being a correspondent node appears to be the weakest point since
there are very few assumptions upon which it can base its state there are very few assumptions upon which it can base its state
formation. That is, an attacker has much easier task to fool a formation. That is, an attacker has much easier task to fool a
correspondent node to believe that a presumably mobile node is correspondent node to believe that a presumably mobile node is
somewhere it is not, than to fool a mobile node itself into believing somewhere it is not, than to fool a mobile node itself into believing
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
5.4). Section 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 timing. In a stationary IPv4 network, an attacker must be between
the communication nodes at the same time as the nodes communicate. the communication nodes at the same time as the nodes communicate.
With 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
selected time. If a large number of active BCEs carrying large selected time. If a large number of active BCEs carrying large
amounts of traffic expired at the same time, the result might be an amounts of traffic expired at the same time, the result might be an
overload towards the home agent or the home network. (See Section overload towards the home agent or the home network. (See
3.2.2 for a more detailed explanation.) Section 3.2.2 for a more detailed explanation.)
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
skipping to change at page 13, line 16 skipping to change at page 13, line 16
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 and related protection mechanisms. The goal of the attacker can be
to corrupt the correspondent node's binding cache and to cause to corrupt the correspondent node's binding cache and to cause
packets to be delivered to a wrong address. This can compromise packets to be delivered to a wrong address. This can compromise
secrecy and integrity of communication and cause denial-of-service secrecy and integrity of communication and cause denial-of-service
(DoS) both at the communicating parties and at the address that (DoS) both at the communicating parties and at the address that
receives the unwanted packets. The attacker may also exploit receives the unwanted packets. The attacker may also exploit
features of the Binding Update (BU) mechanism to exhaust the features of the Binding Update (BU) mechanism to exhaust the
resources of the mobile node, the home agent, or the correspondent resources of the mobile node, the home agent, or the correspondent
nodes. The aim of this section is to describe the major attacks and nodes. The aim of this section is to provide an overview of the
to overview various protocol mechanisms and their limitations. The various protocol mechanisms and their limitations. The details of
details of the mechanisms are covered in Section 4. 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 the attacker to be worth preventing.
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. consider attackers that only observe messages but do not send any.
In 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 target nodes.
Nevertheless, an important class of passive attacks remains, namely, Nevertheless, an important class of passive attacks remains, namely,
attacks on privacy. It is well known that by simply examining attacks on privacy. It is well known that by simply examining
packets, eavesdroppers can track the movements of individual nodes packets, eavesdroppers can track the movements of individual nodes
(and potentially, users) [3] Mobile IPv6 exacerbates the problem by (and potentially, users) [3] Mobile IPv6 exacerbates the problem by
adding more potentially sensitive information into the packets (e.g., adding more potentially sensitive information into the packets (e.g.,
Binding Updates, routing headers or home address options). This Binding Updates, routing headers or home address options). This
document does not address these attacks. 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 (Section 3.4). Finally, we consider the applicability of solutions
solutions relying on some kind of a global security infrastructure relying on some kind of a global security infrastructure
(Section 3.5). (Section 3.5).
3.1 Attacks against address 'owners' aka. address 'stealing' 3.1 Attacks against address 'owners' (also known as 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 claims to be a given node at a given
address, and then trying to "steal" traffic destined to that address. address, and then tries to "steal" traffic destined to that address.
There are several variants of this attack. We first describe the We first describe the basic variant of this attack, follow with a
basic variant, followed by a description how the situation is description of how the situation is affected if the target is a
affected if the target is a stationary node, and continuing more stationary node, and continue with more complicated issues related to
complicated issues related to timing (the so called "future" timing (so called "future" attacks), confidentiality and integrity,
attacks), confidentiality and integrity, and DoS aspects. 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 Internet. All nodes that support the correspondent node
functionality would become unwitting accomplices to this attack. As functionality would become unwitting accomplices to this attack. As
explained in Section 2.1, there is no way of telling which addresses explained in Section 2.1, there is no way of telling which addresses
belong to mobile nodes that really could send binding updates and belong to mobile nodes that really could send binding updates and
which addresses belong to stationary nodes (see below), so which addresses belong to stationary nodes (see below), so
skipping to change at page 14, line 38 skipping to change at page 14, line 38
| B |<----------------| A |- - - - - - ->| C | | B |<----------------| A |- - - - - - ->| C |
+---+ packet flow +---+ flow +---+ +---+ packet flow +---+ flow +---+
^ ^
| |
| False BU: B -> C | False BU: B -> C
| |
+----------+ +----------+
| Attacker | | Attacker |
+----------+ +----------+
Figure 2 Figure 2: Basic Address Stealing
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
skipping to change at page 16, line 12 skipping to change at page 16, line 12
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 legitimately. That is, if the attacker is a client of the Home
Agent, and able to acquire the home address temporarily, it may be Agent, and able to acquire the home address temporarily, it may be
able to do so, and then return the home address back to the Home able to do so, and then return the home address back to the Home
Agent once 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-
man-in-the-middle or denial-of-service attack. The mechanism applied middle or denial-of-service attack. The mechanism applied in the
in the MIPv6 security design is to limit the lifetime of Binding MIPv6 security design is to limit the lifetime of Binding Cache
Cache Entries to a few minutes. 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
possible under some other conditions. However, all of these attacks possible under some other conditions. However, all of these attacks
are limited by the Binding Cache Entry lifetime, and therefore not a are limited by the Binding Cache Entry lifetime, and therefore not a
real concern under the current design. real concern with the current design.
3.1.4 Attacks against Secrecy and Integrity 3.1.4 Attacks against Secrecy and Integrity
By spoofing Binding Updates, an attacker could redirect all packets By spoofing Binding Updates, an attacker could redirect all packets
between two IP nodes to itself. By sending a spoofed binding update between two IP nodes to itself. By sending a spoofed binding update
to A, it could capture the data intended to B. That is, it could to A, it could capture the data intended to B. That is, it could
pretend to be B and highjack A's connections with B, or establish new pretend to be B and highjack A's connections with B, or establish new
spoofed connections. The attacker could also send spoofed binding spoofed connections. The attacker could also send spoofed binding
updates to both A and B and insert itself in the middle of all updates to both A and B and insert itself in the middle of all
connections between them (man-in-the-middle attack). Consequently, connections between them (man-in-the-middle attack). Consequently,
skipping to change at page 17, line 4 skipping to change at page 17, line 22
Modified data path, after the falsified binding updates Modified data path, after the falsified binding updates
+---+ +---+ +---+ +---+
| A | | B | | A | | B |
+---+ +---+ +---+ +---+
\ / \ /
\ / \ /
\ +----------+ / \ +----------+ /
\---------| Attacker |-------/ \---------| Attacker |-------/
+----------+ +----------+
Figure 3
Figure 3: Man-in-the-Middle Attack
Strong end-to-end encryption and integrity protection, such as Strong end-to-end encryption and integrity protection, such as
authenticated IPSec, can prevent all the attacks against data secrecy authenticated IPSec, can prevent all the attacks against data secrecy
and integrity. When the data is cryptographically protected, spoofed and integrity. When the data is cryptographically protected, spoofed
binding updates could result in denial of service (see below) but not binding updates could result in denial of service (see below) but not
in disclosure or corruption of sensitive data beyond revealing the in disclosure or corruption of sensitive data beyond revealing the
existence of the traffic flows. Two fixed nodes could also protect existence of the traffic flows. Two fixed nodes could also protect
communication between themselves by refusing to accept binding communication between themselves by refusing to accept binding
updates from each other. Ingress filtering, on the other hand, does updates from each other. Ingress filtering, on the other hand, does
not help because the attacker is using its own address as the care-of not help because the attacker is using its own address as the care-of
address and is not spoofing source IP addresses. address and is not spoofing source IP addresses.
The protection adopted in MIPv6 Security Design is to authenticate The protection adopted in MIPv6 Security Design is to authenticate
(albeit weakly) the addresses by return routability (RR), which (albeit weakly) the addresses by return routability (RR), which
limits the topological locations from which the attack is possible limits the topological locations from which the attack is possible
(see Section 4.1). (see Section 4.1).
3.1.5 Basic Denial of Service Attacks 3.1.5 Basic Denial of Service Attacks
By sending spoofed binding updates, the attacker could redirect all By sending spoofed binding updates, the attacker could redirect all
packets sent between two IP nodes to a random or nonexistent packets sent between two IP nodes to a random or nonexistent address
address(es). This way, it might be able to stop or disrupt (or addresses). As a result, it might be able to stop or disrupt
communication between the nodes. This attack is serious because any communication between the nodes. This attack is serious because any
Internet node could be targeted, also fixed nodes belonging to the Internet node could be targeted, including fixed nodes belonging to
infrastructure (e.g., DNS servers) are vulnerable. Again, the the infrastructure (e.g., DNS servers) which are also vulnerable.
selected protection mechanism is return routability (RR). Again, the selected protection mechanism is return routability (RR).
3.1.6 Replaying and Blocking Binding Updates 3.1.6 Replaying and Blocking Binding Updates
Any protocol for authenticating binding update has to consider replay Any protocol for authenticating binding updates has to consider
attacks. That is, an attacker may be able to replay recent replay attacks. That is, an attacker may be able to replay recently
authenticated binding updates to the correspondent and, that way, authenticated binding updates to the correspondent and, consequently,
direct packets to the mobile node's previous location. Like spoofed direct packets to the mobile node's previous location. As with
binding updates, this could be used both for capturing packets and spoofed binding updates, this could be used both for capturing
for DoS. The attacker could capture the packets and impersonate the packets and for DoS. The attacker could capture the packets and
mobile node if it reserved the mobile's previous address after the impersonate the mobile node if it reserved the mobile's previous
mobile node has moved away and then replayed the previous binding address after the mobile node has moved away and then replayed the
update to redirect packets back to the previous location. previous binding update to redirect packets back to the previous
location.
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 location. Therefore, we believe that these attacks are not as
serious as ones that can be mounted from remote locations. The serious as ones that can be mounted from remote locations. The
limited lifetime of the Binding Cache entry and the associated nonces limited lifetime of the Binding Cache entry and the associated nonces
limit the time frame within which the replay attacks are possible. limit the time frame within which the replay attacks are possible.
Replay protection is provided by the sequence number and MAC in the
Binding Update. To not undermine this protection, correspondent
nodes must exercise care upon deleting a binding cache entry, as per
section 5.2.8 ("Preventing Replay Attacks") in [7].
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 overload
arbitrary Internet address with excessive amounts of packets. The an arbitrary Internet address with an excessive volume of packets
attacker could also target a network by redirecting data to one or (known as a 'bombing attack'). The attacker could also target a
more IP addresses within the network. There are two main variations network by redirecting data to one or more IP addresses within the
of flooding: basic flooding and return-to-the-home flooding. We network. There are two main variations of flooding: basic flooding
consider them separately. and return-to-home flooding. We consider them separately.
3.2.1 Basic flooding 3.2.1 Basic flooding
In the simplest attack, the attacker knows that there is a heavy data In the simplest attack, the attacker knows that there is a heavy data
stream from node A to B and redirects this to the target address C. stream from node A to B and redirects this to the target address C.
However, A would soon stop sending the data because it is not However, A would soon stop sending the data because it is not
receiving acknowledgments from B. receiving acknowledgments from B.
(B is attacker) (B is attacker)
+---+ 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: Basic Flooding Attack
A more sophisticated attacker would act itself as B; see Figure 4. A more sophisticated attacker would act itself as B; see Figure 4.
It would first subscribe to a data stream (e.g. a video stream) and It would first subscribe to a data stream (e.g. a video stream) and
then redirects this stream to the target address C. The attacker then redirects this stream to the target address C. The attacker
would even be able to spoof the acknowledgements. For example, would even be able to spoof the acknowledgements. For example,
consider a TCP stream. The attacker would perform the TCP handshake consider a TCP stream. The attacker would perform the TCP handshake
itself and thus know the initial sequence numbers. After redirecting itself and thus know the initial sequence numbers. After redirecting
the data to C, the attacker would continue to send spoofed the data to C, the attacker would continue to send spoofed
acknowledgments. It would even be able to accelerate the data rate acknowledgments. It would even be able to accelerate the data rate
by simulating a fatter pipe [10]. 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 without
additional measures.
During the Mobile IPv6 design process, the effectiveness of this During the Mobile IPv6 design process, the effectiveness of this
attack was debated. It was mistakenly assumed that the target node attack was debated. It was mistakenly assumed that the target node
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 not only a mobile one. What makes it particularly serious compared
to 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 compounded 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 denial of service (DDoS) attacks. Ingress filtering in the
attacker's local network prevents the spoofing of source addresses attacker's local network prevents the spoofing of source addresses
but the attack would still be possible by setting the Alternate but the attack would still be possible by setting the Alternate
care-of 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
4.1.2). Section 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. home network instead of the care-of-address or a visited network.
The attacker would claim to be a mobile with the home address equal The attacker would claim to be a mobile with the home address equal
to the target address. While claiming to be away from home, the to the target address. While claiming to be away from home, the
attacker would start downloading a data stream. The attacker would attacker would start downloading a data stream. The attacker would
then send a binding update cancellation (i.e. a request to delete then send a binding update cancellation (i.e. a request to delete the
the binding from the Binding Cache), or just allow the cache entry to binding from the Binding Cache), or just allow the cache entry to
expire. Either would redirect the data stream to the home network. expire. Either would redirect the data stream to the home network.
Just like when bombing a care-of-address, the attacker can keep the As when bombing a care-of-address, the attacker can keep the stream
stream alive and even increase data rate by spoofing acknowledgments. alive and even increase the data rate by spoofing acknowledgments.
When successful, the bombing attack against the home network is just When successful, the bombing attack against the home network is just
as serious as the one against a care-of-address. 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
4.1.1. Section 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
authentication, the easier it may be for an attacker to use the authentication, the easier it may be for an attacker to use the
protocol features to exhaust the mobile's or the correspondent's protocol features to exhaust the mobile's or the correspondent's
resources. resources.
3.3.1 Inducing Unnecessary Binding Updates 3.3.1 Inducing Unnecessary Binding Updates
When a mobile node receives an IP packet from a new correspondent via When a mobile node receives an IP packet from a new correspondent via
the home agent, it may initiate the binding update protocol. An the home agent, it may initiate the binding update protocol. An
attacker can exploit this by sending the mobile node a spoofed IP attacker can exploit this by sending the mobile node a spoofed IP
packet (e.g. ping or TCP SYN packet) that appears to come from a new packet (e.g. ping or TCP SYN packet) that appears to come from a new
correspondent node. Since the packet arrives via the home agent, the correspondent node. Since the packet arrives via the home agent, the
mobile node may start the binding update protocol with the mobile node may start the binding update protocol with the
correspondent node. The decision whether or not to initiate the correspondent node. The decision as to whether or not to initiate
binding update procedure may depend on several factors (including the 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 binding update protocol might even complete successfully. The
entries created in the Binding Cache are correct but useless. This entries created in the Binding Cache are correct but useless. In
way, the attacker can induce the mobile to execute the binding update this way, the attacker can induce the mobile to execute the binding
protocol unnecessarily, which can drain the mobile's resources. update 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 will complete successfully. By inducing a large number of
unnecessary binding updates, the attacker is able to consume the unnecessary binding updates, the attacker is able to consume the
target node's resources. target node's resources.
skipping to change at page 21, line 21 skipping to change at page 21, line 46
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) node is under DoS attack. A correspondent node (i.e., any IP node)
may 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 only send binding updates to
accept them from those addresses. Since it may be impossible for the or accept them from those addresses. Since it may be impossible for
IP layer to know about the protocol state in higher protocol layers, the IP layer to know about the protocol state in higher protocol
a good measure of the meaningfulness of the past communication is layers, a good measure of the meaningfulness of the past
probably per-address packet counts. Alternatively, Neighbor communication is probably per-address packet counts. Alternatively,
Discovery [2] (section 5.1, Conceptual Data Structures) defines the Neighbor Discovery [2] (section 5.1, Conceptual Data Structures)
Destination Cache as a set of entries about destinations to which defines the Destination Cache as a set of entries about destinations
traffic has been sent recently. Thus, implementors may wish to use to which traffic has been sent recently. Thus, implementors may wish
the information in the Destination Cache. 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 when such a route optimization procedure should be initiated. It
does indicate when it may justifiable to do so, but these hints are does indicate when it may justifiable to do so, but these hints are
not enough. This remains an area where more work is needed. not enough. This remains an area where more work is needed.
Obviously, given that route optimization is optional, any node that Obviously, given that route optimization is optional, any node that
finds the processing load excessive or unjustified may simply turn it finds the processing load excessive or unjustified may simply turn it
off (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 previously suggested that the target of a DoS attack may respond by
stopping route optimization for all or some communication. stopping route optimization for all or some communication.
Obviously, an attacker can exploit this fallback mechanism and force Obviously, an attacker can exploit this fallback mechanism and force
the target to use the less efficient home agent based routing. The the target to use the less efficient home agent based routing. The
attacker only needs to mount a noticeable DoS attack against the attacker only needs to mount a noticeable DoS attack against the
mobile or correspondent, and the target will default to non-optimized mobile or correspondent, and the target will default to non-optimized
routing. 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
skipping to change at page 23, line 16 skipping to change at page 23, line 37
| Attacker |-------------------->| Reflector | | Attacker |-------------------->| Reflector |
+----------+ +-----------+ +----------+ +-----------+
| |
| TCP SYN-ACK to HoA | TCP SYN-ACK to HoA
V V
+-----------+ +-----------+
| Flooding | | Flooding |
| target | | target |
+-----------+ +-----------+
Figure 5 Figure 5: Reflection Attack
A badly designed binding update protocol could also be used for A badly designed binding update protocol could also be used for
reflection: the correspondent would respond to a data packet by reflection: the correspondent would respond to a data packet by
initiating the binding update authentication protocol, which usually initiating the binding update authentication protocol, which usually
involves sending a packet to the home address. In that case, the involves sending a packet to the home address. In that case, the
reflection attack can be discouraged by copying the mobile's address reflection attack can be discouraged by copying the mobile's address
into the messages sent by the mobile to the correspondent. (The into the messages sent by the mobile to the correspondent. (The
mobile's source address is usually the same as the care-of address mobile's source address is usually the same as the care-of address
but an Alternative care-of address suboption can specify a different but an Alternative care-of address suboption can specify a different
care-of address.) Some of the early proposals for MIPv6 security used care-of address.) Some of the early proposals for MIPv6 security
this approach, and were prone to the reflection attacks. used this approach, and were prone to reflection attacks.
In some of the proposals for binding update authentication protocols, In some of the proposals for binding update authentication protocols,
the correspondent node responded to an initial message from the the correspondent node responded to an initial message from the
mobile with two packets (one to the home address, one to the care-of mobile with two packets (one to the home address, one to the care-of
address). It would have been possible to use this to amplify a address). It would have been possible to use this to amplify a
flooding attack by a factor of two. Furthermore, with public-key flooding attack by a factor of two. Furthermore, with public-key
authentication, the packets sent by the correspondent might have been authentication, the packets sent by the correspondent might have been
significantly larger than the one that triggers them. significantly larger than the one that triggers them.
These types of reflection and amplification can be avoided by These types of reflection and amplification can be avoided by
skipping to change at page 24, line 15 skipping to change at page 24, line 27
3.4 Classification of attacks 3.4 Classification of attacks
Sect. Attack name Target Sev. Mitigation Sect. Attack name Target Sev. Mitigation
--------------------------------------------------------------------- ---------------------------------------------------------------------
3.1.1 Basic address stealing MN Med. RR 3.1.1 Basic address stealing MN Med. RR
3.1.2 Stealing addresses of stationary nodes Any High RR 3.1.2 Stealing addresses of stationary nodes Any High RR
3.1.3 Future address stealing MN Low RR, lifetime 3.1.3 Future address stealing MN Low RR, lifetime
3.1.4 Attacks against Secrecy and Integrity MN Low RR, IPsec 3.1.4 Attacks against Secrecy and Integrity MN Low RR, IPsec
3.1.5 Basic Denial of Service Attacks Any Med. RR 3.1.5 Basic Denial of Service Attacks Any Med. RR
3.1.6 Replaying and Blocking Binding Updates MN Low lifetime, 3.1.6 Replaying and Blocking Binding Updates MN Low lifetime,
cookies sequence number,
MAC
3.2.1 Basic flooding Any High RR 3.2.1 Basic flooding Any High RR
3.2.2 Return-to-home flooding Any High RR 3.2.2 Return-to-home flooding Any High RR
3.3.1 Inducing Unnecessary Binding Updates MN, CN Med. heuristics 3.3.1 Inducing Unnecessary Binding Updates MN, CN Med. heuristics
3.3.2 Forcing Non-Optimized Routing MN Low heuristics 3.3.2 Forcing Non-Optimized Routing MN Low heuristics
3.3.3 Reflection and Amplification N/A Med. BU design 3.3.3 Reflection and Amplification N/A Med. BU design
Figure 6 Figure 6: Summary of Discussed Attacks
Figure 6 gives a summary of the discussed attacks. As it stands Figure 6 gives a summary of the attacks discussed. As it stands at
today, the return-to-the-home flooding and the induction of the time of writing, the return-to-the-home flooding and the
unnecessary binding updates look like the threats that we have the induction of unnecessary binding updates look like the threats
least amount of protection, compared to their severity. against which we have the smallest 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 the default way to secure Binding Updates with arbitrary could be the default way to secure Binding Updates with arbitrary
correspondent nodes. However, this turned out to be impossible. correspondent nodes. However, this turned out to be impossible.
Plain IPsec relies on an infrastructure for key management, which, to Plain IPsec relies on an infrastructure for key management, which, to
be usable with any arbitrary pair of nodes, would need to be global be usable with any arbitrary pair of nodes, would need to be global
in scope. Such a "global PKI" does not exist, nor is it expected to in scope. Such a "global PKI" does not exist, nor is it expected to
come into existence any time soon. come into existence any time soon.
skipping to change at page 25, line 33 skipping to change at page 25, line 48
Neighbor Discovery [13], although in this case only routers (not Neighbor Discovery [13], although in this case only routers (not
necessarily every single potential mobile node) need to secure such a necessarily every single potential mobile node) need to secure such a
certificate. Furthermore, checking all the signatures on the tree certificate. Furthermore, checking all the signatures on the tree
would place a considerable burden on the correspondent nodes, making would place a considerable burden on the correspondent nodes, making
route optimization prohibitive, or at least justifiable only in very route optimization prohibitive, or at least justifiable only in very
particular circumstances. Finally, it is not enough to simply check particular circumstances. Finally, it is not enough to simply check
if the mobile node is authorized to send binding updates containing a if the mobile node is authorized to send binding updates containing a
given Home Address, because to protect against flooding attacks the given Home Address, because to protect against flooding attacks the
care-of address must also be verified. care-of address must also be verified.
Relying on this same secure DNS infrastructure to verify Relying on this same secure DNS infrastructure to verify care-of-
care-of-addresses would be even harder than verifying home addresses. addresses would be even harder than verifying home addresses.
Instead, a different method would be required, e.g., a return Instead, a different method would be required, e.g., a return
routability procedure. If so, the obvious question is whether the routability procedure. If so, the obvious question is whether the
gargantuan cost of deploying the global secure DNS infrastructure is gargantuan cost of deploying the global secure DNS infrastructure is
worth the additional protection it affords, as compared to simply worth the additional protection it affords, as compared to simply
using return routability for both home address and care-of address using return routability for both home address and care-of address
verification. 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 <threats>. The goal has been to produce a design whose discussed in Section 3. The goal has been to produce a design with a
security is close to that of a static IPv4 based Internet, and whose level of security which is close to that of a static IPv4 based
cost in terms of packets, delay and processing is not excessive. The Internet, and with a cost in terms of packets, delay and processing
result is not what one would expect: the result is definitely not a that is not excessive. The result is not what one would expect: the
traditional cryptographic protocol. Instead, the result relies result is definitely not a traditional cryptographic protocol.
heavily on the assumption of an uncorrupted routing infrastructure, Instead, the result relies heavily on the assumption of an
and builds upon the idea of checking that an alleged mobile node is uncorrupted routing infrastructure, and builds upon the idea of
indeed reachable both through its home address and its checking that an alleged mobile node is indeed reachable both through
care-of-address. Furthermore, the lifetime of the state created at its home address and its care-of-address. Furthermore, the lifetime
the corresponded nodes is deliberately restricted to a few minutes, of the state created at the corresponded nodes is deliberately
in order to limit the potential ability of time shifting. restricted to a few minutes, in order to limit the potential threat
from time shifting.
In this section we describe the solution in reasonable detail (for In this section we describe the solution in reasonable detail (for
further details see the specification), starting from Return further details see the specification), starting from Return
Routability (Section 4.1), continuing with a discussion about state Routability (Section 4.1), continuing with a discussion about state
creation at the correspondent node (Section 4.2), and completing the creation at the correspondent node (Section 4.2), and completing the
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. RR is based on
means that a node verifies that there is a node that is able to the idea that a node should be able to verify that there is a node
respond to packets sent to a given address. The check yields false that is able to respond to packets sent to a given address. The
positives if the routing infrastructure is compromised or if there is check yields false positives if the routing infrastructure is
an attacker between the verifier and the address to be verified. compromised or if there is an attacker between the verifier and the
With these exceptions, it is assumed that a successful reply address to be verified. With these exceptions, it is assumed that a
indicates that there is indeed a node at the given address, and that successful reply indicates that there is indeed a node at the given
the node is willing to reply to the probes sent to it. address, and that 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 Init (CoTI) directly. The correspondent node replies to both of
these independently by sending a Home Test (HoT) in response to the these independently by sending a Home Test (HoT) in response to the
Home Test Init and a Care-of Test (CoT) in response to the Care-of Home Test Init and a Care-of Test (CoT) in response to the Care-of
Test Init. Finally, once the mobile node has received both the Home Test Init. Finally, once the mobile node has received both the Home
skipping to change at page 27, line 21 skipping to change at page 28, line 21
| |2b| CoT / / | |2b| CoT / /
| | | / / | | | / /
| | | 3) BU / / | | | 3) BU / /
V | V / / V | V / /
+------+ 1a) HoTI / / +------+ 1a) HoTI / /
| |<----------------/ / | |<----------------/ /
| CN | 2a) HoT / | CN | 2a) HoT /
| |------------------/ | |------------------/
+------+ +------+
Figure 7 Figure 7: Return Routability Packet Flow
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 Test, Binding Update > and < Care-of Test, Binding Update >. The
Home Test Init and Care-of Test Init packets are only needed to Home Test Init and Care-of Test Init packets are only needed to
trigger 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 state exhaustion DoS attacks (see Section 4.2). o avoidance of reflection and amplification (see Section 3.3.3), and
o 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 receives an
receives an IP packet from some arbitrary IP address. In a way, this unsolicited IP packet from some arbitrary IP address. In a way, this
is similar to a server receiving a TCP SYN from a previously unknown is similar to a server receiving a TCP SYN from a previously unknown
client. If the correspondent node would send two packets in response client. If the correspondent node were to send two packets in
to an initial trigger, that would create a DoS amplification effect, response to an initial trigger, that would provide the potential for
as discussed in Section 3.3.3. a DoS amplification effect, as discussed in Section 3.3.3.
Reflection avoidance is directly related. If the correspondent node
would reply to another address but the source address of the packet,
that would create a reflection effect. Thus, since the correspondent
node does not know better, the only safe way is to reply to the
received packet with just one packet, and to send the reply to the
source address of the received packet. Hence, two initial triggers
are needed instead of just one.
Let us now consider the two return routability tests separately. This scheme also avoids providing for a potential reflection attack.
If the correspondent node were to reply to an address other than the
source address of the packet, that would create a reflection effect.
Thus, the only safe mechanism possible for a naive correspondent is
to reply to each received packet with just one packet, and to send
the reply to the source address of the received packet. Hence, two
initial triggers are needed instead of just one.
Below, the derivation of cryptographic material from each of these is Let us now consider the two return routability tests separately. In
shown in a simplified manner. For the real formulas and more detail, the following sections, the derivation of cryptographic material from
please refer to [7]. each of these is shown in a simplified manner. For the real formulas
and more detail, please refer to [7].
4.1.1 Home Address check 4.1.1 Home Address check
The Home Address check consists of a Home Test (HoT) packet and a The Home Address check consists of a Home Test (HoT) packet and a
subsequent Binding Update (BU). It is triggered by the arrival of a subsequent Binding Update (BU). It is triggered by the arrival of a
Home Test Init (HoTI). A correspondent node replies to a Home Test Home Test Init (HoTI). A correspondent node replies to a Home Test
Init by sending a Home Test to the source address of the Home Test Init by sending a Home Test to the source address of the Home Test
Init. The source address is assumed to be the home address of a Init. The source address is assumed to be the home address of a
mobile node, and therefore the Home Test is assumed to be tunneled by mobile node, and therefore the Home Test is assumed to be tunneled by
the Home Agent to the mobile node. The Home Test contains a the Home Agent to the mobile node. The Home Test contains a
cryptographically generated token, home keygen token, which is formed cryptographically generated token, home keygen token, which is formed
by calculating a hash function over the concatenation of a secret key by calculating a hash function over the concatenation of a secret key
Kcn known only by the correspondent node, the source address of the Kcn known only by the correspondent node, the source address of the
Home Test Init packet, and a nonce. Home Test Init packet, and a nonce.
home keygen token = hash(Kcn | home address | nonce | 0) home keygen token = hash(Kcn | home address | nonce | 0)
An index to the nonce is also included in the Home Test packet, An index to the nonce is also included in the Home Test packet,
allowing the correspondent node to easier find the appropriate nonce. allowing the correspondent node to find the appropriate nonce more
easily.
The token allows the correspondent node to make sure that the The token allows the correspondent node to make sure that any binding
subsequently received binding update is created by a node that has update received subsequently has been created by a node that has seen
seen the Home Test packet; see Section 4.2. the Home Test packet; see Section 4.2. 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 forwards the packet to the mobile node. This path is taken inside an
the IPsec ESP protected tunnel, making it impossible for the IPsec ESP protected tunnel, making it impossible for the outsiders to
outsiders to learn the contents of the packet. 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, the
that would be unnecessary. However, in most practical settings the additional protection would be unnecessary. However, in most
network is likely to be more secure near the Home Agent than near the practical settings the network is likely to be more secure near the
Mobile Node. For example, if the home agent hosts a virtual home Home Agent than near the Mobile Node. For example, if the home agent
link and the mobile nodes are never actually at home, an eavesdropper hosts a virtual home link and the mobile nodes are never actually at
should be close to the correspondent node or on the path between the home, an eavesdropper should be close to the correspondent node or on
correspondent node and the home agent, since it could not eavesdrop the path between the correspondent node and the home agent, since it
at the home agent. If the correspondent node is a big server, all could not eavesdrop at the home agent. If the correspondent node is
the links on the path between it and the Home Agent are likely to be a major server, all the links on the path between it and the Home
fairly secure. On the other hand, the Mobile Node is probably using Agent are likely to be fairly secure. On the other hand, the Mobile
wireless access technology, making it sometimes trivial to eavesdrop Node is probably using wireless access technology, making it
its access link. Thus, it is fairly easy to eavesdrop packets that sometimes trivial to eavesdrop on its access link. Thus, it is
arrive at the mobile node. Consequently, protecting the HA-MN path fairly easy to eavesdrop on packets that arrive at the mobile node.
is likely to provide real security benefits even when the CN-HA path Consequently, protecting the HA-MN path is likely to provide real
remains unprotected. security benefits even when the CN-HA path 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-Address
very similar to the Home check. The only difference is that now the check is very similar to the Home check. The only difference is that
source address of the received Care-of Test Init packet is assumed to now the source address of the received Care-of Test Init packet is
be the care-of-address of the mobile node. Furthermore, the token is assumed to be the care-of-address of the mobile node. Furthermore,
created in a slightly different manner in order to make it impossible the token is created in a slightly different manner in order to make
to use home tokens for care-of tokens or vice versa. it impossible to use home tokens for care-of tokens or vice versa.
care-of keygen token = hash(Kcn | care-of address | nonce | 1) care-of keygen token = hash(Kcn | care-of address | nonce | 1)
The Care-of Test traverses only one leg, directly from the The Care-of Test traverses only one leg, directly from the
correspondent node to the mobile node. It remains unprotected all correspondent node to the mobile node. It remains unprotected all
along the way, making it vulnerable to eavesdroppers near the along the way, making it vulnerable to eavesdroppers near the
correspondent node, on the path from the correspondent node to the correspondent node, on the path from the correspondent node to the
mobile node, or near the mobile node. mobile node, or near the mobile node.
4.1.3 Forming the first Binding Update 4.1.3 Forming the first Binding Update
When the mobile node has received both the Home Test and Care-of Test When the mobile node has received both the Home Test and Care-of Test
messages, it creates a binding key Kbm by taking a hash function over messages, it creates a binding key Kbm by taking a hash function over
the concatenation of the tokens received. the concatenation of the tokens received.
This key is used to protect the first and the subsequent binding This key is used to protect the first and the subsequent binding
updates, as long as the key remains valid. updates, as long as the key remains valid.
Note that the key Kbm is available to anyone that is able to receive Note that the key Kbm is available to anyone that is able to receive
both the Care-of Test and Home Test messages. However, they are both the Care-of Test and Home Test messages. However, they are
normally routed through different routes through the network, and the normally routed by different routes through the network, and the Home
Home Test is transmitted over an encrypted tunnel from the home agent Test is transmitted over an encrypted tunnel from the home agent to
to the mobile node (see also Section 5.4). the mobile node (see also Section 5.4).
4.2 Creating state safely 4.2 Creating state safely
The correspondent node may remain stateless until it receives the The correspondent node may remain stateless until it receives the
first Binding Update. That is, it does not need to record receiving first Binding Update. That is, it does not need to record receiving
and replying to the Home Test Init and Care-of Test Init messages. and replying to the Home Test Init and Care-of Test Init messages.
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
skipping to change at page 30, line 20 skipping to change at page 31, line 22
procedure is to ensure that there is indeed a mobile node that has procedure is to ensure that there is indeed a mobile node that has
recently received a Home Test and a Care-of Test that were sent to recently received a Home Test and a Care-of Test that were sent to
the claimed home and care-of-addresses, respectively, and to make the claimed home and care-of-addresses, respectively, and to make
sure that the correspondent node does not unnecessarily spend CPU or sure that the correspondent node does not unnecessarily spend CPU or
other 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 information so that relevant state can be created. The binding
update 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
to the source address used in the Care-of Test Init message. Source address: The care-of address specified in the Binding Update
Notice that this applies to the effective Care-of Address of the must be equal to the source address used in the Care-of Test Init
Binding Update. In particular, if the Binding Update includes an message. Notice that this applies to the effective Care-of
Alternate Care-of Address (AltCoA) [7], the effective CoA is, of Address of the Binding Update. In particular, if the Binding
course, this AltCoA. Thus, the Care-of Test Init must have Update includes an Alternate Care-of Address (AltCoA) [7], the
originated from the AltCoA. effective CoA is, of course, this AltCoA. Thus, the Care-of Test
The home address specified in the Binding Update must be equal to Init must have originated from the AltCoA.
the source address used in the Home Test Init message.
These are copied over from the Home Test and Care-of Test Home address: The home address specified in the Binding Update must
messages, and together with the other information they allow the be equal to the source address used in the Home Test Init message.
correspondent node to re-create the tokens sent in the Home Test
and Care-of Test messages and used for creating Kbm. Without them Two nonce indices: These are copied over from the Home Test and
the correspondent node might need to try the 2-3 latest nonces, Care-of Test messages, and together with the other information
leading to unnecessary resource consumption. they allow the correspondent node to re-create the tokens sent in
The binding update is authenticated by computing a MAC function the Home Test and Care-of Test messages and used for creating Kbm.
over the care-of-address, the correspondent node's address and the Without them the correspondent node might need to try the 2-3
binding update message itself. The MAC is keyed with the key Kbm. latest nonces, leading to unnecessary resource consumption.
Message Authentication Code (MAC): The binding update is
authenticated by computing a MAC function over the care-of-
address, the correspondent node's address and the binding update
message itself. The MAC is keyed with the key Kbm.
Given the addresses, the nonce indices and thereby the nonces, and Given the addresses, the nonce indices and thereby the nonces, and
the key Kcn, the correspondent node can re-create the home and the key Kcn, the correspondent node can re-create the home and
care-of tokens at the cost of a few memory lookups and computation of care-of tokens at the cost of a few memory lookups and computation of
one MAC and one hash function. one MAC and one hash function.
Once the correspondent node has re-created the tokens, it hashes the Once the correspondent node has re-created the tokens, it hashes the
tokens together, giving the key Kbm. If the Binding Update is tokens together, giving the key Kbm. If the Binding Update is
authentic, Kbm is cached together with the binding. This key is then authentic, Kbm is cached together with the binding. This key is then
used to verify the MAC that protects integrity and origin of the used to verify the MAC that protects integrity and origin of the
skipping to change at page 31, line 17 skipping to change at page 32, line 24
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 responsible for retransmissions. That is, the mobile node should
keep 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 with 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
point of time but not later. If the Home Test had an infinite or a point of time but not later. If the Home Test had an infinite or a
long lifetime, that would allow the attacker to perform a time long lifetime, that would allow the attacker to perform a time
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 on 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. no longer able to eavesdrop on 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. threats, the validity of the tokens is limited to a few minutes.
This effectively limits the validity of the key Kbm and the lifetime This effectively limits the validity of the key Kbm and the lifetime
of 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 purely functional
of view, thereby representing overhead. What is worse, though, is point of view, thereby representing overhead. What is worse, though,
that they make the home agent a single point of failure. That is, if is that they make the home agent a single point of failure. That is,
the Home Test Init / Home Test messages were not needed, the existing if the Home Test Init / Home Test messages were not needed, the
connections from a mobile node to other nodes could continue even existing connections from a mobile node to other nodes could continue
when the home agent fails, but the current design forces the bindings even when the home agent fails, but the current design forces the
to expire after a few minutes. bindings to expire after a few minutes.
This concludes our walkthrough of the selected security design. The This concludes our walkthrough of the selected security design. The
cornerstones of the design were the employment of the return cornerstones of the design were the employment of the return
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 known at the time the design was
completed in fall 2002. It should be noted that this section does completed in fall 2002. It should be noted that this section does
not 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, the 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.
The known residual threats as compared with IPv4 are discussed in The known residual threats as compared with IPv4 are discussed in
Section 5.1. Considerations related to the application of IPsec to Section 5.1. Considerations related to the application of IPsec to
authorize route optimization are discussed in Section 5.2. Section authorize route optimization are discussed in Section 5.2.
5.3 discusses an attack against neighboring nodes. Finally, Section Section 5.3 discusses an attack against neighboring nodes. Finally,
5.4 deals with the special case of two mobile nodes conversing and Section 5.4 deals with the special case of two mobile nodes
performing the route optimization procedure with each other. conversing and 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 for as long as the binding lasts, or, alternatively, is able
delay a return-to-the-home flooding attack (Section 3.2.2) until the to delay a return-to-home flooding attack (Section 3.2.2) until the
binding expires. This is a difference from IPv4 where an attacker binding expires. This is a difference from IPv4 where an attacker
may continue an attack only as long as it is at the path between the may continue an attack only as long as it is on the path between the
two 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 equivalently
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
3.3). In particular, inducing unnecessary binding updates could (Section 3.3). In particular, inducing unnecessary binding updates
potentially be a severe attack, but this would be more due to faulty could potentially be a severe attack, but this would be most likely
implementations. As an extreme measure, a correspondent node can due to faulty implementations. As an extreme measure, a
protect against these attacks by turning off route optimization. If correspondent node can protect against these attacks by turning off
so, it becomes obvious that the only residual attack against which route optimization. If so, it becomes obvious that the only residual
there is no clear-cut prevention (other than its severe limitation as attack against which there is no clear-cut prevention (other than its
currently specified) is the time shifting attack mentioned above. severe limitation as 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, which implied the ability to run the protocol without
security infrastructure. An alternative would have been to rely on any existing security infrastructure. An alternative would have been
existing trust relationships, perhaps in the form of a special to rely on existing trust relationships, perhaps in the form of a
purpose Public Key Infrastructure in conjunction with IPsec. That special purpose Public Key Infrastructure in conjunction with IPsec.
would have limited scalability, making route optimization available That would have limited scalability, making route optimization
only in environments where it is possible to create appropriate IPsec available only in environments where it is possible to create
security associations between the mobile nodes and the corresponding appropriate IPsec security associations between the mobile nodes and
nodes. the corresponding 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-
pre-established keys with the mobile node, that would be the case. 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. necessarily sufficient for accepting Binding Updates.
Home Address Check: If one wants to replace the home address check Home Address Check: If one wants to replace the home address check
with cryptographic credentials, these must carry proper with cryptographic credentials, these must carry proper
authorization for the specific home address, and care must be authorization for the specific home address, and care must be
taken to make sure that the issuer of the certificate is entitled taken to make sure that the issuer of the certificate is entitled
to express such authorization. At the time of the design work, to express such authorization. At the time of the design work,
the route optimization security design team was not aware of the route optimization security design team was not aware of
standardized certificate formats to do this, although more recent standardized certificate formats to do this, although more recent
skipping to change at page 35, line 21 skipping to change at page 36, line 25
mobile node and correspondent node. On the other hand, the mobile node and correspondent node. On the other hand, the
specification is carefully written to allow the creation of the specification is carefully written to allow the creation of the
binding management key Kbm through some different means. binding management key Kbm through some different means.
Accordingly, where an appropriate relationship exists between a Accordingly, where an appropriate relationship exists between a
mobile node and a correspondent node, the use of IPsec is possible, mobile node and a correspondent node, the use of IPsec is possible,
and is, in fact, being pursued in more recent work. and is, in fact, being pursued in more recent work.
5.3 Pretending to be one's neighbor 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 neighboring node. To launch this attack, the mobile node establishes
establishes route optimization with some arbitrary correspondent route optimization with some arbitrary correspondent node. While
node. While performing the return routability tests and creating the performing the return routability tests and creating the binding
binding management key Kbm, the attacker uses its real home address management key Kbm, the attacker uses its real home address but a
but a faked care-of address. Indeed, the care-of address would be faked care-of address. Indeed, the care-of address would be the
the address of the neighboring node on the local link. The attacker address of the neighboring node on the local link. The attacker is
is able to create the binding since it receives a valid Home Test 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 on the Care-of Test as it
on the local link. appears 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 practice. 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.
skipping to change at page 36, line 4 skipping to change at page 37, line 8
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
simultaneously in the mobile node and the correspondent node roles. simultaneously in the mobile node and the correspondent node roles.
In the correspondent node role, the nodes are vulnerable to attackers In the correspondent node role, the nodes are vulnerable to attackers
that are co-located at the same link. Such an attacker is able to that are co-located at the same link. Such an attacker is able to
learn both the Home Test and Care-of Test sent by the mobile node, learn both the Home Test and Care-of Test sent by the mobile node,
and therefore it is able to spoof the location of the other mobile and therefore it is able to spoof the location of the other mobile
host to the neighboring one. What is worse is that the attacker can host to the neighboring one. What is worse is that the attacker can
obtain a valid Care-of Test itself, combine it with the Home Test, obtain a valid Care-of Test itself, combine it with the Home Test,
and the claim to the neighboring node that the other node has just and then claim to the neighboring node that the other node has just
arrived at the same link. arrived at the same link.
There is an easy way to avoid this attack. In the correspondent node There is an easy way to avoid this attack. In the correspondent node
role, the mobile node should tunnel the sent Home Test messages role, the mobile node should tunnel the Home Test messages which it
through its home agent. This prevents the co-located attacker from sends through its home agent. This prevents the co-located attacker
learning any valid Home Test messages. from learning any valid Home Test messages.
6. Conclusions 6. Conclusions
In this document we have discussed the security design rationale for In this document we have discussed the security design rationale for
the Mobile IPv6 Route Optimization. We have tried to describe the the Mobile IPv6 Route Optimization. We have tried to describe the
dangers created by Mobile IP Route Optimization, the security goals dangers created by Mobile IP Route Optimization, the security goals
and background of the design, and the actual mechanisms employed. and background of the design, and the actual mechanisms employed.
We started the discussion with a background tour to the IP routing We started the discussion with a background tour to the IP routing
architecture the definition of the mobility problem. After that we architecture the definition of the mobility problem. After that we
covered the dimensions of the danger: the targets, the time shifting covered the avenues of attack: the targets, the time shifting
abilities, and the possible locations of an attacker. We outlined a abilities, and the possible locations of an attacker. We outlined a
number of identified threat scenarios, and discussed how they are number of identified threat scenarios, and discussed how they are
mitigated in the current design. Finally, in Section 4 we gave an mitigated in the current design. Finally, in Section 4 we gave an
overview of the actual mechanisms employed, and the rational behind overview of the actual mechanisms employed, and the rational behind
them. them.
As far as we know today, the only significant difference between the As far as we know today, the only significant difference between the
security of an IPv4 internet and that of an internet with Mobile IPv6 security of an IPv4 internet and that of an internet with Mobile IPv6
(and route optimization): time shifting attacks. Nevertheless, these (and route optimization): time shifting attacks. Nevertheless, these
are severely retricted in the current design. are severely restricted in the current design.
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 with 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
5.3. Francis Dupont for first discussing the case of two mobile Section 5.3. Francis Dupont for first discussing the case of two
nodes talking to each other (Section 5.4) and sundry other comments. mobile nodes talking to each other (Section 5.4) and sundry other
Pekka Savola for his help in Section 1.1.1. comments. Pekka Savola for his help in Section 1.1.1. Elwyn Davies
for his thorough editorial review.
8 Informative References 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] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[3] Narten, T. and R. Draves, "Privacy Extensions for Stateless [3] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[4] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines [4] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines
and Philosophy", RFC 3439, December 2002. and Philosophy", RFC 3439, December 2002.
[5] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource [5] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record (RR)", RFC 3445, December 2002. Record (RR)", RFC 3445, December 2002.
[6] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [6] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in [7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[8] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to [8] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004. Agents", RFC 3776, June 2004.
[9] Chiappa, J., "Will The Real "End-End Principle" Please Stand [9] Chiappa, J., "Will The Real "End-End Principle" Please Stand
Up?", date unknown. Up?", date unknown.
[10] 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.
[11] Nikander, P., "Denial-of-Service, Address Ownership, and [11] Nikander, P., "Denial-of-Service, Address Ownership, and
Early 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,
2467, pages 12-26, Springer, 2002. LNCS 2467, pages 12-26, Springer, 2002.
[12] 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.
[13] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, [13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 Neighbor Discovery (SEND)", RFC 3971, March 2005.
(work in progress), July 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 Laboratories Microsoft Corporation
16 Network Circle One Microsoft Way
Menlo Park 94025 Redmond, WA 98052
USA USA
Phone: Email: gabriel_montenegro_2000@yahoo.com
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 Rights 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
skipping to change at page 40, line 41 skipping to change at page 41, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
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/