idnits 2.17.1 draft-ietf-v6ops-6to4-security-04.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 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1846. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1852. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1868), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 40 longer pages, the longest (page 28) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 41 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 (July 18, 2004) is 7216 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 3330 (ref. '5') (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 1771 (ref. '6') (Obsoleted by RFC 4271) -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '7') (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 (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops Working Group P. Savola 3 Internet-Draft CSC/FUNET 4 Expires: January 16, 2005 C. Patel 5 All Play, No Work 6 July 18, 2004 8 Security Considerations for 6to4 9 draft-ietf-v6ops-6to4-security-04.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 16, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 The IPv6 interim mechanism 6to4 (RFC3056) uses automatic 45 IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The 46 architecture includes 6to4 routers and 6to4 relay routers, which 47 accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from 48 any node in the IPv4 internet. This characteristic enables a number 49 of security threats, mainly Denial of Service. It also makes it 50 easier for nodes to spoof IPv6 addresses. This document discusses 51 these issues in more detail and suggests enhancements to alleviate 52 the problems. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 5 58 2.1 From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . . 5 59 2.2 From Native to 6to4 . . . . . . . . . . . . . . . . . . . 6 60 2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . . . 6 61 2.4 Other Models . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.4.1 BGP Between 6to4 Routers and Relays . . . . . . . . . 7 63 2.4.2 6to4 as an Optimization Method . . . . . . . . . . . . 7 64 2.4.3 6to4 as Tunnel End-Point Addressing Mechanism . . . . 8 65 3. Functionalities of 6to4 Network Components . . . . . . . . . . 9 66 3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . . 11 68 4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . . . 13 70 4.1.1 Attacks with ND Messages . . . . . . . . . . . . . . . 13 71 4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . . . . 15 72 4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . . . . 17 73 4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 19 74 4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . . . 21 75 4.2.1 Attacks with ND Messages . . . . . . . . . . . . . . . 21 76 4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . . . . 21 77 4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . . . . 23 78 4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 24 79 4.2.5 Theft of Service . . . . . . . . . . . . . . . . . . . 25 80 4.2.6 Relay Operators Seen as Source of Abuse . . . . . . . 26 81 4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . . . 28 82 4.4 Summary of the Attacks . . . . . . . . . . . . . . . . . . 28 83 5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 30 84 5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . . 31 85 5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . . 31 86 5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . . 32 87 5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32 88 5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 33 89 5.3.3 Optional Ingress Filtering . . . . . . . . . . . . . . 33 90 5.3.4 Notes About the Checks . . . . . . . . . . . . . . . . 33 91 6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 34 92 6.1 Implementation Considerations with Automatic Tunnels . . . 34 93 6.2 A Different Model for 6to4 Deployment . . . . . . . . . . 35 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 98 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 37 99 10.2 Informative References . . . . . . . . . . . . . . . . . . . 37 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 38 101 A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 39 102 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40 103 Intellectual Property and Copyright Statements . . . . . . . . 41 105 1. Introduction 107 The IPv6 interim mechanism "6to4" [1] specifies automatic 108 IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by 109 embedding the tunnel IPv4 address in the IPv6 6to4 prefix. 111 Two characteristics of the 6to4 mechanism introduce most of the 112 security considerations: 114 1. All 6to4 routers must accept and decapsulate IPv4 packets from 115 every other 6to4 router, and 6to4 relays. 117 2. 6to4 relay routers must accept traffic from any native IPv6 node. 119 Since the 6to4 router must accept traffic from any other 6to4 router 120 or relay, a certain requirement for trust is implied, and there are 121 no strict constraints on what the IPv6 packet may contain. Thus, 122 addresses within the IPv4, and IPv6 header may be spoofed, and this 123 property leads to various types of threats including different 124 flavors of Denial of Service -attacks. 126 The 6to4 specification outlined a few security considerations and 127 rules, but was very ambiguous on their exact requirement level. 128 Further, the description of the considerations was rather short, and 129 in fact, some of them have been proven to be difficult to understand 130 or impossible to implement. 132 This draft analyzes the 6to4 security issues in more detail and 133 outlines some enhancements and caveats. 135 Section 2, and Section 3 are more or less introductory in nature, 136 rehashing how 6to4 is used today based on the 6to4 specification, so 137 that it is easier to understand how security could be affected. 138 Section 4 provides a threat analysis for implementations that already 139 implement most of the security checks. Section 5 describes the 140 optimal decapsulation/encapsulation rules for 6to4 implementations, 141 and Section 6 provides further discussion on a few issues which have 142 proven to be difficult to implement. Appendix A outlines a few 143 possible trivial attack scenarios in the case that very little or no 144 security has been implemented. 146 For the sake of simplicity, in this document, the native Internet is 147 assumed to encompass IPv6 networks formed using other transition 148 mechanisms (e.g. RFC 2893 [4]), as these mechanisms cannot talk 149 directly to the 6to4 network. 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [2]. 155 Throughout this memo, IPv4 addresses from blocks 7.0.0.0/24, 8.0.0.0/ 156 24 and 9.0.0.0/24 are used for demonstrative purposes, to represent 157 global IPv4 addresses which have no relation to each other. This 158 approach was chosen instead of just using addresses from 192.0.2.0/24 159 [5] for two reasons: to use addresses whose 6to4 mapping is 160 blindingly obvious, and to make it obvious that the IPv4 addresses of 161 different 6to4 gateways do not have to have any relation to each 162 other. 164 2. Different 6to4 Forwarding Scenarios 166 It should be noted that when communicating between 6to4 and native 167 domains, the 6to4 relays that will be used in the two directions are 168 very likely different; routing is highly asymmetric. Because of 169 this, it is not feasible to limit relays from which 6to4 routers may 170 accept traffic. 172 The first three subsections introduce the most common forms of 6to4 173 operation. Other models are presented in the fourth subsection. 175 2.1 From 6to4 to 6to4 177 6to4 domains always exchange 6to4 traffic directly via IPv4 178 tunneling; the endpoint address V4ADDR is derived from 6to4 prefix 179 2002:V4ADDR::/48 of the destination. 181 .--------. _----_ .--------. 182 | 6to4 | _( IPv4 )_ | 6to4 | 183 | router | <====> ( Internet ) <===> | router | 184 '--------' (_ _) '--------' 185 ^ '----' ^ 186 | Direct tunneling over IPv4 | 187 V V 188 .--------. .-------. 189 | 6to4 | | 6to4 | 190 | host | | host | 191 '--------' '--------' 193 Figure 1 195 It is required that every 6to4 router considers every other 6to4 196 router it wants to talk to to be "on-link" (with IPv4 as the 197 link-layer). 199 2.2 From Native to 6to4 201 When native domains send traffic to 6to4 prefix 2002:V4ADDR::/48, it 202 will be routed to the topologically nearest, advertising (advertising 203 route to 2002::/16) 6to4 relay. The 6to4 relay will tunnel the 204 traffic over IPv4 to the corresponding IPv4 address V4ADDR. 206 Note that IPv4 address 9.0.0.1 here is just an example of a global 207 IPv4 address, and it is assigned to the 6to4 router's 208 pseudo-interface. 210 Closest to 211 "Native IPv6 node" 212 .--------. _----_ .------------. .--------. 213 | Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 | 214 | IPv6 | -> ( Internet ) --> | router | =========> | router | 215 | node | (_ _) '------------' 9.0.0.1 '--------' 216 '--------' '----' dst_v6=2002:0900:0001::1 | 217 V 218 .-------. 219 | 6to4 | 220 | host | 221 '--------' 223 Figure 2 225 2.3 From 6to4 to Native 227 6to4 domains send traffic to native domains by tunneling it over IPv4 228 to their configured 6to4 relay router, or the closest one found using 229 6to4 IPv4 Anycast [3]. The relay will decapsulate the packet and 230 forward it to native IPv6 Internet, the same way as any other IPv6 231 packet. 233 Note that destination IPv6 address in the packet is a non-6to4 234 address, and is assumed to be 2001:db8::1 in the example. 236 Configured 237 -or- 238 found by IPv4 Anycast 239 .--------. _----_ .------------. .--------. 240 | Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 | 241 | Client | <- ( Internet ) <-- | router | <========= | router | 242 '--------' (_ _) '------------' 192.88.99.1'--------' 243 2001:db8::1 '----' (or configured) ^ 244 | 245 .-------. 246 | 6to4 | 247 | client | 248 '--------' 250 Figure 3 252 2.4 Other Models 254 These are more or less special cases of 6to4 operations. In later 255 chapters, unless otherwise stated, only the most generally-used 256 models (above) will be considered. 258 2.4.1 BGP Between 6to4 Routers and Relays 260 Section 5.2.2.2 in [1] presents a model where, instead of static 261 configuration, BGP [6] is used between 6to4 relay routers and 6to4 262 routers (for outgoing relay selection only). 264 Going further than [1], if the 6to4 router established a BGP session 265 between all the possible 6to4 relays, and advertised its /48 prefix 266 to them, the traffic from non-6to4 sites would always come from a 267 "known" relay. Alternatively, the 6to4 relays might advertise the 268 more specific 6to4 routes between 6to4 relays. 270 Both of these approaches are more or less obviously infeasible due to 271 scalability issues. 273 Neither of these models are known to be used at the time of writing; 274 this is probably caused by the fact that parties that need 6to4 are 275 those that are not able to run BGP, and because setting up these 276 sessions would be much more work for relay operators. 278 2.4.2 6to4 as an Optimization Method 280 Some sites seem to use 6to4 as an IPv6 connectivity "optimization 281 method"; that is, they have also non-6to4 addresses on their nodes 282 and border routers, but also employ 6to4 to reach 6to4 sites. 284 This is typically done to be able to reach 6to4 destinations by 285 direct tunneling and not having to use relays at all. 287 These sites also publish both 6to4 and non-6to4 addresses in DNS to 288 affect inbound connections; if the source host's default address 289 selection [7] works properly, 6to4 sources will use 6to4 addresses to 290 reach the site and non-6to4 nodes use non-6to4 addresses. If this 291 behavior of foreign nodes can be assumed, the security threats to 292 such sites can be significantly simplified. 294 2.4.3 6to4 as Tunnel End-Point Addressing Mechanism 296 6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel 297 endpoint addressing and routing mechanism. 299 An example of this is interconnecting 10 branch offices where nodes 300 use non-6to4 addresses. Only the offices' border routers need to be 301 aware of 6to4, and use 6to4 addresses solely for addressing the 302 tunnels between different branch offices. An example is provided in 303 the figure below. 305 2001:db8:0:10::/60 2001:db8:0:20::/60 306 .--------. .--------. 307 ( Branch 1 ) ( Branch 2 ) 308 '--------' '--------' 309 | | 310 .--------. _----_ .--------. 311 | 6to4 | _( IPv4 )_ | 6to4 | 312 | router | <====> ( Internet ) <===> | router | 313 '--------' (_ _) '--------' 314 9.0.0.1 '----' 8.0.0.2 315 ^^ 316 || 317 vv 318 .--------. 319 | 6to4 | 7.0.0.3 320 | router | 321 '--------' 322 | 2001:db8::/48 323 .-----------. 324 ( Main Office ) 325 '-----------' 326 ^ 327 | 328 v 329 _----_ 330 _( IPv6 )_ 332 ( Internet ) 333 (_ _) 334 '----' 336 Figure 4 338 In the figure, the main office sets up two routes: 340 2001:db8:0:10::/60 -> 2002:0900:0001::1 342 2001:db8:0:20::/60 -> 2002:0800:0002::1 344 And a branch office sets up two routes as well: 346 2001:db8:0:20::/60 -> 2002:0800:0002::1 348 default -> 2002:0700:0003::1 350 Thus, the IPv4 Internet is treated as NBMA link-layer for 351 interconnecting 6to4-enabled sites; with explicit routes, 6to4 352 addressing need not be used in other than the 6to4 edge routers. 353 However, note that if a branch office sends a packet to any 6to4 354 destination, it will not go through the main office as the 6to4 355 2002::/16 route overrides the default route. 357 This approach may make addressing and routing slightly easier in some 358 circumstances. 360 3. Functionalities of 6to4 Network Components 362 This section summarizes the main functionalities of the 6to4 network 363 components (6to4 routers, and 6to4 relays), and the security checks 364 that must be done by them. The pseudo-code for the security checks 365 is provided in Section 5. 367 This section summarizes the main functions of the various components 368 that are part of a 6to4 network - 6to4 relay routers, and 6to4 369 routers. Refer to Section 1.1 of RFC 3056 [1] for 6to4 related 370 definitions. 372 3.1 6to4 Routers 374 The 6to4 routers acts as the border router of a 6to4 domain. It does 375 not have a native, global IPv6 address except in certain special 376 cases. Since the specification [1] uses the term "6to4 router", this 377 memo does the same; however, note that we also include a single host 378 with a 6to4 pseudo-interface, which doesn't otherwise act as a 379 router, in this definition. The main functions of the 6to4 router 380 are: 382 o Provide IPv6 connectivity to local clients and routers. 384 o Tunnel packets sent to foreign 6to4 addresses to the destination 385 6to4 router using IPv4. 387 o Forward packets sent to locally configured 6to4 addresses to the 388 6to4 network. 390 o Tunnel packets sent to non-6to4 addresses, to the configured/ 391 closest-by-anycast 6to4 relay router. 393 o Decapsulate directly received IPv4 packets from foreign 6to4 394 addresses. 396 o Decapsulate IPv4 packets received via the relay closest to the 397 native IPv6 sources. Note, it is not easily distinguishable that 398 the packet was really received from a 6to4 relay router, not from 399 a spoofing third party. 401 The 6to4 router should also perform security checks on traffic that 402 it will receive from other 6to4 relays, or 6to4 routers, or from 403 within the 6to4 site. These checks include: 405 o Disallow traffic that has private, broadcast or certain specific 406 reserved IPv4 addresses (see Section 5.3.1 for details) in 407 tunnels, or the matching 6to4 prefixes. 409 o Disallow traffic from 6to4 routers where the IPv4 tunnel source 410 address does not match the 6to4 prefix. (Note that the 411 pseudo-interface must pick the IPv4 address corresponding to the 412 prefix when encapsulating, or else problems may ensue on e.g., 413 multi-interface routers.) 415 o Disallow traffic where the destination IPv6 address is not a 416 global address; in particular, e.g. link-local addresses, mapped 417 addresses and such should not be used. 419 o Disallow traffic transmission to other 6to4 domains through 6to4 420 relay router or via some third party 6to4 router. (To avoid 421 transmission to the relay router, the pseudo-interface prefix 422 length must be configured correctly to be /16. Further, to avoid 423 the traffic being discarded, 6to4 source addresses must always 424 correspond to the IPv4 address encapsulating the traffic.) 426 o Discard traffic received from other 6to4 domains via a 6to4 relay 427 router. 429 o Discard traffic received for prefixes other than your own 6to4 430 prefix(es). 432 3.2 6to4 Relay Routers 434 The 6to4 relay router acts as a relay between all 6to4 domains and 435 native IPv6 networks; more specifically: 437 o It advertises the reachability of the 2002::/16 prefix to native 438 IPv6 routing, thus receiving traffic to all 6to4 addresses from 439 closest native IPv6 nodes. 441 o Advertise (if RFC 3068 [3] is implemented) the reachability of 442 IPv4 "6to4 relay anycast prefix" (192.88.99.0/24) to IPv4 routing, 443 thus receiving some tunneled traffic to native IPv6 nodes from 444 6to4 routers. 446 o Decapsulate, and forward packets received from 6to4 addresses 447 through tunneling, using normal IPv6 routing. 449 o Tunnels packets received through normal IPv6 routing from native 450 addresses, and are destined for 2002::/16, to the corresponding 451 6to4 router. 453 The 6to4 relay should also perform security checks on traffic that it 454 will receive from 6to4 routers, or from native IPv6 nodes. These 455 checks are: 457 o Disallow traffic that has private, broadcast or certain specific 458 reserved IPv4 addresses in tunnels, or the matching 6to4 prefixes. 460 o Disallow traffic from 6to4 routers where the IPv4 tunnel source 461 address does not match the 6to4 prefix. (Note that the 462 pseudo-interface must pick the IPv4 address corresponding to the 463 prefix when encapsulating, or else problems may ensue on e.g., 464 multi-interface routers.) 466 o Disallow traffic where the destination IPv6 address is not a 467 global address; in particular, e.g. link-local addresses, mapped 468 addresses and such should not be used. 470 o Discard traffic received from 6to4 routers with the destination as 471 a 6to4 prefix. 473 4. Threat Analysis 475 This section discusses attacks against the 6to4 network or attacks 476 that are caused by the 6to4 network. The threats are discussed in 477 light of the 6to4 deployment models defined in Section 2. 479 There are three general types of threats: 481 1. Denial-of-Service (DoS) attacks, in which a malicious node 482 prevents communication between the node under attack and other 483 nodes. 485 2. Reflection Denial-of-Service (DoS) attacks, in which a malicious 486 node reflects the traffic off unsuspecting nodes to a particular 487 node (node under attack) with the intent of preventing 488 communication between the node under attack and other nodes. 490 3. Service theft, in which a malicious node/site/operator may make 491 unauthorized use of service. 493 6to4 also provides a means for a "meta-threat", traffic laundering, 494 in which some other attack is channeled through the third parties to 495 make it more difficult to trace the real origin of the attack. This 496 is used in conjunction with other threats, whether specific to 6to4 497 or not. 499 At this point it is important to reiterate that the attacks are 500 possible because: 502 1. 6to4 routers have to consider all 6to4 relays, and other 6to4 503 routers as "on-link". 505 2. 6to4 relays have to consider all 6to4 routers as "on-link". 507 3. Partial implementation of the security checks in the 6to4 508 implementation. It has been discovered that at least a couple of 509 major implementations do not implement all the checks. 511 The attacks descriptions are classified based on the target of the 512 attack: 514 1. Attacks on 6to4 networks. 516 2. Attacks on IPv6 networks. 518 3. Attacks on IPv4 networks. 520 Note, one of the mitigation methods listed for various attacks is 521 based on the premise that 6to4 relays could have a feature that may 522 be able to limit traffic to/from specific 6to4 sites. At the time of 523 writing this document, such a feature is speculation, and more work 524 needs to be done to determine the logistics of such a feature. 526 4.1 Attacks on 6to4 Networks 528 This section describes attacks against 6to4 networks. Attacks which 529 leverage 6to4 networks, but where the ultimate victim is elsewhere 530 (e.g., a native IPv6 user, an IPv4 user) are described later in the 531 memo. 533 6to4 relays and routers are IPv4 nodes, and there is no way for any 534 6to4 router to confirm the identity of the IPv4 node from which it is 535 receiving traffic -- whether it is a legitimate 6to4 relay or some 536 other node. A 6to4 router has to process traffic from all IPv4 537 nodes. Malicious IPv4 nodes can exploit this property and attack 538 nodes within the 6to4 network. 540 It is possible to conduct a variety of attacks on the 6to4 nodes. 541 These attacks are: 543 1. Attacks with Neighbor Discovery (ND) Messages 545 2. Spoofing traffic to 6to4 nodes 547 3. Reflecting traffic from 6to4 nodes 549 4. Local IPv4 broadcast attack 551 4.1.1 Attacks with ND Messages 553 ATTACK DESCRIPTION 555 Since the 6to4 router assumes all the other 6to4 routers, and 6to4 556 relays are "on-link" it is possible to attack the 6to4 router using 557 ND messages from any node in the IPv4 network, unless a prior trust 558 relationship has been established. 560 The attacks are targeting the 6to4 pseudo-interface. As long as the 561 6to4 addresses are not used in the source or destination address, the 562 security checks specified by 6to4 take no stance on these packets. 563 Typically these use link-local addresses. 565 For example, a possible attack could be a Route Advertisement or 566 Neighor Advertisement message, crafted specifically to cause havoc; 567 the addresses in such a packet could be like: 569 src_v6 = fe80::2 (forged address) 570 dst_v6 = fe80::1 (valid or invalid address) 571 src_v4 = 8.0.0.1 (valid or forged address) 572 dst_v4 = 9.0.0.2 (valid address, matches dst_v6) 574 These attacks are exacerbated in case the implementation supports 575 more tunneling mechanisms than just 6to4 (or configured tunneling), 576 because it is impossible to disambiguate such mechanisms, making it 577 difficult to enable strict security checks (see Section 6.1). 579 The Neighbor Discovery threats (Redirect DoS, or DoS) are described 580 in [8]. Note that all attacks may not be applicable, as the 6to4 581 pseudo-interface is assumed not to have a link-layer address (Section 582 3.8 RFC 2893 [4]). However, one should note that the 6to4 router can 583 be either a router or host from the Neighbor Discovery perspective. 585 THREAT ANALYSIS AND MITIGATION METHODS 587 The attacks can be mitigated by using any of the following methods: 589 o The usage of ND messages could be prohibited. It implies that all 590 packets using addresses of scope link-local will be silently 591 discarded. Section 3.1 of RFC 3056 [1] leaves scope for future 592 uses of link-local address. This method has its pitfalls - it 593 would prohibit any sort of ND message, and thus close the doors on 594 development, and use of other ND options. Whether this is a 595 significant problem is another thing. 597 o The 6to4 pseudo-interface could be insulated from the other 598 interfaces, particularly the other tunnel interfaces (if any), for 599 example using a separate neighbor cache. 601 o If ND messages are needed, either IPsec [4] or an extension of 602 SEND could be used [9] to secure packet exchange using link-local 603 address; vanilla SEND would not work as the link-layer does not 604 have an address -- and IPsec would be rather complex. 606 COMPARISON TO SITUATION WITHOUT 6to4 608 Even though rather simply fixable, this attack is not new as such; 609 the same is possible using automatic tunneling [4] or configured 610 tunneling (if one is able to spoof source IPv4 address to that of the 611 tunnel end-point). 613 However, as 6to4 provides open decapsulation, and automatic tunneling 614 is being deprecated [10], 6to4 provides an easy means which would not 615 exist without 6to4. 617 4.1.2 Spoofing Traffic to 6to4 Nodes 619 ATTACK DESCRIPTION 621 The attacker - a malicious IPv4 or IPv6 node - can send packets which 622 are difficult to trace (e.g., due to spoofing or going through a 623 relay) to a 6to4 node. This can be used e.g., to accomplish a DoS 624 attack. 626 The IPv6 and IPv4 addresses of the packets will be similar to: 628 src_v6 = 2001:db8::1 (forged address) 629 dst_v6 = 2002:0900:0002::1 (valid address) 630 src_v4 = 8.0.0.1 (valid or forged address) 631 dst_v4 = 9.0.0.2 (valid address, matches dst_v6) 633 For attacks launched from a native IPv6 node, the src_v4 will be the 634 address of the relay through which the traffic will reach the 6to4 635 node. From IPv4 nodes, src_v4 can be either a spoofed or the real 636 source address. 638 The 6to4 router receives these packets from 8.0.0.1, decapsulates 639 them, discards the IPv4 header containing the source address 8.0.0.1 640 and processes them as normal (the attacker has guessed or obtained 641 "dst_v6" using one of a number of techniques). 643 This is a DoS attack on 6to4 nodes. 645 This attack is similar to ones shown in [11]. 647 EXTENSIONS 649 Replies to the traffic will be directed to the src_v6 address, 650 resulting in 6to4 nodes in participating in a reflection DoS. This 651 attack is described in more detail in Section 4.2.3. That is, the 652 replies (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to 653 UDP echo service, ICMPv6 Destination Unreachable, etc.) are sent to 654 the victim (src_v6), above. All the traces from the original 655 attacker (src_v4) have been discarded. These return packets will go 656 through a relay. 658 Certain 6to4 networks may have a trivial ACL (Access Control List) 659 based firewall that allows traffic to pass through if it comes from 660 particular source(s). Such a firewalling mechanism can be bypassed 661 by address spoofing. This attack can therefore be used for trivial 662 ACL avoidance as well. These attacks might be hampered by the fact 663 that the replies from the 6to4 node to the spoofed address will be 664 lost. 666 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 668 The Denial-of-Service attack based on traffic spoofing is not new; 669 the only twists come from the fact that traces of an attack are more 670 easily lost, and that spoofing the IPv6 address is possible even to 671 those who are unable to do so in their current networks. The 6to4 672 router typically does not log IPv4 addresses (as they would be 673 treated as L2 addresses) and thus the source of the attack (if 674 launched from an IPv4 node) is lost. Since traces to the src_v4 675 address can easily be lost, these attacks can also be be launched 676 from IPv4 nodes whose connection is ingress-filtered. 678 However, often this is not a real factor, as usually the attackers 679 are just zombies and real attackers may not even care if the 680 unspoofed source address is discovered. 682 Malicious native IPv6 nodes could be caught easily if ingress 683 filtering was enabled everywhere in the IPv6 Internet. 685 These attacks are easy to perform, but the extent of harm is limited: 687 o For every packet sent, at most one reply packet is generated: 688 there is no amplification factor. 690 o Attack packets, if initiated from an IPv6 node, will pass through 691 choke point(s), namely a 6to4 relay; in addition to physical 692 limitations, these could implement some form of 6to4-site-specific 693 traffic limiting. 695 On the other hand, a variety of factors can make the attack serious: 697 o The attacker may have the ability to choose the relay, and he 698 might employ the ones best suited for the attacks. Also, many 699 relays use 192.88.99.1 [3] as the source address making tracing 700 even more difficult (also see Section 4.2.6). 702 o The relay's IPv4 address may be used as a source address for these 703 attacks, potentially causing a lot of complaints or other actions 704 as the relay might seem to be the source of the attack (see 705 Section 4.2.6 for more). 707 Some of the mitigation methods for such attacks are: 709 1. Ingress filtering in the native IPv6 networks to prevent packets 710 with spoofed IPv6 source being transmitted. It would, thus, make 711 it easy to identify the source of the attack. Unfortunately, 712 this would depend on significant (or even complete) ingress 713 filtering everywhere in other networks; while this is highly 714 desirable, it may also be practically unfeasible. 716 2. Security checks in the 6to4 relay. The 6to4 relay must drop 717 traffic (from the IPv6 Internet) that has 6to4 addresses as 718 source address, see Section 5 for more. This has very little 719 cost. 721 However, these mitigation methods do not address the case of IPv4 722 node sending encapsulated IPv6 packets. 724 There exists no simple way to prevent such attacks, and longer term 725 solutions like ingress filtering [12] or itrace [13] would have to be 726 deployed in both IPv6 and IPv4 networks to help identify the source 727 of the attacks. A total penetration is likely impossible to achieve. 728 (Note that itrace work has been discontinued, as of this writing in 729 July 2004.) 731 COMPARISON TO SITUATION WITHOUT 6to4 733 Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just 734 makes it easier: anyone can, regardless of ingress filtering, spoof a 735 native IPv6 address to a 6to4 node, even if "maximal security" would 736 be implemented and deployed. Losing trails is also easier. 738 Therefore, depending on how much one assumes ingress filtering is 739 deployed for IPv4 and IPv6, this could be considered to be a very 740 serious issue, or close to irrelevant compared to the IP spoofing 741 capabilities without 6to4. 743 4.1.3 Reflecting Traffic to 6to4 Nodes 745 ATTACK DESCRIPTION 747 Spoofed traffic (as described in Section 4.2.2) may be sent to native 748 IPv6 nodes with the aim of performing a reflection attack against 749 6to4 nodes. 751 The spoofed traffic is sent to a native IPv6 node, either from an 752 IPv4 node (through a 6to4 relay), or from a native IPv6 node (unless 753 ingress filtering has been deployed). With the former, the sent 754 packets would look like: 756 src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node) 757 dst_v6 = 2002:0900:0002::1 (valid address) 758 src_v4 = 8.0.0.1 (valid or invalid address) 759 dst_v4 = 9.0.0.2 (valid address, matches dst_v6) 761 One should note that an attack through the relay is prevented if the 762 relay implements proper decapsulation security checks (see Section 5 763 for details) unless the IPv4 node can spoof the source address to 764 match src_v6. Similarly, the attack from native IPv6 nodes could be 765 prevented by global ingress filtering deployment. 767 These attacks can be initiated by native IPv6, IPv4, or 6to4 nodes. 769 EXTENSIONS 771 A distributed Reflection DoS can be performed if a large number nodes 772 are involved in sending spoofed traffic with the same src_v6. 774 Malicious 6to4 nodes can also (try to) initiate this attack by 775 bouncing traffic off 6to4 nodes in other 6to4 sites. However this 776 attack may not be possible as the 6to4 router (in the site from which 777 the attack is being launched) will filter packets with forged source 778 address (with security checks mentioned in Section 5), and thus the 779 attack will be prevented. 781 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 783 The reverse traffic in this case are replies to the messages received 784 by the 6to4 nodes. The attacker has less control on the packet type 785 in this case, and this would inhibit certain types of attacks. For 786 example, flooding a 6to4 node with TCP SYN packets will not be 787 possible (but e.g., a SYN-ACK or RST would be). 789 These attacks may be mitigated in various ways: 791 o Implementation of ingress filtering by the IPv4 service providers. 792 It would prevent forging of the src_v4 address, and would help in 793 closing down on the culprit IPv4 nodes. Note that, it will be 794 difficult to shut down the attack if a large number of IPv4 nodes 795 are involved. 797 These attacks may be also be stopped at the 6to4 sites if the 798 culprit src_v4 address is identified, and if it is constant, by 799 filtering traffic from this address. Note that it would be 800 difficult to implement this method, if appropriate logging is not 801 done by the 6to4 router, or if a large number of 6to4 nodes, and/ 802 or a large number of IPv4 nodes are participating in the attack. 804 Unfortunately, as many IPv4 service providers don't implement 805 ingress filtering, for whatever reasons, this may not be a 806 satisfactory resolution. 808 o Implementation of ingress filtering by all IPv6 service providers 809 would eliminate this attack, because src_v6 could not be spoofed 810 to be a 6to4 address. However, expecting this to happen may not 811 be practical. 813 o Proper implementation of security checks (see Section 5) both at 814 the 6to4 relays and routers would eliminate the attack, when 815 launched from an IPv4 node, except when the IPv4 source address 816 was also spoofed -- but then the attacker would have been able to 817 just attack the ultimate destination directly. 819 o Rate limiting traffic at the 6to4 relays. In a scenario where 820 most of the traffic is passing through few 6to4 relays, these 821 relays can implement traffic rate-limiting features, and 822 rate-limit the traffic from 6to4 sites. 824 COMPARISON TO SITUATION WITHOUT 6to4 826 This particular attack can be mitigated by proper implementation of 827 security checks (which is quite straightforward) and ingress 828 filtering; where ingress filtering is not implemented, it's typically 829 easier to attack directly than through reflection -- unless "traffic 830 laundering" is an explicit goal in the attack. Therefore, this 831 attack does not seem very serious. 833 4.1.4 Local IPv4 Broadcast Attack 835 ATTACK DESCRIPTION 837 This threat is applicable if the 6to4 router does not check whether 838 the IPv4 address it tries to send encapsulated IPv6 packets to a 839 local broadcast address, or a multicast address. 841 This threat is described in the specification [1], and implementing 842 the checks eliminates this threat. However, as this has not been 843 widely implemented, it is included here regardless for completeness. 845 There practically two kinds of attacks: where a local 6to4 user tries 846 to send packets to the address corresponding to the broadcast 847 address, or when someone is able to do that remotely. 849 In the first option, assume that 9.0.0.255 is the 6to4 router's 850 broadcast address. After receiving the packet with a destionation 851 address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the 852 router doesn't check the destination address for subnet broadcast, it 853 would send the encapsulated protocol-41 packet to 9.0.0.255. This 854 would be received by all nodes in the subnet, and the responses would 855 be directed to the 6to4 router. 857 Malicious sites may also embed forged 6to4 addresses in the DNS, use 858 of which by a 6to4 node will result in a local broadcast by the 6to4 859 router. One way to perform this attack would be to send an HTML mail 860 containing a link to an invalid URL (for example, http:// 861 [2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 technology 862 based network. Opening of the mail simultaneously would result in a 863 broadcast storm. 865 The second kind of attack is more complex: the attack can be 866 initiated by IPv4 nodes not belonging to the local network as long as 867 they can send traffic with invalid (for example 2002:0900:00ff::bbbb) 868 source address. The 6to4 router has to respond to the traffic by 869 sending ICMPv6 packets back to the source, for example Hop Limit 870 Exceeded or Destination Unreachable. The packet would be as follows: 872 src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router) 873 dst_v6 = 2002:0800:0001::0001 (valid non-existent address) 875 This is a DoS attack. 877 EXTENSIONS 879 The attacks could also be directed at non-local broadcast addresses, 880 but these would be so-called "IPv4 directed broadcasts", which have 881 been (luckily enough) already been extensively blocked in the 882 Internet. 884 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 886 The attack is based on the premise that the 6to4 router has to send a 887 packet to an IPv6 address that embeds an invalid IPv4 address. Such 888 an attack is easily thwarted by ensuring that the 6to4 router does 889 not transmit packets to invalid IPv4 addresses. Specifically traffic 890 should not be sent to broadcast or multicast IPv4 addresses. 892 COMPARISON TO SITUATION WITHOUT 6to4 894 The first threat is similar to what's already possible with IPv4, but 895 IPv6 does not have broadcast addresses. 897 The second, a more complex threat, is similarly also available in 898 IPv4. 900 In consequence, the security does not seem to be significantly worse 901 than with IPv4, and even that is restricted to the site(s) with 6to4 902 implementations which haven't been secured as described in Section 5. 904 4.2 Attacks on Native IPv6 Internet 906 This section describes attacks against native IPv6 Internet which 907 leverage 6to4 architecture somehow. Attacks against 6to4 nodes were 908 described in the previous section. 910 Native IPv6 nodes can be accessed by 6to4 and IPv4 nodes through the 911 6to4 relay routers. Thus the 6to4 relays play a crucial role in any 912 attack on native IPv6 nodes by IPv4 nodes or 6to4 nodes. 914 6to4 relays have only one significant security check they must 915 perform for general safety: when decapsulating IPv4 packets, check 916 that 2002:V4ADDR::/48 and V4ADDR match in the source address. If 917 this is not done, several threats become more serious; in the 918 following analysis, it is assumed that such checks are implemented. 920 6to4 relay should not relay packets between 6to4 addresses. In 921 particular, packets decapsulated from 6to4 routers should not be 922 encapsulated again towards 6to4 routers, as described in rules in 923 Section 5. Similarly, packets with 6to4 source and destination 924 address sent from IPv6 nodes should not be relayed. It is not clear 925 whether this kind of check is typically implemented. The attacks 926 described below assume that such checks are not implemented. 928 4.2.1 Attacks with ND Messages 930 These attacks are the same as employed against 6to4 routers as 931 described in Section 4.1.1. 933 4.2.2 Spoofing Traffic to Native IPv6 node 935 ATTACK DESCRIPTION 937 The attacker - a malicious IPv4 or 6to4 node - can send packets with 938 spoofed (or not spoofed) 6to4 source address to a native IPv6 node to 939 accomplish a DoS attack. 941 The threat is similar as the one involving 6to4 routers as described 942 in Section 4.1.2. 944 The difference here is that the attack is initiated by IPv4 nodes, or 945 6to4 nodes. The source IPv6 address may or may not be spoofed. 946 Note, as mentioned above, the relay is assumed to correlate source 947 IPv4 address with the address embedded in the source IPv6 address 948 during decapsulation. A side effect is that all the spoofed traffic 949 will have a 6to4 source address. 951 EXTENSIONS 952 Spoofed traffic may also be sent to native IPv6 nodes by either other 953 native IPv6 nodes, or 6to4 nodes, or malicious IPv4 nodes to conduct 954 Reflection DoS on either native IPv6 nodes or 6to4 nodes. 956 Certain native IPv6 networks may have a trivial ACL (Access Control 957 List) based firewall that allows traffic to pass through if it comes 958 from particular source(s). Such a firewalling mechanism can be 959 bypassed by address spoofing. This attack can therefore be used for 960 trivial ACL avoidance as well. These attacks might be hampered by 961 the fact that the replies from the 6to4 node to the spoofed address 962 will be lost. 964 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 966 The Denial-of-Service attack based on traffic spoofing is not new; 967 the only twist comes from the fact that traces of an attack are more 968 easily lost. The 6to4 relay typically does not log IPv4 addresses 969 (as they would be treated as L2 addresses) and thus the source of the 970 attack (if launched from an IPv4 node) is lost. Since traces to the 971 src_v4 address can easily be lost, these attacks can also be be 972 launched from IPv4 nodes whose connection is ingress-filtered. 974 These attacks might be not be very easy to perform, and might be 975 hampered because of: 977 o It might be difficult to launch such attacks from 6to4 nodes 978 because even if the 6to4 routers allow spoofing of the source IPv6 979 address, the 6to4 relay would check if source V4ADDR is same as 980 the one embedded in the source IPv6 address. Thus, 6to4 nodes 981 will be forced to use the correct IPv6 prefix while lauching 982 attack, and it is easy to close such attacks. 984 o Packets may pass through choke point(s), namely a 6to4 relay. In 985 addition to physical limitations, there could be some sort of 986 traffic rate limiting mechanisms which may be implemented, and it 987 could tone down the attack. 989 o For every packet sent, at most one reply packet is generated: 990 there is no amplification factor. 992 Some of the mitigation methods for such attacks are: 994 1. Ingress filtering in the IPv4 Internet to prevent packets with 995 spoofed IPv4 source being transmitted. As the relay checks that 996 the 6to4 address embeds the IPv4 address, no spoofing can be 997 achieved done unless IPv4 addresses can be spoofed. However, 998 this would probably be an unfeasible requirement. 1000 2. Security checks in the 6to4 relay. The 6to4 relay must drop 1001 traffic (from 6to4 nodes, or IPv4 nodes) that has non-6to4 1002 addresses as source address, or where the source IPv4 address 1003 does not match the address embebdded in the source IPv6 address. 1005 COMPARISON TO SITUATION WITHOUT 6to4 1007 Compared to Section 4.1.2, which is more serious, this threat appears 1008 to be slightly more manageable. If the relays perform proper 1009 decapsulation checks, the spoofing can only be achived, to a 6to4 1010 source address, when IPv4 address is spoofable as well. 1012 4.2.3 Reflecting Traffic to Native IPv6 nodes 1014 ATTACK DESCRIPTION 1016 These reflection attacks are similar to the one involving 6to4 1017 routers as described in Section 4.1.3. Traffic may be reflected off 1018 native IPv6 nodes, or 6to4 nodes. The attack can be initiated by 1019 either: 1021 o Native IPv6 nodes. These nodes can send invalid traffic with 1022 spoofed native IPv6 addresses to valid 6to4 nodes. Replies from 1023 the 6to4 nodes are part of a reflection attack. 1025 o IPv4 nodes. These nodes can send traffic with native IPv6 source 1026 addresses (encapsulated by the IPv4 node itself into a protocol-41 1027 packet) to 6to4 nodes. Replies from the 6to4 nodes are part of a 1028 reflection attack. 1030 o 6to4 nodes. These nodes can perform similar attacks to the ones 1031 by IPv4 nodes, but that would require spoofing of the source 1032 address at the 6to4 site before encapsulation; that is likely to 1033 be difficult. 1035 When launched from a native IPv6 node, the traffic goes through 6to4 1036 relays twice, both after and before the reflection; when launched 1037 from a 6to4/IPv4 node, the traffic goes through a relay only after 1038 the reflection. 1040 EXTENSIONS 1042 A distributed Reflection DoS can be performed if a large number of 1043 native IPv6 nodes or IPv4/6to4 nodes are involved in sending spoofed 1044 traffic with the same source IPv6 address. 1046 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 1047 Some of the mitigation methods for such attacks are: 1049 1. Attacks from the native IPv6 nodes could be stopped by 1050 implementing ingress filtering in the IPv6 Internet; hopefully 1051 this will become commonplace, but past experience of IPv4 ingress 1052 filtering deployment (or lack thereof) does not promise much. 1054 2. Two measures are needed to stop or mitigate the attacks from IPv4 1055 nodes: 1) Implementing ingress filtering in the IPv4 internet, 1056 and 2) logging IPv4 source address in the 6to4 router. 1058 3. Attacks from 6to4 nodes in other sites can be stopped if the 6to4 1059 router in those sites implements egress filtering. This could be 1060 done by those sites, but the sites who are most likely to be 1061 abused are typically also most likely to be neglecting to 1062 installing appropriate filtering at their edges. 1064 4. The traffic passes through one or two relays, and traffic rate 1065 limiting in the 6to4 relays might help tone down the reflection 1066 attack. 1068 COMPARISON TO SITUATION WITHOUT 6to4 1070 Even thought there are means to mitigate the attack, it is still 1071 rather efficient, especially when used by native IPv6 nodes with 1072 spoofed addresses. Using 6to4 relays and routers could easily take 1073 down the 6to4 relay system and/or provide an easy means for traffic 1074 laundering. However, if the intent of the attack is just to DoS the 1075 victim, it can be achieved more smoothly by doing it directly (as the 1076 source address spoofing was available as well). 1078 Therefore, the threat seems to be higher to the availability and 1079 stability of the 6to4 relay system itself than to native IPv6 1080 Internet. 1082 4.2.4 Local IPv4 Broadcast Attack 1084 This attack is similar to the ones employed against 6to4 routers as 1085 described in Section 4.1.4. There are slight differences with regard 1086 to the source of the attacks. This attack can be initiated by: 1088 o Native IPv6 nodes that may send traffic to the relay's subnet 1089 broadcast address. 1091 o IPv4 nodes that may send traffic with spoofed source IP address 1092 (to be the relay's broadcast address) to elicit replies (e.g., 1093 ICMPv6 Hop Limit Exceeded messages) from the 6to4 relay to its 1094 local nodes. 1096 The first is more dangerous than in Section 4.1.4 because it can be 1097 initiated by any IPv6 node (which is allowed to use the relay, that 1098 is), not limited to local users. 1100 The second is trickier and not really useful. For it to succeed, the 1101 relay would have to accept native source addresses over the 6to4 1102 pseudo-interface (but we did not assume this check was implemented), 1103 as if coming from another relay, and trigger an ICMPv6 message to the 1104 relay's local IPv4 subnet. The former method is more lucrative. 1106 EXTENSIONS 1108 None. 1110 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 1112 The threat is restricted to the relay's local subnet, and is fixed by 1113 tightening the 6to4 security checks. 1115 COMPARISON TO SITUATION WITHOUT 6to4 1117 This scenario is caused by 6to4, but fortunately, the issue is not 1118 serious. 1120 4.2.5 Theft of Service 1122 ATTACK DESCRIPTION 1124 The 6to4 relay administrators would often want to use some policy to 1125 limit the use of the relay to specific 6to4 sites and/or specific 1126 IPv6 sites. 1128 The policy control is usually done by applying restrictions to where 1129 the routing information for 2002::/16 and/or 192.188.99.0/24 (if the 1130 anycast address used [3]) will spread. 1132 Some users may be able to use the service regardless of these 1133 controls, by: 1135 o Configuring the address of the relay using its IPv4 address 1136 instead of 192.88.99.1, or 1138 o Using the Routing header to route IPv6 packets to reach specific 1139 6to4 relays. (Some other routing tricks like using static routes 1140 may also be used.) 1142 EXTENSIONS 1143 None. 1145 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 1147 Attempts to use the relay's IPv4 address instead of 192.88.99.1 can 1148 be mitigated in the following ways: 1150 1. IPv4 domains should prevent usage of the actual IPv4 address of 1151 the relay instead of 192.88.99.1. 1153 2. Usage of access lists in the 6to4 relay to limit access. This is 1154 only feasible if the number of IP networks the relay is supposed 1155 to serve is relatively low. 1157 3. The 6to4 relay should filter out arriving tunneled packets with 1158 protocol 41 (IPv6) which do not have the the 192.88.99.1 as the 1159 destination address. 1161 The other threat of using routing tricks in the IPv6 networks to 1162 reach the 6to4 relay has similar solutions: 1164 1. Usage of access lists in the relay to limit access. 1166 2. Filtering out the packets with a routing header (may have other 1167 implications). 1169 3. Monitoring the source addresses going through the relay, to 1170 detect e.g. peers setting up static routes. 1172 Routing Header is not specific to 6to4, the main things one could do 1173 here with it would be to select the relay; some generic threats about 1174 Routing Header use are described in [11]. 1176 As this threat does not have implications on other than the 1177 organization providing 6to4 relay, it is not analyzed any further. 1179 COMPARISON TO SITUATION WITHOUT 6to4 1181 These threats are specific to 6to4 relays (or in general, anycast 1182 services), and do not exist in networks without 6to4. 1184 4.2.6 Relay Operators Seen as Source of Abuse 1186 ATTACK DESCRIPTION 1188 There are several attacks which use 6to4 relays to anonymize the 1189 traffic; this often results in packets being tunneled from the relay 1190 to a supposedly-6to4 site. 1192 However, as was already pointed out in Section 4.2, the IPv4 source 1193 address used by the relay could, cursorily looking, be seen as the 1194 source of these "protocol-41" attacks. 1196 This could cause a number of concerns for the operators deploying 1197 6to4 relay service. For example: 1199 o Getting contacted a lot (via email, phone, fax, or lawyers) on 1200 suspected "abuse", 1202 o Getting the whole IPv4 address range rejected as a source of abuse 1203 or spam, causing outage to other operations as well, or 1205 o Causing the whole IPv4 address range to be to be blacklisted in 1206 some "spammer databases", if the relay would be used for those 1207 purposes. 1209 This threat seems slightly similar (but more generic) to the outburst 1210 of SMTP abuse caused by open relays. 1212 EXTENSIONS 1214 None. 1216 THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 1218 This problem can be avoided (or really, "made someone else's 1219 problem") by using the 6to4 anycast address in 192.88.99.0/24 as the 1220 source address: blacklisting or rejecting that should not cause 1221 problems to the other operations. 1223 Further, when someone is filing complaints to the owner of 1224 192.88.99.0/24, depending on which registry they are querying, they 1225 might get, for example: 1227 o Knowledge that this is a special IANA address block, with no real 1228 contact person, 1230 o Knowledge that this is a special address block for RFC 3068, or 1232 o Knowledge that this is a special address block for RFC 3068, and 1233 that there are multiple entries in the database by relay 1234 operators. 1236 Any of these, at least when processed by a human, should make one 1237 learn that the 6to4 relay is in fact innocent. Of course, this could 1238 result in these reports going to the closest anycast 6to4 relay as 1239 well, which in fact had nothing to do with the incident. 1241 However, the wide-spread usage of 192.88.99.1 as the source address 1242 may make it more difficult to disambiguate the relays, which might be 1243 a useful feature for debugging purposes. 1245 COMPARISON TO SITUATION WITHOUT 6to4 1247 This threat is caused by 6to4 deployment, but can be avoided, at 1248 least in the short-term, by using the use of 192.88.99.1 as the 1249 source address. 1251 4.3 Attacks on IPv4 Internet 1253 There are two types of attacks on the IPv4 internet - spoofed 1254 traffic, and reflection. They can be initiated by native IPv6 nodes, 1255 6to4 nodes, and IPv4 nodes. 1257 Attacks initiated by IPv4 nodes that send spoofed traffic that will 1258 not utilize the 6to4 infrastructure are considered out of scope of 1259 this document. 6to4 infrastructure may be utilized in reflection 1260 attacks that are initiated by IPv4 nodes. 1262 It is difficult for these attacks to be effective as the traffic sent 1263 out will be IPv6-in-IPv4. Such traffic will be rejected by most IPv4 1264 nodes unless they have implemented some sort of IPv6-in-IPv4 1265 tunneling. 1267 4.4 Summary of the Attacks 1269 Columns: 1271 o Section number. The section that describes the attack. 1273 o Attack name. 1275 o Initiator. The node that initiates the attack. 1277 * I_4 - IPv4 node 1279 * I_6 - native IPv6 node 1281 * 6to4 - 6to4 node 1283 * * - All of the above 1285 o Victim. The victim node 1287 * I_4 - IPv4 node 1288 * I_6 - native IPv6 node 1290 * 6to4 - 6to4 node 1292 * Relay - 6to4 relay 1294 * Router - 6to4 router 1296 o ToA. Type of Attack 1298 * D - DoS 1300 * R - Reflection DoS 1302 * T - Theft of Service 1304 o Fix. Specified who is responsible for fixing the attack. 1306 * 6 - The 6to4 developer and/or operator can completely mitigate 1307 this attack. 1309 * 6* - The 6to4 developer and/or operator can partially mitigate 1310 this attack. 1312 * E - This threat cannot be fixed by the 6to4 developer or the 1313 6to4 operator. 1315 Summary of attacks on a 6to4 network: 1317 +-------+----------------------+---------+----------+-----+-----+ 1318 | Sec | Attack name |Initiator| Victim | ToA | Fix | 1319 +-------+----------------------+---------+----------+-----+-----+ 1320 | 4.1.1 | Attacks with ND | I_4 | Router | D | 6 | 1321 +-------+----------------------+---------+----------+-----+-----+ 1322 | 4.1.2 | Spoofing Traffic | I_4,I_6 | 6to4 | D | E | 1323 +-------+----------------------+---------+----------+-----+-----+ 1324 | 4.1.3 | Reflection Attacks | * | 6to4 | R | 6* | 1325 +-------+----------------------+---------+----------+-----+-----+ 1326 | 4.1.4 | Local IPv4 Broadcast | * | Router | D | 6 | 1327 +-------+----------------------+---------+----------+-----+-----+ 1329 Figure 9 1331 Summary of attacks on the native IPv6 internet: 1333 +-------+----------------------+---------+----------+-----+-----+ 1334 | Sec | Attack name |Initiator| Victim | ToA | Fix | 1335 +-------+----------------------+---------+----------+-----+-----+ 1336 | 4.2.1 | Attacks with ND | I_4 | Relay | D | 6 | 1337 +-------+----------------------+---------+----------+-----+-----+ 1338 | 4.2.2 | Spoofing Traffic | I_4,6to4| I_6 | D | 6* | 1339 +-------+----------------------+---------+----------+-----+-----+ 1340 | 4.2.3 | Reflection Attacks | * | I_6 | R | 6* | 1341 +-------+----------------------+---------+----------+-----+-----+ 1342 | 4.2.4 | Local IPv4 Broadcast | * | Relay | D | 6 | 1343 +-------+----------------------+---------+----------+-----+-----+ 1344 | 4.2.5 | Theft of Service | 6to4 | Relay | T | 6 | 1345 +-------+----------------------+---------+----------+-----+-----+ 1346 | 4.2.6 | Relay Operators ... | - | - | D | 1) | 1347 +-------+----------------------+---------+----------+-----+-----+ 1349 Figure 10 1351 Notes: 1353 1) This attack is a side-effect of the other attacks, and thus does 1354 not have any Initiator, Victim, and Fix. It is a Denial of Service 1355 attack not on the network but on the organization in-charge of the 1356 relay. 1358 Summary of attacks on IPv4 internet: 1360 +-------+----------------------+---------+----------+-----+-----+ 1361 | Sec | Attack name |Initiator| Victim | ToA | Fix | 1362 +-------+----------------------+---------+----------+-----+-----+ 1363 | 4.3 | Spoofing Traffic | * | I_4 | D | 6* | 1364 +-------+----------------------+---------+----------+-----+-----+ 1365 | 4.3 | Reflection Attacks | * | I_4 | R | 6* | 1366 +-------+----------------------+---------+----------+-----+-----+ 1368 Figure 11 1370 5. Implementing Proper Security Checks in 6to4 1372 In this section, several ways to implement the security checks 1373 required or implied by the specification [1] or augmented by this 1374 memo are described. These do not, in general, protect against the 1375 majority of the threats listed above in the "Threat Analysis" 1376 section. They're just prerequisites for a relatively safe and simple 1377 6to4 implementation. 1379 Note that in in general, the 6to4 router or relay does not know 1380 whether it is acting as a router or relay. It would be possible to 1381 include a toggle to specify the behaviour, to be used e.g., when the 1382 interface is brought up, but at least in February 2004, no 1383 implementations were known to do that. Due to that, the checks are 1384 described as one -- which works independent of whether the node is a 1385 router or relay. 1387 5.1 Encapsulating IPv6 into IPv4 1389 The checks described in this section are to be performed when 1390 encapsulating IPv6 into IPv4. 1392 The encapsulation rules are mainly designed to keep one from 1393 "shooting yourself on the foot" -- for example, the source address 1394 check verifies that the packet will be acceptable to the 1395 decapsulator, or the sanity checks ensure that addresses derived from 1396 private addresses are not used (which would be equally unacceptable). 1398 src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below) else drop 1399 if prefix (src_v6) == 2002::/16 1400 ipv4 address embedded in src_v6 MUST match src_v4 1401 else if prefix (dst_v6) == 2002::/16 1402 dst_v4 SHOULD NOT be assigned to the router 1403 else 1404 drop 1405 /* we somehow got a native-native ipv6 packet */ 1406 fi 1407 accept 1409 5.2 Decapsulating IPv4 into IPv6 1411 The checks described in this section are to be performed when 1412 decapsulating IPv4 into IPv6. They will be performed in both the 1413 6to4 router and relay. 1415 src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop 1416 src_v6 and dst_v6 MUST pass ipv6-sanity checks, else drop 1417 if prefix (dst_v6) == 2002::/16 1418 ipv4 address embedded in dst_v6 MUST match dst_v4 1419 if prefix (src_v6) == 2002::/16 1420 ipv4 address embedded in src_v6 MUST match src_v4 1421 dst_v4 SHOULD be assigned to the router 1422 fi 1423 elif prefix (src_v6) == 2002::/16 1424 ipv4 address embedded in src_v6 MUST match src_v4 1425 dst_v4 SHOULD be assigned to the router (see notes below) 1426 else 1427 drop 1428 /* the we somehow got a native-native ipv6 packet */ 1429 fi 1430 accept 1432 5.3 IPv4 and IPv6 Sanity Checks 1434 The encapsulation and decapsulation checks included certain sanity 1435 checks for both IPv4 and IPv6. These are described here in detail. 1437 5.3.1 IPv4 1439 IPv4 address MUST be a global unicast address, as required by the 1440 6to4 specification. The disallowed addresses include those defined 1441 in [14], and others widely used and known not to be global. These 1442 are: 1444 o 0.0.0.0/8 (the system has no address assigned yet) 1446 o 10.0.0.0/8 (private) 1448 o 127.0.0.0/8 (loopback) 1450 o 172.16.0.0/12 (private) 1452 o 192.168.0.0/16 (private) 1454 o 169.254.0.0/16 (IANA Assigned DHCP link-local) 1456 o 224.0.0.0/4 (multicast) 1458 o 240.0.0.0/4 (reserved and broadcast) 1460 In addition, the address MUST NOT be any of the system's broadcast 1461 addresses. This is especially important if the implementation is 1462 made so that it can: 1464 o receive and process encapsulated IPv4 packets arriving at its 1465 broadcast addresses, or 1467 o send encapsulated IPv4 packets to one of its broadcast addresses. 1469 5.3.2 IPv6 1471 IPv6 address MUST NOT be: 1473 o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...) 1475 o fe80::/10 (link-local) 1477 o fec0::/10 (site-local) 1479 o ff00::/8 (any multicast) 1481 Note: only link-local multicast would be strictly required, but it is 1482 believed that multicast with 6to4 will not be feasible, so it has 1483 been disallowed as well. 1485 In addition, it MUST be checked that equivalent 2002:V4ADDR::/48 1486 checks, where V4ADDR is any of the above IPv4 addresses, will not be 1487 passed. 1489 5.3.3 Optional Ingress Filtering 1491 In addition, the implementation in the 6to4 router may perform some 1492 form of ingress filtering (e.g. Unicast Reverse Path Forwarding 1493 checks). For example, if the 6to4 router has multiple interfaces, of 1494 which some are "internal", receiving either IPv4 or IPv6 packets with 1495 source address belonging to any of these internal networks from the 1496 Internet might be disallowed. 1498 If these checks are implemented, and are enabled by default, it's 1499 recommended that there is a toggle to disable them if needed. 1501 5.3.4 Notes About the Checks 1503 The rule "dst_v4 SHOULD be assigned to the router" is not needed if 1504 the 6to4 router implementation only accepts and processes 1505 encapsulated IPv4 packets arriving its unicast IPv4 addresses, and 1506 when destination address is known to be a local broadcast address, it 1507 does not try to encapsulate and send packets to it. (see Section 1508 4.1.4, and Section 4.2.4 about this threat). 1510 Some checks, especially the IPv4/IPv6 Sanity Checks, could be at 1511 least partially implementable with system-level access lists, if one 1512 would like to avoid placing too many restrictions in the 6to4 1513 implementation itself. This depends on how many hooks for the access 1514 lists are in place. In practice it seems that this could not be done 1515 effectively enough unless the access list mechanism is able to parse 1516 the encapsulated packets. 1518 6. Issues in 6to4 Implementation and Use 1520 This section tries to give an overview of some of the problems 6to4 1521 implementations are faced with, and the kind of generic problems the 1522 6to4 users could come up with. 1524 6.1 Implementation Considerations with Automatic Tunnels 1526 There is a problem with multiple transition mechanisms if strict 1527 security checks are implemented. This may vary a bit from 1528 implementation to implementation. 1530 Consider three mechanisms using automatic tunneling: 6to4, ISATAP 1531 [15] and Automatic Tunneling using Compatible Addresses [4] 1532 (currently removed [10] but typically still supported). All of these 1533 use IP-IP (protocol 41) [16] IPv4 encapsulation with, more or less, a 1534 pseudo-interface. 1536 When a router, which has any two of these enabled, receives an IPv4 1537 encapsulated IPv6 packet: 1539 src_v6 = 2001:db8::1 1540 dst_v6 = 2002:1010:1010::2 1541 src_v4 = 10.0.0.1 1542 dst_v4 = 20.20.20.20 1544 What can it do? How should it decide which transition mechanism this 1545 belongs to; there is no "transition mechanism number" in IPv6 or IPv4 1546 header to signify this. (This can also be viewed as a flexibility 1547 benefit.) 1549 Without any kind of security checks (in any of implemented methods) 1550 these often just "work" as the mechanisms aren't differentiated but 1551 handled in "one big lump". 1553 Configured tunneling [4] does not suffer from this as it is 1554 point-to-point, and based on src_v6/dst_v6 pairs of both IPv4 and 1555 IPv6 addresses it can be deduced which logical tunnel interface is in 1556 the question. 1558 Solutions for this include 1) not using more than one automatic 1559 tunneling mechanism in a node or 2) binding different mechanisms to 1560 different IPv4 addresses. 1562 6.2 A Different Model for 6to4 Deployment 1564 Even though this was already discussed in Section 4.1.2, it bears 1565 some additional elaboration as it was the only problem which cannot 1566 be even partially solved using the current deployment model -- but 1567 there are some mitigation methods. 1569 That is, 6to4 routers receive traffic from non-6to4 ("native") 1570 sources via 6to4 relays. 6to4 routers have no way of matching IPv4 1571 source address of the relay with non-6to4 IPv6 address of the source. 1572 Consequently, anyone can spoof any non-6to4 IPv6 address he wants by 1573 sending traffic, encapsulated, directly to 6to4 routers. 1575 It could be possible to turn the deployment assumptions of 6to4 1576 around a bit to eliminate some threats caused by untrusted 6to4 1577 relays. That is: 1579 o Every dual-stack site (or even ISP) would be required to have 1580 their own 6to4 relay. (This assumes that IPv6-only is so long 1581 away that 6to4 would be hopefully retired at that point.) That 1582 is, there would not be third-party relays, and 2002::/16 and 1583 192.88.99.0/24 routes would not need to be advertised globally, 1584 and 1586 o The security implications of 6to4 use could be pushed back to the 1587 level of trust inside the site or ISP (or their acceptable use 1588 policies) -- this is something that the sites and ISP's should be 1589 familiar with already. 1591 However, this has a number of problems: 1593 This model would shift the majority of burden of supporting 6to4 to 1594 IPv6 sites which don't employ or use 6to4 at all, i.e., "those who 1595 deploy proper native dual-stack". It could be argued that the 1596 deployment pain should be borne by 6to4 users, not the others. 1598 The main advantage of 6to4 is easy deployment and free relays. This 1599 would require that everyone the 6to4 sites wish to communicate with 1600 implement these measures. 1602 The model would not fix the "relay spoofing problem", unless 1603 everybody deployed also 6to4 addresses on the nodes (alongside with 1604 native addresses, if necessary), which in turn would change 6to4 to 1605 operate without relays completely. 1607 7. Security Considerations 1609 This draft discusses security considerations of 6to4. 1611 Even if proper checks are implemented, there are a large number of 1612 different kind of security threats; these threats are analyzed in 1613 Section 4. 1615 There are mainly three classes of potential problem sources: 1617 1. 6to4 routers not being able to identify whether relays are 1618 legitimate, 1620 2. Wrong or impartially implemented 6to4 router or relay security 1621 checks, 1623 3. 6to4 architecture used to participate in DoS or reflected DoS 1624 attacks, or made to participate in "packet laundering", i.e., 1625 making another attack harder to trace, or 1627 4. 6to4 relays being subject to "administrative abuse", e.g., theft 1628 of service, or being seen as a source of abuse. 1630 The first is the toughest problem, still under research. The second 1631 can be fixed by ensuring the correctness of implementations; this is 1632 important. The third is also a very difficult problem, and 1633 impossible to solve completely -- therefore it is important to be 1634 able to analyze whether this results in a significant increase of 1635 threats. The fourth problem seems to have feasible solutions. 1637 These are analyzed in detail in Threat Analysis, in Section 4. 1639 8. IANA Considerations 1641 This memo makes no requet to IANA. (RFC-editor note: please remove 1642 this section on publication.) 1644 9. Acknowledgments 1646 Some issues were first brought up by Itojun Hagino in [17], and Alain 1647 Durand introduced one specific problem at IETF51 in August 2001 1648 (though there was some discussion on the list prior to that); these 1649 gave the author the push to start looking into the details of 1650 securing 6to4. 1652 Alexey Kuznetsov brought up the implementation problem with IPv6 1653 martian checks. Christian Huitema formulated the rules that rely on 1654 6to4 relays using only anycast. Keith Moore brought up the point 1655 about reduced flexibility. Brian Carpenter, Tony Hain and Vladislav 1656 Yasevich are acknowledged for lengthy discussions. Alain Durand 1657 reminded of relay spoofing problems. Brian Carpenter reminded of the 1658 BGP-based 6to4 router model. Christian Huitema gave a push to a more 1659 complete threat analysis. Itojun Hagino spelled out the operators' 1660 fears about 6to4 relay abuse. Rob Austein brought up the idea of a 1661 different 6to4 deployment model. 1663 In the latter phase, especially discussions with Christian Huitema, 1664 Brian Carpenter and Alain Durand were helpful when improving the 1665 document. 1667 David Malone, Iljitsch van Beijnum, and Tim Chown gave feedback on 1668 the document. 1670 10. References 1672 10.1 Normative References 1674 [1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 1675 Clouds", RFC 3056, February 2001. 1677 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1678 Levels", BCP 14, RFC 2119, March 1997. 1680 [3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 1681 3068, June 2001. 1683 10.2 Informative References 1685 [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 1686 Hosts and Routers", RFC 2893, August 2000. 1688 [5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 1690 [6] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 1691 RFC 1771, March 1995. 1693 [7] Draves, R., "Default Address Selection for Internet Protocol 1694 version 6 (IPv6)", RFC 3484, February 2003. 1696 [8] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 1697 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 1699 [9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 1700 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 1701 (work in progress), April 2004. 1703 [10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 1704 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-03 (work in 1705 progress), June 2004. 1707 [11] Savola, P., "Security of IPv6 Routing Header and Home Address 1708 Options", draft-savola-ipv6-rh-ha-security-02 (work in 1709 progress), March 2002. 1711 [12] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1712 Defeating Denial of Service Attacks which employ IP Source 1713 Address Spoofing", BCP 38, RFC 2827, May 2000. 1715 [13] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback 1716 Messages", draft-ietf-itrace-04 (work in progress), February 1717 2003. 1719 [14] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 1720 June 1995. 1722 [15] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site 1723 Automatic Tunnel Addressing Protocol (ISATAP)", 1724 draft-ietf-ngtrans-isatap-22 (work in progress), May 2004. 1726 [16] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. 1728 [17] Hagino, J., "Possible abuse against IPv6 transition 1729 technologies", draft-itojun-ipv6-transition-abuse-01.txt 1730 (expired, work-in-progress) , July 2000. 1732 Authors' Addresses 1734 Pekka Savola 1735 CSC/FUNET 1736 Espoo 1737 Finland 1739 EMail: psavola@funet.fi 1740 Chirayu Patel 1741 All Play, No Work 1742 185, Defence Colony 1743 Bangalore, Karnataka 560038 1744 India 1746 Phone: +91-98452-88078 1747 EMail: chirayu@chirayu.org 1748 URI: http://www.chirayu.org 1750 Appendix A. Some Trivial Attack Scenarios Outlined 1752 Here, a few trivial attack scenarios are outlined -- ones that are 1753 prevented by implementing checks listed in [1] or in section 6. 1755 When two 6to4 routers send traffic to each others' domains, packet 1756 sent by RA to RB is like: 1758 src_v6 = 2002:0800:0001::aaaa 1759 dst_v6 = 2002:0800:0002::bbbb 1760 src_v4 = 8.0.0.1 (added when encapsulated to IPv4) 1761 dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) 1763 When the packet is received by IPv4 stack on RB, it will be 1764 decapsulated so that only src_v6 and dst_v6 remain, as originally 1765 sent by RA: 1767 src_v6 = 2002:0800:0001::aaaa 1768 dst_v6 = 2002:0800:0002::bbbb 1770 As every other node is just one hop away (IPv6-wise) and the 1771 link-layer (IPv4) addresses are lost, this may open a lot of 1772 possibilities for misuse. 1774 As an example, unidirectional IPv6 spoofing is made trivial because 1775 nobody can check (without delving into IP-IP packets) whether the 1776 encapsulated IPv6 addresses were authentic (With native IPv6, this 1777 can be done by e.g., RPF-like mechanisms or access lists in upstream 1778 routers). 1780 src_v6 = 2002:1234:5678::aaaa (forged) 1781 dst_v6 = 2002:0800:0002::bbbb 1782 src_v4 = 8.0.0.1 (added when encapsulated to IPv4) 1783 dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) 1785 A similar attack with "src" being native address is possible even 1786 with the security checks, by having the sender node pretend to be a 1787 6to4 relay router. 1789 More worries come in to the picture if e.g., 1791 src_v6 = ::ffff:[some trusted IPv4 in a private network] 1792 src_v6/dst_v6 = ::ffff:127.0.0.1 1793 src_v6/dst_v6 = ::1 1794 src_v6/dst_v6 = ... 1796 Some implementations might have been careful enough to have designed 1797 the stack to as to avoid the incoming (or reply) packets going to 1798 IPv4 packet processing through special addresses (e.g., IPv4-mapped 1799 addresses), but who can say for all ... 1801 Appendix B. Change Log 1803 [[ RFC-EDITOR note: to be removed before publication ]] 1805 Changes from -03 to -04 1807 1. Some editorial fixes; resolve IESG evaluation comments. 1809 Changes from -02 to -03 1811 1. Only rather minor editorial changes. 1813 Changes from -01 to -02 1815 1. Incorporate Iljitsch's feedback 1817 2. Clean up section 6.2 1819 3. Fix encapsulation code (had been munged in -01) 1821 Changes from -00 to -01 1823 1. Lots of editorial changes in other sections 1825 2. Revamped the "Threat Analysis" section completely; ripple the 1826 effects elsewhere in the document as well. 1828 3. Added Chirayu Patel as a co-author. 1830 Intellectual Property Statement 1832 The IETF takes no position regarding the validity or scope of any 1833 Intellectual Property Rights or other rights that might be claimed to 1834 pertain to the implementation or use of the technology described in 1835 this document or the extent to which any license under such rights 1836 might or might not be available; nor does it represent that it has 1837 made any independent effort to identify any such rights. Information 1838 on the procedures with respect to rights in RFC documents can be 1839 found in BCP 78 and BCP 79. 1841 Copies of IPR disclosures made to the IETF Secretariat and any 1842 assurances of licenses to be made available, or the result of an 1843 attempt made to obtain a general license or permission for the use of 1844 such proprietary rights by implementers or users of this 1845 specification can be obtained from the IETF on-line IPR repository at 1846 http://www.ietf.org/ipr. 1848 The IETF invites any interested party to bring to its attention any 1849 copyrights, patents or patent applications, or other proprietary 1850 rights that may cover technology that may be required to implement 1851 this standard. Please address the information to the IETF at 1852 ietf-ipr@ietf.org. 1854 Disclaimer of Validity 1856 This document and the information contained herein are provided on an 1857 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1858 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1859 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1860 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1861 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1862 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1864 Copyright Statement 1866 Copyright (C) The Internet Society (2004). This document is subject 1867 to the rights, licenses and restrictions contained in BCP 78, and 1868 except as set forth therein, the authors retain all their rights. 1870 Acknowledgment 1872 Funding for the RFC Editor function is currently provided by the 1873 Internet Society.