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

[Fernando Gont]

Hi, Douglas,

On 09/27/2011 11:08 PM, Douglas Otis 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...

I've just checked a default installation of FreeBSD-current of a few
months ago, and it doesn't seem to be processing RDNSS. Could you please
comment on which version of FreeBSD you were referring to as "supporting
RDNSS"?


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

My coments above where about RDNSS, and not about ARP, DHCP, SLAAC, or
DHCPv6.

However, since you asked, IPv4 depends on ARP for address resolution,
and on DHCPv4 for autoconfiguration (i.e., one protocol for one
function). IPv6 ends-up depending on SLAAC and DHCPv6 for
autoconfiguration (i.e., two protocols for a single function). --
(although strictly speaking, one should add MLD to that list).


> The point that must be internalized is that neither DHCPv6 nor RDNSS
> reliance can be assumed.

Then comes the question: how the heck do we get the address of a caching
DNS server?


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

I don't follow. We're talking about how messy it is to be relying on two
protocols for the same function (autoconf), particularly when it would
be trivial to have SLAAC and DHCPv6 be independent from each other.


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

Practicality aside (which is not generally the case for certificates),
the issue is probably that people simply want to "port" what they do in
IPv4 to IPv6.



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

Last time I checked, that simply meant that SeND falls back to ND: i.e.,
if you don't implement SeND, you use ND.

But I don't follow what the argument is here...


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

... and NATs will disappear with IPv6, and there will be increased use
of IPsec as a result of IPv6 end-to-end'ness, etc.

Jokes aside, we have been hearing theories (myths) of how great the
world is going to turn out. Let's just "downgrade" to a humble goal of
"longer addresses, with parity of features with IPv4".


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

Nobody said "trusted". We're just talking about how a number of
potential attacks can be mitigated. Basically, how to prevent trivial
DoS/MITM attacks.

Also, note that even if you have authentication at the link/internet
layers, you usually still need authentication at the user/app level,
which belongs way above the protocol stack.

For instance, SeND doesn't help much while the DNS is still mostly
insecure. Rather than bothering with ND spoofing or RA sppofing, an
attacker could simply spoof DNS responses. -- i.e., the usual "the
strength of a chain is that of its weakest link".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492