[ipv6hackers] IPv6 security (slides and training)

[Douglas Otis]

On 11/8/11 11:18 PM, Fernando Gont wrote:
>  On 11/09/2011 12:12 AM, Douglas Otis wrote:
> >> Address exhaustion is a real problem, and the only solution on
> >> the table is IPv6. That's the reason to deploy it. -- And my
> >> presentation didn't argue against that.
> >
> > Your presentation makes dismissive statements regarding IPv6
> > deployment.
>
>  Are you arguing that there's lots of IPv6 traffic, and that IPv6 is
>  widely deployed?

No.  v4/v6 traffic ratios provide poor metrics to assess internal 
deployment or the role IPv6 plays for reasons stated.

> > 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. :-)
>
>  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?  
Understanding the path forward should take precedence.  This path will 
need to leverage IPv6 associations whenever native IPv6 is not available 
for providing a seamless transition.

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

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.

> > 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.  Firewalls also 
make tradeoffs between performance and state tracking.  Better security 
is available when deployed in conjunction with IPv6 along with Security 
Associations in conjunction with cryptographic verifications, such as 
IPsec whether or not these services are directly managed by IT.

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

> > 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.  For example, Transaction SIGnature 
(TSIG) to authenticate dynamic DNS updates by users, Kerberos 
certificates defending mDNS can all be done in the cloud.   An approach 
that applies to iCloud, MicroCells, etc.   This often leverages existing 
infrastructure in conjunction with IPsec and IPv6.  The extent of the 
advantage afforded security by IPv6 is not seen in IPv4/IPv6 traffic 
metrics.

> > 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).  Reasonable security does not 
expect unprotected services to be secure.  Additional steps are 
required.  Yes, networking becomes a bit more complex, but others can 
assist to the point where "it just works". :^)

> > For example, Apple's ability to navigate safely beyond NATs depends
> > upon Security Associations based upon the IPv6 address held by the
> > host. Terminating security at the NAT (making an unlikely
> > assumption that the NAT is able) exposes sessions to questionable
> > security at the NAT and that maintained in the presence of wireless
> > networks.
>  You won't necessarily "navigate safely" even with crypto in place.
>  They do not fix malware, low-quality OSes/apps, etc.

For systems to be secure, there must not a presumption local networks 
are secure!  Likewise, no trust can be placed in specific IP addresses 
nor in externally initiated services.  Paranoia of the local network 
improves security within an office, and equally from a coffee shop's 
open WiFi.  Rather than maximizing up time, corporations worry more 
about data integrity.  Integrity is assured by avoiding dangerous 
assumptions.  Such as not assuming DHCP assigned resources are secure or 
recursive DNS is trustworthy.  IPv6 tools should only be need to resolve 
systematic issues caused by misbehaving hosts.  Beyond possible 
interruption, security should not be affected.  Clearly, ISPs care more 
about maximizing up time, which stresses an ability to monitor network 
activity.

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.

> > 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...
> > For example, Apple places IPv6 ULA in the destination field of
> > IPsec Security Associations to ensure the end-to-end path between
> > hosts are fully protected. These Security Associations also
> > survive network changes since the IPv6 ULA remains the same even
> > when a host changes location.
>
>  ULAs are not publicly routeable.... Do they do all this just for
>  local communication??

This provides a host identifier that extends beyond any host TCP 
connection or Security Association (one that can change at reboot).

> > When IPv6 is combined with secure services (not even necessarily
> > present within the local network), security becomes much better
> > than what is possible using IPv4 with an OS that by default does
> > not open non-security related ports.
>
>  Again, I don't really understand what you mean. Please elaborate...

Secure DNS updates, Kerberos, user accounts, IPsec, can all be managed 
within "the cloud" and not be dependent upon local IT expertise.  Their 
NAT-PMP has also been incorporated into LSNs, since it better supports 
that environment while reporting external assignments.  uPNP expected 
user directed resource/duration assignments that are not practical with 
LSNs.

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

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

>  That aside, I'd argue that many IPv6 implementations are hitting the
>  same sort of problems that v4 implementations hit many years ago.
>
>  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.

There are issues needing to be addressed, without a doubt.  Even so, 
those issues do not justify disabling IPv6.

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

> >>> IPsec is not the only way to implement end-to-end security.
> >> Not only that. In some cases it may be undesirable, or may not
> >> provide what you want (e.g., you may want to authenticate a
> >> user, rather than the end-point itself).
> >
> > Exactly. Read RFC6281. The IPv6 packet is wrapped by the UDP
> > header and encrypted by ESP having an IPv6 destination. This
> > safely navigates the perils found in either home, corporate, or
> > military configurations.
>
>  Where's the "user" in all that?

The user account is accessed via a purchased device, the web using a 
generic device, to establish credentials often tied to a purchase or 
financial instruments.  Their password is used to create shared secrets 
validating host's DNS updates.  A TSIG RR is dynamically computed as an 
digest, used once and included as additional data within a response.  
These DNS messages are also protected by TLS to prevent eavesdropping.

> >>> 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.  The sky is not falling and many security issues are 
better handled using IPv6 when deployed in a responsible manner.  That 
might mean use of IPsec VPN, etc.  The normal and incorrect assumption 
made in respect to IPv4 is local networks are trustworthy because of 
some type of firewall has been deployed.  If you have done IPv4 hacking, 
you also know that is not true either.

>  I can probably publicly comment on some findings, and I'm sure Marc
>  Heuse could comment on others....

I am well aware of the issues and have been using IPv6 for several years.

> > perhaps needing a few minor tweaks. :^)
>
>  You probably meant "patches".

Small processes and configuration adjustments seem normal environmental 
adjustments.  As with any OS connecting to the Internets, expect an 
endless stream of patches.

-Doug