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