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]