Sergey Nivens - Fotolia
Editor's note: This is part two of a series on Internet Protocol Version 6 address usage and how it can benefit enterprise security. The first part explores the basics of IPv6 address and scope considerations for enterprises.
Typically, IPv6 addresses are expected to remain stable for as long as a host remains attached to the same network. However, in response to privacy concerns associated with stable addresses, temporary addresses (see the Internet Engineering Task Force's RFC 4941 for more) were introduced such that network activity correlation could be mitigated.
Generally speaking, the lifetime and stability of an address has a direct impact on:
- the ability of an attacker to correlate network activity;
- exposure to attack; and
Address stability considerations
For obvious reasons, an address that is employed for multiple communication instances enables the aforementioned network activities to be correlated. The longer an address is employed for multiple communication instances, the longer such correlation is possible.
In the worst-case scenario, a stable address that is employed for multiple communication instances over time will enable all such activities to be correlated. On the other extreme, if a host were to generate and subsequently throw away one new address for each communication instance, network activity correlation would be mitigated.
Similarly, when it comes to attack exposure, the longer an address is employed, the longer an attacker is exposed to attacks by other hosts that somehow learned about such an address.
Most transport protocols associate communication instances, such as Transmission Control Protocol (TCP) connections, with the underlying IP addresses. That is, the lifetime of such communication instances is tightly associated with the lifetime of the underlying IPv6 address.
As a result of the above considerations, hosts that employ temporary addresses do so along with stable addresses rather than in replacement of them. Essentially, stable addresses are employed for incoming communications where address stability is most desirable, while temporary addresses are employed for outgoing communications where mitigation of network activity correlation is mostly desirable.
The extent to which temporary addresses provide improved mitigation of network activity correlation and reduced attack exposure may be questionable. For example, a temporary address that is reachable for, say, a few hours, has a questionable reduced exposure. Similarly, if network activity can be correlated for the life of such an address on the order of several hours, such a period of time might be long enough for the attacker to correlate all the network activity they hope to correlate.
In order to better mitigate network activity correlation and possibly reduce host exposure, an implementation might want to reduce the lifetime of each temporary address. However, the reduced address lifetime has an associated price in terms of operational complexity and possible impact on associated network devices that may need to maintain state for each such address. Besides, employing small lifetimes may cause long-lived TCP connections, such as those corresponding to SSH sessions, to fail.
Clearly, the use of temporary IPv6 addresses is desirable for mobile nodes, for which privacy is mostly desirable. On the other hand, in enterprise scenarios, an administrator might prefer to disable temporary addresses, sacrificing improved privacy properties in favor of simpler network operation and administration.
Address usage considerations
As noted earlier in this article, hosts typically enforce some sort of policy regarding which IPv6 addresses they prefer to employ. However, all addresses are ultimately acceptable for both outgoing and incoming communications. While this may seem sensible in principle, it may also have unexpected consequences.
For example, a host that operates as a client can expose the IPv6 addresses it employs for performing outgoing communications. A host that supports temporary addresses typically employs temporary addresses for such outgoing communications, and such temporary addresses can become exposed to at least the nodes with which the host communicates. Once such addresses become exposed, an attacker might try to employ them for contacting the host for malicious purposes. However, such exposure is actually unwarranted, since temporary addresses are meant to be employed only for outgoing communications.
Unfortunately, virtually all IPv6 implementations will gladly accept incoming communications even on temporary addresses and, thus, performing outgoing communications leaves them open to port scans and incoming connections to any open ports.
There are multiple ways in which a specific usage type may be enforced for specific addresses. For example, an organizational firewall might be configured to accept incoming communications only for some specific addresses, while allowing only outgoing communications for other addresses.
Similarly, a host-based firewall or the host operating system itself might be able to enforce a similar policy on the host itself rather than relying on a network-based filtering policy. Even applications could theoretically specify on which addresses they are willing to accept incoming communications.
Unfortunately, it is unusual for hosts or networks to limit their addresses to their intended usage type and, thus, clients performing outgoing communications can become exposed to external attacks. For example, such scenarios have been reported for hosts that expose their temporary addresses as a result of contacting Network Time Protocol servers to synchronize their clocks.
The availability of multiple IPv6 addresses of different scopes and stability properties in each IPv6 host may be leveraged for improved security, privacy and resiliency properties. Awareness about the different properties and their associated implications will help enterprises realize the potential benefits in the emerging IPv6 deployments.
Learn more about the security and privacy improvements in the IPv6 update
Find out about the risks of unpatched IPv6 vulnerabilities
Discover the effects of Amazon Web Services IPv6 support