[ipv6hackers] IPv6 security (slides and training)

[Douglas Otis]

On 11/9/11 5:49 PM, Fernando Gont wrote:
>  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.
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.  
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.

> > 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.  iCloud also offers 
Kerberos and secures mDNS.  These two IPv6 based strategies offers 
protection within _any_ environment even before a user logs on.  Such 
security improvements seem worth mentioning, especially when the 
approach also mitigates many of your expressed concerns.

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

References were provided that were seemingly disregarded.

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

This removes dependence on middlebox security.  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.  The goal of the access 
firewall seems better aimed at protecting resources.

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

Agreed.  The pervasive number of compromised hosts within a firewalled 
network suggest an urgent need to reconsider the firewall paradigm.  
Neither IPv4 or IPv6 offer secure local networks since IP addressing 
remains easily spoofed.  The role of the middlebox needs to be 
deprecated, especially as the Internet HTTP content shrinks and becomes 
more diverse.

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

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

IPv6 and cryptographic base security is being used, and absent viable 
alternatives, this affords an opportunity to prepare for an Internet 
containing a quadrillion networks.

Perhaps that can be done by leveraging existing services and conventions 
such as Kerberos, APL RRsets, and DANE. :^)

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

For the Internet to continue to support current demands, a different 
strategy is required.  One that places fewer demands upon local network 
security.

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

Not surprising, when not considering the role designers of IPv6 placed 
in the use of IPsec or its equivalent.

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

> >>> 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 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, truly secure local networks when desired, and importantly 
establish unique Security Associations.   IPv4 often has difficulty at 
establishing a functioning IP address. :^(

> >>> 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! ;-)

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.

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


-Doug