i have submitted the following draft to IETF.
i'd suggest vendors who ship IPv4/v6 dual stack nodes/routers,
to check if you have made a secure choice. I believe OpenBSD and
NetBSD are secure enough (OpenBSD is more secure than NetBSD).
itojun
---
Internet Engineering Task Force Jun-ichiro itojun Hagino
INTERNET-DRAFT Research Lab, IIJ
Expires: Feb 22, 2003 Aug 22, 2002
IPv4 mapped address considered harmful
draft-itojun-v6ops-v4mapped-harmful-00.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 Feb 22, 2003.
Abstract
IPv6 address architecture [Hinden, 1998] defines IPv4 mapped address.
The representation is used in IPv6 basic API [Gilligan, 1999] to denote
IPv4 destinations on AF_INET6 socket within the API. At the same time,
there are protocol proposals that use IPv4 mapped address on wire.
Therefore, IPv4 mapped address has two meanings, and they are not
distinguishable from the userland applications. This draft discusses
security threats due to the dual use of IPv4 mapped address. It also
discusses threats due to the additional complexities introduced by IPv4
mapped address.
1. Dual meaning of IPv4 mapped address
IPv6 basic socket API [Gilligan, 1999] defines the use of IPv4 mapped
address with AF_INET6 sockets. IPv4 mapped address is used as an
internal identifier for IPv4 peers, 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, kernel IPv4 layer will handle it,
Hagino Expires: Feb 22, 2003 [Page 1]
DRAFT IPv4 mapped address considered harmful Aug 2002
then passes it up to TCP/UDP layer. When TCP/UDP 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. Let us
call it "basic API behavior" in this draft.
Some of the translator technologies such as SIIT [Nordmark, 2000] uses
IPv4 mapped address in header fields of actual IPv6 packet on wire.
These technologies are designed with IPv6 only nodes in mind. It is
assumed that IPv6 packets with IPv4 mapped address will be handled by
IPv6 layer then by TCP/UDP layer, and reaches an AF_INET6 socket. Let
us call it "SIIT behavior" in this draft.
2. Threats due to the use of IPv4 mapped address on wire
When userland application on top of AF_INET6 API sees peers with IPv4
mapped addresses (like by getpeername(2) or recvfrom(2)), it cannot
detect if the packet actually was IPv4 (IPv4 mapped address appeared due
to basic API behavior) or IPv6 (SIIT behavior).
This ambiguity creates chances to malicious party to trick victim nodes.
Here are a couple of examples:
o By transmitting IPv6 packet with ::ffff:127.0.0.1 in IPv6 source
address field, applications that assume basic API behavior will be
tricked to believe that the packet is from the node itself (IPv4
loopback address, 127.0.0.1).
o By transmitting IPv6 packet to firewall device, with IPv4 mapped
address corresponds to address inside the firewall (like
::ffff:10.1.1.1) as the IPv6 source address, malicious party could
bypass IPv4 filtering rules and inject traffic inside the firewall.
o Assume that the victim node is an IPv4/v6 dual stack node. By
transmitting IPv6 packet with IPv4 mapped address corresponds to IPv4
broadcast address (::ffff:10.255.255.255) in IPv6 source address
field, to TCP/UDP port that swaps IPv6 source and destination address
(e.g. UDP port 53, DNS), malicious node can trick the victim node to
generate improper IPv4 broadcast traffic; This is because basic API on
the victim node will emit transmission requests to destination IPv4
mapped address, ::ffff:10.255.255.255, into IPv4 traffic.
3. Other threats related to IPv4 mapped address
3.1. Access control complexity
RFC2553 section 3.7 adds complexity to access controls. Due to the
additional complexity, it is likely that there will be many mistakes in
access controls.
Hagino Expires: Feb 22, 2003 [Page 2]
DRAFT IPv4 mapped address considered harmful Aug 2002
Due to RFC2553 section 3.7, AF_INET6 socket will accept IPv4 packets.
On an IPv4/v6 dual stack node, if there is no AF_INET listening socket,
normal administrators would believe that there will be no access from
IPv4 peers. However, if AF_INET6 listening socket is present, IPv4
peers will be able to access the service.
To protect applications from this threat, every access control logic has
to have a special case handling for IPv4 mapped address. It is
impossible to enforce such a requirement to every application
implementations.
4. Suggested protocol change
o In IPv4 address architecture document [Hinden, 1998] explicitly state
that IPv4 mapped address is for use within basic API [Gilligan, 1999]
, and basic API only. Forbid any other uses.
o Move any document that suggests the use of IPv4 mapped address on wire
to historic, due to security reasons.
The above change will remove the threat due to the use of IPv4 mapped
address on wire.
Another way is to deprecate RFC2553 section 3.7, however, due to the
wide deployment of applications that use IPv6 basic API, the option is
not feasible.
5. Suggested implementation tips
5.1. Kernel/library developers
o Do not support IPv4 mapped address on AF_INET6 API (RFC2553 section
3.7). By doing so the kernel TCP/UDP code will be greatly simplified,
and will reduce the likelihood of security-sensitive kernel bugs.
o Implement 2553bis [Gilligan, 2002] IPV6_V6ONLY socket option, and make
the default value to on (the default value suggested by the document
is "off"). This has almost the same effect as the previous bullet.
With the approach you still have to implement complex in-kernel
interaction between AF_INET and AF_INET6 socket, which can lead to
security-senstive kernel bugs. Also, once a userland application
turns the socket option off, your system will become vulnerable. The
change will make your stack incompatible with 2553bis section 3.7 and
5.3.
o Drop any IPv6 native packet with IPv4 mapped address in any of IPv6
header fields as well as IPv6 extension header fields. It will make
the system incompatible with SIIT.
Hagino Expires: Feb 22, 2003 [Page 3]
DRAFT IPv4 mapped address considered harmful Aug 2002
o Drop any IPv6 DNS response that contains IPv4 mapped address.
5.2. Application developers
o In EVERY userland application check the IPv6 source address, if it
embeds bad IPv4 address. This approach is impossible in reality, as
it's hard to know what is "bad" address, and there are millions of
coders in different places. There is no way to enforce this rule.
o Do not try to utilize RFC2553 section 3.7 (IPv4 traffic on AF_INET6
socket). Implement server applications by using AF_INET and AF_INET6
listening socket. Explicitly set IPV6_V6ONLY socket option to on,
whenever the socket option is available on the system.
NOTE: Due to the lack of standard behavior in bind(2) semantics,
this may not be possible on some systems. Some IPv6 stack does not
permit bind(2) to 0.0.0.0, after bind(2) to ::. Also, there is no
standard on how IPv4 traffic will be routed when both 0.0.0.0 and
:: listening sockets are available on the same port.
6. Security considerations
The document talks about security issues in the use of IPv4 mapped
address. Possible solutions are provided.
7. Change History
none yet.
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.
Gilligan, 2002.
R. Gilligan, S. Thomson, J. Bound, J. McCann, and W. R. Stevens, "Basic
Socket Interface Extensions for IPv6" in draft-ietf-ipngwg-
rfc2553bis-06.txt (July 2002). work in progress material.
Hagino Expires: Feb 22, 2003 [Page 4]
DRAFT IPv4 mapped address considered harmful Aug 2002
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: itojunat_private
Hagino Expires: Feb 22, 2003 [Page 5]
This archive was generated by hypermail 2b30 : Thu Aug 22 2002 - 10:36:31 PDT