idnits 2.17.1 draft-nordmark-multi6-threats-00.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.) 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 694, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'IPv6-SA' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'IPv6-AUTH' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 706, 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 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) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark 3 Oct 20, 2003 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 April 20, 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............................................. 2 51 2. TERMINOLOGY.............................................. 3 53 3. TODAY'S ASSUMPTIONS...................................... 4 54 3.1. Application Assumptions............................. 4 55 3.2. Redirection Attacks Today........................... 6 56 3.3. Flooding Attacks Today.............................. 6 58 4. POTENTIAL NEW REDIRECTION ATTACKS........................ 8 59 4.1. Cause Packets to be Sent to the Attacker............ 8 60 4.1.1. Once Packets are Flowing....................... 8 61 4.1.2. Premeditated Redirection....................... 9 62 4.1.3. Using Replay Attacks........................... 9 63 4.2. Cause Packets to be Sent to a Black Hole............ 10 64 4.3. Third Party Denial-of-Service Attacks............... 10 65 4.3.1. Basic Third Party DoS.......................... 11 66 4.3.2. Third Party DoS with On-Path Help.............. 12 67 4.4. Accepting Packets from Unknown Locators............. 13 69 5. OTHER SECURITY CONCERNS.................................. 14 71 6. SECURITY CONSIDERATIONS.................................. 15 73 7. ACKNOWLEDGMENTS.......................................... 16 75 8. REFERENCES............................................... 16 76 8.1. Normative References................................ 16 77 8.2. Informative References.............................. 16 79 AUTHORS' ADDRESSES........................................... 17 81 1. INTRODUCTION 83 The goal of the IPv6 multihoming work is to allow a site to take 84 advantage of multiple attachments to the global Internet without 85 having a specific entry for the site visible in the global routing 86 table. Specifically, a solution should allow hosts to use multiple 87 attachments in parallel, or to switch between these attachment points 88 dynamically in the case of failures, without an impact on the upper 89 layer protocols. 91 At the highest level the concerns about allowing such "rehoming" of 92 packet flows can be called "redirection attacks"; the ability to 93 cause packets to be sent to a place that isn't tied to the upper 94 layer protocol's notion of the peer. These attacks pose threats 95 against confidentiality, integrity, and availability. That is, an 96 attacker might learn the contents of a particular flow by redirecting 97 it to a location where the attacker has a packet recorder. If, 98 instead of a recorder, the attacker changes the packets and then 99 forwards them to the ultimate destination, the integrity of the data 100 stream would be compromised. Finally, the attacker can simply use 101 the redirection of a flow as a denial of service attack. 103 This document has been developed while considering multihoming 104 solutions architected around a separation of network identity and 105 network location. However, this separation is not a requirement for 106 all threats, so this taxonomy may also apply to other approaches. 107 This document is not intended to examine any single proposed 108 solution. Rather, it is intended as an aid to discussion and 109 evaluation of proposed solutions. By cataloging known threats, we 110 can help to ensure that all proposals deal with all of the available 111 threats. 113 2. TERMINOLOGY 115 upper layer protocol (ULP) 116 - a protocol layer immediately above IP. Examples are 117 transport protocols such as TCP and UDP, control 118 protocols such as ICMP, routing protocols such as 119 OSPF, and Internet or lower-layer protocols being 120 "tunneled" over (i.e., encapsulated in) IP such as 121 IPX, AppleTalk, or IP itself. 123 interface - a node's attachment to a link. 125 address - an IP layer name that contains both topological 126 significance and acts as a unique identifier for an 127 interface. 129 locator - an IP layer topological name for an interface or a 130 set of interfaces. 132 identifier - an IP layer identifier for an IP layer endpoint 133 (stack name in [NSRG]). The transport endpoint is a 134 function of the transport protocol and would 135 typically include the IP identifier plus a port 136 number. 138 address field 139 - the source and destination address fields in the 140 IPv6 header. As IPv6 is currently specified this 141 fields carry "addresses". If identifiers and 142 locators are separated these fields will contain 143 locators. 145 FQDN - Fully Qualified Domain Name 147 3. TODAY'S ASSUMPTIONS 149 The two interesting aspects of security for multihoming solutions are 150 the assumptions made by the applications and upper layer protocols 151 about the identifiers that they see on one hand, and the existing 152 abilities to perform redirection attacks today, on the other hand. 154 3.1. Application Assumptions 156 In the Internet today, the initiating part of applications either 157 starts with a FQDN, which it looks up in the DNS, or already has an 158 IP address from somewhere. For the FQDN to IP address lookup the 159 application effectively places trust in the DNS. Once it has the IP 160 address, the application places trust in the routing system 161 delivering packets to that address. Applications that use security 162 mechanisms, such as IPsec or TLS, with mutual authentication have the 163 ability to "bind" the FQDN to the cryptographic keying material thus 164 compromising the DNS and/or the routing system can at worst cause the 165 packets to be dropped or delivered to an entity which does not posses 166 the keying material. 168 At the responding (non-initiating) end of communication today, we 169 find applications that fall into approximately five classes with 170 respect to their security requirements. 172 The first class is the set of public content servers. These systems 173 provide data to any and all systems and are not particularly 174 concerned with confidentiality, as they make their content available 175 to all. However, they are interested in data integrity and denial of 176 service attacks. Having someone manipulate the results of a search 177 engine, for example, or prevent certain systems from reaching a 178 search engine would be a serious security issue. 180 The second class of applications use existing IP source addresses 181 from outside of their immediate local site as a means of 182 authentication without any form of verification. Today, with source 183 IP address spoofing and TCP sequence number guessing as rampant 184 attacks, such applications are effectively opening themselves for 185 public connectivity and are reliant on other systems, such as 186 firewalls, for overall security. We do not consider this class of 187 systems in this document. 189 The third class of applications receive existing IP source addresses, 190 but attempt some verification using the DNS, effectively using the 191 FQDN for access control. (This is typically done by performing a 192 reverse lookup from the IP address followed by a forward lookup and 193 verifying that the IP address matches one of the addresses returned 194 from the forward lookup.) These applications are already subject to 195 a number of attacks using techniques like source address spoofing and 196 TCP sequence number guessing since an attacker, knowing this is the 197 case, can simply create a DoS attack using a forged source address 198 that has authentic DNS records. In general this class of 199 applications is strongly discouraged, but it is probably important 200 that a multihoming solution doesn't introduce any new and easier ways 201 to perform such attacks. 203 The fourth class of applications use cryptographic security 204 techniques to provide both a strong identity for the peer and data 205 integrity with or without confidentiality. Such systems are still 206 potentially vulnerable to denial of service attacks that could be 207 introduced by a multihoming solution. 209 Finally, the fifth class of applications use cryptographic security 210 techniques but without strong identity (such as opportunistic IPsec). 211 Thus data integrity with or without confidentiality is provided when 212 communicating with an unknown/unauthenticated principal. Just like 213 the first category above such applications can't perform access 214 control since they do not know the identity of the peer. [TBD: Does 215 one-way authentication, without mutual authentication, add a 216 different class of applications?] 218 The requirement for a multihoming solution is that security be no 219 worse than it is today in all situations. Thus, mechanisms that 220 provide confidentiality, integrity, or authentication today should 221 continue to provide these properties in a multihomed environment. 223 3.2. Redirection Attacks Today 225 This section enumerates some of the redirection attacks that are 226 possible in today's Internet. 228 If routing can be compromised, packets for any destination can be 229 redirected to any location. This can be done by injecting a long 230 prefix into global routing, thereby causing the longest match 231 algorithm to deliver packets to the attacker. 233 Similarly, if DNS can be compromised, and a change can be made to an 234 advertised resource record to advertise a different IP address for a 235 hostname, effectively taking over that hostname. 237 Any system that is along the path from the source to the destination 238 host can be compromised and used to redirect traffic. Systems may be 239 added to the best path to accomplish this. Further, even systems 240 that are on multi-access links that do not provide security can also 241 be used to redirect traffic off of the normal path. For example, ARP 242 and ND spoofing can be used to attract all traffic for the legitimate 243 next hop across an Ethernet. 245 Finally, the hosts themselves that terminate the connection can also 246 be compromised and can perform functions that were not intended by 247 the end user. 249 All of the above protocol attacks are the subject of ongoing work to 250 secure them (DNSsec, security for BGP, Secure ND) and are not 251 considered further within this document. The goal for a multihoming 252 solution is not to solve these attacks. Rather, it is to avoid 253 adding to this list of attacks. 255 3.3. Flooding Attacks Today 257 In the Internet today there are several ways for an attacker to use a 258 redirection mechanism to launch DoS attacks that can not easily be 259 traced to the attacker. An example of this is to use protocols which 260 cause reflection with or without amplification [PAXSON01]. 261 Reflection without amplification can be accomplished by an attacker 262 sending a TCP SYN packet to a well-known server with a spoofed source 263 address; the resulting TCP SYN ACK packet will be sent to the spoofed 264 source address. 266 Devices on the path between two communicating entities can also 267 launch DoS attacks. While such attacks might not be interesting 268 today, it is necessary to understand them better in order to 269 determine whether a multihoming solution might enables new types of 270 DoS attacks. 272 For example, today if A is communicating with B, then A can try to 273 overload the path from B to A. If TCP is used A could do this by 274 sending ACK packets for data that it has not yet received (but it 275 suspects B has already sent) so that B would send at a rate that 276 would cause persistent congestion on the path towards A. Such an 277 attack would seem self-destructive since A would only make its own 278 corner of the network suffer by overloading the path from the 279 Internet towards A. 281 A more interesting case is if A is communicating with B and X is on 282 the path between A and B, then X might be able to fool B to send 283 packets towards A at a rate that is faster than A (and the path 284 between A and X) can handle. For instance, if TCP is used then X can 285 craft TCP ACK packets claiming to come from A to cause B to use a 286 congestion window that is large enough to potentially cause 287 persistent congestion towards A. Furthermore, if X can suppress the 288 packets from A to B it can also prevent A from sending any explicit 289 "slow down" packets to B. Similar attacks can presumably be launched 290 using protocols that carry streaming media by forging such a 291 protocol's notion of acknowledgment and feedback. 293 An attribute of this type of attack is that A will simply think that 294 B is faulty since its flow and congestion control mechanisms don't 295 seem to be working. Detecting that the stream of ACK packets is 296 generated from X and not from A might be challenging, since the rate 297 of ACK packets might be relatively low. This type of attack might 298 not be common today because it requires that X remain on the path in 299 order to sustain the DoS attack, but the addition of multihoming 300 redirection mechanisms might potentially remove that constraint. And 301 with the current, no-multihoming support, using end-to-end strong 302 security at a protocol level at (or below) this "ACK" processing 303 would prevent this type of attack. But if a multihoming solution is 304 provided underneath IPsec that prevention mechanism would not exist. 306 Thus the challenge for multihoming solutions is to not create 307 additional types of attacks in this area, or make existing types of 308 attacks significantly easier. 310 4. POTENTIAL NEW REDIRECTION ATTACKS 312 This section documents the additional redirection attacks that have 313 been discovered that result from an architecture where hosts can 314 change their topological connection to the network in the middle of a 315 transport session without interruption. This discussion is again 316 framed in the context of independent host identifiers and topological 317 locators. Some of these attacks may not be applicable if traditional 318 addresses are used. This section assumes that each host has multiple 319 locators and that there is some mechanism for determining the 320 locators for a correspondent host. We do not assume anything about 321 the properties of these mechanisms. Instead, this list will serve to 322 help us derive the properties of these mechanisms that will be 323 necessary to prevent these redirection attacks. 325 Depending on the purpose of the redirection attack we separate the 326 attacks into several different types. 328 4.1. Cause Packets to be Sent to the Attacker 330 An attacker might want to receive the flow of packets, for instance 331 to be able to inspect and/or modify the payload or to be able to 332 apply cryptographic analysis to cryptographically protected payload, 333 using redirection attacks. 335 4.1.1. Once Packets are Flowing 337 This might be viewed as the "classic" redirection attack. 339 While A and B are communicating X might send packets to B and claim: 340 "Hi, I'm A, send my packets to my new location." where the location 341 is really X's location. 343 "Standard" solutions to this include requiring the node requesting 344 redirection somehow be verified to be the same node as the initial 345 node to establish communication. However, the burdens of such 346 verification must not be onerous, or the redirection requests 347 themselves can be used as a DoS attack. 349 To prevent this type of attack, a solution would need some mechanism 350 that B can use to verify whether a locator belongs to A before B 351 starts using that locator, and be able to do this when multiple 352 locators are assigned to A. 354 4.1.2. Premeditated Redirection 356 This is a variant of the above where the attacker "installs" itself 357 before communication starts. 359 For example, if the attacker X can predict that A and B will 360 communicate in the (near) future, then the attacker can tell B: "Hi, 361 I'm A and I'm at this location". When A later tries to communicate 362 with B, will B believe it is really A? 364 If the solution to the classic redirection attack is based on "prove 365 you are the same as initially", then A will fail to prove this to B 366 since X initiated communication. 368 Depending on details that would be specific to a proposed solution, 369 this type of attack could either case redirection (so that the 370 packets intended for A will be sent to X) or they could cause DoS 371 (where A would fail to communicate with B since it can't prove it is 372 the same node as X). 374 To prevent this attack, the verification whether a locator belongs to 375 the peer can not simply be based on the first peer that made contact. 377 4.1.3. Using Replay Attacks 379 While the multihoming problem doesn't inherently imply any 380 topological movement it is useful to also consider the impact of site 381 renumbering in combination with multihoming. In that case the set of 382 locators for a node will change each time its site renumbers and at 383 some point in time after a renumbering event the old locator prefix 384 might be reassigned to some other site. 386 This potentially opens up the ability for an attacker to replay 387 whatever protocol mechanism was used to inform a node of a peer's 388 locators so that the node would incorrectly be lead to believe that 389 the old locator (set) should be used even long after a renumbering 390 event. This is similar to the risk of replay of Binding Updates in 391 [MIPv6] but the time constant is quite different; Mobile IPv6 might 392 see movements every second while site renumbering followed by 393 reassignment of the site locator prefix might be a matter of weeks or 394 months. 396 To prevent such replay attacks the protocol which is used to verify 397 which locators can be used with a particular identifier needs some 398 replay protection mechanism. 400 Also, in this space one needs to be concerned about potential 401 interaction between such replay protection and the administrative act 402 of reassignment of a locator. If the identifier and locator 403 relationship is distributed across the network one would need to make 404 sure that the old information has been completely purged from the 405 network before any reassignment. Note that this does not require 406 explicit mechanism. This can instead be implemented by locator reuse 407 policy and careful timeouts of locator information. 409 4.2. Cause Packets to be Sent to a Black Hole 411 This is also a variant of the classic redirection attack. The 412 difference is that the new location is a locator that is nonexistent 413 or unreachable. Thus the effect is that sending packets to the new 414 locator causes the packets to be dropped by the network somewhere. 416 One would expect that solutions which prevent the previous 417 redirection attacks would prevent this attack as a side effect, but 418 it makes sense to include this attack here for completeness. 419 Mechanisms that prevented a redirection attack to the attacker should 420 also prevent redirection to a black hole. 422 4.3. Third Party Denial-of-Service Attacks 424 An attacker can use the ability to perform redirection to cause 425 overload on an unrelated third party. For instance, if A and B are 426 communicating then the attacker X might be able to convince A to send 427 the packets intended for B to some third node C. While this might 428 seem harmless at first, since X could just flood C with packets 429 directly, there are a few aspects of these attacks that cause 430 concern. 432 The first is that the attacker might be able to completely hide its 433 identity and location. It might suffice for X to send and receive a 434 few packets to A in order to perform the redirection, and A might not 435 retain any state on who asked for the redirection to C's location. 436 Even if A had retained such state, that state would probably not be 437 easily available to C, thus C can't determine who was the attacker 438 once C is being DoS'ed. 440 The second concern is that with a direct DoS attack from X to C, the 441 attacker is limited by the bandwidth of its own path towards C. If 442 the attacker can fool another node like A to redirect its traffic to 443 C then the bandwidth is limited by the path from A towards C. If A 444 is a high-capacity Internet service and X has slow (e.g., dialup) 445 connectivity this difference could be substantial. Thus in effect 446 this could be similar to packet amplifying reflectors in [PAXSON01]. 448 The third, and final concern, is that if an attacker only need a few 449 packets to convince one node to flood a third party, then it wouldn't 450 be hard for the attacker to convince lots of nodes to flood the same 451 third party. Thus this could be used for Distributed Denial-of- 452 Service attacks. 454 In today's Internet the ability to perform this type of attack is 455 quite limited. In order for the attacker to initiate communication 456 it will in most cases need to be able to receive some packets from 457 the peer (the potential exception being combining this with TCP 458 sequence number guessing type of techniques). Furthermore, to the 459 extent that parts of the Internet uses ingress filtering [INGRESS], 460 even if the communication could be initiated it wouldn't be possible 461 to sustain it by sending ACK packets with spoofed source addresses 462 from an off-path attacker. 464 If this type of attack can't be prevented there might be mitigation 465 techniques that can be employed. For instance, in the case of TCP it 466 would help if TCP slow-start was triggered when the destination 467 locator changes. (Folks might argue that, separately from security, 468 this would be the correct action for congestion control since TCP 469 might not have any congestion-relation information about the new path 470 implied by the new locator). Applying this technique to other ULPs 471 which perform different forms of (TCP friendly) congestion control 472 might be more difficult since the lower layers generally lack an API 473 to provide such information to the ULPs. Also, for other protocols, 474 this might be less beneficial, since other ULPs might not adapt 475 rapidly and could view the suggestion of congestion as being more 476 severe than a simple deficit of congestion information. 478 4.3.1. Basic Third Party DoS 480 Assume that X is on a slow link anywhere in the Internet. B is on a 481 fast link (gigabits; e.g. a media server) and A is the victim. 483 X could flood A directly but is limited by its low bandwidth. If X 484 can establish communication with B, ask B to send it a high-speed 485 media stream, then X can presumably fake out the 486 "acknowledgments/feedback" needed for B to blast out packets at full 487 speed. So far this only hurts X - and the path between X and the 488 Internet. But if X could also tell B "I'm at A's locator" then X has 489 effectively used this redirection capability in multihoming to 490 amplify its DoS capability, which would be a source of concern. 492 One could envision rather simple techniques to prevent such attacks. 493 For instance, before sending to a new peer locator perform a clear 494 text exchange with the claimed new locator of the form "Are you X?" 495 resulting in "Yes, I'm X.". This would suffice for the simplest of 496 attacks. However, as we will see below, more sophisticated attacks 497 are possible. 499 4.3.2. Third Party DoS with On-Path Help 501 The scenario is as above but in addition the attacker X has a friend 502 Y on the path between A and B: 504 ----- ----- ----- 505 | A |--------| Y |--------| B | 506 ----- ----- ----- 507 / 508 / 509 / 510 / 511 / 512 / 513 ----- 514 | X | 515 ----- 517 With the simple solution suggested in the previous section, all Y 518 might need to do is to fake a response to the "Are you X?" packet, 519 and after that point in time Y might not be needed; X could 520 potentially sustain the data flow towards A by generating the ACK 521 packets. Thus it would be even harder to detect the existence of Y. 523 Furthermore, if X is not the actual end system but an attacker 524 between some node C and B, then X can claim to be C, and no finger 525 can be pointed at X either: 527 ----- ----- ----- 528 | A |--------| Y |--------| B | 529 ----- ----- ----- 530 / 531 / 532 / 533 / 534 / 535 / 536 ----- ----- 537 | C |-------| X | 538 ----- ----- 540 Thus with two attackers on different paths, there might be no trace 541 of who did the redirection to the 3rd party once the redirection has 542 taken place. 544 A specific case of this is when X=Y, and X is located on the same LAN 545 as B. 547 A potential way to make such attacks harder would be to use the last 548 received (and verified) source locator as the destination locator. 549 That way when X sends the ACK packets (whether it claims to be X or 550 C) the result would be that the packet flow from B would switch back 551 towards X/C, which would result in an attack similar to what can be 552 performed in today's Internet. 554 Another way that a multihoming solution might address this is to 555 ensure that B will only accept locators that can be authenticated to 556 be synonymous with the original correspondent. It must be possible 557 to securely ensure that these locators form an equivalence class. So 558 in the first example, not only does X need to assert that it is A, 559 but A needs to assert that it is X. 561 4.4. Accepting Packets from Unknown Locators 563 The multihoming solution space does not only affect the destination 564 of packets; it also raises the question from which sources packets 565 should be accepted. It is possible to build a multihoming solution 566 that allows traffic to be recognized as coming from the same peer 567 even if there is a previously unknown locator present in the source 568 address field. The question is whether we want to allow packets from 569 unverified sources to be passed on to upper layer protocols. 571 In the current Internet, an attacker can't inject packets with 572 arbitrary source addresses into a session if there is ingress 573 filtering present, so allowing packets with unverified sources in a 574 multihoming solution would fail our "no worse than what we have now" 575 litmus test. However, given that ingress filtering deployment is far 576 from universal and ingress filtering typically wouldn't prevent 577 spoofing of addresses in the same subnet, requiring rejecting packets 578 from unverified locators might be too stringent. A factor to take 579 into account to determine the "requirement level" for this is that 580 when IPsec is used on top of the multihoming solution, then IPsec 581 will reject such spoofed packets. (Note that this is different than 582 in the redirection attack cases where even with IPsec an attacker 583 could potentially cause a DoS attack.) 585 There might also be a middle ground where arbitrary attackers are 586 prevented from injecting packets by using the SCTP verification tag 587 type of approach [SCTP]. (This is a clear-text tag which is sent to 588 the peer which the peer is expected to include in each subsequent 589 packet.) Such an approach doesn't prevent packet injection from on- 590 path attackers (since they can observe the verification tag), but 591 neither does ingress filtering. 593 5. OTHER SECURITY CONCERNS 595 The protocol mechanisms added as part of a multihoming solution 596 shouldn't introduce any new DoS in the mechanisms themselves. In 597 particular, care must be taken not to: 599 - create state on the first packet in an exchange, since that could 600 result in state consumption attacks similar to the TCP SYN 601 flooding attack. 603 - perform much work on the first packet in an exchange (such as 604 expensive verification) 606 There is a potential chicken-and-egg problem here, because 607 potentially one would want to avoid doing work or creating state 608 until the peer has been verified, but verification will probably need 609 some state and some work to be done. 611 A possible approach that solutions might investigate is to defer 612 verification until there appears to be two different nodes (or two 613 different locators for the same node) that want to use the same 614 identifier. 616 Another possible approach is to first establish communications, and 617 then perform verification in parallel with normal data transfers. 618 Redirection would only be permitted after verification was complete, 619 but prior to that event, data could transfer in a normal, non- 620 multihomed manner. 622 Finally, the new protocol mechanisms should be protected against 623 spoofed packets, at least from off-path sources, and replayed 624 packets. 626 6. SECURITY CONSIDERATIONS 628 In section 3 we discussed existing protocol-based redirection 629 attacks. But there are also non-protocol redirection attacks. An 630 attacker which can gain physical access to one of 632 - The copper/fiber somewhere in the path. 634 - A router or L2 device in the path. 636 - One of the end systems 638 can also redirect packets. This could be possible for instance by 639 physical break-ins or by bribing staff that have access to the 640 physical infrastructure. Such attacks are out of scope for this 641 discussion, but are worth to keep in mind when looking at the cost 642 for an attacker to exploit any protocol-based attacks against 643 multihoming solutions; making protocol-based attacks much more 644 expensive to launch than break-ins/bribery type of attacks might be 645 overkill. 647 7. ACKNOWLEDGMENTS 649 This document is a product of a MULTI6 design team consisting of (in 650 alphabetical order): Iljitsch van Beijnum, Steve Bellovin, Brian 651 Carpenter, Mike O'Dell, Sean Doran, Dave Katz, Tony Li, Erik 652 Nordmark, and Pekka Savola. 654 Much of the awareness of these threats come from the work on Mobile 655 IPv6 [MIPv6, NIKANDER03, AURA02]. 657 8. REFERENCES 659 8.1. Normative References 661 8.2. Informative References 663 [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the 664 NSRG", draft-irtf-nsrg-report-09.txt (work in progress), 665 March 2003. 667 [MIPv6] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support in 668 IPv6", draft-ietf-mobileip-ipv6-24.txt (work in progress), 669 June 2003. 671 [AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", 672 draft-aura-mipv6-bu-attacks-01 (work in progress), March 673 2002. 675 [NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E. 676 Nordmark, "Mobile IP version 6 Route Optimization Security 677 Design Background", draft-nikander-mobileip-v6-ro-sec-01 678 (work in progress), June 2003. 680 [PAXSON01] V. Paxson, "An Analysis of Using Reflectors for 681 Distributed Denial-of-Service Attacks", Computer 682 Communication Review 31(3), July 2001. 684 [INGRESS] Ferguson P., and D. Senie, "Network Ingress Filtering: 685 Defeating Denial of Service Attacks which employ IP Source 686 Address Spoofing", RFC 2827, May 2000. 688 [SCTP] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. 690 Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and 691 V. Paxson, "Stream Control Transmission Protocol", RFC 692 2960, October 2000. 694 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 695 Addressing Architecture", RFC 3513, April 2003. 697 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 698 6 (IPv6) Specification", RFC 2461. 700 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 701 Protocol". RFC 2401, November 1998. 703 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, 704 November 1998. 706 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 707 RFC 2406, November 1998. 709 AUTHORS' ADDRESSES 711 Erik Nordmark Tony Li 712 Sun Microsystems, Inc. Procket Networks, Inc. 713 17 Network Circle 1110 Cadillac Ct. 714 Mountain View, CA Milpitas, CA 715 USA USA 717 phone: +1 650 786 2921 phone: +1 408 635 7903 718 fax: +1 650 786 5896 fax: +1 408 635 7522 719 email: erik.nordmark@sun.com email: Tony.Li@procket.com 721 Full Copyright Statement 723 Copyright (C) The Internet Society (2003). All Rights Reserved. 725 This document and translations of it may be copied and furnished to 726 others, and derivative works that comment on or otherwise explain it 727 or assist in its implementation may be prepared, copied, published 728 and distributed, in whole or in part, without restriction of any 729 kind, provided that the above copyright notice and this paragraph are 730 included on all such copies and derivative works. However, this 731 document itself may not be modified in any way, such as by removing 732 the copyright notice or references to the Internet Society or other 733 Internet organizations, except as needed for the purpose of 734 developing Internet standards in which case the procedures for 735 copyrights defined in the Internet Standards process must be 736 followed, or as required to translate it into languages other than 737 English. 739 The limited permissions granted above are perpetual and will not be 740 revoked by the Internet Society or its successors or assignees. 742 This document and the information contained herein is provided on an 743 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 744 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 745 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 746 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 747 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 749 Acknowledgment 751 Funding for the RFC Editor function is currently provided by the 752 Internet Society.