Slow IPv6 adoption is a GOOD THING as IETF plans privacy boost
New 'SLAAC' RFC aims to do a better job of hiding hosts
The glacial pace of the worldwide IPv6 rollout might cause hand-wringing among 'net boffins, but at least it's leaving time for engineers to pry around for possible problems before the whole world's on the protocol.
Since the transition is still at an early stage, it's easy to forget that IPv6 has, as a document, been around since the late 1990s – an era long before ordinary users had learned to fear the NSA, worry about deliberately-compromised cryptography, or wonder if they'd lost their data to the Heartbleed bug.
Back then, the authors of IPv6 were worried about address exhaustion, so the main game was to expand the address space, making it big enough that everyone/thing could get an address. Data confidentiality was considered optional to the operation of the protocol.
With its new-found desire to NSA-proof the Internet, it's no surprise that there's an RFC that looks back at IPv6 to propose how addresses could be made more private.
The document has the snappy title of A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC), and its aim is to resolve two challenges that face IPv6.
You need a stable address to be able to communicate; however, as has become increasingly clear in the post-Snowden world, addresses can also be correlated with users and user activity. As the RFC states, if Interface Identifiers don't vary over time, user privacy is compromised.
Moreover, since there's a to-most-intents-and-purposes-inexhaustible supply of IPv6 addresses, your device can have the same address forever, regardless of which network it's connected to: “Since the resulting Interface Identifiers are constant across networks, the resulting IPv6 addresses can be leveraged to track and correlate the activity of a host across multiple networks (e.g., track and correlate the activities of a typical client connecting to the public Internet from different locations), thus negatively affecting the privacy of users”, the RFC says.
Why it's needed
Nobody likes configuring IP addresses by hand, so an autoconfiguration process was proposed in 2007 in RFC4860. That way, machines with an IPv6 stack could create their own addresses under a process called Stateless Address Autoconfiguration.
A unique address is guaranteed by getting the host to use its MAC address (which is supposed to be unique, but let's leave spoofing out of the question for now) as part of the address, using a prefix provided by (for example) a router.
Since v6 doesn't need to reassign addresses, the device would then keep that address forever – and there's where the privacy risk arises. This could be tackled by using temporary addresses, but only at the cost of making sys admins' work a bit of a nightmare.
The new RFC, 7217, offers at least a partial fix: while a host's address would be stable as long as it stays attached to a given subnet, it would change as the host moves between networks. If you connect your tablet to the office WiFi in the morning and stay there, it'll retain the same address all day; but when you go home, you'll get a new address from the cellular network during your trip, and another when you connect to the home WiFi.
This, the RFC says, should at least mitigate address-scanning attacks, “preventing correlation of the activities of a host as it moves from one network to another”.
How it's done
The privacy challenge is complicated by the need to ensure that:
- My device doesn't generate the same address every time it connects to a particular network;
- It's hard for an attacker to predict the address a device might receive from a particular network (to limit attacks in public networks such as coffeeshop WiFi); and
- Reconfiguring a device won't upset the network by changing its address when you don't want it to change.
Simplified, the process works like this:
- A secret key in the host is added to the computation of the random identifier (ie, in addition to parameters like net prefix, MAC address and so on). This produces a random-but-stable identifier (RID);
- Starting at the least significant bit, as many bits from the RID are taken as are needed.
This means the interface identifier part of the IPv6 address should vary across each prefix used, and consequently across networks.
“This mitigates the correlation of activities of multihomed hosts (since each of the corresponding addresses will typically employ a different prefix), host-tracking (since the network prefix will change as the host moves from one network to another), and any other attacks that benefit from predictable Interface Identifiers (such as IPv6 address-scanning attacks)”, the RFC states. ®