IPv6 Security and those damned dirty NATs
Saturday, February 6, 2010 by darcoPosted in Articles, Security, IPv6
With less than 10% of IPv4 addresses remaining unallocated, IPv6 has been getting a lot of attention lately. As such, hardware vendors and ISPs (like Comcast) are now starting to figure out how best to deploy IPv6 connectivity to residential customers.
IPv6 would effectively make the use of IP masquerading (A form of Network Address Translaton used in practically all residential gateway routers) unnecessary. Unfortunately, the current ubiquity of IP masquerading has caused vendors and ISPs to be suspicious of allowing proper end-to-end connectivity to residential customers. I have even heard that some are even considering using the same IP masquerading mechanism for IPv6—for security reasons!
This would be a very bad thing for the future of the IPv6 internet, so I wanted to elaborate on the motivations people have for doing this and ways that it can be avoided altogether.
Services
The perception is that IP masquerading (where you have many machines behind one external IP address) is more secure than having every computer out on the open internet. For IPv4 this is absolutely true. The problem with IP masquerading is that it has made software developers and operating system vendors lazy.
For example, if you turn on file sharing on your Mac it does not differentiate between sharing files on your local network (which is most likely your intention) versus sharing files on the globally routable internet (which is most likely NOT your intention). In this case the scope of access is defined by the network you are connected to, as opposed to being defined by you explicitly.
In IPv4, you generally have one IP address per interface. If your machine has a globally-routable IPv4 address, then any time you start a service it will also be accessible from the public internet as well. With IP masquerading, any service you enable is only available on the local network(with a few obscure exceptions).
With IPv6, every network interface is required to have a special kind of address called the "link-local address" in addition to any other addresses the interface may have1. If you bind a socket to the link-local address, connections will only be allowed to and from that local network. Connections from the open IPv6 internet would simply not be possible.
Instead of simply providing an option to turn a service on or off, there should also be the ability to specify what scope you want the service to be bound to. It could be an option named something like "Allow connections from:" with the values "Local networks", "Site networks", and "All networks". This gives us the same type of security that would be provided by IP masquerading while giving users the flexibility to choose to make available specific services on a larger scope. The default should obviously be "Local networks".
This is just a simple example, there is plenty more than can be done.
Privacy
It is currently the convention that the least significant 64-bits of an IPv6 address (called the "interface identifier") is derived from the hardware address of the interface—usually a MAC address. The concern is that this provides a static globally unique identifier which could be used to track the behavior of an individual across networks. (This is similar to the security concerns of HTTP cookies but much more broad in scope)
Let's say that you work for the a government agency which is ripe with corruption. You want to blow the whistle on this corruption, but are afraid to do so publicly out of fear of losing your job—or worse. In order to conceal your identity, you take your laptop to an obscure IPv6-enabled coffee shop and send an anonymous tip to a reporter via a web form. The government agency, mad as hell, somehow figures out the IPv6 address that the tip came from(They are the corrupt government, after all). They then know that it was you who tipped off the reporter because someone using a machine with the same interface identifier logged into the government VPN with your account last week. Busted.
It is this sort of scenario that RFC 3041 aims to fix. RFC 3041 describes a mechanism to change the interface identifier of non-link-scope IPv6 address randomly over time, in order to provide a degree of anonymity.
Microsoft Windows implements RFC 3041 and uses it by default. Support for RFC 3041 appears to be in the Linux kernel, but few (if any) distributions seem to enable it by default. MacOS X unfortunately does not appear to support it at all.
The IPv6 transition is going to be hard, but it is also going to be fruitful. We just need to make sure that we don't neuter the IPv6 internet before we can realize the benefits.
1: IPv4 has a concept of a link-local address RFC 3927, but it is only intended for use when there is no other way to obtain an IPv4 address—once an interface gets assigned a "real" IPv4 address, the link-local address goes away. ↩