NSA publishes IPv6 network security guidance
Tunnelling, translation, SLAAC and multihoming all discouraged
When IPv6 is implemented on a computer network, the operator needs to pay additional attention to the network's security. It's particularly important to do so during the current transitional phase, with dual-stack set-ups and other IPv4-IPv6 transition mechanisms in widespread use. Those are the key takeaways from the US National Security Agency's recently published IPv6 Security Guidance.
According to the authors, the security measures required for IPv6 do not differ fundamentally from those currently used for IPv4. The same measures can therefore be implemented, with a few modifications where appropriate. The authors see the creation of new IPv6 networks and the complex transition mechanisms associated with migration from IPv4 to IPv6 as the main drivers of extra risk, mainly due to the immaturity of IPv6 configurations and security tooling, and a lack of relevant experience on the part of some network operators.
Administrative burden and attack surface
Notably, the complexity of the transition mechanisms isn't the first issue mentioned by the authors. They begin by highlighting the extra administrative burden and increased attack surface associated with popular dual-stack set-ups. They go on to make the following recommendations:
Although the automatic assignment of IPv6 addresses using SLAAC can significantly reduce the administrative burden, there are privacy implications. However, the authors' recommended solution isn't SLAAC Privacy Extensions, but DHCPv6.
(For the Privacy Extensions, they still refer to RFC 4941, even though that was superseded 2 years ago by RFC 8981, which, in combination with RFC 7217 and RFC 8064, provides additional privacy protections.)
The use of network tunnels, which was common in older transition mechanisms, is discouraged – partly because of the complexity of the protocols, and partly because the existence of tunnels implies opaque points of entry to the network.
(An overview of the transition protocols is available here. We do not recommend using the older tunnelling-based protocols (6to4, 6in4, IPv6 rapid deployment (6rd) and Public 4over6). Other legacy protocols, such as ISATAP and Teredo, are not included in that list because, although they are sometimes still encountered in existing networks, they are gradually disappearing. (An overview of the current transition mechanisms (some tunnelling-based, some translation-based) is available here.)
With a dual stack, all the security measures implemented for IPv4 must also be implemented for IPv6, and to at least an equally high standard. Again, tunnelling and translation are not recommended, because of the complexity.
The assignment of multiple IPv6 addresses to a host (multihoming) [RFC 7934 advises configuring a separate IPv6 address for each service] also increases the risk. Close attention therefore needs to be paid to filter lists, access control lists (ACLs) and logging.
Other focus points
Other points that the authors flag up as warranting attention:
The importance of knowledge of IPv6 networks and their configuration
The use of Split DNS (for both IPv4 and IPv6)
Filtering (particularly if tunnels are used)
ICMPv6 (necessary for various elements of IPv6, meaning that packets of the relevant type are allowed through more often than with IPv4)
Fake DHCPv6 servers
Avoiding translation (except for NAT64/DNS64 and 464XLAT in IPv6-only networks)
