| < draft-ietf-netlmm-threats-03.txt | draft-ietf-netlmm-threats-04.txt > | |||
|---|---|---|---|---|
| Network Working Group C. Vogt | Network Working Group C. Vogt | |||
| Internet-Draft Universitaet Karlsruhe (TH) | Internet-Draft Universitaet Karlsruhe (TH) | |||
| Expires: February 22, 2007 J. Kempf | Expires: March 16, 2007 J. Kempf | |||
| DoCoMo USA Labs | DoCoMo USA Labs | |||
| August 21, 2006 | September 12, 2006 | |||
| Security Threats to Network-Based Localized Mobility Management | Security Threats to Network-Based Localized Mobility Management | |||
| draft-ietf-netlmm-threats-03.txt | draft-ietf-netlmm-threats-04.txt | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 35 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on February 22, 2007. | This Internet-Draft will expire on March 16, 2007. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
| Abstract | Abstract | |||
| This document discusses security threats to network-based localized | This document discusses security threats to network-based localized | |||
| mobility management. Threats may occur on two interfaces: the | mobility management. Threats may occur on two interfaces: the | |||
| interface between an LMA and a MAG, as well as the interface between | interface between a localized mobility anchor and a mobile access | |||
| a MAG and a mobile node. Threats to the former interface impact the | gateway, as well as the interface between a mobile access gateway and | |||
| localized mobility management protocol itself. | a mobile node. Threats to the former interface impact the localized | |||
| mobility management protocol itself. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2. Threats to Interface between LMA and MAG . . . . . . . . . . . 4 | 2. Threats to Interface between LMA and MAG . . . . . . . . . . . 4 | |||
| 2.1 LMA Compromise or Impersonation . . . . . . . . . . . . . 4 | 2.1 LMA Compromise or Impersonation . . . . . . . . . . . . . 4 | |||
| 2.2 MAG Compromise or Impersonation . . . . . . . . . . . . . 5 | 2.2 MAG Compromise or Impersonation . . . . . . . . . . . . . 5 | |||
| 2.3 Man in the Middle Attack . . . . . . . . . . . . . . . . . 7 | 2.3 Man in the Middle Attack . . . . . . . . . . . . . . . . . 7 | |||
| 3. Threats to Interface between MAG and Mobile Node . . . . . . . 8 | 3. Threats to Interface between MAG and Mobile Node . . . . . . . 7 | |||
| 3.1 Mobile Node Compromise or Impersonation . . . . . . . . . 8 | 3.1 Mobile Node Compromise or Impersonation . . . . . . . . . 8 | |||
| 3.2 Man in the Middle Attack . . . . . . . . . . . . . . . . . 10 | 3.2 Man in the Middle Attack . . . . . . . . . . . . . . . . . 10 | |||
| 4. Threats from the Internet . . . . . . . . . . . . . . . . . . 10 | 4. Threats from the Internet . . . . . . . . . . . . . . . . . . 10 | |||
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 | 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 8.1 Normative References . . . . . . . . . . . . . . . . . . . 13 | 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 | |||
| 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 | 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| Intellectual Property and Copyright Statements . . . . . . . . 17 | Intellectual Property and Copyright Statements . . . . . . . . 16 | |||
| 1. Introduction | 1. Introduction | |||
| The network-based localized mobility management (NETLMM) architecture | The network-based localized mobility management (NETLMM) architecture | |||
| [1] supports movement of IPv6 mobile nodes locally within a domain | [1] supports movement of IPv6 mobile nodes locally within a domain | |||
| without requiring mobility support in the mobile nodes' network | without requiring mobility support in the mobile nodes' network | |||
| stacks. A mobile node can keep its IP address constant as it moves | stacks. A mobile node can keep its IP address constant as it moves | |||
| from link to link, avoiding the signaling overhead and latency | from link to link, avoiding the signaling overhead and latency | |||
| associated with changing the IP address. While software specifically | associated with changing the IP address. Software specifically for | |||
| for localized mobility management is not required on the mobile node, | localized mobility management is not required on the mobile node, | |||
| IP-layer movement detection software may be necessary, and driver | whereas IP-layer movement detection software may be necessary, and | |||
| software for link-layer mobility is prerequisite. | driver software for link-layer mobility is prerequisite. | |||
| The IP addresses of mobile nodes have a prefix that routes to a | The IP addresses of mobile nodes have a prefix that routes to a | |||
| localized mobility anchor (LMA). The LMA maintains an individual | localized mobility anchor (LMA) [3]. The LMA maintains an individual | |||
| route for each registered mobile node. Any particular mobile node's | route for each registered mobile node. Any particular mobile node's | |||
| route terminates at a mobile access gateway (MAG) which the mobile | route terminates at a mobile access gateway (MAG) [3], to which the | |||
| node uses as a default router on its current access link. MAGs are | mobile node attaches at its current access link. MAGs are | |||
| responsible for updating the mobile node's route on the LMA as the | 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 | 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 | local access link based on handoff signaling that the mobile node | |||
| pursues. The MAG may additionally monitor connectivity of the mobile | pursues. The MAG may additionally monitor connectivity of the mobile | |||
| node in order to recognize when the mobile node has left the local | node in order to recognize when the mobile node has left the local | |||
| access link. The localized mobility management architecture | access link. The localized mobility management architecture | |||
| therefore has two interfaces: | therefore has two interfaces: | |||
| 1. The interface between a MAG and an LMA where route update | 1. The interface between a MAG and an LMA where route update | |||
| signaling occurs. | signaling occurs. | |||
| 2. The interface between a mobile node and its current MAG where | 2. The interface between a mobile node and its current MAG where | |||
| handoff signaling and other link maintenance signaling occurs. | handoff signaling and other link maintenance signaling occurs. | |||
| The localized mobility management architecture specifies no | The localized mobility management architecture demands no specific | |||
| standardized protocol for a MAG to detect the arrival or departure of | protocol for a MAG to detect the arrival or departure of mobile nodes | |||
| mobile nodes on its local link and accordingly initiate route update | to and from its local access link and accordingly initiate route | |||
| signaling with the LMA. An appropriate mechanism may be entirely | update signaling with an LMA. An appropriate mechanism may be | |||
| implemented at the link layer, such as is common for cellular | entirely implemented at the link layer, such as is common for | |||
| networks. In that case, the IP layer never detects any movement, | cellular networks. In that case, the IP layer never detects any | |||
| even when a mobile node moves from one link to another handled by a | movement, even when a mobile node moves from one link to another | |||
| different MAG. If the link layer does not provide the necessary | handled by a different MAG. If the link layer does not provide the | |||
| functionality, the mobile node must perform active IP-layer movement | necessary functionality, the mobile node must perform IP-layer | |||
| detection signaling so as to trigger route update signaling at the | movement detection and auto-configuration signaling, thereby | |||
| MAG. In either case, the decisive handoff signaling is bound to a | providing the trigger for the MAG to update its route at the LMA. A | |||
| mobile node identity, which is established when the mobile node | mobile node identity, established by the localized mobility | |||
| initially connects to the domain. For some wireless access | management domain when the mobile node initially connects and | |||
| technologies, the mobile node identity may have to be re-established | authenticates, enables the MAG to ascribe the decisive link- or IP- | |||
| on every link-layer handoff. | layer signaling to the correct mobile node. Some wireless access | |||
| technologies may require the mobile node identity to be re- | ||||
| established on every link-layer handoff. | ||||
| Vulnerabilities in either interface of the localized mobility | Vulnerabilities in either interface of the localized mobility | |||
| management architecture may entail new security threats which go | management architecture may entail new security threats which go | |||
| beyond those that already exist in IPv6. Potential attack objectives | beyond those that already exist in IPv6. This document identifies | |||
| may be to roam at the cost of a legitimate mobile node, interpose in | and discusses security threats on both interfaces of the localized | |||
| a mobile node's communications from a position off link, or cause | mobility management architecture. It is limited to threats which are | |||
| denial of service to a mobile node or to the localized mobility | peculiar to localized mobility management; threats to IPv6 in general | |||
| management domain as a whole. This document identifies and discusses | are documented in [4]. | |||
| 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 [3]. | ||||
| 1.1 Terminology | 1.1 Terminology | |||
| The terminology in this document follows the definitions in [2], with | The terminology in this document follows the definitions in [2], with | |||
| those revisions and additions from [1]. In addition, the following | those revisions and additions from [1]. In addition, the following | |||
| definition is used: | definition is used: | |||
| Mobile node identity | Mobile Node Identity | |||
| An identity established for the mobile node when initially | An identity established for the mobile node when initially | |||
| connecting to the domain. It allows the localized mobility | connecting to the domain. It allows the localized mobility | |||
| management domain to definitively and unambiguously identify the | management domain to definitively and unambiguously identify the | |||
| mobile node upon handoff for route update signaling purposes. The | mobile node upon handoff for route update signaling purposes. The | |||
| mobile node identity is conceptually independent of the mobile | mobile node identity is conceptually independent of the mobile | |||
| node's IP or link-layer addresses, but it must be securely bound | node's IP or link-layer addresses, but it must be securely bound | |||
| to the mobile node's handoff signaling. | to the mobile node's handoff signaling. | |||
| 2. Threats to Interface between LMA and MAG | 2. Threats to Interface between LMA and MAG | |||
| The localized mobility management protocol executed on the interface | The localized mobility management protocol executed on the interface | |||
| between an LMA and a MAG serves to establish, update, and tear down | between an LMA and a MAG serves to establish, update, and tear down | |||
| routes for data plane traffic of mobile nodes. Threats to this | routes for data plane traffic of mobile nodes. Threats to this | |||
| interface can be separated into compromise or impersonation of a | interface can be separated into compromise or impersonation of a | |||
| legitimate LMA, compromise or impersonation of a legitimate MAG, and | legitimate LMA, compromise or impersonation of a legitimate MAG, and | |||
| man-in-the-middle attacks. | man-in-the-middle attacks. | |||
| 2.1 LMA Compromise or Impersonation | 2.1 LMA Compromise or Impersonation | |||
| A compromised LMA can ignore routing updates from a legitimate MAG, | A compromised LMA can ignore route updates from a legitimate MAG in | |||
| or forge routing updates for a victim mobile node in order to | order to deny service to a mobile node. It may also be able to trick | |||
| redirect or deny the mobile node's traffic. Since data plane traffic | a legitimate MAG into creating a new, incorrect route, thereby | |||
| preparing the MAG to receive redirected traffic of a mobile node; it | ||||
| may cause the traffic forwarded by a MAG to be redirected to a | ||||
| different LMA; or it may simply have the MAG drop an existing route | ||||
| in order to deny the mobile node service. Since data plane traffic | ||||
| for mobile nodes routes through the LMA, a compromised LMA can also | for mobile nodes routes through the LMA, a compromised LMA can also | |||
| intercept, inspect, modify, redirect, or drop such traffic on a MAG | intercept, inspect, modify, or drop such traffic, or redirect it to a | |||
| supported by the LMA. The attack can be conducted transiently, to | destination in collusion with the attacker. The attack can be | |||
| selectively disable traffic for any particular mobile node or MAG at | conducted transiently, to selectively disable traffic for any | |||
| particular times. | particular mobile node or MAG at particular times. | |||
| Moreover, a compromised LMA may manipulate its routing table such | Moreover, a compromised LMA may manipulate its routing table such | |||
| that all packets are directed towards a single MAG. This may result | that all packets are directed towards a single MAG. This may result | |||
| in a DoS attack against that MAG and its attached link. | in a DoS attack against that MAG and its attached access link. | |||
| These threats also emanate from an attacker which tricks a MAG into | These threats also emanate from an attacker which tricks a MAG into | |||
| believing that it is a legitimate LMA. This attacker can cause the | believing that it is a legitimate LMA. This attacker can cause the | |||
| MAG to conduct route update signaling with the attacker instead of | MAG to conduct route update signaling with the attacker instead of | |||
| with the legitimate LMA, enabling it to ignore route updates from the | 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 | MAG, or induce incorrect route changes at the MAG as described above, | |||
| mobile node's traffic. The attacker does not necessarily have to be | in order to redirect or deny a mobile node's traffic. The attacker | |||
| on the original control plane path between the legitimate LMA and the | does not necessarily have to be on the original control plane path | |||
| MAG, provided that it can somehow make its presence known to the MAG. | between the legitimate LMA and the MAG, provided that it can somehow | |||
| E.g., the IP address of a mobility anchor point in hierarchical | make its presence known to the MAG. Failure to mutually authenticate | |||
| Mobile IPv6 mobility management [4] may be proliferated across a | when establishing an association between an LMA and a MAG would allow | |||
| domain hop by hop in Router Advertisement messages. Failure to | an attacker to establish itself as a rogue LMA. | |||
| properly authenticate a comparable mechanism for localized mobility | ||||
| management would allow an attacker to establish itself as a rogue | ||||
| LMA. | ||||
| The attacker may further be able to intercept, inspect, modify, | The attacker may further be able to intercept, inspect, modify, drop, | |||
| redirect, or drop data plane traffic to and from a mobile node. This | or redirect data plane traffic to and from a mobile node. This is | |||
| is obvious if the attacker is on the original data plane path between | obvious if the attacker is on the original data plane path between | |||
| the legitimate LMA and the mobile node's current MAG, which may | the legitimate LMA and the mobile node's current MAG, which may | |||
| happen independent of whether or not the attacker is on the original | happen independently of whether the attacker is on the original | |||
| control plane path. If the attacker is not on this path, it may be | control plane path. If the attacker is not on this path, it may be | |||
| able to leverage the localized mobility management protocol to | able to leverage the localized mobility management protocol to | |||
| redefine the prefix that the mobile node uses in IP address | redefine the prefix that the mobile node uses in IP address | |||
| configuration. The attacker can then specify a prefix that routes to | configuration. The attacker can then specify a prefix that routes to | |||
| itself. Whether or not outgoing data plane packets sourced by the | itself. Whether or not outgoing data plane packets sourced by the | |||
| mobile node can be interfered with by an attacker off the original | mobile node can be interfered with by an attacker off the original | |||
| data plane path depends on the specific data plane forwarding | data plane path depends on the specific data plane forwarding | |||
| mechanism within the localized mobility management domain. E.g., if | mechanism within the localized mobility management domain. E.g., if | |||
| IP-in-IP encapsulation or an equivalent per-mobile-node approach is | IP-in-IP encapsulation or an equivalent approach is used for outbound | |||
| used for outbound data plane packets, the packets will route through | data plane packets, the packets can be forced to be routed through | |||
| the attacker. On the other hand, standard IP routing may cause the | the attacker. On the other hand, standard IP routing may cause the | |||
| packets to be relayed via the legitimate LMA and hence to circumvent | packets to be relayed via a legitimate LMA and hence to circumvent | |||
| the attacker. | the attacker. | |||
| 2.2 MAG Compromise or Impersonation | 2.2 MAG Compromise or Impersonation | |||
| A compromised MAG can redirect a victim mobile node's traffic onto | A compromised MAG can redirect a mobile node's traffic onto its local | |||
| its local access link arbitrarily, without authorization from the | access link arbitrarily, without authorization from the mobile node. | |||
| mobile node. This threat is similar to an attack on a typical | This threat is similar to an attack on a typical routing protocol | |||
| routing protocol where a malicious stub router injects a bogus host | where a malicious stub router injects a bogus host route for the | |||
| route for the mobile node. In general, forgery of a subnet prefix in | mobile node. In general, forgery of a subnet prefix in link state or | |||
| link state or distance vector routing protocols requires support of | distance vector routing protocols requires support of multiple | |||
| multiple routers in order to obtain a meaningful change in forwarding | routers in order to obtain a meaningful change in forwarding | |||
| behavior. But a bogus host route is likely to take precedence over | behavior. But a bogus host route is likely to take precedence over | |||
| the routing information advertised by legitimate routers, which is | the routing information advertised by legitimate routers, which is | |||
| usually less specific, hence the attack should succeed even if the | usually less specific, hence the attack should succeed even if the | |||
| attacker is not supported by other routers. A difference between | attacker is not supported by other routers. A difference between | |||
| redirection in a routing protocol and redirection in localized | redirection in a routing protocol and redirection in localized | |||
| mobility management is that the former impacts the routing tables of | mobility management is that the former impacts the routing tables of | |||
| multiple routers, whereas the latter involves only the compromised | multiple routers, whereas the latter involves only the compromised | |||
| MAG and an LMA. | MAG and an LMA. | |||
| Moreover, a compromised MAG can ignore the presence of a mobile node | Moreover, a compromised MAG can ignore the presence of a mobile node | |||
| on its local access link and refrain from registering the mobile node | on its local access link and refrain from registering the mobile node | |||
| at an LMA. The mobile node then loses its traffic. The compromised | at an LMA. The mobile node then loses its traffic. The compromised | |||
| MAG may further be able to cause interruption to a mobile node by | MAG may further be able to cause interruption to a mobile node by | |||
| deregistering the mobile node at the LMA, pretending that the mobile | deregistering the mobile node at the serving LMA, pretending that the | |||
| node has powered down. The mobile node then needs to reinitiate the | mobile node has powered down. The mobile node then needs to re- | |||
| network access authentication procedure, which the compromised MAG | initiate the network access authentication procedure, which the | |||
| may prevent repeatedly until the mobile node moves to a different | compromised MAG may prevent repeatedly until the mobile node moves to | |||
| MAG. The mobile node should be able to handle this situation, but | a different MAG. The mobile node should be able to handle this | |||
| the recovery process may be lengthy and hence impair ongoing | situation, but the recovery process may be lengthy and hence impair | |||
| communication sessions to a significant extent. | ongoing communication sessions to a significant extent. | |||
| Attacks that the MAG can mount on its access link interface are | ||||
| common for any regular IPv6 access router [3]. | ||||
| Denial of service against an LMA is another threat of MAG subversion. | Denial of service against an LMA is another threat of MAG subversion. | |||
| The compromised MAG can trick the LMA into believing that a high | The compromised MAG can trick an LMA into believing that a high | |||
| number of mobile nodes have attached to the MAG. The LMA will then | number of mobile nodes have attached to the MAG. The LMA will then | |||
| establish a routing table entry for each of the non-existing mobile | establish a routing table entry for each of the non-existing mobile | |||
| nodes. The unexpected growth of the routing table may eventually | nodes. The unexpected growth of the routing table may eventually | |||
| cause the LMA to reject legitimate route update requests. It may | cause the LMA to reject legitimate route update requests. It may | |||
| also decrease the forwarding speed for data plane packets due to | also decrease the forwarding speed for data plane packets due to | |||
| higher route lookup latencies, and it may for the same reason slow | higher route lookup latencies, and it may for the same reason slow | |||
| down the responsiveness to control plane packets. Another adverse | down the responsiveness to control plane packets. Another adverse | |||
| side effect of a high number of routing table entries is that the | side effect of a high number of routing table entries is that the | |||
| LMA, and hence the localized mobility management domain as a whole, | LMA, and hence the localized mobility management domain as a whole, | |||
| becomes more susceptible to flooding packets from external attackers | becomes more susceptible to flooding packets from external attackers | |||
| (see Section 4). The high number of superfluous routes increases the | (see Section 4). The high number of superfluous routes increases the | |||
| probability that a flooding packet, sent to a random IP address | probability that a flooding packet, sent to a random IP address | |||
| within the localized mobility management domain, matches an existing | within the localized mobility management domain, matches an existing | |||
| routing table entry at the LMA and gets tunneled to a MAG, which in | 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 | turn performs address resolution on the local access link. At the | |||
| the same time, fewer flooding packets can be dropped directly at the | same time, fewer flooding packets can be dropped directly at the LMA | |||
| LMA due to a nonexistent routing table entry. | on the basis of a nonexistent routing table entry. | |||
| All of these threats apply not just to a MAG that is compromised, but | 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 | also to an attacker that manages to counterfeit the identity of a | |||
| authorized MAG in interacting with both mobile nodes and an LMA. | legitimate MAG in interacting with both mobile nodes and an LMA. | |||
| Such an attacker can behave towards mobile nodes like a legitimate | Such an attacker can behave towards mobile nodes like an authorized | |||
| MAG and engage an LMA in route update signaling. In a related | MAG and engage an LMA in route update signaling. In a related | |||
| attack, the perpetrator eavesdrops on signaling packets exchanged | attack, the perpetrator eavesdrops on signaling packets exchanged | |||
| between an authorized MAG and an LMA and replays these packets at a | between a legitimate MAG and an LMA and replays these packets at a | |||
| later time. These attacks may be conducted transiently, to | later time. These attacks may be conducted transiently, to | |||
| selectively disable traffic for any particular mobile node at | selectively disable traffic for any particular mobile node at | |||
| particular times. | particular times. | |||
| 2.3 Man in the Middle Attack | 2.3 Man in the Middle Attack | |||
| An attacker that manages to interject itself between a legitimate LMA | An attacker that manages to interject itself between a legitimate LMA | |||
| and a legitimate MAG can act as a man in the middle with respect to | 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 | both control plane signaling and data plane traffic. If the attacker | |||
| is on the original control plane path, it can forge, modify, or drop | is on the original control plane path, it can forge, modify, or drop | |||
| route update packets so as to cause the establishment of incorrect | route update packets so as to cause the establishment of incorrect | |||
| routes or the removal of routes that are in active use. Similarly, | routes or the removal of routes that are in active use. Similarly, | |||
| an attacker on the original data plane path can intercept, inspect, | an attacker on the original data plane path can intercept, inspect, | |||
| modify, redirect, and drop data plane packets sourced by or destined | modify, drop, and redirect data plane packets sourced by or destined | |||
| to a victim mobile node. | to a mobile node. | |||
| A compromised router located between an LMA and a MAG may cause | A compromised switch or router located between an LMA and a MAG can | |||
| similar damage. Any router on the control plane path can forge, | cause similar damage. Any switch or router on the control plane path | |||
| modify, or drop control plane packets, and thereby interfere with | can forge, modify, or drop control plane packets, and thereby | |||
| route establishment. Any router on the data plane path can | interfere with route establishment. Any switch or router on the data | |||
| intercept, inspect, modify, and drop data plane packets, or rewrite | plane path can intercept, inspect, modify, and drop data plane | |||
| IP headers so as to divert the packets from their original path. | packets, or rewrite IP headers so as to divert the packets from their | |||
| original path. | ||||
| An attacker between an LMA and a MAG may further impersonate the MAG | An attacker between an LMA and a MAG may further impersonate the MAG | |||
| towards the LMA and vice versa in route update signaling. The | towards the LMA and vice versa in route update signaling. The | |||
| attacker can so interfere with route establishment even if it is not | 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 | 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 | attacker off the original data plane path may undertake the same to | |||
| cause inbound data plane packets destined to the mobile node to be | 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 | 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 | 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 | explained in Section 2.1, here, too, it depends on the specific data | |||
| plane forwarding mechanism within the localized mobility management | plane forwarding mechanism within the localized mobility management | |||
| domain whether or not the attacker can influence the route of | domain whether or not the attacker can influence the route of | |||
| outgoing data plane packets sourced by the mobile node. | outgoing data plane packets sourced by the mobile node. | |||
| 3. Threats to Interface between MAG and Mobile Node | 3. Threats to Interface between MAG and Mobile Node | |||
| A MAG monitors the mobile nodes' link-layer handoff signaling or IP- | A MAG monitors the arrival and departure of mobile nodes to and from | |||
| layer movement detection signaling in order to detect the arrival and | its local access link based on link- or IP-layer mechanisms. | |||
| departure of mobile nodes and accordingly initiate route updates with | Whatever signaling on the access link is thereby decisive must be | |||
| the LMA. Cellular access technologies utilize only the signaling at | securely bound to the mobile node identity. A MAG uses this binding | |||
| the wireless link layer, and the IP stack never sees any change when | to ascribe the signaling to the mobile node and accordingly initiate | |||
| the mobile node moves from one MAG to a MAG on a different link. For | route update signaling with an LMA. The binding must be robust to | |||
| non-cellular access technologies, such as IEEE 802.11 or wired | spoofing because it would otherwise facilitate impersonation of the | |||
| Ethernet, the link-layer signaling may not hide a handoff from the IP | mobile node by a third party, denial of service, or man-in-the-middle | |||
| layer. Instead, IP-layer movement detection signaling may have to be | attacks. | |||
| performed in response to a notification from the link layer that a | ||||
| change in link-layer attachment has occurred. This signaling may | ||||
| involve extensions [6] for IPv6 Neighbor Discovery [5], DHCPv6 [7], | ||||
| or additional technology-specific functionality at the IP layer. | ||||
| 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 mobile node is | ||||
| decisive for route updates on 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 | ||||
| possibly when the mobile node leaves the 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 man-in-the-middle attacks. | ||||
| 3.1 Mobile Node Compromise or Impersonation | 3.1 Mobile Node Compromise or Impersonation | |||
| An attacker that is able to forge the mobile node identity of a | 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 | mobile node can to trick a MAG into redirecting data plane packets | |||
| redirecting the mobile node's packets to itself. Such an on-link | for the mobile node to the attacker. The attacker can launch such an | |||
| attack is common for any regular IPv6 network [3]. However, if | impersonation attack against a mobile node that resides on the same | |||
| handoff signaling cannot definitively and unambiguously be linked | link as the attacker, or against a mobile node on a different link. | |||
| back to the legitimate mobile node identity, an attacker may further | If the attack is on-link, the redirection of packets from the mobile | |||
| be capable of fabricating handoff signaling of a victim mobile node | node to the attacker is internal to the MAG, and it involves no route | |||
| that currently attaches to a different link. The attacker can thus | update signaling between the MAG and an LMA. On-link attacks are | |||
| trick its MAG into believing that the mobile node has handed over | possible in a regular IPv6 network [4] that does not use Secure | |||
| onto the MAG's access link. The MAG will then initiate route update | Neighbor Discovery [5]. | |||
| signaling to an LMA, causing the LMA to redirect inbound data plane | ||||
| packets for the mobile node to the attacker's MAG and finally to the | ||||
| attacker itself. The attacker can so examine the packets that | ||||
| legitimately belong to the mobile node, or discard the packets in | ||||
| order to deny the mobile node service. The same can happen if a MAG | ||||
| accepts from the attacker replayed handoff signaling packets which | ||||
| the attacker has previously recorded from the legitimate mobile node. | ||||
| The above attack is conceivable both if the attacker and the mobile | Off-link impersonation requires the attacker to fabricate handoff | |||
| node are on links that connect to different MAGs, as well as if they | signaling of the mobile node and thus trick the MAG into believing | |||
| are on separate links connecting to the same MAG. In the former | that the mobile node has handed over onto the MAG's access link. The | |||
| case, two MAGs would think they see the mobile node and both would | attack is conceivable both if the attacker and the mobile node are on | |||
| independently perform route update signaling with the LMA. In the | separate links that connect to different MAGs, as well as if they are | |||
| latter case, route update signaling is likely to be performed only | on separate, possibly virtual per-mobile-node links that connect to | |||
| once, and the redirection of packets from the mobile node to the | the same MAG. In the former case, two MAGs would think they see the | |||
| attacker is internal to the MAG. The mobile node can always | mobile node and both would independently perform route update | |||
| recapture its traffic back from the attacker through another run of | signaling with the LMA. In the latter case, route update signaling | |||
| handoff signaling. But standard mobile nodes are generally not | is likely to be performed only once, and the redirection of packets | |||
| prepared to counteract this kind of attack, and even where network | from the mobile node to the attacker is internal to the MAG. The | |||
| stacks include suitable functionality, the attack may not be | mobile node can always recapture its traffic back from the attacker | |||
| noticeable early enough at the link or IP layer to quickly institute | through another run of handoff signaling. But standard mobile nodes | |||
| countermeasures. The attack is therefore disruptive at a minimum, | are generally not prepared to counteract this kind of attack, and | |||
| and may potentially persist until the mobile node initiates signaling | even where network stacks include suitable functionality, the attack | |||
| again upon a subsequent handoff. | may not be noticeable early enough at the link or IP layer to quickly | |||
| institute countermeasures. The attack is 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. | Impersonation attacks can be prevented at the link layer, | |||
| E.g., they are not possible with cellular access technologies, where | particularly with cellular technologies where the handoff signaling | |||
| the handoff signaling is completely controlled by the wireless link | between the mobile node and the network must be authenticated and is | |||
| layer. Here, an attacker must be on the same link as the victim | completely controlled by the wireless link layer. Cellular access | |||
| mobile node in order to disrupt the negotiation between the mobile | technologies provide a variety of cryptographic and non-cryptographic | |||
| node and the network. Cellular access technologies also provide | attack barriers at the link layer which make mouting an impersonation | |||
| other cryptographic and non-cryptographic attack barriers at the link | attack, both on-link and off-link, very difficult. However, for non- | |||
| layer, which make mounting an impersonation attack, both on-link and | cellular technologies that do not require link layer authentication | |||
| off-link, very difficult. For non-cellular access technologies, | and authorization during handoff, impersonation attacks may be | |||
| however, off-link impersonation attacks may be possible. | possible. | |||
| An attacker which can forge handoff signaling messages may also cause | An attacker that can forge handoff signaling may also cause denial of | |||
| denial of service against the localized mobility management domain. | service against the localized mobility management domain. The | |||
| The attacker can trick a MAG into believing that a large number of | attacker can trick a MAG into believing that a large number of mobile | |||
| mobile nodes have attached to the local access link and thus induce | nodes have attached to the local access link and thus induce it to | |||
| it to initiate route update signaling with an LMA for each mobile | initiate route update signaling with an LMA for each mobile node | |||
| node assumed on link. The result of such an attack is both | assumed on link. The result of such an attack is both superfluous | |||
| superfluous signaling overhead on the control plane as well as a high | signaling overhead on the control plane as well as a high number of | |||
| number of needless entries in the LMA's and MAG's routing tables. | needless entries in the LMA's and MAG's routing tables. The | |||
| The unexpected growth of the routing tables may eventually cause the | unexpected growth of the routing tables may eventually cause the LMA | |||
| LMA to reject legitimate route update requests, and it may cause the | to reject legitimate route update requests, and it may cause the MAG | |||
| MAG to ignore handoffs of legitimate mobile nodes on its local access | to ignore handoffs of legitimate mobile nodes onto its local access | |||
| link. It may also decrease the LMA's and MAG's forwarding speed for | 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 | inbound and outbound data plane packets due to higher route lookup | |||
| latencies, and it may for the same reason slow down their | latencies, and it may for the same reason slow down their | |||
| responsiveness to control plane packets. An adverse side effect of | responsiveness to control plane packets. An adverse side effect of | |||
| this attack is that the LMA, and hence the localized mobility | this attack is that the LMA, and hence the localized mobility | |||
| management domain as a whole, becomes more susceptible to flooding | management domain as a whole, becomes more susceptible to flooding | |||
| packets from external attackers (see Section 4). The high number of | packets from external attackers (see Section 4). The high number of | |||
| superfluous routes increases the probability that a flooding packet, | superfluous routes increases the probability that a flooding packet, | |||
| sent to a random IP address within the localized mobility management | sent to a random IP address within the localized mobility management | |||
| domain, matches an existing routing table entry at the LMA and gets | domain, matches an existing routing table entry at the LMA and gets | |||
| tunneled to a MAG, which in turn performs address resolution [5] on | tunneled to a MAG, which in turn performs address resolution on the | |||
| the local access link. At the same time, fewer flooding packets can | local access link. At the same time, fewer flooding packets can be | |||
| be dropped directly at the LMA due to a nonexistent routing table | dropped directly at the LMA on the basis of a nonexistent routing | |||
| entry. | table entry. | |||
| A threat related to the ones identified above, but not limited to | A threat related to the ones identified above, but not limited to | |||
| handoff signaling, is IP spoofing [8][9]. Attackers use IP spoofing | handoff signaling, is IP spoofing [6]. Attackers use IP spoofing | |||
| mostly for reflection attacks or to hide their identities. The | mostly for reflection attacks or to hide their identities. The | |||
| threat can be reasonably contained by a wide deployment of network | threat can be reasonably contained by a wide deployment of network | |||
| ingress filtering [10] in access network routers. This technique | ingress filtering [7] in routers, especially within access networks. | |||
| prevents IP spoofing to the extent that it ensures topological | This technique prevents IP spoofing to the extent that it ensures | |||
| correctness of IP source address prefixes in to-be-forwarded packets. | topological correctness of IP source address prefixes in to-be- | |||
| Where the technique is deployed in an access router, packets are | forwarded packets. Where the technique is deployed in an access | |||
| forwarded only if the prefix of their IP source address is valid on | router, packets are forwarded only if the prefix of their IP source | |||
| the router's local access link. An attacker can still use a false | address is valid on the router's local access link. An attacker can | |||
| interface identifier in combination with an on-link prefix. But | still use a false interface identifier in combination with an on-link | |||
| since reflection attacks typically aim at off-link targets, and the | prefix. But since reflection attacks typically aim at off-link | |||
| enforcement of topologically correct IP address prefixes also limits | targets, and the enforcement of topologically correct IP address | |||
| the effectiveness of identity concealment, network ingress filtering | prefixes also limits the effectiveness of identity concealment, | |||
| has proven adequate so far. On the other hand, prefixes are not | network ingress filtering has proven adequate so far. On the other | |||
| limited to a specific link in a localized mobility management domain, | hand, prefixes are not limited to a specific link in a localized | |||
| so an attacker may be able to send packets with an off-link IP source | mobility management domain, so merely ensuring topological | |||
| address despite the presence of network ingress filtering. This | correctness through ingress filtering becomes insufficient. An | |||
| could make IP spoofing again more attractive. | additional mechanism for IP address ownership verification is | |||
| necessary to prevent an attacker from sending packets with an off- | ||||
| link IP source address. | ||||
| 3.2 Man in the Middle Attack | 3.2 Man in the Middle Attack | |||
| An attacker which can interpose between a victim mobile node and a | An attacker which can interpose between a mobile node and a MAG | |||
| MAG during handoff signaling, router discovery, and IP address | during link- and/or IP-layer handoff signaling may be able to mount a | |||
| configuration can mount a man-in-the-middle attack on the mobile | man-in-the-middle attack on the mobile node, spoofing the mobile node | |||
| node, spoofing the mobile node into believing that it has a | into believing that it has a legitimate connection with the localized | |||
| legitimate connection with the localized mobility management domain. | mobility management domain. The attacker can thus intercept, | |||
| The attacker can thus intercept, inspect, modify, or selectively drop | inspect, modify, or drop data plane packets sourced by or destined to | |||
| packets sourced by or destined to the mobile node. | the mobile node. | |||
| 4. Threats from the Internet | 4. Threats from the Internet | |||
| A localized mobility management domain uses host routes for data | A localized mobility management domain uses individual host routes | |||
| plane traffic and hence deviates from the standard IPv6 longest- | for data plane traffic of different mobile nodes, each between an LMA | |||
| prefix-match routing. Creation, maintenance, and deletion of tese | and a MAG. Creation, maintenance, and deletion of these routes cause | |||
| host routes in addition cause control traffic within the localized | control traffic within the localized mobility management domain. | |||
| mobility management domain. These characteristics are transparent to | These characteristics are transparent to mobile nodes as well as | |||
| mobile nodes as well as external correspondent nodes, but the | external correspondent nodes, but the functional differences within | |||
| functional differences within the domain may influence the impact | the domain may influence the impact that a denial-of-service attack | |||
| that a denial-of-service attack from the outside world can have on | from the outside world can have on the domain. | |||
| the domain. | ||||
| A denial-of-service attack on an LMA may be launched by sending | A denial-of-service attack on an LMA may be launched by sending | |||
| packets to arbitrary IP addresses which are potentially in use by | packets to arbitrary IP addresses that are potentially in use by | |||
| mobile nodes within the localized mobility management domain. Like a | mobile nodes within the localized mobility management domain. Like a | |||
| border router, the LMA is in a topological position through which a | border router, the LMA is in a topological position through which a | |||
| substantial amount of data plane traffic goes, so it must process the | substantial amount of data plane traffic goes, so it must process the | |||
| flooding packets and perform a routing table lookup for each of them. | flooding packets and perform a routing table lookup for each of them. | |||
| The LMA can discard packets for which the IP destination address is | The LMA can discard packets for which the IP destination address is | |||
| not registered in its routing table. But other packets must be | not registered in its routing table. But other packets must be | |||
| encapsulated and forwarded. A target MAG as well as any mobile nodes | encapsulated and forwarded. A target MAG as well as any mobile nodes | |||
| attached to the MAG's local access link are also likely to suffer | attached to that MAG's local access link are also likely to suffer | |||
| damage because the unrequested packets must be decapsulated and | damage because the unrequested packets must be decapsulated and | |||
| consume link bandwidth as well as processing capacities on the | consume link bandwidth as well as processing capacities on the | |||
| receivers. This threat is in principle the same as for denial of | receivers. This threat is in principle the same as for denial of | |||
| service on a regular IPv6 border router, but because either the | service on a regular IPv6 border router, but because the routing | |||
| routing table lookup enables the LMA to drop a flooding packet early | table lookups may enable the LMA to drop part of the flooding packets | |||
| on or, on the contrary, additional tunneling workload is required, | early on or, on the contrary, additional tunneling workload is | |||
| the impact of an attack against localized mobility management may be | required for packets that cannot be dropped, the impact of an attack | |||
| different. | against localized mobility management may be different. | |||
| In a related attack, the villain manages to obtain a globally | In a related attack, the attacker manages to obtain a globally | |||
| routable IP address of an LMA or a different network entity within | routable IP address of an LMA or a different network entity within | |||
| the localized mobility management domain and perpetrates a denial-of- | the localized mobility management domain and perpetrates a denial-of- | |||
| service attack against that IP address. Localized mobility | service attack against that IP address. Localized mobility | |||
| management is in general somewhat resistant to such an attack because | management is in general somewhat resistant to such an attack because | |||
| mobile nodes need never obtain a globally routable IP address of any | mobile nodes need never obtain a globally routable IP address of any | |||
| entity within the localized mobility management domain. A | entity within the localized mobility management domain. A | |||
| compromised mobile node hence cannot pass such an IP address off to a | compromised mobile node hence cannot pass such an IP address off to a | |||
| remote attacker, limiting the feasibility of extracting information | remote attacker, limiting the feasibility of extracting information | |||
| on the topology of the localized mobility management domain. It is | on the topology of the localized mobility management domain. It is | |||
| still possible for an attacker to perform IP address scanning if MAGs | still possible for an attacker to perform IP address scanning if MAGs | |||
| and LMAs have globally routable IP addresses, but the much larger | and LMAs have globally routable IP addresses, but the much larger | |||
| IPv6 address space makes scanning considerably more time consuming. | IPv6 address space makes scanning considerably more time consuming. | |||
| 5. Security Considerations | 5. Security Considerations | |||
| This document describes threats to network-based localized mobility | This document describes threats to network-based localized mobility | |||
| management. These may either occur on the interface between an LMA | management. These may either occur on the interface between an LMA | |||
| and a MAG, or on the interface between a MAG and a mobile node. | and a MAG, or on the interface between a MAG and a mobile node. | |||
| Mitigation measures for the threats, as well as the security | Mitigation measures for the threats, as well as the security | |||
| considerations associated with those measures, are described in the | considerations associated with those measures, are described in the | |||
| respective protocol specifications [11][12] for the two interfaces. | respective protocol specifications [3][8] for the two interfaces. | |||
| 6. IANA Considerations | 6. IANA Considerations | |||
| This document has no actions for IANA. | This document has no actions for IANA. | |||
| 7. Acknowledgment | 7. Acknowledgment | |||
| The authors would like to thank the NETLMM working group, especially | The authors would like to thank the NETLMM working group, especially | |||
| Jari Arkko, Gregory Daley, Vijay Devarapalli, Lakshminath Dondeti, | Jari Arkko, Gregory Daley, Vijay Devarapalli, Lakshminath Dondeti, | |||
| Gerardo Giaretta, Wassim Haddad, Andy, Huang, Dirk von Hugo, Julien | Gerardo Giaretta, Wassim Haddad, Andy, Huang, Dirk von Hugo, Julien | |||
| skipping to change at page 13, line 19 ¶ | skipping to change at page 12, line 19 ¶ | |||
| [1] Kempf, J., "Problem Statement for Network-based Localized | [1] Kempf, J., "Problem Statement for Network-based Localized | |||
| Mobility Management", IETF Internet Draft | Mobility Management", IETF Internet Draft | |||
| draft-ietf-netlmm-nohost-ps-04.txt (work in progress), | draft-ietf-netlmm-nohost-ps-04.txt (work in progress), | |||
| June 2006. | June 2006. | |||
| [2] Manner, J. and M. Kojo, "Mobility Related Terminology", | [2] Manner, J. and M. Kojo, "Mobility Related Terminology", | |||
| IETF Request for Comments 3753, June 2004. | IETF Request for Comments 3753, June 2004. | |||
| 8.2 Informative References | 8.2 Informative References | |||
| [3] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor | [3] Giaretta, G., "NetLMM Protocol", IETF Internet Draft | |||
| Discovery (ND) Trust Models and Threats", IETF Request for | draft-giaretta-netlmm-dt-protocol-00.txt (work in progress), | |||
| Comments 3756, May 2004. | June 2006. | |||
| [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. | ||||
| 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: | [4] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor | |||
| Defeating Denial of Service Attacks which employ IP Source | Discovery (ND) Trust Models and Threats", IETF Request for | |||
| Address Spoofing", IETF Request for Comments 2827, May 2000. | Comments 3756, May 2004. | |||
| [11] Giaretta, G., "NetLMM Protocol", IETF Internet Draft | [5] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure | |||
| draft-giaretta-netlmm-dt-protocol-00.txt (work in progress), | Neighbor Discovery (SEND)", IETF Request for Comments 3971, | |||
| June 2006. | March 2005. | |||
| [12] Laganier, J., Narayanan, S., and F. Templin, "Network-based | [6] CERT Coordination Center, "CERT Advisory CA-1996-21 TCP SYN | |||
| Localized Mobility Management Interface between Mobile Node and | Flooding and IP Spoofing Attacks", September 1996. | |||
| 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)", | [7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating | |||
| IETF Request for Comments 3972, March 2005. | Denial of Service Attacks which employ IP Source Address | |||
| Spoofing", IETF Request for Comments 2827, May 2000. | ||||
| [14] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network | [8] Laganier, J., Narayanan, S., and F. Templin, "Network-based | |||
| Access Identifier", IETF Request for Comments 4282, | Localized Mobility Management Interface between Mobile Node and | |||
| December 2005. | Access Router", IETF Internet Draft | |||
| draft-ietf-netlmm-mn-ar-if-01.txt (work in progress), June 2006. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Christian Vogt | Christian Vogt | |||
| Institute of Telematics | Institute of Telematics | |||
| Universitaet Karlsruhe (TH) | Universitaet Karlsruhe (TH) | |||
| P.O. Box 6980 | P.O. Box 6980 | |||
| 76128 Karlsruhe | 76128 Karlsruhe | |||
| Germany | Germany | |||
| skipping to change at page 14, line 41 ¶ | skipping to change at page 13, line 28 ¶ | |||
| 181 Metro Drive, Suite 300 | 181 Metro Drive, Suite 300 | |||
| San Jose, CA 95110 | San Jose, CA 95110 | |||
| USA | USA | |||
| Phone: +1 408 451 4711 | Phone: +1 408 451 4711 | |||
| Email: kempf@docomolabs-usa.com | Email: kempf@docomolabs-usa.com | |||
| Appendix A. Change Log | Appendix A. Change Log | |||
| The following is a list of technical changes that were made from | The following is a list of technical changes that were made from | |||
| version 03 to version 04 of the document. Editorial revisions are | ||||
| not explicitly mentioned. | ||||
| o Section 2.1: Clarified in first paragraph what it means for a | ||||
| compromised LMA to "forge routing updates for a victim mobile | ||||
| node" and what the intention behind such an attack could be. | ||||
| o Section 2.1: Removed description of how MAP discovery works in | ||||
| Hierarchical Mobile IPv6. | ||||
| o Section 3: Introductory text shortened, because (i) it repeated | ||||
| material from Section 1, and (ii) also described potential link- | ||||
| layer technologies for access links, which was not within the | ||||
| scope of this document. | ||||
| o Section 3.1: Clarified how impersonation of a mobile node may | ||||
| look like when the attacker attaches to the same MAG as the mobile | ||||
| node, but to a different link. | ||||
| o Section 3.1: Revised text on why cellular technologies can | ||||
| prevent impersonation attacks against mobile nodes at the link | ||||
| layer. | ||||
| The following is a list of technical changes that were made from | ||||
| version 02 to version 03 of the document. Editorial revisions are | version 02 to version 03 of the document. Editorial revisions are | |||
| not explicitly mentioned. | not explicitly mentioned. | |||
| o Changed the terminology from "network access identity" to "mobile | o Changed the terminology from "network access identity" to "mobile | |||
| node identity" as the previous term was frequently confused with | node identity" as the previous term was frequently confused with | |||
| the different "network access identifier" (NAI). Removed the | the different "network access identifier" (NAI). Removed the | |||
| special "Network Access Identity" subsection in Section 3. The | special "Network Access Identity" subsection in Section 3. The | |||
| mobile node identity is now first mentioned in Section 1, which | mobile node identity is now first mentioned in Section 1, which | |||
| fits well with the nutshell description of the NETLMM | fits well with the nutshell description of the NETLMM | |||
| architecture. The security requirements of the mobile node | architecture. The security requirements of the mobile node | |||
| skipping to change at page 15, line 19 ¶ | skipping to change at page 14, line 31 ¶ | |||
| This makes more sense than a special subsection because the text, | This makes more sense than a special subsection because the text, | |||
| on one hand, provides the necessary basis to understand the | on one hand, provides the necessary basis to understand the | |||
| following subsections, while on the other hand, it does not really | following subsections, while on the other hand, it does not really | |||
| explain an attack itself. | explain an attack itself. | |||
| o Section 1: Extended the description of conceptual actors in the | o Section 1: Extended the description of conceptual actors in the | |||
| localized mobility management architecture and added a summary of | localized mobility management architecture and added a summary of | |||
| potential attack objectives and attack targets. | potential attack objectives and attack targets. | |||
| o Section 3.1: Granularity of ingress filtering may be coarser in a | o Section 3.1: Granularity of ingress filtering may be coarser in a | |||
| localized mobility mangement domain. It may also allow off-link | localized mobility management domain. It may also allow off-link | |||
| IP spoofing since prefixes are not limited to a specific 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 | o Section 2.2: The threat of replay attacks was not mentioned in | |||
| this section. It was added. | this section. It was added. | |||
| o Section 3.1: The threat of replay attacks was not mentioned in | o Section 3.1: The threat of replay attacks was not mentioned in | |||
| this section. It was added. | this section. It was added. | |||
| o Section 2.2: Causing spurious route updates may lead to DoS | o Section 2.2: Causing spurious route updates may lead to DoS | |||
| against the localized mobility management domain. This threat was | against the localized mobility management domain. This threat was | |||
| End of changes. 52 change blocks. | ||||
| 272 lines changed or deleted | 251 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||