A few months ago, I made a post about IPv6 security. I’ve caught some flak for saying that IPv6 isn’t a security issue. I still stand by this position.

This is not to say that you should ignore security considerations when deploying IPv6. All I claim is that deploying IPv6 in and of itself does not make an organization any more or less secure. This point was made by Dr. Joe St. Sauver, of the University of Oregon, in an excellent talk on IPv6 security at the Winter 2009 Internet2 Joint Techs meeting (video is also available). Joe’s talk is the most level-headed analysis of IPv6 security I’ve seen. I highly recommend watching it.

Earlier this month, Derrick Webber posted an article entitled, “The coming IPv6 security disaster”. For the most part, I agree with his conclusion: If organizations wait to deploy IPv6 until IPv4 is depleted, they will most likely rush to deploy IPv6, and the ensuing sloppiness will have security implications. But this doesn’t seem to me to be an IPv6-specific issue; the same could be said for practically any technology (in his defense, Weber admits this).

Having said that, there are aspects of IPv6 which need to be addressed. These include securing Router Advertisements, handling fragment reassembly and analysis, and the lack of NDP and DHCPv6 inspection in edge switches.

Another common concern are the “transition” mechanisms, such as dual-stack and tunneling. Securing dual-stack networks isn’t that difficult: For the most part, you mirror your security policies from IPv4 to IPv6 (accomodating protocol-specific differences, such as ICMPv6 filtering). As for tunneling, I don’t have much good to say about it. I certainly recommend avoiding 6to4 and Teredo whenever possible. Both systems tend to be very slow. Many firewalls can’t filter them (but most firewalls can’t filter many other tunneled protocols either). I understand that it’s easy for me to dismiss tunneling, since I work at an institution with native IPv6 access. If you’re going to tunnel, at least use a static one from a reputable tunnel broker.

Of course, with any code, there are bound to be implementation bugs. Most recently, Stephan Lagerholm alterted the IPv6 community to a particularly nasty ICMPv6 bug that was patched in Mac OS X 10.5.7 (so go patch if you haven’t already). Of course, the 10.5.7 update fixed several other remotely exploitable bugs that have nothing to do with IPv6, some of which are pretty serious. To repeat a line from my earlier blog post: Implementation bugs in any piece of software are inevitable. When we find them, we patch the affected systems. This is true of IPv4, IPv6, Apache, sendmail, IOS, OpenSSL the VMware hypervisor, etc. Keep your wits about you, and sign up for the appropriate mailing lists.

At Penn State, as part of ITS’ IPv6 planning process, I’ve been working with our security office to develop list of security requirements for IPv6-only networks. In other words, if a unit wants to deploy an IPv6-only network, what does ITS have to do first, to enable them to be incompliance with various University policies (such as AD-20 and iPAS Phase II). It’s more of a hypothetical exercise today, as we could use private IPv4 addresses to contact internal resources (such as update servers, syslog servers, etc), but it was still a very useful exercice. The good news is that we’re well on the way to IPv6-enabling several of these services (watch this space, big announcement should be coming soon).

By the way, I can’t say enough positive things about the book, IPv6 Security by Scott Hogg and Eric Vyncke. It’s an excellent book that covers the common attacks on IPv6 networks, and presents a realistic, vendor neutral view of the current state of IPv6 security. For readers at Penn State, the book is available online via the University Library’s Safari subscription. I also encourage PSU readers to consult the IPv6 Security page in the University Wiki.

Deploying IPv6 won’t make you any more or less secure. But like any “new” technology, it takes time to deploy it right. So start now!