Securing IPv6 Neighbor Discovery Address Resolution with Voucher-Based Addressing

Abstract

The majority of local IPv6 networks continue to remain insecure and vulnerable to neighbor spoofing attacks. The Secure Neighbor Discovery (SEND) standard and its concomitant Cryptographically Generated Addressing (CGA) scheme were accepted by large standard bodies to codify practical mitigations. SEND and CGA have never seen widespread adoption due to their complexities, obscurity, costs, compatibility issues, and continued lack of mature implementations. In light of their poor adoption, research since their standardization has continued to find new perspectives and proffer new ideas. The orthodox solutions for securing Neighbor Discovery have historically struggled to successfully harmonize three core ideals: simplicity, flexibility, and privacy preservation. This research introduces Voucher-Based Addressing, a low-configuration, low-cost, and high-impact alternative to IPv6 address generation methods. It secures the Neighbor Discovery address resolution process while remaining simple, highly adaptable, indistinguishable, and privacy-focused. Applying a unique concoction of cryptographic key derivation functions, link-layer address binding, and neighbor consensus on the parameters of address generation, the resolved address bindings are verifiable without the need for complex techniques that have hindered the adoption of canonical specifications.

1. Introduction

The Neighbor Discovery Protocol (NDP) for Internet Protocol version 6 (IPv6) was first introduced in 1996 by [1], revised in 1998 by [2], and published in its current version in 2007 as [3]. It is a protocol extension of ICMPv6 [4] used by neighboring nodes in a local network to discover each other’s presence, to detect routers, to self-determine addresses, to resolve each other’s link-layer addresses, and to maintain details about the reachability of known, active neighbors. A relevant and focal weakness of NDP is the potential for malicious neighbor spoofing attacks, whereby a malevolent neighbor can insert itself into the path of traffic between two other neighbors by intercepting and falsifying Neighbor Discovery address resolution (NDAR; see Table 1) messages. The category of threat vectors exploited by these spoofing-related traffic redirections is labeled “on-path” attacks (historically: Man-In-The-Middle, or MITM, attacks). On-path attacks are a critical concern for network administrators because confidentiality, integrity, and availability may all be compromised by the interception of traffic at a local scope, where the least amount of network traffic is likely to be encrypted or otherwise secured.

The Secure Neighbor Discovery (SEND; RFC 3971 [5]) and Cryptographically Generated Addresses (CGA; RFC 3972 [6]) specifications were conceived to address the neighbor spoofing problem and other NDP security concerns. The mitigation of on-path attacks with SEND and CGAs has been well established for some time now, but these mitigations have never received widespread adoption in practice. Considering the arcaneness and obscurity of IPv6 outside of academia, networking enthusiast communities, or IETF circles, SEND and CGA descend into an even greater shroud of obscurity that unfortunately keeps them beyond the purview of the mainstream. Furthermore, any existing implementations of SEND and CGA are immature, having little to no backing or validation [7], and each implementation brings wildly varying effects on network performance across different systems [8].

Keeping in mind the mistakes of the past and the paths already paved, a new solution should be proposed for preventing NDP-driven on-path attacks. This solution should do so while remaining viable and efficient for all adopting devices, with a conception that necessitates the balance of three key aspects: privacy, flexibility, and simplicity. This research presents the Voucher-Based Addressing specification (VBA; also Voucher-Based Addresses, VBAs) to satisfy this requirement.

VBA is a low-complexity, high-impact, privacy-conscious, optional proposal that secures local networks from NDP-based on-path threats via an alternative address generation technique. Interface link-layer addresses are bound to sets of deterministic IP addresses in a process which can be repeated by local neighbors to perform address verification. By coupling link-layer identifiers and network-layer identifiers together, the common NDAR procedure for resolving this type of binding can guarantee that only legitimate bindings are used and statefully maintained. All generated addresses appear random to off-link nodes and potential trackers, which ensures node privacy, especially for mobile nodes. Locally distributed vouchers play a key role in controlling, obfuscating, and adjusting the parameters used to create and verify these resultant VBAs.

A key purpose of this research is to produce an alternative to the widely accepted SEND and CGA standards—rather than augment, replace, or survey them—in order to foster new perspectives or to renew interest in solving these longstanding IPv6 security issues. Starting with Section 2, this work provides more background about the problem it attempts to solve and collates some other research which has been carried out to solve relevant NDP issues. A conceptual overview of VBA is given in Section 3. Relevant benchmarks and other experimental, implementation-based results are then described in Section 4. Section 5 includes a subsequent discussion of some of the miscellaneous practicalities of this work. Section 6 then concludes by outlining some potential future research and summarizing the implications of this work.

2. Background and Motivation

Like many early and formative internet protocols, security unfortunately became an afterthought in the design of NDP: presumably sacrificed based on the need for protocol optimizations that matched the performance of the more limited hardware constraints of the era. The widespread adoption of NDP occurred before its threat models were formally cataloged in RFC 3756 [9] and before the specification of Secure Neighbor Discovery in RFC 3971 [5] with its complementary Cryptographically Generated Addresses in RFC 3972 [6]. Arkko et al. in 2002 [10] first detailed the various vulnerabilities of Neighbor Discovery: neighbor spoofing, Router Advertisement spoofing, bogus-prefix denial-of-service attacks, Duplicate Address Detection attacks, and attacks based on falsely advertised configurations. Many of these remain trivial to execute in normative networks as shown by Anbar et al. as recently as 2016 [11], almost a decade after the final revision of the NDP specification. Unfortunately, these problems continue to linger in modern IPv6 deployments.

Among its list of insecurities, NDP harbors a dangerous capability for neighbor spoofing threats creating an opportunity for easy-to-execute on-path attacks. By successfully advertising a spoofed link-layer address binding with a victim IP address, an attacker can redirect frames from neighbors to itself, allowing it to inspect and capture private packet data on the forwarding path before then forwarding it to its original unicast target. This initial spoof and redirection process is sometimes termed “cache poisoning” to express that each misled neighbor falsely caches a binding (i.e., association) between a neighbor IP address and a malicious link-layer address rather than a target’s genuine link-layer address. If an attacker successfully spoofs link-layer address bindings for both target IP addresses in a local exchange, then it can insert itself on-path between the two communicating neighbors and transparently observe passing network traffic. Any upper-layer protocol without encryption then becomes susceptible to this attack, having atrocious privacy and security implications at the local network scope where traffic has the highest chance to be unencrypted and insecure.

2.1. Classic Neighbor Spoofing Attacks

The “classic” neighbor spoofing attack targets two nodes that have established existing and reachable-state cache entries between them. In its simplest form, it overhears an address resolution transaction and follows the completed exchange with an overriding Neighbor Advertisement packet to the target of the attack. RFC 4861 [3] is careful to mention these target nodes receiving unsolicited Neighbor Advertisements: “The Override flag MAY be set to either zero or one. In either case, neighboring nodes will immediately change the state of their Neighbor Cache entries for the target address to STALE, prompting them to verify the path for reachability. If the Override flag is set to one, neighboring nodes will install the new link-layer address in their caches. Otherwise, they will ignore the new link-layer address, choosing instead to probe the cached address”.

Such a mechanism is put in place to allow the target of any Neighbor Discovery proxying to assert its own link-layer address as being reachable on-link directly, rather than letting traffic slowly meander to it through the proxy node(s) indirectly. Due to this tradeoff made by the NDP specification, this advertised override forces the target node to update the link-layer address binding for the victim to the spoofed address. Thus, a single packet has initiated this especially heinous attack.

In step 1 of Figure 1, Node A is the solicitor who asks for the link-layer-to-IP-address (LL2IP; see Table 1) binding from the address fe80::b. Since Node A does not know the target’s link-layer address yet (and thus where to forward frames), a solicited-node multicast address is used instead which utilizes the last 24 bits of the target IP address. Any node can be subscribed to the solicited-node multicast group without authorization. So, then, both Node B (the legitimate target) and Node C (the listening threat actor) from the Figure receive the multicast NS packet. Notice that in step 1, Node A also includes an “SLLAO” (source link-layer address option) with its NS message in order to let receivers know the reverse path on the link layer to find fe80::a (i.e., the MAC address 11-22-33-44-55-aa).

In step 2, Node B receives the NS, pre-caches the link-layer binding from the SLLAO, and responds with its legitimate MAC address in a unicast advertisement packet to Node A at fe80::a. The listening Node C has also received the same NS message details in this step. After some brief delay, it sends a spoofed unicast Override NA in step 3 with its own link-layer address (11-22-33-44-55-cc) as the reported binding for fe80::b. Note that Node C does not need to await this NDAR process in order to send an Override NA if it already knows the link-layer address of Node A.

Node A has now been poisoned: it subsequently updates its Neighbor Cache for fe80::b to the spoofed link-layer address because of the Override flag, for which there is no authentication requirement to use. Packets destined for fe80::b will now be sent to Node C, which can read and interact with the data before forwarding it down the path to Node B, where it will be received without the knowledge that Node C had any interaction with it. If Node C repeats this process oppositely with Node B’s traffic en route to Node A, then a completely transparent and two-way on-path attack is successfully set up. Node C would achieve a complete arbitration of the traffic stream between Nodes A and B.

2.2. Eager Neighbor Spoofing Attacks

A less well-known and much more powerful cache poisoning attack opportunity exists in an optimization related to Neighbor Solicitations. The source link-layer address option (SLLAO) stub can be included with NS messages to indicate the intended link-layer address binding of the IP source address of the NS packet. This is performed so that receiving nodes will not be required to reverse-probe the sender’s IP address for a link-layer address binding during NDAR transactions.

The NDP specification in RFC 4861 [3] reads: “If the [NS] is being sent to a solicited-node multicast address, the sender MUST include its link-layer address (if it has one) as a Source Link-Layer Address option. Otherwise, the sender SHOULD include its link-layer address (if it has one) as a Source Link-Layer Address option. Including the source link-layer address in a multicast [NS] is required to give the target an address to which it can send the [NA]”. This optimization to NDP allows NDAR transactions to occur much faster, but it weakens the protocol due to its blind trust of senders and subsequent automatic caching. Since NS packets are generally the first contact in an NDP transaction, there is no straightforward way to recognize and mitigate this “eager” attack unless the NS occurs for an IP address that already has a binding within a target’s Neighbor Cache.

Figure 2 demonstrates the simplicity and potency of a more eager neighbor spoofing attack: only two steps are necessary for the poisoning to begin from the very start of an apparently legitimate and innocuous NDP transaction. In step 1, the malicious Node C creates a solicited-node multicast Neighbor Solicitation with a spoofed IP source address of fe80::b (Node B’s address). The target address of address resolution is not important, but the attacker will need to aim the NS at the multicast group for which it knows the target node (Node A) is a member while trying to avoid sending the NS to the victim (Node B). By random chance, this will almost always be the case anyway for a 24-bit address suffix used to derive a solicited-node multicast address. When Node A receives the NS packet, it will preemptively cache the link-layer address found in the SLLAO and bind it to the IP source address of the packet; so Node A creates the entry [fe80::b → 11-22-33-44-55-cc].

In step 2, Node A happily advertises itself through a unicast NA message as fe80::a with its legitimate MAC address 11-22-33-44-55-aa as a part of an expected and normal NDAR response. Node C is now free to receive data frames originally intended for Node B, transparently forwarding them, blocking them, or modifying them in-transit. It is also important to note that this attack can be effective in NDP augmentations requiring a Nonce field to be attached to NS/NA packets, because this eager poisoning can dishonestly forge any Nonce value as a virtue of being the NDAR initiator (i.e., solicitor).

2.3. Motivating Attack Commonalities

There exists a glaring commonality between the various NDP attack surfaces that present opportunities for on-path attacks: caching. Regardless of how the cached value is updated or exposed to poisoning, the efficacy of the attack relies solely on making a “bad” update to the target’s Neighbor Cache. Attacks successfully poisoning a target’s Neighbor Cache often then only need to maintain the malicious entries through the normative Neighbor Unreachability Detection (NUD) process. This observation reveals that by merely guarding the cache at the target node, through some form of sender validation or challenge–response authentication, attacks resulting in false updates to (or creations of) Neighbor Cache entries can be mitigated altogether.

2.4. Related Works

Well beyond the conception of SEND, researchers continue to strive for an ideal NDP. Research is conducted year after year into denial-of-service protections, protocol extensions, and, most relevant of all, the prevention of spoofing threats. It is important to measure the effectiveness of these endeavors by evaluating how the goal of spoof prevention is achieved while simultaneously preserving the three ideals of privacy preservation, simplicity, and flexibility. These properties are crucial considerations for the widespread success and adoption of any proposed protocol amendment for a technology as widely deployed as Neighbor Discovery. Since this work measures its own efficacy against these same ideals, using this baseline against other relevant research creates an adequate comparison.

The Source Address Validation Improvement (SAVI) framework specified in [12] is a proven and effective mitigation for various spoofing strategies. It does so by learning and enforcing known bindings between source IP addresses and source link-layer addresses, along with identifying and associating the switchport used to communicate the messages. However, SAVI has been criticized for both its complex, time-consuming implementation in large-scale networks and its high false-positive rate of misreported bindings. If deployed across the infrastructure incorrectly, the method SAVI uses to form its associations can lead to horrendous state synchronization problems. Additionally, the framework is often not compatible with multihomed interfaces having multiple IP addresses across many subnets at the same time. As robust as the SAVI solution is, it cannot be considered to satisfy all three ideals because it is neither simplistic nor flexible.

Praptodiyono et al. introduce the Trust-ND mechanism in [13] as another method specifically designed to abate the neighbor spoofing attack vector by employing a 32-byte NDP Trust Option. This option incorporates a mixture of integrity checking via hashing and a soft-security technique of social trust between independent neighbors. This method was later improved upon by Hasbullah et al. in [14], mitigating weaknesses and granularity issues relating to the Trust Option’s Timestamp value. The most interesting aspect of this work is its independence from any centralized infrastructure, opting instead to rely on what neighbors might already know about each other, direct message authentication details, and the calculation of a trustworthiness score, and then making NDP determinations from that information.

Decentralization and node-independent trust make Trust-ND very flexible for deployment in mixed networks, where some nodes may not recognize or acknowledge the newly introduced Trust Option. It is also simplistic due to both its introduction of only one new NDP option and a software-based mechanism to accumulate and calculate neighbor trust. However, Trust-ND lacks the preservation of privacy, because the trust score and knowledge of the source node’s past activity rely partially on what the receiver (trustor) knows about the sender (trustee), identified by a packet hash and NDP details. This means that for Trust-ND to continually work by calculating high-scoring trust between nodes, both nodes will need to remain at fixed IP addresses and link-layer identifiers, because these are the identifiers used by Trust-ND trustors to identify trustees. If nodes cannot change their addresses freely, then they will be subject to the privacy concerns of tracking and activity correlation.

Finally, NDPsec was introduced by Al-Ani et al. in [15] to augment Secure Neighbor Discovery practices and guarantee improved performance among a litany of other proposed SEND improvements (algorithm changes, new options, etc.). While a significant leap forward for NDP security, this proposal still lacks privacy preservation, flexibility, and simplicity in one way or another thanks to its associations with SEND and CGA. One might imagine that adding things to SEND or CGA would certainly not reduce their complexities. However, NDPsec offers a drastically improved baseline by which SEND and CGA can be evaluated in a more recent context. Other analyses of these proposals and how they affect the efficacy of SEND and CGA—as well as analyses for SEND and CGA themselves—can be found in [16,17,18,19,20].

Related endeavors striving to prevent neighbor spoofing capture an exceptional amount of time, effort, and ingenuity to close what security researchers rightfully understand as a very important gap in local IPv6 network security. Of any existing proposal, one might be a more viable candidate than another depending on the context of the target network being secured. That is precisely why this work does not desire to express that these related proposals are by any means inadequate to solve NDP security issues. Rather, it is left to adopters to determine which is best suited for their own applications.

This research proposes an alternative to securing NDP against neighbor spoofing attacks that relies on the idea of caching being a crucial point of interception. It identifies and applies what should be considered three crucial aspects for the adoption of Neighbor Discovery amendments: simplicity, flexibility, and privacy preservation. Voucher-Based Addressing (VBA) is thus introduced as a possible candidate to mitigate the neighbor spoofing threat in local IPv6 networks. Compared to the given related works which do not satisfy these three ideals, VBA does so by introducing a simple software-level shim during address resolution processes, by having a dynamic operating mode for each interface, and by generating outwardly random addresses for use at any scope.

3. Voucher-Based Addressing

3.1. Terminology

A glossary of terms and acronyms related to Voucher-Based Addressing is necessary to index, organize, and comprehend the many different aspects of its proposal. To acquire more prerequisite context, please see Section 2.1 of the NDP specification in RFC 4861 [3] for the definitions of the following terms: neighbor, node, interface, link, address, router, host, on-link, off-link, IP, ICMP, packet, target, Neighbor Unreachability Detection (NUD), Neighbor Cache (NC), and all well-known NDP ICMP packet types (Redirect, RS, RA, NS, and NA).

Table 1. Related and necessary terminology as a reference for this research.

NDAR	Neighbor Discovery address resolution (see Section 7.2 of RFC 4861 [3]).
LLID	A shorthand representation for the terms “link-layer address” or “link-layer identifier”. Both terms are synonymous and describe any individual link-layer identifier for a network interface. This term is generally used synonymously with MAC addresses in this research.
VBA	Voucher-Based Addressing (the overall concept), or Voucher-Based Address (a single unicast IPv6 address generated according to this research).
LV	Link Voucher. An NDP option consisting of a data payload distributed by a responsible neighbor. Its details are shared by neighbors and used in both generating and verifying VBAs.
VB	Voucher Bearer. A neighbor that is solely responsible for the dissemination of the current Link Voucher.
IEM	Interface Enforcement Mode. An interface-level, mutable operating mode which controls interface VBA generation and verification behaviors.
Binding	Used primarily to describe a coupling between two types of addresses on different layers of the OSI Reference Model [21]. In the case of VBA, it is usually used in reference to link-layer identifiers as bound to network-layer identifiers.
KDF	A cryptographic key derivation function. Defined in Section 3 of RFC 8018 [22].

Table 1. Related and necessary terminology as a reference for this research.

NDAR	Neighbor Discovery address resolution (see Section 7.2 of RFC 4861 [3]).
LLID	A shorthand representation for the terms “link-layer address” or “link-layer identifier”. Both terms are synonymous and describe any individual link-layer identifier for a network interface. This term is generally used synonymously with MAC addresses in this research.
VBA	Voucher-Based Addressing (the overall concept), or Voucher-Based Address (a single unicast IPv6 address generated according to this research).
LV	Link Voucher. An NDP option consisting of a data payload distributed by a responsible neighbor. Its details are shared by neighbors and used in both generating and verifying VBAs.
VB	Voucher Bearer. A neighbor that is solely responsible for the dissemination of the current Link Voucher.
IEM	Interface Enforcement Mode. An interface-level, mutable operating mode which controls interface VBA generation and verification behaviors.
Binding	Used primarily to describe a coupling between two types of addresses on different layers of the OSI Reference Model [21]. In the case of VBA, it is usually used in reference to link-layer identifiers as bound to network-layer identifiers.
KDF	A cryptographic key derivation function. Defined in Section 3 of RFC 8018 [22].

3.2. Threat Model

In the projected threat model for the local network, threat actors are only interested in stealthy on-path attacks resulting from neighbor spoofing exploitation. Modeled threat actors are not concerned with network disruptions or denial-of-service attacks; they would prefer to remain quiet and unseen. For the most part, the success of an on-path attack arbitrating and examining unicast messages is dependent upon the threat actor remaining undiscovered on the path between two victim nodes in the first place. This model assumes that no two Link-Layer Identifiers (LLIDs; see Table 1) within the target broadcast domain can be the same value or be spoofed in the network without obvious disruptions to network activity. It also simultaneously assumes an insecure link layer.

For external networks, the threat model includes risks to the privacy of an interface communicating off-link. Nodes can be remotely tracked, targeted, and even exploited through their unique, global unicast addresses if these addresses are not sufficiently rotated. This can be performed by some global adversary omniscient of all node traffic, or by some target infrastructure repeatedly contacted over some extended duration. Furthermore, if an address generation mechanism incorporates link-layer information and does not obscure it in some way, then attacks can be launched against addresses based on what might be revealed from the link-layer information. Address assignment schemes which do not encourage or permit regular primary address rotations are subjected to these threats and can be a valuable attack vector for targeting victims.

3.3. Design Goals and Overview

MAC spoofing attacks as presented in Section 3.B of [23] are a driving factor of why Voucher-Based Addressing functions in the first place. When two nodes share the same link-layer identifier in a switched network, frames will unreliably be forwarded to one of them based on which node most recently communicated through the switch. A flip-flopping of frame delivery at the link layer causes confusion of higher-level protocols and will most likely result in a denial-of-service attack on the legitimate node owning the MAC, thus disrupting the network. In the threat model from Section 3.2, this is an undesired consequence for stealthy threat actors. With this context, the principle of MAC address uniqueness per broadcast domain can be established.

During the address resolution process, the goal is to associate a target IP address with its underlying link-layer address to which frames can be forwarded and switched. When LLIDs become the determining factors for higher-layer abstractions, such as IP addresses in the case of VBA, then “bindings” are created between the LLIDs and the abstractions. Since VBA generation depends on both these bindings and the principle of MAC address uniqueness at the per-interface scope, VBA verifications are considered valid proofs of MAC address ownership so long as the interface remains present on-link. The verification process is employed at specific times during NDAR transactions, independently mirroring the VBA generation process.

Verifications are parameterized by (1) various inputs which identify the target node during NDAR (the IP and MAC addresses from NDP packets), and (2) inputs which lie beyond the control of the target node. Such external information resides within locally disseminated Link Voucher (LV; see Table 1) details agreed upon by all the neighbors. Due to the utilization of LL2IP bindings in both generating and verifying VBAs, it is impossible to forge an association of an IP address to an LLID that cannot be bound to it. Enforcing binding verification secures the NDAR process against the issues of LL2IP binding impersonation and thus against neighbor spoofing threats.

Creating an IP address which incorporates verbatim the direct value of the LLID would suffice if the goal of bindings in VBA were only to validate address ownership. For example, EUI-64 is a long-established address assignment methodology that employs the direct implantation of an LLID in assigned addresses. This would create an easily verifiable LL2IP binding for each interface, but it would not incorporate a focus on privacy because the LLID of the interface is publicly exposed and the address remains fixed. Additionally, EUI-64 is a one-to-one LL2IP binding, whereas VBA seeks to derive many IP addresses for each LLID.

To meet the need for privacy, simplicity, and flexibility in generating new, obscure IP addresses during the SLAAC (Stateless Address Autoconfiguration; see RFC 4862 [24]) self-addressing process, VBA employs a trivial hashing process. Using techniques based on hash functions ensures that any LLID of an arbitrary length can be reliably bound to an irreversible address suffix that is a desirable and fixed-length. However, simply hashing an LLID will still only manifest a one-to-one binding. Many formalized IPv6 address generation schemes already offer ways to derive many privacy-focused addresses on a single interface (e.g., Section 5 and Appendix A.3 of RFC 7217 [25]). The addresses generated through these schemes are intentionally obfuscated to preserve the privacy of the node unless the reversing parties are aware of all the input parameters used by the deterministic address generation function. VBA solves this one-to-one addressing problem by employing a variant of salted hashing and key derivation functions.

VBA strikes a careful balance of (1) keeping off-link actors unaware of local voucher information, and (2) ensuring on-link nodes are aware of all the parameters used to generate any neighbor’s IP address(es). Off-link parties cannot derive a target’s bound LLID because they cannot receive NDP messages from the target’s broadcast domain, nor can they determine the binding from any patterns within the target’s address itself. VBAs will always appear random as a consequence of utilizing the outputs of deterministic hash functions. Finally, using key derivation techniques as the deterministic hashing functions introduces an adjustable work factor that modifies VBA generation requirements and mitigates brute-force attacks.

3.4. Address Generation and Verification

To gain further advantage, this work elevates simple hashing techniques to the use of key derivation functions (KDFs; see Table 1), enabling a set of one-to-many LL2IP bindings and enforcing a minimum address computation time. KDFs accept input iteration values specifying how many times the driving pseudo-random function (or underlying hash function) must be iterated before producing a final result. In VBA generation, various inputs that specifically identify the target node, as well as the chosen iteration count, are computed by a known KDF into a hash value. The input iteration count is then obscured and planted into the generated VBA adjacent to a slice of the resultant hash such that the following three components are an inherent value exchanged by any NDAR transaction: (1) the target’s reported LLID and IP address (i.e., VBA itself); (2) a portion of the KDF’s hash output (embedded within the VBA); and (3) the iteration count that was supplied when computing the KDF hash (also embedded within the VBA).

Interfaces using the VBA generation procedure during SLAAC, therefore, enforce that all three aforementioned items are bound together and conveyed to neighbors, alongside on-link voucher details, to produce the same output VBA during verification. Each increment or decrement of the iteration count value produces an entirely new, seemingly random address with no correlation to another VBA produced from a different iteration count value. Nodes falsifying any information during the NDAR process will be denied communication with enforcing neighbors who cannot successfully verify the illegitimate bindings.

VBAs are composed of three key components in order from the most-significant to least-significant byte: the 64-bit subnet prefix, a 16-bit Z value indicating the encoded iteration count (L) used to compute the address, and a 48-bit hash-derived address suffix (H). If the subnet is less than 64 bits in length, then the remaining gap between the end of the subnet prefix and the beginning of Z is always populated with pseudo-random noise by the generating node. VBA generation is not compatible with networks whose subnet prefixes exceed 64 bits in length. A VBA contains only a partial conveyance of the information required for neighbors to reconstruct and therefore verify the address binding. Figure 3 provides a simple visual representation of how an IPv6 address is partitioned.

The interface identifier for all the VBAs, also called the suffix, embeds two important details for verification. A 16-bit Z value is calculated as a bitwise complement of the XOR of the 16-bit L value (the iteration count used in the KDF function K) and the first hextet (a 2-byte, 16-bit unit of data) of the current voucher seed value. The Z value is used to ensure that the same input iteration count value, L, will be unique across different voucher seeds to provide enhanced address privacy.

The L value is a significant member of the generated VBA: this parameter controls how many times the KDF function specified in the voucher is iterated to produce the resulting hash value from which H is derived. Increasing this value increases both the work required to verify the VBA and the work necessary to discover potential collisions with H. H is the other value embedded in the VBA which consists of 48 bits acquired from computing the resulting KDF function with L iterations. The first 8 bytes of the resultant KDF hash are used in formulating the suffix of the VBA, where its first hextet (bytes 1 and 2) is replaced with the Z value as shown in Figure 4.

The address generation algorithm depicted in Figure 4 is detailed procedurally as follows:

• A node connects to a network and discovers link VBA compatibility from a Link Voucher option obtained upon router solicitation.
• The local L value is chosen based on (1) node preference, (2) intended VBA difficulty, or (3) random selection. The Link Voucher contains instructions for KDF parameters and algorithm selection as well as the 128-bit seed value to use.
• The KDF salt is created as a variable-length concatenation of a few different inputs in the order specified by the list below. The adjective “raw” dictates specifically binary values, not the hexadecimal string notations of said values.
  • The raw LLID of the network interface on which VBAs are being generated, in network byte order. Since the salt value has a varying length, this is not required to be an IEEE 802 MAC address. It must only represent the LLID to which the VBA(s) are to be bound and which will be provided to verifying nodes during NDAR transactions.
  • The string “vba”.
  • The raw prefix (subnet prefix) value in network byte order. This must match the prefix that will be prepended to the final VBA given during NDAR processes.
• The final address suffix is computed as follows:
  • The first 16 bits are the bitwise complement of an XOR between the node-selected iteration count L and the first hextet of the known voucher seed.
  • The least significant 48 bits are 6 sequential bytes from the computed KDF hash H, skipping its first hextet (two bytes).

When enabled and enforced by a receiving interface’s Interface Enforcement Mode (IEM; see Table 1), the verification process uses the information embedded within the IP address that is provided during an NDAR exchange. VBA verification simply mirrors the generation of the reported VBA locally; Figure 5 illustrates this process. If the reconstructed address of the target node does not match the IP address reported in the NDAR transaction, then the VBA is invalid and communication with the node is denied according to the verifier’s IEM setting. The Link Voucher (”LV” in the Figure) is always retrieved from the state preserved on the verifying interface, and never from an external source that is not the acting Voucher Bearer. If the verification procedure fails due to a voucher mismatch between Nodes A and B, then there is most likely either (1) a synchronization problem, (2) malicious activity, or (3) an issue with multiple vouchers being distributed simultaneously.

During step 1 from the Figure, Node A can choose to attach a source link-layer address option (SLLAO) to its solicitation, which will cause Node B to verify its binding with the IP Sender Address from the NS packet. The Z’ function returns the L value (iteration count) embedded within Node B’s address. This function is the opposite of Z from the address generation process: it uses an input address to determine L rather than using an input L to determine an encoded hextet. Despite the different inputs, the naming alludes to the opposite purposes for each function.

VBA does little to modify Neighbor Discovery, instead opting to change the behavior and decision-making processes of its underlying software implementations. Figure 6 expresses the application of these changes in a practical scenario, where both nodes are required to engage their VBA verification processes between certain NDAR events. In summary, VBA requires modifications to the following NDP behaviors on VBA-enabled interfaces:

• Any new LLIDs on neighbors have an impossibly low chance of organically producing the same VBA as one already cached by verifying neighbors. Such an unlikelihood implies that any Neighbor Advertisement (NA) packets targeting an already-cached IP address which is not in the INCOMPLETE state must be ignored if an included Target Link-Layer Address Option (TLLAO) attempts to update the cache entry state or change its binding to a different LLID. This will prevent threat actors from maliciously triggering costly VBA verification processes where they are not necessary.
• The value of an LLID within a Neighbor Solicitation (NS) packet must likewise never update any existing cache entry for the given IP source address. This is because it is a statistical improbability for any known VBA to have been genuinely formed from a different LLID when the voucher has not changed.
• Any supposed urgent updates about underlying details for a known VBA are unnecessary. The Override flag in received NAs must not be able to freely update the underlying LLID or state of any cache entry. Some devices might wish to support the laxer AGVL IEM which allows compatibility with static unicast addresses on-link. In the case where an IEM is set to AGVL, the Override flag in NAs should not be ignored, in order to let static addresses immediately notify neighbors of a change in their interface LLIDs.

Figure 6. Another comprehensive depiction of VBA verification is given. The steps are equal to Figure 5, except step 5 considers the equivalence check its own process. As shown, VBA processes do not modify the typical Neighbor Discovery process or exchange. Instead, software local to each interface, if equipped, will act to verify the received IP addresses during NDAR transactions based on the interface’s selected Enforcement Mode.

Figure 6. Another comprehensive depiction of VBA verification is given. The steps are equal to Figure 5, except step 5 considers the equivalence check its own process. As shown, VBA processes do not modify the typical Neighbor Discovery process or exchange. Instead, software local to each interface, if equipped, will act to verify the received IP addresses during NDAR transactions based on the interface’s selected Enforcement Mode.

VBA verification is a “shim” software process—a small functionality added as a process between two existing procedures—that prescreens incoming requests to insert or update cached bindings according to the normative Neighbor Discovery process. In Figure 6, Host B calls upon the verification shim of a verifying neighbor, Host A, in step 4. If the shim rejects the binding from entering or updating the Neighbor Cache, then Host A will be denied from properly forwarding data frames to the advertising Host B. This is because a cache entry in the Reachable state does not exist and will not be created. Prefiltering in such a manner immediately eliminates any threat actor’s opportunity to forge NDAR messages or to redirect traffic maliciously.

Employing the verification shim results in repeated KDF computations that could impact performance significantly for systems with minimal resources, so the shim must be optimized and called as seldom as possible. For the sake of optimization, NUD exchanges must not call upon the shim when none of the NDAR parameters (i.e., the IP address or the LLID) are being changed. Incoming NDAR messages failing VBA verification must be immediately ignored, and NC entries must not be created or updated as a result of their receipt. Nodes, likewise, must not respond to any packets failing the verification process.

There are a few situations when address resolution packets cannot be optimized and must explicitly pass through the VBA verification shim for approval:

• An NS, RS, or RA packet is received with an SLLAO attached and an NC entry for the IP source address is not already present.
• An NA or Redirect packet is received for a target address whose NC entry is in the INCOMPLETE state.
• An NA packet is received and the Override flag is set, and the receiving interface is using the AGVL IEM.

The above list is perhaps not all-inclusive and does not consider other extensions to NDP which may allow certain messages to modify or insert cache entries. Except for forward progress indications through NUD, NDAR transactions of any type seeking to update or create any active NC entry must be pipelined through the verification shim first depending on the current IEM.

3.5. Interface Enforcement Modes

Each interface employing VBA must always have the option to set a single local Interface Enforcement Mode (IEM) which determines its handling of NDP messages and VBA. IEMs are a flexibility feature allowing a granular, per-interface setting that adjusts the behaviors of each interface in real-time. They are designed to be changeable at any time and for any reason, no matter the operating state of the interface. The IEMs, in order of increasing strictness, are as follows:

• Address Awareness Disabled (AAD): The interface must disable any generation or verification of addresses during NDAR transactions. It must completely withdraw from any activity related to VBA, with the exception that it can still listen for and capture the current voucher state.
• Address Generation Only (AGO): The VBA generation and process is followed during SLAAC self-assignment, but the interface’s address verification shim must be disabled for all NDAR transactions.
• Address Generation and Verification with Levels (AGVL): VBA generation and verification are performed, but any failure to verify a neighbor must not be strictly enforced. Purported LL2IP bindings which fail to verify are instead tagged in the Neighbor Cache as “Unsecured” entries, and those which do successfully verify are tagged as “Secured”. The Secured responses are always preferred over the Unsecured ones, which permits the legitimate, verified bindings to receive sole connection priority without denying communication to neighbors whose VBAs do not successfully verify (and for which a Secured cache entry does not exist).
• Address Generation and Verification (AGV): Any purported binding which does not verify must be dropped immediately from the Neighbor Cache. Interfaces opting to use this mode will guarantee themselves protection against neighbor spoofing threats because they will only ever be able to transact IPv6 packets with other valid VBAs on the local network. Flexibility with neighbors in mixed networks where some nodes do not have VBA capabilities is consequently revoked.

3.6. Link Voucher Structure and Rules

The Link Voucher is an optional attachment to NDP Router Advertisement and Redirect messages from a responsible Voucher Bearer. Link Vouchers dictate the parameters used by the local network’s neighbors to generate and verify VBAs. By agreeing on these shared, distributed parameters during address generation, all neighbors can independently incorporate the same information to verify each other’s addresses. Establishing a link-local baseline for distributing VBA generation parameters in the voucher enhances node privacy, because off-link nodes will not know all the address inputs.

Figure 7 shows the binary structure of the Link Voucher NDP option and all its descriptive field names. Each field is completed, either statically or by the Voucher Bearer, as follows:

• Type

The unique NDP Option Type identifier for LVs is 63.

• Length

The total length of the LV from the type through its end, inclusive, in units of 8 octets.

• Expiration

A 16-bit big-endian value storing the amount of time in seconds that the LV option should be considered legitimate when an update has not been received from the VB. This value is recommended to be set between 3600 (1 h) and 43,200 (12 h) s. Setting the value any lower or higher results in issues with over-rotations and under-rotations, respectively—two situations which can easily cause denial-of-service attacks when abused.

• Reserved

Reserved for future use. This field is set to zero by senders and ignored by receivers.

• Timestamp

A 64-bit value representing the local system time of the sender at the moment the LV option is constructed.

• VoucherID

A pseudo-random 32-bit value which uniquely identifies a persistent LV instance. This must never change between distributions of the same unique voucher.

• Seed

A 128-bit pseudo-random value used as an input in local VBA generation. This value must be the same for each voucher instance identified by a VoucherID, and it cannot be equal across different VoucherID values.

• Algorithm Type

A Type–Length–Value field specifying exactly which type of key derivation function to use in VBA generation and its corresponding baseline difficulty.

• ECDSA PublicKey and Signature

A variable-length field representing a unique public key value held by the VB issuing the LV option. It is used to sign the LV option and to authenticate any updates to future LV details. The exact mechanism of public key management is beyond the scope of this paper. More specifically, this field describes a Distinguished Encoding Rule (DER) structure containing an ECDSA [26] public key of type “SubjectPublicKeyInfo” according to Section 2 of RFC 5480 [27]. The public key structure is followed immediately by an adjacent DER-encoded ECDSA signature, derived using the private key corresponding to the PublicKey value. The ECDSA signature is computed over a series of sequential octets, constructed in the following order:

• The 16-bit Expiration value.
• The 64-bit Timestamp value.
• The 32-bit VoucherID value.
• The 128-bit Seed value.
• The variable-length contents of the Algorithm Type value, including its type and length values.

The algorithm used in signature computation is “ecdsa-with-SHA256”, as defined in Section 3.2 of RFC 5758 [28]. The signature must be a DER-encoded ASN.1 structure of the type “ECDSA-Sig-Value” (Section 2.2.3 of RFC 3279 [29]). The final expected data structure appears as the two adjacent DER structures depicted in Figure 8.

Neighbors receiving new vouchers will always trust them if they do not already have one stored for the given subnet ID. When neighbors first acquire and store an LV in their local cache or storage, they are required to validate this field and keep track of the current public key value used to sign the last known voucher. Any updates to vouchers henceforth are required to use this same public key, unless the most recent LV had expired—according to its Expiration field—without being refreshed or renewed. This “lock-in” process ensures that only the original VB providing LVs via NDP message attachments is authorized to provide further voucher information and updates. Securing against rogue LVs and unauthorized changes is beyond the scope of this paper and is left to other mechanisms that can prevent rogue Router Advertisement or Redirect messages in the first place.

• Padding

Any extra padding set on the datagram to round its total length to an even 8-octet boundary. This field is always set to zero and is ignored by receivers.

3.7. Algorithm Type Options

There are three default key derivation algorithms that must be included with all the basic implementations of VBA. An Algorithm Type option is a value within LV options that is formatted as a Type–Length–Value (TLV) object, where the type is a numeric identifier uniquely representing a chosen KDF, the length is the width of the total Algorithm Type stub in units of 4 octets, and the value is a compact, binary data format that is zero-padded to the nearest 32-bit (4-octet) boundary. Figure 9 exhibits the structure of Algorithm Type TLV objects as they appear within LV options. Any future versions or extensions of VBA should take advantage of this flexible structure to easily add and formalize new KDF algorithms with their corresponding type identifiers and relevant values.

The list of the three default KDF Algorithm Type choices is given below:

• PBKDF2_SHA256

The Password-Based Key Derivation Function (PBKDF2) is defined in Section 5.2 of RFC 8018 [22]. It is a CPU-bound KDF, the use of which might result in significant computation speed disparities between embedded systems and high-performance hardware. It is included primarily for portability, universality, and its simple implementation.

Type: 1

Length: Always 2

Value:

ITERATIONS_FACTOR

A 16-bit integer representing the multiplier of an input KDF iteration count, specified in big-endian format. This value is required to be greater than zero, and receivers of zero values will simply assume a value of 1 instead. This linear scaling factor can be used by a VB to amplify the baseline cost of computing the PBKDF2 KDF across all neighbors.

Padding

A total of 16 bits (2 octets) of padding initialized to zero and ignored by receivers.

• Argon2d

The Argon2 algorithm is specified in Section 3 of RFC 9106 [30]. It is a memory-bound KDF providing significantly less disparate address computation speeds across varying hardware than CPU-bound algorithms like PBKDF2. VBA explicitly opts to use Argon2d instead of Argon2i or Argon2id because the generation of VBAs does not require any resistance to side-channel attacks. Implementations of VBA should always prefer to employ this Algorithm Type over others when there is no specific reason to opt for another Type, provided all the participating neighbors have Argon2d support.

