The Perimeter Problem
Back to security. One thing that quickly becomes clear when rolling out IPv6 is that network systems themselves are the easy part of the project, so much so that it's become accepted wisdom to start a deployment in the center and work outward. Difficulties present themselves in greater numbers as you make your way toward the network edge, where users are connected to services. Envision a "core-to-edge" deployment strategy with your IPv6-enabled network in the middle, surrounded by concentric perimeters of services. Closest to the center are the services essential to the fundamental operation of the network: DNS, DHCP, and the like. Around that perimeter are the services necessary to both manage the network and provide support: Think configuration management, change policy enforcement, monitoring, alarming, and logging.The outside perimeter comprises your security bulwark: firewalls, access control lists, intrusion detection and prevention systems, and the policies enforced by them. The order in which systems are tackled under this model reflects the current v6 readiness of our systems.
If your company lists support for IPv6 among the must-have criteria when purchasing new security gear, you're ahead of the game--and likely frustrated that there isn't more such gear available. While network architects have long had a wide variety of IPv6-capable routers and support systems to choose from, security products have lagged the rest of the industry. Incredibly, until recently, relatively few firewalls had useful IPv6 capabilities, and there are still significant limitations.
We hear all the time that IPv6 is intrinsically more secure than IPv4. This misconception likely springs from the fact that support for authentication and encryption is integral to the IPv6 specification. Problem is, a capability called for in a spec does not necessarily translate into a capability that works in an actual network. In fact, our experience shows that few IPv6 implementations provide "built-in" authentication and encryption, and end-to-end IPv6 sessions are not automatically secured. Again, a limitation of vendor implementations of the specification.
Another facet of the IPv6 security myth stems from characteristics of the protocol that, while not directly security-related, do have security implications. For example, you'll often hear that IPv6's huge address space makes it immune to port scanning. Assuming a port scanner could "hit" one address per second, a scan of the entire address space of a 64-bit subnet would take upward of 584 billion years. That's an impressive stat, but it ignores the fact that smart subnet spies are already selective about the ports they scan and predictive about the IP addresses they target. Yes, port scanning is more problematic on a typical IPv6 subnet--for both snoops and for your own security team--compared with almost any IPv4 subnet. But stating that IPv6 is immune to scanning is just plain wrong.
And don't assume that because most network engineers aren't yet familiar with IPv6, the bad guys aren't either. In fact, as we discuss in our full report, the opposite is true: There are black hats out there who see IPv6 as a once-in-a-lifetime opportunity. So much new code, so much time to probe for flaws.