Network Working Group                                           J. Kempf
Internet-Draft                                           DoCoMo USA Labs
Expires: October 19, 2006                                            C. Vogt
Internet-Draft                               Universitaet Karlsruhe (TH)
                                                          April 17,
Expires: December 25, 2006                                      J. Kempf
                                                         DoCoMo USA Labs
                                                           June 23, 2006

    Security Threats to Network-based Localized Mobility Management

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on October 19, December 25, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   This document discusses security threats to NETLMM-based NETLMM mobility
   management with a focus on threats
   management.  Threats to NETLMM occur on two interfaces: the access
   router/localized mobility anchor interface between mobile
   nodes and the access routers. router/
   mobile node interface.  Threats to the NETLMM protocol itself,
   which runs between the access routers and router/localized
   mobility anchor points, interface are
   similar to those faced by other protocols between network entities
   like routers.  These threats are handled in to the NETLMM protocol
   specification.  In contrast, itself.
   This document discusses 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. these two interfaces.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3  4
   2.  NETLMM Architecture  Threats to the AR/LMA Interface  . . . . . . . . . . . . . . .  4
     2.1   Unauthorized AR  . . . . . .  3
   3.  Outline of Threats . . . . . . . . . . . . . . .  4
     2.2   Unauthorized LMA . . . . . . .  5
   4.  Threats to IPv6 Address to Mobile Node Identifier Mapping . .  6
     4.1   Roaming at a Victim's Costs . . . . . . . . . . . .  5
     2.3   Man in the Middle Attack . . .  6
     4.2   Off-Path Eavesdropping . . . . . . . . . . . . . .  5
     2.4   Denial of Service Attack on the LMA  . . . .  7
     4.3   Denial of Service . . . . . . .  5
   3.  Threats to the MN-AR Interface . . . . . . . . . . . . .  7
   5.  Threats to Access Router Functions . . .  6
     3.1   Mobile Node Identity . . . . . . . . . . .  8
   6.  Threats to Location Privacy . . . . . . . .  6
     3.2   Impersonation on Handover  . . . . . . . . .  8
     6.1   Threats from Nodes within the NETLMM Domain . . . . . . .  9
     6.2   Threats from Nodes At Any Location  7
     3.3   Off-Link Attacks . . . . . . . . . . . . 10
   7. . . . . . . . . .  7
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  8
   5.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  8
   6.  Informative References . . . . . . . . . . . . . . . . . . . . 12  9
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 10
       Intellectual Property and Copyright Statements . . . . . . . . 14 11

1.  Introduction

   The NETLMM architecture supports movement of IPv6 mobile nodes within
   a localized mobility management domain with minimal involvement no specialized support on
   the part of the mobile node itself. for localized mobility management.  In contrast to
   architectures where there is no localized mobility management support
   or where localized mobility management support is provided by a host-based 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 and, of course course,
   driver software for link layer link-layer movement is always required.  More on
   the network-based localized mobility management problem architecture can be
   found in [3]. [1].

   In this document, threats to the protocols involved in implementing the NETLMM architecture are discussed.  The document focuses on
   threats on the architecture, a localized mobility anchor (LMA)
   maintains routes for mobile node to access router interface.  Threats nodes.  Packets to
   the NETLMM protocol itself, which runs and from mobile nodes
   (MNs) on the access router to
   mobility anchor point interface last hop wireless links are briefly described, but detailed
   requirements and solutions for security routed through the LMA.
   When a MN moves from one access router (AR) to another, the route for
   the NETLMM protocol are
   handled in mobile node on the LMA is updated by the requirements ARs.  The NETLMM
   architecture therefore has two interfaces:

   1.  The AR to LMA interface where route update signaling occurs.

   2.  The MN to AR interface where movement detection and IP handover
       signaling occurs.

   The NETLMM architecture specifies no standardized protocol specification
   documents [1][4].  While a default IP-based protocol for on the
   interface between
   MN/AR interface.  The network must be informed when a mobile nodes and node
   having an IP address moves from one access routers has been specified
   [2], router to another, but how
   that interface occurs is the focus not part of this document because the
   protocol running across it NETLMM protocol.  The mechanism can potentially be completely
   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 without any does not handle movement detection and IP involvement.  This document handover, however,
   support at the IP level is intended to provide guidance required.  In that case, the mobile node
   must perform IP signaling for active movement detection.  The access
   router uses this signaling to developers linking 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 to such wireless link protocols so that they know what itself is defined on the
   potential security AR/LMA interface, and is
   specified in [3].

   This document discusses threats are.

