[ipv6hackers] SLAAC and DHCPv6 support (was Re: IPv6 security presentation at Hack.lu 2011)

[Douglas Otis]

On 9/27/11 5:17 PM, Fernando Gont wrote:

Hi Fernando,
> 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:
>> http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems
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 
is used.

It is hard to image how the typical arrangement used with IPv4 can be 
trusted, especially with UDP packets being in the clear.

-Doug