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 09:48:12 -0700
From:	David Stevens <dlstevens@...ibm.com>
To:	"C. Scott Ananian" <cscott@...top.org>
Cc:	cananian@...il.com, netdev@...r.kernel.org,
	"Rémi Denis-Courmont" <rdenis@...phalempin.com>
Subject: Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration

cananian@...il.com wrote on 06/23/2007 07:47:06 AM:

> 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

        It would be two pieces looking at the same packet, but it isn't
redundant processing. The kernel would ignore the RDNS header, and the
app would ignore everything else; everything would be processed once.

> Although parsing
> RA messages and processing expiry in userland looks barely-possible
> now,
        "barely possible"?? See below.

> 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?

        No, in fact! I didn't hear anyone suggesting that all of
neighbor discovery be pushed out of the kernel. All I suggested is
that you read a raw ICMPv6 socket for RA's that have the RDNS header
and the app _process_the_RDNS_header. The kernel should still continue
to do everything it needs to with the kernel data in the RA. Then you
just need a hash table (or maybe just a list -- there shouldn't be a
lot of them) and a timer to delete them when the RDNS expiration hits.
Easy, right?
        You might have to change the icmp6_filter, if RA's are not
already copied to raw sockets (I don't know either way offhand),
but that's a trivial kernel patch; otherwise, I don't believe you
have to do anything but read the socket and process the RDNS header
on RAs you receive.
 
 +-DLS

-
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