[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/