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

[Fernando Gont]

On 09/30/2011 06:45 PM, Douglas Otis wrote:
>>> 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"?
> This change applies to version 8 and 9 from what I read.
> http://lists.freebsd.org/pipermail/freebsd-net/2011-June/029070.html
> http://svnweb.freebsd.org/base?view=revision&revision=222732

Have you actually tried it? -- IIRC, there are userspace apps in Linux
and/or FreeBSD to process RDNSS... but they are not part of the
userspace app that process RAs for other autoconf issues.


>> 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).
> 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 may not identify
> a host in a meaningful way by of the DUID.

Still don't understand what you mean.


>> 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.
> From a security standpoint, deploying unique certificates on each host
> represents a fundamental step not solved by DHCPv6. 

Who's arguing against that? -- There are lots of things that could be
great from a security standpoint. However... how many of them are
doable? How many of them are deployable?

I don't understand why you keep pushing in the direction of "if we
deployed X, that would be an improvement", when the argument being made
is that those technologies are not actually easy to deploy.


> Since any
> deployment must still permit self assigned link-local addresses, and all
> DHCPv6 assigned addresses must still be checked for duplicates using
> multicast groups, what benefit is there in using DHCPv6 with perhaps an
> exception for public servers?

For starters, it follows our current practices with IPv4... and makes
current experience gained with IPv4 "portable" to IPv6.



>>> 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.
> There is no reason public portions of certificates couldn't be collected
> within DNSSEC as an alternative to a CA as a trust anchor.  Even for an
> OS that doesn't currently implement SeND, Java code in user space could
> be used as a stop-gap alternative.

Lots of cool things can be done on paper.



>> 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".
> Which is why DNSSEC+(DANE) and SeND can work together at creating
> cohesive and practical network security.  Let's not wait for the
> headlines to get worse.

Good luck with deploying it.

Seriously: 99% claims related with IPv6 security and functionality need
a reality check. And they actually hurt IPv6 deployment: they create
expectations that will not be fulfilled, and will thus lead to frustration.

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