| Internet-Draft | ndp-vba | September 2024 |
| Puhl | Expires 12 March 2025 | [Page] |
Voucher-Based Addressing is an extensible IPv6 address generation and verification methodology for SLAAC-enabled local networks. Individual link-layer identifiers are bound to sets of deterministic output IP addresses. Neighbor Discovery Link Voucher options distributed with Router Advertisement or Redirect messages form a shared consensus between neighbors of the parameters used to auto-generate interface addresses. Cryptographic key derivation functions are used to generate pseudo-random addresses and to intentionally stretch address computation times. Host-selected parameters can be used to derive any number of both stable and ephemeral, privacy-focused addresses for each on-link prefix and at the link-local scope. Neighbors can then verify the link-layer-to-IP bindings during NDP address resolution processes to prevent active neighbor spoofing attacks in local networks.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 12 March 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Neighbor Discovery Protocol (NDP) [RFC4861] is self-aware of its potential for misuse in neighbor spoofing attacks. Section 11 of the RFC provides a brief threat analysis followed by pointers to both SEcure Neigbor Discovery (SEND) [RFC3971], as well as Security Associations with native IPSec (Section 4 of [RFC4301]), as solutions for its weaknesses. Though SEND has been considered the canonical solution for its namesake (securing ND), it and its complementary Cryptographically Generated Addressing (CGA) [RFC3972] have failed to achieve widespread adoption.¶
NDP Address Resolution (NDAR; Section 7.2 of [RFC4861]) establishes a process for discovering the link-layer identifier (LLID) of a neighbor's IP address. This process faithfully relies on an untrusted neighbor owning the target IP to respond with its own LLID (and not, e.g., a malicious neighbor to respond with a redirected LLID). If the target IP address is already being directly correlated with an LLID through the NDAR process, it is then sensible to tightly bind the two identifiers together: IP addresses should be provably derived from their underlying interface LLID. Maintaining awareness of address privacy concerns, this binding needs to be formed in a way where temporary and stable identifiers can coexist with minimal impacts to pre-established privacy conventions.¶
Voucher-Based Addressing (VBA) offers local IPv6 networks (1) a common procedure for binding LLIDs to IP addresses, (2) rotatable and private IP address generation, and (3) prevention of subversive spoofing attacks that lead to network traffic interception. Address bindings use mutual key derivation functions to map public input components to deterministic output IP addresses. These bindings can be subsequently verified through the same procedure by neighboring nodes to assert a target's bindings before proceeding with further communications. The address generation process creates rotatable IP addresses which appear entirely random to off-link actors, who are by design unaware of all input parameters associated with creating the addresses.¶
This document describes a cross-application of cryptographic key-stretching techniques and LLID-IP bindings in generating multiple useful, random IPv6 addresses. The result is a high-impact, low-complexity, gradually adoptable, optional amendment to the NDAR process, with minimal changes to NDP options, formats, or behaviors. It is proposed as an alternative to SEND [RFC3971], CGA [RFC3972], and opaque IIDs [RFC7217], and it does not intend to obsolete or update any other document.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document assumes the reader's basic familiarity with the following specifications. These can be referenced in order to provide plenty of helpful context for the concepts proposed herein.¶
To acquire necessary context, please see Section 2.1 of [RFC4861] for definitions of the following terms used equivalently in this document: neighbor, node, interface, link, address, router, host, on-link, off-link, IP, ICMP, packet, and target.¶
NOTE: Any use of the terms 'IP', 'DHCP', or 'ICMP' in the following sections of this document are synonymous with 'IPv6', 'DHCPv6', and 'ICMPv6', respectively. When referencing the IPv4-based versions of these protocols, it will be explicitly noted.¶
This section outlines the design goals of Voucher-Based Addressing. It reviews the primary mechanisms driving the proposal and discusses related requirements for its adoption. It includes concrete processes and procedures used by VBA-capable network nodes to both verify neighbor bindings and to auto-generate their own VBAs.¶
A Voucher-Based Address is defined as any unicast IP address derived from a hashed combination of known voucher information, a subnet prefix, a work factor selection, and a bound LLID. The actual address derivation process is underpinned by a deterministic procedure parameterized by these values. This same derivation procedure is employed independently by neighbors to verify purported address bindings during NDAR transactions.¶
This section will outline the design goals of VBA aspiring to synergistically balance privacy, flexibility, and simplicity.¶
VBAs are generated by using the LLID of the underlying, assigned interface as a partial input. They operate on the assumption that LLIDs must be unique on the same broadcast domain (link layer) at any given time in order for higher-level protocols to successfully operate. Due to this assumption of temporal uniqueness, nodes actively using and responding from exchanged LLIDs during NDAR are considered 'owners' of said LLIDs. Therefore, it follows that VBAs can be directly formed and authenticated from this 'identity'.¶
Consider the effects of a MAC spoofing attack in an Ethernet LAN, as presented in Section 3.B of [ETHSEC]. Two nodes attempting to use the same LLID on a shared link will cause frames to be unreliably delivered and to flip-flop between two different paths in the network's link-layer switching infrastructure. This only benefits a threat actor if its objective is to deny service to a target, rather than to intercept or change frames. More specifically, the intended threat model for VBA assumes the presence of SILENT, TRANSPARENT spoofing attacks in which malicious neighbors arbitrate and intercept traffic without the knowledge of any parties on the path of communication.¶
During NDAR, the goal is to associate a Target IP with a corresponding LLID to which frames can be forwarded at the link layer (see Section 7.2 of [RFC4861]). Because deterministic VBA generation partially depends on the value of the generating interface's LLID -- and thus the same one which would be reported in an NDAR exchange -- purported NDAR IPs and their bound LLIDs cannot be falsified. Thus, NDAR becomes safe from false reporting of LLIDs for IP addresses that do not produce a legitimate binding, so active neighbor spoofing becomes impossible.¶
VBA verification is a procedure run by neighbors which mirrors the address generation procedure independently. Verification is parameterized by (1) data which identifies the target node during NDAR (IP address and LLID), and (2) data which lies outside of the generating node's administration. Such 'outside' information is found within the Link Voucher details that all VBA-capable neighbors are expected to know when performing verifications.¶
Link-layer bindings using a simple embedding or hashing scheme should suffice if the goals of VBA were only binding verification. For example, modified EUI-64 interface identifiers are formed by a long-established address derivation methodology which uses the LLID of an underlying interface; see Section 2.5.1 of [RFC4291]. These could be used to confirm and fulfill the same purpose. But a design goal of VBA is to also establish a privacy-focused address generation procedure which will obscure the node's LLID while permitting rotatable addresses. EUI-64 is by design a rudimentary address derivation methodology which does not permit such flexibility.¶
For this requirement, VBAs employ more sophisticated hashing during the address generation process to create a pseudo-random output address. A hash-based address does not allow outside trackers to know the LLID of the node. Using hashing and key derivation techniques ensures that any LLID of arbitrary length can be reliably bound to an address suffix that is fixed at 64 bits in length.¶
Furthermore, hashing an LLID and producing an output will only create a one-to-one binding, but many IP address generation schemes already offer ways to derive many privacy-focused addresses from an LLID (e.g., Section 5 and Appendix A.3 of [RFC7217]). These addresses are usually by design NOT reversible, unless reversing parties are aware of all input parameters for the generation function. This is intended to preserve the privacy of the address.¶
VBA strikes a careful balance of (1) keeping off-link nodes unaware of local LV information used in address derivation, and (2) ensuring on-link nodes are indeed aware of all parameters used to generate an address. Off-link actors cannot possibly know the VBA's bound LLID because they cannot receive ND messages, nor can they determine it from the address itself: VBAs will always appear as random as a consequence of using the outputs of deterministic hashing functions.¶
More to the point, VBA elevates use of simple hashing to use of key derivation functions (KDFs), which allow a set of one-to-many LL2IP bindings. This is because KDFs accept work factor values specifying how many times the pseudo-random function or underlying hash function must be iterated [RFC8018] to produce a final result. VBA computes KDFs with various inputs that specifically identify a neighbor's on-link interface, and the result of the KDF is planted into its generated VBA(s). Work factor selections are embedded into resultant IPs adjacent to their KDF outputs, such that the following three components are an inherent value always exchanged by an NDAR transaction:¶
Interfaces using this generation process therefore enforce that all three items are mixed together and conveyed to verifiers -- who must also be aware of current Link Voucher details -- to produce the same output VBA. Each increment or decrement of the embedded work factor value produces an entirely new, seemingly random address with almost no correlation to the previous one.¶
This section outlines different interface-level configurations and options which MUST be available in any implementation of VBA. It also discusses topics specific to caching LV information on local interfaces and outlines some specific details of the process.¶
For more information on Link Vouchers, see Section 4.1.¶
Per-interface modes (IEMs) are able to granularly dictate VBA behaviors. Flexibility in per-interface decision-making grants VBA a higher degree of flexibility with neighbors and adaptability in mixed networks. Implementations MUST allow nodes to independently opt into any one of the following IEMs for each local interface.¶
AAD - Address Awareness DisabledAGO - Address Generation OnlyAGV - Address Generation & VerificationAGVL - Address Generation & Verification with LevelsRegardless of their current IEM settings, VBA-capable interfaces are REQUIRED to store the full state of the most current, validated Link Voucher. If an LV is not available on-link, then no stored LV state is required and the node MUST enter the Address Awareness Disabled state. If an LV subsequently becomes available, then the node MAY choose to enter a different IEM based on the implementation (and whether the AAD IEM is manually set on the interface).¶
LV details MAY also be set statically on an interface. In such cases, the static information MUST contain at least a VoucherID, Voucher Seed, and Algorithm Type specification. Any interface with static details configured MUST ignore any received LVs. Static LVs MUST always be considered active and preferred; therefore, they MUST NOT expire.¶
Interfaces connecting to the link for the first time are REQUIRED to accept and cache the first LV received. If the connecting interface intends to maintain responsibility for the LV as a VB, it MUST follow the process outlined in Section 4.1.1. Available LV options can be discovered by sending a plain RS message according to normative ND processes. Interfaces receiving multiple valid LVs simultaneously SHOULD use the LV with the most recent Timestamp value.¶
An active LV expires when no updated LV with the same 'VoucherID' has been received within the amount of seconds specified in the voucher's 'Expiration' field. When an expiration occurs, the interface MUST again accept the first received LV. The 'Expiration' time can also elapse for an interface while it is disconnected from the link. If such an expiration occurs, then that interface MUST follow the same LV acquisition process.¶
Because LV distribution to interfaces requires automatic Trust On First Use [TOFU], it is essential for more adversarial networks to implement some form of protection against distribution of unauthorized LVs at a lower or intermediate level. See Section 6.2 for more information. In the cases where these protective mechanisms are not available, administrators MAY choose to set LV information on each node statically. Administrators in this sitation SHOULD also choose to employ some form of intrusion detection to better prevent the distribution of unauthorized LVs.¶
The node responsible for the current LV MAY at any time issue a handoff of that responsibility to another node (see Section 5.2.3). During the period of transition between the previous LV and the new one, VBA-capable interfaces which are subscribed to the LOVMA channel SHOULD receive VHA multicast packets specifying the parameters of the new LV. These LOVMA-connected interfaces are strongly RECOMMENDED to allow both LVs to be cached, so that VBAs generated using either LV are immediately valid. These interfaces are also strongly RECOMMENDED to begin VBA generation with the new LV parameters ahead of time, in anticipation of the completed LV transition.¶
==========================================> Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~+
... LV_A Validity |
~~~|~~~~~|~~~~~X~~~~~~~~~~~Z
| | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | LV_B Validity ...
| | +~~~~~|~~~~~|~~~~~|~~~~~|~~~~~~~
|==|=====|=====|=====|=====|=====|=====|===> Time
| O O O O O O O ...
| | |
[ LV_A Active [ Overlap [ LV_B Active
(1) (2) (3)
** 'X' marks the final advertisement for LV_A.
Each 'O' at 'X' until and including 'Z' will
include a VHA from the VB of LV_A.
** 'Z' marks the time at [X + LV_A.Expiration].
** 'O' indicates the advertisement of an LV on-link.
Moments:
1 = Link Voucher A is active for all nodes.
2 = VHA. LOVMA-subscribed nodes become aware
of a transition window. Both LV_A and
LV_B are considered active LVs.
3 = LV_A expires. Link Voucher B is active for
neighbors and the transition completes.
If another VHA appears indicating a third LV as appointed for election, receivers MUST ignore the VHA until one of the two LVs from the original VHA has expired. This prevents abuse which could flag several active LVs on the same link as being valid, causing an 'address generation storm' that drains available resources from neighbors.¶
Once the transition window ends, the amount of valid LVs MUST return from 2 to 1. The transition window ends when the original LV is intentionally not refreshed within its LV-specified Expiration time. This indicates a final transfer of the current LV (and possibly the VB node).¶
For interfaces that DO NOT regard LOVMA VHA datagrams, the 'transition' process is more akin to a 'hard handoff'. Due to LV requirements, these interfaces will not trust the new LV until the previous LV has expired, at which time any LV becomes acceptable. For this reason, any VBAs preemptively generated with the upcoming LV will not be successfully verified by neighbors unaware of the handoff, until the transition window has ended and the new LV becomes primary. Therefore, all implementations SHOULD parse VHAs in order to secure the handoff process, preventing malicious VBs from timing their own voucher injections during the 'hard handoff'.¶
When a handoff completes, the LV for the interface has changed. Any time the stored VoucherID of the active LV transitions to another, the interface's non-static Neighbor Cache entries MUST be cleared and all VBAs, whether generated or verified, MUST be derived from the parameters of the newly active LV ONLY. This is true even in the case of a hard handoff.¶
The handoff and transition window provides an opportunity for optimization. If neighbors are aware of the upcoming LV, then they MAY preemptively generate new interface VBAs in anticipation of the completed transition. Implementations MAY also choose to utilize this transition window for preemptive VBA verification of already-cached neighbors who advertise a Preferred Work Factor specified in LOVMA VSR packets.¶
Finally, if the current node responsible for the LV either disconnects from the network or lets its LV expire without an election process, then the link becomes open and allows neighbors to fill in the LV void with their own. If no other VB assumes responsibility on the link while the primary VB is away or not transmitting updated LVs, then all VBA-enabled interfaces MUST retain the most recent LV for the purposes of VBA generation and verification, until a new LV becomes available.¶
This section discusses VBA composition and the VBA generation procedure.¶
Address composition:
PREFIX // SUFFIX (64 bits)
+------ ~ ------+-------------+---------------------+
| 64-bit prefix | Z (16 bits) | H (48 bits) |
+------ ~ ------+-------------+---------------------+
where:
PREFIX is the 64-bit subnet prefix. If the subnet length is
shorter than 64 bits, the rest of the 64-bit field
MUST be initialized to a pseudo-random value.
SUFFIX is the first 8 bytes from the result of a Key Derivation
Function (KDF) 'K' iterated 'L' times. The leftmost
hextet is replaced by 'Z'.
Formulas:
H = K(L, Key, Salt)
|---> K = A KDF specified by the Link Voucher.
|---> L = A node-selected work factor.
|---> Key = The 128-bit Link Voucher seed value.
`---> Salt = [LLID] || 'v' || 'b' || 'a' || [PREFIX]
Z = ~(L ^ Key[0..1])
SUFFIX = hextets{ Z, H[2..3], H[4..5], H[6..7] }
`--> (using 0-based indexing)
The IID for all VBAs (i.e., the SUFFIX) embeds two important details for verification:¶
A 16-bit 'Z' value, calculated as a bitwise complement of the XOR of the 16-bit 'L' value and the first hextet of the LV seed. This calculation uses this XOR computation to ensure the same work factor 'L' between different LV seeds will be unique and provide some resistance to tracking hosts between each varying LV seed. This is especially true if the node indicates a Preferred Work Factor value (Section 5.2.1).¶
The address generation algorithm is detailed procedurally as follows:¶
The KDF Salt is a variable-length CONCATENATION of a few different values, in the order specified below. 'Raw' values indicate binary values, NOT hexademical string notations of the values.¶
The final address SUFFIX is computed:¶
This section provides an overview of VBA verification.¶
VBA verification MUST only performed during NDAR when enabled by the IEM of the verifying interface. Verifying a VBA entails reproducing the address generation procedure run by the Target Node during SLAAC self-assignment and ensuring the output address is exactly equivalent to the Target Address being solicited by the Client Node.¶
The Target Node address being resolved MAY be any unicast address, but MUST be within the address space of an on-link prefix.¶
The following figure shows how VBA verification integrates into NDAR. Node 'A' is the Client Node and Node 'B' is the Target Node. Each moment of the process is numbered sequentially, leading up to a final determination by Node 'A' as to whether the information given by Node 'B' constitutes a valid binding.¶
,-- [advertise] <---. <======== (unicast NA)
V (2) |
|A|{LV} |B|{LV}{MAC} (verify SLLAO*)
| | | |
+---+-> [solicit] --' <====|=== (solicited-node
| | (1; SLLAO*) | multicast NS)
| | |
| +---------+-------. |
| | | | |
| | +~~~~~~V~~~~~~~|~~~~+~~~~~~~~~~~+
`---+->| H := LV.K( V | [rebuild |
(3) | | L := Z'(B, LV), | addr B] |
`--+-> LV.seed, v----' |
| makeSalt(MAC, prefix(B)) |
| ); |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
|
| +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
`----> | [prefix(B) || suffix(Z(L, LV), H)] == B |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
(4) {????}
| |
DROP <-- false <---' '---> true --> ACCEPT/CACHE
The Link Voucher MUST always be used from the state preserved on the verifying interface. Nodes SHALL NOT request or use the LVs stored by other nodes for any reason. If the verification procedure fails due to an LV mismatch between nodes A and B, then there is most likely either (1) an ongoing voucher transition window or (2) multiple same-link LVs being distributed.¶
During moment (1), the Client Node MAY choose to attach an SLLAO to its NS message, which will cause the Target Node to verify its binding with the IP Sender Address from the NS packet. For more information about the 'when' of VBA verification, see Section 3.5.1.¶
In the above figure, the Z' (Z-prime) function returns the work factor 'L' embedded in Node B's address.
This function is the opposite of Z; it uses an input address to determine L rather than using
an input L to determine an output hextet. Despite the different inputs, the naming alludes to the
opposite purposes for each function. Z' is necessarily computed for each VBA verification because the
L value is a required component to reconstruct the solicited Target Address of the Target Node.¶
Z(L, LV) = ~(L ^ LV.seed[0..1])Z'(B, LV) = ~(B[8..9] ^ LV.seed[0..1])This section describes the requirements and implications of VBAs with regard to ordinary NDP. Simple amendments to NDP are necessary to secure NDAR. Any behavioral NDAR change not explicitly declared in this section falls back to the typical NDAR behavior in Section 7.2 of [RFC4861].¶
If a receiving interface uses either the AAD or the AGO IEM, then this section's behavioral changes MUST NOT apply to that interface or its Neighbor Discovery behaviors.¶
This document requests modifications for the following NDP behaviors on VBA-capable interfaces:¶
Since LLIDs are deterministically bound to IPs and VBA collisions are highly unlikely, new LLIDs on neighbors have an
impossibly low chance of producing the same VBA. This unlikelihood means that any NAs using a cached
Target Address NOT in the INCOMPLETE state MUST be ignored if an included TLLAO attempts to
update the record to a different LLID (or attempts to change the NC entry to a different state).¶
The value of an LLID from an NS should likewise never update for the same generated IP Source Address. So NS packets with an SLLAO attached MUST NOT update the state or values of any active NC entry. This is true only if the current LV has not changed; however, a change of LV already requires a refresh of NC entries.¶
Any "urgent updates" about underlying details for the previous IP are unnecessary. The Override flag in NA messages MUST NOT update the underlying LLID of an active NC entry. It also MUST NOT update the state of any NC entry.¶
However, when the IEM is set to AGVL, the Override bit MUST NOT be ignored. This can let static addresses immediately notify neighbors of a change in their LLIDs. This is not secure and is NOT RECOMMENDED.¶
VBA verification is a 'shim' software process that filters incoming requests to cache bindings between IP addresses and LLIDs. If the verification shim rejects a binding from entering the NC, then the verifying node will be denied from properly forwarding data frames to the requesting node. This revokes a malicious neighbor's ability to forge NDAR packets or to spoof another neighbor with a different LLID.¶
Employing the verification shim results in repeated KDF computations that could be costly for neighbors with fewer resources. Therefore, the shim needs to be optimized and called as seldom as possible. This document specifies that VBA verification MUST only be performed when updating or creating a NC entry through NDAR exchanges. For the sake of optimization, NUD exchanges MUST NOT use the verification shim. Incoming NDAR messages failing verification MUST be ignored and NC entries MUST NOT be created or updated. Neighbors MUST NOT respond to any messages failing verification.¶
There are a few situations when NDP messages MUST pass through the VBA verification shim for approval:¶
This list is perhaps not all-inclusive and does not consider other ND extensions which may allow certain ND packets to modify NC entries. Except for forward progress indications through NUD, NDAR packets of any type seeking to update an active cache entry (whether state or values) or to create a new entry, MUST be pipelined through the VBA verification shim depending on the current receiver's IEM.¶
The NDP specification outlines Reachability Confirmations that regularly update NC values when one of two types of hints indicates connections with already-cached neighbors are making "forward progress" (Section 7.3.1 of [RFC4861]). Forward progress signals that an established connection is still ongoing and that a neighbor is still considered REACHABLE in the NC.¶
Nodes engage in NUD to keep their NC entries in ideal REACHABLE states. VBA capitalizes on this behavior by foregoing address verification requirements when NS/NA transactions only serve to express forward progress. This means that any forward progress showing NO CHANGE in the LLID and IP address of a NC entry MUST allow the record to be refreshed as REACHABLE without requiring VBA verification. Any forward progress indicating that a change has occurred in the LLID for an IP address MUST be ignored and MUST NOT update the cache.¶
Any expiration of a current LV MUST cause the dynamic NC to be immediately cleared. This could occur for any number of reasons, but the expiration indicates that the LV is no longer in active use and therefore any non-static addresses which were previously cached MUST be dropped. Implementations MAY wish as an optimization to categorize or label NC entries by the LV 'VoucherID' used to verify them, so that other NC entries will not be forcibly cleared (such as those from a new LV after a voucher transition completes).¶
When a new LV is accepted and cached, whether by a transition or due to the absence of a current LV, any current NC entries (especially busy or recent ones) MAY have their LLIDs pre-computed into the new resultant VBAs that derive from the new LV's parameters. This can occur even if no NDAR messages have been exchanged with those neighbors yet. This process necessitates that the pre-computing party knows a neighbor's Preferred Work Factor specified on the LOVMA channel. This allows communications with select neighbors to immediately resume without any potential delays incurred by the VBA verification shim. It is left to the discretion of each implementation to apply this optimization where feasible.¶
Static mappings entered into the NC MUST be preserved regardless of LV updates.¶
Gratuitious ND [RFC9131] allows routers to create STALE NC entries from received NAs, in order to expedite the exchange of neighbor LLID bindings. VBAs SHOULD support this option, since routers preemptively verifying a host's address bindings will allow the host to communicate off-link much faster than if the router required a reverse NDAR process for the host.¶
Implementations SHOULD be flexible with Gratuitious ND in how it applies to IEMs requiring VBA verifications. If a flurry of NA packets is received in an ostensible attack, the router might quickly find itself with too much work and could start dropping packets. Implementations MAY therefore toggle enablement of this feature reactively based on the router's evaluated processing load in real-time.¶
When generating a VBA, the node MUST follow the ordinary means of Duplicate Address Detection (DAD) specified by the SLAAC RFC (section 5.4 of [RFC4862]). The DAD procedure SHOULD follow any other applicable DAD optimizations ([RFC4429], [RFC7527], etc.).¶
Upon detecting a duplicate address, VBA-capable interfaces MUST select another work factor 'L' value to generate a different and non-conflicting address. This can become computationally expensive to recompute each new value based on the amount of address collisions, and can be abused in the case of denial of service attacks.¶
To counter this weakness, implementations MUST employ one of two options based on the selected work factor (L):¶
L > 4L <= 4
Implementations SHOULD always prefer the option where the 'L' value is greater than 4, because
L-4 through L-1 produce intermediate KDF hashes that are already necessary in order to calculate the
hash at the final 'L' value. Conversely, any 'L' value at or under 4 will cache the generated KDF hash at 'L' then increment the
input 'L' by one for each DAD collision, up to 4 times.¶
A figure representing this process visually is shown below:¶
COMPUTE & CACHE:
N = Set of K(L', Key, Salt),
where L' :=
if L > 4 : { L-4, L-3, L-2, L-1, L },
else : { L }
(1) +~~~~~~~~~~~~~~+
|A|{B}------------>| Normal SLAAC | (B : Duplicate!)
| v-----------| DAD Process | (B': Success)
| [FAIL] (2) +~~~~~~~~~~~~~~+
| ^
`---> [cached (L-1) |
or new (L+1) | (3)
generates B'] --'
In the figure, (1) shows node A engaged in DAD using the address B generated with L.
After the collision is detected in (2), moment (3) shows the new VBA B' being immediately tried using the
already-cached hash value from the work factor L-1. The DAD process is then successful and there are no
duplicate addresses. The cost of computing L-1 or some other input work factor value has been avoided.¶
To further cement this important optimization procedure, a written example process follows.¶
0xFF04 as its link-local VBA's 'L' value.¶
0xFEFF.¶
0xFF00 (or L-4) iterations will be cached.¶
0xFF01, 0xFF02, & 0xFF03).¶
0xFF04 iterations, and will use the result to generate
a valid link-local VBA.¶
L-1 value of 0xFF03
to create the link-local VBA.¶
If all 5 attempted input work factors result in DAD collisions, then the node MUST give up and use some other implementation-specific course of action to contact an administrator or log a system management error.¶
Note that truly benign DAD collisions are a dangerous prospect for VBA. Address collisions imply that a separate LLID with the SAME 'L' value and LV Seed has generated a KDF hash collision in the used 48-bit segment, exposing the possibility for node impersonation. Some implementations MAY wish to find trusted ways to detect such a collision, possibly by means of intermediate device monitoring (such as switching hardware), and take action(s) based on it.¶
Nodes encountering a duplicate address will by necessity require a different work factor value to generate their current address. If the node advertises a Preferred Work Factor then it is RECOMMENDED that it send a gratuitous VSR update to the LOVMA channel with the new value (Section 5.2.1).¶
Protections to mitigate denial of service attacks based on DAD are beyond the scope of this document. However, the cost of the VBA generation procedure is safeguarded from being abused by DAD mechanisms or their misuses. Since VBAs do not modify the actual DAD process, further work regarding DAD denial of service protections will apply likewise when using VBAs.¶
The NDP option formats specified in this section MUST be supported to enable VBA functionality.¶
The Link Voucher option specifies the VBA generation and verification parameters which neighbors MUST use.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 64-bit Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit VoucherID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | 128-bit Voucher Seed | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > TLV Algorithm Type < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | > DER-encoded < > PublicKey & Signature < | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Padding < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A variable-length field containing a DER-encoded ECDSA [ECDSA] public key of type SubjectPublicKeyInfo
according to Section 2 of [RFC5480].¶
The public key structure is followed immediately by an adjacent DER-encoded ECDSA signature, derived using the Private Key corresponding to PublicKey. The signature is computed over a series of sequential octets, constructed in the following order:¶
The algorithm used in signature computation is ecdsa-with-SHA256, as defined in Section 3.2 of [RFC5758]. The Signature MUST be a DER-encoded [ITU.X690.2002] ASN.1 structure of the type ECDSA-Sig-Value (Section 2.2.3 of [RFC3279]).¶
The final field appears as the following two immediately adjacent DER structures:¶
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
},
subjectPublicKey BIT STRING
}
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Voucher Bearers MUST always respond to Router Soliciation packets with a valid LV option. This is true whether it is using a Redirect or Router Advertisement to distribute its LV.¶
Sending nodes wishing to distribute an LV MUST first check the link for an already-active LV. This entails following a process of router discovery, then only assuming LV responsibility if no LV is already present.¶
FF02::2.¶
Repeat this process 2 more times.¶
Senders of LVs MUST maintain stateful information about their own LV options, so reliable and consistent vouchers can be sent whenever demanded. The rotation of stable LV information -- i.e., the VoucherID, Seed value, or Algorithm details -- MUST be signaled in advance using the LOVMA group (Section 5.2.3), which will initiate a transition window to the new VBA generation parameters.¶
Expiration values MUST be set to an appropriate value. Senders MAY adjust this value without requiring a handoff. Timestamp values MUST always be sent to the precise system time as a big-endian 64-bit value.¶
The Sender's LV option MUST always be unique and MUST NOT be a forwarded or duplicated copy of another LV. Additionally, the voucher's Seed value MUST NOT be preserved between different LV VoucherIDs or handoffs. It MUST always be a random value when first associated to an LV VoucherID.¶
Protecting the network from malicious LV options is crucial to maintain the full consensus of the local network in VBA generation and verification parameters. See Section 6.2 on RA-Guard and Section 9.3 about LV Hijacking for more details. Section 11.3 also discusses considerations for incorporating trust anchors and PKI into LV option signatures.¶
An LV option appearing with any message except Router Advertisements or Redirects MUST be discarded and ignored.¶
Nodes manually set to any IEM on their receiving interfaces MUST still regard and cache LVs according to the rules specified in this document. Nodes with static LV details assigned on their interface(s) MUST ignore and discard any received LVs.¶
Nodes acting as authorized VBs MUST disregard any received LV options on the links for which they are already the active, responsible VB.¶
Receiving nodes MUST statefully maintain and update all LV information per interface, if and only if the received LV is successfully verified according to its cryptographic signature and is not expired. The most recent, valid, and unexpired version of the LV is what MUST always be cached and preferred on the receiving interface. A received LV that does not contain a valid Signature, Timestamp, or Expiration MUST be ignored.¶
Nodes receiving a new LV for the first time are 'locked' to that LV and its public key through an automatic "Trust On First Use" mechanism [TOFU]. Receivers therefore MUST NOT accept LVs which contain any other Public Key details or signatures which do not use the same Public Key. This period of trust in the public key's value remains in effect until the cached LV expires or until another LV is elected in a handoff and a transition begins.¶
Received LVs which contain different VBA generation parameters (VoucherID, Seed, Algorithm details) MUST be ignored and MUST NOT update any cached LV entries, even if the signature field is valid. Likewise, any difference in the public key value MUST cause the LV to be ignored regardless of the LV's contents.¶
LVs with invalid Timestamp values MUST be ignored. Timestamps MUST be considered invalid if the value falls outside
of the range [CURRENT_TIMESTAMP - LV_Expiration] to [CURRENT_TIMESTAMP + LV_Expiration], where CURRENT_TIMESTAMP
is the precise 64-bit system time measured by the Receiver. In cases where the precise system time is measured in sub-second
intervals like microseconds, the unit of 'seconds' in the LV_Expiration time still applies and MUST be converted
properly for accurate arithmetic with CURRENT_TIMESTAMP. This timestamping process ensures LV validity remains flexible
even with minor clock drifting across the local network.¶
Voucher transitions (Section 5.2.3) allow 2 LV options to be considered valid and cached simultaneously. When a Receiver is subscribed to the LOVMA and detects a VHA electing a new LV, it MUST ignore further LV updates either signed by the previous LV's public key value or sharing its VoucherID. This will ensure the previous LV follows through with its commitment to self-expire once the transition began.¶
Section 5 of [RFC8018] specifies the definition of a Key Derivation Function (KDF):¶
A key derivation function produces a derived key from a base key and other parameters. In a password-based key derivation function, the base key is a password, and the other parameters are a salt value and an iteration count...¶
This section will discuss the default algorithms and KDF types that MUST be packaged with basic implementations of VBA. Future versions or extensions of this document MAY add new KDF algorithms corresponding and Type IDs.¶
Any Algorithm Type option not specified in this document or in future versions MUST be ignored by receivers.¶
An Algorithm Type choice is formatted as a Type-Length-Value (TLV) object, where Type is a numeric identifier uniquely representing a chosen KDF, Length is the width of the total Algorithm Type in units of 4 octets, and Value is a compact data format zero-padded to the nearest 32-bit (4-octet) boundary. Receivers MUST always ignore padding and senders MUST always initialize padded areas to zero.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Value < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The list of default KDF Algorithm Type choices is given below.¶
The Password-Based Key Derivation Function (PBKDF2) is defined in Section 5.2 of [RFC8018]. It is a CPU-bound KDF, use of which can result in significant computation speed disparities between systems with variable hardware resources. It is included primarily for portability, universality, and ease of implementation.¶
This specification explicitly uses PBKDF2 with SHA-256 as its PRF in Type 1. Implementations using this Type MUST use SHA-256 as the underlying PBKDF2 pseudo-random function.¶
The Argon2 algorithm is specified in Section 3 of [RFC9106]. It is a Memory-bound cryptographic KDF which will ideally provide less disparate address computation speeds than CPU-bound algorithms like PBKDF2.¶
VBA explicitly uses Argon2d instead of Argon2i or Argon2id because address generation does not require any resistance to side-channel attacks. The in-memory data used by the KDF SHOULD NOT be treated as secret for any reason. All implementations with this Type MUST specifically use Argon2d. Implementations SHOULD always prefer to use this Type over others, provided all participating network devices have Argon2d support.¶
The work factor 'L' value is used as the 't' input 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 LV parameters in the Value field more weight, 't' MUST always be reduced from the input 'L' value as follows:¶
t := (L >> 8) + 1¶
The Argon2 parameters for Secret Value 'K' and Associated Data 'X' MUST NOT be used or distributed by the LV. The Tag Length 'T' for Argon2d MUST be set to 32 and MUST NOT be changed.¶
8 × Parallelism and MUST NOT
be set to 0. Receivers MUST adjust the minimum MemorySize accordingly if the value does not meet the minimum
threshold for the ACTUAL degree of Parallelism being used.¶
The Scrypt KDF algorithm is specified in Section 6 of [RFC7914]. It is a Memory-bound cryptographic function which, similar to Argon2, ideally provides less disparate address computation costs than CPU-bound KDF techniques.¶
The work factor 'L' value is used in parts of the 'N', 'r', and 'p' inputs for Scrypt computations. The Scrypt 'N' parameter indicates the CPU/Memory cost of running the computation. This value MUST be a power of 2. The 'r' Scrypt parameter indicates the desired block size (RAM cost). The 'p' parameter indicates the desired degree of parallelization. Actual values are computed by the following conversion:¶
N (Cost) := MAX(1 << (MIN(11, MAX(1, ((L & 0xFF00) >> 8) / 24))), 2) << SCALING_FACTOR
p (Parallelization) := MAX( 1, (L & 0x00F0) )
r (BlockSize) := MAX{ 1, (L & 0x000F) )
¶
The Scrypt parameter 'dkLen' (derived key length) MUST always be set to 32 and MUST NOT differ between implementations.¶
The LOVMA group is defined for the express purpose of sharing non-essential, independent VBA details between neighbors. All VBA-capable neighbors are strongly RECOMMENDED to join this group, regardless of their IEM settings. Nodes are not required nor expected to make practical use of any LOVMA traffic. However, current link VBs are always REQUIRED to join the LOVMA channel.¶
This multicast group is located at the IP address FF02::ABBA. A helpful mnemonic to remember this address is to
think of ABBA as the closest possible hexademical rendition of "a VBA".¶
The designated UDP port on which all LOVMA data is sent and received is 2196.¶
When utilizing the LOVMA channel for any purpose, implementations MUST regard these constraints:¶
All LOVMA datagrams MUST use a Type-Length-Value (TLV) format. Type is an 8-bit integer identifying the datagram type, Length is an 8-bit integer specifying the length of the packet (including the Type and Length fields) in units of 4 octets, and Value is the data to be handled.¶
The Type and Length fields MUST NOT be set to 0. Receivers MUST ignore datagrams with a Type of 0 or a Length of 0.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | > ... < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A node MAY occasionally send VSRs to the LOVMA channel to gratuitously let other nodes know of its presence as a VBA-capable interface, in addition to a few VBA-related status fields.¶
Senders are REQUIRED to add their interface LLIDs onto transmitted VSR packets. This allows receivers to easily identify the sending interface by ID, rather than the IP Source Address of the datagram, to associate the sender with one of its potentially many on-link IP addresses.¶
Senders MUST adhere to the rules defined in the below figure. Receivers are not required to parse any of the fields. Receivers MAY confirm the IP Source Address and LLID by running the VBA verification procedure to check the binding, but it is not necessary and therefore NOT RECOMMENDED due to its potential costs.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IEM | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit VoucherID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pref. Work Factor | LLID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > LLID < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Padding < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A 3-bit value identifying the IEM of the sending interface according to the table below. This value MUST be set to the AAD IEM if the sending interface does not have a currently cached, active LV.¶
| Value | IEM |
|---|---|
| 0 | AAD |
| 1 | AGO |
| 2 | AGV |
| 3 | AGVL |
| 4 | Reserved |
| 5 | Reserved |
| 6 | Reserved |
| 7 | Reserved |
A node MAY notify the LOVMA channel about its potential candidacy as a Voucher Bearer by sending a VCI datagram. The VCI is an informational datagram REQUIRED to be sent for consideration of election by the current VB.¶
Receivers are typically intended to be the current VB, but any neighbor MAY make use of VCI details. Neighbors MUST NOT consider VCI packets as valid LVs. The current VB MAY maintain a state of unexpired VCI packets, especially when it intends to elect a new node responsible for the LV. Current VBs SHOULD NOT elect a new VB without first receiving a VCI datagram indicating the Sender's readiness to be elected.¶
Sending nodes MUST NOT assume that issuance of a VCI packet is guaranteed to lead to eventual election as a VB. The decision for election by the current VB MUST be indicated by receipt of a signed VHA datagram, whose signature's PublicKey matches that of the current, active LV of the VB.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Link Voucher Contents < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The node responsible for the LV MAY at any time elect a new VB using the VHA datagram. This handoff communication notifies subscribing VBA-capable nodes of a change in VB and thus the PublicKey information used to sign the new LV. If the signature on the VHA is valid, listening nodes MUST accept the start of the handoff process whereby both VoucherID fields become temporarily valid for the link.¶
If the Signature field is not verifiable using the current LV's PublicKey, then receivers MUST ignore the packet. If there is no current LV and a VHA is received, then it MUST be ignored.¶
The transition window duration is based on the 'Expiration' value of the current VB's LV at the time the VHA is sent. Exceedingly long Expirations will entail exceedingly long transition windows, and there is no limit to its duration. VHA retransmission frequency is variable but is RECOMMENDED to follow the same frequency as the node's previous RA or Redirect issuances. VBs initiating a handoff MUST send at least one VHA notification every 5 seconds for a minimum of 3 minutes. If the 'Expiration' value is high, nodes handing off VB responsibility MAY choose to stop transmitting VHAs after this minimum threshold has elapsed.¶
Candidate nodes considered for VB election MUST be gathered from either (1) manually configured details or (2) senders of recent, unexpired VCI notifications on the LOVMA channel.¶
When the elected node observes the VHA packet granting it VB responsibility, it MUST begin sending gratuitous RAs or Redirects to the link for which it is now a VB. Sending an RA to the link always follows the receipt of a valid, unexpired VHA from the previous VB. After 2 minutes, the new VB MUST consider the LV parameters (including the PublicKey) of the previous VB as invalid, and MUST NOT trigger any more RAs driven by receipt of VHAs from the previous VB.¶
VHAs MUST also be used to indicate a change in active LV details using the 'Refresh' bit. This indicates that the handoff represents a transition between LV parameters from the same VB rather than a change of issuing VB nodes. Using the VHA for this purpose affords neighbors enough time to fully transition addresses between varying LV parameters, just like in an ordinary election.¶
See Section 3.2.4 for more details regarding the handoff process at the per-interface scope.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 64-bit Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Signer VoucherID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Upcoming VoucherID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > < > DER-encoded Signature < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Padding < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The current precise system time encoded as a 64-bit value.¶
Timestamps MUST be considered invalid if the value falls outside the range [CURRENT_TIMESTAMP - 120] to
[CURRENT_TIMESTAMP + 120], where CURRENT_TIMESTAMP is the precise 64-bit system time measured by the
receiving node and 120 is in units of seconds. If the CURRENT_TIMESTAMP is measured in sub-second units
like microseconds, then the 120 value MUST be converted to an appropriate value. This requirement ensures timestamp
validity remains flexible even with minor clock drifting across the local network.¶
A variable-length field containing a DER-encoded ECDSA [ECDSA] signature (and thus PublicKey), derived using the Private Key corresponding to the sender's Signer VoucherID. The signature is computed over a series of sequential octets, constructed in the following order:¶
The algorithm used in signature computation is ecdsa-with-SHA256, as defined in Section 3.2 of [RFC5758]. This field MUST be a DER-encoded [ITU.X690.2002] ASN.1 structure of the type ECDSA-Sig-Value (Section 2.2.3 of [RFC3279]).¶
The implied PublicKey value MUST be equal to the PublicKey of the active LV on the receiving interface. If it differs, then the VHA MUST be ignored.¶
A Voucher Bearer (VB) is a neighbor responsible for the current, active, majority-accepted Link Voucher option. This section introduces VB constraints, recommendations, or other requirements for implementations and deployments.¶
Any willing neighbor MAY be elected to serve as the VB, whether by manual configuration or by a process of election and appointment from the current VB (see Section 5.2.2). Current VBs wishing to transfer LV ownership to another responsible candidate MUST use the LOVMA channel and issue handoffs per the election process (see Section 5.2.3). Neighbors MUST NOT be granted VB responsibilities without first announcing their candidacy through valid an LOVMA VCI message.¶
If the current VB is not a router nor responsible for routing subnet traffic, then it MUST distribute the LV via an ND Redirect packet with an LV option instead of using an RA packet with the LV option. The Redirect message MUST otherwise conform to the constraints of normative NDP Redirects (Section 8 of [RFC4861]).¶
VBs MAY at any time let their own LVs expire if they do not wish to elect another VB, or if there are no other candidates available on the LOVMA channel. VBs SHOULD NOT let their own LVs expire without first appointing a responsible successor. If there is no successor, then the most recent LV MUST remain current for the link until another neighbor assumes VB responsibilities.¶
Fake or malicious LVs can be problematic for neighbors that do not yet have an LV stored for. Illegitimate VBs represent a threat more thoroughly explored in Section 9.3. Bogus RAs/Redirects are a known problem in local IPv6 networks with no active protections, causing potential failures of neighbors. An excerpt from the RA-Guard RFC is noted:¶
[RFC6105] describes a solution framework for the rogue-RA problem [RFC6104] where network segments are designed around a single L2-switching device or a set of L2-switching devices capable of identifying invalid RAs and blocking them. The solutions developed within this framework can span the spectrum from basic (where the port of the L2 device is statically instructed to forward or not to forward RAs received from the connected device) to advanced (where a criterion is used by the L2 device to dynamically validate or invalidate a received RA, this criterion can even be based on SEND mechanisms).¶
The RA-Guard system SHOULD be augmented and deployed with VBA awareness, capable of tracking the state of LVs and LOVMA channel elections. This will allow an intermediate network device or set thereof, such as a switch, to only require RA-Guard Learning Mode for a short initial period. It can then subsequently "follow" the authorized LV around the link.¶
The difference with RA-Guard in this scenario is to restrict the forwarding of frames containing encapsulated RA/Redirect packets when and where appropriate based on what the system understands about the state of vouchers on the network. One notable exception to this, however, is that an RA-Guard implementation MAY drop its protections if and only if the most recent and legitimate LV has expired without a successor. This is because some responsible VB needs to be free to supersede a "dead" or expired LV.¶
In the case where the elected VB is not a link router nor responsible for routing traffic and ND Redirect messages are being sent with attached LV options, a Redirect-aware flavor of RA-Guard is strongly RECOMMENDED to also include these in its learning processes.¶
Use of RA-Guard is primarily suggested for networks with a "revolving door" of neighbors, public networks, or networks which otherwise need to fortify and guarantee their security posture. Appointments or elections of new VBs should be considered with caution because the lack of PKI permits false claims of initial identity. The exact deployment of RA-Guard is beyond the scope of this document, but it is strongly RECOMMENDED.¶
This section briefly summarizes and references the various optimizations built into VBA by default.¶
Avoiding Repeat VerificationsDuplicate Address DetectionThe LOVMA Channel & PreemptionKey Derviation Function SelectionsThis document proposes various optimizations to ensure the performance of VBA is commensurate with its simplicity. However, the cost of binding verification may be significant depending on an LV's imposed Algorithm Type option as compared to the relative computing power of the verifying node. Such a process could create a situation where VBAs cannot be verified fast enough.¶
As such, optimizations become inversely proportional to security. Preemptive caching of neighbor bindings results in fewer lost packets and much less ND-driven delays when enabled, but it also allows malicious attackers to spoof thousands of false advertisements per second, inundating neighbors with backlogs of LL2IP bindings to verify (assuming the IEMs on the receiving interfaces mandate verification).¶
It is left to both (1) other works and (2) per-implementation details to balance these issues. While this document attempts to find a happy medium, it can only make generic suggestions due to its umbrella of effect.¶
It is unrealistic to assume that VBAs could be deployed simultaneously across all nodes in even relatively tiny local networks. There will undoubtedly be network devices present which have no support for VBA. While that is especially true at the time of drafting this document, it is certain that some hardware vendors and software developers will never implement VBA or provide necessary operable support. Therefore, VBA must come pre-packaged with an exploration of its ability to work in a transitionary environment where its full support is lacking.¶
Local IEMs can be adjusted on nodes communicating directly with unsupporting nodes to better accommodate their lack of verifiable bindings. For example, a VBA-capable node corresponding with its noncompliant neighbor might opt to use the AGVL IEM. This would allow it to strongly prefer Secured cache entries for the rest of the network (such as the default gateway) while still caching and marking Unsecured any NDAR responses that do not successfully verify.¶
In the case of a subnet router in a mixed network -- that is, a local network consisting of VBA-capable and incapable neighbors -- using the AGVL IEM can again prove very advantageous for the sake of accommodation. Assuming most nodes communicate with valid VBAs and a few cannot, only those few nodes are at risk of neighbor spoofing attacks.¶
This section includes discussions related to the security of VBA. It also serves to clarify certain processes or tangential topics which may not have had adequate exploration in the rest of this document.¶
VBA generation only preserves 48 bits from a resultant hash. While a collision is unlikely, nodes treat this as they do the DAD process: even if it is unlikely, it is possible and must be handled appropriately. Potential hash collisions expose a weakness of VBA because LL2IP binding is done through a deterministic hashing process and nothing else. In other words, there is no other mechanism used for certifying neighbor addresses. Thus, any other spoofable LLID producing the same 48-bit 'H' portion of the VBA suffix will result in an equally valid VBA according to the verification procedure.¶
The employment of cryptographic KDFs drastically reduces the capacity for attackers to discover address collisions and use them for spoofing purposes. This brute-force resistance is a consequence of each KDF intentionally requiring more time than traditional hashing to compute. Section 3 of [RFC8018] defines a KDF in the exact manner this specification intends to apply it:¶
Another approach to password-based cryptography is to construct key derivation techniques that are relatively expensive, thereby increasing the cost of exhaustive search. One way to do this is to include an iteration count in the key derivation technique, indicating how many times to iterate some underlying function by which keys are derived.¶
Thus, KDFs are applied to VBA for the added purpose of slowing collision discoveries. This same tradeoff of requiring slightly more time for address computation in order to protect against brute-force enumeration is a strategy also recommended for use in password storage systems to protect user secrets (see [SP.800-132]).¶
To prevent any possible time-memory tradeoff attacks, the LV is distributed between nodes to ensure that input parameters generating VBAs are always generously salted by a 128-bit pseudo-random value, as well as the subnet prefix, so they can never be pared down to a simple dictionary attack. This same value from the LV is also intended to rotate occasionally in order to prevent long-term attacks.¶
An attacker searching for inputs producing a colliding address is therefore subjected to the misery of enumerating many different link-layer addresses in order to generate an IP address that matches the target's 48-bit hash suffix. This spoofed IP address must also embed the same work factor as its target because it needs to be an equivalent IP. If the target IP address contains a high work factor value, then this searching process will be even slower and more unlikely to succeed. All the while, these collision-producing inputs must be obtained before the rotation of the LV Seed, which will reset the hypothetical attacker's marathon entirely.¶
LVs also specify the use of shared KDF algorithms and difficulties on the link. This permits a dynamic adjustment of the base computation time required to derive or verify all link VBAs. For example, adjusting computation time to be an approximate minimum of 20 milliseconds per address for the least powerful node, and an estimated 1 millisecond for the fastest, produces a negligible delay in processing legitimate ND messages. Simultaneously, this hypothetical time taken to compute each VBA hamstrings any node, regardless of computing power, from being able to search collisions expeditiously. This guarantees responsiveness while also protecting addresses.¶
Continuing the above example, 1-millisecond VBA generation times for the most powerful link nodes still equates to attempting only 1,000 spoofed LLIDs per second (3,600,000 LLIDs per hour). If the LLID in this case were an IEEE 802 MAC address, 3.6M attempted MAC addresses is equivalent to only about a millionth of a percent of all possible addresses (248 when not accounting for reserved MAC address ranges).¶
In an ideal network, VBA deployments would be unnecessary for the purpose of securing address ownership. One sample trust model which may disregard VBA verifications is a small enterprise network for which all LL2IP bindings are entered statically. Another might be a private home network, where on-path attackers are very unlikely to be lurking.¶
The implications of VBA against adversaries should be explored from a broad perspective. Notably, this exploration assumes a hypothetical VBA deployment that is using the AGV IEM to enact full, strict protections on all address bindings. With the context of the design goals of this document, of various ND problem statements (Section 4 of [RFC3756]), and of IPv6 address privacy concerns ([RFC8064] and [RFC7721]): consider how VBA either proposes a resolution for a potential issue or encounters a drawback.¶
Sending Neighbor Advertisements or Solicitations with false link-layer addresses.¶
The sender of a NS can use a false SLLAO, while the sender of a NA can use a false TLLAO. Since NDAR specifies optimizations or instructions to enter these into the Neighbor Cache on receipt (without verification), the protocol becomes vulnerable to abuse.¶
VBA is a way to force this purported binding in NA/NS packets to be verified. This specification dictates that any cache-affecting ND instruction, or optimization to automatically accept link-layer address options, be shimmed with the VBA verification process first. NDAR messages which fail VBA verification are subsequently dropped and do not update the NC, mitigating the issue.¶
Asserting a false link-layer address in Neighbor Unreachability Detection packets.¶
Malicious nodes can extend impersonation attacks against the target node by responding to NUD probes, in order to indicate continued reachability. Again, with VBA this attack is not possible because of the imposed verification requirement. If NUD probes detect any changes in cached LL2IP bindings -- e.g., a malicious node responds with an LLID that is different from an original cache entry -- the attack target will drop the packet and will neither update nor refresh its NC with the unverified information.¶
Correlating unicast address activities in the long-term across networks.¶
[RFC7721] discusses four primary issues of deriving IP addresses from LLIDs: network activity correlation, location tracking, address scanning, and device-specific vulnerability exploitation. The applicability of this discussion, however, only applies to addresses from which any off-link actor might derive the LLID directly or somehow become aware of it. VBAs are created using an irreversible hashing function mixed with details available only on-link; therefore, LLIDs are not recoverable by off-link nodes.¶
Stable VBAs do not truly exist unless the active LV is also stable. In such a case, addresses being spawned by the VBA generation process are still pseudo-random in appearance. Nodes employing these addresses also have the option to select a new work factor at any time despite any stable LV details, rotating the used address for a fresh one that is still valid and verifiable.¶
Nodes who are 'killed' or go offline are impersonated.¶
When a node goes off-link, there is no consequence for a malicious node spoofing its LLID. Since the VBA threat model assumes an insecure link-layer, this remains a persistent problem. VBA is designed primarily to prevent active, transparent spoofing; that is, the quiet arbitration of data between two active neighbors without intercepting or disrupting messages between either party. VBA does not employ PKI to certify LL2IP bindings; rather, it hinges on the principle that two link-layer interfaces on a shared link cannot share the same identifier at the same time without causing noticeable network disruptions.¶
Hijacking the role of link VB can be achieved by a few different means, based on the level of security employed in the local network. Without RA-Guard, false VBs are free to constantly advertise and inject their own rogue LVs onto the network. For neighbors on the network already having an active LV, this is only a problem if VHAs in the LOVMA are not being used and the current LV expires. For neighbors joining the network for the first time, there is a timing opportunity for an abuse of automatic Trust On First Use [TOFU].¶
If a legitimate VB goes offline and is not able to transmit any updated LVs to the network, then its current LV can expire. When an LV expires, the design of VBA requires nodes to accept any incoming LV as providing direction and consensus for addressing. If a malicious neighbor uses denial-of-service methodologies to force a current VB offline for long enough, then it can force an expiration of the current LV and gain control of it.¶
Relatively short 'Expiration' windows for LVs are disallowed in LVs because of (1) possible time synchronization issues between nodes, (2) 'address generation storm' prevention, and (3) compensating for possibly slow VBs who cannot deliver LVs to the link fast enough. Most relevant to this section are items 2 and 3. The 'address generation storm' prevention relying on this mechanism stops malicious VBs from over-rotating the current LV and exhausting resources of neighbors who will be very busy trying to keep up with VBA generations. Compensating for a slow VB with long 'Expiration' windows requires malicious nodes to force that same legitimate VB off the link for longer in order to take their place.¶
Hijacking, tampering with, or otherwise desynchronizing the LV can be used for either malicious denial-of-service attacks or to set the difficulty of VBA computation to a very low threshold.¶
All of the concerns in this section allude to the importance of guarding the local link from malicious LV options in the first place. Though spoofing attacks are still LESS feasible with VBA enabled, regardless of LV control, that still does not outweigh the risks assessed above. Section 6.2 has more information about RA-Guard and protecting against concerns of rogue LVs.¶
VBA primarily counters spoofing attacks in local networks. Mitigation of NDP denial-of-service attacks is only an auxiliary goal that could be achieved by integrating other protocols or designs. Placing the burden of resolving these problems onto this document could reduce its flexibility and applicability by forcing it to apply specific mitigation strategies rather than leaving them as optional add-ons.¶
This section discusses concerns about potential denial-of-service threats when employing VBA. When a topic is presented without a solution, it is STRONGLY IMPLIED that an implementation of this document SHOULD find and use another solution to mitigate the problem, or at least maintain an awareness of the weakness(es) during development.¶
Section 4.3.2 of [RFC3756] outlines an attack targeting last-hop routers that inundates a network with traffic destined to on-link hosts which do not exist. VBAs do not suffer from this attack vector or from any situation involving creation of repeated NS packets, as there is no extra cost incurred in creating them.¶
When a VBA-capable node is receiving a flood of NS packets instead of sending them -- particularly if the NS messages contain spoofed SLLAOs -- then the node may be forced to compute a large volume of verifications in a short interval. This could easily lead to resource exhaustion if the receiving interface's actively stoed LV specifies a more difficult set of KDF settings.¶
A malicious neighbor may also initiate a series of connections from bogus IP addresses that demand return traffic at higher layers of the network stack, such as TCP SYN floods. This would necessitate that the target of the attack engages in NDAR to determine the LLIDs of the supposed initiating IPs if the LLIDs were not provided in NS SLLAOs. If the bogus initiating IPs use high work factors, then the influx of queued work for the verification process could quickly overwhelm the target.¶
NA floods, either with (1) randomized target addresses and TLLAOs or (2) randomized TLLAOs for a known target address, will not affect VBA-capable neighbors. VBA-mandated NC behavior for NAs does not by default permit the presence of an Override flag to affect a cache entry, nor do NAs affect cache entries which have matured beyond the INCOMPLETE state. A more effective attack vector is listed in the previous section. Falsified incoming connections could bait a target node into sending a litany of NS packets, each of which an attacker could reply to with a bogus, high-difficulty VBA to verify.¶
Large local networks might have thousands of devices on the same logical link using NDP to resolve each others' bindings. When a network is of this size and the active LV is transitioned to another through the election process, optimizations for low-resource neighbors could get excessively costly. Pre-generation of anticipated VBAs according to the new LV parameters would be the primary culprit. To reduce this burden, implementations MAY choose to either limit their optimizations at a certain cache size or pre-generate VBAs only for the most recently contacted, high-throughput neighbors.¶
The selection of an appropriate KDF is essential to scale the difficulty of discovering hash collisions. The choice of KDF is also essential for fairness in computing generated interface addresses. A network having widely varying computing resources across nodes will record disparate address generation and verification times when using CPU-bound KDFs instead of choosing Memory-bound KDFs for address calculations [MEMBOUND].¶
Even when using memory-bound KDFs like Argon2d, the proper delegation of baseline algorithm parameters in the LV SHOULD always tend toward being more forgiving for neighbors with limited resources. The balance of low compute latencies with high security might be difficult to determine. Implementations MAY attempt to discover and apply defaults that achieve this goal as universally as possible.¶
Networks requiring a mix of ephemeral addresses alongside static, stable, long-term addresses might encounter difficulties deploying and maintaining VBA. Preserving the state of a local LV long-term will not be feasible to maintain stable addresses, since long-term LVs introduce a vulnerability to malicious address collision discoveries.¶
Assigning long-term addresses to neighbors on a VBA-capable network can be accomplished using a few approaches:¶
Use the AGVL IEM (Section 3.2.1) on either the whole subnet or on interfaces known to interact with the target static address(es) directly. The AGVL IEM will permit per-implementation behaviors to strongly prefer Secured results of NDAR over Unsecured ones, allowing bindings for static addresses to be cached as long as no Secured responses are received.¶
It is not necessary to set AGVL on the interfaces with static addresses (unless such interfaces also interact with other static addresses), because the selected IEM affects neighbor verifications and does not impose restrictions on statically-assigned local interface addresses.¶
If local nodes simply do not interact with the static addresses, then the only affected parties are the node(s) with the static assignments and the subnet router, which will ostensibly route traffic to and from the static address(es). Most RAs will specify a link-local address as the subnet gateway: if this is the case within the subnet, then only router-to-host traffic will fail VBA verification. This is because the router needs to be aware of the LLID corresponding to the static IP address, but the host forwarding to the router can always safely verify using the router's link-local VBA.¶
Therefore, a static entry in the NC of the router can correlate the appropriate LLID(s) to the static IP address(es) of each neighbor. Doing this for long-term static IP addresses will mitigate any potential spoofing attacks for both neighbors involved while still ensuring that all NDAR transactions with other neighbors still verify according to IEM settings.¶
Anycast addresses are allocated from the unicast address space and are thus indistinguishable to nodes establishing connections to them. NDAR exchanges with these hosts may therefore respond with varying LLIDs and cause VBA verification to be unreliable. For this reason, it is NOT RECOMMENDED to utilize anycast addresses for on-link prefixes within VBA-enabled networks, because the address cannot be successfully bound to any one LLID.¶
The IPv6 Addressing Architecture RFC ([RFC4291]) outlines a Required Anycast Address
in Section 2.6.1. VBA implementations SHOULD maintain compatibility with this requirement by disabling
verification for on-link subnet anycast addresses. For example, a node using SLAAC to generate an
address in the subnet 2001:db8:700::/64 SHOULD disable VBA expectations and verifications for the
address 2001:db8:700::. Because VBA protections must be disabled for this target address, implementations
SHOULD avoid using the subnet Required Anycast Address wherever possible.¶
This document defines a new Neighbor Discovery Protocol option type and one new link-local multicast address. The introduced Link Voucher option type contains another set of Type-Length-Value (TLV) packet options. The multicast address also uses other assigned TLV packets to convey important (but optional) protocol information.¶
One new Neighbor Discovery Protocol option is defined in this document and must have a new Option Type value assigned in the "IPv6 Neighbor Discovery Option Formats" subregistry of the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry.¶
The Link Voucher option includes a new option type used to convey KDF algorithm selections. Assigned in the "Algorithm Type Options" subregistry are string identifiers corresponding to integers which indicate their Algorithm Type values. Future values MUST be assigned according to the Standards Action policy of [RFC8126]. Default registrations are defined in this document:¶
| Type | Name/Identifier |
|---|---|
| 1 | VBAKDF_PBKDF2_SHA256 |
| 10 | VBAKDF_ARGON2D |
| 20 | VBAKDF_SCRYPT |
See Section 5 for information about the Local On-link Voucher Multicast Address subscribed to by VBA-enabled network interfaces. This section will also contain specific packet formats.¶
Assigned in the "Link-Local Scope Multicast Addresses" subregistry of the "IPv6 Multicast Address Space Registry":¶
Address(es): FF02::ABBA
Description: Local On-link Voucher Multicast Address
Reference: draft-puhl-6man-ndp-vba-00¶
The well-known UDP port 2196 is used for multicast traffic on the LOVMA channel. Assigned in the "Service Name and Transport Protocol Port Number Registry":¶
Service Name: vba_lovma
Port Number: 2196
Transport Protocol: UDP
Description: IPv6 Voucher-Based Addressing LOVMA updates
Reference: draft-puhl-6man-ndp-vba-00¶
A set of three TLV packet types used specifically in the new LOVMA channel are defined in this document. Assigned in the "LOVMA Message Types and Options" subregistry of the "Voucher-Based Addressing (VBA) Parameters" registry.¶
The values in the "LOVMA Message Types and Options" subregistry are string identifiers corresponding to integers which indicate their packet Type values. Future values MUST be assigned according to the Standards Action policy of [RFC8126]. Default registrations are defined in this document:¶
| Type | Name/Identifier | Reference |
|---|---|---|
| 1 | LOVMA_VSR | Section 5.2.1 |
| 2 | LOVMA_VCI | Section 5.2.2 |
| 3 | LOVMA_VHA | Section 5.2.3 |
This section provides an overview of adjacent topics that might be explored in future work related to this document.¶
DHCP is not mentioned elsewhere in this document because VBAs are designed primarily for SLAAC-based environments. However, future work might wish to add features into DHCP servers that support VBAs, using something like DHCP Snooping to ensure that only legitimate servers are assigning addresses. Because of its centrality and responsibility, a DHCP server would also be well-suited as the link VB if no connected router supports VBA.¶
One notable change of generating VBAs server-side is the lack of an ability for client nodes to dynamically self-determine a work factor. Allowing nodes to choose their own work factor values affords them the ability to (1) randomize it according to their own decision-making processes and (2) preserve a Preferred Work Factor (see Section 5.2.1 about VSRs). In a future proposal, DHCP client options might be amended to allow a client to request a certain 'security level' as a work factor value. Such an option could also present an opportunity to exchange other information about client preferences or other important VBA details.¶
[RFC4389] specifies a Neighbor Discovery Proxy as a network-layer device or software used to provide a presence for nodes who have gone off-link or have always been residents off-link. This is supposed to stand in lieu of a classic link-layer bridge.¶
Due to link-layer binding, VBA does not support ND proxying unless the proxy is also able to spoof the LLIDs of all intended target nodes. These spoofed LLIDs would need to appear on the interface attached to the link that it must receive and answer ND packets on. One solution to enabling ND proxy while keeping the rest of the network secure is to apply the same strategy used for static addressing and create manual cache entries. Another solution might be to enable the AVGL IEM on the nodes who are required to transact with the proxy.¶
Support for ND proxies is not very well defined by this document since it conflicts with one of its primary goals. Future experimentation may wish to explore ways to integrate the two concepts seamlessly and securely.¶
Link Vouchers are susceptible to impersonation despite the use of asymmetric cryptography in signing their details. Once a host becomes aware of a valid public-key and signature, it becomes 'locked' to this key and will not accept LVs from senders NOT using it in their signatures (unless the current LV expires or a VHA is issued). However, the point of first contact between a legitimate, authorized VB and its neighbors is still vulnerable. This is because any malicious neighbor could craft its own LV and advertise it if it is not first blocked by infrastructure-based solutions like RA-Guard.¶
Section 6 of [RFC3971] dictates the use of a Public Key Infrastructure (PKI) to ensure communication is genuine between hosts and routers, and that each router is authorized to provide router information. Trust anchors are used to determine whether a certificate presented by a router validates its role in SEND: if the router presents a certificate that is trusted by the anchor, then neighbors sharing the same trust anchor will consider it as legitimate.¶
Future additions to this specification MAY invoke PKI and certificates for public-key signatures appearing on LVs. This could include amendments to the LV option which would extend the field to convey trust anchor or certification path information. While this proposal seeks to avoid the complexities introduced by PKI, it might be a crucial consideration for first-contact trust wherever RA-Guard or similar protections cannot be used. This is likely a much more performant use of certification paths than SEND, simply because the trust of a public key only needs to be verified during LV signature verification and not for various NDP messages.¶
Source code demonstrating the VBA address generation and verification procedures is available at https://github.com/NotsoanoNimus/voucher-based-addressing.¶
The author would like to thank Dr. Jinhua Guo of the University of Michigan for his valuable, constructive feedback and support of this work.¶