Network Working Group                                            C. Vogt
Internet-Draft                               Universitaet Karlsruhe (TH)
Expires: December 25, 2006 January 24, 2007                                       J. Kempf
                                                         DoCoMo USA Labs
                                                           June
                                                           July 23, 2006

    Security Threats to Network-based Network-Based Localized Mobility Management
                    draft-ietf-netlmm-threats-01.txt
                    draft-ietf-netlmm-threats-02.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 December 25, 2006. January 24, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document discusses security threats to NETLMM network-based localized
   mobility management.  Threats to NETLMM may occur on two interfaces:  the access
   router/localized mobility anchor
   interface between an LMA and a MAG, as well as the access router/ interface between
   a MAG and a mobile node interface. node.  Threats to the access router/localized
   mobility anchor former interface are threats to impact the NETLMM
   localized mobility management protocol itself.
   This document discusses threats on these two interfaces.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4  3
   2.  Threats to the AR/LMA Interface  . . . . between LMA and MAG . . . . . . . . . . .  4
     2.1   Unauthorized AR  . . . . . . . .   LMA Compromise or Impersonation  . . . . . . . . . . . . .  4
     2.2   Unauthorized LMA . . . . . . . .   MAG Compromise or Impersonation  . . . . . . . . . . . . .  5
     2.3   Man in the Middle Attack . . . . . . . . . . . . . . . . .  5  6
     2.4   Denial of Service Attack on the LMA  . . . . . . . . . . .  5  7
   3.  Threats to the MN-AR Interface between MAG and Mobile Node . . . . . . .  7
     3.1   Network Access Identity  . . . . . . . . .  6
     3.1   Mobile Node Identity . . . . . . . .  8
     3.2   Impersonation of Mobile Nodes  . . . . . . . . . . . . .  6
     3.2   Impersonation on Handover .  8
     3.3   Man in the Middle Attack . . . . . . . . . . . . . . .  7
     3.3   Off-Link Attacks . .  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   4.  Security 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . .  8
   5. . . 10
   6.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . .  8
   6. 10
   7.  Informative References . . . . . . . . . . . . . . . . . . . .  9 11
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 12
   A.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       Intellectual Property and Copyright Statements . . . . . . . . 11 14

1.  Introduction

   The NETLMM network-based localized mobility management (NETLMM) architecture
   [1] supports movement of IPv6 mobile nodes locally within a localized mobility management domain with no specialized support on
   the mobile node for localized mobility management.  In contrast to
   architectures where there is no localized mobility management support
   or where localized
   without requiring mobility management support is provided by a host-
   based solution, in the NETLMM architecture, the mobile nodes' network
   stacks.  A mobile node is able
   to can keep its IP address constant within the localized mobility
   management domain as it moves, moves
   from link to link, avoiding the signaling overhead
   required to change and latency
   associated with changing the IP address.  Software  While software specifically
   for localized mobility management is not required on the mobile node, though
   software for IP
   IP-layer movement detection software may be needed and, of course, necessary, and driver
   software for link-layer movement is always required.  More on
   the network-based localized mobility management architecture can be
   found in [1].

   In the NETLMM architecture, is prerequisite.

   The IP addresses of mobile nodes have a prefix that routes to a
   localized mobility anchor (LMA) (LMA).  This LMA maintains routes an individual
   route for each mobile nodes.  Packets to and from node.  Any particular mobile nodes
   (MNs) on the last hop wireless links are routed through the LMA.
   When node's route
   terminates at a MN moves from one mobile access router (AR) to another, gateway (MAG) which the route mobile node
   uses as a default router on its current access link.  MAGs are
   responsible for updating the mobile node node's route on the LMA is updated by as the ARs.
   mobile node moves.  The NETLMM localized mobility management architecture
   therefore has two interfaces:

   1.  The AR to LMA interface between MAGs and the LMA where route update
       signaling occurs.

   2.  The MN to AR interface between mobile nodes and their currently selected
       MAGs where link-layer handoff signaling and possibly IP-layer
       movement detection and IP handover signaling occurs.

   The NETLMM localized mobility management architecture specifies no
   standardized protocol on the
   MN/AR interface.  The network must be informed when for a mobile node
   having an IP address moves from one access router MAG to another, but how
   that occurs is not part detect the arrival or departure of
   mobile nodes on its local link and initiate route update signaling
   with the NETLMM protocol.  The LMA.  An appropriate mechanism can may be entirely implemented by
   at the wireless link protocol, layer, such as is common for cellular networks.  In that
   case, the IP layer never detects any movement, even though the when a mobile
   node may be moving moves from one link to another handled by a different access router. MAG.  If
   the wireless link
   protocol layer does not handle movement detection and IP handover, however,
   support at provide the IP level is required.  In that case, necessary functionality, the
   mobile node must perform IP signaling for active IP-layer movement detection.  The access
   router uses this detection signaling
   so as to infer mobile node movement.  More about
   IP level movement detection and NETLMM can be found in the NETLMM
   MN-AR interface document [2].

   The NETLMM protocol itself is defined on trigger route update signaling at the AR/LMA interface, and is
   specified in [3]. MAG.

   This document discusses threats to security threats on the NETLMM interfaces. both interfaces of
   localized mobility management.  The discussion is limited to threats
   specific to localized mobility management; threats to IPv6 in general
   are documented in [2].

