Re: ipv6/ipv4 co-operation problem

From: Brian Wellington (bwelling@xbill.org)
Date: Thu Jun 15 2000 - 12:37:24 EST


On Thu, 15 Jun 2000 kuznet@ms2.inr.ac.ru wrote:

> Hello!

Hi. Thanks for the quick response.

> > > Of course. Socket bound to IN6ADDR_ANY listens for IPv4 as well,
> > > so that no more bindings to this port are allowed more.
> >
> > Is this the desired behavior?
>
> To my opinion, it is not desired behavior. 8)
>
> But:
>
> > It opens up some pretty large security
> > holes. Any sort of IPv4 access control is bypassed when IPv4-mapped IPv6
> > addresses are used.
>
> Sorry... You have said something strange. Think more.
> Setting policy of kind, proposed by you, by default is
> evident security hole.
>
> BTW, your reference to KAME in this context sounds interesting,
> port stealing hole is one of the largest flaws in 4.4BSD API. 8)

Yes, 4.4 BSD is broken. The current NetBSD, at least, only allows more
specific port binding if the uid of the process is the same as the uid
that opened the less specific socket. It fixes the port stealing problem,
while still being useful.

> > The current thinking is that IPv6 sockets should not accept IPv4
> > connections by default.
>
> I am old unlucky fighter against brain damaged transition mechanism,
> combining IPv6 and IPv4 to one port space. 8)

This is configurable on NetBSD using a sysctl - net.inet6.ip6.bindv6only.
It would be even better if it was configurable per application, with
setsockopt, and one of the NetBSD developers is trying to get that added.

> But the thing, which you have just said is something doubly weird
> and would break all currently existing applications.

Most existing applications don't support IPv6 anyway. There have been a
lot of trivial INADDR_ANY -> INADDR6_ANY changes to get those applications
to work, but I don't think they're that heavily used yet.

If the default was to not bind to IPv4 addresses, and a setsockopt() would
allow the binding, the trivially modified applications would just need
another trivial modification.

> Hierarchical bind() never existed. If applications wants
> to bind to specific address, it binds to specific address,
> be it IPv6 or IPv4. If you listen, you listen everything.
> Provided we follow paradigm of sharing port spaces
> between IPv4 and IPv6, it is not clever idea to break this simple rule.

This rule seems wrong. INADDR6_ANY should mean "all IPv6" addresses, not
"all addresses". It has a 6 in it, after all. If anything, INADDR_ANY,
which doesn't have a 4 or a 6, should mean "all addresses". The RFC
recommends this, but many people (including some of the authors) think
it's a bad idea for security reasons, and it has either been changed in
the current drafts or will be changed very soon.

> > We're running into Linux IPv6 problems in BIND 9 development related to
> > this. It works better on pretty much every other OS we're testing.
>
> I apologize, but if it works differently on Linux, it is simply broken. 8)

I don't think so. To effectively work on IPv6, a daemon needs to open the
wildcard socket. Otherwise, it would need to open many individual sockets
(at least 3 per interface), and would need to check for changes in IP
addresses often to handle rapid renumbering. With a wildcard socket,
filtering can happen in user space, and only one socket is needed.

IPv4 is a different story. Addresses are (usually) static, so
named traditionally has opened one listening TCP socket per IP address,
and allowed interfaces to be specifically enabled/disabled (by address).
We don't want to break backwards compatibility.

With IPv6, though, opening a wildcard TCP socket also accepts IPv4
connections, so that the IPv4 acls on TCP unexpectedly just don't work
unless IPv6 is specifically disabled, since the TCP bind()s fail, but
connections are still possible through mapped addresses. With the current
API, there's no way to say "I want to listen on all IPv6 addresses".
There should be.

Brian

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:35 EST