[ipv6hackers] IPv6 security (slides and training)
dotis at mail-abuse.org
Thu Nov 10 01:56:38 CET 2011
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
> > 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
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
> >> 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
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
> >>> 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.
More information about the Ipv6hackers