Seven Security Policies for the IPv6 Network of the Future

By Paul Rubens | Nov 19, 2010 | Print this Page
http://www.enterprisenetworkingplanet.com/netsecur/article.php/3914091/Seven-Security-Policies-for-the-IPv6-Network-of-the-Future.htm

The switch from IPv4 to IPv6 will force many organizations to rethink the way their networks are defended. The result will be a shift away from the "guilty until proven innocent" attitude to incoming network traffic, toward one of "paranoid openness."

That's the view of Eric Vyncke, a Distinguished Engineer at Cisco Systems. Talking at the RSA Conference in London last month, he said that it is only when organizations become more open to incoming traffic that they will get the full benefits of IPv6 .

Many companies have delayed thinking about a move to the next generation IPv6 Internet protocol because there is little benefit in being a "first mover," but sometime in the next few years the remaining free IPv4 IP addresses will be used up. When that happens the world will be forced over time to move to IPv6, which offers 128 bit addresses (instead of IPv4's 32 bit addresses), resulting in a staggering 2 ^ 128 different possible IP addresses . That's more than enough to assign a unique IP address to every atom on the surface of the earth, let alone every network connected server, desktop computer, laptop, smartphone, Web camera, and any other device that will ever be manufactured and connected to a corporate network. The benefits for many organizations of this end-to-end IPv6 connectivity could be very significant indeed.

The security benefits of NAPT

Before thinking about the security implications of this, let's take a look at how key parts of network security work with IPv4. Typically an enterprise will have a number of machines on the corporate local area network (LAN), all assigned local IP addresses. These sit behind a firewall, and share a limited number of public IP addresses using network address translation (NAT ), or, more accurately, network address and port translation (NAPT). There'll also be an Intrusion Prevention System (IPS ) to handle layer 5, 6, and 7 attacks, and possibly an application firewall as well.

The benefits of NAPT are that it provides plenty of individual private IP addresses for all the devices on the corporate LAN, and it also provides security for these devices. That's because the devices on the LAN can't be addressed (and therefore attacked directly) by anyone outside the firewall. Further, since every device inside the firewall is "invisible" to potential attackers on the outside, it makes attacking them very difficult. It's only by getting inside the network that an attacker can carry out reconnaissance, scan the network and build up an idea of its topology, and potential weak points to attack.

That's conventional thinking anyway, but does NAPT really provide that much security? It can certainly block connection attempts originating from the outside, but no more than a stateful firewall, Vyncke points out. And in any case there are ways of bypassing NAPT and getting to a machine with a private IP address, for example using reverse tunneling, or an external broker in the way that Skype does.

And as far as obscuring the network topology behind the firewall, techniques such as counting ID fields or TCP timestamps, or analyzing TTL or email RC 882 headers exist which can help an attacker shed light on your network setup, Vyncke adds.

On the negative side, NATP makes it much harder for you to carry out network forensics to see which devices have been responsible for what external activity. And many types of attack (such as phishing) are actually initiated by users inside your firewall unwittingly downloading malware into your machines. NAPT provides no protection from this. Once machines have been compromised with malware, it is fairly simple for an attacker to scan your network from the inside using standard reconnaissance tools such as Nmap.

Why's IPv6 Better?

So what has all this got to do with IPv6 security? It certainly raises the question of whether any form of NAPT is desirable. If you get rid of it, you have the potential benefit of end to end connectivity between any arbitrary device on your network and any external device - because with IPv6, remember, every device can have its own unique IP address because there are so many to go around.

And getting rid of NAPT with IPv6 doesn't really make your network less secure by making its topology visible to attackers. That's because default IPv6 subnets have some 2 ^ 64 addresses on them, so even at a rate of 10Mpps it would take more than 50,000 years for a hacker to complete a scan (and Nmap doesn't even support ping sweeps on IPv6). That's not to say that hackers won't be able to carry out reconnaissance on your network - it just means that they'll have to use other means, like DNS records or the examination of logs or netstat data on compromised machines, to find other machines to attack.

Vyncke's conclusion is that since NAPT offers little or nothing in an IPv6 environment, organizations should abandon it to ensure they get the maximum benefit from the huge new address space. And that means that rather than stopping all external traffic from entering the network (with a few exceptions such as web server traffic) he suggests allowing all traffic in once it has been checked or, as he puts it, a policy of paranoid openness.

Traffic checking would have to be carried out by a number of systems, Vyncke suggests. These would include some sort of IP address reputation system which checks traffic and blocks any coming from an IP address with a low reputation score, and an intrusion prevention system with dynamic signature updating.

The Secure IPv6 Network of the Future

A default enterprise security policy could be based on the following seven rules suggested by Vyncke, adapted for your organization's particular needs:

  1. Reject packets with bogus source addresses by applying unicast reverse path forwarding checks .
  2. Block any traffic from (or to) IPv6 addresses with a low reputation score.
  3. Inspect outbound traffic and allow returning traffic matching states, but only after it has gone through the IPS on the way out and back, to detect any botnet traffic or malware inadvertently brought in by a user (perhaps as a result of a phishing attack)
  4. Allow inbound traffic to an address which is listed in a public DNS with an AAAA record (which translates a host name to its IPv6 address.)
  5. Block any traffic to an internal address if that address has never sent any traffic outside the corporate boundary. This is to protect internal devices such as printers which should never be accessed from the outside.
  6. Intercept all inbound SSL/TLS traffic, decrypt it with a self signed certificate, and view it before allowing it in
  7. Allow all other inbound traffic in by default after passing through the IPS but rate limit it to protect devices from becoming overloaded.

It may be that Vyncke's suggestions are too radical for many organizations - especially until the benefits of IPv6-style end-to end-connectivity are proven. But let's not forget that the only reason organizations put up with the security risks of connecting their LANs to the Internet at all right now is because the benefits of doing make the risks worthwhile.