draft-ietf-netlmm-threats-00.txt   draft-ietf-netlmm-threats-01.txt 
Network Working Group J. Kempf Network Working Group C. Vogt
Internet-Draft DoCoMo USA Labs Internet-Draft Universitaet Karlsruhe (TH)
Expires: October 19, 2006 C. Vogt Expires: December 25, 2006 J. Kempf
Universitaet Karlsruhe (TH) DoCoMo USA Labs
April 17, 2006 June 23, 2006
Security Threats to Network-based Localized Mobility Management Security Threats to Network-based Localized Mobility Management
draft-ietf-netlmm-threats-00.txt draft-ietf-netlmm-threats-01.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 October 19, 2006. This Internet-Draft will expire on December 25, 2006.
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-based mobility This document discusses security threats to NETLMM mobility
management with a focus on threats on the interface between mobile management. Threats to NETLMM occur on two interfaces: the access
nodes and access routers. Threats to the NETLMM protocol itself, router/localized mobility anchor interface and the access router/
which runs between the access routers and mobility anchor points, are mobile node interface. Threats to the access router/localized
similar to those faced by other protocols between network entities mobility anchor interface are threats to the NETLMM protocol itself.
like routers. These threats are handled in the NETLMM protocol This document discusses threats on these two interfaces.
specification. In contrast, threats on the interface between mobile
nodes and access routers are different, because the access routers
are presenting the NETLMM domain as a single subnet, in order to
allow mobile nodes to continue using the same IP address as they move
from one access router to another.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. NETLMM Architecture . . . . . . . . . . . . . . . . . . . . . 3 2. Threats to the AR/LMA Interface . . . . . . . . . . . . . . . 4
3. Outline of Threats . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Unauthorized AR . . . . . . . . . . . . . . . . . . . . . 4
4. Threats to IPv6 Address to Mobile Node Identifier Mapping . . 6 2.2 Unauthorized LMA . . . . . . . . . . . . . . . . . . . . . 5
4.1 Roaming at a Victim's Costs . . . . . . . . . . . . . . . 6 2.3 Man in the Middle Attack . . . . . . . . . . . . . . . . . 5
4.2 Off-Path Eavesdropping . . . . . . . . . . . . . . . . . . 7 2.4 Denial of Service Attack on the LMA . . . . . . . . . . . 5
4.3 Denial of Service . . . . . . . . . . . . . . . . . . . . 7 3. Threats to the MN-AR Interface . . . . . . . . . . . . . . . . 6
5. Threats to Access Router Functions . . . . . . . . . . . . . . 8 3.1 Mobile Node Identity . . . . . . . . . . . . . . . . . . . 6
6. Threats to Location Privacy . . . . . . . . . . . . . . . . . 8 3.2 Impersonation on Handover . . . . . . . . . . . . . . . . 7
6.1 Threats from Nodes within the NETLMM Domain . . . . . . . 9 3.3 Off-Link Attacks . . . . . . . . . . . . . . . . . . . . . 7
6.2 Threats from Nodes At Any Location . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Informative References . . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 14
1. Introduction 1. Introduction
The NETLMM architecture supports movement of IPv6 mobile nodes within The NETLMM architecture supports movement of IPv6 mobile nodes within
a localized mobility management domain with minimal involvement on a localized mobility management domain with no specialized support on
the part of the mobile node itself. In contrast to architectures the mobile node for localized mobility management. In contrast to
where there is no localized mobility management support or where architectures where there is no localized mobility management support
localized mobility management support is provided by a host-based or where localized mobility management support is provided by a host-
solution, in the NETLMM architecture, the mobile node is able to keep based solution, in the NETLMM architecture, the mobile node is able
its IP address constant within the localized mobility management to keep its IP address constant within the localized mobility
domain as it moves, avoiding the signaling overhead required to management domain as it moves, avoiding the signaling overhead
change the address. Software specifically for localized mobility required to change the address. Software specifically for localized
management is not required on the mobile node, though software for IP mobility management is not required on the mobile node, though
link movement detection may be needed and of course driver software software for IP movement detection may be needed and, of course,
for link layer movement is always required. More on the localized driver software for link-layer movement is always required. More on
mobility management problem can be found in [3]. the network-based localized mobility management architecture can be
found in [1].
In this document, threats to the protocols involved in implementing
the NETLMM architecture are discussed. The document focuses on
threats on the mobile node to access router interface. Threats to
the NETLMM protocol itself, which runs on the access router to
mobility anchor point interface are briefly described, but detailed
requirements and solutions for security for the NETLMM protocol are
handled in the requirements and NETLMM protocol specification
documents [1][4]. While a default IP-based protocol for the
interface between mobile nodes and access routers has been specified
[2], that interface is the focus of this document because the
protocol running across it can potentially be completely handled by
the wireless link protocol without any IP involvement. This document
is intended to provide guidance to developers linking the NETLMM
protocol to such wireless link protocols so that they know what the
potential security threats are.
1.1 Terminology
Mobility terminology in this document follows that in [5], with those
revisions and additions from [3] and [4].
2. NETLMM Architecture
Figure 1 depicts the NETLMM architecture. A mobility anchor point
(MAP) manages routing for packets to mobile nodes as they move
through the NETLMM domain. The MAP communicates with a collection of
access routers (AR_1 through AR_n in Figure 1). Each access router
is connected to a collection of wireless access points (AP_1 through
AP_m in Figure 1) that provide wireless access links to mobile nodes.
The access routers handle routing updates to the MAP when a new
mobile node moves onto the IP link controlled by the access router.
In order for the mobile node to keep its address constant across the
NETLMM domain, the access routers must all advertise the same IPv6
subnet prefixes to mobile nodes on their link, and the internal
gateway protocol (IGP) used to distribute routes to routers
throughout the IGP routing domain must target the MAP as the last hop
router for those IPv6 subnet prefixes that span IP links in the
NETLMM domain. The MAP tunnels packets to and from the access
routers, changing to a new access router when a routing update from a
new access router indicates that an mobile node has moved.
NETLMM Domain
+-------+
| MAP |
+-------+
@ @
@ @
@ @
@ AR-MAP @
@ Interface @
@ @
+------+ +------+
| AR_1 | ... | AR_n |
+------+ +------+
* *
* * MN-AR *
* * Interface *
* * *
* * *
* * *
/\ /\ /\
/ \ ... / \ ... / \
/ AP \ / AP \ / AP \
/ AP_1 \ / AP_i \ / AP_m \
-------- -------- --------
+--+ +--+ +--+
|MN|----->|MN|----->|MN|----->
+--+ +--+ +--+
Figure 1: Protocol Interfaces in the NETLMM Architecture
3. Outline of Threats
The threats for the NETLMM architecture break down into two parts:
o Threats on the interface between mobile nodes and access routers.
o Threats on the interface between the access routers and a MAP.
Threats on the interface between mobile nodes and access routers are, In the NETLMM architecture, a localized mobility anchor (LMA)
in many respects, similar to threats [6] against the IPv6 Neighbor maintains routes for mobile nodes. Packets to and from mobile nodes
Discovery protocol, except that rather than being confined to a (MNs) on the last hop wireless links are routed through the LMA.
single IP link, the threat potential is distributed across the last When a MN moves from one access router (AR) to another, the route for
hops of the NETLMM domain. The interface between mobile nodes and the mobile node on the LMA is updated by the ARs. The NETLMM
access routers may run the default IP protocol [2], or it may run a architecture therefore has two interfaces:
wireless link technology-specific protocol. Threats on this
interface are discussed in detail in the following sections.
The threats on the interface between access routers and a MAP are of 1. The AR to LMA interface where route update signaling occurs.
the same nature as the threats that an IGP for routing faces.
Specifically, a rogue MAP or a rouge access router can end up
injecting incorrect tunnels or host routes for mobile nodes. This
may result in traffic being siphoned off, facilitating impersonation
of the mobile node or the mobile node's peer, or in traffic being
dropped, resulting in a DoS attack on the mobile node.
Rouge access routers and MAPs can be handled with the same security 2. The MN to AR interface where movement detection and IP handover
measures used by IGPs for standard IP routing. Since these threats signaling occurs.
are specific to the NETLMM protocol, which runs across the interface
between the access routers and a MAP, they are discussed in the
NETLMM protocol specification [1]. The document also identifies
specific security measures for the NETLMM protocol.
Another threat on the interface between access routers and the MAP is The NETLMM architecture specifies no standardized protocol on the
DoS against network entities. Here, an attacker manages to obtain a MN/AR interface. The network must be informed when a mobile node
globally routable IP address of an access router, a MAP, or some having an IP address moves from one access router to another, but how
other network entity, and perpetrates a DoS attack against that IP that occurs is not part of the NETLMM protocol. The mechanism can be
address. In general, NETLMM-based mobility management is somewhat entirely implemented by the wireless link protocol, such as is common
more resistant to DoS attacks than host-based localized mobility for cellular networks. In that case, the IP layer never detects any
management because nodes within the domain need never obtain a movement, even though the mobile node may be moving from one link to
globally routable IP address of any entity within the NETLMM domain. another handled by a different access router. If the wireless link
As a consequence, a compromised node cannot pass such an IP address protocol does not handle movement detection and IP handover, however,
off to an attacker, limiting the ability of an attacker to extract support at the IP level is required. In that case, the mobile node
information on the topology of the NETLMM domain. It is still must perform IP signaling for active movement detection. The access
possible for an attacker to perform address scanning if access router uses this signaling to infer mobile node movement. More about
routers and MAPs have globally routable IP addresses, or for a IP level movement detection and NETLMM can be found in the NETLMM
compromise to happen in another way, but the much larger IPv6 address MN-AR interface document [2].
space makes address scanning considerably more time consuming.
Network operators need to take these considerations into account, and
ensure that their internal network topologies are sparsely populated.
4. Threats to IPv6 Address to Mobile Node Identifier Mapping The NETLMM protocol itself is defined on the AR/LMA interface, and is
specified in [3].
A mobile node identifies itself to the NETLMM domain based on an This document discusses threats to security on the NETLMM interfaces.
identifier that is conceptually independent of its IP and link-layer
addresses. For packets to be later recognized as coming from the
mobile node, the mobile node's identity is tied to its IP address, or
possibly to any other identifier which shows up in the packets (e.g.,
the link-layer address or an IPsec SPI), during the initial
authentication procedure. Without lack of generality, it is assumed
in the following that the mobile node's IP address is used for this
purpose.
Per se, a mapping between the mobile-node identifier and the IP The discussion in this document focuses only on NETLMM signaling
address is insufficient to protect the mobile node against traffic, both for the NETLMM protocol itself and for signaling on the
impersonation by a third party. Specifically, the following attacks MN/AR interface that signals mobile node movement to the network.
are conceivable. Details on how the threats are handled by the NETLMM protocol and the
IP MN/AR interface are discussed in [3] and [2] respectively.
4.1 Roaming at a Victim's Costs 1.1 Terminology
Given that regular IP packets do not carry a signature of the mobile Mobility terminology in this document follows that in [4], with those
node or a comparable proof of origin, an attacker may trick the revisions and additions from [1] and [5]. In addition, the following
NETLMM domain into accepting packets, sent by the attacker from the definition is used:
mobile node's IP address, and charging any forwarding services or
other due services to the mobile node's account. This allows the
attacker to roam across the entire NETLMM domain and communicate at
the mobile node's costs.
The attacker not necessarily needs to be a customer of the NETLMM Network access identity
domain since it does not have to authenticate itself to the NETLMM
domain. It rather waits for the mobile node to accomplish the
authentication procedure. The attacker must also record the mobile
node's IP address so that it can later forge packets that appear to
be coming from the mobile node. The attack may or may not overlap
with a period during which the mobile node itself communicates, and
the attacker may or may not be on the same link as the mobile node
while the attack proceeds. The duration of the attack depends on how
long a refresh interval the NETLMM domain imposes on the mobile
node's authentication.
This threat can be eliminated if appropriate per-packet A identity established for the mobile node with the network during
authentication is used for packets that the mobile node sends. The network access authentication that allows the network to
packets can be authenticated either on the link layer or on the IP unambiguously identify the mobile node for signaling purposes.
layer, provided that the IP address, based on which the NETLMM domain For example, a wireless link session key established by the
identifies the packets as coming from the mobile node, is covered by wireless link layer, the Network Access Identifier (NAI) [6], or
the protection and securely bound to the authentication context. the SEND public key [7] may serve as the identifier associated
with the network access identity.
A possible mechanism for link-layer authentication is a combination 2. Threats to the AR/LMA Interface
of IEEE 802.11i technology and a function in the access router that
verifies whether or not an inbound packet's IP source address is
bound to the link-layer encryption keys. At the IP layer, IPsec AH
provides appropriate protection. Note that IPsec ESP is not
sufficient as it does not cover a packet's IP header.
A related attack shows the importance of a secure binding between a In this section, threats to the AR/LMA interface are discussed.
mobile node's IP address and the keys it uses for per-packet Since the information propagated between the AR and LMA is routing
authentication: Failure to provide such a binding allows an updates, the threats on this interface are similar to the threats
attacker, who is itself a customer of the NETLMM domain, to experienced by two routers exchanging routing information with a
authenticate to the NETLMM domain, obtain the keys for per-packet routing protocol. One difference is that the AR and LMA need not be
authentication, and then spoof its IP source address to be the separated by a single hop, whereas routing updates are usually
address of some third node. The attacker can thus roam and propagated by flooding, so two routers exchanging routing information
communicate at its victim's costs. are usually separated by a single hop.
4.2 Off-Path Eavesdropping 2.1 Unauthorized AR
If an attacker can forge a victim's mobile-node identifier or An AR that is not authorized to propagate NETLMM routing updates can
generate packets that appear to originate from the victim, the result in serious damage to the security of a localized mobility
attacker can siphon off packets meant for the victim and redirect management domain. The AR can redirect traffic from MNs on the AR's
them to its own location. The perpetrator can inspect these packets, lst hop link arbitrarily, without authorization from the MN. The AR
effectively waging an "off-path" eavesdropping attack. However, it can ignore routing updates from the LMA so that the victim MNs lose
is impossible for the attacker to forward the packets on to the their traffic. An unauthorized AR can also intercept, inspect, and
victim given that the attacker and the victim use the same IP redirect data plane traffic for mobile nodes on its last hop
address. The compromised communication session is therefore highly interface, but this threat is common for any last hop router.
likely to abort before the attack causes significant damage.
The described redirection attack resembles a related man-in-the- Note that this threat applies not just to an AR that is compromised,
middle attack identified in [8]. In that attack, the impersonator but also to an off-path attacker that manages to forge the identity
manages to redirect packets exchanged between a victim and the of an authorized AR, and thereby spoof the LMA into conducting NETLMM
victim's peer via itself. Packets thus eventually reach their protocol signaling as if the attacker were legitimate. Such an
intended destination, although the attacker can eavesdrop on them or attack could be conducted transiently, to selectively disable traffic
modify them on the fly. The triangular routing becomes possible for particular mobile nodes at particular times.
because the attacker uses a different IP address than its victim.
The NETLMM architecture mitigates this attack to some extent in that
the attacker cannot redirect a third node's packets unless it somehow
duplicates that node's IP address.
4.3 Denial of Service 2.2 Unauthorized LMA
A similar attack strategy to the one described in Section 4.2 causes An unauthorized LMA can ignore routing updates from legitimate ARs,
denial of service to a victim. Again, the attacker forges the or forge routing updates for MNs in order to redirect or deny traffic
victim's mobile-node identifier or generates packets that appear to to victims. Since data plane traffic for mobile nodes routes through
originate from the victim, and it thereby redirects the packets meant the LMA, a rogue LMA can also intercept, inspect, and redirect data
for the victim to its own location. Any request that the victim plane traffic for mobile nodes on ARs supported by the LMA. A piece
sends to nodes located elsewhere than its local link will of malware might further manipulate the LMA's routing table such that
consequently solicit responses that the NETLMM domain will route to all packets are directed towards a single AR, resulting in a DoS
the attacker's location. As a result, the victim is unable to attack against that AR and its attached link. Again, these are the
communicate. same threats experienced by any intermediate router in the network.
This attack is limited in that the attacker can only redirect the Note that these threats apply not just to a LMA that is compromised,
victim's packets to its own location because it must obtain the but also to an off-path attacker that manages to forge the identity
victim's IP address. This is a natural limitation of the NETLMM of an authorized LMA, and thereby spoof the ARs in a localized
architecture because packets are only forwarded to links where the mobility domain into conducting NETLMM protocol signaling as if the
destination node is known (or believed) to be present. attacker were legitimate. Such an attack could be conducted
transiently, to selectively disable traffic for particular mobile
nodes or ARs at particular times.
5. Threats to Access Router Functions 2.3 Man in the Middle Attack
An attacker that is able to set up a bogus access router can trick An unauthorized intermediate router or other node that manages to
mobile nodes into sending their packets to the attacker. The interject itself between the AR and LMA is in a position to
attacker can thus act as an active or passive man in the middle, intercept, inspect, and redirect NETLMM protocol signaling traffic
possibly forwarding the victim's packets to their actual destination between an authorized LMA and authorized ARs handling mobility
via a path outside the NETLMM domain. management for the localized mobility management domain. If the
attacker can masquerade as an AR to the LMA and as the LMA to the
ARs, it may be in a position to spoof both sides into believing that
they have a secure link. The attacker can then utilize the
information derived from the NETLMM protocol signaling for various
purposes.
Return packets sent by the victim's peer are likely to be delivered 2.4 Denial of Service Attack on the LMA
through the NETLMM domain, however. The attacker may hence not be
able to manipulate those packets, although it may still read them.
A more sophisticated attacker can impersonate an access router and An attacker could launch a denial-of-service attack on the LMA by
act as a NAT box at the same time. It tricks a victim into accepting sending packets to arbitrary IP addresses with a prefix from the
it as its default router and forwards the victim's packets, after NETLMM domain. The LMA is in a topological position through which
manipulation, with an IP source address through which it is itself all data-plane traffic goes, so it would have to process the flooding
reachable. Unless the victim's peer expects a particular IP address, packets and perform a routing table lookup for each of them. The LMA
it will send any responses "back" to the attacker. The attacker can could discard packets for which the destination IP address is not
read and/or manipulate these packets and finally deliver them to the registered in the routing table. But other packets would have to be
victim. encapsulated and forwarded. There would also be some damage to the
target AR and its link.
Essentially, a NETLMM domain is subject to attacks against access In a related attack, the attacker manages to obtain a globally
routers in the same way as any conventional IPv6 domain. These routable IP address of an LMA or a different network entity within
threats are due to vulnerabilities of the IPv6 Neighbor Discovery the NETLMM domain, and perpetrates a DoS attack against that IP
protocol, and are as such identified in [6]. In particular, address. In general, NETLMM-based mobility management is somewhat
impersonating an access router requires the attacker to send spoofed more resistant to DoS attacks than host-based localized mobility
Router Advertisement messages, which can be precluded, or at least management because nodes within the domain need never obtain a
mitigated to a reasonable extent, by SeND [7]. globally routable IP address of any entity within the NETLMM domain.
As a consequence, a compromised node cannot pass such an IP address
off to an attacker, limiting the ability of an unauthorized attacker
to extract information on the topology of the NETLMM domain. It is
still possible for an attacker to perform address scanning if ARs and
LMAs have globally routable IP addresses, or for a compromise to
happen in another way, but the much larger IPv6 address space makes
address scanning considerably more time consuming.
6. Threats to Location Privacy 3. Threats to the MN-AR Interface
The location privacy of mobile nodes may be compromised if their In order to detect IP level handovers of mobile nodes, NETLMM access
identities can somehow be associated to their IP or MAC addresses. routers utilize handover signaling between the mobile node and the
This may happen if mobile-node identifiers can be read from the access router. For cellular-type interfaces, such signaling occurs
protocol executed on the interface between mobile nodes and access at the wireless link layer, and the IP stack never sees any change
routers, if the NETLMM protocol run between access routers and the when the mobile node moves from one AR to an AR on a different link.
MAP leaks the mobile-node identifiers, or if an attacker manages to For non-cellular interfaces, such as 802.11 or wired Ethernet-type
steal confidential information from a NETLMM database. Certainly, an interfaces, link layer signaling may not hide IP handover from the IP
attacker may also be able to infer a mobile node's identity from stack. The IP stack may need to perform movement detection in
other sources, e.g., from information extracted from application- response to some kind of link layer hint that a change in access
layer payloads sent or received by the mobile node. But those point has occurred. This signaling may involve extensions of IPv6
attacks are not specific to NETLMM and hence outside the scope of Neighbor Discovery [8] or it may involve DHCP [9] or it may involve
this document. some link-specific IP level mechanism. In any case, the security
threats to the handover signaling that triggers NETLMM routing
updates are the same, and are described in this section.
Threats to location privacy that are specific to NETLMM can 3.1 Mobile Node Identity
conceptually be separated into threats that emanate from nodes which
are themselves within the NETLMM domain and threats that may also
come from nodes outside the NETLMM domain.
6.1 Threats from Nodes within the NETLMM Domain In order for NETLMM to be able to definitively identify a mobile node
upon handover, the mobile node must establish a network access
identity when it initially enters the network. For example, a mobile
node may initially authenticate itself to the NETLMM domain based on
its NAI and an AAA-based protocol. This identifier is conceptually
independent of the mobile node's IP or link-layer addresses. In some
wireless networks, the network access identity must be re-established
on every handover between access points.
An attacker within the localized mobility management domain can NETLMM requires that the access network establish a binding between
obtain location information through the usual IPv6 Neighbor Discovery the network access identity and the IP addresses that the mobile node
mechanisms. E.g., the attacker can obtain the IP address of a victim self-configures (if address auto-configuration is used) or that it is
within the localized mobility management domain and multicasts a assigned (if stateful address configuration is used). This binding
Neighbor Solicitation message to resolve this IP address to the is used by the AR to definitively and unambiguously deduce that a
victim's link-layer address. If the attacker receives a Neighbor mobile node has handed over into the AR's last hop subnet, thereby
Advertisement message in response, it knows that the victim is providing the trigger for NETLMM route update signaling to the LMA.
present somewhere in the NETLMM domain. The binding between the initial mobile-node authentication and the
IPv6 addresses must be robust to spoofing, for it would otherwise
facilitate impersonation of the mobile node by a third party.
Lacking this binding, the following attacks are conceivable.
The obtained location information may be more precise depending on 3.2 Impersonation on Handover
how far beyond the local link IPv6 Neighbor Discovery messages are
forwarded by the NETLMM routing fabric. In case such messages are
kept link-local, the attacker can even conclude from a received
Neighbor Advertisement message that the victim is on the same link.
Likewise, the attacker can use Duplicate Address Detection to An attacker that is able to forge an MN's network access identity can
determine whether another node is within the localized mobility use this capability to fabricate handover signaling, thereby tricking
management domain or on the local link. The attacker multicasts a the AR into believing that the victim has handed over into the AR's
Neighbor Solicitation message to the solicited-node multicast address last hop subnet. The AR will then perform route update signaling
for the victim's address. If a Neighbor Advertisement message with the LMA, causing the LMA to redirect traffic to the attacker.
returns, the attacker knows that the victim is somewhere in the The attacker can utilize this capability to examine and discard
localized mobility management domain or on the local link, depending traffic that legitimately belongs to the MN, as a means of denying
on whether or not NETLMM routers forward Duplicate Address Detection the MN service or to snoop the MN's traffic. If the attacker can
signaling. 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.
IPv6 Neighbor Discovery messages are normally of link-local scope and 3.3 Off-Link Attacks
as such not forwarded by routers. This is based on the prerequisite
that prefix sets of different links are disjunct. However, links
within a NETLMM domain all use the same set of prefixes. While this
does not necessarily imply that address-resolution messages need to
be distributed across an entire NETLMM domain (link-local redirects
may also be feasible), it does imply that messages exchanged for the
purpose of Duplicate Address Detection would have to.
More precise location information can only be acquired from a Depending on the exact nature of the handover signaling, an
position where the links incoming to and outgoing from the MAP can be impersonation attack could be mounted from off link. Off-link
monitored. An attacker in this position can listen to the NETLMM attacks are possible in cases where the NETLMM domain consists of
protocol traffic between the MAP and the different access routers and multiple access routers serving multiple last hop links. If the
thus derive the link where its victim is currently attached to. The security on network access identity establishment is weak, or the IP
attacker may even be able to reasonably track its victim if it has level movement detection signaling is unprotected so that the network
access to only a subset of the links to and from the MAP. cannot definitively link the signaling back to the legitimate mobile
node network access identity, then an attacker from another link
could spoof IP level movement detection signaling for a victim mobile
node and thereby steal the mobile node's traffic.
6.2 Threats from Nodes At Any Location Off-link attacks can be prevented at the link-layer. E.g., they are
not possible with cellular-style protocols, where the handover
signaling is completely controlled by the wireless link layer,
because an attacker must be on the same link with the MN in order to
disrupt the negotiation with the network. Cellular-style protocols
also have other cryptographic and noncryptographic barriers to attack
at the link layer, which make mounting an impersonation attack, both
on-link and off-link, very difficult. For non-cellular-style
protocols, however, it may be possible for an off-link attacker to
mount an impersonation attack.
Furthermore, a mobile node's presence within the NETLMM domain is 4. Security Considerations
also implied by the prefix of its IP source address. Correspondent
nodes can identify the NETLMM domain and coarsely localize the mobile
node based on this address, as they could do with any other IP node.
The NETLMM architecture blurs the resolution of such location The document describes threats to the NETLMM protocol [3] and to the
information to some extent in that the IP source address does not MN-AR interface functions necessary to support network-based mobility
contain information about the link within the NETLMM domain where the management [2]. Mitigation measures for these threats, and the
mobile node currently is. Tracing tools such as "traceroute" may security considerations associated with those measures, are described
allow the correspondent node (or any other node with the mobile in the respective drafts that discuss the NETLMM protocol and the
node's IP address) to obtain the IP addresses of some routers on the MN-AR interface.
path to the mobile node. But since packets are tunneled on the sub-
path between the MAP and the mobile node's current access router, the
acquired information may not be sufficient to actually locate the
mobile node.
The location tracker does not necessarily have to be a correspondent 5. Acknowledgment
node of its victim. The attacker may also be another node, both
outside and within the NETLMM domain, provided that it has somehow
obtained the victim's IP address.
This threat can be eliminated by filtering tracing attempts at the The authors would like to thank Gregory Daley, Gerardo Giaretta,
NETLMM domain gateways. Julien Laganier, Phil Roberts, and Vidya Narayanan for their comments
and suggestions regarding this document.
7. Security Considerations 6. Informative References
This document deals with the security of the NETLMM architecture. [1] Kempf, J., "Problem Statement for IP Local Mobility",
IETF Internet Draft draft-ietf-netlmm-nohost-ps-01.txt (work in
progress), April 2006.
8. Acknowledgment [2] Laganier, J. and S. Narayanan, "Network-based Localized
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.
The authors would like to thank Phil Roberts for his comments and [3] "NETLMM Protocol Specification (TBD)", IETF Working Group Item
suggestions regarding the initial version of this document. (work in progress).
9. Informative References [4] Manner, J. and M. Kojo, "Mobility Related Terminology",
IETF Request for Comments 3753, June 2004.
[1] "NETLMM Protocol Specification (TBD)", IETF Working Group Item [5] Kempf, J., "Goals for Network-based Localized Mobility
(work in progress). Management (NETLMM)", IETF Internet Draft
draft-ietf-netlmm-nohost-req-01.txt (work in progress),
April 2006.
[2] "NETLMM Mobile-Node Access-Router Protocol Specification (TBD)", [6] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
IETF Working Group Item (work in progress). Access Identifier", IETF Request for Comments 4282,
December 2005.
[3] Kempf, J., "Problem Statement for IP Local Mobility", [7] Aura, T., "Cryptographically Generated Addresses (CGA)",
IETF Internet Draft draft-kempf-netlmm-nohost-ps-00.txt (work in IETF Request for Comments 3972, March 2005.
progress), June 2005.
[4] Kempf, J., "Requirements and Gap Analysis for IP Local [8] Kempf, J., Narayanan, S., Nordmark, E., Pentland, B., and JH.
Mobility", IETF Internet Draft Choi, "Detecting Network Attachment in IPv6 Networks (DNAv6)",
draft-kempf-netlmm-nohost-req-00.txt (work in progress), IETF Internet Draft draft-ietf-dna-protocol-00.txt (work in
July 2005. progress), February 2006.
[5] Manner, J. and M. Kojo, "Mobility Related Terminology", [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
IETF Request for Comments 3753, June 2004. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", IETF Internet Draft draft-ietf-dna-protocol-00.txt
(work in progress), February 2006.
[6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [10] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", IETF Request for Discovery (ND) Trust Models and Threats", IETF Request for
Comments 3756, May 2004. Comments 3756, May 2004.
[7] Aura, T., "Cryptographically Generated Addresses (CGA)", [11] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
IETF Request for Comments 3972, March 2005.
[8] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", IETF Request for Comments 4225, Design Background", IETF Request for Comments 4225,
December 2005. December 2005.
Authors' Addresses Authors' Addresses
James Kempf
DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110
USA
Phone: +1 408 451 4711
Email: kempf@docomolabs-usa.com
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
DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110
USA
Phone: +1 408 451 4711
Email: kempf@docomolabs-usa.com
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.
skipping to change at page 14, line 29 skipping to change at page 11, line 29
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
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 Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 59 change blocks. 
385 lines changed or deleted 285 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/