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

From: Brian Zill <[email-masked]>
Date: Fri, 21 Jul 2000 17:03:19 -0700

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Jul 2000 20:08:32 -0500

> IPv4-mapped addresses on the wire is unacceptable in my opinion.

Absolutely. I *hate* translators and always have done, but
unfortunately we will need them for the next ten or fifteen years.

  Another Brian

---

From: [email-masked]
Date: Sat, 22 Jul 2000 11:09:04 +0900

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

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

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

>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

>But isn't that "certain behavior" more commonly known as "incorrect

	for FTP bounce attack case, you are right (TCP is harder to forge).
	please think about DNS query example above.

>What does this have to do with v4-mapped addresses?

	again, just like shown in the above.

>again, why is adding checks to protect against v4-mapped address misuse any

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

>of the translator only need to speak v6!

	see my reply to yoshfuji.

>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

---

From: [email-masked]
Date: Sat, 22 Jul 2000 11:14:29 +0900

>	i hope you do not mean this...

	in the example, please ignore "MAC address" portion.
	i was making example where A and B are on the same link, and forgot
	to fix the portion.

itojun

---

From: Hideaki YOSHIFUJI (吉藤英明) <[email-masked]>
Date: Sat, 22 Jul 2000 12:14:17 +0900

> 	  SIIT (too-clever SIIT enabled client may try to drop it because of

	Not too-clever.

	SIIT should drop packets whose source address is
	::ffff:a.b.c.d/(96+n) (assuming figure in my previous mail).

	Nodes in SIIT cloud should drop packets whose source 
	address is ::ffff:127.0.0.0/104 and ::ffff:a.b.c.d/(96+n) from 
	outside.

	Nodes not in SIIT cloud should drop ::ffff:0:0/96 from outside.

	Anyway, issues seems to be administrative problem.

-- 
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: [email-masked]
Date: Sat, 22 Jul 2000 12:28:55 +0900

>> 	  SIIT (too-clever SIIT enabled client may try to drop it because of

	i don't see any of your wording on RFC2765.  i took your email as a
	suggestion to RFC2765, am I right?
	your suggestion does not protect nodes that are outside of SIIT cloud
	(which is more common setup today).  how do you intend to secure
	those nodes?  i think you are making separate discussion thread here.

>	::ffff:a.b.c.d/(96+n) (assuming figure in my previous mail).

	you mean the SIIT box ([SIIT] in the following figure) should drop
	the packet, when the packet tryes to go into the SIIT cloud?

				    drop it
                     ___________    <-----    ___________
                    /           \            /           \
      [IPv6 Host]--< Dual network>--[SIIT]--< IPv4 network>--[IPv4 Host]
                    \___________/     |      \___________/
                             (pool of IPv4 addresses)

>	address is ::ffff:127.0.0.0/104 and ::ffff:a.b.c.d/(96+n) from 

	i don't think this is workable, as this requires every nodes in
	SIIT cloud to know about the IPv4 address pool configured to the
	SIIT cloud.

	From seeing RFC2765 section 5, I think that the nodes in SIIT
	cloud is unaware of the existence of SIIT box (or it does not know
	if it is inside SIIT cloud or not).

>	Anyway, issues seems to be administrative problem.

	i think, for an end node in SIIT cloud, it is impossible to
	determine if the traffic is from the outside, or from inside.

itojun