1.1  Terminology

   The terminology in this document focuses only on NETLMM signaling
   traffic, both for follows the NETLMM protocol itself definitions in [3], with
   those revisions and for signaling on the
   MN/AR interface that signals mobile node movement to the network.
   Details on how the threats are handled by the NETLMM protocol and the
   IP MN/AR interface are discussed in [3] and [2] respectively.

1.1  Terminology

   Mobility terminology in this document follows that in [4], with those
   revisions and additions from [1] and [5].  In addition, additions from [1].  In addition, the following
   definition is used:

   Network access identity

      A

      An identity established for the mobile node with the network during network access
      authentication that allows the network to unambiguously identify
      the mobile node for signaling purposes.
      For example,  The network access
      identity may, e.g., be bound to a wireless link link-layer session key established by the
      wireless link layer, the Network Access Identifier key, a
      network access identifier (NAI) [6], [4], or
      the a SEND public key [7] may serve as the identifier associated
      with the network access identity. [5].

2.  Threats to the AR/LMA Interface

   In this section, threats to the AR/LMA interface are discussed.
   Since the information propagated between the AR and LMA is routing
   updates, the threats and MAG

   The localized mobility management protocol executed on this the interface are similar to
   between the threats
   experienced by two routers exchanging routing information with LMA and a
   routing protocol.  One difference is that the AR MAG serves to establish, update, and LMA need not tear down
   routes for data plane traffic of mobile nodes.  Threats to this
   interface can be separated by into compromise or impersonation of a single hop, whereas
   legitimate LMA, compromise or impersonation of a legitimate MAG, man-
   in-the-middle attacks, and denial-of-service attacks on the LMA.

2.1  LMA Compromise or Impersonation

   A compromised LMA can ignore routing updates are usually
   propagated by flooding, so two routers exchanging routing information
   are usually separated by from a single hop.

2.1  Unauthorized AR

   An AR that is not authorized to propagate NETLMM legitimate MAG,
   or forge routing updates can
   result for a victim mobile node in serious damage order to
   redirect or deny the security of mobile node's traffic.  Since data plane traffic
   for all mobile nodes routes through the LMA, a localized mobility
   management domain.  The AR compromised LMA can redirect
   also intercept, inspect, modify, redirect, or drop such traffic from MNs on a
   MAG supported by the AR's
   lst hop link arbitrarily, without authorization from the MN. LMA.  The AR
   can ignore routing updates from the LMA so that the victim MNs lose
   their traffic.  An unauthorized AR attack can also intercept, inspect, and
   redirect data plane be conducted transiently,
   to selectively disable traffic for any particular mobile nodes on node or MAG
   at particular times.

   Moreover, a compromised LMA may manipulate its last hop
   interface, but this threat is common for any last hop router.

   Note routing table such
   that this threat applies not just to an AR all packets are directed towards a single MAG.  This may result
   in a DoS attack against that is compromised,
   but MAG and its attached link.

   These threats also to emanate from an off-path attacker which tricks a MAG into
   believing that manages to forge it is the identity
   of an authorized AR, and thereby spoof legitimate LMA.  This attacker can cause the LMA into conducting NETLMM
   protocol
   MAG to conduct route update signaling as if with the attacker were legitimate.  Such an
   attack could be conducted transiently, instead of
   with the legitimate LMA, enabling it to selectively disable traffic
   for particular mobile nodes at particular times.

2.2  Unauthorized LMA

   An unauthorized LMA can ignore routing route updates from legitimate ARs, the
   MAG, or forge routing route updates for MNs in order to redirect or deny traffic a victim
   mobile node's traffic.  The attacker does not necessarily have to victims.  Since data be
   on the original control plane traffic for mobile nodes routes through path between the LMA, a rogue legitimate LMA and the
   MAG, provided that it can also somehow make its presence known to the MAG.
   E.g., the IP address of a mobility anchor point in hierarchical
   Mobile IPv6 mobility management [6] may be proliferated across a
   domain hop by hop in Router Advertisement messages.  Failure to
   properly authenticate a comparable mechanism for localized mobility
   management would allow an attacker to establish itself as a rouge
   LMA.

   The attacker may further be able to intercept, inspect, and redirect modify,
   redirect, or drop data plane traffic for to and from a mobile nodes on ARs supported by node.  This
   is obvious if the attacker is on the original data plane path between
   the legitimate LMA and the mobile node's current MAG, which may
   happen independent of whether or not the attacker is on the original
   control plane path.  If the attacker is not on this path, it may be
   able to leverage the localized mobility management protocol to
   redefine the prefix that the mobile node uses in IP address
   configuration.  The attacker can then specify a prefix that routes to
   itself.  Whether or not outgoing data plane packets sourced by the
   mobile node can be interfered with by an attacker off the original
   data plane path depends on the specific data plane forwarding
   mechanism within the localized mobility management domain.  E.g., if
   IP-in-IP encapsulation or an equivalent per-mobile-node approach is
   used for outbound data plane packets, the packets will route through
   the attacker.  On the other hand, standard IP routing may cause the
   packets to be relayed via the legitimate LMA and hence to circumvent
   the attacker.

2.2  MAG Compromise or Impersonation

   A compromised MAG can redirect a victim mobile node's traffic onto
   its local access link arbitrarily, without authorization from the
   mobile node.  This threat is similar to an attack on a typical
   routing protocol where a malicious stub router injects a bogus host
   route for the mobile node.  In general, forgery of a subnet prefix in
   link state or distance vector routing protocols requires support of
   multiple routers in order to obtain a meaningful change in forwarding
   behavior.  But a bogus host route is likely to take precedence over
   the routing information advertised by legitimate routers, which is
   usually less specific, hence the attack should succeed even if the
   attacker is not supported by other routers.  A difference between
   redirection in a routing protocol and redirection in localized
   mobility management is that the former impacts the routing tables of
   multiple routers, whereas the latter involves only the compromised
   MAG and the LMA.

   A compromised MAG can further ignore the presence of a mobile node on
   its local access link and refrain from registering the mobile node at
   the LMA.  The mobile node then loses its traffic.  Attacks that the
   MAG can mount on its access link interface are common for any regular
   IPv6 access router [2].

   Moreover, a compromised MAG may be able to cause interruption to a
   mobile node by deregistering the mobile node at the LMA, pretending
   that the mobile node has powered down.  The mobile node then needs to
   reinitiate the network access authentication procedure, which the LMA.  A piece
   of malware might further manipulate
   compromised MAG may prevent repeatedly until the LMA's routing table such that
   all packets are directed towards a single AR, resulting in mobile node moves to
   a DoS
   attack against that AR and its attached link.  Again, these are the
   same threats experienced by any intermediate router in different MAG.  The mobile node should be able to handle this
   situation, but the network.

   Note that recovery process may be lengthy and hence impair
   ongoing communication sessions to a significant extent.

   All of these threats apply not just to a LMA MAG that is compromised, but
   also to an off-path attacker that manages to forge counterfeit the identity of an
   authorized LMA, and thereby spoof the ARs MAG in a localized
   mobility domain into conducting NETLMM protocol signaling as if interacting with both mobile nodes and the
   attacker were legitimate. LMA.
   Such an attacker can behave towards mobile nodes like a legitimate
   MAG and engage the LMA in route update signaling.  The attack could may be
   conducted transiently, to selectively disable traffic for any
   particular mobile
   nodes or ARs node at particular times.

