Some Notes on Hardening IPv6 Stacks

Initially I wanted to start a long-planned post on “IPv6 Security Best Practices”, with a particular focus on enterprise environments, but then I realized I might need some ramp-up clarifications beforehand.

First it might be helpful to understand that actual ‘IPv6 security measures’ in a given environment might heavily depend on the ‘deployment mode’. As mentioned in a recent Twitter thread I increasingly think that the specific, let’s call it: ‘use case’ of IPv6 in a given (sub-) network, plays a huge role for the way it’s configured and operated, incl. the security side of things. Look at these three examples:

IPv6 in the data center: this is often done with static addressing (even though other approaches might exist) which includes a high level of control (on the one hand the desire for this is the reason for the former and on the other hand it’s an operational prerequisite), security is frequently implemented by/contributed to by at least one layer of network-based traffic filtering etc.

IPv6 in a mostly Wi-Fi based campus network: here commonly SLAAC comes into play, RA Guard and filtering of server-side DHCPv6 packets are considered basic network hygiene (implemented either by means of active configuration steps or by default on the platform of choice, see this thread), in a given enterprise environment one can expect a certain homogeneity of the involved operating systems, and one can also expect some level of administrative control with regard to the (IPv6-related) settings on the hosts.

IPv6 in networks populated mostly by ‘IoT systems’ which in turn usually implies a low level of control over the individual systems and their settings as well as a high degree of heterogeneity when it comes to their IPv6 stacks, together with – maybe – different protection needs (re: traffic confidentiality or system availability) when compared to data center networks.

While the above are just examples, I think that distinguishing between different deployment models, and namely understanding that those exist, can play a significant role for the discussion of security controls applicable in a specific environment. This becomes clear when one looks at a potential security control which has been the subject of some debates for a while, that is the ‘hardening’ of IPv6 stacks. There are people who think that ‘IPv6 is primarily a network thing, and hence the network folks should take care of securing it’, while others think that (host-level) hardening is an essential part of a holistic infrastructure security framework. Also it’s a topic of common interest in IPv6 security circles – the ‘Hardening IPv6’ guides for different OSs which my friend Antonios Atlasis wrote in a joint project back in 2014 (you can find those documents here) have been downloaded a lot over the years.

Let’s have a quick look at typical ‘IP hardening’ measures, and where/how to implement those. Based on IPv6 projects I’ve done in very large enterprise networks between 2013 and mid-2019, I for one would say that host-level hardening of IPv6 by means of operational configuration measures (not to be confused with shipping hardened IPv6 stacks from a vendor, see this discussion on the APNIC blog) should only be done in data center networks, if at all. Reason mainly being that, from my experience, in other deployment scenarios the ratio of operational feasibility vs. the achieved security benefit/risk reduction usually isn’t very good. Put differently: one might invest a lot of energy, and expectations, into hardening measures without gaining much real-life security. Please note that I’m not stating this lightly as I’ve always been a big fan of hardening in my security career, and I still am. It’s just that in the IPv6 world hardening might be overrated (as IPv6 by design assumes a high level of autonomy for individual hosts, and deviating from this usually involves significant operational effort). Furthermore some measures which would actually be useful (such at just not processing IPv6 extension headers of the types 0,43,60 and/or dropping all IPv6 fragments by default on a given stack) are commonly not available, again due to IPv6 design decisions. As I laid out in my Troopers 16 IPv6 Security Summit talk on “Protecting Hosts in IPv6 Networks” and in the recent IPv6 stack level security post, potential measures can be broken down to the following categories:

• Removal of unused IPv6 features or helper protocols
• Static configuration of IPv6 parameters incl. disabling ‘dynamic functionalities’
• Tweaking of IPv6-parameters

In the following I’ll discuss some details on those, with sample parameters from the Linux world (documentation of those I mention for the current kernel here. also note that some parameters can be configured on various levels like ‘all’, ‘default’ or interface-specific, so multiple configuration steps might be needed).

Removal of unused IPv6 features or helper protocols

In case of a static (address) configuration approach, SLAAC can (and should 😉 be disabled, via configuring
net.ipv6.conf.default.autoconf

Getting rid of MLD might be an idea, too, but you should thoroughly understand its role and the implications (see this series of posts on MLD that we wrote some years ago). I’m not aware how to disable it by a sysctl on Linux or FreeBSD anyway.

Static configuration of IPv6 parameters incl. disabling ‘dynamic functionalities’

Common candidates in this space encompass disabling the processing of router advertisements and disabling the processing of ICMPv6 redirects, via touching
net.ipv6.conf.default.accept_ra
net.ipv6.conf.default.accept_redirects

I’d say that the 1st one is a common thing in data center environments, whereas the 2nd isn’t configured very often (see also results of this Twitter poll I did a while ago). Also keep in mind that the RA parameter might/should also be configured on ‘all’ plus on the interface level. Furthermore it’s noteworthy that Linux nowadays allows some granularity wrt the pieces of an RA that will be accepted (e.g. default route, PIO, MTU).

Tweaking of IPv6-parameters

There are two types of measures of interest here: those that control security-related specifications (e.g. RFC 6980) and those which enforce upper limits of IPv6-related data structures. From the 1st category on Linux there is only
net.ipv6.conf.all.suppress_frag_ndisc
which has a reasonable default value (‘1’ = ‘enabled’), and I’m not aware of any configuration knob on other OSs.

From the second category one might have a look at max thresholds for the number of (default) routes or addresses (which shouldn’t be needed anyway when SLAAC is disabled, see above), or at limits in the context of fragmentation/reassembly (provided fragments are allowed in[to] the environment in the first place, which might already be debatable from a security & network stability perspective …). Looking at the Linux kernel, the following parameters come to mind in this space:
net.ipv6.conf.all.max_addresses
net.ipv6.ip6frag_high_thresh & net.ipv6.ip6frag_time

Finally, from a security point of view, one might have a look at this one:
net.ipv6.icmp.echo_ignore_multicast

However, frankly, I don’t remember many environments configuring the settings in this last section at all. Still those might be worth a closer look, together with proper testing in case you consider touching them ;-). Most operating systems don’t even offer ways to do that.

tl:dr: the chosen IPv6 security strategy will depend on the deployment scenario. When hardening is part of this strategy, there’s usually only a limited number of parameters which are worth looking at, from an OpEx-to-security gains perspective.

Thanks for reading so far. As always I’m happy to receive feedback.