Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario
Extracted elements (22)
Forwarding a defended DAD message is explicitly prohibited because it may cause other SAVI devices on the perimeter to send additional defense NAs, and the rate of defense NAs should be limited to reduce DoS exposure from a malicious host flooding DAD messages.
Packet filtering in a SAVI-MIX device is not performed by each SAVI method separately; instead, all individual SAVI methods submit candidate bindings to SAVI-MIX, and the combined table drives filtering. This avoids one method incorrectly dropping addresses discovered by another.
When CGA addresses are used and a binding collision is detected, preference should be given to the anchor that carries verifiable CGA credentials (CGA parameters and RSA options), because CGA cryptographic verification provides stronger assurance than arrival order alone.
For DHCP and SLAAC coexistence, operators should use non-overlapping prefixes: set the A bit in the Prefix Information option of Router Advertisements for the SLAAC prefix and set the M bit for the DHCP prefix, per RFC 4861 and RFC 4862.
For SEND and non-SEND coexistence, operators should avoid mixed environments or separate the prefixes announced to SEND and non-SEND nodes, for example by sending unicast Router Advertisements with different non-overlapping prefixes in response to SEND vs. non-SEND Router Solicits.
In a multi-SAVI-device deployment, assuming DAD is performed throughout the security perimeter for all addresses regardless of assignment method, DAD responses propagate collision information to all SAVI devices, allowing First-Come, First-Served to work consistently across the perimeter.
A SAVI device MUST implement the corresponding binding setup methods (SAVI methods) for each address assignment technique in use if it is to provide source address validation.
At least one of "anchor" and "method" MUST be specified in a configuration-preference triplet ("prefix"/"address", "anchor", "method").
In the absence of any manual configuration or protocol hint, the SAVI device SHOULD choose the first-come binding anchor, consistent with the First-Come, First-Served principle implied by SLAAC, DHCPv4, DHCPv6, and SEND standards.
SEND nodes in the network MUST disable the option to ignore unsecured advertisements (per RFC 3971 Section 8) when the SAVI-MIX configuration-preference defense mechanism is in use; if that option is enabled, the case is outside the scope of this document.
The SAVI-MIX preferences of all SAVI devices in the same layer 2 domain SHOULD be consistent; inconsistent configurations may cause network breaks.
To prevent addresses discovered by one SAVI method from being filtered out by another, the SAVI binding table SHOULD be shared by all SAVI methods in use in the device.
When a DAD message arrives for a target matching a configured preference entry but with a different anchor, the switch SHOULD defend the address by sending a Neighbor Advertisement on behalf of the target node, SHOULD NOT install the entry into the binding table, and SHOULD discard (not forward) the DAD message.
When resolving a collision where the same address is bound to different binding anchors by different SAVI methods, if there is any manually configured binding the SAVI device SHOULD choose the manually configured binding anchor.
When implementing multiple SAVI methods, the privacy considerations of all enabled methods apply cumulatively to the combined SAVI-MIX deployment.
A SAVI device may be configured with a preference triplet of ("prefix" or "address", "anchor", "method") to override default First-Come, First-Served collision resolution; at least one of "anchor" and "method" MUST be specified in each such triplet.
Each entry in the SAVI-MIX binding table contains five fields: (1) IP source address, (2) binding anchor, (3) lifetime, (4) creation time, and (5) binding method (the SAVI method used for this entry).
SAVI-MIX is an arbiter component within a SAVI device that receives candidate binding setup requests from individual SAVI methods (FCFS, DHCP, SEND), resolves conflicts, and produces a single unified binding table used for packet filtering.
When the same address is bound to the same binding anchor by multiple SAVI methods (e.g., both FCFS SAVI and SAVI-DHCP), lifetime priority follows the order: (1) manual configuration, (2) SAVI-DHCP, (3) FCFS SAVI; the binding is removed when the highest-priority lifetime expires.
Combining SAVI methods does not improve or eliminate the security considerations of each individual SAVI method; each enabled method's security considerations (as described in its own RFC) must still be addressed independently.
Combining SAVI methods in SAVI-MIX may increase susceptibility to DoS attacks because the binding setup rate becomes the sum of the rates of all enabled SAVI methods; implementers must account for these added resource requirements.
SAVI-MIX potentially reduces the overall security level to that of the weakest supported method, unless additional measures such as requiring non-overlapping address spaces for different methods are taken.