1.1  Terminology

   Mobility terminology to security on the NETLMM interfaces.

   The discussion in this document follows that in [5], with those
   revisions and additions from [3] and [4].

2. focuses only on NETLMM Architecture

   Figure 1 depicts signaling
   traffic, both for the NETLMM architecture.  A mobility anchor point
   (MAP) manages routing protocol itself and for packets to signaling on the
   MN/AR interface that signals mobile nodes as they move
   through node movement to the network.
   Details on how the threats are handled by the NETLMM domain.  The MAP communicates with a collection of
   access routers (AR_1 through AR_n protocol and the
   IP MN/AR interface are discussed in Figure 1).  Each access router
   is connected to a collection of wireless access points (AP_1 through
   AP_m [3] and [2] respectively.

1.1  Terminology

   Mobility terminology in Figure 1) this document follows 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 in [4], with those
   revisions and additions from [1] and [5].  In addition, the following
   definition is used:

   Network access router.
   In order identity

      A identity established for the mobile node to keep its address constant across the
   NETLMM domain, with the network during
      network access routers must all advertise authentication that allows the same IPv6
   subnet prefixes network to
      unambiguously identify the mobile nodes on their link, and node for signaling purposes.
      For example, a wireless link session key established by the internal
   gateway protocol (IGP) used to distribute routes to routers
      wireless link layer, the IGP routing domain must target Network Access Identifier (NAI) [6], or
      the MAP SEND public key [7] may serve 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 identifier associated
      with the network access
   routers, changing identity.

2.  Threats 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 \
                --------   --------  --------

                  +--+      +--+      +--+
                  +--+      +--+      +--+

         Figure 1: Protocol Interfaces in the NETLMM Architecture

3.  Outline of Threats

   The AR/LMA Interface

   In this section, threats for the NETLMM architecture break down into two parts:

   o  Threats on to the AR/LMA interface between mobile nodes and access routers.
   o  Threats on are discussed.
   Since the interface information propagated between the access routers AR and a MAP.

   Threats on LMA is routing
   updates, the threats on this interface between mobile nodes and access routers are,
   in many respects, are similar to the threats [6] against
   experienced by two routers exchanging routing information with a
   routing protocol.  One difference is that the IPv6 Neighbor
   Discovery protocol, except that rather than being confined to AR and LMA need not be
   separated by a single IP link, the threat potential hop, whereas routing updates are usually
   propagated by flooding, so two routers exchanging routing information
   are usually separated by a single hop.

2.1  Unauthorized AR

   An AR that is distributed across not authorized to propagate NETLMM routing updates can
   result in serious damage to the last
   hops security of the NETLMM a localized mobility
   management domain.  The interface between mobile nodes and
   access routers may run AR can redirect traffic from MNs on the default IP protocol [2], or it may run a
   wireless AR's
   lst hop link technology-specific protocol.  Threats on this
   interface are discussed in detail in arbitrarily, without authorization from the following sections. MN.  The threats on AR
   can ignore routing updates from the interface between access routers LMA so that the victim MNs lose
   their traffic.  An unauthorized AR can also intercept, inspect, and a MAP are
   redirect data plane traffic for mobile nodes on its last hop
   interface, but this threat is common for any last hop router.

   Note that this threat applies not just to an AR that is compromised,
   but also to an off-path attacker that manages to forge the identity
   of an authorized AR, and thereby spoof the same nature LMA into conducting NETLMM
   protocol signaling as if the threats that attacker were legitimate.  Such an IGP
   attack could be conducted transiently, to selectively disable traffic
   for routing faces.
   Specifically, a rogue MAP or a rouge access router particular mobile nodes at particular times.

