Here are three features that are often not implemented in most networks but could help to really address security shortcomings and potential operational issues.
I’ve recently started implementing DHCP Snooping, Dynamic ARP Inspection and IP Source Guard in my networks so I thought I’d take the time to strike up a conversation around those features and hear what everyone else is doing.
These features are all intended to provide a more stable network environment and help protect against intentional and unintentional events that can interfere with the proper operation of the network. Before we can implement any of these features we need to understand how they work and what changes (if any) will be needed to support them.
Hopefully most people have Spanning Tree, FastStart, BPDU filtering (guard) and Broadcast/Multicast rate limiting enabled by now but if you don’t you should certainly look at enabling and configuring those features before you start to try any of the ones I’m about to discuss.
The sample configuration code provided below is applicable for Avaya Ethernet Routing Switches.
DHCP Snooping
Dynamic Host Configuration Protocol (DHCP) snooping provides security to the network by preventing DHCP spoofing. DHCP spoofing refers to an attacker’s ability to respond to DHCP requests with false IP information. DHCP snooping acts like a firewall between untrusted hosts and the DHCP servers, so that DHCP spoofing cannot occur. There are 2 types of ports in DHCP snooping, trusted and untrusted. The network will only allow DHCP responses from trusted ports – usually uplinks as opposed to allowing DHCP responses from untrusted ports – usually edge switch ports.
Example, if someone brings a Linksys router into the office and connects the LAN side to your network the Linksys router will start handing out 192.168.1.x IP DHCP addresses which will likely cause some chaos. DHCP Snooping will prevent those DHCP responses from poisoning your network. I’m happy to admit that this is happened to me on more than one occasion, usually at our remote finance office where auditors think their second job could be in Information Technology.
DHCP Option 82 – With DHCP Option 82 the switch will append additional information to the DHCP request which can be stored in your IPAM (IP Address Management) solution to help identify the switch and port from which the request was initiated. This can provide diagnostic and troubleshooting information which can all be stored directly in your IPAM if it supports DHCP Option 82. Infoblox supports DHCP Option 82.
The latest software releases support the ability to copy the DHCP binding table up to a TFTP server. This prevents the switch from throwing away all the previously learned DHCP transactions between reboots or restarts of the switch.
In this example our uplinks are 1/24 and 2/24, all interfaces are untrusted by default.
ip dhcp-snooping vlan 10 ip dhcp-snooping vlan 11 ip dhcp-snooping enable interface fa 1/24,2/24 ip dhcp-snooping trusted exit
If you want to enable DHCP Option 82 support;
ip dhcp-relay option82 interface vlan 10 ip dhcp-relay option82 interface vlan 11 ip dhcp-relay option82
You can also edit the text string the switch will append per port with the following;
interface FastEthernet 1 ip dhcp-relay option82-subscriber-id <string 1..255>
Issues with DHCP Snooping
While you need to properly identify trusted and untrusted ports there are very few draw backs to utilizing DHCP snooping. It only prevents DHCP replies from untrusted ports essentially preventing DHCP spoofing in the network. DHCP Snooping can be enabled in most networks with a few configuration changes and very little danger (impact).
Dynamic ARP Inspection
Dynamic Address Resolution Protocol (Dynamic ARP) inspection is a security feature that validates ARP packets in the network.
Without dynamic ARP inspection, a malicious user can attack hosts, switches, and routers connected to the Layer 2 network by poisoning the ARP caches of systems connected to the subnet and by intercepting traffic intended for other hosts on the subnet. Dynamic ARP inspection prevents this type of attack. It intercepts, logs, and discards ARP packets with invalid IP-to-MAC address bindings.
The address binding table is dynamically built from information gathered in the DHCP request and reply when DHCP snooping is enabled. The MAC address from the DHCP request is paired with the IP address from the DHCP reply to create an entry in the DHCP binding table.
When you enable Dynamic ARP inspection, ARP packets on untrusted ports are filtered based on the source MAC and IP addresses stored in the DHCP snooping table. The switch forwards an ARP packet when the source MAC and IP address matches an entry in the DHCP snooping table. Otherwise, the ARP packet is dropped.
For dynamic ARP inspection to function, DHCP snooping must be globally enabled. Dynamic ARP inspection is configured on a VLAN to VLAN basis.
Let’s enable Dynamic ARP Inspection on VLANs 10, 11 and set our uplinks as trusted;
ip arp-inspection vlan 10 ip arp-inspection vlan 11 ip arp-inspection enable interface fa 1/24,2/24 ip arp-inspection trusted exit interface fa 1/1-23,2/1-23 ip arp-inspection untrusted exit
Issues with Dynamic ARP Inspection
Dynamic ARP Inspection relies on the information stored in the DHCP binding table (from DHCP Snooping) to validate the ARP packets it receives on untrusted ports. Any device whether it be statically configured or dynamically configured would need to appear in the DHCP binding table.
If you have a statically configured device you’ll need to manually populate the DHCP snooping table. If someone changed out a statically configured device the MAC address would most likely need to be updated in the DHCP binding table. If the DHCP binding table was accidentally cleared the switch would block IP traffic until the DHCP binding table was re-built either manually or from DHCP transactions.
This is another great reason to use manual or reserved DHCP assignments where possible if the device requires a persistent IP address.
This feature will likely create some significant administrative overhead based on the number of devices configured with a static IP address over the number of DHCP configured devices.
IP Source Guard
IP Source Guard provides security to the network by filtering clients with invalid or spoofed IP addresses. IP Source Guard is a Layer 2 (L2), port-to-port feature that works closely with information in the Dynamic Host Control Protocol (DHCP) snooping binding table. When you enable IP Source Guard on an untrusted port with DHCP snooping enabled, an IP filter entry is created or deleted for that port automatically, based on IP information stored in the corresponding DHCP binding table entry. When a connecting client receives a valid IP address from the DHCP server, a filter is installed on the port to allow traffic only from the assigned IP address. A maximum of 10 IP addresses are allowed on each IP Source Guard-enabled port. When this number is reached, no more filters are set up and traffic is dropped.
While Dynamic ARP Inspection blocks only ARP packets, IP Source Guard blocks all IP packets.
interface fa 1/1-23,2/1-23 ip verify source exit
Issues with IP Source Guard
IP Source Guard utilizes the information stored in the DHCP binding table (from DHCP Snooping) to validate the IP traffic. Any device whether it be statically configured or dynamically configured would need to appear in the DHCP binding table. Statically configured devices would need to be manually placed in the DHCP binding table. If someone changed out a device the MAC address would most likely need to be updated in the DHCP binding table. If the DHCP binding table was accidentally cleared the switch would block IP traffic until the DHCP binding table was re-built either manually or from DHCP transactions.
This feature will likely create some significant administrative overhead based on the number of devices configured with a static IP address over the number of DHCP configured devices.
My Thoughts
I’m taking a split approach right now, let me explain. I’ll be utilizing DHCP snooping and DHCP Option 82 throughout my network. Unfortunately due to the administrative overhead required to leverage Dynamic ARP Inspection and IP Source Guard I’m only planning on implementing those features at my smaller remote offices – the ones I usually have issues with from a security perspective. Since those remote offices are much smaller and usually don’t make too many changes it offers me the opportunity to evaluate the new features without over taxing my network administrators and engineers.
Cheers!
Frank says
We are in the process of rolling out these features across all of our edge ports, as hardware refreshes allow it. It’s already cut down on impact from various broken/misconfigured, especially in residential buildings.
One more note to add – don’t forget to pester your vendors, whoever they may be to get full feature parity in the IPv6 space. We need RA guard and NDP inspection, or we’re going to have the same old problem re-appearing as soon as we roll out v6!
Michael McNamara says
Thanks for the comment Frank!
I don’t think we’ll be deploying IPv6 on the internal production network anytime soon. We have plans to offer IPv6 on our Internet accessible networks and on our DMZ networks but no real need for IPv6 on the actual internal network. I can’t imagine the stares I’ll get from all the healthcare vendors regarding IPv6, they probably don’t even have IPv6 on their product or support roadmaps.
These features make a great argument for doing manual (reserved) DHCP IP address assignments for almost everything (if possible). The more devices using DHCP the less administrative overhead you’ll need to content with in managing the DHCP snooping tables. I believe the DHCP snooping table has a limit of 1024 records as of 6.2 software for the Ethernet Routing Switch 5000 series so you can’t really implement a single network wide table.
Cheers!
It might be w
Cheers!
Will says
Michael,
This post was excellent. Thanks a lot.
I remember when a peer turned on arp inspection (to try and fix a broadcast storm) and took down the entire network. i.e. – do not enable any of the above unless you understand the impact
Michael McNamara says
Hi Will,
As you alluded to these features require some thought and evaluation before deploying. I will raise this point as well, if you want to move a port to a different you need to disable IP Source Guard before you can change the VLAN assignment.
Thanks for the comment!
IJdod says
Interesting post, thank you.
Does the vlan interface actually have to do the routing for the vlan to be able to use option 82? In other words: does it work with a router upstream (which does the actual DHCP relay for that vlan as well) from the access switch?
Michael McNamara says
Hi IJdo,
I believe DHCP Option 82 will work regardless if the switch is configured as a Layer 3 router or just a Layer 2 access/edge switch.
Cheers!
IJdod says
Cheers. Something I’ll have to test in the lab, then. I would suspect it works, otherwise there wouldn’t be much point to it… Would have been nice if Avaya documented that bit just a little bit better :D.
karky says
About Dynamic ARP Inspection, you can use DHCP Snooping External Save. Every 5 minutes the table is saved on a tftp server. If the stack reboot, the table is loaded.
Ricardo Meireles says
Is DHCP-Snooping/DAI compatible with 802.1x?
I’m seeting up these features together with some issues
Michael McNamara says
Hi Ricardo,
I haven’t used the combination myself personally… I would think 802.1x occurs well before any DHCP requests.
What exactly are you seeing?
Cheers!
Ricardo Meireles says
Hello Micheal,
When I set up DHCP-Snooping/DAI, 802.1x stop working without warning exactlly on the switch used for testing purposes. It turns out to be a coincidence. I’ve just upgraded the switch and now both features are working well.
Fabien B. says
Hello,
I’m currently trying to implement DHCP snoop and ARP inspection on a 4500 with L3 (RIP, dhcp-relay), and my IP phones can get an IP address, but are not entered in DHCP Snooping binding table, and then doesn’t work…
We already implemented those protocols on 4500 with only L2 protocols, and there’s no problem…
Do you have an idea ?
Fabien.
Michael McNamara says
Hi Fabien,
What version of software?
I haven’t tested it myself in a L3 configuration, wondering if you’ve stumbled across a bug.
Cheers!
Fabien B. says
Hi Michael,
Thanks fot the quick answer.
Software version is 5.6.0008, and since it’s a test configuration, I can’t really make update, since it’s supposed to be the same configuration as production switches…
I’ll try a more recent software to see if it’s a bug, and I’ll let you know.
Rafi says
Hi Michael,
I tried to add dhcp snooping on nortel 8300 version 4.2.2.
Aftet i enabled it clients couldent get ip
This is how i enabled the dhcp snooping
– Enable in global
-Enable on specipic
– change the switch port of dhcp server
To trust (true)
Any idea ?
Michael McNamara says
Hi Rafi,
That’s a really hold piece of hardware with some really old software you have there.
Is the DHCP server seeing the DHCP discover requests? Is this all Layer 2 or do you have DHCP relay enabled?
Good Luck!
Rafi says
Hi Michael,
Yes it’s really old :(
I don’t own the dhcp so i don’t know if the server sees the massage “discover”. (i can ask the it guy to give me access)
It’s L2 the client is broadcasting to the dhcp server.
Regards
Rafi
Rafi says
Hi,
I checked it again this time include Dhcp server and after i chcked it i realized that i IT gave me the wrong port.
Fixed it all works well.
Thanks
Rafi