Request for Comments: 4225 J. Arkko
Category: Informational Ericsson Research NomadicLab
T. Aura
Microsoft Research
G. Montenegro
Microsoft Corporation
E. Nordmark
Sun Microsystems
December 2005
Mobile IP Version 6 Route Optimization Security Design Background
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document is an account of the rationale behind the Mobile IPv6
(MIPv6) Route Optimization security design. The purpose of this
document is to present the thinking and to preserve the reasoning
behind the Mobile IPv6 security design in 2001 - 2002.
The document has two target audiences: (1) helping MIPv6 implementors
to better understand the design choices in MIPv6 security procedures,
and (2) allowing people dealing with mobility or multi-homing to
avoid a number of potential security pitfalls in their designs.
Table of Contents
1. Introduction ....................................................3
1.1. Assumptions about the Existing IP Infrastructure ...........4
1.2. The Mobility Problem and the Mobile IPv6 Solution ..........6
1.3. Design Principles and Goals ................................8
1.3.1. End-to-End Principle ..................................8
1.3.2. Trust Assumptions .....................................8
1.3.3. Protection Level ......................................8
1.4. About Mobile IPv6 Mobility and its Variations ..............9
2. Avenues of Attack ...............................................9
2.1. Target ....................................................10
2.2. Timing ....................................................10
2.3. Location ..................................................11
3. Threats and Limitations ........................................11
3.1. Attacks Against Address ’Owners’ ("Address Stealing").. ...12
3.1.1. Basic Address Stealing ...............................12
3.1.2. Stealing Addresses of Stationary Nodes ...............13
3.1.3. Future Address Sealing ...............................14
3.1.4. Attacks against Secrecy and Integrity ................15
3.1.5. Basic Denial-of-Service Attacks ......................16
3.1.6. Replaying and Blocking Binding Updates ...............16
3.2. Attacks Against Other Nodes and Networks (Flooding) .......16
3.2.1. Basic Flooding .......................................17
3.2.2. Return-to-Home Flooding ..............................18
3.3. Attacks against Binding Update Protocols ..................18
3.3.1. Inducing Unnecessary Binding Updates .................19
3.3.2. Forcing Non-Optimized Routing ........................20
3.3.3. Reflection and Amplification .........................21
3.4. Classification of Attacks .................................22
3.5. Problems with Infrastructure-Based Authorization ..........23
4. Solution Selected for Mobile IPv6 ..............................24
4.1. Return Routability ........................................24
4.1.1. Home Address Check ...................................26
4.1.2. Care-of-Address Check ................................27
4.1.3. Forming the First Binding Update .....................27
4.2. Creating State Safely .....................................28
4.2.1. Retransmissions and State Machine ....................29
4.3. Quick expiration of the Binding Cache Entries .............29
5. Security Considerations ........................................30
5.1. Residual Threats as Compared to IPv4 ......................31
5.2. Interaction with IPsec ....................................31
5.3. Pretending to Be One’s Neighbor ...........................32
5.4. Two Mobile Nodes Talking to Each Other ....................33
6. Conclusions ....................................................33
7. Acknowledgements ...............................................34
8. Informative References .........................................34
1. Introduction
Mobile IPv4 is based on the idea of supporting mobility on top of
existing IP infrastructure, without requiring any modifications to
the routers, the applications, or the stationary end hosts. However,
in Mobile IPv6 [6] (as opposed to Mobile IPv4), the stationary end
hosts may provide support for mobility, i.e., route optimization. In
route optimization, a correspondent node (CN) (i.e., a peer for a
mobile node) learns a binding between the mobile node’s stationary
home address and its current temporary care-of address. This binding
is then used to modify the handling of outgoing (as well as the
processing of incoming) packets, leading to security risks. The
purpose of this document is to provide a relatively compact source
for the background assumptions, design choices, and other information
needed to understand the route optimization security design. This
document does not seek to compare the relative security of Mobile
IPv6 and other mobility protocols, or to list all the alternative
security mechanisms that were discussed during the Mobile IPv6 design
process. For a summary of the latter, we refer the reader to [1].
Even though incidental implementation suggestions are included for
illustrative purposes, the goal of this document is not to provide a
guide to implementors. Instead, it is to explain the design choices
and rationale behind the current route optimization design. The
authors participated in the design team that produced the design and
hope, via this note, to capture some of the lessons and reasoning
behind that effort.
The authors’ intent is to document the thinking behind that design
effort as it was. Even though this note may incorporate more recent
developments in order to illustrate the issues, it is not our intent
to present a new design. Rather, along with the lessons learned,
there is some effort to clarify differing opinions, questionable
assumptions, or newly discovered vulnerabilities, should such new
information be available today. This is also very important, because
it may benefit the working group’s hindsight as it revises or
improves the Mobile IPv6 specification.
To fully understand the security implications of the relevant design
constraints, it is necessary to explore briefly the nature of the
existing IP infrastructure, the problems Mobile IP aims to solve, and
the design principles applied. In the light of this background, we
can then explore IP-based mobility in more detail and have a brief
look at the security problems. The background is given in the rest
of this section, starting from Section 1.1.
Although the introduction in Section 1.1 may appear redundant to
readers who are already familiar with Mobile IPv6, it may be valuable
to read it anyway. The approach taken in this document is very
different from that in the Mobile IPv6 specification. That is, we
have explicitly aimed to expose the implicit assumptions and design
choices made in the base Mobile IPv6 design, while the Mobile IPv6
specification aims to state the result of the design. By
understanding the background, it is much easier to understand the
source of some of the related security problems, and to understand
the limitations intrinsic to the provided solutions.
In particular, this document explains how the adopted design for
"Return Routability" (RR) protects against the identified threats
(Section 3). This is true except for attacks on the RR protocol
itself, which require other countermeasures based on heuristics and
judicious implementation (Section 3.3).
The rest of this document is organized as follows: after this
introductory section, we start by considering the avenues of attack
in Section 2. The security problems and countermeasures are studied
in detail in Section 3. Section 4 explains the overall operation and
design choices behind the current security design. Section 5
analyzes the design and discuss the remaining threats. Finally,
Section 6 concludes this document.
1.1. Assumptions about the Existing IP Infrastructure
One of the design goals in the Mobile IP design was to make mobility
possible without changing too much. This was especially important
for IPv4, with its large installed base, but the same design goals
were inherited by Mobile IPv6. Some alternative proposals take a
different approach and propose larger modifications to the Internet
architecture (see Section 1.4).
To understand Mobile IPv6, it is important to understand the MIPv6
design view of the base IPv6 protocol and infrastructure. The most
important base assumptions can be expressed as follows:
1. The routing prefixes available to a node are determined by its
current location, and therefore the node must change its IP
address as it moves.
2. The routing infrastructure is assumed to be secure and well
functioning, delivering packets to their intended destinations as
identified by destination address.
Although these assumptions may appear to be trivial, let us explore
them a little further. First, in current IPv6 operational practice
the IP address prefixes are distributed in a hierarchical manner.
This limits the number of routing table entries each individual
router needs to handle. An important implication is that the
topology determines what globally routable IP addresses are available
at a given location. That is, the nodes cannot freely decide what
globally routable IP address to use; they must rely on the routing
prefixes served by the local routers via Router Advertisements or by
a DHCP server. In other words, IP addresses are just what the name
says, addresses (i.e., locators).
Second, in the current Internet structure, the routers collectively
maintain a distributed database of the network topology and forward
each packet towards the location determined by the destination
address carried in the packet. To maintain the topology information,
the routers must trust each other, at least to a certain extent. The
routers learn the topology information from the other routers, and
they have no option but to trust their neighbor routers about distant
topology. At the borders of administrative domains, policy rules are
used to limit the amount of perhaps faulty routing table information
received from the peer domains. While this is mostly used to weed
out administrative mistakes, it also helps with security. The aim is
to maintain a reasonably accurate idea of the network topology even
if someone is feeding faulty information to the routing system.
In the current Mobile IPv6 design, it is explicitly assumed that the
routers and the policy rules are configured in a reasonable way, and
that the resulting routing infrastructure is trustworthy enough.
That is, it is assumed that the routing system maintains accurate
information of the network topology, and that it is therefore able to
route packets to their destination locations. If this assumption is
broken, the Internet itself is broken in the sense that packets go to
wrong locations. Such a fundamental malfunction of the Internet
would render hopeless any other effort to assure correct packet
delivery (e.g., any efforts due to Mobile IP security
considerations).
1.1.1. A Note on Source Addresses and Ingress Filtering
Some of the threats and attacks discussed in this document take
advantage of the ease of source address spoofing. That is, in the
current Internet it is possible to send packets with a false source
IP address. The eventual introduction of ingress filtering is
assumed to prevent this. When ingress filtering is used, traffic
with spoofed addresses is not forwarded. This filtering can be
applied at different network borders, such as those between an
Internet service provider (ISP) and its customers, between downstream
and upstream ISPs, or between peer ISPs [5]. Obviously, the
granularity of ingress filters specifies how much you can "spoof
inside a prefix". For example, if an ISP ingress filters a
customer’s link but the customer does nothing, anything inside the
customer’s /48 prefix could be spoofed. If the customer does
filtering at LAN subnets, anything inside the /64 prefixes could be
spoofed. Despite the limitations imposed by such "in-prefix
spoofing", in general, ingress filtering enables traffic to be
traceable to its real source network [5].
However, ingress filtering helps if and only if a large part of the
Internet uses it. Unfortunately, there are still some issues (e.g.,
in the presence of site multi-homing) that, although not
insurmountable, do require careful handling, and that are likely to
limit or delay its usefulness [5].
1.2. The Mobility Problem and the Mobile IPv6 Solution
The Mobile IP design aims to solve two problems at the same time.
First, it allows transport layer sessions (TCP connections, UDP-
based transactions) to continue even if the underlying host(s) move
and change their IP addresses. Second, it allows a node to be
reached through a static IP address, a home address (HoA).
The latter design choice can also be stated in other words: Mobile
IPv6 aims to preserve the identifier nature of IP addresses. That
is, Mobile IPv6 takes the view that IP addresses can be used as
natural identifiers of nodes, as they have been used since the
beginning of the Internet. This must be contrasted to proposed and
existing alternative designs where the identifier and locator natures
of the IP addresses have been separated (see Section 1.4).
The basic idea in Mobile IP is to allow a home agent (HA) to work as
a stationary proxy for a mobile node (MN). Whenever the mobile node
is away from its home network, the home agent intercepts packets
destined to the node and forwards the packets by tunneling them to
the node’s current address, the care-of address (CoA). The transport
layer (e.g., TCP, UDP) uses the home address as a stationary
identifier for the mobile node. Figure 1 illustrates this basic
arrangement.
The basic solution requires tunneling through the home agent, thereby
leading to longer paths and degraded performance. This tunneling is
sometimes called triangular routing since it was originally planned
that the packets from the mobile node to its peer could still
traverse directly, bypassing the home agent.
+----+ +----+
| MN |=#=#=#=#=#=#=#=#=tunnel=#=#=#=#=#=#=#=#|#HA |
+----+ ____________ +-#--+
| CoA ___/ \_____ # Home Link
-+-------/ Internet * * *-*-*-*-#-#-#-#-----
| * * | * Home Address
\___ * * _____/ + * -+
\_____*______/ | MN |
* + - -+
+----+
| CN | Data path as * * * *
+----+ it appears to correspondent node
Real data path # # # #
Figure 1. Basic Mode of Operation in Mobile IPv6
To alleviate the performance penalty, Mobile IPv6 includes a mode of
operation that allows the mobile node and its peer, a correspondent
node (CN), to exchange packets directly, bypassing the home agent
completely after the initial setup phase. This mode of operation is
called route optimization (RO). When route optimization is used, the
mobile node sends its current care-of address to the correspondent
node, using binding update (BU) messages. The correspondent node
stores the binding between the home address and care-of address into
its Binding Cache.
Whenever MIPv6 route optimization is used, the correspondent node
effectively functions in two roles. Firstly, it is the source of the
packets it sends, as usual. Secondly, it acts as the first router
for the packets, effectively performing source routing. That is,
when the correspondent node is sending out packets, it consults its
MIPv6 route optimization data structures and reroutes the packets, if
necessary. A Binding Cache Entry (BCE) contains the home address and
the care-of address of the mobile node, and records the fact that
packets destined to the home address should now be sent to the
destination address. Thus, it represents a local routing exception.
The packets leaving the correspondent node are source routed to the
care-of address. Each packet includes a routing header that contains
the home address of the mobile node. Thus, logically, the packet is
first routed to the care-of address and then, virtually, from the
care-of address to the home address. In practice, of course, the
packet is consumed by the mobile node at the care-of address; the
header just allows the mobile node to select a socket associated with
the home address instead of one with the care-of address. However,
the mechanism resembles source routing, as there is routing state
involved at the correspondent node, and a routing header is used.
Nevertheless, this routing header is special (type 2) to avoid the
risks associated with using the more general (type 0) variant.
1.3. Design Principles and Goals
The MIPv6 design and security design aimed to follow the end-to-end
principle, to notice the differences in trust relationships between
the nodes, and to be explicit about delivering a practical (instead
of an over-ambitious) level of protection.
1.3.1. End-to-End Principle
Perhaps the leading design principle for Internet protocols is the
so-called end-to-end principle [4][11]. According to this principle,
it is beneficial to avoid polluting the network with state, and to
limit new state creation to the involved end nodes.
In the case of Mobile IPv6, the end-to-end principle is applied by
restricting mobility-related state primarily to the home agent.
Additionally, if route optimization is used, the correspondent nodes
also maintain a soft state relating to the mobile nodes’ current
care-of addresses, the Binding Cache. This can be contrasted to an
approach that would use individual host routes within the basic
routing system. Such an approach would create state on a huge number
of routers around the network. In Mobile IPv6, only the home agent
and the communicating nodes need to create state.
1.3.2. Trust Assumptions
In the Mobile IPv6 security design, different approaches were chosen
for securing the communication between the mobile node and its home
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
agent know each other through a prior arrangement, e.g., due to a
business relationship. In contrast, it was strictly assumed that the
mobile node and the correspondent node do not need to have any prior
arrangement, thereby allowing Mobile IPv6 to function in a scalable
manner, without requiring any configuration at the correspondent
nodes.
1.3.3. Protection Level
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
period 2001 - 2002. In particular, that means that there is little
protection against attackers that are able to attach themselves
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
the communication path between two arbitrary nodes, it was able to
disrupt, modify, and eavesdrop all the traffic between the two nodes,
unless IPsec protection was used. Even when IPsec was used, the
attacker was still able to block communication selectively by simply
dropping the packets. The attacker in control of a router between
the two nodes could also mount a flooding attack by redirecting the
data flows between the two nodes (or, more practically, an equivalent
flow of bogus data) to a third party.
1.4. About Mobile IPv6 Mobility and its Variations
Taking a more abstract angle, IPv6 mobility can be defined as a
mechanism for managing local exceptions to routing information in
order to direct packets that are sent to one address (the home
address) to another address (the care-of address). It is managing in
the sense that the local routing exceptions (source routes) are
created and deleted dynamically, according to instructions sent by
the mobile node. It is local in the sense that the routing
exceptions are valid only at the home agent, and in the correspondent
nodes if route optimization is used. The created pieces of state are
exceptions in the sense that they override the normal topological
routing information carried collectively by the routers.
Using the terminology introduced by J. Noel Chiappa [14], we can say
that the home address functions in the dual role of being an end-
point identifier (EID) and a permanent locator. The care-of address
is a pure, temporary locator, which identifies the current location
of the mobile node. The correspondent nodes effectively perform
source routing, redirecting traffic destined to the home address to
the care-of address. This is even reflected in the packet structure:
the packets carry an explicit routing header.
The relationship between EIDs and permanent locators has been
exploited by other proposals. Their technical merits and security
problems, however, are beyond the scope of this document.
2. Avenues of Attack
From the discussion above, it should now be clear that the dangers
that Mobile IPv6 must protect from lie in creation (or deletion) of
the local routing exceptions. In Mobile IPv6 terms, the danger is in
the possibility of unauthorized creation of Binding Cache Entries
(BCE). The effects of an attack differ depending on the target of
the attack, the timing of the attack, and the location of the
attacker.
2.1. Target
Basically, the target of an attack can be any node or network in the
Internet (stationary or mobile). The basic differences lie in the
goals of the attack: does the attacker aim to divert (steal) the
traffic destined to and/or sourced at the target node, or does it aim