The iteration count value is used as the t input value for Argon2d computations. The Argon2 t parameter indicates the number of passes and is used to increase the algorithm’s running time regardless of MemorySize. To give the parameters in the Value field more weight, t is reduced from the KDF’s input L value as follows:

t = (L >> 8) + 1

The Argon2 parameters for Secret Value (K) and Associated Data (X) are neither used nor distributed by the LV for any reason, and the Tag Length (T) for Argon2d is set statically to a fixed value of 32. These predefined values assure the Argon2d KDF computation will scale according to a specific projection as the input L value increases.

Type: 10

Length: Always 2

Value:

Parallelism

An 8-bit integer determining how many degrees of parallelism (i.e., lanes) are allowed to run during KDF computation. A value of zero is not acceptable and will instead be defaulted to 1 by receivers.

MemorySize

A 24-bit integer representing the number of kibibytes (KiB) used as space for the KDF computation. This value should be carefully controlled, and if possible, should take into consideration the computing resources across the link on which the voucher will be distributed. This value is required to be a minimum of 8 × Parallelism and cannot be set to zero. Receivers must adjust the minimum MemorySize value accordingly if the value specified does not meet the minimum threshold for the actual degree of Parallelism being used.

• Scrypt

The Scrypt KDF algorithm is specified in Section 6 of RFC 7914 [31]. It is a memory-bound KDF that, like Argon2, provides less disparate address computation durations across varying hardware than CPU-bound KDF techniques. The iteration count L value is used in part for both the N and r inputs for Scrypt computations. The Scrypt N parameter indicates the resource cost of running the computation and is required to be a power of 2. The r Scrypt parameter indicates the desired block size. Actual values are computed through the following conversion:

r (Parallelism) = MAX{ 16, (L & 0xFF00) >> 4 } << SCALING_FACTOR

N (Cost) = MAX{ 2, 1 << (L & 0x00FF) } << SCALING_FACTOR

The Scrypt parameter dkLen (derived key length) is set to a fixed value of 32 and cannot differ between implementations. The parallelization parameter (p) is always set to 1 and must not differ between implementations.

Type: 20

Length: Always 2

Value:

SCALING_FACTOR

An 8-bit integer setting the difficulty scaling of the Scrypt algorithm. This value must only be 0 through 5 inclusive. Receivers must always limit the maximum SCALING_FACTOR to 5, regardless of whether the received value exceeds 5.

Padding

A total of 24 bits (3 octets) of padding initialized to zero and ignored by receivers.

4. Results

A testing laptop was used to generate a set of VBAs for each VBA Algorithm Type option and to evaluate the time taken by each KDF algorithm for each input iteration count. The laptop was used during a fully idle state, running the Windows 11 operating system. It was equipped with a 12th-generation Intel^® Core™ i7 processor, 32 GB of DDR4 RAM, and a GeForce RTX™ 30 Series GPU. The testing hardware is useful to know but is not particularly important, however, because all the results are relative to one another. That is, since all the tests are performed on the same device, their relationships will manifest similarly to how they would across other hardware. With a partial VBA generation implementation written in C, based on the procedure from Section 3.4, an experimental application spawns VBAs on-the-fly based on any set of dynamic or precompiled parameters.

Using the minimal KDF work factors (i.e., iteration count values) for each default algorithm, Figure 10 shows a mostly linear trajectory for the results of each test. As expected, an increase in the input iteration count value is linearly associated with the time taken to compute the resultant VBAs. Deviations in the graph are realistic and spurious events generated by an active CPU on the testing laptop switching between various scheduled tasks through the underlying operating system. Even though the results of the graph are not aggregate statistics, the relationships between the data and their interdependencies demonstrate how VBA might perform in a real-world application. To emphasize a key point: any degree of hardware resources should manifest the same relationships between these three default VBA KDFs per Figure 10.

Argon2 key derivation is highly preferred as the default Algorithm Type for VBA Link Vouchers because its minimal baseline settings produce a memory-bound KDF requiring relatively little time to compute addresses. This grants Voucher Bearers a simple origin when determining the desired level of the baseline computational difficulty for VBA generation on the local network. Both PBKDF2 and Scrypt share a similar baseline relationship with the iteration count used: about every 20–25 thousand additional required iterations result in 5 more milliseconds of computation time during address generation and verification.

These two KDFs intentionally follow a similar progression with minimal difficulties because PBKDF2 is a CPU-bound KDF while Scrypt is a memory-bound KDF. Keeping these two minimal baselines close will allow implementations to choose from a similar baseline difficulty for each type (memory-bound or CPU-bound), and to make further determinations from that pattern. It should be noted that the Scrypt KDF’s linearity slightly tapers into a gentle curve at higher iteration count values. The reason for this fall-off is unclear but it does little to affect any projections of minimal baseline computation times.

Beyond the results in Figure 10, the same hardware was used to evaluate the individual relationships between work factors at an arbitrarily high difficulty for each KDF. The results from Figure 11, Figure 12 and Figure 13 should not be used to compare one algorithm to another, as each algorithm’s “high” difficulty setting was chosen independently from the others. Instead, the results are intended to demonstrate how much computing time a considerably high cost for each algorithm might require during generation and verification processes in relation to individual, node-selected work factor values.

The input iteration count values selected during each VBA generation can widely change the aggregate cost of securing an address on the network, whether advantageous or not. Importantly, selecting the iteration count is in the control of the VBA-generating node. Neighbors who wish to ensure the legitimacy of a received LL2IP binding will be expending the same, symmetric amount of time and energy to verify the binding. This means that a selector’s potentially high work factor choice (i.e., iteration count value) will impart more latency and strain on the initial communications between neighbors and the selector when (and only when) its bindings must be verified. Therefore, the minimum baseline costs for each KDF will result in significantly less work for the network than considerably difficult baseline costs, regardless of the chosen work factors at each node.

5. Discussion

5.1. Precomputing Address Collisions

Malicious Voucher Bearers controlling address generation parameters are not able to further any goals aimed at neighbor spoofing attacks without infeasible time–memory tradeoffs. Control over network-wide KDF parameters and the voucher seed affords the opportunity to minimize the baseline difficulty of computing a hash collision, but only to an extent where the correct collision-producing link-layer identifiers must yet be discovered for neighbors with dynamic addresses.

If the role of the Voucher Bearer is successfully hijacked by a malicious neighbor, then a static seed value with a minimal-cost KDF can be set according to the attacker’s whims. The attacker can pre-compute a set of rainbow tables for all possible link-layer address bindings. However, the selection of an iteration count is determined at each network node and is not controllable by the threat actor. Therefore, indexing a set of predetermined results would require an index containing derivations from all possible link-layer identifiers (48 bits for MAC addresses), multiplied by all possible iteration count values (a 16-bit value) for each generated network address.

$$2^{48}\times 2^{16}=2^{64}=\mathrm{18,446,744,073,709,552,000} \mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}\mathrm{e}\mathrm{s}$$

In the case specific to MAC addresses as link-layer identifiers: if each result stored only the necessary 48 bits extracted from the derived KDF hash value, then storage requirements per hash lookup in the rainbow table would total:

MAC Address (48 bits) + Iterations Count (16 bits) + Hash Result Slice (48 bits) = 112 bits or 14 bytes

For $2^{64}$ rainbow table entries at 14 bytes each, 258,254,417,031,933,722,624 bytes, or about 224 EiB (exbibytes), of storage space would be required. This of course assumes that all possible 48-bit MAC addresses are useable by network nodes, which is not the case but provides a somewhat accurate demonstration. In total, 224 EiB is roughly equivalent to 2 million 128-TiB enterprise-grade storage arrays in sequence: an incomprehensible amount of data. If each hash were to require only 1 microsecond to compute, 8183.589 millennia of computation time would be required to calculate all the possible values, longer than any conceivable amount of time on a human scale.

