IPv6 Security Best Practices

That’s an ambitious title, from many regards.
Still, late 2020 might finally be time that we, as the IPv6 community, try to come up with a set of simple IPv6 security best practices to be used both as guidance and in a checklist manner.
One of the earliest of such efforts goes back to my friend Eric Vyncke, yet that one dates from 2007 (btw, Eric is also the maintainer of the useful ‘IPv6 Deployment Aggregated Status’ site). I had the pleasure to co-author an Internet-Draft on “Operational Security Considerations for IPv6 Networks”, but after years of discussions on the mailing list it has been stuck in ‘IETF review hell’ for a while (I paraphrase this term from Geoff Huston’s essay on “The Making of an RFC in today’s IETF“). Currently it doesn’t feel like that any of the authors incl. myself has any motivation or energy left to drive this further.
I’ll hence use this blog to formulate some ideas. As I have done IPv6 projects predominantly in large enterprise environments (before taking over my current role in mid-2019) there’ll be a certain focus on that space, though many of the thoughts should be applicable in various types of organizations. Also I’ll try to keep it simple, which isn’t always easy for me 😂.

Harden your servers

I recently wrote a piece about hardening of IPv6 stacks. For most systems the security benefits gained from it might not be worth the associated operational effort, but for systems in data centers hardening should be on your list of IPv6 security measures, especially when those systems are configured with static (global) addresses. Simply not offering certain interactions usually strengthens the security posture of systems or network devices.

Review packet filtering rules

In pretty much all environments packet filtering, either on the network level (via firewalls or ACLs on routers) or on the host level contributes to the overall security stance. In the course of your IPv6 deployment you might want to check those rule sets, as IPv6 brings technical changes which in turn require adapted rules, like

• Different functionalities of ICMPv6 (some additional info here, here, and here)
• IPv6 extension headers (see also next section)
• Different network behavior within subnets, that is – in IPv6 lingo – ‘on the
  local link’
• An altered addressing architecture (more on this here, here, or here)

An organization’s IPv6 transition might also provide a good opportunity to review rule sets from a broader perspective (“do we still need all those rules sitting in there since 15 years?”), but maybe you shouldn’t overload an IPv6 deployment effort with the ambition to cure deficiencies in your company’s security governance space at the same time ;-). Usually the former is complex enough.

Drop packets with extension header types 0, 43, 60 at network borders

There’s an active, and worth a read, Internet-Draft on “Operational Implications of IPv6 Packets with Extension Headers” (authored by Gert Doering, Fernando Gont and others). It includes this section:

This nicely summarizes the potential security issues of those headers, more information here or here. The main point, however, being that there’s no compelling (or other) use case for any production use of EH types 0,43, and 60 at all. If there are no practical benefits of a certain functionality, but many associated risks – why would one ever allow such stuff to enter one’s network?

Strongly consider dropping all inbound IPv6 fragments

Security problems related to IPv6 extension headers are often amplified when fragmentation comes into play (see here or here). There’s hope that the amount of fragmented IPv6 packets in the Internet right now significantly decreases due to the recent DNS flag day 2020. In recent years the majority of IPv6 fragments has been DNS traffic; nowadays one should only see very few TCP fragments, if at all, given TCP has the MSS to deal with situations requiring to split a payload, and at the same time the black hole detection of most OSs has become quite mature.
You might face some resistance when coming up with this measure. It could be an idea to perform an extra amount of testing incl. documentation, to closely observe counters of related ACLs for a while, and/or to come up with some training to identify MTU related connection issues during troubleshooting or via network telemetry. I also encourage all involved parties to read RFC 8900 “IP Fragmentation Considered Fragile”.

In shared L2 subnets perform risk analysis for RAs, NDP, MLD, and DHCPv6

All these packet types can cause security issues on the local link. Over the years there’s been some debate if the operational effort related to deploying associated controls on the switch port level (often called “First Hop Security” features) is worth the resulting risk reduction, in particular as from my experience several vendor approaches have shown serious teething problems. One may also keep in mind that at least in the past some of these features could be easily evaded.
There are RFCs on addressing rogue RAs (RFC 6105) and on protecting against unsolicited DHCPv6 packets (RFC 7610); see also next section. Eric Vyncke, Antonios Atlasis and myself once came up with the idea of an ‘MLD-guard’ feature but this didn’t take off, presumably because bad things doable with MLD are considered less severe than those related to the other packet types. In the projects mentioned above I primarily saw RA Guard and DHCPv6 Guard getting implemented (hence this post from 2015).

