idnits 2.17.1 draft-ietf-netlmm-threats-04.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 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 670. ** 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 (September 12, 2006) is 6429 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) == 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') == 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 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: March 16, 2007 J. Kempf 5 DoCoMo USA Labs 6 September 12, 2006 8 Security Threats to Network-Based Localized Mobility Management 9 draft-ietf-netlmm-threats-04.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 March 16, 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 a localized mobility anchor and a mobile access 45 gateway, as well as the interface between a mobile access gateway and 46 a mobile node. Threats to the former interface impact the localized 47 mobility management protocol itself. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Threats to Interface between LMA and MAG . . . . . . . . . . . 4 54 2.1 LMA Compromise or Impersonation . . . . . . . . . . . . . 4 55 2.2 MAG Compromise or Impersonation . . . . . . . . . . . . . 5 56 2.3 Man in the Middle Attack . . . . . . . . . . . . . . . . . 7 57 3. Threats to Interface between MAG and Mobile Node . . . . . . . 7 58 3.1 Mobile Node Compromise or Impersonation . . . . . . . . . 8 59 3.2 Man in the Middle Attack . . . . . . . . . . . . . . . . . 10 60 4. Threats from the Internet . . . . . . . . . . . . . . . . . . 10 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 66 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 68 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 Intellectual Property and Copyright Statements . . . . . . . . 16 71 1. Introduction 73 The network-based localized mobility management (NETLMM) architecture 74 [1] supports movement of IPv6 mobile nodes locally within a domain 75 without requiring mobility support in the mobile nodes' network 76 stacks. A mobile node can keep its IP address constant as it moves 77 from link to link, avoiding the signaling overhead and latency 78 associated with changing the IP address. Software specifically for 79 localized mobility management is not required on the mobile node, 80 whereas IP-layer movement detection software may be necessary, and 81 driver software for link-layer mobility is prerequisite. 83 The IP addresses of mobile nodes have a prefix that routes to a 84 localized mobility anchor (LMA) [3]. The LMA maintains an individual 85 route for each registered mobile node. Any particular mobile node's 86 route terminates at a mobile access gateway (MAG) [3], to which the 87 mobile node attaches at its current access link. MAGs are 88 responsible for updating the mobile node's route on the LMA as the 89 mobile node moves. A MAG detects the arrival of a mobile node on its 90 local access link based on handoff signaling that the mobile node 91 pursues. The MAG may additionally monitor connectivity of the mobile 92 node in order to recognize when the mobile node has left the local 93 access link. The localized mobility management architecture 94 therefore has two interfaces: 96 1. The interface between a MAG and an LMA where route update 97 signaling occurs. 99 2. The interface between a mobile node and its current MAG where 100 handoff signaling and other link maintenance signaling occurs. 102 The localized mobility management architecture demands no specific 103 protocol for a MAG to detect the arrival or departure of mobile nodes 104 to and from its local access link and accordingly initiate route 105 update signaling with an LMA. An appropriate mechanism may be 106 entirely implemented at the link layer, such as is common for 107 cellular networks. In that case, the IP layer never detects any 108 movement, even when a mobile node moves from one link to another 109 handled by a different MAG. If the link layer does not provide the 110 necessary functionality, the mobile node must perform IP-layer 111 movement detection and auto-configuration signaling, thereby 112 providing the trigger for the MAG to update its route at the LMA. A 113 mobile node identity, established by the localized mobility 114 management domain when the mobile node initially connects and 115 authenticates, enables the MAG to ascribe the decisive link- or IP- 116 layer signaling to the correct mobile node. Some wireless access 117 technologies may require the mobile node identity to be re- 118 established on every link-layer handoff. 120 Vulnerabilities in either interface of the localized mobility 121 management architecture may entail new security threats which go 122 beyond those that already exist in IPv6. This document identifies 123 and discusses security threats on both interfaces of the localized 124 mobility management architecture. It is limited to threats which are 125 peculiar to localized mobility management; threats to IPv6 in general 126 are documented in [4]. 128 1.1 Terminology 130 The terminology in this document follows the definitions in [2], with 131 those revisions and additions from [1]. In addition, the following 132 definition is used: 134 Mobile Node Identity 136 An identity established for the mobile node when initially 137 connecting to the domain. It allows the localized mobility 138 management domain to definitively and unambiguously identify the 139 mobile node upon handoff for route update signaling purposes. The 140 mobile node identity is conceptually independent of the mobile 141 node's IP or link-layer addresses, but it must be securely bound 142 to the mobile node's handoff signaling. 144 2. Threats to Interface between LMA and MAG 146 The localized mobility management protocol executed on the interface 147 between an LMA and a MAG serves to establish, update, and tear down 148 routes for data plane traffic of mobile nodes. Threats to this 149 interface can be separated into compromise or impersonation of a 150 legitimate LMA, compromise or impersonation of a legitimate MAG, and 151 man-in-the-middle attacks. 153 2.1 LMA Compromise or Impersonation 155 A compromised LMA can ignore route updates from a legitimate MAG in 156 order to deny service to a mobile node. It may also be able to trick 157 a legitimate MAG into creating a new, incorrect route, thereby 158 preparing the MAG to receive redirected traffic of a mobile node; it 159 may cause the traffic forwarded by a MAG to be redirected to a 160 different LMA; or it may simply have the MAG drop an existing route 161 in order to deny the mobile node service. Since data plane traffic 162 for mobile nodes routes through the LMA, a compromised LMA can also 163 intercept, inspect, modify, or drop such traffic, or redirect it to a 164 destination in collusion with the attacker. The attack can be 165 conducted transiently, to selectively disable traffic for any 166 particular mobile node or MAG at particular times. 168 Moreover, a compromised LMA may manipulate its routing table such 169 that all packets are directed towards a single MAG. This may result 170 in a DoS attack against that MAG and its attached access link. 172 These threats also emanate from an attacker which tricks a MAG into 173 believing that it is a legitimate LMA. This attacker can cause the 174 MAG to conduct route update signaling with the attacker instead of 175 with the legitimate LMA, enabling it to ignore route updates from the 176 MAG, or induce incorrect route changes at the MAG as described above, 177 in order to redirect or deny a mobile node's traffic. The attacker 178 does not necessarily have to be on the original control plane path 179 between the legitimate LMA and the MAG, provided that it can somehow 180 make its presence known to the MAG. Failure to mutually authenticate 181 when establishing an association between an LMA and a MAG would allow 182 an attacker to establish itself as a rogue LMA. 184 The attacker may further be able to intercept, inspect, modify, drop, 185 or redirect data plane traffic to and from a mobile node. This is 186 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 independently of whether 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 approach is used for outbound 198 data plane packets, the packets can be forced to be routed through 199 the attacker. On the other hand, standard IP routing may cause the 200 packets to be relayed via a legitimate LMA and hence to circumvent 201 the attacker. 203 2.2 MAG Compromise or Impersonation 205 A compromised MAG can redirect a mobile node's traffic onto its local 206 access link arbitrarily, without authorization from the mobile node. 207 This threat is similar to an attack on a typical routing protocol 208 where a malicious stub router injects a bogus host route for the 209 mobile node. In general, forgery of a subnet prefix in link state or 210 distance vector routing protocols requires support of multiple 211 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 serving LMA, pretending that the 226 mobile node has powered down. The mobile node then needs to re- 227 initiate the network access authentication procedure, which the 228 compromised MAG may prevent repeatedly until the mobile node moves to 229 a different MAG. The mobile node should be able to handle this 230 situation, but the recovery process may be lengthy and hence impair 231 ongoing communication sessions to a significant extent. 233 Denial of service against an LMA is another threat of MAG subversion. 234 The compromised MAG can trick an LMA into believing that a high 235 number of mobile nodes have attached to the MAG. The LMA will then 236 establish a routing table entry for each of the non-existing mobile 237 nodes. The unexpected growth of the routing table may eventually 238 cause the LMA to reject legitimate route update requests. It may 239 also decrease the forwarding speed for data plane packets due to 240 higher route lookup latencies, and it may for the same reason slow 241 down the responsiveness to control plane packets. Another adverse 242 side effect of a high number of routing table entries is that the 243 LMA, and hence the localized mobility management domain as a whole, 244 becomes more susceptible to flooding packets from external attackers 245 (see Section 4). The high number of superfluous routes increases the 246 probability that a flooding packet, sent to a random IP address 247 within the localized mobility management domain, matches an existing 248 routing table entry at the LMA and gets tunneled to a MAG, which in 249 turn performs address resolution on the local access link. At the 250 same time, fewer flooding packets can be dropped directly at the LMA 251 on the basis of a nonexistent routing table entry. 253 All of these threats apply not just to a MAG that is compromised, but 254 also to an attacker that manages to counterfeit the identity of a 255 legitimate MAG in interacting with both mobile nodes and an LMA. 256 Such an attacker can behave towards mobile nodes like an authorized 257 MAG and engage an LMA in route update signaling. In a related 258 attack, the perpetrator eavesdrops on signaling packets exchanged 259 between a legitimate MAG and an LMA and replays these packets at a 260 later time. These attacks may be conducted transiently, to 261 selectively disable traffic for any particular mobile node at 262 particular times. 264 2.3 Man in the Middle Attack 266 An attacker that manages to interject itself between a legitimate LMA 267 and a legitimate MAG can act as a man in the middle with respect to 268 both control plane signaling and data plane traffic. If the attacker 269 is on the original control plane path, it can forge, modify, or drop 270 route update packets so as to cause the establishment of incorrect 271 routes or the removal of routes that are in active use. Similarly, 272 an attacker on the original data plane path can intercept, inspect, 273 modify, drop, and redirect data plane packets sourced by or destined 274 to a mobile node. 276 A compromised switch or router located between an LMA and a MAG can 277 cause similar damage. Any switch or router on the control plane path 278 can forge, modify, or drop control plane packets, and thereby 279 interfere with route establishment. Any switch or router on the data 280 plane path can intercept, inspect, modify, and drop data plane 281 packets, or rewrite IP headers so as to divert the packets from their 282 original path. 284 An attacker between an LMA and a MAG may further impersonate the MAG 285 towards the LMA and vice versa in route update signaling. The 286 attacker can so interfere with route establishment even if it is not 287 on the original control plane path between the LMA and the MAG. An 288 attacker off the original data plane path may undertake the same to 289 cause inbound data plane packets destined to the mobile node to be 290 routed first from the LMA to the attacker, and from there to the 291 mobile node's MAG and finally to the mobile node itself. As 292 explained in Section 2.1, here, too, it depends on the specific data 293 plane forwarding mechanism within the localized mobility management 294 domain whether or not the attacker can influence the route of 295 outgoing data plane packets sourced by the mobile node. 297 3. Threats to Interface between MAG and Mobile Node 299 A MAG monitors the arrival and departure of mobile nodes to and from 300 its local access link based on link- or IP-layer mechanisms. 301 Whatever signaling on the access link is thereby decisive must be 302 securely bound to the mobile node identity. A MAG uses this binding 303 to ascribe the signaling to the mobile node and accordingly initiate 304 route update signaling with an LMA. The binding must be robust to 305 spoofing because it would otherwise facilitate impersonation of the 306 mobile node by a third party, denial of service, or man-in-the-middle 307 attacks. 309 3.1 Mobile Node Compromise or Impersonation 311 An attacker that is able to forge the mobile node identity of a 312 mobile node can to trick a MAG into redirecting data plane packets 313 for the mobile node to the attacker. The attacker can launch such an 314 impersonation attack against a mobile node that resides on the same 315 link as the attacker, or against a mobile node on a different link. 316 If the attack is on-link, the redirection of packets from the mobile 317 node to the attacker is internal to the MAG, and it involves no route 318 update signaling between the MAG and an LMA. On-link attacks are 319 possible in a regular IPv6 network [4] that does not use Secure 320 Neighbor Discovery [5]. 322 Off-link impersonation requires the attacker to fabricate handoff 323 signaling of the mobile node and thus trick the MAG into believing 324 that the mobile node has handed over onto the MAG's access link. The 325 attack is conceivable both if the attacker and the mobile node are on 326 separate links that connect to different MAGs, as well as if they are 327 on separate, possibly virtual per-mobile-node links that connect to 328 the same MAG. In the former case, two MAGs would think they see the 329 mobile node and both would independently perform route update 330 signaling with the LMA. In the latter case, route update signaling 331 is likely to be performed only once, and the redirection of packets 332 from the mobile node to the attacker is internal to the MAG. The 333 mobile node can always recapture its traffic back from the attacker 334 through another run of handoff signaling. But standard mobile nodes 335 are generally not prepared to counteract this kind of attack, and 336 even where network stacks include suitable functionality, the attack 337 may not be noticeable early enough at the link or IP layer to quickly 338 institute countermeasures. The attack is therefore disruptive at a 339 minimum, and may potentially persist until the mobile node initiates 340 signaling again upon a subsequent handoff. 342 Impersonation attacks can be prevented at the link layer, 343 particularly with cellular technologies where the handoff signaling 344 between the mobile node and the network must be authenticated and is 345 completely controlled by the wireless link layer. Cellular access 346 technologies provide a variety of cryptographic and non-cryptographic 347 attack barriers at the link layer which make mouting an impersonation 348 attack, both on-link and off-link, very difficult. However, for non- 349 cellular technologies that do not require link layer authentication 350 and authorization during handoff, impersonation attacks may be 351 possible. 353 An attacker that can forge handoff signaling may also cause denial of 354 service against the localized mobility management domain. The 355 attacker can trick a MAG into believing that a large number of mobile 356 nodes have attached to the local access link and thus induce it to 357 initiate route update signaling with an LMA for each mobile node 358 assumed on link. The result of such an attack is both superfluous 359 signaling overhead on the control plane as well as a high number of 360 needless entries in the LMA's and MAG's routing tables. The 361 unexpected growth of the routing tables may eventually cause the LMA 362 to reject legitimate route update requests, and it may cause the MAG 363 to ignore handoffs of legitimate mobile nodes onto its local access 364 link. It may also decrease the LMA's and MAG's forwarding speed for 365 inbound and outbound data plane packets due to higher route lookup 366 latencies, and it may for the same reason slow down their 367 responsiveness to control plane packets. An adverse side effect of 368 this attack is that the LMA, and hence the localized mobility 369 management domain as a whole, becomes more susceptible to flooding 370 packets from external attackers (see Section 4). The high number of 371 superfluous routes increases the probability that a flooding packet, 372 sent to a random IP address within the localized mobility management 373 domain, matches an existing routing table entry at the LMA and gets 374 tunneled to a MAG, which in turn performs address resolution on the 375 local access link. At the same time, fewer flooding packets can be 376 dropped directly at the LMA on the basis of a nonexistent routing 377 table entry. 379 A threat related to the ones identified above, but not limited to 380 handoff signaling, is IP spoofing [6]. Attackers use IP spoofing 381 mostly for reflection attacks or to hide their identities. The 382 threat can be reasonably contained by a wide deployment of network 383 ingress filtering [7] in routers, especially within access networks. 384 This technique prevents IP spoofing to the extent that it ensures 385 topological correctness of IP source address prefixes in to-be- 386 forwarded packets. Where the technique is deployed in an access 387 router, packets are forwarded only if the prefix of their IP source 388 address is valid on the router's local access link. An attacker can 389 still use a false interface identifier in combination with an on-link 390 prefix. But since reflection attacks typically aim at off-link 391 targets, and the enforcement of topologically correct IP address 392 prefixes also limits the effectiveness of identity concealment, 393 network ingress filtering has proven adequate so far. On the other 394 hand, prefixes are not limited to a specific link in a localized 395 mobility management domain, so merely ensuring topological 396 correctness through ingress filtering becomes insufficient. An 397 additional mechanism for IP address ownership verification is 398 necessary to prevent an attacker from sending packets with an off- 399 link IP source address. 401 3.2 Man in the Middle Attack 403 An attacker which can interpose between a mobile node and a MAG 404 during link- and/or IP-layer handoff signaling may be able to mount a 405 man-in-the-middle attack on the mobile node, spoofing the mobile node 406 into believing that it has a legitimate connection with the localized 407 mobility management domain. The attacker can thus intercept, 408 inspect, modify, or drop data plane packets sourced by or destined to 409 the mobile node. 411 4. Threats from the Internet 413 A localized mobility management domain uses individual host routes 414 for data plane traffic of different mobile nodes, each between an LMA 415 and a MAG. Creation, maintenance, and deletion of these routes cause 416 control traffic within the localized mobility management domain. 417 These characteristics are transparent to mobile nodes as well as 418 external correspondent nodes, but the functional differences within 419 the domain may influence the impact that a denial-of-service attack 420 from the outside world can have on the domain. 422 A denial-of-service attack on an LMA may be launched by sending 423 packets to arbitrary IP addresses that are potentially in use by 424 mobile nodes within the localized mobility management domain. Like a 425 border router, the LMA is in a topological position through which a 426 substantial amount of data plane traffic goes, so it must process the 427 flooding packets and perform a routing table lookup for each of them. 428 The LMA can discard packets for which the IP destination address is 429 not registered in its routing table. But other packets must be 430 encapsulated and forwarded. A target MAG as well as any mobile nodes 431 attached to that MAG's local access link are also likely to suffer 432 damage because the unrequested packets must be decapsulated and 433 consume link bandwidth as well as processing capacities on the 434 receivers. This threat is in principle the same as for denial of 435 service on a regular IPv6 border router, but because the routing 436 table lookups may enable the LMA to drop part of the flooding packets 437 early on or, on the contrary, additional tunneling workload is 438 required for packets that cannot be dropped, the impact of an attack 439 against localized mobility management may be different. 441 In a related attack, the attacker manages to obtain a globally 442 routable IP address of an LMA or a different network entity within 443 the localized mobility management domain and perpetrates a denial-of- 444 service attack against that IP address. Localized mobility 445 management is in general somewhat resistant to such an attack because 446 mobile nodes need never obtain a globally routable IP address of any 447 entity within the localized mobility management domain. A 448 compromised mobile node hence cannot pass such an IP address off to a 449 remote attacker, limiting the feasibility of extracting information 450 on the topology of the localized mobility management domain. It is 451 still possible for an attacker to perform IP address scanning if MAGs 452 and LMAs have globally routable IP addresses, but the much larger 453 IPv6 address space makes scanning considerably more time consuming. 455 5. Security Considerations 457 This document describes threats to network-based localized mobility 458 management. These may either occur on the interface between an LMA 459 and a MAG, or on the interface between a MAG and a mobile node. 460 Mitigation measures for the threats, as well as the security 461 considerations associated with those measures, are described in the 462 respective protocol specifications [3][8] for the two interfaces. 464 6. IANA Considerations 466 This document has no actions for IANA. 468 7. Acknowledgment 470 The authors would like to thank the NETLMM working group, especially 471 Jari Arkko, Gregory Daley, Vijay Devarapalli, Lakshminath Dondeti, 472 Gerardo Giaretta, Wassim Haddad, Andy, Huang, Dirk von Hugo, Julien 473 Laganier, Henrik Levkowetz, Vidya Narayanan, Phil Roberts, and Pekka 474 Savola (in alphabetical order) for valuable comments and suggestions 475 regarding this document. 477 8. References 479 8.1 Normative References 481 [1] Kempf, J., "Problem Statement for Network-based Localized 482 Mobility Management", IETF Internet Draft 483 draft-ietf-netlmm-nohost-ps-04.txt (work in progress), 484 June 2006. 486 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", 487 IETF Request for Comments 3753, June 2004. 489 8.2 Informative References 491 [3] Giaretta, G., "NetLMM Protocol", IETF Internet Draft 492 draft-giaretta-netlmm-dt-protocol-00.txt (work in progress), 493 June 2006. 495 [4] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 496 Discovery (ND) Trust Models and Threats", IETF Request for 497 Comments 3756, May 2004. 499 [5] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 500 Neighbor Discovery (SEND)", IETF Request for Comments 3971, 501 March 2005. 503 [6] CERT Coordination Center, "CERT Advisory CA-1996-21 TCP SYN 504 Flooding and IP Spoofing Attacks", September 1996. 506 [7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating 507 Denial of Service Attacks which employ IP Source Address 508 Spoofing", IETF Request for Comments 2827, May 2000. 510 [8] Laganier, J., Narayanan, S., and F. Templin, "Network-based 511 Localized Mobility Management Interface between Mobile Node and 512 Access Router", IETF Internet Draft 513 draft-ietf-netlmm-mn-ar-if-01.txt (work in progress), June 2006. 515 Authors' Addresses 517 Christian Vogt 518 Institute of Telematics 519 Universitaet Karlsruhe (TH) 520 P.O. Box 6980 521 76128 Karlsruhe 522 Germany 524 Email: chvogt@tm.uka.de 526 James Kempf 527 DoCoMo USA Labs 528 181 Metro Drive, Suite 300 529 San Jose, CA 95110 530 USA 532 Phone: +1 408 451 4711 533 Email: kempf@docomolabs-usa.com 535 Appendix A. Change Log 537 The following is a list of technical changes that were made from 538 version 03 to version 04 of the document. Editorial revisions are 539 not explicitly mentioned. 541 o Section 2.1: Clarified in first paragraph what it means for a 542 compromised LMA to "forge routing updates for a victim mobile 543 node" and what the intention behind such an attack could be. 545 o Section 2.1: Removed description of how MAP discovery works in 546 Hierarchical Mobile IPv6. 548 o Section 3: Introductory text shortened, because (i) it repeated 549 material from Section 1, and (ii) also described potential link- 550 layer technologies for access links, which was not within the 551 scope of this document. 553 o Section 3.1: Clarified how impersonation of a mobile node may 554 look like when the attacker attaches to the same MAG as the mobile 555 node, but to a different link. 557 o Section 3.1: Revised text on why cellular technologies can 558 prevent impersonation attacks against mobile nodes at the link 559 layer. 561 The following is a list of technical changes that were made from 562 version 02 to version 03 of the document. Editorial revisions are 563 not explicitly mentioned. 565 o Changed the terminology from "network access identity" to "mobile 566 node identity" as the previous term was frequently confused with 567 the different "network access identifier" (NAI). Removed the 568 special "Network Access Identity" subsection in Section 3. The 569 mobile node identity is now first mentioned in Section 1, which 570 fits well with the nutshell description of the NETLMM 571 architecture. The security requirements of the mobile node 572 identifier are discussed in the introductory text of Section 3. 573 This makes more sense than a special subsection because the text, 574 on one hand, provides the necessary basis to understand the 575 following subsections, while on the other hand, it does not really 576 explain an attack itself. 578 o Section 1: Extended the description of conceptual actors in the 579 localized mobility management architecture and added a summary of 580 potential attack objectives and attack targets. 582 o Section 3.1: Granularity of ingress filtering may be coarser in a 583 localized mobility management domain. It may also allow off-link 584 IP spoofing since prefixes are not limited to a specific link. 586 o Section 2.2: The threat of replay attacks was not mentioned in 587 this section. It was added. 589 o Section 3.1: The threat of replay attacks was not mentioned in 590 this section. It was added. 592 o Section 2.2: Causing spurious route updates may lead to DoS 593 against the localized mobility management domain. This threat was 594 missing in the discussion of this section and it was added. 596 o Section 3.1: Causing spurious route updates may lead to DoS 597 against the localized mobility management domain. This threat was 598 missing in the discussion of this section and it was added. 600 o Section 4: Moved DoS attack against a localized mobility 601 management domain from the Internet to a separate section because 602 it is not specific to either interface within the domain. 604 o Revised the document with respect to the recent agreement the 605 addressing model. 607 o Revised the document with respect to the the possibility that 608 there may be more than one LMA. The text was initially written 609 under the assumption that the LMA is unique. 611 o References split into normative and informative references. 613 The following is a list of technical changes that were made from 614 version 01 to version 02 of the document. Editorial revisions are 615 not explicitly mentioned. 617 o Section 2.1: Included DoS/flooding attack against MAG. Also 618 clarified how a malicious node off the control plane path between 619 the authorized LMA and one or multiple target MAGs could 620 impersonate the authorized LMA against the MAGs. Such an attacker 621 could use various means to interfere with data plane traffic even 622 if it is off the original data plane path between the legitimate 623 LMA and the MAGs. 625 o Section 2.2: Malicious MAG may deregister an actively 626 communicating mobile node, without consent of the mobile node. 628 o Section 2.3: Included related threats pertaining to MITM between 629 LMA and MAG, which were formerly described in other sections. 631 o Section 4: Included description of DoS/flooding attack against 632 LMA, including its impact on the target MAGs, their links, and the 633 target mobile nodes. 635 o Section 3: Revised the structure of this section. Threats are 636 now divided into attacks against a mobile node's network access 637 identity; impersonation of a mobile node, both from the mobile 638 node's link and from off link; as well as man-in-the-middle 639 attacks. 641 o Section 1: The binding with the network access identity may be 642 with the authentication keys associated with the mobile node's IP 643 address, not necessarily with the IP addresses themselves. 645 o Section 3.1: Off-link attack may be mounted from a link that 646 connects to a different MAG than the victim mobile node's MAG. 648 Intellectual Property Statement 650 The IETF takes no position regarding the validity or scope of any 651 Intellectual Property Rights or other rights that might be claimed to 652 pertain to the implementation or use of the technology described in 653 this document or the extent to which any license under such rights 654 might or might not be available; nor does it represent that it has 655 made any independent effort to identify any such rights. Information 656 on the procedures with respect to rights in RFC documents can be 657 found in BCP 78 and BCP 79. 659 Copies of IPR disclosures made to the IETF Secretariat and any 660 assurances of licenses to be made available, or the result of an 661 attempt made to obtain a general license or permission for the use of 662 such proprietary rights by implementers or users of this 663 specification can be obtained from the IETF on-line IPR repository at 664 http://www.ietf.org/ipr. 666 The IETF invites any interested party to bring to its attention any 667 copyrights, patents or patent applications, or other proprietary 668 rights that may cover technology that may be required to implement 669 this standard. Please address the information to the IETF at 670 ietf-ipr@ietf.org. 672 The IETF has been notified of intellectual property rights claimed in 673 regard to some or all of the specification contained in this 674 document. For more information consult the online list of claimed 675 rights. 677 Disclaimer of Validity 679 This document and the information contained herein are provided on an 680 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 681 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 682 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 683 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 684 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 685 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 687 Copyright Statement 689 Copyright (C) The Internet Society (2006). This document is subject 690 to the rights, licenses and restrictions contained in BCP 78, and 691 except as set forth therein, the authors retain all their rights. 693 Acknowledgment 695 Funding for the RFC Editor function is currently provided by the 696 Internet Society.