Rogue Servers and Snooping

## What the client asks, and who can answer A DHCPv4 client with no address starts in the **INIT** state and broadcasts a `DHCPDISCOVER` from source `0.0.0.0` to `255.255.255.255`. A broadcast reaches every port in the VLAN, so the production server (or the relay agent forwarding to it) and a test server someone plugged into a spare access port both hear it. RFC 2131 says each server "may respond" with a `DHCPOFFER`, and that the client "may choose to wait for multiple responses" and pick one. Many client implementations simply take the first acceptable offer, so the outcome is a race: a test server on the same switch, one hop away and idle, often answers before a production server reached through a relay agent. ## What an offer hands the client An offer is not just an address. Its fields and options set the host's whole view of the network: | Field or option | What the client does with it | What a wrong value causes | |---|---|---| | `yiaddr` | Uses it as its IPv4 address | A lab range with no route out, or a duplicate of a production address | | Option 1, subnet mask | Decides which destinations are on-link | Local peers sent to a router, or remote ones treated as local | | Option 3, router | Installs it as the default gateway | Every off-subnet packet goes to whatever host the offer names | | Option 6, domain name server | Sends DNS queries there | Names resolve to whatever that resolver answers | | Option 51, lease time | Sets the lease length, and with it T1 and T2 | A long lease keeps the bad configuration for days | | Option 54, server identifier | Records which server to renew with | Renewals go back to the test server, not to production | RFC 2131 section 7 lists these outcomes as the protocol's known exposure: unauthorized servers can send "incorrect or duplicate IP addresses, incorrect routing information (including spoof routers, etc.), incorrect domain nameserver addresses". An accidental test server usually breaks connectivity loudly. A deliberate one names a gateway and resolver it controls, so traffic keeps flowing — through it. ## Why the wrong lease persists Unplugging the box does not fix the hosts at once, because the lease lives on the clients: 1. **Renewing.** At T1 (by default half the lease) the client unicasts a `DHCPREQUEST` to the address in its `server identifier` — the test server. While that server answers, the lease is extended and production never sees the client. 2. **Rebinding.** Only if renewal gets no answer does the client, at T2 (by default 0.875 of the lease), broadcast its `DHCPREQUEST`; any server may answer, including the test server. 3. **Rebooting.** A client that restarts with a cached lease enters **INIT-REBOOT** and broadcasts a `DHCPREQUEST` naming its old address. RFC 2131 says a server that finds the client on the wrong network SHOULD send `DHCPNAK`, but a server with no record of the client "MUST remain silent". If the test server handed out production-subnet addresses, the production server stays silent and the test server's `DHCPACK` is the only reply. 4. **Expiry.** The client returns to INIT when the lease expires or a `DHCPNAK` sends it there — and the race starts again. ## Why DHCPv4 cannot tell the servers apart Nothing in an offer proves who sent it. The `server identifier` is an IPv4 address the server chose for itself, the options carry no signature, and the message rides plain UDP from port 67 to port 68. RFC 2131 states that "DHCP in its current form is quite insecure", because configuring hosts "with passwords or keys may be difficult and inconvenient". RFC 3046 repeats that DHCP "provides no authentication or security mechanisms". A client therefore has no protocol-level way to prefer the production server; the defence has to live in the network that carries the offer. ## Accident or attack: the same mechanics - A **test server or spare home router** plugged in by mistake usually offers its own private range and gateway, so hosts lose the network — a burst of "no connectivity" tickets from one VLAN. - A **deliberate rogue** offers plausible values: an address on the right subnet, plus a router and DNS server it controls. Hosts look healthy while their traffic passes through it. It may drain the real pool first, so its offer is the only one. - **Detection** comes from the clients: a lease showing an unexpected `server identifier`, duplicate-address complaints, or a switch counting server messages on an access port. - **Prevention** sits in the switch: **DHCP snooping**, a vendor feature with no RFC, drops server messages that arrive on access ports. The IETF's counterparts are DHCPv6-Shield (RFC 7610) and SAVI-DHCP (RFC 7513).