Chris and I will give a tutorial on the above topic at next week’s RIPE Meeting in Reykjavík. In this post (actually this will probably become a small series of posts) I’ll try to summarize some thoughts on IPv6 security in enterprise environments in 2019.
We’re going to cover three main areas:
- Why IPv6 Is Different, Security-wise
- Traffic Filtering in IPv6 Networks
- IPv6 Security in L2 Networks / First Hop Security et al.
Let’s start with the first item. In real-life scenarios the security of “a protocol” – IPv6 can rather be considered a “protocol family” which includes helper protocols like ICMPv6 and MLD (which in turn is implemented by means of ICMPv6 messages) and potentially others like DHCPv6 – might depend on a number of factors:
- the technical properties of the protocol itself (which cryptographic features does it bring, what about authentication methods, which type of transport or low-level communication approach is used etc.); see also this post.
- what’s the attack surface (or from an operators’ point of view: the “exposure to incidents” which might include human errors during configuration processes, due to the features/complexity of $PROTOCOL)? This might be influenced by the amount of of dynamic elements in packets (think TLVs or “options” like those in IPv6 router advertisements).
- what’s the implementation status of potential security controls, be them protocol-inherent or provided by other entities (like implementing RA Guard on switches to cure a protocol-inherent weakness)? Here the OS support of (seemingly) protocol-inherent features (e.g. SEcure Neighbor Discovery) might play a role, as well as the maturity of security controls provided by solutions/vendors or their operational feasibility (of both types of controls).
- experience with the protocol and/or its security controls by operator personnel or on the vendor side (this recent vulnerability is an interesting example where apparently the vendor did not apply a security feature in the IPv6 space in the same way as in IPv4).
Looking specifically at IPv6 we can identify some properties which are different or new (in contrast to IPv4) and which might have security implications:
- higher complexity
- the way how IP parameters can be provisioned to/be configured on systems (as IPv6 practitioners know the combination of routers providing IP configuration information to local systems and, at the same time, the trust model which considers/expects others systems on the local link to act in a benign manner can have some significant [alas not entirely positive] security consequences).
- IPv6 extension headers (their nasty security implications have been discussed at many occasions like here or here. if you think that this is “old stuff which is certainly cured as of 2019” you might look at CVE-2019-5597 IPv6 fragmentation vulnerability in OpenBSD Packet Filter).
- the fact that interfaces usually have multiple addresses (which, for example, can have an impact on how local traffic filtering has to be implemented on systems).
Considering the above I think it becomes clear that in many environments IPv6 security has to be handled in a different way to, say, “just doing the same stuff as with IPv4, but with longer addresses”. From a high level perspective this requires
- to reflect on which security functions/controls a specific environments uses/relies on (as for IPv4).
- understand the implications of IPv6 for the environment. Essentially this boils down to “where can we use the existing approach & controls? if so (in general), would that make sense? ;-)”, with the latter focusing on the protocol design perspective and on vendor support of required controls/features (you may look at this thread if you think that we’re there yet, as for mature IPv6 support of enterprise gear in 2019).
- adapt where needed. Which is exactly what we plan to spend most time on in Monday’s tutorial ;-).
I’ll conclude this post here and I will directly start writing a sequel mainly covering traffic filtering in IPv6 networks. Stay tuned.
Wishing everybody a great weekend and safe travels to Reykjavík! Don’t forget to bring your running shoes (kudos Henrik Kramshoej for suggesting a joint run Tue morning) or, maybe, even your swimming trunks (as proposed by Emile Aben).
Cheers, Enno