[Server-devel] Fwd: [PATCH] IPv6: optionaly validate RAs on raw sockets

[C. Scott Ananian]

Putting RA advertisements in the kernel seems to be contentious still.
 Yoshifuji was a little more supportive of my approach, saying,  "I'm
not still conviced to adopt this work in kernel, but... well... ".
Hopefully I'll get some cycles to work more on this after Trial 2
stuff is done.
 --scott

Forwarded Conversation [trimmed some]
Subject: [PATCH] IPv6: optionaly validate RAs on raw sockets
------------------------

 From: Remi Denis-Courmont <rdenis at simphalempin.com>
To: David Miller <davem at davemloft.net>, yoshfuji at linux-ipv6.org
Cc: netdev at vger.kernel.org
Date: Tue, Jul 10, 2007 at 2:11 PM

ICMPv6 Router Advertisements may now contain informations that is
mostly of interest to userland. This currently mostly consists of
recursive DNS server addresses (though one should expect other
stuff to come).

This patch adds a setsockopt to ICMPv6 sockets to only deliver Router
Advertisements if they pass the same set of checks as the kernel
IPv6 autoconfiguration does, so that userland can parse attributes it
is interested safely (otherwise, it would get and parse advertisements
that the kernel rejected).
[...]

--------
 From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji at linux-ipv6.org>
To: rdenis at simphalempin.com
Cc: davem at davemloft.net, netdev at vger.kernel.org, yoshfuji at linux-ipv6.org
Date: Wed, Jul 11, 2007 at 8:29 AM

In article <200707102111.18824 at auguste.remlab.net> (at Tue, 10 Jul
2007 21:11:17 +0300), Remi Denis-Courmont <rdenis at simphalempin.com>
says:

> ICMPv6 Router Advertisements may now contain informations that is
> mostly of interest to userland. This currently mostly consists of
> recursive DNS server addresses (though one should expect other
> stuff to come).

I really do not want to have such non-standard API in kernel.

--yoshfuji
--------
 From: Rémi Denis-Courmont <rdenis at simphalempin.com>
To: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji at linux-ipv6.org>
Cc: davem at davemloft.net, netdev at vger.kernel.org
Date: Wed, Jul 11, 2007 at 8:44 AM

On Wednesday 11 July 2007 15:29:16 YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <200707102111.18824 at auguste.remlab.net> (at Tue, 10 Jul 2007
21:11:17 +0300), Remi Denis-Courmont <rdenis at simphalempin.com> says:
> > ICMPv6 Router Advertisements may now contain informations that is
> > mostly of interest to userland. This currently mostly consists of
> > recursive DNS server addresses (though one should expect other
> > stuff to come).
>
> I really do not want to have such non-standard API in kernel.

I can only think of a very limited set of ways to extract options from RAs
that the kernel currently ignores:

1) parse everything in kernel addrconf.c
2) validate RA in kernel, parse userland options in userland
3) parse everything in userland
4) do not support any option of interest to userland ever
5) userland and kernel do their own cooking separately

netdev folks already rejected (1) earlier. You just rejected (2) this instant.
(3) implies removing addrconf from the kernel completely, which does not
sound good, besides being a big waste. (4) means Linux is unusable on IPv6
networks. And it's already been pointed out (5) was not safe/secure (userland
may end up accepting something when it should not).

I might be missing something because I am a notoriously arrogant moron but it
looks like Linux IPv6 is in a dead-end for the time being :-(

What do you propose then?

--
Rémi Denis-Courmont
[Quoted text hidden]
--------
 From: David Stevens <dlstevens at us.ibm.com>
To: Rémi Denis-Courmont <rdenis at simphalempin.com>
Cc: davem at davemloft.net, netdev at vger.kernel.org,
netdev-owner at vger.kernel.org, YOSHIFUJI Hideaki / 吉藤英明
<yoshfuji at linux-ipv6.org>
Date: Wed, Jul 11, 2007 at 9:20 AM

I think #2 in your list is the right choice, and that has nothing to do
with adding a
non-standard option (which I completely agree is a bad idea).

It looked like you're just checking if the machine is acting as a router
or not and
if it comes from a link-local address; is that right? Of course, lots of
apps already
check for "am I a router" and they don't require a new socket option. (!)
See everything
in the quagga package, for example. And checking the address type in a app
is
trivial.

The previous discussion about "validation" was talking about RA's that are
forged,
so don't pass IPsec authentication checks. I don't see any reason at all
to deliver those
to an application (ever), so no non-standard socket option required there.
I don't know
if those are currently delivered on raw sockets or not, but if they are, I
think it's
reasonable to have a patch that clones them only after authentication
rather than before.

Prior discussion used FUD about some monitoring apps needing to see forged
RA's.
I don't think there really are apps that need to see forged RA's, but if
they really
want everything, they should use bpf or the like, just as they would need
to do to
receive, for example, packets with invalid checksums.

                                                                +-DLS
[Quoted text hidden]
--------