netdev - Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200706232218.50100@auguste.remlab.net>
Date:	Sat, 23 Jun 2007 22:18:44 +0300
From:	Rémi Denis-Courmont <rdenis@...phalempin.com>
To:	David Stevens <dlstevens@...ibm.com>
Cc:	cananian@...il.com, "C. Scott Ananian" <cscott@...top.org>,
	netdev@...r.kernel.org
Subject: Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration

Le samedi 23 juin 2007, David Stevens a écrit :
>         This doesn't say that unauthenticated packets must be
> delivered, and I don't think the portability of an RDNS daemon is an
> issue. But even if you really wanted to run the same code on a
> non-Linux machine, it just means that your daemon code would have to
> do its own authentication.
> Reading /proc or netlink with packet formats you've defined to get
> this information is not more portable to non-Linux machines, right? I
> don't see any issue here. If an application is relying on the ability
> to see forged packets for portability reasons, it's probably not an
> application you want running on your machine. :-)

It so happens that the very userland applications that are currently 
using raw ICMPv6 sockets to see RAs *DO* want to see them all. As far 
as I know, they are all monitoring softwares (radvdump from radvd, 
rdisc6 from ndisc6, and probably scapy as well) where you do want to 
see "problematic" packets.

All in all, this would break well-behaved standard-abiding userland 
applications...

> > The userspace DNS configuration daemon might need to be started
> > later than the kernel autoconf - another issue that needs help from
> > the kernel.
>
>         Easily done; the init scripts are what bring the interfaces
> up in the first place, so start the daemon before those run. Adding
> an entry in inittab so it'll be automatically restarted if it dies is
> also a reasonable thing. RA's are resent periodically, and they can
> be lost anyway, so not the end of the world if you miss one, either.

What about NFS root? the network interface will already be up before 
even the real init gets started, let alone the userland RDNSS daemon.

"resent periodically"... at a default rate of one every 10 minutes! I 
surely hope your desktop boots up faster than that. Besides, some links 
do not have unsolicited advertisements at all (I have seen such a PPPoA 
link for instance). An ugly kludge would be to send a RS from userland, 
but that's not so great considering routers are rate-limiting their 
RAs.

The only way is for the kernel to remember "something" about the last 
processed RA. That disqualifies raw ICMPv6 sockets.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)