idnits 2.17.1 draft-ietf-mip6-ro-sec-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.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1687. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1703), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 185 has weird spacing: '...oposals take ...' == Line 313 has weird spacing: '...d route optim...' == Line 718 has weird spacing: '... return routa...' == Line 1035 has weird spacing: '... Low lifet...' == Line 1040 has weird spacing: '... Low heuri...' == (2 more instances...) -- 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 (July 19, 2004) is 7221 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) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '2') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '3') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3445 (ref. '5') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '7') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-send-ndopt-05 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Nikander 2 Internet-Draft J. Arkko 3 Expires: January 17, 2005 Ericsson Research Nomadic Lab 4 T. Aura 5 Microsoft Research 6 G. Montenegro 7 E. Nordmark 8 Sun Microsystems 9 July 19, 2004 11 Mobile IP version 6 Route Optimization Security Design Background 12 draft-ietf-mip6-ro-sec-01 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at http:// 34 www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 17, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). All Rights Reserved. 45 Abstract 47 This document is a succint account of the rationale behind the Mobile 48 IPv6 (MIPv6) Route Optimization Security Design. The purpose of this 49 document is to present the thinking and to preserve the reasoning 50 behind the Mobile IPv6 Security Design in 2001-2002. 52 The document has two target audiences: (1) MIPv6 implementors so that 53 they can better understand the design choices in MIPv6 security 54 procedures; and (2) people dealing with mobility or multi-homing so 55 that they can avoid a number of potential security pitfalls in their 56 design. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1 Assumptions about the Existing IP Infrastructure . . . . . 5 62 1.1.1 A note on source addresses and ingress filtering . . . 6 63 1.2 The Mobility Problem and the Mobile IPv6 Solution . . . . 7 64 1.3 Design Principles and Goals . . . . . . . . . . . . . . . 8 65 1.3.1 End-to-end principle . . . . . . . . . . . . . . . . . 9 66 1.3.2 Trust assumptions . . . . . . . . . . . . . . . . . . 9 67 1.3.3 Protection level . . . . . . . . . . . . . . . . . . . 9 68 1.4 About Mobile IPv6 Mobility and its Variations . . . . . . 10 69 2. Dimensions of Danger . . . . . . . . . . . . . . . . . . . . . 11 70 2.1 Target . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 2.2 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 2.3 Location . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 3. Threats and limitations . . . . . . . . . . . . . . . . . . . 13 74 3.1 Attacks against address 'owners' aka. address 75 'stealing' . . . . . . . . . . . . . . . . . . . . . . . . 14 76 3.1.1 Basic address stealing . . . . . . . . . . . . . . . . 14 77 3.1.2 Stealing addresses of stationary nodes . . . . . . . . 15 78 3.1.3 Future address stealing . . . . . . . . . . . . . . . 15 79 3.1.4 Attacks against Secrecy and Integrity . . . . . . . . 16 80 3.1.5 Basic Denial of Service Attacks . . . . . . . . . . . 17 81 3.1.6 Replaying and Blocking Binding Updates . . . . . . . . 17 82 3.2 Attacks against other nodes and networks (flooding) . . . 18 83 3.2.1 Basic flooding . . . . . . . . . . . . . . . . . . . . 18 84 3.2.2 Return-to-home flooding . . . . . . . . . . . . . . . 19 85 3.3 Attacks against binding update protocols . . . . . . . . . 20 86 3.3.1 Inducing Unnecessary Binding Updates . . . . . . . . . 20 87 3.3.2 Forcing Non-Optimized Routing . . . . . . . . . . . . 21 88 3.3.3 Reflection and Amplification . . . . . . . . . . . . . 22 89 3.4 Classification of attacks . . . . . . . . . . . . . . . . 24 90 3.5 Problems with infrastructure based authorization . . . . . 24 91 4. The solution selected for Mobile IPv6 . . . . . . . . . . . . 26 92 4.1 Return Routability . . . . . . . . . . . . . . . . . . . . 26 93 4.1.1 Home Address check . . . . . . . . . . . . . . . . . . 28 94 4.1.2 Care-of-Address check . . . . . . . . . . . . . . . . 29 95 4.1.3 Forming the first Binding Update . . . . . . . . . . . 29 96 4.2 Creating state safely . . . . . . . . . . . . . . . . . . 29 97 4.2.1 Retransmissions and state machine . . . . . . . . . . 31 98 4.3 Quick expiration of the Binding Cache Entries . . . . . . 31 99 5. Security considerations . . . . . . . . . . . . . . . . . . . 33 100 5.1 Residual Threats as Compared to IPv4 . . . . . . . . . . . 33 101 5.2 Interaction with IPsec . . . . . . . . . . . . . . . . . . 34 102 5.3 Pretending to be one's neighbor . . . . . . . . . . . . . 35 103 5.4 Two mobile nodes talking to each other . . . . . . . . . . 35 104 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37 105 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 106 8. Informative References . . . . . . . . . . . . . . . . . . . . 38 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 108 Intellectual Property and Copyright Statements . . . . . . . . 40 110 1. Introduction 112 Mobile IPv4 is based on the idea of supporting mobility on top of 113 existing IP infrastructure, without requiring any modifications to 114 the routers, the applications, or the stationary end hosts. However, 115 in Mobile IPv6 [7] (as opposed to Mobile IPv4) the stationary end 116 hosts may provide support for mobility, i.e., route optimization. In 117 route optimization a correspondent node (CN), i.e., a peer for a 118 mobile node, learns a binding between the mobile node's stationary 119 home address and its current temporary care-of-address. This binding 120 is then used to modify the handling of outgoing (as well as the 121 processing of incoming) packets, leading to security risks. The 122 purpose of this document is the provide a relatively compact source 123 of the background assumptions, design choices, and other information 124 needed to understand the route optimization security design. This 125 document does not seek to compare the relative security of Mobile 126 IPv6 and other mobility protocols, or to list all the alternative 127 security mechanisms that were discussed during the Mobile IPv6 design 128 process. For a summary of the latter, we refer the reader to [1]. 129 Even though incidental implementation suggestions are included for 130 illustrative purposes, the goal of this document is not to provide a 131 guide to implementors. The goal of this document is to explain the 132 design choices and rationale behind the current route optimization 133 design. The authors participated in the design team which produced 134 the design, and hope, via this note, to capture some of the lessons 135 and reasoning behind that effort. 137 The intent is to document the thinking behind that design effort, as 138 it was. Even though this note may incorporate more recent 139 developments in order to illustrate the issues, it is not our intent 140 to present a new design. Rather, along with the lessons learned, 141 there is some effort to clarify differing opinions, questionable 142 assumptions, or newly discovered vulnerabilities, should such new 143 information be available today. This is also very important, because 144 it may benefit the working group's hindsight as it revises or 145 improves the Mobile IPv6 specification. 147 To fully understand the security implications of the relevant design 148 constraints it is necessary to briefly explore the nature of the 149 existing IP infrastructure, the problems Mobile IP aims to solve, and 150 the design principles applied. In the light of this background, we 151 can then explore IP based mobility in more detail, and have a brief 152 look at the security problems. The background is given in the rest 153 of this section, starting from Section 1.1. 155 While the introduction in Section 1.1 may appear redundant to those 156 readers who are already familiar with Mobile IPv6, it may be valuable 157 to read it anyway. The approach taken in this document is very 158 different from the one in the Mobile IPv6 specification. That is, we 159 have explicitly aimed to expose the implicit assumptions and design 160 choices made in the base Mobile IPv6 design, while the Mobile IPv6 161 specification aims to state the result of the design. By 162 understanding the background it is much easier to understand the 163 source of some of the related security problems, and to understand 164 the limitations intrinsic to the provided solutions. 166 In particular, this document explains how the adopted design for 167 "Return Routability" (RR) protects against the identified threats 168 (Section 3). This is true except for attacks on the RR protocol 169 itself, which require other countermeasures based on heuristics and 170 judicious implementation (Section 3.3). 172 The rest of this document is organized as follows. After this 173 introductory section, we start by considering the dimensions of the 174 danger in Section 2. The security problems and countermeasures are 175 studied in detail in Section 3. Section 4 explains the overall 176 operation and design choices behind the current security design. In 177 Section 5 we analyze the design and discuss the remaining threats. 178 Finally Section 6 concludes this document. 180 1.1 Assumptions about the Existing IP Infrastructure 182 One of the design goals in the Mobile IP design was to make mobility 183 possible without changing too much. This was especially important 184 for IPv4, with its large installed base, but the same design goals 185 were inherited by Mobile IPv6. Some alternative proposals take a 186 different approach and propose larger modifications to the Internet 187 architecture (see Section 1.4). 189 To understand Mobile IPv6, it is important to understand the MIPv6 190 design view to the base IPv6 protocol and infrastructure. The most 191 important base assumptions can be expressed as follows: 192 The routing prefixes available to a node are determined by its 193 current location, and therefore the node must change its IP 194 address as its moves. 195 The routing infrastructure is assumed to be secure and well 196 functioning, delivering packets to their intended destinations as 197 identified by the destination address. 199 While these may appear as trivial, let us explore them a little 200 further. Firstly, in the current IPv6 operational practice the IP 201 address prefixes are distributed in a hierarchical manner. This 202 limits the amount of routing table entries each single router needs 203 to handle. An important implication is that the topology determines 204 what globally routable IP addresses are available at a given 205 location. That is, the nodes cannot freely decide what globally 206 routable IP address to use, but must rely on the routing prefixes 207 served by the local routers via Router Advertisements or by a DHCP 208 server. In other words, IP addresses are just what the name says, 209 addresses, i.e., locators. 211 Secondly, in the current Internet structure, the routers collectively 212 maintain a distributed database of the network topology, and forward 213 each packet towards the location determined by the destination 214 address carried in the packet. To maintain the topology information, 215 the routers must trust each other, at least to a certain extent. The 216 routers learn the topology information from the other routers, and 217 they have no option but to trust their neighbor routers about distant 218 topology. At the borders of administrative domains, policy rules are 219 used to limit the amount of perhaps faulty routing table information 220 received from the peer domains. While this is mostly used to weed 221 out administrative mistakes, it also helps with security. The aim is 222 to maintain a reasonably accurate idea of the network topology even 223 if someone is feeding faulty information to the routing system. 225 In the current Mobile IPv6 design it is explicitly assumed that the 226 routers and the policy rules are configured in a reasonable way, and 227 that the resulting routing infrastructure is trustworthy enough. 228 That is, it is assumed that the routing system maintains accurate 229 information of the network topology, and that it is therefore able to 230 route packets to their destination locations. If this assumption is 231 broken, the Internet itself is broken in the sense that packets go to 232 wrong locations. Such a fundamental malfunction of the Internet 233 would render hopeless any other effort to assure correct packet 234 delivery (e.g., any efforts due to Mobile IP security 235 considerations). 237 1.1.1 A note on source addresses and ingress filtering 239 Some of the threats and attacks discussed in this document take 240 advantage of the ease of source address spoofing. That is, in the 241 current Internet it is possible to send packets with false source IP 242 address. Ingress filtering is assumed to eventually prevent this. 243 When ingress filtering is used, traffic with spoofed addresses is not 244 forwarded. This filtering can be applied at different network 245 borders like those between an Internet service provider (ISP) and its 246 customers, between downstream and upstream ISPs, between peer ISPs, 247 etc [6]. Obviously, the granularity of ingress filters specifies how 248 much you can "spoof inside a prefix". For example, if an ISP ingress 249 filters a customer's link, but the customer does nothing, anything 250 inside the customer's /48 prefix could be spoofed, or if the customer 251 does filtering at LAN subnets, anything inside the /64 prefixes could 252 be spoofed. Despite the limitations imposed by such "in-prefix 253 spoofing", in general, ingress filtering enables traffic to be 254 traceable to its real source network [6]. 256 However, ingress filtering helps if and only if a large part of the 257 Internet uses it. Unfortunately, there are still some issues (e.g. 258 in the presence of site multi-homing) which, although not 259 insurmountable, do require careful handling, and are likely to limit 260 or delay its usefulness [6]. 262 1.2 The Mobility Problem and the Mobile IPv6 Solution 264 The Mobile IP design aims to solve two problems at the same time. 265 Firstly, it allows transport layer sessions (TCP connections, 266 UDP-based transactions) to continue even if the underlying host(s) 267 move and change their IP addresses. Secondly, it allows a node to be 268 reached through a static IP address, a home address (HoA). 270 The latter design choice can also be stated in other words: Mobile 271 IPv6 aims to preserve the identifier nature of IP addresses. That 272 is, Mobile IPv6 takes the view that IP addresses can be used as 273 natural identifiers of nodes, as they have been used since the 274 beginning of the Internet. This must be contrasted to proposed and 275 existing alternative designs where the identifier and locator natures 276 of the IP addresses have been separated (see Section 1.4) 278 The basic idea in Mobile IP is to allow a home agent (HA) to work as 279 a stationary proxy for a mobile node (MN). Whenever the mobile node 280 is away from its home network, the home agent intercepts packets 281 destined to the node, and forwards the packets by tunneling them to 282 the node's current address, the care-of-address (CoA). The transport 283 layer (e.g., TCP, UDP) uses the home address as a stationary 284 identifier for the mobile node. Figure 1 illustrates this basic 285 arrangement. 287 +----+ +----+ 288 | MN |=#=#=#=#=#=#=#=#=tunnel=#=#=#=#=#=#=#=#|#HA | 289 +----+ ____________ +-#--+ 290 | CoA ___/ \_____ # Home Link 291 -+-------/ Internet * * *-*-*-*-#-#-#-#----- 292 | * * | * Home Address 293 \___ * * _____/ + * -+ 294 \_____*______/ | MN | 295 * + - -+ 296 +----+ 297 | CN | Data path as * * * * 298 +----+ it appears to correspondent node 299 Real data path # # # # 301 Figure 1 303 The basic solution requires tunneling through the home agent, thereby 304 leading to longer paths and degraded performance. This tunneling is 305 sometimes called triangular routing since it was originally planned 306 that the packets from the mobile node to its peer could still 307 traverse directly, bypassing the home agent. 309 To alleviate the performance penalty, Mobile IPv6 includes a mode of 310 operation that allows the mobile node and its peer, a correspondent 311 node (CN), to exchange packets directly, bypassing the home agent 312 completely after the initial setup phase. This mode of operation is 313 called route optimization (RO). When route optimization is used, 314 the mobile node sends its current care-of-address to the 315 correspondent node using binding update (BU) messages. The 316 correspondent node stores the binding between the home address and 317 care-of address into its Binding Cache. 319 Whenever MIPv6 route optimization is used, the correspondent node 320 effectively functions in two roles. Firstly, it is the source of the 321 packets it sends, as usual. Secondly, it acts as the first router 322 for the packets, effectively performing source routing. That is, 323 when the correspondent node is sending out packets, it consults its 324 MIPv6 route optimization data structures, and reroutes the packets if 325 necessary. A Binding Cache Entry (BCE) contains the home address and 326 the care-of-address of the mobile node, and records the fact that 327 packets destined to the home address should now be sent to the 328 destination address. Thus, it represents a local routing exception. 330 The packets leaving the correspondent node are source routed to the 331 care-of-address. Each packet includes a routing header that contains 332 the home address of the mobile node. Thus, logically, the packet is 333 first routed to the care-of-address, and then virtually from the 334 care-of-address to the home address. In practice, of course, the 335 packet is consumed by the mobile node at the care-of-address, and the 336 header just allows the mobile node to select a socket associated with 337 the home address instead of one with the care-of-address. However, 338 the mechanism resembles source routing since there is routing state 339 involved at the correspondent node, and a routing header is used. 340 Nevertheless, this routing header is special (type 2) to avoid the 341 risks associated with using the more general (type 0) variant. 343 1.3 Design Principles and Goals 345 The MIPv6 design and security design aimed to follow the end-to-end 346 principle, to duly notice the differences in trust relationships 347 between the nodes, and to establish an explicit goal in the provided 348 level of protection. 350 1.3.1 End-to-end principle 352 Perhaps the leading design principle for Internet protocols is the so 353 called end-to-end principle [4][9]. According to this principle, it 354 is beneficial to avoid polluting the network with state, and to limit 355 new state creation to the involved end nodes. 357 In the case of Mobile IPv6, the end-to-end principle is applied by 358 restricting mobility related state primarily to the home agent. 359 Additionally, if route optimization is used, the correspondent nodes 360 also maintain a soft state about the mobile nodes' current 361 care-of-addresses, the Binding Cache. This can be contrasted to an 362 approach that would use individual host routes within the basic 363 routing system. Such an approach would create state on a huge number 364 of routers around the network. In Mobile IPv6, only the home agent 365 and the communicating nodes need to create state. 367 1.3.2 Trust assumptions 369 In the Mobile IPv6 security design, different approaches were chosen 370 for securing the communication between the mobile node and its home 371 agent and between the mobile node and its correspondent nodes. In 372 the home agent case it was assumed that the mobile node and the home 373 agent know each other through a prior arrangement, e.g., due to a 374 business relationships. In contrast, it was strictly assumed that 375 the mobile node and the correspondent node do not need to have any 376 prior arrangement, thereby allowing Mobile IPv6 to function in a 377 scalable manner, without requiring any configuration at the 378 correspondent nodes. 380 1.3.3 Protection level 382 As a security goal, Mobile IPv6 design aimed to be "as secure as the 383 (non-mobile) IPv4 Internet" was at the time of the design, in the 384 period 2001-2002. In particular, that means that there is little 385 protection against attackers that are able to attach themselves 386 between a correspondent node and a home agent. The rational is 387 simple: in the 2001 Internet, if a node was able to attach itself to 388 the communication path between two arbitrary nodes, it was able to 389 disrupt, modify, and eavesdrop all the traffic between the two nodes, 390 unless IPsec protection was used. Even when IPsec was used, the 391 attacker was still able to selectively block communication by simply 392 dropping the packets. The attacker in control of a router between 393 the two nodes could also mount a flooding attack by redirecting the 394 data flows between the two nodes (or, more practically, an equivalent 395 flow of bogus data) to a third party. 397 1.4 About Mobile IPv6 Mobility and its Variations 399 Taking a more abstract angle, IPv6 mobility can be defined as a 400 mechanism for managing local exceptions to routing information in 401 order to direct packets that are sent to one address (the home 402 address) to another address (the care-of-address). It is managing in 403 the sense that the local routing exceptions (source routes) are 404 created and deleted dynamically, based on the instructions sent by 405 the mobile node. It is local in the sense that the routing 406 exceptions are valid only at the home agent, and in the correspondent 407 nodes if route optimization is used. The created pieces of state are 408 exceptions in the sense that they override the normal topological 409 routing information carried collectively by the routers. 411 Using the terminology introduced by J. Noel Chiappa [12], we can say 412 that the home address functions in the dual role of being an 413 end-point identifier (EID) and a permanent locator. The 414 care-of-address is a pure, temporary locator, which identifies the 415 current location of the mobile node. The correspondent nodes 416 effectively perform source routing, redirecting traffic destined to 417 the home address to the care-of-address. This is even reflected in 418 the packet structure: the packets carry an explicit routing header. 420 The relationshiop between EID's and permanent locators has been 421 exploited by other proposals. Their technical merits and security 422 problems, however, are beyond the scope of this document. 424 2. Dimensions of Danger 426 Based on the discussion above it should now be clear that the dangers 427 in Mobile IPv6 lie in creation (or deletion) of the local routing 428 exceptions. In Mobile IPv6 terms, the danger is in the possibility 429 of unauthorized creation of Binding Cache Entries (BCE). The effects 430 of an attack differ depending on the target of the attack, the timing 431 of the attack, and the location of the attacker. 433 2.1 Target 435 Basically, the target of an attack can be any node or network in the 436 Internet (stationary or mobile). The basic differences lie in the 437 goals of the attack: does the attacker aim to divert (steal) the 438 traffic destined to and/or sourced at the target node, or does it aim 439 to cause denial-of-service to the target node or network. The target 440 does not typically play much of an active role attack. As an 441 example, an attacker may launch a denial-of-service attack on a given 442 node A by contacting a large number of nodes, claiming to be A, and 443 subsequently diverting the traffic at these other nodes so that A is 444 harmed by no longer being able to receive packets from those nodes. 445 A itself need not be involved at all before its communications start 446 to break. Furthermore, A is not necessarily a mobile node; it may 447 very well be stationary. 449 Mobile IPv6 uses the same class of IP addresses for both mobile nodes 450 (i.e., home and care-of addresses) and stationary nodes. That is, 451 mobile and stationary addresses are indistinguishable from each 452 other. Attackers can take advantage of this by taking any IP address 453 and using it in a context where normally only mobile (home or care-of 454 addresses) appear. This means that attacks that otherwise would only 455 concern mobiles are, in fact, a threat to all IPv6 nodes. 457 In fact, the role of being a mobile node appears to be most 458 protected, since in that role a node does not need to maintain state 459 about the whereabouts of some remote nodes. Conversely, the role of 460 being a correspondent node appears to be the weakest point since 461 there are very few assumptions upon which it can base its state 462 formation. That is, an attacker has much easier task to fool a 463 correspondent node to believe that a presumably mobile node is 464 somewhere it is not, than to fool a mobile node itself into believing 465 something similar. On the other hand, since it is possible to attack 466 a node indirectly by first targetting its peers, all nodes are 467 equally vulnerable in some sense. Furthermore, a (usually) mobile 468 node often also plays the role of being a correspondent node, since 469 it can exchange packets with other mobile nodes (see also Section 470 5.4). 472 2.2 Timing 474 An important aspect in understanding Mobile IPv6 related dangers is 475 timing. In a stationary IPv4 network, an attacker must be between 476 the communication nodes at the same time as the nodes communicate. 477 With the Mobile IPv6 ability of creating binding cache entries, the 478 situation changes. A new danger is created. Without proper 479 protection, an attacker could attach itself between the home agent 480 and a correspondent node for a while, create a BCE at the 481 correspondent node, leave the position, and continuously update the 482 correspondent node about the mobile node's whereabouts. This would 483 make the correspondent node send packets destined to the mobile node 484 to an incorrect address as long as the BCE remained valid, i.e., 485 typically until the correspondent node is rebooted. The converse 486 would also be possible: an attacker could also launch an attack by 487 first creating a BCE and then letting it expire at a carefully 488 selected time. If a large number of active BCEs carrying large 489 amounts of traffic expired at the same time, the result might be an 490 overload towards the home agent or the home network. (See Section 491 3.2.2 for a more detailed explanation.) 493 2.3 Location 495 In a static IPv4 Internet, an attacker can only receive packets 496 destined to a given address if it is able to attach itself to or 497 control a node on the topological path between the sender and the 498 recipient. On the other hand, an attacker can easily send spoofed 499 packets from almost anywhere. If Mobile IPv6 allowed sending 500 unprotected Binding Updates, an attacker could create a BCE on any 501 correspondent node from anywhere in the Internet, simply by sending a 502 fraudulent Binding Update to the correspondent node. Instead of 503 being required to be between the two target nodes, the attacker could 504 act from anywhere in the Internet. 506 In summary, by introducing the new routing exception (binding cache) 507 at the correspondent nodes, Mobile IPv6 introduces the dangers of 508 time and space shifting. Without proper protection, Mobile IPv6 509 would allow an attacker to act from anywhere in the Internet and well 510 before the time of the actual attack. In contrast, in the static 511 IPv4 Internet the attacking nodes must be present at the time of the 512 attack and they must be positioned in a suitable way, or the attack 513 would not be possible in the first place. 515 3. Threats and limitations 517 This section describes attacks against Mobile IPv6 Route Optimization 518 and related protection mechanisms. The goal of the attacker can be 519 to corrupt the correspondent node's binding cache and to cause 520 packets to be delivered to a wrong address. This can compromise 521 secrecy and integrity of communication and cause denial-of-service 522 (DoS) both at the communicating parties and at the address that 523 receives the unwanted packets. The attacker may also exploit 524 features of the Binding Update (BU) mechanism to exhaust the 525 resources of the mobile node, the home agent, or the correspondent 526 nodes. The aim of this section is to describe the major attacks and 527 to overview various protocol mechanisms and their limitations. The 528 details of the mechanisms are covered in Section 4. 530 It is essential to understand that some of the threats are more 531 serious than others, some can be mitigated but not removed, some 532 threats may represent acceptable risk, and some threats may be 533 considered too expensive to be prevented. 535 We consider only active attackers. The rationale behind this is that 536 in order to corrupt the binding cache, the attacker must sooner or 537 later send one or more messages. Thus, it makes little sense to 538 consider attackers that only observe messages but do not send any. 539 In fact, some active attacks are easier, for the average attacker, to 540 launch than a passive one would be. That is, in many active attacks 541 the attacker can initiate binding update processing at any time, 542 while most passive attacks require the attacker to wait for suitable 543 messages to be sent by the targets nodes. 545 Nevertheless, an important class of passive attacks remains, namely, 546 attacks on privacy. It is well known that by simply examining 547 packets, eavesdroppers can track the movements of individual nodes 548 (and potentially, users) [3] Mobile IPv6 exacerbates the problem by 549 adding more potentially sensitive information into the packets (e.g., 550 Binding Updates, routing headers or home address options). This 551 document does not address these attacks. 553 We first consider attacks against nodes that are supposed to have a 554 specified address (Section 3.1), continuing with flooding attacks 555 (Section 3.2) and attacks against the basic Binding Update protocol 556 (Section 3.3). After that we present a classification of the attacks 557 (Section 3.4). Finally, we considering the applicability of 558 solutions relying on some kind of a global security infrastructure 559 (Section 3.5). 561 3.1 Attacks against address 'owners' aka. address 'stealing' 563 The most obvious danger in Mobile IPv6 is address "stealing", i.e., 564 an attacker illegitimately claiming to be a given node at a given 565 address, and then trying to "steal" traffic destined to that address. 566 There are several variants of this attack. We first describe the 567 basic variant, followed by a description how the situation is 568 affected if the target is a stationary node, and continuing more 569 complicated issues related to timing (the so called "future" 570 attacks), confidentiality and integrity, and DoS aspects. 572 3.1.1 Basic address stealing 574 If Binding Updates were not authenticated at all, an attacker could 575 fabricate and send spoofed binding updates from anywhere in the 576 Internet. All nodes that support the correspondent node 577 functionality would become unwitting accomplices to this attack. As 578 explained in Section 2.1, there is no way of telling which addresses 579 belong to mobile nodes that really could send binding updates and 580 which addresses belong to stationary nodes (see below), so 581 potentially any node (including "static" nodes) are vulnerable. 583 +---+ original +---+ new packet +---+ 584 | B |<----------------| A |- - - - - - ->| C | 585 +---+ packet flow +---+ flow +---+ 586 ^ 587 | 588 | False BU: B -> C 589 | 590 +----------+ 591 | Attacker | 592 +----------+ 594 Figure 2 596 Consider an IP node A sending IP packets to another IP node B. The 597 attacker could redirect the packets to an arbitrary address C by 598 sending a Binding Update to A. The home address (HoA) in the binding 599 update would be B and the care-of address (CoA) would be C. After 600 receiving this binding update, A would send all packets intended for 601 the node B to the address C. See Figure 2. 603 The attacker might select the care-of address to be either its own 604 current address, another address in its local network, or any other 605 IP address. If the attacker selected a local care-of address 606 allowing it to receive the packets, it would be able to send replies 607 to the correspondent node. Ingress filtering at the attacker's local 608 network does not prevent the spoofing of Binding Updates but forces 609 the attacker either to choose a care-of address from inside its own 610 network or to use the Alternate care-of address sub-option. 612 The binding update authorization mechanism used in the MIPv6 security 613 design is primarily intended to mitigate this threat, and to limit 614 the location of attackers to the path between a correspondent node 615 and the home agent. 617 3.1.2 Stealing addresses of stationary nodes 619 The attacker needs to know or guess the IP addresses of both the 620 source of the packets to be diverted (A in the example above) and the 621 destination of the packets (B). This means that it is difficult to 622 redirect all packets to or from a specific node because the attacker 623 would need to know the IP addresses of all the nodes with which it is 624 communicating. 626 Nodes with well-known addresses, such as servers and those using 627 stateful configuration, are most vulnerable. Nodes that are a part 628 of the network infrastructure, such as DNS servers, are particularly 629 interesting targets for attackers, and particularly easy to identify. 631 Nodes that frequently change their address and use random addresses 632 are relatively safe. However, if they register their address into 633 Dynamic DNS, they become more exposed. Similarly, nodes that visit 634 publicly accessible networks such as airport wireless LANs risk 635 revealing their addresses. IPv6 addressing privacy features [3] 636 mitigate these risks to an extent but it should be noted that 637 addresses cannot be completely recycled while there are still open 638 sessions that use those addresses. 640 Thus, it is not the mobile nodes that are most vulnerable to address 641 stealing attacks, it is the well known static servers. Furthermore, 642 the servers often run old or heavily optimized operating systems, and 643 may not have any mobility related code at all. Thus, the security 644 design cannot be based on the idea that mobile nodes might somehow be 645 able to detect if someone has stolen their address, and reset the 646 state at the correspondent node. Instead, the security design must 647 make reasonable measures to prevent the creation of fraudulent 648 binding cache entries in the first place. 650 3.1.3 Future address stealing 652 If an attacker knows an address that a node is likely to select in 653 the future, it can launch a "future" address stealing attack. The 654 attacker creates a Binding Cache Entry using the home address that it 655 anticipates the target node will use. If the Home Agent allows 656 dynamic home addresses, the attacker may be able to do this 657 legitimately. That is, if the attacker is a client of the Home 658 Agent, and able to acquire the home address temporarily, it may be 659 able to do so, and then return the home address back to the Home 660 Agent once the BCE is in place. 662 Now, if the BCE state had a long expiration time, the target node 663 would acquire the same home address while the BCE is still effective, 664 and the attacker would be able to launch a successful 665 man-in-the-middle or denial-of-service attack. The mechanism applied 666 in the MIPv6 security design is to limit the lifetime of Binding 667 Cache Entries to a few minutes. 669 Note that this attack applies only to fairly specific conditions. 670 There are also some variations of this attack that are theoretically 671 possible under some other conditions. However, all of these attacks 672 are limited by the Binding Cache Entry lifetime, and therefore not a 673 real concern under the current design. 675 3.1.4 Attacks against Secrecy and Integrity 677 By spoofing Binding Updates, an attacker could redirect all packets 678 between two IP nodes to itself. By sending a spoofed binding update 679 to A, it could capture the data intended to B. That is, it could 680 pretend to be B and highjack A's connections with B, or establish new 681 spoofed connections. The attacker could also send spoofed binding 682 updates to both A and B and insert itself in the middle of all 683 connections between them (man-in-the-middle attack). Consequently, 684 the attacker would be able to see and modify the packets sent between 685 A and B. See Figure 3. 687 Original data path, before man-in-the-middle attack 689 +---+ +---+ 690 | A | | B | 691 +---+ +---+ 692 \___________________________________/ 694 Modified data path, after the falsified binding updates 696 +---+ +---+ 697 | A | | B | 698 +---+ +---+ 699 \ / 700 \ / 701 \ +----------+ / 702 \---------| Attacker |-------/ 703 +----------+ 704 Figure 3 706 Strong end-to-end encryption and integrity protection, such as 707 authenticated IPSec, can prevent all the attacks against data secrecy 708 and integrity. When the data is cryptographically protected, spoofed 709 binding updates could result in denial of service (see below) but not 710 in disclosure or corruption of sensitive data beyond revealing the 711 existence of the traffic flows. Two fixed nodes could also protect 712 communication between themselves by refusing to accept binding 713 updates from each other. Ingress filtering, on the other hand, does 714 not help because the attacker is using its own address as the care-of 715 address and is not spoofing source IP addresses. 717 The protection adopted in MIPv6 Security Design is to authenticate 718 (albeit weakly) the addresses by return routability (RR), which 719 limits the topological locations from which the attack is possible 720 (see Section 4.1). 722 3.1.5 Basic Denial of Service Attacks 724 By sending spoofed binding updates, the attacker could redirect all 725 packets sent between two IP nodes to a random or nonexistent 726 address(es). This way, it might be able to stop or disrupt 727 communication between the nodes. This attack is serious because any 728 Internet node could be targeted, also fixed nodes belonging to the 729 infrastructure (e.g., DNS servers) are vulnerable. Again, the 730 selected protection mechanism is return routability (RR). 732 3.1.6 Replaying and Blocking Binding Updates 734 Any protocol for authenticating binding update has to consider replay 735 attacks. That is, an attacker may be able to replay recent 736 authenticated binding updates to the correspondent and, that way, 737 direct packets to the mobile node's previous location. Like spoofed 738 binding updates, this could be used both for capturing packets and 739 for DoS. The attacker could capture the packets and impersonate the 740 mobile node if it reserved the mobile's previous address after the 741 mobile node has moved away and then replayed the previous binding 742 update to redirect packets back to the previous location. 744 In a related attack, the attacker blocks binding updates from the 745 mobile at its new location, e.g., by jamming the radio link or by 746 mounting a flooding attack, and takes over its connections at the old 747 location. The attacker will be able to capture the packets sent to 748 the mobile and to impersonate the mobile until the correspondent's 749 Binding Cache entry expires. 751 Both of the above attacks require the attacker to be on the same 752 local network with the mobile, where it can relatively easily observe 753 packets and block them even if the mobile does not move to a new 754 location. Therefore, we believe that these attacks are not as 755 serious as ones that can be mounted from remote locations. The 756 limited lifetime of the Binding Cache entry and the associated nonces 757 limit the time frame within which the replay attacks are possible. 759 3.2 Attacks against other nodes and networks (flooding) 761 By sending spoofed binding updates, an attacker could redirect 762 traffic to an arbitrary IP address. This could be used to bomb an 763 arbitrary Internet address with excessive amounts of packets. The 764 attacker could also target a network by redirecting data to one or 765 more IP addresses within the network. There are two main variations 766 of flooding: basic flooding and return-to-the-home flooding. We 767 consider them separately. 769 3.2.1 Basic flooding 771 In the simplest attack, the attacker knows that there is a heavy data 772 stream from node A to B and redirects this to the target address C. 773 However, A would soon stop sending the data because it is not 774 receiving acknowledgments from B. 776 (B is attacker) 778 +---+ original +---+ flooding packet +---+ 779 | B |<================| A |==================>| C | 780 +---+ packet flow +---+ flow +---+ 781 | ^ 782 \ / 783 \__________________/ 784 False binding update + false acknowledgements 786 Figure 4 788 A more sophisticated attacker would act itself as B; see Figure 4. 789 It would first subscribe to a data stream (e.g. a video stream) and 790 then redirects this stream to the target address C. The attacker 791 would even be able to spoof the acknowledgements. For example, 792 consider a TCP stream. The attacker would perform the TCP handshake 793 itself and thus know the initial sequence numbers. After redirecting 794 the data to C, the attacker would continue to send spoofed 795 acknowledgments. It would even be able to accelerate the data rate 796 by simulating a fatter pipe [10]. 798 This attack might be even easier with UDP/RTP. The attacker could 799 create spoofed RTCP acknowledgements. Either way, the attacker would 800 be able to redirect an increasing stream of unwanted data to the 801 target address without doing much work itself. It could carry on 802 opening more streams and refreshing the Binding Cache entries by 803 sending a new binding update every few minutes. Thus, the limitation 804 of BCE lifetime to a few minutes does not help here alone. 806 During the Mobile IPv6 design process, the effectiveness of this 807 attack was debated. It was mistakenly assumed that the target node 808 would send a TCP Reset to the source of the unwanted data stream, 809 which would then stop sending. In reality, all practical TCP/IP 810 implementations fail to send the Reset. The target node drops the 811 unwanted packets at the IP layer because it does not have a Binding 812 Update List entry corresponding to the Routing Header on the incoming 813 packet. Thus, the flooding data is never processed at the TCP layer 814 of the target node and no Reset is sent. This means that the attack 815 using TCP streams is more effective than was originally believed. 817 This attack is serious because the target can be any node or network, 818 not only a mobile one. What makes it particularly serious compared 819 to the other attacks is that the target itself cannot do anything to 820 prevent the attack. For example, it does not help if the target 821 network stops using Route Optimization. The damage is the worst if 822 these techniques are used to amplify the effect of other distributed 823 denial of service (DDoS) attacks. Ingress filtering in the 824 attacker's local network prevents the spoofing of source addresses 825 but the attack would still be possible by setting the Alternate 826 care-of address sub-option to the target address. 828 Again, the protection mechanism adopted for MIPv6 is return 829 routability. This time it is necessary to check that there is indeed 830 a node at the new care-of-address, and that the node is the one that 831 requested redirecting packets to that very address (see Section 832 4.1.2). 834 3.2.2 Return-to-home flooding 836 A variation of the bombing attack targets the home address or the 837 home network instead of the care-of-address or a visited network. 838 The attacker would claim to be a mobile with the home address equal 839 to the target address. While claiming to be away from home, the 840 attacker would start downloading a data stream. The attacker would 841 then send a binding update cancellation (i.e. a request to delete 842 the binding from the Binding Cache), or just allow the cache entry to 843 expire. Either would redirect the data stream to the home network. 844 Just like when bombing a care-of-address, the attacker can keep the 845 stream alive and even increase data rate by spoofing acknowledgments. 847 When successful, the bombing attack against the home network is just 848 as serious as the one against a care-of-address. 850 The basic protection mechanism adopted is return routability. 851 However, it is hard to fully protect against this attack; see Section 852 4.1.1. 854 3.3 Attacks against binding update protocols 856 Security protocols that successfully protect the secrecy and 857 integrity of data can sometimes make the participants more vulnerable 858 to denial-of-service attacks. In fact, the stronger the 859 authentication, the easier it may be for an attacker to use the 860 protocol features to exhaust the mobile's or the correspondent's 861 resources. 863 3.3.1 Inducing Unnecessary Binding Updates 865 When a mobile node receives an IP packet from a new correspondent via 866 the home agent, it may initiate the binding update protocol. An 867 attacker can exploit this by sending the mobile node a spoofed IP 868 packet (e.g. ping or TCP SYN packet) that appears to come from a new 869 correspondent node. Since the packet arrives via the home agent, the 870 mobile node may start the binding update protocol with the 871 correspondent node. The decision whether or not to initiate the 872 binding update procedure may depend on several factors (including 873 heuristics, cross layer information, configuration options, etc) and 874 is not specified by Mobile IPv6. Not initiating the binding update 875 procedure automatically may alleviate these attacks, but will not, in 876 general, avoid them completely. 878 In a real attack the attacker would induce the mobile node to 879 initiate binding update protocols with a large number of 880 correspondent nodes at the same time. If the correspondent addresses 881 are real addresses of existing IP nodes, then most instances of the 882 binding update protocol might even complete successfully. The 883 entries created in the Binding Cache are correct but useless. This 884 way, the attacker can induce the mobile to execute the binding update 885 protocol unnecessarily, which can drain the mobile's resources. 887 A correspondent node (i.e., any IP node) can also be attacked in a 888 similar way. The attacker sends spoofed IP packets to a large number 889 of mobiles with the target node's address as the source address. 890 These mobiles will initiate the binding update protocol with the 891 target node. Again, most of the binding update protocol executions 892 will complete successfully. By inducing a large number of 893 unnecessary binding updates, the attacker is able to consume the 894 target node's resources. 896 This attack is possible against any binding update authentication 897 protocol. The more resources the binding update protocol consumes, 898 the more serious the attack. Hence, strong cryptographic 899 authentication protocol is more vulnerable to the attack than a weak 900 one or unauthenticated binding updates. Ingress filtering helps a 901 little, since it makes it harder to forge the source address of the 902 spoofed packets, but it does not completely eliminate this threat. 904 A node should protect itself from the attack by setting a limit on 905 the amount of resources, i.e., processing time, memory, and 906 communications bandwidth, which it uses for processing binding 907 updates. When the limit is exceeded, the node can simply stop 908 attempting route optimization. Sometimes it is possible to process 909 some binding updates even when a node is under the attack. A mobile 910 node may have a local security policy listing a limited number of 911 addresses to which binding updates will be sent even when the mobile 912 node is under DoS attack. A correspondent node (i.e. any IP node) 913 may similarly have a local security policy listing a limited set of 914 addresses from which binding updates will be accepted even when the 915 correspondent is under a binding update DoS attack. 917 The node may also recognize addresses with which they have had 918 meaningful communication in the past and sent binding updates to or 919 accept them from those addresses. Since it may be impossible for the 920 IP layer to know about the protocol state in higher protocol layers, 921 a good measure of the meaningfulness of the past communication is 922 probably per-address packet counts. Alternatively, Neighbor 923 Discovery [2] (section 5.1, Conceptual Data Structures) defines the 924 Destination Cache as a set of entries about destinations to which 925 traffic has been sent recently. Thus, implementors may wish to use 926 the information in the Destination Cache. 928 Section 11.7.2 ("Correspondent Registration") in [7] does not specify 929 when such a route optimization procedure should be initiated. It 930 does indicate when it may justifiable to do so, but these hints are 931 not enough. This remains an area where more work is needed. 932 Obviously, given that route optimization is optional, any node that 933 finds the processing load excessive or unjustified may simply turn it 934 off (either selectively or completely). 936 3.3.2 Forcing Non-Optimized Routing 938 As a variant of the previous attack, the attacker can prevent a 939 correspondent node from using route optimization by filling its 940 Binding Cache with unnecessary entries so that most entries for real 941 mobiles are dropped. 943 Any successful DoS attack against a mobile or a correspondent node 944 can also prevent the processing of binding updates. We have 945 repeatedly suggested that the target of a DoS attack may respond by 946 stopping route optimization for all or some communication. 947 Obviously, an attacker can exploit this fallback mechanism and force 948 the target to use the less efficient home agent based routing. The 949 attacker only needs to mount a noticeable DoS attack against the 950 mobile or correspondent, and the target will default to non-optimized 951 routing. 953 The target node can mitigate the effects of the attack by reserving 954 more space for the Binding Cache, by reverting to non-optimized 955 routing only when it cannot otherwise cope with the DoS attack, by 956 trying aggressively to return to optimized routing, or by favoring 957 mobiles with which it has an established relationship. This attack 958 is not as serious as the ones described earlier, but applications 959 that rely on Route Optimization could still be affected. For 960 instance, conversational multimedia sessions can suffer drastically 961 from the additional delays caused by triangle routing. 963 3.3.3 Reflection and Amplification 965 Attackers sometimes try to hide the source of a packet flooding 966 attack by reflecting the traffic from other nodes [1]. That is, 967 instead of sending the flood of packets directly to the target, the 968 attacker sends data to other nodes, tricking them to send the same 969 number, or more, packets to the target. Such reflection can hide the 970 attacker's address even when ingress filtering prevents source 971 address spoofing. Reflection is particularly dangerous if the 972 packets can be reflected multiple times, if they can be sent into a 973 looping path, or if the nodes can be tricked into sending many more 974 packets than they receive from the attacker, because such features 975 can be used to amplify the traffic by a significant factor. When 976 designing protocols, one should avoid creating services that can be 977 used for reflection and amplification. 979 Triangle routing would easily create opportunities for reflection: a 980 correspondent node receives packets (e.g. TCP SYN) from the mobile 981 node and replies to the home address given by the mobile node in the 982 Home Address Option (HAO). The mobile might not really be a mobile 983 and the home address could actually be the target address. The 984 target would only see the packets sent by the correspondent and could 985 not see the attacker's address (even if ingress filtering prevents 986 the attacker from spoofing its source address). 988 +----------+ TCP SYN with HAO +-----------+ 989 | Attacker |-------------------->| Reflector | 990 +----------+ +-----------+ 991 | 992 | TCP SYN-ACK to HoA 993 V 994 +-----------+ 995 | Flooding | 996 | target | 997 +-----------+ 999 Figure 5 1001 A badly designed binding update protocol could also be used for 1002 reflection: the correspondent would respond to a data packet by 1003 initiating the binding update authentication protocol, which usually 1004 involves sending a packet to the home address. In that case, the 1005 reflection attack can be discouraged by copying the mobile's address 1006 into the messages sent by the mobile to the correspondent. (The 1007 mobile's source address is usually the same as the care-of address 1008 but an Alternative care-of address suboption can specify a different 1009 care-of address.) Some of the early proposals for MIPv6 security used 1010 this approach, and were prone to the reflection attacks. 1012 In some of the proposals for binding update authentication protocols, 1013 the correspondent node responded to an initial message from the 1014 mobile with two packets (one to the home address, one to the care-of 1015 address). It would have been possible to use this to amplify a 1016 flooding attack by a factor of two. Furthermore, with public-key 1017 authentication, the packets sent by the correspondent might have been 1018 significantly larger than the one that triggers them. 1020 These types of reflection and amplification can be avoided by 1021 ensuring that the correspondent only responds to the same address 1022 from which it received a packet, and only with a single packet of the 1023 same size. These principles have been applied to MIPv6 security 1024 design. 1026 3.4 Classification of attacks 1028 Sect. Attack name Target Sev. Mitigation 1029 --------------------------------------------------------------------- 1030 3.1.1 Basic address stealing MN Med. RR 1031 3.1.2 Stealing addresses of stationary nodes Any High RR 1032 3.1.3 Future address stealing MN Low RR, lifetime 1033 3.1.4 Attacks against Secrecy and Integrity MN Low RR, IPsec 1034 3.1.5 Basic Denial of Service Attacks Any Med. RR 1035 3.1.6 Replaying and Blocking Binding Updates MN Low lifetime, 1036 cookies 1037 3.2.1 Basic flooding Any High RR 1038 3.2.2 Return-to-home flooding Any High RR 1039 3.3.1 Inducing Unnecessary Binding Updates MN, CN Med. heuristics 1040 3.3.2 Forcing Non-Optimized Routing MN Low heuristics 1041 3.3.3 Reflection and Amplification N/A Med. BU design 1043 Figure 6 1045 Figure 6 gives a summary of the discussed attacks. As it stands 1046 today, the return-to-the-home flooding and the induction of 1047 unnecessary binding updates look like the threats that we have the 1048 least amount of protection, compared to their severity. 1050 3.5 Problems with infrastructure based authorization 1052 Early in the MIPv6 design process it was assumed that plain IPsec 1053 could be the default way to secure Binding Updates with arbitrary 1054 correspondent nodes. However, this turned out to be impossible. 1055 Plain IPsec relies on an infrastructure for key management, which, to 1056 be usable with any arbitrary pair of nodes, would need to be global 1057 in scope. Such a "global PKI" does not exist, nor is it expected to 1058 come into existence any time soon. 1060 Other more minor issues that also surfaced at the time were: (1) 1061 insufficient filtering granularity for the state of IPsec at the 1062 time, (2) cost to establish a security association (in terms of CPU 1063 and round trip times) and (3) expressing the proper authorization (as 1064 opposed to just authentication) for binding updates [11]. These 1065 issues are solvable, and, in particular, (1) and (3) have been 1066 addressed for IPsec usage with binding updates between the mobile 1067 node and the home agent [8]. 1069 But the lack of a global PKI remains unsolved. 1071 One way of providing a global key infrastructure for mobile IP could 1072 be DNSSEC. Such a scheme is not completely supported by the existing 1073 specifications, as it constitutes a new application of the KEY RR, 1074 something explicitly limited to DNSSEC [5]. Nevertheless, if one 1075 were to define it, one could proceed along the following lines: A 1076 secure reverse DNS that provided a public key for each IP address 1077 could be used to verify that a binding update is indeed signed by an 1078 authorized party. However, in order to be secure, each link in such 1079 a system must be secure. That is, there must be a chain of keys and 1080 signatures all the way down from the root (or at least starting from 1081 a trust anchor common to the mobile node and the correspondent node) 1082 to the given IP address. Furthermore, it is not enough that each key 1083 be signed by the key above it in the chain. It is also necessary 1084 that each signature explicitly authorize the lower key to manage the 1085 corresponding address block below. 1087 Even though it would be theoretically possible to build a secure 1088 reverse DNS infrastructure along the lines shown above, the practical 1089 problems would be daunting. Whereas the delegation and key signing 1090 might work close to the root of the tree, it would probably break 1091 down somewhere along the path to the individual nodes. Notice that a 1092 similar delegation tree is currently being proposed for Secure 1093 Neighbor Discovery [13], although in this case only routers (not 1094 necessarily every single potential mobile node) need to secure such a 1095 certificate. Furthermore, checking all the signatures on the tree 1096 would place a considerable burden on the correspondent nodes, making 1097 route optimization prohibitive, or at least justifiable only in very 1098 particular circumstances. Finally, it is not enough to simply check 1099 if the mobile node is authorized to send binding updates containing a 1100 given Home Address, because to protect against flooding attacks the 1101 care-of address must also be verified. 1103 Relying on this same secure DNS infrastructure to verify 1104 care-of-addresses would be even harder than verifying home addresses. 1105 Instead, a different method would be required, e.g., a return 1106 routability procedure. If so, the obvious question is whether the 1107 gargantuan cost of deploying the global secure DNS infrastructure is 1108 worth the additional protection it affords, as compared to simply 1109 using return routability for both home address and care-of address 1110 verification. 1112 4. The solution selected for Mobile IPv6 1114 The current Mobile IPv6 route optimization security has been 1115 carefully designed to prevent or mitigate the threats that were 1116 discussed in . The goal has been to produce a design whose 1117 security is close to that of a static IPv4 based Internet, and whose 1118 cost in terms of packets, delay and processing is not excessive. The 1119 result is not what one would expect: the result is definitely not a 1120 traditional cryptographic protocol. Instead, the result relies 1121 heavily on the assumption of an uncorrupted routing infrastructure, 1122 and builds upon the idea of checking that an alleged mobile node is 1123 indeed reachable both through its home address and its 1124 care-of-address. Furthermore, the lifetime of the state created at 1125 the corresponded nodes is deliberately restricted to a few minutes, 1126 in order to limit the potential ability of time shifting. 1128 In this section we describe the solution in reasonable detail (for 1129 further details see the specification), starting from Return 1130 Routability (Section 4.1), continuing with a discussion about state 1131 creation at the correspondent node (Section 4.2), and completing the 1132 description with a discussion about the lifetime of Binding Cache 1133 Entries (Section 4.3). 1135 4.1 Return Routability 1137 Return Routability (RR) is the name of the basic mechanism deployed 1138 by Mobile IPv6 route optimization security design. Basically, it 1139 means that a node verifies that there is a node that is able to 1140 respond to packets sent to a given address. The check yields false 1141 positives if the routing infrastructure is compromised or if there is 1142 an attacker between the verifier and the address to be verified. 1143 With these exceptions, it is assumed that a successful reply 1144 indicates that there is indeed a node at the given address, and that 1145 the node is willing to reply to the probes sent to it. 1147 The basic return routability mechanism consist of two checks, a Home 1148 Address check (see Section 4.1.1) and a care-of-address check (see 1149 Section 4.1.2). The packet flow is depicted in Figure 7. First the 1150 mobile node sends two packets to the correspondent node: a Home Test 1151 Init (HoTI) packet is sent through the home agent, and a Care-of Test 1152 Init (CoTI) directly. The correspondent node replies to both of 1153 these independently by sending a Home Test (HoT) in response to the 1154 Home Test Init and a Care-of Test (CoT) in response to the Care-of 1155 Test Init. Finally, once the mobile node has received both the Home 1156 Test and Care-of Test packets, it sends a Binding Update to the 1157 correspondent node. 1159 +------+ 1a) HoTI +------+ 1160 | |---------------------->| | 1161 | MN | 2a) HoT | HA | 1162 | |<----------------------| | 1163 +------+ +------+ 1164 1b) CoTI | ^ | / ^ 1165 | |2b| CoT / / 1166 | | | / / 1167 | | | 3) BU / / 1168 V | V / / 1169 +------+ 1a) HoTI / / 1170 | |<----------------/ / 1171 | CN | 2a) HoT / 1172 | |------------------/ 1173 +------+ 1175 Figure 7 1177 It might appear that the actual design was somewhat convoluted. That 1178 is, the real return routability checks are the message pairs < Home 1179 Test, Binding Update > and < Care-of Test, Binding Update >. The 1180 Home Test Init and Care-of Test Init packets are only needed to 1181 trigger the test packets, and the Binding Update acts as a combined 1182 routability response to both of the tests. 1184 There are two main reasons behind this design: 1185 avoidance of reflection and amplification (see Section 3.3.3), and 1186 avoidance of state exhaustion DoS attacks (see Section 4.2). 1188 The reason for sending two Init packets instead of one is the 1189 avoidance of amplication. The correspondent node does not know 1190 anything about the mobile node, and therefore it just suddenly 1191 receives an IP packet from some arbitrary IP address. In a way, this 1192 is similar to a server receiving a TCP SYN from a previously unknown 1193 client. If the correspondent node would send two packets in response 1194 to an initial trigger, that would create a DoS amplification effect, 1195 as discussed in Section 3.3.3. 1197 Reflection avoidance is directly related. If the correspondent node 1198 would reply to another address but the source address of the packet, 1199 that would create a reflection effect. Thus, since the correspondent 1200 node does not know better, the only safe way is to reply to the 1201 received packet with just one packet, and to send the reply to the 1202 source address of the received packet. Hence, two initial triggers 1203 are needed instead of just one. 1205 Let us now consider the two return routability tests separately. 1207 Below, the derivation of cryptographic material from each of these is 1208 shown in a simplified manner. For the real formulas and more detail, 1209 please refer to [7]. 1211 4.1.1 Home Address check 1213 The Home Address check consists of a Home Test (HoT) packet and a 1214 subsequent Binding Update (BU). It is triggered by the arrival of a 1215 Home Test Init (HoTI). A correspondent node replies to a Home Test 1216 Init by sending a Home Test to the source address of the Home Test 1217 Init. The source address is assumed to be the home address of a 1218 mobile node, and therefore the Home Test is assumed to be tunneled by 1219 the Home Agent to the mobile node. The Home Test contains a 1220 cryptographically generated token, home keygen token, which is formed 1221 by calculating a hash function over the concatenation of a secret key 1222 Kcn known only by the correspondent node, the source address of the 1223 Home Test Init packet, and a nonce. 1225 home keygen token = hash(Kcn | home address | nonce | 0) 1227 An index to the nonce is also included in the Home Test packet, 1228 allowing the correspondent node to easier find the appropriate nonce. 1230 The token allows the correspondent node to make sure that the 1231 subsequently received binding update is created by a node that has 1232 seen the Home Test packet; see Section 4.2. 1234 In most cases the Home Test packet is forwarded over two different 1235 segments of the Internet. It first traverses from the correspondent 1236 node to the Home Agent. On this trip, it is not protected and any 1237 eavesdropper on the path can learn its contents. The Home Agent then 1238 forwards the packet to the mobile node. This path is taken inside 1239 the IPsec ESP protected tunnel, making it impossible for the 1240 outsiders to learn the contents of the packet. 1242 At first it may sound unnecessary to protect the packet between the 1243 home agent and the mobile node since it travelled unprotected between 1244 the correspondent node and the mobile node. If all links in the 1245 Internet were equally insecure, the situation would indeed be so, 1246 that would be unnecessary. However, in most practical settings the 1247 network is likely to be more secure near the Home Agent than near the 1248 Mobile Node. For example, if the home agent hosts a virtual home 1249 link and the mobile nodes are never actually at home, an eavesdropper 1250 should be close to the correspondent node or on the path between the 1251 correspondent node and the home agent, since it could not eavesdrop 1252 at the home agent. If the correspondent node is a big server, all 1253 the links on the path between it and the Home Agent are likely to be 1254 fairly secure. On the other hand, the Mobile Node is probably using 1255 wireless access technology, making it sometimes trivial to eavesdrop 1256 its access link. Thus, it is fairly easy to eavesdrop packets that 1257 arrive at the mobile node. Consequently, protecting the HA-MN path 1258 is likely to provide real security benefits even when the CN-HA path 1259 remains unprotected. 1261 4.1.2 Care-of-Address check 1263 From the correspondent node's point of view, the Care-of check is 1264 very similar to the Home check. The only difference is that now the 1265 source address of the received Care-of Test Init packet is assumed to 1266 be the care-of-address of the mobile node. Furthermore, the token is 1267 created in a slightly different manner in order to make it impossible 1268 to use home tokens for care-of tokens or vice versa. 1270 care-of keygen token = hash(Kcn | care-of address | nonce | 1) 1272 The Care-of Test traverses only one leg, directly from the 1273 correspondent node to the mobile node. It remains unprotected all 1274 along the way, making it vulnerable to eavesdroppers near the 1275 correspondent node, on the path from the correspondent node to the 1276 mobile node, or near the mobile node. 1278 4.1.3 Forming the first Binding Update 1280 When the mobile node has received both the Home Test and Care-of Test 1281 messages, it creates a binding key Kbm by taking a hash function over 1282 the concatenation of the tokens received. 1284 This key is used to protect the first and the subsequent binding 1285 updates, as long as the key remains valid. 1287 Note that the key Kbm is available to anyone that is able to receive 1288 both the Care-of Test and Home Test messages. However, they are 1289 normally routed through different routes through the network, and the 1290 Home Test is transmitted over an encrypted tunnel from the home agent 1291 to the mobile node (see also Section 5.4). 1293 4.2 Creating state safely 1295 The correspondent node may remain stateless until it receives the 1296 first Binding Update. That is, it does not need to record receiving 1297 and replying to the Home Test Init and Care-of Test Init messages. 1298 The Home Test Init/Home Test and Care-of Test Init/Care-of Test 1299 exchanges take place in parallel but independently from each other. 1300 Thus, the correspondent can respond to each message immediately and 1301 it does not need to remember doing that. This helps in potential 1302 Denial-of-Service situations: no memory needs to be reserved when 1303 processing Home Test Init and Care-of Test Init messages. 1304 Furthermore, Home Test Init and Care-of Test Init processing is 1305 designed to be lightweight, and it can be rate limited if necessary. 1307 When receiving a first binding update, the correspondent node goes 1308 through a rather complicated procedure. The purpose of this 1309 procedure is to ensure that there is indeed a mobile node that has 1310 recently received a Home Test and a Care-of Test that were sent to 1311 the claimed home and care-of-addresses, respectively, and to make 1312 sure that the correspondent node does not unnecessarily spend CPU or 1313 other resources while performing this check. 1315 Since the correspondent node does not have any state when the binding 1316 update arrives, the binding update itself must contain enough 1317 information so that relevant state can be created. The binding 1318 update contains the following pieces of information for that: 1319 The care-of address specified in the Binding Update must be equal 1320 to the source address used in the Care-of Test Init message. 1321 Notice that this applies to the effective Care-of Address of the 1322 Binding Update. In particular, if the Binding Update includes an 1323 Alternate Care-of Address (AltCoA) [7], the effective CoA is, of 1324 course, this AltCoA. Thus, the Care-of Test Init must have 1325 originated from the AltCoA. 1326 The home address specified in the Binding Update must be equal to 1327 the source address used in the Home Test Init message. 1328 These are copied over from the Home Test and Care-of Test 1329 messages, and together with the other information they allow the 1330 correspondent node to re-create the tokens sent in the Home Test 1331 and Care-of Test messages and used for creating Kbm. Without them 1332 the correspondent node might need to try the 2-3 latest nonces, 1333 leading to unnecessary resource consumption. 1334 The binding update is authenticated by computing a MAC function 1335 over the care-of-address, the correspondent node's address and the 1336 binding update message itself. The MAC is keyed with the key Kbm. 1338 Given the addresses, the nonce indices and thereby the nonces, and 1339 the key Kcn, the correspondent node can re-create the home and 1340 care-of tokens at the cost of a few memory lookups and computation of 1341 one MAC and one hash function. 1343 Once the correspondent node has re-created the tokens, it hashes the 1344 tokens together, giving the key Kbm. If the Binding Update is 1345 authentic, Kbm is cached together with the binding. This key is then 1346 used to verify the MAC that protects integrity and origin of the 1347 actual Binding Update. Note that the same Kbm may be used for a 1348 while, until either the mobile node moves (and needs to get a new 1349 care-of-address token), the care-of token expires, or the home token 1350 expires. 1352 4.2.1 Retransmissions and state machine 1354 Note that since the correspondent node may remain stateless until it 1355 receives a valid binding update, the mobile node is solely 1356 responsible for retransmissions. That is, the mobile node should 1357 keep sending the Home Test Init / Care-of Test Init messages until it 1358 receives a Home Test / Care-of Test, respectively. Similarly, it may 1359 need to send the binding update a few times in the case it is lost 1360 while in transit. 1362 4.3 Quick expiration of the Binding Cache Entries 1364 A Binding Cache Entry, along the key Kbm, represents the return 1365 routability state of the network at the time when the Home Test and 1366 Care-of Test messages were sent out. Now, it is possible that a 1367 specific attacker is able to eavesdrop a Home Test message at some 1368 point of time but not later. If the Home Test had an infinite or a 1369 long lifetime, that would allow the attacker to perform a time 1370 shifting attack (see Section 2.2). That is, in the current IPv4 1371 architecture an attacker at the path between the correspondent node 1372 and the home agent is able to perform attacks only as long as the 1373 attacker is able to eavesdrop (and possibly disrupt) communications 1374 on that particular path. A long living Home Test, and consequently 1375 the ability to send valid binding updates for a long time, would 1376 allow the attacker to continue its attack even after the attacker is 1377 not any more able to eavesdrop the path. 1379 To limit the seriousness of this and other similar time shifting 1380 threats, the validity of the tokens is limited to a few minutes. 1381 This effectively limits the validity of the key Kbm and the lifetime 1382 of the resulting binding updates and binding cache entries. 1384 While short life times are necessary given the other aspects of the 1385 security design and the goals, they are clearly detrimental for 1386 efficiency and robustness. That is, a Home Test Init / Home Test 1387 message pair must be exchanged through the home agent every few 1388 minutes. These messages are unnecessary from a pure functional point 1389 of view, thereby representing overhead. What is worse, though, is 1390 that they make the home agent a single point of failure. That is, if 1391 the Home Test Init / Home Test messages were not needed, the existing 1392 connections from a mobile node to other nodes could continue even 1393 when the home agent fails, but the current design forces the bindings 1394 to expire after a few minutes. 1396 This concludes our walkthrough of the selected security design. The 1397 cornerstones of the design were the employment of the return 1398 routability idea in the Home Test, Care-of Test and binding update 1399 messages, the ability to remain stateless until a valid binding 1400 update is received, and the limiting of the binding life times to a 1401 few minutes. Next we briefly discuss some of the remaining threats 1402 and other problems inherent to the design. 1404 5. Security considerations 1406 In this section we give a brief analysis of the security design, 1407 mostly in the light of what was know at the time the design was 1408 completed in fall 2002. It should be noted that this section does 1409 not present a proper security analysis of the protocol, but merely 1410 discusses a few issues that were known at the time the design was 1411 completed. 1413 It should be kept in mind that the MIPv6 RO security design was never 1414 intended to be fully secure. Instead, as we stated earlier, to goal 1415 was to be roughly as secure as non-mobile IPv4 was known to be at the 1416 time of the design. As it turns out, the result is slightly less 1417 secure than IPv4, but the difference is small and most likely to be 1418 insignificant in real life. 1420 The known residual threats as compared with IPv4 are discussed in 1421 Section 5.1. Considerations related to the application of IPsec to 1422 authorize route optimization are discussed in Section 5.2. Section 1423 5.3 discusses an attack against neighboring nodes. Finally, Section 1424 5.4 deals with the special case of two mobile nodes conversing and 1425 performing the route optimization procedure with each other. 1427 5.1 Residual Threats as Compared to IPv4 1429 As we mentioned in Section 4.2, the lifetime of a binding represents 1430 a potential time shift in an attack. That is, an attacker that is 1431 able to create a false binding is able to reap the benefits of the 1432 binding as long as the binding lasts, or, alternatively, is able to 1433 delay a return-to-the-home flooding attack (Section 3.2.2) until the 1434 binding expires. This is a difference from IPv4 where an attacker 1435 may continue an attack only as long as it is at the path between the 1436 two hosts. 1438 Since the binding lifetimes are severely restricted in the current 1439 design, the ability to do a time shifting attack is respectively 1440 restricted. 1442 Threats possible because of the introduction of route optimization 1443 are, of course, not present in a baseline IPv4 internet (Section 1444 3.3). In particular, inducing unnecessary binding updates could 1445 potentially be a severe attack, but this would be more due to faulty 1446 implementations. As an extreme measure, a correspondent node can 1447 protect against these attacks by turning off route optimization. If 1448 so, it becomes obvious that the only residual attack against which 1449 there is no clear-cut prevention (other than its severe limitation as 1450 currently specified) is the time shifting attack mentioned above. 1452 5.2 Interaction with IPsec 1454 A major motivation behind the current binding update design was 1455 scalability, the ability to run the protocol without any existing 1456 security infrastructure. An alternative would have been to rely on 1457 existing trust relationships, perhaps in the form of a special 1458 purpose Public Key Infrastructure and IPsec. That would have limited 1459 scalability, making route optimization available only in environments 1460 where it is possible to create appropriately authorized IPsec 1461 security associations between the mobile nodes and the corresponding 1462 nodes. 1464 There clearly are situations where there exists an appropriate 1465 relationship between a mobile node and the correspondent node. For 1466 example, if the correspondent node is a server that has 1467 pre-established keys with the mobile node, that would be the case. 1468 However, entity authentication or an authenticated session key is not 1469 necessarily sufficient for accepting Binding Updates. 1471 Home Address Check: If one wants to replace the home address check 1472 with cryptographic credentials, these must carry proper 1473 authorization for the specific home address, and care must be 1474 taken to make sure that the issuer of the certificate is entitled 1475 to express such authorization. At the time of the design work, 1476 the route optimization security design team was not aware of 1477 standardized certificate formats to do this, although more recent 1478 efforts within the IETF are addressing this issue. Notice that 1479 there is plenty of motivation to do so, as any pre-existing 1480 relationship with a correspondent node would involve the mobile 1481 node's home address (instead of any of its possible care-of 1482 addresses). Accordingly, the IKE exchange would most naturally 1483 run between the correspondent node and the mobile node's home 1484 address. This still leaves open the issue of checking the mobile 1485 node's care-of address. 1487 Care-of Address Check: As for the care-of address check, in 1488 practice, it seems highly unlikely that nodes could completely 1489 replace the care-of address check with credentials. Since the 1490 care-of addresses are ephemeral, in general it is very difficult 1491 for a mobile node to present credentials that taken at face value 1492 (by an arbitrary correspondent node) guarantee no misuse for, say, 1493 flooding attacks (Section 3.2). As discussed before, a 1494 reachability check goes a long way to alleviate such attacks. 1495 Notice that, as part of the normal protocol exchange, establishing 1496 an IPsec security association via IKE includes one such 1497 reachability test. However, as per the previous section, the 1498 natural IKE protocol exchange runs between the correspondent node 1499 and the mobile node's home address. Hence, another reachability 1500 check is needed to check the care-of address at which the node is 1501 currently reachable. If this address changes, such a reachability 1502 test is likewise necessary, and is included in ongoing work aimed 1503 at securely updating the node's current address. 1505 Nevertheless, the Mobile IPv6 base specification [7] does not specify 1506 how to use IPsec together with the mobility procedures between the 1507 mobile node and correspondent node. On the other hand, the 1508 specification is carefully written to allow the creation of the 1509 binding management key Kbm through some different means. 1510 Accordingly, where an appropriate relationship exists between a 1511 mobile node and a correspondent node, the use of IPsec is possible, 1512 and is, in fact, being pursued in more recent work. 1514 5.3 Pretending to be one's neighbor 1516 One possible attack against the security design is to pretend to be a 1517 neighboring node. To launch this attack, the mobile nodes 1518 establishes route optimization with some arbitrary correspondent 1519 node. While performing the return routability tests and creating the 1520 binding management key Kbm, the attacker uses its real home address 1521 but a faked care-of address. Indeed, the care-of address would be 1522 the address of the neighboring node on the local link. The attacker 1523 is able to create the binding since it receives a valid Home Test 1524 normally, and it is able to eavesdrop the Care-of Test as it appears 1525 on the local link. 1527 This attack would allow the mobile node to divert unwanted traffic 1528 towards the neighboring node, resulting in an flooding attack. 1530 However, this attack is not very serious in practice. Firstly, it is 1531 limited in the terms of location, since it is only possible against 1532 neighbors. Secondly, the attack works also against the attacker, 1533 since it shares the local link with the target. Thirdly, a similar 1534 attack is possible with Neighbor Discovery spoofing. 1536 5.4 Two mobile nodes talking to each other 1538 When two mobile nodes want to establish route optimization with each 1539 other, some care must be exercised in order not to reveal the reverse 1540 tokens to an attacker. In this situation, both mobile nodes act 1541 simultaneously in the mobile node and the correspondent node roles. 1542 In the correspondent node role, the nodes are vulnerable to attackers 1543 that are co-located at the same link. Such an attacker is able to 1544 learn both the Home Test and Care-of Test sent by the mobile node, 1545 and therefore it is able to spoof the location of the other mobile 1546 host to the neighboring one. What is worse is that the attacker can 1547 obtain a valid Care-of Test itself, combine it with the Home Test, 1548 and the claim to the neighboring node that the other node has just 1549 arrived at the same link. 1551 There is an easy way to avoid this attack. In the correspondent node 1552 role, the mobile node should tunnel the sent Home Test messages 1553 through its home agent. This prevents the co-located attacker from 1554 learning any valid Home Test messages. 1556 6. Conclusions 1558 In this document we have discussed the security design rationale for 1559 the Mobile IPv6 Route Optimization. We have tried to describe the 1560 dangers created by Mobile IP Route Optimization, the security goals 1561 and background of the design, and the actual mechanisms employed. 1563 We started the discussion with a background tour to the IP routing 1564 architecture the definition of the mobility problem. After that we 1565 covered the dimensions of the danger: the targets, the time shifting 1566 abilities, and the possible locations of an attacker. We outlined a 1567 number of identified threat scenarios, and discussed how they are 1568 mitigated in the current design. Finally, in Section 4 we gave an 1569 overview of the actual mechanisms employed, and the rational behind 1570 them. 1572 As far as we know today, the only significant difference between the 1573 security of an IPv4 internet and that of an internet with Mobile IPv6 1574 (and route optimization): time shifting attacks. Nevertheless, these 1575 are severely retricted in the current design. 1577 We have also briefly covered some of the known subtleties and 1578 shortcomings, but that discussion cannot be exhaustive. It is quite 1579 probable that new subtle problems will be discovered from the design. 1580 As a consequence, it is most likely that the design needs to be 1581 revised in the light of experience and insights. 1583 7. Acknowledgements 1585 Hesham Soliman for reminding us about the threat explained in Section 1586 5.3. Francis Dupont for first discussing the case of two mobile 1587 nodes talking to each other (Section 5.4) and sundry other comments. 1588 Pekka Savola for his help in Section 1.1.1. 1590 8 Informative References 1592 [1] Aura, T., Roe, M. and J. Arkko, "Security of Internet Location 1593 Management", Proc. 18th Annual Computer Security Applications 1594 Conference, pages 78-87, Las Vegas, NV USA, IEEE Press., 1595 December 2002. 1597 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 1598 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1600 [3] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1601 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1603 [4] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines 1604 and Philosophy", RFC 3439, December 2002. 1606 [5] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 1607 Record (RR)", RFC 3445, December 2002. 1609 [6] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1610 Networks", BCP 84, RFC 3704, March 2004. 1612 [7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 1613 IPv6", RFC 3775, June 2004. 1615 [8] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to 1616 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1617 Agents", RFC 3776, June 2004. 1619 [9] Chiappa, J., "Will The Real "End-End Principle" Please Stand 1620 Up?", date unknown. 1622 [10] Savage, S., Cardwell, N., Wetherall, D. and T. Anderson, "TCP 1623 Congestion Control with a Misbehaving Receiver", Computer 1624 Communication Review 29:5, 1999. 1626 [11] Nikander, P., "Denial-of-Service, Address Ownership, and 1627 Early Authentication in the IPv6 World", Security Protocols 9th 1628 International Workshop, Cambridge, UK, April 25-27 2001, LNCS 1629 2467, pages 12-26, Springer, 2002. 1631 [12] Chiappa, J., "Endpoints and Endpoint Names: A Proposed 1632 Enhancement to the Internet Architecture", date unknown. 1634 [13] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 1635 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 1636 (work in progress), April 2004. 1638 Authors' Addresses 1640 Pekka Nikander 1641 Ericsson Research Nomadic Lab 1642 JORVAS FIN-02420 1643 FINLAND 1645 Phone: +358 9 299 1 1646 EMail: pekka.nikander@nomadiclab.com 1648 Jari Arkko 1649 Ericsson Research Nomadic Lab 1651 Tuomas Aura 1652 Microsoft Research 1654 Gabriel Montenegro 1655 Sun Microsystems 1656 Montbonnot 38240 1657 France 1659 Phone: 1660 EMail: gab@sun.com 1662 Erik Nordmark 1663 Sun Microsystems 1665 Intellectual Property Statement 1667 The IETF takes no position regarding the validity or scope of any 1668 Intellectual Property Rights or other rights that might be claimed to 1669 pertain to the implementation or use of the technology described in 1670 this document or the extent to which any license under such rights 1671 might or might not be available; nor does it represent that it has 1672 made any independent effort to identify any such rights. Information 1673 on the procedures with respect to rights in RFC documents can be 1674 found in BCP 78 and BCP 79. 1676 Copies of IPR disclosures made to the IETF Secretariat and any 1677 assurances of licenses to be made available, or the result of an 1678 attempt made to obtain a general license or permission for the use of 1679 such proprietary rights by implementers or users of this 1680 specification can be obtained from the IETF on-line IPR repository at 1681 http://www.ietf.org/ipr. 1683 The IETF invites any interested party to bring to its attention any 1684 copyrights, patents or patent applications, or other proprietary 1685 rights that may cover technology that may be required to implement 1686 this standard. Please address the information to the IETF at 1687 ietf-ipr@ietf.org. 1689 Disclaimer of Validity 1691 This document and the information contained herein are provided on an 1692 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1693 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1694 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1695 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1696 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1697 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1699 Copyright Statement 1701 Copyright (C) The Internet Society (2004). This document is subject 1702 to the rights, licenses and restrictions contained in BCP 78, and 1703 except as set forth therein, the authors retain all their rights. 1705 Acknowledgment 1707 Funding for the RFC Editor function is currently provided by the 1708 Internet Society.