The coming IPv6 security disaster
Last week ARIN (the group who hands out IP addresses for the U.S., Canada and most Carribean nations) sent a letter [pdf] to organizations stating that IPv4 IP addresses will be depleted in two years. ARIN is encouraging everyone to prepare their infrastructure for it now.
Will IPv6 adoption be a disaster for information security? Of course it will: every new thing is a disaster: email, instant messaging, wireless, VOIP, mobile devices, social networks, e-commerce, cloud computing… and of course the granddaddy and still reigning champions of security disasters: web browsers and web applications.
We’ve all heard the “IPv4 is running out” admonition for a decade, but now it may finally be true. Still, most still see no business need for IPv6. Adoption will probably languish until it’s no longer feasible to acquire IPv4 netblocks, then IPv6 will be rushed into place without proper design, testing or understanding of the issues.
But IPv6 is not just another protocol or type of application. Nor is it just IPv4 with more numbers. Consider the following:
- Mandatory IPSEC (with all the associated crypto code)
- Mandatory multicast
- Mandatory QoS
- Automatic configuration of interfaces (DHCP replacement)
- All devices Internet addressable (no more NAT)
- Massive (up to 4GB) packet sizes
- Many new rules for routing, private addresses, DNS, packet analysis, fragmentation, and so on.
Lots of complex new code at the driver, network and application layers must be written to implement all the above. Like all new code, it will be buggy as hell for many years. But slowly the implementation flaws will get patched.
However, the above also means a fair-sized learning curve for developers, network architects, operation staff and security folk. If organizations just treat IPv6 like it’s IPv4 with more addresses, it’s going to be a mess for quite a while.
People, policy, standardds and procedures are not so easy to patch. RFC 4942 and a few other guides exist to help people get up to speed, but a lot of unlearning will need to be done. Cherished concepts like firewalls, NAT and IDS must be re-thought (heh… the Jericho folks finally get some traction 
.
Will large-scale rollout of IPv6 be a reiteration of the last 15 years? Are we about to see this century’s version of open ports, ping of death, source routing, IP spoofing, tunneling, cache poisoning, buffer overflows and denial of service attacks?
We defenders have a lot of learning and research to do: learn the new packet structure, fuzz every vendor’s IPv6 stack, test firewalls and IDS, add IPv6 capabilities to existing assessment tools and write many new ones.
(Speaking of firewalls: there are a disturbing number of products that handle IPv4 packets fine but either let IPv6 packets though, permit source routing or just overflow badly when they see a bad packet.)
The assessment tools are not there yet. For example, Nmap has had basic support for IPv6 for years, but only for simple connect() scans. Support in Nessus is similarly limited, and Nessus replacement OpenVAS can’t do IPv6 at all.
But evaluating the security of IPv6 implementations doesn’t just require an IPv6-enabled version of existing tools. The differences and new features in IPv6 mean we’ll see many new types of vulnerabilities, and need new tools to detect them.
As usual, expect the attackers to lead the way. Then expect the current cycle to continue: implementation errors will be ignored and disputed by the vendors then grudgingly patched, networks will be restructured, and ugly hacks will be invented to work around fundamental vulnerabilities in the protocol specifications themselves.
It’s going to be a great time to be in networking and security. I just hope it won’t take another 15 years to get back to where we are now.
7 Responses to “The coming IPv6 security disaster”:
May 9th, 2009 at 11:53 pm
Derrick –
I do agree that there’s going to be quite a bit of learning to be done with a full transition to IPv6. Luckily, it doesn’t have to be done all at once, but can be accomplished in incremental steps which allows the learning and acclimation to happen over time.
One good initial step is getting public facing web and email servers enabled with an IPv6 address in addition to their IPv4. This makes more resource available via IPv6 for everyone, thus reducing the load on translation devices. Additionally, it provides for a relatively manageable amount of IPv6 work, and work that can occur predominately outside any organizational firewall and thus limits the initial security exposure as well, while we wait for vendors to catch up, etc.
Excellent article!
/John
May 10th, 2009 at 12:15 pm
@John Curran:
Thanks for the comment. I agree… rollout of IPv6 could be done incrementally. And I sincerely hope that how most organizations will do it.
Sadly, historically most new things get slammed into place with little or no oversight. Especially now that profits are down and staff have been cut, I think a non-sexy, forward-thinking plumbing-level project like IPv6 rollout is unlikely to get much attention in most organizations.
It would be nice to see more IPv6 capable web and mail servers, but I’d be reluctant to start with public-facing services for an IPv6 rollout. We don’t yet have good knowledge of the vulnerabilities involved, nor how to detect and prevent IPv6-related attacks. I think implementing internally first has a lower risk, plus allows staff more time to get up to speed and (to some degree) more room for error.
May 22nd, 2009 at 12:40 pm
The biggest potential security disaster is the fact that you need to open for ICMP packet too big packets in your firewall. There is no more fragmentation so intermediate routers need to be able to signal back when a packet is too big for them to handle.
And you cannot do any stateful firewalling on the incoming ICMP packets, as there is no associated outgoing packet that triggered the firewall to keep the state. My advice so far is to always use the lowest MTU (1280) and just block all ICMPv6 Packet too big.
So a bug like the recent ICMPv6 bug (see http://ipv4depletion.com/?p=209) found in MacOS, becomes really nasty. Especially when you realize that the ICMPv6 handler probably runs in Kernel mode.
May 22nd, 2009 at 1:24 pm
@Stephan Lagerholm:
Thanks for pointing that out. This is a great example of a combination of implementation error and change in the protocol itself that IMHO we’ll be battling often.
May 23rd, 2009 at 2:56 am
Thank you for the level-headed article. I linked to this article from APNIC’s ICONS IPv6 Wiki site (http://icons.apnic.net/display/IPv6/Home) to share your useful heads-up with the wider community.
Some of the AP NOG communities (e.g., JANOG – Japan Network Operators Group) are discussion the exact topic how to handle ICMP packets while implementing IPv6 networks. I think establishing a set of IPv6 security BCP will be very helpful.
May 26th, 2009 at 1:09 pm
@Miwa Fujii
Check out rfc 4890, I don’t agree with everything in there (for example the packet too big) but it is a good start.
/S
June 3rd, 2009 at 1:01 pm
I consider IPv6 as an improved Internet Protocol. Layer 4 and high-level stuffs are very much the same. IPsec isn’t new. Multicast is a leaner, QoS isn’t an IP issue but the routing, Auto-configuration is not necessarily replacing stateful interface configuration using DHCP, not all devices must be globally reachable (you can use ULA), use of jumbo jumbo frame must be coupled with PMTU discovery. Yes, there are new rules; But I don’t see how we can get into a lot of troubles.