idnits 2.17.1 draft-ietf-multi6-multihoming-threats-03.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 1536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1526. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1542), 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) -- 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 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark 3 Jan 7, 2005 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 18 Internet-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 July 7, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). 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 all IPv6 multihoming solutions. The threats in this 47 document build upon the threats discovered and discussed as part of 48 the Mobile IPv6 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.............................. 11 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.......................... 18 74 4.3.2. Third Party DoS with On-Path Help.............. 18 75 4.4. Accepting Packets from Unknown Locators............. 20 76 4.5. New Privacy Considerations.......................... 20 78 5. GRANULARITY OF REDIRECTION............................... 21 80 6. MOVEMENT IMPLICATIONS?................................... 23 82 7. OTHER SECURITY CONCERNS.................................. 24 84 8. SECURITY CONSIDERATIONS.................................. 25 86 9. IANA CONSIDERATIONS...................................... 25 88 10. ACKNOWLEDGMENTS......................................... 25 90 11. REFERENCES.............................................. 26 91 11.1. Normative References............................... 26 92 11.2. Informative References............................. 26 94 AUTHORS' ADDRESSES........................................... 28 96 APPENDIX A: CHANGES SINCE PREVIOUS DRAFT..................... 28 97 APPENDIX B: SOME SECURITY ANALYSIS........................... 31 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 as part of its own threat analysis, especially in the following 136 areas: 138 1) If the solution makes the split between locators and identifiers, 139 then most application security mechanisms should be tied to the 140 identifier, not to the locator. Therefore, work would be needed 141 to understand how attacks on the identifier mechanism affect 142 security, especially, attacks on the mechanism that would bind 143 locators to identifiers. 145 2) How does the solution apply multihoming to IP multicast. 146 Depending on how this is done there might be specific threats 147 relating to multicast that need to be understood. This document 148 does not discuss any multicast specific threats. 150 3) Connection-less transport protocols probably need more attention. 151 They are already difficult to secure, even without a 152 locator/identifier split. 154 1.1. Assumptions 156 This threat analysis doesn't assume that security has been applied 157 other security relevant parts of the Internet, such as DNS and 158 routing protocols, but it does assume that at some point in time at 159 least parts of the Internet will be operating with security for such 160 key infrastructure. With that assumption it then becomes important 161 that a multihoming solution would not, at that point in time, become 162 the weakest link. This is the case even if, for instance, insecure 163 DNS might be the weakest link today. 165 This document doesn't assume that the application protocols are 166 protected by strong security today or in the future. However, it is 167 still useful to assume that the application protocols which care 168 about integrity and/or confidentiality apply the relevant end-to-end 169 security measures, such as IPsec, TLS, and/or application layer 170 security. 172 For simplicity, the document assumes that an on-path attacker can see 173 packets, modify packets and send them out, and block packets from 174 being delivered. This is a simplification because there might exist 175 ways, for instance monitoring capability in switches, which allow 176 authenticated and authorized users to observe packets without being 177 able to send or block the packets. 179 In some cases it might make sense to make a distinction between 180 on-path attackers which can monitor packets and perhaps also inject 181 packets, without being able to block packets from passing through. 183 On-path attackers that only need to monitor might be lucky and find a 184 non-switched Ethernet in the path, or use capacitive or inductive 185 coupling to listen on a copper wire. But if the attacker is on an 186 Ethernet that is on the path, whether switched or not, the attacker 187 can also employ ARP/ND spoofing to get access to the packet flow 188 which allows blocking as well. Similarly, if the attacker has access 189 to the wire, the attacker can also place a device on the wire to 190 block. Other on-path attacks would be those that gain control of a 191 router or a switch (or gain control of one of the endpoints) and most 192 likely those would allow blocking as well. 194 So the strongest currently known case where monitoring is easier than 195 blocking, is when switches and routers have monitoring capabilities 196 (for network management or for lawful intercept) where an attacker 197 might be able to bypass the authentication and authorization checks 198 for those capabilities. However, this document makes the simplifying 199 assumption treat all on path attackers the same by assuming that such 200 an attacker can monitor, inject, and block packets. A security 201 analysis of a particular proposal can benefit from not making this 202 assumption, and look at how on-path attackers with different 203 capabilities can generate different attacks perhaps not present in 204 today's Internet. 206 The document assumes that an off-path attacker can neither see 207 packets between the peers (for which it is not on the path) nor block 208 them from being delivered. Off-path attackers can in general send 209 packets with arbitrary IP source addresses and content, but such 210 packets might be blocked if ingress filtering [INGRESS] is applied. 211 Thus it is important to look at the multihoming impact on security 212 both in the presence and absence of ingress filtering. 214 1.2. Authentication, Authorization, and Identifier Ownership 216 The overall problem domain can be described using different 217 terminology. 219 One way to describe it is that it is necessary to first authenticate 220 the peer and then verify that the peer is authorized to control the 221 locators used for a particular identifier. While this is correct, it 222 might place too much emphasis on the authorization aspect. In this 223 case the authorization is conceptually very simple; each host (each 224 identifier) is authorized to control which locators are used for 225 itself. 227 Hence there is a different way to describe the same thing. If the 228 peer can somehow prove that it is the owner of the identifier, and 229 the communication is bound to the identifier (and not the locator), 230 then the peer is allowed to control the locators that are used with 231 the identifier. This way to describe the problem is used in [OWNER]. 233 Both ways to look at the problem, hence both sets of terminology, are 234 useful when trying to understand the problem space and the threats. 236 2. TERMINOLOGY 238 link - a communication facility or medium over which nodes 239 can communicate at the link layer, i.e., the layer 240 immediately below IPv6. Examples are Ethernets 241 (simple or bridged); PPP links; X.25, Frame Relay, 242 or ATM networks; and Internet (or higher) layer 243 "tunnels", such as tunnels over IPv4 or IPv6 itself. 245 interface - a node's attachment to a link. 247 address - an IP layer name that has both topological 248 significance (i.e., a locator) and identifies an 249 interface. There may be multiple addresses per 250 interface. Normally an address uniquely identifies 251 an interface but there are cases when the same 252 unicast address is assigned to multiple interfaces 253 on the same node, as well as anycast address which 254 can be assigned to different interfaces on different 255 nodes. 257 locator - an IP layer topological name for an interface or a 258 set of interfaces. There may be multiple locators 259 per interface. 261 identifier - an IP layer identifier for an IP layer endpoint 262 (stack name in [NSRG]), that is, something that 263 might be commonly referred to as a "host". The 264 transport endpoint name is a function of the 265 transport protocol and would typically include the 266 IP identifier plus a port number. There might be 267 use for having multiple identifiers per stack/per 268 host. 270 An identifier continues to function regardless of 271 the state of any one interface. 273 address field 274 - the source and destination address fields in the 275 IPv6 header. As IPv6 is currently specified this 276 fields carry "addresses". If identifiers and 277 locators are separated these fields will contain 278 locators. 280 FQDN - Fully Qualified Domain Name [FYI18] 282 3. TODAY'S ASSUMPTIONS AND ATTACKS 284 The two interesting aspects of security for multihoming solutions are 285 the assumptions made by the transport layer and application layer 286 protocols about the identifiers that they see on one hand, and the 287 existing abilities to perform today various attacks related to the 288 identity/location relationship, on the other hand. 290 3.1. Application Assumptions 292 In the Internet today, the initiating part of applications either 293 starts with a FQDN, which it looks up in the DNS, or already has an 294 IP address from somewhere. For the FQDN to IP address lookup the 295 application effectively places trust in the DNS. Once it has the IP 296 address, the application places trust in the routing system 297 delivering packets to that address. Applications that use security 298 mechanisms, such as IPSEC or TLS, have the ability to bind an address 299 or FQDN to cryptographic keying material. Compromising the DNS 300 and/or routing system can result in packets being dropped or 301 delivered to an attacker in such cases, but since the attacker does 302 not possess the keying material the application will not trust the 303 attacker, and the attacker can not decrypt what it receives. 305 At the responding (non-initiating) end of communication today, we 306 find that the security configurations used by different applications 307 that fall into approximately five classes, where a single application 308 might use different classes of configurations for different types of 309 communication. 311 The first class is the set of public content servers. These systems 312 provide data to any and all systems and are not particularly 313 concerned with confidentiality, as they make their content available 314 to all. However, they are interested in data integrity and denial of 315 service attacks. Having someone manipulate the results of a search 316 engine, for example, or prevent certain systems from reaching a 317 search engine would be a serious security issue. 319 The second class of security configurations use existing IP source 320 addresses from outside of their immediate local site as a means of 321 authentication without any form of verification. Today, with source 322 IP address spoofing and TCP sequence number guessing as rampant 323 attacks [RFC1948], such applications are effectively opening 324 themselves for public connectivity and are reliant on other systems, 325 such as firewalls, for overall security. We do not consider this 326 class of configurations in this document because they are in any case 327 fully open to all forms of network layer spoofing. 329 The third class of security configurations receive existing IP source 330 addresses, but attempt some verification using the DNS, effectively 331 using the FQDN for access control. (This is typically done by 332 performing a reverse lookup from the IP address followed by a forward 333 lookup and verifying that the IP address matches one of the addresses 334 returned from the forward lookup.) These applications are already 335 subject to a number of attacks using techniques like source address 336 spoofing and TCP sequence number guessing since an attacker, knowing 337 this is the case, can simply create a DoS attack using a forged 338 source address that has authentic DNS records. In general this class 339 of security configurations is strongly discouraged, but it is 340 probably important that a multihoming solution doesn't introduce any 341 new and easier ways to perform such attacks. However, we note that 342 some people think we should treat this class the same as the second 343 class of security configurations. 345 The fourth class of security configurations use cryptographic 346 security techniques to provide both a strong identity for the peer 347 and data integrity with or without confidentiality. Such systems are 348 still potentially vulnerable to denial of service attacks that could 349 be introduced by a multihoming solution. 351 Finally, the fifth class of security configurations use cryptographic 352 security techniques but without strong identity (such as 353 opportunistic IPsec). Thus data integrity with or without 354 confidentiality is provided when communicating with an 355 unknown/unauthenticated principal. Just like the first category 356 above such applications can't perform access control based on network 357 layer information since they do not know the identity of the peer. 358 However, they might perform access control using higher-level notions 359 of identity. The availability of IPsec (and similar solutions) 360 together with channel bindings allow protocols which in themselves 361 are vulnerable to MiTM-attacks to operate with a high level of 362 confidentiality in the security of the identification of the peer. A 363 typical example is the Remote Direct Data Placement Protocol (RDDP) 364 which, when used with opportunistic IPsec, works well if channel 365 bindings are available. Channel bindings provide a link between the 366 IP-layer identification and the application protocol identification. 368 A variant of the fifth class are those that use "leap-of-faith" 369 during some initial communication, hence do not provide strong 370 identities, but where subsequent communication is bound to the 371 initial communication providing strong protection that the peer is 372 the same as during the initial communication. 374 The fifth class is important and its security properties must be 375 preserved by a multihoming solution. 377 The requirement for a multihoming solution is that security be no 378 worse than it is today in all situations. Thus, mechanisms that 379 provide confidentiality, integrity, or authentication today should 380 continue to provide these properties in a multihomed environment. 382 3.2. Redirection Attacks Today 384 This section enumerates some of the redirection attacks that are 385 possible in today's Internet. 387 If routing can be compromised, packets for any destination can be 388 redirected to any location. This can be done by injecting a long 389 prefix into global routing, thereby causing the longest match 390 algorithm to deliver packets to the attacker. 392 Similarly, if DNS can be compromised, and a change can be made to an 393 advertised resource record to advertise a different IP address for a 394 hostname, effectively taking over that hostname. More detailed 395 information about threats relating to DNS are in [DNS-THREATS]. 397 Any system that is along the path from the source to the destination 398 host can be compromised and used to redirect traffic. Systems may be 399 added to the best path to accomplish this. Further, even systems 400 that are on multi-access links that do not provide security can also 401 be used to redirect traffic off of the normal path. For example, ARP 402 and ND spoofing can be used to attract all traffic for the legitimate 403 next hop across an Ethernet. And since the vast majority of 404 applications rely on DNS lookups, if DNSsec is not deployed, then 405 attackers that are on the path between the host and the DNS servers 406 can also cause redirection by modifying the responses from the DNS 407 servers. 409 In general the above attacks work only when the attacker is on the 410 path at the time it is performing the attack. However, in some cases 411 it is possible for an attacker to create a DoS attack which remains 412 at least some time after the attacker has moved off the path. An 413 example of this is an attacker which uses ARP or ND spoofing while on 414 path to either insert itself or send packets to a black hole (a 415 non-existent L2 address). After the attacker moves away the ARP/ND 416 entries will remain in the caches in the neighboring nodes for some 417 amount of time; a minute or so in the case of ARP. This will result 418 in packets continuing to be black-holed until ARP entry is flushed. 420 Finally, the hosts themselves that terminate the connection can also 421 be compromised and can perform functions that were not intended by 422 the end user. 424 All of the above protocol attacks are the subject of ongoing work to 425 secure them (DNSsec, security for BGP, Secure ND) and are not 426 considered further within this document. The goal for a multihoming 427 solution is not to solve these attacks. Rather, it is to avoid 428 adding to this list of attacks. 430 3.3. Packet Injection Attacks Today 432 In today's Internet the transport layer protocols, such as TCP and 433 SCTP, which use IP, use the IP addresses as the identifiers for the 434 communication. In the absence of ingress filtering [INGRESS] the IP 435 layer allows the sender to use an arbitrary source address, thus the 436 transport protocols and/or applications need some protection against 437 malicious senders injecting bogus packets into the packet stream 438 between two communicating peers. If this protection can be 439 circumvented, then it is possible for an attacker to cause harm 440 without necessarily needing to redirect the return packets. 442 There are various level of protection in different transport 443 protocols. For instance, in general TCP packets have to contain a 444 sequence that falls in the receiver's window to be accepted. If the 445 TCP initial sequence numbers are random then it is very hard for an 446 off-path attacker to guess the sequence number close enough for it to 447 belong to the window, and as result be able to inject a packet into 448 an existing connection. How hard this is depends on the size of the 449 available window, whether the port numbers are also predictable, and 450 the lifetime of the connection. Note that there is ongoing work to 451 strengthen TCP's protection against this broad class of attacks 452 [TCPSECURE]. SCTP provides a stronger mechanism with the 453 verification tag; an off-path attacker would need to guess this 454 random 32-bit number. Of course, IPsec provide cryptographically 455 strong mechanisms which prevent attackers on or off path to inject 456 packets once the security associations have been established. 458 When ingress filtering is deployed between the potential attacker and 459 the path between the communicating peers, it can prevent the attacker 460 from using the peer's IP address as source. In that case the packet 461 injection will fail in today's Internet. 463 We don't expect a multihoming solution improve the existing degree of 464 prevention against packet injection. However, it is necessary to 465 look carefully whether a multihoming solution makes it easier for 466 attackers to inject packets since the desire to have the peer be 467 present at multiple locators, and perhaps at a dynamic set of 468 locators, can potentially result in solutions that, even in the 469 presence of ingress filtering, make packet injection easier. 471 3.4. Flooding Attacks Today 473 In the Internet today there are several ways for an attacker to use a 474 redirection mechanism to launch DoS attacks that can not easily be 475 traced to the attacker. An example of this is to use protocols which 476 cause reflection with or without amplification [PAXSON01]. 478 Reflection without amplification can be accomplished by an attacker 479 sending a TCP SYN packet to a well-known server with a spoofed source 480 address; the resulting TCP SYN ACK packet will be sent to the spoofed 481 source address. 483 Devices on the path between two communicating entities can also 484 launch DoS attacks. While such attacks might not be interesting 485 today, it is necessary to understand them better in order to 486 determine whether a multihoming solution might enables new types of 487 DoS attacks. 489 For example, today if A is communicating with B, then A can try to 490 overload the path from B to A. If TCP is used A could do this by 491 sending ACK packets for data that it has not yet received (but it 492 suspects B has already sent) so that B would send at a rate that 493 would cause persistent congestion on the path towards A. Such an 494 attack would seem self-destructive since A would only make its own 495 corner of the network suffer by overloading the path from the 496 Internet towards A. 498 A more interesting case is if A is communicating with B and X is on 499 the path between A and B, then X might be able to fool B to send 500 packets towards A at a rate that is faster than A (and the path 501 between A and X) can handle. For instance, if TCP is used then X can 502 craft TCP ACK packets claiming to come from A to cause B to use a 503 congestion window that is large enough to potentially cause 504 persistent congestion towards A. Furthermore, if X can suppress the 505 packets from A to B it can also prevent A from sending any explicit 506 "slow down" packets to B, that is, X can disable any flow or 507 congestion control mechanism such as Explicit Congestion Notification 508 [ECN]. Similar attacks can presumably be launched using protocols 509 that carry streaming media by forging such a protocol's notion of 510 acknowledgment and feedback. 512 An attribute of this type of attack is that A will simply think that 513 B is faulty since its flow and congestion control mechanisms don't 514 seem to be working. Detecting that the stream of ACK packets is 515 generated from X and not from A might be challenging, since the rate 516 of ACK packets might be relatively low. This type of attack might 517 not be common today because, in the presence of ingress filtering, it 518 requires that X remain on the path in order to sustain the DoS 519 attack. And in the absence of ingress filtering an attacker would 520 either need to be present on the path initially and then move away, 521 or the attacker would need to be able to perform the setup of the 522 communication "blind" i.e., without seeing the return traffic (which 523 in the case of TCP implies guessing the initial sequence number). 525 The danger is that the addition of multihoming redirection mechanisms 526 might potentially remove the constraint that the attacker remain on 527 the path. And with the current, no-multihoming support, using 528 end-to-end strong security at a protocol level at (or below) this 529 "ACK" processing would prevent this type of attack. But if a 530 multihoming solution is provided underneath IPsec that prevention 531 mechanism would potentially not exist. 533 Thus the challenge for multihoming solutions is to not create 534 additional types of attacks in this area, or make existing types of 535 attacks significantly easier. 537 3.5. Address Privacy Today 539 In today's Internet there is limited ability to track a host as it 540 uses the Internet because in some cases, such as dialup connectivity, 541 the host will acquire different IPv4 addresses each time it connects. 542 However, with increasing use of broadband connectivity, such as DSL 543 or cable, it is becoming more likely that the host will maintain the 544 same IPv4 over time. Should a host move around in today's Internet, 545 for instance, by visiting WiFi hotspots, it will be configured with a 546 different IPv4 address at each location. 548 We also observe that a common practice in IPv4 today is to use some 549 form of address translation, whether the site is multihomed or not. 550 This effectively hides the identity of the specific host within a 551 site; only the site can be identified based on the IP address. 553 In the cases where it is desirable to maintain connectivity as a host 554 moves around, whether using layer 2 technology or Mobile IPv4, the 555 IPv4 address will remain constant during the movement (otherwise the 556 connections would break). Thus there is somewhat of a choice today 557 between seamless connectivity during movement and increased address 558 privacy. 560 Today when a site is multihomed to multiple ISPs the common setup is 561 that a single IP address prefix is used with all the ISPs. As a 562 result it is possible to track that it is the same host that is 563 communication via all ISPs. 565 However, when a host (and not a site) is multi-homed to several ISP, 566 e.g. through a GPRS connection and a wireless hot spot, the host is 567 provided with different IP addresses on each interface. While the 568 focus of the multihoming work is on site multihoming, should the 569 solution also be applicable to host multihoming, the privacy impact 570 needs to be considered for this case as well. 572 IPv6 stateless address auto-configuration facilitates IP address 573 management, but raises some concerns since the Ethernet address is 574 encoded in the low-order 64 bits of the IPv6 address. This could 575 potentially be used to track a host as it moves around the network, 576 using different ISPs etc. IPv6 specifies temporary addresses 577 [RFC3041] which allow applications to control whether they need 578 long-lived IPv6 addresses or desire the improved privacy of using 579 temporary addresses. 581 Given that there is no address privacy in site multihoming setups 582 today, the primary concerns for the "do no harm" criteria are to 583 ensure that hosts that move around still have the same ability as in 584 today's Internet to choose between seamless connectivity and improved 585 address privacy, and also that the introduction of multihoming 586 support should still provide the same ability as we have in IPv6 with 587 temporary addresses. 589 When considering privacy threats it makes sense to distinguish 590 between attacks make by on-path entities observing the packets flying 591 by, and attacks by the communicating peer. While it is probably 592 feasible to prevent on-path entities from correlating the multiple IP 593 addresses of the host, the fact that the peer needs to be told 594 multiple IP addresses in order to be able to switch to using 595 different addresses when communication fails limits the ability of 596 the host to prevent correlating its multiple addresses. However, 597 using multiple pseudonyms for a host should be able address this 598 case. 600 4. POTENTIAL NEW ATTACKS 602 This section documents the additional attacks that have been 603 discovered that result from an architecture where hosts can change 604 their topological connection to the network in the middle of a 605 transport session without interruption. This discussion is again 606 framed in the context where the topological locators may be 607 independent of the host identifiers used by the transport and 608 application layer protocols. Some of these attacks may not be 609 applicable if traditional addresses are used. This section assumes 610 that each host has multiple locators and that there is some mechanism 611 for determining the locators for a correspondent host. We do not 612 assume anything about the properties of these mechanisms. Instead, 613 this list will serve to help us derive the properties of these 614 mechanisms that will be necessary to prevent these redirection 615 attacks. 617 Depending on the purpose of the redirection attack we separate the 618 attacks into several different types. 620 4.1. Cause Packets to be Sent to the Attacker 622 An attacker might want to receive the flow of packets, for instance 623 to be able to inspect and/or modify the payload or to be able to 624 apply cryptographic analysis to cryptographically protected payload, 625 using redirection attacks. 627 Note that such attacks are always possible today for an attacker 628 which is on the path between the two communicating parties, and a 629 multihoming solution can't possibly remove that threat. Hence the 630 bulk of these concerns relate to off-path attackers. 632 4.1.1. Once Packets are Flowing 634 This might be viewed as the "classic" redirection attack. 636 While A and B are communicating X might send packets to B and claim: 637 "Hi, I'm A, send my packets to my new location." where the location 638 is really X's location. 640 "Standard" solutions to this include requiring the host requesting 641 redirection somehow be verified to be the same host as the initial 642 host to establish communication. However, the burdens of such 643 verification must not be onerous, or the redirection requests 644 themselves can be used as a DoS attack. 646 To prevent this type of attack, a solution would need some mechanism 647 that B can use to verify whether a locator belongs to A before B 648 starts using that locator, and be able to do this when multiple 649 locators are assigned to A. 651 4.1.2. Time-shifting Attack 653 The term "time-shifting attack" is used to describe an attackers 654 ability to perform an attack after no longer being on the path. Thus 655 the attacker would have been on the path at some point in time, 656 snooping and/or modifying packets, and later when the attacker is no 657 longer on the path, it launches the attack. 659 In the current Internet, it is not possible to perform such attacks 660 to redirect packets. But for sometime after moving away the attacker 661 can cause a DoS attack e.g. by leaving a bogus ARP entry in the nodes 662 on the path or by forging TCP Reset packets based on having seen the 663 TCP Initial Sequence Numbers when it was on the path. 665 It would be reasonable to require that a multihoming solution limit 666 the ability to redirect and/or DoS traffic to a few minutes after the 667 attacker has moved off the path. 669 4.1.3. Premeditated Redirection 671 This is a variant of the above where the attacker "installs" itself 672 before communication starts. 674 For example, if the attacker X can predict that A and B will 675 communicate in the (near) future, then the attacker can tell B: "Hi, 676 I'm A and I'm at this location". When A later tries to communicate 677 with B, will B believe it is really A? 679 If the solution to the classic redirection attack is based on "prove 680 you are the same as initially", then A will fail to prove this to B 681 since X initiated communication. 683 Depending on details that would be specific to a proposed solution, 684 this type of attack could either cause redirection (so that the 685 packets intended for A will be sent to X) or they could cause DoS 686 (where A would fail to communicate with B since it can't prove it is 687 the same host as X). 689 To prevent this attack, the verification whether a locator belongs to 690 the peer can not simply be based on the first peer that made contact. 692 4.1.4. Using Replay Attacks 694 While the multihoming problem doesn't inherently imply any 695 topological movement it is useful to also consider the impact of site 696 renumbering in combination with multihoming. In that case the set of 697 locators for a host will change each time its site renumbers and at 698 some point in time after a renumbering event the old locator prefix 699 might be reassigned to some other site. 701 This potentially opens up the ability for an attacker to replay 702 whatever protocol mechanism was used to inform a host of a peer's 703 locators so that the host would incorrectly be lead to believe that 704 the old locator (set) should be used even long after a renumbering 705 event. This is similar to the risk of replay of Binding Updates in 706 [MIPv6] but the time constant is quite different; Mobile IPv6 might 707 see movements every second while site renumbering followed by 708 reassignment of the site locator prefix might be a matter of weeks or 709 months. 711 To prevent such replay attacks the protocol which is used to verify 712 which locators can be used with a particular identifier needs some 713 replay protection mechanism. 715 Also, in this space one needs to be concerned about potential 716 interaction between such replay protection and the administrative act 717 of reassignment of a locator. If the identifier and locator 718 relationship is distributed across the network one would need to make 719 sure that the old information has been completely purged from the 720 network before any reassignment. Note that this does not require an 721 explicit mechanism. This can instead be implemented by locator reuse 722 policy and careful timeouts of locator information. 724 4.2. Cause Packets to be Sent to a Black Hole 726 This is also a variant of the classic redirection attack. The 727 difference is that the new location is a locator that is nonexistent 728 or unreachable. Thus the effect is that sending packets to the new 729 locator causes the packets to be dropped by the network somewhere. 731 One would expect that solutions which prevent the previous 732 redirection attacks would prevent this attack as a side effect, but 733 it makes sense to include this attack here for completeness. 734 Mechanisms that prevented a redirection attack to the attacker should 735 also prevent redirection to a black hole. 737 4.3. Third Party Denial-of-Service Attacks 739 An attacker can use the ability to perform redirection to cause 740 overload on an unrelated third party. For instance, if A and B are 741 communicating then the attacker X might be able to convince A to send 742 the packets intended for B to some third node C. While this might 743 seem harmless at first, since X could just flood C with packets 744 directly, there are a few aspects of these attacks that cause 745 concern. 747 The first is that the attacker might be able to completely hide its 748 identity and location. It might suffice for X to send and receive a 749 few packets to A in order to perform the redirection, and A might not 750 retain any state on who asked for the redirection to C's location. 751 Even if A had retained such state, that state would probably not be 752 easily available to C, thus C can't determine who was the attacker 753 once C is being DoS'ed. 755 The second concern is that with a direct DoS attack from X to C, the 756 attacker is limited by the bandwidth of its own path towards C. If 757 the attacker can fool another host like A to redirect its traffic to 758 C then the bandwidth is limited by the path from A towards C. If A 759 is a high-capacity Internet service and X has slow (e.g., dialup) 760 connectivity this difference could be substantial. Thus in effect 761 this could be similar to packet amplifying reflectors in [PAXSON01]. 763 The third, and final concern, is that if an attacker only need a few 764 packets to convince one host to flood a third party, then it wouldn't 765 be hard for the attacker to convince lots of hosts to flood the same 766 third party. Thus this could be used for Distributed 767 Denial-of-Service attacks. 769 A third party DoS attack might be against the resources of a 770 particular host i.e., C in the example above, or it might be against 771 the network infrastructure towards a particular IP address prefix, by 772 overloading the routers or links even though there is no host at the 773 address being targeted. 775 In today's Internet the ability to perform this type of attack is 776 quite limited. In order for the attacker to initiate communication 777 it will in most cases need to be able to receive some packets from 778 the peer (the potential exception being combining this with TCP 779 sequence number guessing type of techniques). Furthermore, to the 780 extent that parts of the Internet uses ingress filtering [INGRESS], 781 even if the communication could be initiated it wouldn't be possible 782 to sustain it by sending ACK packets with spoofed source addresses 783 from an off-path attacker. 785 If this type of attack can't be prevented there might be mitigation 786 techniques that can be employed. For instance, in the case of TCP a 787 partial defense can be constructed by having TCP slow-start be 788 triggered when the destination locator changes. (Folks might argue 789 that, separately from security, this would be the correct action for 790 congestion control since TCP might not have any congestion-relation 791 information about the new path implied by the new locator). 792 Presumably the same approach can be applied to other transport 793 protocols which perform different forms of (TCP friendly) congestion 794 control, even though some of them might not adapt as rapidly as TCP. 795 But since all congestion controlled protocols probably need to have 796 some reaction to the path change implied by a locator change, it 797 makes sense thinking about 3rd party DoS attacks when designing how 798 the specific transport protocols should react to a locator change. 799 However, this would only be a partial solution since it would 800 probably take several packets and roundtrips before the transport 801 protocol would stop transmitting, thus an attacker could still use 802 this as a reflector with packet amplification. Thus the multihoming 803 mechanism probably needs some form of defense against third party DoS 804 attacks, in addition to the help we can get from the transport 805 protocols. 807 4.3.1. Basic Third Party DoS 809 Assume that X is on a slow link anywhere in the Internet. B is on a 810 fast link (gigabits; e.g., a media server) and A is the victim. 812 X could flood A directly but is limited by its low bandwidth. If X 813 can establish communication with B, ask B to send it a high-speed 814 media stream, then X can presumably fake out the 815 "acknowledgments/feedback" needed for B to blast out packets at full 816 speed. So far this only hurts X - and the path between X and the 817 Internet. But if X could also tell B "I'm at A's locator" then X has 818 effectively used this redirection capability in multihoming to 819 amplify its DoS capability, which would be a source of concern. 821 One could envision rather simple techniques to prevent such attacks. 822 For instance, before sending to a new peer locator perform a clear 823 text exchange with the claimed new locator of the form "Are you X?" 824 resulting in "Yes, I'm X.". This would suffice for the simplest of 825 attacks. However, as we will see below, more sophisticated attacks 826 are possible. 828 4.3.2. Third Party DoS with On-Path Help 830 The scenario is as above but in addition the attacker X has a friend 831 Y on the path between A and B: 833 ----- ----- ----- 834 | A |--------| Y |--------| B | 835 ----- ----- ----- 836 / 837 / 838 / 839 / 840 / 841 / 842 ----- 843 | X | 844 ----- 846 With the simple solution suggested in the previous section, all Y 847 might need to do is to fake a response to the "Are you X?" packet, 848 and after that point in time Y might not be needed; X could 849 potentially sustain the data flow towards A by generating the ACK 850 packets. Thus it would be even harder to detect the existence of Y. 852 Furthermore, if X is not the actual end system but an attacker 853 between some node C and B, then X can claim to be C, and no finger 854 can be pointed at X either: 856 ----- ----- ----- 857 | A |--------| Y |--------| B | 858 ----- ----- ----- 859 / 860 / 861 / 862 / 863 / 864 / 865 ----- ----- 866 | C |-------| X | 867 ----- ----- 869 Thus with two attackers on different paths, there might be no trace 870 of who did the redirection to the 3rd party once the redirection has 871 taken place. 873 A specific case of this is when X=Y, and X is located on the same LAN 874 as B. 876 A potential way to make such attacks harder would be to use the last 877 received (and verified) source locator as the destination locator. 878 That way when X sends the ACK packets (whether it claims to be X or 879 C) the result would be that the packet flow from B would switch back 880 towards X/C, which would result in an attack similar to what can be 881 performed in today's Internet. 883 Another way to make such attacks harder would be to perform periodic 884 verifications that the peer is available at the locator, instead of 885 just one when the new locator is received. 887 A third way that a multihoming solution might address this is to 888 ensure that B will only accept locators that can be authenticated to 889 be synonymous with the original correspondent. It must be possible 890 to securely ensure that these locators form an equivalence class. So 891 in the first example, not only does X need to assert that it is A, 892 but A needs to assert that it is X. 894 4.4. Accepting Packets from Unknown Locators 896 The multihoming solution space does not only affect the destination 897 of packets; it also raises the question from which sources packets 898 should be accepted. It is possible to build a multihoming solution 899 that allows traffic to be recognized as coming from the same peer 900 even if there is a previously unknown locator present in the source 901 address field. The question is whether we want to allow packets from 902 unverified sources to be passed on to transport and application layer 903 protocols. 905 In the current Internet, an attacker can't inject packets with 906 arbitrary source addresses into a session if there is ingress 907 filtering present, so allowing packets with unverified sources in a 908 multihoming solution would fail our "no worse than what we have now" 909 litmus test. However, given that ingress filtering deployment is far 910 from universal and ingress filtering typically wouldn't prevent 911 spoofing of addresses in the same subnet, requiring rejecting packets 912 from unverified locators might be too stringent. 914 An example of the current state are the ability to inject RST packets 915 into existing TCP connections. When there is no ingress filtering in 916 the network, this is something that the TCP endpoints need to sort 917 out themselves. However, deploying ingress filtering helps in 918 today's Internet since an attacker is limited in the set of source 919 address it can use. 921 A factor to take into account to determine the "requirement level" 922 for this is that when IPsec is used on top of the multihoming 923 solution, then IPsec will reject such spoofed packets. (Note that 924 this is different than in the redirection attack cases where even 925 with IPsec an attacker could potentially cause a DoS attack.) 927 There might also be a middle ground where arbitrary attackers are 928 prevented from injecting packets by using the SCTP verification tag 929 type of approach [SCTP]. (This is a clear-text tag which is sent to 930 the peer which the peer is expected to include in each subsequent 931 packet.) Such an approach doesn't prevent packet injection from 932 on-path attackers (since they can observe the verification tag), but 933 neither does ingress filtering. 935 4.5. New Privacy Considerations 937 While introducing identifiers can be helpful by providing ways to 938 identify hosts across events when its IP address(es) might change, 939 there is a risk that such mechanisms can be abused to track the 940 identity of the host over long periods of time, whether using the 941 same (set of) ISP(s) or moving between different network attachment 942 points. Designers of solutions to multihoming need to be aware of 943 this concern. 945 Introducing the multihoming capability inherently implies that the 946 communicating peers need to know multiple locators for each other in 947 order to be resilient to failures of some paths/locators. In 948 addition, if the multihoming signaling protocol doesn't provide 949 privacy it might be possible for 3rd parties on the path to discover 950 many or all the locators assigned to a host, which would increase the 951 privacy exposure compared to a multihomed host today. 953 A solution could address this for instance by allowing each host to 954 have multiple identifiers at the same time and perhaps even changing 955 the set of identifiers that are used over time. Such an approach 956 could be analogous to what is done for IPv6 addresses in [RFC3041]. 958 5. GRANULARITY OF REDIRECTION 960 Different multihoming solutions might approach the problem at 961 different layers in the protocol stack. For instance, there have 962 been proposals for a shim layer inside IP as well as transport layer 963 approaches. The former would have the capability to redirect an IP 964 address while the latter might be constrained to only redirect a 965 single transport connection. This difference might be important when 966 it comes to understanding the security impact. 968 For instance, premeditated attacks might have quite different impact 969 in the two cases. In an IP-based multihoming solution a successful 970 premeditated redirection could be due to the attacker connecting to a 971 server and claiming to be 'A' which would result in the server 972 retaining some state about 'A' which it received from the attacker. 973 Later, when the real 'A' tries to connect to the server, the 974 existence of this state might mean that 'A' fails to communicate, or 975 that its packets are sent to the attacker. But if the same scenario 976 is applied to a transport-layer approach then the state created due 977 to the attacker would perhaps be limited to the existing transport 978 connection. Thus while this might prevent the real 'A' from 979 connecting to the server while the attacker is connected (if they 980 happen to use the same transport port number) most likely it would 981 not affect 'A's ability to connect after the attacker has 982 disconnected. 984 A particular aspect of the granularity question is the direction 985 question; will the created state be used for communication in the 986 reverse direction from the direction when it was created? For 987 instance, if the attacker 'X' suspects that 'A' will connect to 'B' 988 in the near future, can X connect to A and claim to be B and have 989 that later make A connect to the attacker instead of to the real B? 991 Note that transport layer approaches are limited to the set of 992 "transport" protocols that the implementation makes aware of 993 multihoming. In many cases there would be "transport" protocols that 994 are unknown to the multihoming capability of the system, such as 995 applications built on top of UDP. To understand the impact of the 996 granularity question on the security, one would also need to 997 understand how such applications/protocols would be handled. 999 A property of transport granularity is that the amount of work 1000 performed by a legitimate host is proportional to the number of 1001 transport connections it creates that uses the multihoming support, 1002 since each such connection would require some multihoming signaling. 1003 And the same is true for the attacker. This means that an attacker 1004 could presumably do a premeditated attack for all TCP connections to 1005 port 80 from A to B, by setting up 65,536 (for all TCP source port 1006 numbers) to the server B and causing B to think those connections 1007 should be directed to the attacker and keeping those TCP connections 1008 open. Any attempt to make legitimate communication more efficient, 1009 e.g., by being able to signal for multiple transport connections at a 1010 time, would provide as much relative benefit for an attacker as the 1011 legitimate hosts. 1013 But the issue isn't only about the space (granularity) but also about 1014 the lifetime component in the results of a multihoming request. In a 1015 transport-layer approach the multihoming state would presumably be 1016 destroyed when the transport state is deleted as part of closing the 1017 connection. But an IP-layer approach would have to rely on some 1018 timeout or garbage collection mechanisms perhaps combined with some 1019 new explicit signaling to remove the multihoming state. The coupling 1020 between the connection state and multihoming state in the 1021 transport-layer approach might make it more expensive for the 1022 attacker, since it needs to keep the connections open. 1024 In summary, there are issues we don't yet understand well about 1025 granularity and reuse of the multihoming state. 1027 6. MOVEMENT IMPLICATIONS? 1029 In the case when nothing moves around we have a reasonable 1030 understanding of the security requirements. Something that is on the 1031 path can be a MiTM in today's Internet and a multihoming solution 1032 doesn't need to make that aspect any more secure. 1034 But it is more difficult to understand the requirements when hosts 1035 are moving around. For instance, a host might be on the path for a 1036 short moment in time by driving by an 802.11 hotspot. Would we or 1037 would we not be concerned if such a drive-by (which many call a 1038 "time-shifting" attack) would result in the temporarily on-path host 1039 being able to act as a MiTM for future communication? Depending on 1040 the solution this might be possible by the attacker causing 1041 multihoming state to be created in various peer hosts while the 1042 attacker was on the path, and that state remaining in the peers for 1043 some time. 1045 The answer to this question doesn't seem to be obvious even in the 1046 absence of any new multihoming support. We don't have much 1047 experience with hosts moving around that are able to attack things as 1048 they move. In Mobile IPv6 [MIPv6] a conservative approach was taken 1049 which limits the effect of such drive-by attacks to the maximum 1050 lifetime of the binding, which is set to a few minutes. 1052 With multihoming support the issue gets a bit more complicated 1053 because we explicitly want to allow a host to be present at multiple 1054 locators at the same time, thus there might be a need to distinguish 1055 between the host moving between different locators, and the host 1056 sending packets with different source locators because it is present 1057 at multiple locators without any topological movement. 1059 Note that the multihoming solutions that have been discussed range 1060 from such drive-by's being impossible (for instance, due to a strong 1061 binding to a separate identifier as in HIP, or due to reliance on the 1062 relative security of the DNS for forward plus reverse lookups in 1063 NOID), to systems that are first-come/first-serve (WIMP being an 1064 example with a separate ID space, a MAST approach with a PBK being an 1065 example without a separate ID space) that allow the first host which 1066 is using an ID/address to claim that without any time limit. 1068 7. OTHER SECURITY CONCERNS 1070 The protocol mechanisms added as part of a multihoming solution 1071 shouldn't introduce any new DoS in the mechanisms themselves. In 1072 particular, care must be taken not to: 1074 - create state on the first packet in an exchange, since that could 1075 result in state consumption attacks similar to the TCP SYN 1076 flooding attack. 1078 - perform much work on the first packet in an exchange (such as 1079 expensive verification) 1081 There is a potential chicken-and-egg problem here, because 1082 potentially one would want to avoid doing work or creating state 1083 until the peer has been verified, but verification will probably need 1084 some state and some work to be done. Avoiding any work does not seem 1085 possible, but good protocol design can often delay state creation 1086 until verification has been completed. 1088 A possible approach that solutions might investigate is to defer 1089 verification until there appears to be two different hosts (or two 1090 different locators for the same host) that want to use the same 1091 identifier. In such a case one would need to investigate whether 1092 combination of impersonation and DoS attack can be used to prevent 1093 the discovery of the impersonation. 1095 Another possible approach is to first establish communications, and 1096 then perform verification in parallel with normal data transfers. 1097 Redirection would only be permitted after verification was complete, 1098 but prior to that event, data could transfer in a normal, 1099 non-multihomed manner. 1101 Finally, the new protocol mechanisms should be protected against 1102 spoofed packets, at least from off-path sources, and replayed 1103 packets. 1105 8. SECURITY CONSIDERATIONS 1107 In section 3 the document presented existing protocol-based 1108 redirection attacks. But there are also non-protocol redirection 1109 attacks. An attacker which can gain physical access to one of 1111 - The copper/fiber somewhere in the path. 1113 - A router or L2 device in the path. 1115 - One of the end systems 1117 can also redirect packets. This could be possible for instance by 1118 physical break-ins or by bribing staff that have access to the 1119 physical infrastructure. Such attacks are out of scope for this 1120 discussion, but are worth to keep in mind when looking at the cost 1121 for an attacker to exploit any protocol-based attacks against 1122 multihoming solutions; making protocol-based attacks much more 1123 expensive to launch than break-ins/bribery type of attacks might be 1124 overkill. 1126 9. IANA CONSIDERATIONS 1128 This document has no IANA considerations. 1130 10. ACKNOWLEDGMENTS 1132 This document was originally produced of a MULTI6 design team 1133 consisting of (in alphabetical order): Iljitsch van Beijnum, Steve 1134 Bellovin, Brian Carpenter, Mike O'Dell, Sean Doran, Dave Katz, Tony 1135 Li, Erik Nordmark, and Pekka Savola. 1137 Much of the awareness of these threats come from the work on Mobile 1138 IPv6 [MIPv6, NIKANDER03, AURA02]. 1140 As the document has evolved the MULTI6 WG participants have 1141 contributed to the document. In particular: Masataka Ohta brought 1142 up privacy concern related to stable identifiers. The suggestion to 1143 discuss transport versus IP granularity was contributed by Marcelo 1144 Bagnulo, who also contributed text to Appendix B. Many editorial 1145 clarifications came from Jari Arkko. 1147 11. REFERENCES 1149 11.1. Normative References 1150 1152 11.2. Informative References 1154 [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the 1155 NSRG", draft-irtf-nsrg-report-10.txt (work in progress), 1156 September 2003. 1158 [MIPv6] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support in 1159 IPv6", RFC 3775, June 2004. 1161 [AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", 1162 draft-aura-mipv6-bu-attacks-01 (work in progress), March 1163 2002. 1165 [NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E. 1166 Nordmark, "Mobile IP version 6 Route Optimization Security 1167 Design Background", draft-nikander-mobileip-v6-ro-sec-02 1168 (work in progress), December 2003. 1170 [PAXSON01] V. Paxson, "An Analysis of Using Reflectors for 1171 Distributed Denial-of-Service Attacks", Computer 1172 Communication Review 31(3), July 2001. 1174 [INGRESS] Ferguson P., and D. Senie, "Network Ingress Filtering: 1175 Defeating Denial of Service Attacks which employ IP Source 1176 Address Spoofing", RFC 2827, May 2000. 1178 [SCTP] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. 1179 Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and 1180 V. Paxson, "Stream Control Transmission Protocol", RFC 1181 2960, October 2000. 1183 [RFC3041] T. Narten and Draves, R, "Privacy Extensions for 1184 Stateless Address Autoconfiguration in IPv6", January 2001. 1186 [DNS-THREATS] Derek Atkins, Rob Austein, "Threat Analysis Of The 1187 Domain Name System", RFC 3833, August 2004. 1189 [FYI18] G. Malkin, Ed., "Internet Users' Glossary", August 1996, 1190 Also RFC RFC1983. 1192 [ECN] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of 1193 Explicit Congestion Notification (ECN) to IP", RFC 3168, 1194 September 2001. 1196 [OWNER] Nikander, P., "Denial-of-Service, Address Ownership, and 1197 Early Authentication in the IPv6 World", Security Protocols 1198 9th International Workshop, Cambridge, UK, April 25-27 1199 2001, LNCS 2467, pages 12-26, Springer, 2002. 1201 [RFC1948] Bellovin, S., "Defending Against Sequence Number 1202 Attacks", RFC 1948, May 1996. 1204 [PBK] Scott Bradner, Allison Mankin, Jeffrey Schiller, "A Framework 1205 for Purpose-Built Keys (PBK)", 9-Jun-03, 1208 [NOID] Erik Nordmark, "Multihoming without IP Identifiers", July 1209 2004, 1211 [HIP] Pekka Nikander, "Considerations on HIP based IPv6 multi- 1212 homing", July 2004, 1214 [WIMP] Jukka Ylitalo, "Weak Identifier Multihoming Protocol 1215 (WIMP)", June 2004, 1217 [CBHI] Iljitsch van Beijnum, "Crypto Based Host Identifiers", 2- 1218 Feb-04, 1220 [TCPSECURE] M. Dalal (ed), "Transmission Control Protocol security 1221 considerations", Nov 22, 2004, 1224 AUTHORS' ADDRESSES 1226 Erik Nordmark 1227 Sun Microsystems, Inc. 1228 17 Network Circle 1229 Mountain View, CA 1230 USA 1232 phone: +1 650 786 2921 1233 fax: +1 650 786 5896 1234 email: erik.nordmark@sun.com 1236 Tony Li 1237 email: Tony.Li@tony.li 1239 APPENDIX A: CHANGES SINCE PREVIOUS DRAFT 1241 [RFC-editor: please remove this section before publication as an RFC] 1243 The following changes have been made since draft-ietf-multi6- 1244 threats-02: 1246 o Responding to IESG comments as detailed below 1248 o Reworded the abstract to say "inherent in all IPv6 multihoming 1249 solutions" 1251 o Removed unused references from the references section 1253 o Rewrote the text previously labeled "DISCUSSION" 1255 o Clarified text on multicast 1257 o Rewrote some (but not all) usage of first person to make the 1258 document seem stronger in its points. 1260 o Change the RDP example to be RDDP. 1262 o Added more text about transport layer issues and ongoing work in 1263 the section on packet injection attacks. Added reference to 1264 draft-ietf-tcpm-tcpsecure-02.txt. 1266 o Change the text to no longer say that non-TCP transport are more 1267 difficult with respect to 3rd party DoS attack mitigation. Made 1268 it clear that a transport-level approach to 3rd party DoS attack 1269 mitigation is helpful but most likely insufficient. 1271 o Clarified issue about doing work before verification has been 1272 performed in section 7. 1274 o Editorial clarifications requested by the IESG. 1276 The following changes have been made since draft-ietf-multi6- 1277 threats-01: 1279 o Fixed some idnits complaints. 1281 o Fixed potentially confusing "interfaces" vs. "identifiers" in the 1282 definition for "identifier". 1284 o In section 4.1, bluntly pointing out the man-in-the- middle 1285 potential in all of the redirection attacks. 1287 o Added text that the document is necessarily incomplete since it 1288 doesn't analyze a particular solution and that additional work 1289 will be needed when a solution is specified. 1291 o Clarified the uniqueness assumptions in the "address" definition. 1293 o In section 3.1 clarified the "binding" when mutual authentication 1294 is used. 1296 o Renamed "class of applications" to be "class of security 1297 configurations for applications". 1299 o Clarified in section 7 that deferred verification might be 1300 combined with DoS attacks to make it hard to detect the 1301 impersonation. 1303 o Added an empty IANA Considerations section 1305 o Added note for RFC-editor to remove Appendix A. 1307 o Added clarification that "leap of faith" trust arrangements is 1308 part of the 5th category. 1310 The following changes have been made since draft-ietf-multi6- 1311 threats-00: 1313 o Added more information to section 3.1 based on comments on the 1314 mailing list. 1316 o Made stronger statements about privacy from the WG discussion on 1317 San Diego. 1319 o Added text about time-shifting attacks i.e. where an attacker was 1320 on-path and later moves off the path. 1322 The following changes have been made since draft-nordmark-multi6- 1323 threats-02: 1325 o Editorial clarifications based on WG comments. 1327 o Removed the ULP term and it's usage since it was potentially 1328 confusing. 1330 o Added a current state of privacy as the basis for "do no harm" 1332 o Added some background information about authentication, 1333 authorization, and identifier ownership. 1335 o Improvements to Appendix B 1337 The following changes have been made since draft-nordmark-multi6- 1338 threats-01: 1340 o Editorial clarifications based on comments from Brian. 1342 The following changes have been made since draft-nordmark-multi6- 1343 threats-00: 1345 o Added reference to [DNS-THREATS] and clarified that attackers on 1346 the path between the host and the DNS servers can redirect traffic 1347 today. 1349 o Added a section on existing packet injection attacks to talk about 1350 TCP sequence number guessing etc. 1352 o Clarified ingress filtering relationship in section on today's 1353 flooding attacks. 1355 o Added a new section on granularity to list some issues about 1356 transport-level versus IP-level approaches and what we understand 1357 about the differences in security. This is still very much a work 1358 in progress. 1360 o Added a new section on movement to discuss how things change when 1361 hosts move around the network. This is still very much a work in 1362 progress. 1364 o Added Appendix B - but this should probably be moved to a 1365 different document to keep this document focused on the threats. 1367 APPENDIX B: SOME SECURITY ANALYSIS 1369 When looking at the proposals that have been made for multihoming 1370 solutions and the above threats it seems like there are two separable 1371 aspects of handling the redirection threats: 1373 - Redirection of existing communication 1375 - Redirection of an identity before any communication 1377 This seems to be related to the fact that there are two different 1378 classes of use of identifiers. One use is for: 1380 o Initially establishing communication; looking up a FQDN to find 1381 something which is passed to a connect() or sendto() API call. 1383 o Comparing whether a peer entity is the same peer entity as in some 1384 previous communication. 1386 o Using the identity of the peer for future communication 1387 ("callbacks") in the reverse direction, or to refer to a 3rd party 1388 ("referrals"). 1390 The other use of identifiers is as part of being able to redirect 1391 existing communication to use a different locator. 1393 The first class of use seems to be related to something about the 1394 ownership of the identifier; proving the "ownership" of the 1395 identifier should be sufficient in order to be authorized to control 1396 which locators are used to reach the identifier. 1398 The second class of use seems to be related to something more 1399 ephemeral. It seems to be sufficient to be able to prove that the 1400 entity is the same as the one that initiated the communication to be 1401 able to redirect the existing communication to some other locator. 1402 One can view this as proving the ownership of some context, where the 1403 context is established around the time when the communication is 1404 initiated. 1406 Preventing unauthorized redirection of existing communication can be 1407 addressed by a large number of approaches which are based on setting 1408 up some form of security material at the beginning of communication, 1409 and later using the existence of that material for one end to prove 1410 to the other that it remains the same. An example of this is Purpose 1411 Built Keys [PBK]. One can envision different approaches for such 1412 schemes with different complexity, performance, and resulting 1413 security such as anonymous 1414 Diffie-Hellman exchange, the reverse hash chains presented in [WIMP], 1415 or even a clear-text token exchanged at the initial communication. 1417 However, the mechanisms for preventing unauthorized use of an 1418 identifier can be quite different. One way to prevent premeditated 1419 redirection is to simply not introduce a new identifier name space 1420 but instead rely on existing name space(s), a trusted third party, 1421 and a sufficiently secure way to access the third party, as in 1422 [NOID]. Such an approach relies on the third party (DNS in the case 1423 of NOID) as the foundation. In terms of multihoming state creation, 1424 in this case premeditated redirection is as easy or as hard as 1425 redirecting an IP address today. Essentially this relies on the 1426 return-routability check associated with a roundtrip of communication 1427 which verifies that the routing system delivers packets to the IP 1428 address in question. 1430 Alternatively, one can use the crypto-based identifiers such as in 1431 [HIP] or crypto-generated addresses as in [CBHI], which both rely on 1432 public-key crypto, to prevent premeditated attacks. In some cases it 1433 is also possible to avoid the problem by having (one end of the 1434 communication) use ephemeral identifiers as the initiator does in 1435 [WIMP]. This avoids premeditated redirection by detecting that some 1436 other entity is using the same identifier at the peer and switching 1437 to use another ephemeral ID. While the ephemeral identifiers might 1438 be problematic when used by applications, for instance due to 1439 callbacks or referrals, it is an interesting observation that for the 1440 end that has the ephemeral identifier, one can skirt around the 1441 premeditated attacks (assuming the solution has a robust way to pick 1442 a new identifier when one is in use/stolen). 1444 Assuming the problem can't be skirted around by using ephemeral 1445 identifiers there seem to be 3 types of approaches which can be used 1446 to establish some form of identity ownership: 1448 - A trusted third party, which states that a given identity is 1449 reachable at a given set of locators, so the endpoint reached at 1450 one of this locators is the owner of the identity. 1452 - Crypto-based identifiers or crypto-generated addresses where the 1453 public/private key pair can be used to prove that the identifier 1454 was generated by the node knowing the private key (or by another 1455 node whose public key hashes to the same value) 1457 - A static binding, as currently defined in IP, where you trust that 1458 the routing system will deliver the packets to the owner of the 1459 locator, and since the locator and the identity are one, you prove 1460 identity ownership as a sub-product. 1462 A solution would need to combine elements which provide protection 1463 against both premeditated and 1464 on-going communication redirection. This can be done in several 1465 ways, and the current set of proposals do not appear to contain all 1466 useful combinations. For instance, the HIP CBID property could be 1467 used to prevent premeditated attacks while the WIMP hash chains could 1468 be used to prevent on-going redirection. And there are probably 1469 other interesting combinations. 1471 A related, but perhaps separate aspect, is whether the solution 1472 provides for protection against Man-in-The-Middle attacks with 1473 on-path attackers. Some schemes, such as [HIP] and [NOID] do, but 1474 given that an on-path attacker can see and modify the data traffic 1475 whether or not it can modify the multihoming signaling, this level of 1476 protection seems like overkill. Protecting against on-path MiTM for 1477 the data traffic can be done separately using IPsec, TLS, etc. 1479 Finally, preventing third party DoS attacks is conceptually simpler; 1480 it would suffice to somehow verify that the peer is indeed reachable 1481 at the new locator before sending a large number of packets to that 1482 locator. 1484 Just as the redirection attacks are conceptually prevented by proving 1485 at some level the ownership of the identifier or the ownership of the 1486 communication context, third party DoS attacks are conceptually 1487 prevented by showing that the endpoint is authorized to use a given 1488 locator. 1490 The currently known approaches for showing such authorization are: 1492 - Return routability, that is, if an endpoint is capable of 1493 receiving packets at a given locator, it is because he is 1494 authorized to do so. This relies to routing being reasonably hard 1495 to subvert to deliver packets to the wrong place. While this 1496 might be the case when routing protocols are used with reasonable 1497 security mechanisms and practices, it isn't the case on a single 1498 link where ARP and Neighbor Discovery can be easily spoofed. 1500 - Trusted third party. A third party establishes that a given 1501 identity is authorized to use a given set of locators (for 1502 instance the DNS) 1504 Intellectual Property Statement 1506 The IETF takes no position regarding the validity or scope of any 1507 Intellectual Property Rights or other rights that might be claimed to 1508 pertain to the implementation or use of the technology described in 1509 this document or the extent to which any license under such rights 1510 might or might not be available; nor does it represent that it has 1511 made any independent effort to identify any such rights. Information 1512 on the procedures with respect to rights in RFC documents can be 1513 found in BCP 78 and BCP 79. 1515 Copies of IPR disclosures made to the IETF Secretariat and any 1516 assurances of licenses to be made available, or the result of an 1517 attempt made to obtain a general license or permission for the use of 1518 such proprietary rights by implementers or users of this 1519 specification can be obtained from the IETF on-line IPR repository at 1520 http://www.ietf.org/ipr. 1522 The IETF invites any interested party to bring to its attention any 1523 copyrights, patents or patent applications, or other proprietary 1524 rights that may cover technology that may be required to implement 1525 this standard. Please address the information to the IETF at 1526 ietf-ipr@ietf.org. 1528 Disclaimer of Validity 1530 This document and the information contained herein are provided on an 1531 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1532 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1533 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1534 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1535 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1536 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1538 Copyright Statement 1540 Copyright (C) The Internet Society (2005). This document is subject 1541 to the rights, licenses and restrictions contained in BCP 78, and 1542 except as set forth therein, the authors retain all their rights. 1544 Acknowledgment 1546 Funding for the RFC Editor function is currently provided by the 1547 Internet Society.