Internet Engineering Task Force P. Savola Internet Draft CSC/FUNET Expiration Date: April 2003 October 2002 Security Considerations for 6to4 draft-savola-v6ops-6to4-security-00.txt Status of this Memo This document is an Internet-Draft and is subject to 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 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 the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract The IPv6 interim mechanism 6to4 [6TO4] uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes Relay Routers and Routers, which accept and decapsulate IPv4 traffic from anywhere. There aren't many constraints on the embedded IPv6 packets, or where IPv4 traffic will be automatically tunneled to. These could enable one to go around access controls, and more likely, being able to perform proxy Denial of Service attacks using Relays as reflectors. Anyone is also capable of spoofing traffic from non-6to4 addresses, as if it was coming from a relay, to a 6to4 router. This document discusses these issues in more detail and tries to suggest enhancements to alleviate the problems. Savola [Expires April 2003] [Page 1] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 Table of Contents 1. Introduction ............................................... 3 2. Different 6to4 Forwarding Scenarios ........................ 4 2.1. From 6to4 to 6to4 ...................................... 4 2.2. From Native to 6to4 .................................... 4 2.3. From 6to4 to Native .................................... 5 3. Some Functionalities of 6to4 ............................... 5 3.1. Functions of Different 6to4 Network Components ......... 5 3.2. Non-functions of Different 6to4 Network Components ..... 7 4. Special Processing of 6to4 Packets ......................... 7 4.1. Encapsulating IPv6 Packets into IPv4 ................... 7 4.2. Decapsulating IPv4 Packets into IPv6 ................... 8 5. Solutions .................................................. 8 5.1. Generic Approach ....................................... 8 5.1.1. Encapsulating IPv6 into IPv4 ....................... 8 5.1.2. Decapsulating IPv4 into IPv6 ....................... 8 5.1.3. IPv4 and IPv6 Sanity Checks ........................ 9 5.1.3.1. IPv4 ........................................... 9 5.1.3.2. IPv6 ........................................... 9 5.1.3.3. Optional Ingress Filtering ..................... 10 5.1.3.4. Notes About the Checks ......................... 10 5.2. Simplified Approach .................................... 10 5.2.1. Encapsulating IPv6 into IPv4 ....................... 10 5.2.2. Decapsulating IPv4 into IPv6 ....................... 11 5.3. All Relays Must Be Anycast ............................. 11 6. Problems ................................................... 12 6.1. Implementation Considerations with Automatic Tunnels ... 12 6.2. Reduced Flexibility .................................... 12 6.3. Anyone Pretending to Be a Relay Router ................. 13 6.3.1. 6to4 Relay Routers Must Use 192.88.99.1 ........... 13 6.3.2. Limited Distribution of More Specific Routes ....... 14 7. Security Considerations .................................... 15 8. Acknowledgements ........................................... 16 9. References ................................................. 16 9.1. Normative References ................................... 16 9.2. Informative References ................................. 16 Author's Address ............................................... 17 A. Some Attack Scenarios Outlined ............................. 17 A.1. IPv6 Spoofing and Access Control Avoidance ............. 18 A.2. IPv4 Local Directed Broadcast Attacks .................. 18 A.3. DoS Reflector .......................................... 19 A.4. Remote Net-access Threats .............................. 20 Savola [Expires April 2003] [Page 2] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 1. Introduction The IPv6 interim mechanism "6to4" [6TO4] specifies automatic IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds without explicit tunnels by embedding the tunnel IPv4 address in the IPv6 6to4 prefix. One challenge with this mechanism is that all 6to4 routers must accept and decapsulate IPv4 packets from every other 6to4 router; 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 networks and 6to4 clouds, relay routers are used as bridges between these two clouds. Relay routers can be tricked by malicious parties to send IPv4, or IPv6, traffic anywhere the attacker wants. With source address spoofing, this could be called traffic "laundering" or a "proxy" denial-of-service attack. Even worse, anyone can send tunneled traffic, spoofed to come from non-6to4 addresses to any 6to4 router, and the node does not have any means to ensure its correctness, but to assume it came from a legitimate Relay. The 6to4 specification outlined quite a few security considerations, but it has been shown that in practice some of these have been difficult to get implemented due to their abstract nature. This draft analyses the 6to4 security issues in more detail and outlines some enhancements and caveats. Sections 2-4 are more or less introductory in nature, rehashing how 6to4 should be used today based on the 6to4 specification, so that it is easier to understand how security could be affected. Section 5 introduces some filtering rules for 6to4 implementations, and section 6 discusses some additional problems which still need some consideration. Appendix A outlines a few possible attack scenarios. 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]. Savola [Expires April 2003] [Page 3] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 2. Different 6to4 Forwarding Scenarios It should be noted that when communicating between 6to4 and native domains, the 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 traffic from with e.g. access lists. 2.1. 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. .--------. _----_ .--------. | 6to4 | _( IPv4 )_ | 6to4 | | Router | <====> ( Internet ) <===> | Router | '--------' (_ _) '--------' ^ '----' ^ | Direct tunneling over IPv4 | V V .--------. .-------. | 6to4 | | 6to4 | | Client | | Client | '--------' '--------' 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. From Native to 6to4 When native domains send traffic to 6to4 address 2002:V4ADDR, it will be routed to the topologically nearest, advertising 6to4 Relay Router. Relay router will tunnel the traffic over IPv4 to the corresponding IPv4 address V4ADDR. (Note that IPv4 address 9.0.0.1 here is just an example of a global IPv4 address.) Savola [Expires April 2003] [Page 4] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 2002::/16 Closest to 'Native Client' .--------. _----_ .------------. .--------. | Native | _( IPv6 )_ | 6to4 Relay | Tunneled | 6to4 | | Client | -> ( Internet ) --> | Router | =========> | Router | '--------' (_ _) '------------' 9.0.0.1 '--------' '----' dst=2002:0900:0000::1 | V .-------. | 6to4 | | Client | '--------' 2.3. From 6to4 to Native 6to4 domains send traffic to native domains by tunneling it over IPv4 to their configured 6to4 Relay Router, or the closest 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/found by IPv4 Anycast .--------. _----_ .------------. .--------. | Native | _( IPv6 )_ | 6to4 Relay | Tunneled | 6to4 | | Client | <- ( Internet ) <-- | Router | <========= | Router | '--------' (_ _) '------------' 192.88.99.1'--------' '----' (or configured) ^ dst=3ffe:ffff::1 | .-------. | 6to4 | | Client | '--------' 3. Some Functionalities of 6to4 We list some, relatively obvious features of different 6to4 components to better undestand what's the required behaviour. 3.1. Functions of Different 6to4 Network Components o Non-6to4 (Native) Node If native IPv6 nodes want to communicate with 6to4 nodes, they send the traffic along normally. The traffic will reach the topologically closest, advertising 6to4 Relay Router, and will be tunneled to the destination 6to4 Router, which will pass it to the 6to4 node via normal forwarding process. Savola [Expires April 2003] [Page 5] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 o 6to4 Host A host, usually autoconfigured and has an address from a 6to4 prefix, but doesn't have a 6to4 pseudo-interface. It doesn't need to know anything about 6to4, and it acts like a normal IPv6 Host in every manner. Note that 6to4 Hosts can also be 6to4 Routers in some scenarios, but then 6to4 Router functionalities, below, apply. o 6to4 Router Acts at the border of a 6to4 domain. It does not have a native, global IPv6 address. More specifically: - provide "native-like" IPv6 connectivity to local clients and routers - if packets are sent to foreign 6to4 addresses, tunnel them to the destination 6to4 router using IPv4 - if packets are sent to locally configured 6to4 addresses, forward them normally - if packets are sent to non-6to4 addresses, tunnel them to the configured/closest-by-anycast 6to4 Relay Router, which will pass them on - if packets are received from 6to4 addresses, decapsulate the IPv4 packets received from 6to4 routers - if packets are received from non-6to4 addresses, decapsulate the IPv4 packets received from 6to4 Relay Router closest to the source (note: it is not easily distinguishable that the packet was really received from a Relay router, not from a spoofing third party.) o 6to4 Relay Router Acts as a relay between all 6to4 domains and native IPv6; more specifically: - advertises the reachability of the 2002::/16 prefix to native IPv6 routing, thus receiving traffic to all 6to4 addresses from closest native IPv6 nodes - (if implements RFC3068) advertise the reachability of IPv4 '6to4 Relay anycast prefix' (192.88.99.0/24) to IPv4 routing, thus receiving some tunneled traffic to native IPv6 nodes from 6to4 Routers - if packets are received from 6to4 addresses through tunneling, decapsulate them and forwards them on using normal IPv6 routing Savola [Expires April 2003] [Page 6] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 - if packets are received through normal IPv6 routing from native addresses, and are destined for 2002::/16, tunnel them to the corresponding 6to4 Router 3.2. Non-functions of Different 6to4 Network Components What should not happen; this forms a basis for the security checks. The lists are not exhaustive. o 6to4 Router or Relay - use private, broadcast or reserved IPv4 addresses in tunnels, or the matching 6to4 prefixes - receive traffic from 6to4 Routers where the IPv4 tunnel source address does not match the 6to4 prefix - receive 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 6to4 Router - send traffic to other 6to4 domains through 6to4 Relay Router or via some third party 6to4 Router - receive traffic from other 6to4 domains via a 6to4 Relay Router - receive traffic to other than to your own 6to4 prefix(es) o 6to4 Relay Router - receive traffic from 6to4 to 6to4 4. Special Processing of 6to4 Packets One could summarize the special processing of 6to4 as follows: o Relay Router 1. incoming from native, tunneled to 6to4 2. tunneled from 6to4, going to native o Router 1. tunneled from relay, source is native 2. tunneled to relay, destination is native 3. tunneled directly, destination is 6to4 4.1. Encapsulating IPv6 Packets into IPv4 IPv6 packets are encapsulated into IPv4 in three scenarios: 1. 6to4 Router sends packets to other 6to4 Routers (2002::/16 destination) Savola [Expires April 2003] [Page 7] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 2. 6to4 Router sends packets to its configured/nearest-by-anycast 6to4 Relay Router (non-2002::/16 destination) 3. 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 from 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. Solutions 5.1. Generic Approach 5.1.1. Encapsulating IPv6 into IPv4 src and dst SHOULD pass ipv6-sanity checks, else drop (defined below) if src=2002 src MUST match src_v4 [ the scenario: 4.1. case 1. or 2. ] if dst=2002 dst_v4 SHOULD NOT be assigned to the router (avoid misconfigurations) [ the scenario: 4.1. case 1. ] fi elif dst=2002 dst_v4 MAY have to match one of ipv4 equiv. of 6to4 prefixes masked by a user-specified prefix length (restricting who can use the relay) [ the scenario: 4.1. case 3. ] else drop [ the scenario: we somehow got a native-native ipv6 packet ] fi accept 5.1.2. Decapsulating IPv4 into IPv6 src_v4 and dst_v4 SHOULD pass ipv4-sanity checks, else drop (defined below) src and dst SHOULD pass ipv6-sanity checks, else drop (defined below) if dst=2002 dst MUST match dst_v4 src_v4 may be restricted to be 6to4_ipv4_anycast [not useful for a long time yet] [ the scenario: 4.2. case 1. or 2. ] Savola [Expires April 2003] [Page 8] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 if src=2002 src MUST match src_v4 dst_v4 SHOULD be assigned to the router (see notes below) [ the scenario: 4.2. case 1. ] fi elif src=2002 src MUST match src_v4 dst_v4 SHOULD be assigned to the router (see notes below) src_v4 MAY have to match one of ipv4 equiv. of 6to4 prefixes masked by a user-specified prefix length (restricting who can use the relay) [ the scenario: 4.2. case 3. ] else drop [ the scenario: we somehow got a native-native ipv6 packet ] fi accept 5.1.3. IPv4 and IPv6 Sanity Checks 5.1.3.1. IPv4 IPv4 address MUST be a global unicast address, as required by the 6to4 specification. The disallowed addresses include those defined in [RFC1812], 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 224.0.0.0/4 (multicast) o 255.0.0.0/8 (broadcast) In addition it it SHOULD be checked that the address is not any of the system's broadcast addresses. This is especially important if the implementation is made so that it can receive and process encapsulated IPv4 packets arriving at its broadcast addresses, or try to send encapsulated IPv4 packets to one of its broadcast addresses. 5.1.3.2. IPv6 IPv6 address MUST not be: o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...) Savola [Expires April 2003] [Page 9] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 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 V4ADDR is any of the above IPv4 addresses, will not be passed. 5.1.3.3. Optional Ingress Filtering In addition, the implementation may perform some form of ingress filtering (e.g. Unicast Reverse Path Forwarding checks). For example, if the 6to4 Router has multiple interfaces, of which some are "internal", receiving either IPv4 or IPv6 packets with source address belonging to any of these internal networks from the Internet might be disallowed. If these checks are implemented, it is RECOMMENDED that they default to disabled. 5.1.3.4. Notes About the Checks The rule 'dst_v4 SHOULD be assigned to the router' is not needed if the implementation is made in such a way that it only accepts and processes encapsulated IPv4 packets arriving on unicast IPv4 addresses, and that if destination address is known to be a local broadcast address, not try to encapsulate and send packets to it. Some checks, especially the IPv4/IPv6 Sanity Checks, could be at least partially implementable with system-level access lists, if one would like to avoid placing too many restrictions in the 6to4 implementation itself. This depends on how many hooks for ACL's are in place. In practice it seems like this could not be done effectively enough unless the access list mechanism is able to parse the encapsulated packets within IP-IP. 5.2. Simplified Approach This makes some assumptions about the implementation as pointed above to simplify the above rules. 5.2.1. Encapsulating IPv6 into IPv4 src and dst SHOULD pass ipv6-sanity checks, else drop if src=2002 src MUST match src_v4 elif dst=2002 Savola [Expires April 2003] [Page 10] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 (accept) else drop fi accept 5.2.2. Decapsulating IPv4 into IPv6 src_v4 and dst_v4 SHOULD pass ipv4-sanity checks, else drop src and dst SHOULD pass ipv6-sanity checks, else drop if dst=2002 dst MUST match dst_v4 if src=2002 src MUST match src_v4 fi elif src=2002 src MUST match src_v4 else drop fi accept 5.3. All Relays Must Be Anycast In this model, all Relay Routers must always use 6to4 IPv4 Anycast address as the source address. In order for this to be implementable, every single 6to4 Relay Router must use only anycast. This may be too significant a deployment restriction. Also, in certain circumstances if Unicast RPF is used, the use of IPv4 anycast as a source address globally will fail the checks and result in dropped packets. The checks would be: if src_v4 is 6to4 ipv4 anycast address accept [coming from relay] elif src_v4 is non-global ipv4 unicast address drop elif src = 2002 src MUST match src_v4 [coming from other 6to4 routers] accept else drop fi Savola [Expires April 2003] [Page 11] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 6. Problems 6.1. 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_v4 = 10.0.0.1 dst_v4 = 20.20.20.20 src = 3ffe:ffff::1 dst = 2002:1010:1010::2 what can it do? How should it decide which transitionary mechanism this belongs to; there is no "transitionary 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, and based on src/dst pairs of both IPv4 and IPv6 addresses it can be deduced which logical tunnel interface is in the question. Solutions for this include not using more than one automatic tunneling mechanisms in the same system or binding different mechanisms to different IPv4 addresses. 6.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 Savola [Expires April 2003] [Page 12] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 be critical. However, it is difficult to predict how long the intermediate period will be. 6.3. Anyone Pretending to Be a Relay Router 6to4 Routers receive traffic from non-6to4 ("native") sources via 6to4 Relays. 6to4 Routers have no way of matching IPv4 source address of the relay with non-6to4 IPv6 address of the source. In consequence, anyone can spoof any non-6to4 IPv6 address he wants by sending traffic, encapsulated, directly to 6to4 Routers. 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-address of IP packets. Unfortunately, this problem is very difficult to solve properly. There have been two rough ideas: o Every 6to4 Relay MUST configure and use "192.88.99.1" as the source address of packets that are encapsulated towards 6to4 Routers. o Every 6to4 Relay MUST participate in an eBGP multi-hop peering mesh (which can be hierarchical): there more specific routes will be advertised. It should be noted that if IPv6 operators do not implement ingress filtering for IPv6, so that spoofing IPv6 is not more difficult than spoofing IPv4, these problems have only little impact on the overall security of 6to4 nodes. These two are analyzed in order. 6.3.1. 6to4 Relay Routers Must Use 192.88.99.1 This is a natural extension of [6TO4ANY], but it should be noted that the routers do not necessarily have to _advertise_ 192.88.99.1 or provide service using that address, just source packets from it. (If not advertised, the problems with unicast RPF-like mechanisms become even more difficult.) 6to4 Routers would verify, as pointed above, that encapsulated traffic coming from non-6to4 sources has "192.88.99.1" as source IPv4 address. Savola [Expires April 2003] [Page 13] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 This has the advantage that the attacker must be able to spoof to use the source address "192.88.99.1" to be able to inject spoofed IPv6 traffic. This seems like a considerable advantage to the current status, but one still cannot protect from those who can spoof "192.88.99.1", of course. The disadvantage is that it becomes difficult to tell relays apart: debugging will be very difficult as everyone is using the same address. Another, much smaller, disadvantage is that sites employing unicast RPF-checks may lose some packets under certain circumstances (to be elaborated if this is considered significant). If that would help any, the Relays could also pick any valid address from 192.88.99.0/24 -- there would be space to (somehow) distinguish 254 Relay routers. 6.3.2. Limited Distribution of More Specific Routes If 6to4 prefixes more specific than 2002::/16 could be advertised, the traffic model between native<->6to4 and 6to4<-> could be changed so that only one Relay would always be used, most often the one closest to the 6to4 Router. This approach was rejected due, as IPv6 routing table was not to be polluted by 6to4 prefixes derived of IPv4 prefixes. However, the problem can be avoided with some effort: creating a separate, possibly hierarchical based on IPv6 connections, peering mesh for 6to4 Relay routers. This could be done by forming eBGP [BGP] multi-hop peerings between Relays, and advertising more specific routes (e.g. the same superblocks of IPv4 addresses one expects to service) to all the other Routers. In that way, the global routing table would not be impacted at all. This seems to have at least three potential issues: o Every Relay should be part of this (if one wants to have some extra safety that the addresses haven't been spoofed) o The route from a native source takes the path to the first Relay, and there (possibly through other Relays) to the last Relay to tunnel the packet to the 6to4 Router; this adds at least some latency Savola [Expires April 2003] [Page 14] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 o The mechanism of redistributing IPv4 6to4 client addresses to other relays as 6to4 prefixes need work Of these, only the last requires more discussion. It could be argued that this advertising should either be manually configured once (ie. relatively static prefixes, or generated from IPv4 route-objects in RADB etc.) or generated automatically (e.g. when a 6to4 Router first sends a "triggering" packet through the Relay). Further analysis on this is TBD if necessary. 7. Security Considerations This draft discusses security considerations. If proper checks are not implemented, there are significant security threats ranging from DoS proxy attacks to spoofing and attacks against 6to4 pseudo-interface. Remainder threats, if "maximal" security is implemented (e.g. all MUSTs and SHOULDs in 5.2.1 and 5.2.2): o one cannot verify that the supposed relay is authorized to originate the traffic from native sources o relays can be used for remote reflection (packets sent to 2002:[target ipv4]) o relays can be used without authorization (theft of service); BGP advertisement restrictions aren't enough, e.g. routing headers can be used to work around these. The first could be partially remedied by keeping a list of trusted relays but that is not a really scalable or completely secure solution. The latter two of these can be worked around (but only in a very closed environment) by IPv6 packet filter access-lists. Remainder threats, when only the most important checks have been implemented (e.g. only MUSTs in 5.2.1 and 5.2.2): o relays used for local amplified reflection (packets sent to 2002:[addr], where addr is a (subnet) broadcast or multicast address. o relays' 6to4 pseudo-interface is subject to some remote local netaccess threats [NETACCESS] (e.g. with destination being link- local). This assumes that when encapsulating (or in some cases, decapsulating), the destination is not checked completely. As can be seen, there are mainly three classes of potential problem sources: Savola [Expires April 2003] [Page 15] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 o 6to4 routers not being able to identify whether relays are legitimate o wrong or impartially implemented 6to4 Routers o relays performing packet laundering The first can be fixed by ensuring the correctness of implementations; this is important. The second is the toughest problem, still under research. Thr third is also a difficult, but a fairly restricted problem as relays are limited in number. 8. Acknowledgements Alexey Kuznetsov brought up the implementation problem with IPv6 martian checks. Christian Huitema formulated the rules that rely on Relays using only anycast. Keith Moore brought up the point about reduced flexibility. Brian Carpenter, Tony Hain and Vladislav Yasevich for lengthy discussions. Alain Durand reminded of relay spoofing problems. 9. References 9.1. Normative References [6TO4] Carpenter, B. and Moore K., "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. 9.2. Informative References [IPIP] Simpson, W. "IP in IP Tunneling", RFC 1853, October 1995. [ISATAP] Templin, F. et al "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap-05.txt (work in progress). [MECH] Gilligan, R., and Nordmark, E. "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. Savola [Expires April 2003] [Page 16] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 [NETACCESS] Kempf, J., Nordmark, E., "Threat Analysis for IPv6 Public Multi-Access Links", draft-kempf-ipng-netaccess-02.txt (work in progress). [BGP] Rekhter, Y., Li, T., "A Border Gateway Protocol 4", RFC1771, March 1995. Author's Address Pekka Savola CSC/FUNET Espoo, Finland EMail: psavola@funet.fi A. Some Attack Scenarios Outlined If the security checks haven't been properly implemented, at least the following are possible. The following addresses are used in these examples. IPv4 addresses are indeed just examples of global IPv4 addresses. __________________ __________________ | Native IPv6 N1 | | Native IPv6 N2 | | 3ffe:ffff:1::/48 | | 3ffe:ffff:2::/48 | '------------------' '------------------' _______________________ _______________________ | 6to4 Relay Router RR1 | | 6to4 Relay Router RR2 | | 3ffe:ffff:10::1/48 | | 3ffe:ffff:11:1::1/48 | | 2002:0900:0001::1/48 | | 2002:0900:0002::1/48 | | (IPv4) 9.0.0.1 | | (IPv4) 9.0.0.2 | '-----------------------' '-----------------------' ______________________ ______________________ | 6to4 Router RA | | 6to4 Router RB | | 2002:0800:0001::1/48 | | 2002:0800:0002::1/48 | | (IPv4) 8.0.0.1 | | (IPv4) 8.0.0.2 | '----------------------' '----------------------' When two 6to4 Routers send traffic to each others' domains, packet sent by RA to RB is like: src = 2002:0800:0001::aaaa dst = 2002:0800:0002::bbbb src_v4 = 8.0.0.1 (added when encapsulated to IPv4) dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) Savola [Expires April 2003] [Page 17] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 When the packet is received by IPv4 stack on RB, it will be decapsulated so that only src and dst remain, as originally sent by RA: src = 2002:0800:0001::aaaa dst = 2002:0800:0002::bbbb As every other node is just "one hop away" and the "link-layer" addresses are lost, this may open a lot of possibilities for misuse. Some possible approaches are outlined below. A.1. IPv6 Spoofing and Access Control Avoidance 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 = 8.0.0.1 (added when encapsulated to IPv4) dst_v4 = 8.0.0.2 (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 = ::ffff:[some trusted IPv4 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 designed the stack to as to avoid these, but who can say for all ... A.2. IPv4 Local Directed Broadcast Attacks Relays could be targeted with local broadcast attacks: src = 3ffe:ffff:5678::aaaa (forged) dst = 2002:0900:00ff::bbbb Now, if the Relay doesn't check the destination address for broadcast, it would send the encapsulated IP-IP packet to 9.0.0.255 which might be a local broadcast address (packets sent to every IPv4 node in the subnet). Classic directed broadcast checks will not Savola [Expires April 2003] [Page 18] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 prevent this as the packet doesn't come from outside (in IPv4 sense). A.3. DoS Reflector Denial-of-Service attacks could be reflected against either IPv4 nodes (not that useful, only thing that could be sent is IP-IP packets) or IPv6 nodes. 6to4 Relay Router could be abused as follows: src = X dst = Y src_v4 = 8.0.0.1 (added when encapsulated to IPv4) dst_v4 = 9.0.0.2 (added when encapsulated to IPv4) a) X=2002:1234:5678::1 or X=3ffe:1122:3344::1 (forged) Y=2002:0500:0001::1 or Y=::0500:0001 (the victim) Target IPv4 address 5.0.0.1 would be bombed with reflected packets from 6to4 Relay Router RR2. Source address in IPv6 header reveals nothing, or can be used to throw blame on someone else. b) X=2002:1234:5678::1 or X=3ffe:1122:3344::1 (forged) Y=3ffe:aabb:ccdd::1 (the victim) As above, the target could be native IPv6 address too, not necessarily an IPv4 node. Improper 6to4 Router could be abused as follows: src = X dst = Y src_v4 = 8.0.0.1 (added when encapsulated to IPv4) dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) Both issues from above may also apply, if not implemented properly. For example: a) X=2002:1234:5678::1 or X=3ffe:1122:3344::1 (forged) Y=3ffe:aabb:ccdd::1 (the victim) This might allow one to tunnel to the 6to4 Router RB, and place packets, with forged source addresses (be they 6to4 or not) to the router, and if it accepted them to be routed natively (ie. the forwarding process doesn't check that it shouldn't send them out the same way they came), be tunneled to Relay Router, and from there to Internet. Savola [Expires April 2003] [Page 19] Internet Draft draft-savola-v6ops-6to4-security-00.txt October 2002 A.4. Remote Net-access Threats As [NETACCESS] points out, there is a significant number of issues with public multi-access links. The security mechanism is that Hop Limit can be verified to be 255 (the packet has not been forwarded) and link-local addresses are used. However, with 6to4 pseudo-interface, unless there are checks for the destination addresses (a bit problematic especially in 6to4 Relays), these become realized on the decapsulating pseudo-interface. The packet would look like: src_v4 = dst_v4 = ttl_v4 = src = 3ffe:ffff::1 or (in some cases) fe80::2 dst = fe80::1 hop limit = 255 Needless to say, this would bring the security of 6to4 pseudo- interface (or any interface blindly decapsulating packets and not performing strict checks on the content) could become like that of a public multi-access network. Similarly, e.g. '::1' could also be used as a destination address. Savola [Expires April 2003] [Page 20]