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

[Douglas Otis]

On 9/27/11 8:53 PM, Fernando Gont wrote:

Hi Fernando,
> 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"?
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

On June 6, 2011 Hiroki Sato commits 
RFC6106<http://www.rfc-editor.org/rfc/rfc6106.txt> "IPv6 Router 
Advertisement Options for DNS Configuration" (RDNSS and DNSSL) support 
reported here:
http://www.freebsd.org/ipv6/

I waited to see if could dig deeper, but Trend is in the middle of 
moving our team's servers while also rearranging firewalls.  Presently I 
have lost access to my servers and I have found our firewall now 
prevents access to the FreeBSD repository. :^(
>>>>    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).
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.
> 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.  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?
>> 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.

The goal should be something safer than what is currently found with IPv4.
>>> 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...
The certificate supported by the server can signal whether they have 
been authorized to send RAs, and it provides a means to secure the 
content of the announcement.  Again, this could be a user space option 
checking critical assignments.  There an App for that. ;^)
>> 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".
End-to-end security should not be considered a joke, nor does IPv6 or 
end-to-end security require use of IPsec or additional NATs.  The 
current state of IPv4 security is not good, nor is anything achieved 
pretending DHCPv4 is the equivalent of DHCPv6.  While DHCPv6 may play a 
suitable role with public facing servers, benefits for other uses 
diminish, where this scheme may also allow wide spread security failures.
>> 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".
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.

-Doug