Source Address Validation Improvement (SAVI) Solution for DHCP
Extracted elements (28)
The Data Snooping Process triggers probabilistically, not deterministically, on unmatched data packets. This design limits exposure to DoS attacks in which an attacker sends large numbers of packets with forged source addresses to exhaust the BST.
The DHCP Snooping Process requires the SAVI device to be the cut vertex separating the DHCP client from all DHCP servers/relays. When multiple paths exist or topology is dynamic (including local-link client movement), snooping may miss the DHCP exchange, motivating the complementary Data Snooping Process.
The Identity Association (IA) is not stored in the BST for three reasons: each address within an IA has its lease assigned separately; when a binding is set up via data snooping the IA cannot be recovered from leasequery; and DHCPv4 does not define an IA concept.
The SAVI perimeter is designed primarily for scalability: each SAVI device only establishes bindings for directly or indirectly attached clients and only validates source addresses on traffic from those clients, rather than checking all traffic passing through the network.
Trusted DHCP servers and relays must be placed inside the SAVI perimeter because SAVI-DHCP cannot distinguish a legitimate DHCP server outside the perimeter from a bogus one. A valid server outside the perimeter will have its Server-to-Client messages dropped just like those from an attacker.
SAVI-DHCP applies only to stateful DHCP (RFC 2131, RFC 3315). For hosts using SLAAC, FCFS SAVI (RFC 6620) must be used instead. SAVI-DHCP does not block link-local addresses as they are not DHCP-assigned; a complementary SAVI solution for link-local addresses (e.g., FCFS SAVI) is RECOMMENDED.
SAVI-DHCP must be considered in the context of Detecting Network Attachment (DNA). When a client detaches and reattaches using a Confirm message rather than a full DHCP exchange, the binding may need to be re-established via the INIT_BIND state and a subsequent LEASEQUERY, requiring coordination with DNA procedures.
A DHCP message that does not trigger a valid event (e.g., fails attribute, TID, or binding anchor checks) MUST still be forwarded if it passes the control packet filtering checks in Section 8.2. The binding state does not change in this case.
A SAVI device MUST store the list of DHCP server addresses it could contact during a leasequery process. It may also require preconfigured security keys for establishing secure leasequery connections per RFC 4388 and RFC 5007.
A SAVI device MUST use a non-spoofable and exclusive binding anchor. Using a spoofable anchor (e.g., a plain MAC address) or a non-exclusive anchor (e.g., a port shared via a non-SAVI device) can lead to worse outcomes than allowing spoofed IP traffic.
For DHCPv4, the SAVI device MUST have an IPv4 address. For DHCPv6, the SAVI device MUST have a link-local address, and when the DHCPv6 server is not on the same link, MUST also have an IPv6 address of at least the same scope as the server.
If a DHCP or data message would trigger creation of a new binding entry, the binding entry limit on the binding anchor MUST NOT be exceeded. This prevents malicious or malfunctioning nodes from overloading the BST.
Implementation of the Data Snooping Process is OPTIONAL. It SHOULD be enabled unless the deployment is known to lack multi-path or dynamic-topology exceptions (e.g., a pure tree topology with no host local-link movement).
In the Data Snooping Process, address conflicts MUST be detected and prevented before a binding is established from an unmatched data packet. A Duplicate Address Detection message (ARP Request/Probe or DAD NS) is sent; a reply from any other port indicates a conflict and the entry is discarded.
Mutually exclusive attributes MUST NOT be set TRUE on the same attachment point. Trust is mutually exclusive with DHCP-Snooping, Data-Snooping, and Validating; all other pairwise combinations are compatible.
The interval between two successive EVE_DATA_UNMATCH events triggered from the same attachment MUST be no smaller than DATA_SNOOPING_INTERVAL. This rate-limits data-triggered binding initiation to mitigate DoS attacks.
When a DHCPv6 Reply in response to a Confirm message contains no lease time, the SAVI device SHOULD send a LEASEQUERY message to retrieve it. If LEASEQUERY is not sent, a preconfigured DHCP_DEFAULT_LEASE MUST be set on the corresponding binding entry; using T1 from DHCP servers is RECOMMENDED.
SAVI-DHCP maintains a persistent mapping between IP addresses and binding anchors (which may include MAC addresses and physical port identifiers), enabling fine-grained tracking of device location and network activity. This information could facilitate surveillance and should be treated as sensitive.
Five configurable per-attachment attributes govern SAVI-DHCP behavior: Trust (bypass all validation), DHCP-Trust (permit Server-to-Client messages), DHCP-Snooping (trigger binding setup from DHCP messages), Data-Snooping (allow data-triggered binding), and Validating (enforce source address validation against the BST).
The Binding State Table (BST) stores bindings between DHCP-assigned IP addresses and binding anchors. Each entry has six fields: Binding Anchor, IP Address, State, Lifetime (remaining seconds or expiry timestamp), Transaction ID (TID), and Timeouts (used only by the Data Snooping Process).
The SAVI-DHCP perimeter separates trusted (inside) from untrusted (outside) regions. DHCP-Trust is only set inside the perimeter; DHCP Server-to-Client messages arriving from outside are dropped. DHCP servers and relays must reside inside the perimeter to be reachable by the snooping process.
Each binding anchor MUST have a binding entry limit enforced. Without this limit, a malicious or malfunctioning node could create an unbounded number of binding entries, exhausting the BST and denying service to other clients on the SAVI device.
Fragmented DHCP messages pose a risk: a SAVI device may be unable to inspect the full message payload in a fragment, allowing an attacker to bypass DHCP snooping checks by deliberately fragmenting DHCP packets. Implementations should handle or drop fragmented DHCP messages appropriately.
Leasequery operations used by the Data Snooping Process should be secured. RFC 4388 and RFC 5007 mechanisms allow preconfigured keys to protect these exchanges; without security, a compromised DHCP server or man-in-the-middle could return false lease information and cause incorrect bindings.
The Data Snooping Process is inherently less secure than the DHCP Snooping Process because it relies on ARP/NS and leasequery rather than direct observation of DHCP exchanges. A sophisticated attacker who can suppress leasequery responses or forge ARP replies may be able to establish false bindings.
When a client departs without sending a DHCP Release message, its binding remains in the BST until lease expiry. During this window a different client may be assigned the same address by DHCP, causing valid traffic from the new client to be dropped until the stale binding expires.
The Data Snooping Process adds three states beyond the DHCP Snooping states: DETECTION (ARP/NS duplicate address detection in progress), RECOVERY (DHCP Leasequery in progress to confirm address assignment), and VERIFY (verifying that the attached device's hardware address matches the leasequery response). EVE_DATA_UNMATCH triggers entry from NO_BIND into DETECTION or RECOVERY.
The DHCP Snooping Process uses three states: NO_BIND, INIT_BIND, and BOUND. Transitions are: NO_BIND → INIT_BIND on Request/Confirm/Reboot/Solicit_RC; INIT_BIND → BOUND on ACK/Reply (success); BOUND → NO_BIND on Release, Decline, or entry expiry. BOUND → BOUND on Renew/Rebind/Reply/Leasequery-Reply updates the lifetime.