Q&A: Things to consider when it comes to IPv6 and security (Part III)by Steve Ragan - Jun 9 2011, 00:24
The Tech Herald (TTH): What are the top five security problems that IPv6 has the potential to create?
Tom Daly (TD): IPv6 brings the unknown to network administrators and architects. While IPv6, in implementation, is simply an IP numbering space of a larger size, the reality of it is that it requires a complete overlay network to work properly. This means network administrators have two networks to manage.
With a larger IP numbering space, it means that networks are much more vulnerable to large scale IP scans, which can cause certain types of DoS issues on legacy equipment. Network administrators need to strategically pick the right subnet sizes to maximize the benefits of IPv6, while anticipating the threats that come from these types of remote scans.
The best route for IPv6 deployment is native IPv4/IPv6 dual stack, but there are multiple transition technologies that exist such as NAT64, DNS64, 6RD, 6to4, and DS-Lite to help bridge the gap between IPv4 and IPv6. As with any technology, these transition technologies have their own quirks and complications to deal with, each of which could cause a security issue.
There's threats that emerge due to the design of certain pieces of networking equipment. Years ago, most networking equipment relied on software based packet routing and forwarding. With the significant increase in IPv4 traffic over the past 10 years, most manufacturers have developed hardware based routing and forwarding planes in their equipment for IPv4 to handle the amount of traffic that now runs through these devices.
In some cases, but not all, manufacturers have left the duties of IPv6 routing and forwarding back in software based planes, which creates the potential for IPv6 network congestion, latency, and/or DoS.
Lastly, there are some pieces of equipment that claim to handle IPv6, but in operation, they do not properly handle the protocol, and could potential leak information (think of a firewall).
IT purchasers need to be mindful of this when selecting equipment to purchase, and should always be asking their vendor for an IPv6 certification test from an independent laboratory.
TTH: What can administrators do to address these problems?
TD: I think that it boils down to practice, practice, practice. As with anything, technicians need to feel comfortable and acclimated to the equipment, technology, and methodologies they are using day to day.
It's similar to riding a bike - its something people just get comfortable with, and can repeatedly execute. The same is true in operating networks, practice makes perfect, and companies should be focused on deploying IPv6 in lab environments, training and practicing with their teams, and then drilling for security events. Once comfortable, begin deploying IPv6 to production.
TTH: What should administrators consider when deploying IPv6? What are some of the best practices you recommend?
TD: Most importantly, keep in mind that an overlay network is being deployed, parallel to the IPv4 network (unless certain transition technologies are used). This means that everything you do for IPv4, you need/should be doing for IPv6 - this means ACLs, firewall configuration, monitoring, alerting, and capacity planning all needs to be considered for IPv6 as it is for IPv4.
There are a number of best practices around the deployment of IPv6, and one of the most simple techniques is to map your IPv6 space on top of your IPv4 space. Given that IPv6 gives us 64 bits for networks, and IPv4 only occupies 32-bits, we can encode IPv4 addresses into IPv6.
So, for example, if your webserver is numbered as x.y.z.37 in IPv4, number it as X:Y:Z::37 in IPv6. This makes it easier for administrators to correlate functions in the IPv6 network to functions in the IPv4 network.
TTH: How will reputation-based defenses be hurt by the flood of available space on IPv6?
TD: Severely. The adoption of IPv6 has not been taking place at the same rate we've been using IPv4 address space, and so in many cases, there is NO reputation for IPv6 addresses yet.
This means that all IPs in IPv6 are neutral, yet we know that not all organizations who take IP space are equal. Certain correlations between IPv4 reputation and issued IPv6 space may need to be made in order to seed the databases for these types of defenses.
Additionally, there's no well agreed upon subnet boundary in IPv6 like there is in IPv4. In IPv4, if you see bad behavior from a number of IPv4 addresses in the same /24 block, its generally safe to assume that the entire /24 block could be used for malicious purposes, and many reputation services will list an entire /24 as a result.
At most, only 256 IP addresses affected using this technique. In IPv6, where is the boundary? /64? /56? And how many potential end hosts can be blocked when a subnet based listing is made?
TTH: What are your predictions for dual stack networks, and how do you think criminals will leverage this to target organizations and users?
TD: Criminals will use any means possible to harm organizations today. Dual stack networks present an additional hurdle to administrators and security specialists - namely another parallel network to manage and secure.
Additionally, with IPv6 traffic being such a small amount of traffic in production networks today, the ability to identify an anomaly in that noise decreases. IPS and IDS devices may not be up to the task of classifying and alerting on IPv6 traffic when being "blasted" with all of the noise in IPv4. This gives bad guys an opportunity to "fly under the radar" by penetrating networks via IPv6.
TTH: What are some of the things Dyn is doing to strengthen defenses as IPv6 is deployed?
TD: The key thing at Dyn is that we are NOT using IPv4/IPv6 transition technologies in our high bandwidth / high packet rate channels, specifically, for DNS and application servers. We're running native dual-stack IPv4/IPv6 through most of our network, and are managing the two networks as two separate networks, to ensure they are secured, monitored, and managed appropriately.
It means that every function we perform for our IPv4 network, we're duplicating to support our IPv6 network. It's likely the most complex way to go, but we know that it is the most optimal for delivery of services to our customers.