ARP design

Request

As outlined above, the requirement of ARP is to convert a protocol address to a MAC address. In the following examples, the sender will have the IP address 10.0.0.1 and the destination will have the IP address 10.0.0.2. We can imagine such a query to be of the following form:

Who is 10.0.0.2? Tell 10.0.0.1.
Now, this is addressed to everyone in the network. If no one responds within a timeout, then an appropriate action can be taken.

Once again, there seems to be a chicken/egg problem. The source puts in its protocol address (10.0.0.1) in the request. How will it reply to the host, if it doesn't have its MAC address? This problem can be resolved in two ways.

Since the host which is issuing the request has to fill in its SOURCE address in the packet, we can infer the sender's MAC address from the packet's SOURCE.
Attach the source address along with the request.
For a couple of reasons, (2) is preferred over (1). This decision, I believe, was made keeping the consideration that the Address Resolution should be independent of whether we run Ethernet II, or FDDI, or Ethernet I or any other protocol. So, the source hardware address is embedded inside the ARP request itself. However, to account for different sizes in the hardware address (6 bytes for Ethernet), a hardware address size is also included. Once again, the protocol address needn't be an IP address. It can be something else too. So, the protocol address size is also included in the request.

To summarize, the following fields are present in an ARP packet.

Field Description
opcode Are we requesting or replying to a request?
hwlen The hardware address length -- 6 bytes in Ethernet
protolen The protocol address length
srchw The source hardware address
dsthw The destination hardware address. It will be 00:00:00:00:00:00 in the case of a request
srcproto The source protocol address
dstproto The destination protocol address
The actual structure of the ARP packet can be seen in this website.

http://www.networksorcery.com/enp/protocol/arp.htm
The above request can be easily visualized as follows.


A sample ARP Request packet, dissected.2

Reply

The concerned host will see the request, and reply with its MAC address embedded in a ARP-Reply packet. The reply can be thought of as:

10.0.0.2 is at 55:44:33:22:11:00
addressed to 00:11:22:33:44:55. The corresponding packet fields will not be hard to see, given the ARP packet structure.

Layer 2 Attacks

We have discussed a lot of pre-requisites. Now, it's time to delve into the details of the attack. We will first look at what kind of attacks are possible at this layer of the protocol stack and then look at ways to detect and if possible, prevent these attacks.

One of the most common attacks that is possible at any level in the protocol stack is a Denial of Service. It can be caused either due to excessive flooding of packets, causing loss of bandwidth and CPU time (consumed in processing the packets). Other attacks cleverly manipulate the fields present in the ARP packet to their advantage. Remember, the intelligence of the Internet/Intranet is at the end hosts.

One such clever manipulation leads to an attack called ARP Spoofing. Since the addresses are filled by the host, they can be filled with arbitrary values. These manipulations can lead to various kinds of attacks.

Denial of Service (DoS)

Suppose I am an attacker, masquerade and reply to the ARP request that is not for me; the source will send packets to me. But, I will inspect the packets and just drop them, leading to a DoS for the source.

Man in The Middle (MiTM)

Say I am an attacker. A DoS can raise suspicion even to a naive user. So, I decide to spy on the packets that are incoming, and forward them to the actual destination. The actual sequence of events will be as follows:

1. Source: Who has 10.0.0.2? Tell 10.0.0.1
2. Attacker: Who has 10.0.0.2? Tell 10.0.0.3
3. Dest: 10.0.0.2 is at 55:44:33:22:11:00 (to 10.0.0.3)
4. Attacker: 10.0.0.2 is at de:ad:de:ad:de:ad (to 10.0.0.1)

So, the packets from *Source* are sent to *Attacker*,
instead of *Dest*. *Attacker* can play the role of a relay,
forwarding the packets so that the chain is completed. For
this, the attacker needs to know the MAC Addr of the
*Dest*. Hence, we need something like request (2).
Note that this is possible only if the attacker somehow traps the first request and prevents Dest from seeing the actual request. This may not be always possible, and we will see how this limitation can be overcome by the attacker.

Gratuitous ARP

There is a feature in ARP that was introduced, so that everyone in the network can update their ARP caches (or, ARP tables) for your computer. That method was called a Gratuitous ARP.

gratuitous
adjective.

uncalled for; lacking good reason; unwarranted
given or done free of charge
This special ARP packet, when broadcasted, causes all machines to update the ARP caches for the host (which is supplied by the srcproto field in the packet) to the MAC address pointed to by the srchw field of the packet. This can be dangerous! Fortunately, since this packet is a broadcast packet, it can also be seen by that host which the attacker wants to spoof as. So, the host can take necessary action to counter such an attack. However, note that nothing stops the attacker from sending a Gratuitous ARP addressed to a specific host, even though this isnt' part of the specification! This can be done by modifying the destination address in the Ethernet frame.

Now, we will see how to detect the above mentioned attacks.

Detection

The only way to detect such attacks is to monitor the network for suspicious activity. Since it is quite unlikely that the attacker would have been there all the time, a sudden change in the MAC address of the destination indicates a possible attack scenario.

Careful!

The above method can lead to a false positive situation, wherein there are two hosts on the network with the same IP address. In that case, both the hosts will reply to a request and this will cause a problem. In fact, this method is used by operating systems to detect duplicate IP addresses on the network. Windows usually pops up a ballon with a crib message.

This method will also fail if we have a segmented network. I presume that you have been introduced to concepts of Networks, Sub-Networks, Netmasks and Gateways. If not, please check the following page for a nice explanation of the same.

http://www.tcpipguide.com/free/t_SegmentsNetworksSubnetworksandInternetworks.htm
If we place an ARP Request for the hardware address of a host which is not physically on our network, the gateway will respond to the request with its physical address. This will happen for all addresses not in our network. But, this is not an attack scenario, even though the gateway is a perfect example of a Man in The Middle.

Protection

Since ARP spoofing can lead to possible leakage of sensitive information, we should be able to take preventive measures against it. One way is to use Intrusion Detection Systems (like netrakshini :D, which will be available soon) and stop the work if there is a warning of an attack taking place.

ARP replies are cached for a particular period of time. That is done to avoid an ARP request for every single packet that is transmitted! Otherwise, the network will be flooded with ARP requests and replies. Now, if we are sure of the first ARP reply, we could set the cache time to Infinity; essentially telling the OS that the MAC address of the destination will never change.

List of some software that help protect/detech ARP spoofing.

Arpwatch

ftp://ftp.ee.lbl.gov/arpwatch.tar.gz
http://www-nrg.ee.lbl.gov/
A *nix program that listens for ARP replies on the network and emails the concerned user of any changes.

anti-arpspoof

http://sync-io.net/Sec/anti-arpspoof.aspx

This program creates static ARP entries.

netrakshini

Coming soon!

Will feature tools to detect ARP spoofing

Alternatives

Another method of protection/prevention is to stop using ARP! Can we do without ARP? Is it absolutely needed?

Yes and no. Some kind of address resolution is definitely needed, to know the destination MAC address. However, it need not be ARP. I have not yet fully understood the alternatives and so, it is quite difficult for me to describe them. We have already seen one such way -- avoid ARP by using static MAC addresses.

IPv6, the next generation Internet Protocol avoids ARP. It uses a special mode of operation called Neighbour Discovery to find out the hardware address of the destination. However, that is a discussion for another time.

Conclusion

In this document, we saw that though ARP is essential, it can be easily exploited to launch attacks. They can be stopped by using various methods outlined. There are other ways to stop it, which I haven't touched upon in this article. You could see the following references for more information about ARP spoofing in general.