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

[Douglas Otis]

On 9/30/11 4:22 PM, Fernando Gont wrote:
> 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.
As soon as I can get a setup working.  From what I have seen, this 
modifies rtadvd and rtsold structures used in the kernel where the data 
collected is placed into resolv.conf by resolvconf script.  It also does 
not appear the changes updated the related documentation.
>>> 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.
See:
http://tools.ietf.org/html/draft-ietf-savi-framework-05

This framework lists methods to establish assignments (self or 
otherwise) of an IPv6 address.  DHCPv6 is one such method.  It also 
covers difficulties related with legacy switches.  Unlike IPv4, hosts 
are not required to obtain IP address from DHCPv6 servers.  With IPv6, 
even when DHCP support is announced in the RA, DHCPv6 use is still not 
required.  Such a requirement would interfere with more secure methods 
such as manual or SeND.  Whether an address is obtained via DHCPv6 or 
otherwise, immediate use is improper without DAD.  This is true even 
when when the address has been assigned by a DHCPv6 server.

Imagine monitoring 16.7 million mulicast groups.  As bad as that sounds, 
breaking big jobs into smaller pieces can tasks easier.  Even when 
DHCPv6 is used, subsequent exchanges may be difficult to associate with 
the relevant host.  Although the DUID is logged, there is no assurance 
the relevant host can be ascertained.   On the other hand, being able to 
log all DAD operations would, and not impose any specific assignment 
methods.  Even when a host uses DHCPv6, it must start with a 
self-assigned address checked using DAD and perhaps build upon things like:

http://ndpmon.sourceforge.net/

>>> 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?
Exactly.  Rather than advocating deployment of DHCPv6 as a solution, 
understand what it does not solve.  Is seems there should be doable 
strategies that provide more comprehensive anomaly coverage.
> 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.
A view of DHCPv6 as a singular IP address assignment method is unlikely 
to prevail and is building upon a flawed premise.  It is neither 
simpler, nor required.  For example, _ntp._udp.<dnssl> DNSSEC offers a 
more scalable and comprehensive method to extend services without 
imposing constrained parameters.

Here is a review of the security considerations regarding various 
methods that DNS might be used dynamically.
http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html

>> 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.
Well almost.  The big difference is avoidance of broadcast techniques 
replaced with 16.7 million multicast groups creating some issues with 
legacy switches.  Nor can DHCPv6 be considered comprehensive, as this 
leaves plenty of space for badness when only DHCPv6 logs are available.

This describes a practical MLD configuration for 6rd.
http://tools.ietf.org/html/draft-sarikaya-softwire-6rdmulticast-01

>>>> 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.
We are looking for some low hanging fruit still able fulfill requirements that avoid assumptions the LAN is secure.  We know it is not.

>>> 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.
Are you suggesting everyone use ISATAP?  It is not secure either 
although made easy to deploy?

Aren't you also troubled by the number of large organizations using 
compromised networks.  Easy to deploy and secure are not synonymous 
concepts.  Thank you for your time, and your practical insights.

-Doug