Ephemeral Node Identifiers for Enhanced Flow Privacy

Abstract

The Internet Protocol (IP) uses numerical address values carried in IP packets at the network layer to allow correct forwarding of packets between source and destination. Those address values must be kept visible in all parts of the network. By definition, those addresses must carry enough information to identify the source and destination for the communication. This means that successive flows of IP packets can be correlated—it is possible for an observer of the flows to easily link them to an individual source and so, potentially, to an individual user. To alleviate this privacy concern, it is desirable to have ephemeral address values—values that have a limited lifespan and so make flow correlation more difficult for an attacker. However, the IP address is also used in the end-to-end communication state for transport layer flows so must remain consistent to allow correct operation at the transport layer. We present a solution to this tension in requirements by the use of ephemeral Node Identifier (eNID) values in IP packets as part of the address value. We have implemented our approach as an extension to IPv6 in the FreeBSD14 operating system kernel. We have evaluated the implementation with existing applications over both a testbed network in a controlled environment, as well as with global IPv6 network connectivity. Our results show that eNIDs work with existing applications and over existing IPv6 networks. Our analyses shows that using eNIDs creates a disruption to the correlation of flows and so effectively perturbs linkability. As our approach is a network layer (layer 3) mechanism, it is usable by any transport layer (layer 4) protocol, improving privacy for all applications and all users.

1. Introduction

The visibility of the IP address in all IP packets is essential for communication across the global Internet, but is vulnerable to privacy-compromising attacks. An adversary on the communication path—a compromised or malicious gateway, router, Internet Service Provider, or other eavesdropper—can correlate to different communication sessions based on address values used across multiple separate communication flows. This allows the attacker to build a detailed picture of an end user’s online activity, violating expectations of privacy. As this attack does not exploit the application data, commonplace security measures such as end-to-end encryption are insufficient to disrupt it. A network-layer defence that perturbs the use of address values in correlation attacks is therefore required.

Security guidelines for Internet-based communication—formalised in RFC3552(BCP) [1], and now a ubiquitous feature of protocol design—typically aim to prevent the misuse of a protocol, rather than to minimise the information leaks that make attacks against privacy possible. It was only after the security and privacy exploitations exposed by Edward Snowden [2] that the Internet community hastily introduced privacy guidelines [3] to address certain privacy-specific threats. This included a definition for the privacy threat of correlation:

“Correlation is closely related to identification. Internet protocols can facilitate correlation by allowing individuals’ activities to be tracked and combined over time. The use of persistent or infrequently replaced identifiers at any layer of the stack can facilitate correlation”.

An IP address is one such stable identifier that can be exploited to perform this attack.

In principle, some network-layer fields do not necessarily need to be visible in transmitted packets for normal network operations, and so could be omitted by protocols that value privacy, further reducing the attack surface [4]. In practice, however, intermediate nodes must be able to inspect:

• the destination IP address, which is essential for packet forwarding and delivery; and
• the source IP address, which is essential for transport layer protocol state at end-systems, and which might be required for firewall operations.

As IP addresses cannot be hidden from on-path nodes, they remain an attack vector for compromising privacy [5].

1.1. Contributions

This work demonstrates how to perturb use of IP addresses for attacks on identity privacy, without modifying any applications and maintaining the correct operation of existing transport protocols as well as normal network routing and forwarding functions. We show that IP’s use of time-based ‘Temporary Address’ values [6] provides little protection against correlation attacks—only by constraining the linkability of the address bytes to within individual packet flows is it possible to prevent flow correlation attacks.

Using the Identifier-Locator Network Protocol (ILNP) [7], an extension of IPv6 which specifies cleaner semantics and bindings for the bytes of an IPv6 address, we show privacy protection against address-based flow correlation attacks. This can be achieved without disrupting network operations by exploiting ILNP’s separation of identity and location semantics in IPv6 addresses. Our solution can be deployed with updates to only the endpoints that require protection, and requires only standard IPv6 connectivity. We also discuss the additional security and privacy capabilities that are possible by building on this defence with ILNP.

1.2. Structure of This Paper

We first present some discussion on the key points for considering privacy for flows with respect to flow correlation, and how the visibility of addressing information is used, in Section 2. Then, in Section 3, we describe our key metric for comparative analysis and the experiments we undertook to evaluate our system in both Testbed and Global Connectivity scenarios. In Section 4, we provide a detailed description of the results from our Testbed and Global Connectivity evaluations. We conclude in Section 6, along with describing some indicators of future work.

2. Background

There are three key factors that need to be considered in our discussion of flow correlation privacy:

• Spatial flow privacy. There should not be any addressing information in packets that can be correlated across different topological sub-network points of attachment (SNPA). If a node changes its SNPA such that it is now in a different part of the IP network, an attacker should not be able to correlate flows generated by that node while connected to a different SNPA. For privacy, the desire is for there to be completely new address values when an SNPA change results in a network topology change for a node.
• Temporal flow privacy. There should not be any addressing information that can be correlated across time between different flows. An attacker should not be able to correlate multiple flows from the same node even on the same topological SNPA. For privacy, the desire is for there to be completely new address values when a new flow is created.
• Scope of trust. If an entity other than the node using an address value is involved in the generation or allocation of that address value, that entity could be compromised or act with malicious intent. This, in turn, would lead to exposure of linkage information between a node and its address values. For privacy, the desire is for the scope of trust to be confined to the node itself.

A summary of the various addressing schemes discussed in this section with respect to these key factors is given in

Table 1. A summary comparison of addressing schemes as described in this section.

Addressing Mechanism	Addressing State	Spatial Flow Privacy	Temporal Flow Privacy	Scope of Trust
SLAAC [8]	IID, 64 bits	RedNo	RedNo	RedGlobal 1
DHCPv6 [9]	IID, 64 bits	RedNo	BurntOrangePossibly/Partial 2	BurntOrangeLAN/Enterprise
SO-SLAAC [10]	IID, 64 bits	ForestGreenYes	RedNo	ForestGreenNode
TA-SLAAC [6]	IID, 64 bits	ForestGreenYes	BurntOrangePartial	ForestGreenNode
NPT [11]	IID, 64 bits	RedNo	RedNo	BurntOrangeLAN
VPN	IID, 64 bits	RedNo	RedNo	BurntOrangeService Provider
MP-TCP 3 [12]	multiple addresses, 128 bits each	(As above)	(As above)	(As above)
QUIC 3 [13]	single address 4, 128 bits	(As above)	(As above)	(As above)
ILNP eNID	NID, 64 bits	ForestGreenYes	ForestGreenYes	ForestGreenNode

