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 21:13:01 +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 :
>         The kernel should do the authentication, as it will for other
> RA's,
> and should not deliver (IMAO) unauthenticated packets. If it is, I
> would consider that a bug (for all cases, not just this), and that
> would be a good thing to fix. :-)

I am all for an interface whereby the kernel queues all "accepted" RAs 
for userland to process additionnal parameters... but that's totally 
NOT how ICMPv6 raw sockets currently work, and it would be a very 
significant departure from the Advanced IPv6 Socket API (RFC 3542, in 
particular §3.3):

   An implementation might perform additional validity checks on the
   ICMPv6 message content and discard malformed packets.  However, a
   portable application must not assume that such validity checks have
   been performed.

Being malformed does not include failing authentication, or the local 
host not using autoconf. I am all for a setsockopt() that limits 
delivery to "accepted" RAs, but it does not currently exist.

>         An interface going down doesn't directly invalidate a DNS
> server address, though it may not be the best through another
> interface. Since it is a list, I think "doing nothing" for this case
> wouldn't be terrible. This is no worse than the existing resolver
> code.

That would encourage people into running open recursive DNS servers 
which is widely known and documented as a bad practice. Definitely a 
very bad idea.

> But if you really need it, you can monitor netlink, or poll the
> interface flags on whatever interval you require for detection.

>         As for autoconf, that's available from sysctl, I assume from
> /proc somewhere, too. That usually doesn't change, but if you want to
> account for runtime configuration changes, you can always monitor
> netlink and reread when new addresses appear, too.

There are a bunch of parameters that determine whether an interface 
accepts RAs or not. I doubt it's wise to try to reimplement that into 
userspace, particularly if it is subject to change.

>         There certainly may be complications I haven't thought of,
> since I haven't implemented it. But I still don't see a good case for
> using the kernel as a DNS database.

I never said the kernel needed to parse DNS messages by itself. My point 
is raw IPv6 sockets are not usable for the time being, and I do not see 
anyway to fix without modifying the kernel.

The userspace DNS configuration daemon might need to be started later 
than the kernel autoconf - another issue that needs help from the 
kernel.

-- 
Rémi Denis-Courmont
http://www.remlab.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