Part I: Addressing

In this first post in a series that will try to summarize recent (~10 years) advancements in the area of IPv6 security, FERNANDO GONT gives a go at not only discussing such advancements but also describing the context in which such work was carried out.

Let’s start from the beginning

Around 2009, I started working on a project for the UK Centre for the Protection of National Infrastructure (CPNI), which consisted of the first (and only, as far as I am aware) 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:

RFC 3971: Secure Neighbor Discovery (SEND), an attempt to secure IPv6 Neighbor Discovery (IPv6 version of IPv4 ARP and DHCP, so to speak).

RFC 4941: Temporary addresses, as a mitigation for some privacy issues associated with IPv6 addresses.

RFC 5095: Deprecation of Routing Header Type 0 (RHT0), in response to Philippe Biondi and Arnaud Ebalard’s presentation at the CanSecWest 2007 conference.

RFC 5157: An analysis of IPv6 network reconnaissance, which shed some light on the topic, and provided operational advice — but didn’t tackle the problem at the protocol level.

RFC 5722: 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+ page document that was never publicly released but it 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 so 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 website — 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 series, I will describe recent (~10 years) IPv6 security advances, separating them into different areas (IPv6 addressing, IPv6 first hop security, IPv6 extension headers, and so forth) — as opposed to discussing them in the chronological order in which the IETF discussed or published them. Let’s start with IPv6 addressing.

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 fit. 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 a 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 (for example, just probe PREFIX::MAC_Address for each interesting prefix).

While the myth existed (and still does!) that IPv6 address scanning was unfeasible, RFC 5157 had already suggested that this might not be the case.

Another concern was that in many (most?) managed networks, temporary addresses were unattractive — 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 is essentially the same concept employed for generating TCP Initial Sequence Numbers (ISNs) in RFC 1948 (now RFC 6528), and results 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 RFC 7217, it was suggested that the 6man working group should work 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 been present in the original proposal that led to RFC 7217. 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 RFC 7217).

An analysis of the security and privacy implications of IPv6 addressing (eventually published as RFC 7721).

A document to replace the traditional SLAAC scheme with the new one (eventually published as RFC 8064).

RFC 7217 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 published the security and privacy assessment of IPv6 addressing, as RFC 7721. Nearly a year later (February 2017), the IETF published RFC 8064, formally replacing the traditional algorithm for generating SLAAC addresses with RFC 7217 — 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!).

RFC 4941 — 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 unadopted the document, based on rather unbacked claims, and thus we (the authors of the document) resorted to publishing the document via the independent stream as RFC 7943.

On the other hand, in order to address flaws in RFC 4941, we submitted a proposal to replace it. After quite a bit of effort, the 6man working group decided that we should instead work on an ‘RFC 4941bis’ document — that is, start from the text in RFC 4941, 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, RFC 5157 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 RFC 7707, 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 and next February will be hosting an IPv6 Security Training Course. Meanwhile, your feedback is welcome!

Adapted from original post which appeared on SI6 Networks’ Blog.

• Gont specializes in the field of communications protocols security, working for private and governmental organizations from around the world.

• Editor’s Note: The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.https://blog.apnic.net/2020/08/24/a-brief-history-of-recent-advances-in-ipv6-security-part-i-addressing/