IPv6 Security & Capability Testing, Part 1

Let’s be realistic about this: the advent of any new technology in a complex IT environment can lead to additional vulnerability exposure and hence to additional risk. Given the fundamental role of IP for practically all communication acts and all digital services in today’s organizations this is particularly true for IPv6.

On the other hand as an IPv6 practitioner one definitely wants to avoid being responsible for significantly increasing the risk exposure of an environment, not least as it’s already hard in itself to drive the deployment of a protocol which shines by a lot of added – and, maybe, from today’s 20/20 perspective: unnecessary – complexity while at the same time, rightfully or not, being perceived as bringing just one single advantage, that is larger address space.

This is why I want to discuss in a small series of posts some thoughts how to deal with this situation. What are the things to keep in mind or to focus on, when IPv6 is gaining traction in any sufficiently large, complex and heterogeneous environment?

Said additional exposure can stem from several factors:

  • Lack of operational experience (we as the IPv6 community can try to contribute to curing this by training & education, but of course there will be gaps for some time/years). These two papers (both from 2016) lay out some differences between IPv4 and IPv6 from an Internet scanning perspective, and quite some of those observed differences could be attributed to disparities in operational practices.
  • Lack of available security mechanisms & processes. I’m not the biggest fan of the ‘let’s just transfer our security architecture & technologies from the IPv4 world to IPv6’ approach, but it’s a commonly found and – considering the often significant efforts of deploying IPv6 – fully legitimate approach (I mean we as IPv6 practitioners shouldn’t expect our valued peers from the security groups to heavily re-engineer their stuff just because of our new thing, and I’m fully serious here). On the other hand it might just be that such a ‘simply transfer’ strategy can’t be pursued due to hardware limitations (TCAM memory comes to mind) or due to performance penalties arising from IPv6. While from 2013, this diagram (from a presentation at the ‘IPv6 Hackers’ meeting at IETF 87) might give an idea of the latter:
    undefined
  • Specifics of the new technology in question. In case of IPv6 this might encompass factors like new protocol features with possible security impact (router advertisements or MLD come to mind), the generally huge variety when it comes to IPv6 stacks & their properties, and finally the potential immaturity of those stacks. I mean in 2020 we shouldn’t see things like this or this anymore, right?
    undefined

This last aspect is the reason why I think that the following three elements should be part of the security side of each IPv6 deployment in a complex environment:

  • Make sure that any IPv6-enabled system is properly protected by (at least) some packet filtering mechanism (be it an ACL on the network layer or a host-based component) from the very beginning. This is particularly important as you should always assume global reachability due to IPv6 GUAs and due to the potential lack of control your security groups might have over route announcements and route filtering. How to audit this (existence of packet filter on some layer for all systems) can be an interesting challenge, and I might get back to this at a later point/post.
  • Make sure that all IPv6-enabled systems are covered by your organization’s vulnerability scanning process in case such a thing exists. Given one can not reasonably scan IPv6 subnets sequentially this might actually require some changes to said process.
  • Create transparency with regard to the capabilities & properties of individual IPv6 stacks to be found in the organization, e.g. when it comes to RFC 6980 support or to their susceptibility as for malformed IPv6 packets.

The actual vulnerability exposure and the associated risk level of your IPv6 deployment will highly depend on these three factors. In the next post I will particularly focus on the third of those, that is on ideas and approaches how to create such transparency.

Stay tuned, and thanks for reading so far.

Published by Enno

Old-school networking guy with a certain focus on network security. This blog is a private blog and it contains private musings, even though I have a day job around the Internet Protocol. I leave it to the valued reader to guess which version of it ;-) Twitter: @Enno_Insinuator

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: