I’m very pleased to publish this article on IPv6 security from IPv6 evangelist and guru Paul Ebersman. In it, he provides an excellent summary of the key differences between security in IPv4 and its eventual replacement.
We’re always interested to hear what IPv6 issues you’ve run into so be sure to leave a comment regarding your own experiences with IPv6 security. Also, be sure to follow Paul on twitter: @Paul_IPv6.
Thanks for reading!
Tom
If you’ve started looking at IPv6, you will undoubtedly have hit various articles talking about security and IPv6, predicting doom and gloom and recommending that you avoid it, disable it, etc. They make vague claims about all sorts of new problems, point out that it’s not widely deployed and claim to be prudent. So what’s the reality?
The reality is that IPv4 still has design flaws that can be vectors of attack and there are a lot of issues with the original design that really could use a re-write. And after 30+ years of deployment, we’re still finding new problems. That said, the internet and private TCP/IP networks are all getting real work done in a useful and predictable fashion. Obviously, these issues doesn’t make IPv4 unusable.
IPv6 took the lessons we learned from IPv4 and is an attempt to improve on IPv4. And it is an improvement. Not perfect, but an improvement. Yes, there are issues and yes, we’ll find new ones as we all deploy IPv6. But as with IPv4, we can still build safe, reliable networks and get real work done with IPv6.
If you start to poke under the hood, you’ll find that most security issues with IPv6 fall into the following categories:
– same problem/exposure as IPv4, just with a different name – actual new issues due to the redesign – FUD. folks using fear, uncertainty and doubt to scare you
Improvements
Lots of space: The recommended subnet size is a /64, which gives you 18 quintillion addresses. Trying to brute force scan this with pings is useless, so if you truly randomize your address assignments across the entire /64, bad guys can’t find your hosts with pings. Less noise: No more broadcasts and more focused multicasts means more of your bandwidth is doing real work (data). ICMPv6: ICMPv6 is much more closely specified as to type, so you can control what you allow via ACLs much more precisely. RA Guard: DHCPv4 doesn’t have a good, standardized way of preventing rogue DHCP servers (see next section). With IPv6, we have RFC 6105 RA guard.
Same same
ARP cache poisoning: ARP cache poisoning in IPv4 allows for various local network chaos, including man-in-the-middle attacks and denial of service attacks. In IPv6, we no longer use ARP to map MAC addresses to IP addresses; we use ICMPv6 neighbor discovery. Each host keeps this info in a neighbor cache, which can also be poisoned. The technique is different (ICMP vs ARP) but the hosts that can do it, what problems it causes and how to fix it are quite similar.
Ping pong attacks: Point to point links between routers can be flooded, causing a forwarding loop. We don’t tend to see that much in IPv4 because we have had a scarcity of addresses long enough that we tend to use /31s for the point to point link, which eliminates the problem. If you don’t use a /127 for IPv6 p2p links, you’ll be vulnerable to these ping pong attacks (see RFC 6164).
Rogue DHCP: In IPv4, if you have a rogue DHCPv4 server telling all the clients that it is the DHCP server and giving them a default route via a router or host the bad guy controls, you wind up with a denial of service or man-in-the-middle attack. In IPv6/DHCPv6, the DHCP server no longer gives out the default route. However, the RA (router advertisement) messages which give out the default route can be spoofed with a rogue RA, resulting in the same problems as a rogue DHCP server in IPv4. RFC 6105 is a standardized way to protect clients against this.
Actual new problems
Extension header chains: IPv6 standardized and shortened the first part of the IPv6 header and put the additional information into the extension headers section. This makes it easier to write routing code. The issue is that there are not limits on how long the chains can be. This means if the bad guy knows you are doing deep packet inspection on your firewalls, he can grind them to a halt just by sending packets with artificially long extension header chains. See IETF draft draft-ietf-6man-oversized-header-chain-09. [Also, see the recently published RFC 7112 “Implications of Oversized IPv6 Header Chains” -Tom]
Header fragmentation: IPv6 only requires intermediate hosts/routers to be able to handle packets of 1280 bytes. If a bad guy is playing with extension header chains, he can construct packets with just the header being large enough that packets fragment in ways that might result in either packets being dropped or misinterpreted.
Atomic fragments: Another fragmentation attack which could result in packets being misinterpreted or dropped. See RFC 6946.
FUD
In my experience, if a vendor is telling me all the reasons why IPv6 is the sign of the apocalypse, evil incarnate and that I should disable it everywhere or at least live in fear, I’ve found that either:
– they don’t have an IPv6 solution in their product but a competitor does – they have a security solution they’re trying to sell
So what should we do?
At a minimum, get IPv6 in your lab, train your staff, test all your apps and work with all your vendors on getting IPv6. If you can, start rolling out IPv6 in a dual stack mode with IPv4 and start testing IPv6 only to find out what things you need that aren’t ready yet. Especially test with your security and perimeter devices and software. Rolling out IPv6 with no security is about as safe as rolling out IPv4 with no security…
Once you have some experience in the lab, figure out how you are going to monitor and log. If you can’t see problems in IPv6, you can’t use it in production.
When you are able to monitor and log and you have someplace in your environment where IPv6 meets your needs, roll it out there. Then, piece by piece, roll it out everwhere.
But, if you don’t start testing and training, you will be left behind as the internet migrates inevitably towards IPv6 and away from IPv4.
-Paul Ebersman
