DHCP snooping

A switch feature that only allows address-assignment replies from ports you have declared trustworthy.

It exists because DHCP has no authentication: any device on the segment can answer, and a client may simply take the first offer it hears. A rogue server can hand out its own address as the gateway and quietly become the path for everything. Trusting only the ports that lead to real servers removes that whole class of attack.

Snooping divides a switch's ports into trusted and untrusted. Server messages such as DHCPOFFER are forwarded only from trusted ports and dropped on untrusted ones, so a rogue server on an access port reaches nobody. On Juniper switches it is off by default; once enabled, trunk ports are trusted and access ports untrusted unless configured otherwise. RFC 7513 states the same rule for source address validation: server-to-client messages from attachments without the DHCP-Trust attribute MUST be discarded, and that attribute is false by default.

While it watches, the switch builds a binding table from the lease information in the server's replies and deletes each entry when its lease expires. The server messages it logs from untrusted ports are a way to find a rogue server.

The threat is documented. In 2008 a malware variant ran a DHCP server on infected PCs that answered every discover with its own offer, racing the legitimate server; a 2009 variant existed to spread a bad DNS server address. Starvation, a flood of requests from spoofed MAC addresses that empties the pool, needs another control: a limit on MAC addresses per port.

Also known as: trusted port, dhcp binding table, untrusted port

Sources

← All glossary entries