Stage first-hop source validation without stranding legitimate devices

Source facts: SAVI binds permitted source addresses near attachment points

RFC 7513 specifies a Source Address Validation Improvement solution for DHCP environments. A SAVI device builds bindings between a source address and a binding anchor associated with the attachment point, then filters packets whose source information does not match a valid binding. The design aims to reduce source-address spoofing close to the host.

RFC 6959 analyzes SAVI threats and deployment considerations, including forged control messages, topology assumptions, state exhaustion, binding disruption, and the need to protect trust relationships. Vendor access-switch features can combine DHCP snooping bindings, IP source guard, and dynamic ARP inspection, but command names, protocol scope, storage, failover, and enforcement behavior vary by platform.

First-hop validation is complementary to broader source-address validation and routing security. It does not prove user identity, inspect application behavior, or stop a permitted device from sending malicious traffic with its valid address. A bad trusted-port decision, missing static binding, lost binding database, unsupported address-assignment method, or incomplete IPv6 design can also block legitimate service.

DSE recommendation: learn the edge before enforcing it

Treat source validation as an access-layer architecture change. Start by modeling how each device class receives an address and how the binding survives normal failures.

1. Inventory attachment types. Map user endpoints, phones, cameras, access-control panels, printers, servers, hypervisors, wireless access points, downstream switches, routers, firewalls, building systems, static devices, and guest networks. Record VLAN, IPv4 and IPv6 methods, mobility, redundancy, and business criticality.
2. Draw trust boundaries. Identify where DHCP server messages should enter, which ports face hosts, where trunks and relays operate, and which infrastructure genuinely requires trust. Minimize trusted ports and document why each one cannot be treated as an ordinary attachment point.
3. Design binding sources. Determine how dynamic leases, reservations, static addresses, failover, readdressing, virtual machines, link aggregation, wireless roaming, and device replacement create or update a valid binding. Plan protected persistence and recovery where the platform supports it.
4. Protect the control plane. Apply rate limits, capacity monitoring, authorized DHCP-server controls, secure administration, logging, configuration backup, and change control. Verify that an attacker cannot cheaply exhaust binding resources or cause the switch to trust a hostile control message.
5. Pilot with evidence. Use monitor, permit-and-log, or narrowly scoped enforcement modes where supported. Compare learned bindings with DHCP and inventory data. Test renewals, expiry, sleep and wake, phone-and-PC pass-through, wireless movement, stack failover, reboot, server failover, and loss of the binding database.
6. Stage enforcement. Begin with well-understood user segments, maintain console or out-of-band recovery, schedule business-aware change windows, and publish helpdesk symptoms. Add static or exceptional bindings through an approved, expiring process rather than broad trust.
7. Watch the result. Monitor drops by port and reason, binding-table use, untrusted server events, ARP inspection failures, unexpected source changes, failover behavior, and exception age. Correlate with authentication and asset context without claiming the binding proves a person.

Define a stop condition before each enforcement stage. An unexpected increase in blocked critical devices, binding loss after switch restart, DHCP failover errors, or loss of management reachability should pause expansion and trigger the documented recovery path. Preserve the relevant binding table, switch logs, DHCP evidence, configuration version, and affected-port list before rollback. That evidence helps distinguish a missing legitimate binding from a forged source, capacity problem, or trust-boundary mistake and prevents the same outage in the next segment.

Factual boundary: RFC 7513 defines a DHCP-based SAVI solution, not a universal configuration for every switch, address-assignment method, or IPv6 environment. Vendor features may implement related concepts differently. Confirm platform support, scale, failure behavior, and interoperability before enforcement.

Measure covered access ports, valid binding rate, unknown static devices, trusted-port count, binding exhaustion, legitimate blocks, exception age, and recovery time after restart or failover. The goal is not to enable every first-hop feature at once. It is to make spoofing materially harder while keeping legitimate addressing predictable and recoverable.

Official references

• IETF, Source Address Validation Improvement (SAVI) Solution for DHCP, RFC 7513.
• IETF, Source Address Validation Improvement (SAVI) Threat Scope, RFC 6959.
• Cisco, Dynamic ARP Inspection.