Quote:
There’s a lot to consider (too much to mention in one sitting) but here are several things that will ring a bell for those familiar with IPv4:
Poor implementation and misconfiguration - When things go wrong, it’s almost always at the implementation level. Even though many elements of IPv6 will be familiar from IPv4, we’re going to be treading on an immense amount of new territory, and this lack of experience could do us in, if we don’t make strides in education; this is especially crucial for those who will be involved in the configuration process.
IPv6 may be full of promise, but all that matters is what it looks like in a real world environment, and if you get the configuration process wrong, you can effectively negate any enhanced security features.
Flooding attacks - Due to IPv6’s massive address space, it would take years to scan a single IPv6 block, versus seconds for an IPv4 block. You might think that this would prevent flooding attacks, but you’d be wrong. Thanks to multicast traffic, which allows you to send a packet to multiple destinations with a single send operation, distributed denial of service (DDoS) attacks, like smurf, are possible.
With a smurf attack, a type of broadcast amplification attack, a victim’s IP address is used to send an echo-request message with subnet broadcast’s destination address, along with a spoofed source address, causing all of the subnet’s end hosts to respond to the spoofed source address and flood the victim with echo-reply messages.
Dual stack attacks - The Internet is mostly IPv4 based these days, but we’re going to see an uptick in the number of IPv6 compatible networks. During this lengthy transitioning process, “6to4” stacks will take care of this, by implementing IPv6 and IPv4 separately, or in a hybrid manner, which allows applications to work transparently over both IPv4 and IPv6. However, now you’re dealing with two non-interoperable protocols and their specific sets of security issues. This leads to more technical complexity, which will make configuration even harder and more prone to failure.
Spoofing attacks - The modification of a source IP address, as well as the ports on which they are communicating, can be done to make it appear as if traffic originated somewhere else. There are best practice methods for filtering, as in RFC 2827, but this isn’t mandatory, which means many ISPs won’t implement it.
The use of strong cryptography can thwart these attacks. On the other hand, even though IPSec support is mandatory on IPv6 (whereas it was optional for IPv4) it’s likely to experience the same hurdles as with IPv4 and not be widely deployed.
Header manipulation and fragmentation - Attacks exploiting header manipulation and fragmentation can do everything from bypass intrusion detection systems (IDS), intrusion prevention systems (IPS) and firewalls, by using out-of-order fragments, or even go after the network’s infrastructure itself. Also, in IPv6, you have extension headers, which can be used to get around access control lists (ACL) on routers and firewalls, by causing devices at the end host to process router headers and forward them elsewhere.
Obviously, the concerns above are just a snapshot of what we’ll face when IPv6 sees a wide rollout. Right now, it’s a game of testing, testing, and more testing.
Quote:
World IPv6 Day will give us a better idea of what we’re up against and how this will change the security landscape for the applications and protocols we currently have in place. Industry leaders like Facebook, Google, Microsoft, Yahoo, and Cisco are all participating in this first test run, organized by the Internet Society.
Since the federal government has set its own requirement to have government systems on IPv6 by the end of 2012, this sets a fast schedule for the rest of the industry. Given just how little we know about what’s to come with an IPv6 Internet, the industry must move quickly to prepare itself for the coming transition.