¹ Once the value has been used, anyone can see it, detect it, and replicate it globally. ² This will depend on local administrative policy on use of DHCPv6 for address management, e.g., lease times for a prefix or address. ³ This is a transport-layer protocol, so has no control over address allocation to a node (any of the other schemes could be used), but the protocol might have control over address selection for a particular flow instantiation. ⁴ At the time of writing, multipath QUIC, which would allow use of multiple addresses as in MP-TCP, is not mature.

.

2.1. Address Bytes and Privacy in IP

IPv6 addresses contain both location and identity information. The upper 64 bits form the routing prefix, which encodes topological information about a network’s location, while the lower 64 bits, interface ID (IID), uniquely identify an end system at that network location [14]. As the address values uniquely identify the communicating endpoints, they are used by transport protocols as immutable identifiers for end-system state. The topological information addresses contain is necessary for routing and forwarding, so the addresses must also remain visible when packets are sent across the network. Communication endpoints for end users typically have a single public IPv6 address which they use for all communications while connected to a particular network location.

As IPv6 addresses identify end systems, are exposed to intermediate nodes along communication paths, and are reused across different communication sessions, correlation attacks are possible. These attacks are hard to disrupt, as the IP address value serves different purposes for transport protocols, for routing at the network layer, and for local network management. So, any modifications to the definition or use of address values must ensure these independent components and functions at different communication layers still operate correctly.

Note that for any given IP network, the prefix value, the upper 64 bits, is the same for all nodes on that network. So, it is the value of the lower 64 bits of the address that is of concern to us in our consideration of identity privacy in addressing.

In addition to the privacy concerns, the dual role of IP addresses as both an identity label and a location specifier has resulted in an inflexible architecture that cannot adapt well to current demands for mobility and multihoming:

• A mobile endpoint that moves between different networks will change topological location, therefore changing the routing prefix, and IP address. As addresses are part of immutable transport state, this migration forces a termination to the transport session, unless some additional state management mechanism is employed.
• A multihomed node that is simultaneously connected to multiple networks for resiliency or improved throughput—and therefore has multiple routing prefixes—is similarly unable to take advantage of those multiple routing prefixes in any transport session, as each transport endpoint for both TCP and UDP is identified by a single address (and therefore a single prefix).

While solutions for both IP mobility (e.g., Mobile IPv6 [15]) and a multipath transport protocol (e.g., MP-TCP [12]) exist, these still use fixed address values and so the same privacy concerns remain.

2.2. Changing Addressing Semantics Whilst Maintaining Interworking

Our solution is based on a radical new approach to addressing. The Identifier Locator Network Protocol (ILNP) [7,16] is an evolution of IPv6. It introduces improved functionality at the network layer through cleaner semantics of the IPv6 address by splitting the address into a Locator (L64) and a Node ID (NID), respectively, as shown in Figure 1. The L64 functions as a routing prefix, with the same syntax and semantics as for the IPv6 routing prefix, allowing ILNP packets to be viewed as IPv6 packets by routers and switches, and to allow deployment of ILNP without modification to existing routing and forwarding infrastructure. A NID has the same syntax as the IPv6 IID, but different semantics: it labels a node, rather than a single interface on that node. Unlike IPv6, only the NID values are used in transport-layer state—the L64 bits are excluded [7,16]. The L64 and NID together form an Identifier-Locator Vector (I-LV) which is used in place of the address bits in an IPv6 packet. This separation of identity and location facilitates mobility and multihoming, and also improves privacy properties, including perturbing flow correlation attacks. The implementation of our mechanism is publicly available [17].

2.3. Attacks on Identity Privacy

Privacy attacks exploiting IP addresses are not merely theoretical. By analysing real-world data on publicly exposed fingerprinting information, it has been shown that public IP addresses are often sufficiently long-lived to track a device’s activity for a month or longer [5]. Even mobile devices that connected through many different networks were vulnerable, as the set of IP addresses they cycled through could be used to identify them and to track their location. Any entity that can see IP addresses can perform this kind of attack, linking all Internet activity from a node to a single identity label.

As this attack can be performed passively and leaves no evidence, it is hard to spot it “in the wild”. However, evidence exists of various organisations performing such an attack. The Snowden leaks exposed details of a US National Security Agency (NSA) tool used for searching collected data and metadata on Internet communications [18]. Similarly, the UK government has actively employed powers granted under its Investigatory Powers Act to collect the data necessary to perform this attack [19].

2.4. Defence of Identity Privacy

These attacks exploit the IID of an IPv6 endpoint to compromise identity privacy. They key to disrupting this attack is therefore found in the management of IID values. Existing mechanisms to generate and manage IID values do not always have privacy as an objective, but can have, or are perceived to have, privacy benefits.

Typically, an IID is generated using Stateless Address Auto-Configuration (SLAAC) [8], the default mechanism for the original IPv6 specification. While the Dynamic Host Configuration Protocol (DHCP) can be used with IPv6 [9], SLAAC is the recommended approach, and the starting point for most privacy-focused innovations. It provides dynamic address management with zero administrative overhead, but was not designed for privacy—SLAAC IIDs are fixed, being derived from hardware values, such as the 48-bit values found on network interface hardware. IIDs generated in this fashion can therefore be used to correlate all flows to a particular device for the lifetime of that device and across different networks globally.

Semantically Opaque SLAAC (SO-SLAAC) modifies SLAAC’s IID generation method to remove the trackable semantics [10]. IIDs are instead generated by a hash of various values, including a software-defined secret key, and an identifier for the local network. This results in an IID that is stable for a particular node on a particular network, but will change if the machine is moved to another location, or if the secret key is changed.

While stable IIDs are convenient for some administrative purposes, stronger privacy guarantees can be achieved with Temporary Address Extensions for SLAAC (TA-SLAAC a.k.a. temporary addresses) [6]. When using TA-SLAAC, IIDs are generated as pseudo-random values with no semantics, and are periodically expired and replaced. TA-SLAAC uses two parameters, TEMP_PREFERRED_LIFETIME and TEMP_VALID_LIFETIME, to control, respectively, the time that a generated IID is usable by a node, and the time for which it is still considered valid even after it is no longer available for use by a node, e.g., if it is used in long-lived flows. So, a single IID value is used for all outbound communication during the configured period (24 h by default) before becoming deprecated, but is maintained beyond this period to avoid disrupting ongoing communications.

Periodically cycling through IID values means an attacker cannot correlate flows using a new IID with flows using a previous value. This places a temporal limit on tracking, but does not stop an attacker tracking devices laterally, by spotting simultaneous flows using the same IID within the timeframe before that IID is expired.

Although desirable for privacy, TA-SLAAC IID values face an operational challenge: they cannot be expired efficiently, as the operating system is not aware of which IIDs might still be in use. As a result, deprecated IID values must be maintained for an extended period (several days) to avoid disrupting long-lived flows. This is an additional overhead for the local network, as it requires each node to maintain a larger pool of addresses, resulting in more Neighbour Discovery Protocol (NDP) traffic and larger NDP tables. Efforts to reduce these costs are an area of ongoing research [6].

