IPv6 is a lot of fun and, as you’ve probably noticed, I encourage everyone to lab, test and learn IPv6. After that, install it for production use. You might want to ask me – what about security? Will I still be protected without a NAT? Will I be the first one, experiencing all the trouble? No, you will not be first. IPv6 is out there. A growing number of service providers support IPv6 to home users, cellphones and businesses. The experience of running IPv6 in production is growing while many are still in the lab phase. It’s time to learn more about IPv6 security.
This week I’m in the heart of the Norwegian University Network – at Uninett in Trondheim. And for the institutions connected to the nation-wide Uninett, IPv6 is beyond labs and testing, it’s production use. Their on-line statistics show a growing number of IPv6-enabled hosts, currently around 20.000 with one university having IPv6-enabled more than 75% of their installed base. They do not hide that they’ve had issues, but they have worked them through, changed equipment and upgraded software where necessary.
That’s a very important part, the feedback of experience, best current practice and issues that needs to be solved, to the group that manage the standards. At the recent IETF meeting, I understood that there’s still some work needed for the large scale service providers. It’s not only about adding IPv6 now, but how to manage the complete transition to IPv6 as the main protocol. The equipment provided to customers stays for a long time and it’s important to do it right the first time. Installing a solution where IPv6 is tunneled over IPv4 is the only solution, is not a long term platform to use. This applies to the security work as well, you need to start working with IPv6 security for both the transition phase as well as the native connectivity phase. Plan for traffic growth on IPv6 from start. It may not be much at this point, but the growth will be much bigger than the growth you are used to for IPv4 traffic.
ALL networks need IPv6 security
The security area is of course an area where we need to build a shared knowledge base on the net, just as we’ve done for IPv4. You can see that there’s a discussion going on here in a number of documents. One area is the impact of various migration technologies. While waiting for the native IPv6 connection, different tunneling solutions can be used. A new Internet Draft – Security Implications of IPv6 on IPv4 networks – discusses potential issues with these tunnels, like the Teredo support that is automatically implemented in Microsoft Windows 7.
“Finally, some transition/co-existence mechanisms (notably Teredo) are designed to traverse Network Address Translators (NATs), which in many deployments provide a minimum level of protection by only allowing those instances of communication that have been initiated from the internal network. Thus, these mechanisms might cause an internal host with otherwise limited IPv4 connectivity to become globally reachable over IPv6, therefore resulting in increased (and possibly unexpected) host exposure. That is, the aforementioned technologies might inadvertently allow incoming IPv6 connections from the Internet to hosts behind the organizational firewall.”
In short, if you believe you have an IPv4-only network, you will be surprised. This draft, which is aimed at becoming a Best Current Practise document, says that ALL networks should start to implement IPv6 security mechanisms, regardless of what you believe you have inside. There’s no time to wait for native IPv6 connectivity. IPv6 is here and is showing up in many places.
The IPv6 Security Overview – RFC 4942
RFC 4942, published in 2007, contains a wealth of information and is a good starting point. It groups the security area into three groups:
- Issued caused by the IPv6 protocol
- Issued caused by IPv6 transition solutions
- Issued caused by IPv6 deployment
The document introduction gives a realistic view of the transition phase:
“It is important to understand that deployments are unlikely to be replacing IPv4 with IPv6 (in the short term), but rather will be adding IPv6 to be operated in parallel with IPv4 over a considerable period, so that security issues with transition mechanisms and dual stack networks will be of ongoing concern. This extended transition and coexistence period stems primarily from the scale of the current IPv4 network. It is unreasonable to expect that the many millions of IPv4 nodes will be converted overnight. It is more likely that it will take two or three capital equipment replacement cycles (between nine and 15 years) for IPv6 capabilities to spread through the network, and many services will remain available over IPv4 only for a significant period whilst others will be offered either just on IPv6 or on both protocols. To maintain current levels of service, enterprises and service providers will need to support IPv4 and IPv6 in parallel for some time.”
The RFC is just 41 pages long, but contains a lot of important information. It strongly advices agains fixed firewall rules in devices (read: home routers), since the IPv6 protocol needs to evolve. In the world of IPv4 we’ve seen many issues when trying to launch protocol or networking improvements. These boxes aren’t flexible enough and can’t adopt to a changing network.
On the other hand, the document talks about IP enabled small devices, part of the Internet of things:
“With the deployment of IPv6 we can expect the attachment of a very large number of new IPv6-enabled devices with scarce resources and low computing capacity. The resource limitations are generally because of a market requirement for cost reduction. Although the [RFC4294] specifies some mandatory security capabilities for every conformant node, these do not include functions required for a node to be able to protect itself. Accordingly, some such devices may not be able even to perform the minimum set of functions required to protect themselves (e.g., ‘personal’ firewall, automatic firmware update, enough CPU power to endure DoS attacks). This means a different security scheme may be necessary for such reduced functionality devices.”
There are many people working with these kind of solutions now and we’ll probably see lots of development in this area.
Executive summary:
Stop reading this week’s blog entry. Go read RFC 4942 – IPv6 transition/coexistence security considerations. Spend 30 minutes on IPv6 every Friday!
That’s all for me this week. As always, I do appreciate feedback!
/Olle
PS: If you missed it, I wrote another article about IPv6 Security in March 2012.