2.3  Man in the Middle Attack

   An unauthorized intermediate router or other node attacker that manages to interject itself between the AR and legitimate
   LMA and a legitimate MAG can act as a man in the middle with respect
   to both control plane signaling and data plane traffic.  If the
   attacker is on the original control plane path, it can forge, modify,
   or drop route update packets so as to cause the establishment of
   incorrect routes or the removal of routes that are in a position active use.
   Similarly, an attacker on the original data plane path can intercept,
   inspect, modify, redirect, and drop data plane packets sourced by or
   destined to a victim mobile node.

   A compromised router located between the LMA and a MAG may cause
   similar damage.  Any router on the control plane path can forge,
   modify, or drop control plane packets, and thereby interfere with
   route establishment.  Any router on the data plane path can
   intercept, inspect, modify, and redirect NETLMM protocol signaling traffic drop data plane packets, or rewrite
   their IP headers so as to divert the packets from their original
   path.

   An attacker between an authorized the LMA and a MAG may further impersonate the MAG
   towards the LMA and vice versa in route update signaling.  The
   attacker can so interfere with route establishment even if it is not
   on the original control plane path between the LMA and authorized ARs handling mobility
   management for the localized mobility management domain.  If the MAG.  An
   attacker can masquerade as an AR off the original data plane path may undertake the same to
   cause inbound data plane packets destined to the mobile node to be
   routed first from the LMA to the attacker, and as from there to the LMA
   mobile node's MAG and finally to the
   ARs, it may be mobile node itself.  As
   explained in a position to spoof both sides into believing that
   they have a secure link.  The Section 2.1, here, too, it depends on the specific data
   plane forwarding mechanism within the localized mobility management
   domain whether or not the attacker can then utilize influence the
   information derived from route of
   outgoing data plane packets sourced by the NETLMM protocol signaling for various
   purposes. mobile node.

2.4  Denial of Service Attack on the LMA

   An attacker could may launch a denial-of-service attack on the LMA by
   sending packets to arbitrary IP addresses with a prefix from which are potentially in
   use by mobile nodes within the
   NETLMM localized mobility management domain.  The
   Like a border router, the LMA is in a topological position through
   which all data-plane data plane traffic goes, so it would have to must process the flooding
   packets and perform a routing table lookup for each of them.  The LMA
   could
   can discard packets for which the destination IP destination address is not
   registered in the routing table.  But other packets would have to must be
   encapsulated and forwarded.  There would  A target MAG as well as any mobile nodes
   attached to its access link are also be some damage likely to suffer damage because
   the
   target AR unrequested packets must be decapsulated and its link. consume link
   bandwidth as well as processing capacities on the receivers.  This
   threat is in principle the same as for denial of service on a regular
   IPv6 border router, but because either the routing table lookup
   enables the LMA to drop a flooding packet early or, on the contrary,
   additional tunneling workload is required, the impact of an attack
   against localized mobility management may be different.

   In a related attack, the attacker villain manages to obtain a globally
   routable IP address of an LMA or a different network entity within
   the NETLMM domain, localized mobility management domain and perpetrates a DoS denial-of-
   service attack against that IP address.  In general, NETLMM-based  Localized mobility
   management is in general somewhat
   more resistant to DoS attacks than host-based localized mobility
   management such an attack because
   mobile nodes within the domain need never obtain a globally routable IP address of any
   entity within the NETLMM localized mobility management domain.
   As a consequence, a  A
   compromised mobile node hence cannot pass such an IP address off to an a
   remote attacker, limiting the ability feasibility of an unauthorized attacker
   to extract extracting information
   on the topology of the NETLMM localized mobility management domain.  It is
   still possible for an attacker to perform IP address scanning if ARs MAGs
   and LMAs have globally routable IP addresses, or for a compromise to
   happen in another way, IP addresses, but the much larger
   IPv6 address space makes
   address scanning considerably more time consuming.

3.  Threats to the MN-AR Interface between MAG and Mobile Node

   In order to detect IP level handovers of mobile nodes, NETLMM access
   routers utilize handover signaling between the arrival and departure of mobile node nodes and
   accordingly initiate route updates with the LMA, a MAG monitors the
   mobile nodes' link-layer handoff signaling or IP-layer movement
   detection signaling.  Cellular access router.  For cellular-type interfaces, such technologies utilize only the
   signaling occurs at the wireless link layer, and the IP stack never sees any
   change when the mobile node moves from one AR MAG to an AR a MAG on a
   different link.  For non-cellular interfaces, access technologies, such as IEEE
   802.11 or wired Ethernet-type
   interfaces, link layer Ethernet, the link-layer signaling may not hide IP handover a
   handoff from the IP
   stack.  The IP stack may need to perform layer.  Instead, IP-layer movement detection
   signaling may have to be performed in response to some kind of a notification from
   the link layer hint that a change in access
   point link-layer attachment has occurred.
   This signaling may involve extensions of [7] for IPv6 Neighbor Discovery [8]
   [8], DHCPv6 [9], or it may involve DHCP [9] or it may involve
   some link-specific additional technology-specific functionality at
   the IP level mechanism. layer.  In any case, the security threats to on the handover signaling that triggers NETLMM routing
   updates are interface
   between the same, MAG and a mobile node are described in this section. the same.  They either pertain
   to impersonation of the mobile node or to man-in-the-middle attacks.

3.1  Mobile Node  Network Access Identity

   In order for NETLMM localized mobility management to be able to definitively
   and unambiguously identify a mobile node upon handover, handoff, the mobile
   node must establish a network access identity when it initially enters
   connects to the localized mobility managment domain.  E.g., the network.  For example, a
   mobile node may initially authenticate itself to the NETLMM domain based on its NAI
   [4] and an AAA-based protocol.  This identifier  The network access identity is
   conceptually independent of the mobile node's IP or link-layer
   addresses.  In  For some wireless networks, access technologies, the network access
   identity must be re-established on every handover between access points.

   NETLMM link-layer handoff.

   Localized mobility management requires that the access network establish establishment of a secure
   binding between the network access identity and either the IP
   addresses that of the mobile node
   self-configures (if address auto-configuration is used) node, or that it is
   assigned (if stateful address configuration is used).  This any authentication keys associated
   with these IP addresses.  The binding is used by the AR MAG to definitively and unambiguously deduce
   that a the mobile node has handed over into onto the AR's last hop subnet, MAG's access link,
   thereby providing the trigger for NETLMM route update signaling to the LMA.
   The binding between the initial mobile-node authentication and the
   IPv6 addresses must be robust to spoofing, for spoofing because it would otherwise
   facilitate impersonation of the mobile node by a third party.
   Lacking this binding, the following attacks are conceivable. party or man-
   in-the-middle attacks.

3.2  Impersonation on Handover of Mobile Nodes

   An attacker that is able is able to forge the network access identity of a
   neighboring victim mobile node can trick its MAG into redirecting the
   mobile node's packets to itself.  Such an on-link attack is common
   for any regular IPv6 network [2].

   However, if handoff signaling cannot definitively be linked back to
   the legitimate network access identity, an attacker may be capable of
   fabricating handoff signaling of a victim mobile node that currently
   attaches to forge an MN's network access identity a different link.  The attacker can
   use this capability to fabricate handover signaling, thereby tricking
   the AR thus trick its MAG
   into believing that the victim mobile node has handed over into onto the AR's
   last hop subnet. MAG's
   access link.  The AR MAG will then perform initiate route update signaling
   with to
   the LMA, causing the LMA to redirect traffic inbound data plane packets for
   the mobile node to the attacker. attacker's MAG and finally to the attacker
   itself.  The attacker can utilize this capability to so examine and discard
   traffic the packets that legitimately belongs
   belong to the MN, as a means of denying
   the MN service mobile node, or to snoop the MN's traffic.  If the attacker can
   interpose between discard the MN packets and deny the network during router discovery and
   address configuration, mobile
   node service.  This is conceivable both if the attacker can mount a man in and the middle
   attack
   mobile node are on links that connect to different MAGs, as well as
   if they are on separate links connecting to the MN, spoofing same MAG.  In the MN into believing it has a legitimate
   connection with
   former case, two MAGs would think they see the network.

3.3  Off-Link Attacks

   Depending on mobile node and both
   would independently perform route update signaling with the exact nature of LMA.  In
   the handover signaling, an
   impersonation attack could latter case, route update signaling is likely to be mounted from off link.  Off-link
   attacks are possible in cases where performed
   only once, and the NETLMM domain consists redirection of
   multiple access routers serving multiple last hop links.  If packets from the
   security on network access identity establishment is weak, or mobile node to the IP
   level movement detection signaling
   attacker is unprotected so that the network
   cannot definitively link the signaling back internal to the legitimate MAG.  The mobile node network access identity, then an attacker can always
   recapture its traffic back from the attacker through another link
   could spoof IP level run of
   link-layer handoff signaling and/or IP-layer movement detection signaling for
   signaling.  But standard mobile nodes are generally not prepared to
   counteract this kind of attack, and even where network stacks include
   suitable functionality, the attack may not be noticeable early enough
   at the link or IP layer to quickly institute countermeasures.  The
   attack is therefore disruptive at a victim mobile
   node minimum, and thereby steal may potentially
   persist until the mobile node's traffic. node initiates signaling again upon a
   subsequent handoff.

   Off-link impersonation attacks can be prevented at the link-layer. link layer.
   E.g., they are not possible with cellular-style protocols, cellular access technologies, where
   the handover handoff signaling is completely controlled by the wireless link layer,
   because
   layer.  Here, an attacker must be on the same link with as the MN victim
   mobile node in order to disrupt the negotiation with between the mobile
   node and the network.  Cellular-style protocols  Cellular access technologies also have provide
   other cryptographic and noncryptographic barriers to non-cryptographic attack barriers at the link
   layer, which make mounting an impersonation attack, both on-link and
   off-link, very difficult.  For non-cellular-style
   protocols, non-cellular access technologies,
   however, it off-link impersonation attacks may be possible possible.

3.3  Man in the Middle Attack

   An attacker which can interpose between a victim mobile node and the
   MAG during link-layer handoff signaling and/or IP-layer signaling for an off-link
   movement detection, router discovery, and IP address configuration
   can mount a man-in-the-middle attack on the mobile node, spoofing the
   mobile node into believing that it has a legitimate connection with
   the localized mobility management domain.  The attacker can thus
   intercept, inspect, modify, or selectively drop packets sourced by or
   destined to
   mount an impersonation attack. the mobile node.

4.  Security Considerations

   The

   This document describes threats to network-based localized mobility
   management.  These may either occur on the NETLMM protocol [3] interface between the LMA
   and to a MAG, or on the
   MN-AR interface functions necessary to support network-based mobility
   management [2]. between a MAG and a mobile node.
   Mitigation measures for these the threats, and as well as the security
   considerations associated with those measures, are described in the
   respective drafts that discuss the NETLMM protocol and specifications [10][11] for the
   MN-AR interface. two interfaces.

