Address Resolution Protocol (ARP) for Company Networks

ARP (Address Resolution Protocol) is a procedure for connecting an always-changing IP (Internet Protocol) address to a fixed machine or MAC (media access control) address.

ARP maps IP addresses to MAC addresses so that data packets can find their way to the correct destination within a local network. It helps different devices on the same network segment communicate effectively. 

How ARP works

ARP enables devices to efficiently discover and talk to each other within the same local network. Without ARP, the process of sending packets out would be much slower and cumbersome.

Imagine you’re emailing a colleague in the same office. Your computer knows the colleague’s IP address, but it needs their device’s MAC address to send the email effectively within the local network. That’s where ARP steps in. 

Your computer sends an ARP request, asking, “Who has this IP address?” Every device on the network segment hears this request. The device with the colleague’s IP address responds with its MAC address. Now, your computer can wrap the email in the correct ‘envelope’ and send it directly to their machine.

Remember, when a device joins a network it gets an IP address it uses to route and transmit data packets over the internet, as well as a MAC address that identifies it and which it uses for local communication within a network. ARP uses a device’s IP address to identify a MAC address and streamline the transmission of data packets and messages.

ARP request and reply

When a host needs to determine the MAC address of a destination, it sends an ARP request. This happens after the node checks its ARP table and finds that the address is unknown. 

The host crafting the ARP request packet will fill in the known addresses: the sender's own IP and MAC addresses, and the target's IP address. The unknown destination MAC address is set to all zeros. This request packet is then broadcast to the entire local network, ensuring that every connected device sees it.

For example, imagine a host with IP address 192.168.1.1 and MAC address 00:14:22:01:23:45 needs to communicate with another device at IP address 192.168.1.254, but it doesn't know the corresponding MAC address. The ARP request will include:

• Sender MAC address: 00:14:22:01:23:45
• Sender IP address: 192.168.1.1
• Target IP address: 192.168.1.254
• Target MAC address: 00:00:00:00:00:00 (unknown)

This ARP request is sent to the broadcast address FF:FF:FF:FF:FF:FF, making sure all devices on the same local network receive the packet.

When the device with IP address 192.168.1.254 gets this packet, it recognizes its IP address in the target field and responds with an ARP reply. This reply contains its MAC address, completing the necessary information for the original sender. Let's say the responding device's MAC address is 00:19:55:35:1A:D0. The ARP reply will include:

• Sender MAC address: 00:19:55:35:1A:D0
• Sender IP address: 192.168.1.254
• Target MAC address: 00:14:22:01:23:45
• Target IP address: 192.168.1.1

This ARP reply packet is unicast directly back to the original requester, bypassing other devices on the network. Once the original sender receives this reply, it updates its ARP table with the new entry, enabling it to direct further packets to the correct MAC address without needing to re-ARP.

For example, the ARP table update would look something like this:

Internet Address      Physical Address      Type

192.168.1.254         00-19-55-35-1A-D0     dynamic

With this information now cached, any future packets sent to 192.168.1.254 will include the correct MAC address, significantly speeding up communication. 

ARP cache

An ARP cache is a collection of Address Resolution Protocol (ARP) entries. These entries are mostly dynamic and get created when an IP address is resolved to a MAC address. 

Why is this important? Without an ARP cache, a computer can't communicate effectively with the IP address it's trying to reach. 

For example, if your computer wants to send data to an external server, it first checks the ARP cache to see if it already has the server's MAC address. If it does, the data is sent immediately. If not, an ARP request is sent out to find the MAC address, and then the ARP cache gets updated.

Now, here’s where it gets a bit tricky. An ARP cache can be a double-edged sword. While it streamlines communication, it can also be exploited. Hackers can use this to their advantage through what's known as ARP cache poisoning. 

However, it’s not all doom and gloom. ARP caches also have measures to prevent these kinds of attacks. They can distinguish between low-level IP and IP-based vulnerabilities, offering another layer of security. 

For instance, some advanced network security systems use routing trace-based techniques to prevent ARP spoofing attacks, identify inconsistencies, and take action before any real damage happens. 

In practical terms, if you are on a Windows machine and notice network issues, you might flush the ARP cache to clear outdated or incorrect entries. This is done using the command prompt with a simple command: `arp -d`. This clears the cache and forces the computer to rebuild it as needed, which can resolve some connectivity issues.

ARP application scope and management

ARP isn't limited to just Ethernet networks. It's versatile and works with various network types like Token Ring and ATM. But Ethernet is where it shines due to its ubiquity. 

Every device on an Ethernet network has a unique MAC address, hardcoded during manufacture, ensuring that data packets reach their correct destination.

The dynamic nature of IP addresses adds another layer of complexity. Devices can get their IP addresses assigned either manually or dynamically via DHCP. 

Therefore, static mappings between IP and MAC addresses wouldn't be practical. ARP handles this beautifully by constantly updating its mappings as devices join and leave the network or change IP addresses.

ARP cache timeout and entries

