Itojun,
I am unwilling to give up SIIT. Changing the architecture to forbid
IPv4-mapped addresses on the wire is unacceptable in my opinion.
I'm far from convinced that there is a real problem here. Your examples are
contrived. You already agreed I was right about the first one, so let's
look at the second again:
> >> 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?
>
> no, this is not the access control code that is broken.
> the problem is, under RFC2553, you have no way to
> distinguish between native-ipv4-mapped and
> RFC2553-inbound packet, in the userland.
Nor do you need to if you (the stack writer) only allow the same set of
native-ipv4-mapped addresses to show up where you'd allow them as
RFC2553-inbound addresses.
> both of them have ::ffff:127.0.0.1 as the result of
> getpeername (or getsockname), both of them appear on
> AF_INET6 socket, if you would like to permit accesses
> from IPv4 127.0.0.1, and even if you would like to
> reject native-ipv4-mapped with ::ffff:127.0.0.1, you
> can't do that.
If an IPv4 packet arrived at your machine with a source address of
127.0.0.1, what would your kernel do? Now if an IPv6 packet arrives at your
machine with a source address of ::ffff:127.0.0.1, what does your kernel do?
If it does the same thing in both cases, why should user-land care how it
got there? If it doesn't do the same thing, why not?
> >> 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),
That's not unexpected IPv4 traffic -- that's *expected* IPv4 traffic!
> >> 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.
But isn't that "certain behavior" more commonly known as "incorrect
behavior"?
> >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?
>
> the problem is that people can inject malicious
> packets more easily than before. they can inject
> malicious IPv6 packet from remote places (by
> wrapping it into IPv4 packet).
What does this have to do with v4-mapped addresses?
> they can let us relay malicious packets by abusing
> normal IPv6 routers, auto-tunnel capable IPv6
> routers, and 6to4 relay routers. it will be much
> harder to track than normal IP packets we are seeing.
These are all tunnelling issues. Nobody is suggesting getting rid of
tunnels to fix them - they're suggesting appropriate security checks. I ask
again, why is adding checks to protect against v4-mapped address misuse any
different?
> SIIT requires the dual use of IPv4 mapped address
> (native-ipv4-mapped and RFC2553-inbound). this is
> a feature of SIIT, not the other documents.
No, SIIT doesn't require user-level programs to receive IPv4 packets on
AF_INET6 socekts. It only requires that IPv6 packets (with v4-mapped
addresses) are received on AF_INET6 sockets. Machines living on the v6 side
of the translator only need to speak v6!
> >> 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?
>
> maybe my text is rather unclear, but what part are
> you referring to by the underlined "this"?
This = recording the wire packet format in the connection table. If you
really insist that user-land needs to know the difference for some reason, I
suppose you could do this and find some way for the kernel to pass it up
(ammend scope id behavior?). I still don't see the need though. This
transparency still strikes me as a feature, not a bug.
--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]
--------------------------------------------------------------------
