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

    Security Threats to Network-Based Localized Mobility Management
                    draft-ietf-netlmm-threats-02.txt
                    draft-ietf-netlmm-threats-03.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 January 24, February 22, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

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

Table of Contents

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

1.  Introduction

   The network-based localized mobility management (NETLMM) architecture
   [1] supports movement of IPv6 mobile nodes locally within a domain
   without requiring mobility support in the mobile nodes' network
   stacks.  A mobile node can keep its IP address constant as it moves
   from link to link, avoiding the signaling overhead and latency
   associated with changing the IP address.  While software specifically
   for localized mobility management is not required on the mobile node,
   IP-layer movement detection software may be necessary, and driver
   software for link-layer mobility is prerequisite.

   The IP addresses of mobile nodes have a prefix that routes to a
   localized mobility anchor (LMA).  This  The LMA maintains an individual
   route for each registered mobile node.  Any particular mobile node's
   route terminates at a mobile access gateway (MAG) which the mobile
   node uses as a default router on its current access link.  MAGs are
   responsible for updating the mobile node's route on the LMA as the
   mobile node moves.  A MAG detects the arrival of a mobile node on its
   local access link based on handoff signaling that the mobile node
   pursues.  The MAG may additionally monitor connectivity of the mobile
   node in order to recognize when the mobile node has left the local
   access link.  The localized mobility management architecture
   therefore has two interfaces:

   1.  The interface between MAGs a MAG and the an LMA where route update
       signaling occurs.

   2.  The interface between a mobile nodes node and their currently selected
       MAGs its current MAG where link-layer
       handoff signaling and possibly IP-layer
       movement detection other link maintenance signaling occurs.

   The localized mobility management architecture specifies no
   standardized protocol for a MAG to detect the arrival or departure of
   mobile nodes on its local link and accordingly initiate route update
   signaling with the LMA.  An appropriate mechanism may be entirely
   implemented at the link layer, such as is common for cellular
   networks.  In that case, the IP layer never detects any movement,
   even when a mobile node moves from one link to another handled by a
   different MAG.  If the link layer does not provide the necessary
   functionality, the mobile node must perform active IP-layer movement
   detection signaling so as to trigger route update signaling at the
   MAG.

   This document discusses security threats on both interfaces of
   localized mobility management.  The discussion  In either case, the decisive handoff signaling is limited bound to threats
   specific a
   mobile node identity, which is established when the mobile node
   initially connects to localized mobility management; threats the domain.  For some wireless access
   technologies, the mobile node identity may have to IPv6 be re-established
   on every link-layer handoff.

   Vulnerabilities in either interface of the localized mobility
   management architecture may entail new security threats which go
   beyond those that already exist in IPv6.  Potential attack objectives
   may be to roam at the cost of a legitimate mobile node, interpose in
   a mobile node's communications from a position off link, or cause
   denial of service to a mobile node or to the localized mobility
   management domain as a whole.  This document identifies and discusses
   security threats on both interfaces of the localized mobility
   management architecture.  It is limited to threats which are peculiar
   to localized mobility management; threats to IPv6 in general are
   documented in [2]. [3].

1.1  Terminology

   The terminology in this document follows the definitions in [3], [2], with
   those revisions and additions from [1].  In addition, the following
   definition is used:

   Network access

   Mobile node identity

      An identity established for the mobile node during network access
      authentication that when initially
      connecting to the domain.  It allows the network localized mobility
      management domain to definitively and unambiguously identify the
      mobile node upon handoff for route update signaling purposes.  The network access
      mobile node identity may, e.g., is conceptually independent of the mobile
      node's IP or link-layer addresses, but it must be securely bound
      to a link-layer session key, a
      network access identifier (NAI) [4], or a SEND public key [5]. the mobile node's handoff signaling.

2.  Threats to Interface between LMA and MAG

   The localized mobility management protocol executed on the interface
   between the an LMA and a MAG serves to establish, update, and tear down
   routes for data plane traffic of mobile nodes.  Threats to this
   interface can be separated into compromise or impersonation of a
   legitimate LMA, compromise or impersonation of a legitimate MAG, man-
   in-the-middle attacks, and denial-of-service attacks on the LMA.
   man-in-the-middle attacks.

2.1  LMA Compromise or Impersonation

   A compromised LMA can ignore routing updates from a legitimate MAG,
   or forge routing updates for a victim mobile node in order to
   redirect or deny the mobile node's traffic.  Since data plane traffic
   for all mobile nodes routes through the LMA, a compromised LMA can also
   intercept, inspect, modify, redirect, or drop such traffic on a MAG
   supported by the LMA.  The attack can be conducted transiently, to
   selectively disable traffic for any particular mobile node or MAG at
   particular times.

   Moreover, a compromised LMA may manipulate its routing table such
   that all packets are directed towards a single MAG.  This may result
   in a DoS attack against that MAG and its attached link.

   These threats also emanate from an attacker which tricks a MAG into
   believing that it is the a legitimate LMA.  This attacker can cause the
   MAG to conduct route update signaling with the attacker instead of
   with the legitimate LMA, enabling it to ignore route updates from the
   MAG, or forge route updates in order to redirect or deny a victim
   mobile node's traffic.  The attacker does not necessarily have to be
   on the original control plane path between the legitimate LMA and the
   MAG, provided that it can somehow make its presence known to the MAG.
   E.g., the IP address of a mobility anchor point in hierarchical
   Mobile IPv6 mobility management [6] [4] 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 rogue
   LMA.

   The attacker may further be able to intercept, inspect, modify,
   redirect, or drop data plane traffic to and from a mobile 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 an LMA.

   A

   Moreover, 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 an 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  The compromised
   MAG may further be able to cause interruption to a mobile node by
   deregistering the mobile node at the LMA, pretending that the mobile
   node has powered down.  The mobile node then needs to reinitiate the
   network access authentication procedure, which the compromised MAG
   may prevent repeatedly until the mobile node moves to a different
   MAG.  The mobile node should be able to handle this situation, but
   the recovery process may be lengthy and hence impair ongoing
   communication sessions to a significant extent.

   All of these threats apply not just to a MAG that is compromised, but
   also to an attacker

   Attacks that manages to counterfeit the identity MAG can mount on its access link interface are
   common for any regular IPv6 access router [3].

   Denial of service against an
   authorized LMA is another threat of MAG in interacting with both subversion.
   The compromised MAG can trick the LMA into believing that a high
   number of mobile nodes and have attached to the LMA.
   Such MAG.  The LMA will then
   establish a routing table entry for each of the non-existing mobile
   nodes.  The unexpected growth of the routing table may eventually
   cause the LMA to reject legitimate route update requests.  It may
   also decrease the forwarding speed for data plane packets due to
   higher route lookup latencies, and it may for the same reason slow
   down the responsiveness to control plane packets.  Another adverse
   side effect of a high number of routing table entries is that the
   LMA, and hence the localized mobility management domain as a whole,
   becomes more susceptible to flooding packets from external attackers
   (see Section 4).  The high number of superfluous routes increases the
   probability that a flooding packet, sent to a random IP address
   within the localized mobility management domain, matches an existing
   routing table entry at the LMA and gets tunneled to a MAG, which in
   turn performs address resolution [5] on the local access link.  At
   the same time, fewer flooding packets can be dropped directly at the
   LMA due to a nonexistent routing table entry.

   All of these threats apply not just to a MAG that is compromised, but
   also to an attacker that manages to counterfeit the identity of an
   authorized MAG in interacting with both mobile nodes and an LMA.
   Such an attacker can behave towards mobile nodes like a legitimate
   MAG and engage the an LMA in route update signaling.  The attack  In a related
   attack, the perpetrator eavesdrops on signaling packets exchanged
   between an authorized MAG and an LMA and replays these packets at a
   later time.  These attacks may be conducted transiently, to
   selectively disable traffic for any particular mobile node at
   particular times.

2.3  Man in the Middle Attack

   An attacker that manages to interject itself between the a 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 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 an LMA and a MAG may cause
   similar damage.  Any router on the control plane path can forge,
   modify, or drop control plane packets, and thereby interfere with
   route establishment.  Any router on the data plane path can
   intercept, inspect, modify, and drop data plane packets, or rewrite
   their
   IP headers so as to divert the packets from their original path.

   An attacker between the an LMA and a MAG may further impersonate the MAG
   towards the LMA and vice versa in route update signaling.  The
   attacker can so interfere with route establishment even if it is not
   on the original control plane path between the LMA and the MAG.  An
   attacker off the original data plane path may undertake the same to
   cause inbound data plane packets destined to the mobile node to be
   routed first from the LMA to the attacker, and from there to the
   mobile node's MAG and finally to the mobile node itself.  As
   explained in Section 2.1, here, too, it depends on the specific data
   plane forwarding mechanism within the localized mobility management
   domain whether or not the attacker can influence the route of
   outgoing data plane packets sourced by the mobile node.

2.4  Denial of Service Attack on the LMA

   An attacker may launch a denial-of-service attack on the LMA by
   sending packets

3.  Threats to arbitrary IP addresses which are potentially Interface between MAG and Mobile Node

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

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

3.  Threats to Interface between MAG and Mobile Node

   In order to detect the arrival and departure of order to detect the arrival and
   departure of mobile 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. LMA.  Cellular access technologies utilize only the signaling at
   the wireless link layer, and the IP stack never sees any change when
   the mobile node moves from one MAG to a MAG on a different link.  For
   non-cellular access technologies, such as IEEE 802.11 or wired
   Ethernet, the link-layer signaling may not hide a handoff from the IP
   layer.  Instead, IP-layer movement detection signaling may have to be
   performed in response to a notification from the link layer that a
   change in link-layer attachment has occurred.  This signaling may
   involve extensions [7] [6] for IPv6 Neighbor Discovery
   [8], [5], DHCPv6 [9], [7],
   or additional technology-specific functionality at the IP layer.  In any

   Although the mobile node identity is conceptually independent of the
   mobile node's IP or link-layer addresses in either case, it must be
   securely bound to whatever handoff signaling of the security threats mobile node is
   decisive for route updates on the interface
   between the MAG-LMA interface, be it via an
   address or otherwise.  A MAG uses this binding to deduce when the
   mobile node has handed over onto the MAG's local access link, and a
   possibly when the mobile node are leaves the same.  They either pertain local access link again,
   thereby providing the trigger for route update signaling to an LMA.
   The binding must be robust to spoofing because it would otherwise
   facilitate impersonation of the mobile node by a third party, denial
   of service, or to man-in-the-middle attacks.

3.1  Network Access Identity

   In order for localized mobility management  Mobile Node Compromise or Impersonation

   An attacker that is able to forge the mobile node identity of a
   neighboring victim mobile node may be able to trick its MAG into
   redirecting the mobile node's packets to itself.  Such an on-link
   attack is common for any regular IPv6 network [3].  However, if
   handoff signaling cannot definitively and unambiguously identify be linked
   back to the legitimate mobile node identity, an attacker may further
   be capable of fabricating handoff signaling of a victim mobile node upon handoff,
   that currently attaches to a different link.  The attacker can thus
   trick its MAG into believing that the mobile node must establish a network has handed over
   onto the MAG's access identity when it initially
   connects link.  The MAG will then initiate route update
   signaling to an LMA, causing the localized mobility managment domain.  E.g., LMA to redirect inbound data plane
   packets for the mobile node may authenticate itself to the domain based on its NAI
   [4] attacker's MAG and an AAA-based protocol. finally to the
   attacker itself.  The network access identity is
   conceptually independent of attacker can so examine the packets that
   legitimately belong to the mobile node's IP node, or link-layer
   addresses.  For some wireless access technologies, discard the network access
   identity must be re-established on every link-layer handoff.

   Localized mobility management requires packets in
   order to deny the establishment of mobile node service.  The same can happen if a secure
   binding between MAG
   accepts from the network access identity and either attacker replayed handoff signaling packets which
   the IP
   addresses of attacker has previously recorded from the legitimate mobile node, or any authentication keys associated
   with these IP addresses. node.

   The binding above attack is used by conceivable both if the MAG to deduce
   that attacker and the mobile
   node has handed over onto are on links that connect to different MAGs, as well as if they
   are on separate links connecting to the MAG's access link,
   thereby providing same MAG.  In the trigger for former
   case, two MAGs would think they see the mobile node and both would
   independently perform route update signaling to with the LMA.
   The binding must be robust  In the
   latter case, route update signaling is likely to spoofing because it would otherwise
   facilitate impersonation be performed only
   once, and the redirection of packets from the mobile node by a third party or man-
   in-the-middle attacks.

3.2  Impersonation of Mobile Nodes

   An to the
   attacker that is able internal to forge the network access identity of a
   neighboring victim MAG.  The mobile node can trick always
   recapture its MAG into redirecting traffic back from the attacker through another run of
   handoff signaling.  But standard mobile node's packets nodes are generally not
   prepared to itself.  Such an on-link 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 common
   for any regular IPv6 network [2].

   However, if therefore disruptive at a minimum,
   and may potentially persist until the mobile node initiates signaling
   again upon a subsequent handoff.

   Off-link impersonation attacks can be prevented at the link layer.
   E.g., they are not possible with cellular access technologies, where
   the handoff signaling cannot definitively is completely controlled by the wireless link
   layer.  Here, an attacker must be linked back on the same link as the victim
   mobile node in order to disrupt the legitimate network negotiation between the mobile
   node and the network.  Cellular access identity, technologies also provide
   other cryptographic and non-cryptographic attack barriers at the link
   layer, which make mounting an attacker impersonation attack, both on-link and
   off-link, very difficult.  For non-cellular access technologies,
   however, off-link impersonation attacks may be capable of
   fabricating possible.

   An attacker which can forge handoff signaling messages may also cause
   denial of a victim mobile node that currently
   attaches to a different link. service against the localized mobility management domain.
   The attacker can thus trick its a MAG into believing that the a large number of
   mobile node has handed over onto nodes have attached to the MAG's local access link.  The MAG will then link and thus induce
   it to initiate route update signaling to with an LMA for each mobile
   node assumed on link.  The result of such an attack is both
   superfluous signaling overhead on the LMA, causing control plane as well as a high
   number of needless entries in the LMA's and MAG's routing tables.
   The unexpected growth of the routing tables may eventually cause the
   LMA to redirect reject legitimate route update requests, and it may cause the
   MAG to ignore handoffs of legitimate mobile nodes on its local access
   link.  It may also decrease the LMA's and MAG's forwarding speed for
   inbound and outbound data plane packets due to higher route lookup
   latencies, and it may for the mobile node same reason slow down their
   responsiveness to control plane packets.  An adverse side effect of
   this attack is that the LMA, and hence the localized mobility
   management domain as a whole, becomes more susceptible to flooding
   packets from external attackers (see Section 4).  The high number of
   superfluous routes increases the probability that a flooding packet,
   sent to a random IP address within the localized mobility management
   domain, matches an existing routing table entry at the LMA and gets
   tunneled to a MAG, which in turn performs address resolution [5] on
   the local access link.  At the same time, fewer flooding packets can
   be dropped directly at the LMA due to the attacker's MAG and finally a nonexistent routing table
   entry.

   A threat related to the attacker
   itself. ones identified above, but not limited to
   handoff signaling, is IP spoofing [8][9].  Attackers use IP spoofing
   mostly for reflection attacks or to hide their identities.  The attacker
   threat can so examine the packets that legitimately
   belong be reasonably contained by a wide deployment of network
   ingress filtering [10] in access network routers.  This technique
   prevents IP spoofing to the mobile node, or discard extent that it ensures topological
   correctness of IP source address prefixes in to-be-forwarded packets.
   Where the technique is deployed in an access router, packets and deny are
   forwarded only if the mobile
   node service.  This prefix of their IP source address is conceivable both if valid on
   the router's local access link.  An attacker can still use a false
   interface identifier in combination with an on-link prefix.  But
   since reflection attacks typically aim at off-link targets, and the
   mobile node
   enforcement of topologically correct IP address prefixes also limits
   the effectiveness of identity concealment, network ingress filtering
   has proven adequate so far.  On the other hand, prefixes are on links that connect not
   limited to different MAGs, as well as
   if they are on separate links connecting a specific link in a localized mobility management domain,
   so an attacker may be able to send packets with an off-link IP source
   address despite the same MAG.  In the
   former case, two MAGs would think they see presence of network ingress filtering.  This
   could make IP spoofing again more attractive.

