I agree with Jim that we shouldn't break how IPv4-mapped addresses are used
in the basic API spec, nor should we forbid their use on the wire as SIIT
requires today.
The security issues Itojun raises look to me to be internal
implementation-specific issues. Let's look at his examples:
> 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.
Isn't this obvious? What's the problem? And how would preventing
IPv4-mapped addresses on the wire protect against this anyway?
> 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.
This is just broken access control code in the host. If you want to protect
against this, you need similar checks in any decapsulator as well, right?
Why is this any different?
> 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.
As you note, there are similar problems with IPv4-compatible addresses and
6to4 addresses. Again, why is adding checks to protect against one any
different than adding checks to prevent against the other? I'm against
dropping useful features of the protocol just to ease development of a
particular implementation.
Leaving the examples...
> 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.
Personally, I consider this to be a feature. To apps, a host with a
hybrid-stack should look exactly the same as a host that sits behind a
translator, shouldn't it?
Hmm, maybe it would be best for an implementation to internally map source
addresses of incoming IPv4 packets to IPv4-mapped addresses and destination
addresses to IPv4-translated addresses (and vice-versa on send).
> 3.2. Possible solutions
>
> 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.
If an implementation decides that it really needs to know whether a packet
came in as a real IPv4 packet or as an IPv6 packet with
mapped/translated/compatible addresses, then it could do this. Why is this
a bad solution?
Put another way, why should we waste a portion of the IPv6 address space on
node-internal information?
--Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
