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

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

I agree with Jim that we shouldn't break how IPv4-mapped addresses are used
in the basic API spec, nor should we forbid their use on the wire as SIIT
requires today.

The security issues Itojun raises look to me to be internal
implementation-specific issues.  Let's look at his examples:

> We have three problems with the specification.  First,
> IPv4 mapped address support complicates IPv4 access
> control mechanisms.  For example, if you would like to
> reject accesses from IPv4 clients to a certain transport
> layer service, it is not enough to reject accesses to
> AF_INET socket.  You will need to check AF_INET6 socket
> for accesses from IPv4 clients (seen as accesses from
> IPv4 mapped address) as well.

Isn't this obvious?  What's the problem?  And how would preventing
IPv4-mapped addresses on the wire protect against this anyway?

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

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

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?  I'm against
dropping useful features of the protocol just to ease development of a
particular implementation.

Leaving the examples...

> The confusion came from the dual use of IPv4 mapped
> address, for node-internal representation for remote
> IPv4 destination/source, and for real IPv6
> destination/source.

Personally, I consider this to be a feature.  To apps, a host with a
hybrid-stack should look exactly the same as a host that sits behind a
translator, shouldn't it?

Hmm, maybe it would be best for an implementation to internally map source
addresses of incoming IPv4 packets to IPv4-mapped addresses and destination
addresses to IPv4-translated addresses (and vice-versa on send).

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

Put another way, why should we waste a portion of the IPv6 address space on
node-internal information?

--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: Sat, 22 Jul 2000 07:53:01 +0900

>implementation-specific issues.  Let's look at his examples:

	no, this is not an implementation-specific issue.

	first I need to be very clear: I have couple of options to solve
	this security issue.  major routes are:
	- change addressing architecutre and forbid native-ipv4-mapped
		CONS: application writers are asked to check RFC2553-inbound
			cases, which is not that trivial when seeing the spec
		CONS: SIIT cannot be used
	- change RFC2553 API to disable RFC2553-inbound
		PROS: applications gets simplified very well, AF_INET6 is
			always IPv6, AF_INET is always IPv4 (good for security)
		PROS: RFC2553-inbound case is gone, application writers do not
			need to care about RFC2553-inbound cases
		CONS: SIIT itself is okay, but now unnatural
	- change RFC2553/2292 API to pass protocol version on the wire to the
	  userland, to allow applications to distinguish between RFC2553-inbound
	  and native-ipv4-mapped
		PROS: no impact to SIIT
		CONS: too much complexity is left, bad for security
	now we are talking about the first one.  taking both 1st and 2nd
	one is my favorite, actually.

	here i try to define acronym for clarification:
	RFC2553-inbound:
		inbound IPv4 traffic goes into AF_INET6 wildcard socket
	RFC2553-outbound:
		outbound AF_INET6 packet with IPv4 mapped address goes to IPv4
	native-ipv4-mapped:
		IPv6 packet with IPv4 mapped address in src/dst address field
		in IPv6 header

>IPv4-mapped addresses on the wire protect against this anyway?

	you right, this one does not directly solved by prohibiting
	native-ipv4-mapped.
	i have seen and made improvements to many ported applications.
	almost none of them have the proper access control logic with
	consideration to RFC2553-inbound.  for security, complexity is a
	bad thing.

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

	In the solutions I listed, I missed one option: extend API to
	give application some idea about the IP version (native-ipv4-mapped
	or RFC2553-inbound).

>particular implementation.

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

>addresses to IPv4-translated addresses (and vice-versa on send).

	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.  (see the earliest part of the email for possible other
	routers to take)

>a bad solution?							~~~~

	maybe my text is rather unclear, but what part are you referring
	to by the underlined "this"?

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Jul 2000 16:54:49 -0700 (PDT)

> 		CONS: SIIT itself is okay, but now unnatural

This also has the CONS that it makes it harder to port current AF_INET
server applications to support both IPv4 and IPv6 - you can no longer have
a single in6addr_any AF_INET6 listening/receiving socket.

  Erik

---

From: [email-masked]
Date: Wed, 26 Jul 2000 09:08:58 +0900

>a single in6addr_any AF_INET6 listening/receiving socket.

	we can make it switchable via setsockopt, if the ported application
	requires RFC2553-inbound behavior (i think jim mentioned it in past
	email about netbsd implementation - which is one of the proposals
	from us).

itojun