2.2  Unauthorized LMA

   An unauthorized LMA can end up
   injecting incorrect tunnels ignore routing updates from legitimate ARs,
   or host routes forge routing updates for mobile nodes.  This
   may result MNs in order to redirect or deny traffic being siphoned off, facilitating impersonation
   of the
   to victims.  Since data plane traffic for mobile node or nodes routes through
   the mobile node's peer, or in LMA, a rogue LMA can also intercept, inspect, and redirect data
   plane traffic being
   dropped, for mobile nodes on ARs supported by the LMA.  A piece
   of malware might further manipulate the LMA's routing table such that
   all packets are directed towards a single AR, resulting in a DoS
   attack on the mobile node.

   Rouge access routers against that AR and MAPs can be handled with the same security
   measures used by IGPs for standard IP routing.  Since its attached link.  Again, these threats are specific to the NETLMM protocol, which runs across
   same threats experienced by any intermediate router in the interface
   between network.

   Note that these threats apply not just to a LMA that is compromised,
   but also to an off-path attacker that manages to forge the access routers identity
   of an authorized LMA, and thereby spoof the ARs in a MAP, they are discussed localized
   mobility domain into conducting NETLMM protocol signaling as if the
   attacker were legitimate.  Such an attack could be conducted
   transiently, to selectively disable traffic for particular mobile
   nodes or ARs at particular times.

2.3  Man in the Middle Attack

   An unauthorized intermediate router or other node that manages to
   interject itself between the AR and LMA is in a position to
   intercept, inspect, and redirect NETLMM protocol specification [1].  The document also identifies
   specific security measures signaling traffic
   between an authorized LMA and authorized ARs handling mobility
   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.

   Another threat protocol signaling for various

2.4  Denial of Service Attack on the interface between access routers LMA

   An attacker could launch a denial-of-service attack on the LMA by
   sending packets to arbitrary IP addresses with a prefix from the
   NETLMM domain.  The LMA is in a topological position through which
   all data-plane traffic goes, so it would have to process the flooding
   packets and perform a routing table lookup for each of them.  The LMA
   could discard packets for which the MAP destination IP address is
   DoS against network entities.  Here, an not
   registered in the routing table.  But other packets would have to be
   encapsulated and forwarded.  There would also be some damage to the
   target AR and its link.

   In a related attack, the attacker manages to obtain a globally
   routable IP address of an access router, a MAP, LMA or some
   other a different network entity, entity within
   the NETLMM domain, 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 unauthorized 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 ARs and MAPs
   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.
   Network operators need

3.  Threats 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

   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 MN-AR Interface

   In order to its detect 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 level handovers of generality, it is assumed
   in the following that the mobile node's IP address is used for this

   Per se, a mapping nodes, NETLMM access
   routers utilize handover signaling between the mobile-node identifier and the IP
   address is insufficient to protect the mobile node against
   impersonation by a third party.  Specifically, and the following attacks
   are conceivable.

4.1  Roaming
   access router.  For cellular-type interfaces, such signaling occurs
   at a Victim's Costs

   Given that regular the wireless link layer, and the IP packets do not carry a signature of stack never sees any change
   when the mobile node or a comparable proof of origin, moves from one AR to an attacker AR on a different link.
   For non-cellular interfaces, such as 802.11 or wired Ethernet-type
   interfaces, link layer signaling may trick the
   NETLMM domain into accepting packets, sent by the attacker not hide IP handover from the
   mobile node's IP address, and charging any forwarding services or
   other due services
   stack.  The IP stack may need to the mobile node's account. perform movement detection in
   response to some kind of link layer hint that a change in access
   point has occurred.  This allows signaling may involve extensions of IPv6
   Neighbor Discovery [8] or it may involve DHCP [9] or it may involve
   some link-specific IP level mechanism.  In any case, the
   attacker security
   threats to roam across the entire handover signaling that triggers NETLMM domain and communicate at routing
   updates are the mobile node's costs.

   The attacker not necessarily needs same, and are described in this section.

3.1  Mobile Node Identity

   In order for NETLMM to be able to definitively identify a customer of mobile node
   upon handover, the NETLMM
   domain since mobile node must establish a network access
   identity when it does not have to initially enters the network.  For example, a mobile
   node may initially 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
   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
   consequently solicit responses that the NETLMM domain will route to
   the attacker's location.  As a result, the victim is unable to

   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

   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, based on
   its NAI 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 AAA-based protocol.  This identifier is conceptually
   independent of the mobile nodes may be compromised if their
   identities can somehow be associated to their node's IP or MAC link-layer addresses.
   This may happen if mobile-node identifiers can be read from the
   protocol executed on the interface between mobile nodes and access
   routers, if  In some
   wireless networks, the NETLMM protocol run between network 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 must be more precise depending re-established
   how far beyond the local link IPv6 Neighbor Discovery messages are
   forwarded by the every handover between access points.

   NETLMM routing fabric.  In case such messages are
   kept link-local, requires that the attacker can even conclude from access network establish a received
   Neighbor Advertisement message that binding between
   the victim is on network access identity and the same link.

   Likewise, IP addresses that the attacker can use Duplicate Address Detection to
   determine whether another mobile node
   self-configures (if address auto-configuration is within the localized mobility
   management domain used) or on that it is
   assigned (if stateful address configuration is used).  This binding
   is used by the local link.  The attacker multicasts AR to definitively and unambiguously deduce that a
   Neighbor Solicitation message
   mobile node has handed over into the AR's last hop subnet, thereby
   providing the trigger for NETLMM route update signaling to the solicited-node multicast address LMA.
   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 victim's address.  If mobile node by a Neighbor Advertisement message
   returns, third party.
   Lacking this binding, the following attacks are conceivable.

3.2  Impersonation on Handover

   An attacker knows that is able to forge an MN's network access identity can
   use this capability to fabricate handover signaling, thereby tricking
   the AR into believing that the victim is somewhere in has handed over into the
   localized mobility management domain or on AR's
   last hop subnet.  The AR will then perform route update signaling
   with the local link, depending
   on whether or not NETLMM routers forward Duplicate Address Detection

   IPv6 Neighbor Discovery messages are normally of link-local scope and
   as such not forwarded by routers.  This is based on LMA, causing the prerequisite
   that prefix sets of different links are disjunct.  However, links
   within a NETLMM domain all use LMA to redirect traffic to the same set of prefixes.  While attacker.
   The attacker can utilize this
   does not necessarily imply that address-resolution messages need capability to
   be distributed across an entire NETLMM domain (link-local redirects
   may also be feasible), it does imply examine and discard
   traffic that messages exchanged for legitimately belongs to the
   purpose of Duplicate Address Detection would have to.

   More precise location information can only be acquired from MN, as a
   position where means of denying
   the links incoming MN service or to and outgoing from snoop the MN's traffic.  If the MAP can be
   monitored.  An attacker in this position can listen to the NETLMM
   protocol traffic
   interpose between the MAP MN and the different access routers network during router discovery and
   thus derive
   address configuration, the attacker can mount a man in the middle
   attack on the MN, spoofing the link where its victim is currently attached to.  The
   attacker may even be able to reasonably track its victim if MN into believing it has
   access to only a subset of legitimate
   connection with the links to and from network.

3.3  Off-Link Attacks

   Depending on the MAP.

