[ipv6hackers] IPv6 security (slides and training)

[Fernando Gont]

On 11/09/2011 09:56 PM, Douglas Otis wrote:
>> > Page 5 "(current estimations are that IPv6 traffic is less than 1%
>> > of total traffic)"
[....]
>>  However, the numbers are simply indicative... i.e., "we're far from
>>  where we'd like to be". That's it.
> 
> Why quote meaningless statistics?  Is this to suggest IPv6 is not
> important until it represents a significant share of overall traffic? 

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.



> Understanding the path forward should take precedence.  

My presentation was about IPv6 security, rather than about "action plan
for v6".


> Many are unknowingly using IPsec in various forms.  Whether for
> MicroCell towers or iCloud within highly diverse environments used by
> millions, often initially served by IPv4 where where IPsec and IPv6
> security associations play a critical role.  Whether or not there is
> native IPv6 access, IPv6 offers enhanced security over what is available
> in IPv4 only environments.  The market has already begun selecting
> products properly leveraging IPv6 benefits.

I don't buy the "enhanced security stuff", and I'm not sure what are the
"benefits" you're referring to.



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



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



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

That aside, there's lots of things that one could possibly imagine. The
point is how many of those will be really used in practice.


>> > Your presentation also overlooks the value IPv6 offers at
>> > providing better security when dealing with NATs. It seems you see
>> > no value in technology that has been deployed for many years
>> > providing the basis for much of today's secure communications.
>>
>>  huh? Please elaborate. -- I don't understand what you mean...
> 
> RFC6281 describes how Apple deployed security for services depending
> upon IPv6 (often through IPv4 access).  

I will go through the RFC and comment later.


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



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

Can we get to concrete stuff? -- Because these are the sort of
statements that make bold claims without any backing...



>> > 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.
> 
> 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 diffrent paradigm in
the addressing architecture of v6 vs that of v4???



>> > 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.
> 
> When something becomes ready for prime-time or is past its prime depends
> upon what is considered acceptable.  Technologies referenced in RFC6281
> have been deployed on a large scale for years having fewer problems than
> most alternatives.  There also doesn't seem be problems preventing
> moving this scheme forward.   I suspect the reluctance is due to
> strategic departure that the local networks can be assumed secure.  It
> seems time to admit local networks are not secure, and move on from
> there.  When local networks must be secure, only IPv6 offers a viable
> solution, SeND.

I don't think the architecture of local networks will change. REgarding
SeND: Good luck! ;-)



>> >>> Security related assumptions premised on use of IPv4 must be
>> >>> questioned, just as they should be for IPv6. As a general rule,
>> >>> no OS unable to properly handle IPv6 should be used.
>> >> Under your general rule, people should probably use only
>> >> OpenBSD.
>> >
>> > Most modern BSD derivations should prove satisfactory,
>>
>>  Have you heard about "assumptions being the mother of all f* ups"?
>>  :-)
>>
>>  If you have done some IPv6 hacking, you know that your statement is
>>  not true.
> 
> Clearly, IPv6 offers more secure deployment techniques over what is
> possible with IPv4.  

Again, blod claims, without much backing,

Thanks!

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