draft-ietf-netlmm-threats-01.txt   draft-ietf-netlmm-threats-02.txt 
Network Working Group C. Vogt Network Working Group C. Vogt
Internet-Draft Universitaet Karlsruhe (TH) Internet-Draft Universitaet Karlsruhe (TH)
Expires: December 25, 2006 J. Kempf Expires: January 24, 2007 J. Kempf
DoCoMo USA Labs DoCoMo USA Labs
June 23, 2006 July 23, 2006
Security Threats to Network-based Localized Mobility Management Security Threats to Network-Based Localized Mobility Management
draft-ietf-netlmm-threats-01.txt draft-ietf-netlmm-threats-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 December 25, 2006. This Internet-Draft will expire on January 24, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document discusses security threats to NETLMM mobility This document discusses security threats to network-based localized
management. Threats to NETLMM occur on two interfaces: the access mobility management. Threats may occur on two interfaces: the
router/localized mobility anchor interface and the access router/ interface between an LMA and a MAG, as well as the interface between
mobile node interface. Threats to the access router/localized a MAG and a mobile node. Threats to the former interface impact the
mobility anchor interface are threats to the NETLMM protocol itself. localized mobility management protocol itself.
This document discusses threats on these two interfaces.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Threats to the AR/LMA Interface . . . . . . . . . . . . . . . 4 2. Threats to Interface between LMA and MAG . . . . . . . . . . . 4
2.1 Unauthorized AR . . . . . . . . . . . . . . . . . . . . . 4 2.1 LMA Compromise or Impersonation . . . . . . . . . . . . . 4
2.2 Unauthorized LMA . . . . . . . . . . . . . . . . . . . . . 5 2.2 MAG Compromise or Impersonation . . . . . . . . . . . . . 5
2.3 Man in the Middle Attack . . . . . . . . . . . . . . . . . 5 2.3 Man in the Middle Attack . . . . . . . . . . . . . . . . . 6
2.4 Denial of Service Attack on the LMA . . . . . . . . . . . 5 2.4 Denial of Service Attack on the LMA . . . . . . . . . . . 7
3. Threats to the MN-AR Interface . . . . . . . . . . . . . . . . 6 3. Threats to Interface between MAG and Mobile Node . . . . . . . 7
3.1 Mobile Node Identity . . . . . . . . . . . . . . . . . . . 6 3.1 Network Access Identity . . . . . . . . . . . . . . . . . 8
3.2 Impersonation on Handover . . . . . . . . . . . . . . . . 7 3.2 Impersonation of Mobile Nodes . . . . . . . . . . . . . . 8
3.3 Off-Link Attacks . . . . . . . . . . . . . . . . . . . . . 7 3.3 Man in the Middle Attack . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Informative References . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 7. Informative References . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 14
1. Introduction 1. Introduction
The NETLMM architecture supports movement of IPv6 mobile nodes within The network-based localized mobility management (NETLMM) architecture
a localized mobility management domain with no specialized support on [1] supports movement of IPv6 mobile nodes locally within a domain
the mobile node for localized mobility management. In contrast to without requiring mobility support in the mobile nodes' network
architectures where there is no localized mobility management support stacks. A mobile node can keep its IP address constant as it moves
or where localized mobility management support is provided by a host- from link to link, avoiding the signaling overhead and latency
based solution, in the NETLMM architecture, the mobile node is able associated with changing the IP address. While software specifically
to keep its IP address constant within the localized mobility for localized mobility management is not required on the mobile node,
management domain as it moves, avoiding the signaling overhead IP-layer movement detection software may be necessary, and driver
required to change the address. Software specifically for localized software for link-layer mobility is prerequisite.
mobility management is not required on the mobile node, though
software for IP movement detection may be needed and, of course,
driver software for link-layer movement is always required. More on
the network-based localized mobility management architecture can be
found in [1].
In the NETLMM architecture, a localized mobility anchor (LMA)
maintains routes for mobile nodes. Packets to and from mobile nodes
(MNs) on the last hop wireless links are routed through the LMA.
When a MN moves from one access router (AR) to another, the route for
the mobile node on the LMA is updated by the ARs. The NETLMM
architecture therefore has two interfaces:
1. The AR to LMA interface where route update signaling occurs. The IP addresses of mobile nodes have a prefix that routes to a
localized mobility anchor (LMA). This LMA maintains an individual
route for each mobile node. Any particular mobile node's route
terminates at a mobile access gateway (MAG) which the mobile node
uses as a default router on its current access link. MAGs are
responsible for updating the mobile node's route on the LMA as the
mobile node moves. The localized mobility management architecture
therefore has two interfaces:
2. The MN to AR interface where movement detection and IP handover 1. The interface between MAGs and the LMA where route update
signaling occurs. signaling occurs.
The NETLMM architecture specifies no standardized protocol on the 2. The interface between mobile nodes and their currently selected
MN/AR interface. The network must be informed when a mobile node MAGs where link-layer handoff signaling and possibly IP-layer
having an IP address moves from one access router to another, but how movement detection signaling occurs.
that occurs is not part of the NETLMM protocol. The mechanism can be
entirely implemented by the wireless link protocol, such as is common
for cellular networks. In that case, the IP layer never detects any
movement, even though the mobile node may be moving from one link to
another handled by a different access router. If the wireless link
protocol does not handle movement detection and IP handover, however,
support at the IP level is required. In that case, the mobile node
must perform IP signaling for active movement detection. The access
router uses this signaling to infer mobile node movement. More about
IP level movement detection and NETLMM can be found in the NETLMM
MN-AR interface document [2].
The NETLMM protocol itself is defined on the AR/LMA interface, and is
specified in [3].
This document discusses threats to security on the NETLMM interfaces. The localized mobility management architecture specifies no
standardized protocol for a MAG to detect the arrival or departure of
mobile nodes on its local link and initiate route update signaling
with the LMA. An appropriate mechanism may be entirely implemented
at the link layer, such as is common for cellular networks. In that
case, the IP layer never detects any 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 necessary functionality, the
mobile node must perform active IP-layer movement detection signaling
so as to trigger route update signaling at the MAG.
The discussion in this document focuses only on NETLMM signaling This document discusses security threats on both interfaces of
traffic, both for the NETLMM protocol itself and for signaling on the localized mobility management. The discussion is limited to threats
MN/AR interface that signals mobile node movement to the network. specific to localized mobility management; threats to IPv6 in general
Details on how the threats are handled by the NETLMM protocol and the are documented in [2].
IP MN/AR interface are discussed in [3] and [2] respectively.
1.1 Terminology 1.1 Terminology
Mobility terminology in this document follows that in [4], with those The terminology in this document follows the definitions in [3], with
revisions and additions from [1] and [5]. In addition, the following those revisions and additions from [1]. In addition, the following
definition is used: definition is used:
Network access identity Network access identity
A identity established for the mobile node with the network during An identity established for the mobile node during network access
network access authentication that allows the network to authentication that allows the network to unambiguously identify
unambiguously identify the mobile node for signaling purposes. the mobile node for signaling purposes. The network access
For example, a wireless link session key established by the identity may, e.g., be bound to a link-layer session key, a
wireless link layer, the Network Access Identifier (NAI) [6], or network access identifier (NAI) [4], or a SEND public key [5].
the SEND public key [7] may serve as the identifier associated
with the network access identity.
2. Threats to the AR/LMA Interface 2. Threats to Interface between LMA and MAG
In this section, threats to the AR/LMA interface are discussed. The localized mobility management protocol executed on the interface
Since the information propagated between the AR and LMA is routing between the LMA and a MAG serves to establish, update, and tear down
updates, the threats on this interface are similar to the threats routes for data plane traffic of mobile nodes. Threats to this
experienced by two routers exchanging routing information with a interface can be separated into compromise or impersonation of a
routing protocol. One difference is that the AR and LMA need not be legitimate LMA, compromise or impersonation of a legitimate MAG, man-
separated by a single hop, whereas routing updates are usually in-the-middle attacks, and denial-of-service attacks on the LMA.
propagated by flooding, so two routers exchanging routing information
are usually separated by a single hop.
2.1 Unauthorized AR 2.1 LMA Compromise or Impersonation
An AR that is not authorized to propagate NETLMM routing updates can A compromised LMA can ignore routing updates from a legitimate MAG,
result in serious damage to the security of a localized mobility or forge routing updates for a victim mobile node in order to
management domain. The AR can redirect traffic from MNs on the AR's redirect or deny the mobile node's traffic. Since data plane traffic
lst hop link arbitrarily, without authorization from the MN. The AR for all mobile nodes routes through the LMA, a compromised LMA can
can ignore routing updates from the LMA so that the victim MNs lose also intercept, inspect, modify, redirect, or drop such traffic on a
their traffic. An unauthorized AR can also intercept, inspect, and MAG supported by the LMA. The attack can be conducted transiently,
redirect data plane traffic for mobile nodes on its last hop to selectively disable traffic for any particular mobile node or MAG
interface, but this threat is common for any last hop router. at particular times.
Note that this threat applies not just to an AR that is compromised, Moreover, a compromised LMA may manipulate its routing table such
but also to an off-path attacker that manages to forge the identity that all packets are directed towards a single MAG. This may result
of an authorized AR, and thereby spoof the LMA into conducting NETLMM in a DoS attack against that MAG and its attached link.
protocol signaling as if the attacker were legitimate. Such an
attack could be conducted transiently, to selectively disable traffic
for particular mobile nodes at particular times.
2.2 Unauthorized LMA These threats also emanate from an attacker which tricks a MAG into
believing that it is the legitimate LMA. This attacker can cause the
MAG to conduct route update signaling with the attacker instead of
with the legitimate LMA, enabling it to ignore route updates from the
MAG, or forge route updates in order to redirect or deny a victim
mobile node's traffic. The attacker does not necessarily have to be
on the original control plane path between the legitimate LMA and the
MAG, provided that it can somehow make its presence known to the MAG.
E.g., the IP address of a mobility anchor point in hierarchical
Mobile IPv6 mobility management [6] may be proliferated across a
domain hop by hop in Router Advertisement messages. Failure to
properly authenticate a comparable mechanism for localized mobility
management would allow an attacker to establish itself as a rouge
LMA.
An unauthorized LMA can ignore routing updates from legitimate ARs, The attacker may further be able to intercept, inspect, modify,
or forge routing updates for MNs in order to redirect or deny traffic redirect, or drop data plane traffic to and from a mobile node. This
to victims. Since data plane traffic for mobile nodes routes through is obvious if the attacker is on the original data plane path between
the LMA, a rogue LMA can also intercept, inspect, and redirect data the legitimate LMA and the mobile node's current MAG, which may
plane traffic for mobile nodes on ARs supported by the LMA. A piece happen independent of whether or not the attacker is on the original
of malware might further manipulate the LMA's routing table such that control plane path. If the attacker is not on this path, it may be
all packets are directed towards a single AR, resulting in a DoS able to leverage the localized mobility management protocol to
attack against that AR and its attached link. Again, these are the redefine the prefix that the mobile node uses in IP address
same threats experienced by any intermediate router in the network. configuration. The attacker can then specify a prefix that routes to
itself. Whether or not outgoing data plane packets sourced by the
mobile node can be interfered with by an attacker off the original
data plane path depends on the specific data plane forwarding
mechanism within the localized mobility management domain. E.g., if
IP-in-IP encapsulation or an equivalent per-mobile-node approach is
used for outbound data plane packets, the packets will route through
the attacker. On the other hand, standard IP routing may cause the
packets to be relayed via the legitimate LMA and hence to circumvent
the attacker.
Note that these threats apply not just to a LMA that is compromised, 2.2 MAG Compromise or Impersonation
but also to an off-path attacker that manages to forge the identity
of an authorized LMA, and thereby spoof the ARs in a localized A compromised MAG can redirect a victim mobile node's traffic onto
mobility domain into conducting NETLMM protocol signaling as if the its local access link arbitrarily, without authorization from the
attacker were legitimate. Such an attack could be conducted mobile node. This threat is similar to an attack on a typical
transiently, to selectively disable traffic for particular mobile routing protocol where a malicious stub router injects a bogus host
nodes or ARs at particular times. route for the mobile node. In general, forgery of a subnet prefix in
link state or distance vector routing protocols requires support of
multiple routers in order to obtain a meaningful change in forwarding
behavior. But a bogus host route is likely to take precedence over
the routing information advertised by legitimate routers, which is
usually less specific, hence the attack should succeed even if the
attacker is not supported by other routers. A difference between
redirection in a routing protocol and redirection in localized
mobility management is that the former impacts the routing tables of
multiple routers, whereas the latter involves only the compromised
MAG and the LMA.
A compromised MAG can further ignore the presence of a mobile node on
its local access link and refrain from registering the mobile node at
the LMA. The mobile node then loses its traffic. Attacks that the
MAG can mount on its access link interface are common for any regular
IPv6 access router [2].
Moreover, a compromised MAG may be able to cause interruption to a
mobile node by deregistering the mobile node at the LMA, pretending
that the mobile node has powered down. The mobile node then needs to
reinitiate the network access authentication procedure, which the
compromised MAG may prevent repeatedly until the mobile node moves to
a different MAG. The mobile node should be able to handle this
situation, but the recovery process may be lengthy and hence impair
ongoing communication sessions to a significant extent.
All of these threats apply not just to a MAG that is compromised, but
also to an attacker that manages to counterfeit the identity of an
authorized MAG in interacting with both mobile nodes and the LMA.
Such an attacker can behave towards mobile nodes like a legitimate
MAG and engage the LMA in route update signaling. The attack may be
conducted transiently, to selectively disable traffic for any
particular mobile node at particular times.
2.3 Man in the Middle Attack 2.3 Man in the Middle Attack
An unauthorized intermediate router or other node that manages to An attacker that manages to interject itself between the legitimate
interject itself between the AR and LMA is in a position to LMA and a legitimate MAG can act as a man in the middle with respect
intercept, inspect, and redirect NETLMM protocol signaling traffic to both control plane signaling and data plane traffic. If the
between an authorized LMA and authorized ARs handling mobility attacker is on the original control plane path, it can forge, modify,
management for the localized mobility management domain. If the or drop route update packets so as to cause the establishment of
attacker can masquerade as an AR to the LMA and as the LMA to the incorrect routes or the removal of routes that are in active use.
ARs, it may be in a position to spoof both sides into believing that Similarly, an attacker on the original data plane path can intercept,
they have a secure link. The attacker can then utilize the inspect, modify, redirect, and drop data plane packets sourced by or
information derived from the NETLMM protocol signaling for various destined to a victim mobile node.
purposes.
A compromised router located between the LMA and a MAG may cause
similar damage. Any router on the control plane path can forge,
modify, or drop control plane packets, and thereby interfere with
route establishment. Any router on the data plane path can
intercept, inspect, modify, and drop data plane packets, or rewrite
their IP headers so as to divert the packets from their original
path.
An attacker between the LMA and a MAG may further impersonate the MAG
towards the LMA and vice versa in route update signaling. The
attacker can so interfere with route establishment even if it is not
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
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
mobile node's MAG and finally to the mobile node itself. As
explained in Section 2.1, here, too, it depends on the specific data
plane forwarding mechanism within the localized mobility management
domain whether or not the attacker can influence the route of
outgoing data plane packets sourced by the mobile node.
2.4 Denial of Service Attack on the LMA 2.4 Denial of Service Attack on the LMA
An attacker could launch a denial-of-service attack on the LMA by An attacker may launch a denial-of-service attack on the LMA by
sending packets to arbitrary IP addresses with a prefix from the sending packets to arbitrary IP addresses which are potentially in
NETLMM domain. The LMA is in a topological position through which use by mobile nodes within the localized mobility management domain.
all data-plane traffic goes, so it would have to process the flooding Like a border router, the LMA is in a topological position through
which all data plane traffic goes, so it must process the flooding
packets and perform a routing table lookup for each of them. The LMA packets and perform a routing table lookup for each of them. The LMA
could discard packets for which the destination IP address is not can discard packets for which the IP destination address is not
registered in the routing table. But other packets would have to be registered in the routing table. But other packets must be
encapsulated and forwarded. There would also be some damage to the encapsulated and forwarded. A target MAG as well as any mobile nodes
target AR and its link. attached to its access link are also likely to suffer damage because
the unrequested packets must be decapsulated and consume link
bandwidth as well as processing capacities on the receivers. This
threat is in principle the same as for denial of service on a regular
IPv6 border router, but because either the routing table lookup
enables the LMA to drop a flooding packet early or, on the contrary,
additional tunneling workload is required, the impact of an attack
against localized mobility management may be different.
In a related attack, the attacker manages to obtain a globally In a related attack, the villain 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 NETLMM domain, and perpetrates a DoS attack against that IP the localized mobility management domain and perpetrates a denial-of-
address. In general, NETLMM-based mobility management is somewhat service attack against that IP address. Localized mobility
more resistant to DoS attacks than host-based localized mobility management is in general somewhat resistant to such an attack because
management because nodes within the domain need never obtain a mobile nodes need never obtain a globally routable IP address of any
globally routable IP address of any entity within the NETLMM domain. entity within the localized mobility management domain. A
As a consequence, a compromised node cannot pass such an IP address compromised mobile node hence cannot pass such an IP address off to a
off to an attacker, limiting the ability of an unauthorized attacker remote attacker, limiting the feasibility of extracting information
to extract information on the topology of the NETLMM domain. It is on the topology of the localized mobility management domain. It is
still possible for an attacker to perform address scanning if ARs and still possible for an attacker to perform IP address scanning if MAGs
LMAs have globally routable IP addresses, or for a compromise to and LMAs have globally routable IP addresses, but the much larger
happen in another way, but the much larger IPv6 address space makes IPv6 address space makes scanning considerably more time consuming.
address scanning considerably more time consuming.
3. Threats to the MN-AR Interface 3. Threats to Interface between MAG and Mobile Node
In order to detect IP level handovers of mobile nodes, NETLMM access In order to detect the arrival and departure of mobile nodes and
routers utilize handover signaling between the mobile node and the accordingly initiate route updates with the LMA, a MAG monitors the
access router. For cellular-type interfaces, such signaling occurs mobile nodes' link-layer handoff signaling or IP-layer movement
at the wireless link layer, and the IP stack never sees any change detection signaling. Cellular access technologies utilize only the
when the mobile node moves from one AR to an AR on a different link. signaling at the wireless link layer, and the IP stack never sees any
For non-cellular interfaces, such as 802.11 or wired Ethernet-type change when the mobile node moves from one MAG to a MAG on a
interfaces, link layer signaling may not hide IP handover from the IP different link. For non-cellular access technologies, such as IEEE
stack. The IP stack may need to perform movement detection in 802.11 or wired Ethernet, the link-layer signaling may not hide a
response to some kind of link layer hint that a change in access handoff from the IP layer. Instead, IP-layer movement detection
point has occurred. This signaling may involve extensions of IPv6 signaling may have to be performed in response to a notification from
Neighbor Discovery [8] or it may involve DHCP [9] or it may involve the link layer that a change in link-layer attachment has occurred.
some link-specific IP level mechanism. In any case, the security This signaling may involve extensions [7] for IPv6 Neighbor Discovery
threats to the handover signaling that triggers NETLMM routing [8], DHCPv6 [9], or additional technology-specific functionality at
updates are the same, and are described in this section. the IP layer. In any case, the security threats on the interface
between the MAG and a mobile node are the same. They either pertain
to impersonation of the mobile node or to man-in-the-middle attacks.
3.1 Mobile Node Identity 3.1 Network Access Identity
In order for NETLMM to be able to definitively identify a mobile node In order for localized mobility management to be able to definitively
upon handover, the mobile node must establish a network access and unambiguously identify a mobile node upon handoff, the mobile
identity when it initially enters the network. For example, a mobile node must establish a network access identity when it initially
node may initially authenticate itself to the NETLMM domain based on connects to the localized mobility managment domain. E.g., the
its NAI and an AAA-based protocol. This identifier is conceptually mobile node may authenticate itself to the domain based on its NAI
independent of the mobile node's IP or link-layer addresses. In some [4] and an AAA-based protocol. The network access identity is
wireless networks, the network access identity must be re-established conceptually independent of the mobile node's IP or link-layer
on every handover between access points. addresses. For some wireless access technologies, the network access
identity must be re-established on every link-layer handoff.
NETLMM requires that the access network establish a binding between Localized mobility management requires the establishment of a secure
the network access identity and the IP addresses that the mobile node binding between the network access identity and either the IP
self-configures (if address auto-configuration is used) or that it is addresses of the mobile node, or any authentication keys associated
assigned (if stateful address configuration is used). This binding with these IP addresses. The binding is used by the MAG to deduce
is used by the AR to definitively and unambiguously deduce that a that the mobile node has handed over onto the MAG's access link,
mobile node has handed over into the AR's last hop subnet, thereby thereby providing the trigger for route update signaling to the LMA.
providing the trigger for NETLMM route update signaling to the LMA. The binding must be robust to spoofing because it would otherwise
The binding between the initial mobile-node authentication and the facilitate impersonation of the mobile node by a third party or man-
IPv6 addresses must be robust to spoofing, for it would otherwise in-the-middle attacks.
facilitate impersonation of the mobile node by a third party.
Lacking this binding, the following attacks are conceivable.
3.2 Impersonation on Handover 3.2 Impersonation of Mobile Nodes
An attacker that is able to forge an MN's network access identity can An attacker that is able to forge the network access identity of a
use this capability to fabricate handover signaling, thereby tricking neighboring victim mobile node can trick its MAG into redirecting the
the AR into believing that the victim has handed over into the AR's mobile node's packets to itself. Such an on-link attack is common
last hop subnet. The AR will then perform route update signaling for any regular IPv6 network [2].
with the LMA, causing the LMA to redirect traffic to the attacker.
The attacker can utilize this capability to examine and discard
traffic that legitimately belongs to the MN, as a means of denying
the MN service or to snoop the MN's traffic. If the attacker can
interpose between the MN and the network during router discovery and
address configuration, the attacker can mount a man in the middle
attack on the MN, spoofing the MN into believing it has a legitimate
connection with the network.
3.3 Off-Link Attacks However, if handoff signaling cannot definitively be linked back to
the legitimate network access identity, an attacker may be capable of
fabricating handoff signaling of a victim mobile node that currently
attaches to a different link. The attacker can thus trick its MAG
into believing that the mobile node has handed over onto the MAG's
access link. The MAG will then initiate route update signaling to
the LMA, causing the LMA to redirect inbound data plane packets for
the mobile node to the attacker's MAG and finally to the attacker
itself. The attacker can so examine the packets that legitimately
belong to the mobile node, or discard the packets and deny the mobile
node service. This is conceivable both if the attacker and the
mobile node are on links that connect to different MAGs, as well as
if they are on separate links connecting to the same MAG. In the
former case, two MAGs would think they see the mobile node and both
would independently perform route update signaling with the LMA. In
the latter case, route update signaling is likely to be performed
only once, and the redirection of packets from the mobile node to the
attacker is internal to the MAG. The mobile node can always
recapture its traffic back from the attacker through another run of
link-layer handoff signaling and/or IP-layer movement detection
signaling. But standard mobile nodes are generally not prepared to
counteract this kind of attack, and even where network stacks include
suitable functionality, the attack may not be noticeable early enough
at the link or IP layer to quickly institute countermeasures. The
attack is therefore disruptive at a minimum, and may potentially
persist until the mobile node initiates signaling again upon a
subsequent handoff.
Depending on the exact nature of the handover signaling, an Off-link impersonation attacks can be prevented at the link layer.
impersonation attack could be mounted from off link. Off-link E.g., they are not possible with cellular access technologies, where
attacks are possible in cases where the NETLMM domain consists of the handoff signaling is completely controlled by the wireless link
multiple access routers serving multiple last hop links. If the layer. Here, an attacker must be on the same link as the victim
security on network access identity establishment is weak, or the IP mobile node in order to disrupt the negotiation between the mobile
level movement detection signaling is unprotected so that the network node and the network. Cellular access technologies also provide
cannot definitively link the signaling back to the legitimate mobile other cryptographic and non-cryptographic attack barriers at the link
node network access identity, then an attacker from another link layer, which make mounting an impersonation attack, both on-link and
could spoof IP level movement detection signaling for a victim mobile off-link, very difficult. For non-cellular access technologies,
node and thereby steal the mobile node's traffic. however, off-link impersonation attacks may be possible.
Off-link attacks can be prevented at the link-layer. E.g., they are 3.3 Man in the Middle Attack
not possible with cellular-style protocols, where the handover
signaling is completely controlled by the wireless link layer, An attacker which can interpose between a victim mobile node and the
because an attacker must be on the same link with the MN in order to MAG during link-layer handoff signaling and/or IP-layer signaling for
disrupt the negotiation with the network. Cellular-style protocols movement detection, router discovery, and IP address configuration
also have other cryptographic and noncryptographic barriers to attack can mount a man-in-the-middle attack on the mobile node, spoofing the
at the link layer, which make mounting an impersonation attack, both mobile node into believing that it has a legitimate connection with
on-link and off-link, very difficult. For non-cellular-style the localized mobility management domain. The attacker can thus
protocols, however, it may be possible for an off-link attacker to intercept, inspect, modify, or selectively drop packets sourced by or
mount an impersonation attack. destined to the mobile node.
4. Security Considerations 4. Security Considerations
The document describes threats to the NETLMM protocol [3] and to the This document describes threats to network-based localized mobility
MN-AR interface functions necessary to support network-based mobility management. These may either occur on the interface between the LMA
management [2]. Mitigation measures for these threats, and the and a MAG, or on the interface between a MAG and a mobile node.
security considerations associated with those measures, are described Mitigation measures for the threats, as well as the security
in the respective drafts that discuss the NETLMM protocol and the considerations associated with those measures, are described in the
MN-AR interface. respective protocol specifications [10][11] for the two interfaces.
5. Acknowledgment 5. IANA Considerations
The authors would like to thank Gregory Daley, Gerardo Giaretta, This document has no actions for IANA.
Julien Laganier, Phil Roberts, and Vidya Narayanan for their comments
and suggestions regarding this document.
6. Informative References 6. Acknowledgment
[1] Kempf, J., "Problem Statement for IP Local Mobility", The authors would like to thank the NETLMM working group, especially
IETF Internet Draft draft-ietf-netlmm-nohost-ps-01.txt (work in Jari Arkko, Gregory Daley, Gerardo Giaretta, Wassim Haddad, Julien
progress), April 2006. Laganier, Lakshminath Dondeti, Henrik Levkowetz, Phil Roberts, Vidya
Narayanan, and Pekka Savola (in alphabetical order) for valuable
comments and suggestions regarding this document.
[2] Laganier, J. and S. Narayanan, "Network-based Localized 7. Informative References
Mobility Management Interface between Mobile Node and Access
Router", IETF Internet Draft draft-ietf-netlmm-mn-ar-if-00.txt
(work in progress), April 2006.
[3] "NETLMM Protocol Specification (TBD)", IETF Working Group Item [1] Kempf, J., "Problem Statement for Network-based Localized
(work in progress). Mobility Management", IETF Internet Draft
draft-ietf-netlmm-nohost-ps-04.txt (work in progress),
June 2006.
[4] Manner, J. and M. Kojo, "Mobility Related Terminology", [2] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
IETF Request for Comments 3753, June 2004. Discovery (ND) Trust Models and Threats", IETF Request for
Comments 3756, May 2004.
[5] Kempf, J., "Goals for Network-based Localized Mobility [3] Manner, J. and M. Kojo, "Mobility Related Terminology",
Management (NETLMM)", IETF Internet Draft IETF Request for Comments 3753, June 2004.
draft-ietf-netlmm-nohost-req-01.txt (work in progress),
April 2006.
[6] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network [4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", IETF Request for Comments 4282, Access Identifier", IETF Request for Comments 4282,
December 2005. December 2005.
[7] Aura, T., "Cryptographically Generated Addresses (CGA)", [5] Aura, T., "Cryptographically Generated Addresses (CGA)",
IETF Request for Comments 3972, March 2005. IETF Request for Comments 3972, March 2005.
[8] Kempf, J., Narayanan, S., Nordmark, E., Pentland, B., and JH. [6] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)",
IETF Request for Comments 4140, August 2005.
[7] Kempf, J., Narayanan, S., Nordmark, E., Pentland, B., and JH.
Choi, "Detecting Network Attachment in IPv6 Networks (DNAv6)", Choi, "Detecting Network Attachment in IPv6 Networks (DNAv6)",
IETF Internet Draft draft-ietf-dna-protocol-00.txt (work in IETF Internet Draft draft-ietf-dna-protocol-01.txt (work in
progress), February 2006. progress), June 2006.
[9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [8] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
IETF Internet Draft draft-ietf-ipv6-2461bis-07.txt (work in
progress), May 2006.
[9] Droms, R., Bound, J., Volz, B., Lemon, T., E., C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", IETF Internet Draft draft-ietf-dna-protocol-00.txt (DHCPv6)", IETF Request for Comments 3315, July 2003.
(work in progress), February 2006.
[10] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [10] Giaretta, G., "NetLMM Protocol", IETF Internet Draft
Discovery (ND) Trust Models and Threats", IETF Request for draft-giaretta-netlmm-dt-protocol-00.txt (work in progress),
Comments 3756, May 2004. June 2006.
[11] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [11] Laganier, J., Narayanan, S., and F. Templin, "Network-based
Nordmark, "Mobile IP Version 6 Route Optimization Security Localized Mobility Management Interface between Mobile Node and
Design Background", IETF Request for Comments 4225, Access Router", IETF Internet Draft
December 2005. 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
skipping to change at page 11, line 5 skipping to change at page 12, line 25
James Kempf James Kempf
DoCoMo USA Labs DoCoMo USA Labs
181 Metro Drive, Suite 300 181 Metro Drive, Suite 300
San Jose, CA 95110 San Jose, CA 95110
USA USA
Phone: +1 408 451 4711 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 01 to version 02 of the document. Editorial revisions are
not explicitly identified.
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 interfer 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 2.4: Included description of DoS/flooding attack against
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
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 3.1: The binding with the network access identity may be
with the authentication keys associated with the mobile node's IP
address, not necessarily with the IP addresses themselves.
o Section 3.2: Off-link attack may be mounted from a link that
connects to a different MAG than the victim mobile node's MAG.
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
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.
 End of changes. 55 change blocks. 
263 lines changed or deleted 390 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/