Many organizations delay deploying IPv6 because they feel it doesn’t provide enough value for such a significant investment. However, many of these late adopters have not recognized that a majority of updated operating systems they would have deployed in recent years are IPv6 enabled by default.
This combination of inactivity, in terms of deploying and staying up-to date with IPv6 best practices, has resulted in an abundant number of unexpected insecurities in networks the world over.
Being one of the earliest adopters of IPv6 in Switzerland, as well as the National Research and Education Network (NREN), SWITCH has sought to educate more organizations of this oversight.
Its IPv6 training program — a collaborative project between their networking and CERT (SWITCH-CERT) departments — has been operating since 2012, assisting organizations with both deploying IPv6 and understanding its many security considerations.
Stop thinking just IPv4
Most of us — including information security experts — still unconsciously ‘think IPv4-only’ when it comes to network security. We falsely assume our devices live in a single-protocol environment because that’s what it has been for so long and what has been relevant for much of our past education.
Think of the last information security conference you attended. Many of the presentations would have shown IP addresses in their examples, right? And, in most of those presentations the examples would have been IPv4 addresses, right?
With Google recently announcing that over 25% of traffic it sees is carried over IPv6, it’s time to start thinking in and considering dual-stack and IPv6-only. Yes, it may require some more thinking — dual-stack environments are, in general, more complex than IPv4-only networks — but it will save you any costly oversights in the future.
Managers take note
One thing is sure — weak security controls for IPv6 networks will sooner or later be leveraged by adversaries. Every manager who is responsible for an IT infrastructure or its security has to make sure they have a feasible IPv6 roadmap in place, which includes the lifecycle of the equipment and security tools.
This also means they need an up-to-date and complete device inventory. For example, if nobody knows which devices are secured by access control lists (ACLs), it’s not possible to ensure that these ACLs are also set up for IPv6.
The other important point that managers need to consider is the need for appropriate training for staff. Decide who in the organization needs what level of IPv6 knowledge.
Also, don’t assume that new security equipment has the same IPv6 support as it does for IPv4 — this is often not the case. Remember, if you have to secure your investment, you have to be able to define detailed IPv6 requirements, which again requires appropriate knowledge. So, be sure to review and check that your vendors are able to offer the support you need.
My top three security considerations to take into account for IPv6
- IPv6 and IPv4 are different — There’s more to IPv6 than a huge amount of address space. It is very different to, and non-compatible with, IPv4.
- Read up — Once you have an idea about the differences, it’s good practice to learn about IPv6-specific and dual-stack-specific attacks. Some handy references I can recommend are the NIST Guidelines for the Secure Deployment of IPv6 and the more extensive Cisco book on IPv6 Security.
- Get your hands dirty — Often the best way to learn about something new is to start playing with it. It’s easy to build a small IPv6 lab – if you want to make it really simple, you can just set up some virtual machines on your laptop (see Figure 1) and play around with IPv6. If that starts to get boring, install Wireshark and hacker tools, such as the THC IPv6 attack toolkit or the SI6s IPv6 toolkit, to learn how IPv6 protocol attacks work. But be warned: never use these tools in a production environment, they can really do harm.
Figure 1 — Example setup with virtual machines. Source.
Frank Herberg is Head of the Commercial Sectors Team at SWITCH-CERT.
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.