idnits 2.17.1 draft-savola-ngtrans-6to4-security-01.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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** The abstract seems to contain references ([6TO4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 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 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: IPv6 address MUST not be: o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...) o fe80::/10 (link-local) o fec0::/10 (site-local) o ff02::/16 (link-local multicast) -- 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 (February 2002) is 8100 days in the past. Is this intentional? 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 369, but not defined == Unused Reference: 'RFC1918' is defined on line 596, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3068 (ref. '6TO4ANY') (Obsoleted by RFC 7526) ** Obsolete normative reference: RFC 2893 (ref. 'MECH') (Obsoleted by RFC 4213) ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. 'IPIP') == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-ngtrans-isatap (ref. 'ISATAP') -- No information found for draft-kempf-ipng-netaccess - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NETACCESS' Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet Draft CSC/FUNET 4 Expiration Date: August 2002 5 February 2002 7 Security Considerations for 6to4 9 draft-savola-ngtrans-6to4-security-01.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 [6TO4] uses automatic IPv6-over-IPv4 35 tunneling to interconnect IPv6 networks. The architecture includes 36 Relay Routers and Routers, which accept and decapsulate IPv4 traffic 37 from anywhere. There aren't many constraints on the embedded IPv6 38 packets, or where IPv4 traffic will be automatically tunneled to. 39 These could enable one to go around access controls, and more likely, 40 being able to perform proxy Denial of Service attacks using Relays as 41 reflectors. This document discusses these issues in more detail and 42 tries to suggest enhancements to alleviate the problems. 44 Table of Contents 46 1. Introduction ............................................... 3 47 2. Different 6to4 Forwarding Scenarios ........................ 3 48 2.1. From 6to4 to 6to4 ...................................... 4 49 2.2. From Native to 6to4 .................................... 4 50 2.3. From 6to4 to Native .................................... 5 51 3. Some Functionalities of 6to4 ............................... 5 52 3.1. Functions of Different 6to4 Network Components ......... 5 53 3.2. Non-functions of Different 6to4 Network Components ..... 7 54 4. Special Processing of 6to4 Packets ......................... 7 55 4.1. Encapsulating IPv6 Packets into IPv4 ................... 7 56 4.2. Decapsulating IPv4 Packets into IPv6 ................... 8 57 5. Solutions .................................................. 8 58 5.1. Generic Approach ....................................... 8 59 5.1.1. Encapsulating IPv6 into IPv4 ....................... 8 60 5.1.2. Decapsulating IPv4 into IPv6 ....................... 8 61 5.1.3. IPv4 and IPv6 Sanity Checks ........................ 9 62 5.1.3.1. IPv4 ........................................... 9 63 5.1.3.2. IPv6 ........................................... 9 64 5.1.3.3. Optional Ingress Filtering ..................... 10 65 5.1.3.4. Notes About the Checks ......................... 10 66 5.2. Simplified Approach .................................... 10 67 5.2.1. Encapsulating IPv6 into IPv4 ....................... 10 68 5.2.2. Decapsulating IPv4 into IPv6 ....................... 11 69 5.3. All Relays Must Be Anycast ............................. 11 70 6. Problems ................................................... 12 71 6.1. Implementation Considerations with Automatic Tunnels ... 12 72 6.2. Reduced Flexibility .................................... 12 73 7. Security Considerations .................................... 13 74 8. Acknowledgements ........................................... 14 75 9. References ................................................. 14 76 Author's Address ............................................... 14 77 A. Some Attack Scenarios Outlined ............................. 15 78 A.1. IPv6 Spoofing and Access Control Avoidance ............. 16 79 A.2. IPv4 Local Directed Broadcast Attacks .................. 16 80 A.3. DoS Reflector .......................................... 16 81 A.4. Remote Net-access Threats .............................. 17 83 1. Introduction 85 The IPv6 interim mechanism "6to4" [6TO4] specifies automatic 86 IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds without 87 explicit tunnels by embedding the tunnel IPv4 address in the IPv6 88 6to4 prefix. 90 One challenge with this mechanism is that all 6to4 routers must 91 accept and decapsulate IPv4 packets from every other 6to4 router; 92 there are no strict constraints on what the IPv6 packet may contain, 93 which implies a trust relationship. 95 Another, bigger challenge is that to interconnect native IPv6 96 networks and 6to4 clouds, relay routers are used as bridges between 97 these two clouds. Relay routers can be tricked by malicious parties 98 to send IPv4, or IPv6, traffic anywhere the attacker wants. With 99 source address spoofing, this could be called traffic "laundering" or 100 a "proxy" denial-of-service attack. 102 The 6to4 specification outlined quite a few security considerations, 103 but it has been shown that in practice some of these have been 104 difficult to get implemented due to their abstract nature. 106 This draft analyses the 6to4 security issues in more detail and 107 outlines some enhancements and caveats. 109 Sections 2-4 are more or less introductory in nature, rehashing how 110 6to4 should be used today based on the 6to4 specification, so that it 111 is easier to understand how security could be affected. 113 Appendix A outlines a few possible attack scenarios. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. Different 6to4 Forwarding Scenarios 121 It should be noted that when communicating between 6to4 and native 122 domains, the relays that will be used in the two directions are very 123 likely different; routing is highly asymmetric. Because of this, it 124 is not feasible to limit relays you accept traffic from with e.g. 125 access lists. 127 2.1. From 6to4 to 6to4 129 6to4 domains always exchange 6to4 traffic directly via IPv4 130 tunneling; the endpoint address V4ADDR is derived from 6to4 prefix 131 2002:V4ADDR. 133 .--------. _----_ .--------. 134 | 6to4 | _( IPv4 )_ | 6to4 | 135 | Router | <====> ( Internet ) <===> | Router | 136 '--------' (_ _) '--------' 137 ^ '----' ^ 138 | Direct tunneling over IPv4 | 139 V V 140 .--------. .-------. 141 | 6to4 | | 6to4 | 142 | Client | | Client | 143 '--------' '--------' 145 It is required that every 6to4 router considers every other 6to4 146 router it wants to talk to to be "on-link" (with IPv4 as the link- 147 layer). If this is restricted by increasing the prefix length from 148 2002::/16, some traffic will be sent to the 6to4 Relay Router, which 149 would forward it to other 6to4 Routers. However, if the original 150 destination does not have equally long prefix, the traffic it tries 151 to send back will be tunneled directly, and will be dropped. 153 Therefore, the restricted scenario is not globally workable and will 154 not be considered here. 156 2.2. From Native to 6to4 158 Native domains send traffic to 6to4 address 2002:V4ADDR, and it will 159 be routed to the topologically nearest, advertising 6to4 Relay 160 Router. Relay router will tunnel the traffic over IPv4 to the 161 corresponding IPv4 address V4ADDR. (Note that IPv4 address 9.0.0.1 162 here is just an example of a global IPv4 address.) 163 2002::/16 Closest to 'Native Client' 164 .--------. _----_ .------------. .--------. 165 | Native | _( IPv6 )_ | 6to4 Relay | Tunneled | 6to4 | 166 | Client | -> ( Internet ) --> | Router | =========> | Router | 167 '--------' (_ _) '------------' 9.0.0.1 '--------' 168 '----' dst=2002:0900:0000::1 | 169 V 170 .-------. 171 | 6to4 | 172 | Client | 173 '--------' 175 2.3. From 6to4 to Native 177 6to4 domains send traffic to native domains by tunneling it over IPv4 178 to their configured 6to4 Relay Router, or the closest found using 179 6to4 IPv4 Anycast [6TO4ANY]. The relay will decapsulate the packet 180 and forward it to native IPv6 Internet using normal routing table and 181 mechanisms. 183 Configured/found by IPv4 Anycast 184 .--------. _----_ .------------. .--------. 185 | Native | _( IPv6 )_ | 6to4 Relay | Tunneled | 6to4 | 186 | Client | <- ( Internet ) <-- | Router | <========= | Router | 187 '--------' (_ _) '------------' 192.88.99.1'--------' 188 '----' (or configured) ^ 189 dst=3ffe:ffff::1 | 190 .-------. 191 | 6to4 | 192 | Client | 193 '--------' 195 3. Some Functionalities of 6to4 197 3.1. Functions of Different 6to4 Network Components 199 o Non-6to4 (Native) Node 201 If native IPv6 nodes want to communicate with 6to4 nodes, 202 they send the traffic along normally. The traffic will 203 reach the topologically closest, advertising 6to4 Relay 204 Router, and will be tunneled to the destination 6to4 Router, 205 which will pass it to the 6to4 node via normal forwarding 206 process. 208 o 6to4 Host 210 A host, usually autoconfigured and has an address from a 211 6to4 prefix, but doesn't have a 6to4 pseudo-interface. It 212 doesn't need to know anything about 6to4, and it acts like a 213 normal IPv6 Host in every manner. Note that 6to4 Hosts can 214 also be 6to4 Routers in some scenarios, but then 6to4 Router 215 functionalities, below, apply. 217 o 6to4 Router 219 Acts on the border of a 6to4 domain. It does not have a 220 native, global IPv6 address. More specifically: 222 - provide "native-like" IPv6 connectivity to local clients 223 and routers 224 - if packets are sent to foreign 6to4 addresses, tunnel 225 them to the destination 6to4 router using IPv4 226 - if packets are sent to locally configured 6to4 227 addresses, forward them normally 228 - if packets are sent to non-6to4 addresses, tunnel them 229 to the configured/closest-by-anycast 6to4 Relay Router, 230 which will pass them on 231 - if packets are received from 6to4 addresses, decapsulate 232 the IPv4 packets received from 6to4 routers 233 - if packets are received from non-6to4 addresses, 234 decapsulate the IPv4 packets received from 6to4 Relay 235 Router closest to the source. 237 o 6to4 Relay Router 239 Acts as a relay between all 6to4 domains and native IPv6; 240 more specifically: 242 - advertises the reachability of the 2002::/16 prefix to 243 native IPv6 routing, thus receiving traffic to all 6to4 244 addresses from closest native IPv6 nodes 245 - (if implements RFC3068) advertise the reachability of 246 IPv4 '6to4 Relay anycast prefix' (192.88.99.0/24) to 247 IPv4 routing, thus receiving some tunneled traffic to 248 native IPv6 nodes from 6to4 Routers 249 - if packets are received from 6to4 addresses through 250 tunneling, decapsulate them and forwards them on using 251 normal IPv6 routing 252 - if packets are received through normal IPv6 routing from 253 native addresses, and are destined for 2002::/16, tunnel 254 them to the corresponding 6to4 Router 256 3.2. Non-functions of Different 6to4 Network Components 258 What should not happen; this forms a basis for the security checks. 259 The lists are not exhaustive. 261 o 6to4 Router or Relay 262 - use private, broadcast or reserved IPv4 addresses in tunnels, 263 or the matching 6to4 prefixes 264 - receive traffic from 6to4 Routers where the IPv4 tunnel 265 source address does not match the 6to4 prefix 266 - receive traffic where the destination IPv6 address is not a 267 global address; in particular, e.g. link-local addresses, 268 mapped addresses and such should not be used 269 o 6to4 Router 270 - send traffic to other 6to4 domains through 6to4 Relay Router 271 or via some third party 6to4 Router 272 - receive traffic from other 6to4 domains via a 6to4 Relay 273 Router 274 - receive traffic to other than to your own 6to4 prefix(es) 275 o 6to4 Relay Router 276 - receive traffic from 6to4 to 6to4 278 4. Special Processing of 6to4 Packets 280 One could summarize the special processing of 6to4 as follows: 282 o Relay Router 283 1. incoming from native, tunneled to 6to4 284 2. tunneled from 6to4, going to native 286 o Router 287 1. tunneled from relay, source is native 288 2. tunneled to relay, destination is native 289 3. tunneled directly, destination is 6to4 291 4.1. Encapsulating IPv6 Packets into IPv4 293 IPv6 packets are encapsulated into IPv4 in three scenarios: 295 1. 6to4 Router sends packets to other 6to4 Routers (2002::/16 296 destination) 297 2. 6to4 Router sends packets to its configured/nearest-by-anycast 298 6to4 Relay Router (non-2002::/16 destination) 299 3. 6to4 Relay Router sends packets from native IPv6 sources to 300 6to4 Routers (2002::/16 destination) 302 4.2. Decapsulating IPv4 Packets into IPv6 304 IPv6 packets are decapsulated from IPv4 in three scenarios: 306 1. 6to4 Router receives packets from other 6to4 Routers (2002::/16 307 source) 308 2. 6to4 Router receives packets from its 6to4 Relay Router closest 309 to the source (non-2002::/16 source) 310 3. 6to4 Relay Router receives packets from 6to4 Routers, to be 311 sent to native IPv6 destinations (2002::/16 source) 313 5. Solutions 315 5.1. Generic Approach 317 5.1.1. Encapsulating IPv6 into IPv4 319 src and dst SHOULD pass ipv6-sanity checks, else drop (defined below) 320 if src=2002 321 src MUST match src_v4 322 [ the scenario: 4.1. case 1. or 2. ] 323 if dst=2002 324 dst_v4 SHOULD NOT be assigned to the router (avoid misconfigurations) 325 [ the scenario: 4.1. case 1. ] 326 fi 327 elif dst=2002 328 dst_v4 MAY have to match one of ipv4 equiv. of 6to4 prefixes masked by a 329 user-specified prefix length (restricting who can use the relay) 330 [ the scenario: 4.1. case 3. ] 331 else 332 drop 333 [ the scenario: we somehow got a native-native ipv6 packet ] 334 fi 335 accept 337 5.1.2. Decapsulating IPv4 into IPv6 339 src_v4 and dst_v4 SHOULD pass ipv4-sanity checks, else drop (defined below) 340 src and dst SHOULD pass ipv6-sanity checks, else drop (defined below) 341 if dst=2002 342 dst MUST match dst_v4 343 src_v4 may be restricted to be 6to4_ipv4_anycast [not useful for a long time yet] 344 [ the scenario: 4.2. case 1. or 2. ] 345 if src=2002 346 src MUST match src_v4 347 dst_v4 SHOULD be assigned to the router (see notes below) 348 [ the scenario: 4.2. case 1. ] 349 fi 351 elif src=2002 352 src MUST match src_v4 353 dst_v4 SHOULD be assigned to the router (see notes below) 354 src_v4 MAY have to match one of ipv4 equiv. of 6to4 prefixes masked by a 355 user-specified prefix length (restricting who can use the relay) 356 [ the scenario: 4.2. case 3. ] 357 else 358 drop 359 [ the scenario: we somehow got a native-native ipv6 packet ] 360 fi 361 accept 363 5.1.3. IPv4 and IPv6 Sanity Checks 365 5.1.3.1. IPv4 367 IPv4 address MUST be a global unicast address, as required by the 368 6to4 specification. The disallowed addresses include those defined 369 in [RFC1812], and others widely used and known not to be global. 370 These are: 371 o 0.0.0.0/8 (the system has no address assigned yet) 372 o 10.0.0.0/8 (private) 373 o 127.0.0.0/8 (loopback) 374 o 172.16.0.0/12 (private) 375 o 192.168.0.0/16 (private) 376 o 169.254.0.0/16 (IANA Assigned DHCP link-local) 377 o 224.0.0.0/4 (multicast) 378 o 255.0.0.0/8 (broadcast) 380 In addition it it SHOULD be checked that the address is not any of 381 the system's broadcast addresses. This is especially important if 382 the implementation is made so that it can receive and process 383 encapsulated IPv4 packets arriving at its broadcast addresses, or try 384 to send encapsulated IPv4 packets to one of its broadcast addresses. 386 5.1.3.2. IPv6 388 IPv6 address MUST not be: 389 o 0::/16 (compatible, mapped addresses, loopback, unspecified, 390 ...) 391 o fe80::/10 (link-local) 392 o fec0::/10 (site-local) 393 o ff02::/16 (link-local multicast) 395 Other multicast could also be considered for filtering. 397 In addition, it MUST be checked that equivalent 2002:V4ADDR checks, 398 where V4ADDR is any of the above IPv4 addresses, will not be passed. 400 5.1.3.3. Optional Ingress Filtering 402 In addition, the implementation may perform some form of ingress 403 filtering (e.g. Unicast Reverse Path Forwarding checks). For 404 example, if a Router has multiple interfaces, of which some are 405 "internal", receiving either IPv4 or IPv6 packets with source address 406 belonging to any of these internal networks from the Internet might 407 be disallowed. 409 If these checks are implemented, it is RECOMMENDED that they default 410 to disabled. 412 5.1.3.4. Notes About the Checks 414 The rule 'dst_v4 SHOULD be assigned to the router' is not needed if 415 the implementation is made in such a way that it only accepts and 416 processes encapsulated IPv4 packets arriving on unicast IPv4 417 addresses, and that if destination address is known to be a local 418 broadcast address, not try to encapsulate and send packets to it. 420 Some checks, especially the IPv4/IPv6 Sanity Checks, could be at 421 least partially implementable with system-level access lists, if one 422 would like to avoid placing too many restrictions in the 6to4 423 implementation itself. This depends on how many hooks for ACL's are 424 in place. In practice it seems like this could not be done 425 effectively enough unless the access list mechanism is able to parse 426 the encapsulated packets within IP-IP. 428 5.2. Simplified Approach 430 This makes some assumptions about the implementation as pointed above 431 to simplify the above rules. 433 5.2.1. Encapsulating IPv6 into IPv4 435 src and dst SHOULD pass ipv6-sanity checks, else drop 436 if src=2002 437 src MUST match src_v4 438 elif dst=2002 439 (accept) 440 else 441 drop 442 fi 443 accept 445 5.2.2. Decapsulating IPv4 into IPv6 447 src_v4 and dst_v4 SHOULD pass ipv4-sanity checks, else drop 448 src and dst SHOULD pass ipv6-sanity checks, else drop 449 if dst=2002 450 dst MUST match dst_v4 451 if src=2002 452 src MUST match src_v4 453 fi 454 elif src=2002 455 src MUST match src_v4 456 else 457 drop 458 fi 459 accept 461 5.3. All Relays Must Be Anycast 463 In this model, all Relay Routers must always use 6to4 IPv4 Anycast 464 address as the source address. 466 In order for this to be implementable, every single 6to4 Relay Router 467 must use only anycast. This may be too significant a deployment 468 restriction. 470 Also, in certain circumstances if Unicast RPF is used, the use of 471 IPv4 anycast as a source address globally will fail the checks and 472 result in dropped packets. 474 The checks would be: 476 if src_v4 is 6to4 ipv4 anycast address 477 accept [coming from relay] 478 elif src_v4 is non-global ipv4 unicast address 479 drop 480 elif src = 2002 481 src MUST match src_v4 [coming from router] 482 accept 483 else 484 drop 485 fi 487 6. Problems 489 6.1. Implementation Considerations with Automatic Tunnels 491 There is a problem with multiple transition mechanisms if security is 492 implemented. This may vary a bit from implementation to 493 implementation. 495 Consider three mechanisms using automatic tunneling: 6to4, ISATAP 496 [ISATAP] and Automatic Tunneling using Compatible Addresses [MECH]. 497 All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with, 498 more or less, a pseudo-interface. 500 When a router, which has any two of these enabled, receives an IPv4 501 encapsulated IPv6 packet: 503 src_v4 = 10.0.0.1 504 dst_v4 = 20.20.20.20 505 src = 3ffe:ffff::1 506 dst = 2002:1010:1010::2 508 what can it do? How should it decide which transitionary mechanism 509 this belongs to; there is no "transitionary mechanism number" in IPv6 510 or IPv4 header to signify this. (This can also be viewed as a 511 flexibility benefit.) 513 Without any kind of security checks (in any of implemented methods) 514 these often just "work" as the mechanisms aren't differentiated but 515 handled in "one big lump". 517 Configured tunneling [MECH] does not suffer from this as it is point- 518 to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses 519 it can be deduced which logical tunnel interface is in the question. 521 Solutions for this include not using more than one automatic 522 tunneling mechanisms in the same system or binding different 523 mechanisms to different IPv4 addresses. 525 6.2. Reduced Flexibility 527 There is a worry about too strict rules limiting the (future) 528 flexibility of 6to4. If later, for some reason, one would want to 529 introduce new revolutionary ways to use 6to4, strict checking in all 530 relevant nodes might prevent it, as new updated version would have to 531 be deployed everywhere before the new method could be used. 533 On the other hand, one could argue that 6to4 has always been intended 534 as an intermediate mechanism, and that future flexibility should not 535 be critical. However, it is difficult to predict how long the 536 intermediate period will be. 538 7. Security Considerations 540 This draft discusses security considerations. 542 If proper checks are not implemented, there are significant security 543 threats ranging from DoS proxy attacks to spoofing and attacks 544 against 6to4 pseudo-interface. 546 Remainder threats, if "maximal" security is implemented (e.g. all 547 MUSTs and SHOULDs in 5.2.1 and 5.2.2): 548 o one cannot verify that the relay is authorized to originate the 549 traffic from native sources 550 o relays can be used for remote reflection (packets sent to 551 2002:[target ipv4]) 552 o relays can be used without authorization (theft of service); EGP 553 advertisement restrictions aren't enough, e.g. routing headers 554 can be used to work around these. 556 The first could be partially remedied by keeping a list of trusted 557 relays but that is not a really scalable or completely secure 558 solution. The latter two of these can be worked around (but only in 559 a very closed environment) by IPv6 packet filter access-lists. 561 Remainder threats, when only the most important checks have been 562 implemented (e.g. only MUSTs in 5.2.1 and 5.2.2): 563 o relays used for local amplified reflection (packets sent to 564 2002:[addr], where addr is a (subnet) broadcast or multicast 565 address. 566 o relays' 6to4 pseudo-interface is subject to some remote local 567 netaccess threats [NETACCESS] (e.g. with destination being link- 568 local). 570 This assumes that when encapsulating (or in some cases, 571 decapsulating), the destination is not checked completely. 573 As can be seen, relays are the toughest part to get secured, but 574 luckily enough, there aren't thousands of them and the administrators 575 can be assumed to be at least partially knowledgeable. 577 8. Acknowledgements 579 Alexey Kuznetsov brought up the implementation problem with IPv6 580 martian checks. Christian Huitema formulated the rules that rely on 581 Relays using only anycast. Keith Moore brought up the point about 582 reduced flexibility. Brian Carpenter, Tony Hain and Vladislav 583 Yasevich for lengthy discussions. 585 9. References 587 [6TO4] Carpenter, B. and Moore K., "Connection of IPv6 Domains 588 via IPv4 Clouds", RFC 3056, February 2001. 590 [6TO4ANY] Huitema, C. "An Anycast Prefix for 6to4 Relay 591 Routers", RFC 3068, June 2001. 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997. 596 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G. 597 and E. Lear, "Address Allocation for Private Internets", 598 BCP 5, RFC 1918, February 1996. 600 [MECH] Gilligan, R., and Nordmark, E. "Transition Mechanisms for 601 IPv6 Hosts and Routers", RFC 2893, August 2000. 603 [IPIP] Simpson, W. "IP in IP Tunneling", RFC 1853, October 604 1995. 606 [ISATAP] Templin, F. "Intra-Site Automatic Tunnel Addressing 607 Protocol (ISATAP)", draft-ietf-ngtrans-isatap-03.txt 608 (work in progress). 610 [NETACCESS] Kempf, J., Nordmark, E., "Threat Analysis for IPv6 Public 611 Multi-Access Links", draft-kempf-ipng-netaccess-00.txt 612 (work in progress). 614 Author's Address 616 Pekka Savola 617 CSC/FUNET 618 Espoo, Finland 619 EMail: psavola@funet.fi 621 A. Some Attack Scenarios Outlined 623 If the security checks haven't been properly implemented, at least 624 the following are possible. 626 The following addresses are used in these examples. IPv4 addresses 627 are indeed just examples of global IPv4 addresses. 629 __________________ __________________ 630 | Native IPv6 N1 | | Native IPv6 N2 | 631 | 3ffe:ffff:1::/48 | | 3ffe:ffff:2::/48 | 632 '------------------' '------------------' 633 _______________________ _______________________ 634 | 6to4 Relay Router RR1 | | 6to4 Relay Router RR2 | 635 | 3ffe:ffff:10::1/48 | | 3ffe:ffff:11:1::1/48 | 636 | 2002:0900:0001::1/48 | | 2002:0900:0002::1/48 | 637 | (IPv4) 9.0.0.1 | | (IPv4) 9.0.0.2 | 638 '-----------------------' '-----------------------' 639 ______________________ ______________________ 640 | 6to4 Router RA | | 6to4 Router RB | 641 | 2002:0800:0001::1/48 | | 2002:0800:0002::1/48 | 642 | (IPv4) 8.0.0.1 | | (IPv4) 8.0.0.2 | 643 '----------------------' '----------------------' 645 When two 6to4 Routers send traffic to each others' domains, packet 646 sent by RA to RB is like: 648 src = 2002:0800:0001::aaaa 649 dst = 2002:0800:0002::bbbb 650 src_v4 = 8.0.0.1 (added when encapsulated to IPv4) 651 dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) 653 When the packet is received by IPv4 stack on RB, it will be 654 decapsulated so that only src and dst remain, as originally sent by 655 RA: 657 src = 2002:0800:0001::aaaa 658 dst = 2002:0800:0002::bbbb 660 As every other node is just "one hop away" and the "link-layer" 661 addresses are lost, this may open a lot of possibilities for misuse. 662 Some possible approaches are outlined below. 664 A.1. IPv6 Spoofing and Access Control Avoidance 666 Unidirectional IPv6 spoofing is made trivial because nobody can check 667 (without delving into IP-IP packets) whether the encapsulated IPv6 668 addresses were authentic (With native IPv6, this can be done by e.g. 669 RPF-like mechanisms or access lists in upstream routers). 671 src = 2002:1234:5678::aaaa (forged) 672 dst = 2002:0800:0002::bbbb 673 src_v4 = 8.0.0.1 (added when encapsulated to IPv4) 674 dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) 676 More worries come in to the picture if e.g. 678 src = ::ffff:[some trusted IPv4 in a private network] 679 src/dst = ::ffff:127.0.0.1 680 src/dst = ::1 681 src/dst = ... 683 Some implementations might have been careful enough to have designed 684 the stack to as to avoid these, but who can say for all ... 686 A.2. IPv4 Local Directed Broadcast Attacks 688 Relays could be targeted with local broadcast attacks: 690 src = 3ffe:ffff:5678::aaaa (forged) 691 dst = 2002:0900:00ff::bbbb 693 Now, if the Relay doesn't check the destination address for 694 broadcast, it would send the encapsulated IP-IP packet to 9.0.0.255 695 which might be a local broadcast address (packets sent to every IPv4 696 node in the subnet). Classic directed broadcast checks will not 697 prevent this as the packet doesn't come from outside (in IPv4 sense). 699 A.3. DoS Reflector 701 Denial-of-Service attacks could be reflected against either IPv4 702 nodes (not that useful, only thing that could be sent is IP-IP 703 packets) or IPv6 nodes. 705 6to4 Relay Router could be abused as follows: 707 src = X 708 dst = Y 709 src_v4 = 8.0.0.1 (added when encapsulated to IPv4) 710 dst_v4 = 9.0.0.2 (added when encapsulated to IPv4) 712 a) X=2002:1234:5678::1 or X=3ffe:1122:3344::1 (forged) 713 Y=2002:0500:0001::1 or Y=::0500:0001 (the victim) 715 Target IPv4 address 5.0.0.1 would be bombed with reflected packets 716 from 6to4 Relay Router RR2. Source address in IPv6 header reveals 717 nothing, or can be used to throw blame on someone else. 719 b) X=2002:1234:5678::1 or X=3ffe:1122:3344::1 (forged) 720 Y=3ffe:aabb:ccdd::1 (the victim) 722 As above, the target could be native IPv6 address too, not 723 necessarily an IPv4 node. 725 Improper 6to4 Router could be abused as follows: 727 src = X 728 dst = Y 729 src_v4 = 8.0.0.1 (added when encapsulated to IPv4) 730 dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) 732 Both issues from above may also apply, if not implemented properly. 733 For example: 735 a) X=2002:1234:5678::1 or X=3ffe:1122:3344::1 (forged) 736 Y=3ffe:aabb:ccdd::1 (the victim) 738 This might allow one to tunnel to the 6to4 Router RB, and place 739 packets, with forged source addresses (be they 6to4 or not) to the 740 router, and if it accepted them to be routed natively (ie. the 741 forwarding process doesn't check that it shouldn't send them out the 742 same way they came), be tunneled to Relay Router, and from there to 743 Internet. 745 A.4. Remote Net-access Threats 747 As [NETACCESS] points out, there are a significant number of issues 748 with public multi-access links. The security mechanism is that 749 nobody will want to do any harm, Hop Limit can be verified to be 255 750 (the packet has not been forwarded) and link-local addresses are 751 used. 753 However, with 6to4 pseudo-interface, unless there are checks for the 754 destination addresses (a bit problematic especially in 6to4 Relays), 755 none of these are valid! The packet would look like: 757 src_v4 = 758 dst_v4 = 759 ttl_v4 = 760 src = 3ffe:ffff::1 or (in some cases) fe80::2 761 dst = fe80::1 762 hop limit = 255 764 Needless to say, this would bring the security of 6to4 pseudo- 765 interface (or any interface blindly decapsulating packets and not 766 performing strict checks on the content) could become like that of a 767 public multi-access network. 769 Similarly, e.g. '::1' could also be used as a destination address.