[ipv6hackers] IPv6 security presentation at Hack.lu 2011

[Fernando Gont]

On 09/27/2011 08:46 PM, Douglas Otis wrote:
>>  That depends on what you mean by "simplify", or *what* (specifically)
>>  you want to simplify. e.g., DHCPv6 makes logging trivial. However,
>>  SLAAC+Privacy Extensions makes it rather difficult (at least with
>>  publicly available tools).
> 
> Cramming a growing list of options into DHCP packets has always stifled
> innovation.  

Innovation has been stifled by lack of ideas and protocol religion more
than by anything else.


> Security obtained by injecting options into DHCP then
> picked up via snooping is not without issues.  

Note sure what you mean.



> This approach is neither
> ideal or the simpler option.  Especially when DHCP can no longer be
> relied upon as being relied upon.  Some systems may ignore RA
> recommendations for stateful Address configuration, especial for devices
> that do not support DHCPv6.

I'm just arguing that it looks pretty dumb to have to different autoconf
methods that, at the end of the day, require support of the other --
yes, specification of RDNSS improves this on the SLAAC side, but...
specifying this after (almost) 10 years of RFC 2461 (now obsoleted by
RFC 4861) seems to be a hint that we should have done better.


>> > RFC5006 introduced RDNSS in 2007, and was upgraded to standards
>> > track in 2010 where DNS Search Lists (DNSSL) option was also
>> > included. It should also be noted a large IPv6 provider's CPE
>> > supported the RDNSS option for years with their 6RD deployment.
>>
>>  Last time I checked (1-2 years ago), neither Windows, nor any of the
>>  open source OSes I was using supported RDNSS by default.
> 
> Check again:
> 
> Cisco IOS, Fedora, HP-UX, iOS, OS X, MeeGo, Red Hat, Suse, Ubuntu, and
> even FreeBSD (as of June 6) support RDNSS, as does Apple routers,
> FreeBox, OpenWRT, etc.

I will recheck Ubuntu and FreeBSD, but... do you mean this support is
"on" by default? i.e., do these implementations that ship with SLAAC
support "on by default" also have support for RDNSS "on by default"?



>> > Real LAN based security remains possible with SeND,
>>  ... if only one could deploy it for the general case.
> 
> Again, SeND does not require support by all devices.  At least
> deployment at the switch and router by either Cisco or Juniper offers
> protection for an important portion of the infrastructure.  

Not sure what you mean. Say I have a local network, and want to protect
my network from ND spoofing and RA spoofing attacks, but hosts do not
support SeND. How do envision a scenario in which I'd benefit from SeND?


> Such use
> also provides OS independent meansto identify rogue routers using Java
> based SeND lite. :^)

:^)

With the current specs, that's probably as difficult as mitigating other
ND attacks.



> How is security improved by allowing Windows or OS X to set standards at
> the lowest denominator? 

Short answer: security improves in the same way it improves when we
produce standards that nobody implements and/or nobody deploys.

Another one could be:
Reality is... real. Even if you/me don't like that some vendor of set of
vendors don't implement this or that standard, from the pov of a
security guy that still means that something needs to be done to
mitigate existing vulnerabilities.

Some cynical might add:
How is security improved (in the first place) if one decides to opt for
vendors with questionable security-wise decisions or practices?

("practices" embracing anything from how they manage to vulnerabilities,
to which security features they decide to implement, or even whether the
source is publicly available or not....)

(And please note that I'm not referring to any particular vendor... but
rather pointing out that if one means to be really bold, then more
questions need to be asked (and probably first))



> Be bold.  Parity with IPv4 is not good enough.

Probably. But... "96 more bits, no magic" is probably not good enough,
either (particularly after 25+ years of IPv4). However, at some point
one needs to be pragmatic: We'd all like some supercool protocol that
implements lots of supercool features and that is easy to transition to.
We don't have such a thing, and we need more addresses... hence we
deploy IPv6.

In the same way, we'd all like lots of cool security features that
everybody supports, and that are so easy to deploy and use. But we don't
have such thing, either. Hence we hope that, at the very least, we'll be
able to migrate our IPv4 techniques to IPv6 (which, at least, comes with
lots of years of experience).

That's probably what "engineering" is about.

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