[ipv6hackers] IPv6 security (slides and training)

Fernando Gont fgont at si6networks.com
Wed Nov 9 08:18:30 CET 2011


On 11/09/2011 12:12 AM, Douglas Otis wrote:
>>  Address exhaustion is a real problem, and the only solution on the
>>  table is IPv6. That's the reason to deploy it. -- And my presentation
>>  didn't argue against that.
> 
> Your presentation makes dismissive statements regarding IPv6 deployment.

Are you arguing that there's lots of IPv6 traffic, and that IPv6 is
widely deployed?



> Page 5 "(current estimations are that IPv6 traffic is less than 1% of
> total traffic)"
> 
> This estimation is problematic and ignores massive growth in actual IPv6
> deployment.  

If that was the case, we wouldn't be having this argument in the first
place. :-)

However, the numbers are simply indicative... i.e., "we're far from
where we'd like to be". That's it.



> IPsec obstacles are also overblown and fail to envision superior
> deployments currently in use that do not depend upon end-to-end
> connectivity.  

Not sure what you mean. Are you expecting increased IPsec use? If so,
why, and how?



> Page 20 concludes by suggesting protection is provided by
> stateful firewalls where end-to-end protections are either not
> available, increases host exposure, or is not desired for production.

Good look with having people open their networks.

For instance, the IETF standardized home routers to behave this way
(stateful firewall ("on" by default) that only allows return traffic),
and I'm told this is what e.g. Comcast is deploying.



> Yikes.  The conclusion on Page 26 is simply wrong because it assumes
> hosts are not supported by security services that could even be located
> within the cloud.

Not sure what you mean. Could you please elaborate?


> Your presentation also overlooks the value IPv6 offers at providing
> better security when dealing with NATs. It seems you see no value in
> technology that has been deployed for many years providing the basis for
> much of today's secure communications.

huh? Please elaborate. -- I don't understand what you mean...



> For example, Apple's ability to navigate safely beyond NATs depends upon
> Security Associations based upon the IPv6 address held by the host. 
> Terminating security at the NAT (making an unlikely assumption that the
> NAT is able) exposes sessions to questionable security at the NAT and
> that maintained in the presence of wireless networks. 

You won't necessarily "navigate safely" even with crypto in place. They
do not fix malware, low-quality OSes/apps, etc.


> The use of IPv6
> can easily extend security to the host, even when traversing a NAT in a
> manner that also supports access point mobility.

There's IPsec over UDP, BTW...



> For example, Apple places IPv6 ULA in the destination field of IPsec
> Security Associations to ensure the end-to-end path between hosts are
> fully protected.  These Security Associations also survive network
> changes since the IPv6 ULA remains the same even when a host changes
> location. 

ULAs are not publicly routeable.... Do they do all this just for local
communication??



> When IPv6 is combined with secure services (not even necessarily present
> within the local network), security becomes much better than what is
> possible using IPv4 with an OS that by default does not open
> non-security related ports.

Again, I don't really understand what you mean. Please elaborate...



>>  Again, I do not necessarily advocate that. However, there are some
>>  scenarios (defense networks, for example) in which you don't won't
>>  to deploy IPv6 unless you really need it.
> 
> This is where we disagree.  I have seen government defense networks leak
> IPv6 traffic due to internally compromised systems.  

I'm talking about operations networks, in which you don't put additional
stuff unless you really need it.



> IPv6 deployed
> properly can improve security over what is possible using IPv4. 

Can you please elaborate? All these claims of improved security without
any rationale don't make much sense.

That aside, I'd argue that many IPv6 implementations are hitting the
same sort of problems that v4 implementations hit many years ago.

So... Yes, it's great to deploy v6 for the general case (for instance
'dig www.si6networks.com aaaa'). But you don't want a critical network
to be hacked just because you thought deploying v6 was cool, but didn't
care about or consider the implications.


> Clinging to IPv4 is not the safe path forward.

I do not advocate sticking to IPv4 for a general user that wants to
browse the web or the like (that'd be non-sensical). But it's equally
non-sensical to deploy immature implementations on critical networks.



>> > IPsec is not the only way to implement end-to-end security.
>>  Not only that. In some cases it may be undesirable, or may not
>>  provide what you want (e.g., you may want to authenticate a user,
>>  rather than the end-point itself).
> 
> Exactly.  Read RFC6281.  The IPv6 packet is wrapped by the UDP header
> and encrypted by ESP having an IPv6 destination.  This safely navigates
> the perils found in either home, corporate, or military configurations.

Where's the "user" in all that?



>> > Security related assumptions premised on use of IPv4 must be
>> > questioned, just as they should be for IPv6. As a general rule, no
>> > OS unable to properly handle IPv6 should be used.
>>  Under your general rule, people should probably use only OpenBSD.
> 
> Most modern BSD derivations should prove satisfactory,

Have you heard about "assumptions being the mother of all f* ups"? :-)

If you have done some IPv6 hacking, you know that your statement is not
true.

I can probably publicly comment on some findings, and I'm sure Marc
Heuse could comment on others....


> perhaps needing a few minor tweaks. :^)

You probably meant "patches".

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






More information about the Ipv6hackers mailing list