>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:
as i wrote in my reply to yoshfuji's email,
- i still think it is real serious issue
- i'll drop the comment to address architecture, for now
- i'll come up with sample program, to show you that it's real.
hope we can test it in pittsburgh.
>> 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.
i don't understand what you mean here... you say that, if the stack
accepts RFC2553-inbound case, you need to accept native-ipv4-mapped?
>> 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?
127.0.0.1 may be a special case, but i try to outline it here.
"normal" userland program will do the following.
struct sockaddr_storage ss;
struct sockaddr_in6 *sin6;
socklen_t salen;
salen = sizeof(ss);
getpeername(s, (struct sockaddr *)&ss, &salen);
switch (ss.ss_family) {
case AF_INET:
/* it is always IPv4 packet, IPv4 access control */
break;
case AF_INET6:
sin6 = (struct sockaddr_in6 *)&ss;
if (IN6_IS_ADDR_V4MAPPED(&sin6->sin6_addr))
/* IPv4 access control */
else
/* IPv6 access control */
break;
}
- if we got an IPv4 packet with 127.0.0.1 in the source, and it was
from outside, it should be dropped by the kernel. (RFC1812 p48 (e))
many kernel do not drop it, though.
if the packet comes upward to AF_INET6 socket, it will be presented
as ::ffff:127.0.0.1, and normal userland program will think that it
is from IPv4 source 127.0.0.1.
- if we got an IPv6 packet with ::ffff:127.0.0.1 in the source,
and it was from outside, the kernel does not drop it for the sake of
SIIT (too-clever SIIT enabled client may try to drop it because of
IPv4 rules)
if the packet comes upward to AF_INET6 socket, it will be presented
as ::ffff:127.0.0.1, and normal userland program will think that it
is from IPv4 source 127.0.0.1.
for addresses other than 127.0.0.1, story goes mostly the same,
except that we do not have RFC1812 rule.
>> >> 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!
do you say the following packet trace is the expected behavior?
i hope you do not mean this...
A: bad guy, using remote IPv4 address z.z.z.z
B: has an IPv4 address 10.1.1.1/24, has auto tunnel support.
(the use of private address is just for example)
MAC address A -> MAC address B:
IPv4 (src=z.z.z.z, dst=10.1.1.1)
IPv6 (src=::ffff:10.1.1.2, dst=::10.1.1.1)
UDP (src port=X, dst port=53)
DNS query
as RFC1933/1933bis does not limit IPv6 source on auto tunnel traffic,
the packet will go all the way to the IPv6 transport capable
DNS server via AF_INET6 socket, and gets replied.
MAC address B -> MAC address A:
IPv4 (src=10.1.1.1, dst=10.1.1.2)
UDP (src port=53, dst port=X)
DNS reply
>> >> 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"?
for FTP bounce attack case, you are right (TCP is harder to forge).
please think about DNS query example above.
>> 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?
again, just like shown in the above.
>> 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?
what i'm saying is, this is real hard to get it right. there are
many tunnelling technologies and transition technology. for a
given tunnelling/transition technology Ti, we need to make sure
that we make proper checks against all the transition technologies,
T{1..n}.
>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!
see my reply to yoshfuji.
>> >> 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.
i'm suggesting, in the draft, to record wire packet format in the
connecdtion table. i'm objecting to guess wire packet format
from address format, for example:
if (IN6_IS_ADDR_V4MAPPED)
wire format is IPv4
else
wire format is IPv6
i think my english was not good enough.
itojun
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
