Security in the age of IPv6

As a follow-up to my last article, I thought I'd briefly cover security and the approach IPv6 encourages. Let's review what we currently do, and how IPv6 requires a different approach.

Secured networks, the IPv4 way

In IPv4, security is generally based on networks. A network is subdivided into smaller networks, each having a particular profile, and then firewalls sit between those networks filtering traffic. A typical office will have two or three subnetworks:

• A so-called "DMZ". This used to describe environments in which all traffic to particular "real" (Internet routable) IP addresses would be routed to machines unchanged, although today generally it describes only a situation where there's a one to one mapping with "real" IP addresses and machines on the inside, but usually many levels of filtering are used to restrict traffic going to these machines. The DMZ contains the externally accessible servers - if you run a website, for example, or a server to receive email, these will usually be on the DMZ. 
• A group of internal servers. These aren't usually on a network of their own, but it's not uncommon for them to be. Usually they're part of the main internal network, described below.
• The main internal network - this is where the PCs are. Computers on this network have limited access to the outside world, and outside devices cannot initiate connections under any circumstances to the PCs. NAT is almost always used, which means that it's difficult to even identify PCs on this network.

These networks are generally not just firewalled from the Internet, but also from one another. The configuration is usually such that the machines can all "see" one another, but the firewalls block certain types of access.

This set up is popular for a number of reasons. The shortage of IPv4 addresses makes NAT all but mandatory, and so much of this configuration would be required even if security was not in the minds of the network administrators.  In some ways, then, security has been implemented almost as an afterthought. The critical security element in this mix is the firewall. The firewalls, and not anything else, are the key element that defines who can talk to who, and what they can say.

But... but there's a problem with this approach. It's not very fine grained, and in any case, the Internet is constantly advancing, and technology is constantly advancing, and the end result is that people are constantly looking for ways to bypass the rules to get their jobs done. Some of these have been fixed in official ways: working from outside the network, for example, has been solved in a variety of ways, most of which are fairly ugly. Others have been solved by programmers, not administrators, and arguably have undermined security as a result. As an example, virtually all new ways to have one machine talk to another involve a system of making the communication look like web access. Why? Because web access is usually not firewalled.

And while this technique provides some degree of protection against external attacks, it doesn't protect against problems once inside the network. A computer virus can quickly infect all of the other computers on its own subnet as there's nothing to stop it.

One way to improve security is to stop trying to use external filters, and to instead secure each and every machine. You configure each computer to only accept legitimate connections to legitimate applications. In IPv4, that's a nightmare, and arguably impossible. Not so in IPv6.

How IPv6 changes everything

IPv6 is somewhat different from IPv4 in its approach to security. Let's look at the key elements:

1. Two way routing. A machine receiving a connection from any address knows that it can make a connection back to that machine, and thus that that address identifies a specific device.
2. Universal encryption. Using IPsec, mandatory in IPv6, two computers that know one another (possibly using a third party key server) can negotiate an encrypted connection. Encryption achieves two goals: first, it prevents a connection from being spied upon by a third party. And secondly, it helps validate the integrity of the incoming data. Unless the key exchange itself is compromised, both computers can be reasonably sure they're talking to the computers they think they're talking to.

Put these together, recognize that most operating systems now include "Software firewalls", and add a mix of key servers and systems like Kerberos to help identify and validate users and computers, and you have a network that's possible to maintain centrally, but with a finer, more targeted, form of security than you could hope to achieve under IPv4.

In this environment, it's no longer necessary (or even advisable) to put in firewalls and strip down the network into subnetworks. Employees who work from home can log in using Kerberos (Active Directory) and access all of the servers they're authorized without needing to implement any special "hacks" like VPNs. Two companies who need to transfer data securely and confidentially can identify the specific computers in their organizations that need that access and authorize them - without opening up holes that anyone in their organizations can use. And internal breaches, whether from bad employees or computers outside of your universal control, are no longer a problem.

This technique also opens up a host of other possibilities. Using a third party server, a "cloud" service, today can raise security and configuration questions in an environment in which such a server may need to communicate with your servers, but belongs on an external network. In IPv6, the external server can be treated as just another server on your network.

All in all, IPv6 should help improve security. Are there downsides? Well, there are some:

• The main one is that IPv6 addresses can be used, to a certain extent, as a way to identify traffic that previously would be considered anonymous. For example, apparently unrelated organizations (let's say friendbook.com, professionallinks.com, and blackmail.com) could exchange server logs, with blackmail.com able to link people and what they've done to their personal profiles using just the IP address. To me, this is overblown - not because it's not a legitimate concern, but because it's already the case that simple IP address analysis will already collect a large amount of data targetable to one or two people, especially when combined with cookies and browser data.
• Bugs in TCP/IP stacks. This is less of a problem than it was, but if you're going to rely upon computers doing most of their own traffic filtering, then those computers have to be built so that their security systems are not circumventable. In the past, fortunately the distant past, bugs in the network systems themselves were an issue. Famously, early versions of Windows 95 could be crashed just by sending malformed data.
• Unfamiliarity. IPSec has been a standard for a long time now, and has been effectively "back-ported" to IPv4, and it's still not in widespread use. People just don't know what it is or how to use it.
• Immature tools: regardless of whether the security is at a firewall level or placed on the machines that deal with the traffic to begin with, system administrators are going to want to centrally manage the security of all of the computers in their domain. This is easier said than done. As I've said before, centralized, domain based, security is still poorly implemented outside of Windows, and there's a lot more that needs to be administered in this environment.

IPv6 has the potential to revolutionize security, improving productivity while locking down private information to a degree never seen before. But it has to be understood, and operating system vendors in particular need to work on making sure they're ready. It's not enough simply to be able to route IPv6 packets - and believe me, with so many applications still IPv4 only, even that's still on the major vendor's to-do lists, it's also a matter of creating the tools necessary to fully administer a modern, secure, IPv6 network. What we have to hope is that this comes soon.