November 2008 Archives
Every now and then, I read an article claiming that IPv6 poses some sort of grave security threat by its mere existence. I had such an encounter this week, which prompted this entry.
IPv6 is not a serious security concern at the moment.
There are a few security arguments against IPv6. I think both are strawmen:
- There are security bugs in IPv6 implementations, so we should block IPv6 and disable IPv6 code.
- Users can setup IPv6 tunnels and bypass network security devices (firewalls, IDS, etc), so we should block IPv6 and disable IPv6 code.
Of these, I put some credence in argument 2 and discount argument 1 entirely.
As for argument 1, yes, there have been security bugs in IPv6 stacks. There are security bugs in most software, and we deal with them. We promptly patch affected systems. There are far more bugs in web browsers, mail clients and PHP than in an average IPv6 stack. For example, this year, FreeBSD has issued 11 security advisories, only 2 of which were related to IPv6. If you include the ports collection, the statistics look even better. There are similar results for IOS. I'll put those stats up against most other software packages any day. And most of the IPv6 vulnerabilities are far from serious.
If users were seriously concerned about end system security, they'd be wiser to turn off Flash than IPv6.
I have no doubt that as IPv6 is more widely deployed that more bugs will be discovered. We'll deal with them the same way we deal with every other security issue. Nevertheless, IPv6 bugs sure do make the headlines, even if they are relatively minor compared to some other bugs.
Argument two can be dealt with even easier: If you don't want users creating IPv6 tunnels, block the tunneling protocols on your firewall. This is pretty straightforward, but the press loves to hype up the supposed danger. (By the way, much of the tunnels-as-security-hole concern surrounds Teredo, which is only really used on Windows and is disabled by default if Active Directory is used.)
And, so, users are frequently told to turn off IPv6. This is extremely frustrating, since the more places it's turned off, the harder (and hence more expensive) it will be to turn it on when we're out of IPv4, which will happen in a few years. Rather than turning off IPv6 (read: sticking our heads in the sand), we should update security software to support IPv6. There are several relevant standards here:
- RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls
- RFC 4942: IPv6 Transition/Coexistence Security Considerations
- Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service (IETF draft).
- NSA Firewall Design Considerations for IPv6
- NSA Router Security Configuration Guide Supplement - Security for IPv6
There has been progress updating security software to handle IPv6. Most OSes come with IPv6-aware firewalls (and some OSes even enable them by default). Snort has very rough IPv6 support, but the next release will significantly improve that. Nessus also supports IPv6.
But along with software, we also need an education campaign to inform sysadmins about IPv6. Many of the security issues are the same as for IPv4, but there are some significant differences. I think this will be the most difficult part; changing software is a lot easier than changing attitudes.
Let me illustrate this with an example:
OS X comes with two firewalls (ip6fw and the app firewall), both of which support IPv6. Last month, I saw an article in Macworld comparing third-party software firewalls for Mac OS X. I posted a comment asking if anyone had checked these products for IPv6 support. One of the vendors posted a response:
DoorStop X supports ipv6 in what we feel is the safest way possible -- by default it fully disables any access from ipv6 machines. Right now, for almost all users, ipv6 is simply a potential security vulnerability with no real advantages....
This is precisely the attitude I'm discussing. This particular vendor has a history of slamming IPv6 on alleged security grounds. Yet, strangely, they've never recommended that users uninstall Flash or quit using QuickTime, both of which have had far more security holes than IPv6.
As best as I can tell, their product just shells out to ipfw(8). Rather than disable IPv6, why not also shell out to ip6fw(8)? This certainly wouldn't be perfect, but it's a reasonable first step for IPv6 support, and should be trivial to implement.
None of this is to say that there aren't attacks taking place over IPv6. There are. But for the moment, IPv6 is a tiny attack surface compared to IPv4. We should take advantage of this situation to get our ducks in a row.
Many manufacturers support IPv6 in their products, but charge extra for it. Cisco, for example, makes customers purchase more expensive feature packs for IOS to gain IPv6 support. This is starting to change.
Cisco is phasing-out their "IPv6 for a premium" policy. They're now offering IPv4 and IPv6 features in the same feature packs. This policy is starting with the Catalyst 6500 series, but will be expanded to other product lines throughout 2009.
Cisco is ... offering packaging parity for IPv6 with IPv4 such that IPv6 feature support for a technology will be packaged in the same feature set as IPv4. For example, IPv6 feature support for BGP will be packaged in IP Services where BGP for IPv4 resides today. This new IOS packaging for IPv6 is starting on Cisco IOS Software Release 12.2(33)SXI, and will get propagated to other IOS release trains in future.
Last night, the .edu domain got IPv6 glue in the DNS root. I'm thrilled beyond words at this.
Most top-level domains (e.g. .com, .org, .uk) already have IPv6 glue. I'm glad Educause made this step. It's been a long-time coming.
Educause operates .edu under contract from the US Department of Commerce. In turn, they sub-contract the day-to-day operation to Verisign, which also runs the .com and .net root servers. From what I understand, Verisign is migrating .edu over to the .com and .net cluster, which will give .edu IPv6 support.
Educause has allowed subdomains to register IPv6 glue for a while (psu.edu has had IPv6 glue for at least year). The DNS root got IPv6 support earlier this year. But .edu was always this big v4-only gap in DNS. I'm really happy that it's being fixed.
AMS-IX, the Amsterdam Internet Exchange, is the largest public Internet exchange in the world. Today, their native IPv6 traffic crossed 1 Gbit/sec:
It was only a temporary peak, but it's still a milestone. Congrats.
KanREN, the Kansas Research & Education Network, is doing a lot with IPv6. As best as I can tell, they're the second Internet2 member to have IPv6-enabled web, email and DNS services (3Rox was first). So, hat's off to them!
This is particularly relevant, since two more IPv4 address blocks were allocated today (blocks 110 and 111, to the Asia Pacific registrar). Only 14% of the IPv4 address space is unallocated.
It's been a busy week for IPv6.
On Tuesday, the Squid web cache announced a beta of version 3.1, the first with IPv6 support. For those of you using Squid 2.x, there are plans to backport this code to release Squid 2 (the work will be spread between 2.8 and 2.9). This has been a long time coming — the code was merged almost a year ago. Given the dearth of IPv6 deployment, dual-stacked web proxies will probably be important during the IPv6 migration.
On Wednesday, UCLA IPv6-enabled its web site:
As far as I know, UCLA is the first university in Internet2 to take this step. Congratulations!
On Thursday, there were several code commits to FreeBSD to remove IPv4 dependencies. The goal is to let the kernel be compiled without IPv4 support (one can only dream of such a day).
Also, RIPE (the Regional Internet Registry for Europe, Middle East and parts of Asia) published the slides from its meeting last month in Dubai. These were several excellent talks. Several European Internet Exchange Points showed growth in the number of IPv6-enabled customers.
Etisalat, a large Middle East telco, discussed their IPv6 deployment, which has been underway for most of the decade. They're motivated for the usual reasons: The significant increase in Internet-attached devices is exceeding NAT's usefullness. I found it interesting that they've required IPv6 support in new equipment purchases since 2001! I'm really hoping that Penn State adopts a similar policy soon.
Google presented two talks on its on-going IPv6 trial. As a refresher, Google doesn't see NAT as a long-term solution to IPv4 address depletion. In fact, they claim that excessive NAT will have significant negative impact on common web apps. So they've run an IPv6 pilot since March. So far, the results are very encouraging: Only 0.09% of users have broken IPv6 connectivity.
I'm glad to see that Google (among others) is actually gathering empirical data on IPv6 usage, since there is a lot of FUD about there that IPv6 will cause all sorts of breakage. To quote Google, "It's not that broken... don't believe the FUD."
Having said that, things are not perfect. IPv6 routing is often sub-optimal (to be polite). Gert Doering presented on the state of the IPv6 routing table, as asked "Why does traffic from Germany to Germany get routed through the US and Hong Kong? He showed an example of a user in Munich accessing a server in Frankfurt. The traffic went across the Atlantic to Washington, DC, across the continental US to Chicago, then Seattle, then across the Pacific to Hong Kong, then finally back to Germany. This has got to stop.
Google also sees these sort of problems. They had an example of traffic from Virginia to Virginia being routed through Amsterdam. All of this adds significant latency to IPv6, making users disinclined to use it. Fortunately, we know how to fix the problem: We need to start filtering IPv6 routes. We've done this for IPv4 for a while, and it's time to do the same for v6.
So that's the week in IPv6. There was a lot more covered at RIPE-57. I'll blog about that later.