In DHCP snooping, which port do you trust, and does a wrong choice free a rogue or starve the rack?

## What "trusted" actually means DHCP snooping is a switch function that watches DHCP exchanges crossing the switch and writes down what it learns. Every port carries one of two roles. - **Untrusted**: the switch forwards client-sourced messages (a host asking for an address) but discards server-sourced messages — offers and acknowledgements. A host plugged into an untrusted port can ask for a lease, and it can never answer someone else's request. - **Trusted**: everything passes, and what the switch observes there is treated as authoritative. Trust is therefore a claim about a *direction in the topology* — "the real DHCP server is that way", or "that link goes to another switch that is already doing this job". It is not a claim that the device on the far end is well behaved, and reading it that way is the classic first mistake. ## What the switch builds from it As the real server hands out addresses, the switch records a **binding**: client MAC, assigned IP, VLAN, ingress interface, and the remaining lease. Those bindings are the only ground truth the switch has about which address legitimately lives behind which port, and two controls read them: - **Dynamic ARP inspection** examines ARP frames on untrusted ports and discards any whose sender MAC/IP pair has no matching binding. - **IP source guard** filters forwarded IP traffic whose source address does not match a binding on that port. Both are designed to skip trusted ports. That is the detail that makes trust placement a security decision rather than a plumbing one: a trusted port is exempt from the checks as well as from the filtering. ## The adversary this is aimed at One host on the segment, with nothing more than a live port, doing either of two things: answering ARP for the default gateway's address so traffic leaving the subnet passes through it first, or offering leases that name itself as gateway and resolver. Snooping plus binding-table validation is the counter — untrusted ports may ask, never answer, and may only use the address they were actually given. ## The two symmetric mistakes | Mistake | Who pays | What you see | | --- | --- | --- | | An access port marked trusted | everyone on that segment | rogue offers and gateway claims pass unchallenged, and the control's counters stay clean because nothing was ever evaluated | | The path to the real server left untrusted | the whole rack | genuine offers dropped, no host renews, and off-subnet reachability dies gradually as leases expire rather than all at once | The second failure is the reason first-hop deployments get rolled back. It is not loud at the moment of the change; it appears at the first renewal, which for most clients is halfway through the lease, so the change looks successful for hours before the rack begins to fall off. ## Where it gets hard in a data-centre fabric Two populations complicate the tidy picture. A **top-of-rack uplink carrying a hypervisor link** aggregates many guests behind one physical port. Trusting it is tempting because it makes the deployment stop breaking things, but it exempts every guest behind that link from validation: a compromised guest can then claim the gateway for the whole segment, which is precisely the attack the deployment exists to stop. The honest shape is to trust only the path to the server, keep the guest-bearing link untrusted, and accept that each guest must either lease through the switch or carry a binding. **Statically addressed appliances** — storage controllers, out-of-band management interfaces — never ask for a lease, so no binding is ever learned for them. They are not solved by trust placement at all; they need static bindings entered by hand, or they will be dropped the moment validation stops logging and starts discarding. ## What a good answer contains Say that trust points toward the server; that untrusted means "may request, may not answer"; that the table built from those exchanges is what later validation compares against; and that both directions of error are real — a wrongly trusted access port silently voids the control, while a wrongly untrusted server path starves the segment. Naming the aggregating uplink as the place the temptation to over-trust actually appears is what separates a memorised answer from an operational one.