Chapter 8. DHCP Snooping and ARP Inspection
This chapter covers the following exam topics:
5.0 Security Fundamentals
5.7 Configure Layer 2 security features (DHCP snooping, dynamic ARP inspection, and port security)
To understand the kinds of risks that exist in modern networks, you have to first understand the rules. Then you have to think about how an attacker might take advantage of those rules in different ways. Some attacks might cause harm as part of a denial-of-service (DoS) attack, while a reconnaissance attack may gather more data to prepare for some other attack. For every protocol and function you learn in networking, there are possible methods to take advantage of those features to give an attacker an advantage.
This chapter discusses two switch features that help prevent some types of attacks that can result in the attacker getting copies of packets sent to/from a legitimate host. One of these features, DHCP Snooping, notices DHCP messages that fall outside the normal use of DHCP—messages that may be part of an attack—and discards those messages. It also watches the DHCP messages that flow through a LAN switch, building a table that lists the details of legitimate DHCP flows, so that other switch features can know what legitimate DHCP leases exist for devices connected to the switch.
The second such feature, Dynamic ARP Inspection (DAI), also helps prevent packets being redirected to an attacking host. Some ARP attacks try to convince hosts to send packets to the attacker’s device instead of the true destination. The switch watches ARP messages as they flow through the switch. The switch checks incoming ARP messages, checking those against normal ARP operation as well as checking the details against other data sources, including the DHCP Snooping binding table. When the ARP message does not match the known information about the legitimate addresses in the network, the switch filters the ARP message.
This chapter examines DHCP Snooping concepts and configuration in the first major section and DAI in the second.
“Do I Know This Already?” Quiz
Take the quiz (either here or use the PTP software) if you want to use the score to help you decide how much time to spend on this chapter. The letter answers are listed at the bottom of the page following the quiz. Appendix C, found both at the end of the book as well as on the companion website, includes both the answers and explanations. You can also find both answers and explanations in the PTP testing software.
Table 8-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
Foundation Topics Section |
Questions |
DHCP Snooping |
1–4 |
Dynamic ARP Inspection |
5–7 |
1. An engineer hears about DHCP Snooping and decides to implement it. Which of the following are the devices on which DHCP Snooping could be implemented? (Choose two answers.)
Layer 2 switches
Routers
Multilayer switches
End-user hosts
2. Layer 2 switch SW2 connects a Layer 2 switch (SW1), a router (R1), a DHCP server (S1), and three PCs (PC1, PC2, and PC3). All PCs are DHCP clients. Which of the following are the most likely DHCP Snooping trust state configurations on SW2 for the ports connected to the listed devices? (Choose two answers.)
The port connected to the router is untrusted.
The port connected to switch SW1 is trusted.
The port connected to PC1 is untrusted.
The port connected to PC3 is trusted.
3. Switch SW1 needs to be configured to use DHCP Snooping in VLAN 5 and only VLAN 5. Which commands must be included, assuming at least one switch port in VLAN 5 must be an untrusted port? (Choose two answers.)
no ip dhcp snooping trust
ip dhcp snooping untrust
ip dhcp snooping
ip dhcp snooping vlan 5
4. On a multilayer switch, a switch needs to be configured to perform DHCP Snooping on some Layer 2 ports in VLAN 3. Which command may or may not be needed depending on whether the switch also acts as a DHCP relay agent?
no ip dhcp snooping information option
ip dhcp snooping limit rate 5
errdisable recovery cause dhcp-rate-limit
ip dhcp snooping vlan 3
5. Switch SW1 has been configured to use Dynamic ARP Inspection with DHCP Snooping in VLAN 5. An ARP request arrives on port G0/1. Which answer describes two items DAI always compares regardless of the configuration?
The message’s ARP origin hardware address and the message’s Ethernet header source MAC address
The message’s ARP origin hardware address and the DHCP Snooping binding table
The message’s ARP target IP address and the DHCP Snooping binding table
The message’s ARP target IP address and the switch’s ARP table
6. Switch SW1 needs to be configured to use Dynamic ARP Inspection along with DHCP Snooping in VLAN 6 and only VLAN 6. Which commands must be included, assuming at least one switch port in VLAN 6 must be a trusted port? (Choose two answers.)
no ip arp inspection untrust
ip arp inspection trust
ip arp inspection
ip arp inspection vlan 6
7. A Layer 2 switch needs to be configured to use Dynamic ARP Inspection along with DHCP Snooping. Which command would make DAI monitor ARP message rates on an interface at an average rate of 4 received ARP messages per second? (Choose two answers.)
ip arp inspection limit rate 4 burst interval 2
ip arp inspection limit rate 10 burst interval 2
ip arp inspection limit rate 16 burst interval 4
ip arp inspection limit rate 4
Answers to the “Do I Know This Already?” quiz:
1 A, C
2 B, C
3 C, D
4 A
5 B
6 B, D
7 C, D
Foundation Topics
DHCP Snooping
DHCP servers play a vital role in most every network today, with almost every user endpoint using DHCP to learn its IP address, mask, default gateway, and DNS server IP addresses. Chapter 7, “Implementing DHCP,” shows how DHCP should work under normal circumstances. This section now examines how attackers might use DHCP for their own ends and how two specific tools—DHCP Snooping and Dynamic ARP Inspection (DAI)—help defeat those attacks.
This section begins with an examination of the need for DHCP Snooping concepts including the types of attacks it can try to prevent, followed by details of how to configure DHCP Snooping.
DHCP Snooping Concepts
DHCP Snooping on a switch acts like a firewall or an ACL in many ways. It analyzes incoming messages on the specified subset of ports in a VLAN. DHCP Snooping never filters non-DHCP messages, but it may choose to filter DHCP messages, applying logic to make a choice—allow the incoming DHCP message or discard the message.
While DHCP itself provides a Layer 3 service, DHCP Snooping operates on LAN switches and is commonly used on Layer 2 LAN switches and enabled on Layer 2 ports. The reason to put DHCP Snooping on the switch is that the function needs to be performed between a typical end-user device—the type of device that acts as a DHCP client—and DHCP servers or DHCP relay agents.
Figure 8-1 shows a sample network that provides a good backdrop to discuss DHCP Snooping. First, all devices connect to Layer 2 switch SW2, with all ports as Layer 2 switchports, all in the same VLAN. The typical DHCP clients sit on the right of the figure. The left shows other devices that could be the path through which to reach a DHCP server.
Figure 8-1 DHCP Snooping Basics: Client Ports Are Untrusted
DHCP Snooping works first on all ports in a VLAN, but with each port being trusted or untrusted by DHCP Snooping. To understand why, consider this summary of the general rules used by DHCP Snooping. Note that the rules differentiate between messages normally sent by servers (like DHCPOFFER and DHCPACK) versus those normally sent by DHCP clients:
DHCP messages received on an untrusted port, for messages normally sent by a server, will always be discarded.
DHCP messages received on an untrusted port, as normally sent by a DHCP client, may be filtered if they appear to be part of an attack.
DHCP messages received on a trusted port will be forwarded; trusted ports do not filter (discard) any DHCP messages.
A Sample Attack: A Spurious DHCP Server
To give you some perspective, Figure 8-2 shows a legitimate user’s PC on the far right and the legitimate DHCP server on the far left. However, an attacker has connected his laptop to the LAN and started his DHCP attack by acting like a DHCP server. Following the steps in the figure, assume PC1 is attempting to lease an IP address while the attacker is making his attack:
PC1 sends a LAN broadcast with PC1’s first DHCP message (DHCPDISCOVER).
The attacker’s PC—acting as a spurious DHCP server—replies to the DHCPDISCOVER with a DHCPOFFER.
Figure 8-2 DHCP Attack Supplies Good IP Address but Wrong Default Gateway
In this example, the DHCP server created and used by the attacker actually leases a useful IP address to PC1, in the correct subnet, with the correct mask. Why? The attacker wants PC1 to function, but with one twist. Notice the default gateway assigned to PC1: 10.1.1.2, which is the attacker’s PC address, rather than 10.1.1.1, which is router R1’s address. Now PC1 thinks it has all it needs to connect to the network, and it does—but now all the packets sent by PC1 to what it thinks is its default router flow first through the attacker’s PC, creating a man-in-the-middle attack, as shown in Figure 8-3.
Figure 8-3 Unfortunate Result: DHCP Attack Leads to Man-in-the-Middle
Note that the legitimate DHCP also returns a DHCPOFFER message to host PC1, but most hosts use the first received DHCPOFFER, and the attacker will likely be first in this scenario.
The two steps in the figure show data flow once DHCP has completed. For any traffic destined to leave the subnet, PC1 sends its packets to its default gateway, 10.1.1.2, which happens to be the attacker. The attacker forwards the packets to R1. The PC1 user can connect to any and all applications just like normal, but now the attacker can keep a copy of anything sent by PC1.
DHCP Snooping Logic
The preceding example shows just one attack in which the attacker acts like a DHCP server (spurious DHCP server). DHCP Snooping defeats such attacks by making most ports untrusted, which by definition would filter the DHCP server messages that arrive on the untrusted ports. For instance, in Figures 8-2 and 8-3, making the port connected to the attacker, a DHCP Snooping untrusted port defeats the attack.
To appreciate the broader set of DHCP Snooping rules and logic, it helps to have a handy reference of some of the more common DHCP messages and processes. For a quick review, the normal message flow includes this sequence: DISCOVER, OFFER, REQUEST, ACK (DORA). In particular:
Clients send DISCOVER and REQUEST.
Servers send OFFER and ACK.
Additionally, DHCP clients also use the DHCP RELEASE and DHCP DECLINE messages. When a client has a working lease for an address but no longer wants to use the address, the DHCP client can tell the DHCP server it no longer needs the address, releasing it back to the DHCP server, with the DHCP RELEASE message. Similarly, a client can send a DHCP DECLINE message to turn down the use of an IP address during the normal DORA flow on messages.
Now to the logic for DHCP Snooping untrusted ports. Figure 8-4 summarizes the ideas, with two switch ports. On the left, the switch port connects to a DHCP server, so it should be trusted; otherwise DHCP would not work, because the switch would filter all DHCP messages sent by the DHCP server. On the right, PC1 connects to an untrusted port with a DHCP client.
Figure 8-4 Summary of Rules for DHCP Snooping
The following list summarizes the DHCP Snooping rules:
Examine all incoming DHCP messages.
If normally sent by servers, discard the message.
If normally sent by clients, filter as follows:
For DISCOVER and REQUEST messages, check for MAC address consistency between the Ethernet frame and the DHCP message.
For RELEASE or DECLINE messages, check the incoming interface plus IP address versus the DHCP Snooping binding table.
For messages not filtered that result in a DHCP lease, build a new entry to the DHCP Snooping binding table.
The next few pages complete the discussion of concepts by explaining a little more about steps 3 and 4 in the list.
Filtering DISCOVER Messages Based on MAC Address
DHCP Snooping does one straightforward check for the most common client-sent messages: DISCOVER and REQUEST. First, note that DHCP messages define the chaddr (client hardware address) field to identify the client. Hosts on LANs include the device’s MAC address as part of chaddr. As usual, Ethernet hosts encapsulate the DHCP messages inside Ethernet frames, and those frames of course include a source MAC address—an address that should be the same MAC address used in the DHCP chaddr field. DHCP Snooping does a simple check to make sure those values match.
Figure 8-5 shows how an attacker could attempt to overload the DHCP server and lease all the addresses in the subnet. The attacker’s PC uses pseudo MAC address A, so all three DISCOVER messages in the figure show a source Ethernet address of “A.” However, each message (in the DHCP data) identifies a different MAC address in the chaddr value (shown as MAC1, MAC2, and MAC3 in the figure for brevity), so from a DHCP perspective, each message appears to be a different DHCP request. The attacker can attempt to lease every IP address in the subnet so that no other hosts could obtain a lease.
Figure 8-5 DHCP Snooping Checks chaddr and Ethernet Source MAC
The core feature of DHCP Snooping defeats this type of attack on untrusted ports. It checks the Ethernet header source MAC address and compares that address to the MAC address in the DHCP header, and if the values do not match, DHCP Snooping discards the message.
Filtering Messages that Release IP Addresses
Before looking at the next bit of logic, you need to first understand the DHCP Snooping binding table.
DHCP Snooping builds the DHCP Snooping binding table for all the DHCP flows it sees that it allows to complete. That is, for any working legitimate DHCP flows, it keeps a list of some of the important facts. Then DHCP Snooping, and other features like Dynamic ARP Inspection, can use the table to make decisions.
As an example, consider Figure 8-6, which repeats the same topology as Figure 8-4, now with one entry in its DHCP Snooping binding table.
Figure 8-6 Legitimate DHCP Client with DHCP Binding Entry Built by DHCP Snooping
In this simple network, the DHCP client on the right leases IP address 172.16.2.101 from the DHCP server on the left. The switch’s DHCP Snooping feature combines the information from the DHCP messages, with information about the port (interface G1/0/3, assigned to VLAN 11 by the switch), and puts that in the DHCP Snooping binding table.
DHCP Snooping then applies additional filtering logic that uses the DHCP Snooping binding table: it checks client-sent messages like RELEASE and DECLINE that would cause the DHCP server to be allowed to release an address. For instance, a legitimate user might lease address 172.16.2.101, and at some point release the address back to the server; however, before the client has finished with its lease, an attacker could send DHCP RELEASE message to release that address back into the pool. The attacker could then immediately try to lease that address, hoping the DHCP server assigns that same 172.16.2.101 address to the attacker.
Figure 8-7 shows an example. PC1 already has a DHCP address (172.16.2.101), with SW2 listing an entry in the DHCP Snooping binding table. The figure shows the action by which the attacker off port G1/0/5 attempts to release PC1’s address. DHCP Snooping compares the incoming message, incoming interface, and matching table entry:
The incoming message is a DHCP RELEASE message in port G1/0/5 listing address 172.16.2.101.
The DHCP Snooping binding table lists 172.16.2.101 as being originally leased via messages arriving on port G1/0/3.
DHCP Snooping discards the DHCP RELEASE message.
Figure 8-7 DHCP Snooping Defeats a DHCP RELEASE from Another Port
DHCP Snooping Configuration
DHCP Snooping requires several configuration steps to make it work. First, you need to use a pair of associated global commands: one to enable DHCP Snooping and another to list the VLANs on which to use DHCP Snooping. Both must be included for DHCP Snooping to operate.
Second, while not literally required, you will often need to configure a few ports as trusted ports. Most switches that use DHCP Snooping for a VLAN have some trusted ports and some untrusted ports, and with a default of untrusted, you need to configure the trusted ports.
This section begins with an example that shows how to configure a typical Layer 2 switch to use DHCP Snooping, with required commands as just described, and with other optional commands.
Configuring DHCP Snooping on a Layer 2 Switch
The upcoming examples all rely on the topology illustrated in Figure 8-8, with Layer 2 switch SW2 as the switch on which to enable DHCP Snooping. The DHCP server sits on the other side of the WAN, on the left of the figure. As a result, SW2’s port connected to router R2 (a DHCP relay agent) needs to be trusted. On the right, two sample PCs can use the default untrusted setting.
Figure 8-8 Sample Network Used in DHCP Snooping Configuration Examples
Switch SW2 places all the ports in the figure in VLAN 11, so to enable DHCP Snooping in VLAN 11, SW2 requires two commands, as shown near the top of Example 8-1: ip dhcp snooping and ip dhcp snooping vlan 11. Then, to change the logic on port G1/0/2 (connected to the router) to be trusted, the configuration includes the ip dhcp snooping trust interface subcommand.
Example 8-1 DHCP Snooping Configuration to Match Figure 8-8
ip dhcp snooping ip dhcp snooping vlan 11 no ip dhcp snooping information option ! interface GigabitEthernet1/0/2 ip dhcp snooping trust
Note that the no ip dhcp snooping information option command in Example 8-1 will be explained in a better context just after Example 8-2 but is listed in Example 8-1 to make the example complete.
With this configuration, the switch follows the logic steps detailed in the earlier section titled “DHCP Snooping Logic.” To see some support for that claim, look at Example 8-2, which shows the output from the show ip dhcp snooping command on switch SW2.
Example 8-2 SW2 DHCP Snooping Status
SW2# show ip dhcp snooping Switch DHCP snooping is enabled Switch DHCP gleaning is disabled DHCP snooping is configured on following VLANs: 11 DHCP snooping is operational on following VLANs: 11 Smartlog is configured on following VLANs: none Smartlog is operational on following VLANs: none DHCP snooping is configured on the following L3 Interfaces: Insertion of option 82 is disabled circuit-id default format: vlan-mod-port remote-id: bcc4.938b.a180 (MAC) Option 82 on untrusted port is not allowed Verification of hwaddr field is enabled Verification of giaddr field is enabled DHCP snooping trust/rate is configured on the following Interfaces: Interface Trusted Allow option Rate limit (pps) ----------------------- ------- ------------ ---------------- GigabitEthernet1/0/2 yes yes unlimited Custom circuit-ids:
The highlighted lines in the example point out a few of the key configuration settings. Starting at the top, the first two confirm the configuration of the ip dhcp snooping and ip dhcp snooping vlan 11 commands, respectively. Also, the highlighted lines at the bottom of the output show a section that lists trusted ports—in this case, only port G1/0/2.
Also, you might have noticed that highlighted line in the middle that states Insertion of option 82 is disabled. That line confirms the addition of the no ip dhcp information option command to the configuration back in Example 8-1. To understand why the example includes this command, consider these facts about DHCP relay agents:
DHCP relay agents add new fields to DHCP requests—defined as option 82 DHCP header fields (in RFC 3046).
DHCP Snooping uses default settings that work well if the switch acts as a Layer 3 switch and as a DHCP relay agent, meaning that the switch should insert the DHCP option 82 fields into DHCP messages. In effect, the switch defaults to use ip dhcp snooping information option.
When the switch does not also act as a DHCP relay agent, the default setting stops DHCP from working for end users. The switch sets fields in the DHCP messages as if it were a DHCP relay agent, but the changes to those messages cause most DHCP servers (and most DHCP relay agents) to ignore the received DHCP messages.
The conclusion: To make DHCP Snooping work on a switch that is not also a DHCP relay agent, disable the option 82 feature using the no ip dhcp snooping information option global command.
That concludes the DHCP Snooping configuration that is both required and that you will most often need to make the feature work. The rest of this section discusses a few optional DHCP Snooping features.
Limiting DHCP Message Rates
Knowing that DHCP Snooping prevents their attacks, what might attackers do in response? Devise new attacks, including attacking DHCP Snooping itself.
One way to attack DHCP Snooping takes advantage of the fact that it uses the general-purpose CPU in a switch. Knowing that, attackers can devise attacks to generate large volumes of DHCP messages in an attempt to overload the DHCP Snooping feature and the switch CPU itself. The goal can be as a simple denial-of-service attack or a combination of attacks that might cause DHCP Snooping to fail to examine every message, allowing other DHCP attacks to then work.
To help prevent this kind of attack, DHCP Snooping includes an optional feature that tracks the number of incoming DHCP messages. If the number of incoming DHCP messages exceeds that limit over a one-second period, DHCP Snooping treats the event as an attack and moves the port to an err-disabled state. Also, the feature can be enabled both on trusted and untrusted interfaces.
Although rate limiting DHCP messages can help, placing the port in an err-disabled state can itself create issues. As a reminder, once in the err-disabled state, the switch will not send or receive frames for the interface. However, the err-disabled state might be too severe an action because the default recovery action for an err-disabled state requires the configuration of a shutdown and then a no shutdown subcommand on the interface.
To help strike a better balance, you can enable DHCP Snooping rate limiting and then also configure the switch to automatically recover from the port’s err-disabled state, without the need for a shutdown and then no shutdown command.
Example 8-3 shows how to enable DHCP Snooping rate limits and err-disabled recovery. First, look at the lower half of the configuration, to the interfaces, to see the straightforward setting of the per-interface limits using the ip dhcp snooping rate limit number interface subcommands. The top of the configuration uses two global commands to tell IOS to recover from an err-disabled state if it is caused by DHCP Snooping, and to use a nondefault number of seconds to wait before recovering the interface. Note that the configuration in Example 8-3 would rely on the core configuration for DHCP Snooping as shown in Example 8-1.
Example 8-3 Configuring DHCP Snooping Message Rate Limits
errdisable recovery cause dhcp-rate-limit errdisable recovery interval 30 ! interface GigabitEthernet1/0/2 ip dhcp snooping limit rate 10 ! interface GigabitEthernet1/0/3 ip dhcp snooping limit rate 2
A repeat of the show ip dhcp snooping command now shows the rate limits near the end of the output, as noted in Example 8-4.
Example 8-4 Confirming DHCP Snooping Rate Limits
SW2# show ip dhcp snooping ! Lines omitted for brevity Interface Trusted Allow option Rate limit (pps) ----------------------- ------- ------------ ---------------- GigabitEthernet1/0/2 yes yes 10 Custom circuit-ids: GigabitEthernet1/0/3 no no 2 Custom circuit-ids:
DHCP Snooping Configuration Summary
The following configuration checklist summarizes the commands included in this section about how to configure DHCP Snooping.
Step 1. Configure this pair of commands (both required):
A. Use the ip dhcp snooping global command to enable DHCP Snooping on the switch.
B. Use the ip dhcp snooping vlan vlan-list global command to identify the VLANs on which to use DHCP Snooping.
Step 2. (Optional): Use the no ip dhcp snooping information option global command on Layer 2 switches to disable the insertion of DHCP Option 82 data into DHCP messages, specifically on switches that do not act as a DHCP relay agent.
Step 3. Configure the ip dhcp snooping trust interface subcommand to override the default setting of not trusted.
Step 4. (Optional): Configure DHCP Snooping rate limits and err-disabled recovery:
Step A. (Optional): Configure the ip dhcp snooping limit rate number interface subcommand to set a limit of DHCP messages per second.
Step B. (Optional): Configure the no ip dhcp snooping limit rate number interface subcommand to remove an existing limit and reset the interface to use the default of no rate limit.
Step C. (Optional): Configure the errdisable recovery cause dhcp-rate-limit global command to enable the feature of automatic recovery from err-disabled mode, assuming the switch placed the port in err-disabled state because of exceeding DHCP Snooping rate limits.
Step D. (Optional): Configure the errdisable recovery interval seconds global commands to set the time to wait before recovering from an interface err-disabled state (regardless of the cause of the err-disabled state).
Dynamic ARP Inspection
The Dynamic ARP Inspection (DAI) feature on a switch examines incoming ARP messages on untrusted ports to filter those it believes to be part of an attack. DAI’s core feature compares incoming ARP messages with two sources of data: the DHCP Snooping binding table and any configured ARP ACLs. If the incoming ARP message does not match the tables in the switch, the switch discards the ARP message.
This section follows the same sequence as with the DHCP Snooping section, first examining the concepts behind DAI and ARP attacks, and then showing how to configure DAI with both required and optional features.
DAI Concepts
To understand the attacks DAI can prevent, you need to be ready to compare normal ARP operations with the abnormal use of ARP used in some types of attacks. This section uses that same flow, first reviewing a few important ARP details, and then showing how an attacker can just send an ARP reply—called a gratuitous ARP—triggering hosts to add incorrect ARP entries to their ARP tables.
Review of Normal IP ARP
If all you care about is how ARP works normally, with no concern about attacks, you can think of ARP to the depth shown in Figure 8-9. The figure shows a typical sequence. Host PC1 needs to send an IP packet to its default router (R2), so PC1 first sends an ARP request message in an attempt to learn the MAC address associated with R2’s 172.16.2.2 address. Router R2 sends back an ARP reply, listing R2’s MAC address (note the figure shows pseudo MAC addresses to save space).
Figure 8-9 Legitimate ARP Tables After PC1 DHCP and ARP with Router R2
The ARP tables at bottom of the figure imply an important fact: both hosts learn the other host’s MAC address with this two-message flow. Not only does PC1 learn R2’s MAC address based on the ARP reply (message 2), but router R2 learns PC1’s IP and MAC address because of the ARP request (message 1). To see why, take a look at the more detailed view of those messages as shown in Figure 8-10.
Figure 8-10 A Detailed Look at ARP Request and Reply
The ARP messages define origin IP and hardware (MAC) address fields as well as target IP and hardware address fields. The origin should list the sending device’s IP address and MAC, no matter whether the message is an ARP reply or ARP request. For instance, message 1 in the figure, sent by PC1, lists PC1’s IP and MAC addresses in the origin fields, which is why router R2 could learn that information. PC2 likewise learns of R2’s MAC address per the origin address fields in the ARP reply.
Gratuitous ARP as an Attack Vector
Normally, a host uses ARP when it knows the IP address of another host and wants to learn that host’s MAC address. However, for legitimate reasons, a host might also want to inform all the hosts in the subnet about its MAC address. That might be useful when a host changes its MAC address, for instance. So, ARP supports the idea of a gratuitous ARP message with these features:
It is an ARP reply.
It is sent without having first received an ARP request.
It is sent to an Ethernet destination broadcast address so that all hosts in the subnet receive the message.
For instance, if a host’s MAC address is MAC A, and it changes to MAC B, to cause all the other hosts to update their ARP tables, the host could send a gratuitous ARP that lists an origin MAC of MAC B.
Attackers can take advantage of gratuitous ARPs because they let the sending host make other hosts change their ARP tables. Figure 8-11 shows just such an example initiated by PC A (an attacker) with a gratuitous ARP. However, this ARP lists PC1’s IP address but a different device’s MAC address (PC A) at step 1, causing the router to update its ARP table (step 2).
Figure 8-11 Nefarious Use of ARP Reply Causes Incorrect ARP Data on R2
At this point, when R2 forwards IP packets to PC1’s IP address (172.16.2.101), R2 will encapsulate them in an Ethernet frame with PC A as the destination rather than with PC1’s MAC address. At first, this might seem to stop PC1 from working, but instead it could be part of a man-in-the-middle attack so that PC A can copy every message. Figure 8-12 shows the idea of what happens at this point:
PC1 sends messages to some server on the left side of router R2.
The server replies to PC1’s IP address, but R2 forwards that packet to PC A’s MAC address, rather than to PC1.
PC A copies the packet for later processing.
PC A forwards the packet inside a new frame to PC1 so that PC1 still works.
Figure 8-12 Man-in-the-Middle Attack Resulting from Gratuitous ARP
Dynamic ARP Inspection Logic
DAI has a variety of features that can prevent these kinds of ARP attacks. To understand how, consider the sequence of a typical client host with regards to both DHCP and ARP. When a host does not have an IP address yet—that is, before the DHCP process completes—it does not need to use ARP. Once the host leases an IP address and learns its subnet mask, it needs ARP to learn the MAC addresses of other hosts or the default router in the subnet, so it sends some ARP messages. In short, DHCP happens first, then ARP.
DAI takes an approach for untrusted interfaces that confirms an ARP’s correctness based on DHCP Snooping’s data about the earlier DHCP messages. The correct normal DHCP messages list the IP address leased to a host as well as that host’s MAC address. The DHCP Snooping feature also records those facts into the switch’s DHCP Snooping binding table.
For any DAI untrusted ports, DAI compares the ARP message’s origin IP and origin MAC address fields to the DHCP Snooping binding table. If found in the table, DAI allows the ARP through, but if not, DAI discards the ARP. For instance, Figure 8-13 shows step 1 in which the attacker at PC A attempts the gratuitous ARP shown earlier in Figure 8-11. At step 2, DAI makes a comparison to the DHCP Snooping binding table, not finding a match with MAC A along with IP address 172.16.2.101, so DAI would discard the message.
Figure 8-13 DAI Filtering ARP Based on DHCP Snooping Binding Table
DAI works with the idea of trusted and untrusted ports with the same general rules as DHCP Snooping. Access ports connected to end-user devices are often untrusted by both DHCP Snooping and DAI. Ports connected to other switches, routers, the DHCP server—anything other than links to end-user devices—should be trusted by DAI.
Note that although DAI can use the DHCP Snooping table as shown here, it can also use similar statically configured data that lists correct pairs of IP and MAC addresses via a tool called ARP ACLs. Using ARP ACLs with DAI becomes useful for ports connected to devices that use static IP addresses rather than DHCP. Note that DAI looks for both the DCHP Snooping binding data and ARP ACLs.
Beyond that core feature, note that DAI can optionally perform other checks as well. For instance, the Ethernet header that encapsulates the ARP should have addresses that match the ARP origin and target MAC addresses. Figure 8-14 shows an example of the comparison of the Ethernet source MAC address and the ARP message origin hardware field.
Figure 8-14 DAI Filtering Checks for Source MAC Addresses
DAI can be enabled to make the comparisons shown in the figure, discarding these messages:
Messages with an Ethernet header source MAC address that is not equal to the ARP origin hardware (MAC) address
ARP reply messages with an Ethernet header destination MAC address that is not equal to the ARP target hardware (MAC) address
Messages with unexpected IP addresses in the two ARP IP address fields
Finally, like DHCP Snooping, DAI does its work in the switch CPU rather than in the switch ASIC, meaning that DAI itself can be more susceptible to DoS attacks. The attacker could generate large numbers of ARP messages, driving up CPU usage in the switch. DAI can avoid these problems through rate limiting the number of ARP messages on a port over time.
Dynamic ARP Inspection Configuration
Configuring DAI requires just a few commands, with the usual larger variety of optional configuration settings. This section examines DAI configuration, first with mostly default settings and with reliance on DHCP Snooping. It then shows a few of the optional features, like rate limits, automatic recovery from err-disabled state, and how to enable additional checks of incoming ARP messages.
Configuring ARP Inspection on a Layer 2 Switch
Before configuring DAI, you need to think about the feature and make a few decisions based on your goals, topology, and device roles. The decisions include the following:
Choose whether to rely on DHCP Snooping, ARP ACLs, or both.
If using DHCP Snooping, configure it and make the correct ports trusted for DHCP Snooping.
Choose the VLAN(s) on which to enable DAI.
Make DAI trusted (rather than the default setting of untrusted) on select ports in those VLANs, typically for the same ports you trusted for DHCP Snooping.
All the configuration examples in this section use the same sample network used in the DHCP Snooping configuration topics, repeated here as Figure 8-15. Just as with DHCP Snooping, switch SW2 on the right should be configured to trust the port connected to the router (G1/0/2), but not trust the two ports connected to the PCs.
Figure 8-15 Sample Network Used in ARP Inspection Configuration Examples
Example 8-5 shows the required configuration to enable DAI on switch SW2 in Figure 8-15—a configuration that follows a similar progression compared to DHCP Snooping. All ports in the figure connect to VLAN 11, so to enable DAI in VLAN 11, just add the ip arp inspection vlan 11 global command. Then, to change the logic on port G1/0/2 (connected to the router) to be trusted by DAI, add the ip arp inspection trust interface subcommand.
Example 8-5 IP ARP Inspection Configuration to Match Figure 8-15
ip arp inspection vlan 11 ! interface GigabitEthernet1/0/2 ip arp inspection trust
Example 8-5 configures DAI, but it omits both DHCP Snooping and ARP ACLs. (If you were to configure a switch only with commands shown in Example 8-5, the switch would filter all ARPs entering all untrusted ports in VLAN 11.) Example 8-6 shows a complete and working DAI configuration that adds the DHCP Snooping configuration to match the DAI configuration in Example 8-5. Note that Example 8-6 combines Example 8-1’s earlier DHCP Snooping configuration for this same topology to the DAI configuration just shown in Example 8-5, with highlights for the DAI-specific configuration lines.
Example 8-6 IP DHCP Snooping Configuration Added to Support DAI
ip arp inspection vlan 11 ip dhcp snooping ip dhcp snooping vlan 11 no ip dhcp snooping information option ! interface GigabitEthernet1/0/2 ip dhcp snooping trust ip arp inspection trust
Remember, DHCP occurs first with DHCP clients, and then they send ARP messages. With the configuration in Example 8-6, the switch builds its DHCP Snooping binding table by analyzing incoming DHCP messages. Next, any incoming ARP messages on DAI untrusted ports must have matching information in that binding table.
Example 8-7 confirms the key facts about correct DAI operation in this sample network based on the configuration in Example 8-6. The show ip arp inspection command gives both configuration settings along with status variables and counters. For instance, the highlighted lines show the total ARP messages received on untrusted ports in that VLAN and the number of dropped ARP messages (currently 0).
Example 8-7 SW2 IP ARP Inspection Status
SW2# show ip arp inspection Source Mac Validation : Disabled Destination Mac Validation : Disabled IP Address Validation : Disabled Vlan Configuration Operation ACL Match Static ACL ---- ------------- --------- --------- ---------- 11 Enabled Active Vlan ACL Logging DHCP Logging Probe Logging ---- ----------- ------------ ------------- 11 Deny Deny Off Vlan Forwarded Dropped DHCP Drops ACL Drops ---- --------- ------- ---------- --------- 11 59 0 0 0 Vlan DHCP Permits ACL Permits Probe Permits Source MAC Failures ---- ------------ ----------- ------------- ------------------- 11 7 0 49 0 Vlan Dest MAC Failures IP Validation Failures Invalid Protocol Data ---- ----------------- ---------------------- --------------------- Vlan Dest MAC Failures IP Validation Failures Invalid Protocol Data ---- ----------------- ---------------------- --------------------- 11 0 0 0 SW2# show ip dhcp snooping binding MacAddress IpAddress Lease(sec) Type VLAN Interface ----------------- ------------- ---------- ------------- ---- -------------------- 02:00:11:11:11:11 172.16.2.101 86110 dhcp-snooping 11 GigabitEthernet1/0/3 02:00:22:22:22:22 172.16.2.102 86399 dhcp-snooping 11 GigabitEthernet1/0/4 Total number of bindings: 2
The end of Example 8-7 shows an example of the show ip dhcp snooping binding command on switch SW2. Note that the first two columns list a MAC and IP address as learned from the DHCP messages. Then, imagine an ARP message arrives from PC1, a message that should list PC1’s 0200.1111.1111 MAC address and 172.16.2.101 as the origin MAC and IP address, respectively. Per this output, the switch would find that matching data and allow the ARP message.
Example 8-8 shows some detail of what happens when switch SW2 receives an invalid ARP message on port G1/0/4 in Figure 8-15. In this case, to create the invalid ARP message, PC2 in the figure was configured with a static IP address of 172.16.2.101 (which is PC1’s DHCP-leased IP address). The highlights in the log message at the top of the example show PC2’s claimed origin MAC and origin IP addresses in the ARP message. If you refer back to the bottom of Example 8-7, you can see that this origin MAC/IP pair does not exist in the DHCP Snooping binding table, so DAI rejects the ARP message.
Example 8-8 Sample Results from an ARP Attack
Jul 25 14:28:20.763: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi1/0/4, vlan 11.([0200.2222.2222/172.16.2.101/0000.0000.0000/172.16.2.1/09:28:20 EST Thu Jul 25 2019]) SW2# show ip arp inspection statistics Vlan Forwarded Dropped DHCP Drops ACL Drops ---- --------- ------- ---------- --------- 11 59 17 17 0 Vlan DHCP Permits ACL Permits Probe Permits Source MAC Failures ---- ------------ ----------- ------------- ------------------- 11 7 0 49 0 Vlan Dest MAC Failures IP Validation Failures Invalid Protocol Data ---- ----------------- ---------------------- --------------------- 11 0 0 0
The statistics from the show ip arp inspection command also confirms that the switch has dropped some ARP messages. The highlighted lines in the middle of the table show 17 total dropped ARP messages in VLAN 11. That same highlighted line confirms that it dropped all 17 because of the DHCP Snooping binding table (“DHCP Drops”), with zero dropped due to an ARP ACL (“ACL Drops”).
Limiting DAI Message Rates
Like DHCP Snooping, DAI can also be the focus of a DoS attack with the attacker generating a large number of ARP messages. Like DHCP Snooping, DAI supports the configuration of rate limits to help prevent those attacks, with a reaction to place the port in an err-disabled state, and with the ability to configure automatic recovery from that err-disabled state.
The DHCP Snooping and DAI rate limits do have some small differences in operation, defaults, and in configuration, as follows:
DAI defaults to use rate limits for all interfaces (trusted and untrusted), with DHCP Snooping defaulting to not use rate limits.
DAI allows the configuration of a burst interval (a number of seconds), so that the rate limit can have logic like “x ARP messages over y seconds” (DHCP Snooping does not define a burst setting).
It helps to look at DAI and DHCP Snooping rate limit configuration together to make comparisons, so Example 8-9 shows both. The example repeats the exact same DHCP Snooping commands in earlier Example 8-3 but adds the DAI configuration (highlighted). The configuration in Example 8-7 could be added to the configuration shown in Example 8-6 for a complete DHCP Snooping and DAI configuration.
Example 8-9 Configuring ARP Inspection Message Rate Limits
errdisable recovery cause dhcp-rate-limit errdisable recovery cause arp-inspection errdisable recovery interval 30 ! interface GigabitEthernet1/0/2 ip dhcp snooping limit rate 10 ip arp inspection limit rate 8 ! interface GigabitEthernet1/0/3 ip dhcp snooping limit rate 2 ip arp inspection limit rate 8 burst interval 4
Example 8-10 lists output that confirms the configuration settings. For instance, Example 8-9 configures port G1/0/2 with a rate of 8 messages for each (default) burst of 1 second; the output in Example 8-10 for interface G1/0/2 also lists a rate of 8 and burst interval of 1. Similarly, Example 8-9 configures port G1/0/3 with a rate of 8 over a burst of 4 seconds, with Example 8-10 confirming those same values for port G1/0/3. Note that the other two interfaces in Example 8-10 show the default settings of a rate of 15 messages over a one-second burst.
Example 8-10 Confirming ARP Inspection Rate Limits
SW2# show ip arp inspection interfaces Interface Trust State Rate (pps) Burst Interval --------------- ----------- ---------- -------------- Gi1/0/1 Untrusted 15 1 Gi1/0/2 Trusted 8 1 Gi1/0/3 Untrusted 8 4 Gi1/0/4 Untrusted 15 1 ! Lines omitted for brevity
Configuring Optional DAI Message Checks
As mentioned in the section titled “Dynamic ARP Inspection Logic,” DAI always checks the ARP message’s origin MAC and origin IP address fields versus some table in the switch, but it can also perform other checks. Those checks require more CPU, but they also help prevent other types of attacks.
Example 8-11 shows how to configure those three additional checks. Note that you can configure one, two, or all three of the options: just configure the ip arp inspection validate command again with all the options you want in one command, and it replaces the previous global configuration command. The example shows the three options, with the src-mac (source mac) option configured.
Example 8-11 Confirming ARP Inspection Rate Limits
SW2# configure terminal Enter configuration commands, one per line. End with CNTL/Z. SW2(config)# ip arp inspection validate ? dst-mac Validate destination MAC address ip Validate IP addresses src-mac Validate source MAC address SW2(config)# ip arp inspection validate src-mac SW2(config)# ^Z SW2# SW2# show ip arp inspection Source Mac Validation : Enabled Destination Mac Validation : Disabled IP Address Validation : Disabled
IP ARP Inspection Configuration Summary
The following configuration checklist summarizes the commands included in this section about how to configure Dynamic IP ARP Inspection:
Step 1. Use the ip arp inspection vlan vlan-list global command to enable Dynamic ARP Inspection (DAI) on the switch for the specified VLANs.
Step 2. Separate from the DAI configuration, also configure DHCP Snooping and/or ARP ACLs for use by DAI.
Step 3. Configure the ip arp inspection trust interface subcommand to override the default setting of not trusted.
Step 4. (Optional): Configure DAI rate limits and err-disabled recovery:
Step A. (Optional): Configure the ip arp inspection limit rate number [burst interval seconds] interface subcommand to set a limit of ARP messages per second, or ARP messages for each configured interval.
Step B. (Optional): Configure the ip arp inspection limit rate none interface subcommand to disable rate limits.
Step C. (Optional): Configure the errdisable recovery cause arp-inspection global command to enable the feature of automatic recovery from err-disabled mode, assuming the switch placed the port in err-disabled state because of exceeding DAI rate limits.
Step D. (Optional): Configure the errdisable recovery interval seconds global commands to set the time to wait before recovering from an interface err-disabled state (regardless of the cause of the err-disabled state).
Step 5. (Optional): Configure the ip arp inspection validate {[dst-mac] [src-mac] [ip]} global command to add DAI validation steps.
Chapter Review
One key to doing well on the exams is to perform repetitive spaced review sessions. Review this chapter’s material using either the tools in the book or interactive tools for the same material found on the book’s companion website. Refer to the “Your Study Plan” element for more details. Table 8-2 outlines the key review elements and where you can find them. To better track your study progress, record when you completed these activities in the second column.
Table 8-2 Chapter Review Tracking
Review Element |
Review Date(s) |
Resource Used |
Review key topics |
|
Book, website |
Review key terms |
|
Book, website |
Answer DIKTA questions |
|
Book, PTP |
Review config checklists |
|
Book, website |
Review All the Key Topics
Table 8-3 Key Topics for Chapter 8
Key Topic Element |
Description |
Page Number |
DHCP filtering actions on trusted and untrusted ports |
||
List |
DHCP Snooping logic |
|
DHCP Snooping binding table concept |
||
DHCP Snooping configuration |
||
List |
DHCP Snooping configuration checklist |
|
Detail inside ARP messages with origin and target |
||
List |
Gratuitous ARP details |
|
Core Dynamic ARP Inspection logic |
||
Dynamic ARP Inspection configuration with associated DHCP Snooping configuration |
||
List |
Dynamic ARP Inspection checklist |
Key Terms You Should Know
Command References
Tables 8-4 and 8-5 list the configuration and verification commands used in this chapter. As an easy review exercise, cover the left column in a table, read the right column, and try to recall the command without looking. Then repeat the exercise, covering the right column, and try to recall what the command does.
Table 8-4 Chapter 8 Configuration Command Reference
Command |
Mode/Purpose/Description |
ip dhcp snooping |
Global command that enables DHCP Snooping if combined with enabling it on one or more VLANs |
ip dhcp snooping vlan vlan-list |
Global command that lists VLANs on which to enable DHCP Snooping, assuming the ip dhcp snooping command is also configured |
[no] ip dhcp snooping information option |
Command that enables (or disables with no option) the feature of inserting DHCP option 82 parameters by the switch when also using DHCP Snooping |
[no] ip dhcp snooping trust |
Interface subcommand that sets the DHCP Snooping trust state for an interface (default no, or untrusted) |
ip dhcp snooping limit rate number |
Interface subcommand that sets a limit to the number of incoming DHCP messages processed on an interface, per second, before DHCP Snooping discards all other incoming DHCP messages in that same second |
err-disable recovery cause dhcp-rate-limit |
Global command that enables the switch to automatically recover an err-disabled interface if set to that state because of exceeding a DHCP rate limit setting |
err-disable recovery interval seconds |
Global command that sets the number of seconds IOS waits before recovering any err-disabled interfaces which, per various configuration settings, should be recovered automatically |
err-disable recovery cause arp-inspection |
Global command that enables the switch to automatically recover an err-disabled interface if set to that state because of an ARP Inspection violation |
Table 8-5 Chapter 8 EXEC Command Reference
Command |
Purpose |
show ip dhcp snooping |
Lists a large variety of DHCP Snooping configuration settings |
show ip dhcp snooping statistics |
Lists counters regarding DHCP Snooping behavior on the switch |
show ip dhcp snooping binding |
Displays the contents of the dynamically created DHCP Snooping binding table |
show ip arp inspection |
Lists both configuration settings for Dynamic ARP Inspection (DAI) as well as counters for ARP messages processed and filtered |
show ip arp inspection statistics |
Lists the subset of the show ip arp inspection command output that includes counters |