Subject: RE: New "IP Version 6 Addressing Architecture" draft

From: Brian Zill <[email-masked]>
Date: Fri, 21 Jul 2000 21:44:36 -0700

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-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Sun, 23 Jul 2000 13:21:27 +0900

>wire is necessary.  I'm not even sure it's a viable solution, much less a

	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)

>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
>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

	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.

>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

---

From: Hideaki YOSHIFUJI (吉藤英明) <[email-masked]>
Date: Sun, 23 Jul 2000 14:43:15 +0900

> 	  packet.  (this is close to impossible, from what RFC2553 provides)

	I think:

	- IPv4 packet on the wire, and native-ipv4-mapped packet on the wire,
	  should be handled by the same set of accept/deny policy in
	  APPLICATIONs.

	- this is KERNEL's responsibility to deal with native-ipv4-mapped
	  packet.  KERNEL should drop malicious packet from outside.

You too, Brian (Zill)?

-- 
Hideaki YOSHIFUJI @ USAGI Project  <[email-masked]>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Mauro Tortonesi <[email-masked]>
Date: Sun, 23 Jul 2000 14:36:23 +0200 (CEST)

> 	agreement i volunteer to start it.

this would be great. why not to write a guideline on "how to port your
servers to ipv6", then? security should be the most interesting argument,
but some other informations and usable code would be nice. i've read your
article "implementing af-indipendent applications" and i've found it very
interesting (i was about to write an updated version of it, with some code
examples) - it could be an excellent starting point.  

if you are looking for help, i am into it ;-)

-- 
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi			[email-masked]
Ferrara Linux User Group	http://www.ferrara.linux.it
Project6 - IPv6 for Linux	http://project6.ferrara.linux.it