[ipv6hackers] IPv6 security (slides and training)

[Fernando Gont]

On 11/09/2011 02:06 PM, Owen DeLong wrote:

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

I should have said "widely deployed/widely used" (and the answer is
obviously "no").



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

I fully agree with Geoff regarding this point (fwiw, the guys at AMS-IX
and DEC-IX seem to agree, too).



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

Have you done any actual hacking with these issues? Because I have, and
it's pretty trivial to DoS any vulnerable host connected to the local
network. The effect of scanning attacks on the Neighbor Cache are also real.

I believe it is pretty unfair (non-serious, actually) to blame IPv6
security research for the lack of IPv6 deployment.

Rather than blaming the people researching vulnerabilities, please blame
vendors who sit on their a**es for wait too long without implementing
fixes for them.

Also, as noted on slide 6 of my slideware, what *has* had a negative
impact are all these myths (whether "traffic numbers", security
properties, or whatever) that have been build up (probably in the hopes
that that would help v6 deployment).


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

The risks the security community talks about are *security* risks. The
risks you're referring to are mostly business/economic risks, or
whatever you want to call them.


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

You're taking that statement our of context.

In a critical network, yes: "don't run X unless you absolutely have to"
(whether "X" is IPv6 or anything else).

In other networks, the analysis can be different. For example, we run
IPv6 at www.si6networks.com, even when we "don't have to".


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

What do you mean by "optimistic IPsec usage"? FWIW, I don't see the
increased IPsec usage you're referring to.


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

You'll probably have to do at least part of this to get IPv6 runnung,
anyway.


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

Agreed. But who was arguing about filtering IPsec?


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

That's "out of scope" for my presentation -- I cannot be blamed for what
people may misunderstand and possibly repeat.



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

Privacy/temporary addresses don't help this "event correlation", I
should say.



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

There are not going to be many improvements unless people stop making up
numbers and properties, and do more hacking.

Those being blamed for discussing security issues are the ones trying to
get vendors patch their implementations.



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

We have yet another generation that doesn't understand that NAT devices
provide (security-wise) the same functionality as a stateful firewall
that only allows return traffic.



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

+1



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

Could you clarify what are the risks that you're referring to for such
networks?


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

Unfortunately, users in Asia will have to find their way to access
IPv4-only systems, since most of them are not IPv4-enabled.

Not that I like it, but... that doesn't make "truth" go away.

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