Internet Engineering Task Force Craig Metz INTERNET-DRAFT Extreme Networks Expires: Apr 27, 2003 Jun-ichiro itojun Hagino Research Lab, IIJ Oct 27, 2002 IPv4-Mapped Addresses on the Wire Considered Harmful draft-itojun-v6ops-v4mapped-harmful-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.'' To view the list Internet-Draft Shadow Directories, see 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 Apr 27, 2003. Abstract The IPv6 Addressing Architecture [Hinden, 1998] defines the "IPv4-mapped IPv6 address." These addresses are used in the IPv6 basic API [Gilligan, 1999] to denote IPv4 addresses using AF_INET6 sockets. These addresses are used in protocol proposals such as SIIT [Nordmark, 2000] to denote IPv6 communication using AF_INET6 sockets. Therefore, IPv4-mapped addresses have two different meanings, and they are not distinguishable from the user-land applications. This draft discusses security threats due to this ambiguity of IPv4-mapped address. It also discusses threats due to the additional complexities introduced by IPv4-mapped addresses. Finally, it proposes to resolve these problems by forbidding protocols from using IPv4-mapped addresses for IPv6 communications. Metz and Hagino Expires: Apr 27, 2003 [Page 1] DRAFT IPv4-mapped Addr. on Wire Considered Harmful Oct 2002 1. Dual meaning of IPv4-mapped address Basic Socket Interface Extensions for IPv6 [Gilligan, 1999] defines the use of IPv4-mapped address with AF_INET6 sockets. IPv4-mapped addresses are used to represent IPv4 addresses using the IPv6 API (e.g., on AF_INET6 sockets). The API is designed with IPv4/v6 dual stack nodes in mind. When an IPv4 packet reaches an IPv4/v6 dual stack node, the node's IPv4 layer will process it, then pass it to the transport layer. When the transport layer finds an AF_INET6 listening socket, it will pass the packet to the listening socket as if it was from the corresponding IPv4-mapped address. In this document, we will refer to this as the "basic API behavior." Some of the IPv6 translation protocols, such as SIIT [Nordmark, 2000] , use IPv4-mapped addresses actual IPv6 packets on the wire. These protocols are designed for use with IPv6-only nodes. When an IPv6 packet containing these addresses reaches a node, the node's IPv6 layer will process it, then pass it to the transport layer. When the transport layer finds an AF_INET6 listening socket, it will pass the packet to the listening socket with the IPv4-mapped address intact. In this document, we will refer to this as the "SIIT behavior." 2. Threats due to the use of IPv4-mapped address on wire When an application using the AF_INET6 API receives an IPv4-mapped addresses (for example, returned by getpeername(2) or recvfrom(2)), it cannot detect if the packet received by the node actually used IPv4 (basic API behavior) or IPv6 (SIIT behavior). This ambiguity creates an opportunity that a malicious party can exploit in order to deceive victim nodes. For example: o If an attacker transmits an IPv6 packet with ::ffff:127.0.0.1 in the IPv6 source address field, he might be able to bypass a node's access controls by deceiving applications into believing that the packet is from the node itself (e.g., the IPv4 loopback address, 127.0.0.1). The same attack might be performed using the node's IPv4 interface address instead. o If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 destination address field corresponding to IPv4 addresses inside a site's security perimeter (e.g., ::ffff:10.1.1.1), he might be able to bypass IPv4 packet filtering rules and traverse a site's firewall. o If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 source and destination fields to a protocol that swaps IPv6 source and destination addresses, he might be able to use a node as a proxy for certain types of attacks. For example, this might be used to construct broadcast multiplication and proxy TCP port scan attacks. Metz and Hagino Expires: Apr 27, 2003 [Page 2] DRAFT IPv4-mapped Addr. on Wire Considered Harmful Oct 2002 3. Recommended solution Forbid the use of IPv4-mapped address on wire. The IPv6 node requirements: o IPv6 nodes MUST NOT generate packets that contain IPv4-mapped addresses in any network layer field. Specifically, the IPv6 header, routing header, options headers, and any other chained headers MUST NOT contain IPv4-mapped addresses. o IPv6 nodes SHOULD NOT generate packets that contain IPv4-mapped addresses in any field. (As a particular exception, it MAY be acceptable for fields referring to third-party nodes to contain IPv4-mapped addresses. Implementors must ensure that, where this is allowed, it is done with great care.) o IPv6 nodes MUST silently discard packets that contain IPv4-mapped address in IPv6 header fields, or IPv6 extension header fields. The IPv6 router requirements: o IPv6 routers MUST NOT forward packets that contain IPv4-mapped addresses in any field the router processes. Specifically, the IPv6 header, routing header, and the hop-by-hop options headers parsed by the router MUST NOT contain IPv4-mapped addresses. o IPv6 routers MUST NOT advertise any prefixes into a routing protocol that are within the IPv4-mapped address space. Further, IPv6 routers MUST appropriately discard and/or ignore any received prefixes within the IPv4-mapped address space. Standards requirements: o The IPv6 address architecture document [Hinden, 1998] MUST explicitly state that IPv4-mapped addresses are exclusively for uses local to a node as specified in the basic API [Gilligan, 1999] and MUST never appear in the wire. o Any document that suggests the use of IPv4-mapped addresses in packets on the wire SHOULD be modified to remove such usage. This will remove the threat due to the use of IPv4-mapped address on wire. An alternate solution is to deprecate IPv4-mapped addresses from the basic API. Due to the wide deployment of applications that use IPv6 basic API, further study of this option's feasibility is required. This solution is not mutually exclusive with the recommended solution. Metz and Hagino Expires: Apr 27, 2003 [Page 3] DRAFT IPv4-mapped Addr. on Wire Considered Harmful Oct 2002 4. Suggested implementation tips 4.1. System (e.g., kernel and library) developers o Drop any IPv6 native packet with IPv4-mapped addresses in any of IPv6 header fields as well as IPv6 extension header fields. (N.B., this will make the system incompatible with the current version of SIIT [Nordmark, 2000] ) o Drop any IPv6 DNS response that contains IPv4-mapped addresses. 5. Security considerations This document discusses security issues with the use of IPv4-mapped address. A recommended and alternate solution is provided. 6. Change History 00 -> 01 Craig Metz joins the team. Updates based on feedback given at v6ops interim meeting fall 2002. Move API issues to a separate draft. References Hinden, 1998. R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. 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. Nordmark, 2000. E. Nordmark, "Stateless IP/ICMP Translator (SIIT)" in RFC2765 (February, 2000). ftp://ftp.isi.edu/in-notes/rfc2765.txt. Author's addresses Metz and Hagino Expires: Apr 27, 2003 [Page 4] DRAFT IPv4-mapped Addr. on Wire Considered Harmful Oct 2002 Craig Metz Extreme Networks 220 Spring Street, Suite 100 Herndon, VA 20170-5209, USA Tel: +1 703 885 6721 email: cmetz@inner.net 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 Metz and Hagino Expires: Apr 27, 2003 [Page 5]