A few weeks ago Scott Hogg, one of the smartest persons around in the field of IPv6 security, published a post titled “7 points your security team needs to know about IPv6 (but probably doesn’t)“. He listed ‘IPv6 needs to be secured from the onset, not retroactively’ as one of those. Given my own security education started in the 90s where one (still) considered ‘hardening’ as an integral part of an overall security landscape ;-), this made me reflect on the potential properties or attributes of an IPv6 stack itself which one would label as ‘a secure one’. I mean it all starts with the stack, right? – so “from the onset” could mean exactly that: begin an IPv6 journey with sufficiently secure implementations, then take care of (security-wise) proper operational handling.
At that point the question ‘just’ is: what does a ‘secure’ IPv6 stack look like/incorporate? This is what I want to discuss in a informal manner in this post.
Code base & code quality
As the recent Ripple20 vulnerabilities have shown, the vulnerability surface of a specific TCP/IP stack can play a huge role for the security of devices using the respective stack. Subsequently it can make sense to look at the origins and the code base of an implementation, e.g. on the one hand the FreeBSD IPv6 stack (stemming from the KAME project) is usually considered a stable and secure one, but on the other hand this excellent technical report from 2018 (supervised by my friend Sergey Bratus) reviewed a number of vulnerabilities it had in earlier years.
Privacy properties of address generation approach
The privacy implications of the initial EUI-64 based SLAAC addresses have been discussed extensively in the past (btw there are some tidbits on the political dimensions of the choice of EUI-64 in Brian Carpenter’s book “Network Geeks. How They Built the Internet“). There was an article “Where’s All The Outrage About The IPv6 Privacy Threat?” already in 1999 (I could only find a version of it buried in this page, in the SixXS archives which are a nice resource anyway if you have an interest in the history of IPv6) and the first RFC on Privacy Extensions was published in 2001. Also this is a talk which Chris Werny and myself gave on the topic at the Heise IPv6 Kongress 2012.
In any case from today’s perspective it’s usually considered to be beneficial when a SLAAC generated address fulfills mainly two requirements:
- sufficiently privacy-preserving in the sense that an IID can not be tracked across different networks.
- some amount of ‘stability’ (read: the address does not change [very often]) as long as the respective interface stays in/with the same subnet/prefix.
Several address generation mechanisms which serve these objectives exist, namely the one described by Fernando Gont in RFC 7217 (but also Cryptographically Generated Addresses [CGAs] as of RFC 3972 can fulfill the above objectives).
By definition any implementation of the Internet Protocol can be expected to process input (read: packets) from many untrusted/untrustworthy communication partners 😉.
Still (at least) two questions come to mind here:
- how does an implementation handle input/packets which it has to process as part of its core functionality (like parsing the IP header, or processing NS/NA packets sent from other hosts on the local link)?
- which additional interactions (=> vulnerability surfaces) does an implementation offer?
The first question relates to the (secure) parsing capabilities of a stack (see the above section on code quality) and potentially also to limits of resources which can be consumed by an untrusted party sending legitimate packets (see the below section on limits on data structures). Let’s hence focus on the second question, and let me paraphrase it a bit: which additional IPv6 ‘subprotocols’ does an implementation bring and, more importantly, which of those are enabled/started by default? There’s three of those which deserve a bit of attention: MLD, DHCPv6 and mDNS.
I for one still think that the current practice of IPv6 stacks coming with MLD enabled by default goes back to a misunderstanding of section 7.2.1 of RFC 4861 where ambiguous language is used (‘is done’ can be prescriptive [‘normative’ as of IETF lingo] or descriptive), and that the vast majority of IPv6 stacks wouldn’t need MLD to function properly. From a security perspective MLD can be abused in many ways (see the ‘MLD Considered Harmful‘ presentation from the Troopers IPv6 Security Summit 2015), but one has to accept that pretty much all implementations come with MLD enabled (Antonios Atlasis mentioned OpenBSD as an exception in this post from 2014), not least as the MLD-related of the IPv6 Node Requirements RFC seems to imply that any use of multicast addresses (including link-local uses such as ff02::1 or the Solicited-Node Address as of RFC 4291 which is employed in the context of neighbor discovery) requires MLD. While I’d like to point out that generally MLD doesn’t make much sense for multicast communication on the local link (which is btw why quite a few implementations of MLD snooping explicitly do not process LL multicast groups), but the ‘let’s consider the usefulness of MLD’ ship has long sailed.
DHCPv6 could be another candidate for the ‘do we really need this at all/enabled by default?’ category as several DHCP (client) implementations have been vulnerable in the past (e.g. see CVE-2019-0547 or the very nice CVE 2018-1111 discovered by my former colleague Felix Wilhelm), but then again pretty much all current IPv6 implementations come with an enabled-by-default client-side DHCPv6 process.
The same applies to mDNS: even Microsoft IPv6 implementations have it since a while, (see this post) and RFC 8504 encourages its use in section 9 of the document. Wearing a security hat one might still be tempted to ask: “do we need this by default?”, especially when one has read the “An Attack-in-Depth Analysis of multicast DNS and DNS Service Discovery“ paper by Antonios).
Security properties of the stack
There’s a number of RFCs describing – I’m hesitant to write ‘mandating’ 😉 – security-oriented ways of handling IPv6 packets with specific properties, incl.
- RFC 6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
- RFC 7112 Implications of Oversized IPv6 Header Chains (which subsequently found its way into RFC 8200)
- RFC 8021 Generation of IPv6 Atomic Fragments Considered Harmful (also incorporated in RFC 8200)
With regard to our initial question one should clearly take those into account when it comes to evaluating an IPv6 stack’s overall security, but it can be quite difficult to find out for an individual stack (extensive testing as described here might be a good road…).
Limits on data structures
As laid out above, an IPv6 stack has to digest all types of input from untrusted sources. This can include quite complex packets (like router advertisements) which in turn can lead to memory- and/or computation-intensive processes on the local system. A properly secure(d) IPv6 stack should hence impose limits on certain data structures. Some of you might recall the “IPv6 readiness update” initially released by Microsoft in 2012, presumably as a response to RA flooding performed at the time with Marc Heuse‘s THC-IPV6 attack toolkit. In general data structures subject to similar restrictions can include:
- Neighbor cache entries, namely ‘incomplete’ ones (for some discussion see this post)
- IPv6 default routes
- SLAAC generated addresses based on the prefix information option (PIO) in RAs (also called ‘honored PIOs’).
(Additional) Security features
Following a wide-spread industry approach of bolting on security (features) to things-to-be-secured one might be tempted to cure inherent security weaknesses of IPv6 (such as the lack of security properties of router advertisements) by bringing in additional elements. Bonus points in this space are usually awarded for complex cryptography based stuff, like for example in the IPv6 realm SEcure Neighbor Discovery (SEND).
Still regular readers of my posts probably know that I do not necessarily share the opinion that additional lines of code always increase the security posture of a component 😉 (here: an IPv6 stack) , so I’m not sure if ‘supplementary security features’ make it to my list of a ‘secure IPv6 stack’. Happy to take suggestions from you, dear readers, here…
Finally the resources (time, skills, diversity etc.) spent on security assessments of the respective stack might obviously constitute a (main?) contributing factor to the overall security of an IPv6 stack. Evaluating the security of an individual implementation (c|sh)ould hence include finding out about those. For example from that angle one could look at the aforementioned IPv6 stack of BSD-derived systems and draw some conclusions (e.g. CVE-2019-5597 initially found in OpenBSD also affected FreeBSD and apparently even Solaris whereas CVE-2019-5608 doesn’t seem to affect other stacks from the BSD family, but ‘only’ components directly using FreeBSD, see for example this advisory. Also there has been some speculation if CVE-2020-1603 in Junos OS is related to the latter, or to CVE-2019-5611). In any case some research on security assessments of an individual IPv6 stack should be part of a ‘secure stack’ evaluation.
I hope the above provided some food for thought as for IPv6 security from the point of view of IPv6 stacks – I’m happy to receive any type of feedback, on any channel.
Thank you for reading so far! 😉