MAC Address Spoofing is a kind of Man-in-the-Middle Attack where attacker tries to redirect frames destined for authorized host to the attacker PC instead. To redirect traffic attacker needs to overwrite CAM table entry with actual true destination host’s MAC address. Be aware that is is not possible to have two the same MAC addresses in the CAM table on the switch, once switch detects this kind of strange behaviour will log the following error on the console:
*Mar 1 00:30:41: %SW_MATM-4-MACFLAP_NOTIF: Host 0000.1111.1111 in vlan 10 is flapping between port Fa0/1 and port Fa0/2

Another way to spoof MAC address is to use Address Resolution Protocol (ARP). When host sends a broadcast ARP request to figure out a MAC address of target host’s MAC address, target host response thru ARP reply.

Once the CAM table will be overwritten, packets to the true destination PC will be redirected to the attacker PC. If the true PC sends traffic once again CAM table will be rewritten again, moving the traffic back to the true PC’s port.

DHCP snooping feature is one of the method of mitigating IP Address Spoofing Attacks but with additional fetures like IP Source Guard and Dynamic ARP Inspection can fight with MAC Address Spoofing.

Using DHCP server attacker can prevent normal communications for the hosts or simply redirect the traffic to own PC. The plan is simple: connect DHCP server to the network and assign IP addresses to the clients without default gateway IP address what will successful prevent hosts to communicate with oustside world or just define default gateway’s or DNS server IP of hacker own PC. We can prevent this with DHCP Snooping. Here we are configuration step by step to configure the feature.

First we need to enable DHCP Snooping feature globally on the switch, next enable for specific VLAN, then configure trusted port where DHCP server will be connected or expected traffic from the DHCP server will be received like over trunk interfaces:
SW(config)#ip dhcp snooping
SW(config)#ip dhcp snooping vlan 10
SW(config)#int fa0/5
SW(config-if)#description DHCP-Server
SW(config-if)#ip dhcp snooping trust

Let’s see what we have configured already:

SW#sh ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10
DHCP snooping is operational on following VLANs:
10
DHCP snooping is configured on the following L3
Interfaces:Insertion of option 82 is enabled
circuit-id format: vlan-mod-port
remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:
Interface Trusted Rate limit (pps)
------------------------ ------- ----------------
FastEthernet0/5 yes unlimited

So we enable globaly and for VLAN 10 DHCP Snooping feature, additionaly we have configured Fa0/5 as trust interface, so DHCP server will be connected here. In case you will not trust any interface once switch gets DHCP Discover message it will drop the frame and log the following error on console:
*Mar 1 01:32:06: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (10)
*Mar 1 01:32:06: DHCP_SNOOPING_SW: bridge packet output port set is null, packet is dropped.

Let’s see what we have now on the switch, we will debug DHCP Snooping process with above configuration:
SW#debug ip dhcp snooping
*Mar 1 00:12:44: DHCP_SNOOPING: received new DHCP packet from input interface (FastEthernet0/1)
*Mar 1 00:12:44: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Fa0/1, MAC da: ffff.ffff.ffff, MAC sa: 0000.1111.1111, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0000.1111.1111
*Mar 1 00:12:44: DHCP_SNOOPING: add relay information option.
*Mar 1 00:12:44: DHCP_SNOOPING_SW: Encoding opt82 CID in vlan-mod-port format
*Mar 1 00:12:44: DHCP_SNOOPING_SW: Encoding opt82 RID in MAC address format
*Mar 1 00:12:44: DHCP_SNOOPING: binary dump of relay info option, length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0xA 0x0 0x0 0x2 0x8 0x0 0x6 0x0 0xB 0x5F 0x7E 0x7A 0x80
*Mar 1 00:12:44: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (10)
*Mar 1 00:12:44: DHCP_SNOOPING_SW: bridge packet send packet to port: FastEthernet0/5, vlan 10.
One important note, once you enabled IP DHCP Snooping feature Cisco switch by default add to the DHCP Discover packet DHCP Option 82 and is working as kind of relay agent, we can observe it on the console, the begining is DHCP_SNOOPING: add relay information option.
What exactly the 82 options is?
Options 82 has two suboptions: Remote-ID suboption is the switch’s MAC address and Circuit-ID suboption is the port identifier so exactly interface where client is connected to . The idea is simple, switch adds this option and thanks to this DHCP server assign proper IP address, so it’s a kind of client’s distinction mechanism. We can observe a related issue to this switch’s feature if we have DHCP server configured on the router:

