idnits 2.17.1 draft-ietf-v6ops-6to4-security-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1810. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1826), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 39 longer pages, the longest (page 25) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 40 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 36 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 8 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 17, 2004) is 7253 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) ** Obsolete normative reference: RFC 3068 (ref. '3') (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 2893 (ref. '4') (Obsoleted by RFC 4213) -- Obsolete informational reference (is this intentional?): RFC 1771 (ref. '5') (Obsoleted by RFC 4271) -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '6') (Obsoleted by RFC 6724) == Outdated reference: A later version (-06) exists of draft-ietf-send-ndopt-05 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-03 == Outdated reference: A later version (-03) exists of draft-savola-ipv6-rh-ha-security-02 == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-22 Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 v6ops Working Group P. Savola 2 Internet-Draft CSC/FUNET 3 Expires: December 16, 2004 C. Patel 4 All Play, No Work 5 June 17, 2004 7 Security Considerations for 6to4 8 draft-ietf-v6ops-6to4-security-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 16, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 The IPv6 interim mechanism 6to4 (RFC3056) uses automatic 42 IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The 43 architecture includes 6to4 routers and 6to4 relay routers, which 44 accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from 45 any node in the IPv4 internet. This characteristic enables a number 46 of security threats, mainly Denial of Service. It also makes it 47 easier for nodes to spoof IPv6 addresses. This document discusses 48 these issues in more detail and suggests enhancements to alleviate 49 the problems. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 5 55 2.1 From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . . 5 56 2.2 From Native to 6to4 . . . . . . . . . . . . . . . . . . . 5 57 2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . . . 6 58 2.4 Other Models . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.4.1 BGP Between 6to4 Routers and Relays . . . . . . . . . 7 60 2.4.2 6to4 as an Optimization Method . . . . . . . . . . . . 7 61 2.4.3 6to4 as Tunnel End-Point Addressing Mechanism . . . . 7 62 3. Functionalities of 6to4 Network Components . . . . . . . . . . 9 63 3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . . 10 65 4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . . . 12 67 4.1.1 Attacks with ND Messages . . . . . . . . . . . . . . . 13 68 4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . . . . 14 69 4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . . . . 17 70 4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 18 71 4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . . . 20 72 4.2.1 Attacks with ND Messages . . . . . . . . . . . . . . . 20 73 4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . . . . 21 74 4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . . . . 22 75 4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 24 76 4.2.5 Theft of Service . . . . . . . . . . . . . . . . . . . 24 77 4.2.6 Relay Operators Seen as Source of Abuse . . . . . . . 26 78 4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . . . 27 79 4.4 Summary of the Attacks . . . . . . . . . . . . . . . . . . 27 80 5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 29 81 5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . . 30 82 5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . . 30 83 5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . . 31 84 5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 31 85 5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32 86 5.3.3 Optional Ingress Filtering . . . . . . . . . . . . . . 32 87 5.3.4 Notes About the Checks . . . . . . . . . . . . . . . . 32 88 6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 33 89 6.1 Implementation Considerations with Automatic Tunnels . . . 33 90 6.2 A Different Model for 6to4 Deployment . . . . . . . . . . 34 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 93 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 95 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 96 10.2 Informative References . . . . . . . . . . . . . . . . . . . 36 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 98 A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 38 99 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39 100 Intellectual Property and Copyright Statements . . . . . . . . 40 102 1. Introduction 104 The IPv6 interim mechanism "6to4" [1] specifies automatic 105 IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by 106 embedding the tunnel IPv4 address in the IPv6 6to4 prefix. 108 Two characteristics of the 6to4 mechanism introduce most of the 109 security considerations: 111 1. All 6to4 routers must accept and decapsulate IPv4 packets from 112 every other 6to4 router, and 6to4 relays. 114 2. 6to4 relay routers must accept traffic from any native IPv6 node. 116 Since the 6to4 router must accept from traffic from any other 6to4 117 router or relay, a certain requirement for trust is implied, and 118 there are no strict constraints on what the IPv6 packet may contain. 119 Thus, addresses within the IPv4, and IPv6 header may be spoofed, and 120 this property leads to various types of threats including different 121 flavors of Denial of Service -attacks. 123 The 6to4 specification outlined a few security considerations and 124 rules, but was very ambiguous on their exact requirement level. 125 Further, the description of the considerations was rather short, and 126 in fact, some of them have been proven to be difficult to understand 127 or impossible to implement. 129 This draft analyzes the 6to4 security issues in more detail and 130 outlines some enhancements and caveats. 132 Section 2, and Section 3 are more or less introductory in nature, 133 rehashing how 6to4 is used today based on the 6to4 specification, so 134 that it is easier to understand how security could be affected. 135 Section 4 provides a threat analysis for implementations that already 136 implement most of the security checks. Section 5 describes the 137 optimal decapsulation/encapsulation rules for 6to4 implementations, 138 and Section 6 provides further discussion on a few issues which have 139 proven to be difficult to implement. Appendix A outlines a few 140 possible trivial attack scenarios in the case that very little or no 141 security has been implemented. 143 For the sake of simplicity, in this document, native IPv6 Internet is 144 assumed to encompass IPv6 networks formed using other transition 145 mechanisms (e.g. RFC 2893 [4]), as these mechanisms cannot talk 146 directly 6to4 network. 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [2]. 152 2. Different 6to4 Forwarding Scenarios 154 It should be noted that when communicating between 6to4 and native 155 domains, the 6to4 relays that will be used in the two directions are 156 very likely different; routing is highly asymmetric. Because of 157 this, it is not feasible to limit relays from which 6to4 routers may 158 accept traffic. 160 The first three subsections introduce the most common forms of 6to4 161 operation. Other models are presented in the fourth subsection. 163 2.1 From 6to4 to 6to4 165 6to4 domains always exchange 6to4 traffic directly via IPv4 166 tunneling; the endpoint address V4ADDR is derived from 6to4 prefix 167 2002:V4ADDR::/48 of the destination. 169 .--------. _----_ .--------. 170 | 6to4 | _( IPv4 )_ | 6to4 | 171 | router | <====> ( Internet ) <===> | router | 172 '--------' (_ _) '--------' 173 ^ '----' ^ 174 | Direct tunneling over IPv4 | 175 V V 176 .--------. .-------. 177 | 6to4 | | 6to4 | 178 | host | | host | 179 '--------' '--------' 181 Figure 1 183 It is required that every 6to4 router considers every other 6to4 184 router it wants to talk to to be "on-link" (with IPv4 as the 185 link-layer). 187 2.2 From Native to 6to4 189 When native domains send traffic to 6to4 prefix 2002:V4ADDR::/48, it 190 will be routed to the topologically nearest, advertising (advertising 191 route to 2002::/16) 6to4 relay. The 6to4 relay will tunnel the 192 traffic over IPv4 to the corresponding IPv4 address V4ADDR. 194 Note that IPv4 address 9.0.0.1 here is just an example of a global 195 IPv4 address, and it is assigned to the 6to4 router's 196 pseudo-interface. 198 Closest to 199 "Native IPv6 node" 200 .--------. _----_ .------------. .--------. 201 | Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 | 202 | IPv6 | -> ( Internet ) --> | router | =========> | router | 203 | node | (_ _) '------------' 9.0.0.1 '--------' 204 '--------' '----' dst_v6=2002:0900:0001::1 | 205 V 206 .-------. 207 | 6to4 | 208 | host | 209 '--------' 211 Figure 2 213 2.3 From 6to4 to Native 215 6to4 domains send traffic to native domains by tunneling it over IPv4 216 to their configured 6to4 relay router, or the closest one found using 217 6to4 IPv4 Anycast [3]. The relay will decapsulate the packet and 218 forward it to native IPv6 Internet, the same way as any other IPv6 219 packet. 221 Note that destination IPv6 address in the packet is a non-6to4 222 address, and is assumed to be 2001:db8::1 in the example. 224 Configured 225 -or- 226 found by IPv4 Anycast 227 .--------. _----_ .------------. .--------. 228 | Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 | 229 | Client | <- ( Internet ) <-- | router | <========= | router | 230 '--------' (_ _) '------------' 192.88.99.1'--------' 231 2001:db8::1 '----' (or configured) ^ 232 | 233 .-------. 234 | 6to4 | 235 | client | 236 '--------' 238 Figure 3 240 2.4 Other Models 242 These are more or less special cases of 6to4 operations. In later 243 chapters, unless otherwise stated, only the most generally-used 244 models (above) will be considered. 246 2.4.1 BGP Between 6to4 Routers and Relays 248 Section 5.2.2.2 in [1] presents a model where, instead of static 249 configuration, BGP [5] is used between 6to4 relay routers and 6to4 250 routers. 252 If the 6to4 router established a BGP session between all the possible 253 6to4 relays, and advertised its /48 prefix to them, the traffic from 254 non-6to4 sites would always come from a "known" relay. 255 Alternatively, the 6to4 relays might advertise the more specific 6to4 256 routes between 6to4 relays. 258 Both of these approaches are more or less obviously infeasible due to 259 scalability issues. 261 Neither of these models are known to be used at the time of writing; 262 this is probably caused by the fact that parties that need 6to4 are 263 those that are not able to run BGP, and because setting up these 264 sessions would be much more work for relay operators. 266 2.4.2 6to4 as an Optimization Method 268 Some sites seem to use 6to4 as an IPv6 connectivity "optimization 269 method"; that is, they have also non-6to4 addresses on their nodes 270 and border routers, but also employ 6to4 to reach 6to4 sites. 272 This is typically done to be able to reach 6to4 destinations by 273 direct tunneling and not having to use relays at all. 275 These sites also publish both 6to4 and non-6to4 addresses in DNS to 276 affect inbound connections; if the source host's default address 277 selection [6] works properly, 6to4 sources will use 6to4 addresses to 278 reach the site and non-6to4 nodes use non-6to4 addresses. If this 279 behavior of foreign nodes can be assumed, the security threats to 280 such sites can be significantly simplified. 282 2.4.3 6to4 as Tunnel End-Point Addressing Mechanism 284 6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel 285 endpoint addressing and routing mechanism. 287 An example of this is interconnecting 10 branch offices where nodes 288 use non-6to4 addresses. Only the offices' border routers need to be 289 aware of 6to4, and use 6to4 addresses solely for addressing the 290 tunnels between different branch offices. An example is provided in 291 the figure below. 293 2001:db8:0:10::/60 2001:db8:0:20::/60 294 .--------. .--------. 295 ( Branch 1 ) ( Branch 2 ) 296 '--------' '--------' 297 | | 298 .--------. _----_ .--------. 299 | 6to4 | _( IPv4 )_ | 6to4 | 300 | router | <====> ( Internet ) <===> | router | 301 '--------' (_ _) '--------' 302 9.0.0.1 '----' 8.0.0.2 303 ^^ 304 || 305 vv 306 .--------. 307 | 6to4 | 7.0.0.3 308 | router | 309 '--------' 310 | 2001:db8::/48 311 .-----------. 312 ( Main Office ) 313 '-----------' 314 ^ 315 | 316 v 317 _----_ 318 _( IPv6 )_ 319 ( Internet ) 320 (_ _) 321 '----' 323 Figure 4 325 In the figure, the main office sets up two routes: 327 2001:db8:0:10::/60 -> 2002:0900:0001::1 329 2001:db8:0:20::/60 -> 2002:0800:0002::1 331 And a branch office sets up two routes as well: 333 2001:db8:0:20::/60 -> 2002:0800:0002::1 335 default -> 2002:0700:0003::1 337 Thus, the IPv4 Internet is treated as NBMA link-layer for 338 interconnecting 6to4-enabled sites; with explicit routes, 6to4 339 addressing need not be used in other than the 6to4 edge routers. 340 However, note that if a branch office sends a packet to any 6to4 341 destination, it will not go through the main office as the 6to4 342 2002::/16 route overrides the default route. 344 This approach may make addressing and routing slightly easier in some 345 circumstances. 347 3. Functionalities of 6to4 Network Components 349 This section summarizes the main functionalities of the 6to4 network 350 components (6to4 routers, and 6to4 relays), and the security checks 351 that must be done by them. The pseudo-code for the security checks 352 is provided in Section 5. 354 This section summarizes the main functions of the various components 355 that are part of a 6to4 network - 6to4 relay routers, and 6to4 356 routers. Refer to Section 1.1 of RFC 3056 [1] for 6to4 related 357 definitions. 359 3.1 6to4 Routers 361 The 6to4 routers acts as the border router of a 6to4 domain. It does 362 not have a native, global IPv6 address except in certain special 363 cases. Since the specification [1] uses the term "6to4 router", this 364 memo does the same; however, note that we also include a single host 365 with a 6to4 pseudo-interface, which doesn't otherwise act as a 366 router, in this definition. The main functions of the 6to4 router 367 are: 369 o Provide IPv6 connectivity to local clients and routers. 371 o Tunnel packets sent to foreign 6to4 addresses to the destination 372 6to4 router using IPv4. 374 o Forward packets sent to locally configured 6to4 addresses to the 375 6to4 network. 377 o Tunnel packets sent to non-6to4 addresses, to the configured/ 378 closest-by-anycast 6to4 relay router. 380 o Decapsulate directly received IPv4 packets from foreign 6to4 381 addresses. 383 o Decapsulate IPv4 packets received via the relay closest to the 384 native IPv6 sources. Note, it is not easily distinguishable that 385 the packet was really received from a 6to4 relay router, not from 386 a spoofing third party. 388 The 6to4 router should also perform security checks on traffic that 389 it will receive from other 6to4 relays, or 6to4 routers, or from 390 within the 6to4 site. These checks include: 392 o Disallow traffic that has private, broadcast or reserved IPv4 393 addresses in tunnels, or the matching 6to4 prefixes. 395 o Disallow traffic from 6to4 routers where the IPv4 tunnel source 396 address does not match the 6to4 prefix. (Note that the 397 pseudo-interface must pick the IPv4 address corresponding to the 398 prefix when encapsulating, or else problems may ensue on e.g., 399 multi-interface routers.) 401 o Disallow traffic where the destination IPv6 address is not a 402 global address; in particular, e.g. link-local addresses, mapped 403 addresses and such should not be used. 405 o Disallow traffic transmission to other 6to4 domains through 6to4 406 relay router or via some third party 6to4 router. (To avoid 407 transmission to the relay router, the pseudo-interface prefix 408 length must be configured correctly to be /16. Further, to avoid 409 the traffic being discarded, 6to4 source addresses must always 410 correspond to the IPv4 address encapsulating the traffic.) 412 o Discard traffic received from other 6to4 domains via a 6to4 relay 413 router. 415 o Discard traffic received for prefixes other than your own 6to4 416 prefix(es). 418 3.2 6to4 Relay Routers 420 The 6to4 relay router acts as a relay between all 6to4 domains and 421 native IPv6 networks; more specifically: 423 o It advertises the reachability of the 2002::/16 prefix to native 424 IPv6 routing, thus receiving traffic to all 6to4 addresses from 425 closest native IPv6 nodes. 427 o Advertise (if RFC 3068 [3] is implemented) the reachability of 428 IPv4 "6to4 relay anycast prefix" (192.88.99.0/24) to IPv4 routing, 429 thus receiving some tunneled traffic to native IPv6 nodes from 430 6to4 routers. 432 o Decapsulate, and forward packets received from 6to4 addresses 433 through tunneling, using normal IPv6 routing. 435 o Tunnels packets received through normal IPv6 routing from native 436 addresses, and are destined for 2002::/16, to the corresponding 437 6to4 router. 439 The 6to4 relay should also perform security checks on traffic that it 440 will receive from 6to4 routers, or from native IPv6 nodes. These 441 checks are: 443 o Disallow traffic that has private, broadcast or reserved IPv4 444 addresses in tunnels, or the matching 6to4 prefixes. 446 o Disallow traffic from 6to4 routers where the IPv4 tunnel source 447 address does not match the 6to4 prefix. (Note that the 448 pseudo-interface must pick the IPv4 address corresponding to the 449 prefix when encapsulating, or else problems may ensue on e.g., 450 multi-interface routers.) 452 o Disallow traffic where the destination IPv6 address is not a 453 global address; in particular, e.g. link-local addresses, mapped 454 addresses and such should not be used. 456 o Discard traffic received from 6to4 routers with the destination as 457 a 6to4 prefix. 459 4. Threat Analysis 461 This section discusses attacks against the 6to4 network or attacks 462 that are caused by the 6to4 network. The threats are discussed in 463 light of the 6to4 deployment models defined in Section 2. 465 There are three general types of threats: 467 1. Denial-of-Service (DoS) attacks, in which a malicious node 468 prevents communication between the node under attack and other 469 nodes. 471 2. Reflection Denial-of-Service (DoS) attacks, in which a malicious 472 node reflects the traffic off unsuspecting nodes to a particular 473 node (node under attack) with the intent of preventing 474 communication between the node under attack and other nodes. 476 3. Service theft, in which a malicious node/site/operator may make 477 unauthorized use of service. 479 6to4 also provides a means for a "meta-threat", traffic laundering, 480 in which some other attack is channeled through the third parties to 481 make it more difficult to trace the real origin of the attack. This 482 is used in conjunction with other threats, whether specific to 6to4 483 or not. 485 At this point it is important to reiterate that the attacks are 486 possible because: 488 1. 6to4 routers have to consider all 6to4 relays, and other 6to4 489 routers as "on-link". 491 2. 6to4 relays have to consider all 6to4 routers as "on-link". 493 3. Partial implementation of the security checks in the 6to4 494 implementation. It has been discovered that at least a couple of 495 major implementations do not implement all the checks. 497 The attacks descriptions are classified based on the target of the 498 attack: 500 1. Attacks on 6to4 networks. 502 2. Attacks on IPv6 networks. 504 3. Attacks on IPv4 networks. 506 Note, the IPv4 address blocks 8.0.0.0/24 and 9.0.0.0/24 are only used 507 for demonstrative purposes, and represent global IPv4 addresses. 509 Note, one of the mitigation methods listed for various attacks is 510 based on the premise that 6to4 relays will a have a feature that may 511 be able to limit traffic to/from specific 6to4 sites. At the time of 512 writing this document, such a feature is speculation, and more work 513 needs to be done to determine the logistics of such a feature. 515 4.1 Attacks on 6to4 Networks 517 This section describes attacks against 6to4 networks. Attacks which 518 leverage 6to4 networks, but where the ultimate victim is elsewhere 519 (e.g., a native IPv6 user, an IPv4 user) are described later in the 520 memo. 522 6to4 relays and routers are IPv4 nodes, and there is no way for any 523 6to4 router to confirm the identity of the IPv4 node from which it is 524 receiving traffic -- whether it is a legitimate 6to4 relay or some 525 other node. A 6to4 router has to process traffic from all IPv4 526 nodes. Malicious IPv4 nodes can exploit this property and attack 527 nodes within the 6to4 network. 529 It is possible to conduct a variety of attacks on the 6to4 nodes. 530 These attacks are: 532 1. Attacks with Neighbor Discovery (ND) Messages 534 2. Spoofing traffic to 6to4 nodes 536 3. Reflecting traffic from 6to4 nodes 538 4. Local IPv4 broadcast attack 540 4.1.1 Attacks with ND Messages 542 ATTACK DESCRIPTION 544 Since the 6to4 router assumes all the other 6to4 routers, and 6to4 545 relays are "on-link" it is possible to attack the 6to4 router using 546 ND messages from any node in the IPv4 network, unless a prior trust 547 relationship has been established. 549 The attacks are targeting the 6to4 pseudo-interface. As long as the 550 6to4 addresses are not used in the source or destination address, the 551 security checks specified by 6to4 take no stance on these packets. 552 Typically these use link-local addresses. 554 For example, a possible attack could be a Route Advertisement or 555 Neighor Advertisement message, crafted specifically to cause havoc; 556 the addresses in such a packet could be like: 558 src_v6 = fe80::2 (forged address) 559 dst_v6 = fe80::1 (valid or invalid address) 560 src_v4 = 8.0.0.1 (valid or forged address) 561 dst_v4 = 9.0.0.2 (valid address, matches dst_v6) 563 These attacks are exacerbated in case the implementation supports 564 more tunneling mechanisms than just 6to4 (or configured tunneling), 565 because it is impossible to disambiguate such mechanisms, making it 566 difficult to enable strict security checks (see Section 6.1). 568 The Neighbor Discovery threats (Redirect DoS, or DoS) are described 569 in [7]. Note that all attacks may not be applicable, as the 6to4 570 pseudo-interface is assumed not to have a link-layer address (Section 571 3.8 RFC 2893 [4]). However, one should note that the 6to4 router can 572 be either a router or host from the Neighbor Discovery perspective. 574 THREAT ANALYSIS AND MITIGATION METHODS 576 The attacks can be mitigated by using any of the following methods: 578 o The usage of ND messages could be prohibited. It implies that all 579 packets using addresses of scope link-local will be silently 580 discarded. Section 3.1 of RFC 3056 [1] leaves scope for future 581 uses of link-local address. This method has its pitfalls - it 582 would prohibit any sort of ND message, and thus close the doors on 583 development, and use of other ND options. Whether this is a 584 significant problem is another thing. 586 o The 6to4 pseudo-interface could be insulated from the other 587 interfaces (for example, using a separate neighbor cache). 589 o Either IPsec [4] or an extension of SEND could be used [8] to 590 secure packet exchange using link-local address; vanilla SEND 591 would not work as the link-layer does not have an address -- and 592 IPsec would be rather complex. 594 COMPARISON TO SITUATION WITHOUT 6to4 596 Even though rather simply fixable, this attack is not new as such; 597 the same is possible using automatic tunneling [4] or configured 598 tunneling (if one is able to spoof source IPv4 address to that of the 599 tunnel end-point). 601 However, as 6to4 provides open decapsulation, and automatic tunneling 602 is being deprecated [9], 6to4 provides an easy means which would not 603 exist without 6to4. 605 4.1.2 Spoofing Traffic to 6to4 Nodes 607 ATTACK DESCRIPTION 609 The attacker - a malicious IPv4 or IPv6 node - can send packets which 610 are difficult to trace (e.g., due to spoofing or going through a 611 relay) to a 6to4 node. This can be used e.g., to accomplish a DoS 612 attack. 614 The IPv6 and IPv4 addresses of the packets will be similar to: 616 src_v6 = 2001:db8::1 (forged address) 617 dst_v6 = 2002:0900:0002::1 (valid address) 618 src_v4 = 8.0.0.1 (valid or forged address) 619 dst_v4 = 9.0.0.2 (valid address, matches dst_v6) 621 For attacks launched from a native IPv6 node, the src_v4 will be the 622 address of the relay through which the traffic will reach the 6to4 623 node. From IPv4 nodes, src_v4 can be either a spoofed or the real 624 source address. 626 The 6to4 router receives these packets from 8.0.0.1, decapsulates 627 them, discards the IPv4 header containing the source address 8.0.0.1 628 and processes them as normal (the attacker has guessed or obtained 629 "dst_v6" using one of a number of techniques). 631 This is a DoS attack on 6to4 nodes. 633 This attack is similar to ones shown in [10]. 635 EXTENSIONS 637 Replies to the traffic will be directed to the src_v6 address, 638 resulting in 6to4 nodes in participating in a reflection DoS. This 639 attack is described in more detail in Section 4.2.3. That is, the 640 replies (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to 641 UDP echo service, ICMPv6 Destination Unreachable, etc.) are sent to 642 the victim (src_v6), above. All the traces from the original 643 attacker (src_v4) have been discarded. These return packets will go 644 through a relay. 646 Certain 6to4 networks may have a trivial ACL (Access Control List) 647 based firewall that allows traffic to pass through if it comes from 648 particular source(s). Such a firewalling mechanism can be bypassed 649 by address spoofing. This attack can therefore be used for trivial 650 ACL avoidance as well. These attacks might be hampered by the fact 651 that the replies from the 6to4 node to the spoofed address will be 652 lost. 654 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 656 The Denial-of-Service attack based on traffic spoofing is not new; 657 the only twists come from the fact that traces of an attack are more 658 easily lost, and that spoofing the IPv6 address is possible even to 659 those who are unable to do so in their current networks. The 6to4 660 router typically does not log IPv4 addresses (as they would be 661 treated as L2 addresses) and thus the source of the attack (if 662 launched from an IPv4 node) is lost. Since traces to the src_v4 663 address can easily be lost, these attacks can also be be launched 664 from IPv4 nodes whose connection is ingress-filtered. 666 However, often this is not a real factor, as usually the attackers 667 are just zombies and real attackers may not even care if the 668 unspoofed source address is discovered. 670 Malicious native IPv6 nodes could be caught easily if ingress 671 filtering was enabled everywhere in the IPv6 Internet. 673 These attacks are easy to perform, but the extent of harm is limited: 675 o For every packet sent, at most one reply packet is generated: 676 there is no amplification factor. 678 o Attack packets, if initiated from an IPv6 node, will pass through 679 choke point(s), namely a 6to4 relay; in addition to physical 680 limitations, these could implement some form of 6to4-site-specific 681 traffic limiting. 683 On the other hand, a variety of factors can make the attack serious: 685 o The attacker may have the ability to choose the relay, and he 686 might employ the ones best suited for the attacks. Also, many 687 relays use 192.88.99.1 [3] as the source address making tracing 688 even more difficult (also see Section 4.2.6). 690 o The relay's IPv4 address may be used as a source address for these 691 attacks, potentially causing a lot of complaints or other actions 692 as the relay might seem to be the source of the attack (see 693 Section 4.2.6 for more). 695 Some of the mitigation methods for such attacks are: 697 1. Ingress filtering in the native IPv6 networks to prevent packets 698 with spoofed IPv6 source being transmitted. It would, thus, make 699 it easy to identify the source of the attack. 701 2. Security checks in the 6to4 relay. The 6to4 relay must drop 702 traffic (from the IPv6 internet) that has 6to4 addresses as 703 source address, see Section 5 for more. 705 However, these mitigation methods do not address the case of IPv4 706 node sending encapsulated IPv6 packets. 708 There exists no simple way to prevent such attacks, and longer term 709 solutions like ingress filtering [11] or itrace [12] would have to be 710 deployed in both IPv6 and IPv4 networks to help identify the source 711 of the attacks. (Note that itrace work has been discontinued, as of 712 this writing.) 714 COMPARISON TO SITUATION WITHOUT 6to4 716 Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just 717 makes it easier: anyone can, regardless of ingress filtering, spoof a 718 native IPv6 address to a 6to4 node, even if "maximal security" would 719 be implemented and deployed. Losing trails is also easier. 721 Therefore, depending on how much one assumes ingress filtering is 722 deployed for IPv4 and IPv6, this could be considered to be a very 723 serious issue, or close to irrelevant compared to the IP spoofing 724 capabilities without 6to4. 726 4.1.3 Reflecting Traffic to 6to4 Nodes 728 ATTACK DESCRIPTION 730 Spoofed traffic (as described in Section 4.2.2) may be sent to native 731 IPv6 nodes with the aim of performing a reflection attack against 732 6to4 nodes. 734 The spoofed traffic is sent to a native IPv6 node, either from an 735 IPv4 node (through a 6to4 relay), or from a native IPv6 node (unless 736 ingress filtering has been deployed). With the former, the sent 737 packets would look like: 739 src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node) 740 dst_v6 = 2002:0900:0002::1 (valid address) 741 src_v4 = 8.0.0.1 (valid or invalid address) 742 dst_v4 = 9.0.0.2 (valid address, matches dst_v6) 744 One should note that an attack through the relay is prevented if the 745 relay implements proper decapsulation security checks (see Section 5 746 for details) unless the IPv4 node can spoof the source address to 747 match src_v6. Similarly, the attack from native IPv6 nodes could be 748 prevented by global ingress filtering deployment. 750 These attacks can be initiated by native IPv6, IPv4, or 6to4 nodes. 752 EXTENSIONS 754 A distributed Reflection DoS can be performed if a large number nodes 755 are involved in sending spoofed traffic with the same src_v6. 757 Malicious 6to4 nodes can also (try to) initiate this attack by 758 bouncing traffic off 6to4 nodes in other 6to4 sites. However this 759 attack may not be possible as the 6to4 router (in the site from which 760 the attack is being launched) will filter packets with forged source 761 address (with security checks mentioned in Section 5), and thus the 762 attack will be prevented. 764 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 765 The reverse traffic in this case are replies to the messages received 766 by the 6to4 nodes. The attacker has less control on the packet type 767 in this case, and this would inhibit certain types of attacks. For 768 example, flooding a 6to4 node with TCP SYN packets will not be 769 possible (but e.g., a SYN-ACK or RST would be). 771 These attacks may be countered in various ways: 773 o Implementation of ingress filtering by the IPv4 service providers. 774 It would prevent forging of the src_v4 address, and would help in 775 closing down on the culprit IPv4 nodes. Note that, it will be 776 difficult to shut down the attack if a large number of IPv4 nodes 777 are involved. 779 These attacks may be also be stopped at the 6to4 sites if the 780 culprit src_v4 address is identified, and if it is constant, by 781 filtering traffic from this address. Note that it would be 782 difficult to implement this method, if appropriate logging is not 783 done by the 6to4 router, or if a large number of 6to4 nodes, and/ 784 or a large number of IPv4 nodes are participating in the attack. 786 o Implementation of ingress filtering by all IPv6 service providers 787 would eliminate this attack, because src_v6 could not be spoofed 788 to be a 6to4 address. However, expecting this to happen may not 789 be practical. 791 o Proper implementation of security checks (see Section 5) both at 792 the 6to4 relays and routers would eliminate the attack, when 793 launched from an IPv4 node, except when the IPv4 source address 794 was also spoofed -- but then the attacker would have been able to 795 just attack the ultimate destination directly. 797 o Rate limiting traffic at the 6to4 relays. In a scenario where 798 most of the traffic is passing through few 6to4 relays, these 799 relays can implement traffic rate-limiting features, and 800 rate-limit the traffic from 6to4 sites 802 COMPARISON TO SITUATION WITHOUT 6to4 804 This particular attack can be mitigated by proper implementation of 805 security checks and ingress filtering; where ingress filtering is not 806 implemented, it's typically easier to attack directly than through 807 reflection -- unless "traffic laundering" is an explicit goal in the 808 attack. Therefore, this attack does not seem very serious. 810 4.1.4 Local IPv4 Broadcast Attack 812 ATTACK DESCRIPTION 813 This threat is applicable if the 6to4 router does not check whether 814 the IPv4 address it tries to send encapsulated IPv6 packets to a 815 local broadcast address, or a multicast address. 817 This threat is described in the specification [1], and implementing 818 the checks eliminates this threat. However, as this has not been 819 widely implemented, it is included here regardless for completeness. 821 There practically two kinds of attacks: where a local 6to4 user tries 822 to send packets to the address corresponding to the broadcast 823 address, or when someone is able to do that remotely. 825 In the first option, assume that 9.0.0.255 is the 6to4 router's 826 broadcast address. After receiving the packet with a destionation 827 address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the 828 router doesn't check the destination address for subnet broadcast, it 829 would send the encapsulated protocol-41 packet to 9.0.0.255. This 830 would be received by all nodes in the subnet, and the responses would 831 be directed to the 6to4 router. 833 Malicious sites may also embed forged 6to4 addresses in the DNS, use 834 of which by a 6to4 node will result in a local broadcast by the 6to4 835 router. One way to perform this attack would be to send an HTML mail 836 containing a link to an invalid URL (for example, 837 http://[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 838 technology based network. Opening of the mail simultaneously would 839 result in a broadcast storm. 841 The second kind of attack is more complex: the attack can be 842 initiated by IPv4 nodes not belonging to the local network as long as 843 they can send traffic with invalid (for example 2002:0900:00ff::bbbb) 844 source address. The 6to4 router has to respond to the traffic by 845 sending ICMPv6 packets back to the source, for example Hop Limit 846 Exceeded or Destination Unreachable. The packet would be as follows: 848 src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router) 849 dst_v6 = 2002:0800:0001::0001 (valid non-existent address) 851 This is a DoS attack. 853 EXTENSIONS 855 The attacks could also be directed at non-local broadcast addresses, 856 but these would be so-called "IPv4 directed broadcasts", which have 857 been (luckily enough) already been extensively blocked in the 858 Internet. 860 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 861 The attack is based on the premise that the 6to4 router has to send a 862 packet to an IPv6 address that embeds an invalid IPv4 address. Such 863 an attack is easily thwarted by ensuring that the 6to4 router does 864 not transmit packets to invalid IPv4 addresses. Specifically traffic 865 should not be sent to broadcast or multicast IPv4 addresses. 867 COMPARISON TO SITUATION WITHOUT 6to4 869 The first threat is similar to what's already possible with IPv4, but 870 IPv6 does not have broadcast addresses. 872 The second, a more complex threat, is similarly also available in 873 IPv4. 875 In consequence, the security does not seem to be significantly worse 876 than with IPv4, and even that is restricted to the site(s) with 6to4 877 implementations which haven't been secured as described in Section 5. 879 4.2 Attacks on Native IPv6 Internet 881 This section describes attacks against native IPv6 Internet which 882 leverage 6to4 architecture somehow. Attacks against 6to4 nodes were 883 described in the previous section. 885 Native IPv6 nodes can be accessed by 6to4 and IPv4 nodes through the 886 6to4 relay routers. Thus the 6to4 relays play a crucial role in any 887 attack on native IPv6 nodes by IPv4 nodes or 6to4 nodes. 889 6to4 relays have only one significant security check they must 890 perform for general safety: when decapsulating IPv4 packets, check 891 that 2002:V4ADDR::/48 and V4ADDR match in the source address. If 892 this is not done, several threats become more serious; in the 893 following analysis, it is assumed that such checks are implemented. 895 6to4 relay should not relay packets between 6to4 addresses. In 896 particular, packets decapsulated from 6to4 routers should not be 897 encapsulated again towards 6to4 routers, as described in rules in 898 Section 5. Similarly, packets with 6to4 source and destination 899 address sent from IPv6 nodes should not be relayed. It is not clear 900 whether this kind of check is typically implemented. The attacks 901 described below assume that such checks are not implemented. 903 4.2.1 Attacks with ND Messages 905 These attacks are the same as employed against 6to4 routers as 906 described in Section 4.1.1. 908 4.2.2 Spoofing Traffic to Native IPv6 node 910 ATTACK DESCRIPTION 912 The attacker - a malicious IPv4 or 6to4 node - can send packets with 913 spoofed (or not spoofed) 6to4 source address to a native IPv6 node to 914 accomplish a DoS attack. 916 The threat is similar as the one involving 6to4 routers as described 917 in Section 4.1.2. 919 The difference here is that the attack is initiated by IPv4 nodes, or 920 6to4 nodes. The source IPv6 address may or may not be spoofed. 921 Note, as mentioned above, the relay is assumed to correlate source 922 IPv4 address with the address embedded in the source IPv6 address 923 during decapsulation. A side effect is that all the spoofed traffic 924 will have a 6to4 source address. 926 EXTENSIONS 928 Spoofed traffic may also be sent to native IPv6 nodes by either other 929 native IPv6 nodes, or 6to4 nodes, or malicious IPv4 nodes to conduct 930 Reflection DoS on either native IPv6 nodes or 6to4 nodes. 932 Certain native IPv6 networks may have a trivial ACL (Access Control 933 List) based firewall that allows traffic to pass through if it comes 934 from particular source(s). Such a firewalling mechanism can be 935 bypassed by address spoofing. This attack can therefore be used for 936 trivial ACL avoidance as well. These attacks might be hampered by 937 the fact that the replies from the 6to4 node to the spoofed address 938 will be lost. 940 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 942 The Denial-of-Service attack based on traffic spoofing is not new; 943 the only twist comes from the fact that traces of an attack are more 944 easily lost. The 6to4 relay typically does not log IPv4 addresses 945 (as they would be treated as L2 addresses) and thus the source of the 946 attack (if launched from an IPv4 node) is lost. Since traces to the 947 src_v4 address can easily be lost, these attacks can also be be 948 launched from IPv4 nodes whose connection is ingress-filtered. 950 These attacks might be not be very easy to perform, and might be 951 hampered because of: 953 o It might be difficult to launch such attacks from 6to4 nodes 954 because even if the 6to4 routers allow spoofing of the source IPv6 955 address, the 6to4 relay would check if source V4ADDR is same as 956 the one embedded in the source IPv6 address. Thus, 6to4 nodes 957 will be forced to use the correct IPv6 prefix while lauching 958 attack, and it is easy to close such attacks. 960 o Packets may pass through choke point(s), namely a 6to4 relay. In 961 addition to physical limitations, there could be some sort of 962 traffic rate limiting mechanisms which may be implemented, and it 963 could tone down the attack. 965 o For every packet sent, at most one reply packet is generated: 966 there is no amplification factor. 968 Some of the mitigation methods for such attacks are: 970 1. Ingress filtering in the IPv4 Internet to prevent packets with 971 spoofed IPv4 source being transmitted. As the relay checks that 972 the 6to4 address embeds the IPv4 address, no spoofing can be 973 achieved done unless IPv4 addresses can be spoofed. 975 2. Security checks in the 6to4 relay. The 6to4 relay must drop 976 traffic (from 6to4 nodes, or IPv4 nodes) that has non-6to4 977 addresses as source address, or where the source IPv4 address 978 does not match the address embebdded in the source IPv6 address. 980 COMPARISON TO SITUATION WITHOUT 6to4 982 Compared to Section 4.1.2, which is more serious, this threat appears 983 to be slightly more manageable. If the relays perform proper 984 decapsulation checks, the spoofing can only be achived, to a 6to4 985 source address, when IPv4 address is spoofable as well. 987 4.2.3 Reflecting Traffic to Native IPv6 nodes 989 ATTACK DESCRIPTION 991 These reflection attacks are similar to the one involving 6to4 992 routers as described in Section 4.1.3. Traffic may be reflected off 993 native IPv6 nodes, or 6to4 nodes. The attack can be initiated by 994 either: 996 o Native IPv6 nodes. These nodes can send invalid traffic with 997 spoofed native IPv6 addresses to valid 6to4 nodes. Replies from 998 the 6to4 nodes are part of a reflection attack. 1000 o IPv4 nodes. These nodes can send traffic with native IPv6 source 1001 addresses (encapsulated by the IPv4 node itself into a protocol-41 1002 packet) to 6to4 nodes. Replies from the 6to4 nodes are part of a 1003 reflection attack. 1005 o 6to4 nodes. These nodes can perform similar attacks to the ones 1006 by IPv4 nodes, but that would require spoofing of the source 1007 address at the 6to4 site before encapsulation; that is likely to 1008 be difficult. 1010 When launched from a native IPv6 node, the traffic goes through 6to4 1011 relays twice, both after and before the reflection; when launched 1012 from a 6to4/IPv4 node, the traffic goes through a relay only after 1013 the reflection. 1015 EXTENSIONS 1017 A distributed Reflection DoS can be performed if a large number of 1018 native IPv6 nodes or IPv4/6to4 nodes are involved in sending spoofed 1019 traffic with the same source IPv6 address. 1021 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 1023 Some of the mitigation methods for such attacks are: 1025 1. Attacks from the native IPv6 nodes could be stopped by 1026 implementing ingress filtering in the IPv6 Internet. 1028 2. Two measures are needed to stop or mitigate the attacks from IPv4 1029 nodes: 1) Implementing ingress filtering in the IPv4 internet, 1030 and 2) logging IPv4 source address in the 6to4 router. 1032 3. Attacks from 6to4 nodes in other sites can be stopped if the 6to4 1033 router in those sites implements egress filtering. 1035 4. The traffic passes through one or two relays, and traffic rate 1036 limiting in the 6to4 relays might help tone down the reflection 1037 attack. 1039 COMPARISON TO SITUATION WITHOUT 6to4 1041 Even thought there are means to mitigate the attack, it is still 1042 rather efficient, especially when used by native IPv6 nodes with 1043 spoofed addresses. Using 6to4 relays and routers could easily take 1044 down the 6to4 relay system and/or provide an easy means for traffic 1045 laundering. However, if the intent of the attack is just to DoS the 1046 victim, it can be achieved more smoothly by doing it directly (as the 1047 source address spoofing was available as well). 1049 Therefore, the threat seems to be higher to the availability and 1050 stability of the 6to4 relay system itself than to native IPv6 1051 Internet. 1053 4.2.4 Local IPv4 Broadcast Attack 1055 This attack is similar to the ones employed against 6to4 routers as 1056 described in Section 4.1.4. There are slight differences with regard 1057 to the source of the attacks. This attack can be initiated by: 1059 o Native IPv6 nodes that may send traffic to the relay's subnet 1060 broadcast address. 1062 o IPv4 nodes that may send traffic with spoofed source IP address 1063 (to be the relay's broadcast address) to elicit replies (e.g., 1064 ICMPv6 Hop Limit Exceeded messages) from the 6to4 relay to its 1065 local nodes. 1067 The first is more dangerous than in Section 4.1.4 because it can be 1068 initiated by any IPv6 node (which is allowed to use the relay, that 1069 is), not limited to local users. 1071 The second is trickier and not really useful. For it to succeed, the 1072 relay would have to accept native source addresses over the 6to4 1073 pseudo-interface (but we did not assume this check was implemented), 1074 as if coming from another relay, and trigger an ICMPv6 message to the 1075 relay's local IPv4 subnet. The former method is more lucrative. 1077 EXTENSIONS 1079 None. 1081 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 1083 The threat is restricted to the relay's local subnet, and is fixed by 1084 tightening the 6to4 security checks. 1086 COMPARISON TO SITUATION WITHOUT 6to4 1088 This scenario is caused by 6to4, but fortunately, the issue is not 1089 serious. 1091 4.2.5 Theft of Service 1093 ATTACK DESCRIPTION 1095 The 6to4 relay administrators would often want to use some policy to 1096 limit the use of the relay to specific 6to4 sites and/or specific 1097 IPv6 sites. 1099 The policy control is usually done by applying restrictions to where 1100 the routing information for 2002::/16 and/or 192.188.99.0/24 (if the 1101 anycast address used [3]) will spread. 1103 Some users may be able to use the service regardless of these 1104 controls, by: 1106 o Configuring the address of the relay using its IPv4 address 1107 instead of 192.88.99.1, or 1109 o Using the Routing header to route IPv6 packets to reach specific 1110 6to4 relays. (Some other routing tricks like using static routes 1111 may also be used.) 1113 EXTENSIONS 1115 None. 1117 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 1119 Attempts to use the relay's IPv4 address instead of 192.88.99.1 can 1120 be mitigated in the following ways: 1122 1. IPv4 domains should prevent usage of the actual IPv4 address of 1123 the relay instead of 192.88.99.1. 1125 2. Usage of access lists in the 6to4 relay to limit access. This is 1126 only feasible if the number of IP networks the relay is supposed 1127 to serve is relatively low. 1129 3. The 6to4 relay should filter out arriving tunneled packets with 1130 protocol 41 (IPv6) which do not have the the 192.88.99.1 as the 1131 destination address. 1133 The other threat of using routing tricks in the IPv6 networks to 1134 reach the 6to4 relay has similar solutions: 1136 1. Usage of access lists in the relay to limit access. 1138 2. Filtering out the packets with a routing header (may have other 1139 implications). 1141 3. Monitoring the source addresses going through the relay, to 1142 detect e.g. peers setting up static routes. 1144 Routing Header is not specific to 6to4, the main things one could do 1145 here with it would be to select the relay; some generic threats about 1146 Routing Header use are described in [10]. 1148 As this threat does not have implications on other than the 1149 organization providing 6to4 relay, it is not analyzed any further. 1151 COMPARISON TO SITUATION WITHOUT 6to4 1153 These threats are specific to 6to4 relays (or in general, anycast 1154 services), and do not exist in networks without 6to4. 1156 4.2.6 Relay Operators Seen as Source of Abuse 1158 ATTACK DESCRIPTION 1160 There are several attacks which use 6to4 relays to anonymize the 1161 traffic; this often results in packets being tunneled from the relay 1162 to a supposedly-6to4 site. 1164 However, as was already pointed out in Section 4.2, the IPv4 source 1165 address used by the relay could, cursorily looking, be seen as the 1166 source of these "protocol-41" attacks. 1168 This could cause a number of concerns for the operators deploying 1169 6to4 relay service. For example: 1171 o Getting contacted a lot (via email, phone, fax, or lawyers) on 1172 suspected "abuse", 1174 o Getting the whole IPv4 address range rejected as a source of abuse 1175 or spam, causing outage to other operations as well, or 1177 o Causing the whole IPv4 address range to be to be blacklisted in 1178 some "spammer databases", if the relay would be used for those 1179 purposes. 1181 This threat seems slightly similar (but more generic) to the outburst 1182 of SMTP abuse caused by open relays. 1184 EXTENSIONS 1186 None. 1188 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 1190 This problem can be avoided (or really, "made someone else's 1191 problem") by using the 6to4 anycast address in 192.88.99.0/24 as the 1192 source address: blacklisting or rejecting that should not cause 1193 problems to the other operations. 1195 Further, when someone is filing complaints to the owner of 1196 192.88.99.0/24, they notice multiple WHOIS records and see a pointer 1197 to [3], and may learn that the 6to4 relay is in fact innocent. Of 1198 course, this could result in these reports going to the closest 1199 anycast 6to4 relay as well, which in fact had nothing to do with the 1200 incident. 1202 However, the wide-spread usage of 192.88.99.1 as the source address 1203 may make it more difficult to disambiguate the relays, which might be 1204 a useful feature for debugging purposes. 1206 COMPARISON TO SITUATION WITHOUT 6to4 1208 This threat is caused by 6to4 deployment, but can be avoided, at 1209 least in the short-term, by using the use of 192.88.99.1 as the 1210 source address. 1212 4.3 Attacks on IPv4 Internet 1214 There are two types of attacks on the IPv4 internet - spoofed 1215 traffic, and reflection. They can be initiated by native IPv6 nodes, 1216 6to4 nodes, and IPv4 nodes. 1218 Attacks initiated by IPv4 nodes that send spoofed traffic that will 1219 not utilize the 6to4 infrastructure are considered out of scope of 1220 this document. 6to4 infrastructure may be utilized in reflection 1221 attacks that are initiated by IPv4 nodes. 1223 It is difficult for these attacks to be effective as the traffic sent 1224 out will be IPv6-in-IPv4. Such traffic will be rejected by most IPv4 1225 nodes unless they have implemented some sort of IPv6-in-IPv4 1226 tunneling. 1228 4.4 Summary of the Attacks 1230 Columns: 1232 o Section number. The section that describes the attack. 1234 o Attack name. 1236 o Initiator. The node that initiates the attack. 1238 * I_4 - IPv4 node 1240 * I_6 - native IPv6 node 1242 * 6to4 - 6to4 node 1244 * * - All of the above 1246 o Victim. The victim node 1248 * I_4 - IPv4 node 1250 * I_6 - native IPv6 node 1252 * 6to4 - 6to4 node 1254 * Relay - 6to4 relay 1256 * Router - 6to4 router 1258 o ToA. Type of Attack 1260 * D - DoS 1262 * R - Reflection DoS 1264 * T - Theft of Service 1266 o Fix. Specified who is responsible for fixing the attack. 1268 * 6 - The 6to4 developer and/or operator can completely mitigate 1269 this attack. 1271 * 6* - The 6to4 developer and/or operator can partially mitigate 1272 this attack. 1274 * E - This threat cannot be fixed by the 6to4 developer or the 1275 6to4 operator. 1277 Summary of attacks on a 6to4 network: 1279 +-------+----------------------+---------+----------+-----+-----+ 1280 | Sec | Attack name |Initiator| Victim | ToA | Fix | 1281 +-------+----------------------+---------+----------+-----+-----+ 1282 | 4.1.1 | Attacks with ND | I_4 | Router | D | 6 | 1283 +-------+----------------------+---------+----------+-----+-----+ 1284 | 4.1.2 | Spoofing Traffic | I_4,I_6 | 6to4 | D | E | 1285 +-------+----------------------+---------+----------+-----+-----+ 1286 | 4.1.3 | Reflection Attacks | * | 6to4 | R | 6* | 1287 +-------+----------------------+---------+----------+-----+-----+ 1288 | 4.1.4 | Local IPv4 Broadcast | * | Router | D | 6 | 1289 +-------+----------------------+---------+----------+-----+-----+ 1291 Figure 9 1293 Summary of attacks on the native IPv6 internet: 1295 +-------+----------------------+---------+----------+-----+-----+ 1296 | Sec | Attack name |Initiator| Victim | ToA | Fix | 1297 +-------+----------------------+---------+----------+-----+-----+ 1298 | 4.2.1 | Attacks with ND | I_4 | Relay | D | 6 | 1299 +-------+----------------------+---------+----------+-----+-----+ 1300 | 4.2.2 | Spoofing Traffic | I_4,6to4| I_6 | D | 6* | 1301 +-------+----------------------+---------+----------+-----+-----+ 1302 | 4.2.3 | Reflection Attacks | * | I_6 | R | 6* | 1303 +-------+----------------------+---------+----------+-----+-----+ 1304 | 4.2.4 | Local IPv4 Broadcast | * | Relay | D | 6 | 1305 +-------+----------------------+---------+----------+-----+-----+ 1306 | 4.2.5 | Theft of Service | 6to4 | Relay | T | 6 | 1307 +-------+----------------------+---------+----------+-----+-----+ 1308 | 4.2.6 | Relay Operators ... | - | - | D | 1) | 1309 +-------+----------------------+---------+----------+-----+-----+ 1311 Figure 10 1313 Notes: 1315 1) This attack is a side-effect of the other attacks, and thus does 1316 not have any Initiator, Victim, and Fix. It is a Denial of Service 1317 attack not on the network but on the organization in-charge of the 1318 relay. 1320 Summary of attacks on IPv4 internet: 1322 +-------+----------------------+---------+----------+-----+-----+ 1323 | Sec | Attack name |Initiator| Victim | ToA | Fix | 1324 +-------+----------------------+---------+----------+-----+-----+ 1325 | 4.3 | Spoofing Traffic | * | I_4 | D | 6* | 1326 +-------+----------------------+---------+----------+-----+-----+ 1327 | 4.3 | Reflection Attacks | * | I_4 | R | 6* | 1328 +-------+----------------------+---------+----------+-----+-----+ 1330 Figure 11 1332 5. Implementing Proper Security Checks in 6to4 1334 In this section, several ways to implement the security checks 1335 required or implied by the specification [1] or augmented by this 1336 memo are described. These do not, in general, protect against the 1337 majority of the threats listed above in the "Threat Analysis" 1338 section. They're just prerequisites for a relatively safe and simple 1339 6to4 implementation. 1341 Note that in in general, the 6to4 router or relay does not know 1342 whether it is acting as a router or relay. It would be possible to 1343 include a toggle to specify the behaviour, to be used e.g., when the 1344 interface is brought up, but at least in February 2004, no 1345 implementations were known to do that. Due to that, the checks are 1346 described as one -- which works independent of whether the node is a 1347 router or relay. 1349 5.1 Encapsulating IPv6 into IPv4 1351 The checks described in this section are to be performed when 1352 encapsulating IPv6 into IPv4. 1354 The encapsulation rules are mainly designed to keep one from 1355 "shooting yourself on the foot" -- for example, the source address 1356 check verifies that the packet will be acceptable to the 1357 decapsulator, or the sanity checks ensure that addresses derived from 1358 private addresses are not used (which would be equally unacceptable). 1360 src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below) else drop 1361 if prefix (src_v6) == 2002::/16 1362 ipv4 address embedded in src_v6 MUST match src_v4 1363 else if prefix (dst_v6) == 2002::/16 1364 dst_v4 SHOULD NOT be assigned to the router 1365 else 1366 drop 1367 /* we somehow got a native-native ipv6 packet */ 1368 fi 1369 accept 1371 5.2 Decapsulating IPv4 into IPv6 1373 The checks described in this section are to be performed when 1374 decapsulating IPv4 into IPv6. They will be performed in both the 1375 6to4 router and relay. 1377 src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop 1378 src_v6 and dst_v6 MUST pass ipv6-sanity checks, else drop 1379 if prefix (dst_v6) == 2002::/16 1380 ipv4 address embedded in dst_v6 MUST match dst_v4 1381 if prefix (src_v6) == 2002::/16 1382 ipv4 address embedded in src_v6 MUST match src_v4 1383 dst_v4 SHOULD be assigned to the router 1384 fi 1385 elif prefix (src_v6) == 2002::/16 1386 ipv4 address embedded in src_v6 MUST match src_v4 1387 dst_v4 SHOULD be assigned to the router (see notes below) 1388 else 1389 drop 1390 /* the we somehow got a native-native ipv6 packet */ 1391 fi 1392 accept 1394 5.3 IPv4 and IPv6 Sanity Checks 1396 The encapsulation and decapsulation checks included certain sanity 1397 checks for both IPv4 and IPv6. These are described here in detail. 1399 5.3.1 IPv4 1401 IPv4 address MUST be a global unicast address, as required by the 1402 6to4 specification. The disallowed addresses include those defined 1403 in [13], and others widely used and known not to be global. These 1404 are: 1406 o 0.0.0.0/8 (the system has no address assigned yet) 1408 o 10.0.0.0/8 (private) 1410 o 127.0.0.0/8 (loopback) 1412 o 172.16.0.0/12 (private) 1414 o 192.168.0.0/16 (private) 1416 o 169.254.0.0/16 (IANA Assigned DHCP link-local) 1418 o 224.0.0.0/4 (multicast) 1420 o 240.0.0.0/4 (reserved and broadcast) 1422 In addition, the address MUST NOT be any of the system's broadcast 1423 addresses. This is especially important if the implementation is 1424 made so that it can: 1426 o receive and process encapsulated IPv4 packets arriving at its 1427 broadcast addresses, or 1429 o send encapsulated IPv4 packets to one of its broadcast addresses. 1431 5.3.2 IPv6 1433 IPv6 address MUST NOT be: 1435 o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...) 1437 o fe80::/10 (link-local) 1439 o fec0::/10 (site-local) 1441 o ff00::/8 (any multicast) 1443 Note: only link-local multicast would be strictly required, but it is 1444 believed that multicast with 6to4 will not be feasible, so it has 1445 been disallowed as well. 1447 In addition, it MUST be checked that equivalent 2002:V4ADDR::/48 1448 checks, where V4ADDR is any of the above IPv4 addresses, will not be 1449 passed. 1451 5.3.3 Optional Ingress Filtering 1453 In addition, the implementation in the 6to4 router may perform some 1454 form of ingress filtering (e.g. Unicast Reverse Path Forwarding 1455 checks). For example, if the 6to4 router has multiple interfaces, of 1456 which some are "internal", receiving either IPv4 or IPv6 packets with 1457 source address belonging to any of these internal networks from the 1458 Internet might be disallowed. 1460 If these checks are implemented, and are enabled by default, it's 1461 recommended that there is a toggle to disable them if needed. 1463 5.3.4 Notes About the Checks 1465 The rule "dst_v4 SHOULD be assigned to the router" is not needed if 1466 the 6to4 router implementation only accepts and processes 1467 encapsulated IPv4 packets arriving its unicast IPv4 addresses, and 1468 when destination address is known to be a local broadcast address, it 1469 does not try to encapsulate and send packets to it. (see Section 1470 4.1.4, and Section 4.2.4 about this threat). 1472 Some checks, especially the IPv4/IPv6 Sanity Checks, could be at 1473 least partially implementable with system-level access lists, if one 1474 would like to avoid placing too many restrictions in the 6to4 1475 implementation itself. This depends on how many hooks for the access 1476 lists are in place. In practice it seems that this could not be done 1477 effectively enough unless the access list mechanism is able to parse 1478 the encapsulated packets. 1480 6. Issues in 6to4 Implementation and Use 1482 This section tries to give an overview of some of the problems 6to4 1483 implementations are faced with, and the kind of generic problems the 1484 6to4 users could come up with. 1486 6.1 Implementation Considerations with Automatic Tunnels 1488 There is a problem with multiple transition mechanisms if strict 1489 security checks are implemented. This may vary a bit from 1490 implementation to implementation. 1492 Consider three mechanisms using automatic tunneling: 6to4, ISATAP 1493 [14] and Automatic Tunneling using Compatible Addresses [4] 1494 (currently removed [9] but typically still supported). All of these 1495 use IP-IP (protocol 41) [15] IPv4 encapsulation with, more or less, a 1496 pseudo-interface. 1498 When a router, which has any two of these enabled, receives an IPv4 1499 encapsulated IPv6 packet: 1501 src_v6 = 2001:db8::1 1502 dst_v6 = 2002:1010:1010::2 1503 src_v4 = 10.0.0.1 1504 dst_v4 = 20.20.20.20 1506 What can it do? How should it decide which transition mechanism this 1507 belongs to; there is no "transition mechanism number" in IPv6 or IPv4 1508 header to signify this. (This can also be viewed as a flexibility 1509 benefit.) 1511 Without any kind of security checks (in any of implemented methods) 1512 these often just "work" as the mechanisms aren't differentiated but 1513 handled in "one big lump". 1515 Configured tunneling [4] does not suffer from this as it is 1516 point-to-point, and based on src_v6/dst_v6 pairs of both IPv4 and 1517 IPv6 addresses it can be deduced which logical tunnel interface is in 1518 the question. 1520 Solutions for this include 1) not using more than one automatic 1521 tunneling mechanism in a node or 2) binding different mechanisms to 1522 different IPv4 addresses. 1524 6.2 A Different Model for 6to4 Deployment 1526 Even though this was already discussed in Section 4.1.2, it bears 1527 some additional elaboration as it was the only problem which cannot 1528 be even partially solved using the current deployment model -- but 1529 there are some mitigation methods. 1531 That is, 6to4 routers receive traffic from non-6to4 ("native") 1532 sources via 6to4 relays. 6to4 routers have no way of matching IPv4 1533 source address of the relay with non-6to4 IPv6 address of the source. 1534 Consequently, anyone can spoof any non-6to4 IPv6 address he wants by 1535 sending traffic, encapsulated, directly to 6to4 routers. 1537 It could be possible to turn the deployment assumptions of 6to4 1538 around a bit to eliminate some threats caused by untrusted 6to4 1539 relays. That is: 1541 o Every dual-stack site (or even ISP) would be required to have 1542 their own 6to4 relay. (This assumes that IPv6-only is so long 1543 away that 6to4 would be hopefully retired at that point.) That 1544 is, there would not be third-party relays, and 2002::/16 and 1545 192.88.99.0/24 routes would not need to be advertised globally, 1546 and 1548 o The security implications of 6to4 use could be pushed back to the 1549 level of trust inside the site or ISP (or their acceptable use 1550 policies) -- this is something that the sites and ISP's should be 1551 familiar with already. 1553 However, this has a number of problems: 1555 This model would shift the majority of burden of supporting 6to4 to 1556 IPv6 sites which don't employ or use 6to4 at all, i.e., "those who 1557 deploy proper native dual-stack". It could be argued that the 1558 deployment pain should be borne by 6to4 users, not the others. 1560 The main advantage of 6to4 is easy deployment and free relays. This 1561 would require that everyone the 6to4 sites wish to communicate with 1562 implement these measures. 1564 The model would not fix the "relay spoofing problem", unless 1565 everybody deployed also 6to4 addresses on the nodes (alongside with 1566 native addresses, if necessary), which in turn would change 6to4 to 1567 operate without relays completely. 1569 7. Security Considerations 1571 This draft discusses security considerations of 6to4. 1573 Even if proper checks are implemented, there are a large number of 1574 different kind of security threats; these threats are analyzed in 1575 Section 4. 1577 There are mainly three classes of potential problem sources: 1579 1. 6to4 routers not being able to identify whether relays are 1580 legitimate, 1582 2. Wrong or impartially implemented 6to4 router or relay security 1583 checks, 1585 3. 6to4 architecture used to participate in DoS or reflected DoS 1586 attacks, or made to participate in "packet laundering", i.e., 1587 making another attack harder to trace, or 1589 4. 6to4 relays being subject to "administrative abuse", e.g., theft 1590 of service, or being seen as a source of abuse. 1592 The first is the toughest problem, still under research. The second 1593 can be fixed by ensuring the correctness of implementations; this is 1594 important. The third is also a very difficult problem, and 1595 impossible to solve completely -- therefore it is important to be 1596 able to analyze whether this results in a significant increase of 1597 threats. The fourth problem seems to have feasible solutions. 1599 These are analyzed in detail in Threat Analysis, in Section 4. 1601 8. IANA Considerations 1603 This memo makes no requet to IANA. (RFC-editor note: please remove 1604 this section on publication.) 1606 9. Acknowledgments 1608 Some issues were first brought up by Itojun Hagino in [16], and Alain 1609 Durand introduced one specific problem at IETF51 in August 2001 1610 (though there was some discussion on the list prior to that); these 1611 gave the author the push to start looking into the details of 1612 securing 6to4. 1614 Alexey Kuznetsov brought up the implementation problem with IPv6 1615 martian checks. Christian Huitema formulated the rules that rely on 1616 6to4 relays using only anycast. Keith Moore brought up the point 1617 about reduced flexibility. Brian Carpenter, Tony Hain and Vladislav 1618 Yasevich are acknowledged for lengthy discussions. Alain Durand 1619 reminded of relay spoofing problems. Brian Carpenter reminded of the 1620 BGP-based 6to4 router model. Christian Huitema gave a push to a more 1621 complete threat analysis. Itojun Hagino spelled out the operators' 1622 fears about 6to4 relay abuse. Rob Austein brought up the idea of a 1623 different 6to4 deployment model. 1625 In the latter phase, especially discussions with Christian Huitema, 1626 Brian Carpenter and Alain Durand were helpful when improving the 1627 document. 1629 David Malone, Iljitsch van Beijnum, and Tim Chown gave feedback on 1630 the document. 1632 10. References 1634 10.1 Normative References 1636 [1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 1637 Clouds", RFC 3056, February 2001. 1639 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1640 Levels", BCP 14, RFC 2119, March 1997. 1642 [3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 1643 3068, June 2001. 1645 10.2 Informative References 1647 [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 1648 Hosts and Routers", RFC 2893, August 2000. 1650 [5] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 1651 RFC 1771, March 1995. 1653 [6] Draves, R., "Default Address Selection for Internet Protocol 1654 version 6 (IPv6)", RFC 3484, February 2003. 1656 [7] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 1657 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 1659 [8] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 1660 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 1661 (work in progress), April 2004. 1663 [9] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 1664 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-03 (work in 1665 progress), June 2004. 1667 [10] Savola, P., "Security of IPv6 Routing Header and Home Address 1668 Options", draft-savola-ipv6-rh-ha-security-02 (work in 1669 progress), March 2002. 1671 [11] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1672 Defeating Denial of Service Attacks which employ IP Source 1673 Address Spoofing", BCP 38, RFC 2827, May 2000. 1675 [12] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback 1676 Messages", draft-ietf-itrace-04 (work in progress), February 1677 2003. 1679 [13] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 1680 June 1995. 1682 [14] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site 1683 Automatic Tunnel Addressing Protocol (ISATAP)", 1684 draft-ietf-ngtrans-isatap-22 (work in progress), May 2004. 1686 [15] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. 1688 [16] Hagino, J., "Possible abuse against IPv6 transition 1689 technologies", draft-itojun-ipv6-transition-abuse-01.txt 1690 (expired, work-in-progress) , July 2000. 1692 Authors' Addresses 1694 Pekka Savola 1695 CSC/FUNET 1696 Espoo 1697 Finland 1699 EMail: psavola@funet.fi 1701 Chirayu Patel 1702 All Play, No Work 1703 185, Defence Colony 1704 Bangalore, Karnataka 560038 1705 India 1707 Phone: +91-98452-88078 1708 EMail: chirayu@chirayu.org 1709 URI: http://www.chirayu.org 1711 Appendix A. Some Trivial Attack Scenarios Outlined 1713 Here, a few trivial attack scenarios are outlined -- ones that are 1714 prevented by implementing checks listed in [1] or in section 6. 1716 When two 6to4 routers send traffic to each others' domains, packet 1717 sent by RA to RB is like (note: addresses from 8.0.0.0/24 are just 1718 examples of global IPv4 addresses): 1720 src_v6 = 2002:0800:0001::aaaa 1721 dst_v6 = 2002:0800:0002::bbbb 1722 src_v4 = 8.0.0.1 (added when encapsulated to IPv4) 1723 dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) 1725 When the packet is received by IPv4 stack on RB, it will be 1726 decapsulated so that only src_v6 and dst_v6 remain, as originally 1727 sent by RA: 1729 src_v6 = 2002:0800:0001::aaaa 1730 dst_v6 = 2002:0800:0002::bbbb 1732 As every other node is just one hop away (IPv6-wise) and the 1733 link-layer (IPv4) addresses are lost, this may open a lot of 1734 possibilities for misuse. 1736 As an example, unidirectional IPv6 spoofing is made trivial because 1737 nobody can check (without delving into IP-IP packets) whether the 1738 encapsulated IPv6 addresses were authentic (With native IPv6, this 1739 can be done by e.g., RPF-like mechanisms or access lists in upstream 1740 routers). 1742 src_v6 = 2002:1234:5678::aaaa (forged) 1743 dst_v6 = 2002:0800:0002::bbbb 1744 src_v4 = 8.0.0.1 (added when encapsulated to IPv4) 1745 dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) 1747 A similar attack with "src" being native address is possible even 1748 with the security checks, by having the sender node pretend to be a 1749 6to4 relay router. 1751 More worries come in to the picture if e.g., 1753 src_v6 = ::ffff:[some trusted IPv4 in a private network] 1754 src_v6/dst_v6 = ::ffff:127.0.0.1 1755 src_v6/dst_v6 = ::1 1756 src_v6/dst_v6 = ... 1758 Some implementations might have been careful enough to have designed 1759 the stack to as to avoid the incoming (or reply) packets going to 1760 IPv4 packet processing through special addresses (e.g., IPv4-mapped 1761 addresses), but who can say for all ... 1763 Appendix B. Change Log 1765 [[ RFC-EDITOR note: to be removed before publication ]] 1767 Changes from -02 to -03 1769 1. Only rather minor editorial changes. 1771 Changes from -01 to -02 1773 1. Incorporate Iljitsch's feedback 1775 2. Clean up section 6.2 1777 3. Fix encapsulation code (had been munged in -01) 1779 Changes from -00 to -01 1781 1. Lots of editorial changes in other sections 1783 2. Revamped the "Threat Analysis" section completely; ripple the 1784 effects elsewhere in the document as well. 1786 3. Added Chirayu Patel as a co-author. 1788 Intellectual Property Statement 1790 The IETF takes no position regarding the validity or scope of any 1791 Intellectual Property Rights or other rights that might be claimed to 1792 pertain to the implementation or use of the technology described in 1793 this document or the extent to which any license under such rights 1794 might or might not be available; nor does it represent that it has 1795 made any independent effort to identify any such rights. Information 1796 on the procedures with respect to rights in RFC documents can be 1797 found in BCP 78 and BCP 79. 1799 Copies of IPR disclosures made to the IETF Secretariat and any 1800 assurances of licenses to be made available, or the result of an 1801 attempt made to obtain a general license or permission for the use of 1802 such proprietary rights by implementers or users of this 1803 specification can be obtained from the IETF on-line IPR repository at 1804 http://www.ietf.org/ipr. 1806 The IETF invites any interested party to bring to its attention any 1807 copyrights, patents or patent applications, or other proprietary 1808 rights that may cover technology that may be required to implement 1809 this standard. Please address the information to the IETF at 1810 ietf-ipr@ietf.org. 1812 Disclaimer of Validity 1814 This document and the information contained herein are provided on an 1815 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1816 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1817 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1818 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1819 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1820 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1822 Copyright Statement 1824 Copyright (C) The Internet Society (2004). This document is subject 1825 to the rights, licenses and restrictions contained in BCP 78, and 1826 except as set forth therein, the authors retain all their rights. 1828 Acknowledgment 1830 Funding for the RFC Editor function is currently provided by the 1831 Internet Society.