6.2  Threats exact nature of the handover signaling, an
   impersonation attack could be mounted from Nodes At Any Location

   Furthermore, a mobile node's presence within off link.  Off-link
   attacks are possible in cases where the NETLMM domain is
   also implied by the prefix consists of its IP source address.  Correspondent
   nodes can identify the NETLMM domain and coarsely localize
   multiple access routers serving multiple last hop links.  If the mobile
   node based
   security 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 network access identity establishment is weak, or the IP source address does not
   contain information about
   level movement detection signaling is unprotected so that the network
   cannot definitively link within the NETLMM domain where signaling back to the legitimate mobile
   node currently is.  Tracing tools such as "traceroute" may
   allow the correspondent node (or any other network access identity, then an attacker from another link
   could spoof IP level movement detection signaling for a victim mobile
   node with and thereby steal the mobile node's IP address) to obtain the IP addresses of some routers on the
   path to traffic.

   Off-link attacks can be prevented at the mobile node.  But since packets link-layer.  E.g., they are tunneled on
   not possible with cellular-style protocols, where the sub-
   path between handover
   signaling is completely controlled by the MAP and wireless link layer,
   because an attacker must be on the mobile node's current access router, same link with the
   acquired information may not be sufficient MN in order to actually locate
   disrupt the
   mobile node.

   The location tracker does not necessarily negotiation with the network.  Cellular-style protocols
   also have other cryptographic and noncryptographic barriers to be a correspondent
   node of its victim.  The attacker may also be another node, attack
   at the link layer, which make mounting an impersonation attack, both
   on-link and within the NETLMM domain, provided that off-link, very difficult.  For non-cellular-style
   protocols, however, it has somehow
   obtained the victim's IP address.

   This threat can may be eliminated by filtering tracing attempts at the
   NETLMM domain gateways.

7. possible for an off-link attacker to
   mount an impersonation attack.

4.  Security Considerations


   The document deals with describes threats to the NETLMM protocol [3] and to the
   MN-AR interface functions necessary to support network-based mobility
   management [2].  Mitigation measures for these threats, and the
   security of considerations associated with those measures, are described
   in the respective drafts that discuss the NETLMM architecture.

8. protocol and the
   MN-AR interface.

5.  Acknowledgment

   The authors would like to thank Gregory Daley, Gerardo Giaretta,
   Julien Laganier, Phil Roberts Roberts, and Vidya Narayanan for his their comments
   and suggestions regarding the initial version of this document.


6.  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 draft-ietf-netlmm-nohost-ps-01.txt (work in
         progress), June 2005.

   [4]  Kempf, J., "Requirements April 2006.

   [2]   Laganier, J. and Gap Analysis for IP Local
        Mobility", S. Narayanan, "Network-based Localized
         Mobility Management Interface between Mobile Node  and Access
         Router", IETF Internet Draft
        draft-kempf-netlmm-nohost-req-00.txt draft-ietf-netlmm-mn-ar-if-00.txt
         (work in progress),
        July 2005.

   [5] April 2006.

   [3]   "NETLMM Protocol Specification (TBD)", IETF Working Group Item
         (work in progress).

   [4]   Manner, J. and M. Kojo, "Mobility Related Terminology",
         IETF Request for Comments 3753, June 2004.

   [5]   Kempf, J., "Goals for Network-based Localized Mobility
         Management (NETLMM)", IETF Internet Draft
         draft-ietf-netlmm-nohost-req-01.txt (work in progress),
         April 2006.

   [6]   Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
         Access Identifier", IETF Request for Comments 4282,
         December 2005.

   [7]   Aura, T., "Cryptographically Generated Addresses (CGA)",
         IETF Request for Comments 3972, March 2005.

   [8]   Kempf, J., Narayanan, S., Nordmark, E., Pentland, B., and JH.
         Choi, "Detecting Network Attachment in IPv6 Networks (DNAv6)",
         IETF Internet Draft draft-ietf-dna-protocol-00.txt (work in
         progress), February 2006.

   [9]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
         Carney, "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", IETF Internet Draft draft-ietf-dna-protocol-00.txt
         (work in progress), February 2006.

   [10]  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.


   [11]  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

   Christian Vogt
   Institute of Telematics
   Universitaet Karlsruhe (TH)
   P.O. Box 6980
   76128 Karlsruhe


   James Kempf
   DoCoMo USA Labs
   181 Metro Drive, Suite 300
   San Jose, CA 95110

   Phone: +1 408 451 4711
   Christian Vogt
   Institute of Telematics
   Universitaet Karlsruhe (TH)
   P.O. Box 6980
   76128 Karlsruhe


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

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.