R5-DHCP#debug ip dhcp server packet
*Mar 1 00:30:55.545: DHCPD: inconsistent relay information.
*Mar 1 00:30:55.545: DHCPD: relay information option exists, but giaddr is zero

So what exactly this error means? Router sees inconsistent information, why? What is exactly happening when relay agent like router with ip helper-address options gets DHCP Discover packet from the client and sends it forward to the DHCP server. We have to look in to the DHCP Discover packet. Router gets DHCP Discover (broadcast) from client and based on it generates new DHCP Discover (unicast) packets with LAN IP as source and DHCP Server IP as destiantion, additionaly modifies giaddr field known as Relay agent IP address in the BOOTP packet from 0.0.0.0 to own IP (the same like source IP = LAN IP). What about the switch? Problem is that switch by default adds kind of relay option to the packet but doesn’t change the giaddr field so routers treats it as inconsistent information and drops packet.

We have two options to work around this issue:
first one – disable adding of DHCP Option 82 on the switch:
SW(config)#no ip dhcp snooping information option
second one – allow DHCP server (on the router) receives DHCP packets that contain relay info option with zero giaddr:
R5-DHCP(config)#ip dhcp relay information trust-all

Let’s back to snooping. Switch watches two-way DHCP address allocation process and learns about IP address that has been assigned to the client, switch builds IP DHCP Snooping Binding table where adds MAC address of the client, IP that has been assigned by the server, lease time, vlan where clients resides and interface where is connected to:
SW#sh ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:00:11:11:11:11 10.0.1.1 83572 dhcp-snooping 10 FastEthernet0/1
Total number of bindings: 1

Based on the sh ip dhcp snooping output IP DHCP Snooping verify only the MAC address based on the binding table (Verification of hwaddr field is enabled). Really? What about Cisco Configuration Guide says:

„When a switch receives a packet on an untrusted interface and the interface belongs to a VLAN in which DHCP snooping is enabled, the switch compares the source MAC address and the DHCP client hardware address. If the addresses match (the default), the switch forwards the packet. If the addresses do not match, the switch drops the packet.”

I don’ agree with it. Let’s make a small test to proof it. We have two routers R1 and R3 connected to the same switch (second one is DHCP server that has assigned the IP address 10.0.1.1 to R1’s MAC: 00:00:00:11:11:11). We can ping R3 from R1:
R1#sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.0.1.1 YES DHCP up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
R1#
R1#ping 10.0.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms
good, is working fine as expected :), let disconnect the R1 from the switch and see how the binding table looks like:
SW#
*Mar 1 01:37:50: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
SW#sh ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:00:11:11:11:11 10.0.1.1 86290 dhcp-snooping 10 FastEthernet0/1
Total number of bindings: 1
nothing changed, switch remembers binding even if we disconnected R1, nice. So lets connect the R1 back but before we do it we change R1’s IP to 10.0.1.2, then we ping R3 again:
R1(config-if)#int fa0/0
R1(config-if)#ip add 10.0.1.2 255.255.255.0
R1#ping 10.0.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

no issue with ping, working fine even if we have changed IP, so let’s changed the MAC now to different one for example 00:00:00:22:22:22

R1(config)#int fa0/0
R1(config-if)#mac-address 0000.2222.2222
R1#ping 10.0.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms LOL, we can still ping even if we have changed IP and MAC. So where is a issue. As we have see in the simplest form DHCP Snooping just filter unwanted DHCP Offer packets, to let the switch filter traffic based on the MAC or IP that’s resides in the DHCP Snooping binding table we have to employ other fetures like IP Source Guard (to filter based on the IP) or IP Source Guard with Port Security to filter based on the MAC and IP. We will discusse about it in one of the future post.