idnits 2.17.1 draft-ietf-v6ops-6to4-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 9 instances of too long lines in the document, the longest one being 9 characters in excess of 72. == There are 23 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (October 2003) is 7499 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1812' is mentioned on line 1005, but not defined == Unused Reference: 'RFC1918' is defined on line 1338, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3068 (ref. '6TO4ANY') (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. 'ADDRSEL') (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-15 -- Obsolete informational reference (is this intentional?): RFC 2893 (ref. 'MECH') (Obsoleted by RFC 4213) == Outdated reference: A later version (-04) exists of draft-ietf-send-psreq-03 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops Working Group P. Savola 3 Internet Draft CSC/FUNET 4 Expiration Date: April 2004 5 October 2003 7 Security Considerations for 6to4 9 draft-ietf-v6ops-6to4-security-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over- 35 IPv4 tunneling to interconnect IPv6 networks. The architecture 36 includes 6to4 Routers and Relay Routers, which accept and decapsulate 37 IPv4 protocol-41 ("IPv6-in-IPv4") traffic from anywhere. There 38 aren't many constraints on the embedded IPv6 packets, or where IPv4 39 traffic will be automatically tunneled to. These could enable one to 40 go around access controls, and more likely, being able to perform 41 proxy Denial of Service attacks using 6to4 relays or routers as 42 reflectors. Anyone is also capable of spoofing traffic from non-6to4 43 addresses, as if it was coming from a relay, to a 6to4 node. This 44 document discusses these issues in more detail and tries to suggest 45 enhancements to alleviate the problems. 47 Table of Contents 49 1. Introduction ............................................... 3 50 2. Different 6to4 Forwarding Scenarios ........................ 4 51 2.1. From 6to4 to 6to4 ...................................... 4 52 2.2. From Native to 6to4 .................................... 5 53 2.3. From 6to4 to Native .................................... 6 54 2.4. Other Models ........................................... 6 55 2.4.1. BGP Between 6to4 Routers and Relays ................ 6 56 2.4.2. 6to4 as an Optimization Method ..................... 7 57 2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism ...... 7 58 3. Some Functionalities of 6to4 ............................... 7 59 3.1. Functions of Different 6to4 Network Components ......... 7 60 3.2. Non-functions of Different 6to4 Network Components ..... 9 61 4. Special Processing of 6to4 Packets ......................... 9 62 4.1. Encapsulating IPv6 Packets into IPv4 ................... 9 63 4.2. Decapsulating IPv4 Packets into IPv6 ................... 10 64 5. Threat Analysis ............................................ 10 65 5.1. Threats Related to Any 6to4 Node ....................... 10 66 5.2. Threats Related to 6to4 Routers ........................ 10 67 5.2.1. Attacks Against the 6to4 Pseudo-Interface .......... 11 68 5.2.1.1. Comparison to Situation without 6to4 ........... 11 69 5.2.2. Relay Spoofing, DoS against IPv6 Nodes ............. 11 70 5.2.2.1. Comparison to Situation without 6to4 ........... 12 71 5.3. Threats Related to 6to4 Relays ......................... 13 72 5.3.1. Attacks Against the 6to4 Pseudo-Interface .......... 14 73 5.3.2. Spoofing, DoS against IPv6 Nodes ................... 14 74 5.3.3. Participating in DoS attacks against IPv4 .......... 14 75 5.3.3.1. Comparison to Situation without 6to4 ........... 14 76 5.3.4. Using Any IPv6 Node for Reflection ................. 15 77 5.3.4.1. Comparison to Situation without 6to4 ........... 15 78 5.3.5. IPv4 Local Directed Broadcast Attacks .............. 16 79 5.3.5.1. Comparison to Situation without 6to4 ........... 16 80 5.3.6. Theft of Service ................................... 16 81 5.3.7. Relay Operators Seen as Source of Abuse ............ 17 82 5.4. Possible Threat Mitigation Methods ..................... 18 83 5.4.1. 6to4 Decapsulation Cache ........................... 18 84 5.4.2. Rate-limiting at 6to4 Routers/Relays ............... 18 85 5.4.3. An Application of iTrace Model ..................... 18 86 5.5. Summary ................................................ 19 87 5.5.1. Summary of the Threats ............................. 19 88 5.5.2. Generic Notes about Threats ........................ 20 89 6. Implementing Proper Security Checks in 6to4 ................ 21 90 6.1. Generic Approach ....................................... 21 91 6.1.1. Encapsulating IPv6 into IPv4 ....................... 21 92 6.1.2. Decapsulating IPv4 into IPv6 ....................... 22 93 6.1.3. IPv4 and IPv6 Sanity Checks ........................ 22 94 6.1.3.1. IPv4 ........................................... 22 95 6.1.3.2. IPv6 ........................................... 23 96 6.1.3.3. Optional Ingress Filtering ..................... 23 97 6.1.3.4. Notes About the Checks ......................... 23 98 6.2. Simplified Approach .................................... 24 99 6.2.1. Encapsulating IPv6 into IPv4 ....................... 24 100 6.2.2. Decapsulating IPv4 into IPv6 ....................... 24 101 7. Issues ..................................................... 25 102 7.1. Implementation Considerations with Automatic Tunnels ... 25 103 7.2. Reduced Flexibility .................................... 26 104 7.3. Anyone Pretending to Be a Relay Router ................. 26 105 7.3.1. Limited Distribution of More Specific Routes ....... 27 106 7.3.2. A Different Model for 6to4 Deployment .............. 28 107 8. Security Considerations .................................... 28 108 9. Acknowledgements ........................................... 29 109 10. References ................................................ 30 110 10.1. Normative References .................................. 30 111 10.2. Informative References ................................ 30 112 Author's Address ............................................... 31 113 A. Some Trivial Attack Scenarios Outlined ..................... 31 115 1. Introduction 117 The IPv6 interim mechanism "6to4" [6TO4] specifies automatic 118 IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds without 119 explicit tunnels by embedding the tunnel IPv4 address in the IPv6 120 6to4 prefix. 122 One challenge with this mechanism is that all 6to4 routers must 123 accept and decapsulate IPv4 packets from every other 6to4 router; 124 there are no strict constraints on what the IPv6 packet may contain, 125 which implies a trust relationship. 127 Another, bigger challenge is that to interconnect native IPv6 128 networks and 6to4 clouds, relay routers are used as bridges between 129 these two clouds. Relay routers can be tricked by malicious parties 130 to send IPv4 or IPv6 traffic anywhere the attacker wants. With 131 source address spoofing, this could be called traffic "laundering" or 132 a "proxy" denial-of-service attack. To some extent, these reflected 133 attacks can also be launched off from any node at all. 135 Even worse, anyone can send tunneled traffic, spoofed to come from 136 non-6to4 addresses to any 6to4 router, and the node does not have any 137 means to ensure its correctness, but to assume it came from a 138 legitimate Relay. 140 The 6to4 specification outlined quite a few security considerations, 141 but it has been shown that in practice some of these have been 142 difficult to get implemented due to their abstract nature. 144 This draft analyses the 6to4 security issues in more detail and 145 outlines some enhancements and caveats. 147 Sections 2-4 are more or less introductory in nature, rehashing how 148 6to4 should be used today based on the 6to4 specification, so that it 149 is easier to understand how security could be affected. Section 5 150 provides a threat analysis for implementations that already implement 151 most of the security checks. Section 6 introduces some filtering 152 rules for 6to4 implementations, and section 7 discusses some 153 additional problems which still need some consideration. Appendix A 154 outlines a few possible trivial attack scenarios in the case that 155 very little or no security has been implemented. 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 2. Different 6to4 Forwarding Scenarios 163 It should be noted that when communicating between 6to4 and native 164 domains, the relays that will be used in the two directions are very 165 likely different; routing is highly asymmetric. Because of this, it 166 is not feasible to limit relays you accept traffic from with e.g. 167 access lists. 169 The first three subsections introduce the most common forms of 6to4 170 operation. Other models are presented in the fourth subsection. 172 2.1. From 6to4 to 6to4 174 6to4 domains always exchange 6to4 traffic directly via IPv4 175 tunneling; the endpoint address V4ADDR is derived from 6to4 prefix 176 2002:V4ADDR. 178 .--------. _----_ .--------. 179 | 6to4 | _( IPv4 )_ | 6to4 | 180 | Router | <====> ( Internet ) <===> | Router | 181 '--------' (_ _) '--------' 182 ^ '----' ^ 183 | Direct tunneling over IPv4 | 184 V V 185 .--------. .-------. 186 | 6to4 | | 6to4 | 187 | Client | | Client | 188 '--------' '--------' 190 It is required that every 6to4 router considers every other 6to4 191 router it wants to talk to to be "on-link" (with IPv4 as the link- 192 layer). If this is restricted by increasing the prefix length from 193 2002::/16, some traffic will be sent to the 6to4 Relay Router, which 194 would forward it to other 6to4 Routers. However, if the original 195 destination does not have equally long prefix, the traffic it tries 196 to send back will be tunneled directly, and will be dropped. 198 Therefore, the restricted scenario with a longer prefix-length is not 199 globally workable and will not be considered here. 201 2.2. From Native to 6to4 203 When native domains send traffic to 6to4 address 2002:V4ADDR, it will 204 be routed to the topologically nearest, advertising 6to4 Relay 205 Router. Relay router will tunnel the traffic over IPv4 to the 206 corresponding IPv4 address V4ADDR. (Note that IPv4 address 9.0.0.1 207 here is just an example of a global IPv4 address.) 209 2002::/16 Closest to 'Native Client' 210 .--------. _----_ .------------. .--------. 211 | Native | _( IPv6 )_ | 6to4 Relay | Tunneled | 6to4 | 212 | Client | -> ( Internet ) --> | Router | =========> | Router | 213 '--------' (_ _) '------------' 9.0.0.1 '--------' 214 '----' dst=2002:0900:0001::1 | 215 V 216 .-------. 217 | 6to4 | 218 | Client | 219 '--------' 221 2.3. From 6to4 to Native 223 6to4 domains send traffic to native domains by tunneling it over IPv4 224 to their configured 6to4 Relay Router, or the closest found using 225 6to4 IPv4 Anycast [6TO4ANY]. The relay will decapsulate the packet 226 and forward it to native IPv6 Internet, the same way as any other 227 IPv6 packet. 229 Configured/found by IPv4 Anycast 230 .--------. _----_ .------------. .--------. 231 | Native | _( IPv6 )_ | 6to4 Relay | Tunneled | 6to4 | 232 | Client | <- ( Internet ) <-- | Router | <========= | Router | 233 '--------' (_ _) '------------' 192.88.99.1'--------' 234 '----' (or configured) ^ 235 dst=3ffe:ffff::1 | 236 .-------. 237 | 6to4 | 238 | Client | 239 '--------' 241 2.4. Other Models 243 These are more or less special cases of 6to4 operation; in later 244 chapters, unless otherwise stated, only the most generally-used 245 models (above) will be considered. 247 2.4.1. BGP Between 6to4 Routers and Relays 249 [6TO4, 5.2.2.2] presents a model where, instead of static 250 configuration, BGP4+ is used between 6to4 Relay Routers and 6to4 251 Routers. 253 If the 6to4 router established a BGP session between all the possible 254 6to4 relays, the traffic from non-6to4 sites would always go through 255 "home relay", and configuring "trusted relay" would not be a problem; 256 an alternative would be to advertise the more specific 6to4 routes 257 between 6to4 Relays, as described later in this memo. 259 This model is not known to be used at the time of writing; this is 260 probably caused by the fact that parties that need 6to4 are those 261 that are not able to run BGP, and because setting up these sessions 262 would be much more work for relay operators. 264 2.4.2. 6to4 as an Optimization Method 266 Some seem to use 6to4 as an IPv6 connectivity "optimization method"; 267 that is, they have also non-6to4 addresses on their nodes and border 268 routers, but also employ 6to4 to reach 6to4 sites. 270 This is typically done to be able to reach 6to4 destinations by 271 direct tunneling and not having to use relays at all. 273 Some also publish both 6to4 and non-6to4 addresses in DNS to affect 274 inbound connections; if the source host's default address selection 275 [ADDRSEL] works properly, 6to4 sources will use 6to4 addresses to 276 reach the site and non-6to4 nodes use non-6to4 addresses. If this 277 behaviour of foreign nodes can be assumed, the security threats to 278 such sites can be significantly simplified. 280 2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism 282 6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel 283 endpoint addressing and routing mechanism. 285 An example of this is interconnecting 10 branch offices where nodes 286 use non-6to4 addresses. Only the offices' border routers need to be 287 aware of 6to4, and use 6to4 addresses solely for addressing the 288 tunnels between different branch offices. This assumes that all 289 outgoing traffic from the main organization (but not between branch 290 offices) uses one or more non-6to4 connections. 292 This is similar to the optimization model above, and can be used to 293 make the addressing and routing easier. 295 3. Some Functionalities of 6to4 297 In this section, some, relatively obvious features of different 6to4 298 components are listed to better undestand what's the required 299 behaviour. 301 3.1. Functions of Different 6to4 Network Components 303 o Non-6to4 (Native) Node 305 If native IPv6 nodes want to communicate with 6to4 nodes, 306 they send the traffic along normally. The traffic will 307 reach the topologically closest, advertising 6to4 Relay 308 Router, and will be tunneled to the destination 6to4 Router, 309 which will pass it to the 6to4 node via normal forwarding 310 process. 312 o 6to4 Host 314 A host, usually autoconfigured, that has an address from a 315 6to4 prefix, but doesn't have a 6to4 pseudo-interface. It 316 doesn't need to know anything about 6to4, and it acts like a 317 normal IPv6 Host in every manner. Note that 6to4 Hosts can 318 also be 6to4 Routers in some scenarios, but then 6to4 Router 319 functionalities, below, apply. 321 o 6to4 Router 323 Acts at the border of a 6to4 domain. It does not have a 324 native, global IPv6 address. More specifically: 326 - provide "native-like" IPv6 connectivity to local clients 327 and routers 328 - if packets are sent to foreign 6to4 addresses, tunnel 329 them to the destination 6to4 router using IPv4 330 - if packets are sent to locally configured 6to4 331 addresses, forward them normally 332 - if packets are sent to non-6to4 addresses, tunnel them 333 to the configured/closest-by-anycast 6to4 Relay Router, 334 which will pass them on 335 - if packets are received from 6to4 addresses, decapsulate 336 the IPv4 packets received from 6to4 routers 337 - if packets are received from non-6to4 addresses, 338 decapsulate the IPv4 packets received from 6to4 Relay 339 Router closest to the source (note: it is not easily 340 distinguishable that the packet was really received from 341 a Relay router, not from a spoofing third party.) 343 o 6to4 Relay Router 345 Acts as a relay between all 6to4 domains and native IPv6; 346 more specifically: 348 - advertises the reachability of the 2002::/16 prefix to 349 native IPv6 routing, thus receiving traffic to all 6to4 350 addresses from closest native IPv6 nodes 351 - (if implements RFC3068) advertise the reachability of 352 IPv4 '6to4 Relay anycast prefix' (192.88.99.0/24) to 353 IPv4 routing, thus receiving some tunneled traffic to 354 native IPv6 nodes from 6to4 Routers 355 - if packets are received from 6to4 addresses through 356 tunneling, decapsulate them and forwards them on using 357 normal IPv6 routing 359 - if packets are received through normal IPv6 routing from 360 native addresses, and are destined for 2002::/16, tunnel 361 them to the corresponding 6to4 Router 363 3.2. Non-functions of Different 6to4 Network Components 365 What should not happen; this forms a basis for the security checks. 366 The lists are not exhaustive. 368 o 6to4 Router or Relay 369 - use private, broadcast or reserved IPv4 addresses in tunnels, 370 or the matching 6to4 prefixes 371 - receive traffic from 6to4 Routers where the IPv4 tunnel 372 source address does not match the 6to4 prefix 373 - receive traffic where the destination IPv6 address is not a 374 global address; in particular, e.g. link-local addresses, 375 mapped addresses and such should not be used 376 o 6to4 Router 377 - send traffic to other 6to4 domains through 6to4 Relay Router 378 or via some third party 6to4 Router 379 - receive traffic from other 6to4 domains via a 6to4 Relay 380 Router 381 - receive traffic to other than to your own 6to4 prefix(es) 382 o 6to4 Relay Router 383 - receive traffic from 6to4 to 6to4 385 4. Special Processing of 6to4 Packets 387 One could summarize the special processing of 6to4 as follows: 389 o Relay Router 390 1. incoming from native, tunneled to 6to4 391 2. tunneled from 6to4, going to native 393 o Router 394 1. tunneled from relay, source is native 395 2. tunneled to relay, destination is native 396 3. tunneled directly, destination is 6to4 398 4.1. Encapsulating IPv6 Packets into IPv4 400 IPv6 packets are encapsulated into IPv4 in three scenarios: 402 1. 6to4 Router sends packets to other 6to4 Routers (2002::/16 403 destination) 405 2. 6to4 Router sends packets to its configured/nearest-by-anycast 406 6to4 Relay Router (non-2002::/16 destination) 407 3. 6to4 Relay Router sends packets from native IPv6 sources to 408 6to4 Routers (2002::/16 destination) 410 4.2. Decapsulating IPv4 Packets into IPv6 412 IPv6 packets are decapsulated from IPv4 in three scenarios: 414 1. 6to4 Router receives packets from other 6to4 Routers (2002::/16 415 source) 416 2. 6to4 Router receives packets from a node, supposedly 6to4 Relay 417 Router closest to the source (non-2002::/16 source) 418 3. 6to4 Relay Router receives packets from 6to4 Routers, to be 419 sent to native IPv6 destinations (2002::/16 source) 421 5. Threat Analysis 423 The 6to4 threat analysis presented here focuses on 6to4 424 implementations which have implemented most if not all security 425 checks listed in [6TO4]; in particular, checks that always match 426 2002:V4ADDR and V4ADDR must be implemented. Many implementations are 427 known to be problematic at least in some cases. 429 The appendix lists some additional trivial threats which are 430 applicable if no or only little security is implemented. 432 The IPv4 address blocks 8.0.0.0/24 and 9.0.0.0/24 are only used for 433 demonstrative purposes, representing global IPv4 addresses. 435 5.1. Threats Related to Any 6to4 Node 437 Any 6to4 node can be made to participate in a DoS attack listed in 438 5.2.2 below, being used as "dst". The threat will be discussed 439 there. 441 5.2. Threats Related to 6to4 Routers 443 Note that in this memo, a loose interpretation of "6to4 router" is 444 used; it is used to refer to those all nodes which have the 6to4 445 pseudo-interface. 447 There are two main classes of threats; attacks against the 6to4 448 pseudo-interface and attacks relying on being able to abuse the fact 449 that it is difficult for 6to4 routers to tell whether packets from 450 non-6to4 nodes come from legitimate relays. 452 5.2.1. Attacks Against the 6to4 Pseudo-Interface 454 Unless the 6to4 pseudo-interface has been sufficiently protected, 455 it's possible to remotely attack the pseudo-interface with tunneled 456 link-local packets, just as if it were in a local network. Threats 457 to Neighbor Discovery are listed in [SEND]. 459 The potential effects of an attack can be mitigated if the interface 460 is insulated from the other interfaces (e.g. a separate neighbor 461 cache). In practise, this is not the case. 463 The attack can be eliminated by restricting the use of 6to4 pseudo- 464 interface: if any packet with scope smaller than global is received, 465 it must be silently discarded. ("Local addresses", if specified, 466 might be allowed in some restricted scenarios.) This may conflict 467 with future uses of [6TO4, 3.1]. 469 5.2.1.1. Comparison to Situation without 6to4 471 Even though rather simply fixable, this attack is not new as such; 472 the same is possible using automatic tunneling [MECH] or configured 473 tunneling (if one is able to spoof source IPv4 address to that of the 474 tunnel end-point). 476 However, as automatic tunneling is being deprecated, the worst 477 problem comes from 6to4; any open decapsulation is bad. 479 5.2.2. Relay Spoofing, DoS against IPv6 Nodes 481 6to4 Routers receive packets from non-6to4 source addresses through 482 Relay Routers, as described in section 2.2 and 4.2 point 2. 484 In the general case, the 6to4 router cannot distinguish Relay routers 485 from malicious nodes sending IPv4-encapsulated IPv6 traffic directly 486 to the 6to4 router. 488 This makes two kinds of attacks possible: 490 o unidirectional source address spoofing, and 491 o Denial-of-Service attack reflection against native IPv6 nodes. 493 In both scenarios, the attacker sends IPv4-encapsulated IPv6 packets 494 to the 6to4 router with contents like: 496 src = 3ffe:1122:3344::1 (forged) 497 dst = 2002:0900:0002::1 498 src_v4 = 8.0.0.1 499 dst_v4 = 9.0.0.2 (matching dst) 501 Now the 6to4 router receives these packets from 8.0.0.1, decapsulates 502 them, discarding the IPv4 header containing the source address 503 8.0.0.1 and processes them as normal ("dst" has been guessed or 504 obtained using one of a number of techniques). 506 In the first scenario, it is assumed that "src" is somehow specially 507 trusted (at least to some extent) more than some other packets. This 508 kind of weak trust based on IP addresses is commonplace. This 509 enables unidirectional (as the replies will be lost) source address 510 spoofing, but may be enough for e.g. exploiting some remote 511 vulnerabilities in connectionless protocol server applications. 513 In the second scenario, if "dst" exists, the replies (e.g. TCP SYN 514 ACK, TCP RST, ICMP Echo Reply, input sent to UDP echo service, etc.) 515 are sent to the victim "src", above. All the traces from the 516 original attacker src_v4 have been discarded. These return packets 517 will go through a relay. 519 These attacks are similar to ones shown in [RHHASEC]. 521 5.2.2.1. Comparison to Situation without 6to4 523 The unidirectional spoofing attack exists without 6to4 too, but it 524 requires the attacker is able to spoof IPv6 source addresses. With 525 6to4, one is able to launch this attack without any spoofing at all. 526 A restriction is that the source address cannot be spoofed to belong 527 to the destination site as only non-6to4 addresses can be spoofed 528 (assuming correct implementations). Blindly trusting source address 529 of packets coming from the Internet without other precautions is very 530 bad practise, though -- and this attack would typically be useful 531 only for spoofing destination site -- which is not possible, and can 532 be protected against with egress filtering. 534 The Denial-of-Service attack is also not really new; the only twists 535 come from the fact that traces of an attack are more easily lost and 536 that attacker does not really have to even spoof his IPv4 address to 537 be able to reasonably discreetly launch the attack. 539 However, it can be argued that this DoS attack is not critical 540 because: 542 o 6to4 as an enabling mechanism does not provide any possibility 543 for packet multiplication, attacks are generally 1:1, 544 o victim receives packets as replies from "dst": unless echo 545 service (e.g. UDP port 7) is used, the attacker has reasonably 546 little control on the content of packets; for example, pure "SYN" 547 TCP packets often used for flooding cannot be sent, 548 o attack packets pass through choke point(s), namely (one or more) 549 6to4 relays; in addition to physical limitations, these could 550 implement some form 6to4-site-specific traffic limiting, and 551 o one has to know a valid destination address (however, this is 552 easily guessable or deducible with e.g. an ICMP echo request with 553 a limited Hop Count). 555 The attack can be launched from hosts whose connection is ingress- 556 filtered, too. So, this enables a way to launch attacks which hide 557 the source address even when it was supposed to be prevented (for 558 IPv4). 560 However, often this is not a real factor, as usually the attackers 561 are just zombies and real attackers may not even care if the 562 unspoofed source address is discovered. 564 This is one of the most serious threats. 566 5.3. Threats Related to 6to4 Relays 568 6to4 Relays are also subject to attacks, but usually in a different 569 role than 6to4 Routers; usually Relays' function is the anonymization 570 of the attack and losing trails, not reflection -- as properly 571 implemented relays should be resistant to reflection. 573 6to4 Relays have only one significant security check they must 574 perform for general safety: when decapsulating IPv4 packets, check 575 that 2002:V4ADDR and V4ADDR match. If this is not done, several 576 threats become more serious; in the following, it's assumed that such 577 checks are always done. 579 Also, it is assumed here that the Relay checks that it will not relay 580 packets between 6to4 addresses. In particular, packets decapsulated 581 from 6to4 routers cannot be encapsulated again towards 6to4 routers, 582 as descibed in rules in section 6. It is not clear whether this kind 583 of check is typically implemented. 585 5.3.1. Attacks Against the 6to4 Pseudo-Interface 587 The threats are the same as against 6to4 routers. 589 5.3.2. Spoofing, DoS against IPv6 Nodes 591 If one cannot assume that IPv6 source addresses are ingress-filtered, 592 the same threats as listed in 5.2.2 apply. 594 The difference here is that a native IPv6 node spoofs the source IPv6 595 addresses, and the relay router provides a layer of indirection and 596 loses the trails. 598 5.3.3. Participating in DoS attacks against IPv4 600 An attack specific to 6to4 Relays is similar to 6to4 Routers, but 601 against IPv4; the attacker sends IPv6-native packets with an IPv4 602 address he wants to bomb as the 6to4 destination address, like: 604 src = 3ffe:1122:3344::1 (spoofed or real attacker) 605 dst = 2002:0900:0002::1 (victim) 607 Now the 6to4 relay receives these packets, and encapsulates in IPv4 608 packets that are sent towards 9.0.0.2; the destination may not have a 609 faintest idea of what IPv6 is, but is bombed with packets coming from 610 the relay's IPv4 address, including IPv6 packets as the payload. 612 5.3.3.1. Comparison to Situation without 6to4 614 Slightly different arguments apply; below are reasons why this can be 615 considered not too serious an attack: 617 o 6to4 as an enabling mechanism does not provide any possibility 618 for packet multiplication, attacks are generally 1:1, 619 o victim receives packets as sent by the source; if the victim is 620 an IPv4-only node, it just sees "protocol 41" packets which are 621 not typically dangerous and easily filtered, 622 o 6to4 relay's source IPv4 address is used in packets, and tracing 623 is easier, 624 o source IPv6 address (spoofed or real) is in the packets which may 625 make manual tracing easier, and 626 o attack packets pass through choke point(s), namely (one or more) 627 6to4 relays; in addition to physical limitations, these could 628 implement some form 6to4-site-specific traffic limiting. 630 And as counter-arguments, some more serious aspects of it are: 632 o victim receives packets as sent by the source; if the victim is 633 6to4 node, IPv6 packet can include almost anything; however if 634 IPv6 source addess is not spoofed, this attack is nothing new, 635 o the relays can be chosen by the attacker, so if there are a large 636 number of relays, he can pick ones that are known best suited for 637 the attack (e.g. bad security policy, ones using 192.88.99.1 as 638 source for more difficult tracing, etc.), and 639 o the relay's IPv4 address is used as a source address for these 640 attacks, potentially causing a lot of complaints or other actions 641 as the relay seems to be the source of this "attack". 643 5.3.4. Using Any IPv6 Node for Reflection 645 Any IPv6 node will respond to IPv6 packets destined to the node with 646 source address belonging to 2002::/16. 648 This attack is applicable if: 650 o the relay chosen by the attacker does not check that IPv4 source 651 and 2002::/16 source address match, or 652 o the attacker's IPv6 connection is not ingress-filtered (and it 653 was really a non-6to4 source). 655 The IPv6 source address being forged, the node will participate as an 656 unwilling intermediary to an attack through a 6to4 relay against any 657 IPv4 node (or 6to4 node), like: 659 src = 2002:0900:0002::1 (forged, target of the attack) 660 dst = 3ffe:1122:3344::1 (intermediary node) 662 This is not new: similar attack with any other spoofed source address 663 is possible if ingress filtering is not enabled. The only difference 664 here is that when attacking IPv4 nodes, the relay's IPv4 source 665 address is seen as the immediate source of the attack. Closer 666 inspection (after packet reflection) reveals the IPv6 datagram with 667 (possibly spoofed) 2002::/16 destination address. 669 5.3.4.1. Comparison to Situation without 6to4 671 This attack is a reflected variation of the attack above; the 672 implications are similar to those in section 5.2.2.1: 674 o A non-compliant 6to4 implementation or IPv6 source address 675 spoofing is required, 676 o 6to4 as an enabling mechanism does not provide any possibility 677 for packet multiplication, attacks are generally 1:1, 679 o victim receives packets as replies from "dst": unless echo 680 service (e.g. UDP port 7) is used, the attacker has reasonably 681 little control on the content of packets; for example, pure "SYN" 682 TCP packets often used for flooding cannot be sent, 683 o attack packets pass through choke point(s), namely (one or more) 684 6to4 relays; in addition to physical limitations, these could 685 implement some form 6to4-site-specific traffic limiting, and 686 o the relay's IPv4 address is used as a source address for these 687 attacks, potentially causing a lot of complaints or other actions 688 as the relay seems to be the source of this "attack". 690 5.3.5. IPv4 Local Directed Broadcast Attacks 692 This threat is applicable if the relay does not check whether the 693 IPv4 address it tries to send encapsulated IPv6 packets to is a local 694 broadcast address. This threat is mentioned in [6TO4]. The packet 695 could be sent as follows: 697 src = 3ffe:ffff:5678::aaaa (may be forged) 698 dst = 2002:0900:00ff::bbbb 700 9.0.0.255 is assumed the the relay's broadcast address. After 701 receiving the packet natively, if the relay doesn't check the 702 destination address for subnet broadcast, it would send the 703 encapsulated IP-IP packet to 9.0.0.255. This would be received by 704 all nodes in the subnet, and the responses would be directed to the 705 relay. 707 5.3.5.1. Comparison to Situation without 6to4 709 This is a special form of "directed broadcast" attack which cannot be 710 protected against except by the mentioned check. However, there is a 711 significant difference: the reply packets are sent back to the relay. 712 Therefore only the non-compliant device can suffer from this; the 713 rest of the Internet cannot be affected. 715 5.3.6. Theft of Service 717 The administrators of 6to4 Relay Routers often want to use some 718 policy to limit the use of relay. 720 The policy control is usually done by applying some restrictions in 721 where the routing information for 2002::/16 and/or 192.88.99.0/24 (if 722 [6TO4ANY] is used) will spread. 724 Some users may be able to use the service regardless of these 725 controls using: 727 o configuring the address of the relay using its IPv4 address 728 instead of 192.88.99.1, or 729 o using Routing Header to route IPv6 packets to reach some 6to4 730 Relay (some other routing tricks like neighbors setting static 731 routes are also possible). 733 The former can be protected against using configured access lists in 734 the relay; this is only feasible if the number of IP networks the 735 relay is supposed to serve is relatively low. Another possible way 736 to mitigate this is to filter out arriving tunneled packets with 737 protocol 41 (IPv6) which do not have the the 192.88.99.1 as the 738 destination address. 740 The latter has similar issues: the IPv6 source address could be 741 checked so the packets to the relay only come from the valid IPv6 742 addresses which are able to reach the relay anyway. As Routing 743 Header is not specific to 6to4, the main things one could do here 744 with it would be to select the relay; some generic threats about 745 Routing Header use are described in [RHHASEC]. 747 Of these, except in really restricted scenarios, only the first may 748 be of some interest, and the mitigating the problem by access list is 749 rather straightforward. 751 As this threat does not have implications on other than the 752 organization providing Relay, it is not further analysed. 754 5.3.7. Relay Operators Seen as Source of Abuse 756 There are several attacks which use 6to4 Relays to anonymize the 757 traffic; this often results in packets being tunneled from the relay 758 to a supposedly-6to4 site. 760 However, as was already pointed out in sections 5.3.3 and 5.3.4, the 761 IPv4 source address used by the relay could, cursorily looking, be 762 seen as the source of these "protocol-41" attacks. 764 This could cause a number of concerns for the operators deploying 765 6to4 relay service, for example: 767 o getting contacted a lot (via email, phone, fax or lawyers) on 768 suspected "abuse", 769 o getting the whole IPv4 address range rejected as a source of 770 abuse or spam, causing outage to other operations as well, or 771 o causing the whole IPv4 address range to be to be blacklisted in 772 some "spammer databases", if the relay would be used for those 773 purposes. 775 This problem can be avoided (or really, "made someone else's 776 problem") by using the 6to4 anycast address in 192.88.99.0/24 as the 777 source address: blacklisting or rejecting that should not cause 778 problems to the other operations. Further, when someone is filing 779 complaints to the owner of 192.88.99.0/24, they notice multiple 780 records and see a pointer to [6TO4ANY], and may learn that the 6to4 781 relay is in fact innocent. Of course, this could result in these 782 reports going to the closest anycast 6to4 relay as well, which in 783 fact had nothing to do with the incident. 785 5.4. Possible Threat Mitigation Methods 787 This section gives a rough idea of mechanisms thought to mitigate the 788 threats. 790 5.4.1. 6to4 Decapsulation Cache 792 6to4 decapsulators (routers, relays) could keep a least recently used 793 (LRU) header cache of possibly a few hundred entries of recently seen 794 packets for tracing purposes. 796 The problem here is how that kind of data could be extracted -- by 797 third parties that need it -- in timely fashion. Many 798 implementations are, of course, already able to perform something 799 like this by e.g. manually set logging access lists. 801 5.4.2. Rate-limiting at 6to4 Routers/Relays 803 TBD. 805 5.4.3. An Application of iTrace Model 807 6to4 decapsulators (or some of them) could send out some specific 808 packets probabilitically as a way ensure that reflectors cannot be 809 used to lose trails of an attack. This could either be a 810 simplification or an extension of e.g. [ITRACE] model, depending on 811 how fast its specification goes. 813 The most important place for this would be at 6to4 Routers, to 814 counter the reflection attack descibed in 5.2.2. If so, the check 815 could be placed at the decapsulation phase where packets have a 6to4 816 destination address but the source is non-6to4. 818 The iTrace working group has been concluded due to decreased 819 applicability of the work. The documents may move forward as 820 individual submissions. 822 5.5. Summary 824 It would be useful to try to characterize the different threats by 825 comparing the severity of the threat to: 827 1. IPv4 networks today, where in many cases (even most), source 828 address spoofing is possible and there are no easy ways to 829 trace attacks 831 2. Hypothetical IPv4 networks -- the case if ingress filtering 832 would be deployed everywhere 834 3. Hypothetical IPv6 networks -- the case if ingress filtering 835 would be deployed everywhere in current and future IPv6 836 networks 838 However, this would be very difficult as it is not easy to assign 839 severity values to all the features 6to4 adds and try to decide 840 whether it's more serious or not. 842 5.5.1. Summary of the Threats 844 Below is the summary of the threats discussed above. Threat in 5.1 845 was merged with 5.2.2 as the effects are the same but from a 846 different perspective. 848 +----+-----+--------------------+-------+-------+---+---+----+ 849 |Type| Sec | Characterization | Using |Against|Fix|I-F|Comp| 850 +----+-----+--------------------+-------+-------+---+---+----+ 851 |Othr|5.2.1|Pseudo-Interface |Rtr/Rly|itself |yes|N/A| 3 | 852 |Othr|5.3.5|Local Direct. Bcast |Rly |itself |yes|N/A| 3 | 853 |Othr|5.3.6|Theft of Service |Rly |itself |yes|N/A| - | 854 |Othr|5.3.7|Relay Seems to Abuse|Rly |any v4 | ? | ? | - | 855 +----+-----+--------------------+-------+-------+---+---+----+ 856 |Spf |5.2.2|Relay Spoofing |Rtr |ownsite| y?| - |same| 857 +----+-----+--------------------+-------+-------+---+---+----+ 858 |Dir |5.3.3|DoS against IPv4 |Rly |any v4 | ? | 6 |1,2 | 859 +----+-----+--------------------+-------+-------+---+---+----+ 860 |Refl|5.2.2|Refl. off any 6to4 |Rtr/Any|non6to4| ? | - | 2 | 861 |Refl|5.3.2|Refl. off any 6to4 |R*/Any |non6to4| ? | 6 | 2 | 862 |Refl|5.3.4|Refl. off any IPv6 |Rly/Any|any v4 |1/2|4+6|1,2 | 863 +----+-----+--------------------+-------+-------+---+---+----+ 865 The table is sorted by threat type. Possibilities are spoofing, 866 direct attack, attack by reflection (ie. final attack consists of 867 some response packets) and other. 869 Threats when realize (ab)use some IPv6 nodes: possibilities are 870 either 6to4 Routers (Rtr), 6to4 Relays (Rly) or any IPv6 nodes or any 871 6to4 nodes (Any). "R*" means that both Relays and Routers are used. 873 The final target of the attack is descibed in "Against"; it can be 874 node(s) or network itself, the site itself which could prevent the 875 attack, any IPv4 node or any non-6to4 IPv6 node (non6to4). 877 If a fix for the problem is apparent, it is mentioned in the Fix 878 field. 880 If it can be assumed that either complete Internet-wide IPv4 or IPv6 881 ingress filtering would (more or less) fix or significantly alleviate 882 the problem, the fixing version of ingress filtering is noted in I-F 883 column. The notable case is 5.3.4 where both v4/v6 ingress filtering 884 is needed -- but if the half of the readily-available fix is done, 885 IPv6 ingress filtering is enough. The other notable case is threat 886 5.2.2, which cannot be disabled by ingress filtering. 888 The last field "Comp" tries to compare the threats to their IPv4 889 equivalents, using: 890 1. cannot control packets significantly, ie. a weak attack, 891 2. can be mitigated significantly by adding some kind of tracing, 892 or 893 3. some new form of attack. 895 5.5.2. Generic Notes about Threats 897 Note: TBD. 899 o correct and fully-implemented base security features are a pre- 900 requisite for reasonably safe operation, 901 o being able to spoof IPv4 or IPv6 packets enables one to launch 902 similar or more powerful attacks even currently, 903 o some 6to4 attacks provide an additional layer of indirection, 904 which may or may not be useful, 905 o 6to4 as an enabling mechanism does not provide any possibility 906 for packet multiplication which would affect global Internet, 907 attacks are generally 1:1, 908 o typically the reflected packets have restricted content, limiting 909 the usability in an attack, 910 o attacks typically have either 6to4 relay router's address or some 911 other information which could be used in manual tracing, 912 o attack packets pass through choke point(s), namely (one or more) 913 6to4 relays; in addition to physical limitations, these could 914 implement some form 6to4-site-specific traffic limiting, 916 o the relay's IPv4 address is often used as a source address for 917 these attacks, potentially causing a lot of complaints or other 918 actions as the relay seems to be the source of this "attack", and 919 o attacks could in theory be traceable using an extension of 920 [ITRACE] or [REVITRACE], but as those haven't been specified, 921 much less used, the point seems rather academic yet. 923 When considering motives for DoS attacks and how to protect against 924 them (and considering the cost, and whether the protection actually 925 buys you anything), the following should not be forgotten: 927 o IPv4 and IPv6 ingress filtering are not likely to be commonplace 928 for a long time; until it is, you cannot really depend on it, 929 o the real attacker (launching a DoS or DDoS) may not really even 930 care whether some zombie nodes get found out, 931 o techniques to trace DoS attacks are still in infancy (or not even 932 there) yet; due to time anything takes to get deployed, it is not 933 clear whether tracing mechanisms even for basic DoS attack 934 mechanisms would get reasonably widely deployed before it was 935 time to (more or less) retire 6to4, and 936 o DoS attacks are something that, in practise, operational people 937 have to be able to deal with anyway. 939 6. Implementing Proper Security Checks in 6to4 941 In this section, several ways to implement the security checks 942 required or implied by [6TO4] or augmented by this specification are 943 described. These do not, in general, protech against the majority of 944 the threats listed above in the threat analysis. They're just 945 prerequisites for a relatively safe and simple 6to4 implementation. 947 Two different sets of rules are listed, "generic", and "simplified". 948 The former addresses the required rules in the generic form; the 949 latter simplifies them using a number number of assumptions to 950 increase the readability. 952 6.1. Generic Approach 954 6.1.1. Encapsulating IPv6 into IPv4 956 src and dst MUST pass ipv6-sanity checks, else drop (defined below) 957 if src=2002 958 src MUST match src_v4 959 /* the scenario: 4.1. case 1. or 2. */ 960 if dst=2002 961 dst_v4 SHOULD NOT be assigned to the router (avoid misconfigurations) 962 /* the scenario: 4.1. case 1. */ 963 fi 965 elif dst=2002 966 dst_v4 MAY have to match one of ipv4 equiv. of 6to4 prefixes masked by a 967 user-specified prefix length (restricting who can use the relay) 968 /* the scenario: 4.1. case 3. */ 969 else 970 drop 971 /* the scenario: we somehow got a native-native ipv6 packet */ 972 fi 973 accept 975 6.1.2. Decapsulating IPv4 into IPv6 977 src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop (defined below) 978 src and dst MUST pass ipv6-sanity checks, else drop (defined below) 979 if dst=2002 980 dst MUST match dst_v4 981 /* the scenario: 4.2. case 1. or 2. */ 982 if src=2002 983 src MUST match src_v4 984 dst_v4 SHOULD be assigned to the router (see notes below) 985 /* the scenario: 4.2. case 1. */ 986 fi 987 elif src=2002 988 src MUST match src_v4 989 dst_v4 SHOULD be assigned to the router (see notes below) 990 src_v4 MAY have to match one of ipv4 equiv. of 6to4 prefixes masked by a 991 user-specified prefix length (restricting who can use the relay) 992 /* the scenario: 4.2. case 3. */ 993 else 994 drop 995 /* the scenario: we somehow got a native-native ipv6 packet */ 996 fi 997 accept 999 6.1.3. IPv4 and IPv6 Sanity Checks 1001 6.1.3.1. IPv4 1003 IPv4 address MUST be a global unicast address, as required by the 1004 6to4 specification. The disallowed addresses include those defined 1005 in [RFC1812], and others widely used and known not to be global. 1006 These are: 1008 o 0.0.0.0/8 (the system has no address assigned yet) 1009 o 10.0.0.0/8 (private) 1010 o 127.0.0.0/8 (loopback) 1011 o 172.16.0.0/12 (private) 1012 o 192.168.0.0/16 (private) 1013 o 169.254.0.0/16 (IANA Assigned DHCP link-local) 1014 o 224.0.0.0/4 (multicast) 1015 o 255.0.0.0/8 (broadcast) 1017 In addition it MUST be checked that the address is not any of the 1018 system's broadcast addresses. This is especially important if the 1019 implementation is made so that it can: 1021 o receive and process encapsulated IPv4 packets arriving at its 1022 broadcast addresses, or 1023 o send encapsulated IPv4 packets to one of its broadcast addresses. 1025 6.1.3.2. IPv6 1027 IPv6 address MUST NOT be: 1028 o 0::/16 (compatible, mapped addresses, loopback, unspecified, 1029 ...) 1030 o fe80::/10 (link-local) 1031 o fec0::/10 (site-local) 1032 o ff02::/16 (link-local multicast) 1034 Other multicast could also be considered for filtering. 1036 In addition, it MUST be checked that equivalent 2002:V4ADDR checks, 1037 where V4ADDR is any of the above IPv4 addresses, will not be passed. 1039 6.1.3.3. Optional Ingress Filtering 1041 In addition, the implementation may perform some form of ingress 1042 filtering (e.g. Unicast Reverse Path Forwarding checks). For 1043 example, if the 6to4 Router has multiple interfaces, of which some 1044 are "internal", receiving either IPv4 or IPv6 packets with source 1045 address belonging to any of these internal networks from the Internet 1046 might be disallowed. 1048 If these checks are implemented, it is RECOMMENDED that they default 1049 to disabled. 1051 6.1.3.4. Notes About the Checks 1053 The rule 'dst_v4 SHOULD be assigned to the router' is not needed if 1054 the implementation is made in such a way that it only accepts and 1055 processes encapsulated IPv4 packets arriving on unicast IPv4 1056 addresses, and that if destination address is known to be a local 1057 broadcast address, not try to encapsulate and send packets to it (see 1058 section 5.3.5 about this threat). 1060 Some checks, especially the IPv4/IPv6 Sanity Checks, could be at 1061 least partially implementable with system-level access lists, if one 1062 would like to avoid placing too many restrictions in the 6to4 1063 implementation itself. This depends on how many hooks for the access 1064 lists are in place. In practice it seems like this could not be done 1065 effectively enough unless the access list mechanism is able to parse 1066 the encapsulated packets within IP-IP. 1068 6.2. Simplified Approach 1070 This makes some assumptions about the implementation as pointed above 1071 to simplify the above rules. 1073 6.2.1. Encapsulating IPv6 into IPv4 1075 src and dst MUST pass ipv6-sanity checks, else drop 1076 if src=2002 1077 src MUST match src_v4 1078 elif dst=2002 1079 (accept) 1080 else 1081 drop 1082 fi 1083 accept 1085 6.2.2. Decapsulating IPv4 into IPv6 1087 src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop 1088 src and dst MUST pass ipv6-sanity checks, else drop 1089 if dst=2002 1090 dst MUST match dst_v4 1091 if src=2002 1092 src MUST match src_v4 1093 fi 1094 elif src=2002 1095 src MUST match src_v4 1096 else 1097 drop 1098 fi 1099 accept 1101 7. Issues 1103 This section tries to give an overview of some of the problems 6to4 1104 implementations are faced with, and which kind of generic problems 1105 the 6to4 users could come up with. 1107 7.1. Implementation Considerations with Automatic Tunnels 1109 There is a problem with multiple transition mechanisms if strict 1110 security checks are implemented. This may vary a bit from 1111 implementation to implementation. 1113 Consider three mechanisms using automatic tunneling: 6to4, ISATAP 1114 [ISATAP] and Automatic Tunneling using Compatible Addresses [MECH]. 1115 All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with, 1116 more or less, a pseudo-interface. 1118 When a router, which has any two of these enabled, receives an IPv4 1119 encapsulated IPv6 packet: 1121 src_v4 = 10.0.0.1 1122 dst_v4 = 20.20.20.20 1123 src = 3ffe:ffff::1 1124 dst = 2002:1010:1010::2 1126 what can it do? How should it decide which transition mechanism this 1127 belongs to; there is no "transition mechanism number" in IPv6 or IPv4 1128 header to signify this. (This can also be viewed as a flexibility 1129 benefit.) 1131 Without any kind of security checks (in any of implemented methods) 1132 these often just "work" as the mechanisms aren't differentiated but 1133 handled in "one big lump". 1135 Configured tunneling [MECH] does not suffer from this as it is point- 1136 to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses 1137 it can be deduced which logical tunnel interface is in the question. 1139 Solutions for this include not using more than one automatic 1140 tunneling mechanisms in the same system or binding different 1141 mechanisms to different IPv4 addresses. 1143 7.2. Reduced Flexibility 1145 There is a worry about too strict rules limiting the (future) 1146 flexibility of 6to4. If later, for some reason, one would want to 1147 introduce new revolutionary ways to use 6to4, strict checking in all 1148 relevant nodes might prevent it, as new updated version would have to 1149 be deployed everywhere before the new method could be used. 1151 On the other hand, one could argue that 6to4 has always been intended 1152 as an intermediate mechanism, and that future flexibility should not 1153 be critical. However, it is difficult to predict how long the 1154 intermediate period will be. 1156 7.3. Anyone Pretending to Be a Relay Router 1158 6to4 Routers receive traffic from non-6to4 ("native") sources via 1159 6to4 Relays. 6to4 Routers have no way of matching IPv4 source 1160 address of the relay with non-6to4 IPv6 address of the source. In 1161 consequence, anyone can spoof any non-6to4 IPv6 address he wants by 1162 sending traffic, encapsulated, directly to 6to4 Routers. This is 1163 analyzed in more detail in the Threat Analysis section, above. 1165 Of course, as the source IPv4 address may be logged, many may spoof 1166 their IPv4 source address, but the ability to do so is not be 1167 required: it is unlikely that source IPv4 (but rather, the spoofed 1168 IPv6 address) will be logged anywhere -- this would be equivalent to 1169 logging the MAC-address of IP packets. 1171 Unfortunately, this problem is very difficult to solve properly. 1172 There have been three rough ideas: 1174 o Every 6to4 Relay must configure and use "192.88.99.1" as the 1175 source address of packets that are encapsulated towards 6to4 1176 Routers. 1178 o Every 6to4 Relay must participate in an eBGP multi-hop peering 1179 mesh (which can be hierarchical): there more specific routes will 1180 be advertised. 1182 o The 6to4 usage model would be turned upside-down, and the 1183 deployment of 6to4 would be have to be borne by native IPv6 1184 users. 1186 It should be noted that if IPv6 operators do not implement ingress 1187 filtering for IPv6, so that spoofing IPv6 is not more difficult than 1188 spoofing IPv4, these problems have only little impact on the overall 1189 security of 6to4 nodes. 1191 The first has since then been rejected: the difference in the 1192 difficulty of spoofing an address and spoofing it to be 192.88.99.1 1193 does not seem to justify the mechanism. A tentative analysis for the 1194 second and third is given below. 1196 7.3.1. Limited Distribution of More Specific Routes 1198 If 6to4 prefixes more specific than 2002::/16 could be advertised, 1199 the traffic model between native<->6to4 and 6to4<-> could be changed 1200 so that only one Relay would always be used, most often the one 1201 closest to the 6to4 Router. 1203 This model was rejected in the base specification, as IPv6 routing 1204 table was not to be polluted by 6to4 prefixes derived of IPv4 1205 prefixes. 1207 However, the problem could be avoided with some effort: creating a 1208 separate, possibly hierarchical based on IPv6 connections, peering 1209 mesh for 6to4 Relay routers. This could be done by forming eBGP 1210 [BGP] multi-hop peerings between Relays, and advertising more 1211 specific routes (e.g. the same superblocks of IPv4 addresses one 1212 expects to service) to all the other Routers. 1214 In that way, the global routing table would not be impacted at all. 1216 This seems to have at least three potential issues: 1218 o Every Relay should be part of this (if one wants to have some 1219 extra safety that the addresses haven't been spoofed), 1221 o The route from a native source takes the path to the first Relay, 1222 and there (possibly through other Relays) to the last Relay to 1223 tunnel the packet to the 6to4 Router; this adds at least some 1224 latency, and 1226 o The mechanism of redistributing IPv4 6to4 client addresses to 1227 other relays as 6to4 prefixes needs work. 1229 Of these, only the last requires more discussion. It could be argued 1230 that this advertising should either be manually configured once (ie. 1231 relatively static prefixes, or generated from IPv4 route-objects in 1232 RADB etc.) or generated automatically (e.g. when a 6to4 Router first 1233 sends a "triggering" packet through the Relay). Of course, this data 1234 could even be derived in some form from the IPv4 routing tables. 1235 Further analysis on this is TBD if necessary. 1237 This method seems to be the only one where strong cryptography-based 1238 mechanisms to be sure about the 6to4 Router - 6to4 Relay 1239 -relationship could be doable; otherwise, some sort of infrastructure 1240 (e.g. small-scale PKI) would have to be established which would have 1241 to include all the possible 6to4 Relays in the Internet. 1243 7.3.2. A Different Model for 6to4 Deployment 1245 It could be possible to turn the deployment assumptions of 6to4 1246 around a bit to eliminate some threats caused by untrusted 6to4 1247 relays. That is: 1249 o Every dual-stack site (or even ISP) would be required to have 1250 their own 6to4 relay. That is, there would not be third-party 1251 relays, and the 2002::/16 route would not need to be advertised 1252 globally, and 1254 o The security implications of 6to4 use could be pushed back to the 1255 level of trust inside the site or ISP (or their acceptable use 1256 policies) -- this is something that the sites and ISPs should be 1257 familiar with already. 1259 However, this has a number of problems: 1261 This model would shift the majority of burden of supporting 6to4 to 1262 IPv6 sites which don't employ or use 6to4 at all, e.g. "those who 1263 deploy proper native dual-stack". It could be argued that the pain 1264 should be borne by 6to4 users, not the others. 1266 The main advantage of 6to4 is easy deployment and free relays. This 1267 would require that everyone the 6to4 sites wish to communicate with 1268 implement these measures. 1270 The model would not fix the "relay spoofing problem", only restrict 1271 it a bit, unless everybody deployed also 6to4 addresses on the nodes 1272 (alongside with native addresses, if necessary), which in turn would 1273 change 6to4 to operate without relays completely. 1275 To summarize, it seems like 6to4 cannot be salvaged: the decision is 1276 either to embrace it or trash it. 1278 8. Security Considerations 1280 This draft discusses security considerations. 1282 Even if proper checks are implemented, there are significant security 1283 threats ranging from DoS proxy attacks to spoofing and attacks 1284 against 6to4 pseudo-interface. These threats are analyzed in section 1285 5. 1287 As can be seen, there are mainly three classes of potential problem 1288 sources: 1290 o 6to4 routers not being able to identify whether relays are 1291 legitimate 1292 o wrong or impartially implemented 6to4 Routers 1293 o relays performing packet laundering 1295 The first is the toughest problem, still under research. The second 1296 can be fixed by ensuring the correctness of implementations; this is 1297 important. The third is also a difficult, but a fairly restricted 1298 problem as relays are limited in number. 1300 These are analyzed in detail in Threat Analysis section, above. 1302 9. Acknowledgements 1304 Some issues were first brought up by Itojun Hagino in [TRANSAB], and 1305 Alain Durand introduced one specific problem at IETF51 in August 2001 1306 (though there was some discussion on the list prior to that); these 1307 gave the author the push to start looking into the details of 1308 securing 6to4. 1310 Alexey Kuznetsov brought up the implementation problem with IPv6 1311 martian checks. Christian Huitema formulated the rules that rely on 1312 Relays using only anycast. Keith Moore brought up the point about 1313 reduced flexibility. Brian Carpenter, Tony Hain and Vladislav 1314 Yasevich are acknowledged for lengthy discussions. Alain Durand 1315 reminded of relay spoofing problems. Brian Carpenter reminded of the 1316 BGP-based 6to4 router model. Christian Huitema gave a push to a more 1317 complete threat analysis. Itojun Hagino spelled out the operators' 1318 fears about 6to4 relay abuse. Rob Austein brought up the idea of a 1319 different 6to4 deployment model. 1321 In the latter phase, especially discussions with Christian Huitema, 1322 Brian Carpenter and Alain Durand were helpful when improving the 1323 document. 1325 David Malone and [your name could be here] gave feedback on the 1326 document. 1328 10. References 1330 10.1. Normative References 1332 [6TO4] Carpenter, B. and Moore K., "Connection of IPv6 Domains 1333 via IPv4 Clouds", RFC 3056, February 2001. 1335 [6TO4ANY] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1336 RFC 3068, June 2001. 1338 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G. 1339 and E. Lear, "Address Allocation for Private Internets", 1340 BCP 5, RFC 1918, February 1996. 1342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1343 Requirement Levels", BCP 14, RFC 2119, March 1997. 1345 10.2. Informative References 1347 [ADDRSEL] Draves, R., "Default Address Selection for IPv6", 1348 RFC 3484, February 2003. 1350 [BGP] Rekhter, Y., Li, T., "A Border Gateway Protocol 4", 1351 RFC1771, March 1995. 1353 [IPIP] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1354 1995. 1356 [ISATAP] Templin, F. et al, "Intra-Site Automatic Tunnel 1357 Addressing Protocol (ISATAP)", draft-ietf-ngtrans- 1358 isatap-15.txt (work-in-progress), August 2003. 1360 [ITRACE] Bellovin, S., Leech, M., Taylor, T., "ICMP Traceback 1361 Messages", draft-ietf-itrace-04.txt (work in progress), 1362 February 2003. 1364 [MECH] Gilligan, R., and Nordmark, E. "Transition Mechanisms for 1365 IPv6 Hosts and Routers", RFC 2893, August 2000. 1367 [REVITRACE] Barros, C., "A Proposal for ICMP Traceback Messages", 1368 http://www.research.att.com/lists/ietf-itrace/2000/09/ 1369 msg00044.html. 1371 [RHHASEC] Savola, P., "Security of IPv6 Routing Header and Home 1372 Address Options", draft-savola-ipv6-rh-ha-security-03.txt 1373 (work-in-progress), December 2002. 1375 [SEND] Nikander, P. (Ed.), "IPv6 Neighbor Discovery trust 1376 models and threats", draft-ietf-send-psreq-03.txt 1377 (work-in-progress), April 2003. 1379 [TRANSAB] Hagino, J., "Possible abuse against IPv6 transition 1380 technologies", draft-itojun-ipv6-transition-abuse-01.txt 1381 (expired, work-in-progress), July 2000. 1383 Author's Address 1385 Pekka Savola 1386 CSC/FUNET 1387 Espoo, Finland 1388 EMail: psavola@funet.fi 1390 A. Some Trivial Attack Scenarios Outlined 1392 Here, a few trivial attack scenarios are outlined -- ones that are 1393 prevented by implementing checks listed in [6TO4] or in section 6. 1395 When two 6to4 Routers send traffic to each others' domains, packet 1396 sent by RA to RB is like (note: addresses from 8.0.0.0/24 are just 1397 examples of global IPv4 addresses): 1399 src = 2002:0800:0001::aaaa 1400 dst = 2002:0800:0002::bbbb 1401 src_v4 = 8.0.0.1 (added when encapsulated to IPv4) 1402 dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) 1404 When the packet is received by IPv4 stack on RB, it will be 1405 decapsulated so that only src and dst remain, as originally sent by 1406 RA: 1408 src = 2002:0800:0001::aaaa 1409 dst = 2002:0800:0002::bbbb 1411 As every other node is just one hop away (IPv6-wise) and the link- 1412 layer (IPv4) addresses are lost, this may open a lot of possibilities 1413 for misuse. 1415 As an example, unidirectional IPv6 spoofing is made trivial because 1416 nobody can check (without delving into IP-IP packets) whether the 1417 encapsulated IPv6 addresses were authentic (With native IPv6, this 1418 can be done by e.g. RPF-like mechanisms or access lists in upstream 1419 routers). 1421 src = 2002:1234:5678::aaaa (forged) 1422 dst = 2002:0800:0002::bbbb 1423 src_v4 = 8.0.0.1 (added when encapsulated to IPv4) 1424 dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) 1426 A similar attack with "src" being native address is possible even 1427 with the security checks, by having the sender node pretend to be a 1428 6to4 Relay router. 1430 More worries come in to the picture if e.g. 1432 src = ::ffff:[some trusted IPv4 in a private network] 1433 src/dst = ::ffff:127.0.0.1 1434 src/dst = ::1 1435 src/dst = ... 1437 Some implementations might have been careful enough to have designed 1438 the stack to as to avoid the incoming (or reply) packets going to 1439 IPv4 packet processing through special addresses (e.g. IPv4-mapped 1440 addresses), but who can say for all ...