Re: comment on v4mapped-api-harmful

[Pekka Savola <pekkas@netcore.fi>]

On Mon, 18 Nov 2002 itojun@iijlab.net wrote:
> 	to be clear, i have been pointing this problem out since 2553bis
> 	discussions group (apifolks).

Yep..
 
> >o Do not intentionally use RFC2553 section 3.7 (IPv4 traffic on AF_INET6
> >  socket).  Implement server applications by using separate AF_INET and
> >  AF_INET6 listening sockets.  Explicitly set the IPV6_V6ONLY socket
> >  option to on, whenever the socket option is available on the system.
> >==> please provide some overview on the migration path (kernel/library, 
> >apps) from the current state to this.
> >Reversing the default value would appear to be totally unacceptable, 
> >because it'd break _all_ current apps.
> 
> 	it'd breaks apps that assume IPv4 mapped address support, such as:
> 	- server program that listens to AF_INET6 socket only to receive both
> 	  IPv4 and IPv6 inbound traffic.
> 		can be worked around by running two instance of the app,
> 		one for AF_INET and one for AF_INET6

Sure, but the point was how to get there?

Hypothetically assume that the model you proposed is adopted.  Some
vendors have it right now.  Some have it in 1 year, some in 2.  Some may
never implement it.

How should you code your app so that it detects whether AF_INET6 is enough 
or whether it needs also AF_INET? 

In particular, in some systems:

1) bind to AF_INET6 with IPV6_V6ONLY gives only AF_INET6
 a) on some, setsockopt IPV6_V6ONLY will fail
2) bind to AF_INET6 without IPV6_ONLY gives
  a) only AF_INET6
  b) both AF_INET and AF_INET6
3) bind to AF_INET6 with some new "IPV6_ALSOV4" gives both sockets

Porting apps wrt. AF_INET6 quirks is complicated enough already (but 
somehow getting to the state you propose would simplify it in the long 
term).

I guess you could use something like "#ifdef IPV6_ALSOV4" to check whether
the system would support your model -- checking with IPV6_V6ONLY will not
be enough -- but in reality, the check should be done at runtime.

> 	the change in default behavior shouldn't break applications if
> 	appliations are correctly written to handle IPv4 traffic on AF_INET
> 	socket, and IPv6 traffic on AF_INET6 socket.

The problem is that the definition of "correctly written" is currently 
satisfied by doing AF_INET6 + mapped addrs.
 
> 	the following code fragment (server side) should avoid vulnerability
> 	on systems with/without IPv4 mapped address behavior, assuming:
> 	- bind(2) to the same port on AF_INET and AF_INET6 does not conflict
> 	  (yes, some systems they do conflict and you can open only one of them)
> 	- 2553bis IPV6_V6ONLY is implemented
> 	- getaddrinfo(3) returns both AF_INET and AF_INET6 wildcard address
> 	  on AI_PASSIVE
> 	i dunno, on how many systems, the above assumption holds.  due to the
> 	lack of specification bind(2) behavior varies very much by
> 	implementation.

I think you're also assuming:
 - when the system headers/libs support IPV6_V6ONLY, the kernel also 
supports it
 - the same binary cannot be used on systems with different IPV6_V6ONLY 
etc. implementation (see above)
 
> #ifdef IPV6_V6ONLY
> 		if (res->ai_family == AF_INET6 && setsockopt(s, IPPROTO_IPV6,
> 		    IPV6_V6ONLY, &on, sizeof(on)) < 0) {
> 			close(s);
> 			continue;
> 		}
> #endif
> 		if (bind(s, res->ai_addr, res->ai_addrlen) < 0) {
> 			close(s);
> 			continue;

if your lib supports IPV6_V6ONLY (or, rather, the version where the
program compiled with) but kernel doesn't, I believe this will end up
listening to AF_INET only.

Seems like a pretty nasty change of behaviour (== DoS) to me.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords