Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT Research Lab, IIJ Expires: January 10, 2001 July 10, 2000 Possible abuse against IPv6 transition technologies draft-itojun-ipv6-transition-abuse-01.txt Status of this Memo This document is an Internet-Draft and is in 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 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be January 10, 2001. Abstract The document talks about possible abuse of IPv6 transition technologies, which may lead to denial-of-service (DoS) attacks and other problems. IPv6 transition technologies, namely IPv6 over IPv4 tunnelling specifications and some others, have room for abuse by malicious parties. Detailed descriptions and possible workarounds are supplied. 1. Abuse of IPv4 compatible address 1.1. Problem To implement automatic tunnelling described in RFC1933 [Gilligan, 1996] , IPv4 compatible addresses (like ::123.4.5.6) are used. From IPv6 stack point of view, an IPv4 compatible address is considered to be a normal unicast address. If an IPv6 packet has IPv4 compatible addresses in the header, the packet will be encapsulated automatically into an IPv4 packet, with IPv4 address taken from lowermost 4 bytes of the IPv4 compatible addresses. Since there is no good way to check if embedded Hagino Expires: January 10, 2001 [Page 1] DRAFT Abuse against IPv6 transition technologies July 2000 IPv4 address is sane, improper IPv4 packet can be generated as a result. Malicious party can abuse it, by injecting IPv6 packets to an IPv4/v6 dual stack node with certain IPv6 source address, to cause transmission of unexpected IPv4 packets. Consider the following scenario: o You have an IPv6 transport-capable DNS server, running on top of IPv4/v6 dual stack node. The node is on IPv4 subnet 10.1.1.0/24. o Malicious party transmits an IPv6 UDP packet to port 53 (DNS), with source address ::10.1.1.255. It does not make difference if it is encapsulated into an IPv4 packet, or is transmitted as a native IPv6 packet. o IPv6 transport-capable DNS server will transmit an IPv6 packet as a reply, copying the original source address into the destination address. Note that the IPv6 DNS server will treat IPv6 compatible address as normal IPv6 unicast address. o The reply packet will automatically be encapsulated into IPv4 packet, based on RFC1933 automatic tunnelling. As a result, IPv4 packet toward 10.1.1.255 will be transmitted. This is the subnet broadcast address for your IPv4 subnet, and will (improperly) reach every node on the IPv4 subnet. 1.2. Possible solutions For the following sections, possible soluitions are presented in the order of preference (the author recommends to implement solutions that appear earlier). Note that some of the following are partial solution to the problem. Some of the solutions may overwrap, or be able to coexist, with other solutions. Solutions marked with (*) are already incorporated into [Gilligan, 2000] which is an updated version of RFC1933. Note that, however, solutions incorporated into [Gilligan, 2000] do not make a complete protection against malicious parties. o Disable automatic tunnelling support. o Reject IPv6 packets with IPv4 compatible address in IPv6 header fields. Note that we may need to check extension headers as well. o Perform ingress filter against IPv6 packet and tunnelled IPv6 packet. Ingress filter should let the packets with IPv4 compatible source address through, only if the source address embeds an IPv4 address belongs to the organization. The approach is a partial solution for avoiding possible transmission of malicious packet, from the organization to the outside. (*) o Whenever possible, check if the addresses on the packet meet the topology you have. For example, if the IPv4 address block for your site is 43.0.0.0/8, and you have a packet from IPv4-wise outside with encapsulated IPv6 source matches ::43.0.0.0/104, it is likely that someone is doing something nasty. This may not be possible to make Hagino Expires: January 10, 2001 [Page 2] DRAFT Abuse against IPv6 transition technologies July 2000 the filter complete, so consider it as a partial solution. (*) o Require use of IPv4 IPsec, namely authentication header [Kent, 1998] , for encapsulated packet. Even with IPv4 IPsec, reject the packet if the IPv6 compatible address in the IPv6 header does not embed the IPv4 address in the IPv4 header. We cannot blindly trust the inner IPv6 packet based on the existence of IPv4 IPsec association, since the inner IPv6 packet may be originated by other nodes and forwarded by the authenticated peer. The solution may be impractical, since it only solves very small part of the problem with too many requirements. o Reject inbound/outgoing IPv6 packets, if it has certain IPv4 compatible address in IPv6 header fields. Note that we may need to check extension headers as well. The author recommends to check any IPv4 compatible address that is mapped from/to IPv4 address not suitable as IPv4 peer. They include 0.0.0.0/8, 127.0.0.0/8, 224.0.0.0/4, 255.255.255.255/32, and subnet broadcast addresses. Since the check can never be perfect (we cannot check for subnet broadcast address in remote site, for example) the direction is not recommend. (*) 2. Abuse of 6to4 address 6to4 [Carpenter, 2000] is another proposal for IPv6-over-IPv4 packet encapsulation, and is very similar to RFC1933 automatic tunneling mentioned in the previous section. 6to4 address embeds IPv4 address in the middle (2nd byte to 5th byte). If an IPv6 packet has a 6to4 address as destination address, it will be encapsulated into IPv4 packet with the embedded IPv4 address as IPv4 destination. IPv6 packets with 6to4 address have the same problems as those with IPv4 compatible address. See the previous section for the details of the problems, and possible solutions. The latest 6to4 draft [Carpenter, 2000] do incoporate some of the solutions presented in the previous section, however, they do not make a complete protection against malicious parties. 3. Abuse of IPv4 mapped address 3.1. Problems IPv6 basic socket API [Gilligan, 1999] defines the use of IPv4 mapped address with AF_INET6 sockets. IPv4 mapped address is used to handle inbound IPv4 traffic toward AF_INET6 sockets, and outbound IPv4 traffic from AF_INET6 sockets. Inbound case has higher probability of abuse, while outbound case contributes to the abuse as well. Here we briefly describe the kernel behavior in inbound case. When we have an AF_INET6 socket bound to IPv6 unspecified address (::), IPv4 traffic, as well as IPv6 traffic, will be captured by the socket. The kernel will present Hagino Expires: January 10, 2001 [Page 3] DRAFT Abuse against IPv6 transition technologies July 2000 the address of the IPv4 peer to the userland program by using IPv4 mapped address. For example, if an IPv4 traffic from 10.1.1.1 is captured by an AF_INET6 socket, the userland program will think that the peer is at ::ffff:10.1.1.1. The userland program can manipulate IPv4 mapped address just like it would do against normal IPv6 unicast address. We have three problems with the specification. First, IPv4 mapped address support complicates IPv4 access control mechanisms. For example, if you would like to reject accesses from IPv4 clients to a certain transport layer service, it is not enough to reject accesses to AF_INET socket. You will need to check AF_INET6 socket for accesses from IPv4 clients (seen as accesses from IPv4 mapped address) as well. Secondly, malicious party may be able to use IPv6 packets with IPv4 mapped address, to bypass access control. Consider the following scenario: o Attacker throws unencapsulated IPv6 packets, with ::ffff:127.0.0.1 as source address. o The access control code in the server thinks that this is from localhost, and grants accesses. Lastly, malicious party can make servers generate unexpected IPv4 traffic. This can be accomplished by sending IPv6 packet with IPv4 mapped address as a source (similar to abuse of IPv4 compatible address), or by presenting IPv4 mapped address to servers (like FTP bounce attack [Allman, 1999] from IPv6 to IPv4). The problem is slightly different from the problems with IPv4 compatible addresses and 6to4 addresses, since it does not make use of tunnels. It makes use of certain behavior of userland applications. The confusion came from the dual use of IPv4 mapped address, for node- internal representation for remote IPv4 destination/source, and for real IPv6 destination/source. 3.2. Possible solutions o In IPv6 addressing architecutre document [Hinden, 1998] , disallow the use of IPv4 mapped addresses on the wire. The change will conflict with SIIT [Nordmark, 2000] , which is the only protocol which tries to use IPv4 mapped address on IPv6 native packet. The dual use of IPv4 mapped address (as a host-internal representation of IPv4 destinations, and as a real IPv6 address) is the prime source of the problem. o Reject IPv6 packets, if it has IPv4 mapped address in IPv6 header fields. Note that we may need to check extension headers such as routing headers, as well. IPv4 mapped address is internal representation in a node, so doing this will raise no conflicts with existing protocols. We recommend to check the condition in IPv6 input Hagino Expires: January 10, 2001 [Page 4] DRAFT Abuse against IPv6 transition technologies July 2000 packet processing, and transport layer processing (TCP input and UDP input) to be sure. o Reject DNS replies, or other host name database replies, which contain IPv4 mapped address. Again, IPv4 mapped address is internal represntation in a node and should never appear on external host name databases. o Do not route inbound IPv4 traffic to AF_INET6 sockets. When an application would like to accept IPv4 traffic, it should explicitly open AF_INET sockets. You may want to run two applications instead, one for an AF_INET socket, and another for an AF_INET6 socket. Or you may want to make the functionality optional, off by default, and let the userland applications explicitly enable it. This greatly simplifies access control issues. This approach conflicts with what IPv6 basic API document says, however, it should raise no problem with properly-written IPv6 applications. It only affects server programs, ported by assuming the behavior of AF_INET6 listening socket against IPv4 traffic. o When implementing TCP or UDP stack, explicitly record the wire packet format (IPv4 or IPv6) into connection table. It is unwise to guess the wire packet format, by existence of IPv6 mapped address in the address pair. o We should separately fix problems like FTP bounce attack. o Applications should always check if the connection to AF_INET6 socket is from an IPv4 node (IPv4 mapped address), or IPv6 node. It should then treat the connection as from IPv4 node (not from IPv6 node with special adderss), or reject the connection. This is, however, dangerous to assume that every application implementers are aware of the issue. The solution is not recommended (this is not a solution actually). 4. Attacks by combining different address formats Malicious party can use different address formats simultaneously, in a single packet. For example, suppose you have implemented checks for abuse against IPv4 compatible address in automatic tunnel egress module. Bad guys may try to send a native IPv6 packet with 6to4 destination address with IPv4 compatible source address, to bypass security checks against IPv4 compatible address in tunnel decapsulation module. Your implementation will not be able to detect it, since the packet will not visit egress module for automatic tunnels. Analyze code path with great care, and reject any packets that does not look sane. Hagino Expires: January 10, 2001 [Page 5] DRAFT Abuse against IPv6 transition technologies July 2000 5. Attacks using source address-based authentication 5.1. Problems IPv6-to-IPv4 translators [Nordmark, 2000; Tsirtsis, 2000; Hagino, 2000] usually relay, or rewrite, IPv6 packet into IPv4 packet. The IPv4 source address in the IPv4 packet will not represent the ultimate source node (IPv6 node). Usually the IPv4 source address represents translator box instead. If we use the IPv4 source address for authentication at the destination IPv4 node, all traffic relayed/translated by the translator box will mistakenly be considered as authentic. The problem applies to IPv4-to-IPv6 translators as well. The problem is similar to proxied services, like HTTP proxy. 5.2. Possible solutions o Do not use translators, for protocols that use IP source address as authentication credental (for example, rlogin [Kantor, 1991] ). o translators must implement some sort of access control, to reject any IPv6 traffic from malicious IPv6 nodes. o Do not use source address based authentication. IP source address should not be used as an authentication credental from the first place, since it is very easy for malicious parties to spoof IP source address. 6. Conclusions IPv6 transition technologies have been proposed, however, some of them looks immune against abuse. The document presented possible ways of abuse, and possible solutions against them. The presented solutions should be reflected to the revision of specifications referenced. For coming protocols, the author would like to propose a set of guilelines for IPv6 transition technologies: o Tunnels must explicitly be configured. Manual configuration, or automatic configuration with proper authentication, should be okay. o Do not embed IPv4 addresses into IPv6 addresses, for tunnels or other cases. It leaves room for abuse, since we cannot practically check if embedded IPv4 address is sane. o Do not define an IPv6 address format that does not appear on the wire. It complicates access control issues. The author hopes to see more deployment of native IPv6 networks, where tunnelling technologies become unnecessary. Hagino Expires: January 10, 2001 [Page 6] DRAFT Abuse against IPv6 transition technologies July 2000 7. Security considerations The document talks about security issues in existing IPv6 related protocol specifications. Possible solutions are provided. References Gilligan, 1996. R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers" in RFC1933 (April 1996). ftp://ftp.isi.edu/in- notes/rfc1933.txt. Gilligan, 2000. R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers" in draft-ietf-ngtrans-mech-06.txt (April 2000). work in progress. Kent, 1998. S. Kent and R. Atkinson, "IP Authentication Header" in RFC2402 (November 1998). ftp://ftp.isi.edu/in-notes/rfc2402.txt. Carpenter, 2000. Brian Carpenter and Keith Moore, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels" in draft-ietf-ngtrans-6to4-06.txt (June 2000). work in progress. Gilligan, 1999. R. Gilligan, S. Thomson, J. Bound, and W. Stevens, "Basic Socket Interface Extensions for IPv6" in RFC2553 (March 1999). ftp://ftp.isi.edu/in-notes/rfc2553.txt. Allman, 1999. M. Allman and S. Ostermann, "FTP Security Considerations" in RFC2577 (May 1999). ftp://ftp.isi.edu/in-notes/rfc2577.txt. Hinden, 1998. R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. Nordmark, 2000. E. Nordmark, "Stateless IP/ICMP Translator (SIIT)" in RFC2765 (February, 2000). ftp://ftp.isi.edu/in-notes/rfc2765.txt. Tsirtsis, 2000. G. Tsirtsis and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)" in RFC2766 (February 2000). ftp://ftp.isi.edu/in- notes/rfc2766.txt. Hagino, 2000. Jun-ichiro Hagino and Kazu Yamamoto, "An IPv6-to-IPv4 transport relay translator" in draft-ietf-ngtrans-tcpudp-relay-01.txt (May 2000). work Hagino Expires: January 10, 2001 [Page 7] DRAFT Abuse against IPv6 transition technologies July 2000 in progress material. Kantor, 1991. B. Kantor, "BSD Rlogin" in RFC1282 (December 1991). ftp://ftp.isi.edu/in-notes/rfc1282.txt. Author's address Jun-ichiro itojun Hagino Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku,Tokyo 101-0054, JAPAN Tel: +81-3-5259-6350 Fax: +81-3-5259-6351 email: itojun@iijlab.net Hagino Expires: January 10, 2001 [Page 8]