Is IPv6 more Secure than IPv4? Or Less?

Scott Hogg recently (in his post “Holding IPv6 Neighbor Discovery to a Higher Standard of Security“) gave the following answer:

“The security of IPv4 is roughly equivalent to IPv6. So why do we expect more from IPv6?”

While I highly value Scott’s IPv6 expertise – not least because I learned a lot about IPv6 security from the book on the topic he wrote together with Eric Vyncke – I strongly disagree with his statement, mainly with the first part. In this post I will lay out why I think that IPv6 is actually less secure than IPv4.

For this purpose I’d like to reflect on what contributes to a protocol’s security (namely in real-life deployments) and then analyze these individual contributions from an IPv6 perspective, compared to IPv4.

So what does actually contribute some $PROTOCOL’s “security”? The following aspects come to mind:

• $PROTOCOL’s properties, not only security-related ones (“is there an authentication option?”) but also “generic” properties like the protocol’s overall complexity or its dependence/interaction with other protocols.
• the protocol’s “attack surface” or – given security is not just about protection from “attacks” – let’s say “incident exposure” which includes the potential for a broader range of security violations like misconfigurations leading to network downtime etc. Here one can take a look at the current level/state of implementations, too.
• the overall state of security controls suited to “protect from attacks/incidents related to $PROTOCOL”. This encompasses feature availability (“can we use this [type of] control [in our environment]?”), feature effectiveness (“does it really protect?”), feature maturity (“does it work reliably?”) and, of course, operational feasibility (“can the feature be deployed with reasonable operational effort?”).
• experience of operators with both the protocol and the security controls available (the stuff from the latter section). Always keep in mind that “operations is key”. If there’s one thing I’ve learned in 15+ years doing “network security assessments” of different types it’s the fact that, in a given environment, the maturity of operational processes as for security controls  is the main element determining the environment’s actual security posture at the end of the day.

So, now let’s have a look at those areas with regard to IPv6 and let’s compare it to IPv4 at the same moment.

Protocol Properties

Overall IPv6 can be considered much more complex than IPv4 and there’s more “helper protocols” involved which have their own security issues (like MLD). In case it’s not clear why complexity might be bad for a protocol’s resilience you might (re-) read RFC 3439.
Another main difference we’ve discussed extensively before is the inclusion of extension headers, a concept mostly unknown to IPv4. They make parsing an IPv6 packet much more difficult (than IPv4 packets) which in the end of the day means that “black list type of security controls” (like IDPS systems, Infrastructure ACLs or FHS controls like DHCPv6 Guard) have a hard time to work properly (see also discussion below).

As they say a picture is worth a thousand words here’a slide from the talk on IDPS evasion that Antonios and I gave at last year’s Black Hat US:

This (hopefully clearly 😉 ) illustrates what can go wrong when parsing IPv6 packets with extension headers.

Attack Surface/Incident Exposure

Clearly IPv6’s attack surface (on the local link) is much bigger than IPv4’s, for several reasons:

• new functionalities. In IPv4 there was no (btw: unauthenticated by default) configuration provisioning from routers to hosts. This in itself, as is widely known, provides quite ample attack surface.
• there’s a higher number of (“helper”) protocols involved.
• these protocols have much more bells & whistles. Just have a look at all those flags and options within (did I already state: unauthenticated by default) router advertisements and you’ll get an idea what I mean here.

While not the fault of the protocol itself it’s still noteworthy that there’s a number of sophisticated attack tools out there (allowing to attack all these specific options) like Marc Heuse’s comprehensive THC-IPv6 Attack Toolkit, the SI6 IPv6 Toolkit by Fernando Gont and Antonios’ awesome Chiron (see also this post).

Additionally, on the implementation side, there’s some more things worth to mention:

• The IPv6 stack (kernel) might not behave as expected in specific cases/scenarios. See for example our post “Should IPv6 Packets With Source Address ::1 Be Processed When Received on an External Interface?“, based on the clever exploitation of ntpd vulnerabilities described here. Apple just patched this behavior in OS X 10.10.3 some weeks ago (CVE-2015-1104).
• OS support of the (August 2013 published) RFC 6980 – which would be very helpful from a network security perspective – is still lacking, except for Linux which has the “suppress_frag_ndisc” sysctl which furthermore defaults to “the correct value” (“1” => discard fragmented neighbor discovery packets).
• And there’s the whole mess of OSs interpreting the specs “their own way” which again adds attack vectors/scenarios previously unknown in IPv4 space.

Availability & Maturity of Security Controls

Here let’s have a look at:

• First Hop Security (FHS)
• “Traditional” security controls incl. dedicated controls (like firewalls) and “bolted-on security features” (of generic use applications/tools).

As for FHS: while Scott is correct, that there’s already a variety of FHS features available, this pretty much only applies (in Cisco space) to physical, IOS based devices. There’s still significant gaps in Nexus/NX-OS land and, as Christopher laid out in his “IPv6 First Hop Security in Virtualized Environments” talk the (availability) situation is even worse when it comes to virtual switches.
Furthermore one of the most interesting – and heavily needed – features (the “undetermined-transport” ACL keyword) still has quite some teething problems. On the excellent Cisco FHS Wiki, thankfully maintained by Andrew Yourtchenko it’s stated, wrt to this one:
“Some platforms may not support acl keyword ‘undetermined-transport’. In that case they may either reject the command altogether, act erratically on such ACLs, or refuse to accept the ACL on the interface.”
We can confirm that the feature has severe issues ;-).

Overall, we consider the IPv6-related feature support of firewalls quite good in the interim, but you might still do performance testing as this talk from the “IPv6 Hackers” meeting at IETF87 shows.

An example of a “bolted-on” security control only serving IPv4 traffic but not IPv6 can be found in Johannes Weber’s blog.

Lack of Operational (Security) Experience or Maturity

In this space several potential deficiencies come to mind, like:

• ACLs being only applied to IPv4 traffic, not to IPv6.
• Hardening only done for IPv4 stuff, but not for IPv6 (due to simple lack of knowledge or due to lack of appropriate [hardening] scripts).
• Service configuration (e.g. listening only on specific addresses/interfaces) only applied to IPv4, but not for IPv6 (you know, on most interfaces there’s several addresses in IPv6…).

The recent Anonabox disaster is a nice example of hardening measures only being applied to the IPv4 configuration, but not to its IPv6 counterpart on the same system.
Furthermore we’re currently conducting a research project evaluating the (differences of) security settings on certain systems and we can already state that there are interesting results…
[slide #25 of this presentation on “Penetration Testing in the Age of IPv6” might give an idea what to expect].

Conclusions

I hope I could illustrate why the overall state of IPv6 security – quite unfortunately – is worse than IPv4 security. Some of the deficiencies discussed above (mainly the lack of proper feature availability and lack of operational experience/maturity) will decrease/disappear over time. Still as I laid out in my keynote ((“Why IPv6 Security Is So Hard“) to the Troopers IPv6 Security Summit 2014 some of these issues are deeply rooted in the IPv6 specs or the way how those are interpreted and worked on since many years. Hence some of those inherent problems will not go away easily or shortly.
Regular readers of this blog know that our goal is not to lament about the state of affairs but to provide advice how to appropriately secure stuff, which we actually do in a number of our IPv6 focused posts. Let me further state that we’re currently working on an “IPv6 Threat & Control Catalogue” which will be published right here in a few months.

If you want to discuss any of the above with Eric Vyncke or myself you can do so at the IPv6 Business Conference in Zurich in two weeks. Furthermore Christopher and I will give an extensive “IPv6 Attacks & Defence” training at 44CON in early September. Last but not least I’m preparing a series of webinars on “IPv6 Advanced Security” topics with Ivan Pepelnjak, to be found on his site soon (stay tuned for details).

We’re happy to receive any type of feedback or comments.
Everybody have a great week,

Enno