[ipv6hackers] IPv6 security (slides and training)

[Owen DeLong]

On Nov 22, 2011, at 6:14 PM, Fernando Gont wrote:

> Hi, Otis,
> 
> On 11/22/2011 09:13 PM, Douglas Otis wrote:
>>> The statistics are not meaningless, and I think they are part of a
>>> good overview of where we are wrt IPv6. e.g., somebody new to the
>>> protocol may wonder "is this being used today", etc., etc.
>> Fernando,
>> 
>> Owen made a good point by comparing IPv6/IPv4 to IP/IPX.  Measuring the
>> ratio of IP to that of IPX would have made little sense as well. 
> 
> Measuring traffic levels shows the amount of current traffic using that
> technology (IPv6 in this case). And it gives an idea of to what extent
> such protocol is used in the global Internet.
> 
> We may not like the numbers and wished something better... but that
> doesn't the data nonsensical...
> 
I didn't say that measuring IPv6 traffic levels was nonsensical or that it
was a bad thing to do. I did say and will continue to say that comparing
IPv6 traffic numbers as a percentage of current IPv4 traffic statistics is
absurd and meaningless. Comparing IPv6 statistics today to IPv6
statistics a year ago or 5 years ago is meaningful, as is comparing IPv4
statistics today to IPv4 statistics 1 or 5 years ago.

Comparing IPv6 statistics today to IPv4 statistics today is about as useful
as comparing IPv4 statistics today to IPX statistics today.

> 
>> Comparing IP to that of IPX would have overlooked the need to deal with
>> external routes.  This need shifted adoption to IP.  Comparing IPv6 to
>> that of IPv4, there is a need to deal with more than 3.8 billion
>> external unicast sources.  Announcement growth in IPv6, as measured in
>> /64 prefix equivalents, has been exponential even though adequate block
>> assignments allowed routing and network growth to remain fairly linear.
> 
> And? What we want is traffic, rather than announcements -- announcements
> are a side effect.
> 

Announcements are not a side effect, they are a precursor. Frankly, traffic
isn't what anyone looking at this rationally wants. Traffic is the side effect.
What we want is end-to-end capabilities. We want User A to be able to reach
website B over IPv6 for as many values of {A,B} as possible. That's what
we really want, isn't it?

Announcements are a big part of that.

Traffic, OTOH, is actually a side effect of not only having the capability, but,
of that capability getting used and preferred over any other parallel
capabilities. As we have seen from documents such as happy eyeballs,
etc., even where native IPv6 is possible, it may not be the ideal current
solution.

That's OK. It's far more important that it is an available solution than that
it be the ideal or chosen solution for any particular flow.

> 
>>>> Understanding the path forward should take precedence.
>>> My presentation was about IPv6 security, rather than about "action
>>> plan for v6".
>> 
>> The alternative of not exchanging IPv6 requires dynamic IPv4 exchanges
>> to begin with unknown entities.  In addition, establishing stable
>> security associations is readily achieved using existing code that
>> leverages IPv6 conventions. This type of strategy has been effective
>> for DirectAccess or iCloud, using IPv6 over IPsec. 
> 
> v6 doesn't change much with respect to IPsec deployment (when compared
> to the v4 case). Again, I don't think we'll see increased IPsec usage as
> a result of IPv6 deployment (in particular when it comes to global traffic).
> 

It actually does. I would argue that between M$ Direct Connect and iCloud,
B2MM and MobileMe, there are probably already more IPSEC SAs on
IPv6 than on IPv4 today. Most of the people using these SAs don't even
know they are doing so. When was the last time you saw opportunistic
IPSEC in IPv4? Never? Thought so.

> 
> 
>>> I don't buy the "enhanced security stuff", and I'm not sure what are
>>> the "benefits" you're referring to.
>> 
>> References were provided that were seemingly disregarded.
> 
> You provided a link to a protocol used by APple, which aparently uses
> IPsec over IPv6. Can you provide a rationale for increased
> widely/globally-deployed IPsec usage?
> 

Apple has a lot of customers using iCloud, MobileMe, and B2MM
all over the world. Can you provide any reason that would not qualify
as widely, globally-deployed IPsec usage?

> And even then, that doesn't make a big deal in terms of security. That
> doesn't solve malware, etc.
> 

You can't solve a software problem at the protocol level. That's like trying
to solve drunk driving by eliminating push-button ignition systems in cars.
This statement is facially absurd.

> 
>>>> The general point is stateful firewalls offer poor security,
>>>> especially once malefactors control script at an internal host.
>>> 
>>> What good does IPsec'ed communication do in this same scenario? :-)
>> 
>> This removes dependence on middlebox security.  
> 
> I think you're missing the point. A firewall and IPsec serve different
> purposes.
> 

