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.


.  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.


.  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.


.  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.


.  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.


.  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.


.  Security considerations

The document talks about security issues in the use of IPv4 mapped
address.  Possible solutions are provided.


.  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: itojun@iijlab.net












































Hagino                    Expires: Feb 22, 2003                 [Page 5]