idnits 2.17.1 draft-ietf-netlmm-threats-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 691. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 21, 2006) is 6458 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '13' is defined on line 553, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 556, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-netlmm-nohost-ps-04 ** Downref: Normative reference to an Informational draft: draft-ietf-netlmm-nohost-ps (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '2') -- Obsolete informational reference (is this intentional?): RFC 4140 (ref. '4') (Obsoleted by RFC 5380) == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-07 == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-01 -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '7') (Obsoleted by RFC 8415) == Outdated reference: A later version (-02) exists of draft-giaretta-netlmm-dt-protocol-00 == Outdated reference: A later version (-03) exists of draft-ietf-netlmm-mn-ar-if-01 -- Obsolete informational reference (is this intentional?): RFC 4282 (ref. '14') (Obsoleted by RFC 7542) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Vogt 3 Internet-Draft Universitaet Karlsruhe (TH) 4 Expires: February 22, 2007 J. Kempf 5 DoCoMo USA Labs 6 August 21, 2006 8 Security Threats to Network-Based Localized Mobility Management 9 draft-ietf-netlmm-threats-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 22, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document discusses security threats to network-based localized 43 mobility management. Threats may occur on two interfaces: the 44 interface between an LMA and a MAG, as well as the interface between 45 a MAG and a mobile node. Threats to the former interface impact the 46 localized mobility management protocol itself. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Threats to Interface between LMA and MAG . . . . . . . . . . . 4 53 2.1 LMA Compromise or Impersonation . . . . . . . . . . . . . 4 54 2.2 MAG Compromise or Impersonation . . . . . . . . . . . . . 5 55 2.3 Man in the Middle Attack . . . . . . . . . . . . . . . . . 7 56 3. Threats to Interface between MAG and Mobile Node . . . . . . . 8 57 3.1 Mobile Node Compromise or Impersonation . . . . . . . . . 8 58 3.2 Man in the Middle Attack . . . . . . . . . . . . . . . . . 10 59 4. Threats from the Internet . . . . . . . . . . . . . . . . . . 10 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 8.1 Normative References . . . . . . . . . . . . . . . . . . . 13 65 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 67 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 Intellectual Property and Copyright Statements . . . . . . . . 17 70 1. Introduction 72 The network-based localized mobility management (NETLMM) architecture 73 [1] supports movement of IPv6 mobile nodes locally within a domain 74 without requiring mobility support in the mobile nodes' network 75 stacks. A mobile node can keep its IP address constant as it moves 76 from link to link, avoiding the signaling overhead and latency 77 associated with changing the IP address. While software specifically 78 for localized mobility management is not required on the mobile node, 79 IP-layer movement detection software may be necessary, and driver 80 software for link-layer mobility is prerequisite. 82 The IP addresses of mobile nodes have a prefix that routes to a 83 localized mobility anchor (LMA). The LMA maintains an individual 84 route for each registered mobile node. Any particular mobile node's 85 route terminates at a mobile access gateway (MAG) which the mobile 86 node uses as a default router on its current access link. MAGs are 87 responsible for updating the mobile node's route on the LMA as the 88 mobile node moves. A MAG detects the arrival of a mobile node on its 89 local access link based on handoff signaling that the mobile node 90 pursues. The MAG may additionally monitor connectivity of the mobile 91 node in order to recognize when the mobile node has left the local 92 access link. The localized mobility management architecture 93 therefore has two interfaces: 95 1. The interface between a MAG and an LMA where route update 96 signaling occurs. 98 2. The interface between a mobile node and its current MAG where 99 handoff signaling and other link maintenance signaling occurs. 101 The localized mobility management architecture specifies no 102 standardized protocol for a MAG to detect the arrival or departure of 103 mobile nodes on its local link and accordingly initiate route update 104 signaling with the LMA. An appropriate mechanism may be entirely 105 implemented at the link layer, such as is common for cellular 106 networks. In that case, the IP layer never detects any movement, 107 even when a mobile node moves from one link to another handled by a 108 different MAG. If the link layer does not provide the necessary 109 functionality, the mobile node must perform active IP-layer movement 110 detection signaling so as to trigger route update signaling at the 111 MAG. In either case, the decisive handoff signaling is bound to a 112 mobile node identity, which is established when the mobile node 113 initially connects to the domain. For some wireless access 114 technologies, the mobile node identity may have to be re-established 115 on every link-layer handoff. 117 Vulnerabilities in either interface of the localized mobility 118 management architecture may entail new security threats which go 119 beyond those that already exist in IPv6. Potential attack objectives 120 may be to roam at the cost of a legitimate mobile node, interpose in 121 a mobile node's communications from a position off link, or cause 122 denial of service to a mobile node or to the localized mobility 123 management domain as a whole. This document identifies and discusses 124 security threats on both interfaces of the localized mobility 125 management architecture. It is limited to threats which are peculiar 126 to localized mobility management; threats to IPv6 in general are 127 documented in [3]. 129 1.1 Terminology 131 The terminology in this document follows the definitions in [2], with 132 those revisions and additions from [1]. In addition, the following 133 definition is used: 135 Mobile node identity 137 An identity established for the mobile node when initially 138 connecting to the domain. It allows the localized mobility 139 management domain to definitively and unambiguously identify the 140 mobile node upon handoff for route update signaling purposes. The 141 mobile node identity is conceptually independent of the mobile 142 node's IP or link-layer addresses, but it must be securely bound 143 to the mobile node's handoff signaling. 145 2. Threats to Interface between LMA and MAG 147 The localized mobility management protocol executed on the interface 148 between an LMA and a MAG serves to establish, update, and tear down 149 routes for data plane traffic of mobile nodes. Threats to this 150 interface can be separated into compromise or impersonation of a 151 legitimate LMA, compromise or impersonation of a legitimate MAG, and 152 man-in-the-middle attacks. 154 2.1 LMA Compromise or Impersonation 156 A compromised LMA can ignore routing updates from a legitimate MAG, 157 or forge routing updates for a victim mobile node in order to 158 redirect or deny the mobile node's traffic. Since data plane traffic 159 for mobile nodes routes through the LMA, a compromised LMA can also 160 intercept, inspect, modify, redirect, or drop such traffic on a MAG 161 supported by the LMA. The attack can be conducted transiently, to 162 selectively disable traffic for any particular mobile node or MAG at 163 particular times. 165 Moreover, a compromised LMA may manipulate its routing table such 166 that all packets are directed towards a single MAG. This may result 167 in a DoS attack against that MAG and its attached link. 169 These threats also emanate from an attacker which tricks a MAG into 170 believing that it is a legitimate LMA. This attacker can cause the 171 MAG to conduct route update signaling with the attacker instead of 172 with the legitimate LMA, enabling it to ignore route updates from the 173 MAG, or forge route updates in order to redirect or deny a victim 174 mobile node's traffic. The attacker does not necessarily have to be 175 on the original control plane path between the legitimate LMA and the 176 MAG, provided that it can somehow make its presence known to the MAG. 177 E.g., the IP address of a mobility anchor point in hierarchical 178 Mobile IPv6 mobility management [4] may be proliferated across a 179 domain hop by hop in Router Advertisement messages. Failure to 180 properly authenticate a comparable mechanism for localized mobility 181 management would allow an attacker to establish itself as a rogue 182 LMA. 184 The attacker may further be able to intercept, inspect, modify, 185 redirect, or drop data plane traffic to and from a mobile node. This 186 is obvious if the attacker is on the original data plane path between 187 the legitimate LMA and the mobile node's current MAG, which may 188 happen independent of whether or not the attacker is on the original 189 control plane path. If the attacker is not on this path, it may be 190 able to leverage the localized mobility management protocol to 191 redefine the prefix that the mobile node uses in IP address 192 configuration. The attacker can then specify a prefix that routes to 193 itself. Whether or not outgoing data plane packets sourced by the 194 mobile node can be interfered with by an attacker off the original 195 data plane path depends on the specific data plane forwarding 196 mechanism within the localized mobility management domain. E.g., if 197 IP-in-IP encapsulation or an equivalent per-mobile-node approach is 198 used for outbound data plane packets, the packets will route through 199 the attacker. On the other hand, standard IP routing may cause the 200 packets to be relayed via the legitimate LMA and hence to circumvent 201 the attacker. 203 2.2 MAG Compromise or Impersonation 205 A compromised MAG can redirect a victim mobile node's traffic onto 206 its local access link arbitrarily, without authorization from the 207 mobile node. This threat is similar to an attack on a typical 208 routing protocol where a malicious stub router injects a bogus host 209 route for the mobile node. In general, forgery of a subnet prefix in 210 link state or distance vector routing protocols requires support of 211 multiple routers in order to obtain a meaningful change in forwarding 212 behavior. But a bogus host route is likely to take precedence over 213 the routing information advertised by legitimate routers, which is 214 usually less specific, hence the attack should succeed even if the 215 attacker is not supported by other routers. A difference between 216 redirection in a routing protocol and redirection in localized 217 mobility management is that the former impacts the routing tables of 218 multiple routers, whereas the latter involves only the compromised 219 MAG and an LMA. 221 Moreover, a compromised MAG can ignore the presence of a mobile node 222 on its local access link and refrain from registering the mobile node 223 at an LMA. The mobile node then loses its traffic. The compromised 224 MAG may further be able to cause interruption to a mobile node by 225 deregistering the mobile node at the LMA, pretending that the mobile 226 node has powered down. The mobile node then needs to reinitiate the 227 network access authentication procedure, which the compromised MAG 228 may prevent repeatedly until the mobile node moves to a different 229 MAG. The mobile node should be able to handle this situation, but 230 the recovery process may be lengthy and hence impair ongoing 231 communication sessions to a significant extent. 233 Attacks that the MAG can mount on its access link interface are 234 common for any regular IPv6 access router [3]. 236 Denial of service against an LMA is another threat of MAG subversion. 237 The compromised MAG can trick the LMA into believing that a high 238 number of mobile nodes have attached to the MAG. The LMA will then 239 establish a routing table entry for each of the non-existing mobile 240 nodes. The unexpected growth of the routing table may eventually 241 cause the LMA to reject legitimate route update requests. It may 242 also decrease the forwarding speed for data plane packets due to 243 higher route lookup latencies, and it may for the same reason slow 244 down the responsiveness to control plane packets. Another adverse 245 side effect of a high number of routing table entries is that the 246 LMA, and hence the localized mobility management domain as a whole, 247 becomes more susceptible to flooding packets from external attackers 248 (see Section 4). The high number of superfluous routes increases the 249 probability that a flooding packet, sent to a random IP address 250 within the localized mobility management domain, matches an existing 251 routing table entry at the LMA and gets tunneled to a MAG, which in 252 turn performs address resolution [5] on the local access link. At 253 the same time, fewer flooding packets can be dropped directly at the 254 LMA due to a nonexistent routing table entry. 256 All of these threats apply not just to a MAG that is compromised, but 257 also to an attacker that manages to counterfeit the identity of an 258 authorized MAG in interacting with both mobile nodes and an LMA. 259 Such an attacker can behave towards mobile nodes like a legitimate 260 MAG and engage an LMA in route update signaling. In a related 261 attack, the perpetrator eavesdrops on signaling packets exchanged 262 between an authorized MAG and an LMA and replays these packets at a 263 later time. These attacks may be conducted transiently, to 264 selectively disable traffic for any particular mobile node at 265 particular times. 267 2.3 Man in the Middle Attack 269 An attacker that manages to interject itself between a legitimate LMA 270 and a legitimate MAG can act as a man in the middle with respect to 271 both control plane signaling and data plane traffic. If the attacker 272 is on the original control plane path, it can forge, modify, or drop 273 route update packets so as to cause the establishment of incorrect 274 routes or the removal of routes that are in active use. Similarly, 275 an attacker on the original data plane path can intercept, inspect, 276 modify, redirect, and drop data plane packets sourced by or destined 277 to a victim mobile node. 279 A compromised router located between an LMA and a MAG may cause 280 similar damage. Any router on the control plane path can forge, 281 modify, or drop control plane packets, and thereby interfere with 282 route establishment. Any router on the data plane path can 283 intercept, inspect, modify, and drop data plane packets, or rewrite 284 IP headers so as to divert the packets from their original path. 286 An attacker between an LMA and a MAG may further impersonate the MAG 287 towards the LMA and vice versa in route update signaling. The 288 attacker can so interfere with route establishment even if it is not 289 on the original control plane path between the LMA and the MAG. An 290 attacker off the original data plane path may undertake the same to 291 cause inbound data plane packets destined to the mobile node to be 292 routed first from the LMA to the attacker, and from there to the 293 mobile node's MAG and finally to the mobile node itself. As 294 explained in Section 2.1, here, too, it depends on the specific data 295 plane forwarding mechanism within the localized mobility management 296 domain whether or not the attacker can influence the route of 297 outgoing data plane packets sourced by the mobile node. 299 3. Threats to Interface between MAG and Mobile Node 301 A MAG monitors the mobile nodes' link-layer handoff signaling or IP- 302 layer movement detection signaling in order to detect the arrival and 303 departure of mobile nodes and accordingly initiate route updates with 304 the LMA. Cellular access technologies utilize only the signaling at 305 the wireless link layer, and the IP stack never sees any change when 306 the mobile node moves from one MAG to a MAG on a different link. For 307 non-cellular access technologies, such as IEEE 802.11 or wired 308 Ethernet, the link-layer signaling may not hide a handoff from the IP 309 layer. Instead, IP-layer movement detection signaling may have to be 310 performed in response to a notification from the link layer that a 311 change in link-layer attachment has occurred. This signaling may 312 involve extensions [6] for IPv6 Neighbor Discovery [5], DHCPv6 [7], 313 or additional technology-specific functionality at the IP layer. 315 Although the mobile node identity is conceptually independent of the 316 mobile node's IP or link-layer addresses in either case, it must be 317 securely bound to whatever handoff signaling of the mobile node is 318 decisive for route updates on the MAG-LMA interface, be it via an 319 address or otherwise. A MAG uses this binding to deduce when the 320 mobile node has handed over onto the MAG's local access link, and 321 possibly when the mobile node leaves the local access link again, 322 thereby providing the trigger for route update signaling to an LMA. 323 The binding must be robust to spoofing because it would otherwise 324 facilitate impersonation of the mobile node by a third party, denial 325 of service, or man-in-the-middle attacks. 327 3.1 Mobile Node Compromise or Impersonation 329 An attacker that is able to forge the mobile node identity of a 330 neighboring victim mobile node may be able to trick its MAG into 331 redirecting the mobile node's packets to itself. Such an on-link 332 attack is common for any regular IPv6 network [3]. However, if 333 handoff signaling cannot definitively and unambiguously be linked 334 back to the legitimate mobile node identity, an attacker may further 335 be capable of fabricating handoff signaling of a victim mobile node 336 that currently attaches to a different link. The attacker can thus 337 trick its MAG into believing that the mobile node has handed over 338 onto the MAG's access link. The MAG will then initiate route update 339 signaling to an LMA, causing the LMA to redirect inbound data plane 340 packets for the mobile node to the attacker's MAG and finally to the 341 attacker itself. The attacker can so examine the packets that 342 legitimately belong to the mobile node, or discard the packets in 343 order to deny the mobile node service. The same can happen if a MAG 344 accepts from the attacker replayed handoff signaling packets which 345 the attacker has previously recorded from the legitimate mobile node. 347 The above attack is conceivable both if the attacker and the mobile 348 node are on links that connect to different MAGs, as well as if they 349 are on separate links connecting to the same MAG. In the former 350 case, two MAGs would think they see the mobile node and both would 351 independently perform route update signaling with the LMA. In the 352 latter case, route update signaling is likely to be performed only 353 once, and the redirection of packets from the mobile node to the 354 attacker is internal to the MAG. The mobile node can always 355 recapture its traffic back from the attacker through another run of 356 handoff signaling. But standard mobile nodes are generally not 357 prepared to counteract this kind of attack, and even where network 358 stacks include suitable functionality, the attack may not be 359 noticeable early enough at the link or IP layer to quickly institute 360 countermeasures. The attack is therefore disruptive at a minimum, 361 and may potentially persist until the mobile node initiates signaling 362 again upon a subsequent handoff. 364 Off-link impersonation attacks can be prevented at the link layer. 365 E.g., they are not possible with cellular access technologies, where 366 the handoff signaling is completely controlled by the wireless link 367 layer. Here, an attacker must be on the same link as the victim 368 mobile node in order to disrupt the negotiation between the mobile 369 node and the network. Cellular access technologies also provide 370 other cryptographic and non-cryptographic attack barriers at the link 371 layer, which make mounting an impersonation attack, both on-link and 372 off-link, very difficult. For non-cellular access technologies, 373 however, off-link impersonation attacks may be possible. 375 An attacker which can forge handoff signaling messages may also cause 376 denial of service against the localized mobility management domain. 377 The attacker can trick a MAG into believing that a large number of 378 mobile nodes have attached to the local access link and thus induce 379 it to initiate route update signaling with an LMA for each mobile 380 node assumed on link. The result of such an attack is both 381 superfluous signaling overhead on the control plane as well as a high 382 number of needless entries in the LMA's and MAG's routing tables. 383 The unexpected growth of the routing tables may eventually cause the 384 LMA to reject legitimate route update requests, and it may cause the 385 MAG to ignore handoffs of legitimate mobile nodes on its local access 386 link. It may also decrease the LMA's and MAG's forwarding speed for 387 inbound and outbound data plane packets due to higher route lookup 388 latencies, and it may for the same reason slow down their 389 responsiveness to control plane packets. An adverse side effect of 390 this attack is that the LMA, and hence the localized mobility 391 management domain as a whole, becomes more susceptible to flooding 392 packets from external attackers (see Section 4). The high number of 393 superfluous routes increases the probability that a flooding packet, 394 sent to a random IP address within the localized mobility management 395 domain, matches an existing routing table entry at the LMA and gets 396 tunneled to a MAG, which in turn performs address resolution [5] on 397 the local access link. At the same time, fewer flooding packets can 398 be dropped directly at the LMA due to a nonexistent routing table 399 entry. 401 A threat related to the ones identified above, but not limited to 402 handoff signaling, is IP spoofing [8][9]. Attackers use IP spoofing 403 mostly for reflection attacks or to hide their identities. The 404 threat can be reasonably contained by a wide deployment of network 405 ingress filtering [10] in access network routers. This technique 406 prevents IP spoofing to the extent that it ensures topological 407 correctness of IP source address prefixes in to-be-forwarded packets. 408 Where the technique is deployed in an access router, packets are 409 forwarded only if the prefix of their IP source address is valid on 410 the router's local access link. An attacker can still use a false 411 interface identifier in combination with an on-link prefix. But 412 since reflection attacks typically aim at off-link targets, and the 413 enforcement of topologically correct IP address prefixes also limits 414 the effectiveness of identity concealment, network ingress filtering 415 has proven adequate so far. On the other hand, prefixes are not 416 limited to a specific link in a localized mobility management domain, 417 so an attacker may be able to send packets with an off-link IP source 418 address despite the presence of network ingress filtering. This 419 could make IP spoofing again more attractive. 421 3.2 Man in the Middle Attack 423 An attacker which can interpose between a victim mobile node and a 424 MAG during handoff signaling, router discovery, and IP address 425 configuration can mount a man-in-the-middle attack on the mobile 426 node, spoofing the mobile node into believing that it has a 427 legitimate connection with the localized mobility management domain. 428 The attacker can thus intercept, inspect, modify, or selectively drop 429 packets sourced by or destined to the mobile node. 431 4. Threats from the Internet 433 A localized mobility management domain uses host routes for data 434 plane traffic and hence deviates from the standard IPv6 longest- 435 prefix-match routing. Creation, maintenance, and deletion of tese 436 host routes in addition cause control traffic within the localized 437 mobility management domain. These characteristics are transparent to 438 mobile nodes as well as external correspondent nodes, but the 439 functional differences within the domain may influence the impact 440 that a denial-of-service attack from the outside world can have on 441 the domain. 443 A denial-of-service attack on an LMA may be launched by sending 444 packets to arbitrary IP addresses which are potentially in use by 445 mobile nodes within the localized mobility management domain. Like a 446 border router, the LMA is in a topological position through which a 447 substantial amount of data plane traffic goes, so it must process the 448 flooding packets and perform a routing table lookup for each of them. 449 The LMA can discard packets for which the IP destination address is 450 not registered in its routing table. But other packets must be 451 encapsulated and forwarded. A target MAG as well as any mobile nodes 452 attached to the MAG's local access link are also likely to suffer 453 damage because the unrequested packets must be decapsulated and 454 consume link bandwidth as well as processing capacities on the 455 receivers. This threat is in principle the same as for denial of 456 service on a regular IPv6 border router, but because either the 457 routing table lookup enables the LMA to drop a flooding packet early 458 on or, on the contrary, additional tunneling workload is required, 459 the impact of an attack against localized mobility management may be 460 different. 462 In a related attack, the villain manages to obtain a globally 463 routable IP address of an LMA or a different network entity within 464 the localized mobility management domain and perpetrates a denial-of- 465 service attack against that IP address. Localized mobility 466 management is in general somewhat resistant to such an attack because 467 mobile nodes need never obtain a globally routable IP address of any 468 entity within the localized mobility management domain. A 469 compromised mobile node hence cannot pass such an IP address off to a 470 remote attacker, limiting the feasibility of extracting information 471 on the topology of the localized mobility management domain. It is 472 still possible for an attacker to perform IP address scanning if MAGs 473 and LMAs have globally routable IP addresses, but the much larger 474 IPv6 address space makes scanning considerably more time consuming. 476 5. Security Considerations 478 This document describes threats to network-based localized mobility 479 management. These may either occur on the interface between an LMA 480 and a MAG, or on the interface between a MAG and a mobile node. 481 Mitigation measures for the threats, as well as the security 482 considerations associated with those measures, are described in the 483 respective protocol specifications [11][12] for the two interfaces. 485 6. IANA Considerations 487 This document has no actions for IANA. 489 7. Acknowledgment 491 The authors would like to thank the NETLMM working group, especially 492 Jari Arkko, Gregory Daley, Vijay Devarapalli, Lakshminath Dondeti, 493 Gerardo Giaretta, Wassim Haddad, Andy, Huang, Dirk von Hugo, Julien 494 Laganier, Henrik Levkowetz, Vidya Narayanan, Phil Roberts, and Pekka 495 Savola (in alphabetical order) for valuable comments and suggestions 496 regarding this document. 498 8. References 500 8.1 Normative References 502 [1] Kempf, J., "Problem Statement for Network-based Localized 503 Mobility Management", IETF Internet Draft 504 draft-ietf-netlmm-nohost-ps-04.txt (work in progress), 505 June 2006. 507 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", 508 IETF Request for Comments 3753, June 2004. 510 8.2 Informative References 512 [3] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 513 Discovery (ND) Trust Models and Threats", IETF Request for 514 Comments 3756, May 2004. 516 [4] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, 517 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 518 IETF Request for Comments 4140, August 2005. 520 [5] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 521 IETF Internet Draft draft-ietf-ipv6-2461bis-07.txt (work in 522 progress), May 2006. 524 [6] Kempf, J., Narayanan, S., Nordmark, E., Pentland, B., and JH. 525 Choi, "Detecting Network Attachment in IPv6 Networks (DNAv6)", 526 IETF Internet Draft draft-ietf-dna-protocol-01.txt (work in 527 progress), June 2006. 529 [7] Droms, R., Bound, J., Volz, B., Lemon, T., E., C., and M. 530 Carney, "Dynamic Host Configuration Protocol for IPv6 531 (DHCPv6)", IETF Request for Comments 3315, July 2003. 533 [8] CERT Coordination Center, "CERT Advisory CA-1996-21 TCP SYN 534 Flooding and IP Spoofing Attacks", September 1996. 536 [9] CERT Coordination Center, "CERT Advisory CA-1998-01 Smurf IP 537 Denial-of-Service Attacks", January 1998. 539 [10] Ferguson, P. and D. Senie, "Network Ingress Filtering: 540 Defeating Denial of Service Attacks which employ IP Source 541 Address Spoofing", IETF Request for Comments 2827, May 2000. 543 [11] Giaretta, G., "NetLMM Protocol", IETF Internet Draft 544 draft-giaretta-netlmm-dt-protocol-00.txt (work in progress), 545 June 2006. 547 [12] Laganier, J., Narayanan, S., and F. Templin, "Network-based 548 Localized Mobility Management Interface between Mobile Node and 549 Access Router", IETF Internet Draft 550 draft-ietf-netlmm-mn-ar-if-01.txt (work in progress), 551 June 2006. 553 [13] Aura, T., "Cryptographically Generated Addresses (CGA)", 554 IETF Request for Comments 3972, March 2005. 556 [14] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 557 Access Identifier", IETF Request for Comments 4282, 558 December 2005. 560 Authors' Addresses 562 Christian Vogt 563 Institute of Telematics 564 Universitaet Karlsruhe (TH) 565 P.O. Box 6980 566 76128 Karlsruhe 567 Germany 569 Email: chvogt@tm.uka.de 571 James Kempf 572 DoCoMo USA Labs 573 181 Metro Drive, Suite 300 574 San Jose, CA 95110 575 USA 577 Phone: +1 408 451 4711 578 Email: kempf@docomolabs-usa.com 580 Appendix A. Change Log 582 The following is a list of technical changes that were made from 583 version 02 to version 03 of the document. Editorial revisions are 584 not explicitly mentioned. 586 o Changed the terminology from "network access identity" to "mobile 587 node identity" as the previous term was frequently confused with 588 the different "network access identifier" (NAI). Removed the 589 special "Network Access Identity" subsection in Section 3. The 590 mobile node identity is now first mentioned in Section 1, which 591 fits well with the nutshell description of the NETLMM 592 architecture. The security requirements of the mobile node 593 identifier are discussed in the introductory text of Section 3. 594 This makes more sense than a special subsection because the text, 595 on one hand, provides the necessary basis to understand the 596 following subsections, while on the other hand, it does not really 597 explain an attack itself. 599 o Section 1: Extended the description of conceptual actors in the 600 localized mobility management architecture and added a summary of 601 potential attack objectives and attack targets. 603 o Section 3.1: Granularity of ingress filtering may be coarser in a 604 localized mobility mangement domain. It may also allow off-link 605 IP spoofing since prefixes are not limited to a specific link. 607 o Section 2.2: The threat of replay attacks was not mentioned in 608 this section. It was added. 610 o Section 3.1: The threat of replay attacks was not mentioned in 611 this section. It was added. 613 o Section 2.2: Causing spurious route updates may lead to DoS 614 against the localized mobility management domain. This threat was 615 missing in the discussion of this section and it was added. 617 o Section 3.1: Causing spurious route updates may lead to DoS 618 against the localized mobility management domain. This threat was 619 missing in the discussion of this section and it was added. 621 o Section 4: Moved DoS attack against a localized mobility 622 management domain from the Internet to a separate section because 623 it is not specific to either interface within the domain. 625 o Revised the document with respect to the recent agreement the 626 addressing model. 628 o Revised the document with respect to the the possibility that 629 there may be more than one LMA. The text was initially written 630 under the assumption that the LMA is unique. 632 o References split into normative and informative references. 634 The following is a list of technical changes that were made from 635 version 01 to version 02 of the document. Editorial revisions are 636 not explicitly mentioned. 638 o Section 2.1: Included DoS/flooding attack against MAG. Also 639 clarified how a malicious node off the control plane path between 640 the authorized LMA and one or multiple target MAGs could 641 impersonate the authorized LMA against the MAGs. Such an attacker 642 could use various means to interfere with data plane traffic even 643 if it is off the original data plane path between the legitimate 644 LMA and the MAGs. 646 o Section 2.2: Malicious MAG may deregister an actively 647 communicating mobile node, without consent of the mobile node. 649 o Section 2.3: Included related threats pertaining to MITM between 650 LMA and MAG, which were formerly described in other sections. 652 o Section 4: Included description of DoS/flooding attack against 653 LMA, including its impact on the target MAGs, their links, and the 654 target mobile nodes. 656 o Section 3: Revised the structure of this section. Threats are 657 now divided into attacks against a mobile node's network access 658 identity; impersonation of a mobile node, both from the mobile 659 node's link and from off link; as well as man-in-the-middle 660 attacks. 662 o Section 1: The binding with the network access identity may be 663 with the authentication keys associated with the mobile node's IP 664 address, not necessarily with the IP addresses themselves. 666 o Section 3.1: Off-link attack may be mounted from a link that 667 connects to a different MAG than the victim mobile node's MAG. 669 Intellectual Property Statement 671 The IETF takes no position regarding the validity or scope of any 672 Intellectual Property Rights or other rights that might be claimed to 673 pertain to the implementation or use of the technology described in 674 this document or the extent to which any license under such rights 675 might or might not be available; nor does it represent that it has 676 made any independent effort to identify any such rights. Information 677 on the procedures with respect to rights in RFC documents can be 678 found in BCP 78 and BCP 79. 680 Copies of IPR disclosures made to the IETF Secretariat and any 681 assurances of licenses to be made available, or the result of an 682 attempt made to obtain a general license or permission for the use of 683 such proprietary rights by implementers or users of this 684 specification can be obtained from the IETF on-line IPR repository at 685 http://www.ietf.org/ipr. 687 The IETF invites any interested party to bring to its attention any 688 copyrights, patents or patent applications, or other proprietary 689 rights that may cover technology that may be required to implement 690 this standard. Please address the information to the IETF at 691 ietf-ipr@ietf.org. 693 The IETF has been notified of intellectual property rights claimed in 694 regard to some or all of the specification contained in this 695 document. For more information consult the online list of claimed 696 rights. 698 Disclaimer of Validity 700 This document and the information contained herein are provided on an 701 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 702 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 703 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 704 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 705 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 706 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 708 Copyright Statement 710 Copyright (C) The Internet Society (2006). This document is subject 711 to the rights, licenses and restrictions contained in BCP 78, and 712 except as set forth therein, the authors retain all their rights. 714 Acknowledgment 716 Funding for the RFC Editor function is currently provided by the 717 Internet Society.