For more perspective, in an evenly distributed workload, 100,000 nodes would need to operate at full throttle for almost 82 years to generate all the desired information. Finally, this generated index would need to be readily cross-referenceable because finding a collision necessitates using a different input link-layer address than the one used by the legitimate node, according to the established principle of link-layer address uniqueness on-link. All of these preemptive calculations assume that the subnet prefix is also statically precomputed with the typical link-local prefix value of fe80::/64. Any change in the subnet prefix value requires an entirely new set of data at 224 EiB in size.

These attacks are clearly computationally infeasible. In the best interest of future-proofing VBA, and to avoid any absurdities related to these considerations, all deployments using VBA should strongly consider using Router Advertisement Guarding per [32] to assist in preventing these attacks. Guarding against rogue vouchers prevents all hijacking and abates these concerns because the voucher seed will never be a fixed value controlled by an attacker.

5.2. Other Security Considerations

Networks requiring a mix of ephemeral addresses in parallel with static, stable addresses will encounter difficulties with VBA. Preserving the state of a voucher long-term will not be a feasible strategy to maintain stable addresses, since its preservation for any extended period grants more time for threat actors to compute collisions. Assigning static addresses to nodes in a VBA-enabled network can be accomplished using a couple of approaches:

• Use the AGVL IEM on either all the interfaces within the local network, or on the interfaces known to interact with the target static address(es) directly. The AGVL IEM will permit per-implementation behaviors to strongly prefer the Secured results of NDAR exchanges over the Unsecured ones. This option will remove any guarantees of address ownership or on-path attack prevention from the static address(es). This is because a static address failing the VBA verification process will be tagged in the Neighbor Cache as an Unsecured entry, at the same level of preference and security as any other addresses whose bindings fail to verify.
• If neighbors do not interact with the static address(es), then the only affected parties are the node(s) with static assignments and the subnet gateway, which will likely route traffic to and from the static address(es). If this is the case within the subnet, then only host-to-router NDAR transactions will fail verification, so a static entry in the NC of the router should correlate each LLID to each static IP address expected to use the gateway.

An additional concern specific to IPv6 networks is anycast addressing. Anycast addresses are allocated from the unicast address space and are thus indistinguishable from nodes establishing connections to them. NDAR exchanges with these targets may, therefore, respond with varying LLIDs and cause VBA verification to be unreliable. For this reason, it is not recommended to utilize anycast addresses, because the ownership of the address cannot be bound to any particular LLID. The IPv6 Addressing Architecture specification in Section 2.6.1 (RFC 4291 [33]) defines a Required Anycast Address. VBA maintains compatibility with this requirement by disabling address verification for per-prefix subnet anycast addresses. For example, a node using SLAAC to generate an address in the subnet 2001:db8:700::/64 will disable VBA verification for the address 2001:db8:700::.

Another concern regarding the security and stability of the position that the Voucher Bearer takes in the VBA process for each local subnet is providing neighbors with a consensus on VBA generation parameters. If a malicious neighbor successfully races to provide LV options to joining neighbors before the legitimate VB can provide its own, then the neighbors will retain (and be subsequently “locked” to) misleading and mismatched voucher details. The ultimate, clean solution to this is to put an end to the capability of nodes to freely send RA or Redirect NDP messages on the local subnet, which by extension will disable the ability to send unauthorized LV NDP options. This is performed with the help of mechanisms like Router Advertisement Guard (see RFC 6105 [32]) or some other infrastructure-level packet filtering. Despite the complications this introduces in the network’s configuration, it is a low-cost implementation because it does not need to be a shared prerequisite for nodes who are joining the local network.

Lastly, considering the constraints of VBA verification, it is possible for a sending node N_A to have verified the VBA for some neighbor N_B without the reverse being true if N_A does not provide an SLLAO during the initial NDAR exchange. N_A can send packets to an application or service on N_B without requiring any response traffic in return. The nodes receiving unsolicited packets from neighbors, for which no response is required or demanded by the sender, do not need to verify the sender’s address binding. The receiving node may choose to verify the neighbor’s IP address if enforced by a VBA implementation, but it is not required. VBA is specifically designed for the prevention of neighbor spoofing attacks and is not concerned with policing incoming traffic that does not require an NDAR exchange.

5.3. Performance Comparisons

The performance of VBA in real-world scenarios is dependent on each individual node tasked with generating or verifying addresses, similar to existing solutions like SEND and Trust-ND. Each node employing these techniques bears the full expense of every required check on its neighbors’ validities. Since the procedure for any VBA’s verification is equivalent to that of its generation, its computational cost is equally incurred at both ends of each NDAR transaction, warranting a brief comparison of the results in Section 4 to other address generation and verification methodologies.

The address generation mechanism used by VBA intentionally increases its computational requirements through the use of a work factor value, shown in the x-axis for Figure 10, Figure 11, Figure 12 and Figure 13, inclusive. The use of a variable KDF type (CPU-bound or memory-bound) makes it difficult to predict the exact time required to produce each VBA, but the cost-to-work-factor relationships should always express the same linearity on nodes with varying resources. Nonetheless, the data gathered by our experiments in generating VBAs with all three default algorithms demonstrates a high granularity in the selection of a suitable generation time, with reasonable and accommodatable limits well below several seconds. This forms a clear contrast with CGA, whose selected Sec values produce wildly varying address generation times. For example, the experiments by AlSa’deh and Meinel in [34] demonstrate that a Sec value of one might require anywhere from 0.2 to 0.6 s to generate a valid CGA, while incrementing the Sec value to two might require more than an hour.

Neighbor verification performance comparisons between VBA, SEND, and other methodologies are more ambiguous and difficult to determine because each cost depends on aggregate network composition, where any two nodes can have disparate resources. SEND requires an evaluation of a digital signature with every received NDP message from neighbors without utilizing any optimizing state information to increase processing speeds. Likewise, proposals such as Trust-ND must spend time evaluating social scores and decomposing neighbor addresses before completing verifications. VBA finds a significant advantage over other security mechanisms because its stateless verification cost is only incurred once per instance of a unique, slow-changing voucher in an ideal setting. It is a simple algorithm with a “yes” or “no” response to its inputs. This means actual, cumulative verification performance with VBA is always guaranteed to surpass SEND or SEND-like mechanisms in the long term.

5.4. Implementation Feasibility and Transitioning Networks

It is unrealistic to assume that VBA would be deployed simultaneously across all the nodes in a local network because not every active node will receive compatibility at the same time. It is safe to assume—based on the past adoption trends of other specifications—that most devices will never achieve operable VBA support. Therefore, VBA comes predefined with an ability to operate in an intermediate environment where its full support is lacking. The three factors driving these built-in transition mechanisms are (1) Interface Enforcement Mode options for each participating interface, (2) localized changes to NDP occurring mostly in the software logic and not to the protocol itself, and (3) processes that do not require complex interactions between neighbors. The second factor is the primary basis for the feasibility of VBA across independent operating systems and platforms: it is left to per-platform implementations to adopt VBA per their own software requirements and capabilities.

A pure IPv6 local network using the AGV IEM across its nodes will simply not be able to communicate bidirectionally with any node(s) lacking VBA support. For example, bidirectional traffic between a non-VBA node with dynamic addresses and an AGV IEM network gateway will be dropped at the gateway due to its binding verification requirement. In the case of dual-stack local networks, IPv4 traffic can be used as an insecure failsafe protocol when the connecting nodes are explicitly aware of a route in both protocol stacks, such as between a host and a gateway router. The Happy Eyeballs algorithm from RFC 8305 [35] specifies a connection methodology that simultaneously attempts IPv4 and IPv6 connections, preferring IPv6 communication where possible. For local networks using and enforcing the AGV mode, the IPv6 network will appear unavailable and broken to non-VBA node(s). Thus, they might desirably fall back to using available IPv4 connections instead. This strict strategy will permit a degree of insecure communication with non-VBA nodes wherever IPv4 traffic is allowed.

Local IEMs on nodes communicating directly with incompatible neighbors can be adjusted to better accommodate the lack of verifiable bindings. For example, a VBA-enabled node corresponding with a neighbor running an antiquated networking stack might opt to use the AGVL IEM. Doing so would allow the VBA node to strongly prefer Secured devices for the rest of the network, such as the default gateway, while still accepting Unsecured NDAR traffic that does not contain any superseding Secured responses. In the case of a subnet router for a network with mixed VBA support, using the AGVL IEM can again prove very advantageous for the sake of accommodation. Figure 14 shows how these interactions in a mixed network might look. Assuming most nodes can use VBA and a few cannot, only those few nodes will remain at risk of neighbor spoofing attacks. This is the most viable transition strategy for the full adoption of VBA over time.

