Transitioning to IPv6 is much more complex than just enabling IPv6 addresses on systems.
In this post, I’ll take a look at the implications of IPv6 on the security controls and processes in common enterprise environments, based on customer projects I performed between 2016 and 2019.
Where’s the best place to start when deploying IPv6
As I laid out in my presentation at the IPv6 WG during RIPE 79, there are three main ‘dimensions’ in an IT environment that need to be considered when deploying IPv6:
- IP addresses identify entities (for example, interfaces of systems) within networks, for a certain duration/amount of time. In the case of IPv6, the latter plays a much more important role than in IPv4 networks — think ‘lifetime’. This is the core function of IP addresses: to enable (processes/applications running on) systems to communicate with each other, where the involved entities are identified by their (own) addresses.
- Furthermore, certain systems can use the IP addresses of other systems to take specific actions, like routers performing forwarding decisions based on destination IP addresses of packets or firewalls dropping packets based on their addresses. The IP address is looked at during the act itself – “Show me the address(es) of a packet and let’s see what I’ll do with it”.
- Finally, IP addresses can be processed (for example, read from or written to files, put into databases or be analysed based on algorithms) by applications or system processes. Some of these operations have security-implications, like in the context of incident response or fraud detection. This can happen in close temporal proximity (real-time) or in retrospective. For this temporal dimension, the above-mentioned property of validity/lifetime has to be taken into account.
From an IPv6 deployment perspective, the third dimension is of greatest importance and usually is the one leading to multi-year IPv6 programs as the places/functions where IP addresses are processed usually constitute dependencies to be solved before the former dimensions can even be touched.
Configuring IPv6 rules on a firewall (second dimension) doesn’t make sense if the analysis framework/infrastructure isn’t capable of IPv6 (third dimension). And merely enabling IPv6 on systems (first dimension) without having the capability to filter IPv6-related traffic (second dimension) can actually be quite dangerous.
Considering security functions
One approach to better understand the implications of IPv6 on security controls and processes is to look at the NIST Cybersecurity Framework (which I also briefly discussed in my talk in the Troopers 2019 Defense Track) and to identify all (sub-) categories potentially affected by IPv6, in one of the above dimensions. When doing so some generalizations can be observed.
In the context of the ‘Identify‘ function, three areas are affected:
- Wherever IP addresses are used to contribute to a function (for example, as an identifying property of an asset/a system) the underlying databases or models might have to be adapted, in order to account for the different format of IPv6 addresses (128 bits instead of 32 bits, hexadecimal characters, different delimiter of parts of the address). And for the fact that usually, multiple IPv6 addresses co-exist on individual interfaces (see this old post of mine for more on this).
- Vulnerability management will be heavily affected in most organizations. Sequential scanning of subnets doesn’t work anymore, systems might expose different vulnerabilities over IPv6 than over IPv4 (see the sources mentioned in this thread) and link-local connectivity might play a role, too.
- Finally, there are some sub-categories in the identify function covering both threats and risk management. These have to consider IPv6, both with regards to IPv6-specific threats and risks (some of these were covered in my RIPE 78 tutorial) and as for suppliers/the supply chain where IPv6 might also kick in.
Not too surprisingly, IPv6 will also heavily affect controls and processes in the field of the ‘Protect‘ function:
- Many technical controls used to protect assets will have to be reviewed as for their IPv6 capabilities, and their configuration (and maybe even the underlying architecture) might have to adapt for IPv6.
- Audit and logging is one of the sub-categories in Protect (see PR.PT-1) and this is a classic example of the above third dimension of IP addresses (being processed by a system process or an application) which might require (potentially complex) adaptions for IPv6.
In a similar way several (sub-) categories of the ‘Detect’ and ‘Respond’ functions will be affected:
- Detection, analysis and correlation methods might have to be modified/enhanced for IPv6.
- IPv6-specific training of personnel performing tasks in the context of these functions will be needed.
- Processes in the incident response and digital forensics context have to take different types of addresses, their intricacies (interfaces with multiple addresses of varying lifetimes) and the co-existence of different address families into account.
As you can see, quite a few security-relevant elements within an organization will have to be reviewed and adapted in the course of an IPv6 deployment effort. Comment below on any other elements you’ve come across too.
Adapted from original post which appeared on The Internet Protocol Blog.
Enno Rey is a long-term IPv6 enthusiast with lots of practical experience in the space.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.