The entries in an ARP cache don't last forever. They have a limited lifetime and will be deleted unless they get refreshed. Typically, an ARP entry's lifetime is about 2 minutes. 

However, there are cases where ARP caches last much longer, even up to 20 minutes. It's a good idea to check how long your system keeps these entries. For instance, on a Linux system, you might notice that ARP entries get removed automatically after a specific amount of time.

Refreshing the ARP cache is crucial. Even if an entry exists in the ARP cache, the system occasionally sends out ARP requests to ensure that the information is still valid. 

This mechanism ensures that the ARP cache entries are up-to-date and helps prevent stale or incorrect mappings. It's a straightforward yet effective way to maintain accurate network communications.

The role of ARP in different networking topologies

Address Resolution Protocol (ARP) plays various roles depending on the network topology. For instance, in a broadcast LAN setup with serial connections like dial-up or VPN, ARP helps to seamlessly integrate remote nodes into the subnet. 

Another role ARP plays is in scenarios where a server needs multiple IP addresses. An example is where a server with an IP address 10.0.0.2 is connected to a network 10.0.0.0/24. Applications requiring multiple IP addresses on this server can use proxy ARP. 

Additional addresses like 10.0.0.230-10.0.0.240 are aliased to the server's loopback or other interfaces. The server ‘publishes’ these addresses on its main interface. This allows the server to handle traffic as if these additional IP addresses were directly assigned to its main interface.

Firewall implementations also benefit from ARP. For instance, a firewall with a single IP address can protect a server or group of servers on a subnet. If a network (10.0.0.0/8) has a server (10.0.0.20) that needs protection, a firewall using proxy ARP can be placed in front of the server. 

This configuration means the firewall responds to ARP requests for 10.0.0.20. Traffic is then routed through the firewall, providing an additional security layer without changing the network configuration.

In mobile IP scenarios, the Home Agent utilizes ARP to intercept traffic meant for a Mobile Node. The Home Agent responds to ARP requests on behalf of the Mobile Node, allowing it to forward messages to the Mobile Node’s current address, known as the Care-of address. This supports seamless mobility without breaking active connections.

Finally, ARP is used for redundancy in broadcast networks like Ethernet through protocols such as the Common Address Redundancy Protocol (CARP) and the Virtual Router Redundancy Protocol (VRRP). 

These protocols ensure network availability by allowing multiple devices to share a single IP address, with one device taking over if another fails. Proxy ARP helps in these setups by managing ARP requests to ensure traffic is directed to the active device.

In all these topologies, ARP serves as a critical mechanism for maintaining network communication and connectivity, adapting to various scenarios effectively.

ARP Traffic Management

Managing ARP traffic in enterprise networks is crucial for maintaining optimal performance and preventing network issues. 

First off, ARP broadcasts can sometimes flood the network, especially in larger enterprise environments. This happens because ARP requests are broadcast to all devices in the network segment. 

For example, in a subnet with 250 devices, an ARP request from one device is sent to all 250 devices. If not managed properly, this can lead to excessive broadcast traffic, slowing down the network. 

To mitigate this, we can use techniques like ARP caching. Devices store ARP responses in their cache, so they don’t have to broadcast a request each time they need to resolve an IP address. For instance, a device might cache an ARP response for a few minutes or even longer, depending on the network configuration.

ARP rate limiting

By controlling the rate of ARP requests, you can prevent any single device from overwhelming the network with ARP traffic. Rate limiting can prevent a misconfigured or faulty device that is spamming ARP requests from affecting overall network performance. Most enterprise-grade switches and routers allow setting limits on the number of ARP requests per second from a single port or device.

Network segmentation

We can also segment the network using VLANs to contain ARP broadcasts within smaller, more manageable broadcast domains. For example, instead of having one large network segment with 500 devices, we can create five VLANs with 100 devices each. 

ARP requests are then broadcast within each VLAN, significantly reducing the overall ARP traffic. This not only improves ARP efficiency but also enhances security and performance across the enterprise network.

Risks associated with ARP

ARP spoofing/poisoning

ARP spoofing, or ARP poisoning, is a sneaky tactic used by attackers to trick the network. They send false ARP messages, linking their MAC address to the IP address of another device, like a server or a gateway. This way, they can intercept, modify, or even stop data intended for that IP address.

Attackers use tools like Ettercap or Arpspoof to launch ARP spoofing attacks. These tools flood the network with fake ARP requests or replies, ensuring that they become the “owner” of whichever IP they target. Once they control the ARP tables, they can launch further attacks.

Man-in-the-Middle (MITM) Attacks with ARP

Picture yourself in your office, happily sending an email to a colleague. You're assuming this traffic goes directly from your machine to your colleague's. But what if someone intercepts it?

With ARP, this scenario represents a legitimate threat. Attackers can exploit the ARP protocol to position themselves between two communicating devices without either party knowing. Essentially, the attacker sends fake ARP messages to the network. These messages associate the attacker's MAC address with the IP address of a legitimate device, like your default gateway.

What's terrifying is how stealthy this can be. The attacker can forward your traffic to the real gateway after eavesdropping on it, making everything seem normal to you. You think your email went straight to your colleague, but it took a detour through the attacker's device, where it could have been read, altered, or even saved for later.

In an enterprise network, the stakes are high. Corporate secrets, sensitive employee information, and financial transactions are constantly zipping around. A successful MITM attack could cause catastrophic data breaches and lead to massive financial loss or reputation damage.

Detecting these attacks isn't always straightforward. Network administrators often rely on tools like Intrusion Detection Systems (IDS) to monitor for unusual ARP traffic or inconsistencies in ARP tables. But the best defense is a good offense: implementing security measures like dynamic ARP inspection (DAI) or using encrypted communication protocols to minimize the risk of MITM attacks.

Static ARP Entries

By default, a device responds to an ARP request only if the destination address is on the local network of the incoming interface. 

However, for Fast Ethernet or Gigabit Ethernet interfaces, you can configure static ARP entries that associate IP addresses of nodes on the same Ethernet subnet with their MAC addresses. This enables the device to respond to ARP requests even if the destination address isn't local to the incoming Ethernet interface.

Unlike dynamically learned ARP entries, static ARP entries don't age out. This is particularly handy in troubleshooting situations or when the device can't learn a MAC address dynamically. For example, you can configure static ARP entries to ensure communication between critical devices without the risk of those entries expiring.

One important note is that by default, an ARP policy is installed and shared among all Ethernet interfaces with the `family inet` statement configured. If needed, you can apply a specific ARP-packet policer to an interface using the `arp` statement at the `[edit interfaces interface-name unit logical-unit-number family inet policer]` hierarchy level. 

How to stop ARP spoofing with Dynamic ARP Inspection (DAI)

To prevent ARP poisoning attacks, a switch must ensure only valid ARP requests and responses are relayed. DAI stops these attacks by intercepting all ARP requests and responses. It checks each intercepted packet for valid MAC to IP address bindings before updating the local ARP cache or forwarding the packet. If the ARP packet is invalid, it's dropped.

Trusted databases to determine the validity of an ARP packet. 

A trusted database is built at runtime through DHCP snooping, which must be enabled on the VLANs and the switch. Additionally, DAI can validate ARP packets against user-configured ARP ACLs to handle hosts with static IP addresses.

For instance, in a typical network setup, you can configure all host-connected ports as untrusted and all switch-to-switch ports as trusted. Let's say hosts HA and HB are on the same subnet and connected to the switch via interfaces A and B. 

If HA needs to communicate with HB at the IP layer, HA broadcasts an ARP request for HB's MAC address. HB then responds with its MAC address, updating HA's ARP cache with the correct binding.

Consider a malicious host, HC, on the same network. HC can poison the ARP caches of both HA and HB by sending forged ARP responses with its MAC address. DAI prevents this by verifying each ARP packet's bindings against the trusted database. If HC sends an ARP response claiming to own HB's IP address but with its own MAC address, DAI detects the inconsistency and drops the packet.

Dropping mismatched MAC addresses

DAI can also be set up to drop ARP packets with invalid IP addresses or mismatched MAC addresses in the packet and Ethernet header. This additional validation layer ensures that even if a packet slips through, it gets caught and discarded based on these discrepancies.

Configuring trust states

You can also configure trust states on interfaces based on their roles. Trusted interfaces bypass all DAI checks, while untrusted interfaces undergo strict validation. 

For example, in a network with two switches, S1 and S2, I set up interfaces connected to hosts as untrusted. The interface between S1 and S2 is trusted, ensuring all ARP packets from a host pass the security checks before entering the network.

To illustrate further, suppose H1 and H2 are connected to S1 and S2, respectively. Both switches run DAI on VLAN 1, where the hosts reside. The interface connecting S1 and S2 (fa6/3 on S1 and fa3/3 on S2) should be configured correctly.

If fa3/3 on S2 isn't trusted, ARP packets from H1 may be dropped, disrupting connectivity. Hence, it's critical to configure trust states carefully.

When you use ARP ACLs for validation, these have precedence over DHCP snooping entries. If an ARP ACL denies a packet, it's dropped even if there's a valid entry in the DHCP snooping database.

Logging denied packets

DAI also supports logging denied packets. It maintains a log of all invalid ARP packets, and you can configure it to control the rate of log messages, ensuring efficient monitoring. 

Moreover, DAI implements rate limiting to protect against denial-of-service attacks. For untrusted interfaces, the rate is set to 15 packets per second by default, whereas trusted interfaces have no rate limit. 

If this rate is exceeded, the port enters the errdisable state until an administrator intervenes. Automatic recovery can be enabled to bring the port back online after a specified timeout. 

When dealing with port channels, the trust state of the first physical port joining a channel defines the channel's trust state. Any physical port joining the channel must match this trust state. 

The rate limit applied to a port channel is cumulative across all its physical ports, ensuring efficient handling of ARP traffic across the network.