5.  IANA Considerations

   This document has no actions for IANA.

6.  Acknowledgment

   The authors would like to thank the NETLMM working group, especially
   Jari Arkko, Gregory Daley, Gerardo Giaretta, Wassim Haddad, Julien
   Laganier, Lakshminath Dondeti, Henrik Levkowetz, Phil Roberts, and Vidya Narayanan
   Narayanan, and Pekka Savola (in alphabetical order) for their valuable
   comments and suggestions regarding this document.

6.

7.  Informative References

   [1]   Kempf, J., "Problem Statement for IP Local Mobility", Network-based Localized
         Mobility Management", IETF Internet Draft draft-ietf-netlmm-nohost-ps-01.txt
         draft-ietf-netlmm-nohost-ps-04.txt (work in progress), April
         June 2006.

   [2]   Laganier, J.   Nikander, P., Kempf, J., and S. Narayanan, "Network-based Localized
         Mobility Management Interface between Mobile Node E. Nordmark, "IPv6 Neighbor
         Discovery (ND) Trust Models and Access
         Router", Threats", IETF Internet Draft draft-ietf-netlmm-mn-ar-if-00.txt
         (work in progress), April 2006. Request for
         Comments 3756, May 2004.

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

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

   [7]

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

   [8]

   [6]   Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
         "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)",
         IETF Request for Comments 4140, August 2005.

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

   [8]   Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
         IETF Internet Draft draft-ietf-ipv6-2461bis-07.txt (work in
         progress), February May 2006.

   [9]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, E., C., and M.
         Carney, "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", IETF Request for Comments 3315, July 2003.

   [10]  Giaretta, G., "NetLMM Protocol", IETF Internet Draft draft-ietf-dna-protocol-00.txt
         draft-giaretta-netlmm-dt-protocol-00.txt (work in progress), February
         June 2006.

   [10]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
         Discovery (ND) Trust Models and Threats", IETF Request for
         Comments 3756, May 2004.

   [11]  Nikander, P., Arkko,  Laganier, J., Aura, T., Montenegro, G., Narayanan, S., and E.
         Nordmark, "Mobile IP Version 6 Route Optimization Security
         Design Background", F. Templin, "Network-based
         Localized Mobility Management Interface between Mobile Node and
         Access Router", IETF Request for Comments 4225,
         December 2005. Internet Draft
         draft-ietf-netlmm-mn-ar-if-01.txt (work in progress),
         June 2006.

Authors' Addresses

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

   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

Appendix A.  Change Log

   The following is a list of technical changes that were made from
   version 01 to version 02 of the document.  Editorial revisions are
   not explicitly identified.

   o  Section 2.1:  Included DoS/flooding attack against MAG.  Also
      clarified how a malicious node off the control plane path between
      the authorized LMA and one or multiple target MAGs could
      impersonate the authorized LMA against the MAGs.  Such an attacker
      could use various means to interfer with data plane traffic even
      if it is off the original data plane path between the legitimate
      LMA and the MAGs.

   o  Section 2.2:  Malicious MAG may deregister an actively
      communicating mobile node, without consent of the mobile node.

   o  Section 2.3:  Included related threats pertaining to MITM between
      LMA and MAG, which were formerly described in other sections.

   o  Section 2.4:  Included description of DoS/flooding attack against
      LMA, including its impact on the target MAGs, their links, and the
      target mobile nodes.

   o  Section 3:  Revised the structure of this section.  Threats are
      now divided into attacks against a mobile node's network access
      identity; impersonation of a mobile node, both from the mobile
      node's link and from off link; as well as man-in-the-middle
      attacks.

   o  Section 3.1:  The binding with the network access identity may be
      with the authentication keys associated with the mobile node's IP
      address, not necessarily with the IP addresses themselves.

   o  Section 3.2:  Off-link attack may be mounted from a link that
      connects to a different MAG than the victim mobile node's MAG.

Intellectual Property Statement

   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.

   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

   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.