Understanding security flaws in IPv6 addressing schemes

Syntax of IPv6 addressing schemes

This screenshot illustrates the syntax of an IPv6 global unicast address:

The global routing prefix is a network prefix delegated by an Internet service provider or registrar. The Subnet ID allows for multiple subnetworks within the same network prefix. Finally, the Interface ID essentially identifies the network interface of one system within a given network (Global Routing Prefix and Subnet ID). The Interface ID has the same semantics as the Host ID of an IPv4 address (which was actually a misnomer for an Interface ID). While the reduced length of the IPv4 Host ID limits the possible ways to use or select these bits, the Interface ID of an IPv6 address is 64 bits long and hence allows for different techniques or algorithms for leveraging these bits.

The specific algorithm employed for generating the Interface ID of an IPv6 address will typically depend on the specific mechanism for address configuration, and may also vary from one implementation to another.

IPv6 address-configuration mechanisms

IPv6 incorporates two different mechanisms for automatic address configuration: stateful Dynamic Host Configuration Protocol version 6 (DHCPv6) and Stateless Address Auto-Configuration (SLAAC). With stateful DHCPv6, addresses are centrally assigned by a DHCPv6 server, and hence the DHCPv6 server can apply any specific algorithm for the generation or selection of the leased addresses. On the other hand, SLAAC is a decentralized approach to address configuration, where each node auto-configures its IPv6 addresses by employing an advertised prefix and a locally generated Interface ID.

DHCPv6 does not require any specific algorithm for the generation or selection of the leased addresses. For example, some DHCPv6 implementations have traditionally generated sequential addresses (e.g., 2001:db8::1, 2001:db8::2, etc.), while others have generated randomized addresses (IPv6 addresses where the Interface ID is a random number).

On the other hand, SLAAC addresses are typically generated by embedding the underlying hardware address in the Interface ID. For example, when it comes to the ubiquitous Ethernet, the relevant IETF standards specify that IPv6 addresses should be constructed from the auto-configuration prefix and an Interface ID that embeds the underlying link-layer address. The following syntax illustrates the structure of an Interface ID generated from an Ethernet MAC address:

SLAAC also allows for the generation of what's called temporary addresses (sometimes referred to as privacy addresses). These addresses, standardized in RFC 4941, employ random Interface IDs that are regenerated over time. They are generated in addition to the traditional SLAAC addresses. That is, a node implementing RFC 4941 will employ not only temporary addresses, but also traditional (stable) SLAAC addresses. Temporary addresses are employed for outgoing connections, while the traditional SLAAC addresses are employed for incoming connections. In other words, the traditional SLAAC addresses are employed only where address stability is generally a required or desirable property.

The temporary addresses standardized in RFC 4941 were originally meant to mitigate some of the security and privacy issues discussed in this tip. However, we will see that they fail to mitigate a number of potential problems, while at the same time introducing additional complexity.

Security and privacy implications of IPv6 addressing

Four (somewhat related) properties of the Interface IDs employed in IPv6 addresses have relevance when it comes to the security and privacy properties of such addresses:

• Whether they vary over time
• Whether they vary across networks
• Whether they can be expected to be globally unique
• Whether they follow specific patterns

An Interface ID that is globally unique leaks information about the node's identity: It can be considered to be the 64-bit serial number of the node in question. Therefore, the corresponding addresses can be assumed to be employed by a single node rather than being reused by multiple nodes.

If an Interface ID (and hence the corresponding address) does not vary over time, a node's activity can be correlated over time. For example, if a server receives a request from, say, address 2001:db8::1111:222:3334:4444, and at some later time the same server receives a request from the IPv6 address 2001:db8::1111:222:3334:4444, both communication instances can be inferred to have involved the same client node. On the other hand, if a client communicates with a server by employing the address 2001:db8::1111:222:3334:4444, later configures a new address 2001:db8::a:b:c:d and employs this address for a subsequent request, it becomes much harder to correlate the two communication events as being initiated by the same client.

If an Interface ID is not only constant in time, but also constant across networks, a node can become traceable across networks. For example, if a server receives a request from, say, IPv6 address 2001:db8:1::1111:222:3334:4444, and at some point later in time it receives a request from the IPv6 address 2001:db8:2::1111:222:3334:4444, the server could assume that both communication instances have involved the same client node, which has simply moved from the network 2001:db8:1::/64 to the network 2001:db8:2::/64.

Clearly, the uniqueness of an Interface ID has a direct effect on the extent to which a node's activities can be correlated in time and/or across networks: If an address cannot be assumed to be employed by a single client, it might be inferred that some network activity involves the same node, when in fact, multiple different nodes (that just happened to employ the same Interface ID) may have been involved.

Furthermore, if the Interface ID employed by a node follows some known or predictable pattern, such information may be leveraged for network reconnaissance purposes. For example, a network that is known to employ IPv6 addresses where the Interface ID is set to a small integer (say 2001:db8::1, 2001:db8::2, 2001:db8::3, etc.) clearly makes the task of finding "live" nodes easy, since an attacker needs only to search for addresses following a predictable pattern, instead of searching (by brute force) the entire 2001:db8::/64 network.

Operational security considerations for IPv6 addressing

Based on our discussion of the security and privacy implications of IPv6 addressing, one might be tempted to assume that the proper mitigation for all the aforementioned issues would be to replace any stable addresses with temporary IPv6 addresses that employ randomized Interface IDs, such that the addresses change both over time and across networks.

However, it should not be surprising that security and privacy requirements are at times at odds with network management requirements and/or expectations. In particular, address stability tends to be a required or desired networking feature for a number of reasons, most commonly because it simplifies network operation, and it allows for long-lived network sessions.

Network operation typically involves things such as enforcing simple access control lists (ACLs) based on the IPv6 addresses of clients and servers, and correlation of network activity of local nodes. For obvious reasons, statically configured ACLs would not work as expected if the IPv6 address(es) of the node(s) for which an ACL is to be enforced changes over time. In a similar vein, it would become virtually impossible to correlate the activity of a local node when its address changes over time (unless the network keeps track of the address changes). This is the main reason why many enterprises disable the use of temporary addresses (RFC 4941): to simplify network operation.

Security and privacy properties of IPv6 address-generation schemes

Based on our previous discussion of the security and privacy properties of IPv6 addressing, it is interesting to examine and compare the current schemes for generating IPv6 addresses.

DHCPv6 sequential addresses employ Interface IDs that are typically small-integer numbers, with the following properties:

• They do not vary over time.
• They vary across networks.
• They are not globally unique.
• They follow specific patterns.

As a result, such addresses allow for the correlation of node activities over time (within the same network), and also allow for trivial IPv6 address-scanning attacks.

On the other hand, DHCPv6 randomized addresses employ Interface IDs that are typically 64-bit random numbers, with the following properties:

• They do not vary over time.
• They vary across networks.
• They are globally unique.
• They do not follow specific patterns.

As a result, such addresses can be subject only to correlation of network activity over time. While this is a drawback from a privacy perspective, it is usually a desired property from an operational point of view.

Traditional SLAAC addresses essentially embed the underlying hardware address, and result in Interface IDs that have the following properties:

• They do not vary over time.
• They do not vary across networks.
• They are globally unique.
• They follow specific patterns.

As a result, these addresses can leveraged to correlate network activity over time, and to correlate network activity across networks (host tracking). Additionally, they allow for trivial IPv6 address scanning attacks.

Temporary addresses would seem to mitigate all security and privacy issues; after all, they are temporary addresses that randomize the Interface ID. However, "the devil is in the details" because temporary addresses are generated in addition to the traditional SLAAC addresses. Therefore, address-scanning attacks are not prevented or even mitigated by the use of temporary addresses.

When it comes to correlation of node activity across networks (host tracking), temporary addresses provide only partial mitigation of these issues. For example, consider a scenario where an attacker knows the Interface ID 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, the attacker could actively discover how to probe the victim node by constructing the target IPv6 addresses from the network prefixes and the stable Interface ID that the victim node would employ in any network it connects to. The key concept here is that as long as there is one Interface ID that is constant across networks, it is still possible to perform host-tracking attacks.

Employing temporary addresses only mitigates passive host tracking attacks (e.g., 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.

It should be clear from the above discussion that in order for temporary addresses to be effective in mitigating IPv6 security and privacy issues, traditional (stable) SLAAC addresses should be improved to consider security and privacy.

Recent advancements in IPv6 addressing schemes

There have been ongoing efforts at the IETF to produce alternative IPv6 addressing schemes that result in improved security and privacy properties.

One of such efforts has resulted in the publication of RFC 7217, which specifies a new method for generating IPv6 Interface IDs with SLAAC. The method in RFC 7217 essentially boils down to the following expression:

Interface_ID = hash(Prefix, Net_Iface, Counter, secret_key)

where the Interface ID is generated as a result of a (cryptographically secure) hash function that takes as its input:

• The network prefix ("Prefix") for which this interface ID is being generated
• A value ("Net_Iface") that identifies the network interface for which this Interface ID is being generated
• A counter ("Counter") that is employed to resolve address collisions
• A secret key ("secret_key") that, along with the hash function, prevents Interface IDs from being predicted or guessed

The Prefix parameter is the network prefix (advertised in Router Advertisement messages by a local router) for which this Interface ID is being generated. For obvious reasons, the Prefix value will typically change as a host moves from one network to another. Net_Iface identifies the network interface for which this Interface ID is being generated, and is expected to be constant across system reboots. This parameter could be set to, for example, the name of the corresponding network interface ("eth0," "wlan0," etc.). The Counter parameter is employed to resolve address collisions. It is initialized to zero, and is incremented by one to resolve address conflicts. That is, if the generated address is found to be already in use in the local network, the counter is incremented and the Interface ID is recomputed. Finally, the secret_key parameter, along with the hash function, prevents Interface IDs from being predicted or guessed by an attacker. The secret_key could be initialized to a random number at system installation time, or manually set by the system administrator.

As one could possibly infer, as long as a node connects to the same network, all of the parameters will remain constant, and hence the result of the hash function (and hence the Interface ID and IPv6 address) will be the same. On the other hand, as a host moves from one network to another, the Prefix argument will change, and the result of the hash function (and hence the Interface ID and IPv6 address) will change. This scheme will thus result in IPv6 addresses that are stable within the same network, but that change as the host moves from one network to another. Additionally, since the hash function is required to be cryptographically secure, its result will not follow any patterns, and hence the addresses generated with this method will mitigate address-scanning attacks.

This mechanism has already been implemented in FreeBSD, and there are upcoming implementations in other operating systems, such as Linux. Additionally, ongoing work at the IETF will make this scheme the default scheme for generating Interface IDs with SLAAC.

The same concept standardized in RFC 7217 for SLAAC has been "ported" to stateful DHCPv6 in the IETF Internet-Draft. For obvious reasons, in the DHCPv6 case the algorithm is employed by the DHCPv6 server leasing the addresses, rather than by the client requesting the addresses. The algorithm employed by the DHCPv6 server is:

Interface_ID = hash(Prefix, Client_DUID, IAID, Counter, secret_key)

Essentially, the Net_Iface parameter from the expression employed by RFC 7217 is replaced with two other parameters: "Client_DUID" and "IAID". Client_DUID is a value advertised by the DHCPv6 client which uniquely identifies the client. IAID is a value used and advertised by the client to identify the interface for which it is requesting IPv6 addresses. Thus, these two values (when employed together) can be considered to identify a specific network interface at a specific DHCPv6 client.

The properties of IPv6 addresses generated by employing this scheme with DHCPv6 are the same as those of IPv6 addresses generated by employing RFC 7217 with SLAAC. However, in the DHCPv6 case, they have an additional and interesting property: They allow for simple address stability when multiple DHCPv6 servers are employed for resiliency/failover purposes. A network that operates multiple DHCPv6 servers (for resiliency purposes) can manually configure the same secret_key parameter in all DHCPv6 servers. As a result, the generated or leased IPv6 addresses for each client or interface will be the same, regardless of which specific DHCPv6 server leased the address. This is a more lightweight approach to provide address stability than some of the "synchronization mechanisms" that require additional protocol work to synchronize the list of DHCPv6-leased IPv6 addresses among DHCPv6 servers.

Conclusions

Some of the IPv6 address-generation schemes that are currently employed in production networks have security and privacy implications that are usually overlooked by both network administrators and users.

The increased understanding of the aforementioned issues in recent years has led to a number of efforts at both the IETF and open source communities to mitigate unintended security and privacy ramifications. It is this author's hope that an increased understanding of these issues will help to deploy more secure and privacy-enhanced networks.

About the author:
Fernando Gont works for SI6 Networks as an Internet security and engineering consultant. He is an active participant in the IETF, where he contributes to several working groups and has authored a number of RFCs (Requests for Comments) and Internet drafts. Gont is a regular speaker at a number of conferences, trade shows and technical meetings, about information security, operating systems and Internet engineering. More information is available at his website.