SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)
Extracted elements (31)
Only DAD_NSOL, DAD_NADV, and NUD_NADV messages can trigger transitions between forwarding and non-forwarding states; arbitrary data packets cannot. This design choice simplifies SEND SAVI processing and prevents data-plane traffic from disrupting binding validity.
SEND SAVI requires no changes to end nodes because verification relies entirely on existing SEND messages (DAD_NSOL, DAD_NADV, NUD_NSOL, NUD_NADV). It defines no new protocols or messages, enabling incremental deployment without host or router modifications.
Switch ports rather than MAC addresses are used as binding anchors because MAC addresses are trivially spoofable. Using a spoofable anchor together with packet dropping would create new DoS vectors based on spoofed binding anchors.
The protection-perimeter model limits source-address validation to the ingress point of the protected realm rather than at every traversed SEND SAVI device. This reduces per-device computing and state requirements in multi-switch deployments.
For virtual switch deployments, if the hypervisor is trusted the virtual switch can be incorporated into the SEND SAVI perimeter (its uplink and the physical port configured as Trusted); if untrusted, the physical port is set Validating and all VM addresses are validated at the physical SEND SAVI device.
Multihomed hosts that share a single IP address across interfaces, or send packets from one interface using another interface's address, are not directly supported. Workarounds are connecting at least one interface to a Trusted port or manually configuring multi-anchor bindings.
Untrusted dynamically attached routers (e.g., a mobile phone acting as a router) cannot be accommodated: they cannot use a Trusted port (not trusted by the operator) and a Validating port causes all their forwarded transit traffic to be discarded. This scenario is explicitly out of scope.
A SEND SAVI device is RECOMMENDED to reserve a minimum of four binding slots per port so that a DoS flooding attack on one port cannot starve nodes on other ports of binding capacity.
A SEND SAVI device MUST be configured with a valid CGA address and MUST behave as a regular SEND node (secured DAD, etc.) when configuring it, per RFC 6434 IPv6 node requirements.
A SEND SAVI device MUST limit the memory used to buffer data packets during address verification, so that DoS flooding cannot exhaust memory needed for binding storage and other functions.
On a VLAN-capable SEND SAVI switch, the SEND SAVI process MUST behave as if there is one independent SEND SAVI process per customer VLAN, with each process maintaining its own binding database.
Ports connected to another SEND SAVI device MUST be configured as Trusted. Ports connected to routers MUST also be Trusted, since routers legitimately forward transit traffic with off-link source addresses.
Ports connected to hosts SHOULD be configured as Validating ports. No more than one host SHOULD be connected per Validating port, as multiple hosts on the same port can spoof each other's addresses and perform replay attacks.
Rate-limiting of packets that trigger SEND SAVI events SHOULD be enforced on a per-port basis to prevent CPU exhaustion from attackers repeatedly triggering costly cryptographic DAD_NSOL validation or NUD_NSOL generation.
SEND SAVI devices MUST discard RADV messages received from Validating ports; RADV messages are only accepted and processed when received through Trusted ports.
SEND SAVI devices MUST only use ND messages received through Validating ports if they are valid per RFC 3971; invalid messages MUST be discarded. Messages from Trusted ports SHOULD NOT be re-validated to reduce processing load.
The SEND SAVI device MUST join the Solicited Node Multicast group for all addresses whose state is other than NO_BIND, ensuring DAD_NSOL messages for those addresses are received even after a node moves.
Transit traffic (source address not in SEND SAVI Prefix List) received through a Validating port MUST be discarded. Transit traffic from a Trusted port is forwarded without SAVI processing.
When the SEND SAVI Database is full, it is RECOMMENDED to evict entries with the highest creation time (newest entries), so that older legitimate bindings are preserved against flooding attacks.
When the SEND SAVI device boots, it MUST send a Router Solicitation (RSOL) to populate the SEND SAVI Prefix List. The RSOL need not be secured if the unspecified address is used. The device SHOULD also re-issue RSOL when a prefix entry is about to expire.
A SEND SAVI device MUST delete binding anchor information as soon as a given address returns to NO_BIND state, except where needed for detection or tracing of actual source address spoofing. Binding data about non-spoofing hosts SHOULD NOT be logged.
Protocol constants: TENT_LT (tentative lifetime used during DAD/NUD checks) is 500 milliseconds; DEFAULT_LT (lifetime assigned to VALID-state bindings) is 5 minutes.
SEND SAVI binds IPv6 source addresses to switch ports (binding anchors) using SEND-validated DAD_NSOL, DAD_NADV, NUD_NSOL, and NUD_NADV messages. Data packets are validated by checking consistency against these bindings, and hosts are prevented from generating packets with off-link IPv6 source addresses.
SEND SAVI defines two port roles: Validating ports (VPs), where source-address filtering and binding creation are performed, and Trusted ports (TPs), where only SEND messages related to certificates, prefix information, and DAD are processed without full re-validation.
The SEND SAVI Database stores per-address state: IPv6 source address, binding anchor (switch port), lifetime, status (one of TENTATIVE_DAD, TENTATIVE_NUD, VALID, TESTING_VP, or TESTING_VP'), alternative binding anchor, and creation time.
The SEND SAVI Prefix List stores link prefixes learned from Prefix Information options (L-bit set) in RADV messages arriving on Trusted ports, or configured manually. Manually configured entries use lifetime 0xffffffff (infinity). The list is not port-specific.
DoS attacks can target SEND SAVI by (1) sending many distinct source addresses to exhaust binding memory, or (2) forcing expensive cryptographic operations per new source address to drain CPU. Mitigations are per-port memory reservations, newest-first cache eviction, and per-port rate-limiting.
In centralized PKI deployments, a router with a globally valid certificate could masquerade as a legitimate router on any link. SEND SAVI mitigates this by rejecting RADV messages and traffic with off-link source addresses arriving on Validating ports, regardless of certificate validity.
Residual threat: if an attacker can DoS a legitimate host into silence, the host cannot answer NUD_NSOL probes, causing SEND SAVI to expire the binding and potentially grant it to the attacker's port after TENT_LT.
SEND SAVI strengthens replay-attack protection beyond SEND by restricting DAD_NSOL propagation only to ports that previously held a binding for the same address. An attacker cannot replay a captured DAD_NSOL to forge a binding from a different port without being able to generate a new valid CGA-signed message, which is deemed infeasible.
SEND SAVI defines six per-(address, device) states: NO_BIND (no binding), TENTATIVE_DAD (DAD_NSOL received, awaiting DAD outcome), TENTATIVE_NUD (data received without prior binding, NUD_NSOL issued), VALID (ownership confirmed, packets forwarded), TESTING_VP (periodic NUD ownership check on current anchor port), and TESTING_VP' (conflict from alternate port detected, testing existing anchor while holding alternative). Transitions are triggered by reception of DAD_NSOL, DAD_NADV, NUD_NADV, data packets, or LIFETIME expiry.