v6ops Working Group P. Savola
Internet DraftInternet-Draft CSC/FUNET Expiration Date: AprilExpires: August 10, 2004 C. Patel All Play, No Work Feb 10, 2004 October 2003Security Considerations for 6to4 draft-ietf-v6ops-6to4-security-00.txtdraft-ietf-v6ops-6to4-security-01.txt Status of this Memo This document is an Internet-Draft and is subject toin full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts.Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. To view thehttp:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories, seeDirectories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 10, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over- IPv4IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 Routersrouters and Relay Routers,6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from anywhere. There aren't many constraints onany node in the embedded IPv6 packets, or whereIPv4 traffic will be automatically tunneled to. These couldinternet. This characteristic enable oneones to go around access controls,controls and more likely, being able toperform proxyDenial of Service attacks using 6to4 relays or routers as reflectors. Anyone is6to4 routers. It also capable of spoofing traffic from non-6to4 addresses, as ifmakes it was coming from a relay,easier for nodes to a 6to4 node.spoof IPv6 addresses. This document discusses these issues in more detail and tries to suggestsuggests enhancements to alleviate the problems. Table of Contents 1. Introduction ............................................... 3. . . . . . . . . . . . . . . . . . . . . . . . 4 2. Different 6to4 Forwarding Scenarios ........................ 4 2.1.. . . . . . . . . . . . 5 2.1 From 6to4 to 6to4 ...................................... 4 2.2.. . . . . . . . . . . . . . . . . . . . . 5 2.2 From Native to 6to4 ..................................... . . . . . . . . . . . . . . . . . . . 5 184.108.40.206 From 6to4 to Native ..................................... . . . . . . . . . . . . . . . . . . . 6 220.127.116.11 Other Models ............................................ . . . . . . . . . . . . . . . . . . . . . . . 6 18.104.22.168.4.1 BGP Between 6to4 Routers and Relays ................ 6 2.4.2.. . . . . . . . . . . . 7 2.4.2 6to4 as an Optimization Method ...................... . . . . . . . . . . . . . . 7 22.214.171.124.4.3 6to4 as Tunnel End-Point Addressing Mechanism ....... . . . . . . 7 3. SomeFunctionalities of 6to4 ............................... 7 3.1. Functions of Different 6to4 Network Components ......... 7 3.2. Non-functions of Different 6to4Network Components ...... . . . . . . . . 9 4. Special Processing of3.1 6to4 Packets ......................... 9 4.1. Encapsulating IPv6 Packets into IPv4 ...................Routers . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Decapsulating IPv4 Packets into IPv6 ................... 10 5. Threat Analysis ............................................ 10 5.1. Threats Related to Any 6to4 Node ....................... 10 5.2. Threats Related to3.2 6to4 Relay Routers ......................... . . . . . . . . . . . . . . . . . . . . 10 126.96.36.199. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . 11 4.1 Attacks Against theon 6to4 Pseudo-Interface .......... 11 188.8.131.52. ComparisonNetworks . . . . . . . . . . . . . . . . . . 12 4.1.1 Attacks with ND Messages . . . . . . . . . . . . . . . . . . 13 4.1.2 Spoofing Traffic to Situation without6to4 ........... 11 5.2.2. Relay Spoofing, DoS against IPv6Nodes ............. 11 184.108.40.206. Comparison to Situation without 6to4 ........... 12 5.3. Threats Related. . . . . . . . . . . . . . . 14 4.1.3 Reflecting Traffic to 6to4 Relays ......................... 13 5.3.1. Attacks Against the 6to4 Pseudo-Interface .......... 14 5.3.2. Spoofing, DoS against IPv6Nodes ................... 14 5.3.3. Participating in DoS attacks against. . . . . . . . . . . . . . 16 4.1.4 Local IPv4 .......... 14 220.127.116.11. ComparisonBroadcast Attack . . . . . . . . . . . . . . . . 18 4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . . . . 19 4.2.1 Attacks with ND Messages . . . . . . . . . . . . . . . . . . 20 4.2.2 Spoofing Traffic to Situation without 6to4 ........... 14 5.3.4. Using AnyNative IPv6 Node for Reflection ................. 15 18.104.22.168. Comparisonnode . . . . . . . . . . . . 20 4.2.3 Reflecting Traffic to Situation without 6to4 ........... 15 5.3.5. IPv4Native IPv6 nodes . . . . . . . . . . 22 4.2.4 Local DirectedIPv4 Broadcast Attacks .............. 16 22.214.171.124. Comparison to Situation without 6to4 ........... 16 5.3.6.Attack . . . . . . . . . . . . . . . . 23 4.2.5 Theft of Service ................................... 16 5.3.7.. . . . . . . . . . . . . . . . . . . . . . 24 4.2.6 Relay Operators Seen as Source of Abuse ............ 17 5.4. Possible Threat Mitigation Methods ..................... 18 5.4.1. 6to4 Decapsulation Cache ........................... 18 5.4.2. Rate-limiting at 6to4 Routers/Relays ............... 18 5.4.3. An Application of iTrace Model ..................... 18 5.5. Summary ................................................ 19 5.5.1.. . . . . . . . . . 25 4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . . . . 26 4.4 Summary of the Threats ............................. 19 5.5.2. Generic Notes about Threats ........................ 20 6.Attacks . . . . . . . . . . . . . . . . . . . 27 5. Implementing Proper Security Checks in 6to4 ................ 21 6.1. Generic Approach ....................................... 21 6.1.1.. . . . . . . . 29 5.1 Encapsulating IPv6 into IPv4 ....................... 21 6.1.2.. . . . . . . . . . . . . . . . 29 5.2 Decapsulating IPv4 into IPv6 ....................... 22 6.1.3.. . . . . . . . . . . . . . . . 30 5.3 IPv4 and IPv6 Sanity Checks ........................ 22 126.96.36.199.. . . . . . . . . . . . . . . . 30 5.3.1 IPv4 ........................................... 22 188.8.131.52.. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.3.2 IPv6 ........................................... 23 184.108.40.206.. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3.3 Optional Ingress Filtering ..................... 23 220.127.116.11.. . . . . . . . . . . . . . . . . 32 5.3.4 Notes About the Checks ......................... 23 6.2. Simplified Approach .................................... 24 6.2.1. Encapsulating IPv6 into IPv4 ....................... 24 6.2.2. Decapsulating IPv4 into IPv6 ....................... 24 7.. . . . . . . . . . . . . . . . . . . 32 6. Issues ..................................................... 25 7.1.in 6to4 Implementation and Use . . . . . . . . . . . 32 6.1 Implementation Considerations with Automatic Tunnels ... 25 7.2. Reduced Flexibility .................................... 26 7.3.. . . . 32 6.2 Anyone Pretending to Be a 6to4 Relay Router ................. 26 7.3.1.. . . . . . . . . . . . 33 6.2.1 Limited Distribution of More Specific Routes ....... 27 7.3.2.. . . . . . . . 34 6.2.2 A Different Model for 6to4 Deployment .............. 28 8.. . . . . . . . . . . 35 7. Security Considerations .................................... 28 9. Acknowledgements ........................................... 29 10. References ................................................ 30 10.1.. . . . . . . . . . . . . . . . . . 35 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 36 Normative References .................................. 30 10.2.. . . . . . . . . . . . . . . . . . . . 36 Informative References ................................ 30 Author's Address ............................................... 31. . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 A. Some Trivial Attack Scenarios Outlined ..................... 31. . . . . . . . . . . 38 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . 40 1. Introduction The IPv6 interim mechanism "6to4" [6TO4] specifies automatic IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds without explicit tunnelsby embedding the tunnel IPv4 address in the IPv6 6to4 prefix. One challenge with thisTwo characteristics of the 6to4 mechanism is that allintroduce most of the security considerations: 1. All 6to4 routers must accept and decapsulate IPv4 packets from every other 6to4 router;router, and 6to4 relays. 2. 6to4 relay routers must accept traffic from any native IPv6 node. Since the 6to4 router must accept from traffic from any other 6to4 router or relay, it implies a certain level of trust, and there are no strict constraints on what the IPv6 packet may contain, which implies a trust relationship. Another, bigger challenge is that to interconnect native IPv6 networkscontain. Thus, addresses within the IPv4, and 6to4 clouds, relay routers are used as bridges between these two clouds. Relay routers can be tricked by malicious parties to send IPv4 orIPv6 traffic anywhere the attacker wants. With source address spoofing, this could be called traffic "laundering" or a "proxy" denial-of-service attack. To some extent, these reflected attacks can alsoheader may be launched off from any node at all. Even worse, anyone can send tunneled traffic, spoofed to come from non-6to4 addresses to any 6to4 router,spoofed, and the node does not have any means to ensure its correctness, butthis property leads to assume it came from a legitimate Relay.various types of threats including DoS, and reflection DoS. The 6to4 specification outlined quite a few security considerations, but it has been shown that in practice some of thesethem have been difficult to get implemented due to their abstract nature. This draft analysesanalyzes the 6to4 security issues in more detail and outlines some enhancements and caveats. Sections 2-4Section 2, and Section 3 are more or less introductory in nature, rehashing how 6to4 should beis used today based on the 6to4 specification, so that it is easier to understand how security could be affected. Section 54 provides a threat analysis for implementations that already implement most of the security checks. Section 65 introduces some filtering rules for 6to4 implementations, and section 7 discusses some additional problemsSection 6 provides further discussion on a few issues which still need some consideration.have proven to be difficult. Appendix A outlines a few possible trivial attack scenarios in the case that very little or no security has been implemented. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", andFor the sake of simplicity, in this document, native IPv6 Internet is assumed to encompass IPv6 networks formed using other transition mechanisms (e.g. RFC 2893 ), as these mechanisms cannot talk directly 6to4 network. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].RFC 2119 . 2. Different 6to4 Forwarding Scenarios It should be noted that when communicating between 6to4 and native domains, the 6to4 relays that will be used in the two directions are very likely different; routing is highly asymmetric. Because of this, it is not feasible to limit relays you accept trafficfrom with e.g. access lists.which 6to4 routers may accept traffic. The first three subsections introduce the most common forms of 6to4 operation. Other models are presented in the fourth subsection. 18.104.22.168 From 6to4 to 6to4 6to4 domains always exchange 6to4 traffic directly via IPv4 tunneling; the endpoint address V4ADDR is derived from 6to4 prefix 2002:V4ADDR.2002:V4ADDR::/48 of the destination. .--------. _----_ .--------. | 6to4 | _( IPv4 )_ | 6to4 | | Routerrouter | <====> ( Internet ) <===> | Routerrouter | '--------' (_ _) '--------' ^ '----' ^ | Direct tunneling over IPv4 | V V .--------. .-------. | 6to4 | | 6to4 | | Clienthost | | Clienthost | '--------' '--------' Figure 1 It is required that every 6to4 router considers every other 6to4 router it wants to talk to to be "on-link" (with IPv4 as the link- layer). If this is restricted by increasing the prefix length from 2002::/16, some traffic will be sent to the 6to4 Relay Router, which would forward it to other 6to4 Routers. However, if the original destination does not have equally long prefix, the traffic it tries to send back will be tunneled directly, and will be dropped. Therefore, the restricted scenario with a longer prefix-length is not globally workable and will not be considered here. 2.2.link-layer). 2.2 From Native to 6to4 When native domains send traffic to 6to4 address 2002:V4ADDR,prefix 2002:V4ADDR::/48, it will be routed to the topologically nearest, advertising (advertising route to 2002::/16) 6to4 Relay Router. Relay routerrelay. The 6to4 relay will tunnel the traffic over IPv4 to the corresponding IPv4 address V4ADDR. (NoteNote that IPv4 address 22.214.171.124 here is just an example of a global IPv4 address.) 2002::/16address, and it is assigned to the 6to4 router's pseudo-interface. Closest to 'Native Client'"Native IPv6 node" .--------. _----_ .------------. .--------. | Native | _( IPv6 )_ | 6to4 Relayrelay | Tunneled | 6to4 | | ClientIPv6 | -> ( Internet ) --> | Routerrouter | =========> | Routerrouter | | node | '--------'(_ _) '------------' 126.96.36.199 '--------' '--------' '----' dst=2002:0900:0001::1dst_v6=2002:0900:0001::1 | V .-------. | 6to4 | | Clienthost | '--------' 2.3.Figure 2 2.3 From 6to4 to Native 6to4 domains send traffic to native domains by tunneling it over IPv4 to their configured 6to4 Relay Router,relay router, or the closest one found using 6to4 IPv4 Anycast [6TO4ANY].. The relay will decapsulate the packet and forward it to native IPv6 Internet, the same way as any other IPv6 packet. Configured/foundNote that destination IPv6 address in the packet is a non-6to4 address, and is assumed to be 2001:db8::1 in the example. Configured -or- found by IPv4 Anycast .--------. _----_ .------------. .--------. | Native | _( IPv6 )_ | 6to4 Relayrelay | Tunneled | 6to4 | | Client | <- ( Internet ) <-- | Routerrouter | <========= | Routerrouter | '--------' (_ _) '------------' 188.8.131.52'--------' 2001:db8::1 '----' (or configured) ^ dst=3ffe:ffff::1| .-------. | 6to4 | | Clientclient | '--------' 2.4.Figure 3 2.4 Other Models These are more or less special cases of 6to4 operation; inoperations. In later chapters, unless otherwise stated, only the most generally-used models (above) will be considered. 184.108.40.206.4.1 BGP Between 6to4 Routers and Relays [6TO4, 220.127.116.11]Section 18.104.22.168 in  presents a model where, instead of static configuration, BGP4+BGP  is used between 6to4 Relay Routersrelay routers and 6to4 Routers.routers. If the 6to4 router established a BGP session between all the possible 6to4 relays, and advertised its /48 prefix to them, the traffic from non-6to4 sites would always go through "home relay", and configuring "trusted relay" would not become from a problem; an alternative would be to"known" relay. Alternatively, the 6to4 relays might advertise the more specific 6to4 routes between 6to4 Relays,relays, as described laterin Section 6.2.1 in this memo. This model is notNeither of these models are known to be used at the time of writing; this is probably caused by the fact that parties that need 6to4 are those that are not able to run BGP, and because setting up these sessions would be much more work for relay operators. 22.214.171.124.4.2 6to4 as an Optimization Method Some sites seem to use 6to4 as an IPv6 connectivity "optimization method"; that is, they have also non-6to4 addresses on their nodes and border routers, but also employ 6to4 to reach 6to4 sites. This is typically done to be able to reach 6to4 destinations by direct tunneling and not having to use relays at all. SomeThese sites also publish both 6to4 and non-6to4 addresses in DNS to affect inbound connections; if the source host's default address selection [ADDRSEL] works properly, 6to4 sources will use 6to4 addresses to reach the site and non-6to4 nodes use non-6to4 addresses. If this behaviourbehavior of foreign nodes can be assumed, the security threats to such sites can be significantly simplified. 126.96.36.199.4.3 6to4 as Tunnel End-Point Addressing Mechanism 6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel endpoint addressing and routing mechanism. An example of this is interconnecting 10 branch offices where nodes use non-6to4 addresses. Only the offices' border routers need to be aware of 6to4, and use 6to4 addresses solely for addressing the tunnels between different branch offices. This assumes that all outgoing traffic from theAn example is provided in the figure below. 2001:db8:0:10::/60 2001:db8:0:20::/60 .--------. .--------. ( Branch 1 ) ( Branch 2 ) '--------' '--------' | | .--------. _----_ .--------. | 6to4 | _( IPv4 )_ | 6to4 | | router | <====> ( Internet ) <===> | router | '--------' (_ _) '--------' 188.8.131.52 '----' 184.108.40.206 ^^ || vv .--------. | 6to4 | 220.127.116.11 | router | '--------' | 2001:db8::/48 .-----------. ( Main Office ) '-----------' ^ | v _----_ _( IPv6 )_ ( Internet ) (_ _) '----' Figure 4 In the figure, the main organization (but not betweenoffice sets up two routes: 2001:db8:0:10::/60 -> 2002:0900:0001::1 2001:db8:0:20::/60 -> 2002:0800:0002::1 And a branch offices) uses one or more non-6to4 connections. This is similar tooffice sets up two routes as well: 2001:db8:0:20::/60 -> 2002:0800:0002::1 default -> 2002:0700:0003::1 Thus, the optimization model above, and canIPv4 Internet is treated as NBMA link-layer for interconnecting 6to4-enabled sites; with explicit routes, 6to4 addressing need not be used in other than the 6to4 edge routers. However, note that if a branch office sends a packet to makeany 6to4 destination, it will not go through the main office as the 6to4 2002::/16 route overrides the default route. This approach may make addressing and routing easier.slightly easier in some circumstances. 3. SomeFunctionalities of 6to4 In this section, some, relatively obvious features of different 6to4 components are listed to better undestand what's the required behaviour. 3.1. Functions of Different 6to4Network Components o Non-6to4 (Native) Node If native IPv6 nodes want to communicate with 6to4 nodes, they sendThis section summarizes the traffic along normally. The traffic will reachmain functionalities of the topologically closest, advertising6to4 Relay Router,network components (6to4 routers, and will6to4 relays), and the security checks that must be tunneled todone by them. The pseudo-code for the destination 6to4 Router, which will pass it tosecurity checks is provided in Section 5. This section summarizes the 6to4 node via normal forwarding process. o 6to4 Host A host, usually autoconfigured,main functions of the various components that has an address fromare part of a 6to4 prefix, but doesn't have anetwork - 6to4 pseudo-interface. It doesn't need to know anything about 6to4,relay routers, and it acts like a normal IPv6 Host in every manner. Note that6to4 Hosts can also berouters. Refer to Section 1.1 of RFC 3056  for 6to4 Routers in some scenarios, but thenrelated definitions. 3.1 6to4 Router functionalities, below, apply. oRouters The 6to4 Router Acts atrouters acts as the border router of a 6to4 domain. It does not have a native, global IPv6 address. More specifically: - provide "native-like"The main functions of the 6to4 router are: o Provide IPv6 connectivity to local clients and routers - ifrouters. o Tunnel packets aresent to foreign 6to4 addresses, tunnel themaddresses to the destination 6to4 router using IPv4 - ifIPv4. o Forward packets aresent to locally configured 6to4 addresses, forward them normally - ifaddresses to the 6to4 network. o Tunnel packets aresent to non-6to4 addresses, tunnel themto the configured/closest-by-anycastconfigured/ closest-by-anycast 6to4 Relay Router, which will pass them on - if packets arerelay router. o Decapsulate directly received from 6to4 addresses, decapsulate theIPv4 packets receivedfrom foreign 6to4 routers - if packets are received from non-6to4 addresses, decapsulate theaddresses. o Decapsulate IPv4 packets received from 6to4 Relay Routervia the relay closest to the source (note:native IPv6 sources. Note, it is not easily distinguishable that the packet was really received from a Relay6to4 relay router, not from a spoofing third party.) o 6to4 Relay Router Acts as a relay between allThe 6to4 domains and native IPv6; more specifically: - advertises the reachability of the 2002::/16 prefix to native IPv6 routing, thus receivingrouter will also perform security checks on traffic to allthat it will receive from other 6to4 addressesrelays, or 6to4 routers, or from closest native IPv6 nodes - (if implements RFC3068) advertisewithin the reachability of IPv4 '6to4 Relay anycast prefix' (18.104.22.168/24) to6to4 site. These checks include: o Disallow traffic that has private, broadcast or reserved IPv4 routing, thus receiving some tunneledaddresses in tunnels, or the matching 6to4 prefixes. o Disallow traffic to native IPv6 nodesfrom 6to4 Routers - if packets are received fromrouters where the IPv4 tunnel source address does not match the 6to4 addresses through tunneling, decapsulate them and forwards them onprefix. o Disallow traffic where the destination IPv6 address is not a global address; in particular, e.g. link-local addresses, mapped addresses and such should not be used. o Disallow traffic transmission to other 6to4 domains through 6to4 relay router or via some third party 6to4 router. o Discard traffic received from other 6to4 domains via a 6to4 relay router. o Discard traffic received for prefixes other than self 6to4 prefix(es). 3.2 6to4 Relay Routers The 6to4 relay router acts as a relay between all 6to4 domains and native IPv6 networks; more specifically: o It advertises the reachability of the 2002::/16 prefix to native IPv6 routing, thus receiving traffic to all 6to4 addresses from closest native IPv6 nodes. o Advertise (if RFC 3068  is implemented) the reachability of IPv4 "6to4 relay anycast prefix" (22.214.171.124/24) to IPv4 routing, thus receiving some tunneled traffic to native IPv6 nodes from 6to4 routers. o Decapsulate, and forward packets received from 6to4 addresses through tunneling, using normal IPv6 routing - ifrouting. o Tunnels packets arereceived through normal IPv6 routing from native addresses, and are destined for 2002::/16, tunnel themto the corresponding 6to4 Router 3.2. Non-functions of Differentrouter. The 6to4 Network Components What should not happen; this forms a basis for therelay will also perform security checks. The lists are not exhaustive. ochecks on traffic that it will receive from 6to4 Routerrouters, or Relay - usefrom native IPv6 nodes. These checks are: o Disallow traffic that has private, broadcast or reserved IPv4 addresses in tunnels, or the matching 6to4 prefixes - receiveprefixes. o Disallow traffic from 6to4 Routersrouters where the IPv4 tunnel source address does not match the 6to4 prefix - receiveprefix. o Disallow traffic where the destination IPv6 address is not a global address; in particular, e.g. link-local addresses, mapped addresses and such should not be used oused. Note, this check might be incorrect if 6to4 Router - send trafficwere to other 6to4 domains through 6to4 Relay Router or via some third party 6to4 Router - receivebe used. o Discard traffic received from other 6to4 domains via a6to4 Relay Router - receive traffic to other than to your own 6to4 prefix(es) orouters with the destination as a 6to4 Relay Router - receive traffic fromprefix. 4. Threat Analysis This section discusses attacks against the 6to4 tonetwork or attacks that are caused by the 6to4 4. Special Processingnetwork. The threats are discussed in light of the 6to4 Packets One could summarizedeployment models defined in the special processingSection 2. There are three general types of 6to4 as follows: o Relay Routerthreats: 1. incoming from native, tunneled to 6to4Denial-of-Service (DoS) attacks, in which a malicious node prevents communication between the node under attack and other nodes. 2. tunneled from 6to4, goingReflection Denial-of-Service (DoS) attacks, in which a malicious node reflects the traffic off unsuspecting nodes to native o Router 1. tunneled from relay, sourcea particular node (node under attack) with the intent of preventing communication between the node under attack and other nodes. 3. Service theft, in which a malicious node/site/operator may make unauthorized use of service. 6to4 also provides a means for a "meta-threat", traffic laundering, in which some other attack is native 2. tunneledchanneled through the third parties to relay, destination is native 3. tunneled directly, destinationmake it more difficult to trace the real origin of the attack. This is used in conjunction with other threats, whether specific to 6to4 4.1. Encapsulating IPv6 Packets into IPv4 IPv6 packetsor not. At this point it is important to reiterate that the attacks are encapsulated into IPv4 in three scenarios:possible because: 1. 6to4 Router sends packetsrouters have to consider all 6to4 relays, and other 6to4 Routers (2002::/16 destination)routers as "on-link". 2. 6to4 Router sends packetsrelays have to its configured/nearest-by-anycastconsider all 6to4 Relay Router (non-2002::/16 destination)routers as "on-link". 3. Partial implementation of the security checks in the 6to4 Relay Router sends packets from native IPv6 sources to 6to4 Routers (2002::/16 destination) 4.2. Decapsulating IPv4 Packets into IPv6 IPv6 packets are decapsulated from IPv4 in three scenarios: 1. 6to4 Router receives packets from other 6to4 Routers (2002::/16 source) 2. 6to4 Router receives packets fromimplementation. It has been discovered that at least a node, supposedly 6to4 Relay Router closest to the source (non-2002::/16 source) 3. 6to4 Relay Router receives packets from 6to4 Routers, to be sent to native IPv6 destinations (2002::/16 source) 5. Threat Analysis The 6to4 threat analysis presented here focuses on 6to4couple of major implementations which have implemented most ifdo not implement all security checks listed in [6TO4]; in particular, checks that always match 2002:V4ADDR and V4ADDR must be implemented. Many implementations are known to be problematic at least in some cases.the checks. The appendix lists some additional trivial threats whichattacks descriptions are applicable if no or only little security is implemented. Theclassified based on the target of the attack: 1. Attacks on 6to4 networks. 2. Attacks on IPv6 networks. 3. Attacks on IPv4 networks. Note, the IPv4 address blocks 126.96.36.199/24 and 188.8.131.52/24 are only used for demonstrative purposes, representingand represent global IPv4 addresses. 5.1. Threats Related to Any 6to4 Node Any 6to4 node can be made to participate in a DoS attackNote, one of the mitigation methods listed in 5.2.2 below, being used as "dst". The threatfor various attacks is based on the premise that 6to4 relays will a have a feature that may be discussed there. 5.2. Threats Relatedable to limit traffic to/from specific 6to4 Routers Note that insites. At the time of writing this memo,document, such a loose interpretation of "6to4 router" is used; itfeature is usedspeculation, and more work needs to referbe done to those all nodes which havedetermine the 6to4 pseudo-interface. There are two main classeslogistics of threats;such a feature. 4.1 Attacks on 6to4 Networks This section describes attacks against the6to4 pseudo-interface and attacks relying on being able to abusenetworks. Attacks which legerate 6to4 networks, but where the fact that itultimate victim is difficult forelsewhere (e.g., a native IPv6 user, an IPv4 user) are described later in the memo. 6to4 relays and routers are IPv4 nodes, and there is no way for any 6to4 router to tellconfirm the identity of the IPv4 node from which it is receiving traffic -- whether packetsit is a legitimate 6to4 relay or some other node. A 6to4 router has to process traffic from non-6to4all IPv4 nodes. Malicious IPv4 nodes comecan exploit this property and attack nodes within the 6to4 network. It is possible to conduct a variety of attacks on the 6to4 nodes. These attacks are: 1. Attacks with Neighbor Discovery (ND) Messages 2. Spoofing traffic to 6to4 nodes 3. Reflecting traffic from legitimate relays. 184.108.40.206to4 nodes 4. Local IPv4 broadcast attack 4.1.1 Attacks Againstwith ND Messages ATTACK DESCRIPTION Since the 6to4 Pseudo-Interface Unlessrouter assumes all the other 6to4 pseudo-interface has been sufficiently protected, it'srouters, and 6to4 relays are "on-link" it is possible to remotelyattack the pseudo-interface with tunneled6to4 router using ND messages from any node in the IPv4 network, unless a prior trust relationship has been established. The attacks are targeting the 6to4 pseudo-interface. As long as the 6to4 addresses are not used in the source or destination address, the security checks specified by 6to4 take no stance on these packets. Typically these use link-local packets,addresses. These attacks are exacerbated in case the implementation supports more tunneling mechanisms than just as if6to4 (or configured tunneling), because it were in a local network. Threatsis impossible to disambiguate such mechanisms, making it difficult to enable strict security checks (see Section 6.1). The Neighbor Discovery threats (Redirect DoS, or DoS) are listeddescribed in [SEND]. The potential effects of an attack can. Note that all attacks may not be mitigated ifapplicable, as the interface6to4 pseudo-interface is insulated fromassumed not to have a link-layer address (Section 3.8 RFC 2893 ). However, one should note that the other interfaces (e.g.6to4 router can be either a separate neighbor cache). In practise, this is notrouter or host from the case.Neighbor Discovery perspective. THREAT ANALYSIS AND MITIGATION METHODS The attackattacks can be eliminatedmitigated by restrictingusing any of the usefollowing methods: o The usage of ND messages could be prohibited. It implies that all packets using addresses of 6to4 pseudo- interface: if any packet withscope smaller than global is received, it mustlink-local will be silently discarded. ("Local addresses", if specified, might be allowed in some restricted scenarios.) This may conflict withSection 3.1 of RFC 3056  leaves scope for future uses of [6TO4, 3.1]. 220.127.116.11. Comparisonlink-local address. This method has its pitfalls - it would prohibit any sort of ND message, and thus close the doors on development, and use of other ND options. Whether this is a significant problem is another thing. o The 6to4 pseudo-interface could be insulated from the other interfaces (for example, using a separate neighbor cache). o Either IPsec  or an extension of SEND could be used  to Situation withoutsecure packet exchange using link-local address; vanilla SEND would not work as the link-layer does not have an address -- and IPsec would be rather complex. COMPARISON TO SITUATION WITHOUT 6to4 Even though rather simply fixable, this attack is not new as such; the same is possible using automatic tunneling [MECH] or configured tunneling (if one is able to spoof source IPv4 address to that of the tunnel end-point). However, as 6to4 provides open decapsulation, and automatic tunneling is being deprecated, the worst problem comes from 6to4; any open decapsulation is bad. 5.2.2. Relay Spoofing, DoS against IPv6 Nodesdeprecated , 6to4 Routers receive packets from non-6to4 source addresses through Relay Routers, as described in section 2.2 and 4.2 point 2. In the general case, theprovides an easy means which would not exist without 6to4. 4.1.2 Spoofing Traffic to 6to4 router cannot distinguish Relay routers fromNodes ATTACK DESCRIPTION The attacker - a malicious nodes sending IPv4-encapsulatedIPv4 or IPv6 traffic directly to the 6to4 router. This makes two kinds of attacks possible: o unidirectionalnode - can send packets with spoofed source address spoofing, and o Denial-of-Service attack reflection against nativeto a 6to4 node to accomplish a DoS attack. The IPv6 nodes. In both scenarios,and IPv4 addresses of the attacker sends IPv4-encapsulated IPv6packets to the 6to4 router with contents like: srcwill be similar to: src_v6 = 3ffe:1122:3344::1 (forged) dst2001:db8::1 (forged address) dst_v6 = 2002:0900:0002::1 (valid address) src_v4 = 18.104.22.168 (valid or forged address) dst_v4 = 22.214.171.124 (matching dst) Now the 6to4 router receives these packets(valid address, matches dst_v6) For attacks launched from 126.96.36.199,a native IPv6 node, the src_v4 will be the address of the relay through which the traffic will reach the 6to4 node. From IPv4 nodes, src_v4 can be either a spoofed or the real source address. The 6to4 router receives these packets from 188.8.131.52, decapsulates them, discardingdiscards the IPv4 header containing the source address 184.108.40.206 and processes them as normal ("dst"(the attacker has beenguessed or obtained "dst_v6" using one of a number of techniques). In the first scenario, it is assumed that "src" is somehow specially trusted (at least to some extent) more than some other packets.This kind of weak trust based on IP addressesis commonplace.a DoS attack on 6to4 nodes. This enables unidirectional (asattack is similar to ones shown in . EXTENSIONS Replies to the repliestraffic will be lost) source address spoofing, but may be enough for e.g. exploiting some remote vulnerabilities in connectionless protocol server applications. Indirected to the second scenario, if "dst" exists,src_v6 address, resulting in 6to4 nodes in participating in a reflection DoS. This attack is described in more detail in Section 4.2.3. That is, the replies (e.g.(e.g., TCP SYN ACK, TCP RST, ICMPICMPv6 Echo Reply, input sent to UDP echo service, ICMPv6 Destination Unreachable, etc.) are sent to the victim "src",(src_v6), above. All the traces from the original attacker src_v4(src_v4) have been discarded. These return packets will go through a relay. These attacks are similar to ones shown in [RHHASEC]. 220.127.116.11. Comparison to Situation without 6to4 The unidirectional spoofing attack exists withoutCertain 6to4 too, butnetworks may have a trivial ACL (Access Control List) based firewall that allows traffic to pass through if it requirescomes from particular source(s). Such a firewalling mechanism can be bypassed by address spoofing. This attack can therefore be used for trivial ACL avoidance as well. These attacks might be hampered by the attacker is able to spoof IPv6 source addresses. With 6to4, one is ablefact that the replies from the 6to4 node to launch thisthe spoofed address will be lost. THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS The Denial-of-Service attack without anybased on traffic spoofing at all. A restrictionis not new; the only twists come from the fact that traces of an attack are more easily lost, and that spoofing the sourceIPv6 address cannot be spoofedis possible even to belongthose who are unable to the destination site as only non-6to4do so in their current networks. The 6to4 router typically does not log IPv4 addresses can(as they would be spoofed (assuming correct implementations). Blindly trustingtreated as L2 addresses) and thus the source addressof packets coming fromthe Internet without other precautions is very bad practise, though -- and this attack would typically be useful only for spoofing destination site -- which is not possible, and can be protected against with egress filtering. The Denial-of-Serviceattack is also not really new; the only twists come(if launched from the fact that traces ofan attack are more easily lost and that attacker does not really have to even spoof hisIPv4 address to be ablenode) is lost. Since traces to reasonably discreetly launchthe attack. However, itsrc_v4 address can easily be argued that this DoS attack is not critical because: o 6to4 as an enabling mechanism does not provide any possibility for packet multiplication, attacks are generally 1:1, o victim receives packets as replies from "dst": unless echo service (e.g. UDP port 7) is used, the attacker has reasonably little control on the content of packets; for example, pure "SYN" TCP packets often used for flooding cannot be sent, o attack packets pass through choke point(s), namely (one or more) 6to4 relays; in addition to physical limitations,lost, these could implement some form 6to4-site-specific traffic limiting, and o one has to know a valid destination address (however, this is easily guessable or deducible with e.g. an ICMP echo request with a limited Hop Count). The attackattacks can also be be launched from hostsIPv4 nodes whose connection is ingress- filtered, too. So, this enables a way to launch attacks which hide the source address even when it was supposed to be prevented (for IPv4).ingress-filtered. However, often this is not a real factor, as usually the attackers are just zombies and real attackers may not even care if the unspoofed source address is discovered. This is one ofMalicious native IPv6 nodes could be caught easily if ingress filtering was enabled everywhere in the most serious threats. 5.3. Threats RelatedIPv6 Internet. These attacks are easy to 6to4 Relays 6to4 Relays are also subject to attacks,perform, but usually in a different role than 6to4 Routers; usually Relays' function isthe anonymizationextent of the attack and losing trails, not reflection -- as properly implemented relays should be resistant to reflection. 6to4 Relays have onlyharm is limited: o For every packet sent, at most one significant security check they must perform for general safety: when decapsulating IPv4 packets, check that 2002:V4ADDR and V4ADDR match. If thisreply packet is not done, several threats become more serious; in the following, it's assumed that such checks are always done. Also, itgenerated: there is assumed here that the Relay checks that it will not relay packets between 6to4 addresses. In particular, packets decapsulatedno amplification factor. o Attack packets, if initiated from an IPv6 node, will pass through choke point(s), namely a 6to4 routers cannot be encapsulated again towards 6to4 routers, as descibed in rulesrelay; in section 6. It is not clear whether this kindaddition to physical limitations, these could implement some form of check is typically implemented. 5.3.1. Attacks Against6to4-site-specific traffic limiting. On the 6to4 Pseudo-Interfaceother hand, a variety of factors can make the attack serious: o The threats areattacker may have the same as against 6to4 routers. 5.3.2. Spoofing, DoS against IPv6 Nodes If one cannot assume that IPv6 source addresses are ingress-filtered,ability to choose the same threatsrelay, and he might employ the ones best suited for the attacks. Also, some relays use 18.104.22.168  as listed in 5.2.2 apply.the source address making tracing even more difficult. o The difference here is thatrelay's IPv4 address may be used as a native IPv6 node spoofs thesource IPv6 addresses, and the relay router providesaddress for these attacks, potentially causing a layerlot of indirection and losescomplaints or other actions as the trails. 5.3.3. Participating in DoS attacks against IPv4 An attack specific to 6to4 Relays is similarrelay might seem to 6to4 Routers, but against IPv4;be the attacker sends IPv6-nativesource of the attack (see Section 4.2.6 for more). Some of the mitigation methods for such attacks are: 1. Ingress filtering in the native IPv6 networks to prevent packets with an IPv4 address he wantsspoofed IPv6 source being transmitted. It would, thus, make it easy to bomb asidentify the 6to4 destination address, like: src = 3ffe:1122:3344::1 (spoofed or real attacker) dst = 2002:0900:0002::1 (victim) Nowsource of the attack. 2. Security checks in the 6to4 relay. The 6to4 relay receivesmust drop traffic (from the IPv6 internet) that has 6to4 addresses as source address, see Section 5 for more. However, these packets,mitigation methods do not address the case of IPv4 node sending encapsulated IPv6 packets. There exists no simple way to prevent such attacks, and encapsulateslonger term solutions like ingress filtering  or itrace  have to be deployed in both IPv6 and IPv4 packets that are sent towards 22.214.171.124;networks to help identify the destination may not have a faintest ideasource of what IPv6 is, but is bombed with packets coming fromthe relay'sattacks. COMPARISON TO SITUATION WITHOUT 6to4 Traffic spoofing is not a new phenomenon in IPv4 address, includingor IPv6. 6to4 just makes it easier: anyone can, regardless of ingress filtering, spoof a native IPv6 packets as the payload. 126.96.36.199. Comparisonaddress to Situation withouta 6to4 Slightly different arguments apply; below are reasons whynode, even if "maximal security" would be implemented and deployed. Losing trails is also easier. Therefore, depending on how much one assumes ingress filtering is deployed for IPv4 and IPv6, this cancould be considered not tooto be a very serious an attack: oissue, or close to irrelevant compared to the IP spoofing capabilities without 6to4. 4.1.3 Reflecting Traffic to 6to4 as an enabling mechanism does not provide any possibility for packet multiplication, attacks are generally 1:1, o victim receives packets as sent byNodes ATTACK DESCRIPTION Spoofed traffic (as described in the source; ifSection 4.2.2) may be sent to native IPv6 nodes with the victim is an IPv4-only node, it just sees "protocol 41" packets which are not typically dangerous and easily filtered, oaim of performing a reflection attack against 6to4 relay's source IPv4 address is used in packets, and tracingnodes. The spoofed traffic is easier, o sourcesent to a native IPv6 address (spoofednode, either from an IPv4 node (through a 6to4 relay), or real) is infrom a native IPv6 node (unless ingress filtering has been deployed). With the former, the sent packets which may make manual tracing easier, and owould look like: src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node) dst_v6 = 2002:0900:0002::1 (valid address) src_v4 = 188.8.131.52 (valid or invalid address) dst_v4 = 184.108.40.206 (valid address, matches dst_v6) One should note that an attack packets passthrough choke point(s), namely (one or more) 6to4 relays; in addition to physical limitations, these could implement some form 6to4-site-specific traffic limiting. And as counter-arguments, some more serious aspects of it are: o victim receives packets as sent bythe source;relay is prevented if the victim is 6to4 node, IPv6 packetrelay implements proper decapsulation security checks (see Section 5 for details) unless the IPv4 node can include almost anything; however if IPv6spoof the source addess is not spoofed, this attack is nothing new, oaddress to match src_v6. Similarly, the relaysattack from native IPv6 nodes could be prevented by global ingress filtering deployment. These attacks can be choseninitiated by the attacker, sonative IPv6, IPv4, or 6to4 nodes. EXTENSIONS A distributed Reflection DoS can be performed if there area large number of relays, he can pick ones thatnodes are known best suited forinvolved in sending spoofed traffic with the same src_v6. Malicious 6to4 nodes can also (try to) initiate this attack (e.g. bad security policy, ones using 220.127.116.11by bouncing traffic off 6to4 nodes in other 6to4 sites. However this attack may not be possible as source for more difficult tracing, etc.), and othe relay's IPv4 address is used as a source address for these attacks, potentially causing a lot of complaints or other actions as6to4 router (in the relay seems to besite from which the source of this "attack". 5.3.4. Using Any IPv6 Node for Reflection Any IPv6 nodeattack is being launched) will respond to IPv6filter packets destined to the nodewith forged source address belonging to 2002::/16. This(with security checks mentioned in Section 5), and thus the attack is applicable if: owill be prevented. THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS The reverse traffic in this case are replies to the relay chosenmessages received by the attacker does not check that IPv4 source and 2002::/16 source address match, or o the attacker's IPv6 connection is not ingress-filtered (and it was really a non-6to4 source).6to4 nodes. The IPv6 source address being forged,attacker has less control on the node will participate as an unwilling intermediary to an attack throughpacket type in this case, and this would inhibit certain types of attacks. For example, flooding a 6to4 relay against any IPv4node (or 6to4 node), like: src = 2002:0900:0002::1 (forged, target of the attack) dst = 3ffe:1122:3344::1 (intermediary node) This is not new: similar attackwith any other spoofed source address isTCP SYN packets will not be possible if(but e.g., a SYN-ACK or RST would be). These attacks may be countered in various ways: o Implementation of ingress filtering is not enabled. The only difference here is that when attacking IPv4 nodes,by the relay'sIPv4 source address is seen as the immediate sourceservice providers. It would prevent forging of the attack. Closer inspection (after packet reflection) revealssrc_v4 address, and would help in closing down on the IPv6 datagram with (possibly spoofed) 2002::/16 destination address. 18.104.22.168. Comparisonculprit IPv4 nodes. Note that, it will be difficult to Situation without 6to4 Thisshut down the attack isif a reflected variationlarge number of IPv4 nodes are involved. These attacks may be also be stopped at the attack above;6to4 sites if the implications are similar to those in section 22.214.171.124: o A non-compliant 6to4 implementation or IPv6 sourceculprit src_v4 address spoofingis required, o 6to4 as an enabling mechanism does not provide any possibility for packet multiplication, attacks are generally 1:1, o victim receives packets as replies from "dst": unless echo service (e.g. UDP port 7)identified, and if it is used, the attacker has reasonably little control on the content of packets; for example, pure "SYN" TCP packets often used for flooding cannotconstant, by filtering traffic from this address. Note that it would be sent, o attack packets pass through choke point(s), namely (one or more) 6to4 relays; in additiondifficult to physical limitations, these couldimplement some form 6to4-site-specific traffic limiting, and o the relay's IPv4 addressthis method, if appropriate logging is used as a source address for these attacks, potentially causingnot done by the 6to4 router, or if a lotlarge number of complaints6to4 nodes, and/ or other actions as the relay seems to be the sourcea large number of this "attack". 5.3.5.IPv4 Local Directed Broadcast Attacks This threat is applicable if the relay does not check whethernodes are participating in the IPv4 address it tries to send encapsulatedattack. o Implementation of ingress filtering by all IPv6 packets to is a local broadcast address. This threat is mentioned in [6TO4]. The packetservice providers would eliminate this attack, because src_v6 could not be sent as follows: src = 3ffe:ffff:5678::aaaa (mayspoofed to be forged) dst = 2002:0900:00ff::bbbb 126.96.36.199 is assumed the the relay's broadcasta 6to4 address. After receiving the packet natively, if the relay doesn't check the destination address for subnet broadcast, it would send the encapsulated IP-IP packetHowever, expecting this to 188.8.131.52. This wouldhappen may not be received by all nodes inpractical. o Proper implementation of security checks (see Section 5) both at the subnet,6to4 relays and the responsesrouters would be directed toeliminate the relay. 184.108.40.206. Comparison to Situation without 6to4 This is a special form of "directed broadcast" attack which cannot be protected againstattack, when launched from an IPv4 node, except bywhen the mentioned check. However, there is a significant difference:IPv4 source address was also spoofed -- but then the reply packets are sent backattacker would have been able to just attack the relay. Therefore only the non-compliant device can suffer from this;ultimate destination directly. o Rate limiting traffic at the rest6to4 relays. In a scenario where most of the Internet cannot be affected. 5.3.6. Theft of Service The administrators oftraffic is passing through few 6to4 Relay Routers often want to use some policy to limitrelays, these relays can implement traffic rate-limiting features, and rate-limit the use of relay. The policy control is usually donetraffic from 6to4 sites COMPARISON TO SITUATION WITHOUT 6to4 This particular attack can be mitigated by applying some restrictions inproper implementation of security checks and ingress filtering; where the routing information for 2002::/16 and/or 220.127.116.11/24 (if [6TO4ANY]ingress filtering is used) will spread. Some users may be ablenot implemented, it's typically easier to useattack directly than through reflection -- unless "traffic laundering" is an explicit goal in the service regardless of these controls using: o configuringattack. Therefore, this attack does not seem very serious. 4.1.4 Local IPv4 Broadcast Attack ATTACK DESCRIPTION This threat is applicable if the address of6to4 router does not check whether the relay using itsIPv4 address instead of 18.104.22.168, or o using Routing Headerit tries to routesend encapsulated IPv6 packets to reach some 6to4 Relay (some other routing tricks like neighbors setting static routes are also possible). The former can be protected against using configured access lists in the relay; thisa local broadcast address, or a multicast address. This threat is only feasible ifmentioned in the numberspecification . There practically two kinds of IP networks the relay is supposedattacks: where a local 6to4 user tries to serve is relatively low. Another possible waysend packets to mitigate thisthe address corresponding to the broadcast address, or when someone is able to filter out arriving tunneled packets with protocol 41 (IPv6) whichdo not have thethat remotely. In the 22.214.171.124 asfirst option, assume that 126.96.36.199 is the destination6to4 router's broadcast address. The latter has similar issues:After receiving the IPv6 sourcepacket with a destionation address could be checked solike "2002:0900:00ff::bbbb" from a local 6to4 node, if the packets torouter doesn't check the relay only come fromdestination address for subnet broadcast, it would send the valid IPv6 addresses which are ableencapsulated protocol-41 packet to reach188.8.131.52. This would be received by all nodes in the relay anyway. As Routing Header is not specific to 6to4,subnet, and the main things one could do here with itresponses would be directed to selectthe relay; some generic threats about Routing Header use are described6to4 router. Malicious sites may also embed forged 6to4 addresses in [RHHASEC]. Of these, exceptthe DNS, use of which by a 6to4 node will result in really restricted scenarios, onlya local broadcast by the first may6to4 router. One way to perform this attack would be to send an HTML mail containing a link to an invalid URL (for example, http:// [2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 technology based network. Opening of some interest, andthe mitigatingmail simultaneously would result in a broadcast storm. The second kind of attack is more complex: the problemattack can be initiated by access list is rather straightforward. As this threat doesIPv4 nodes not have implications on other thanbelonging to the organization providing Relay, it is not further analysed. 5.3.7. Relay Operators Seenlocal network as Source of Abuse There are several attacks which uselong as they can send traffic with invalid (for example 2002:0900:00ff::bbbb) source address. The 6to4 Relaysrouter has to anonymize the traffic; this often results in packets being tunneled from the relayrespond to a supposedly-6to4 site. However, as was already pointed out in sections 5.3.3 and 5.3.4,the IPv4 source address usedtraffic by sending ICMPv6 packets back to the relay could, cursorily looking,source, for example Hop Limit Exceeded or Destination Unreachable. The packet would be seenas the sourcefollows: src_v6 = 2002:0800:00ff::bbbb (broadcast address of these "protocol-41" attacks.the router) dst_v6 = 2002:0800:0001::0001 (valid non-existent address) This could causeis a number of concerns forDoS attack. EXTENSIONS The attacks could also be directed at non-local broadcast addresses, but these would be so-called "IPv4 directed broadcasts", which have been (luckily enough) already been extensively blocked in the operators deploying 6to4 relay service, for example: o getting contacted a lot (via email, phone, fax or lawyers)Internet. THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS The attack is based on suspected "abuse", o gettingthe whole IPv4 address range rejected as a source of abuse or spam, causing outage to other operations as well, or o causingpremise that the whole IPv4 address range6to4 router has to besend a packet to be blacklisted in some "spammer databases", if the relay would be used for those purposes. This problem can be avoided (or really, "made someone else's problem")an IPv6 address that embeds an invalid IPv4 address. Such an attack is easily thwarted by usingensuring that the 6to4 anycast address in 184.108.40.206/24 as the source address: blacklisting or rejecting thatrouter does not transmit packets to invalid IPv4 addresses. Specifically traffic should not cause problemsbe sent to the other operations. Further, when someonebroadcast or multicast IPv4 addresses. COMPARISON TO SITUATION WITHOUT 6to4 The first threat is filing complaintssimilar to the owner of 220.127.116.11/24, they notice multiple records and seewhat's already possible with IPv4, but IPv6 does not have broadcast addresses. The second, a pointermore complex threat, is similarly also available in IPv4. In consequence, the security does not seem to [6TO4ANY],be significantly worse than with IPv4, and may learneven that the 6to4 relayis in fact innocent. Of course, this could result in these reports goingrestricted to the closest anycastsite(s) with 6to4 relay as well,implementations which haven't been secured as described in fact had nothing to do with the incident. 5.4. Possible Threat Mitigation MethodsSection 5. 4.2 Attacks on Native IPv6 Internet This section gives a rough idea of mechanisms thought to mitigate the threats. 5.4.1.describes attacks against native IPv6 Internet which leverage 6to4 Decapsulation Cachearchitecture somehow. Attacks against 6to4 decapsulators (routers, relays) could keep a least recently used (LRU) header cache of possibly a few hundred entries of recently seen packets for tracing purposes. The problem here is how that kind of data couldnodes were described in the previous section. Native IPv6 nodes can be extracted --accessed by third parties that need it --6to4 and IPv4 nodes through the 6to4 relay routers. Thus the 6to4 relays play a crucial role in timely fashion. Many implementations are, of course, already able toany attack on native IPv6 nodes by IPv4 nodes or 6to4 nodes. 6to4 relays have only one significant security check they must perform something likefor general safety: when decapsulating IPv4 packets, check that 2002:V4ADDR::/48 and V4ADDR match. If this by e.g. manually set logging access lists. 5.4.2. Rate-limiting atis not done, several threats become more serious; in the following analysis, it is assumed that such checks are implemented. 6to4 Routers/Relays TBD. 5.4.3. An Application of iTrace Modelrelay should not relay packets between 6to4 decapsulators (or some of them) could send out some specificaddresses. In particular, packets probabilitically as a way ensure that reflectors cannotdecapsulated from 6to4 routers should not be used to lose trails of an attack. This could either be a simplification or an extension of e.g. [ITRACE] model, depending on how fast its specification goes. The most important place for this would be atencapsulated again towards 6to4 Routers, to counter the reflection attack descibedrouters, as described in 5.2.2. If so, the check could be placed at the decapsulation phase whererules in Section 5. Similarly, packets have awith 6to4 source and destination address but the sourcesent from IPv6 nodes should not be relayed. It is non-6to4. The iTrace working group has been concluded due to decreased applicabilitynot clear whether this kind of the work.check is typically implemented. The documents may move forwardattacks described below assume that such checks are not implemented. 4.2.1 Attacks with ND Messages These attacks are the same as individual submissions. 5.5. Summary It would be useful to tryemployed against 6to4 routers as described in Section 4.1.1. 4.2.2 Spoofing Traffic to characterize the different threats by comparing the severity of the threat to: 1.Native IPv6 node ATTACK DESCRIPTION The attacker - a malicious IPv4 networks today, where in many cases (even most),or 6to4 node - can send packets with spoofed (or not spoofed) 6to4 source address spoofing is possible and there are no easy waysto trace attacks 2. Hypothetical IPv4 networks -- the case if ingress filtering would be deployed everywhere 3. Hypotheticala native IPv6 networks --node to accomplish a DoS attack. The threat is similar as the case if ingress filtering would be deployed everywhereone involving 6to4 routers as described in current and futureSection 4.1.2. The difference here is that the attack is initiated by IPv4 nodes, or 6to4 nodes. The source IPv6 networks However, this wouldaddress may or may not be very difficultspoofed. Note, as itmentioned above, the relay is not easy to assign severity valuesassumed to allcorrelate source IPv4 address with the features 6to4 adds and try to decide whether it's more serious or not. 5.5.1. Summary of the Threats Below is the summary of the threats discussed above. Threataddress embedded in 5.1 was merged with 5.2.2 asthe effects aresource IPv6 address during decapsulation. A side effect is that all the same but fromspoofed traffic will have a different perspective. +----+-----+--------------------+-------+-------+---+---+----+ |Type| Sec | Characterization | Using |Against|Fix|I-F|Comp| +----+-----+--------------------+-------+-------+---+---+----+ |Othr|5.2.1|Pseudo-Interface |Rtr/Rly|itself |yes|N/A| 3 | |Othr|5.3.5|Local Direct. Bcast |Rly |itself |yes|N/A| 3 | |Othr|5.3.6|Theft of Service |Rly |itself |yes|N/A| - | |Othr|5.3.7|Relay Seems to Abuse|Rly |any v4 | ? | ? | - | +----+-----+--------------------+-------+-------+---+---+----+ |Spf |5.2.2|Relay Spoofing |Rtr |ownsite| y?| - |same| +----+-----+--------------------+-------+-------+---+---+----+ |Dir |5.3.3|DoS against IPv4 |Rly |any v4 | ? | 6 |1,2 | +----+-----+--------------------+-------+-------+---+---+----+ |Refl|5.2.2|Refl. off any 6to4 |Rtr/Any|non6to4| ? | - | 2 | |Refl|5.3.2|Refl. off any6to4 |R*/Any |non6to4| ? | 6 | 2 | |Refl|5.3.4|Refl. off anysource address. EXTENSIONS Spoofed traffic may also be sent to native IPv6 |Rly/Any|any v4 |1/2|4+6|1,2 | +----+-----+--------------------+-------+-------+---+---+----+ The table is sorted by threat type. Possibilities are spoofing, direct attack, attacknodes by reflection (ie. final attack consists of some response packets) and other. Threats when realize (ab)use some IPv6 nodes: possibilities areeither other native IPv6 nodes, or 6to4 Routers (Rtr), 6to4 Relays (Rly)nodes, or anymalicious IPv4 nodes to conduct Reflection DoS on either native IPv6 nodes or any6to4 nodes (Any). "R*" meansnodes. Certain native IPv6 networks may have a trivial ACL (Access Control List) based firewall that both Relays and Routers are used. The final target of the attack is descibed in "Against";allows traffic to pass through if it comes from particular source(s). Such a firewalling mechanism can be node(s) or network itself,bypassed by address spoofing. This attack can therefore be used for trivial ACL avoidance as well. These attacks might be hampered by the site itself which could preventfact that the attack, any IPv4 node or any non-6to4 IPv6 node (non6to4). If a fix forreplies from the problem is apparent, it is mentioned in6to4 node to the Fix field. If it canspoofed address will be assumed that either complete Internet-wide IPv4 or IPv6 ingress filtering would (more or less) fix or significantly alleviatelost. THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS The Denial-of-Service attack based on traffic spoofing is not new; the problem,only twist comes from the fixing versionfact that traces of ingress filtering is noted in I-F column.an attack are more easily lost. The notable case is 5.3.4 where both v4/v6 ingress filtering is needed -- but if6to4 relay typically does not log IPv4 addresses (as they would be treated as L2 addresses) and thus the halfsource of the readily-available fix is done, IPv6 ingress filtering is enough. The other notable caseattack (if launched from an IPv4 node) is threat 5.2.2, which cannot be disabled by ingress filtering. The last field "Comp" trieslost. Since traces to comparethe threats to their IPv4 equivalents, using: 1. cannot control packets significantly, ie. a weak attack, 2.src_v4 address can easily be mitigated significantly by adding some kind of tracing, or 3. some new form of attack. 5.5.2. Generic Notes about Threats Note: TBD. o correctlost, these attacks can also be be launched from IPv4 nodes whose connection is ingress-filtered. These attacks might be not be very easy to perform, and fully-implemented base security features are a pre- requisite for reasonably safe operation,might be hampered because of: o being able to spoof IPv4 or IPv6 packets enables oneIt might be difficult to launch similar or more powerfulsuch attacks from 6to4 nodes because even currently, o someif the 6to4 attacks provide an additional layerrouters allow spoofing of indirection, which may or may not be useful, othe source IPv6 address, the 6to4 as an enabling mechanism does not provide any possibility for packet multiplication whichrelay would affect global Internet, attacks are generally 1:1, o typically the reflected packets have restricted content, limitingcheck if source V4ADDR is same as the usabilityone embedded in an attack, o attacks typically have eitherthe source IPv6 address. Thus, 6to4 relay router's address or some other information which couldnodes will be used in manual tracing,forced to use the correct IPv6 prefix while lauching attack, and it is easy to close such attacks. o attack packetsPackets may pass through choke point(s), namely (one or more)a 6to4 relays; in additionrelay. In addition to physical limitations, thesethere could implementbe some form 6to4-site-specific traffic limiting, o the relay's IPv4 address is often used as a source address for these attacks, potentially causing a lotsort of complaints or other actions as the relay seems totraffic rate limiting mechanisms which may be the source of this "attack",implemented, and o attacksit could in theory be traceable using an extensiontone down the attack. o For every packet sent, at most one reply packet is generated: there is no amplification factor. Some of [ITRACE] or [REVITRACE], but as those haven't been specified, much less used,the point seems rather academic yet. When considering motivesmitigation methods for DoSsuch attacks and howare: 1. Ingress filtering in the IPv4 Internet to protect against them (and consideringprevent packets with spoofed IPv4 source being transmitted. As the cost, and whetherrelay checks that the protection actually buys you anything),6to4 address embeds the following should notIPv4 address, no spoofing can be forgotten: oachieved done unless IPv4 and IPv6 ingress filtering are not likely toaddresses can be commonplace for a long time; until it is, you cannot really depend on it, ospoofed. 2. Security checks in the real attacker (launching a DoS6to4 relay. The 6to4 relay must drop traffic (from 6to4 nodes, or DDoS) mayIPv4 nodes) that has non-6to4 addresses as source address, or where the source IPv4 address does not really even care whether some zombie nodes get found out, o techniques to trace DoS attacks are stillmatch the address embebdded in infancy (or not even there) yet; due to time anything takesthe source IPv6 address. COMPARISON TO SITUATION WITHOUT 6to4 Compared to get deployed, itSection 4.1.2, which is not clear whether tracing mechanisms even for basic DoS attack mechanisms would get reasonably widely deployed before it was time to (more or less) retire 6to4, and o DoS attacks are something that, in practise, operational people havemore serious, this threat appears to be able to deal with anyway. 6. Implementing Proper Security Checks inslightly more manageable. If the relays perform proper decapsulation checks, the spoofing can only be achived, to a 6to4 In this section, several wayssource address, when IPv4 address is spoofable as well. 4.2.3 Reflecting Traffic to Native IPv6 nodes ATTACK DESCRIPTION These reflection attacks are similar to implementthe security checks requiredone involving 6to4 routers as described in Section 4.1.3. Traffic may be reflected off native IPv6 nodes, or implied6to4 nodes. The attack can be initiated by [6TO4] or augmentedeither: o Native IPv6 nodes. These nodes can send invalid traffic with spoofed native IPv6 addresses to valid 6to4 nodes. Replies from the 6to4 nodes are part of a reflection attack. o IPv4 nodes. These nodes can send traffic with native IPv6 source addresses (encapsulated by this specificationthe IPv4 node itself into a protocol-41 packet) to 6to4 nodes. Replies from the 6to4 nodes are described.part of a reflection attack. o 6to4 nodes. These do not, in general, protech againstnodes can perform similar attacks to the majorityones by IPv4 nodes, but that would require spoofing of the threats listed above insource address at the threat analysis. They're just prerequisites for6to4 site before encapsulation; that is likely to be difficult. When launched from a relatively safe and simplenative IPv6 node, the traffic goes through 6to4 implementation. Two different sets of rules are listed, "generic",relays twice, both after and "simplified". The former addressesbefore the required rules inreflection; when launched from a 6to4/IPv4 node, the generic form;traffic goes through a relay only after the latter simplifies them usingreflection. EXTENSIONS A distributed Reflection DoS can be performed if a numberlarge number of assumptions to increase the readability. 6.1. Generic Approach 6.1.1. Encapsulatingnative IPv6 into IPv4 src and dst MUST pass ipv6-sanity checks, else drop (defined below) if src=2002 src MUST match src_v4 /* the scenario: 4.1. case 1.nodes or 2. */ if dst=2002 dst_v4 SHOULD NOT be assigned toIPv4/6to4 nodes are involved in sending spoofed traffic with the router (avoid misconfigurations) /*same source IPv6 address. THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS Some of the scenario: 4.1. casemitigation methods for such attacks are: 1. */ fi elif dst=2002 dst_v4 MAY have to match one of ipv4 equiv. of 6to4 prefixes maskedAttacks from the native IPv6 nodes could be stopped by a user-specified prefix length (restricting who can useimplementing ingress filtering in the relay) /*IPv6 Internet. 2. Two measures are needed to stop or mitigate the scenario: 4.1. case 3. */ else drop /*attacks from IPv4 nodes: 1) Implementing ingress filtering in the scenario: we somehow got a native-native ipv6 packet */ fi accept 6.1.2. DecapsulatingIPv4 into IPv6 src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop (defined below) srcinternet, and dst MUST pass ipv6-sanity checks, else drop (defined below) if dst=2002 dst MUST match dst_v4 /*2) logging IPv4 source address in the scenario: 4.2. case 1. or 2. */ if src=2002 src MUST match src_v4 dst_v4 SHOULD6to4 router. 3. Attacks from 6to4 nodes in other sites can be assigned tostopped if the 6to4 router (see notes below) /*in those sites implements egress filtering. 4. The traffic passes through one or two relays, and traffic rate limiting in the scenario: 4.2. case 1. */ fi elif src=2002 src MUST match src_v4 dst_v4 SHOULD be assigned to6to4 relays might help tone down the router (see notes below) src_v4 MAY have to match one of ipv4 equiv. ofreflection attack. COMPARISON TO SITUATION WITHOUT 6to4 prefixes maskedEven thought there are means to mitigate the attack, it is still rather efficient, especially when used by a user-specified prefix length (restricting who can usenative IPv6 nodes with spoofed addresses. Using 6to4 relays and routers could easily take down the relay) /*6to4 relay system and/or provide an easy means for traffic laundering. However, if the scenario: 4.2. case 3. */ else drop /*intent of the scenario: we somehow got a native-native ipv6 packet */ fi accept 6.1.3. IPv4attack is just to DoS the victim, it can be achieved more smoothly by doing it directly (as the source address spoofing was available as well). Therefore, the threat seems to be higher to the availability and stability of the 6to4 relay system itself than to native IPv6 Sanity Checks 18.104.22.168. IPv4Internet. 4.2.4 Local IPv4 address MUST be a global unicast address, as required byBroadcast Attack This attack is similar to the ones employed against 6to4 specification. The disallowed addresses include those definedrouters as described in [RFC1812], and others widely used and known notSection 4.1.4. There are slight differences with regard to the source of the attacks. This attack can be global. These are: o 0.0.0.0/8 (the system has no address assigned yet) o 10.0.0.0/8 (private) o 127.0.0.0/8 (loopback) o 172.16.0.0/12 (private) o 192.168.0.0/16 (private) o 169.254.0.0/16 (IANA Assigned DHCP link-local) o 22.214.171.124/4 (multicast)initiated by: o 255.0.0.0/8 (broadcast) In addition it MUST be checkedNative IPv6 nodes that may send traffic to the relay's subnet broadcast address. o IPv4 nodes that may send traffic with spoofed source IP address is not any of(to be the system'srelay's broadcast addresses. This is especially important ifaddress) to elicit replies (e.g., ICMPv6 Hop Limit Exceeded messages) from the implementation6to4 relay to its local nodes. The first is made somore dangerous than in Section 4.1.4 because it can be initiated by any IPv6 node (which is allowed to use the relay, that is), not limited to local users. The second is trickier and not really useful. For it can: o receiveto succeed, the relay would have to accept native source addresses over the 6to4 pseudo-interface (but we did not assume this check was implemented), as if coming from another relay, and process encapsulatedtrigger an ICMPv6 message to the relay's local IPv4 packets arriving at its broadcast addresses, or o send encapsulated IPv4 packetssubnet. The former method is more lucrative. EXTENSIONS None. THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS The threat is restricted to onethe relay's local subnet, and is fixed by tightening the 6to4 security checks. COMPARISON TO SITUATION WITHOUT 6to4 This scenario is caused by 6to4, but fortunately, the issue is not serious. 4.2.5 Theft of its broadcast addresses. 126.96.36.199. IPv6Service ATTACK DESCRIPTION The 6to4 relay administrators would often want to use some policy to limit the use of the relay to specific 6to4 sites and/or specific IPv6 address MUST NOT be: o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...) o fe80::/10 (link-local) o fec0::/10 (site-local) o ff02::/16 (link-local multicast) Other multicast could also be considered for filtering. In addition, it MUST be checked that equivalent 2002:V4ADDR checks, where V4ADDRsites. The policy control is any ofusually done by applying restrictions to where the above IPv4 addresses,routing information for 2002::/16 and/or 188.8.131.52/24 (if the anycast address used ) will notspread. Some users may be passed. 184.108.40.206. Optional Ingress Filtering In addition,able to use the implementation may perform some formservice regardless of ingress filtering (e.g. Unicast Reverse Path Forwarding checks). For example, ifthese controls, by: o Configuring the 6to4 Router has multiple interfaces,address of which some are "internal", receiving eitherthe relay using its IPv4 address instead of 220.127.116.11, or o Using the Routing header to route IPv6 packets with source address belongingto any of these internal networks from the Internet mightreach specific 6to4 relays. (Some other routing tricks like using static routes may also be disallowed. If these checks are implemented, it is RECOMMENDED that they defaultused.) EXTENSIONS None. THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS Attempts to disabled. 18.104.22.168. Notes Aboutuse the Checks The rule 'dst_v4 SHOULDrelay's IPv4 address instead of 22.214.171.124 can be assigned tomitigated in the router' is not needed iffollowing ways: 1. IPv4 domains should prevent usage of the implementation is madeactual IPv4 address of the relay instead of 126.96.36.199. 2. Usage of access lists in such a way that itthe 6to4 relay to limit access. This is only accepts and processes encapsulated IPv4 packets arriving on unicast IPv4 addresses, and thatfeasible if destination addressthe number of IP networks the relay is knownsupposed to be a local broadcast address,serve is relatively low. 3. The 6to4 relay should filter out arriving tunneled packets with protocol 41 (IPv6) which do not tryhave the the 188.8.131.52 as the destination address. The other threat of using routing tricks in the IPv6 networks to encapsulate and sendreach the 6to4 relay has similar solutions: 1. Usage of access lists in the relay to limit access. 2. Filtering out the packets with a routing header (may have other implications). 3. Monitoring the source addresses going through the relay, to it (see section 5.3.5 about this threat). Some checks, especiallydetect e.g. peers setting up static routes. Routing Header is not specific to 6to4, the IPv4/IPv6 Sanity Checks,main things one could be at least partially implementabledo here with system-level access lists, if oneit would likebe to avoid placing too many restrictions in the 6to4 implementation itself. This depends on how many hooks forselect the access listsrelay; some generic threats about Routing Header use are described in place. In practice it seems like. As this couldthreat does not be done effectively enough unlesshave implications on other than the access list mechanismorganization providing 6to4 relay, it is ablenot analyzed any further. COMPARISON TO SITUATION WITHOUT 6to4 These threats are specific to parse the encapsulated packets within IP-IP. 6.2. Simplified Approach6to4 relays (or in general, anycast services), and do not exist in networks without 6to4. 4.2.6 Relay Operators Seen as Source of Abuse ATTACK DESCRIPTION There are several attacks which use 6to4 relays to anonymize the traffic; this often results in packets being tunneled from the relay to a supposedly-6to4 site. However, as was already pointed out in Section 4.2, the IPv4 source address used by the relay could, cursorily looking, be seen as the source of these "protocol-41" attacks. This could cause a number of concerns for the operators deploying 6to4 relay service. For example: o Getting contacted a lot (via email, phone, fax, or lawyers) on suspected "abuse", o Getting the whole IPv4 address range rejected as a source of abuse or spam, causing outage to other operations as well, or o Causing the whole IPv4 address range to be to be blacklisted in some "spammer databases", if the relay would be used for those purposes. This threat seems slightly similar (but more generic) to the outburst of SMTP abuse caused by open relays. EXTENSIONS None. THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS This problem can be avoided (or really, "made someone else's problem") by using the 6to4 anycast address in 184.108.40.206/24 as the source address: blacklisting or rejecting that should not cause problems to the other operations. Further, when someone is filing complaints to the owner of 220.127.116.11/24, they notice multiple WHOIS records and see a pointer to , and may learn that the 6to4 relay is in fact innocent. Of course, this could result in these reports going to the closest anycast 6to4 relay as well, which in fact had nothing to do with the incident. However, the wide-spread usage of 18.104.22.168 as the source address may make it more difficult to disambiguate the relays, which might be a useful feature for debugging purposes. COMPARISON TO SITUATION WITHOUT 6to4 This threat is caused by 6to4 deployment, but can be avoided, at least in the short-term, by using the use of 22.214.171.124 as the source address. 4.3 Attacks on IPv4 Internet There are two types of attacks on the IPv4 internet - spoofed traffic, and reflection. They can be initiated by native IPv6 nodes, 6to4 nodes, and IPv4 nodes. Attacks initiated by IPv4 nodes that send spoofed traffic that will not utilize the 6to4 infrastructure are considered out of scope of this document. 6to4 infrastructure may be utilized in reflection attacks that are initiated by IPv4 nodes. It is difficult for these attacks to be effective as the traffic sent out will be IPv6-in-IPv4. Such traffic will be rejected by most IPv4 nodes unless they have implemented some sort of IPv6-in-IPv4 tunneling. Such attacks can easily be thwarted by implementing protocol-41 filtering in IPv4 nodes or sites that do not implement IPv6 over IPv4 tunneling. Such filters should not be made permanent, as they would act as a hurdle if IPv6 over IPv4 tunneling mechanisms were ever to be implemented by the IPv4 node or site. XXX: do these need to be spelled out, as in previous sections? 4.4 Summary of the Attacks Columns: o Section number. The section that describes the attack. o Attack name. o Initiator. The node that initiates the attack. * I_4 - IPv4 node * I_6 - native IPv6 node * 6to4 - 6to4 node * * - All of the above o Victim. The victim node * I_4 - IPv4 node * I_6 - native IPv6 node * 6to4 - 6to4 node * Relay - 6to4 relay * Router - 6to4 router o ToA. Type of Attack * D - DoS * R - Reflection DoS * T - Theft of Service o Fix. Specified who is responsible for fixing the attack. * 6 - The 6to4 developer and/or operator can completely mitigate this attack. * 6* - The 6to4 developer and/or operator can partially mitigate this attack. * E - This threat cannot be fixed by the 6to4 developer or the 6to4 operator. Summary of attacks on a 6to4 network: +-------+----------------------+---------+----------+-----+-----+ | Sec | Attack name |Initiator| Victim | ToA | Fix | +-------+----------------------+---------+----------+-----+-----+ | 4.1.1 | Attacks with ND | I_4 | Router | D | 6 | +-------+----------------------+---------+----------+-----+-----+ | 4.1.2 | Spoofing Traffic | I_4,I_6 | 6to4 | D | E | +-------+----------------------+---------+----------+-----+-----+ | 4.1.3 | Reflection Attacks | * | 6to4 | R | 6* | +-------+----------------------+---------+----------+-----+-----+ | 4.1.4 | Local IPv4 Broadcast | * | Router | D | 6 | +-------+----------------------+---------+----------+-----+-----+ Figure 8 Summary of attacks on the native IPv6 internet: +-------+----------------------+---------+----------+-----+-----+ | Sec | Attack name |Initiator| Victim | ToA | Fix | +-------+----------------------+---------+----------+-----+-----+ | 4.2.1 | Attacks with ND | I_4 | Relay | D | 6 | +-------+----------------------+---------+----------+-----+-----+ | 4.2.2 | Spoofing Traffic | I_4,6to4| I_6 | D | 6* | +-------+----------------------+---------+----------+-----+-----+ | 4.2.3 | Reflection Attacks | * | I_6 | R | 6* | +-------+----------------------+---------+----------+-----+-----+ | 4.2.4 | Local IPv4 Broadcast | * | Relay | D | 6 | +-------+----------------------+---------+----------+-----+-----+ | 4.2.5 | Theft of Service | 6to4 | Relay | T | 6 | +-------+----------------------+---------+----------+-----+-----+ | 4.2.6 | Relay Operators ... | - | - | D | 1) | +-------+----------------------+---------+----------+-----+-----+ Figure 9 Notes: 1) This attack is a side-effect of the other attacks, and thus does not have any Initiator, Victim, and Fix. It is a Denial of Service attack not on the network but on the organization in-charge of the relay. Summary of attacks on IPv4 internet: +-------+----------------------+---------+----------+-----+-----+ | Sec | Attack name |Initiator| Victim | ToA | Fix | +-------+----------------------+---------+----------+-----+-----+ | 4.3 | Spoofing Traffic | * | I_4 | D | 6* | +-------+----------------------+---------+----------+-----+-----+ | 4.3 | Reflection Attacks | * | I_4 | R | 6* | +-------+----------------------+---------+----------+-----+-----+ Figure 10 5. Implementing Proper Security Checks in 6to4 In this section, several ways to implement the security checks required or implied by the specification  or augmented by this memo are described. These do not, in general, protect against the majority of the threats listed above in the "Threat Analysis" section. They're just prerequisites for a relatively safe and simple 6to4 implementation. Note that in in general, the 6to4 router or relay does not know whether it is acting as a router or relay. It would be possible to include a toggle to specify the behaviour, to be used e.g., when the interface is brought up, but at least in February 2004, no implementations were known to do that. Due to that, the checks are described as one -- which works independent of whether the node is a router or relay. 5.1 Encapsulating IPv6 into IPv4 The checks described in this section are to be performed when encapsulating IPv6 into IPv4. src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below), else drop if prefix (src_v6) == 2002::/16 ipv4 address embedded in src_v6 MUST match src_v4 if prefix (dst_v6) == 2002::/16 dst_v4 SHOULD NOT be assigned to the router fi else drop /* we somehow got a native-native ipv6 packet */ fi accept 5.2 Decapsulating IPv4 into IPv6 The checks described in this section are to be performed when decapsulating IPv4 into IPv6. They will be performed in both the 6to4 router and relay. src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop src_v6 and dst_v6 MUST pass ipv6-sanity checks, else drop if prefix (dst_v6) == 2002::/16 ipv4 address embedded in dst_v6 MUST match dst_v4 if prefix (src_v6) == 2002::/16 ipv4 address embedded in src_v6 MUST match src_v4 dst_v4 SHOULD be assigned to the router fi elif prefix (src_v6) == 2002::/16 ipv4 address embedded in src_v6 MUST match src_v4 dst_v4 SHOULD be assigned to the router (see notes below) else drop /* the we somehow got a native-native ipv6 packet */ fi accept 5.3 IPv4 and IPv6 Sanity Checks The encapsulation and decapsulation checks included certain sanity checks for both IPv4 and IPv6. These are described here in detail. 5.3.1 IPv4 IPv4 address MUST be a global unicast address, as required by the 6to4 specification. The disallowed addresses include those defined in , and others widely used and known not to be global. These are: o 0.0.0.0/8 (the system has no address assigned yet) o 10.0.0.0/8 (private) o 127.0.0.0/8 (loopback) o 172.16.0.0/12 (private) o 192.168.0.0/16 (private) o 169.254.0.0/16 (IANA Assigned DHCP link-local) o 126.96.36.199/4 (multicast) o 240.0.0.0/4 (reserved and broadcast) In addition, the address MUST NOT be any of the system's broadcast addresses. This makes some assumptions aboutis especially important if the implementation is made so that it can: o receive and process encapsulated IPv4 packets arriving at its broadcast addresses, or o send encapsulated IPv4 packets to one of its broadcast addresses. 5.3.2 IPv6 IPv6 address MUST NOT be: o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...) o fe80::/10 (link-local) o fec0::/10 (site-local) o ff00::/8 (any multicast) Note: only link-local multicast would be strictly required, but it is believed that multicast with 6to4 will not be feasible, so it has been disallowed as pointed above to simplifywell. In addition, it MUST be checked that equivalent 2002:V4ADDR::/48 checks, where V4ADDR is any of the above rules. 6.2.1. Encapsulating IPv6 intoIPv4 src and dst MUST pass ipv6-sanity checks, else dropaddresses, will not be passed. 5.3.3 Optional Ingress Filtering In addition, the implementation in the 6to4 router may perform some form of ingress filtering (e.g. Unicast Reverse Path Forwarding checks). For example, if src=2002 src MUST match src_v4 elif dst=2002 (accept) else drop fi accept 6.2.2. Decapsulatingthe 6to4 router has multiple interfaces, of which some are "internal", receiving either IPv4 intoor IPv6 src_v4packets with source address belonging to any of these internal networks from the Internet might be disallowed. If these checks are implemented, and dst_v4 MUST pass ipv4-sanity checks, else drop srcare enabled by default, it's recommended that there is a toggle to disable them if needed. 5.3.4 Notes About the Checks The rule "dst_v4 SHOULD be assigned to the router" is not needed if the 6to4 router implementation only accepts and dst MUST pass ipv6-sanityprocesses encapsulated IPv4 packets arriving its unicast IPv4 addresses, and when destination address is known to be a local broadcast address, it does not try to encapsulate and send packets to it. (see Section 4.1.4, and Section 4.2.4 about this threat). Some checks, else drop if dst=2002 dst MUST match dst_v4especially the IPv4/IPv6 Sanity Checks, could be at least partially implementable with system-level access lists, if src=2002 src MUST match src_v4 fi elif src=2002 src MUST match src_v4 else drop fi accept 7.one would like to avoid placing too many restrictions in the 6to4 implementation itself. This depends on how many hooks for the access lists are in place. In practice it seems that this could not be done effectively enough unless the access list mechanism is able to parse the encapsulated packets. 6. Issues in 6to4 Implementation and Use This section tries to give an overview of some of the problems 6to4 implementations are faced with, and whichthe kind of generic problems the 6to4 users could come up with. 188.8.131.52 Implementation Considerations with Automatic Tunnels There is a problem with multiple transition mechanisms if strict security checks are implemented. This may vary a bit from implementation to implementation. Consider three mechanisms using automatic tunneling: 6to4, ISATAP [ISATAP] and Automatic Tunneling using Compatible Addresses [MECH].. All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with, more or less, a pseudo-interface. When a router, which has any two of these enabled, receives an IPv4 encapsulated IPv6 packet: src_v6 = 2001:db8::1 dst_v6 = 2002:1010:1010::2 src_v4 = 10.0.0.1 dst_v4 = 184.108.40.206 src = 3ffe:ffff::1 dst = 2002:1010:1010::2 whatWhat can it do? How should it decide which transition mechanism this belongs to; there is no "transition mechanism number" in IPv6 or IPv4 header to signify this. (This can also be viewed as a flexibility benefit.) Without any kind of security checks (in any of implemented methods) these often just "work" as the mechanisms aren't differentiated but handled in "one big lump". Configured tunneling [MECH] does not suffer from this as it is point- to-point,point-to-point, and based on src/dstsrc_v6/dst_v6 pairs of both IPv4 and IPv6 addresses it can be deduced which logical tunnel interface is in the question. Solutions for this include 1) not using more than one automatic tunneling mechanismsmechanism in the same systema node or 2) binding different mechanisms to different IPv4 addresses. 7.2. Reduced Flexibility There is a worry about too strict rules limiting the (future) flexibility of 6to4. If later, for some reason, one would want to introduce new revolutionary ways to use 6to4, strict checking in all relevant nodes might prevent it, as new updated version would have to be deployed everywhere before the new method could be used. On the other hand, one could argue that 6to4 has always been intended as an intermediate mechanism, and that future flexibility should not be critical. However, it is difficult to predict how long the intermediate period will be. 220.127.116.11 Anyone Pretending to Be a 6to4 Relay RouterEven though this was already discussed in Section 4.1.2, it bears some additional elaboration as it was the only problem which cannot be even partially solved. That is, 6to4 Routersrouters receive traffic from non-6to4 ("native") sources via 6to4 Relays.relays. 6to4 Routersrouters have no way of matching IPv4 source address of the relay with non-6to4 IPv6 address of the source. In consequence,Consequently, anyone can spoof any non-6to4 IPv6 address he wants by sending traffic, encapsulated, directly to 6to4 Routers. This is analyzed in more detail in the Threat Analysis section, above. Of course, as the source IPv4 address may be logged, many may spoof their IPv4 source address, but the ability to do so is not be required: it is unlikely that source IPv4 (but rather, the spoofed IPv6 address) will be logged anywhere -- this would be equivalent to logging the MAC-addressrouters. Two different models of IP packets. Unfortunately,thinking have been proposed to fix this problem if it is very difficultconsidered to solve properly. There have been three rough ideas: o Every 6to4 Relay must configure and use "18.104.22.168" as the source address of packets that are encapsulated towards 6to4 Routers.be important: o Every 6to4 Relayrelay must participate in an eBGP multi-hop peering mesh (which can be hierarchical): therehierarchical); it would be used to advertise more specific routes will be advertised.routes. o The 6to4 usage model would be turned upside-down, and the deployment of 6to4 would be have to be borne by native IPv6 users. It should be noted that if IPv6 operators do not implement ingress filtering for IPv6, so that spoofing IPv6 is notThese are described at a bit more difficult than spoofing IPv4, these problems have only little impact on the overall security of 6to4 nodes. The first has since then been rejected: the difference in the difficulty of spoofing an address and spoofing it to be 22.214.171.124 does not seem to justify the mechanism. A tentative analysis for the second and third is givenlength below. 126.96.36.199.2.1 Limited Distribution of More Specific Routes If 6to4 prefixes more specific than 2002::/16 could be advertised, the traffic model between native<->6to4native to 6to4 and 6to4<->6to4 to native could be changed so that only one Relay6to4 relay would always be used, most often the one closest to the 6to4 Router.router. This model was rejected in the base specification, as IPv6 routing table was not to be polluted by 6to4 prefixes derived of IPv4 prefixes. However, the problem could be avoided with some effort: creating a separate, possibly hierarchical based on IPv6 connections, peering mesh for 6to4 Relayrelay routers. This could be done by forming eBGP [BGP] multi-hop peerings between Relays,6to4 relays, and advertising more specific routes (e.g.(e.g., the same superblocks of IPv4 addresses one expects to service) to all the other Routers.routers. In that way, the global routing table would not be impacted at all. This seems to have at least three potential issues: o1. Every Relay6to4 relay should be part of this (if one wants to have some extra safety that the addresses haven't been spoofed), o2. The route from a native source takes the path to the first Relay,6to4 relay, and there (possibly through other Relays) to the last Relay6to4 relay to tunnel the packet to the 6to4 Router;router; this adds at least some latency, and o3. The mechanism of redistributing IPv4 6to4 client addresses to other relays as 6to4 prefixes needs work. Of these, only the last requires more discussion. It could be argued that this advertising should either be manually configured once (ie.(i.e., relatively static prefixes, or generated from IPv4 route-objects in RADB etc.) or generated automatically (e.g.(e.g., when a 6to4 Routerrouter first sends a "triggering" packet through the Relay).6to4 relay). Of course, this data could even be derived in some form from the IPv4 routing tables. Further analysis on this is TBD if necessary. This method seemsEven if the traffic to be6to4 routers is limited to few relays, other IPv4 nodes can still spoof both IPv4, and IPv6 address and perform the only one wherespoofing attack. Hence, a necessary step is to use strong cryptography-based mechanisms to be sure aboutensure the 6to4 Routerrouter - 6to4 Relay -relationship could be doable; otherwise,relay relationship. Alternatively, some sort of infrastructure (e.g.(e.g., small-scale PKI) would have to be established which would have to include all the possible 6to4 Relaysrelays in the Internet. 188.8.131.52.2.2 A Different Model for 6to4 Deployment It could be possible to turn the deployment assumptions of 6to4 around a bit to eliminate some threats caused by untrusted 6to4 relays. That is: o Every dual-stack site (or even ISP) would be required to have their own 6to4 relay. That is, there would not be third-party relays, and the 2002::/16 route would not need to be advertised globally, and o The security implications of 6to4 use could be pushed back to the level of trust inside the site or ISP (or their acceptable use policies) -- this is something that the sites and ISPsISP's should be familiar with already. However, this has a number of problems: This model would shift the majority of burden of supporting 6to4 to IPv6 sites which don't employ or use 6to4 at all, e.g.i.e., "those who deploy proper native dual-stack". It could be argued that the deployment pain should be borne by 6to4 users, not the others. The main advantage of 6to4 is easy deployment and free relays. This would require that everyone the 6to4 sites wish to communicate with implement these measures. The model would not fix the "relay spoofing problem", only restrict it a bit,unless everybody deployed also 6to4 addresses on the nodes (alongside with native addresses, if necessary), which in turn would change 6to4 to operate without relays completely. To summarize, it seems like 6to4 cannot be salvaged: the decision is either to embrace it or trash it. 8.7. Security Considerations This draft discusses security considerations.considerations of 6to4. Even if proper checks are implemented, there are significanta large number of different kind of security threats ranging from DoS proxy attacks to spoofing and attacks against 6to4 pseudo-interface. Thesethreats; these threats are analyzed in section 5. As can be seen, thereSection 4. There are mainly three classes of potential problem sources: o1. 6to4 routers not being able to identify whether relays are legitimate o wrongidentify whether relays are legitimate, 2. Wrong or impartially implemented 6to4 router or relay security checks, 3. 6to4 architecture used to participate in DoS or reflected DoS attacks, or made to participate in "packet laundering", i.e., making another attack harder to trace, or impartially implemented4. 6to4 Routers orelays performing packet launderingbeing subject to "administrative abuse", e.g., theft of service, or being seen as a source of abuse. The first is the toughest problem, still under research. The second can be fixed by ensuring the correctness of implementations; this is important. The third is also a difficult, butvery difficult problem, and impossible to solve completely -- therefore it is important to be able to analyze whether this results in a fairly restrictedsignificant increase of threats. The fourth problem as relays are limited in number.seems to have feasible solutions. These are analyzed in detail in Threat Analysis section, above. 9. AcknowledgementsAnalysis, in Section 4. 8. Acknowledgments Some issues were first brought up by Itojun Hagino in [TRANSAB],, and Alain Durand introduced one specific problem at IETF51 in August 2001 (though there was some discussion on the list prior to that); these gave the author the push to start looking into the details of securing 6to4. Alexey Kuznetsov brought up the implementation problem with IPv6 martian checks. Christian Huitema formulated the rules that rely on Relays6to4 relays using only anycast. Keith Moore brought up the point about reduced flexibility. Brian Carpenter, Tony Hain and Vladislav Yasevich are acknowledged for lengthy discussions. Alain Durand reminded of relay spoofing problems. Brian Carpenter reminded of the BGP-based 6to4 router model. Christian Huitema gave a push to a more complete threat analysis. Itojun Hagino spelled out the operators' fears about 6to4 relay abuse. Rob Austein brought up the idea of a different 6to4 deployment model. In the latter phase, especially discussions with Christian Huitema, Brian Carpenter and Alain Durand were helpful when improving the document. David Malone and [your name could be here] gave feedback on the document. 10. References 10.1.Normative References [6TO4] Carpenter, B. and Moore K.,K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [6TO4ANY] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. Informative References [ADDRSEL] Draves, R., "Default Address Selection Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6",IPv6 Hosts and Routers", RFC 3484, February 2003. [BGP]2893, August 2000.  Rekhter, Y.,Y. and T. Li, T.,"A Border Gateway Protocol 4", RFC1771, March 1995. [IPIP] Simpson, W., "IP in IP Tunneling",4 (BGP-4)", RFC 1853, October1771, March 1995. [ISATAP] Templin, F. et al, "Intra-Site Automatic Tunnel Addressing Draves, R., "Default Address Selection for Internet Protocol (ISATAP)", draft-ietf-ngtrans- isatap-15.txt (work-in-progress), Augustversion 6 (IPv6)", RFC 3484, February 2003. [ITRACE] Bellovin, S., Leech, M., Taylor, T., "ICMP Traceback Messages", draft-ietf-itrace-04.txt Nikander, P., "IPv6 Neighbor Discovery trust models and threats", draft-ietf-send-psreq-04 (work in progress), FebruaryOctober 2003. [MECH] Gilligan, R., and Arkko, J., "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-03 (work in progress), January 2004.  Nordmark, E. "Transitionand R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [REVITRACE] Barros, C., "A Proposal for ICMP Traceback Messages", http://www.research.att.com/lists/ietf-itrace/2000/09/ msg00044.html. [RHHASEC]draft-ietf-v6ops-mech-v2-02 (work in progress), February 2004.  Savola, P., "Security of IPv6 Routing Header and Home Address Options", draft-savola-ipv6-rh-ha-security-03.txt (work-in-progress), Decemberdraft-savola-ipv6-rh-ha-security-02 (work in progress), March 2002. [SEND] Nikander, Ferguson, P. (Ed.), "IPv6 Neighbor Discovery trust modelsand threats", draft-ietf-send-psreq-03.txt (work-in-progress), AprilD. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.  Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback Messages", draft-ietf-itrace-04 (work in progress), February 2003. [TRANSAB] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.  Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap-18 (work in progress), February 2004.  Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.  Merit Network Inc., "Routing Assets Database (http:// www.radb.net)".  Hagino, J., "Possible abuse against IPv6 transition technologies", draft-itojun-ipv6-transition-abuse-01.txt (expired, work-in-progress),work-in-progress) , July 2000. Author's Address Barros, C., "Proposal for ICMP Traceback Messages", http:// www.research.att.com/lists/ietf-itrace/2000/09/msg00044.html . Authors' Addresses Pekka Savola CSC/FUNET Espoo,Espoo Finland EMail: email@example.com Chirayu Patel All Play, No Work 185, Defence Colony Bangalore, Karnataka 560038 India Phone: +91-98452-88078 EMail: firstname.lastname@example.org URI: http://www.chirayu.org Appendix A. Some Trivial Attack Scenarios Outlined Here, a few trivial attack scenarios are outlined -- ones that are prevented by implementing checks listed in [6TO4] or in section 6. When two 6to4 Routersrouters send traffic to each others' domains, packet sent by RA to RB is like (note: addresses from 184.108.40.206/24 are just examples of global IPv4 addresses): srcsrc_v6 = 2002:0800:0001::aaaa dstdst_v6 = 2002:0800:0002::bbbb src_v4 = 220.127.116.11 (added when encapsulated to IPv4) dst_v4 = 18.104.22.168 (added when encapsulated to IPv4) When the packet is received by IPv4 stack on RB, it will be decapsulated so that only srcsrc_v6 and dstdst_v6 remain, as originally sent by RA: srcsrc_v6 = 2002:0800:0001::aaaa dstdst_v6 = 2002:0800:0002::bbbb As every other node is just one hop away (IPv6-wise) and the link- layerlink-layer (IPv4) addresses are lost, this may open a lot of possibilities for misuse. As an example, unidirectional IPv6 spoofing is made trivial because nobody can check (without delving into IP-IP packets) whether the encapsulated IPv6 addresses were authentic (With native IPv6, this can be done by e.g. RPF-like mechanisms or access lists in upstream routers). src = 2002:1234:5678::aaaa (forged) dst = 2002:0800:0002::bbbb src_v4 = 22.214.171.124 (added when encapsulateddone by e.g., RPF-like mechanisms or access lists in upstream routers). src_v6 = 2002:1234:5678::aaaa (forged) dst_v6 = 2002:0800:0002::bbbb src_v4 = 126.96.36.199 (added when encapsulated to IPv4) dst_v4 = 188.8.131.52 (added when encapsulated to IPv4) A similar attack with "src" being native address is possible even with the security checks, by having the sender node pretend to be a 6to4 relay router. More worries come in to the picture if e.g., src_v6 = ::ffff:[some trusted IPv4 in a private network] src_v6/dst_v6 = ::ffff:127.0.0.1 src_v6/dst_v6 = ::1 src_v6/dst_v6 = ... Some implementations might have been careful enough to have designed the stack to as to avoid the incoming (or reply) packets going to IPv4 packet processing through special addresses (e.g., IPv4-mapped addresses), but who can say for all ... Appendix B. Change Log [[ RFC-EDITOR note: to be removed before publication ]] Changes from -00 to -01 1. Lots of editorial changes in other sections 2. Revamped the "Threat Analysis" section completely; ripple the effects elsewhere in the document as well. 3. Added Chirayu Patel as a co-author. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to IPv4) dst_v4 = 184.108.40.206 (added when encapsulatedbring to IPv4) A similar attack with "src" being nativeits attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address is possible even withthe security checks, by havinginformation to the sender node pretendIETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be a 6to4 Relay router. More worries comeprepared, copied, published and distributed, in towhole or in part, without restriction of any kind, provided that the picture if e.g. src = ::ffff:[some trusted IPv4above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in a private network] src/dst = ::ffff:127.0.0.1 src/dst = ::1 src/dst = ... Some implementations might have been careful enough to have designedany way, such as by removing the stackcopyright notice or references to the Internet Society or other Internet organizations, except as to avoidneeded for the incoming (or reply) packets goingpurpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to IPv4 packet processing through special addresses (e.g. IPv4-mapped addresses), but who can saytranslate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for all ...the RFC Editor function is currently provided by the Internet Society.