Feeds

Slow IPv6 adoption is a GOOD THING as IETF plans privacy boost

New 'SLAAC' RFC aims to do a better job of hiding hosts

Seven Steps to Software Security

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. ®

Mobile application security vulnerability report

More from The Register

next story
Yorkshire cops fail to grasp principle behind BT Fon Wi-Fi network
'Prevent people that are passing by to hook up to your network', pleads plod
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
BMW's ConnectedDrive falls over, bosses blame upgrade snafu
Traffic flows up 20% as motorway middle lanes miraculously unclog
LibreSSL RNG bug fix: What's all the forking fuss about, ask devs
Blow to bit-spitter 'tis but a flesh wound, claim team
Manic malware Mayhem spreads through Linux, FreeBSD web servers
And how Google could cripple infection rate in a second
Don't look, Snowden: Security biz chases Tails with zero-day flaws alert
Exodus vows not to sell secrets of whistleblower's favorite OS
Researcher sat on critical IE bugs for THREE YEARS
VUPEN waited for Pwn2Own cash while IE's sandbox leaked
prev story

Whitepapers

Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
How modern custom applications can spur business growth
Learn how to create, deploy and manage custom applications without consuming or expanding the need for scarce, expensive IT resources.
Reducing security risks from open source software
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Consolidation: the foundation for IT and business transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.