idnits 2.17.1 draft-ietf-netlmm-threats-01.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 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 412. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 329 has weird spacing: '...le Node and A...' -- 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 (June 23, 2006) is 6516 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: '10' is defined on line 361, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 365, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-netlmm-nohost-ps-01 == Outdated reference: A later version (-03) exists of draft-ietf-netlmm-mn-ar-if-00 == Outdated reference: A later version (-05) exists of draft-ietf-netlmm-nohost-req-01 -- Obsolete informational reference (is this intentional?): RFC 4282 (ref. '6') (Obsoleted by RFC 7542) == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-00 == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-00 -- Duplicate reference: draft-ietf-dna-protocol, mentioned in '9', was also mentioned in '8'. Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 9 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: December 25, 2006 J. Kempf 5 DoCoMo USA Labs 6 June 23, 2006 8 Security Threats to Network-based Localized Mobility Management 9 draft-ietf-netlmm-threats-01.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 December 25, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document discusses security threats to NETLMM mobility 43 management. Threats to NETLMM occur on two interfaces: the access 44 router/localized mobility anchor interface and the access router/ 45 mobile node interface. Threats to the access router/localized 46 mobility anchor interface are threats to the NETLMM protocol itself. 47 This document discusses threats on these two interfaces. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Threats to the AR/LMA Interface . . . . . . . . . . . . . . . 4 54 2.1 Unauthorized AR . . . . . . . . . . . . . . . . . . . . . 4 55 2.2 Unauthorized LMA . . . . . . . . . . . . . . . . . . . . . 5 56 2.3 Man in the Middle Attack . . . . . . . . . . . . . . . . . 5 57 2.4 Denial of Service Attack on the LMA . . . . . . . . . . . 5 58 3. Threats to the MN-AR Interface . . . . . . . . . . . . . . . . 6 59 3.1 Mobile Node Identity . . . . . . . . . . . . . . . . . . . 6 60 3.2 Impersonation on Handover . . . . . . . . . . . . . . . . 7 61 3.3 Off-Link Attacks . . . . . . . . . . . . . . . . . . . . . 7 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Informative References . . . . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 66 Intellectual Property and Copyright Statements . . . . . . . . 11 68 1. Introduction 70 The NETLMM architecture supports movement of IPv6 mobile nodes within 71 a localized mobility management domain with no specialized support on 72 the mobile node for localized mobility management. In contrast to 73 architectures where there is no localized mobility management support 74 or where localized mobility management support is provided by a host- 75 based solution, in the NETLMM architecture, the mobile node is able 76 to keep its IP address constant within the localized mobility 77 management domain as it moves, avoiding the signaling overhead 78 required to change the address. Software specifically for localized 79 mobility management is not required on the mobile node, though 80 software for IP movement detection may be needed and, of course, 81 driver software for link-layer movement is always required. More on 82 the network-based localized mobility management architecture can be 83 found in [1]. 85 In the NETLMM architecture, a localized mobility anchor (LMA) 86 maintains routes for mobile nodes. Packets to and from mobile nodes 87 (MNs) on the last hop wireless links are routed through the LMA. 88 When a MN moves from one access router (AR) to another, the route for 89 the mobile node on the LMA is updated by the ARs. The NETLMM 90 architecture therefore has two interfaces: 92 1. The AR to LMA interface where route update signaling occurs. 94 2. The MN to AR interface where movement detection and IP handover 95 signaling occurs. 97 The NETLMM architecture specifies no standardized protocol on the 98 MN/AR interface. The network must be informed when a mobile node 99 having an IP address moves from one access router to another, but how 100 that occurs is not part of the NETLMM protocol. The mechanism can be 101 entirely implemented by the wireless link protocol, such as is common 102 for cellular networks. In that case, the IP layer never detects any 103 movement, even though the mobile node may be moving from one link to 104 another handled by a different access router. If the wireless link 105 protocol does not handle movement detection and IP handover, however, 106 support at the IP level is required. In that case, the mobile node 107 must perform IP signaling for active movement detection. The access 108 router uses this signaling to infer mobile node movement. More about 109 IP level movement detection and NETLMM can be found in the NETLMM 110 MN-AR interface document [2]. 112 The NETLMM protocol itself is defined on the AR/LMA interface, and is 113 specified in [3]. 115 This document discusses threats to security on the NETLMM interfaces. 117 The discussion in this document focuses only on NETLMM signaling 118 traffic, both for the NETLMM protocol itself and for signaling on the 119 MN/AR interface that signals mobile node movement to the network. 120 Details on how the threats are handled by the NETLMM protocol and the 121 IP MN/AR interface are discussed in [3] and [2] respectively. 123 1.1 Terminology 125 Mobility terminology in this document follows that in [4], with those 126 revisions and additions from [1] and [5]. In addition, the following 127 definition is used: 129 Network access identity 131 A identity established for the mobile node with the network during 132 network access authentication that allows the network to 133 unambiguously identify the mobile node for signaling purposes. 134 For example, a wireless link session key established by the 135 wireless link layer, the Network Access Identifier (NAI) [6], or 136 the SEND public key [7] may serve as the identifier associated 137 with the network access identity. 139 2. Threats to the AR/LMA Interface 141 In this section, threats to the AR/LMA interface are discussed. 142 Since the information propagated between the AR and LMA is routing 143 updates, the threats on this interface are similar to the threats 144 experienced by two routers exchanging routing information with a 145 routing protocol. One difference is that the AR and LMA need not be 146 separated by a single hop, whereas routing updates are usually 147 propagated by flooding, so two routers exchanging routing information 148 are usually separated by a single hop. 150 2.1 Unauthorized AR 152 An AR that is not authorized to propagate NETLMM routing updates can 153 result in serious damage to the security of a localized mobility 154 management domain. The AR can redirect traffic from MNs on the AR's 155 lst hop link arbitrarily, without authorization from the MN. The AR 156 can ignore routing updates from the LMA so that the victim MNs lose 157 their traffic. An unauthorized AR can also intercept, inspect, and 158 redirect data plane traffic for mobile nodes on its last hop 159 interface, but this threat is common for any last hop router. 161 Note that this threat applies not just to an AR that is compromised, 162 but also to an off-path attacker that manages to forge the identity 163 of an authorized AR, and thereby spoof the LMA into conducting NETLMM 164 protocol signaling as if the attacker were legitimate. Such an 165 attack could be conducted transiently, to selectively disable traffic 166 for particular mobile nodes at particular times. 168 2.2 Unauthorized LMA 170 An unauthorized LMA can ignore routing updates from legitimate ARs, 171 or forge routing updates for MNs in order to redirect or deny traffic 172 to victims. Since data plane traffic for mobile nodes routes through 173 the LMA, a rogue LMA can also intercept, inspect, and redirect data 174 plane traffic for mobile nodes on ARs supported by the LMA. A piece 175 of malware might further manipulate the LMA's routing table such that 176 all packets are directed towards a single AR, resulting in a DoS 177 attack against that AR and its attached link. Again, these are the 178 same threats experienced by any intermediate router in the network. 180 Note that these threats apply not just to a LMA that is compromised, 181 but also to an off-path attacker that manages to forge the identity 182 of an authorized LMA, and thereby spoof the ARs in a localized 183 mobility domain into conducting NETLMM protocol signaling as if the 184 attacker were legitimate. Such an attack could be conducted 185 transiently, to selectively disable traffic for particular mobile 186 nodes or ARs at particular times. 188 2.3 Man in the Middle Attack 190 An unauthorized intermediate router or other node that manages to 191 interject itself between the AR and LMA is in a position to 192 intercept, inspect, and redirect NETLMM protocol signaling traffic 193 between an authorized LMA and authorized ARs handling mobility 194 management for the localized mobility management domain. If the 195 attacker can masquerade as an AR to the LMA and as the LMA to the 196 ARs, it may be in a position to spoof both sides into believing that 197 they have a secure link. The attacker can then utilize the 198 information derived from the NETLMM protocol signaling for various 199 purposes. 201 2.4 Denial of Service Attack on the LMA 203 An attacker could launch a denial-of-service attack on the LMA by 204 sending packets to arbitrary IP addresses with a prefix from the 205 NETLMM domain. The LMA is in a topological position through which 206 all data-plane traffic goes, so it would have to process the flooding 207 packets and perform a routing table lookup for each of them. The LMA 208 could discard packets for which the destination IP address is not 209 registered in the routing table. But other packets would have to be 210 encapsulated and forwarded. There would also be some damage to the 211 target AR and its link. 213 In a related attack, the attacker manages to obtain a globally 214 routable IP address of an LMA or a different network entity within 215 the NETLMM domain, and perpetrates a DoS attack against that IP 216 address. In general, NETLMM-based mobility management is somewhat 217 more resistant to DoS attacks than host-based localized mobility 218 management because nodes within the domain need never obtain a 219 globally routable IP address of any entity within the NETLMM domain. 220 As a consequence, a compromised node cannot pass such an IP address 221 off to an attacker, limiting the ability of an unauthorized attacker 222 to extract information on the topology of the NETLMM domain. It is 223 still possible for an attacker to perform address scanning if ARs and 224 LMAs have globally routable IP addresses, or for a compromise to 225 happen in another way, but the much larger IPv6 address space makes 226 address scanning considerably more time consuming. 228 3. Threats to the MN-AR Interface 230 In order to detect IP level handovers of mobile nodes, NETLMM access 231 routers utilize handover signaling between the mobile node and the 232 access router. For cellular-type interfaces, such signaling occurs 233 at the wireless link layer, and the IP stack never sees any change 234 when the mobile node moves from one AR to an AR on a different link. 235 For non-cellular interfaces, such as 802.11 or wired Ethernet-type 236 interfaces, link layer signaling may not hide IP handover from the IP 237 stack. The IP stack may need to perform movement detection in 238 response to some kind of link layer hint that a change in access 239 point has occurred. This signaling may involve extensions of IPv6 240 Neighbor Discovery [8] or it may involve DHCP [9] or it may involve 241 some link-specific IP level mechanism. In any case, the security 242 threats to the handover signaling that triggers NETLMM routing 243 updates are the same, and are described in this section. 245 3.1 Mobile Node Identity 247 In order for NETLMM to be able to definitively identify a mobile node 248 upon handover, the mobile node must establish a network access 249 identity when it initially enters the network. For example, a mobile 250 node may initially authenticate itself to the NETLMM domain based on 251 its NAI and an AAA-based protocol. This identifier is conceptually 252 independent of the mobile node's IP or link-layer addresses. In some 253 wireless networks, the network access identity must be re-established 254 on every handover between access points. 256 NETLMM requires that the access network establish a binding between 257 the network access identity and the IP addresses that the mobile node 258 self-configures (if address auto-configuration is used) or that it is 259 assigned (if stateful address configuration is used). This binding 260 is used by the AR to definitively and unambiguously deduce that a 261 mobile node has handed over into the AR's last hop subnet, thereby 262 providing the trigger for NETLMM route update signaling to the LMA. 263 The binding between the initial mobile-node authentication and the 264 IPv6 addresses must be robust to spoofing, for it would otherwise 265 facilitate impersonation of the mobile node by a third party. 266 Lacking this binding, the following attacks are conceivable. 268 3.2 Impersonation on Handover 270 An attacker that is able to forge an MN's network access identity can 271 use this capability to fabricate handover signaling, thereby tricking 272 the AR into believing that the victim has handed over into the AR's 273 last hop subnet. The AR will then perform route update signaling 274 with the LMA, causing the LMA to redirect traffic to the attacker. 275 The attacker can utilize this capability to examine and discard 276 traffic that legitimately belongs to the MN, as a means of denying 277 the MN service or to snoop the MN's traffic. If the attacker can 278 interpose between the MN and the network during router discovery and 279 address configuration, the attacker can mount a man in the middle 280 attack on the MN, spoofing the MN into believing it has a legitimate 281 connection with the network. 283 3.3 Off-Link Attacks 285 Depending on the exact nature of the handover signaling, an 286 impersonation attack could be mounted from off link. Off-link 287 attacks are possible in cases where the NETLMM domain consists of 288 multiple access routers serving multiple last hop links. If the 289 security on network access identity establishment is weak, or the IP 290 level movement detection signaling is unprotected so that the network 291 cannot definitively link the signaling back to the legitimate mobile 292 node network access identity, then an attacker from another link 293 could spoof IP level movement detection signaling for a victim mobile 294 node and thereby steal the mobile node's traffic. 296 Off-link attacks can be prevented at the link-layer. E.g., they are 297 not possible with cellular-style protocols, where the handover 298 signaling is completely controlled by the wireless link layer, 299 because an attacker must be on the same link with the MN in order to 300 disrupt the negotiation with the network. Cellular-style protocols 301 also have other cryptographic and noncryptographic barriers to attack 302 at the link layer, which make mounting an impersonation attack, both 303 on-link and off-link, very difficult. For non-cellular-style 304 protocols, however, it may be possible for an off-link attacker to 305 mount an impersonation attack. 307 4. Security Considerations 309 The document describes threats to the NETLMM protocol [3] and to the 310 MN-AR interface functions necessary to support network-based mobility 311 management [2]. Mitigation measures for these threats, and the 312 security considerations associated with those measures, are described 313 in the respective drafts that discuss the NETLMM protocol and the 314 MN-AR interface. 316 5. Acknowledgment 318 The authors would like to thank Gregory Daley, Gerardo Giaretta, 319 Julien Laganier, Phil Roberts, and Vidya Narayanan for their comments 320 and suggestions regarding this document. 322 6. Informative References 324 [1] Kempf, J., "Problem Statement for IP Local Mobility", 325 IETF Internet Draft draft-ietf-netlmm-nohost-ps-01.txt (work in 326 progress), April 2006. 328 [2] Laganier, J. and S. Narayanan, "Network-based Localized 329 Mobility Management Interface between Mobile Node and Access 330 Router", IETF Internet Draft draft-ietf-netlmm-mn-ar-if-00.txt 331 (work in progress), April 2006. 333 [3] "NETLMM Protocol Specification (TBD)", IETF Working Group Item 334 (work in progress). 336 [4] Manner, J. and M. Kojo, "Mobility Related Terminology", 337 IETF Request for Comments 3753, June 2004. 339 [5] Kempf, J., "Goals for Network-based Localized Mobility 340 Management (NETLMM)", IETF Internet Draft 341 draft-ietf-netlmm-nohost-req-01.txt (work in progress), 342 April 2006. 344 [6] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 345 Access Identifier", IETF Request for Comments 4282, 346 December 2005. 348 [7] Aura, T., "Cryptographically Generated Addresses (CGA)", 349 IETF Request for Comments 3972, March 2005. 351 [8] Kempf, J., Narayanan, S., Nordmark, E., Pentland, B., and JH. 352 Choi, "Detecting Network Attachment in IPv6 Networks (DNAv6)", 353 IETF Internet Draft draft-ietf-dna-protocol-00.txt (work in 354 progress), February 2006. 356 [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 357 Carney, "Dynamic Host Configuration Protocol for IPv6 358 (DHCPv6)", IETF Internet Draft draft-ietf-dna-protocol-00.txt 359 (work in progress), February 2006. 361 [10] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 362 Discovery (ND) Trust Models and Threats", IETF Request for 363 Comments 3756, May 2004. 365 [11] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 366 Nordmark, "Mobile IP Version 6 Route Optimization Security 367 Design Background", IETF Request for Comments 4225, 368 December 2005. 370 Authors' Addresses 372 Christian Vogt 373 Institute of Telematics 374 Universitaet Karlsruhe (TH) 375 P.O. Box 6980 376 76128 Karlsruhe 377 Germany 379 Email: chvogt@tm.uka.de 381 James Kempf 382 DoCoMo USA Labs 383 181 Metro Drive, Suite 300 384 San Jose, CA 95110 385 USA 387 Phone: +1 408 451 4711 388 Email: kempf@docomolabs-usa.com 390 Intellectual Property Statement 392 The IETF takes no position regarding the validity or scope of any 393 Intellectual Property Rights or other rights that might be claimed to 394 pertain to the implementation or use of the technology described in 395 this document or the extent to which any license under such rights 396 might or might not be available; nor does it represent that it has 397 made any independent effort to identify any such rights. Information 398 on the procedures with respect to rights in RFC documents can be 399 found in BCP 78 and BCP 79. 401 Copies of IPR disclosures made to the IETF Secretariat and any 402 assurances of licenses to be made available, or the result of an 403 attempt made to obtain a general license or permission for the use of 404 such proprietary rights by implementers or users of this 405 specification can be obtained from the IETF on-line IPR repository at 406 http://www.ietf.org/ipr. 408 The IETF invites any interested party to bring to its attention any 409 copyrights, patents or patent applications, or other proprietary 410 rights that may cover technology that may be required to implement 411 this standard. Please address the information to the IETF at 412 ietf-ipr@ietf.org. 414 The IETF has been notified of intellectual property rights claimed in 415 regard to some or all of the specification contained in this 416 document. For more information consult the online list of claimed 417 rights. 419 Disclaimer of Validity 421 This document and the information contained herein are provided on an 422 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 423 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 424 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 425 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 426 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 427 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 429 Copyright Statement 431 Copyright (C) The Internet Society (2006). This document is subject 432 to the rights, licenses and restrictions contained in BCP 78, and 433 except as set forth therein, the authors retain all their rights. 435 Acknowledgment 437 Funding for the RFC Editor function is currently provided by the 438 Internet Society.