[ipv6hackers] IPv6 security (slides and training)

[Fernando Gont]

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


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


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



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

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


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


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

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



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

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


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



>> > Deploying enhanced security allows avoidance of dangerous
>> > assumptions. This avoidance is best done using IPv6 within security
>> > associations (at the least). Whether network information is
>> > carried over native IPv4 or IPv6 is secondary and this represents a
>> > path forward.
>>
>>  I read paragraphs and paragraphs. But nothing of this fixes all the
>>  crappy software that you're running, which is where most of the
>>  problems are.
> 
> For the Internet to continue to support current demands, a different
> strategy is required.  One that places fewer demands upon local network
> security.

What are the big problems that you're expecting to tackle?



>> > Exactly. Since local networks and firewalls can not be presumed
>> > secure, IPv6 is needed, just not always as the native transport.
>>
>>  huh? The satement "Since local networks and firewalls can not be
>>  presumed secure, IPv6 is needed" looks totally random to me.
> 
> Not surprising, when not considering the role designers of IPv6 placed
> in the use of IPsec or its equivalent.

Your argument is essentially that every security problem is solved by
IPsec, or the problem doesn't exist. -- I couldn't disagree more with that.



>>  Can we get to concrete stuff? -- Because these are the sort of
>>  statements that make bold claims without any backing...
> 
> Deployment of iCloud or DirectAccess supports these claims, and this is
> just the beginning of new and required paradigm changes.

If anything, that would be increased use of IPsec. Again: what's the big
problems that you're trying to tackle?




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


> truly secure local networks when desired, and importantly
> establish unique Security Associations.   

Use IPsec over UDP.



>>  I don't think the architecture of local networks will change.
>>  REgarding SeND: Good luck! ;-)
> 
> Local networks have already changed.  IPv6 should be preferred over that
> of tunnels or translators.  Secondly, SeND will find a home within ultra
> secure environments where IPv4 elimination seems destine.

What does this have to do with a change in the architecture?

DO you expect, e.g., hosts in a home network to be globally reachable?
Do you expect firewalls to be removed from the edge of enterprise networks?



>> > Clearly, IPv6 offers more secure deployment techniques over what
>> > is possible with IPv4.
>>
>>  Again, bold claims, without much backing,
> 
> The claims being made about IPv4 somehow offering better security in
> conjunction with a slew of middleboxes also seems ill founded. 

Fully agreed. I never made such argument.



> ALG
> extensions functioning at each can not be trusted.  There is an
> underground industry operating within the shadow of these devices, such
> as siphoning accounts when domains of financial institutions are observed.

?? Could you please elaborate?

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