2.4.1. Network Address Translation (NAT)

Network Address Translation (NAT) (and its derivatives) allows the mapping of one address range into another. A common deployment scenario is to use NAT to allow a private network to use a single public address, reducing IPv4 address exhaustion, as is common for home broadband services.

With multiple devices using a single source address, the precision of correlation attacks is reduced; an attacker cannot trivially spot individuals—only the crowd. However, even with 1000 users behind the same NAT, fingerprinting attacks can identify individual users [20].

A NAT is also problematic as a privacy defence, as it is beyond the user’s control. A small home network NAT provides minimal protection, as the crowd will be small, and only contains devices associated with the user in some way. Hiding in larger crowds requires using larger NATs, such as a service provider’s Carrier-Grade NAT (CGNAT). However, CGNATs are operated by the service provider, upstream, so a user’s domain of trust must extend beyond the device in use. The user:

• must trust the upstream provider regarding the CGNAT function and state;
• cannot opt to use or not use the CGNAT as a privacy feature;
• cannot determine how many others are online to infer how strong the privacy protection of the crowd is.

NAT is not as widely used with IPv6, due to the absence of address exhaustion concerns, but might be used in enterprise networks for easing address management locally. Network Prefix Translation (NPT) [11] is a similar mechanism to NAT for facilitating private addressing for IPv6, but, as the name suggests, only adjusts the routing prefix and not the IID value, so it does not provide even the limited privacy benefits of NAT.

Overall, address mapping systems like these do not improve identity privacy in a meaningful and verifiable way.

2.4.2. Virtual Private Network (VPNs)

A common defence is to use a Virtual Private Network (VPN): communication flows are tunnelled through a third party, and it is their address that is exposed to an attacker, rather than the client’s. As a VPN connection (virtually) places a device on a different network, it will use a different routing prefix. This provides location privacy but not identity privacy, as an attacker can still correlate flows based on IID values from the virtual network addresses. So, VPNs still need identity privacy solutions.

As with CGNAT, VPNs (and other solutions from external service providers), present additional challenges. The user must trust their VPN provider—a third party with a privileged view of the communication—to act with integrity, and be free from compromise. VPNs also require indirection (including non-optimal routing) and traffic encapsulation, incurring a performance cost. Finally, use of VPN communications are blocked or considered illegal in some countries, and vulnerable to legal intercept in others [21].

Other privacy solutions that rely on indirection are vulnerable to the same classes of issue, e.g., Tor [22], which, in addition to non-optimal routing and legal barriers, has the added disadvantage of relying on an overlay network of application-specific gateways, so does not provide a general-purpose solution.

2.4.3. QUIC

QUIC [13] is a transport layer protocol built on top of the User Datagram Protocol (UDP), and is designed to function as an alternative to the Transport Control Protocol (TCP). It was designed with several improved functional and performance characteristics including improvements to privacy and security. However, while transport-layer protocols are able to meet some of the challenges of linkability of packets within a flow, they still rely on the use of network layer IP addresses. So, even with the proposed privacy improvements of QUIC, network-layer identity privacy is still beneficial. QUIC’s proposed privacy solutions apply to different concerns from this work, although both solutions could be used together to resolve each of these concerns without disrupting the other defence.

2.4.4. Ephemeral NIDs for ILNP

Under ILNP, NIDs take the place of IPv6 IIDs, and, by default, are reused in different flows as in SLAAC. However, ILNP’s addressing architecture make it possible to use ephemeral NIDs (eNIDs) for a single transport layer flow, after which an eNID value can be discarded. Like temporary addresses in TA-SLAAC, this prevents an attacker correlating different communication flows based on a common address value. However, in TA-SLAAC, the timeframe of validity of the IID value is an administrative control that is independent of the timeframe of a flow duration, and so IID values are reused across multiple flows. In contrast, ILNP eNIDs are part of the local transport layer operation, so:

• they provide stronger support for both spatial flow privacy and scope of trust, as eNID values are generated locally, at the source node, as pseudo-random values;
• they provide stronger support for temporal flow privacy because eNID values are never reused, even by simultaneous flows;
• their use confines the scope of trust, as the transport protocol state information is maintained at the source of the flow, so the communication does not rely on additional entities, e.g., as in CGNAT, which might be subject to address reconnaissance attacks [23].

Previous work on emulated networks has shown that eNIDs should provide better protection against correlation attacks than TA-SLAAC [24]. eNIDs have since been implemented as part of the ILNP support in FreeBSD14 [17], and this paper shows their behaviour and evaluation in two real network scenarios: a local IPv6 testbed; and the global IPv6 Internet.

3. Method and Implementation

There are four main requirements to consider in terms of evaluating the efficacy of our approach with eNIDs.

• A flow privacy metric. To evaluate the privacy of flows, i.e., a way to measure flow correlation. This must work across multiple flows and over both spatial and temporal dimensions.
• Implementation in IPv6. A demonstration that eNIDs can be implemented on a node within the scope of the current IPv6 specification as proposed.
• Communication across IPv6 networks. A test to show that the modified packets can be transmitted successfully across existing IPv6 infrastructure as proposed.
• Use by existing IPv6 applications. A demonstration that eNIDs can be used by existing, unmodified IPv6 applications.

3.1. Flow Privacy Metric

As the attacker’s goal is to correlate communication flows from the same source, identity privacy can be measured based on the number of clusters into which an attacker classifies the set of flows from a client machine. A successful attack will create a single cluster, as the attacker correlates all flows with the same origin. A totally ineffective attack will create one cluster per flow, failing to correlate any pair of flows from the same origin.

“Clusters per flow” quantifies the effectiveness of a defence against this attack by indicating how frequently an attacker must create a new cluster for the flows it detects. With one cluster per flow, every new flow is a new cluster and so no flow correlation is possible. With less than one cluster per flow (i.e., more than one flow per cluster), the attacker is able to start correlating flows. The degree of flow identity privacy, $P_f$, can therefore be expressed as the ratio of flows from a node (f) to the number of clusters the attacker creates (c):

$$P_f={\displaystyle \frac{c}{f}}$$

(1)

A $P_f$ value of 1 is the best value for privacy, and means c and f are equal: each flow is in its own, unique cluster, and no linking information is exposed, completely thwarting the correlation attack. In the worst case, when all flows are linked to the same source, c is 1 and all flows are in that same cluster, so $P_f$ will approach a limit of zero; each new flow decreases $P_f$ by increasing the linkage between the flows that are visible to the attacker.

Figure 2 shows the mathematical behaviour of this metric over time as an attacker observes flows and clusters them based on an estimate of the source identity, e.g., in our case, by inspecting the source address bits. Depending on how effective the clustering method is, that attacker might correlate more or fewer flows, resulting in the different lines shown. Whenever the attacker is forced to create a new cluster, c increases, which increases $P_f$.

3.2. Implementation in IPv6

Support for eNIDs was built as an extension of the existing support for ILNP in FreeBSD14 [17]. Compared to NIDs, eNIDs require new mechanisms to generate NID values, allocate them to sockets, and expire them once used. In all other respects, eNIDs function like regular ILNP NID values. That is, with respect to the discussion in Section 2.2, only the lower 64-bits of the IPv6 address (used for the IID in IPv6) need to be generated dynamically for each flow.

Ephemeral NID values are generated randomly using the same method as for IPv6 TA-SLAAC [6]. As with TA-SLAAC, eNIDs are generated before use so that IPv6 Duplicate Address Detection (DAD) [25,26] can be completed before the NID is required. In order to facilitate the initiation of multiple communication flows in short succession, a pool of available eNIDs can be maintained. The necessary size of this pool depends on both the expected workload of the node, and various other tunable parameters such as maximum retransmissions for DAD, so this can be configured by a user via the sysctl API [27].

ILNP already tracks which NIDs are in use in order to facilitate dynamic updates of location information. eNIDs further utilise this information to track which NID values have been allocated to a socket, so should not be reused, and which are associated with closed sockets, so should be discarded. IPv6 does not have a convenient way of checking if IID value are in use by an active transport flow, which causes performance issues for use of TA-SLAAC. The state management for eNID values for ILNP are summarised in Figure 3 and

Table 2. Permitted operations in each NID State (please see Figure 3b). A NID must be Available for Use to be used by a new transport session, and Safe to Delete to remove. Only NID values that are In Use will be used to send or receive packets.

State	Available for Use	In Use	Safe to Delete
VALID	Yes	No	No
ACTIVE	Yes	Yes	No
EXPIRED	No	Yes	No
INVALID	No	No	Yes

.

From an application’s perspective, using eNIDs is no different to using a single, static NID under ILNP, or using a single static IID for IPv6—the application only needs the NID/IID value to remain stable for the duration of a transport layer flow. The use of ILNP is also transparent, with IPv6 applications able to use ILNP’s enhanced functionality just by running on an ILNP-aware operating system. So, no changes to existing applications or socket APIs were necessary.

As with IPv6, the operating system eventually frees all socket structures, either when the flow terminates correctly, or when an error in the parent application process causes it to be killed. The expiring of an eNID value is tied to this mechanism, ensuring that the eNID value is not removed while still in use, but is removed as soon as possible. This also allows the node to immediately stop responding to Neighbour Solicitations for that eNID, reducing the costs to the local network when compared with TA-SLAAC.

For simplicity, compatibility, and ease of implementation, generation of eNID values can use the same methods as used for generating IID values for TA-SLAAC. The TA-SLAAC specification [6] gives guidelines that are used for generating IID values in two different ways:

• simple generation of pseudo-random values with randomness requirements and properties as already agreed by the wider Internet community [28];
• generation of probalistically unique pseudo-random values based on functions that take various input parameters, so that existing IID generation functions (such as those used for SO-SLAAC [10]) can be re-used;

Our implementation used the first mechanism to generate eNID values. However, the management of eNID values differs from the TA-SLAAC specification with respect to:

• initial generation of eNID values: eNID values can be pre-generated and maintained in an eNID pool so that they are ready to use when needed, or they can simply be generated just-in-time, e.g., as part of the process of creating a new socket or communication end-point.
• expiring eNID values: an eNID value must not be re-used, but must be expired and deleted from use as soon as the communication flow using it is terminated, e.g., when the socket or communication end-point is deleted.

Indeed, the use of eNID values makes generation and management simpler than TA-SLAAC, as there is no need to maintain and manage additional parameters (such as TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME), or to have additional complexity in managing IID values for long-lived communication flows that might still be in use.

3.3. Communication Across IPv6 Networks

This requirement was evaluated in two ways:

• Lab-based IPv6 testbed. A Testbed was configured using consumer equipment at the University of St Andrews, including desktop workstations and a commercial IPv6 router. This gave an environment for reproducibility in making measurements of test traffic against the metric $P_f$.
• Global IPv6 network. With connectivity between the University lab and the Global IPv6 network at an Internet Engineering Task Force (IETF) Hackathon (IETF118). This test used the Global IPv6 Internet connectivity between the University of St Andrews (UK) and Prague (CZ).

3.3.1. Lab-Based IPv6 Testbed

eNIDs are an alternative to SLAAC and TA-SLAAC for managing IID values. For our demonstration, each of these mechanisms was used to defend an identical set of application-layer exchanges against an eavesdropper.

Figure 4 shows the Testbed topology, and the analogous real world scenario. The traffic was produced by a set of three clients fetching web pages from a server. The server had multiple IP addresses, and served different web pages on each, giving the same behaviour as having three different servers—one with each IP address. Clients were connected to the server by a backbone network of three edge routers, one of which acted as the attacker.

The client nodes requested web pages using the curl program, and the server node ran the widely-used nginx web server software. These binaries were not modified in any way: ILNP support, including eNIDs, was provided transparently by the modified branch of the FreeBSD 14.0-CURRENT operating system. The routers were unmodified Ubiquiti EdgeRouters running EdgeOS routing software, and were configured to route IPv6 traffic: ILNP packets are routed in exactly the same way as IPv6 packets, so this network provided the same behaviour in each test case.

In each experiment, each client used curl to request the three pages available on the server every 5 min for a 24-h period. Three cases were tested:

• In the first case, each client machine configured a single, fixed address using SLAAC, and used it for all connections.
• In the second case, each client used TA-SLAAC. The TA-SLAAC addresses were configured to become deprecated after 1 h, and be expired after 1 h more. This provided the same characteristics as the default 24-h period, but with greater privacy, as address reuse was decreased. Decreasing this further was limited on FreeBSD by traffic storm counter-measures.
• The third case used eNIDs for each client, i.e., each flow had a different NID value.

In each case, every packet seen by the attacker was recorded. Due to the constrained storage space of the EdgeRouters, this packet capture was performed by the server node using tcpdump, instead of on the router. As both nodes see every packet from every flow, this produces the same view of the exchanges. The packet capture was analysed using Suricata, a widely-used, open-source, network analysis and threat detection platform, to detect TCP flows. The detected TCP flows were then correlated based on the IID bytes (lower 64 bits) of the IPv6 source address field.

3.3.2. Global IPv6 Network

The test was performed at a public venue, the Hackathon event of the Internet Engineering Task Force (IETF), IETF118 in Prague, Czechia (CZ). The test involved communication between a node acting as a client system in Prague, and a similar node in St Andrews (UK) acting as a server system. The network addressing and topology is shown in Figure 5.

To distinguish all ILNP packets from normal IPv6 packets at end systems, an IPv6 Destination Option (as in Section 4.6 of RFC8200(S) [29]) is used, which we refer to as the Nonce [30]. This places a randomly generated value in a specially-defined IPv6 Destination Option header which both identifies the packet as an ILNP packet (for correct processing at the destination) and provides some protection against off-path packet spoofing.

Application flows were generated sequentially and separately with rsync (TCP), ping6 (ICMP), and ssh (TCP). The traffic between server and client was captured at the server, i.e., the packets that had successfully traversed the IPv6 Global Connectivity.

3.4. Use by Existing IPv6 Applications

For transparent use in existing IPv6 applications, the aim was to allow existing applications that use IPv6 to be able to use eNIDs without modification or recompilation. In FreeBSD, name resolution is performed by libc via the getaddrinfo function [31]. The expected programming API call pattern for a client, for example, is:

• make a call to getaddrinfo [31] to resolve a name to an IP address;
• create a socket [32] for a communication endpoint;
• and connect [33] to the address using the socket.

This implementation therefore assumes that any attempt to connect to an ILNP-capable host will be immediately preceded by an attempt to resolve the name of that host. As name resolution is performed by a library and not the application itself, the function can be patched without disrupting programs that use it. Note that while our example is in C, most of the popular programming languages in use today are built on C and use the main C library, libc, (e.g., Python, Rust, Java, Javascript, Go, etc.). The process of name-resolution using getaddrinfo first checks for entries in /etc/hosts [34], so the implementation was patched to handle ILNP entries in /etc/hosts, the format for which are shown in Figure 6. Like IPv6 addresses, the textual representation of I-LV values splits the value into two-byte character groups. Unlike IPv6, no shorthand (::) is supported—all character groups must be explicitly stated, although leading zeros may be omitted, provided at least one digit is given. The ‘-’ (minus) character is used as the separator in L64s, and the ‘+’ (plus) character in NIDs, with the two values being separated by a ‘.’ character. This is all to avoid ambiguity in use of IPv6 addressing vs ILNP addressing.

Note that while ILNP also does have Domain Name System (DNS) records defined and supported in DNS server software [35], for our evaluation, we chose to use local modifications in /etc/hosts. This allowed the creation of a self-contained experimental Testbed, which is also more easily reproducible, and removes a variable from evaluating any protocol-level behaviour for our evaluation (no need for DNS servers and DNS communication). For the modified use of /etc/hosts, within libc, the modifications made to the processing for a name resolution are shown in Figure 7.

In short, any existing application can use ILNP and the eNID mechanism transparently. This means that existing applications benefit from the use of eNIDs without requiring any re-design, re-engineering, or even recompilation—existing program binaries that use IPv6 will gain use of eNIDs directly and immediately.

Unmodified program binaries were used both in the Testbed network (Section 3.3.1) and the Global network (Section 3.3.2) evaluation. The list of software is given in

Table 3. This is the list of software applications used in the evaluation and which network scenario each was used in. All applications were unmodified, using pre-compiled binaries from the relevant FreeBSD14 repositories.

Software (Version)	Testbed Network	Global Network
curl (7.76.1) [36]	Yes	No
nginx (1.20.0) [37]	Yes	No
EdgeOS1 (4.12.52-UBNT) [38]	Yes	Yes
tcpdump (4.9.3) [39]	Yes	Yes
Suricata (6.0.4) [40]	Yes	No
rsync (3.3.0) [41]	No	Yes
ping6 (–) 2 [42]	No	Yes
ssh (9.6p1) [43]	Yes	Yes
tshark (4.2.5) [44]	Yes	Yes

¹ This software is the standard installation on the Ubiquiti EdgeRouter 6P [45] platform used in the tests, a commercially-provided binary image for a commercial piece of hardware, and is not based on FreeBSD. ² No version number is available for this. However, according to the man page, this was the standard binary for FreeBSD-14.0-STABLE, September 2023.

.

4. Results

In this section, we present results from our Testbed to show the behaviour of the system that has been created. We then show tests over IPv6 Global Connectivity.

4.1. Observed Flow Privacy

This test was performed on the Testbed configuration as described in Section 3.3.1. The Testbed included commercial IPv6 routers, so there is an initial test to demonstrate that ILNP packets using eNIDs are treated as IPv6 packets. Additionally, a standard web server, nginx, was used with a standard command-line client, program, curl, as described in Section 3.3.1. The Testbed configuration allowed for controlled, repeatable measurements and traffic capture for assessing the $P_f$ values for the flow privacy metric requirement of Section 3.

With reference to the other key evaluation requirements discussed in Section 3, this connectivity test demonstrated Implementation in IPv6, and also use of eNIDs for partially testing both Communication across IPv6 networks and Use in existing IPv6 applications.

Table 4. Observed values for $P_f$ after all flows were complete (3 s.f. where required, details of test execution in Section 3.3.1). As expected, the final $P_f$ values for SLAAC approach 0, and the values for eNIDs are stable at 1. TA-SLAAC falls between these bounds, with some variability between clients due to the precise timing of when new IID values were instantiated compared to the start of flows in the client-server communication.

		Client
	A	B	C
Defence
SLAAC	0.001	0.001	0.001
TA-SLAAC	0.032	0.031	0.029
eNIDs	1	1	1

shows the final value of $P_f$ for each client after the attacker observed all flows. In the SLAAC case, where a single static address was used, 864 flows were observed from the client, and all used the same source address. This results in f of 864 and c of 1, so $P_f={\displaystyle \frac{1}{864}}=0.001$ for all machines.

With TA-SLAAC, there was a variation based on when exactly addresses happened to expire relative to the start of flows. This resulted in c of 28, 27, and 25 for the three clients, yielding $P_f$ in the range 0.029 to 0.032. In all cases, TA-SLAAC provided better privacy than a static address with SLAAC, but were outperformed by eNIDs.

With the use of eNIDs, $c=f=864$, so $P_f$ was always the maximal value of 1.

Figure 8 shows how $P_f$ changed as new flows were observed. eNIDs maintain an equal ratio of identifiers and flows, so $P_f$ is always stable at 1. For SLAAC, each flow adds to the data that the attacker associates with the client, so $P_f$ decreases, approaching zero. For TA-SLAAC, some flows cause $P_f$ to drop (when flows are added to a cluster some time after it has been used), while others cause it to increase (when a fresh IID and IPv6 address is used). The flows causing a decrease in $P_f$ reuse an identifier—c remains the same as before, but f increases—while the flows causing an increase in $P_f$ do so by introducing a new identifier.

4.2. IPv6 Global Connectivity Test

A test of connectivity and application usage was performed for the implementation across the global Internet with IPv6 as described in Section 3.3.2. With reference to the key evaluation requirements discussed in Section 3, this connectivity test further demonstrated Implementation in IPv6, and also use of eNIDs for both Communication across IPv6 networks on wide-area connectivity, and Use in existing IPv6 applications.

The program binaries were unmodified—they were installed directly from the FreeBSD repositories. By adding entries with names and I-LV values in /etc/hosts, the mechanism described in Section 3.4 ensured that all flows were ILNP flows at the network level. As the flows were generated at the client, the packets were captured at the server using tcpdump to show that ILNP packets had indeed traversed the global Internet.

The applications operated correctly at the user level. From our results, we observe the following features:

• All packets generated were ILNP packets (rsync, ping6, ssh).
• All packets were seen as IPv6 packets in the network and forwarded correctly.
• TCP flows were set-up and terminated correctly, with correct operation of TCP algorithms during data transfer (rsync, ssh).
• ICMPv6 packets were handled correctly (ping6).
• The server system did not use eNIDs to demonstrate that eNIDs can be used at the client independently of the server.
• The tests with rsync and ssh ran over secure connections showing further compatibility of eNIDs for use in secure communication for applications.
• NID values are different for each flow.

The last two features are easiest to observe in the ping6 packet capture. This test consisted of 3 runs of ping6 in succession, each of 10 packets. Each run of ping created a new socket and so each has a new eNID value.

4.3. Data Files to Support the Findings

A number of pcap files (listed in

Table 5. List of the pcap files for the experiments carried out on the Testbed network and the Global network. All communication was initiated from a client system so that the eNID values are generated on-demand when a communication starts.

pcap Filename	Network	Flows	Application
testbed-data/slaac.pcap	Testbed 1	864	curl, nginx
testbed-data/ta-slaac.pcap	Testbed 1	864	curl, nginx
testbed-data/enid.pcap	Testbed 1	864	curl, nginx
ietf118-data/rsync.pcap	Global 2	1	rsync
ietf118-data/ping.pcap	Global 2	3	ping6
ietf118-data/ssh.pcap	Global 2	1	ssh

¹ See Figure 4 and Table 3. ² See Figure 5 and Table 3.

) of the data traffic generated for our experiments were captured using tcpdump and then analysed using tshark to provide evidence for the results.

The Testbed pcap files are all ‘raw’ captures—they contain the TCP flows created, plus the normal control-plane traffic for IPv6, such as Router Advertisements (RAs). As noted in Section 3.3.1, the Testbed experiment involved:

• emulating three servers, and these can be seen as the three separate IPv6 addresses:
  2001:0db8:0011:00cc:0000:0000:00dd:00XX
  where XX is 11, 22, or 33.
• emulating three clients, and these can be seen as three separate IPv6 prefixes:
  2001:0db8:0022:00YY/64
  where YY is dd, ee, or ff.

The Global pcap files have been filtered to include only the relevant packets for the relevant TCP flow from the IETF118 Hackathon venue to the St Andrews server. The client addresses all had prefix 2001:67c:1232:eee1/64, and the server address was 2001:630:35:0:138:251:30:221.

5. Discussion

Overall, the use of eNIDs makes it impossible for an attacker to perform a flow correlation from using source address values, which is an attack that is easily realised today. Additionally, there are other possible security benefits from use of eNIDs.

5.1. Ephemeral Identifiers Improve Inter-Flow Privacy

Ephemeral NIDs are superior to TA-SLAAC in terms of the privacy they provide, and the way in which they are managed. TA-SLAAC improves privacy by reducing address reuse between flows; eNIDs eliminate it entirely. The summary of the key characteristics and the improvement with the use of eNIDs is shown in

Table 6. Features of different IID management mechanisms under their default configurations.

Mechanism	IID Reused	IID Expired	Linkable Flows
SLAAC	Yes	Never	All
TA-SLAAC	Yes	After 24 h	Some
eNIDs	No	End of flow	None

.

eNIDs provide the logical conclusion to the development of temporary addresses:

• the use of an eNID for a single flow gives temporal privacy;
• the pseudo-random generation on a node independently gives spatial privacy;
• the generation of the values on the node itself confines the scope of trust to that node.

These benefits apply even if the remote host does not support ILNP: ILNP is defined to fallback to use IPv6, using the NID and L64 as the IID and routing prefix, respectively. The mechanism for managing eNIDs would continue to function, preventing reuse, even though the NID was being used as an IID for IPv6. Similarly, the logic used to manage eNIDs could, in principle, be used to manage IIDs for IPv6. However, this would require changes to the IPv6-layer and transport-layer code to correctly deal with the use of eNIDs as IIDs, with new data structures and additional coding for correct behaviour to associate and manage IIDs with transport state. Of course, this behaviour is already implemented as part of ILNP and has a greater semantic cohesion within the use of the ILNP addressing architecture compared to IPv6.

Other mechanisms that hide or rewrite addresses do not provide the same protection. NAT-like mechanisms for edge networks potentially increase the number of users behind a single IP address, however this represents only a small change in the granularity of the attack, and individuals within that group may still be identifiable [20]. CGNAT potentially hides users in larger crowds, but is beyond the view of the end system, so users cannot verify that it is in place or check how large the crowd is. For IPv6, the limited privacy protection of NAT-like approaches is especially pronounced, as NPT leaves most of the IID bytes unmodified, exposing identity information about the nodes behind the NPT gateway. Address rewriting does not reliably or effectively protect identity privacy, but eNIDs do—even when used in conjunction with a mechanism like NPT.

VPNs and Tor both hide IP addresses by tunnelling connections through extra servers in order to protect location privacy. As the management of these tunnels is costly, they are often shared by all connections from a device. As all connections use the same tunnel, they can be correlated to a common IID or IP address: the address corresponding to the end of the tunnel. While this value will not relate to the device itself, it is still sufficient to perform an identity privacy attack. These defences aim to protect location privacy (or hide the topological location), and do not try to protect identity privacy, so should not be used to do so.

Also, NAT, CGNAT, VPNs, and Tor all rely on additional entities in the network being trusted and being sufficiently protected from compromise.

Finally, as eNID values are pseudo-random values, their use in ILNP has a number of advantages over cryptographic techniques (such as tunnelling) to prevent flow correlation based on source address values:

• they have a much lower computational overhead than cryptographic techniques, so can be used on a range of devices and systems;
• they are not subject to national restrictions that might exist for cryptographic algorithms, so implementations can be used globally, including sharing of code;
• the eNID values can be generated independently on the node to confine the scope of trust, but there is the potential for further security benefits if a wider scope of trust is possible (see Section 5.5 and Section 5.6).

5.2. Ephemeral Identifiers Reduce Traffic Overhead

