[ipv6hackers] SLAAC and DHCPv6 support (was Re: IPv6 security presentation at Hack.lu 2011)
dotis at mail-abuse.org
Wed Sep 28 04:08:12 CEST 2011
On 9/27/11 5:17 PM, Fernando Gont wrote:
> Hi, Jim,
> On 09/27/2011 08:36 PM, Jim Small wrote:
>>> Last time I checked (1-2 years ago), neither Windows, nor any of
>>> the open source OSes I was using supported RDNSS by default.
>> Here's a good list of RDNSS and DHCPv6 support for most O/S:
Even this list missed a few as it is growing which should suggest there
might be trend...
>> Notably though OS X 10.7 supports it, along with some versions of
>> UNIX/Linux. Crossing my fingers for Windows 8...
> Thanks for the info! -- I assume that the OS versions listed in the URL
> above correspond to the first version of the OS which included support
> for each feature... Skiming through the list, it seems that RDNSS
> support was added to "latest version of X", which in most cases dates
> back to only a few months ago.... Thus, I don't think one could rely on
> support for such RDNSS, unfortunately.
> -- not to mention that no version of Windows supports it... which in
> most general scenarios makes this a "show stopper".
Why continue to make extrapolation against IPv4 approaches where there
IS dependence upon both ARP and DHCP?
The point that must be internalized is that neither DHCPv6 nor RDNSS
reliance can be assumed. Neither protocol can act as a comprehensive
basis to identify hosts. Especially with limited support for relaying
and snooping host related information carried within DHCPv6 responses
that still will not identify a host in a meaningful way by the DUID.
The host must be extrapolated using non-standard inclusion host related
information added to logs. Why not leverage EAP related protocols
instead, for example? Leveraging a certificate assigned to a host is
far more secure and offers far greater security. It seems there are
several alternatives within the realm of being even more practical than
inventing yet another overly complex and painful DHCP arrangement.
>>>> Real LAN based security remains possible with SeND,
>>> ... if only one could deploy it for the general case.
>> Unfortunately I have no good news here. AFAIK it's not even in the
>> stock BSD/Linux kernels and there is no option I know of for
>> Apple/Microsoft O/S nor plans/interest from those vendors in
>> supporting it.
> Even "implementation-wise" (i.e., even if SEND were deployable), it
> would take years before OS versions with support for SEND replace
> existing installations. -- That essentially mean that it would take many
> years before you could actually think/try about deploying SEND.
Again, not all devices within a network would be required to support
SeND. See Configuring Secured and Nonsecured Neighbor Discovery Message
Coexistence Modes. As protocols like DANE get advanced, the need for
PKI related services start to disappear, which removes another
impediment against the use of SeND. Even DANE itself might act as a
replacement whenever encryption based upon the certificate at the host
It is hard to image how the typical arrangement used with IPv4 can be
trusted, especially with UDP packets being in the clear.
More information about the Ipv6hackers