>During w.g. last call, I suggested a change of wording in the
>definition of IPv4-mapped addresses (mail attached below). I
>see the suggestion was not incorporated in addr-arch-v3-01.
>Let me offer an example of what motivated my suggestion.
maybe it is too late, but I do have a comment on addr-arch-v3-01.
I presented the issue at the previous IETF.
addr-arch-v3-01 is silent about what is the legal use of IPv4
mapped address. RFC2553 suggests to use it as node-internal
identifier for IPv4 destination, and SIIT draft suggests to use
it on the wire in IPv6 headers.
because the address can be used for two meaning, we have possible
security issue if we try to support RFC2553 AF_INET6 special behavior.
please refer to draft-itojun-ipv6-transition-abuse-01.txt, specifically
section 3. my suggestion is to forbid IPv4 mapped address in the IPv6
headers, and remove ambiguity from the dual use.
itojun
--- excerpt
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
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
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).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
