idnits 2.17.1 draft-ietf-multi6-multihoming-threats-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1487. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1503), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- No issues found here. 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 1162, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 1165, but no explicit reference was found in the text == Unused Reference: 'IPv6-SA' is defined on line 1168, but no explicit reference was found in the text == Unused Reference: 'IPv6-AUTH' is defined on line 1171, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'MAST' is defined on line 1205, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) -- 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) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark 3 Nov 19, 2004 Sun Microsystems 4 Tony Li 5 Threats relating to IPv6 multihoming solutions 6 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet Draft expires May 19, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document lists security threats related to IPv6 multihoming. 40 Multihoming can introduce new opportunities to redirect packets to 41 different, unintended IP addresses. 43 The intent is to look at how IPv6 multihoming solutions might make 44 the Internet less secure than the current Internet, without studying 45 any proposed solution but instead looking at threats that are 46 inherent in the problem itself. The threats in this document build 47 upon the threats discovered and discussed as part of the Mobile IPv6 48 work. 50 Contents 52 1. INTRODUCTION............................................. 3 53 1.1. Assumptions......................................... 4 54 1.2. Authentication, Authorization, and Identifier Ownership 5 56 2. TERMINOLOGY.............................................. 6 58 3. TODAY'S ASSUMPTIONS AND ATTACKS.......................... 7 59 3.1. Application Assumptions............................. 7 60 3.2. Redirection Attacks Today........................... 9 61 3.3. Packet Injection Attacks Today...................... 10 62 3.4. Flooding Attacks Today.............................. 10 63 3.5. Address Privacy Today............................... 12 65 4. POTENTIAL NEW ATTACKS.................................... 13 66 4.1. Cause Packets to be Sent to the Attacker............ 14 67 4.1.1. Once Packets are Flowing....................... 14 68 4.1.2. Time-shifting Attack........................... 14 69 4.1.3. Premeditated Redirection....................... 15 70 4.1.4. Using Replay Attacks........................... 15 71 4.2. Cause Packets to be Sent to a Black Hole............ 16 72 4.3. Third Party Denial-of-Service Attacks............... 16 73 4.3.1. Basic Third Party DoS.......................... 17 74 4.3.2. Third Party DoS with On-Path Help.............. 18 75 4.4. Accepting Packets from Unknown Locators............. 19 76 4.5. New Privacy Considerations.......................... 20 78 5. GRANULARITY OF REDIRECTION............................... 21 80 6. MOVEMENT IMPLICATIONS?................................... 22 82 7. OTHER SECURITY CONCERNS.................................. 23 84 8. SECURITY CONSIDERATIONS.................................. 24 86 9. IANA CONSIDERATIONS...................................... 25 88 10. ACKNOWLEDGMENTS......................................... 25 90 11. REFERENCES.............................................. 25 91 11.1. Normative References............................... 25 92 11.2. Informative References............................. 25 94 AUTHORS' ADDRESSES........................................... 27 96 APPENDIX A: CHANGES SINCE PREVIOUS DRAFT..................... 28 97 APPENDIX B: SOME SECURITY ANALYSIS........................... 30 99 1. INTRODUCTION 101 The goal of the IPv6 multihoming work is to allow a site to take 102 advantage of multiple attachments to the global Internet without 103 having a specific entry for the site visible in the global routing 104 table. Specifically, a solution should allow hosts to use multiple 105 attachments in parallel, or to switch between these attachment points 106 dynamically in the case of failures, without an impact on the 107 transport and application layer protocols. 109 At the highest level the concerns about allowing such "rehoming" of 110 packet flows can be called "redirection attacks"; the ability to 111 cause packets to be sent to a place that isn't tied to the transport 112 and/or application layer protocol's notion of the peer. These 113 attacks pose threats against confidentiality, integrity, and 114 availability. That is, an attacker might learn the contents of a 115 particular flow by redirecting it to a location where the attacker 116 has a packet recorder. If, instead of a recorder, the attacker 117 changes the packets and then forwards them to the ultimate 118 destination, the integrity of the data stream would be compromised. 119 Finally, the attacker can simply use the redirection of a flow as a 120 denial of service attack. 122 This document has been developed while considering multihoming 123 solutions architected around a separation of network identity and 124 network location, whether or not this separation implies the 125 introduction of a new and separate identifier name space. However, 126 this separation is not a requirement for all threats, so this 127 taxonomy may also apply to other approaches. This document is not 128 intended to examine any single proposed solution. Rather, it is 129 intended as an aid to discussion and evaluation of proposed 130 solutions. By cataloging known threats, we can help to ensure that 131 all proposals deal with all of the available threats. 133 As a result of not analyzing a particular solution, this document is 134 inherently incomplete. An actual solution would need to be analyzed, 135 especially in the following areas: 137 1) If we were to make the split between locators and identifiers, 138 then we probably want to tie most application security mechanisms 139 to the identifier, not to the locator. Therefore, work is needed 140 to understand how attacks on the identifier mechanism affect 141 security, especially, in my mind, attacks on any mechanism(s) 142 that bind locators to identifiers. 144 2) Does multicast make matters worse? It usually does. 146 3) Connection-less transport protocols need more attention. They 147 are already difficult to secure, even without a 148 locator/identifier split. 150 1.1. Assumptions 152 This threat analysis doesn't assume that security has been applied 153 other security relevant parts of the Internet, such as DNS and 154 routing protocols, but it does assume that at some point in time at 155 least parts of the Internet will be operating with security for such 156 key infrastructure. With that assumption it then becomes important 157 that a multihoming solution would not, at that point in time, become 158 the weakest link. This is the case even if, for instance, insecure 159 DNS might be the weakest link today. 161 This document doesn't assume that the application protocols are 162 protected by strong security today or in the future. However, it is 163 still useful to assume that the application protocols which care 164 about integrity and/or confidentiality apply the relevant end-to-end 165 security measures, such as IPsec, TLS, and/or application layer 166 security. 168 For simplicity we assume that an on-path attacker can see packets, 169 modify packets and send them out, and block packets from being 170 delivered. This is a simplification because there might exist ways, 171 for instance monitoring capability in switches, which allow 172 authenticated and authorized users to observe packets without being 173 able to send or block the packets. 175 [DISCUSSION: It isn't clear to what extent the above simplifying 176 assumption is misleading, that is, whether we need to make a 177 distinction between on-path attackers which can monitor packets 178 and perhaps also inject packets, without being able to block 179 packets from passing through. 181 On-path attackers that only need to monitor might be lucky and 182 find a non-switched Ethernet in the path, or use capacitive or 183 inductive coupling to listen on a copper wire. But if the 184 attacker is on an Ethernet that is on the path, whether switched 185 or not, the attacker can also employ ARP/ND spoofing to get access 186 to the packet flow which allows blocking as well. Similarly, if 187 the attacker has access to the wire, the attacker can also place a 188 device on the wire to block. Other on-path attacks would be those 189 that gain control of a router or a switch (or gain control of one 190 of the endpoints) and I think those would allow blocking as well. 192 So the strongest currently known case where monitoring (and 193 injecting?) is easier than blocking, is when switches and routers 194 have monitoring capabilities (for network management or for lawful 195 intercept) where an attacker might be able to bypass the 196 authentication and authorization checks for those capabilities.] 198 We assume that an off-path attacker can neither see packets between 199 the peers (for which it is not on the path) nor block them from being 200 delivered. Off-path attackers can in general send packets with 201 arbitrary IP source addresses and content, but such packets might be 202 blocked if ingress filtering [INGRESS] is applied. Thus it is 203 important to look at the multihoming impact on security both in the 204 presence and absence of ingress filtering. 206 1.2. Authentication, Authorization, and Identifier Ownership 208 The overall problem domain can be described using different 209 terminology. 211 One way to describe it is that it is necessary to first authenticate 212 the peer and then verify that the peer is authorized to control the 213 locators used for a particular identifier. While this is correct, it 214 might place too much emphasis on the authorization aspect. In this 215 case the authorization is conceptually very simple; each host (each 216 identifier) is authorized to control which locators are used for 217 itself. 219 Hence there is a different way to describe the same thing. If the 220 peer can somehow prove that it is the owner of the identifier, then 221 the peer can control the locators that are used with the identifier. 222 This way to describe the problem is used in [OWNER]. 224 Both ways to look at the problem, hence both sets of terminology, are 225 useful when trying to understand the problem space and the threats. 227 2. TERMINOLOGY 229 link - a communication facility or medium over which nodes 230 can communicate at the link layer, i.e., the layer 231 immediately below IPv6. Examples are Ethernets 232 (simple or bridged); PPP links; X.25, Frame Relay, 233 or ATM networks; and Internet (or higher) layer 234 "tunnels", such as tunnels over IPv4 or IPv6 itself. 236 interface - a node's attachment to a link. 238 address - an IP layer name that has both topological 239 significance (i.e., a locator) and identifies an 240 interface. There may be multiple addresses per 241 interface. Normally an address uniquely identifies 242 an interfaces but there are cases when the same 243 unicast address is assigned to multiple interfaces 244 on the same node, as well as anycast address which 245 can be assigned to different interfaces on different 246 nodes. 248 locator - an IP layer topological name for an interface or a 249 set of interfaces. There may be multiple locators 250 per interface. 252 identifier - an IP layer identifier for an IP layer endpoint 253 (stack name in [NSRG]), that is, something that 254 might be commonly referred to as a "host". The 255 transport endpoint name is a function of the 256 transport protocol and would typically include the 257 IP identifier plus a port number. There might be 258 use for having multiple identifiers per stack/per 259 host. 261 The identifiers are not associated with an 262 interface. 264 address field 265 - the source and destination address fields in the 266 IPv6 header. As IPv6 is currently specified this 267 fields carry "addresses". If identifiers and 268 locators are separated these fields will contain 269 locators. 271 FQDN - Fully Qualified Domain Name [FYI18] 273 3. TODAY'S ASSUMPTIONS AND ATTACKS 275 The two interesting aspects of security for multihoming solutions are 276 the assumptions made by the transport layer and application layer 277 protocols about the identifiers that they see on one hand, and the 278 existing abilities to perform today various attacks related to the 279 identity/location relationship, on the other hand. 281 3.1. Application Assumptions 283 In the Internet today, the initiating part of applications either 284 starts with a FQDN, which it looks up in the DNS, or already has an 285 IP address from somewhere. For the FQDN to IP address lookup the 286 application effectively places trust in the DNS. Once it has the IP 287 address, the application places trust in the routing system 288 delivering packets to that address. Applications that use mutually 289 authenticating security mechanisms, such as IPSEC or TLS, have the 290 ability to bind an address or FQDN to cryptographic keying material. 291 Compromising the DNS and/or routing system can result in packets 292 being dropped or delivered to an attacker in such cases, but since 293 the attacker does not possess the keying material the application 294 will not trust the attacker, and the attacker can not decrypt what it 295 receives. 297 At the responding (non-initiating) end of communication today, we 298 find that the security configurations used by different applications 299 that fall into approximately five classes, where a single application 300 might use different classes of configurations for different types of 301 communication. 303 The first class is the set of public content servers. These systems 304 provide data to any and all systems and are not particularly 305 concerned with confidentiality, as they make their content available 306 to all. However, they are interested in data integrity and denial of 307 service attacks. Having someone manipulate the results of a search 308 engine, for example, or prevent certain systems from reaching a 309 search engine would be a serious security issue. 311 The second class of security configurations use existing IP source 312 addresses from outside of their immediate local site as a means of 313 authentication without any form of verification. Today, with source 314 IP address spoofing and TCP sequence number guessing as rampant 315 attacks [RFC1948], such applications are effectively opening 316 themselves for public connectivity and are reliant on other systems, 317 such as firewalls, for overall security. We do not consider this 318 class of configurations in this document because they are in any case 319 fully open to all forms of network layer spoofing. 321 The third class of security configurations receive existing IP source 322 addresses, but attempt some verification using the DNS, effectively 323 using the FQDN for access control. (This is typically done by 324 performing a reverse lookup from the IP address followed by a forward 325 lookup and verifying that the IP address matches one of the addresses 326 returned from the forward lookup.) These applications are already 327 subject to a number of attacks using techniques like source address 328 spoofing and TCP sequence number guessing since an attacker, knowing 329 this is the case, can simply create a DoS attack using a forged 330 source address that has authentic DNS records. In general this class 331 of security configurations is strongly discouraged, but it is 332 probably important that a multihoming solution doesn't introduce any 333 new and easier ways to perform such attacks. However, we note that 334 some people think we should treat this class the same as the second 335 class of security configurations. 337 The fourth class of security configurations use cryptographic 338 security techniques to provide both a strong identity for the peer 339 and data integrity with or without confidentiality. Such systems are 340 still potentially vulnerable to denial of service attacks that could 341 be introduced by a multihoming solution. 343 Finally, the fifth class of security configurations use cryptographic 344 security techniques but without strong identity (such as 345 opportunistic IPsec). Thus data integrity with or without 346 confidentiality is provided when communicating with an 347 unknown/unauthenticated principal. Just like the first category 348 above such applications can't perform access control based on network 349 layer information since they do not know the identity of the peer. 350 However, they might perform access control using higher-level notions 351 of identity. The availability of IPsec (and similar solutions) 352 together with channel bindings allow protocols which in themselves 353 are vulnerable to MiTM-attacks to operate with a high level of 354 confidentiality in the security of the identification of the peer. A 355 typical example is the Remote Desktop Protocol (RDP) which when used 356 with opportunistic IPsec works well if channel bindings are 357 available. Channel bindings provide a link between the IP-layer 358 identification and the application protocol identification. 360 A variant of the fifth class are those that use "leap-of-faith" 361 during some initial communication, hence do not provide strong 362 identities, but where subsequent communication is bound to the 363 initial communication providing strong protection that the peer is 364 the same as during the initial communication. 366 The fifth class is important and its security properties must be 367 preserved by a multihoming solution. 369 The requirement for a multihoming solution is that security be no 370 worse than it is today in all situations. Thus, mechanisms that 371 provide confidentiality, integrity, or authentication today should 372 continue to provide these properties in a multihomed environment. 374 3.2. Redirection Attacks Today 376 This section enumerates some of the redirection attacks that are 377 possible in today's Internet. 379 If routing can be compromised, packets for any destination can be 380 redirected to any location. This can be done by injecting a long 381 prefix into global routing, thereby causing the longest match 382 algorithm to deliver packets to the attacker. 384 Similarly, if DNS can be compromised, and a change can be made to an 385 advertised resource record to advertise a different IP address for a 386 hostname, effectively taking over that hostname. More detailed 387 information about threats relating to DNS are in [DNS-THREATS]. 389 Any system that is along the path from the source to the destination 390 host can be compromised and used to redirect traffic. Systems may be 391 added to the best path to accomplish this. Further, even systems 392 that are on multi-access links that do not provide security can also 393 be used to redirect traffic off of the normal path. For example, ARP 394 and ND spoofing can be used to attract all traffic for the legitimate 395 next hop across an Ethernet. And since the vast majority of 396 applications rely on DNS lookups, if DNSsec is not deployed, then 397 attackers that are on the path between the host and the DNS servers 398 can also cause redirection by modifying the responses from the DNS 399 servers. 401 In general the above attacks work only when the attacker is on the 402 path at the time it is performing the attack. However, in some cases 403 it is possible for an attacker to create a DoS attack which remains 404 at least some time after the attacker has moved off the path. An 405 example of this is an attacker which uses ARP or ND spoofing while on 406 path to either insert itself or send packets to a black hole (a 407 non-existent L2 address). After the attacker moves away the ARP/ND 408 entries will remain in the caches in the neighboring nodes for some 409 amount of time; a minute or so in the case of ARP. This will result 410 in packets continuing to be black-holed until ARP entry is flushed. 412 Finally, the hosts themselves that terminate the connection can also 413 be compromised and can perform functions that were not intended by 414 the end user. 416 All of the above protocol attacks are the subject of ongoing work to 417 secure them (DNSsec, security for BGP, Secure ND) and are not 418 considered further within this document. The goal for a multihoming 419 solution is not to solve these attacks. Rather, it is to avoid 420 adding to this list of attacks. 422 3.3. Packet Injection Attacks Today 424 In today's Internet the transport layer protocols, such as TCP and 425 SCTP, which use IP, use the IP addresses as the identifiers for the 426 communication. In the absence of ingress filtering [INGRESS] the IP 427 layer allows the sender to use an arbitrary source address, thus the 428 transport protocols and/or applications need some protection against 429 malicious senders injecting bogus packets into the packet stream 430 between two communicating peers. If this protection can be 431 circumvented, then it is possible for an attacker to cause harm 432 without necessarily needing to redirect the return packets. 434 There are various level of protection in different transport 435 protocols. For instance, in general TCP packets have to contain a 436 sequence that falls in the receiver's window to be accepted. If the 437 TCP initial sequence numbers are random then it is relatively hard 438 for an off-path attacker to guess the sequence number close enough 439 for it to belong to the window, and as result be able to inject a 440 packet into an existing connection. How hard this is depends on the 441 size of the available window. SCTP provides a stronger mechanism 442 with the verification tag; an off-path attacker would need to guess 443 this random 32-bit number. Of course, IPsec provide 444 cryptographically strong mechanisms which prevent attackers on or off 445 path to inject packets once the security associations have been 446 established. 448 When ingress filtering is deployed between the potential attacker and 449 the path between the communicating peers, it can prevent the attacker 450 from using the peer's IP address as source. In that case the packet 451 injection will fail in today's Internet. 453 We don't expect a multihoming solution improve the existing degree of 454 prevention against packet injection. However, it is necessary to 455 look carefully whether a multihoming solution makes it easier for 456 attackers to inject packets since the desire to have the peer be 457 present at multiple locators, and perhaps at a dynamic set of 458 locators, can potentially result in solutions that, even in the 459 presence of ingress filtering, make packet injection easier. 461 3.4. Flooding Attacks Today 463 In the Internet today there are several ways for an attacker to use a 464 redirection mechanism to launch DoS attacks that can not easily be 465 traced to the attacker. An example of this is to use protocols which 466 cause reflection with or without amplification [PAXSON01]. 468 Reflection without amplification can be accomplished by an attacker 469 sending a TCP SYN packet to a well-known server with a spoofed source 470 address; the resulting TCP SYN ACK packet will be sent to the spoofed 471 source address. 473 Devices on the path between two communicating entities can also 474 launch DoS attacks. While such attacks might not be interesting 475 today, it is necessary to understand them better in order to 476 determine whether a multihoming solution might enables new types of 477 DoS attacks. 479 For example, today if A is communicating with B, then A can try to 480 overload the path from B to A. If TCP is used A could do this by 481 sending ACK packets for data that it has not yet received (but it 482 suspects B has already sent) so that B would send at a rate that 483 would cause persistent congestion on the path towards A. Such an 484 attack would seem self-destructive since A would only make its own 485 corner of the network suffer by overloading the path from the 486 Internet towards A. 488 A more interesting case is if A is communicating with B and X is on 489 the path between A and B, then X might be able to fool B to send 490 packets towards A at a rate that is faster than A (and the path 491 between A and X) can handle. For instance, if TCP is used then X can 492 craft TCP ACK packets claiming to come from A to cause B to use a 493 congestion window that is large enough to potentially cause 494 persistent congestion towards A. Furthermore, if X can suppress the 495 packets from A to B it can also prevent A from sending any explicit 496 "slow down" packets to B, that is, X can disable any flow or 497 congestion control mechanism such as Explicit Congestion Notification 498 [ECN]. Similar attacks can presumably be launched using protocols 499 that carry streaming media by forging such a protocol's notion of 500 acknowledgment and feedback. 502 An attribute of this type of attack is that A will simply think that 503 B is faulty since its flow and congestion control mechanisms don't 504 seem to be working. Detecting that the stream of ACK packets is 505 generated from X and not from A might be challenging, since the rate 506 of ACK packets might be relatively low. This type of attack might 507 not be common today because, in the presence of ingress filtering, it 508 requires that X remain on the path in order to sustain the DoS 509 attack. And in the absence of ingress filtering an attacker would 510 either need to be present on the path initially and then move away, 511 or the attacker would need to be able to perform the setup of the 512 communication "blind" i.e., without seeing the return traffic (which 513 in the case of TCP implies guessing the initial sequence number). 515 The danger is that the addition of multihoming redirection mechanisms 516 might potentially remove the constraint that the attacker remain on 517 the path. And with the current, no-multihoming support, using 518 end-to-end strong security at a protocol level at (or below) this 519 "ACK" processing would prevent this type of attack. But if a 520 multihoming solution is provided underneath IPsec that prevention 521 mechanism would potentially not exist. 523 Thus the challenge for multihoming solutions is to not create 524 additional types of attacks in this area, or make existing types of 525 attacks significantly easier. 527 3.5. Address Privacy Today 529 In today's Internet there is limited ability to track a host as it 530 uses the Internet because in some cases, such as dialup connectivity, 531 the host will acquire different IPv4 addresses each time it connects. 532 However, with increasing use of broadband connectivity, such as DSL 533 or cable, it is becoming more likely that the host will maintain the 534 same IPv4 over time. Should a host move around in today's Internet, 535 for instance, by visiting WiFi hotspots, it will be configured with a 536 different IPv4 address at each location. 538 We may also observe that a common practice in IPv4 today is to use 539 some form of address translation, whether the site is multihomed or 540 not. This effectively hides the identity of the specific host within 541 a site; only the site can be identified based on the IP address. 543 In the cases where it is desirable to maintain connectivity as a host 544 moves around, whether using layer 2 technology or Mobile IPv4, the 545 IPv4 address will remain constant during the movement (otherwise the 546 connections would break). Thus there is somewhat of a choice today 547 between seamless connectivity during movement and increased address 548 privacy. 550 Today when a site is multihomed to multiple ISPs the common setup is 551 that a single IP address prefix is used with all the ISPs. As a 552 result it is possible to track that it is the same host that is 553 communication via all ISPs. 555 However, when a *host* is multi-homed to several ISP, e.g. through a 556 GPRS connection and a wireless hot spot, the host is provided with 557 different IP addresses on each interface. While the focus of the 558 multihoming work is on site multihoming, should the solution also be 559 applicable to host multihoming, the privacy impact needs to be 560 considered for this case as well. 562 IPv6 stateless address auto-configuration facilitates IP address 563 management, but raises some concerns since the Ethernet address is 564 encoded in the low-order 64 bits of the IPv6 address. This could 565 potentially be used to track a host as it moves around the network, 566 using different ISPs etc. IPv6 specifies temporary addresses 567 [RFC3041] which allow applications to control whether they need 568 long-lived IPv6 addresses or desire the improved privacy of using 569 temporary addresses. 571 Given that there isn't address privacy in site multihoming setups 572 today, the primary concerns for the "do no harm" criteria are to 573 ensure that hosts that move around still have the same ability as in 574 today's Internet to choose between seamless connectivity and improved 575 address privacy, and also that the introduction of multihoming 576 support should still provide the same ability as we have in IPv6 with 577 temporary addresses. 579 When considering privacy threats it makes sense to distinguish 580 between attacks make by on-path entities observing the packets flying 581 by, and attacks by the communicating peer. While it is probably 582 feasible to prevent on-path entities from correlating the multiple IP 583 addresses of the host, the fact that the peer needs to be told 584 multiple IP addresses in order to be able to switch to using 585 different addresses when communication fails limits the ability of 586 the host to prevent correlating its multiple addresses. However, 587 using multiple pseudonyms for a host should be able address this 588 case. 590 4. POTENTIAL NEW ATTACKS 592 This section documents the additional attacks that have been 593 discovered that result from an architecture where hosts can change 594 their topological connection to the network in the middle of a 595 transport session without interruption. This discussion is again 596 framed in the context where the topological locators may be 597 independent of the host identifiers used by the transport and 598 application layer protocols. Some of these attacks may not be 599 applicable if traditional addresses are used. This section assumes 600 that each host has multiple locators and that there is some mechanism 601 for determining the locators for a correspondent host. We do not 602 assume anything about the properties of these mechanisms. Instead, 603 this list will serve to help us derive the properties of these 604 mechanisms that will be necessary to prevent these redirection 605 attacks. 607 Depending on the purpose of the redirection attack we separate the 608 attacks into several different types. 610 4.1. Cause Packets to be Sent to the Attacker 612 An attacker might want to receive the flow of packets, for instance 613 to be able to inspect and/or modify the payload or to be able to 614 apply cryptographic analysis to cryptographically protected payload, 615 using redirection attacks. 617 Note that such attacks are always possible today for an attacker 618 which is on the path between the two communicating parties, and a 619 multihoming solution can't possibly remove that threat. Hence the 620 bulk of these concerns relate to off-path attackers. 622 4.1.1. Once Packets are Flowing 624 This might be viewed as the "classic" redirection attack. 626 While A and B are communicating X might send packets to B and claim: 627 "Hi, I'm A, send my packets to my new location." where the location 628 is really X's location. 630 "Standard" solutions to this include requiring the host requesting 631 redirection somehow be verified to be the same host as the initial 632 host to establish communication. However, the burdens of such 633 verification must not be onerous, or the redirection requests 634 themselves can be used as a DoS attack. 636 To prevent this type of attack, a solution would need some mechanism 637 that B can use to verify whether a locator belongs to A before B 638 starts using that locator, and be able to do this when multiple 639 locators are assigned to A. 641 4.1.2. Time-shifting Attack 643 The term "time-shifting attack" is used to describe an attackers 644 ability to perform an attack after no longer being on the path. Thus 645 the attacker would have been on the path at some point in time, 646 snooping and/or modifying packets, and later when the attacker is no 647 longer on the path, it launches the attack. 649 In the current Internet, it is not possible to perform such attacks 650 to redirect packets. But for sometime after moving away the attacker 651 can cause a DoS attack e.g. by leaving a bogus ARP entry in the nodes 652 on the path or by forging TCP Reset packets based on having seen the 653 TCP Initial Sequence Numbers when it was on the path. 655 It would be reasonable to require that a multihoming solution limit 656 the ability to redirect and/or DoS traffic to a few minutes after the 657 attacker has moved off the path. 659 4.1.3. Premeditated Redirection 661 This is a variant of the above where the attacker "installs" itself 662 before communication starts. 664 For example, if the attacker X can predict that A and B will 665 communicate in the (near) future, then the attacker can tell B: "Hi, 666 I'm A and I'm at this location". When A later tries to communicate 667 with B, will B believe it is really A? 669 If the solution to the classic redirection attack is based on "prove 670 you are the same as initially", then A will fail to prove this to B 671 since X initiated communication. 673 Depending on details that would be specific to a proposed solution, 674 this type of attack could either cause redirection (so that the 675 packets intended for A will be sent to X) or they could cause DoS 676 (where A would fail to communicate with B since it can't prove it is 677 the same host as X). 679 To prevent this attack, the verification whether a locator belongs to 680 the peer can not simply be based on the first peer that made contact. 682 4.1.4. Using Replay Attacks 684 While the multihoming problem doesn't inherently imply any 685 topological movement it is useful to also consider the impact of site 686 renumbering in combination with multihoming. In that case the set of 687 locators for a host will change each time its site renumbers and at 688 some point in time after a renumbering event the old locator prefix 689 might be reassigned to some other site. 691 This potentially opens up the ability for an attacker to replay 692 whatever protocol mechanism was used to inform a host of a peer's 693 locators so that the host would incorrectly be lead to believe that 694 the old locator (set) should be used even long after a renumbering 695 event. This is similar to the risk of replay of Binding Updates in 696 [MIPv6] but the time constant is quite different; Mobile IPv6 might 697 see movements every second while site renumbering followed by 698 reassignment of the site locator prefix might be a matter of weeks or 699 months. 701 To prevent such replay attacks the protocol which is used to verify 702 which locators can be used with a particular identifier needs some 703 replay protection mechanism. 705 Also, in this space one needs to be concerned about potential 706 interaction between such replay protection and the administrative act 707 of reassignment of a locator. If the identifier and locator 708 relationship is distributed across the network one would need to make 709 sure that the old information has been completely purged from the 710 network before any reassignment. Note that this does not require an 711 explicit mechanism. This can instead be implemented by locator reuse 712 policy and careful timeouts of locator information. 714 4.2. Cause Packets to be Sent to a Black Hole 716 This is also a variant of the classic redirection attack. The 717 difference is that the new location is a locator that is nonexistent 718 or unreachable. Thus the effect is that sending packets to the new 719 locator causes the packets to be dropped by the network somewhere. 721 One would expect that solutions which prevent the previous 722 redirection attacks would prevent this attack as a side effect, but 723 it makes sense to include this attack here for completeness. 724 Mechanisms that prevented a redirection attack to the attacker should 725 also prevent redirection to a black hole. 727 4.3. Third Party Denial-of-Service Attacks 729 An attacker can use the ability to perform redirection to cause 730 overload on an unrelated third party. For instance, if A and B are 731 communicating then the attacker X might be able to convince A to send 732 the packets intended for B to some third node C. While this might 733 seem harmless at first, since X could just flood C with packets 734 directly, there are a few aspects of these attacks that cause 735 concern. 737 Such an attack might be against the resources of a particular host 738 i.e., C in the example above, or it might be against the network 739 infrastructure towards a particular IP address prefix, by overloading 740 the routers or links even though there is no host at the address 741 being targeted. 743 The first is that the attacker might be able to completely hide its 744 identity and location. It might suffice for X to send and receive a 745 few packets to A in order to perform the redirection, and A might not 746 retain any state on who asked for the redirection to C's location. 747 Even if A had retained such state, that state would probably not be 748 easily available to C, thus C can't determine who was the attacker 749 once C is being DoS'ed. 751 The second concern is that with a direct DoS attack from X to C, the 752 attacker is limited by the bandwidth of its own path towards C. If 753 the attacker can fool another host like A to redirect its traffic to 754 C then the bandwidth is limited by the path from A towards C. If A 755 is a high-capacity Internet service and X has slow (e.g., dialup) 756 connectivity this difference could be substantial. Thus in effect 757 this could be similar to packet amplifying reflectors in [PAXSON01]. 759 The third, and final concern, is that if an attacker only need a few 760 packets to convince one host to flood a third party, then it wouldn't 761 be hard for the attacker to convince lots of hosts to flood the same 762 third party. Thus this could be used for Distributed 763 Denial-of-Service attacks. 765 In today's Internet the ability to perform this type of attack is 766 quite limited. In order for the attacker to initiate communication 767 it will in most cases need to be able to receive some packets from 768 the peer (the potential exception being combining this with TCP 769 sequence number guessing type of techniques). Furthermore, to the 770 extent that parts of the Internet uses ingress filtering [INGRESS], 771 even if the communication could be initiated it wouldn't be possible 772 to sustain it by sending ACK packets with spoofed source addresses 773 from an off-path attacker. 775 If this type of attack can't be prevented there might be mitigation 776 techniques that can be employed. For instance, in the case of TCP it 777 would help if TCP slow-start was triggered when the destination 778 locator changes. (Folks might argue that, separately from security, 779 this would be the correct action for congestion control since TCP 780 might not have any congestion-relation information about the new path 781 implied by the new locator). Applying this technique to other 782 transport protocols which perform different forms of (TCP friendly) 783 congestion control might be more difficult since the lower layers 784 generally lack an API to provide such information to the transports. 785 Also, for other protocols, this might be less beneficial, since other 786 transports might not adapt rapidly and could view the suggestion of 787 congestion as being more severe than a simple deficit of congestion 788 information. 790 4.3.1. Basic Third Party DoS 792 Assume that X is on a slow link anywhere in the Internet. B is on a 793 fast link (gigabits; e.g., a media server) and A is the victim. 795 X could flood A directly but is limited by its low bandwidth. If X 796 can establish communication with B, ask B to send it a high-speed 797 media stream, then X can presumably fake out the 798 "acknowledgments/feedback" needed for B to blast out packets at full 799 speed. So far this only hurts X - and the path between X and the 800 Internet. But if X could also tell B "I'm at A's locator" then X has 801 effectively used this redirection capability in multihoming to 802 amplify its DoS capability, which would be a source of concern. 804 One could envision rather simple techniques to prevent such attacks. 805 For instance, before sending to a new peer locator perform a clear 806 text exchange with the claimed new locator of the form "Are you X?" 807 resulting in "Yes, I'm X.". This would suffice for the simplest of 808 attacks. However, as we will see below, more sophisticated attacks 809 are possible. 811 4.3.2. Third Party DoS with On-Path Help 813 The scenario is as above but in addition the attacker X has a friend 814 Y on the path between A and B: 816 ----- ----- ----- 817 | A |--------| Y |--------| B | 818 ----- ----- ----- 819 / 820 / 821 / 822 / 823 / 824 / 825 ----- 826 | X | 827 ----- 829 With the simple solution suggested in the previous section, all Y 830 might need to do is to fake a response to the "Are you X?" packet, 831 and after that point in time Y might not be needed; X could 832 potentially sustain the data flow towards A by generating the ACK 833 packets. Thus it would be even harder to detect the existence of Y. 835 Furthermore, if X is not the actual end system but an attacker 836 between some node C and B, then X can claim to be C, and no finger 837 can be pointed at X either: 839 ----- ----- ----- 840 | A |--------| Y |--------| B | 841 ----- ----- ----- 842 / 843 / 844 / 845 / 846 / 847 / 848 ----- ----- 849 | C |-------| X | 850 ----- ----- 852 Thus with two attackers on different paths, there might be no trace 853 of who did the redirection to the 3rd party once the redirection has 854 taken place. 856 A specific case of this is when X=Y, and X is located on the same LAN 857 as B. 859 A potential way to make such attacks harder would be to use the last 860 received (and verified) source locator as the destination locator. 861 That way when X sends the ACK packets (whether it claims to be X or 862 C) the result would be that the packet flow from B would switch back 863 towards X/C, which would result in an attack similar to what can be 864 performed in today's Internet. 866 Another way to make such attacks harder would be to perform periodic 867 verifications that the peer is available at the locator, instead of 868 just one when the new locator is received. 870 A third way that a multihoming solution might address this is to 871 ensure that B will only accept locators that can be authenticated to 872 be synonymous with the original correspondent. It must be possible 873 to securely ensure that these locators form an equivalence class. So 874 in the first example, not only does X need to assert that it is A, 875 but A needs to assert that it is X. 877 4.4. Accepting Packets from Unknown Locators 879 The multihoming solution space does not only affect the destination 880 of packets; it also raises the question from which sources packets 881 should be accepted. It is possible to build a multihoming solution 882 that allows traffic to be recognized as coming from the same peer 883 even if there is a previously unknown locator present in the source 884 address field. The question is whether we want to allow packets from 885 unverified sources to be passed on to transport and application layer 886 protocols. 888 In the current Internet, an attacker can't inject packets with 889 arbitrary source addresses into a session if there is ingress 890 filtering present, so allowing packets with unverified sources in a 891 multihoming solution would fail our "no worse than what we have now" 892 litmus test. However, given that ingress filtering deployment is far 893 from universal and ingress filtering typically wouldn't prevent 894 spoofing of addresses in the same subnet, requiring rejecting packets 895 from unverified locators might be too stringent. 897 An example of the current state are the ability to inject RST packets 898 into existing TCP connections. When there is no ingress filtering in 899 the network, this is something that the TCP endpoints need to sort 900 out themselves. However, deploying ingress filtering helps in 901 today's Internet since an attacker is limited in the set of source 902 address it can use. 904 A factor to take into account to determine the "requirement level" 905 for this is that when IPsec is used on top of the multihoming 906 solution, then IPsec will reject such spoofed packets. (Note that 907 this is different than in the redirection attack cases where even 908 with IPsec an attacker could potentially cause a DoS attack.) 910 There might also be a middle ground where arbitrary attackers are 911 prevented from injecting packets by using the SCTP verification tag 912 type of approach [SCTP]. (This is a clear-text tag which is sent to 913 the peer which the peer is expected to include in each subsequent 914 packet.) Such an approach doesn't prevent packet injection from 915 on-path attackers (since they can observe the verification tag), but 916 neither does ingress filtering. 918 4.5. New Privacy Considerations 920 While introducing identifiers can be helpful by providing ways to 921 identify hosts across events when its IP address(es) might change, 922 there is a risk that such mechanisms can be abused to track the 923 identity of the host over long periods of time, whether using the 924 same (set of) ISP(s) or moving between different network attachment 925 points. Designers of solutions to multihoming need to be aware of 926 this concern. 928 Introducing the multihoming capability inherently implies that the 929 communicating peers need to know multiple locators for each other in 930 order to be resilient to failures of some paths/locators. In 931 addition, if the multihoming signaling protocol doesn't provide 932 privacy it might be possible for 3rd parties on the path to discover 933 many or all the locators assigned to a host, which would increase the 934 privacy exposure compared to a multihomed host today. 936 A solution could address this for instance by allowing each host to 937 have multiple identifiers at the same time and perhaps even changing 938 the set of identifiers that are used over time. Such an approach 939 could be analogous to what is done for IPv6 addresses in [RFC3041]. 941 5. GRANULARITY OF REDIRECTION 943 Different multihoming solutions might approach the problem at 944 different layers in the protocol stack. For instance, there have 945 been proposals for a shim layer inside IP as well as transport layer 946 approaches. The former would have the capability to redirect an IP 947 address while the latter might be constrained to only redirect a 948 single transport connection. This difference might be important when 949 it comes to understanding the security impact. 951 For instance, premeditated attacks might have quite different impact 952 in the two cases. In an IP-based multihoming solution a successful 953 premeditated redirection could be due to the attacker connecting to a 954 server and claiming to be 'A' which would result in the server 955 retaining some state about 'A' which it received from the attacker. 956 Later, when the real 'A' tries to connect to the server, the 957 existence of this state might mean that 'A' fails to communicate, or 958 that its packets are sent to the attacker. But if the same scenario 959 is applied to a transport-layer approach then the state created due 960 to the attacker would perhaps be limited to the existing transport 961 connection. Thus while this might prevent the real 'A' from 962 connecting to the server while the attacker is connected (if they 963 happen to use the same transport port number) most likely it would 964 not affect 'A's ability to connect after the attacker has 965 disconnected. 967 A particular aspect of the granularity question is the direction 968 question; will the created state be used for communication in the 969 reverse direction from the direction when it was created? For 970 instance, if the attacker 'X' suspects that 'A' will connect to 'B' 971 in the near future, can X connect to A and claim to be B and have 972 that later make A connect to the attacker instead of to the real B? 974 Note that transport layer approaches are limited to the set of 975 "transport" protocols that the implementation makes aware of 976 multihoming. In many cases there would be "transport" protocols that 977 are unknown to the multihoming capability of the system, such as 978 applications built on top of UDP. To understand the impact of the 979 granularity question on the security, one would also need to 980 understand how such applications/protocols would be handled. 982 A property of transport granularity is that the amount of work 983 performed by a legitimate host is proportional to the number of 984 transport connections it creates that uses the multihoming support, 985 since each such connection would require some multihoming signaling. 986 And the same is true for the attacker. This means that an attacker 987 could presumably do a premeditated attack for all TCP connections to 988 port 80 from A to B, by setting up 65,536 (for all TCP source port 989 numbers) to the server B and causing B to think those connections 990 should be directed to the attacker and keeping those TCP connections 991 open. Any attempt to make legitimate communication more efficient, 992 e.g., by being able to signal for multiple transport connections at a 993 time, would provide as much relative benefit for an attacker as the 994 legitimate hosts. 996 Discussion: Perhaps the key issue is not about the granularity, 997 but about the lifetime of the state that is created? In a 998 transport-layer approach the multihoming state would presumably be 999 destroyed when the transport state is deleted as part of closing 1000 the connection. But an IP-layer approach would have to rely on 1001 some timeout or garbage collection mechanisms perhaps combined 1002 with some new explicit signaling to remove the multihoming state. 1003 The coupling between the connection state and multihoming state in 1004 the transport-layer approach might make it more expensive for the 1005 attacker, since it needs to keep the connections open. Is this 1006 the case? 1008 In summary, there are issues we don't yet understand well about 1009 granularity and reuse of the multihoming state. 1011 6. MOVEMENT IMPLICATIONS? 1013 In the case when nothing moves around we have a reasonable 1014 understanding of the security requirements. Something that is on the 1015 path can be a MiTM in today's Internet and a multihoming solution 1016 doesn't need to make that aspect any more secure. 1018 But it is more difficult to understand the requirements when hosts 1019 are moving around. For instance, a host might be on the path for a 1020 short moment in time by driving by an 802.11 hotspot. Would we or 1021 would we not be concerned if such a drive-by (which many call a 1022 "time-shifting" attack) would result in the temporarily on-path host 1023 being able to act as a MiTM for future communication? Depending on 1024 the solution this might be possible by the attacker causing 1025 multihoming state to be created in various peer hosts while the 1026 attacker was on the path, and that state remaining in the peers for 1027 some time. 1029 The answer to this question doesn't seem to be obvious even in the 1030 absence of any new multihoming support. We don't have much 1031 experience with hosts moving around that are able to attack things as 1032 they move. In Mobile IPv6 [MIPv6] a conservative approach was taken 1033 which limits the effect of such drive-by attacks to the maximum 1034 lifetime of the binding, which is set to a few minutes. 1036 With multihoming support the issue gets a bit more complicated 1037 because we explicitly want to allow a host to be present at multiple 1038 locators at the same time, thus there might be a need to distinguish 1039 between the host moving between different locators, and the host 1040 sending packets with different source locators because it is present 1041 at multiple locators without any topological movement. 1043 Note that the multihoming solutions that have been discussed range 1044 from such drive-by's being impossible (for instance, due to a strong 1045 binding to a separate identifier as in HIP, or due to reliance on the 1046 relative security of the DNS for forward plus reverse lookups in 1047 NOID), to systems that are first-come/first-serve (WIMP being an 1048 example with a separate ID space, a MAST approach with a PBK being an 1049 example without a separate ID space) that allow the first host which 1050 is using an ID/address to claim that without any time limit. 1052 7. OTHER SECURITY CONCERNS 1054 The protocol mechanisms added as part of a multihoming solution 1055 shouldn't introduce any new DoS in the mechanisms themselves. In 1056 particular, care must be taken not to: 1058 - create state on the first packet in an exchange, since that could 1059 result in state consumption attacks similar to the TCP SYN 1060 flooding attack. 1062 - perform much work on the first packet in an exchange (such as 1063 expensive verification) 1065 There is a potential chicken-and-egg problem here, because 1066 potentially one would want to avoid doing work or creating state 1067 until the peer has been verified, but verification will probably need 1068 some state and some work to be done. 1070 A possible approach that solutions might investigate is to defer 1071 verification until there appears to be two different hosts (or two 1072 different locators for the same host) that want to use the same 1073 identifier. In such a case one would need to investigate whether 1074 combination of impersonation and DoS attack can be used to prevent 1075 the discovery of the impersonation. 1077 Another possible approach is to first establish communications, and 1078 then perform verification in parallel with normal data transfers. 1079 Redirection would only be permitted after verification was complete, 1080 but prior to that event, data could transfer in a normal, 1081 non-multihomed manner. 1083 Finally, the new protocol mechanisms should be protected against 1084 spoofed packets, at least from off-path sources, and replayed 1085 packets. 1087 8. SECURITY CONSIDERATIONS 1089 In section 3 we discussed existing protocol-based redirection 1090 attacks. But there are also non-protocol redirection attacks. An 1091 attacker which can gain physical access to one of 1093 - The copper/fiber somewhere in the path. 1095 - A router or L2 device in the path. 1097 - One of the end systems 1099 can also redirect packets. This could be possible for instance by 1100 physical break-ins or by bribing staff that have access to the 1101 physical infrastructure. Such attacks are out of scope for this 1102 discussion, but are worth to keep in mind when looking at the cost 1103 for an attacker to exploit any protocol-based attacks against 1104 multihoming solutions; making protocol-based attacks much more 1105 expensive to launch than break-ins/bribery type of attacks might be 1106 overkill. 1108 9. IANA CONSIDERATIONS 1110 This document has no IANA considerations. 1112 10. ACKNOWLEDGMENTS 1114 This document was originally produced of a MULTI6 design team 1115 consisting of (in alphabetical order): Iljitsch van Beijnum, Steve 1116 Bellovin, Brian Carpenter, Mike O'Dell, Sean Doran, Dave Katz, Tony 1117 Li, Erik Nordmark, and Pekka Savola. 1119 Much of the awareness of these threats come from the work on Mobile 1120 IPv6 [MIPv6, NIKANDER03, AURA02]. 1122 As the document has evolved the MULTI6 WG participants have 1123 contributed to the document. In particular: Masataka Ohta brought 1124 up privacy concern related to stable identifiers. The suggestion to 1125 discuss transport versus IP granularity was contributed by Marcelo 1126 Bagnulo, who also contributed text to Appendix B. 1128 11. REFERENCES 1130 11.1. Normative References 1131 11.2. Informative References 1133 [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the 1134 NSRG", draft-irtf-nsrg-report-10.txt (work in progress), 1135 September 2003. 1137 [MIPv6] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support in 1138 IPv6", RFC 3775, June 2004. 1140 [AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", 1141 draft-aura-mipv6-bu-attacks-01 (work in progress), March 1142 2002. 1144 [NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E. 1145 Nordmark, "Mobile IP version 6 Route Optimization Security 1146 Design Background", draft-nikander-mobileip-v6-ro-sec-02 1147 (work in progress), December 2003. 1149 [PAXSON01] V. Paxson, "An Analysis of Using Reflectors for 1150 Distributed Denial-of-Service Attacks", Computer 1151 Communication Review 31(3), July 2001. 1153 [INGRESS] Ferguson P., and D. Senie, "Network Ingress Filtering: 1154 Defeating Denial of Service Attacks which employ IP Source 1155 Address Spoofing", RFC 2827, May 2000. 1157 [SCTP] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. 1158 Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and 1159 V. Paxson, "Stream Control Transmission Protocol", RFC 1160 2960, October 2000. 1162 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 1163 Addressing Architecture", RFC 3513, April 2003. 1165 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 1166 6 (IPv6) Specification", RFC 2461. 1168 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 1169 Protocol". RFC 2401, November 1998. 1171 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, 1172 November 1998. 1174 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 1175 RFC 2406, November 1998. 1177 [RFC3041] T. Narten and Draves, R, "Privacy Extensions for 1178 Stateless Address Autoconfiguration in IPv6", January 2001. 1180 [DNS-THREATS] Derek Atkins, Rob Austein, "Threat Analysis Of The 1181 Domain Name System", RFC 3833, August 2004. 1183 [FYI18] G. Malkin, Ed., "Internet Users' Glossary", August 1996, 1184 Also RFC RFC1983. 1186 [ECN] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of 1187 Explicit Congestion Notification (ECN) to IP", RFC 3168, 1188 September 2001. 1190 [OWNER] Nikander, P., "Denial-of-Service, Address Ownership, and 1191 Early Authentication in the IPv6 World", Security Protocols 1192 9th International Workshop, Cambridge, UK, April 25-27 1193 2001, LNCS 2467, pages 12-26, Springer, 2002. 1195 [RFC1948] Bellovin, S., "Defending Against Sequence Number 1196 Attacks", RFC 1948, May 1996. 1198 [PBK] Scott Bradner, Allison Mankin, Jeffrey Schiller, "A Framework 1199 for Purpose-Built Keys (PBK)", 9-Jun-03, 1202 [NOID] Erik Nordmark, "Multihoming without IP Identifiers", July 1203 2004, 1205 [MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST): 1206 AN EXTENDED PROPOSAL", September 2003, 1209 [HIP] Pekka Nikander, "Considerations on HIP based IPv6 multi- 1210 homing", July 2004, 1212 [WIMP] Jukka Ylitalo, "Weak Identifier Multihoming Protocol 1213 (WIMP)", June 2004, 1215 [CBHI] Iljitsch van Beijnum, "Crypto Based Host Identifiers", 2- 1216 Feb-04, 1218 AUTHORS' ADDRESSES 1220 Erik Nordmark 1221 Sun Microsystems, Inc. 1222 17 Network Circle 1223 Mountain View, CA 1224 USA 1226 phone: +1 650 786 2921 1227 fax: +1 650 786 5896 1228 email: erik.nordmark@sun.com 1230 Tony Li 1231 email: Tony.Li@tony.li 1233 APPENDIX A: CHANGES SINCE PREVIOUS DRAFT 1235 [RFC-editor: please remove this section before publication as an RFC] 1237 The following changes have been made since draft-ietf-multi6- 1238 threats-01: 1240 o Fixed some idnits complaints. 1242 o Fixed potentially confusing "interfaces" vs. "identifiers" in the 1243 definition for "identifier". 1245 o In section 4.1, bluntly pointing out the man-in-the- middle 1246 potential in all of the redirection attacks. 1248 o Added text that the document is necessarily incomplete since it 1249 doesn't analyze a particular solution and that additional work 1250 will be needed when a solution is specified. 1252 o Clarified the uniqueness assumptions in the "address" definition. 1254 o In section 3.1 clarified the "binding" when mutual authentication 1255 is used. 1257 o Renamed "class of applications" to be "class of security 1258 configurations for applications". 1260 o Clarified in section 7 that deferred verification might be 1261 combined with DoS attacks to make it hard to detect the 1262 impersonation. 1264 o Added an empty IANA Considerations section 1266 o Added note for RFC-editor to remove Appendix A. 1268 o Added clarification that "leap of faith" trust arrangements is 1269 part of the 5th category. 1271 The following changes have been made since draft-ietf-multi6- 1272 threats-00: 1274 o Added more information to section 3.1 based on comments on the 1275 mailing list. 1277 o Made stronger statements about privacy from the WG discussion on 1278 San Diego. 1280 o Added text about time-shifting attacks i.e. where an attacker was 1281 on-path and later moves off the path. 1283 The following changes have been made since draft-nordmark-multi6- 1284 threats-02: 1286 o Editorial clarifications based on WG comments. 1288 o Removed the ULP term and it's usage since it was potentially 1289 confusing. 1291 o Added a current state of privacy as the basis for "do no harm" 1293 o Added some background information about authentication, 1294 authorization, and identifier ownership. 1296 o Improvements to Appendix B 1298 The following changes have been made since draft-nordmark-multi6- 1299 threats-01: 1301 o Editorial clarifications based on comments from Brian. 1303 The following changes have been made since draft-nordmark-multi6- 1304 threats-00: 1306 o Added reference to [DNS-THREATS] and clarified that attackers on 1307 the path between the host and the DNS servers can redirect traffic 1308 today. 1310 o Added a section on existing packet injection attacks to talk about 1311 TCP sequence number guessing etc. 1313 o Clarified ingress filtering relationship in section on today's 1314 flooding attacks. 1316 o Added a new section on granularity to list some issues about 1317 transport-level versus IP-level approaches and what we understand 1318 about the differences in security. This is still very much a work 1319 in progress. 1321 o Added a new section on movement to discuss how things change when 1322 hosts move around the network. This is still very much a work in 1323 progress. 1325 o Added Appendix B - but this should probably be moved to a 1326 different document to keep this document focused on the threats. 1328 APPENDIX B: SOME SECURITY ANALYSIS 1330 When looking at the proposals that have been made for multihoming 1331 solutions and the above threats it seems like there are two separable 1332 aspects of handling the redirection threats: 1334 - Redirection of existing communication 1336 - Redirection of an identity before any communication 1338 This seems to be related to the fact that there are two different 1339 classes of use of identifiers. One use is for: 1341 o Initially establishing communication; looking up a FQDN to find 1342 something which is passed to a connect() or sendto() API call. 1344 o Comparing whether a peer entity is the same peer entity as in some 1345 previous communication. 1347 o Using the identity of the peer for future communication 1348 ("callbacks") in the reverse direction, or to refer to a 3rd party 1349 ("referrals"). 1351 The other use of identifiers is as part of being able to redirect 1352 existing communication to use a different locator. 1354 The first class of use seems to be related to something about the 1355 ownership of the identifier; proving the "ownership" of the 1356 identifier should be sufficient in order to be authorized to control 1357 which locators are used to reach the identifier. 1359 The second class of use seems to be related to something more 1360 ephemeral. It seems to be sufficient to be able to prove that the 1361 entity is the same as the one that initiated the communication to be 1362 able to redirect the existing communication to some other locator. 1363 One can view this as proving the ownership of some context, where the 1364 context is established around the time when the communication is 1365 initiated. 1367 Preventing unauthorized redirection of existing communication can be 1368 addressed by a large number of approaches which are based on setting 1369 up some form of security material at the beginning of communication, 1370 and later using the existence of that material for one end to prove 1371 to the other that it remains the same. An example of this is Purpose 1372 Built Keys [PBK]. One can envision different approaches for such 1373 schemes with different complexity, performance, and resulting 1374 security such as anonymous 1375 Diffie-Hellman exchange, the reverse hash chains presented in [WIMP], 1376 or even a clear-text token exchanged at the initial communication. 1378 However, the mechanisms for preventing unauthorized use of an 1379 identifier can be quite different. One way to prevent premeditated 1380 redirection is to simply not introduce a new identifier name space 1381 but instead rely on existing name space(s), a trusted third party, 1382 and a sufficiently secure way to access the third party, as in 1383 [NOID]. Such an approach relies on the third party (DNS in the case 1384 of NOID) as the foundation. In terms of multihoming state creation, 1385 in this case premeditated redirection is as easy or as hard as 1386 redirecting an IP address today. Essentially this relies on the 1387 return-routability check associated with a roundtrip of communication 1388 which verifies that the routing system delivers packets to the IP 1389 address in question. 1391 Alternatively, one can use the crypto-based identifiers such as in 1392 [HIP] or crypto-generated addresses as in [CBHI], which both rely on 1393 public-key crypto, to prevent premeditated attacks. In some cases it 1394 is also possible to avoid the problem by having (one end of the 1395 communication) use ephemeral identifiers as the initiator does in 1396 [WIMP]. This avoids premeditated redirection by detecting that some 1397 other entity is using the same identifier at the peer and switching 1398 to use another ephemeral ID. While the ephemeral identifiers might 1399 be problematic when used by applications, for instance due to 1400 callbacks or referrals, it is an interesting observation that for the 1401 end that has the ephemeral identifier, one can skirt around the 1402 premeditated attacks (assuming the solution has a robust way to pick 1403 a new identifier when one is in use/stolen). 1405 Assuming the problem can't be skirted around by using ephemeral 1406 identifiers there seem to be 3 types of approaches which can be used 1407 to establish some form of identity ownership: 1409 - A trusted third party, which states that a given identity is 1410 reachable at a given set of locators, so the endpoint reached at 1411 one of this locators is the owner of the identity. 1413 - Crypto-based identifiers or crypto-generated addresses where the 1414 public/private key pair can be used to prove that the identifier 1415 was generated by the node knowing the private key (or by another 1416 node whose public key hashes to the same value) 1418 - A static binding, as currently defined in IP, where you trust that 1419 the routing system will deliver the packets to the owner of the 1420 locator, and since the locator and the identity are one, you prove 1421 identity ownership as a sub-product. 1423 A solution would need to combine elements which provide protection 1424 against both premeditated and 1425 on-going communication redirection. This can be done in several 1426 ways, and the current set of proposals do not appear to contain all 1427 useful combinations. For instance, the HIP CBID property could be 1428 used to prevent premeditated attacks while the WIMP hash chains could 1429 be used to prevent on-going redirection. And there are probably 1430 other interesting combinations. 1432 A related, but perhaps separate aspect, is whether the solution 1433 provides for protection against Man-in-The-Middle attacks with on- 1434 path attackers. Some schemes, such as [HIP] and [NOID] do, but given 1435 that an on-path attacker can see and modify the data traffic whether 1436 or not it can modify the multihoming signaling, this level of 1437 protection seems like overkill. Protecting against on-path MiTM for 1438 the data traffic can be done separately using IPsec, TLS, etc. 1440 Finally, preventing third party DoS attacks is conceptually simpler; 1441 it would suffice to somehow verify that the peer is indeed reachable 1442 at the new locator before sending a large number of packets to that 1443 locator. 1445 Just as the redirection attacks are conceptually prevented by proving 1446 at some level the ownership of the identifier or the ownership of the 1447 communication context, third party DoS attacks are conceptually 1448 prevented by showing that the endpoint is authorized to use a given 1449 locator. 1451 The currently known approaches for showing such authorization are: 1453 - Return routability, that is, if an endpoint is capable of 1454 receiving packets at a given locator, it is because he is 1455 authorized to do so. This relies to routing being reasonably hard 1456 to subvert to deliver packets to the wrong place. While this 1457 might be the case when routing protocols are used with reasonable 1458 security mechanisms and practices, it isn't the case on a single 1459 link where ARP and Neighbor Discovery can be easily spoofed. 1461 - Third trusted party. A third party establishes that a given 1462 identity is authorized to use a given set of locators (for 1463 instance the DNS) 1465 Intellectual Property Statement 1467 The IETF takes no position regarding the validity or scope of any 1468 Intellectual Property Rights or other rights that might be claimed to 1469 pertain to the implementation or use of the technology described in 1470 this document or the extent to which any license under such rights 1471 might or might not be available; nor does it represent that it has 1472 made any independent effort to identify any such rights. Information 1473 on the procedures with respect to rights in RFC documents can be 1474 found in BCP 78 and BCP 79. 1476 Copies of IPR disclosures made to the IETF Secretariat and any 1477 assurances of licenses to be made available, or the result of an 1478 attempt made to obtain a general license or permission for the use of 1479 such proprietary rights by implementers or users of this 1480 specification can be obtained from the IETF on-line IPR repository at 1481 http://www.ietf.org/ipr. 1483 The IETF invites any interested party to bring to its attention any 1484 copyrights, patents or patent applications, or other proprietary 1485 rights that may cover technology that may be required to implement 1486 this standard. Please address the information to the IETF at 1487 ietf-ipr@ietf.org. 1489 Disclaimer of Validity 1491 This document and the information contained herein are provided on an 1492 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1493 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1494 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1495 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1496 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1497 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1499 Copyright Statement 1501 Copyright (C) The Internet Society (2004). This document is subject 1502 to the rights, licenses and restrictions contained in BCP 78, and 1503 except as set forth therein, the authors retain all their rights. 1505 Acknowledgment 1507 Funding for the RFC Editor function is currently provided by the 1508 Internet Society.