3.2  Man in the Middle Attack

   An attacker which can interpose between a victim mobile node and both
   would independently perform route update signaling with the LMA.  In
   the latter case, route update signaling is likely to be performed
   only once, a
   MAG during handoff signaling, router discovery, and IP address
   configuration can mount a man-in-the-middle attack on the redirection of packets from mobile
   node, spoofing the mobile node to into believing that it has a
   legitimate connection with the localized mobility management domain.
   The attacker is internal can thus intercept, inspect, modify, or selectively drop
   packets sourced by or destined to the MAG.  The mobile node can always
   recapture its node.

4.  Threats from the Internet

   A localized mobility management domain uses host routes for data
   plane traffic back and hence deviates from the attacker through another run of
   link-layer handoff signaling and/or IP-layer movement detection
   signaling.  But standard mobile nodes IPv6 longest-
   prefix-match routing.  Creation, maintenance, and deletion of tese
   host routes in addition cause control traffic within the localized
   mobility management domain.  These characteristics are generally not prepared transparent to
   counteract this kind of attack, and even where network stacks include
   suitable functionality,
   mobile nodes as well as external correspondent nodes, but the
   functional differences within the domain may influence the impact
   that a denial-of-service attack from the outside world can have on
   the domain.

   A denial-of-service attack on an LMA may not be noticeable early enough
   at the link or IP layer launched by sending
   packets to quickly institute countermeasures.  The
   attack arbitrary IP addresses which are potentially in use by
   mobile nodes within the localized mobility management domain.  Like a
   border router, the LMA is therefore disruptive at in a minimum, and may potentially
   persist until topological position through which a
   substantial amount of data plane traffic goes, so it must process the mobile node initiates signaling again upon
   flooding packets and perform a
   subsequent handoff.

   Off-link impersonation attacks routing table lookup for each of them.
   The LMA can be prevented at the link layer.
   E.g., they are not possible with cellular access technologies, where discard packets for which the handoff signaling IP destination address is completely controlled by
   not registered in its routing table.  But other packets must be
   encapsulated and forwarded.  A target MAG as well as any mobile nodes
   attached to the wireless MAG's local access link
   layer.  Here, an attacker are also likely to suffer
   damage because the unrequested packets must be on the same decapsulated and
   consume link bandwidth as well as processing capacities on the victim
   mobile node
   receivers.  This threat is in order to disrupt principle the negotiation between same as for denial of
   service on a regular IPv6 border router, but because either the mobile
   node and
   routing table lookup enables the network.  Cellular access technologies also provide
   other cryptographic and non-cryptographic attack barriers at LMA to drop a flooding packet early
   on or, on the link
   layer, which make mounting contrary, additional tunneling workload is required,
   the impact of an impersonation attack, both on-link and
   off-link, very difficult.  For non-cellular access technologies,
   however, off-link impersonation attacks attack against localized mobility management may be possible.

3.3  Man in the Middle Attack

   An attacker which can interpose between
   different.

   In a victim mobile node and related attack, the
   MAG during link-layer handoff signaling and/or IP-layer signaling for
   movement detection, router discovery, and villain manages to obtain a globally
   routable IP address configuration
   can mount of an LMA or a man-in-the-middle attack on different network entity within
   the localized mobility management domain and perpetrates a denial-of-
   service attack against that IP address.  Localized mobility
   management is in general somewhat resistant to such an attack because
   mobile node, spoofing nodes need never obtain a globally routable IP address of any
   entity within the localized mobility management domain.  A
   compromised mobile node into believing that it has hence cannot pass such an IP address off to a legitimate connection with
   remote attacker, limiting the feasibility of extracting information
   on the topology of the localized mobility management domain.  The  It is
   still possible for an attacker can thus
   intercept, inspect, modify, or selectively drop packets sourced by or
   destined to perform IP address scanning if MAGs
   and LMAs have globally routable IP addresses, but the mobile node.

4. much larger
   IPv6 address space makes scanning considerably more time consuming.

5.  Security Considerations

   This document describes threats to network-based localized mobility
   management.  These may either occur on the interface between the an LMA
   and a MAG, or on the interface between a MAG and a mobile node.
   Mitigation measures for the threats, as well as the security
   considerations associated with those measures, are described in the
   respective protocol specifications [10][11] [11][12] for the two interfaces.

