[ipv6hackers] IPv6 security (slides and training)

[Owen DeLong]

On Nov 8, 2011, at 11:18 PM, Fernando Gont wrote:

> 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?
> 
Depends on your definition of "widely". We run IPv6 on three continents
with more tens of thousands of end sites served. While it's not yet
ubiquitous, I would say that an argument can be made for "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. :-)
> 

Claiming that IPv6 is less than 1% really depends on where you are
looking from. Certainly there are many parts of the internet (including
some major backbones) where it is more.

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

I agree that we're far from where we'd like to be. I also think that some
of the security fear-mongering about some of the more esoteric
(read non-issue/easily mitigated in most scenarios) issues like
ping-pong (router bug solved by most vendors already) and
neighbor exhaustion attacks (unlikely to provide enough value to
the attacker and unlikely to actually deny service on most
networks likely to be vulnerable) is not helping the situation.

I'm not saying that these issues don't need to get addressed, but, I
am saying that the security community tends to look at security
to the exclusion of all else and often fails to communicate
risk analysis in a manner that provides a clear idea of the level
of risk in context of the other risks such as the risks of utterly
failing to deploy IPv6 in a given environment.

Statements like "don't run IPv6 unless you absolutely have to",
for example, are very counterproductive.

> 
> 
>> 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?
> 

I already see increased IPsec use on IPv6 due to built-in optimistic
IPsec usage by a couple of major applications (Back2MyMac,
M$ DirectConnect).

> 
> 
>> 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.
> 

I agree. A default closed stateful firewall is a good starting point
for any network. Opening only those services which are intended
remains desirable, no matter how good the end-host protections
become.

>> 
>> 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...
> 

Yes, but one of the major advantages to IPv6 with IPsec is that you can
do IPsec directly in the packet header rather than having to hack up
a tunnel, reduce MTUs accordingly, etc. If you don't allow IPv6 native
IPsec end-to-end to function where it is desirable, then, you are doing
your network and your users a disservice. Especially if it's a situation
where you allow it over UDP.

> 
> 
>> 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??
> 

They use ULAs for the tunnel address so that the tunnel can't accidentally
get routed to the global internet. They build an SA pair and number the two
ends of the SA pair (one SA in each direction) from ULA.

>>> 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.
> 

The problem is that's not what your statement conveys and the subtlety
is lost in the soundbite where what gets translated and more widely
repeated becomes "don't deploy IPv6 unless you really need it".

This is utterly counterproductive and doesn't help security.

>> 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.
> 

For one thing, end-to-end addressing means that your audit trails and
attempts at event correlation are much better. This alone is a major
boon to security according to most of the security professionals I've
discussed the topic with.

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

Yes, IPv6 is a 20 year old protocol that the IETF decided was done
and then let sit on the shelf while IPv4 advanced. We're going to be
playing catch-up on that for a little while as IPv6 gets deployed. This
is the price we pay for being so utterly inattentive to this issue as an
industry pretending that NAT was our salvation for so long.

Now, we've got some baggage from our earlier mis-steps:

	1.	We've got an entire generation of enterprise administrators
		that don't understand that RFC-1918 and NAT doe not
		provide security, they just provide address conservation
		and obfuscation.

	2.	We didn't deploy IPv6 while we still had enough IPv4 to make
		the transition relatively painless, so, now we're going through
		a much more painful transition and some people are still
		in denial about whether IPv6 is even necessary.

	3.	Auditors and certain standards organizations have deployed
		standards documents that contain the utter and complete
		misunderstanding expressed in item 1 above. (The PCI
		requirement for NAT (or equivalent control) for example).

> 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.
> 

One should always carefully consider the implications of any action taken
on a critical network. Deploying IPv6 is no exception. However, the
simple reality is that failing to deploy IPv6 even on those critical networks
also comes with a set of risks and these risks should all be evaluated
together in context to provide a complete risk assessment picture.

> 
>> 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.
> 

Again, this depends a lot on the context of the critical network. For
example, if part of what is critical to you is to communicate with
users in Asia, then, very likely you risk disconnecting critical users
if you fail to deploy IPv6.

Owen