# DHCP Snooping
DHCP snooping is a Layer 2 switch security control that intercepts, inspects, and filters DHCP traffic between clients and servers before any IP address assignment completes. It exists because DHCP, by design, is an unauthenticated protocol: any device on a broadcast domain can respond to a DHCP discovery message and assign itself as the authoritative server. This design flaw makes networks inherently vulnerable to rogue server injection, address exhaustion attacks, and the downstream spoofing that follows from illegitimate address assignments. DHCP snooping corrects this gap by enforcing trust boundaries at the port level, building a verified mapping of MAC addresses to IP addresses, and feeding that mapping into dependent controls that protect Layer 2 traffic integrity across the enterprise.
---
DHCP snooping is a switch-resident security feature that operates at Layer 2 of the OSI model to prevent DHCP-based attacks and establish authoritative MAC-to-IP bindings for downstream security controls. The feature works by classifying switch ports as either trusted or untrusted, then applying filtering rules that prevent untrusted ports from injecting DHCP server responses while allowing legitimate server traffic to flow through trusted ports.
The control addresses a fundamental vulnerability in the DHCP protocol itself. DHCP operates without authentication mechanisms, meaning any device can claim to be a DHCP server and respond to client requests. When multiple DHCP servers exist on the same network segment, clients typically accept the first valid response they receive, regardless of whether that response comes from the legitimate server or a rogue device controlled by an attacker. DHCP snooping prevents this scenario by ensuring that only ports connected to legitimate DHCP servers can send server-type DHCP messages.
Beyond preventing rogue DHCP servers, snooping builds a binding table that records which MAC addresses have been assigned which IP addresses on which switch ports. This binding table becomes the foundation for two additional Layer 2 security controls: Dynamic ARP Inspection (DAI) and IP Source Guard. Without an accurate snooping binding table populated with legitimate DHCP transactions, neither DAI nor IP Source Guard can function effectively.
DHCP snooping is not equivalent to 802.1X port authentication, which validates device identity before granting network access. Snooping operates after a device is connected and focused specifically on the integrity of address assignment. It is also distinct from Layer 3 firewalling, as it does not inspect IP packet contents or make routing decisions. The control operates exclusively on DHCP protocol messages within the broadcast domain of a VLAN.
---
DHCP snooping operates through five interconnected mechanisms: port trust classification, message type filtering, client identifier validation, binding table construction, and rate limiting. Each mechanism serves a specific security purpose and must be configured correctly for the overall control to function.
Port Trust Classification
Every switch port participating in a VLAN where DHCP snooping is enabled receives an explicit trust classification. Ports are either trusted or untrusted, with all ports defaulting to untrusted status when snooping is first enabled. Trusted ports are allowed to forward all DHCP message types, including server responses such as DHCPOFFER, DHCPACK, and DHCPNAK. Untrusted ports are restricted from sending these server-originated message types toward the network.
The trust classification must align with physical network topology. Uplink ports connecting access switches to distribution or core switches must be configured as trusted, as legitimate DHCP server responses will arrive through these ports. Ports directly connected to DHCP servers must also be trusted. Access ports connecting to end-user devices, workstations, printers, and IoT devices should remain untrusted, as these devices should never function as DHCP servers.
A common deployment error occurs when administrators enable DHCP snooping globally without first identifying and configuring trusted ports. This causes the switch to drop legitimate DHCP server responses, preventing any device on the VLAN from obtaining IP addresses until the configuration is corrected.
Message Type Filtering
On untrusted ports, DHCP snooping applies strict filtering to incoming DHCP messages. Any message with a DHCP message type indicating a server response (DHCPOFFER, DHCPACK, DHCPNAK) is immediately dropped. These message types should only originate from legitimate DHCP servers, which should be reachable through trusted ports, not connected directly to untrusted access ports.
The filtering operates at the application layer within the DHCP payload, not merely on UDP port numbers. This prevents an attacker from bypassing the control by crafting server-type DHCP messages on non-standard ports or with modified packet structures.
Client Identifier Validation
DHCP snooping performs additional validation on DHCP messages from untrusted ports by comparing the client hardware address (CHADDR) field within the DHCP payload against the source MAC address in the Ethernet frame header. If these addresses do not match, the message is dropped. This prevents a class of attack where a malicious device attempts to request IP addresses on behalf of other clients by spoofing client identifiers while using its own MAC address at the frame level.
Some platforms extend this validation to DHCP release and decline messages, verifying that the device attempting to release an IP address actually holds a valid binding for that address in the snooping database.
Binding Table Construction
As legitimate DHCP transactions complete successfully on untrusted ports, the snooping process creates binding entries that record the relationship between MAC addresses, assigned IP addresses, VLAN identifiers, physical switch ports, and lease expiration times. Each successful DHCP transaction that results in an address assignment generates or updates a binding entry.
The binding table is stored in switch memory and can optionally be persisted to local flash storage or a remote TFTP server to survive switch reboots. Without persistence, a switch restart clears the binding table, which can cause dependent controls like Dynamic ARP Inspection to drop traffic from hosts with existing DHCP leases until those hosts renew their addresses and repopulate the binding table.
Consider a practical example: a laptop connected to port GigabitEthernet 0/15 in VLAN 200 initiates a DHCP discovery. The switch forwards the DHCPDISCOVER message through its trusted uplink port toward the DHCP server. The server responds with a DHCPOFFER, which arrives at the trusted uplink and is forwarded to the laptop on port Gi0/15. The laptop sends a DHCPREQUEST, and the server responds with a DHCPACK confirming the address assignment. At this point, DHCP snooping creates a binding entry: MAC address 00:1B:2C:3D:4E:5F, IP address 192.168.200.45, VLAN 200, port Gi0/15, lease expiration in 24 hours.
Rate Limiting
To prevent DHCP starvation attacks, snooping implements configurable rate limiting on untrusted ports. Rate limits typically range from 10 to 20 DHCP packets per second. When a port exceeds this threshold, it enters an error-disabled state, effectively shutting down the port until administrative intervention occurs or an automatic recovery timer expires.
DHCP starvation attacks work by flooding a network with DHCP discovery messages using randomized source MAC addresses, attempting to exhaust the available address pool before legitimate clients can obtain addresses. Rate limiting stops this attack by detecting the abnormal volume of DHCP traffic and isolating the attacking port.
Rate limit configuration requires balance. Setting the limit too low can cause legitimate ports to be error-disabled during normal network events such as mass DHCP renewals after a power outage. Setting the limit too high may allow starvation attacks to succeed before the rate limit triggers.
Option 82 Relay Agent Information
Many DHCP snooping implementations automatically insert DHCP Option 82 (Relay Agent Information) into client DHCP requests before forwarding them toward the server. Option 82 includes circuit ID and remote ID fields that identify the specific switch and port from which the request originated, allowing DHCP servers to make policy decisions based on client location.
However, DHCP servers must be configured to accept Option 82 information from the switch. If the server is not configured to handle Option 82, it may reject requests that contain this information, preventing address assignments. Administrators must coordinate DHCP server configuration with switch configuration when enabling snooping, or disable Option 82 insertion if the server cannot support it.
---
DHCP-based attacks represent one of the most accessible and effective methods for gaining unauthorized network access and establishing man-in-the-middle positions. The attack requires minimal technical skill and freely available tools, yet can compromise every device that receives a malicious IP address assignment.
Rogue DHCP server attacks work by racing against the legitimate server to respond to client discovery messages. When an attacker's response arrives first, the client accepts the rogue IP configuration, including attacker-controlled default gateway and DNS server addresses. This positions the attacker to intercept, modify, or redirect all traffic from the compromised client. The attack is particularly effective because it operates transparently to the end user, who sees a normal IP address assignment and functional network connectivity.
Tools for conducting DHCP attacks are readily available and require no specialized knowledge. Ettercap, Yersinia, and Metasploit modules can establish rogue DHCP servers with minimal configuration. More sophisticated tools can automate the entire process of DHCP spoofing, DNS redirection, and credential harvesting. Security researchers consistently document successful rogue DHCP attacks during penetration testing engagements, particularly in environments where DHCP snooping is not deployed.
DHCP starvation represents an equally serious threat vector. By exhausting the available IP address pool, attackers can prevent new devices from connecting to the network and force existing clients into renewal failures. This affects not only workstations and laptops, but also VoIP phones, wireless access points, network printers, building automation systems, and IoT devices that depend on DHCP for connectivity.
The business impact extends beyond the immediate network disruption. Organizations that experience DHCP starvation may see widespread productivity loss as employees cannot connect devices to the network. Voice communications may fail if VoIP phones cannot renew their addresses. Facility systems may lose connectivity, affecting lighting, HVAC, and security systems that rely on IP connectivity for management.
A persistent misconception treats DHCP attacks as low-severity because they operate at Layer 2 and are considered "internal" threats. This reasoning fails to account for several realities. First, internal threats represent a substantial portion of actual security incidents, whether from malicious insiders, compromised endpoints, or external attackers who have gained physical access. Second, DHCP compromise affects every subsequent security assumption. If an attacker controls IP address assignment, they can intercept authentication credentials, session tokens, and sensitive communications regardless of other security controls in place.
Organizations also incorrectly assume that DHCP attacks are only relevant in large enterprise environments with sophisticated threat actors. Small and medium-sized businesses using unmanaged switches or managed switches without properly configured security controls are often more vulnerable, not less. The attack surface is the same, but the defensive controls are typically weaker.
---
CDA positions DHCP snooping as a foundational requirement within the Secure Posture Hygiene (SPH) domain of the Planetary Defense Model. The SPH domain encompasses controls that maintain continuous integrity of basic network services and infrastructure components. Address assignment sits at the foundation of network operations, making its security non-negotiable rather than optional.
Under CDA's Autonomous Posture Command (APC) methodology, "Your posture adapts. Your hygiene never sleeps." DHCP snooping exemplifies the hygiene component of this approach. It is not a reactive control that responds to detected threats. It is a preventive structural control that operates continuously and autonomously every time a DHCP transaction occurs. APC categorizes such controls as infrastructure requirements that must be implemented correctly and maintained consistently across the entire environment.
The CDA operational approach extends beyond initial deployment to include continuous validation and monitoring. This includes automated configuration compliance monitoring that verifies DHCP snooping is enabled on all client-serving VLANs, that trusted port designations align with current network topology, that binding tables are being properly persisted, and that rate limiting is configured with appropriate thresholds. Many organizations treat DHCP snooping as a one-time configuration task completed during initial switch deployment. CDA treats it as an ongoing operational requirement that must be verified and maintained.
CDA also positions the DHCP snooping binding table as a live asset inventory data source. The binding table provides real-time MAC-to-IP-to-port mappings with timestamps, offering visibility into what devices are connected where throughout the network. When integrated with network monitoring platforms, binding table data can trigger alerts for unexpected device connections, devices appearing on ports previously associated with different equipment, or binding patterns that deviate from established baselines.
The CDA differentiation lies in operational specificity and continuous verification. Rather than general recommendations to "enable DHCP snooping," CDA defines exact configuration requirements: snooping enabled per VLAN with explicit VLAN identification, trusted ports documented and reviewed quarterly against physical topology changes, binding table persistence configured to a reliable storage location, rate limits set between 10 and 20 packets per second based on port function, and Option 82 behavior explicitly configured based on DHCP server capabilities.
This approach treats configuration ambiguity as a security failure. Foundational controls like DHCP snooping must be implemented with precision and maintained with discipline, as their failure undermines every security assumption built on top of them.
---
---
---