Thoughts on IPv6 Security, Take Two

| | Comments (6) | TrackBacks (0)

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 considersations 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!

0 TrackBacks

Listed below are links to blogs that reference this entry: Thoughts on IPv6 Security, Take Two.

TrackBack URL for this entry: https://blogs.psu.edu/mt4/mt-tb.cgi/66920

6 Comments

Carlos said:

There will be always issues with any almost software, but it's always good to have a review of the most relevant ones that are still unaddressed...

Paul said:

I think in a sense, viewing IPv6 software as "just another software package, that could have flaws" is a bit too short.

Two points:
1. Host-side: the central IP network stack is probably one of the more important software parts of contemporary computers and not just another part of the operating system, and thus has a very high risk,
2. Network-side: you don't change the core IP networking and routing protocols of a given backbone quite regularly. This implies both mistakes that can be made in dual-stack/transitioning that would never happen if you would not change the IP backbone and mistakes in the "IP interface" of any given central network services, that occur only due to the shift to a different networking technology.

What I want to say is -- on the one hand you are correct, the IPv6 stack is after all just one piece of software, but on the other I guess there are and will be many security issues which are not just normal software flaws/issues, but which are completely dependent on the switch from on core Internet protocol to the other.

br
p

Derek Morr Author Profile Page said:

Paul,

I see your point. Let me respond.

#1 - Yes, the IP stack in the kernel is very important. But, for our public-facing services, so is the SSL library, or the HTTP parser, etc. I'm not sure one could rate one of these modules are more important than another. How do these compare to a buggy PHP script that's susceptible to cross-site scripting or SQL injection, which could result in a costly data breach? Or to a bug in BIND that could allow someone to hijack DNS? I don't have a good idea for how to compare the severity of these threats to one another, aside from referencing their Secunia ratings.

For internal services, we use a lot of VMware. Is a bug in a virtualized OS'es IP stack worse than a bug in the VMware ESX hypervisor?

#2 I'm not sure I follow you here. Yes, the protocols don't change often, but implementation bugs are found in them. For example, Cisco has recently patched bugs in PIM and Mobile IP.

Paul said:

I think I could not make my point completely clear.

To respond again:

#1 - "All" public facing networking services of your entity depend on IP. But I guess not all depend on either SSL, HTTP, PHP or VMWare. Probably a combination of the latter, but not all.

Point is: IP is so central in more or less all current services offered or used via computers, that I'd dare say it has a much higher exposure rate than any single one of the higher protocols.

And even if you counter that higher level protocols (or components) have a higher exposure rate than IP due to their, well, higher exposure to users, I'd still say that IP has a much higher severity factor than other services due to its central location in operating systems and business processes.

[However I have to admit that I have never done a full formal Risk Analysis by the book, of IP.]

#2 - Yes, there are probably bugs in PIM, MIP, and everything else. But I think it is valid to say all or most of your organization's "business" systems use IP. Probably not all use PIM, Mobile IP or what have you.

My point is: your complete network backbone and services depend on and interface with IP. Both routers, firewalls, security systems, and user workstations, servers and appliances. All of these have attachments to IP via their separate IP stacks, and in turn all of their programs have different attachments to these IP stacks. Now, with the transition you change all these attachments to new ones.

To summarize: I stipulate that with the transition from IPv4 to IPv6 you have a higher security risk than staying with only IPv4. This follows from the assumption that you change all of these attachments I mentioned vs. you change none of them when you would stay.

Derek Morr Author Profile Page said:

Yes, but to the best of my knowledge, there hasn't been an IPv6 implementation bug that affected every system. The bug I referenced in my post only affected BSD-derived systems (such as Mac OS X).

Even the RH0 bug didn't affect everything (IIRC, Solaris and OpenBSD weren't affected).

But I keep coming back to my earlier argument. We have thousands of desktops running Windows. We have hundreds of servers running Linux. There have been non-IPv6-related bugs that have affected all of those systems. Is that an argument not to run them?

Paul said:

But I keep coming back to my earlier argument. We have thousands of desktops running Windows. We have hundreds of servers running Linux. There have been non-IPv6-related bugs that have affected all of those systems. Is that an argument not to run them?

This does not invalidate what I was trying to say:

There are security issues running any computer system, and there will be risks in the transition of any large computer system to another.

The security risks which will arise during the transition would not arise if you'd just stuck with IPv4.

This is of course not an argument for staying in IPv4 world, but saying that the transition to and introduction of IPv6 in any network will not have serious security implications is very shortsighted if not plain false.

There certainly will be issues that otherwise would be not there.

Leave a comment