As it is hard to determine if addresses managed by TA-SLAAC are still in use, the operating system must maintain deprecated IIDs for several days after they stop being used in new flows. This results in the host maintaining a large pool of addresses, despite almost all of them being unused. When performed by all hosts on a network, the resulting gratuitous IPv6 Neighbour Discovery Protocol (NDP) traffic may adversely impact network performance, resulting in pathological behaviour in caching, and in handling of multicast traffic [46]. eNIDs avoid this problem, as ILNP behaviour can already immediately determine a NID that is no longer in use, and remove it from the end-system state, preventing gratuitous NDP overheads. So, in addition to providing stronger privacy protection than TA-SLAAC, eNIDs alleviate a known performance limitation for which TA-SLAAC does not yet have a satisfactory solution.

With eNIDs, all NDP traffic is ‘useful’—it relates to a NID that is either in use, or potentially about to be used, and never to a value that will not be used or is no longer being used (as can happen with TA-SLAAC). However, excess traffic is still undesirable, especially if each host maintains a large pool of available eNIDs. The overheads could be reduced further by using Optimistic DAD [25,26]. Optimistic DAD is an optimisation of IPv6 DAD that allows a host to generate an IID value and begin using it immediately, rather than waiting to complete DAD.

With Optimistic DAD, a host could generate eNID values just-in-time, rather than maintaining a pool of pre-generated values. This would reduce NDP traffic to only that related to in-use addresses, allowing an inactive node to maintain a minimal (even zero) eNID pool. While this could cause bursts of NDP traffic when a node initiates many flows at once (such as browsing to a webpage with lots of third party content), these bursts would be short, and inter-spaced with periods of low or no activity. The aggregate behaviour of all nodes on the network would therefore have little adverse impact overall.

Even in a default deployment scenario using unmodified DAD, eNIDs have the potential to reduce the high volume of control traffic incurred by alternative solutions like TA-SLAAC. In large networks where scalability is a particular concern, Optimistic DAD—which would already be desirable in such cases for improving the scalability of any IPv6 deployment—complements well the use of eNIDs to reduce control messaging even further. So, eNIDs can be deployed to large or corporate networks without a scalability concern. There may still be an additional administrative cost in correctly configuring eNID pool size or Optimistic DAD parameters if default values were not appropriate for some specific deployment scenario, however this is typical when deploying any configurable system.

5.3. Intra-Flow Privacy

A $P_f$ value of 1 indicates the best possible outcome for inter-flow identity privacy, but does not provide protection for intra-flow privacy. That is, packets within a single transport session can still be correlated based on NID values. A stronger privacy guarantee might ensure that no two packets could be correlated back to the same source, rather than just no two flows. However, this is not possible under the existing network abstraction, which requires the (visible) transport state to be immutable to maintain the end-to-end transport state for a flow.

A partial solution to this problem has been proposed using QUIC [13]. Under QUIC, a single transport session may be multiplexed over multiple UDP subflows. Each of these subflows is a traditional transport session, so must have immutable transport state, but this can change between subflows. As a result, a single QUIC session can appear as multiple UDP flows on the network. These are reassembled using QUIC session IDs that are cryptographically protected, so cannot be exploited by an attacker. If each UDP subflow has different transport state (such as a different eNID), an attacker would be unable to correlate them to the same QUIC session or source node. In extreme cases, QUIC could send every packet out using a different UDP subflow, providing per-packet unique addressing for maximum intra-flow identity privacy.

While QUIC’s solution has the potential to provide excellent identity privacy protection, it has four key problems:

• It is bound by the number of IP addresses a node has: in order to use multiple UDP flows, the node must have multiple public IP addresses. This is typically not true, and might not be possible if, for example, the node was behind a NAT.
• As discussed above, a single node maintaining a large pool of IP addresses introduces performance concerns for the network, which eNIDs can reduce.
• The application must take care in managing the use of multiple addresses to prevent reuse, especially between sessions. Unlike the in-kernel approach of eNIDs, there is no clear mechanism for applications to access this network-layer state.
• Applications must be re-engineered and re-deployed to use QUIC, and existing (legacy) applications and transport protocols, such as UDP and TCP, cannot benefit.

Note that eNIDs solve all four of these problems.

QUIC and eNID solutions to privacy are targetted at different problems, and each occupy a different niche: eNIDs provide inter-session privacy for all flows, regardless of transport layer protocol; QUIC’s multiplexing provides intra-session privacy for applications that choose to use it, under constraints based on available addresses. When used together, QUIC’s solution extends the privacy guarantees further than eNIDs alone, while eNIDs provide the in-kernel mechanism for managing addresses that QUIC requires. So, there is a strong synergy between the two defences, and we expect they can be used together effectively in the future.

5.4. Deployment and Scalability of eNIDs

Deployment of the eNID mechanism is performed by updating a node’s OS image to include the modifications for ILNP with eNIDs. As evidenced by our implementation [17], it is possible to modify existing protocol code for an existing OS. This would then be deployed using automated remote (aka “over-the-air”) updates that are now common for software systems including OS distributions.

The use of eNIDs modifies the IPv6 packet format only, and does not introduce any new control protocol messages, or require new network entities, such as proxies or gateways. So, the eNID mechanism can also be deployed incrementally, only by the nodes that need it, and used without requiring any network upgrades. For the tests and experiments described in Section 3.3.1 and Section 3.3.2, standard, commercial equipments was used, and no special configuration was required for the network components. ILNP packets using eNID values have a wire-image that is seen as an IPv6 packet.

In terms of scalability, similar arguments apply. The ILNP-enabled/eNID-enabled OS images need only be deployed by those nodes that need to use them—a complete upgrade to all netwokr nodes is not needed. Again, for the tests and experiments described in Section 3.3.1 and Section 3.3.2, there was no impact in terms of overhead on the other nodes or network components in those networks. As discussed above in Section 5.2, use of eNIDs at scale is likely to reduce local NDP traffic compared to TA-SLAAC. As the eNID generation and management is purely local to the client node (the initiator of the communication), there is no additional administrative overhead in deployment or operation.

Server systems do not need to be aware that eNID mechanisms are in use by clients. Although our focus has been on privacy for client nodes, we discuss below the use of eNIDs at the server-side (Section 5.6).

5.5. Additional Benefits from Some Shared State and Wider Scope of Trust

The key innovation eNIDs take advantage of—the separation of identity and location semantics in ILNP—has other potential uses. Our results show that transport sessions can operate correctly with arbitrary NID values.

This work has focused on using random NID values to protect identity privacy, with a node acting independently with the scope of trust confined to the node itself. However, if the user is prepared to extend the scope of trust beyond the node where the eNID value is generated, for example in an enterprise scenario, then additional benefits arise in security as well as privacy. By controlling the method used to generate eNID values, new semantics could be added to ephemeral NIDs, including opaque and covert identity checks.

