IPv6 Voucher-Based Addressing for Neighbor Discovery Address Resolution
draft-puhl-6man-ndp-vba-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Zack Puhl | ||
| Last updated | 2024-09-08 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-puhl-6man-ndp-vba-00
IPv6 Maintenance Z. Puhl
Internet-Draft University of Michigan
Intended status: Experimental 8 September 2024
Expires: 12 March 2025
IPv6 Voucher-Based Addressing for Neighbor Discovery Address Resolution
draft-puhl-6man-ndp-vba-00
Abstract
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.
Status of This Memo
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 Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Puhl Expires 12 March 2025 [Page 1]
Internet-Draft ndp-vba September 2024
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 4
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Voucher-Based Addressing . . . . . . . . . . . . . . . . . . 7
3.1. Design . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Link-Layer Address Bindings . . . . . . . . . . . . . 8
3.1.2. Key Derivation Functions & Address Privacy . . . . . 9
3.2. Interface Configurations & States . . . . . . . . . . . . 10
3.2.1. Interface Enforcement Modes . . . . . . . . . . . . . 10
3.2.2. Preserving Voucher-Related State . . . . . . . . . . 11
3.2.3. Link Voucher Acquisitions . . . . . . . . . . . . . . 12
3.2.4. Host Recipients & Link Voucher Transitions . . . . . 12
3.3. Address Generation . . . . . . . . . . . . . . . . . . . 14
3.4. Address Verification . . . . . . . . . . . . . . . . . . 16
3.5. Behavioral Neighbor Discovery Changes . . . . . . . . . . 18
3.5.1. The Address Verification Shim . . . . . . . . . . . . 19
3.5.2. Neighbor Unreachability Detection . . . . . . . . . . 20
3.5.3. Link Voucher Updates . . . . . . . . . . . . . . . . 20
3.5.4. Gratuitous Neighbor Discovery . . . . . . . . . . . . 21
3.5.5. Duplicate Address Detection . . . . . . . . . . . . . 21
4. Neighbor Discovery Protocol Options . . . . . . . . . . . . . 23
4.1. Link Voucher Option . . . . . . . . . . . . . . . . . . . 24
4.1.1. Processing Rules for Senders . . . . . . . . . . . . 26
4.1.2. Processing Rules for Receivers . . . . . . . . . . . 27
4.1.3. Algorithm Type Options . . . . . . . . . . . . . . . 28
5. Local On-link Voucher Multicast Address . . . . . . . . . . . 31
5.1. Constraints . . . . . . . . . . . . . . . . . . . . . . . 32
5.2. Defined Datagrams . . . . . . . . . . . . . . . . . . . . 32
5.2.1. Voucher Status Reports (VSRs) . . . . . . . . . . . . 33
5.2.2. Voucher Capability Indications (VCIs) . . . . . . . . 35
5.2.3. Voucher Handoff Advertisements (VHAs) . . . . . . . . 36
6. Voucher Bearers . . . . . . . . . . . . . . . . . . . . . . . 39
6.1. Appointments . . . . . . . . . . . . . . . . . . . . . . 39
6.2. Employing RA-Guard . . . . . . . . . . . . . . . . . . . 39
7. Specification Optimizations . . . . . . . . . . . . . . . . . 40
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 41
Puhl Expires 12 March 2025 [Page 2]
Internet-Draft ndp-vba September 2024
7.2. A Note About Packet Loss & Speed . . . . . . . . . . . . 41
8. Transition Considerations . . . . . . . . . . . . . . . . . . 42
8.1. Tweaking Interface Enforcement Modes . . . . . . . . . . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . . 42
9.1. Collision Resistance & Time-Memory Tradeoffs . . . . . . 43
9.2. Concerning Adversaries . . . . . . . . . . . . . . . . . 44
9.2.1. Falsifying Neighbor Discovery Messages . . . . . . . 45
9.2.2. Prolonging Attacks & Lies . . . . . . . . . . . . . . 45
9.2.3. Tracking Address or Device Activity . . . . . . . . . 45
9.2.4. Forcing Neighbors Offline . . . . . . . . . . . . . . 46
9.3. Hijacking or Desynchronizing Link Vouchers . . . . . . . 46
9.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 48
9.4.1. Neighbor Solicitation Flooding . . . . . . . . . . . 48
9.4.2. Neighbor Advertisement Flooding . . . . . . . . . . . 49
9.4.3. Link Voucher Over-rotation . . . . . . . . . . . . . 49
9.5. Computational Fairness . . . . . . . . . . . . . . . . . 49
9.6. Static Addresses . . . . . . . . . . . . . . . . . . . . 50
9.7. Anycast Addresses . . . . . . . . . . . . . . . . . . . . 51
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.1. Deployments using DHCP . . . . . . . . . . . . . . . . . 53
11.2. Neighbor Discovery Proxies . . . . . . . . . . . . . . . 53
11.3. Certifying Link Vouchers . . . . . . . . . . . . . . . . 54
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
12.1. Normative References . . . . . . . . . . . . . . . . . . 55
12.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. Code Snippets . . . . . . . . . . . . . . . . . . . 58
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 58
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction
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
Puhl Expires 12 March 2025 [Page 3]
Internet-Draft ndp-vba September 2024
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.
1.1. Specification of Requirements
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.
1.2. Background
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.
* IP Version 6 Addressing Architecture [RFC4291].
* Neighbor Discovery for IP Version 6 [RFC4861].
* IPv6 Stateless Address Autoconfiguration [RFC4862].
* IPv6 Neighbor Discovery (ND) Trust Models and Threats [RFC3756].
* SEcure Neighbor Discovery (SEND) [RFC3971].
Puhl Expires 12 March 2025 [Page 4]
Internet-Draft ndp-vba September 2024
* Cryptographically Generated Addresses (CGA) [RFC3972].
* Semantically Opaque Interface Identifiers [RFC7217].
* Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6 [RFC8981].
* Security and Privacy Considerations for IPv6 Address Generation
Mechanisms [RFC7721].
* Recommendation on Stable IPv6 Interface Identifiers [RFC8064].
* PKCS #5: Password-Based Cryptography Specification Version 2.1
[RFC8018] (primarily Sections 3 and 4).
* The Argon2 Key Derivation Function [RFC9106].
* The Scrypt Key Derivation Function [RFC7914].
2. Terminology
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.
ND (sometimes NDP)
Neighbor Discovery (Protocol) [RFC4861].
SEND
SEcure Neighbor Discovery [RFC3971].
CGA
Cryptographically Generated Addressing [RFC3972].
NDAR
The Neighbor Discovery Address Resolution process; see Section 7.2
of [RFC4861].
NC
Neighbor Cache, as specified in Section 5.1 of [RFC4861].
RS, RA, NS, and NA
Respectively: Router Solicitation, Router Advertisement, Neighbor
Soliciation, and Neighbor Advertisement. A collection of
abbreviations for ICMP packet types defined by NDP in [RFC4861].
NUD
Neighbor Unreachability Detection (Section 7.3 of [RFC4861]).
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 connected network
interface.
Puhl Expires 12 March 2025 [Page 5]
Internet-Draft ndp-vba September 2024
IID
Interface Identifier. The unique identifier of an interface on a
network. See Section 2.5.1 of [RFC4291].
SLLAO
Source Link-Layer Address Option. An ND option indicating the
LLID of the packet sender or (typically) the NDAR initiator
[RFC4861].
TLLAO
Target Link-Layer Address Option. An ND option indicating the
LLID of the NDAR target [RFC4861].
DAD
Duplicate Address Detection (Section 5.4 of [RFC4862]).
SLAAC
Stateless Address Autoconfiguration [RFC4862].
VBA
Voucher-Based Addressing. The primary address generation and
verification concept introduced by this document.
LV
ND Link Voucher option. A data payload intended to be distributed
by a responsible node on-link. Details are statefully maintained
on neighbors and are used in both generating and verifying VBAs.
LOVMA
Local On-link Voucher Multicast Address. A multicast group used
by VBA-capable hosts to get non-essential information from the
current Voucher Bearer or from other VBA-capable neighbors.
VB
Voucher Bearer. The on-link node solely responsible for
dissemination of the LV and authorized by any potential link
guarding to transmit Router Advertisements or Redirects with an LV
attached.
VSR
Voucher Status Report. A type of data payload sent by VBA-capable
nodes to the LOVMA. Shares information about the node's VBA
preferences. Mainly used in optimizations as an optional protocol
feature.
VCI
Voucher Capability Indication. A type of LOVMA data payload sent
by candidate VBs to indicate their candidacy as a future VB.
Puhl Expires 12 March 2025 [Page 6]
Internet-Draft ndp-vba September 2024
VHA
Voucher Handoff Advertisement. A type of data payload sent by the
current VB to the LOVMA, signing off on an election process for a
new LV.
IEM
Interface Enforcement Mode. An interface-level, mutable operating
mode which controls interface address VBA generation and
verification behaviors.
LL2IP
Used to shorten the phrase "link-layer-address-to-IP" when
discussing address bindings.
Binding
Used primarily to describe a coupling between two types of
addresses on different layers of the network protocol stack. In
the case of this document, it describes LL2IP bindings, where
Link-Layer Identifiers are 'bound' to one or more IP addresses.
KDF
Key Derivation Function, as defined in Section 3 of [RFC8018].
Salt
An extra random value used in computing a hash which makes it
impossible for attackers to precompute output values. See
Section 4.1 of [RFC8018] for more information.
Hextet
A 16-bit aggregation; data that is 16 bits in size.
RA-Guard
The Router Advertisement Guard mechanism, as specified in
[RFC6105].
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.
3. Voucher-Based Addressing
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.
Puhl Expires 12 March 2025 [Page 7]
Internet-Draft ndp-vba September 2024
3.1. Design
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.
3.1.1. Link-Layer Address Bindings
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.
Puhl Expires 12 March 2025 [Page 8]
Internet-Draft ndp-vba September 2024
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.
3.1.2. Key Derivation Functions & Address Privacy
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
Puhl Expires 12 March 2025 [Page 9]
Internet-Draft ndp-vba September 2024
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:
* The target's Link-Layer Address (LLID) and IP address (VBA).
* A portion of the KDF's hash output (present within the VBA).
* The work factor used when computing the KDF hash (also present
within the VBA).
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.
3.2. Interface Configurations & States
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.
3.2.1. Interface Enforcement Modes
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 Disabled
The interface MUST NOT generate or verify any VBAs. It MUST NOT
participate in any LOVMA communications. VBAs are ignored
entirely in this mode, except for advertisements of Link Voucher
options, which MUST still be recorded and tracked. This mode
SHALL always be used by interfaces where a known LV is not
present.
Puhl Expires 12 March 2025 [Page 10]
Internet-Draft ndp-vba September 2024
AGO - Address Generation Only
The address generation procedure MUST be used for interface
unicast addresses. NDAR MUST NOT be supplemented by VBA
optimization or verification procedures.
AGV - Address Generation & Verification
The address generation and verification procedures MUST be used.
NDAR is REQUIRED to fail (deny neighbors, skip caching) if the
advertised LLID cannot be verifiably bound to the given IP address
according to the current Link Voucher. This SHOULD be the default
IEM on non-transitioning links with a well-established VBA
conformance.
AGVL - Address Generation & Verification with Levels
Both address generation and verification procedures are employed,
but verification failures MUST NOT discard NDP messages.
Addresses which successfully verify MUST be marked or indicated in
the local NC as "Secured". Any address which fails to verify MUST
be indicated as "Unsecured" and given less preference than
"Secured" responses. This SHOULD be the default IEM on
transitioning links that do not have full VBA adoption. If
multiple Secured responses are entered for the same IP, each with
a different LLID, then there may be an addressing collision and
the behavior of the interface becomes undefined. In this rare
case, the pool of Secured responses are considered equally valid
VBAs, so it is left to the implementation to decide the correct
course of action.
3.2.2. Preserving Voucher-Related State
Regardless 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.
Puhl Expires 12 March 2025 [Page 11]
Internet-Draft ndp-vba September 2024
3.2.3. Link Voucher Acquisitions
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.
3.2.4. Host Recipients & Link Voucher Transitions
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.
Puhl Expires 12 March 2025 [Page 12]
Internet-Draft ndp-vba September 2024
==========================================> 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.
Figure 1: Link Voucher Transitions
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
Puhl Expires 12 March 2025 [Page 13]
Internet-Draft ndp-vba September 2024
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.
3.3. Address Generation
This section discusses VBA composition and the VBA generation
procedure.
Puhl Expires 12 March 2025 [Page 14]
Internet-Draft ndp-vba September 2024
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)
Figure 2: The Voucher-Based Address Generation Procedure
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 'L' value, also termed the 'iterations count' or 'work
factor', controls how many times the KDF 'K' is iterated to
produce the resulting hash. Increasing this value thus
increases the work required to generate and verify the VBA and
the cost of finding potential hash collisions.
Puhl Expires 12 March 2025 [Page 15]
Internet-Draft ndp-vba September 2024
* 48 bits from the resulting hash, or 'H' value, derived from the
KDF after 'L' iterations. Implementations are REQUIRED to use the
FIRST 8 bytes of the hash in formulating the SUFFIX value,
replacing the first hextet with the 'Z' value as shown in the
figure.
The address generation algorithm is detailed procedurally as follows:
1. An interface connects to a link and obtains LV details after
solicitation (Section 4.1).
2. The 'L' value is chosen based on (1) interface/node preference,
(2) intended VBA difficulty, or (3) random selection.
3. The LV contains baseline KDF parameters and the 128-bit Seed
value to use in address computation.
4. 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 raw LLID of the network interface on which VBAs are being
generated. Note that, since the Salt value is a variable-
length value, this is not required to be an IEEE 802 MAC
address, but it MUST represent the same link-layer address to
which the VBA(s) will be bound and thus verified during NDAR.
* The string "vba" without a null termination.
* The raw PREFIX value. This MUST match the 64-bit prefix for
which the VBA will be generated, including any randomly
assigned padding bytes.
5. The final address SUFFIX is computed:
* The first 16 bits are the bitwise complement of an XOR between
the work factor 'L' and the first hextet of the LV seed.
* The least significant 48 bits are 6 sequential bytes from the
KDF hash, skipping the first two bytes (hextet) in the
sequence.
3.4. Address Verification
This section provides an overview of VBA verification.
Client Node
The node resolving the LLID of a neighbor's Target Address; sends
the initial NS packet with an SLLAO.
Puhl Expires 12 March 2025 [Page 16]
Internet-Draft ndp-vba September 2024
Target Node
The node supplying its TLLAO in a responding NA.
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
Figure 3: The Voucher-Based Address Verification Procedure
Puhl Expires 12 March 2025 [Page 17]
Internet-Draft ndp-vba September 2024
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])
Returns a hextet to insert into a generated address. A bitwise
complement of the result of a work factor value XOR'd with the
first hextet of an LV Seed value.
Z'(B, LV) = ~(B[8..9] ^ LV.seed[0..1])
Returns a work factor 'L' derived from a full IP address 'B'. In
this case, 'B[8..9]' is equal to the length and position of the
embedded hextet calculated by the function 'Z' above.
3.5. Behavioral Neighbor Discovery Changes
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:
Puhl Expires 12 March 2025 [Page 18]
Internet-Draft ndp-vba September 2024
* 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.
3.5.1. The Address Verification Shim
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:
Puhl Expires 12 March 2025 [Page 19]
Internet-Draft ndp-vba September 2024
* 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.
* If the receiving interface is using the AGVL IEM: an NA packet is
received and the Override flag is set.
* An NA or Redirect packet is received on a node supporting
Gratuitious ND [RFC9131] and the Target Address does not already
have an NC entry.
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.
3.5.2. Neighbor Unreachability Detection
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.
3.5.3. Link Voucher Updates
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).
Puhl Expires 12 March 2025 [Page 20]
Internet-Draft ndp-vba September 2024
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.
3.5.4. Gratuitous Neighbor Discovery
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.
3.5.5. Duplicate Address Detection
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):
Puhl Expires 12 March 2025 [Page 21]
Internet-Draft ndp-vba September 2024
L > 4
Cache the 4 leading KDF iterations (L-4 through L-1) during the
VBA generation.
L <= 4
Cache the result of the VBA derived from the 'L' value only.
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'] --'
Figure 4: Using DAD with VBAs
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.
1. A new network host has received LV details; it specifies using
PBKDF2 as the KDF.
2. The host arbitrarily selects 0xFF04 as its link-local VBA's 'L'
value.
3. The host will iterate the PBKDF2 function through 0xFEFF.
Puhl Expires 12 March 2025 [Page 22]
Internet-Draft ndp-vba September 2024
4. The PBKDF2 cipher output for 0xFF00 (or L-4) iterations will be
cached.
5. It will do the same for the next 3 steps (0xFF01, 0xFF02, &
0xFF03).
6. It will compute the final PBKDF2 round at 0xFF04 iterations, and
will use the result to generate a valid link-local VBA.
7. When following the DAD procedure, an address collision is
detected.
8. The host then immediately falls back to the KDF hash result from
the L-1 value of 0xFF03 to create the link-local VBA.
9. This new VBA is completely different and does not register a DAD
collision, so the interface continues using it.
10. The optimization has successfully removed the need to recompute
the PBKDF2 algorithm up to some new work factor input, saving a
significant amount of time in the VBA-enabled SLAAC process.
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.
4. Neighbor Discovery Protocol Options
The NDP option formats specified in this section MUST be supported to
enable VBA functionality.
Puhl Expires 12 March 2025 [Page 23]
Internet-Draft ndp-vba September 2024
4.1. Link Voucher Option
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 <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Structure of the NDP Link Voucher Option
Type
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 should be considered legitimate when an update has not
been received. This value MUST be a minimum of 3,600 (1 hour).
Puhl Expires 12 March 2025 [Page 24]
Internet-Draft ndp-vba September 2024
Reserved
64 bits of space reserved for future use. This value MUST be
initialized to 0 by senders and MUST be ignored by receivers.
Timestamp
A 64-bit value representing the system time of the sender upon
sending the option.
VoucherID
A pseudo-random 32-bit value which uniquely identifies an LV
instance. This MUST NOT change between distributions of the same
unique LV and seed value.
Seed
A 128-bit pseudo-random value used as an input in VBA generation.
This value MUST be the same for each distribution of an LV
instance identified by a VoucherID. It MUST NOT be the same value
across different LV instances.
Algorithm Type
Specifies the type and difficulty of the KDF to use in VBA
generation. See Section 4.1.3 for more details.
ECDSA PublicKey & Signature
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:
1. The 16-bit 'Expiration' value.
2. The 64-bit 'Timestamp' value.
3. The 32-bit 'VoucherID' value.
4. The 128-bit 'Seed' value.
5. The full variable-length content 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 [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:
Puhl Expires 12 March 2025 [Page 25]
Internet-Draft ndp-vba September 2024
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
},
subjectPublicKey BIT STRING
}
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Figure 6
Padding
Any extra padding set on the datagram to round its total length to
an even 8-octet boundary. Senders MUST initialize this value to
0. Receivers MUST ignore this field.
4.1.1. Processing Rules for Senders
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.
1. Send a Router Soliciation to the All Routers multicast group at
FF02::2.
2. Wait for an LV option for at least 2 seconds before sending
another RS.
3. Repeat this process 2 more times.
* If an LV is received within an RA or Redirect response, accept
and use the parameters of the received LV. This condition
means the Sender MUST NOT use or send their own LV, nor should
it propagate any instances of received LVs.
* If no LV is received after the 3 total attempts, and...
- the Sender IS NOT a router: the Sender's LV may be
distributed on the local link as an option attached to an
appropriate ND Redirect message.
- the Sender IS a router: the Sender may attach its LV to an
appropriate ND RA message.
Puhl Expires 12 March 2025 [Page 26]
Internet-Draft ndp-vba September 2024
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.
4.1.2. Processing Rules for Receivers
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.
Puhl Expires 12 March 2025 [Page 27]
Internet-Draft ndp-vba September 2024
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.
4.1.3. Algorithm Type Options
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.
Puhl Expires 12 March 2025 [Page 28]
Internet-Draft ndp-vba September 2024
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 <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Structure of an Algorithm Type Option
The list of default KDF Algorithm Type choices is given below.
PBKDF2_SHA256
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.
Type
1
Length
2
Value
ITERATIONS_FACTOR
A big-endian 16-bit integer representing the multiplier of
an input KDF work factor 'L'. This value MUST be greater
than 0; receivers of 0 values MUST assume 1 instead. This
factor can be used by an LV to automatically scale the
difficulty of the PBKDF2 KDF on the link.
Padding
16 bits (2 octets) of padding initialized to zero. Senders
MUST set this to 0. Receivers MUST ignore this padding.
Puhl Expires 12 March 2025 [Page 29]
Internet-Draft ndp-vba September 2024
Argon2d
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.
Type
10
Length
2
Value
Parallelism
An 8-bit integer determining how many degrees of parallelism
(lanes) are allowed to run during KDF computation. This
value SHALL NOT be set to 0. Receivers MUST consider
Parallelism values of 0 to automatically indicate a
Parallelism of 1.
MemorySize
A big-endian 24-bit integer representing the number of
kibibytes (KiB) used in the KDF computation. This value
SHOULD be carefully controlled and SHOULD if possible take
into consideration the computing resources across the link
on which the LV will be distributed. This value MUST be a
minimum of 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.
Puhl Expires 12 March 2025 [Page 30]
Internet-Draft ndp-vba September 2024
Scrypt
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.
Type
20
Length
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 adjust the maximum SCALING_FACTOR
to 5 if the value of this field is greater than 5.
Padding
24 bits (3 octets) of padding initialized to zero. Senders
MUST set this to 0. Receivers MUST ignore this padding.
5. Local On-link Voucher Multicast Address
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".
Puhl Expires 12 March 2025 [Page 31]
Internet-Draft ndp-vba September 2024
The designated UDP port on which all LOVMA data is sent and received
is 2196.
5.1. Constraints
When utilizing the LOVMA channel for any purpose, implementations
MUST regard these constraints:
* LOVMA messages are considered unidirectional. Neighbors SHOULD
NOT send unicast responses in reply to multicast traffic. This
recommended constraint prevents asymmetric traffic volumes and any
resulting denial-of-service vulnerabilities.
* All LOVMA datagrams MUST be User Datagram Protocol (UDP) [RFC768]
packets.
* VBA-capable neighbors MUST NOT assume that any other VBA-capable
nodes are subscribed to the LOVMA multicast group or receiving any
of its related datagrams. However, neighbors MAY assume the
presence of the current link VB on the LOVMA.
* Subscribing nodes MUST NOT offer any trust of LOVMA packets,
unless some datagram verification procedure is explicitly declared
in the Defined Datagram Type specification.
* Senders of LOVMA traffic are REQUIRED to send packets from a link-
local VBA bound to the sending interface.
5.2. Defined Datagrams
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... |
> ... <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Structure of an LOVMA Datagram
Puhl Expires 12 March 2025 [Page 32]
Internet-Draft ndp-vba September 2024
5.2.1. Voucher Status Reports (VSRs)
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 <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Structure of a VSR Datagram
Type
1
Length
Variable. The length of the datagram in its totality, rounded up
to the nearest 4 octets.
IEM
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.
Puhl Expires 12 March 2025 [Page 33]
Internet-Draft ndp-vba September 2024
+=======+==========+
| Value | IEM |
+=======+==========+
| 0 | AAD |
+-------+----------+
| 1 | AGO |
+-------+----------+
| 2 | AGV |
+-------+----------+
| 3 | AGVL |
+-------+----------+
| 4 | Reserved |
+-------+----------+
| 5 | Reserved |
+-------+----------+
| 6 | Reserved |
+-------+----------+
| 7 | Reserved |
+-------+----------+
Table 1: IEM
Identifier Mappings
Reserved
Space reserved for future use. This value MUST be initialized to
0 by senders and MUST be ignored by receivers.
VoucherID
The ID of the cached, active LV stored for the sending interface.
Senders MUST initialize this to 0 if no LV is present or if they
are operating in the AAD IEM.
Preferred Work Factor
Senders MAY use this field to indicate a preferred work factor
('L') value used often when generating VBAs within each on-link
prefix. Receivers MAY associate this field with the LLID value to
preemptively calculate VBAs for the Sender when the current LV
changes or transitions.
LLID Length
The length in bytes of the LLID field. Stored as a big-endian
value.
LLID
A variable-length field containing the sending interface's LLID.
Puhl Expires 12 March 2025 [Page 34]
Internet-Draft ndp-vba September 2024
Padding
Any extra padding set on the datagram to round its total length to
an even 4-octet boundary. Senders MUST initialize this value to
0. Receivers MUST ignore this field.
5.2.2. Voucher Capability Indications (VCIs)
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 <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Structure of a VCI Datagram
Type
2
Length
Variable. The length of the datagram in its totality rounded up
to the nearest 4 octets.
Reserved
Space reserved for future use. This value MUST be initialized to
zero by senders and MUST be ignored by receivers.
Puhl Expires 12 March 2025 [Page 35]
Internet-Draft ndp-vba September 2024
Link Voucher Contents
The entirety of the ND Link Voucher option to be attached to
future RAs or Redirects. This MUST also include the LV's ND
Option Type and Length values. Validation of this field follows
the same rules outlined by Section 4.1. Receivers MUST NOT expect
the signature or PublicKey of the LV option to be the same as that
of the current LV, because this packet type is only announcing a
node's candidacy for future election, and it is NOT attempting to
declare a new LV. Receivers MUST ignore the entire VCI if
validation of the embedded LV fails for any reason, including
invalid cryptographic signatures, null IDs, etc.
5.2.3. Voucher Handoff Advertisements (VHAs)
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.
Puhl Expires 12 March 2025 [Page 36]
Internet-Draft ndp-vba September 2024
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 <
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Structure of a VHA Datagram
Type
3
Length
Variable. The length of the datagram in its totality rounded up
to the nearest 4 octets.
R (Refresh Bit)
A single bit. When set to '1', it indicates that the transition
is only an LV refresh and does not represent a change of the link
VB to a different node. This field is mostly used for
informational purposes and for any implementation-specific
optimizations.
Reserved
15 bits of space reserved for future use. This value MUST be
initialized to 0 by senders and MUST be ignored by receivers.
Puhl Expires 12 March 2025 [Page 37]
Internet-Draft ndp-vba September 2024
Timestamp
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.
Signer VoucherID
The VoucherID of the active LV which is signing the handoff to the
Upcoming VoucherID. Nodes using this ID for their active LV MUST
disregard any further advertised LVs with this ID upon receiving
this VHA datagram. A receiver MUST ignore this packet if the
Signer VoucherID does not represent the active LV held in the
cache of its receiving interface.
Upcoming VoucherID
The VoucherID of the upcoming LV which will be assuming 'active'
status on the network after the handoff window completes.
ECDSA Signature
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:
1. The 64-bit 'Timestamp' value.
2. The 32-bit 'Signer VoucherID' value.
3. The 32-bit 'Upcoming VoucherID' value.
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.
Puhl Expires 12 March 2025 [Page 38]
Internet-Draft ndp-vba September 2024
Padding
Any padding necessary to round the packet size up to the nearest
32-bit boundary. This value MUST be initialized to 0 by senders
and MUST be ignored by receivers.
6. Voucher Bearers
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.
6.1. Appointments
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.
6.2. Employing RA-Guard
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
Puhl Expires 12 March 2025 [Page 39]
Internet-Draft ndp-vba September 2024
| 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.
7. Specification Optimizations
This section briefly summarizes and references the various
optimizations built into VBA by default.
Puhl Expires 12 March 2025 [Page 40]
Internet-Draft ndp-vba September 2024
7.1. Summary
Avoiding Repeat Verifications
Neighbor Discovery NUD is used to avoid continuous and expensive
verification of active neighbors. If the current LV has not
changed, then bindings reported in an NDAR exchange do not need to
be re-verified after being cached. Section 3.5.2 provides more
details about this crucial performance optimization.
Duplicate Address Detection
The SLAAC DAD process [RFC4862] is optimized to reduce the burden
of regenerating another VBA from scratch for each collision.
Section 3.5.5 describes this cost reduction.
The LOVMA Channel & Preemption
The LOVMA group affords various VBA optimizations to the link. It
enables the use of transition windows for VBA-capable neighbors to
detect upcoming LV changes (Section 5.2.3). It allows hosts to
note their preferred work factors for upcoming VBA generations,
new prefixes, and LV transitions (Section 5.2.1). Lastly, it
allows nodes to become candidates for VB election when the current
VB no longer wishes to maintain responsibility for the LV
(Section 5.2.2).
Key Derviation Function Selections
The options presented in Section 4.1.3 permits the flexibility to
choose a baseline difficulty setting for VBA generation and
verification on the link. From this baseline, which
implementations MAY choose either by default settings or by other
details gathered about the link, nodes are permitted to scale the
difficulties of each VBA they generate based on selected work
factor values.
7.2. A Note About Packet Loss & Speed
This 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.
Puhl Expires 12 March 2025 [Page 41]
Internet-Draft ndp-vba September 2024
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.
8. Transition Considerations
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.
8.1. Tweaking Interface Enforcement Modes
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.
9. Security Considerations
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.
Puhl Expires 12 March 2025 [Page 42]
Internet-Draft ndp-vba September 2024
9.1. Collision Resistance & Time-Memory Tradeoffs
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.
Puhl Expires 12 March 2025 [Page 43]
Internet-Draft ndp-vba September 2024
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 (2^48 when not accounting for reserved MAC address ranges).
9.2. Concerning Adversaries
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.
Puhl Expires 12 March 2025 [Page 44]
Internet-Draft ndp-vba September 2024
9.2.1. Falsifying Neighbor Discovery Messages
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.
9.2.2. Prolonging Attacks & Lies
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.
9.2.3. Tracking Address or Device Activity
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
Puhl Expires 12 March 2025 [Page 45]
Internet-Draft ndp-vba September 2024
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.
9.2.4. Forcing Neighbors Offline
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.
9.3. Hijacking or Desynchronizing Link Vouchers
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.
Puhl Expires 12 March 2025 [Page 46]
Internet-Draft ndp-vba September 2024
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.
* Denial of service attacks could result from setting LV parameters
to an excessive difficulty. By asking local nodes to verify and
generate according to absurd KDF settings, even for low work
factor values chosen on each neighbor, absurd amounts of computing
resources could be consumed and wasted. This could potentially
harbor enough resources on a neighbor to force it offline.
* Consider a situation where Group_A represents hosts aware of
legitimate LV_A and Group_B represents hosts aware of malicious
LV_B. Having multiple LVs active on the same link will inevitably
lead to different logical subnetworks, where Group_A hosts are
generating and verifying VBAs according to a completely different
LV than Group_B. Depending on per-interface IEMs, hosts from one
group will be completely barred from communicating with hosts in
the other.
* Malicious VBs could transmit an LV dictating use of a KDF with
very minimal requirements. For example, PBKDF2_SHA256 with an
ITERATIONS_FACTOR of 1. Targeting hosts with low work factor
values would be most efficient for pre-computing a valid and
spoofed LLID that produces an address collision. Undermining the
entire subnet in this way affords the attacker a greater advantage
by greatly reducing the computation costs of neighbor spoofing.
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.
Puhl Expires 12 March 2025 [Page 47]
Internet-Draft ndp-vba September 2024
9.4. Denial of Service
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.
9.4.1. Neighbor Solicitation Flooding
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.
Puhl Expires 12 March 2025 [Page 48]
Internet-Draft ndp-vba September 2024
9.4.2. Neighbor Advertisement Flooding
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.
9.4.3. Link Voucher Over-rotation
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.
9.5. Computational Fairness
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.
Puhl Expires 12 March 2025 [Page 49]
Internet-Draft ndp-vba September 2024
9.6. Static Addresses
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.
* Simply use manual NC entries across the whole subnet wherever
interactions with the static IP addresses may be required. Doing
this abates the need for VBA at all.
Puhl Expires 12 March 2025 [Page 50]
Internet-Draft ndp-vba September 2024
9.7. Anycast Addresses
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.
10. IANA Considerations
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 (63), described in Section 4.1.
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:
Puhl Expires 12 March 2025 [Page 51]
Internet-Draft ndp-vba September 2024
+======+======================+
| Type | Name/Identifier |
+======+======================+
| 1 | VBAKDF_PBKDF2_SHA256 |
+------+----------------------+
| 10 | VBAKDF_ARGON2D |
+------+----------------------+
| 20 | VBAKDF_SCRYPT |
+------+----------------------+
Table 2: Initial Values of
the "Algorithm Type
Options" Subregistry
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:
Puhl Expires 12 March 2025 [Page 52]
Internet-Draft ndp-vba September 2024
+======+=================+===============+
| 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 |
+------+-----------------+---------------+
Table 3: Initial Values of the "LOVMA
Message Types and Options" Subregistry
11. Future Work
This section provides an overview of adjacent topics that might be
explored in future work related to this document.
11.1. Deployments using DHCP
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.
11.2. Neighbor Discovery Proxies
[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.
Puhl Expires 12 March 2025 [Page 53]
Internet-Draft ndp-vba September 2024
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.
11.3. Certifying Link Vouchers
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.
12. References
Puhl Expires 12 March 2025 [Page 54]
Internet-Draft ndp-vba September 2024
12.1. Normative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
Password-Based Cryptography Specification Version 2.1",
RFC 8018, DOI 10.17487/RFC8018, January 2017,
<https://www.rfc-editor.org/info/rfc8018>.
[RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "Argon2 Memory-Hard Function for Password
Hashing and Proof-of-Work Applications", RFC 9106,
DOI 10.17487/RFC9106, September 2021,
<https://www.rfc-editor.org/info/rfc9106>.
[RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based
Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
August 2016, <https://www.rfc-editor.org/info/rfc7914>.
12.2. Informative References
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, DOI 10.17487/RFC3756, May 2004,
<https://www.rfc-editor.org/info/rfc3756>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
Puhl Expires 12 March 2025 [Page 55]
Internet-Draft ndp-vba September 2024
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Problem Statement", RFC 6104, DOI 10.17487/RFC6104,
February 2011, <https://www.rfc-editor.org/info/rfc6104>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/info/rfc6105>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<https://www.rfc-editor.org/info/rfc4429>.
[RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E.,
and W. George, "Enhanced Duplicate Address Detection",
RFC 7527, DOI 10.17487/RFC7527, April 2015,
<https://www.rfc-editor.org/info/rfc7527>.
[RFC9131] Linkova, J., "Gratuitous Neighbor Discovery: Creating
Neighbor Cache Entries on First-Hop Routers", RFC 9131,
DOI 10.17487/RFC9131, October 2021,
<https://www.rfc-editor.org/info/rfc9131>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
2006, <https://www.rfc-editor.org/info/rfc4389>.
Puhl Expires 12 March 2025 [Page 56]
Internet-Draft ndp-vba September 2024
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
Polk, "Internet X.509 Public Key Infrastructure:
Additional Algorithms and Identifiers for DSA and ECDSA",
RFC 5758, DOI 10.17487/RFC5758, January 2010,
<https://www.rfc-editor.org/info/rfc5758>.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
2002, <https://www.rfc-editor.org/info/rfc3279>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<https://www.rfc-editor.org/info/rfc5480>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[ITU.X690.2002]
International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER), and
Distinguished Encoding Rules (DER)",
<https://www.itu.int/rec/T-REC-X.690>.
Puhl Expires 12 March 2025 [Page 57]
Internet-Draft ndp-vba September 2024
[ETHSEC] Kiravuo, T., Sarela, M., and J. Manner, "A Survey of
Ethernet LAN Security",
DOI 10.1109/SURV.2012.121112.00190, January 2013,
<https://doi.org/10.1109/SURV.2012.121112.00190>.
[TOFU] Walfield, N. H. and W. Koch, "TOFU for OpenPGP",
DOI 10.1145/2905760.2905761, April 2016,
<https://doi.org/10.1145/2905760.2905761>.
[ECDSA] Johnson, D., Menezes, A., and S. Vanstone, "The Elliptic
Curve Digital Signature Algorithm (ECDSA)",
DOI 10.1007/s102070100002, August 2001,
<https://doi.org/10.1007/s102070100002>.
[SP.800-132]
National Institute of Standards and Technology,
"Recommendation for Password-Based Key Derviation, Part 1:
Storage Applications", DOI 10.6028/NIST.SP.800-132,
December 2010, <https://doi.org/10.6028/NIST.SP.800-132>.
[MEMBOUND] Abadi, M., Burrows, M., Manasse, M., and T. Wobber,
"Moderately Hard, Memory-bound Functions",
DOI 10.1145/1064340.1064341, May 2005,
<https://doi.org/10.1145/1064340.1064341>.
Appendix A. Code Snippets
Source code demonstrating the VBA address generation and verification
procedures is available at https://github.com/NotsoanoNimus/voucher-
based-addressing.
Acknowledgements
The author would like to thank Dr. Jinhua Guo of the University of
Michigan for his valuable, constructive feedback and support of this
work.
Author's Address
Zack Puhl
University of Michigan
Detroit, Michigan
United States of America
Email: zpuhl@xmit.xyz, zpuhl@umich.edu
URI: https://xmit.xyz/
Puhl Expires 12 March 2025 [Page 58]