Address Resolution Protocol Reduction
Ed Tittel

The Address Resolution Protocol (ARP) is a vital part of Ethernet networks. ARP matches Network layer addresses in the Internet Protocol (IP) format with Data Link layer addresses in the Media Access Control (MAC) format. Upper OSI layer services and applications communicate using the IP format, but communication on any subnet in any single routing domain requires interface-to-interface communications, which require MAC addresses to effect such transfers.

If a workstation wants to send a print job to a network printer on the local network segment, it must discover the correct MAC address for the printer. It does this by sending an ARP broadcast. The broadcast sends the workstation's IP address and asks the printer to return its MAC address. All devices ignore this request except for the device with the matching IP address. The targeted printer sends back its MAC address, which the workstation adds to its dynamic ARP cache table. The workstation then transfers the print output data to the printer using the printer's MAC address.

After communications are established, the workstation and printer retain their ARP cache entries (each other's IP and MAC addresses) for a fixed time interval. Windows XP keeps most IP/MAC address mappings in its ARP cache for 2 minutes (120 seconds) whenever an ARP request is made. The local host keeps the remote host's entry in its table. In the example, the Windows XP client keeps the printer's address data and vice-versa. When an ARP cache entry is used to communicate on the local cable segment or VLAN, the cache lifetime is reset to 10 minutes (600 seconds) after each such reference. After an ARP cache entry's lifetime expires without further reference, that entry is removed from the cache and a new ARP exchange becomes necessary before further communication with the corresponding interface can occur.

Because ARP uses a broadcast mechanism to communicate, all systems in the broadcast domain see ARP traffic and must therefore process those broadcasts. Even though a workstation or device might not be the intended ARP request recipient, it must decode these incoming packets to determine whether its IP address matches the broadcast target. If ARP traffic increases as a network grows, it can eventually degrade overall network performance. ARP traffic on a class C (/8) network might be trivial for a device to process, but on a single class A (/24) or B (/16) network, any single device could see thousands of ARP packets per second. The same is true for CIDR networks where the network portion of the address is 12 bits or greater. ARP traffic can also cause intermittent problems when used indiscriminately by certain software; for example, some network mapping or device management software sweeps IP subnets using ARP as a discovery mechanism. In a recent case, starting a printer administration utility on a class A network generated approximately seven million ARP packets.

A more sinister aspect of ARP traffic is that it can be used as a vehicle for conducting network attacks. ARP can be used to create "man-in-the-middle" attacks where an attacking system fools two other systems into believing that it is the other system in that pair. All traffic between these two systems then flows through the attacker and can be sniffed for sensitive information. Commonly available hacker toolkits make this trivial to set up on a system with access to a local network.

ARP traffic can also be used in MAC address flooding attacks. This attack targets switches and their MAC address tables. By flooding a switch with bogus IP/MAC address combinations, a switch eventually enters flooding mode where all traffic floods out of all ports indiscriminately. Effectively, this turns the switch into a hub and gives attackers access to a larger pool of traffic that they can sniff for sensitive data. Fortunately, port security features on modern switches can recognize and stymie this kind of traffic pattern by discarding high ARP volumes and essentially squelching such traffic.

Increased ARP traffic can be symptomatic of other security problems. The Nimda worm, which spreads via infected email, starts a sweep of IP addresses on the local network as it looks for other systems to target. This process produces copious ARP requests because the worm steps up the subnet class taken from machines it infects and can scan for subnets that might not even exist.

These examples explain why controlling ARP broadcasts must be part of any network traffic management regime. How you accomplish this depends on how you configure the network. A first step might be to implement VLANs on local switches if they're not already in place. Using VLANs reduces the size of broadcast domains on a network and helps mitigate the impact of excessive ARPing.

You could fine tune a system's ARP cache so that entries persist longer than the default timeout settings of 2 minutes for new cache entries and 10 minutes each time a cache entry is referenced. Increasing this time for systems that communicate primarily with statically addressed systems (gateways, printers, servers, and so forth) produces far fewer ARP requests. In fact, most systems that provide network services rarely, if ever, change their network addresses aside from occasional hardware changes or upgrades.

You could also enter static address entries into a system's ARP cache. These entries never require ARP broadcasts and are immune from poisoning because they cannot be overwritten by broadcast information. You can input cache information at boot time via a batch file retrieved from a local server. This centralizes administration to some extent, but requires additional work to implement and maintain. Such methods might be difficult to administer on large networks, but might apply to systems in areas more exposed to the public, namely, conference rooms, lobbies, or wireless networks.

The best way to mitigate risks associated with ARP is to use "port security" features that most switch manufacturers provide. These features allow administrators to tie pre-defined MAC addresses to certain ports and thereby lock unknown systems out. This prevents internal black-hat users from plugging in laptops loaded with hacking and sniffing tools and mounting attacks that might use ARP for nefarious purposes.

It is a good idea to monitor ARP traffic for volume and activity. You can monitor ARP traffic volumes using a protocol analyzer or track ARP activity using a freeware tool such as ARPWatch. Numerous Linux versions are available as is a Windows version named WinARP Watch. ARPWatch monitors IP/MAC address pairings and notifies administrators when new pairings appear on the network. ARP monitors such as XArp refine this capability by reporting only on new or changed ARP pairings.

The right combination of monitoring and address resolution protocol traffic management (static cache entries and turning on switch port security settings where applicable) can help keep traffic volumes down and security levels up. Investigate these options for your networks and use those that fit your needs.