“But…it is written: if the Evil Spirit
Arms the tiger with claws
Brahman provided wings for the dove
Thus spake the super guru“
— “Breakdown” (1991), Guns N’ Roses
This is the first post of a series that will try to summarize recent (~10 years) advancements in the area of IPv6 security, not only discussing such advancements, but also describing the context in which such work was carried out.
Background
Around 2009 I started working on a project for the UK Centre for the Protection of National Infrastructure (CPNI) which consisted on the first (and only, as far as I am aware of) thorough security assessment of the IPv6 protocol suite.
At the time, not much had happened in terms of IPv6 security improvements. For the most part, it boiled down to:
- RFC3971: Secure Neighbor Discovery (SEND), an attempt to secure IPv6 Neighbor Discovery (IPv6 version of IPv4 ARP and DHCP, so to speak)
- RFC4941: Temporary addresses, as a mitigation for some privacy issues associated with IPv6 addresses.
- RFC5095: Deprecation of Routing Header Type 0 (RHT0), in response to Philippe Biondi and Arnaud Ebalard’s presentation at the CanSecWest 2007 conference.
- RFC5157: An analysis of IPv6 network reconnaissance, which shed some light on the topic, and provided operational advice — but didn’t tackled the problem at the protocol level.
- RFC5722: Prohibition of IPv6 overlapping fragments.
Thus, the goal of the project was to perform a security assessment of all the core IPv6 specifications, trying to find any protocol design-based flaws and, where possible and applicable, try to come up with mitigations. Additionally, whenever it could be inferred from the specifications that implementation-dependent vulnerabilities were likely to exist, perform a security assessment of some sample IPv6 implementations to either confirm or (momentarily) reject the potential flaws.
The result of the project was a 100+ pages long document that was never publicly released, but that was shared with at least all major vendors and other interested parties. Additionally, a set of security assessment tools were produced and shared with vendors and other interested parties such that they could assess their own IPv6 implementations and networks. This effort was meant to produce IPv6 security improvements before the widespread adoption of IPv6 — and I believe it did!
The original tools were not meant to be publicly released. However, one of the parties that had received them somehow posted the tools on their company’s web site — essentially publicly releasing them. Thus, once the tools had “leaked”, I decided to actively maintain them as well as produce other additional tools, eventually leading to the SI6 Networks’ IPv6 toolkit.
On the other hand, once the project was over, I tried to take as many of the proposed mitigations to the Internet Engineering Task Force (IETF), in the hopes of improving the IPv6 protocol suite. Thus, while the original CPNI report was never publicly released, most of the proposed mitigations did find their way into Internet-Drafts that I eventually published — along with other documents describing issues that I found while continuing my research on the topic.
In this post series, I will describe recent (~10 years) IPv6 security advances, separating them into different areas (IPv6 Addressing, IPv6 First Hop Security, IPv6 extension headers, etc.) — as opposed to discussing them in the chronological order in which the IETF discussed or published them.
IPv6 Addressing
IPv6 Stateless Address Auto-configuration (SLAAC) is IPv6’s mandatory protocol for automatic host configuration, where local routers advertise configuration information on a local link, and hosts make use of that information as they see fits. Hosts used to auto-configure IPv6 addresses by appending the MAC address of the underlying network interface card to the /64 prefix(es) advertised by the local router — an idea borrowed from the IPX world.
While employing the underlying MAC address was useful for coming up with a unique interface identifier (the equivalent to an IPv4 host id), the privacy implications of embedding the host’s MAC address in an IPv6 address eventually became a concern. Thus, the IETF published an specification for “privacy extensions” for IPv6 SLAAC (also known as “temporary addresses), to mitigate part of those issues. These temporary addresses would be configured in addition to the traditional SLAAC addresses, and would be employed for client-like communications. However, this still left us with two problems:
- Since temporary addresses were configured in addition to the traditional SLAAC addresses, hosts could still be actively tracked (e.g., just probe PREFIX::MAC_Address for each interesting prefix).
- While the myth existed (and still does!) that IPv6 address scanning was unfeasible, RFC5157 had already suggested that this might not be the case.
- Another concern was that in many (most?) managed networks, temporary addresses were un-attractive — or actually, normally seen as an operational hassle.
In December 2011, I submitted a proposal to replace SLAAC’s algorithm for generating IPv6 addresses. Instead of embedding a MAC address in the IPv6 address, an interface identifier (the “host” portion of the address) would be generated with an expression of the form:
Hash(Prefix, Secret)
The scheme was essentially the same concept employed for generating TCP Initial Sequence Numbers (ISNs) in RFC1948 (now RFC6528), and would result in IPv6 addresses with the following properties:
- Interface identifiers employed by different hosts would not follow any patterns, thus mitigating IPv6 address scanning attacks
- Interface identifiers would change as hosts moved across networks, thus mitigating privacy concerns
- Addresses would remain stable within each network — thus mitigating the operational challenge posed by temporary addresses
The relevant working group (6man) adopted the document, but did not agree to formally replace the traditional algorithm for generating SLAAC addresses. Thus, the resulting document would eventually propose an alternative scheme, but hosts would still be required to use the flawed algorithm.
During the final stages of the publication process of RFC7217, it was suggested that the 6man working group worked on an analysis of the security and privacy considerations for IPv6 addressing, to better understand the problem — although, for the most part, such analysis had already present in the original proposal that led to RFC7217. Additionally, the same group decided to work on yet another document that would formally replace the traditional algorithm for generating IPv6 addresses with SLAAC, with the new one.
Thus, at some point in time, what had already been contained in a single document, had now become three different documents:
- A protocol specification for an alternative algorithm to generate IPv6 addresses with SLAAC (eventually published as RFC7217)
- An analysis of the security and privacy implications of IPv6 addressing (eventually published as RFC7721)
- A document to replace the traditional SLAAC scheme with the new one (eventually published as RFC8064)
RFC7217 was the first document of the set to be published, in April 2014. The following note from a 6man participant summarizes the process well:
When I first saw this I-D, I thought what a sensible idea. Since then, I have been surprised, amazed even, at the opposition that has been put up, on this list, on the IETF list and even by the IESG. I have wondered why and have no rational explanation but do believe that you deserve a special mention for seeing this through, when others might have given up long ago (well, I would have done:-(
So, congratulations.
Two years later (March 2016), the IETF would publish the security and privacy assessment of IPv6 addressing, as RFC7721. One more year (February 2017), and the IETF would publish RFC8064, formally replacing the traditional algorithm for generating SLAAC addresses with RFC7217 — not without first doing a working group consensus call to decide whether the Acknowledgements in the document were appropriate (where existing practice seemed to indicate quite a bit of flexibility in that respect).
Thus, it took over five years to mitigate the issues associated with the traditional scheme for generating SLAAC addresses.
However, there was still work to be done in the area of IPv6 addressing:
- Many DHCPv6 server implementations generated predictable addresses (some still do!)
- RFC4941, the specification of IPv6 temporary addresses, contained flaws of its own
In order to mitigate predictable DHCPv6 addresses, we proposed an algorithm to be employed by DHCPv6 servers, which would generate addresses with the following properties:
- The resulting interface identifiers would not follow any patterns
- The scheme would generate stable addresses and support redundancy, without the need to synchronize state among DHCPv6 servers
The dhc working group adopted the proposal. However, it eventually un-adopted the document, based on rather unbacked claims. Thus, resorted to publishing the document via the independent stream as RFC7943.
On the other hand, in order to address flaws in RFC4941, we submitted a proposal to replace it. After quite a bit of effort, the 6man working group decided that we should instead work on a “RFC4941bis” document — that is, start from the text in RFC4941, and apply any necessary changes to it. This eventually resulted in draft-ietf-6man-rfc4941bis, which still needs to complete part of the publication process to become an RFC. That said, the proposed changes have already been incorporated into the Linux kernel, and into OpenBSD’s slaacd.
As noted earlier in this post, RFC5157 had already discussed some interesting aspects of IPv6 network reconnaissance. However, further research in this area warranted that it be revised. Thus, in March 2016 we published RFC7707, shedding some light on IPv6 network reconnaissance, both from defensive and offensive perspectives — probably a “must read” on the topic.
Coming soon….
In the next few weeks I will continue with a discussion of other recent IPv6 security advancements. Meanwhile, your feedback will be welcome!
Regards,
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492