5.5. Examining the Threat Model

The introduction of VBA satisfies the concerns listed in the original threat model from Section 3. VBA relies on the principle of LLID uniqueness on the same broadcast domain, and thus threat actors cannot subversively spoof another node’s legitimate LLID without introducing obvious network disruptions. Since all the deterministic VBA generations depend upon the node’s supposed LLID given during NDAR transactions, two nodes that cannot share the same LLID will never be successfully verified by neighbors for the same IP address. Whether or not the link layer is secure, VBAs are still necessary to validate bindings between IP and link-layer address components during address resolution.

Likewise, threats from external, off-link actors are mitigated by VBA because generated IP addresses employ the results of hashing algorithms, which generally produce pseudo-random outputs. External actors will not be aware of the voucher details incorporated into final addresses: the stored state required for address generation consists of local-only information, so the threat is abated. Any VBA can also be rotated at a node’s discretion to an entirely new, valid address by changing the work factor value (i.e., iteration count) embedded within the address, even if no other parameters or voucher information have changed. Thus, even an omniscient adversary capable of observing all traffic from a particular VBA-capable host cannot feasibly correlate activities from the same host based on its past IP addresses alone.

5.6. Simplicity, Privacy, and Flexibility

As the original goals of this research stated, the introduction of Voucher-Based Addressing aims to satisfy three core ideals: simplicity, privacy, and flexibility. In this brief section, the work of this research will be fairly evaluated against these ideals to determine its adoption potential. A justification is fairly provided to explain why simplicity, privacy, and flexibility are indeed goals achieved by VBA in practice.

Simplicity is key to drawing audience attention to a protocol or idea; complexity can be understandably intimidating. The solutions of the past which have found themselves too complex or difficult to implement have been buried by the sands of time and relegated to a purgatory of only academic citations and no concrete manifestations. VBA is a simple scheme because it does not require huge, mandatory impacts on NDP that cause disruptions in the network or at the node-to-node level. With a mixture of Interface Enforcement Mode selections, a broadcasted Link Voucher option, and already-present details about a node, addresses can be generated and verified using a procedure that is easy to follow and implement. The address verification shim process is a small snippet of the software that carries the entire weight of VBA. It is modifiable with one simple per-interface setting (the IEM).

Privacy is important to establish properly and consciously in proposals that determine the unicast generation of interface IP addresses, whether local or global in scope. It is also an afterthought of many proposals and research which might be elegant and practical otherwise. It is important to understand that “privacy” in this regard does not beget the confidentiality of data from prying eyes; rather, it affords protection against target identifiability over the course of time. VBA manifests privacy in its ability to generate disposable, deterministic, outwardly pseudo-random addresses while still providing enough information for on-link neighbors to reconstruct and validate them. VBAs have no flags or other magic values which indicate that they are VBAs, further adding to their obscurity.

The VBAs assigned to a local interface stem from a one-to-many pairing of the interface LLID to its assigned output address(es) coupled with a set of node-selected iteration count values. This means a node is free at any time, even if the voucher parameters have not changed, to choose a new interface identifier which shares no correlation to another chosen iteration count, defeating any address tracking or activity correlation concerns between the addresses. Since the iteration count values are selected over the entire 16-bit spaces they may occupy, they become indistinguishable from any otherwise random 16-bit integers and data. Furthermore, the use of a consistent iteration count selection across subnets and networks still results in varying address values between different local voucher seeds based on the XOR operation within the VBA generation algorithm, further obscuring the value.

VBAs originating from the same input parameters with varying iteration counts cannot be used to determine the internal state of the VBA algorithm (and thus the details of the interface’s link-layer address or active voucher). This is because a hashing algorithm generates the majority of each final address suffix. VBAs can be regenerated for each subnet prefix, so location tracking is not possible. Additionally, by the irreversible nature of hashing functions, VBAs will not expose the underlying LLID of the generating interface, thus alleviating device-specific vulnerability exploitation concerns and other privacy concerns from leaked LLID values.

Finally, flexibility is a paramount concern for researchers seeking the adoption of their proposals. Any specification that mandates an immediate, wholesale, strict adherence to itself is bound to fail. Networks are built to be dynamic, independent, and transitory between various protocols and specifications, and any given node may be at its own stage in the deployment of a software tool or specification. Any proposal which ignores a simple transition capability will never be adopted because forced compatibility violates any notion of flexibility. VBA employs IEMs to fulfill this need: the various interface modes allow an operating neighbor to decide which policies to enforce based on local settings or autoconfiguration alone, enabling per-interface choices about which rules to adhere to.

5.7. Summary

There is no tangible velocity towards the adoption of a robust security solution for Neighbor Discovery’s issues. It appears these security weaknesses have long been covered and patched with a cocktail of willful ignorance and idle hands. SEND and CGA have proven over the course of decades to be undesirable and too complicated or esoteric for most practical applications. Network monitoring solutions require consistent involvement and interference by administrators who ultimately “just want it to work” so they can have peace of mind. Other proposals to fix NDP’s weaknesses have either languished in obscurity, are too complex, or fail to focus specifically on their practicalities and acknowledge their own shortcomings.

The real fix to these weaknesses is to create and subsequently adopt effective NDP security solutions which provide a trinity of attributes: simplicity, privacy, and flexibility. A solution lacking one or more of these three properties will not be preserved in the long term without painstaking effort, as time has already proven. Voucher-Based Addressing seeks to establish itself as a proposal touting these attributes and aiming to solve a specific problem rather than ambitiously trying to remediate all the complex issues of the protocol at once.

In summary, VBAs bind input link-layer addresses to sets of privacy-focused, deterministic output addresses that can be reconstructed by verifying neighbors to confirm a reported binding. Address generation and verification are constrained to some initial conditions set by a shared voucher on the local network. The generated addresses appear outwardly random to off-link nodes and are easily rotatable to other seemingly random values, yet on-link they provide all the information required for voucher-aware neighbors to verify them. The neighbor consensus of voucher parameters acts as an enforceable handshake during the address resolution process. This process is not actively falsifiable without introducing obvious network disruptions, thus preventing threat actors from subversively intercepting or modifying traffic between neighbors in on-path attacks.

VBA is a simple, unique, transparent, privacy-conscious, and flexible standard for use in Neighbor Discovery Protocol transactions. The proposal presented in this research maintains a high level of abstraction and does not beget very much concrete and practical evidence of its practicality. There is still, however, a very pressing need for a low-configuration, low-complexity technology to fill the security void left by the absence of SEND and CGA adoption in the modern enterprise.

6. Conclusions

The intent of this research within the wider internet community is not to declare an ultimate solution to the neighbor spoofing issues present in normative NDP, though it may perhaps be a suitable baseline. Rather, it is to draw attention to a longstanding security issue and to spur thought for future research to build upon. Future developments based upon the concepts herein might continue to focus on how they could be refined or better implemented, which vulnerabilities they introduce, any gaps in their theory or practice, and how the cross-application of each technique could be applied otherwise. Researchers are encouraged to continually explore more modern, alternative approaches to securing the NDP address resolution process from neighbor spoofing threats.

To conclude, the broad goal of introducing VBA is to define an alternative to SEND, CGAs, and other monolithic approaches to solving the neighbor spoofing problem. This research aims to pragmatically harmonize three important attributes: privacy, flexibility, and simplicity. It has set out to molt the Neighbor Discovery security paradigm that has continued to depend upon sophisticated Public Key Infrastructure, limiting infrastructure-only protocols, superfluous new data constructs, unwieldy asymmetric cryptography, and centralized address registration authorities. This research has defined a decentralized and empirical approach that mostly avoids the aforementioned tar pits and creates a new perspective. The problem of neighbor spoofing in IPv6 can indeed be solved in a way that is comprehensible, privacy-focused, wholly transparent to end users, and not at all disruptive to incompatible neighbors.