Organizational Security Implications of IPv6

In this post (with a very German, bulky title 😉) I’ll take a look at the implications of IPv6 on the security controls & processes in common enterprise environments, based on a few customer projects I performed in 2016–2019.

As I laid out in my presentation in the IPv6 WG at the RIPE79 meeting in Rotterdam there’s three main, say, ‘dimensions’ of (the advent) of IPv6 in an IT environment:

• IP addresses identify entities (e.g. interfaces of systems) within networks, for a certain duration/amount of time (with IPv6 the latter plays a much more important role than in IPv4 networks, think ‘lifetime’). Here (the existence of) an IP address usually precedes the actual communication act – “I have an IP address, therefore I am [ready to communicate]”.
• 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”.
• IP addresses can be processed (e.g. read from or written to files, put into databases or be analysed based on algorithms) by applications or system processes. Some of these types of operations are highly security-related, 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 namely the third above dimension is of great 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 first two former dimensions can even be touched.
Configuring IPv6 rules on a firewall (2nd dimension) doesn’t make sense if the analysis framework/infrastructure isn’t capable of IPv6 (3rd dimension), and merely enabling IPv6 on systems (1st dimension) without having the capability to filter IPv6-related traffic (2nd dimension) can actually be quite dangerous.
That’s why, as some of you dear readers have painfully experienced, usually one has to start an IPv6 project with (taking care of) the 3rd dimension…

Now, to better understand the implications of IPv6 on security controls & processes, one approach could be to take a 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 mainly three areas are affected:

• Wherever IP addresses are used to contribute to a function (e.g. 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 also some of the points in this old post).
• Evidently 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’s some sub-categories in the Identify function covering threats & risk management. Those have to consider IPv6, both wrt to IPv6-specific threats & risks (some of those were covered in my RIPE78 tutorial which is linked in the beginning of this post) and as for suppliers/the supply chain where IPv6 might also kick in.

Not too surprisingly IPv6 will also heavily affect controls & 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 adapted for IPv6.
• Audit & logging is one of the sub-categories in Protect (see PR.PT-1) and this is a classic example of the above 3rd 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 & 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. Transitioning to IPv6 is much more (complex) than just enabling IPv6 addresses on systems.
Challenge accepted, I’d say, given we don’t have any alternative to IPv6…

Happy to receive any type of feedback (Twitter is usually a good channel ;-).
You all have a great week,
Enno

A slide deck with some of these thoughts can be found here:

ipv6_security_implications-2Download