Hi Itojun,
> as i wrote in my reply to yoshfuji's email,
> - i still think it is real serious issue
Oh, I believe that there are many serious security issues involved with a
number of the transition mechanisms that are either proposed or in current
use today. And I applaud you for taking the time to look into them. I just
don't believe that forbidding IPv4-mapped addresses from appearing on the
wire is necessary. I'm not even sure it's a viable solution, much less a
good one.
> - i'll come up with sample program, to show you
> that it's real.
Scenarios are fine, programs not required.
> >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?
I'm saying that the stack should use the same criteria when deciding whether
to accept an IPv6 packet with mapped addresses that it would use for the
equivalent IPv4 packet. In the example mentioned, if you refuse to accept
an IPv4 packet because it has a 127.0.0.1 source address, then you should
refuse to accept an IPv6 packet with a ::ffff:127.0.0.1 source address.
> - 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.
Okay, reasonable policy.
> - 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
Huh? The policy should be the same. Drop the packet. SIIT doesn't have
anything to do with it. SIIT doesn't require you to accept packets that an
IPv4 host in place of the SIIT/v6-only host combination wouldn't accept.
A combination SIIT box and IPv6 only host should look to the other side of
the SIIT exactly like an IPv4 host. Likewise, it should look to the
user-land API exactly like a hybrid v6/v4 stack host (it doesn't exactly
because of IPv6 translated addresses, but that's why I suggested in my
previous email that a hybrid host might want to present it's own v4
addresses as v4-translated addresses and remote addresses as v4-mapped
addresses. But that's a nit).
> 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)
>
> 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.
>
> IPv4 (src=10.1.1.1, dst=10.1.1.2)
> UDP (src port=53, dst port=X)
> DNS reply
Yes, that is exactly what I'd expect to happen. How does this differ from A
sending an ordinary IPv4 packet with a spoofed source address of 10.1.1.2 to
B? If it does differ, then the point at which it differs is where the
security problem that needs to be fixed lies.
> 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}.
I agree completely. Again, I'm glad you're looking into these issues. What
I disagree with is your desire to remove a useful transition technology
instead of making all the proper checks that would prevent its misuse.
> 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.
Your English is fine, and much better than my Japanese. What I'm saying is
that I don't see why you'd ever need to guess. It shouldn't matter to the
user-land program how the packet got there. The kernel should ensure that
you get a v4-mapped packet with wire format of IPv6 if and only if it would
have let you get the same packet with a wire format of IPv4.
--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]
--------------------------------------------------------------------
