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]

Date:	Sat, 23 Jun 2007 10:47:06 -0400
From:	"C. Scott Ananian" <cscott@...top.org>
To:	"Rémi Denis-Courmont" <rdenis@...phalempin.com>
Cc:	"David Stevens" <dlstevens@...ibm.com>, netdev@...r.kernel.org
Subject: Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration

Rémi and Simon give my responses very eloquently.  Although you could
have yet-another-network-daemon redundantly process RA messages, the
kernel is doing it already and it makes sense to just push this
information to userland using /proc and/or netlink.  Although parsing
RA messages and processing expiry in userland looks barely-possible
now, SeND support is really necessary for long-term IPv6 security, and
duplicating SeND functionality in userland would be a nightmare.
Futher, the neighbor discover protocol involves Router Solicitation
messages which elicit the Router Advertisement reply, and we really
don't want userland sending redundant Router Solicitation messages
around, just because the kernel doesn't want to tell it what Router
Advertisements it received.  I considered storing the *complete*
Router Advertisement messages received and pushing them unparsed to
userland, just to get around the bogus "DNS in the kernel" politics
(hint: it's not a resolver in the kernel, it's just nameserver
addresses being stored).  Does anyone really suggest that this would
be a better solution?

The goal is to push the userland component into glibc, likely through
a NSS resolver plugin.  Current glibc doesn't do any processing to
determine when /etc/resolv.conf has changed, which is a problem for
long-running applications.  Exporting RDNSS-in-RA via netlink messages
(or by poll() on a /proc file as is done for /proc/<pid>/mounts, which
was suggested in linux-kernel) is an elegant solution that (as Rémi
noted) cleanly handles interface up/down/reconfig, route expiration,
and (eventually) the cryptographic neighbor discovery protocol without
weaving a web of hairs from the kernel to the resolver.
 --scott

-- 
                         ( http://cscott.net/ )
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html