All of the possibilities outlined below would require some shared state between the communicating node and another entity, and so some additional protocol for synchronising on that state would be required. Such a synchronisation protocol is beyond the scope of this work. However, we note that protocols do exist that could be modified to perform such functions at different layers in the network stack, such as using a Diffie–Helman key exchange to establish shared secret state [47] or the double ratchet algorithm [48] to provide stronger security guarantees about the shared secret on an ongoing basis.

If two nodes wish to communicate regularly, they could agree a shared secret from which to seed a pseudo-random generator for eNID values—functioning like a key derivation function. eNIDs values generated by this method would still be ephemeral and opaque, so would continue to provide identity privacy. However, as they would be predictable to nodes with access to the shared secret, they could be used as a lightweight authentication method.

This defence could be particularly effective against Denial of Service (DoS) attacks. These attacks work by overloading a server with spoofed traffic. One countermeasure is to make session initiation more costly for the client than the server by requiring a proof-of-work check. This makes the attack extremely costly to perform, but delays session initiation even for legitimate users. If a shared secret were established after the first session initiation, future sessions with the (trusted) client could then use eNIDs values generated from shared state to provide enough authentication to bypass this costly step.

The shared secret could also be communicated securely to middleboxes, such as firewalls or content delivery network (CDN) providers. In stateful firewalls, this would provide a lightweight mechanism for authenticating trusted clients based only on a single network layer field while also protecting the client’s identity privacy. Existing firewalls, including those implemented in hardware, e.g., via Field-Programmable Gate Arrays (FPGAs), already use address values as decision-making state [49,50]. As the only change this authentication method requires is to the control mechanism for initialising that state, it is anticipated that there would be no adverse effect on the performance of the firewall.

In the CDN case, the secret could be shared with only the client and the CDN provider. This would allow the CDN to block DoS attacks against a wide range of services, while the client’s identity privacy was protected even from those services.

5.6. Use of eNIDs at the Server Side

Our focus in this paper has been on providing client-side flow privacy—flows generated by a client cannot be correlated when eNIDs are used. However, there are possible security benefits in using eNIDs at the server-side to protect either an individual server or a set of servers providing a service.

There are at least two significant challenges to assess when considering use of eNIDs at the server-side:

• the scalability of the use of eNIDs;
• the need for interaction with the Domain Name System (DNS) service.

For the first point, a client system using eNIDs might typically have several tens of flows concurrently in use, and so several tens of eNIDs/ILVs/IPv6 addresses. Possibly, a particularly active client could peak at have a few hundred concurrent flows, and therefore perhaps few hundred eNIDs/ILVs/IPv6 addresses. There is no definitive study on such numbers, and they depend on the client’s application behaviour and user activity. However, a server system might have many hundreds, thousands, or several tens of thousands of concurrent flows, and so a matching number of eNIDs/ILVs/IPv6 addresses in use.

For the second point, the norm is to use addresses that are easily discoverable by clients via the DNS by looking up a fully-qualified domain name (FQDN) for a server or service. For technical and administrative convenience, IPv6 addresses that are held in the DNS are typically semi-permanent, usually configured through some sort of (human-controlled) administrative process, and not ephemeral, automatically generated on demand. So, if eNIDs are to be used for application servers, there is likely to be need for some coordination between the application server and the DNS service—a DNS-application interaction. Coupled with the first point above, this DNS interaction could be significant, and could impact performance of the service overall, e.g., by increasing the latency when establishing connections.

This creates two considerable challenges for the use of eNIDs at the server-side. So, such usage is likely to be constrained to those cases where the cost of implementation of server-side eNIDs is considered acceptable compared to the benefit that is provided. Overall, from a scalability and performance perspective, use of server-side eNIDs is likely to be restricted to smaller scenarios, such as for a small enterprise network or campus network.

We do not enumerate here all potential uses cases for eNIDs at the server-side, but highlight one particular possible use case which demonstrates the potential utility of eNIDs for an individual server or a service—an address-based capability system for access control and prevention of traffic-based DoS attacks.

Our use case in this discussion is based on previous studies that proposed the use of capabilities [51] for access to services, but based on the use of dynamically generated addressing information [52]. A simple scenario for the use case is shown in Figure 9.

When Client, C, wants to contact to Server, S, it generates a name-lookup for the FQDN of S via the DNS, as normal. The server or service providing DNS name resolution for S is denoted by the DNS server, D, which has been modified to generate eNID values for S. When D sees a new client request, it generates a new eNID value, e1, to return in the DNS response to C. At the same time, it notifies both F and S of the value e1, so that they can both expect an incoming TCP connection using value e1 in the NID/IID portion of the destination address in the IPv6 packet header.

This perturbs forged connection requests by making the attack more resource intensive and harder to execute for an attacker. Now, instead of just generating forged packets from any point on the network, at the very least, an attacker would need to use a valid source address in the outgoing packet to be able to receive the DNS response to then make a correct TCP connection request. Also, even if the DNS request and the response are not protected using encryption, this mechanism helps to prevent off-path forged traffic attacks, as the address to use for the server changes for every client.

This mechanism would not be used by itself, but would added to the toolbox of possible mechanisms to be used together—for example, it could be used with suitably adapted traffic packet filtering [53] or rate limiting techniques at the firewall. It is best suited to an enterprise scenario or another scenario where F, S, and D are within a trusted administrative domain, as it is clear that F, S, and D must work together and have trusted communication for this system to work securely.

Finally, if eNIDs are used at both server and client, then for an attacker inspecting source and destination address values in IP packets, each flow looks like it is from a different client and to a different server.

6. Conclusions

Ephemeral NIDs prevent flow-correlation attacks by avoiding address reuse, and can be implemented completely in end-systems. This is an evolution of the approach already taken by temporary addresses as in TA-SLAAC, but provides stronger privacy protection.

The comparison presented in our Testbed experiments uses ILNP’s semantics of addressing and address bindings at client end-points for ephemeral identities. Our experiments show: (1) that flow-correlation attacks from an on-path attacker can be thwarted effectively; (2) that ephemeral NIDs outperform the use of temporary addresses with TA-SLAAC; and (3) that ephemeral NIDs can be used with existing (legacy) transport protocols and legacy applications. Further, we argue that careful generation of ephemeral NID values could also provide a lightweight network-layer authentication method that could aid in countering denial of service attacks.

Future Work

eNIDs provide protection for the lower 64 bits of the address field. The upper 64 bits—the routing prefix under IPv6, or ILNP Locator (L64)—cannot be changed in the same way, as it encodes essential topological location information used for routing. Even when eNIDs are in use, an attacker could perform a coarse-grained correlation attack based on the prefix/L64 bits, or attack their semantics to compromise location privacy. ILNP provides a potential mechanism for weakening such attacks through the rewriting of mutable locator values at various points on the path across the network [54,55]. We have work in progress to implement such a mechanism by adapting FreeBSD’s IPFW firewall. Once ILNP firewall processing has been demonstrated in software, a high-performance hardware implementation is also of interest.