>> 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.
if you have other suggestion to solve this particular issue (how to
deal with unexpected native-ipv4-mapped packets), could you describe
that briefly? i'm trying to understand your mindset, and it looks
like as follows (correct me if i'm wrong):
- IPv4 packet on the wire, and native-ipv4-mapped packet on the wire,
must go through the same set of accept/deny policy in the kernel.
(I believe this is not correct understanding of RFC2553 section 3.7.
see below)
- this is applications' responsibility to deal with native-ipv4-mapped
packet. (this is close to impossible, from what RFC2553 provides)
>> 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.
my understanding was, for a dual stack node outside of SIIT
cloud, native-ipv4-mapped packets are unexpected and malicious.
i now see you are not agreeing with me here.
there is no specification that says "native-ipv4-mapped packet is
effectively the same as native IPv4 packet". this is defined only in
RFC2553, and SIIT document. RFC2553 explicitly states that IPv4 mapped
address is used to identify real IPv4 peer.
from this fact, if we are outside of SIIT cloud, I understand that
native-ipv4-mapped should be dealt differently from normal IPv4
packets, and are indeed malicious (as someone is trying to inpersonate
IPv4 peer).
i think all other differences in understanding started from here
(so i did not comment on other parts of the previous email from you).
do you disagree with my thinking in the above?
>How does this differ from A
>sending an ordinary IPv4 packet with a spoofed source address of 10.1.1.2 to
>B?
- This is much harder to track down the source, or cause of the packet
(partly because of tunnel, but you may say that this is a separate
issue)
- normal IPv4 ingress filter does not work (again, you can say it is
tunnel issue
- we are not in SIIT cloud, it is not expected to get
native-ipv4-mapped packet and it is malicious.
>If it does differ, then the point at which it differs is where the
>security problem that needs to be fixed lies.
this effectively saying that it is responsibility of userland program
to protect against inpersonateing guys. however, there's not much
userland application can do. this is partly because RFC2553 provides
no way to understand which wire format was used.
>> 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.
do you think that every application writers can handle this complex
checks? we at least need a guideline on "how to port your servers
onto ipv6 without compromising security". once we go into total
agreement i volunteer to start it.
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]
--------------------------------------------------------------------
