idnits 2.17.1 draft-aura-mipv6-bu-attacks-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 946: '... SHOULD implement the limit on resou...' RFC 2119 keyword, line 1000: '...ection mechanism MUST be implemented a...' RFC 2119 keyword, line 1004: '...ection mechanism SHOULD be implemented...' RFC 2119 keyword, line 1007: '...ection mechanism SHOULD be implemented...' RFC 2119 keyword, line 1010: '...imal implementations, MAY elect not to...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 614 has weird spacing: '...otocols are e...' -- 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 (February 2002) is 8106 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'KA98' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: 'MC01' is defined on line 1236, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AN97a' -- Possible downref: Non-RFC (?) normative reference: ref. 'ANL00' ** Obsolete normative reference: RFC 2409 (ref. 'HC98') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2373 (ref. 'HD98') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. 'JB99' ** Downref: Normative reference to an Experimental RFC: RFC 2522 (ref. 'KS99') ** Obsolete normative reference: RFC 2401 (ref. 'KA98') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. 'Mea99' == Outdated reference: A later version (-03) exists of draft-montenegro-sucv-02 -- Possible downref: Normative reference to a draft: ref. 'MC01' ** Obsolete normative reference: RFC 3041 (ref. 'ND01') (Obsoleted by RFC 4941) -- Possible downref: Normative reference to a draft: ref. 'NP01' -- Possible downref: Non-RFC (?) normative reference: ref. 'OR01' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-15 -- Possible downref: Normative reference to a draft: ref. 'Roe02' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sav02' -- Possible downref: Normative reference to a draft: ref. 'TO01' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Mobile IP Working Group T. Aura 3 INTERNET DRAFT Microsoft 4 Expires August 2002 J. Arkko 5 Ericsson 6 February 2002 7 MIPv6 BU Attacks and Defenses 8 draft-aura-mipv6-bu-attacks-01.txt 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), 15 its areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document overviews attacks against mobile and fixed IP nodes 32 by exploiting features of the Mobile IPv6 Route Optimization. Many 33 of the attacks can be prevented by authenticating the Mobile IPv6 34 Binding Updates (BU) but some cannot, some depend on the details of 35 the BU protocol, and some denial-of-service attacks specifically 36 take advantage of authentication mechanisms. The purpose of this 37 document is to help those involved in the design and 38 standardization of BU authentication protocols to understand the 39 attacks, to assess suggested protection mechanisms, and to choose 40 between different levels of protection. 42 Table of Contents 44 Status of This Memo...............................................1 45 Abstract..........................................................1 46 Table of Contents.................................................2 47 1. Introduction...................................................3 48 2. Attacks that Corrupt Routing Tables............................3 49 2.1 Spoofing Binding Updates (o).................................4 50 2.2 Attacks against Secrecy and Integrity (o)....................5 51 2.3 Basic Denial of Service Attacks (o)..........................5 52 2.4 Replaying and Blocking Binding Updates (o)...................6 53 2.5 Bombing CoA with Unwanted Data...............................6 54 2.6 Bombing HoA with unwanted data (*)...........................8 55 3. Authentication of Binding Updates..............................8 56 3.1 Public Key Authentication (o)................................9 57 3.2 Cryptographically Generated Addresses........................9 58 3.3 Return Routability for HoA and CoA (*)......................10 59 3.4 Assuming a safe route.......................................12 60 3.5 Two Independent Routes......................................13 61 3.6 Leap of Faith...............................................14 62 3.7 The Role of Ingress Filtering (o)...........................14 63 4. DoS Attacks against BU Authentication.........................15 64 4.1 Inducing Unnecessary Binding Updates........................15 65 4.2 Consuming Authentication Resources..........................16 66 4.3 Forcing Non-Optimized Routing (o)...........................17 67 4.4 Reflection and Amplification (*)............................17 68 5. Preventing Resource Exhaustion................................18 69 5.1 Delaying Commitment.........................................18 70 5.2 Controlling Damage..........................................20 71 5.3 Favoring Regular Customers..................................20 72 6. The Right Level of Protection.................................21 73 6.1 Prioritizing the Goals (*)..................................21 74 6.2 Multiple Levels of Authentication (*).......................22 75 7. Security Considerations.......................................24 76 8. Conclusions...................................................25 77 Acknowledgments..................................................25 78 References.......................................................25 79 Authors' Addresses............................................27 80 1. Introduction 82 This document describes attacks against Mobile IPv6 [JP01] Route 83 Optimization and related protection mechanisms. The goal of the 84 attacker can be to corrupt the correspondent host's routing table 85 (the Binding Cache) and to cause packets to be routed to a wrong 86 address. This can compromise secrecy and integrity of communication 87 and cause denial-of-service (DoS) both at the communicating parties 88 and at the address that receives the unwanted packets. The attacker 89 may also exploit features of a Binding Update (BU) protocol to 90 exhaust the resources of either the mobile or the correspondent. 91 The aim of this document is to describe the major attacks and to 92 overview various protocol mechanisms and their limitations. 94 In particular, we want to make known several attacks which should 95 be considered when designing a protocol for authenticating BUs but 96 which have only lately received attention at the Working Group 97 (e.g. they were not mentioned in [MPH+01]). First, data flows can 98 be redirected to flood a third party who is not taking part in the 99 BU protocol (Sec. 2.5 -2.6 ). Second, some proposed BU 100 authentication protocols can be broken by attackers located on the 101 route from the correspondent to the Home Agent (Sec. 3.5 ). Third, 102 an attacker can consume the resources of any mobile or 103 correspondent by inducing authentic but unnecessary Binding Updates 104 (Sec. 4.1 ). 106 It is essential to understand that some of the threats are more 107 serious than others, some can be mitigated but not removed, and 108 some may be acceptable or too expensive to prevent. There are also 109 various security mechanisms that provide different levels of 110 guarantees for different security properties. We are particularly 111 interested in mechanisms that allow authentication between 112 arbitrary Internet nodes without pre-established trust 113 relationships, public-key infrastructure (PKI), or trusted third 114 parties (TTP). This means that some compromises must be made. The 115 question for the protocol designer is, which design choices give an 116 acceptable level of protection at an acceptable cost. Our goal is 117 to help answering this question. 119 We have marked with (o) the sections that contain only well-known 120 material, which most readers are likely to be familiar with but 121 which is included for completeness. Sections with major changes or 122 additions since the previous version have been marked with a star 123 (*). 125 2. Attacks that Corrupt Routing Tables 127 Route optimization and Binding Updates create a new opportunity for 128 attackers. By sending false BUs, they can create false entries in 129 the correspondent host's Binding Cache and, thus, reroute IP 130 packets to wrong destinations. If the data in the packets is not 131 protected cryptographically, this can lead to compromise of secrecy 132 and integrity. The attacker may also cause denial-of-service by 133 keeping data from arriving at the right destination and by bombing 134 a target host or network with unwanted data. 136 We consider only active attackers. The rationale behind this is 137 that in order to corrupt a routing table, the attacker must sooner 138 or later send one or more messages. Thus, it makes little sense to 139 consider attackers that only observe messages but do not send any. 140 In fact, the active attacks are easier to for the average attacker 141 than passive ones would be. In most active attacks, the attacker 142 can initiate the BU protocol execution at any time while more 143 passive attacks would require the attacker to wait for suitable 144 messages to be sent by the targets hosts. 146 2.1 Spoofing Binding Updates (o) 148 If Binding Updates are not authenticated, an attacker can send 149 spoofed BUs. All Internet hosts are vulnerable to this attack 150 because they all must support the correspondent functionality. 151 There is also no way of telling which addresses belong to mobile 152 hosts that really could send BUs. Consider an IP host A sending IP 153 packets to another IP host B. The attacker can redirect the packets 154 to an arbitrary address C by sending to A a Binding Update where 155 the home address (HoA) is B and the care-of address (CoA) is C. 156 After receiving this BU, A will send all packets intended for B to 157 the address C. 159 The attacker may select the CoA to be either its own current 160 address (or another address in its local network) or any other IP 161 address. If the attacker selects a local CoA where it can receive 162 packets, it will be able to send further packets to a 163 correspondent, which the correspondent believes to be coming from 164 the mobile. Ingress filtering at the attacker's local network does 165 not prevent the spoofing of Binding Updates but forces the attacker 166 either to choose a CoA from inside its own network or to use the 167 Alternate CoA sub-option. This may make it easier for the attack 168 targets to selectively filter the spurious BUs at a firewall. 170 The correspondent stores the HoA-CoA pair in its Binding Cache. The 171 attacker needs to send a new BU every few minutes to refresh the 172 cache entry. 174 The attacker needs to know or guess the IP addresses of both the 175 sender and receiver. This means that it is difficult to redirect 176 all packets to or from a host because the attacker would need to 177 know the IP addresses of all the hosts with which it is 178 communicating. Hosts with well-known addresses, such as servers and 179 those using stateless auto-configuration, are most vulnerable. 180 Hosts that are a part of the network infrastructure, such as DNS 181 servers, are particularly interesting targets for attackers. 183 Hosts with frequently changing random addresses and no DNS names 184 are relatively safe. However, hosts that visit publicly accessible 185 networks such as airport wireless LANs risk revealing their 186 addresses. IPv6 addressing privacy features [ND01] mitigate these 187 risks to an extent but it should be noted that addresses cannot be 188 completely recycled while there are still open sessions that use 189 those addresses. 191 2.2 Attacks against Secrecy and Integrity (o) 193 By spoofing Binding Updates, an attacker can redirect packets 194 between two IP hosts to itself. By sending a spoofed BU to A, it 195 can capture the data intended to B. It can pretend to be B and 196 highjack B's connections with A, or establish new spoofed 197 connections. The attacker can also send spoofed BUs to both A and B 198 and insert itself to the middle of all connections between them 199 (man-in-the-middle attack). Consequently, the attacker is able to 200 see and modify the packets sent between A and B. The attacks are 201 possible if the target host or its correspondent supports Route 202 Optimization and the attacker knows their IP addresses. 204 Strong encryption and integrity protection, such as authenticated 205 IPSec, can prevent all the attacks against data secrecy and 206 integrity. When the data is cryptographically protected, spoofed 207 BUs can result in denial of service but not in disclosure or 208 corruption of sensitive data beyond revealing the existence of the 209 traffic flows. Two fixed hosts could also protect communication 210 between themselves by refusing to accept BUs from each other. 211 Ingress filtering, on the other hand, does not help because the 212 attacker is using its own address as the CoA and is not spoofing 213 source IP addresses. 215 The attacks described above are a serious threat to the Internet 216 for two reasons. First, a lot of Internet traffic is unprotected. 217 Second, an attacker anywhere on the network can mount the attacks 218 against any Internet hosts, also non-mobile ones. If Binding 219 Updates did not exist, the attacker would need to be on the route 220 between the attack targets in order to listen to the traffic 221 between them. 223 2.3 Basic Denial of Service Attacks (o) 225 By sending spoofed BUs, the attacker can redirect all packets sent 226 between two IP hosts to a random or nonexistent address. This way, 227 it may be able to stop or disrupt communication between the hosts. 228 The requirements are that the target host or its correspondent must 229 support Route Optimization and the attacker must know their IP 230 addresses. 232 The attack is serious because any Internet host can be targeted, 233 also fixed hosts. Hosts belonging to the infrastructure necessary 234 for other hosts to communicate are also vulnerable. Again, two 235 hosts can protect the communication between themselves by refusing 236 BUs from each other or by establishing an authenticated IPSec 237 tunnel for the BUs. 239 2.4 Replaying and Blocking Binding Updates (o) 241 Any protocol for authenticating BUs will have to consider replay 242 attacks. That is, an attacker may be able to replay recent 243 authenticated BUs to the correspondent and, that way, direct 244 packets to the mobile host's previous location. Like spoofed BUs, 245 this can be used both for capturing packets and for DoS. The 246 attacker can capture the packets and impersonate the mobile node if 247 it reserves the mobile's previous address after the mobile has 248 moved away and then replays the previous BU to redirect packets 249 back to the previous location. 251 The replays are a concern if a timestamps are used for checking the 252 freshness of BUs and the mobile is moving so frequently that it 253 sends the next BU before the timestamp in the previous BU has 254 expired. Sequence numbers in authenticated BUs usually prevent the 255 attack. The authentication protocol needs to be is carefully 256 designed to avoid more complex replay attacks. 258 In a related attack, the attacker blocks binding updates from the 259 mobile at its new location, e.g. by jamming the radio link or by 260 mounting a flooding attack, and takes over its connections at the 261 old location. The attacker will be able to capture the packets sent 262 to the mobile and to impersonate the mobile until the 263 correspondent's Binding Cache entry expires. 265 Both of the above attacks require the attacker to be on the same 266 local network with the mobile, where it can relatively easily 267 observe packets and block them even if the mobile does not move to 268 a new location. Therefore, we believe that these attacks are not as 269 serious as ones that can be mounted from remote locations. 271 2.5 Bombing CoA with Unwanted Data 273 By sending spoofed BUs, the attacker can redirect traffic to an 274 arbitrary IP address. This can be used to bomb an arbitrary 275 Internet address with excessive amounts of data. The attacker can 276 also target a network by redirecting data to one or more IP 277 addresses within the network. 279 In the simplest attack, the attacker knows that there is a heavy 280 data stream from host A to B and redirects this to the target 281 address C. A will soon stop sending the data because it is not 282 receiving acknowledgments from B. 284 A more sophisticated attacker acts itself as B. It first subscribes 285 to a data stream (e.g. a video stream from a news web site) and 286 then redirects this to the target address C. The attacker may even 287 be able to spoof the acknowledgements. For example, consider a 288 constant-rate TCP stream. The attacker performs the TCP handshake 289 itself and thus knows the initial sequence numbers. After 290 redirecting the data to C, it suffices to send one spoofed 291 acknowledgment per window. In a constant-rate stream, the attacker 292 is able to predict the sequence numbers, the window size, and the 293 right times for sending the acknowledgments. This way, the attacker 294 is able to redirect a steady stream of unwanted data to the target 295 address without doing much work itself. It can carry on opening 296 more streams and refresh the Binding Cache entries by sending a new 297 BU every few minutes. 299 (TCP provides some protection against this attack: If C is the 300 address of a real host, it will respond with TCP Reset, which 301 should prompt A to close the connection. On the other hand, if C is 302 a non-existent address, A will receive both the spoofed 303 acknowledgments and ICMP Destination Unreachable messages. 304 Depending on the implementation, A may ignore the error messages. 305 Other transport-layer protocols might behave less gracefully.) 307 The attack is serious because the target can be any host or 308 network, not only mobile one. What makes it particularly serious 309 compared to the other attacks is that the target itself cannot do 310 anything to prevent the attack. For example, it does not help if 311 the target network stops using Route Optimization. The damage is 312 the worst if these techniques are used to amplify the effect of a 313 distributed denial of service (DDoS) attack. Ingress filtering in 314 the attacker's local network prevents the spoofing of source 315 addresses but the attack is still possible by setting the Alternate 316 CoA sub-option to the target address. 318 The attacker needs to find a correspondent that is willing to send 319 data streams to unauthenticated recipients. Many popular web sites 320 provide such streams. If the target is a single host, the attacker 321 needs to know or guess the target's IP address. On the other hand, 322 if the target is an entire network, the attacker can congest the 323 link toward that network by bombing random addresses within its 324 routing prefix or group of prefixes. In some cases, a firewall on 325 the border of the target network may be able filter out data that 326 is sent to nonexistent addresses. Whether this is possible depends 327 on the way that the addresses within that network are managed. It 328 seems likely that IPv6 addressing privacy features would preclude 329 such filtering in the general case. 331 2.6 Bombing HoA with unwanted data (*) 333 A variation of the bombing attack targets the HoA instead of the 334 CoA. The attacker claims to be a mobile with the HoA equal to the 335 target address. It starts downloading a data stream. The attacker 336 then sends a BU cancellation (i.e. a request to delete the binding 337 from the Binding Cache), or allows the cache entry to expire, which 338 redirects the data stream to the HoA. Just like when bombing the 339 CoA, the attacker can keep the stream alive by spoofing 340 acknowledgments. 342 When BUs are not authenticated, the attacker can choose an 343 arbitrary address as the HoA and thus target any Internet node. BU 344 authentication usually limits the attacker's choice of target 345 address but care must be taken when designing the protocol. For 346 example, one draft protocol verified the correctness of HoA (using 347 a return routability test, see Sec. 3.3 ) only when a Binding Cache 348 entry was created. This would allow the attacker to target any 349 network where it has once owned an address, e.g. a public access 350 LAN. A limit on the Binding Cache entry lifetimes or more frequent 351 verification of HoA virtually prevents the attacks. 353 When successful, the bombing attack against HoA is just as serious 354 as the one against CoA. One mechanism is not usually enough to 355 prevent both types of bombing attacks and they should be considered 356 separately when designing a BU authentication protocol. 358 3. Authentication of Binding Updates 360 In order to prevent the corruption of correspondent routing tables, 361 the Binding Updates must be authenticated. The two first 362 subsections (Sec. 3.1 -3.2 ) discuss relatively strong, public-key 363 authentication methods. The later subsections go into progressively 364 weaker authentication methods that would be labeled as insecure in 365 the traditional black-and-white network security thinking. 366 Nevertheless, some of them (Sec. 3.3 -3.4 ) do provide well-defined 367 levels of assurance in the real networks and can complement or even 368 replace the stronger methods. The motivation is that instead of 369 trying to prevent all attacks, the best strategy is often to limit 370 the number of potential attackers that can attack a particular 371 target, and to reduce the number of targets a potential attacker 372 can threaten. In particular, limiting the number of attackers is 373 essential in defending against denial-of-service attacks on the 374 Internet because it is rarely possible to entirely prevent these 375 attacks. 377 The current authors regard the cryptographically generated 378 addresses (Sec. 3.2 ) and return routability tests (Sec. 3.3 ) as 379 the most promising solutions for BU authentication. In situations 380 where public-key cryptography is considered too expensive, the best 381 solution may be be to assume a safe network route (Sec. 3.4 ). 383 3.1 Public Key Authentication (o) 385 An obvious solution to Mobile IPv6 authentication would be to use a 386 suite of strong generic authentication mechanisms such as IPSec, 387 IKE, and a PKI. The current lack of a standard BU authentication 388 protocol can thus be seen as a consequence of the commercial 389 failure of PKIs and the slow pace of the IPSec standardization 390 process. 392 There are, however, other reasons (than unavailability) why the 393 generic protocol suites may not be good for BU authentication. 394 First, the generic authentication protocols have usually been 395 designed with general-purpose computers and application-level 396 security in mind. The computation and communication overhead of 397 these protocols may be too high for low-end mobile devices and for 398 a network-level signaling protocol. Second, the Mobile IPv6 399 protocol is carefully designed to accommodate any Internet host as 400 mobile and all hosts as correspondents. This means that a single 401 PKI should cover the entire Internet, which is clearly a formidable 402 goal when even local infrastructures have failed to emerge at the 403 expected rate. Therefore, it is necessary to look for alternative 404 solutions that do not rely on such global infrastructures. 406 There are nevertheless situations where it is possible, and 407 advisable, to apply the generic authentication solutions. In closed 408 user groups and high-security environments, it may be possible to 409 set up a PKI and require BUs to be strongly authenticated. 411 3.2 Cryptographically Generated Addresses 413 A recently discovered technique provides an intermediate level of 414 security below strong public-key authentication and above routing- 415 based weak methods (which will be described in the following 416 sections). The idea, originally introduced in a BU authentication 417 protocol called CAM [OR01], is to form the last 64 bits of the IP 418 address (the interface identifier) by hashing the host's public 419 signature key. Binding Updates can then be signed with this key. A 420 secure one-way hash function makes it difficult for the attacker to 421 come up with a key that matches a given address and to forge signed 422 BUs. The attraction of this technique is that it provides public- 423 key authentication independent of any trusted third parties, PKI, 424 or other global infrastructure. 426 The main weakness of the scheme is that only 62-64 bits of the IP 427 address can be used for the hash. Thus, an attacker may be able to 428 mount a brute force attack and find a matching signature key by 429 trial and error. It is relatively expensive to generate strong 430 signature keys but the attacker does not need to care about the 431 strength of the keys. There may be relatively fast ways of 432 generating weak signature keys, which the correspondent may not 433 able to tell apart from strong ones. In order to make such brute- 434 force attacks less attractive, one should include the routing 435 prefix of the network into the hash. This forces the attacker to 436 perform the search separately for each prefix. Without this, a 437 global table of all hash values and their corresponding keys might 438 become feasible in the future, even if that seems out of practical 439 reach given current storage technology. A mechanism for generating 440 new public keys and changing addresses at regular intervals should 441 also discourage brute-force attacks against individual hosts. 443 Another limitation of the cryptographically generated addresses 444 (CGA) is that although they prevent the theft of another host's 445 address, they do not stop the attacker from inventing new false 446 addresses with an arbitrary routing prefix. The attacker can 447 generate a public key and a matching IP address in any network and 448 use it to mount bombing attacks (as described in Sec. 2.5 -2.6 ). 450 While the public-key protocols (both PKI-based and CGA-based ones) 451 provide a reasonable protection against unauthentic BUs, they are 452 computationally intensive and therefore expose the participants to 453 denial-of-service attacks (see Sec. 4.1 -4.2 ). 455 3.3 Return Routability for HoA and CoA (*) 457 One way to limit the number of attackers and their targets is to 458 test the return routability (RR) of the HoA and CoA. That is, the 459 correspondent sends packets to both addresses and accepts Binding 460 Updates only from mobiles that are able to receive them. Some 461 malicious entities (e.g. ones on the correspondent's local network) 462 may be able to capture one or both packets but most Internet users 463 do not have such capabilities. A typical attacker is able to attack 464 only the correspondents in its own local network. The RR test is, 465 in fact, a variation of the cookie exchange, which has been used as 466 part of the TCP handshake [SKK+97] and in authentication protocols, 467 including Photuris [KS99] and IKE [HC98]. 469 Arguments have been made as to whether the RR test should be done 470 for HoA, CoA, or both. In the following, we will explain what kind 471 of attacks each test prevents and conclude that both tests are 472 needed. 474 The RR test for HoA can be seen as a weaker alternative to CGA or 475 other public-key authentication. In order to subvert the 476 authentication, the attacker must be on the route between the 477 correspondent and the HoA. But as we will see below, the 478 routability test for HoA provides other guarantees in addition to 479 mobile authentication, which make it is complementary, rather than 480 alternative, to CGA authentication. 482 The RR for CoA prevents the bombing of third parties at CoA (Sec. 483 2.5 ). The attacker has to be able to receive the packet sent to 484 the CoA, which means that the attacker must have recently visited 485 the target network. This is a way of checking that the mobile is 486 not lying about its location. Thus, the test has to be repeated 487 every time the mobile moves to a new location. This provides a 488 level of authentication but is not entirely secure because the 489 attacker could be somewhere on the path from the correspondent to 490 the CoA. 492 The bombing attacks against HoA (Sec. 2.6 ) gets around the RR test 493 for CoA (and other the defense mechanisms that somehow verify the 494 correctness the CoA). The first logical reaction to this would be 495 to verify the new location of the mobile no matter if it arrives to 496 a new CoA or to HoA. Unfortunately, it may be impossible to execute 497 a RR test for HoA when a Binding Cache entry is cancelled or 498 expires. The mobile may be unreachable at that time or it may 499 refuse to co-operate in the authentication protocol. 501 What makes the situation difficult is that if the RR test for HoA 502 fails, the correspondent cannot simply drop the cache entry because 503 that is exactly what the attacker would want. However, we believe 504 that it is desirable for the correspondent to be able to delete the 505 Binding Cache entry at any time without executing any further 506 protocols. Therefore, we suggest that the RR test for HoA should be 507 performed regularly during the lifetime of a Binding Cache entry. 508 That way, when the cache entry needs to be deleted for any reason 509 (e.g. BU cancellation, expiring cache entry, or failing 510 authentication), a recent RR test for HoA has always been 511 performed. This prevents bombing of HoA unless the attacker has 512 recently visited that address (or other on-path location where it 513 can receive packets from the correspondent to the HoA). 515 We propose the following guidelines for combining the mechanisms: 517 - Before creating a Binding Cache entry, do authenticated key 518 exchange with CGA, RR test for HoA, and RR test for CoA. 520 - Before a Binding Cache entry is updated with new CoA, do RR test 521 for CoA. 523 - Periodically do RR for HoA. The best time to do this is before 524 refreshing the Binding Cache entry with unchanged CoA but the 525 test must not be postponed indefinitely if the mobile changes 526 its CoA in every BU. (One way to implement this is to limit the 527 lifetime of Binding Cache entries.) 529 The RR test for HoA could executed be more frequently, e.g. every 530 few minutes, in protocols that rely on the RR test for 531 authentication and less often, e.g. every hour, with CGA 532 authentication. This is because CGA removes the need for the RR 533 authentication function and also prevents the bombing of individual 534 addresses. The benefit from such optimization is, however, limited, 535 because the cost of the RR test is lowest when the mobile is not 536 moving and the BU protocol can be executed in the background well 537 before the Binding Cache entry expires. It might, therefore, be 538 simplest to do both RR tests every time when the cache entry is 539 updated without changing CoA. 541 If the CGA authentication or one of RR tests fails, the 542 correspondent should ignore the Binding Update and allow the 543 Binding Cache entry expire. 545 Interestingly, there is an argument for doing RR for CoA in the 546 transport layer rather than in the IP layer. The flooding problem 547 is related to flow control: the correspondent is redirecting a data 548 flow into a new route and needs to verify that this route can 549 accept the data. For TCP streams, the natural solution would be to 550 reset the window size to the initial window size (1 or 2 packets). 551 This would, in effect, test return routability of the new route 552 before sending large amounts of data into it. However, mandating 553 secure RR testing in all transport protocols and changing existing 554 implementations would not be possible in practice. Therefore, the 555 best solution is to do the RR tests in the IP layer. 557 3.4 Assuming a safe route 559 Some proposed BU authentication protocols make the assumption that 560 the communication between two specific hosts is safe from 561 attackers, even though it is not cryptographically protected. For 562 example, the return routability test for HoA (Sec. 3.3 ) can 563 replace public-key authentication of the mobile if one is prepared 564 to assume that the route from the correspondent to the mobile's 565 Home Agent is secure. (Note that the RR test for HoA has two 566 separate functions: authentication of the mobile and protection of 567 the HoA against flooding.) 568 The assumption may be reasonable because the average Internet host 569 cannot listen to or modify packets on the specific routers. 570 Moreover, even an attacker in control of some routers can only 571 interfere with communication between a limited number of hosts 572 because most Internet traffic will not be routed through the 573 compromised routers. 575 The assumption can be justified also by the fact that an attacker 576 on the route between two fixed hosts (a mobile at home and a 577 correspondent) can mount equally damaging attacks against the 578 communication between them. 580 3.5 Two Independent Routes 582 Some weak BU authentication schemes have been proposed (Bake 583 [NP01], HA Cookies [TO01]) where the security essentially depends 584 on sending two pieces of the authentication data between the 585 correspondent and the mobile or its Home Agent through two 586 independent routes and hoping that most attackers are unable to 587 capture both of them. This may not help as much as has perhaps been 588 hoped. In all these protocols, a single attacker on the route 589 between the correspondent and Home Agent can spoof BUs by 590 pretending to be both the mobile and its Home Agent. If the 591 attacker uses its own address as the false CoA, it can spoof 592 packets from both the mobile and the Home Agent to the 593 correspondent, and it can receive messages sent by the 594 correspondent to both HoA and CoA. This means that the protocols 595 essentially make the same assumption about a single safe route as 596 we proposed in the previous section. 598 Without ingress filtering at the attacker's local network, the 599 attacker is, in fact, able to select an arbitrary CoA. Ingress 600 filtering at the attacker's network forces the attacker to use a 601 CoA from its local network. (The Alternate CoA sub-option could be 602 used to get around this.) Ingress filtering also prevents attacks 603 against the HA Cookie protocol because the attacker could not spoof 604 packets from Home Agent to the correspondent. 606 A false sense of security is created if one assumes that the three 607 sides of the triangle in MIPv6 triangle routing are independent 608 routes. This is usually the case for an authentic mobile, but need 609 not be true not for an attacker who claims to be the mobile. When 610 the false mobile (i.e. the attacker) is on the route between the 611 correspondent and the Home Agent, the triangle collapses. (When 612 thinking about the protocols one easily starts arguing in terms of 613 active and passive attackers. It is worth remembering here that all 614 attacks against BU protocols are essentially active, as we 615 explained at the beginning of Sec. 2.) 616 On the other hand, if one finds it reasonable to assume a safe 617 route, i.e. that the attacker cannot listen to traffic between the 618 correspondent and the Home Agent, then an equivalent level of 619 security is achieved by a much simpler protocol: the correspondent 620 sends a secret key in plaintext to HoA and Home Agent forwards it 621 through a secure tunnel to the mobile. (This is a variation of the 622 RR test for HoA.) We believe that however ridiculous this may 623 sound, it may sometimes be the best solution for BU authentication. 625 3.6 Leap of Faith 627 Yet another idea that has been floating around is that if the 628 mobile sends a session key insecurely to the correspondent at the 629 beginning of a connection, the key can be used to authenticate 630 subsequent BUs (so called leap-of-faith authentication). This is a 631 flawed proposition. It fails even if we assume that attacker is 632 unlikely to capture the keys sent by authentic mobiles. First, the 633 attacker can send its false key before the authentic mobile sends 634 the authentic key. Second, there must be a recovery mechanism for 635 situations where the mobile or the correspondent loses its state, 636 and the attacker can exploit this mechanism. 638 The leap-of-faith authentication is suitable for situations where a 639 human user, or some other factor outside the attacker's control, at 640 random times initiates the protocol. The party making the leap must 641 always be the one that initiates the protocol. In such situations, 642 it may be reasonable to argue that an attacker is unlikely to be 643 present at the time of the unauthenticated key exchange. In BU 644 authentication, the protocol is usually initiated by the mobile but 645 the leap in faith should be made by the correspondent. Also, the 646 attacker can trigger the BU protocol at any time by sending a 647 spoofed packet from the correspondent to the mobile's HoA. 649 3.7 The Role of Ingress Filtering (o) 651 Ingress filtering is another way of limiting the number of 652 potential attackers and their targets. As we have noted above, many 653 of the attacks against Route Optimization involve spoofed source IP 654 addresses and are, thus, prevented by ingress filtering. There are 655 two well-known weaknesses in this thinking, though. Firsts, ingress 656 filtering must be applied on the attacker's local network; on the 657 target network it makes no difference. Second, the Home Address 658 Option and the Alternate Care-of Address sub-option can be used for 659 similar source spoofing. While it is advisable to apply ingress 660 filtering in as many networks as possible, one cannot rely on this 661 to stop all attackers. 663 4. DoS Attacks against BU Authentication 665 Security protocols that successfully protect the secrecy and 666 integrity of data can sometimes make the participants more 667 vulnerable to denial-of-service attacks. In fact, the stronger the 668 authentication, the easier it may be for an attacker to use the 669 protocol features to exhaust the mobile's or the correspondent's 670 resources. 672 4.1 Inducing Unnecessary Binding Updates 674 When a mobile host receives an IP packet from a new correspondent 675 via the HoA, it automatically sends a Binding Update to that 676 correspondent. The attacker can exploit this by sending the mobile 677 spoofed IP packets (e.g. ping or TCP SYN packets) that appear to 678 come from different correspondent addresses. The attacker will 679 automatically start the BU protocol with these correspondents. If 680 the correspondent addresses are real addresses of existing IP 681 hosts, then most instances of the BU protocol will complete 682 successfully. The entries created in the Binding Cache are correct 683 but useless. This way, the attacker can with little work induce the 684 mobile to execute the BU protocol unnecessarily, which can drain 685 the mobile's resources. 687 A correspondent (i.e. any IP host) can also be attacked in a 688 similar way. The attacker sends spoofed IP packets to a large 689 number of mobiles with the target host's address as the source 690 address. These mobiles will all send Binding Updates to the target 691 host. Again, most of the BU protocol executions will complete 692 successfully. By inducing a large number of unnecessary BUs, the 693 attacker is able to consume the target host's resources. 695 This attack is possible against any BU authentication protocol. The 696 more resources the Binding Update protocol consumes, the more 697 serious the attack. Hence, strong cryptographic authentication 698 protocol is more vulnerable to the attack than a weak one or 699 unauthenticated BUs. 701 A host should protect itself from the attack by setting a limit on 702 the amount of resources, i.e. processing time, memory, and 703 communications bandwidth, which it uses for processing BUs. When 704 the limit is exceeded, the host can simply stop Route Optimization. 705 (See Sec. 5.2 .) Sometimes it is possible to process some BUs even 706 when a host is under the attack. A mobile host may have a local 707 security policy listing a limited number of addresses to which BUs 708 will be sent even when the mobile host is under DoS attack. A 709 correspondent (i.e. any IP host) may similarly have a local 710 security policy listing a limited set of addresses from which BUs 711 will be accepted even when the correspondent is under a DoS attack. 713 The host may also recognize addresses with which they have had 714 meaningful communication in the past and sent BUs to or accept them 715 from those addresses. 717 Ingress filtering at the attacker's local network mitigates the 718 attacks. When flooding a mobile, the attacker can only choose 719 correspondent addresses in its own local network. When flooding a 720 correspondent, the attacker can only target correspondents in its 721 own network. Unfortunately, the Home Address Option (HAO) can be 722 used to circumvent the ingress filtering and to spoof packets from 723 any correspondent. It has been questioned whether the HAO should be 724 allowed in all packets, or only on those that are associated with 725 an already successfully created Binding Cache Entry. The latter 726 would prevent the use of HAOs in DoS attacks against BU 727 authentication. 729 In the following section, we will explain some additional DoS 730 attacks and defense mechanisms. However, these attacks are 731 generally no more serious than the ones described in this section. 732 It usually does not pay to defend against the other types of 733 attacks unless one can also prevent the attacks of this section. 735 4.2 Consuming Authentication Resources 737 Authentication protocols are often vulnerable to flooding attacks 738 that exploit the protocol features to consume the target host's 739 resources. Computing power is consumed by flooding the host with 740 messages that cause it to perform expensive cryptographic 741 operations. If a host creates state during protocol execution, it 742 is also vulnerable to attacks where the attacker starts excessive 743 numbers of protocol runs and never finishes them. 745 In order to exhaust the computing power of modern processors, the 746 attacker needs to get them to perform public-key cryptographic 747 operations. To do this, they may, for example, spoof large numbers 748 of signed messages where the signatures are replaced by random 749 numbers. The target host must verify the signatures before 750 rejecting the messages. Symmetric encryption, cryptographic hash 751 functions, and non-cryptographic computation are rarely the 752 performance bottleneck. However, if the cryptographic library is 753 optimized only for bulk data, it may behave inefficiently when the 754 functions are invoked on millions of short messages and the keys 755 are changed on every invocation. 757 One way protocols can avoid the unnecessary public-key operations 758 is to require a weak authentication, such as a cookie exchange, 759 before doing the expensive computation. Attacks against stateful 760 protocols can be prevented by making the protocol parties stateless 761 until the honesty of the other participant has been proved or by 762 designing the stare management with flooding attacks in mind. (See 763 Sec. 5.1 .) 765 4.3 Forcing Non-Optimized Routing (o) 767 If the BUs are not authenticated, the attacker can prevent a 768 correspondent from using Route Optimization by filling its Binding 769 Cache with false entries so that most entries for real mobiles are 770 dropped. With authenticated BUs, the attacker can mount the same 771 attack by inducing unnecessary Binding Updates that create 772 authentic but unnecessary cache entries (see Sec. 4.1 ). 774 Any successful DoS attack against a mobile or a correspondent can 775 also prevent the processing of BUs. We have repeatedly suggested 776 that the target of a DoS attack may respond by stopping Route 777 Optimization for all or some communication. Obviously, an attacker 778 can exploit this fallback mechanism and force the target to use the 779 less efficient triangle routing. The attacker only needs to mount a 780 noticeable DoS attack against the mobile or correspondent, and the 781 target will default to non-optimized routing. 783 The target host can mitigate the effects of the attack by reserving 784 more space for the Binding Cache, by reverting to non-optimized 785 routing only when it cannot otherwise cope with the DoS attack, by 786 trying aggressively to return to optimized routing, and by favoring 787 mobiles with which it has an established relationship. This attack 788 is not as serious as the ones described earlier, but applications 789 that rely on Route Optimization could still be affected. For 790 instance, conversational multimedia sessions can suffer drastically 791 from the additional delays caused by triangle routing. 793 4.4 Reflection and Amplification (*) 795 Attackers sometimes try to hide the source of a packet flooding 796 attack by reflecting the traffic from other hosts [Sav02]. That is, 797 instead of sending the flood of packets directly to the target, the 798 attacker sends data to other hosts, tricking them to send the same 799 number, or more, packets to the target. Such reflection can hide 800 the attacker's address even when ingress filtering prevents source 801 address spoofing. Reflection is particularly dangerous if the 802 packets can be reflected multiple times, if they can be sent into a 803 looping path, or if the hosts can be tricked into sending many more 804 packets than they receive from the attacker, because such features 805 can be used to amplify the traffic by a significant factor. When 806 designing protocols, one should avoid creating services that can be 807 used for reflection and amplification. 809 Triangle routing easily creates opportunities for reflection: 810 Correspondent receives packets (e.g. TCP SYN) from the mobile and 811 replies to the home address given by the mobile (in a HAO). The 812 mobile might not really be a mobile and the HoA could actually be 813 the target address. The target at the HoA only sees the packets 814 sent by the correspondent and cannot see the attacker's address 815 (even if ingress filtering prevents the attacker from spoofing its 816 source address). 818 The BU protocol could also be used for reflection: the 819 correspondent responds to a data packet or to an unauthenticated BU 820 by initiating the BU authentication protocol, which usually 821 involves sending a packet to HoA. In that case, the reflection 822 attack can be discouraged by copying the mobile's address into the 823 messages sent by the mobile to the correspondent. (The mobile's 824 source address is usually the same as the CoA but an Alternative 825 CoA suboption can specify a different CoA.) 827 In some proposed BU authentication protocols (e.g. one we co- 828 authored [Roe02]), the correspondent responds to an initial message 829 from the mobile with two packets (one to HoA, one to CoA). This can 830 be used to amplify a flooding attack by a factor of two. 831 Furthermore, with public-key authentication, the packets sent by 832 the correspondent may be significantly larger than the one that 833 triggers them. 835 These types of reflection and amplification could be avoided by 836 ensuring that the correspondent only responds to the same address 837 from which it received a packet, and only with a single packet of 838 the same size. Depending on the BU protocol, this might require an 839 increased number of messages and a reverse tunneling mechanism for 840 sending packets from the mobile through the Home Agent to the 841 correspondent. The question that needs to be decided is whether the 842 cost of these protections is more acceptable than threat created by 843 a small constant factor of amplification. Padding could be used to 844 equalize the packet sizes although we believe this would be 845 unnecessary in practice. The mobile nodes usually have low- 846 bandwidth access links, which makes them vulnerable to flooding 847 attack, but high-value targets, such as public servers, rarely are 848 mobile. 850 5. Preventing Resource Exhaustion 852 In this section, we describe defenses against denial-of-service 853 attacks that exploit features of the BU protocol to exhaust the 854 target host's resources. As it usually is impossible to completely 855 prevent DoS attacks, the right approach is to increase the cost and 856 difficulty of the attacks and to mitigate their effects. 858 5.1 Delaying Commitment 859 A standard protection against DoS attacks is to delay committing 860 one's resources to the protocol until the other party has provided 861 some assurance about its honesty. This assurance could, for 862 example, be authentication or expensive computation of resources by 863 the other party. 865 Expensive public-key operations can be delayed by starting with a 866 weak but inexpensive authentication mechanism and by proceeding 867 with the public-key operations only after the weak authentication 868 succeeds [Mea99]. This either limits the number of attackers who 869 can get to the public-key stage or increases the cost of the attack 870 by forcing the attacker to break the weak mechanism. For example, a 871 BU authentication protocol could start with a cookie exchange or, 872 preferably, with a RR test for both HoA and CoA (see Sec. 3.3 ), 873 and continue with a public-key authentication only if the RR test 874 succeeds. 876 Memory space for storing protocol state is another resource that 877 attackers can exhaust. The conventional way to defeat attacks that 878 consume state storage is to reserve enough memory for storing the 879 state data and to manage the storage efficiently. Another method is 880 to remain stateless until the authentication is complete [AN97a]. 881 Hosts with little memory and implementations aiming for simplicity 882 are particularly likely to find the stateless approach easier. We 883 therefore recommend the that BU authentication protocol should 884 allow stateless implementation of the correspondent. On the other 885 hand, there is no compelling reason to require statelessness for 886 hosts that can manage the state data in other ways. 888 There are some difficulties in making the BU authentication 889 protocol stateless, which should be understood. The main difficulty 890 is that usually only the responder can be stateless, and it is not 891 clear which party initiates the Binding Update process and which 892 one responds. While the mobile normally initiates the 893 authentication, this may be triggered by a packet belonging to 894 another protocol that arrived from the correspondent. Moreover, if 895 a packet from the correspondent triggers the BU, the correspondent 896 may not know that this was the case. A further complication is that 897 once an upper layer protocol has created a protocol state, it is of 898 little value to refrain from doing so in the lower layers, but the 899 IP layer cannot know when this is happening. For simplicity, we 900 recommend making the correspondent stateless and advice against 901 trying to guess which party initiated the protocol and whether the 902 statelessness is necessary or not. We choose protection of the 903 correspondent over the mobile for two reasons. First, any Internet 904 host can be a correspondent. Second, it is less practical to make 905 the mobile stateless because the mobile usually does not 906 authenticate the correspondent and, thus, there is no clear point 907 after which it is safe to create a state. We acknowledge that the 908 mobile is likely to have more stringent memory constraints than the 909 correspondent and it may be left vulnerable to the state storage 910 exhaustion attacks. 912 Cryptographic puzzles [JB99][ANL00] are another proposed protection 913 against resource-exhaustion attacks. A server requires its clients 914 to solve a cryptographic puzzle (e.g. brute-force search for some 915 input bits of a one-way function) before committing its own 916 resources to the protocol. The server can adjust the difficulty of 917 the puzzles according to its load. Solving the puzzle creates a 918 small cost for each protocol invocation, which makes flooding 919 attacks expensive but has little effect on honest hosts. 920 Unfortunately, there are several drawbacks to this strategy in the 921 Mobile IPv6 protocol. First, the IP layer does not know which one 922 of the nodes, the mobile or the correspondent, is the server (i.e. 923 the respondent). Second, mobile nodes can have extremely limited 924 processor and battery capacity, which makes the cost of solving 925 puzzles too high for them, while an attacker pretending to be a 926 mobile is likely have much more computational capacity. The puzzle 927 protocols work well only when all clients have approximately equal 928 computational capacity. 930 5.2 Controlling Damage 932 As we suggested in Sec. 4.1 , a host can protect itself from 933 flooding attacks by limiting the amount of resources it uses for BU 934 authentication. It can set limits on the processor time, memory and 935 communications capacity used for this purpose. When this limit is 936 exceeded, the host should stop all further participation in BU 937 authentication protocols. It may stop processing BUs and let all 938 Binding Cache entries expire. Alternatively, it may continue to 939 update entries already in the Binding Cache if there is a light- 940 weight mechanism (e.g. a session key) for re-authenticating them. 941 The effect of this is to stop Route Optimization for all 942 communication, or only for new connections. The host may return to 943 normal operation when it believes the attack is over. 945 Since authentication cannot prevent all the attacks, every host 946 SHOULD implement the limit on resource usage. A host that does not 947 implement the limit will be vulnerable to flooding attacks but it 948 will not cause any damage to other hosts. 950 5.3 Favoring Regular Customers 952 A correspondent can give priority to mobiles with which it has a 953 long-term relationship or recent meaningful communication in the 954 upper protocols layers. The mobile may similarly favor selected 955 correspondent addresses. The best way to secure Binding Updates 956 when the hosts have a long-term relationship is to use an 957 authenticated IPSec tunnel. The following techniques should only be 958 used when it is not possible to configure an IPSec Security 959 Association. 961 A host's local policy may have a list of addresses or address 962 ranges, to and from which BUs are processed even when the host is 963 under stress from attacks. These should not include addresses for 964 which it is feasible to establish long-term IPSec Security 965 Associations. The list of addresses should not be large or public 966 because otherwise the attacker might be able to mount the attack by 967 using only these addresses. Taking into account authentication and 968 other displays of commitment in the upper protocol layers can be 969 difficult to implement because it violates the stateless nature of 970 the IP protocol layer and creates dependences between protocol 971 layers. In some common situations, it may be worth while to violate 972 the layering principle. For example, a Web server could accept BUs 973 from its clients after it has successfully executed the TCP 974 handshake. 976 It may also help to keep updating the existing entries in the 977 Binding Cache so that existing optimized routes can be maintained 978 during the attack, although it is not certain that the existing 979 cache entries belong to the most important mobiles or even to 980 authentic ones. Some indication of this may be inferred from the 981 packet counts associated with the traffic flowing through the 982 entry. 984 6. The Right Level of Protection 986 We will conclude this document by discussing the criteria that 987 should be used for selecting and comparing BU authentication 988 protocols and issues that arise when there are several alternative 989 protocols. 991 6.1 Prioritizing the Goals (*) 993 The strength of the protection against DoS attacks that do not 994 corrupt routing tables is independent of the strength of the BU 995 authentication. As we have observed, strong authentication 996 mechanisms may even enable DoS attacks that would not otherwise be 997 possible. Nevertheless, the following principles apply to all 998 attacks. 1000 - A protection mechanism MUST be implemented and used if security 1001 of other hosts or communication between other hosts depends on 1002 it (except in cases covered by the next bullet). 1004 - A protection mechanism SHOULD be implemented if communication 1005 between the host itself and others depends on it. 1007 - A protection mechanism SHOULD be implemented if only the host's 1008 own security depends on it. 1010 - Some hosts, e.g. minimal implementations, MAY elect not to 1011 protect themselves and their own connections against all the 1012 attacks as long as that does not compromise the protection for 1013 others. 1015 Since Route Optimization is an optimization, a host MAY always 1016 protect itself and others by ignoring all Binding Updates, which 1017 means giving up Route Optimization. A slightly smarter host MAY 1018 implement only the mandatory mechanisms that help protect others 1019 and stop using Route Optimization when it detects a DoS attack 1020 against itself. 1022 The most serious attack is the bombing of third parties with 1023 unwanted data (Sec. 2.5 -2.6 ) because they cannot do anything to 1024 stop the flood of data. All mobiles and correspondents MUST either 1025 implement and use some kind of protection against this attack, or 1026 ignore all Binding Updates and give up Route Optimization. 1028 Attacks against correspondent hosts that accept Binding Updates 1029 form the second most serious class of attacks. This includes 1030 attacks on data secrecy and integrity as well as denial-of-service 1031 attacks. Every IP host is a potential correspondent and if the 1032 Mobile IP protocol makes them vulnerable, then every IP host is 1033 vulnerable. It is important that reliable protection mechanisms are 1034 available for the correspondents and every IP host SHOULD implement 1035 and use these mechanisms to protect itself. If the protection for 1036 the correspondents requires support from mobiles, all mobile hosts 1037 MUST implement and use the supporting functionality. 1039 Finally, there are the attacks against the mobiles. As with 1040 correspondents, it is important to have protection mechanisms for 1041 the mobiles and they SHOULD be implemented and used. Any necessary 1042 supporting functionality in the correspondents MUST be implemented 1043 and used. Although attacks against mobile hosts cannot bring down 1044 the Internet as we know it, the number and significance of mobiles 1045 will increase. If Mobile IPv6 is to become the primary mobility 1046 protocol in the Internet, it is essential to protect its 1047 reliability against malicious parties. 1049 6.2 Multiple Levels of Authentication (*) 1051 The computational and communications capabilities of Internet hosts 1052 vary vastly, as does the level of security they require. It would, 1053 therefore, be desirable to have a range of BU authentication 1054 protocols with different cost and security trade-offs. For example, 1055 closed high-security groups could use pre-established shared keys 1056 or a PKI, most hosts CCA authentication with return routability 1057 tests for DoS prevention, and low-end mobile devices a protocol 1058 based only on RR. However, care must be taken to accommodate the 1059 multiple levels of protection so that the attacker cannot bid down 1060 to the lowest level. 1062 In the end, the decision about accepting or not accepting a BU is 1063 made by the correspondent. Therefore, the correspondent will always 1064 make the final decision about the required level of authentication 1065 (e.g. CGA/RR or plain RR) for the particular HoA. Also, it makes 1066 little sense for the correspondent to allow multiple levels of 1067 authentication for the same HoA because the attacker could always 1068 tackle the weakest one. Thus, the mobile must either authenticate 1069 itself using the protocol chosen by the correspondent or give up 1070 Route Optimization. It makes little sense to negotiate the 1071 protocol. 1073 In order to conform to the principles of the previous section, any 1074 protocol chosen by the correspondent must provide whatever level of 1075 DoS protection is considered sufficient for the mobile and for 1076 third parties. Thus, the protocols will mostly differ in DoS 1077 protection for the correspondent itself, which the correspondent 1078 may freely tune, and in the strength of the authentication. It is 1079 worth noting that different correspondents can make their choices 1080 of authentication strength independently. This is because a weak 1081 mechanism accepted by one correspondent would not help the attacker 1082 to redirect packets to or from correspondents that use a stronger 1083 protocol. 1085 It is advisable that the default protocol, used for mobiles with 1086 which the correspondent has not prior relationship, be the 1087 strongest one which correspondent can afford under normal use. 1088 Typically, this could be CGA/RR. This default level of 1089 authentication MUST be statically configured at the correspondent 1090 and MUST NOT be adjusted according to the current load. Otherwise, 1091 the attacker could artificially induce the conditions under which a 1092 weaker protocol is chosen. 1094 The correspondent MAY have a local policy that mandates a higher 1095 level (e.g. shared key authentication or PKI) or lower level (e.g. 1096 plain RR) of authentication for a particular HoA or range of 1097 addresses. These addresses can be statically configured or 1098 dynamically determined by strong authentication or equivalent 1099 commitment shown by the mobile in upper protocol layers. For 1100 example, a correspondent could be configured to allow weaker 1101 authentication for some low-end mobile devices that benefit from 1102 Route Optimization but cannot afford to run the stronger 1103 authentication protocol. 1105 It would be possible to allocate one bit of the IP address, similar 1106 to the "u" and "g" bits [HD98] in the interface identifier, to 1107 indicate whether the address is a CGA address. The correspondent 1108 would then select the BU protocol based on this bit. A disadvantage 1109 of this scheme is that the length of the public-key hash would 1110 become one bit shorter. Also, there may be increasing pressure to 1111 allocate bits of the IPv6 address for various purposes and the 64- 1112 bit interface identifier may soon prove to be surprisingly short. 1113 The problem can be mitigated by requiring only mobile hosts (rather 1114 than all IP nodes) to set the CGA-bit correctly. 1116 Based on the above, it should be recommended (or possibly even 1117 mandated) that the mobiles implement all common BU protocols (e.g. 1118 both CGA/RR and plain RR). If one does not, it may be unable to use 1119 Route Optimization with many correspondents. There is also the risk 1120 that business reasons will force practically all IP nodes to use 1121 the weakest level of authentication that is mandatory to implement 1122 and use. For example, if many low-end mobiles only implement the 1123 weakest standardized protocol, virtually all correspondents will 1124 default to this mechanism, which would defeat the purpose of having 1125 any stronger protocol. 1127 7. Security Considerations 1129 This document discusses security of Mobile IPv6 Route Optimization 1130 but does not present any specific protocols or detailed solutions. 1131 A separate specification of the actual BU authentication protocol 1132 is needed. 1134 There are other security concerns with Mobile IPv6 that are not 1135 addresses in this document. The Home Agent Discovery needs to be 1136 secured so that the mobile can establish a secure tunnel to a 1137 reliable Home Agent. Also, some features of the Mobile IPv6 1138 protocol may reduce the effectiveness of ingress filtering. The 1139 Home Address Option, the Alternative CoA sub-option, and possibly 1140 IPv6 in IPv6 tunnels, may be used to spoof the origin of packets 1141 without spoofing the source IP address. 1143 We assume that the mobile has chosen a reliable Home Agent and that 1144 Binding Updates and Acknowledgments between the mobile and its Home 1145 Agent are strongly authenticated with techniques outside the scope 1146 of this document. For example, there could be a manually keyed 1147 IPSec tunnel to a router on the mobile's Home Network. There are 1148 situations where no secure tunnel exist, for example if the mobile 1149 automatically contracts the services of temporary Home Agents along 1150 its path, but we feel that the security in such situations is based 1151 on much weaker assumptions and should be considered separately. 1153 It seems necessary to send the Binding Acknowledgments from other 1154 sources than the Home agent without authentication. In most BU 1155 authentication protocols, only the mobile is authenticated, and 1156 without authenticating the correspondent, there is no way of 1157 authenticating the acknowledgments. The consequence is that an 1158 attacker can send false acknowledgments and cause the mobile to 1159 send the next BU sooner or later than the correspondent expects. At 1160 worst, the effect is that the Binding Cache entry expires and Route 1161 Optimization is not used. Thus, an attacker anywhere on the network 1162 can prevent the use of Route Optimization by sending false Binding 1163 Acknowledgments. 1165 Finally, where an authenticated IPSec tunnel between the mobile and 1166 the correspondent exists, Binding Updates can be sent through the 1167 tunnel. However, the return routability test for DoS prevention 1168 might still be needed. We feel that currently the simplest and most 1169 effective solution is to design the BU protocol independently of 1170 IPSec. 1172 8. Conclusions 1174 We have described attacks against Mobile IPv6 Route Optimization 1175 and mechanisms for protecting the protocol participants and third 1176 parties. Some of the attacks may be new in the sense that they have 1177 not been considered in earlier BU authentication requirements and 1178 protocol drafts. It is our hope that this document will help in 1179 designing BU authentication protocols and in the process of 1180 choosing the protocol or protocols that will be part of the Mobile 1181 IPv6 standard. We are also working on a family of protocols that 1182 takes into account the points of this document [Roe02]. 1184 Acknowledgments 1186 Many of the ideas originate from Mike Roe, Greg O'Shea, Pekka 1187 Nikander, Erik Nordmark and various Internet Drafts. 1189 References 1191 [AN97a] Tuomas Aura and Pekka Nikander. Stateless connections. In 1192 Proc. International Conference on Information and 1193 Communications Security (ICICS'97), volume 1334 of LNCS, 1194 pages 87-97, Beijing, China, November 1997. Springer. 1196 [ANL00] Tuomas Aura, Pekka Nikander, and Jussipekka Leiwo. DOS- 1197 resistant authentication with client puzzles. In Proc. 1198 Security Protocols Workshop 2000, volume 2133 of LNCS, 1199 pages 170-181, Cambridge, UK, April 2000. Springer. 1201 [HC98] Dan Harkins and Dave Carrel. The Internet key exchange 1202 (IKE). RFC 2409, IETF Network Working Group, November 1203 1998. 1205 [HD98] Robert M. Hinden and Stephen E. Deering. IP version 6 1206 addressing architecture. RFC 2373, IETF Network Working 1207 Group, July 1998. 1209 [JB99] Ari Juels and John Brainard. Client puzzles: a 1210 cryptographic countermeasure against connection depletion 1211 attacks. In Proc. 1999 Network and Distributed Systems 1212 Security Symposium (NDSS), pages 151-165, San Diego, CA 1213 USA, February 1999. Internet Society. 1215 [KS99] Phil Karn and William A. Simpson. Photuris: session-key 1216 management protocol. RFC 2522, IETF Network Working 1217 Group, March 1999. 1219 [KA98] Stephen Kent and Randall Atkinson. Security architecture 1220 for the Internet Protocol. RFC 2401, IETF Network Working 1221 Group, November 1998. 1223 [Mea99] Catherine Meadows. A formal framework and evaluation 1224 method for network denial of service. In Proc. 12th IEEE 1225 Computer Security Foundations Workshop, pages 4-13, 1226 Mordano, Italy, June 1999. IEEE Computer Society. 1228 [MPH+01] Allison Mankin, Basavaraj Patil, Dan Harkins, Erik 1229 Nordmark, Pekka Nikander, Phil Roberts, and Thomas 1230 Narten. Threat models introduced by Mobile IPv6 and 1231 requirements for security in Mobile IPv6. Internet Draft 1232 draft-ietf-mobileip-mipv6-scrty-reqts-01.txt, IETF IP 1233 Routing for Wireless/Mobile Hosts (mobileip) WG, October 1234 2001. Work in progress. 1236 [MC01] Gabriel Montenegro and Claude Castelluccia. SUCV 1237 identifiers and addresses. Internet Draft draft- 1238 montenegro-sucv-02.txt, IETF, November 2001. Work in 1239 progress. 1241 [ND01] Thomas Narten and Richard Draves. Privacy extensions for 1242 stateless address autoconfiguration in IPv6. RFC 3041, 1243 IETF Network Working Group, January 2001. 1245 [NP01] Pekka Nikander and Charles Perkins. Binding 1246 authentication key establishment protocol for Mobile 1247 IPv6. Internet Draft draft-perkins-bake-01.txt, IETF 1248 Mobile IP Working Group, July 2001. Work in progress. 1250 [OR01] Greg O'Shea and Michael Roe. Child-proof authentication 1251 for MIPv6 (CAM). ACM Computer Communications Review, 1252 31(2), April 2001. 1254 [JP01] David B. Johnson and Charles Perkins. Mobility support in 1255 ipv6. Internet Draft draft-ietf-mobileip-ipv6-15.txt, 1256 IETF Mobile IP Working Group, July 2001. Work in 1257 progress. 1259 [Roe02] Michael Roe, Tuomas Aura, Greg O'Shea, and Jari Arkko. 1260 Authentication of Mobile IPv6 binding updates and 1261 acknowledgments. Internet Draft draft-roe-mobileip- 1262 updateauth-02.txt, IETF Mobile IP Working Group, February 1263 2002. Work in progress. 1265 [Sav02] Pekka Savola. Security of IPv6 routing header and home 1266 address options. Technical report, IETF, November 2002. 1267 Work in progress. 1269 [SKK+97] Christoph L. Schuba, Ivan V. Krsul, Markus G. Kuhn, 1270 Eugene H. Spaffold, Aurobindo Sundaram, and Diego 1271 Zamboni. Analysis of a denial of service attack on TCP. 1272 In Proc. 1997 IEEE Symposium on Security and Privacy, 1273 pages 208-223, Oakland, CA USA, May 1997. IEEE Computer 1274 Society Press. 1276 [TO01] Michael Thomas and Dave Oran. Home agent cookies for 1277 binding updates. Internet Draft draft-thomas-mobileip-ha- 1278 cookies-00.txt, IETF, July 2001. Work in progress. 1280 Authors' Addresses 1282 Tuomas Aura 1283 7 J J Thompson Avenue 1284 Cambridge, CB3 0FB 1285 United Kingdom 1287 Phone: +44 1223 479708 1288 Email: tuomaura@microsoft.com 1290 Jari Arkko 1291 Oy LM Ericsson Ab 1292 02420 Jorvas 1293 Finland 1295 Phone: +358 40 5079256 1296 Email: Jari.Arkko@ericsson.com