Yes and no. His point is that IPsec provides end-to-end privacy and
authenticity of datagrams. Combined with host level policy, it can,
in fact, eliminate the need for an intervening firewall. The firewall,
after all, is strictly a middle-box policy enforcement mechanism.
Moving policy enforcement to the edge, if it can be done in a practical
and sustainable manner, is actually an improvement.
> 
>> Nearly every corporate
>> network contains compromised systems.  As such, security must be
>> implemented at each host, rather than being placed at elaborate
>> firewalls where scaling becomes problematic.  
> 
> Huh? If the host is compromised, what does IPsec offer? IPsec'ed
> malicious traffic?
> 

If a host engages in more IPsec conversations and regards conversations
that are not IPsec with greater suspicion, then, the result is actually a
host that is less likely to be compromised, no?

> That's kind of "placebo security": You think that "everything is alright
> because you're using super-secure IPsec..." but it's not.
> 

I think you're putting words in his mouth here. IPsec isn't a panacea
any more than stateful inspection or any other security tool.

> 
> 
>>>> Sorry. That was not the point. Expectations a firewall offers
>>>> dependable security has allowed extremely poor practices to
>>>> persist. Advice being offered appears to advocate this expectation
>>>> continuation?
>>> 
>>> You cannot judge a device because of the expectations people may
>>> have about it. Judge it for its technical properties, and not for the
>>> related human idiocy!
>> 
>> Agreed.  The pervasive number of compromised hosts within a firewalled
>> network suggest an urgent need to reconsider the firewall paradigm. 
> 
> As much as the number of compromised certificates suggests a
> reconsideration of their use (just me being ironic).
> 

I would agree with both statements.

> That said, firewalls enforce packet filtering policies. They are usually
> of help to improve security. But that doesn't make compromises
> impossible (nothing does).
> 

Arguably better edge security and moving policy enforcement to the
edge systems would actually do more for improving security than firewalls
can, if that can be done in a useful and sustainable manner. Firewalls are
more convenient to administer because they provide a centralized choke
point for policy maintenance. If you don't have a mechanism for properly
verifying and maintaining edge system policies, then, edge system policies
are less effective than firewalls. If you do, then, firewalls are not all that
useful.

> 
>>>>>> 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?
>>>> 
>>>> Deploying "complex" systems necessary to boot-strap security need
>>>> not be located within local networks.
>>> 
>>> Then you lose network connectivity and... ?
>> 
>> When connectivity to the Internet has been lost, external risks are
>> reduced as well.  Secure methods can be used to access local systems
>> without external services being present.  For example, mDNS in
>> conjunction with ssh offers a fallback strategy.
> 
> IMO, this is nice for a theory book, but is far from practice.
> 

It works in my environment, so, I'm not sure why you say it is far from
practice.

>>>> Many methods are being used to exploit unprotected local networks,
>>>> some using ARP spoofing. For security to extend to each host, an
>>>> identifier is needed that can be coupled with a routing scheme.
>>>> IPv4 does not fulfill that role, however IPv6 offers that
>>>> capability.
>>> 
>>> huh? Can you explain where do you see a completely different paradigm
>>> in the addressing architecture of v6 vs that of v4???
>> 
>> Only IPv6 is able to eliminate a need for middleboxes such as Network
>> Address Translations, provide anonymity and security through privacy
>> extensions, 
> 
> Oh, c'mon... there are plenty of bibliography on the subject. Privacy
> extensions basically clear-up the bad idea of including MAC addresses in
> the INterface-IDs. -- That's it.
> 

First, I don't accept as postulate that it was a bad idea to use EUI-64 host
identifiers. I think that they are quite useful in a number of environments.
I would argue that privacy extensions are, in many environments a far
worse idea than EUI-64 addresses.

> 
>> truly secure local networks when desired, and importantly
>> establish unique Security Associations.   
> 
> Use IPsec over UDP.
> 

To what benefit over native IPSEC in IPv6?

> DO you expect, e.g., hosts in a home network to be globally reachable?

At least in some cases, yes. People want to be able to host games on their
XBoX 360, PS3, etc. People want to be able to run their own servers of various
forms, whether they realize they are servers or not.

Hosts in my home are already globally reachable on both IPv4 and IPv6.

> Do you expect firewalls to be removed from the edge of enterprise networks?
> 

I wouldn't expect this for some time because enterprises are notoriously behind
the times when it comes to security technologies and because many tend to be
sheep following whatever the auditors, so-called experts, and vendor-paid
consultants have told them is the best thing to buy. Since sales of firewall
hardware are lucrative, I expect strong lobbying against the idea of edge-host
based security models until the industry finds a better way to make that more
lucrative than firewall sales.

Owen