draft-ietf-netlmm-threats-04.txt   rfc4832.txt 
Network Working Group C. Vogt Network Working Group C. Vogt
Internet-Draft Universitaet Karlsruhe (TH) Request for Comments: 4832 Universitaet Karlsruhe (TH)
Expires: March 16, 2007 J. Kempf Category: Informational J. Kempf
DoCoMo USA Labs DoCoMo USA Labs
September 12, 2006 Security Threats to Network-Based Localized
Mobility Management (NETLMM)
Security Threats to Network-Based Localized Mobility Management
draft-ietf-netlmm-threats-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 16, 2007. 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 Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document discusses security threats to network-based localized This document discusses security threats to network-based localized
mobility management. Threats may occur on two interfaces: the mobility management. Threats may occur on two interfaces: the
interface between a localized mobility anchor and a mobile access interface between a localized mobility anchor and a mobile access
gateway, as well as the interface between a mobile access gateway and gateway, as well as the interface between a mobile access gateway and
a mobile node. Threats to the former interface impact the localized a mobile node. Threats to the former interface impact the localized
mobility management protocol itself. mobility management protocol itself.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Threats to Interface between LMA and MAG . . . . . . . . . . . 4 2. Threats to Interface between LMA and MAG . . . . . . . . . . . 3
2.1 LMA Compromise or Impersonation . . . . . . . . . . . . . 4 2.1. LMA Compromise or Impersonation . . . . . . . . . . . . . 3
2.2 MAG Compromise or Impersonation . . . . . . . . . . . . . 5 2.2. MAG Compromise or Impersonation . . . . . . . . . . . . . 4
2.3 Man in the Middle Attack . . . . . . . . . . . . . . . . . 7 2.3. Man-in-the-Middle Attack . . . . . . . . . . . . . . . . . 6
3. Threats to Interface between MAG and Mobile Node . . . . . . . 7 3. Threats to Interface between MAG and Mobile Node . . . . . . . 6
3.1 Mobile Node Compromise or Impersonation . . . . . . . . . 8 3.1. Mobile Node Compromise or Impersonation . . . . . . . . . 7
3.2 Man in the Middle Attack . . . . . . . . . . . . . . . . . 10 3.2. Man-in-the-Middle Attack . . . . . . . . . . . . . . . . . 9
4. Threats from the Internet . . . . . . . . . . . . . . . . . . 10 4. Threats from the Internet . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
8.2 Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 16
1. Introduction 1. Introduction
The network-based localized mobility management (NETLMM) architecture The network-based localized mobility management (NETLMM) architecture
[1] supports movement of IPv6 mobile nodes locally within a domain [1] supports movement of IPv6 mobile nodes locally within a domain
without requiring mobility support in the mobile nodes' network without requiring mobility support in the mobile nodes' network
stacks. A mobile node can keep its IP address constant as it moves stacks. A mobile node can keep its IP address constant as it moves
from link to link, avoiding the signaling overhead and latency from link to link, avoiding the signaling overhead and latency
associated with changing the IP address. Software specifically for associated with changing the IP address. Software specifically for
localized mobility management is not required on the mobile node, localized mobility management is not required on the mobile node,
skipping to change at page 3, line 34 skipping to change at page 2, line 34
local access link based on handoff signaling that the mobile node local access link based on handoff signaling that the mobile node
pursues. The MAG may additionally monitor connectivity of the mobile pursues. The MAG may additionally monitor connectivity of the mobile
node in order to recognize when the mobile node has left the local node in order to recognize when the mobile node has left the local
access link. The localized mobility management architecture access link. The localized mobility management architecture
therefore has two interfaces: therefore has two interfaces:
1. The interface between a MAG and an LMA where route update 1. The interface between a MAG and an LMA where route update
signaling occurs. signaling occurs.
2. The interface between a mobile node and its current MAG where 2. The interface between a mobile node and its current MAG where
handoff signaling and other link maintenance signaling occurs. handoff signaling and other link maintenance signaling occur.
The localized mobility management architecture demands no specific The localized mobility management architecture demands no specific
protocol for a MAG to detect the arrival or departure of mobile nodes protocol for a MAG to detect the arrival or departure of mobile nodes
to and from its local access link and accordingly initiate route to and from its local access link and accordingly initiate route
update signaling with an LMA. An appropriate mechanism may be update signaling with an LMA. An appropriate mechanism may be
entirely implemented at the link layer, such as is common for entirely implemented at the link layer, such as is common for
cellular networks. In that case, the IP layer never detects any cellular networks. In that case, the IP layer never detects any
movement, even when a mobile node moves from one link to another movement, even when a mobile node moves from one link to another
handled by a different MAG. If the link layer does not provide the handled by a different MAG. If the link layer does not provide the
necessary functionality, the mobile node must perform IP-layer necessary functionality, the mobile node must perform IP-layer
movement detection and auto-configuration signaling, thereby movement detection and auto-configuration signaling, thereby
providing the trigger for the MAG to update its route at the LMA. A providing the trigger for the MAG to update its route on the LMA. A
mobile node identity, established by the localized mobility mobile node identity, established by the localized mobility
management domain when the mobile node initially connects and management domain when the mobile node initially connects and
authenticates, enables the MAG to ascribe the decisive link- or IP- authenticates, enables the MAG to ascribe the decisive link- or IP-
layer signaling to the correct mobile node. Some wireless access layer signaling to the correct mobile node. Some wireless access
technologies may require the mobile node identity to be re- technologies may require the mobile node identity to be reestablished
established on every link-layer handoff. on every link-layer handoff.
Vulnerabilities in either interface of the localized mobility Vulnerabilities in either interface of the localized mobility
management architecture may entail new security threats which go management architecture may entail new security threats that go
beyond those that already exist in IPv6. This document identifies beyond those that already exist in IPv6. Potential attack objectives
and discusses security threats on both interfaces of the localized may be to consume network services at the cost of a legitimate mobile
mobility management architecture. It is limited to threats which are node, interpose in a mobile node's communications and possibly
peculiar to localized mobility management; threats to IPv6 in general impersonate the mobile node from a position off-link, operate under
are documented in [4]. the disguise of a false or non-existing identity, or cause denial of
service to a mobile node or to the localized mobility management
domain as a whole. This document identifies and discusses security
threats on both interfaces of the localized mobility management
architecture. It is limited to threats that are peculiar to
localized mobility management; threats to IPv6 in general are
documented in [4].
1.1 Terminology 1.1. Terminology
The terminology in this document follows the definitions in [2], with The terminology in this document follows the definitions in [2], with
those revisions and additions from [1]. In addition, the following those revisions and additions from [1]. In addition, the following
definition is used: definition is used:
Mobile Node Identity Mobile Node Identity
An identity established for the mobile node when initially An identity established for the mobile node when initially
connecting to the domain. It allows the localized mobility connecting to the localized mobility management domain. It allows
management domain to definitively and unambiguously identify the the localized mobility management domain to definitively and
mobile node upon handoff for route update signaling purposes. The unambiguously identify the mobile node upon handoff for route
mobile node identity is conceptually independent of the mobile update signaling purposes. The mobile node identity is
node's IP or link-layer addresses, but it must be securely bound conceptually independent of the mobile node's IP or link-layer
to the mobile node's handoff signaling. addresses, but it must be securely bound to the mobile node's
handoff signaling.
2. Threats to Interface between LMA and MAG 2. Threats to Interface between LMA and MAG
The localized mobility management protocol executed on the interface The localized mobility management protocol executed on the interface
between an LMA and a MAG serves to establish, update, and tear down between an LMA and a MAG serves to establish, update, and tear down
routes for data plane traffic of mobile nodes. Threats to this routes for data plane traffic of mobile nodes. Threats to this
interface can be separated into compromise or impersonation of a interface can be separated into compromise or impersonation of a
legitimate LMA, compromise or impersonation of a legitimate MAG, and legitimate LMA, compromise or impersonation of a legitimate MAG, and
man-in-the-middle attacks. man-in-the-middle attacks.
2.1 LMA Compromise or Impersonation 2.1. LMA Compromise or Impersonation
A compromised LMA can ignore route updates from a legitimate MAG in A compromised LMA can ignore route updates from a legitimate MAG in
order to deny service to a mobile node. It may also be able to trick order to deny service to a mobile node. It may also be able to trick
a legitimate MAG into creating a new, incorrect route, thereby a legitimate MAG into creating a new, incorrect route, thereby
preparing the MAG to receive redirected traffic of a mobile node; it preparing the MAG to receive redirected traffic of a mobile node; it
may cause the traffic forwarded by a MAG to be redirected to a may cause the traffic forwarded by a MAG to be redirected to a
different LMA; or it may simply have the MAG drop an existing route different LMA; or it may simply have the MAG drop an existing route
in order to deny the mobile node service. Since data plane traffic in order to deny the mobile node service. Since data plane traffic
for mobile nodes routes through the LMA, a compromised LMA can also for mobile nodes routes through the LMA, a compromised LMA can also
intercept, inspect, modify, or drop such traffic, or redirect it to a intercept, inspect, modify, or drop such traffic, or redirect it to a
destination in collusion with the attacker. The attack can be destination in collusion with the attacker. The attack can be
conducted transiently, to selectively disable traffic for any conducted transiently to selectively disable traffic for any
particular mobile node or MAG at particular times. particular mobile node or MAG at particular times.
Moreover, a compromised LMA may manipulate its routing table such Moreover, a compromised LMA may manipulate its routing table such
that all packets are directed towards a single MAG. This may result that all packets are directed towards a single MAG. This may result
in a DoS attack against that MAG and its attached access link. in a denial-of-service attack against that MAG and its attached
access link.
These threats also emanate from an attacker which tricks a MAG into These threats also emanate from an attacker which tricks a MAG into
believing that it is a legitimate LMA. This attacker can cause the believing that it is a legitimate LMA. This attacker can cause the
MAG to conduct route update signaling with the attacker instead of MAG to conduct route update signaling with the attacker instead of
with the legitimate LMA, enabling it to ignore route updates from the with the legitimate LMA, enabling it to ignore route updates from the
MAG, or induce incorrect route changes at the MAG as described above, MAG, or induce incorrect route changes at the MAG as described above,
in order to redirect or deny a mobile node's traffic. The attacker in order to redirect or deny a mobile node's traffic. The attacker
does not necessarily have to be on the original control plane path does not necessarily have to be on the original control plane path
between the legitimate LMA and the MAG, provided that it can somehow between the legitimate LMA and the MAG, provided that it can somehow
make its presence known to the MAG. Failure to mutually authenticate make its presence known to the MAG. Failure to mutually authenticate
skipping to change at page 5, line 37 skipping to change at page 4, line 40
obvious if the attacker is on the original data plane path between obvious if the attacker is on the original data plane path between
the legitimate LMA and the mobile node's current MAG, which may the legitimate LMA and the mobile node's current MAG, which may
happen independently of whether the attacker is on the original happen independently of whether the attacker is on the original
control plane path. If the attacker is not on this path, it may be control plane path. If the attacker is not on this path, it may be
able to leverage the localized mobility management protocol to able to leverage the localized mobility management protocol to
redefine the prefix that the mobile node uses in IP address redefine the prefix that the mobile node uses in IP address
configuration. The attacker can then specify a prefix that routes to configuration. The attacker can then specify a prefix that routes to
itself. Whether or not outgoing data plane packets sourced by the itself. Whether or not outgoing data plane packets sourced by the
mobile node can be interfered with by an attacker off the original mobile node can be interfered with by an attacker off the original
data plane path depends on the specific data plane forwarding data plane path depends on the specific data plane forwarding
mechanism within the localized mobility management domain. E.g., if mechanism within the localized mobility management domain. For
IP-in-IP encapsulation or an equivalent approach is used for outbound example, if IP-in-IP encapsulation or an equivalent approach is used
data plane packets, the packets can be forced to be routed through for outbound data plane packets, the packets can be forced to be
the attacker. On the other hand, standard IP routing may cause the routed through the attacker. On the other hand, standard IP routing
packets to be relayed via a legitimate LMA and hence to circumvent may cause the packets to be relayed via a legitimate LMA and hence to
the attacker. circumvent the attacker.
2.2 MAG Compromise or Impersonation 2.2. MAG Compromise or Impersonation
A compromised MAG can redirect a mobile node's traffic onto its local A compromised MAG can redirect a mobile node's traffic onto its local
access link arbitrarily, without authorization from the mobile node. access link arbitrarily, without authorization from the mobile node.
This threat is similar to an attack on a typical routing protocol This threat is similar to an attack on a typical routing protocol
where a malicious stub router injects a bogus host route for the where a malicious stub router injects a bogus host route for the
mobile node. In general, forgery of a subnet prefix in link state or mobile node. In general, forgery of a subnet prefix in link state or
distance vector routing protocols requires support of multiple distance vector routing protocols requires support of multiple
routers in order to obtain a meaningful change in forwarding routers in order to obtain a meaningful change in forwarding
behavior. But a bogus host route is likely to take precedence over behavior. But a bogus host route is likely to take precedence over
the routing information advertised by legitimate routers, which is the routing information advertised by legitimate routers, which is
usually less specific, hence the attack should succeed even if the usually less specific; hence, the attack should succeed even if the
attacker is not supported by other routers. A difference between attacker is not supported by other routers. A difference between
redirection in a routing protocol and redirection in localized redirection in a routing protocol and redirection in localized
mobility management is that the former impacts the routing tables of mobility management is that the former impacts the routing tables of
multiple routers, whereas the latter involves only the compromised multiple routers, whereas the latter involves only the compromised
MAG and an LMA. MAG and an LMA.
Moreover, a compromised MAG can ignore the presence of a mobile node Moreover, a compromised MAG can ignore the presence of a mobile node
on its local access link and refrain from registering the mobile node on its local access link and refrain from registering the mobile node
at an LMA. The mobile node then loses its traffic. The compromised at an LMA. The mobile node then loses its traffic. The compromised
MAG may further be able to cause interruption to a mobile node by MAG may further be able to cause interruption to a mobile node by
deregistering the mobile node at the serving LMA, pretending that the deregistering the mobile node at the serving LMA, pretending that the
mobile node has powered down. The mobile node then needs to re- mobile node has powered down. The mobile node then needs to
initiate the network access authentication procedure, which the reinitiate the network access authentication procedure, which the
compromised MAG may prevent repeatedly until the mobile node moves to compromised MAG may prevent repeatedly until the mobile node moves to
a different MAG. The mobile node should be able to handle this a different MAG. The mobile node should be able to handle this
situation, but the recovery process may be lengthy and hence impair situation, but the recovery process may be lengthy and hence impair
ongoing communication sessions to a significant extent. ongoing communication sessions to a significant extent.
Denial of service against an LMA is another threat of MAG subversion. Denial of service against an LMA is another threat of MAG subversion.
The compromised MAG can trick an LMA into believing that a high The compromised MAG can trick an LMA into believing that a high
number of mobile nodes have attached to the MAG. The LMA will then number of mobile nodes have attached to the MAG. The LMA will then
establish a routing table entry for each of the non-existing mobile establish a routing table entry for each of the non-existing mobile
nodes. The unexpected growth of the routing table may eventually nodes. The unexpected growth of the routing table may eventually
cause the LMA to reject legitimate route update requests. It may cause the LMA to reject legitimate route update requests. It may
also decrease the forwarding speed for data plane packets due to also decrease the forwarding speed for data plane packets due to
higher route lookup latencies, and it may for the same reason slow higher route lookup latencies, and it may, for the same reason, slow
down the responsiveness to control plane packets. Another adverse down the responsiveness to control plane packets. Another adverse
side effect of a high number of routing table entries is that the side effect of a high number of routing table entries is that the
LMA, and hence the localized mobility management domain as a whole, LMA, and hence the localized mobility management domain as a whole,
becomes more susceptible to flooding packets from external attackers becomes more susceptible to flooding packets from external attackers
(see Section 4). The high number of superfluous routes increases the (see Section 4). The high number of superfluous routes increase the
probability that a flooding packet, sent to a random IP address probability that a flooding packet, sent to a random IP address
within the localized mobility management domain, matches an existing within the localized mobility management domain, matches an existing
routing table entry at the LMA and gets tunneled to a MAG, which in routing table entry at the LMA and gets tunneled to a MAG, which in
turn performs address resolution on the local access link. At the turn performs address resolution on the local access link. At the
same time, fewer flooding packets can be dropped directly at the LMA same time, fewer flooding packets can be dropped directly at the LMA
on the basis of a nonexistent routing table entry. on the basis of a nonexistent routing table entry.
All of these threats apply not just to a MAG that is compromised, but All of these threats apply not just to a compromised MAG, but also to
also to an attacker that manages to counterfeit the identity of a an attacker that manages to counterfeit the identity of a legitimate
legitimate MAG in interacting with both mobile nodes and an LMA. MAG in interacting with both mobile nodes and an LMA. Such an
Such an attacker can behave towards mobile nodes like an authorized attacker can behave towards mobile nodes like an authorized MAG and
MAG and engage an LMA in route update signaling. In a related engage an LMA in route update signaling. In a related attack, the
attack, the perpetrator eavesdrops on signaling packets exchanged perpetrator eavesdrops on signaling packets exchanged between a
between a legitimate MAG and an LMA and replays these packets at a legitimate MAG and an LMA, and replays these packets at a later time.
later time. These attacks may be conducted transiently, to These attacks may be conducted transiently, to selectively disable
selectively disable traffic for any particular mobile node at traffic for any particular mobile node at particular times.
particular times.
2.3 Man in the Middle Attack 2.3. Man-in-the-Middle Attack
An attacker that manages to interject itself between a legitimate LMA An attacker that manages to interject itself between a legitimate LMA
and a legitimate MAG can act as a man in the middle with respect to and a legitimate MAG can act as a man in the middle with respect to
both control plane signaling and data plane traffic. If the attacker both control plane signaling and data plane traffic. If the attacker
is on the original control plane path, it can forge, modify, or drop is on the original control plane path, it can forge, modify, or drop
route update packets so as to cause the establishment of incorrect route update packets so as to cause the establishment of incorrect
routes or the removal of routes that are in active use. Similarly, routes or the removal of routes that are in active use. Similarly,
an attacker on the original data plane path can intercept, inspect, an attacker on the original data plane path can intercept, inspect,
modify, drop, and redirect data plane packets sourced by or destined modify, drop, and redirect data plane packets sourced by or destined
to a mobile node. to a mobile node.
A compromised switch or router located between an LMA and a MAG can A compromised switch or router located between an LMA and a MAG can
cause similar damage. Any switch or router on the control plane path cause similar damage. Any switch or router on the control plane path
can forge, modify, or drop control plane packets, and thereby can forge, modify, or drop control plane packets, and thereby
interfere with route establishment. Any switch or router on the data interfere with route establishment. Any switch or router on the data
plane path can intercept, inspect, modify, and drop data plane plane path can intercept, inspect, modify, and drop data plane
packets, or rewrite IP headers so as to divert the packets from their packets, or rewrite IP headers so as to divert the packets from their
original path. original path.
An attacker between an LMA and a MAG may further impersonate the MAG An attacker between an LMA and a MAG may further impersonate the MAG
towards the LMA and vice versa in route update signaling. The towards the LMA, and vice versa in route update signaling. The
attacker can so interfere with route establishment even if it is not attacker can interfere with a route establishment even if it is not
on the original control plane path between the LMA and the MAG. An on the original control plane path between the LMA and the MAG. An
attacker off the original data plane path may undertake the same to attacker off the original data plane path may undertake the same to
cause inbound data plane packets destined to the mobile node to be cause inbound data plane packets destined to the mobile node to be
routed first from the LMA to the attacker, and from there to the routed first from the LMA to the attacker, then to the mobile node's
mobile node's MAG and finally to the mobile node itself. As MAG, and finally to the mobile node itself. As explained in
explained in Section 2.1, here, too, it depends on the specific data Section 2.1, here, too, it depends on the specific data plane
plane forwarding mechanism within the localized mobility management forwarding mechanism within the localized mobility management domain
domain whether or not the attacker can influence the route of whether or not the attacker can influence the route of outgoing data
outgoing data plane packets sourced by the mobile node. plane packets sourced by the mobile node.
3. Threats to Interface between MAG and Mobile Node 3. Threats to Interface between MAG and Mobile Node
A MAG monitors the arrival and departure of mobile nodes to and from A MAG monitors the arrival and departure of mobile nodes to and from
its local access link based on link- or IP-layer mechanisms. its local access link based on link- or IP-layer mechanisms.
Whatever signaling on the access link is thereby decisive must be Whatever signaling on the access link is thereby decisive must be
securely bound to the mobile node identity. A MAG uses this binding securely bound to the mobile node identity. A MAG uses this binding
to ascribe the signaling to the mobile node and accordingly initiate to ascribe the signaling to the mobile node and accordingly initiate
route update signaling with an LMA. The binding must be robust to route update signaling with an LMA. The binding must be robust to
spoofing because it would otherwise facilitate impersonation of the spoofing because it would otherwise facilitate impersonation of the
mobile node by a third party, denial of service, or man-in-the-middle mobile node by a third party, denial of service, or man-in-the-middle
attacks. attacks.
3.1 Mobile Node Compromise or Impersonation 3.1. Mobile Node Compromise or Impersonation
An attacker that is able to forge the mobile node identity of a An attacker that is able to forge the mobile node identity of a
mobile node can to trick a MAG into redirecting data plane packets mobile node can trick a MAG into redirecting data plane packets for
for the mobile node to the attacker. The attacker can launch such an the mobile node to the attacker. The attacker can launch such an
impersonation attack against a mobile node that resides on the same impersonation attack against a mobile node that resides on the same
link as the attacker, or against a mobile node on a different link. link as the attacker, or against a mobile node on a different link.
If the attack is on-link, the redirection of packets from the mobile If the attack is on-link, the redirection of packets from the mobile
node to the attacker is internal to the MAG, and it involves no route node to the attacker is internal to the MAG, and it involves no route
update signaling between the MAG and an LMA. On-link attacks are update signaling between the MAG and an LMA. On-link attacks are
possible in a regular IPv6 network [4] that does not use Secure possible in a regular IPv6 network [4] that does not use Secure
Neighbor Discovery [5]. Neighbor Discovery [5].
Off-link impersonation requires the attacker to fabricate handoff Off-link impersonation requires the attacker to fabricate handoff
signaling of the mobile node and thus trick the MAG into believing signaling of the mobile node and thus trick the MAG into believing
skipping to change at page 8, line 48 skipping to change at page 7, line 46
may not be noticeable early enough at the link or IP layer to quickly may not be noticeable early enough at the link or IP layer to quickly
institute countermeasures. The attack is therefore disruptive at a institute countermeasures. The attack is therefore disruptive at a
minimum, and may potentially persist until the mobile node initiates minimum, and may potentially persist until the mobile node initiates
signaling again upon a subsequent handoff. signaling again upon a subsequent handoff.
Impersonation attacks can be prevented at the link layer, Impersonation attacks can be prevented at the link layer,
particularly with cellular technologies where the handoff signaling particularly with cellular technologies where the handoff signaling
between the mobile node and the network must be authenticated and is between the mobile node and the network must be authenticated and is
completely controlled by the wireless link layer. Cellular access completely controlled by the wireless link layer. Cellular access
technologies provide a variety of cryptographic and non-cryptographic technologies provide a variety of cryptographic and non-cryptographic
attack barriers at the link layer which make mouting an impersonation attack barriers at the link layer, which makes mounting an
attack, both on-link and off-link, very difficult. However, for non- impersonation attack, both on-link and off-link, very difficult.
cellular technologies that do not require link layer authentication However, for non-cellular technologies that do not require link-layer
and authorization during handoff, impersonation attacks may be authentication and authorization during handoff, impersonation
possible. attacks may be possible.
An attacker that can forge handoff signaling may also cause denial of An attacker that can forge handoff signaling may also cause denial of
service against the localized mobility management domain. The service against the localized mobility management domain. The
attacker can trick a MAG into believing that a large number of mobile attacker can trick a MAG into believing that a large number of mobile
nodes have attached to the local access link and thus induce it to nodes have attached to the local access link and thus induce it to
initiate route update signaling with an LMA for each mobile node initiate route update signaling with an LMA for each mobile node
assumed on link. The result of such an attack is both superfluous assumed on link. The result of such an attack is both superfluous
signaling overhead on the control plane as well as a high number of signaling overhead on the control plane as well as a high number of
needless entries in the LMA's and MAG's routing tables. The needless entries in the LMA's and MAG's routing tables. The
unexpected growth of the routing tables may eventually cause the LMA unexpected growth of the routing tables may eventually cause the LMA
skipping to change at page 10, line 7 skipping to change at page 9, line 5
targets, and the enforcement of topologically correct IP address targets, and the enforcement of topologically correct IP address
prefixes also limits the effectiveness of identity concealment, prefixes also limits the effectiveness of identity concealment,
network ingress filtering has proven adequate so far. On the other network ingress filtering has proven adequate so far. On the other
hand, prefixes are not limited to a specific link in a localized hand, prefixes are not limited to a specific link in a localized
mobility management domain, so merely ensuring topological mobility management domain, so merely ensuring topological
correctness through ingress filtering becomes insufficient. An correctness through ingress filtering becomes insufficient. An
additional mechanism for IP address ownership verification is additional mechanism for IP address ownership verification is
necessary to prevent an attacker from sending packets with an off- necessary to prevent an attacker from sending packets with an off-
link IP source address. link IP source address.
3.2 Man in the Middle Attack 3.2. Man-in-the-Middle Attack
An attacker which can interpose between a mobile node and a MAG An attacker that can interpose between a mobile node and a MAG during
during link- and/or IP-layer handoff signaling may be able to mount a link- and/or IP-layer handoff signaling may be able to mount a man-
man-in-the-middle attack on the mobile node, spoofing the mobile node in-the-middle attack on the mobile node, spoofing the mobile node
into believing that it has a legitimate connection with the localized into believing that it has a legitimate connection with the localized
mobility management domain. The attacker can thus intercept, mobility management domain. The attacker can thus intercept,
inspect, modify, or drop data plane packets sourced by or destined to inspect, modify, or drop data plane packets sourced by or destined to
the mobile node. the mobile node.
4. Threats from the Internet 4. Threats from the Internet
A localized mobility management domain uses individual host routes A localized mobility management domain uses individual host routes
for data plane traffic of different mobile nodes, each between an LMA for data plane traffic of different mobile nodes, each between an LMA
and a MAG. Creation, maintenance, and deletion of these routes cause and a MAG. Creation, maintenance, and deletion of these routes cause
skipping to change at page 11, line 6 skipping to change at page 9, line 49
service on a regular IPv6 border router, but because the routing service on a regular IPv6 border router, but because the routing
table lookups may enable the LMA to drop part of the flooding packets table lookups may enable the LMA to drop part of the flooding packets
early on or, on the contrary, additional tunneling workload is early on or, on the contrary, additional tunneling workload is
required for packets that cannot be dropped, the impact of an attack required for packets that cannot be dropped, the impact of an attack
against localized mobility management may be different. against localized mobility management may be different.
In a related attack, the attacker manages to obtain a globally In a related attack, the attacker manages to obtain a globally
routable IP address of an LMA or a different network entity within routable IP address of an LMA or a different network entity within
the localized mobility management domain and perpetrates a denial-of- the localized mobility management domain and perpetrates a denial-of-
service attack against that IP address. Localized mobility service attack against that IP address. Localized mobility
management is in general somewhat resistant to such an attack because management is, in general, somewhat resistant to such an attack
mobile nodes need never obtain a globally routable IP address of any because mobile nodes need never obtain a globally routable IP address
entity within the localized mobility management domain. A of any entity within the localized mobility management domain.
compromised mobile node hence cannot pass such an IP address off to a Hence, a compromised mobile node cannot pass such an IP address off
remote attacker, limiting the feasibility of extracting information to a remote attacker, limiting the feasibility of extracting
on the topology of the localized mobility management domain. It is information on the topology of the localized mobility management
still possible for an attacker to perform IP address scanning if MAGs domain. It is still possible for an attacker to perform IP address
and LMAs have globally routable IP addresses, but the much larger scanning if MAGs and LMAs have globally routable IP addresses, but
IPv6 address space makes scanning considerably more time consuming. the much larger IPv6 address space makes scanning considerably more
time consuming.
5. Security Considerations 5. Security Considerations
This document describes threats to network-based localized mobility This document describes threats to network-based localized mobility
management. These may either occur on the interface between an LMA management. These may either occur on the interface between an LMA
and a MAG, or on the interface between a MAG and a mobile node. and a MAG, or on the interface between a MAG and a mobile node.
Mitigation measures for the threats, as well as the security Mitigation measures for the threats, as well as the security
considerations associated with those measures, are described in the considerations associated with those measures, are described in the
respective protocol specifications [3][8] for the two interfaces. respective protocol specifications [3][8] for the two interfaces.
6. IANA Considerations 6. Acknowledgments
This document has no actions for IANA.
7. Acknowledgment
The authors would like to thank the NETLMM working group, especially The authors would like to thank the NETLMM working group, especially
Jari Arkko, Gregory Daley, Vijay Devarapalli, Lakshminath Dondeti, Jari Arkko, Charles Clancy, Gregory Daley, Vijay Devarapalli,
Gerardo Giaretta, Wassim Haddad, Andy, Huang, Dirk von Hugo, Julien Lakshminath Dondeti, Gerardo Giaretta, Wassim Haddad, Andy Huang,
Laganier, Henrik Levkowetz, Vidya Narayanan, Phil Roberts, and Pekka Dirk von Hugo, Julien Laganier, Henrik Levkowetz, Vidya Narayanan,
Savola (in alphabetical order) for valuable comments and suggestions Phil Roberts, and Pekka Savola (in alphabetical order) for valuable
regarding this document. comments and suggestions regarding this document.
8. References 7. References
8.1 Normative References 7.1. Normative References
[1] Kempf, J., "Problem Statement for Network-based Localized [1] Kempf, J., Ed., "Problem Statement for Network-Based Localized
Mobility Management", IETF Internet Draft Mobility Management", RFC 4830, April 2007.
draft-ietf-netlmm-nohost-ps-04.txt (work in progress),
June 2006.
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", [2] Manner, J. and M. Kojo, "Mobility Related Terminology",
IETF Request for Comments 3753, June 2004. RFC 3753, June 2004.
8.2 Informative References 7.2. Informative References
[3] Giaretta, G., "NetLMM Protocol", IETF Internet Draft [3] Levkowetz, H., Ed., "The NetLMM Protocol", Work in Progress,
draft-giaretta-netlmm-dt-protocol-00.txt (work in progress), October 2006.
June 2006.
[4] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [4] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", IETF Request for Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
Comments 3756, May 2004.
[5] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [5] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", IETF Request for Comments 3971, Neighbor Discovery (SEND)", RFC 3971, March 2005.
March 2005.
[6] CERT Coordination Center, "CERT Advisory CA-1996-21 TCP SYN [6] CERT Coordination Center, "CERT Advisory CA-1996-21 TCP SYN
Flooding and IP Spoofing Attacks", September 1996. Flooding and IP Spoofing Attacks", September 1996.
[7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating [7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address Denial of Service Attacks which employ IP Source Address
Spoofing", IETF Request for Comments 2827, May 2000. Spoofing", BCP 38, RFC 2827, May 2000.
[8] Laganier, J., Narayanan, S., and F. Templin, "Network-based [8] Laganier, J., Narayanan, S., and F. Templin, "Network-based
Localized Mobility Management Interface between Mobile Node and Localized Mobility Management Interface between Mobile Node and
Access Router", IETF Internet Draft Access Router", Work in Progress, June 2006.
draft-ietf-netlmm-mn-ar-if-01.txt (work in progress), June 2006.
Authors' Addresses Authors' Addresses
Christian Vogt Christian Vogt
Institute of Telematics Institute of Telematics
Universitaet Karlsruhe (TH) Universitaet Karlsruhe (TH)
P.O. Box 6980 P.O. Box 6980
76128 Karlsruhe 76128 Karlsruhe
Germany Germany
Email: chvogt@tm.uka.de EMail: chvogt@tm.uka.de
James Kempf James Kempf
DoCoMo USA Labs DoCoMo USA Labs
181 Metro Drive, Suite 300 3240 Hillview Avenue
San Jose, CA 95110 Palo Alto, CA 94304
USA USA
Phone: +1 408 451 4711 EMail: kempf@docomolabs-usa.com
Email: kempf@docomolabs-usa.com
Appendix A. Change Log
The following is a list of technical changes that were made from
version 03 to version 04 of the document. Editorial revisions are
not explicitly mentioned.
o Section 2.1: Clarified in first paragraph what it means for a
compromised LMA to "forge routing updates for a victim mobile
node" and what the intention behind such an attack could be.
o Section 2.1: Removed description of how MAP discovery works in
Hierarchical Mobile IPv6.
o Section 3: Introductory text shortened, because (i) it repeated
material from Section 1, and (ii) also described potential link-
layer technologies for access links, which was not within the
scope of this document.
o Section 3.1: Clarified how impersonation of a mobile node may
look like when the attacker attaches to the same MAG as the mobile
node, but to a different link.
o Section 3.1: Revised text on why cellular technologies can
prevent impersonation attacks against mobile nodes at the link
layer.
The following is a list of technical changes that were made from
version 02 to version 03 of the document. Editorial revisions are
not explicitly mentioned.
o Changed the terminology from "network access identity" to "mobile
node identity" as the previous term was frequently confused with
the different "network access identifier" (NAI). Removed the
special "Network Access Identity" subsection in Section 3. The
mobile node identity is now first mentioned in Section 1, which
fits well with the nutshell description of the NETLMM
architecture. The security requirements of the mobile node
identifier are discussed in the introductory text of Section 3.
This makes more sense than a special subsection because the text,
on one hand, provides the necessary basis to understand the
following subsections, while on the other hand, it does not really
explain an attack itself.
o Section 1: Extended the description of conceptual actors in the
localized mobility management architecture and added a summary of
potential attack objectives and attack targets.
o Section 3.1: Granularity of ingress filtering may be coarser in a
localized mobility management domain. It may also allow off-link
IP spoofing since prefixes are not limited to a specific link.
o Section 2.2: The threat of replay attacks was not mentioned in
this section. It was added.
o Section 3.1: The threat of replay attacks was not mentioned in
this section. It was added.
o Section 2.2: Causing spurious route updates may lead to DoS
against the localized mobility management domain. This threat was
missing in the discussion of this section and it was added.
o Section 3.1: Causing spurious route updates may lead to DoS
against the localized mobility management domain. This threat was
missing in the discussion of this section and it was added.
o Section 4: Moved DoS attack against a localized mobility
management domain from the Internet to a separate section because
it is not specific to either interface within the domain.
o Revised the document with respect to the recent agreement the
addressing model.
o Revised the document with respect to the the possibility that
there may be more than one LMA. The text was initially written
under the assumption that the LMA is unique.
o References split into normative and informative references.
The following is a list of technical changes that were made from
version 01 to version 02 of the document. Editorial revisions are
not explicitly mentioned.
o Section 2.1: Included DoS/flooding attack against MAG. Also
clarified how a malicious node off the control plane path between
the authorized LMA and one or multiple target MAGs could
impersonate the authorized LMA against the MAGs. Such an attacker
could use various means to interfere with data plane traffic even
if it is off the original data plane path between the legitimate
LMA and the MAGs.
o Section 2.2: Malicious MAG may deregister an actively
communicating mobile node, without consent of the mobile node.
o Section 2.3: Included related threats pertaining to MITM between
LMA and MAG, which were formerly described in other sections.
o Section 4: Included description of DoS/flooding attack against Full Copyright Statement
LMA, including its impact on the target MAGs, their links, and the
target mobile nodes.
o Section 3: Revised the structure of this section. Threats are Copyright (C) The IETF Trust (2007).
now divided into attacks against a mobile node's network access
identity; impersonation of a mobile node, both from the mobile
node's link and from off link; as well as man-in-the-middle
attacks.
o Section 1: The binding with the network access identity may be This document is subject to the rights, licenses and restrictions
with the authentication keys associated with the mobile node's IP contained in BCP 78, and except as set forth therein, the authors
address, not necessarily with the IP addresses themselves. retain all their rights.
o Section 3.1: Off-link attack may be mounted from a link that This document and the information contained herein are provided on an
connects to a different MAG than the victim mobile node's MAG. "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Statement Intellectual Property
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
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 16, line 29 skipping to change at page 12, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in Acknowledgement
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 52 change blocks. 
286 lines changed or deleted 140 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/