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