5.

6.  IANA Considerations

   This document has no actions for IANA.

6.

7.  Acknowledgment

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

7.  Informative

8.  References

8.1  Normative References

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

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

8.2  Informative References

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

   [3]   Manner, J.

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

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

   [6]   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-01.txt (work in
         progress), June 2006.

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

   [8]   CERT Coordination Center, "CERT Advisory CA-1996-21 TCP SYN
         Flooding and IP Spoofing Attacks", September 1996.

   [9]   CERT Coordination Center, "CERT Advisory CA-1998-01 Smurf IP
         Denial-of-Service Attacks", January 1998.

   [10]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", IETF Request for Comments 2827, May 2000.

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

   [12]  Laganier, J., Narayanan, S., and F. Templin, "Network-based
         Localized Mobility Management Interface between Mobile Node and
         Access Router", IETF Internet Draft
         draft-ietf-netlmm-mn-ar-if-01.txt (work in progress),
         June 2006.

   [13]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         IETF Request for Comments 3753, June 2004.

   [4] 3972, March 2005.

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

   [5]   Aura, T., "Cryptographically Generated

Authors' Addresses (CGA)",
         IETF Request for Comments 3972, March 2005.

   [6]   Soliman, H., Castelluccia, C., El Malki, K.,

   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 02 to version 03 of the document.  Editorial revisions are
   not explicitly mentioned.

   o  Changed the terminology from "network access identity" to "mobile
      node identity" as the previous term was frequently confused with
      the different "network access identifier" (NAI).  Removed the
      special "Network Access Identity" subsection in Section 3.  The
      mobile node identity is now first mentioned in Section 1, which
      fits well with the nutshell description of the NETLMM
      architecture.  The security requirements of the mobile node
      identifier are discussed in the introductory text of Section 3.
      This makes more sense than a special subsection because the text,
      on one hand, provides the necessary basis to understand the
      following subsections, while on the other hand, it does not really
      explain an attack itself.

   o  Section 1:  Extended the description of conceptual actors in the
      localized mobility management architecture 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., added a summary of
      potential attack objectives and JH.
         Choi, "Detecting Network Attachment attack targets.

   o  Section 3.1:  Granularity of ingress filtering may be coarser in IPv6 Networks (DNAv6)",
         IETF Internet Draft draft-ietf-dna-protocol-01.txt (work a
      localized mobility mangement domain.  It may also allow off-link
      IP spoofing since prefixes are not limited to a specific link.

   o  Section 2.2:  The threat of replay attacks was not mentioned in
         progress), June 2006.

   [8]   Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
         IETF Internet Draft draft-ietf-ipv6-2461bis-07.txt (work
      this section.  It was added.

   o  Section 3.1: The threat of replay attacks was not mentioned in
         progress), May 2006.

   [9]   Droms, R., Bound, J., Volz, B., Lemon, T., 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-giaretta-netlmm-dt-protocol-00.txt (work
      this section.  It was added.

   o  Section 2.2:  Causing spurious route updates may lead to DoS
      against the localized mobility management domain.  This threat was
      missing in progress),
         June 2006.

   [11]  Laganier, J., Narayanan, S., and F. Templin, "Network-based
         Localized Mobility Management Interface between Mobile Node the discussion of this section and
         Access Router", IETF Internet Draft
         draft-ietf-netlmm-mn-ar-if-01.txt (work it was added.

   o  Section 3.1:  Causing spurious route updates may lead to DoS
      against the localized mobility management domain.  This threat was
      missing in progress),
         June 2006.

Authors' Addresses

   Christian Vogt
   Institute the discussion 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 this section and it was added.

   o  Section 4:  Moved DoS attack against a localized mobility
      management domain from the Internet to a separate section because
      it is not specific to either interface within the domain.

   o  Revised the document with respect to the recent agreement the
      addressing model.

   o  Revised the document with respect to the the possibility that
      there may be more than one LMA.  The text was initially written
      under the assumption that the LMA is unique.

   o  References split into normative and informative references.

   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. mentioned.

   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 interfere 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: 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: 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: 3.1:  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.