Editor's note: IPv6 auto-configured addresses have raised concerns about the security and privacy consequences of IPv6 addressing. IPv6 auto-configured addresses have three security implications: They allow attackers to reduce the search space when performing address scanning attacks, they allow correlation of node activities within a network and they can make host tracking easier. Security engineer and consultant Fernando Gont discusses ways to counteract these issues, adding that more work is warranted.
IPv6 incorporates two different mechanisms for address configuration: stateless address auto-configuration (SLAAC) and stateful
When it comes to SLAAC, the specific policy to be applied may depend on the underlying link-layer technology. For Ethernet, the relevant IETF standards specify that IPv6 addresses should be constructed from the auto-configuration prefix combined with an Interface ID (IID) that embeds the underlying link-layer address. Specifically, the IID is generated with the following steps:
- Take the Ethernet address of the underlying network interface.
- Invert the U/L bit of the IEEE organizationally unique identifier (OUI) of the Ethernet address.
- Insert the word 0xfffe in between the upper 3 bytes and the lower 3 bytes of the Ethernet address.
The resulting 64 bits will then be employed for the IPv6 address that needs to be generated.
Once the IIDs are created, they share three properties. First, the IIDs, at least in theory, will be globally unique, since the Ethernet addresses from which they are derived are typically unique. Second, they follow specific patterns, resulting from the underlying Ethernet addresses. For example, devices manufactured by the same vendor will share the same high-order 5 bytes of the IID: those corresponding to the IEEE OUI, plus two additional bytes for the word 0xfffe. Third, they will be constant within a network and across networks unless the underlying Ethernet address is manually changed or the underlying network interface card (NIC) is replaced.
Issues arising from traditional SLAAC addresses
Generating IIDs from the underlying Ethernet addresses is a convenient way to produce globally unique IDs; the technique also avoids creating duplicate IPv6 addresses within a network. However, it did not take long for the security community to realize that this method had negative security and privacy implications. Among them, the technique allows attackers to reduce the search space when performing IPv6 address-scanning attacks. It also permits attackers to correlate the node activities within a specific network, as well as across multiple networks.
The key concept here is that as long as there is one IID that remains constant across networks, it is still possible to perform host tracking attacks.
Understanding the implications of a reduced search space was covered in this TechTarget article, posted last year.
For this tip, we will focus on the privacy implications of traditional SLAAC addresses, specifically the correlation of host activity within the same network as well as across multiple networks (host tracking).
As noted earlier, embedding the underlying MAC address of a network interface in the IID of an IPv6 address will result in addresses that remain constant over time (unless a NIC is replaced, for example). As a result, it becomes trivial for an attacker to correlate the activities of a node within the same network. For example, consider a scenario in which a node connects to a network employing the prefix 2001:db8:1::/64, and auto-configures the address 2001:db8:1::a00:27ff:fe89:7878. If the node disconnects from this network and reconnects sometime later, it will auto-configure the same address (again, assuming the underlying NIC has not been replaced). Therefore, an attacker could link all network activity that employs the IPv6 address 2001:db8:1::a00:27ff:fe89:7878 as being performed by the same node. This is usually referred to as a correlation of node activities within a network.
'Super cookie' enables host tracking
SLAAC IIDs are not only constant within a network, but also constant across networks. That's because they only depend on the MAC address of the underlying NIC (which does not vary across networks). Since these interface identifiers are also typically globally unique (because the underlying MAC addresses are typically globally unique), it is not difficult to correlate the activities of a node across different networks. The 64-bit IID, then, provides a "super cookie" that provides a global identifier for the node. For example, consider a scenario in which a node connects to a network employing the prefix 2001:db8:1::/64, and auto-configures the address 2001:db8:1::a00:27ff:fe89:7878. The node disconnects from that network and later connects to a network that employs the prefix 2001:db8:2::/64, where it will auto-configure the address 2001:db8:2::a00:27ff:fe89:7878. The globally unique and constant interface ID a00:27ff:fe89:7878 clearly exposes the identity of the node, allowing correlation of the activities of the node across multiple networks. This is usually referred to as host tracking.
Privacy extensions for IPv6
In response to the privacy concerns regarding traditional SLAAC addresses, the IETF produced RFC 4941, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6"; it is commonly referred to as "temporary addresses." The scheme standardized in RFC 4941 works basically as follows:
- Temporary addresses are IPv6 addresses that employ a random IID that is regenerated over time.
- These temporary addresses are generated in addition to the traditional SLAAC addresses. That is, a node implementing RFC 4941 will not only employ temporary addresses, but will also employ the traditional (stable) SLAAC addresses.
- Temporary addresses are employed for outgoing connections, while the traditional SLAAC addresses are employed for incoming connections. That is, the traditional SLAAC addresses are only employed where address stability is generally a required or desired property.
Unfortunately, temporary addresses have a number of drawbacks. They don't alleviate address scanning attacks, they only partially mitigate host tracking and they generally complicate network operation.
What's more, since temporary addresses are employed in addition to traditional SLAAC addresses (rather than in replacement of them), the use of temporary addresses offers little protection from address scanning attacks.
When it comes to host tracking, temporary addresses provide only partial mitigation of these issues. For example, consider a scenario where an attacker knows the IID employed for the traditional SLAAC addresses of a victim node, and the attacker also knows the possible networks to which that victim node might connect. In that scenario, an attacker could actively poll the victim node in each of the target networks by constructing the target IPv6 addresses from the network prefixes and the stable IID employed by the victim node as it makes a network connection.
The key concept here is that, as long as there is one IID that remains constant across networks, it is still possible to perform host tracking attacks. Employing temporary addresses only mitigates passive host tracking attacks (i.e., those that rely on the victim connecting to an attacker-operated server). However, active host tracking attacks (where the attacker sends probe packets to the victim) still remain possible.
Offsetting active host tracking
The scan6 tool of the SI6 Networks' IPv6 toolkit is an IPv6 address scanning tool engineered for active IPv6 host tracking. It provides a number of options for specifying possible networks the victim could connect to, and the stable Interface ID the victim employs.
For example, consider a situation where an attacker knows that the IID the victim employs for its traditional SLAAC addresses is a00:27ff:fe89:7878, and that the victim could only be connected to the networks 2001:db8:1::/64 and 2001:db8:2::/64. In such a scenario, the attacker could employ the scan6 tool as follows:
# sudo scan6 -i eth0 -d 2001:db8:1::/64 -d 2001:db8:2::/64 -W a00:27ff:fe89:7878 -l -z 60 -t -v
This would make scan6 poll the IPv6 addresses 2001:db8:1::a00:27ff:fe89:7878 and 2001:db8:2::a00:27ff:fe89:7878 once every 60 seconds. As noted above, this attack would work even if the victim uses temporary addresses since temporary addresses are generated in addition to the traditional SLAAC addresses.
The scan6 tool also allows the target IIDs and the target network prefixes to be obtained from respective files. For example, the tool could be implemented as follows:
# sudo scan6 -i eth0 -m PREFIXES-TXT -w IIDS.TXT -l -z 60 -t -v
In this case, the scan6 tool will obtain the target IPv6 prefixes from the file PREFIXES.TXT, and the IIDs of the victim node(s) from the file IIDS.TXT.
Clearly, temporary addresses mitigate correlation of node activities within a network because they make it more difficult for a remote attacker to link a number of communication instances to the same node.
Completely eliminating host tracking attacks would require that a node never employs IIDs that are constant across networks. An IETF proposal, "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)" is meant to do just that. Among its components:
- The resulting IPv6 addresses are constant within a network (i.e., the host always gets the same address when it connects to the same network), so that network operation is not negatively affected.
- The IPv6 addresses change when a host moves from one network to another (thus mitigating host tracking attacks).
The standard is expected to be completed by the end of the year. While there has been interest among a number of vendors to support this approach, it will certainly take time for this method to be widely deployed as a means to solve security and privacy issues surrounding IPv6 addressing.
About the author. Fernando Gont is an Internet security and engineering consultant for S16 Networks. He has worked on various projects on behalf of the U.K. National Infrastructure Security Coordination Centre and the U.K. Centre for the Protection of National Infrastructure. He is an active participant at the IETF, where he contributes to several working groups, and has authored a number of RFCs. Gont is a regular speaker at a number of conferences, trade shows and technical meetings, discussing information security, operating systems and Internet engineering. More information is available at his website.
This was first published in June 2013