idnits 2.17.1 draft-nordmark-multi6-threats-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: ---------------------------------------------------------------------------- == 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 are 8 instances of too long lines in the document, the longest one being 3 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 -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'ADDR-ARCH' is defined on line 913, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 916, but no explicit reference was found in the text == Unused Reference: 'IPv6-SA' is defined on line 919, but no explicit reference was found in the text == Unused Reference: 'IPv6-AUTH' is defined on line 922, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 925, but no explicit reference was found in the text == Unused Reference: 'MAST' is defined on line 942, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-irtf-nsrg-report-09 == Outdated reference: A later version (-02) exists of draft-nikander-mobileip-v6-ro-sec-01 -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. 'SCTP') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. 'ADDR-ARCH') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. 'IPv6') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPv6-SA') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'IPv6-AUTH') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. 'IPv6-ESP') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark 3 June 1, 2004 Sun Microsystems 4 Tony Li 5 Procket Networks 7 Threats relating to IPv6 multihoming solutions 9 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet Draft expires December 1, 2004. 34 Abstract 36 This document lists security threats related to IPv6 multihoming. 37 Multihoming can introduce new opportunities to redirect packets to 38 different, unintended IP addresses. 40 The intent is to look at how IPv6 multihoming solutions might make 41 the Internet less secure than the current Internet, without studying 42 any proposed solution but instead looking at threats that are 43 inherent in the problem itself. The threats in this document build 44 upon the threats discovered and discussed as part of the Mobile IPv6 45 work. 47 Contents 49 1. INTRODUCTION............................................. 3 50 1.1. Assumptions......................................... 3 52 2. TERMINOLOGY.............................................. 4 54 3. TODAY'S ASSUMPTIONS...................................... 5 55 3.1. Application Assumptions............................. 5 56 3.2. Redirection Attacks Today........................... 6 57 3.3. Packet Injection Attacks Today...................... 7 58 3.4. Flooding Attacks Today.............................. 8 60 4. POTENTIAL NEW REDIRECTION ATTACKS........................ 9 61 4.1. Cause Packets to be Sent to the Attacker............ 10 62 4.1.1. Once Packets are Flowing....................... 10 63 4.1.2. Premeditated Redirection....................... 10 64 4.1.3. Using Replay Attacks........................... 11 65 4.2. Cause Packets to be Sent to a Black Hole............ 12 66 4.3. Third Party Denial-of-Service Attacks............... 12 67 4.3.1. Basic Third Party DoS.......................... 13 68 4.3.2. Third Party DoS with On-Path Help.............. 14 69 4.4. Accepting Packets from Unknown Locators............. 15 71 5. GRANULARITY OF REDIRECTION............................... 16 73 6. MOVEMENT IMPLICATIONS?................................... 17 75 7. OTHER SECURITY CONCERNS.................................. 18 77 8. PRIVACY CONSIDERATIONS................................... 19 79 9. SECURITY CONSIDERATIONS.................................. 19 81 10. ACKNOWLEDGMENTS......................................... 20 83 11. REFERENCES.............................................. 20 84 11.1. Normative References............................... 20 85 11.2. Informative References............................. 20 87 AUTHORS' ADDRESSES........................................... 22 89 APPENDIX A: CHANGES SINCE PREVIOUS DRAFT..................... 22 91 APPENDIX B: SOME SECURITY ANALYSIS........................... 23 93 1. INTRODUCTION 95 The goal of the IPv6 multihoming work is to allow a site to take 96 advantage of multiple attachments to the global Internet without 97 having a specific entry for the site visible in the global routing 98 table. Specifically, a solution should allow hosts to use multiple 99 attachments in parallel, or to switch between these attachment points 100 dynamically in the case of failures, without an impact on the upper 101 layer protocols. 103 At the highest level the concerns about allowing such "rehoming" of 104 packet flows can be called "redirection attacks"; the ability to 105 cause packets to be sent to a place that isn't tied to the upper 106 layer protocol's notion of the peer. These attacks pose threats 107 against confidentiality, integrity, and availability. That is, an 108 attacker might learn the contents of a particular flow by redirecting 109 it to a location where the attacker has a packet recorder. If, 110 instead of a recorder, the attacker changes the packets and then 111 forwards them to the ultimate destination, the integrity of the data 112 stream would be compromised. Finally, the attacker can simply use 113 the redirection of a flow as a denial of service attack. 115 This document has been developed while considering multihoming 116 solutions architected around a separation of network identity and 117 network location. However, this separation is not a requirement for 118 all threats, so this taxonomy may also apply to other approaches. 119 This document is not intended to examine any single proposed 120 solution. Rather, it is intended as an aid to discussion and 121 evaluation of proposed solutions. By cataloging known threats, we 122 can help to ensure that all proposals deal with all of the available 123 threats. 125 1.1. Assumptions 127 This threat analysis doesn't assume that security has been applied 128 other security relevant parts of the Internet, such as DNS and 129 routing protocols, but it does assume that at some point in time at 130 least parts of the Internet will be operating with security for such 131 key infrastructure. With that assumption it then becomes important 132 that a multihoming solution would not, at that point in time, become 133 the weakest link. This is the case even if, for instance, insecure 134 DNS might be the weakest link today. 136 This document doesn't assume that the application protocols are 137 protected by strong security today or in the future. However, it is 138 still useful to assume that the application protocols which care 139 about integrity and/or confidentiality apply the relevant end-to-end 140 security measures, such as IPsec or TLS. 142 For simplicity we assume that an on-path attacker can see packets, 143 modify packets and send them out, and block packets from being 144 delivered. This is a simplification because there might exist ways, 145 for instance monitoring capability in switches, which allow 146 authenticated and authorized users to observe packets without being 147 able to send or block the packets. 149 We assume that an off-path attacker can neither see packets between 150 the peers (for which it is not on the path) nor block them from being 151 delivered. Off-path attackers can in general send packets with 152 arbitrary IP source addresses and content, but such packets might be 153 blocked if ingress filtering [INGRESS] is applied. Thus it is 154 important to look at the multihoming impact on security both in the 155 presence and absence of ingress filtering. 157 2. TERMINOLOGY 159 upper layer protocol (ULP) 160 - a protocol layer immediately above IP. Examples are 161 transport protocols such as TCP and UDP, control 162 protocols such as ICMP, routing protocols such as 163 OSPF, and Internet or lower-layer protocols being 164 "tunneled" over (i.e., encapsulated in) IP such as 165 IPX, AppleTalk, or IP itself. 167 interface - a node's attachment to a link. 169 address - an IP layer name that contains both topological 170 significance and acts as a unique identifier for an 171 interface. 173 locator - an IP layer topological name for an interface or a 174 set of interfaces. 176 identifier - an IP layer identifier for an IP layer endpoint 177 (stack name in [NSRG]). The transport endpoint is a 178 function of the transport protocol and would 179 typically include the IP identifier plus a port 180 number. 182 address field 183 - the source and destination address fields in the 184 IPv6 header. As IPv6 is currently specified this 185 fields carry "addresses". If identifiers and 186 locators are separated these fields will contain 187 locators. 189 FQDN - Fully Qualified Domain Name 191 3. TODAY'S ASSUMPTIONS 193 The two interesting aspects of security for multihoming solutions are 194 the assumptions made by the applications and upper layer protocols 195 about the identifiers that they see on one hand, and the existing 196 abilities to perform today various attacks related to the 197 identity/location relationship, on the other hand. 199 3.1. Application Assumptions 201 In the Internet today, the initiating part of applications either 202 starts with a FQDN, which it looks up in the DNS, or already has an 203 IP address from somewhere. For the FQDN to IP address lookup the 204 application effectively places trust in the DNS. Once it has the IP 205 address, the application places trust in the routing system 206 delivering packets to that address. Applications that use security 207 mechanisms, such as IPsec or TLS, with mutual authentication have the 208 ability to "bind" the FQDN to the cryptographic keying material thus 209 compromising the DNS and/or the routing system can at worst cause the 210 packets to be dropped or delivered to an entity which does not posses 211 the keying material. 213 At the responding (non-initiating) end of communication today, we 214 find applications that fall into approximately five classes with 215 respect to their security requirements. 217 The first class is the set of public content servers. These systems 218 provide data to any and all systems and are not particularly 219 concerned with confidentiality, as they make their content available 220 to all. However, they are interested in data integrity and denial of 221 service attacks. Having someone manipulate the results of a search 222 engine, for example, or prevent certain systems from reaching a 223 search engine would be a serious security issue. 225 The second class of applications use existing IP source addresses 226 from outside of their immediate local site as a means of 227 authentication without any form of verification. Today, with source 228 IP address spoofing and TCP sequence number guessing as rampant 229 attacks, such applications are effectively opening themselves for 230 public connectivity and are reliant on other systems, such as 231 firewalls, for overall security. We do not consider this class of 232 systems in this document. 234 The third class of applications receive existing IP source addresses, 235 but attempt some verification using the DNS, effectively using the 236 FQDN for access control. (This is typically done by performing a 237 reverse lookup from the IP address followed by a forward lookup and 238 verifying that the IP address matches one of the addresses returned 239 from the forward lookup.) These applications are already subject to 240 a number of attacks using techniques like source address spoofing and 241 TCP sequence number guessing since an attacker, knowing this is the 242 case, can simply create a DoS attack using a forged source address 243 that has authentic DNS records. In general this class of 244 applications is strongly discouraged, but it is probably important 245 that a multihoming solution doesn't introduce any new and easier ways 246 to perform such attacks. 248 The fourth class of applications use cryptographic security 249 techniques to provide both a strong identity for the peer and data 250 integrity with or without confidentiality. Such systems are still 251 potentially vulnerable to denial of service attacks that could be 252 introduced by a multihoming solution. 254 Finally, the fifth class of applications use cryptographic security 255 techniques but without strong identity (such as opportunistic IPsec). 256 Thus data integrity with or without confidentiality is provided when 257 communicating with an unknown/unauthenticated principal. Just like 258 the first category above such applications can't perform access 259 control since they do not know the identity of the peer. [TBD: Does 260 one-way authentication, without mutual authentication, add a 261 different class of applications?] 263 The requirement for a multihoming solution is that security be no 264 worse than it is today in all situations. Thus, mechanisms that 265 provide confidentiality, integrity, or authentication today should 266 continue to provide these properties in a multihomed environment. 268 3.2. Redirection Attacks Today 270 This section enumerates some of the redirection attacks that are 271 possible in today's Internet. 273 If routing can be compromised, packets for any destination can be 274 redirected to any location. This can be done by injecting a long 275 prefix into global routing, thereby causing the longest match 276 algorithm to deliver packets to the attacker. 278 Similarly, if DNS can be compromised, and a change can be made to an 279 advertised resource record to advertise a different IP address for a 280 hostname, effectively taking over that hostname. More detailed 281 information about threats relating to DNS are in [DNS-THREATS]. 283 Any system that is along the path from the source to the destination 284 host can be compromised and used to redirect traffic. Systems may be 285 added to the best path to accomplish this. Further, even systems 286 that are on multi-access links that do not provide security can also 287 be used to redirect traffic off of the normal path. For example, ARP 288 and ND spoofing can be used to attract all traffic for the legitimate 289 next hop across an Ethernet. And since the vast majority of 290 applications rely on DNS lookups, if DNSsec is not deployed, then 291 attackers that are on the path between the host and the DNS servers 292 can also cause redirection by modifying the responses from the DNS 293 servers. 295 Finally, the hosts themselves that terminate the connection can also 296 be compromised and can perform functions that were not intended by 297 the end user. 299 All of the above protocol attacks are the subject of ongoing work to 300 secure them (DNSsec, security for BGP, Secure ND) and are not 301 considered further within this document. The goal for a multihoming 302 solution is not to solve these attacks. Rather, it is to avoid 303 adding to this list of attacks. 305 3.3. Packet Injection Attacks Today 307 In today's Internet the upper-layer protocols, such as TCP and SCTP, 308 which use IP, use the IP addresses as the identifiers for the 309 communication. In the absence of ingress filtering [INGRESS] the IP 310 layer allows the sender to use an arbitrary source address, thus the 311 ULPs need some protection against malicious senders injecting bogus 312 packets into the packet stream between two communicating peers. If 313 this protection can be circumvented, then it is possible for an 314 attacker to cause harm without necessarily needing to redirect the 315 return packets. 317 There are various level of protection in different ULPs. For 318 instance, in general TCP packets have to contain a sequence that 319 falls in the receiver's window to be accepted. If the TCP initial 320 sequence numbers are random then it is relatively hard for an off- 321 path attacker to guess the sequence number close enough for it to 322 belong to the window, and as result be able to inject a packet into 323 an existing connection. How hard this is depends on the size of the 324 available window. SCTP provides a stronger mechanism with the 325 verification tag; an off-path attacker would need to guess this 326 random 32-bit number. Of course, IPsec provide cryptographically 327 strong mechanisms which prevent attackers on or off path to inject 328 packets once the security associations have been established. 330 When ingress filtering is deployed between the potential attacker and 331 the path between the communicating peers, it can prevent the attacker 332 from using the peer's IP address as source. In that case the packet 333 injection will fail in today's Internet. 335 We don't expect a multihoming solution improve the existing degree of 336 prevention against packet injection. However, it is necessary to 337 look carefully whether a multihoming solution makes it easier for 338 attackers to inject packets since the desire to have the peer be 339 present at multiple locators, and perhaps at a dynamic set of 340 locators, can potentially result in solutions that, even in the 341 presence of ingress filtering, make packet injection easier. 343 3.4. Flooding Attacks Today 345 In the Internet today there are several ways for an attacker to use a 346 redirection mechanism to launch DoS attacks that can not easily be 347 traced to the attacker. An example of this is to use protocols which 348 cause reflection with or without amplification [PAXSON01]. 350 Reflection without amplification can be accomplished by an attacker 351 sending a TCP SYN packet to a well-known server with a spoofed source 352 address; the resulting TCP SYN ACK packet will be sent to the spoofed 353 source address. 355 Devices on the path between two communicating entities can also 356 launch DoS attacks. While such attacks might not be interesting 357 today, it is necessary to understand them better in order to 358 determine whether a multihoming solution might enables new types of 359 DoS attacks. 361 For example, today if A is communicating with B, then A can try to 362 overload the path from B to A. If TCP is used A could do this by 363 sending ACK packets for data that it has not yet received (but it 364 suspects B has already sent) so that B would send at a rate that 365 would cause persistent congestion on the path towards A. Such an 366 attack would seem self-destructive since A would only make its own 367 corner of the network suffer by overloading the path from the 368 Internet towards A. 370 A more interesting case is if A is communicating with B and X is on 371 the path between A and B, then X might be able to fool B to send 372 packets towards A at a rate that is faster than A (and the path 373 between A and X) can handle. For instance, if TCP is used then X can 374 craft TCP ACK packets claiming to come from A to cause B to use a 375 congestion window that is large enough to potentially cause 376 persistent congestion towards A. Furthermore, if X can suppress the 377 packets from A to B it can also prevent A from sending any explicit 378 "slow down" packets to B. Similar attacks can presumably be launched 379 using protocols that carry streaming media by forging such a 380 protocol's notion of acknowledgment and feedback. 382 An attribute of this type of attack is that A will simply think that 383 B is faulty since its flow and congestion control mechanisms don't 384 seem to be working. Detecting that the stream of ACK packets is 385 generated from X and not from A might be challenging, since the rate 386 of ACK packets might be relatively low. This type of attack might 387 not be common today because, in the presence of ingress filtering, it 388 requires that X remain on the path in order to sustain the DoS 389 attack. And in the absence of ingress filtering an attacker can 390 launch simpler DoS attacks by spoofing its source IP address. 392 The danger is that the addition of multihoming redirection mechanisms 393 might potentially remove the constraint that the attacker remain on 394 the path. And with the current, no-multihoming support, using end- 395 to-end strong security at a protocol level at (or below) this "ACK" 396 processing would prevent this type of attack. But if a multihoming 397 solution is provided underneath IPsec that prevention mechanism would 398 potentially not exist. 400 Thus the challenge for multihoming solutions is to not create 401 additional types of attacks in this area, or make existing types of 402 attacks significantly easier. 404 4. POTENTIAL NEW REDIRECTION ATTACKS 406 This section documents the additional redirection attacks that have 407 been discovered that result from an architecture where hosts can 408 change their topological connection to the network in the middle of a 409 transport session without interruption. This discussion is again 410 framed in the context of independent host identifiers and topological 411 locators. Some of these attacks may not be applicable if traditional 412 addresses are used. This section assumes that each host has multiple 413 locators and that there is some mechanism for determining the 414 locators for a correspondent host. We do not assume anything about 415 the properties of these mechanisms. Instead, this list will serve to 416 help us derive the properties of these mechanisms that will be 417 necessary to prevent these redirection attacks. 419 Depending on the purpose of the redirection attack we separate the 420 attacks into several different types. 422 4.1. Cause Packets to be Sent to the Attacker 424 An attacker might want to receive the flow of packets, for instance 425 to be able to inspect and/or modify the payload or to be able to 426 apply cryptographic analysis to cryptographically protected payload, 427 using redirection attacks. 429 4.1.1. Once Packets are Flowing 431 This might be viewed as the "classic" redirection attack. 433 While A and B are communicating X might send packets to B and claim: 434 "Hi, I'm A, send my packets to my new location." where the location 435 is really X's location. 437 "Standard" solutions to this include requiring the host requesting 438 redirection somehow be verified to be the same host as the initial 439 host to establish communication. However, the burdens of such 440 verification must not be onerous, or the redirection requests 441 themselves can be used as a DoS attack. 443 To prevent this type of attack, a solution would need some mechanism 444 that B can use to verify whether a locator belongs to A before B 445 starts using that locator, and be able to do this when multiple 446 locators are assigned to A. 448 4.1.2. Premeditated Redirection 450 This is a variant of the above where the attacker "installs" itself 451 before communication starts. 453 For example, if the attacker X can predict that A and B will 454 communicate in the (near) future, then the attacker can tell B: "Hi, 455 I'm A and I'm at this location". When A later tries to communicate 456 with B, will B believe it is really A? 457 If the solution to the classic redirection attack is based on "prove 458 you are the same as initially", then A will fail to prove this to B 459 since X initiated communication. 461 Depending on details that would be specific to a proposed solution, 462 this type of attack could either cause redirection (so that the 463 packets intended for A will be sent to X) or they could cause DoS 464 (where A would fail to communicate with B since it can't prove it is 465 the same host as X). 467 To prevent this attack, the verification whether a locator belongs to 468 the peer can not simply be based on the first peer that made contact. 470 4.1.3. Using Replay Attacks 472 While the multihoming problem doesn't inherently imply any 473 topological movement it is useful to also consider the impact of site 474 renumbering in combination with multihoming. In that case the set of 475 locators for a host will change each time its site renumbers and at 476 some point in time after a renumbering event the old locator prefix 477 might be reassigned to some other site. 479 This potentially opens up the ability for an attacker to replay 480 whatever protocol mechanism was used to inform a host of a peer's 481 locators so that the host would incorrectly be lead to believe that 482 the old locator (set) should be used even long after a renumbering 483 event. This is similar to the risk of replay of Binding Updates in 484 [MIPv6] but the time constant is quite different; Mobile IPv6 might 485 see movements every second while site renumbering followed by 486 reassignment of the site locator prefix might be a matter of weeks or 487 months. 489 To prevent such replay attacks the protocol which is used to verify 490 which locators can be used with a particular identifier needs some 491 replay protection mechanism. 493 Also, in this space one needs to be concerned about potential 494 interaction between such replay protection and the administrative act 495 of reassignment of a locator. If the identifier and locator 496 relationship is distributed across the network one would need to make 497 sure that the old information has been completely purged from the 498 network before any reassignment. Note that this does not require an 499 explicit mechanism. This can instead be implemented by locator reuse 500 policy and careful timeouts of locator information. 502 4.2. Cause Packets to be Sent to a Black Hole 504 This is also a variant of the classic redirection attack. The 505 difference is that the new location is a locator that is nonexistent 506 or unreachable. Thus the effect is that sending packets to the new 507 locator causes the packets to be dropped by the network somewhere. 509 One would expect that solutions which prevent the previous 510 redirection attacks would prevent this attack as a side effect, but 511 it makes sense to include this attack here for completeness. 512 Mechanisms that prevented a redirection attack to the attacker should 513 also prevent redirection to a black hole. 515 4.3. Third Party Denial-of-Service Attacks 517 An attacker can use the ability to perform redirection to cause 518 overload on an unrelated third party. For instance, if A and B are 519 communicating then the attacker X might be able to convince A to send 520 the packets intended for B to some third node C. While this might 521 seem harmless at first, since X could just flood C with packets 522 directly, there are a few aspects of these attacks that cause 523 concern. 525 The first is that the attacker might be able to completely hide its 526 identity and location. It might suffice for X to send and receive a 527 few packets to A in order to perform the redirection, and A might not 528 retain any state on who asked for the redirection to C's location. 529 Even if A had retained such state, that state would probably not be 530 easily available to C, thus C can't determine who was the attacker 531 once C is being DoS'ed. 533 The second concern is that with a direct DoS attack from X to C, the 534 attacker is limited by the bandwidth of its own path towards C. If 535 the attacker can fool another host like A to redirect its traffic to 536 C then the bandwidth is limited by the path from A towards C. If A 537 is a high-capacity Internet service and X has slow (e.g., dialup) 538 connectivity this difference could be substantial. Thus in effect 539 this could be similar to packet amplifying reflectors in [PAXSON01]. 541 The third, and final concern, is that if an attacker only need a few 542 packets to convince one host to flood a third party, then it wouldn't 543 be hard for the attacker to convince lots of hosts to flood the same 544 third party. Thus this could be used for Distributed Denial-of- 545 Service attacks. 547 In today's Internet the ability to perform this type of attack is 548 quite limited. In order for the attacker to initiate communication 549 it will in most cases need to be able to receive some packets from 550 the peer (the potential exception being combining this with TCP 551 sequence number guessing type of techniques). Furthermore, to the 552 extent that parts of the Internet uses ingress filtering [INGRESS], 553 even if the communication could be initiated it wouldn't be possible 554 to sustain it by sending ACK packets with spoofed source addresses 555 from an off-path attacker. 557 If this type of attack can't be prevented there might be mitigation 558 techniques that can be employed. For instance, in the case of TCP it 559 would help if TCP slow-start was triggered when the destination 560 locator changes. (Folks might argue that, separately from security, 561 this would be the correct action for congestion control since TCP 562 might not have any congestion-relation information about the new path 563 implied by the new locator). Applying this technique to other ULPs 564 which perform different forms of (TCP friendly) congestion control 565 might be more difficult since the lower layers generally lack an API 566 to provide such information to the ULPs. Also, for other protocols, 567 this might be less beneficial, since other ULPs might not adapt 568 rapidly and could view the suggestion of congestion as being more 569 severe than a simple deficit of congestion information. 571 4.3.1. Basic Third Party DoS 573 Assume that X is on a slow link anywhere in the Internet. B is on a 574 fast link (gigabits; e.g. a media server) and A is the victim. 576 X could flood A directly but is limited by its low bandwidth. If X 577 can establish communication with B, ask B to send it a high-speed 578 media stream, then X can presumably fake out the 579 "acknowledgments/feedback" needed for B to blast out packets at full 580 speed. So far this only hurts X - and the path between X and the 581 Internet. But if X could also tell B "I'm at A's locator" then X has 582 effectively used this redirection capability in multihoming to 583 amplify its DoS capability, which would be a source of concern. 585 One could envision rather simple techniques to prevent such attacks. 586 For instance, before sending to a new peer locator perform a clear 587 text exchange with the claimed new locator of the form "Are you X?" 588 resulting in "Yes, I'm X.". This would suffice for the simplest of 589 attacks. However, as we will see below, more sophisticated attacks 590 are possible. 592 4.3.2. Third Party DoS with On-Path Help 594 The scenario is as above but in addition the attacker X has a friend 595 Y on the path between A and B: 597 ----- ----- ----- 598 | A |--------| Y |--------| B | 599 ----- ----- ----- 600 / 601 / 602 / 603 / 604 / 605 / 606 ----- 607 | X | 608 ----- 610 With the simple solution suggested in the previous section, all Y 611 might need to do is to fake a response to the "Are you X?" packet, 612 and after that point in time Y might not be needed; X could 613 potentially sustain the data flow towards A by generating the ACK 614 packets. Thus it would be even harder to detect the existence of Y. 616 Furthermore, if X is not the actual end system but an attacker 617 between some node C and B, then X can claim to be C, and no finger 618 can be pointed at X either: 620 ----- ----- ----- 621 | A |--------| Y |--------| B | 622 ----- ----- ----- 623 / 624 / 625 / 626 / 627 / 628 / 629 ----- ----- 630 | C |-------| X | 631 ----- ----- 633 Thus with two attackers on different paths, there might be no trace 634 of who did the redirection to the 3rd party once the redirection has 635 taken place. 637 A specific case of this is when X=Y, and X is located on the same LAN 638 as B. 640 A potential way to make such attacks harder would be to use the last 641 received (and verified) source locator as the destination locator. 642 That way when X sends the ACK packets (whether it claims to be X or 643 C) the result would be that the packet flow from B would switch back 644 towards X/C, which would result in an attack similar to what can be 645 performed in today's Internet. 647 Another way that a multihoming solution might address this is to 648 ensure that B will only accept locators that can be authenticated to 649 be synonymous with the original correspondent. It must be possible 650 to securely ensure that these locators form an equivalence class. So 651 in the first example, not only does X need to assert that it is A, 652 but A needs to assert that it is X. 654 4.4. Accepting Packets from Unknown Locators 656 The multihoming solution space does not only affect the destination 657 of packets; it also raises the question from which sources packets 658 should be accepted. It is possible to build a multihoming solution 659 that allows traffic to be recognized as coming from the same peer 660 even if there is a previously unknown locator present in the source 661 address field. The question is whether we want to allow packets from 662 unverified sources to be passed on to upper layer protocols. 664 In the current Internet, an attacker can't inject packets with 665 arbitrary source addresses into a session if there is ingress 666 filtering present, so allowing packets with unverified sources in a 667 multihoming solution would fail our "no worse than what we have now" 668 litmus test. However, given that ingress filtering deployment is far 669 from universal and ingress filtering typically wouldn't prevent 670 spoofing of addresses in the same subnet, requiring rejecting packets 671 from unverified locators might be too stringent. A factor to take 672 into account to determine the "requirement level" for this is that 673 when IPsec is used on top of the multihoming solution, then IPsec 674 will reject such spoofed packets. (Note that this is different than 675 in the redirection attack cases where even with IPsec an attacker 676 could potentially cause a DoS attack.) 678 There might also be a middle ground where arbitrary attackers are 679 prevented from injecting packets by using the SCTP verification tag 680 type of approach [SCTP]. (This is a clear-text tag which is sent to 681 the peer which the peer is expected to include in each subsequent 682 packet.) Such an approach doesn't prevent packet injection from on- 683 path attackers (since they can observe the verification tag), but 684 neither does ingress filtering. 686 5. GRANULARITY OF REDIRECTION 688 Different multihoming solutions might approach the problem at 689 different layers in the protocol stack. For instance, there has been 690 proposals on a shim layer inside IP as well as transport layer 691 approaches. The former would have the capability to redirect an IP 692 address while the latter might be constrained to only redirect a 693 single transport connection. This difference might be important when 694 it comes to understanding the security impact. 696 For instance, premeditated attacks might have quite different impact 697 in the two cases. In an IP-based multihoming solution a successful 698 premeditated redirection could be due to the attacker connecting to a 699 server and claiming to be 'A' which would result in the server 700 retaining some state about 'A' which it received from the attacker. 701 Later, when the real 'A' tries to connect to the server, the 702 existence of this state might mean that 'A' fails to communicate, or 703 that its packets are sent to the attacker. But if the same scenario 704 is applied to a transport-layer approach then the state created due 705 to the attacker would perhaps be limited to the existing transport 706 connection. Thus while this might prevent the real 'A' from 707 connecting to the server while the attacker is connected (if they 708 happen to use the same transport port number) most likely it would 709 not affect 'A's ability to connect after the attacker has 710 disconnected. 712 A particular aspect of the granularity question is the direction 713 question; will the created state be used for communication in the 714 reverse direction from the direction when it was created? For 715 instance, if the attacker 'X' suspects that 'A' will connect to 'B' 716 in the near future, can X connect to A and claim to be B and have 717 that later make A connect to the attacker instead of to the real B? 719 Note that transport layer approaches are limited to the set of ULPs 720 that the implementation makes aware of multihoming. In many cases 721 there would be ULPs that are unknown to the multihoming capability of 722 the system, such as applications built on top of UDP. To understand 723 the impact of the granularity question on the security, one would 724 also need to understand how such applications/ULPs would be handled. 726 A property of transport granularity is that the amount of work 727 performed by a legitimate host is proportional to the number of 728 transport connections it creates that uses the multihoming support, 729 since each such connection would require some multihoming signaling. 730 And the same is true for the attacker. This means that an attacker 731 could presumably do a premeditated attack for all TCP connections to 732 port 80 from A to B, by setting up 65,536 (for all TCP source port 733 numbers) to the server B and causing B to think those connections 734 should be directed to the attacker and keeping those TCP connections 735 open. Any attempt to make legitimate communication more efficient, 736 e.g., by being able to signal for multiple transport connections at a 737 time, would provide as much relative benefit for an attacker as the 738 legitimate hosts. 740 Discussion: Perhaps the key issue is not about the granularity, 741 but about the lifetime of the state that is created? In a 742 transport-layer approach the multihoming state would presumably be 743 destroyed when the transport state is deleted as part of closing 744 the connection. But an IP-layer approach would have to rely on 745 some timeout or garbage collection mechanisms perhaps combined 746 with some new explicit signally to remove the multihoming state. 747 The coupling between the connection state and multihoming state in 748 the transport-layer approach might make it more expensive for the 749 attacker, since it needs to keep the connections open. Is this 750 the case? 752 In summary, there are issues we don't yet understand well about 753 granularity and reuse of the multihoming state. 755 6. MOVEMENT IMPLICATIONS? 757 In the case when nothing moves around we have a reasonable 758 understanding of the security requirements. Something that is on the 759 path can be a MiTM in today's Internet and a multihoming solution 760 doesn't need to make that aspect any more secure. 762 But it is more difficult to understand the requirements when hosts 763 are moving around. For instance, a host might be on the path for a 764 short moment in time by driving by an 802.11 hotspot. Would we or 765 would we not be concerned if such a drive-by (which many call a 766 "time-shifting" attack) would result in the temporarily on-path host 767 being able to act as a MiTM for future communication? Depending on 768 the solution this might be possible by the attacker causing 769 multihoming state to be created in various peer hosts while the 770 attacker was on the path, and that state remaining in the peers for 771 some time. 773 The answer to this question doesn't seem to be obvious even in the 774 absence of any new multihoming support. We don't have much 775 experience with hosts moving around that are able to attack things as 776 they move. In Mobile IPv6 [MIPv6] a conservative approach was taken 777 which limits the effect of such drive-by attacks to the maximum 778 lifetime of the binding, which is set to a few minutes. 780 With multihoming support the issue gets a bit more complicated 781 because we explicitly want to allow a host to be present at multiple 782 locators at the same time, thus there might be a need to distinguish 783 between the host moving between different locators, and the host 784 sending packets with different source locators because it is present 785 at multiple locators without any topological movement. 787 Note that the multihoming solutions that have been discussed range 788 from such drive-by's being impossible (for instance, due to a strong 789 binding to a separate identifier as in HIP, or due to reliance on the 790 relative security of the DNS for forward plus reverse lookups in 791 NOID), to systems that are first-come/first-serve (WIMP being an 792 example with a separate ID space, a MAST approach with a PBK being an 793 example without a separate ID space) that allow the first host which 794 is using an ID/address to claim that without any time limit. 796 7. OTHER SECURITY CONCERNS 798 The protocol mechanisms added as part of a multihoming solution 799 shouldn't introduce any new DoS in the mechanisms themselves. In 800 particular, care must be taken not to: 802 - create state on the first packet in an exchange, since that could 803 result in state consumption attacks similar to the TCP SYN 804 flooding attack. 806 - perform much work on the first packet in an exchange (such as 807 expensive verification) 809 There is a potential chicken-and-egg problem here, because 810 potentially one would want to avoid doing work or creating state 811 until the peer has been verified, but verification will probably need 812 some state and some work to be done. 814 A possible approach that solutions might investigate is to defer 815 verification until there appears to be two different hosts (or two 816 different locators for the same host) that want to use the same 817 identifier. 819 Another possible approach is to first establish communications, and 820 then perform verification in parallel with normal data transfers. 821 Redirection would only be permitted after verification was complete, 822 but prior to that event, data could transfer in a normal, non- 823 multihomed manner. 825 Finally, the new protocol mechanisms should be protected against 826 spoofed packets, at least from off-path sources, and replayed 827 packets. 829 8. PRIVACY CONSIDERATIONS 831 While introducing identifiers can be helpful by providing ways to 832 identify hosts across events when its IP address(es) might change, 833 there is a risk that such mechanisms can be abused to track the 834 identity of the host over long periods of time. Designers of 835 solutions to multihoming need to be aware of this concern. 837 A solution could address this for instance by allowing each host to 838 have multiple identifiers at the same time and perhaps even changing 839 the set of identifiers that are used over time. Such an approach 840 could be analogous to what is done for IPv6 addresses in [RFC3041]. 842 9. SECURITY CONSIDERATIONS 844 In section 3 we discussed existing protocol-based redirection 845 attacks. But there are also non-protocol redirection attacks. An 846 attacker which can gain physical access to one of 848 - The copper/fiber somewhere in the path. 850 - A router or L2 device in the path. 852 - One of the end systems 854 can also redirect packets. This could be possible for instance by 855 physical break-ins or by bribing staff that have access to the 856 physical infrastructure. Such attacks are out of scope for this 857 discussion, but are worth to keep in mind when looking at the cost 858 for an attacker to exploit any protocol-based attacks against 859 multihoming solutions; making protocol-based attacks much more 860 expensive to launch than break-ins/bribery type of attacks might be 861 overkill. 863 10. ACKNOWLEDGMENTS 865 This document is a product of a MULTI6 design team consisting of (in 866 alphabetical order): Iljitsch van Beijnum, Steve Bellovin, Brian 867 Carpenter, Mike O'Dell, Sean Doran, Dave Katz, Tony Li, Erik 868 Nordmark, and Pekka Savola. 870 Much of the awareness of these threats come from the work on Mobile 871 IPv6 [MIPv6, NIKANDER03, AURA02]. 873 Masataka Ohta brought up privacy concern related to stable 874 identifiers. The suggestion to discuss transport versus IP 875 granularity was contributed by Marcelo Bagnulo. 877 11. REFERENCES 879 11.1. Normative References 881 11.2. Informative References 883 [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the 884 NSRG", draft-irtf-nsrg-report-09.txt (work in progress), 885 March 2003. 887 [MIPv6] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support in 888 IPv6", draft-ietf-mobileip-ipv6-24.txt (work in progress), 889 June 2003. 891 [AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", 892 draft-aura-mipv6-bu-attacks-01 (work in progress), March 893 2002. 895 [NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E. 896 Nordmark, "Mobile IP version 6 Route Optimization Security 897 Design Background", draft-nikander-mobileip-v6-ro-sec-01 898 (work in progress), June 2003. 900 [PAXSON01] V. Paxson, "An Analysis of Using Reflectors for 901 Distributed Denial-of-Service Attacks", Computer 902 Communication Review 31(3), July 2001. 904 [INGRESS] Ferguson P., and D. Senie, "Network Ingress Filtering: 905 Defeating Denial of Service Attacks which employ IP Source 906 Address Spoofing", RFC 2827, May 2000. 908 [SCTP] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. 909 Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and 910 V. Paxson, "Stream Control Transmission Protocol", RFC 911 2960, October 2000. 913 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 914 Addressing Architecture", RFC 3513, April 2003. 916 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 917 6 (IPv6) Specification", RFC 2461. 919 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 920 Protocol". RFC 2401, November 1998. 922 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, 923 November 1998. 925 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 926 RFC 2406, November 1998. 928 [RFC3041] T. Narten and Draves, R, "Privacy Extensions for 929 Stateless Address Autoconfiguration in IPv6", January 2001. 931 [DNS-THREATS] Derek Atkins, Rob Austein, "Threat Analysis Of The 932 Domain Name System", 5-Apr-04, 935 [PBK] Scott Bradner, Allison Mankin, Jeffrey Schiller, "A Framework 936 for Purpose-Built Keys (PBK)", 9-Jun-03, 939 [NOID] Erik Nordmark, "Multihoming without IP Identifiers", Oct 27, 940 2003, 942 [MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT 943 (MAST): AN EXTENDED PROPOSAL", September 2003, 946 [HIP] Pekka Nikander, "Considerations on HIP based IPv6 multi- 947 homing", 23-Jan-04, 949 [WIMP] Jukka Ylitalo, 13-Feb-04, "Weak Identifier Multihoming 950 Protocol (WIMP)", 952 [CBHI] Iljitsch van Beijnum, "Crypto Based Host Identifiers", 2- 953 Feb-04, 955 AUTHORS' ADDRESSES 957 Erik Nordmark Tony Li 958 Sun Microsystems, Inc. Procket Networks, Inc. 959 17 Network Circle 1110 Cadillac Ct. 960 Mountain View, CA Milpitas, CA 961 USA USA 963 phone: +1 650 786 2921 phone: +1 408 635 7903 964 fax: +1 650 786 5896 fax: +1 408 635 7522 965 email: erik.nordmark@sun.com email: Tony.Li@procket.com 967 APPENDIX A: CHANGES SINCE PREVIOUS DRAFT 969 The following changes have been made since version 00 of the draft. 971 o Added reference to [DNS-THREATS] and clarified that attackers on 972 the path between the host and the DNS servers can redirect traffic 973 today. 975 o Added a section on existing packet injection attacks to talk about 976 TCP sequence number guessing etc. 978 o Clarified ingress filtering relationship in section on today's 979 flooding attacks. 981 o Added a new section on granularity to list some issues about 982 transport-level versus IP-level approaches and what we understand 983 about the differences in security. This is still very much a work 984 in progress. 986 o Added a new section on movement to discuss how things change when 987 hosts move around the network. This is still very much a work in 988 progress. 990 o Added Appendix B - but this should probably be moved to a 991 different document to keep this document focused on the threats. 993 APPENDIX B: SOME SECURITY ANALYSIS 994 When looking at the proposals that have been made for multihoming 995 solutions and the above threats it seems like there are two separable 996 aspects of handling the redirection threats: 998 - Redirection of existing communication 1000 - Redirection of an identity before any communication 1002 The former can be addressed by a large class of approaches which are 1003 based on setting up some form of security material at the beginning 1004 of communication, and later using the existence of that material for 1005 one end to prove to the other that it remains the same. An example 1006 of this is Purpose Built Keys [PBK]. One can envision different 1007 approaches for such schemes with different complexity, performance, 1008 and resulting security such as anonymous Diffie-Hellman exchange, the 1009 reverse hash chains presented in [WIMP], or even a clear-text token 1010 exchanged at the initial communication. 1012 However, the mechanisms for addressing the latter issue can be quite 1013 different. One way to prevent premeditated redirection is to simply 1014 not introduce a new identifier name space but instead rely on 1015 existing name space(s) as in [NOID]; in this case premeditated 1016 redirection is as easy or as hard as redirecting an IP address today. 1017 Essentially this relies on the return-routability check associated 1018 with a roundtrip of communication which verifies that the routing 1019 system delivers packets to the IP address in question. 1021 Alternatively, one can use the crypto-based identifiers such as in 1022 [HIP] or crypto-generated addresses as in [CBHI], which both rely on 1023 public-key crypto, to prevent premeditated attacks. In some cases it 1024 is also possible to avoid the problem by having (one end of the 1025 communication) use ephemeral identifiers as in [WIMP]. This avoids 1026 premeditated redirection by detecting that some other entity is using 1027 the same identifier at the peer and switching to use another 1028 ephemeral ID. 1030 A solution would need to combine elements which provide protection 1031 against both premeditated and on-going communication redirection. 1032 This can be done in several ways, and the current set of proposals do 1033 not appear to contain all useful combinations. For instance, the HIP 1034 CBID property could be used to prevent premeditated attacks while the 1035 WIMP hash chains could be used to prevent on-going redirection. And 1036 there are probably other interesting combinations. 1038 A related, but perhaps separate aspect, is whether the solution 1039 provides for protection against Man-in-The-Middle attacks with on- 1040 path attackers. Some schemes, such as [HIP] and [NOID] do, but given 1041 that an on-path attacker can see and modify the data traffic whether 1042 or not it can modify the multihoming signaling, this level of 1043 protection seems like overkill. Protecting against on-path MiTM for 1044 the data traffic can be done separately using IPsec, TLS, etc. 1046 Finally, preventing third party DoS attacks is conceptually simpler; 1047 it would suffice to somehow verify that the peer is indeed reachable 1048 at the new locator before sending a large number of packets to that 1049 locator. 1051 Full Copyright Statement 1053 Copyright (C) The Internet Society (2003). All Rights Reserved. 1055 This document and translations of it may be copied and furnished to 1056 others, and derivative works that comment on or otherwise explain it 1057 or assist in its implementation may be prepared, copied, published 1058 and distributed, in whole or in part, without restriction of any 1059 kind, provided that the above copyright notice and this paragraph are 1060 included on all such copies and derivative works. However, this 1061 document itself may not be modified in any way, such as by removing 1062 the copyright notice or references to the Internet Society or other 1063 Internet organizations, except as needed for the purpose of 1064 developing Internet standards in which case the procedures for 1065 copyrights defined in the Internet Standards process must be 1066 followed, or as required to translate it into languages other than 1067 English. 1069 The limited permissions granted above are perpetual and will not be 1070 revoked by the Internet Society or its successors or assignees. 1072 This document and the information contained herein is provided on an 1073 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1074 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1075 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1076 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1077 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1079 Acknowledgment 1081 Funding for the RFC Editor function is currently provided by the 1082 Internet Society.