Internet Protocol addresses fill two unique roles. They are both identifiers and locators. They both tell us which interface is which (identity) and tell us how to find that interface (location), through routing. In the last myth, about network scanning, we focused mainly on threats to IPv6 addresses as locators. That is, how to locate IPv6 nodes for exploitation. Today’s myth also deals with IPv6 addresses as identifiers.
As we learned in the last myth:
Traditionally SLAAC uses modified EUI-64 format interface identifiers, which basically takes the interface’s MAC address and stuffs the hexadecimal word “0xfffe” in between the OUI (Organizationally Unique Identifier) and the second half of the MAC address, plus setting the “Universal” bit to 1. For example, the MAC address 00.00.5E.00.53.01 would become the IID (Interface Identifier) 0200:5EFF:FE00:5301.
This mapping of IEEE link-layer (MAC) addresses into IPv6 addresses has significant privacy implications when you consider the identification role of those addresses. When my interface identifier (the second 64 bits of my IPv6 address) is built deterministically from my MAC address, it doesn’t change (unless I change my network interface hardware, another issue that can be problematic for network administrators). An unchanging interface identifier can be used to track my device and it’s Internet activity. Even as it moves from network to network the prefix changes but the IID does not and my identity is revealed.
In response to this privacy threat, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” were developed and are now published in RFC 4941. Ultimately the idea documented here is to generate “privacy addresses” (also known as “temporary addresses”) that change over time. Unpredictable and short-lived, these addresses are meant to combat the threat of your devices being identified and tracked as you use the Internet.
Myth: Privacy Addresses Fix Everything!
Reality: It’s Complicated
The first thing to note about privacy addresses is that they are created in addition to, not in place of, your “regular” SLAAC address. This means that for the purposes of scanning and locating hosts, privacy addresses are of little help.
Another issue that should be considered with regard to privacy addresses is their short-lived nature and its affect on troubleshooting and forensics. It is very hard for network administrators to manage a network full of devices constantly changing their source addresses. Setting up filters, looking back at logs, and many other regular tasks become much more difficult when you can’t predict what address a node will be using, nor guess which address it was using.
The obvious solution to both of these challenges is to use a single, stable address that is not based on the interface’s MAC address. Replacing the EUI-64 based SLAAC address with a randomized one does reduce the ability for an attacker to target OUI patterns or other heuristics. Making the address stable (across reboots and network moves) makes filtering, troubleshooting, and forensics much more possible than with truly temporary addresses. Unfortunately, an unchanging address does not address the privacy concerns that prompted the creation of privacy addresses in the first place – unchanging IIDs can be used to identify and track a given device.
A more recent solution to this is being called “Semantically Opaque Interface Identifiers” and a method for generating them is documented in RFC 7217:
This document specifies a method to generate Interface Identifiers that are stable for each network interface within each subnet, but that change as a host moves from one network to another. Thus, this method enables keeping the “stability” properties of the Interface Identifiers specified in [RFC4291], while still mitigating address-scanning attacks and preventing correlation of the activities of a host as it moves from one network to another.
Not bad! I do note that on-network correlation is still possible, since the addresses only change when moving from one network to another. But that is of course what makes the address easier to manage from a network administrator point of view. It should also be noted that a device could use privacy addresses for outbound communication and opaque addresses for inbound communication, possibly frustrating network admins but improving privacy.
The alternative to all of this would be to use properly configured DHCPv6 instead of SLAAC on your networks. Just be sure to take into account all the risks of scanning mentioned in the last myth, and consider using privacy/temporary addresses with your DHCP implementation for user privacy.
Still confused? This is a tricky topic that is currently in flux a bit. If you want more information or have some clarifying questions, please don’t hesitate to look at our IPv6 security resources or to contact us directly!
Final note: I want to also point out that I intentionally left Cryptographically Generated Addresses (CGA) out of this conversation. I made this choice to simplify the topic in light of the extremely low adoption rate of SEND (Secure Neighbor Discovery) at this time.
This post also appears on the Deploy360 blog.