Understanding the risks associated with these functionalities & packet types, and if or how to protect against those, is part of your security-related homework of the IPv6 journey. I’ll discuss some of this in the following (yes, some overlap of the rules here ;-).

In shared L2 subnets with Ethernet drop RAs and server-side DHCPv6 messages on all access ports by default. Same for Wi-Fi on the controller or AP level

As stated at other occasions this is simply basic network hygiene. Many network operators integrate this into their ‘access port security templates’ (for physical switches, for virtual ones it’s a different story), and barring very specific conditions it’s not only safe but highly advisable to drop these packets. Looking at RFC 8415 section 7.3 ‘server-side DHCPv6 messages’ should encompass Advertise, Reply & Reconfigure messages. Common DHCPv6-Shield (that’s the ‘official’ name of the feature as of RFC 7610) implementations like Cisco’s DHCPv6 Guard probably filter exactly those.

In Wi-Fi networks such filtering can often be done on the controller or on the AP level, and evidently even fewer legit scenarios with such packets exist there than, say, in campus Ethernet networks. The related configuration approaches may be quite different though, e.g. see this talk by Christopher Werny from the Troopers 2016 IPv6 Security Summit, or this guide for Cisco 9800s. Last year I did some cursory testing on its effectiveness on a specific platform (results here).
Given the differences of commercial enterprise Wi-Fi solutions re: the exact configuration steps and their default settings, I recommend going with a combined approach of auditing (which, indeed, you periodically do anyway, right? 😉 ) and configuration steps (to happen in an automated manner during device deployment, maybe).

Think hard about a source of IPv6 truth for processes like asset management or vulnerability management

The importance of asset management and of a proper source of truth for it is, of course, also true for IPv4 environments. There’s a reason why the NIST Cybersecurity Framework starts with the Identify function…
On the other hand most of us know that the simple question “what do we have?” might not be simple to answer, even if executives or regulators may think so. However, in IPv4 networks one could always try to cover blind spots by simply scanning address ranges in a sequential manner, in order to identify ‘alive’ systems (which are then subjected to further enumeration steps). Surprisingly many organizations still do this today. Point is that such an approach is just not feasible in IPv6 subnets. Consequently one has to come up with different methods (such as ingesting data from neighbor tables, incorporating DNS AAAA records etc. – I’ll discuss some of these in another post), and I recommend to start thinking about this better sooner.

Take care that the vulnerability management framework is IPv6-ready

As an IPv6 practitioner one definitely wants to avoid being responsible for increasing the risk exposure of an environment, so taking care of the IPv6-readiness of an organizations’s vulnerability management process makes sense. This usually includes three main fields of activities:

• A source of truth which provides ‘alive’ IPv6 systems/addresses, see above
• IPv6 capabilities of the tools & techniques used for the vulnerability scanning itself
• IPv6 reachability of all to-be-scanned endpoints from the scanner networks

Reflect on network security telemetry and on threat detection in the age of IPv6

I’ve discussed ‘Organizational security implications for IPv6’ on the APNIC blog a few months ago. Furthermore I wrote down some initial thoughts on threat detection in IPv6 networks back in 2016 here, but overall I feel this needs more critical reflection at another occasion (read: stay tuned for an upcoming post ;-).

Suffice to say that, whatever type of smart machinery and/or human intelligence you may be using to look at large sets of security-related data, you’ll have to re-think and adapt some of that for IPv6.

Evaluate the implications of dual-stack and of v6-only + NAT64 on security processes

Some overlap here with the previous point, still this deserves a dedicated mention in the list. Both deployment strategies bring some changes/challenges when it comes to analyzing & namely correlating connection data and traffic flows. In dual-stack environments one endpoint might show up with different addresses, from different families and with differing ‘lifetimes’. In networks using translation techniques one and the same connection might have an IPv4 part and an IPv6 part (initially IPv6 and subsequently IPv4 in case of translation ‘close to the client’ = with NAT64, or initially IPv6 and then IPv4 in case of translation ‘close to the server’, e.g. on load balancers or reverse proxies). Either way all of these scenarios require to re-evaluate the idea of a ‘connection identity’.

---

Tl;dr: (not only) from a security perspective the advent of IPv6 requires technical implementation steps and process changes. Here’s a summary of the rules I discussed: