One document matched: draft-kempf-netlmm-threats-00.txt
Network Working Group J. Kempf
Internet-Draft DoCoMo USA Labs
Expires: August 18, 2006 C. Vogt
Universitaet Karlsruhe (TH)
February 14, 2006
Security Threats to Network-based Localized Mobillity Management
draft-kempf-netlmm-threats-00.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
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document discusses security threats to NETLMM-based mobility
management with a focus on threats on the interface between mobile
nodes and access routers. Threats to the NETLMM protocol itself,
which runs between the access routers and mobility anchor points, are
similar to those faced by other protocols between network entities
like routers. These threats are handled in the NETLMM protocol
specification. In contrast, threats on the interface between mobile
Kempf & Vogt Expires August 18, 2006 [Page 1]
Internet-Draft Security Threats to NetLMM February 2006
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. NETLMM Architecture . . . . . . . . . . . . . . . . . . . . . 3
3. Outline of Threats . . . . . . . . . . . . . . . . . . . . . . 5
4. Threats to IPv6 Address to Mobile Node Identifier Mapping . . 6
4.1 Roaming at a Victim's Costs . . . . . . . . . . . . . . . 6
4.2 Off-Path Eavesdropping . . . . . . . . . . . . . . . . . . 7
4.3 Denial of Service . . . . . . . . . . . . . . . . . . . . 7
5. Threats to Access Router Functions . . . . . . . . . . . . . . 8
6. Threats to Location Privacy . . . . . . . . . . . . . . . . . 8
6.1 Threats from Nodes within the NETLMM Domain . . . . . . . 9
6.2 Threats from Nodes At Any Location . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 14
Kempf & Vogt Expires August 18, 2006 [Page 2]
Internet-Draft Security Threats to NetLMM February 2006
1. Introduction
The NETLMM architecture supports movement of IPv6 mobile nodes within
a localized mobility management domain with minimal involvement on
the part of the mobile node itself. In contrast to architectures
where there is no localized mobility management support or where
localized mobility management support is provided by a host-based
solution, in the NETLMM architecture, the mobile node is able to keep
its IP address constant within the localized mobility management
domain as it moves, avoiding the signaling overhead required to
change the address. Software specifically for localized mobility
management is not required on the mobile node, though software for IP
link movement detection may be needed and of course driver software
for link layer movement is always required. More on the localized
mobility management problem can be found in [3].
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.
Kempf & Vogt Expires August 18, 2006 [Page 3]
Internet-Draft Security Threats to NetLMM February 2006
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
Kempf & Vogt Expires August 18, 2006 [Page 4]
Internet-Draft Security Threats to NetLMM February 2006
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 many respects, similar to threats [6] against the IPv6 Neighbor
Discovery protocol, except that rather than being confined to a
single IP link, the threat potential is distributed across the last
hops of the NETLMM domain. The interface between mobile nodes and
access routers may run the default IP protocol [2], or it may run a
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
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
measures used by IGPs for standard IP routing. Since these threats
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
DoS against network entities. Here, an attacker manages to obtain a
globally routable IP address of an access router, a MAP, or some
other network entity, and perpetrates a DoS attack against that IP
address. In general, NETLMM-based mobility management is somewhat
more resistant to DoS attacks than host-based localized mobility
management because nodes within the domain need never obtain a
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 attacker to extract
information on the topology of the NETLMM domain. It is still
possible for an attacker to perform address scanning if access
routers and MAPs 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.
Network operators need to take these considerations into account, and
ensure that their internal network topologies are sparsely populated.
Kempf & Vogt Expires August 18, 2006 [Page 5]
Internet-Draft Security Threats to NetLMM February 2006
4. Threats to IPv6 Address to Mobile Node Identifier Mapping
A mobile node identifies itself to the NETLMM domain based on an
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
address is insufficient to protect the mobile node against
impersonation by a third party. Specifically, the following attacks
are conceivable.
4.1 Roaming at a Victim's Costs
Given that regular IP packets do not carry a signature of the mobile
node or a comparable proof of origin, an attacker may trick the
NETLMM domain into accepting packets, sent by the attacker from the
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
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
authentication is used for packets that the mobile node sends. The
packets can be authenticated either on the link layer or on the IP
layer, provided that the IP address, based on which the NETLMM domain
identifies the packets as coming from the mobile node, is covered by
the protection and securely bound to the authentication context.
A possible mechanism for link-layer authentication is a combination
Kempf & Vogt Expires August 18, 2006 [Page 6]
Internet-Draft Security Threats to NetLMM February 2006
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
mobile node's IP address and the keys it uses for per-packet
authentication: Failure to provide such a binding allows an
attacker, who is itself a customer of the NETLMM domain, to
authenticate to the NETLMM domain, obtain the keys for per-packet
authentication, and then spoof its IP source address to be the
address of some third node. The attacker can thus roam and
communicate at its victim's costs.
4.2 Off-Path Eavesdropping
If an attacker can forge a victim's mobile-node identifier or
generate packets that appear to originate from the victim, the
attacker can siphon off packets meant for the victim and redirect
them to its own location. The perpetrator can inspect these packets,
effectively waging an "off-path" eavesdropping attack. However, it
is impossible for the attacker to forward the packets on to the
victim given that the attacker and the victim use the same IP
address. The compromised communication session is therefore highly
likely to abort before the attack causes significant damage.
The described redirection attack resembles a related man-in-the-
middle attack identified in [8]. In that attack, the impersonator
manages to redirect packets exchanged between a victim and the
victim's peer via itself. Packets thus eventually reach their
intended destination, although the attacker can eavesdrop on them or
modify them on the fly. The triangular routing becomes possible
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
A similar attack strategy to the one described in Section 4.2 causes
denial of service to a victim. Again, the attacker forges the
victim's mobile-node identifier or generates packets that appear to
originate from the victim, and it thereby redirects the packets meant
for the victim to its own location. Any request that the victim
sends to nodes located elsewhere than its local link will
Kempf & Vogt Expires August 18, 2006 [Page 7]
Internet-Draft Security Threats to NetLMM February 2006
consequently solicit responses that the NETLMM domain will route to
the attacker's location. As a result, the victim is unable to
communicate.
This attack is limited in that the attacker can only redirect the
victim's packets to its own location because it must obtain the
victim's IP address. This is a natural limitation of the NETLMM
architecture because packets are only forwarded to links where the
destination node is known (or believed) to be present.
5. Threats to Access Router Functions
An attacker that is able to set up a bogus access router can trick
mobile nodes into sending their packets to the attacker. The
attacker can thus act as an active or passive man in the middle,
possibly forwarding the victim's packets to their actual destination
via a path outside the NETLMM domain.
Return packets sent by the victim's peer are likely to be delivered
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
act as a NAT box at the same time. It tricks a victim into accepting
it as its default router and forwards the victim's packets, after
manipulation, with an IP source address through which it is itself
reachable. Unless the victim's peer expects a particular IP address,
it will send any responses "back" to the attacker. The attacker can
read and/or manipulate these packets and finally deliver them to the
victim.
Essentially, a NETLMM domain is subject to attacks against access
routers in the same way as any conventional IPv6 domain. These
threats are due to vulnerabilities of the IPv6 Neighbor Discovery
protocol, and are as such identified in [6]. In particular,
impersonating an access router requires the attacker to send spoofed
Router Advertisement messages, which can be precluded, or at least
mitigated to a reasonable extent, by SeND [7].
6. Threats to Location Privacy
The location privacy of mobile nodes may be compromised if their
identities can somehow be associated to their IP or MAC addresses.
This may happen if mobile-node identifiers can be read from the
Kempf & Vogt Expires August 18, 2006 [Page 8]
Internet-Draft Security Threats to NetLMM February 2006
protocol executed on the interface between mobile nodes and access
routers, if the NETLMM protocol run between access routers and the
MAP leaks the mobile-node identifiers, or if an attacker manages to
steal confidential information from a NETLMM database. Certainly, an
attacker may also be able to infer a mobile node's identity from
other sources, e.g., from information extracted from application-
layer payloads sent or received by the mobile node. But those
attacks are not specific to NETLMM and hence outside the scope of
this document.
Threats to location privacy that are specific to NETLMM can
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
An attacker within the localized mobility management domain can
obtain location information through the usual IPv6 Neighbor Discovery
mechanisms. E.g., the attacker can obtain the IP address of a victim
within the localized mobility management domain and multicasts a
Neighbor Solicitation message to resolve this IP address to the
victim's link-layer address. If the attacker receives a Neighbor
Advertisement message in response, it knows that the victim is
present somewhere in the NETLMM domain.
The obtained location information may be more precise depending on
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
determine whether another node is within the localized mobility
management domain or on the local link. The attacker multicasts a
Neighbor Solicitation message to the solicited-node multicast address
for the victim's address. If a Neighbor Advertisement message
returns, the attacker knows that the victim is somewhere in the
localized mobility management domain or on the local link, depending
on whether or not NETLMM routers forward Duplicate Address Detection
signaling.
IPv6 Neighbor Discovery messages are normally of link-local scope and
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
Kempf & Vogt Expires August 18, 2006 [Page 9]
Internet-Draft Security Threats to NetLMM February 2006
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
position where the links incoming to and outgoing from the MAP can be
monitored. An attacker in this position can listen to the NETLMM
protocol traffic between the MAP and the different access routers and
thus derive the link where its victim is currently attached to. The
attacker may even be able to reasonably track its victim if it has
access to only a subset of the links to and from the MAP.
6.2 Threats from Nodes At Any Location
Furthermore, a mobile node's presence within the NETLMM domain is
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
information to some extent in that the IP source address does not
contain information about the link within the NETLMM domain where the
mobile node currently is. Tracing tools such as "traceroute" may
allow the correspondent node (or any other node with the mobile
node's IP address) to obtain the IP addresses of some routers on the
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
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
NETLMM domain gateways.
7. Security Considerations
This document deals with the security of the NETLMM architecture.
Kempf & Vogt Expires August 18, 2006 [Page 10]
Internet-Draft Security Threats to NetLMM February 2006
8. Acknowledgment
The authors would like to thank Phil Roberts for his comments and
suggestions regarding the initial version of this document.
Kempf & Vogt Expires August 18, 2006 [Page 11]
Internet-Draft Security Threats to NetLMM February 2006
9. Informative References
[1] "NETLMM Protocol Specification (TBD)", IETF Working Group Item
(work in progress).
[2] "NETLMM Mobile-Node Access-Router Protocol Specification (TBD)",
IETF Working Group Item (work in progress).
[3] Kempf, J., "Problem Statement for IP Local Mobility",
IETF Internet Draft draft-kempf-netlmm-nohost-ps-00.txt (work in
progress), June 2005.
[4] Kempf, J., "Requirements and Gap Analysis for IP Local
Mobility", IETF Internet Draft
draft-kempf-netlmm-nohost-req-00.txt (work in progress),
July 2005.
[5] Manner, J. and M. Kojo, "Mobility Related Terminology",
IETF Request for Comments 3753, June 2004.
[6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", IETF Request for
Comments 3756, May 2004.
[7] Aura, T., "Cryptographically Generated Addresses (CGA)",
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
Design Background", IETF Request for Comments 4225,
December 2005.
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
Kempf & Vogt Expires August 18, 2006 [Page 12]
Internet-Draft Security Threats to NetLMM February 2006
Christian Vogt
Institute of Telematics
Universitaet Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
Email: chvogt@tm.uka.de
Kempf & Vogt Expires August 18, 2006 [Page 13]
Internet-Draft Security Threats to NetLMM February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
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
Internet Society.
Kempf & Vogt Expires August 18, 2006 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 04:41:01 |