[ipv6hackers] IPv6 security (slides and training)

[Carlos Martinez-Cagnazzo]

// rant alert :-)

I sometimes wonder about all this perceived risks/vulns affecting
IPv6. There were *a lot* of similar vulns in IPv4 back in the time.
You could remotely crash a host with a single command (ping-of-death
anyone? that was really fun :-) ), yet luckily no one at the time
thought that postponing Internet deployment indefinitely until all
IPv4 and network related bugs were patched was a viable alternative.
We patched vulns and moved on, waiting for the next one.

Now, on the other hand, we seem to feel that dying the slow death of
CGN is a preferable alternative to deploying IPv6 (with its bugs and
all). When did we as a community became so risk-averse ?

I had a very heated argument some time ago with one person that said
that deploying IPv6 was an unacceptable proposition to him because
some ICMP messages had to be let through filters. The mentality of
"security tramples everything, no matter what" is doing more harm than
good to the whole Internet ecosystem.

Security measures are almost always recommended without proper risk
assessments and without evaluating the real adversaries and the actual
threats a site faces. ICMP filtering seems now to be written in stone
for some folk. In said argument, I was called "crazy" because my linux
home server was pingable over v4 and v6. Yet I can happily say that in
10 years I have had only one compromise (related to the infamous
rpc-statd bug in RedHat 6)

Sure, if your adversary is the Chinese government, or the FBI, you
must be extra-careful. Sure, maybe you should not IPv6-enable your
nuclear plant just yet, our your air-traffic control system. But
c'mon, how really critical are 99% of networks out there? Regardless
how paranoid we feel, neither of those adversaries are coming after
99% of people anytime soon. I'm more scared of phishers and banking
trojans and DNS poisoning, really. And those have nothing to do with
IPv6.

I do believe that research into IPv6 bugs is valuable, and that effort
must be put into fixing all issues, but on the other hand I believe
that the actual risk for a large percentage of users is being
magnified and is much lower than the risk they face from other
threats. The actual harm done by NOT deploying IPv6 in the name of
security will be far worse in the long term for the very people we
claim we want to protect.

If you kept reading this far, I owe you a beer. Make me remember next
time we meet ;)

Carlos

On Wed, Nov 9, 2011 at 8:53 PM, Fernando Gont <fgont at si6networks.com> wrote:
> 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
>
>
>
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers
>



-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://cagnazzo.name
=========================