DHCP Message Validation

For messages received on trusted ports, no validation is performed. For messages received on untrusted ports, the following steps are taken:

1 DHCP messages normally exchanged from a DHCP server to a client are dropped. These messages are DHCPOFFER, DHCPACK, and DHCPNAK.

2 DHCP messages with a nonzero relay agent/gateway IP address (also called giaddr field) or Option 82 data are dropped.

3 DHCPRELEASE/DHCPDECLINE messages are verified against the binding-table entries to prevent a host from releasing/declining addresses leased to another host.

4 DHCPDISCOVER messages, where the source MAC address does not match the client Hardware Address field, are dropped. This helps to mitigate the DHCP exhaustion attack. This check is performed only if the DHCP snooping MAC address verification option is turned on.

The binding table contains records built from information gleaned through DHCP packets.

A record consists of an IP address, a MAC address, a VLAN, a port, and a lease time. The

IP address is the address assigned by the DHCP server; the MAC address is the host's MAC address; the VLAN and port fields identify the port to which the host is attached; and the lease time specifies the period of validity of the DHCP address assignment. The binding table is constructed as follows:

• Upon seeing a DHCPACK. Add a new binding entry, if one doesn't exist. This event happens when the DHCP server assigns a new IP address to a client.

• Upon seeing a DHCPNAK. Remove a binding entry if one exists. The server sends a DHCPNAK when a client attempts to reuse a previously allocated IP address, and the server finds that it is invalid. (This could potentially happen if the client has moved to a different subnet, for example.)

• Upon seeing a DHCPRELEASE. Remove an existing binding entry. The client decides to relinquish its IP address.

• Upon seeing a DHCPDECLINE. Remove an existing binding entry. The client finds out that the IP address assigned by the server is already being used by another client; therefore, it informs the server that the assignment is invalid.

The binding table is only maintained for untrusted ports.

NOTE It is possible to create manual static bindings for devices that do not use DHCP. Here is how to configure a static binding of MAC address 0000.0c00.40af to IP address 10.42.0.6 on the interface Gigabit Ethernet 1/1 with a pseudo-lease time of 1000 seconds:

IOS(conf) # ip dhcp snooping binding 0000.0c00.40af vlan 1 10.42.0.6 interface gi1/1 expiry 1000

Example 5-3 contains a show command that displays the binding table from a switch with DHCP snooping enabled.

Example 5-3 A DHCP Snooping Binding Table

Switch# show ip dhcp snooping binding

Example 5-3 contains a show command that displays the binding table from a switch with DHCP snooping enabled.

Example 5-3 A DHCP Snooping Binding Table

Switch# show ip dhcp snooping binding

MacAddress						IpAddress		Lease(sec)	Type	VLAN	Interface
00	30	94	C2	EF	35	41.0	0.51	286	dynamic	41	FastEthernet0/3
00	D0	B7	1B	35	DE	41.0	0.52	237	dynamic	41	FastEthernet0/3
00	00	00	00	00	01	40.0	0.46	286	dynamic	40	FastEthernet0/9
00	00	00	00	00	03	42.0	0.33	286	dynamic	42	FastEthernet0/9
00	00	00	00	00	02	41.0	0.53	286	dynamic	41	FastEthernet0/9

NOTE Chapter 6, "Exploiting IPv4 ARP," describes how the information contained in the DHCP snooping table is also used to defeat Address Resolution Protocol (ARP) attacks.

DHCP snooping can mitigate rogue server attacks by ensuring that all host ports are configured as untrusted by default. This makes it impossible to operate a DHCP server off such a port.

Continue reading here: DHCP Snooping with Option

Was this article helpful?

0 0