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