Prevention of ARP Spoofing using Cryptographic Techniques

Submitted in partial fulfillment of the requirements of

BITS G629 Dissertation

By

B Gautam K Varma
ID NO. 2010H112035G
Under the supervision of

Dr. S K Sahay
Assistant Professor, CS & IS Department

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE, PILANI

K. K. BIRLA GOA CAMPUS
APRIL 2012

CERTIFICATE

This is to certify that the Dissertation entitled, Prevention of ARP Spoofing using
Cryptographic Techniques and submitted by B Gautam K Varma, ID No.2010H112035G in
partial fulfillment of the requirement of BITS G629T Dissertation embodies the work done
by him under my supervision.

Date

Signature of the Supervisor

Dr. S K Sahay
Assistant Professor, CS & IS Department

II

ABSTRACT

Dissertation Title:

Prevention of ARP Spoofing using Cryptographic Techniques

Supervisor:

Dr. S K Sahay

Semester:

Second

Name of Student:

B Gautam K Varma ID No.: 2010H112035G

Year: 2011 2012

Abstract: Address Resolution Protocol (ARP) is the most important protocol for host
communication within a Local Area Network. ARP Spoofing or Cache Poisoning pose some
serious problems to the protocol by wrongly associating IP addresses to the MAC addresses
of malicious hosts, thus giving way to a wide range of attacks such as Denial of Service
(DoS) attacks and Man In Middle (MiM) attacks. This work looks into the aspects of
prevention of ARP spoofing by different mechanisms which include detection of spoofing
using tools, modification of DHCP protocol and various cryptographic solutions to ensure
authenticity to ARP replies.

III

Table of Contents

Abstract
. iii
Table of Contents . iv
List of Figures v
1. Introduction 1
1.1. The Address Resolution Protocol ... 1
1.2. Message Format of ARP . 2
1.3. Working of ARP . 3
1.4. ARP Spoofing and Cache Poisoning .. 5
2. Cryptographic Techniques in Prevention of ARP Spoofing ..... 7
2.1. Challenge Response Authentication .............................. 7
2.2. One Way Hashes

......................... 9

2.3. One Time Passwords ...... 11

2.4. Digital Signatures ............... 14

3. Other Methods in Securing ARP ..................................................................... 21

3.1. Detection using Tools .............................................................................. 21
3.2. Static Binding and Stateful Cache ........................................................... 23
3.3. Modification of the DHCP ...................................................................... 25
4. Conclusion . 28
References .. 29

IV

List of Figures

Figure 1: ARP Message Format ............................................................................ 2

Figure 2: ARP Multicast request and Unicast Reply ............................................ 4
Figure 3: Using Hash Function to authenticate ARP replies ................................ 10
Figure 4: S/KEY based OTP ................................................................................. 13
Figure 5: Using OTP to authenticate ARP replies ...............................................

14

Figure 6: Digital Signatures using public key encryption .................................... 16

Figure 7: Using Digital Signatures to authenticate ARP replies .......................... 17
Figure 8: Authenticating ARP replies using tickets ......... 19
Figure 9: Authenticating ARP replies using Digital Signatures and OTP ... 20

1. Introduction
Local Area Networks running TCP/IP over Ethernet are the most common
networks these days. Each host on such a network is assigned an IP address (32 bits).
Hosts also possess a network interface card (NIC) having a unique physical address (48
bits) also called the MAC address. For the final delivery of any packet destined to some
host, its MAC must be known to the sender. Thus, the Address Resolution
Protocol(ARP) is used to resolve an IP address into a MAC address. Resolved addresses
are kept in a cache so as to avoid unnecessary work for already resolved addresses every
time they are needed. Resolution is invoked only for entries expired or absent from the
cache, otherwise cache entries are used.

1.1 The Address Resolution Protocol:

Hosts and applications in a network work with domain names which are
converted to the IP address by a DNS server. But once packets containing application
data arrive on the local Ethernet network of the host, they can be transmitted only if the
MAC address present in the NIC of the destination host is known to the switch. Thus a
conversion is needed from IP addresses to MAC addresses and vice versa. This
conversion is done by the Address Resolution Protocol or ARP in short [1].
ARP works as follows. When a host needs to send an IP datagram as an
Ethernet frame to another host whose MAC address it does not know, it broadcasts a
request for the MAC address associated with the IP address of the destination. Every
host on the subnet receives the request and checks if the IP address in the request is
bound to one of its network interfaces. If this is the case, the host with the matching IP
address sends a unicast reply to the sender of the request with the <IP address, MAC
address> pair. Every host maintains a table of <IP, MAC> pairs, called the ARP cache,
based on the replies it received, in order to minimize the number of requests sent on the
network. No request is made if the <IP, MAC> pair of interest is already present in the
cache. ARP cache entries have a typical lifetime of 20 minutes, after which the entry
should be refreshed.
1

1.2 Message format of ARP:

The format of ARP message is as follows

Figure 1: ARP Message Format

Following are the fields in the Address Resolution Protocol (ARP) Message Format.
Hardware Type: Hardware Type field in the Address Resolution Protocol (ARP)
Message specifies the type of hardware used for the local network transmitting the
Address Resolution Protocol (ARP) message. The value for Ethernet is 1. The size of
this field is 2 bytes.
Protocol Type: Each protocol is assigned a number used in this field. IPv4 is 2048
Hardware Address Length: Hardware Address Length in the Address Resolution
Protocol (ARP) Message is length in bytes of a hardware (MAC) address. Ethernet
addresses are 6 bytes long.
Protocol Address Length: Length in bytes of a logical address. IPv4 addresses are 4
bytes long.
Opcode: Opcode field in the Address Resolution Protocol (ARP) Message specifies the
nature of the ARP message. 1 for ARP request and 2 for ARP reply.

Sender Hardware Address: Layer 2 (MAC Address) address of the device sending the
message.
Sender Protocol Address: The protocol address (IP address) of the device sending the
message
Target Hardware Address: Layer 2 (MAC Address) of the intended receiver. This field
is ignored in requests.
Target Protocol Address: The protocol address (IP Address) of the intended receiver.

1.3 Working of ARP:

The following steps are involved in the working of Address Resolution Protocol
Step 1: When a source device wants to communicate with another device, source device
checks its Address Resolution Protocol (ARP) cache to find it already has a resolved
MAC address of the destination device. If it is there, it will use that address for
communication. To view your Local Address Resolution Protocol (ARP) cache, Open
Command Prompt and type command "arp -a" (Without double quotes using Windows
Operating Systems).
Step 2: If ARP resolution is not there in local cache, the source machine will generate an
Address Resolution Protocol (ARP) request message, it puts its own data link layer
address as the Sender Hardware Address and its own IP address as the Sender Protocol
Address. It fills the destination IP address as the Target Protocol Address. The Target
Hardware Address will be left blank, since the machine is trying to find that.
Step 3: The source broadcast the Address Resolution Protocol (ARP) request message to
the local network.
Step 4: The message is received by each device on the LAN since it is a broadcast. Each
device compare the Target Protocol Address (IP Address of the machine to which the
source is trying to communicate) with its own Protocol Address (IP Address). Those
who do not match will drop the packet without any action.

Step 5: When the targeted device checks the Target Protocol Address, it will find a
match and will generate an Address Resolution Protocol (ARP) reply message. It takes
the Sender Hardware Address and the Sender Protocol Address fields from the Address
Resolution Protocol (ARP) request message and uses these values for the Targeted
Hardware Address and Targeted Protocol Address of the reply message.
Step 6: The destination device will update its Address Resolution Protocol (ARP) cache,
since it need to contact the sender machine soon.
Step 7: Destination device send the Address Resolution Protocol (ARP) reply message
and it will not be a broadcast, but a unicast.
Step 8: The source machine will process the Address Resolution Protocol (ARP) reply
from destination, it store the Sender Hardware Address as the layer 2 address of the
destination.
Step 9: The source machine will update its Address Resolution Protocol (ARP) cache
with the Sender Hardware Address and Sender Protocol Address it received from the
Address Resolution Protocol (ARP) reply message.

Figure 2: ARP Multicast request and Unicast Reply

4

1.4 ARP Spoofing and Cache Poisoning:

ARP Spoofing or ARP Cache Poisoning is the technique in which a hosts
cache is modified to add an incorrect IP, MAC mapping to its ARP cache. Since each
host presumes its local cache to be trustworthy, the poisoned host will send IP packets
encapsulated into Ethernet frames with a bogus MAC address as destination.
In an ARP spoofing, the attacker sends ARP replies with fake <IP;MAC>
mappings, in an attempt to poison the ARP cache of other host(s) on the network. For
example, if the attacker wants to impersonate host X so that host Y sends data destined
to X to the attacker instead, the attacker can send an ARP reply indicating that the host
with the IP x.x.x.x has the MAC mm:mm:mm:mm:mm:mm (the MAC address of the
attacker). Since ARP is an stateless protocol, the receiver will gladly update its ARP
cache with the <IP;MAC> pairing received. Furthermore, some operating systems may
even update static cache entries with information received from unsolicited ARP
replies[2].
Even if ARP is configured to be stateful, an attacker can still perform an ARP
spoofing attack by sending a fake ICMP (Internet Control Message Protocol) echo
request to Y indicating it comes from X, but using the MAC address of the attacker.
Depending on the implementation, the operating system can either use the <IP;MAC>
pairing inferred from the received Ethernet frame and ICMP packet, or it can issue an
ARP request to learn the mapping (before sending the ICMP echo reply). In the latter
case, the attacker can instantly reply to the ARP request, poisoning the cache.
The ARP poisoning attacks just described are often used as part of other serious attacks:
DoS attacks: An attacker can poison an ARP table of a host so that every packet that the
host sends is sent to the attacker instead of its real destination. In this way, the attacker
blocks the communication from the host being attacked.
Host impersonation: Instead of just dropping the packets received from the host being
attacked, the attacker can respond, impersonating any host in the network.
5

Man-in-the-middle (MITM) attacks: By spoofing two hosts in the network at the same
time, an attacker can silently sit in between the two hosts so that they think they are
communicating with each other. This attacker is then able to listen to all the traffic sent
in both directions. This attack can also be performed between any host in the LAN and
an outside host, as the attacker can perform the attack between the host and the default
gateway. With a MITM attack, the attacker can gain access to sensitive information
(e.g., passwords) or he/she can even modify the data being sent, compromising the
datas integrity.
Note that these attacks are not restricted to Ethernet networks. Hosts using
other Layer 2 protocols like 802.11 are also susceptible to ARP poisoning attacks.

2. Cryptographic Techniques in Prevention of ARP

Spoofing
The main problem with Address Resolution Protocol (ARP) is that, in its
unmodified implementation, it accepts the ARP replies from sender without
authenticating the message. Hence, an attacker will be able to send its own malicious
reply and host accepting it, resulting in the poisoning of its cache or ARP spoofing.
Cryptographic techniques like Hashing, Digital Signatures and One Time
Passwords (OTP) can be used along with challenge response protocols to authenticate
the reply received from a particular host. Thus the host will be able to differentiate
between a legitimate host and malicious host hence preventing itself from ARP attacks.

2.1 Challenge Response Authentication:

Challenge-response authentication is a family of protocols in which one party
presents a question ("challenge") and another party must provide a valid answer
("response") to be authenticated. The most common example of a challenge response
system is the password authentication. The server challenges the user to provide with the
correct user name and password, the client responds with the right answer, which is the
correct password. In simple terms, Challenge-Response Authentication (CRA) [12] is a
method for proving your identity over an insecure medium without giving any
information out to eavesdroppers that may enable them to identify themselves as you.
Non-cryptographic authentication is sufficient in a scenario where nobody is
likely to be eavesdropping on the communication channel to observe the password being
entered. So, the insecure channel problem is to be addressed, One way this is done
involves using the password as the encryption key to transmit some randomly-generated
information as the challenge, whereupon the other end must return as its response a
similarly-encrypted value which is some predetermined function of the originally7

offered information, thus proving that it was able to decrypt the challenge. For instance,
in Kerberos, the challenge is an encrypted integer N, while the response is the encrypted
integer N + 1, proving that the other end was able to decrypt the integer N. In other
variations, a hash function operates on a password and a random challenge value to
create a response value.
Such encrypted or hashed exchanges do not directly reveal the password to an
eavesdropper. However, they may supply enough information to allow an eavesdropper
to deduce what the password is, using a dictionary attack or brute-force attack. The use
of information which is randomly generated on each exchange (and where the response
is different from the challenge) guards against the possibility of a replay attack, where a
malicious intermediary simply records the exchanged data and retransmits it at a later
time to fool one end into thinking it has authenticated a new connection attempt from the
other.
Authentication protocols usually employ a cryptographic nonce as the
challenge to ensure that every challenge-response sequence is unique. This protects
against a replay attack. If it is impractical to implement a true nonce, a strong
cryptographically secure pseudorandom number generator and cryptographic hash
function can generate challenges that are highly unlikely to occur more than once. It is
important not to use time-based nonces, as these can weaken servers in different time
zones and servers with inaccurate clocks.
Mutual authentication is performed using a challenge-response handshake in
both directions; the server ensures that the client knows the secret, and the client also
ensures that the server knows the secret, which protects against a rogue server
impersonating the real server.

2.2. One way Hashes:

A cryptographic hash function is an algorithm that takes an arbitrary block of
data and returns a fixed-size bit string, the (cryptographic) hash value, such that a
change to the data will definitely change the hash value. The data to be encoded is often
called the message digest. The ideal cryptographic hash function has four main or
significant properties:

It is easy to compute the hash value for any given message

It is infeasible to generate a message that has a given hash

It is infeasible to modify a message without changing the hash

It is infeasible to find two different messages with the same hash

A cryptographic hash function must be able to withstand all known types of

cryptanalytic attack. As a minimum, it must have the following properties:

Preimage resistance:
Given a hash h it should be difficult to find any message M such that h= hash(M)

Second-preimage resistance:
Given an input message m1, it should be difficult to find another input m2 where
m1m2 such that hash(m1) hash(m2). This property is sometimes referred to as
weak collision resistance

Collision resistance:
It should be difficult to find two different messages m1, m2 such that
hash(m1)=hash(m2). Such a pair is called a cryptographic hash collision. This
property is sometimes referred to as strong collision resistance. It requires a hash
value at least twice as long as that required for preimage-resistance, otherwise
collisions may be found by a birthday attack.

The two most commonly used cryptographic hash functions are MD5 and SHA-1. MD5
digests have been widely used in the software world to provide some assurance that a
transferred file has arrived intact. For example, file servers often provide a pre-computed
MD5 (known as Md5sum) checksum for the files, so that a user can compare the
checksum of the downloaded file to it. Unix-based operating systems include MD5 sum
utilities in their distribution packages, whereas Windows users use third-party
applications.
One way hashes can be used to authenticate the ARP replies in the following
way. Here, each host will be having Passcode(PC), PassNo(PN) combinations for every
other host in the network. These pairs are securely distributed among the hosts. The
process of verification is as shown below

Figure 3: Using Hash Function to authenticate ARP replies

10

Step 1: MAC request is broadcasted in the network by Host1

Step 2: Host2 unicastly replies to Host1 with its MAC address

Step 3: Host 1 challenges Host2 with a Random number and a Pass No. intended
for that particular host.

Step 4: Host2 responds to the challenge by sending the message digest which
includes the random number received, its Pass Code and its MAC address.

Step 5: Host1 computes its own digest from the Pass No., Pass Code information
it has and the MAC address it received earlier.

Step 6: Host1 adds the IP, MAC association to its cache if both the digests are
same; else it will discard the received MAC address.

2.2. One Time Passwords (OTP):

A one-time password (OTP) is a password that is valid for only one login
session or transaction. One-time password systems are designed to counter Replay
Attacks and Key Loggers. Replay attack involves eavesdropping on network
connections to obtain authentication information such as the login IDs and passwords of
legitimate users. Once this information is captured, it can be used at a later time to gain
access to the system. The one time password system uses a secret pass-phrase to
generate a sequence of one-time (single use) passwords, each used only for one
transaction. With this system, the user's secret pass-phrase never needs to cross the
network during authentication. So, if a potential intruder manages to record an OTP that
was already used to log into a service or to conduct a transaction, he or she will not be
able to use it again since it will be no longer valid.
Several tools are available to generate One Time Passwords. Some of them
developed for Unix like systems are OTPW developed by Markus Kuhn which generates
completely random OTPs based on several system variables. Other such tool is OPIE
(One time Passwords In Everything) - An S/Key based authentication system.

11

S/KEY is also a one-time password system developed for authentication to

Unix-like operating systems, especially from untrusted public computers on which one
does not want to type the actual password. S/KEY serves the functionality to thwart any
possible replay attack by making user to use a one-time password for login, so that any
eavesdropping gives useless password information for the attacker as that information is
used for only one time. Added security is provided by the property that no secret
information need be stored on any system, including the host being protected.
S/KEY is also sometimes referred to as Lamport's scheme, after its author,
Leslie Lamport. With the widespread use of computers running SSH and other
cryptographic protocols that can secure an entire session, not just the password, S/KEY
is falling into disuse. SecurID is a related one-time password scheme that still sees
widespread use because, unlike S/KEY, it provides two-factor authentication by
requiring a physical token that cannot be easily reproduced.
There are two sides to the operation of the S/KEY one-time password system.
On the client side, the appropriate one-time password must be generated. On the host
side, the server must verify the one-time password and permit the secure changing of the
user's secret pass-phrase. An S/KEY system client passes the user's secret pass-phrase
through multiple applications of a secure hash function to produce a one-time password.
On each use, the number of applications is reduced by one. Thus a unique sequence of
passwords is generated. The S/KEY system host verifies the one-time password by
making one pass though the secure hash function and comparing the result with the
previous one-time password.

12

Figure 4 : S/KEY based OTP

One time Passwords can therefore be used authenticate the sender in ARP
implementation scenario. Here, each host will be having Pass Key (PK) list for N no. of
transactions for every other host in the network. These Pass Keys will be used as OTP
for every transaction between two particular hosts. These Pass Key lists will be securely
distributed among hosts initially. By using OTPs, we can successfully avoid replay
attacks. The sequence of authentication is as shown below

13

Figure 5: Using OTP to authenticate ARP replies

Step 1: MAC request is broadcasted in the network by Host1

Step 2: Host2 unicastly replies to Host1 with its MAC address

Step 3: Host 1 challenges Host2 with a Pass No. intended for that particular host.

Step 4: Host2 responds to the challenge by sending the Pass Key (PK) for that
particular Pass No.

Step 5: Host1 verifies the Pass Key received to the Pass Key it has in its list.

Step 6: Host1 adds the IP, MAC association to its cache if both the Pass Keys are
same; else it will discard the received MAC address.

14

2.3. Digital Signatures:

A digital signature is a cryptographic scheme for demonstrating the
authenticity of a digital message or document. A valid digital signature gives a recipient
reason to believe that the message was created by a known sender, and that it was not
altered in transit. Digital signatures can be used to authenticate the source of messages.
When ownership of a digital signature secret key is bound to a specific user, a valid
signature shows that the message was sent by that user. Digital signatures also ensure
integrity of the message, because any change in the message after signature will
invalidate the signature. Non-repudiation, or more specifically non-repudiation of origin,
is an important aspect of digital signatures. By this property an entity that has signed
some information cannot at a later time deny having signed it.
In situations where there is not complete trust between sender and receiver,
something more than authentication is needed. The most attractive solution to this
problem is the digital signature. The digital signature is analogous to the handwritten
signature. It must have the following properties:

It must verify the author and the date and time of the signature.

It must to authenticate the contents at the time of the signature.

It must be verifiable by third parties, to resolve disputes.

Digital signatures often use a public key encryption system. Public-key cryptography
refers to a cryptographic system requiring two separate keys, one to lock or encrypt the
plaintext, and one to unlock or decrypt the cypher text. Neither key will do both
functions. One of these keys is published or public and the other is kept private. If the
lock/encryption key is the one published then the system enables private communication
from the public to the unlocking key's owner. If the unlock/decryption key is the one
published then the system serves as a signature verifier of documents locked by the
owner of the private key. Although in this latter case, since encrypting the entire
message is relatively expensive computationally, in practice just a hash of the message is
encrypted for signature verification purposes.
15

Figure 6: Digital Signatures using public key encryption

RSA is the best known, and by far the most widely used general public key
encryption algorithm, and was first published by Rivest, Shamir & Adleman of MIT. It
is the most widely accepted and implemented general-purpose approach to public-key
encryption. It is based on exponentiation in a finite (Galois) field over integers modulo a
prime, using large integers (eg. 1024 bits). Its security is due to the cost of factoring
large numbers.
Digitally signed replies can be exchanged between the hosts to ensure
confidentiality and authenticity. Therefore digital signatures can be used in ARP request
reply scenario to authenticate the ARP replies. One way of doing it is to use asymmetric
cryptography technique. One such case is mentioned here. Each host will be having its
own Public Key (PU) and Private Key (PR) and also the Public Keys of all other hosts
which are distributed securely initially.

16

Figure 7: Using Digital Signatures to authenticate ARP replies

The sequence of authentication is as follows

Step 1: MAC request is broadcasted in the network by Host1

Step 2: Host2 encrypts it MAC and IP association first with its Private Key and
then the Public Key of Host1.

Step 3: Host1 decrypts the message first with its Private Key and then the Public
Key of Host2

It should be noted that only Host1 will be able to read the correct MAC, IP association
as the initial decryption needs its own Private Key, which is available with only Host1.
Thus digital signatures ensure both confidentiality and integrity.
Several solutions that involve cryptography to authenticate the ARP packets
have been proposed. S-ARP [9] proposes a solution to the ARP poisoning problem
based on an extension of the ARP protocol. It introduces a set of functionalities that
enable an integrity and authenticity check on the content of ARP replies, using
asymmetric cryptography. Secure ARP extends ARP with an integrity/authentication
scheme for ARP replies, to prevent ARP poisoning attacks. In order to maintain
compatibility with ARP, an additional header is inserted at the end of the protocol

17

standard messages to carry the authentication information. This way, S-ARP messages
can also be processed by hosts that do not implement S-ARP.
An S-ARP enabled host is identified by its own IP address and has a
public/private key pair. A simple certificate provides the binding between the host
identity and its public key. Besides the host public key, the certificate contains the host
IP address and the MAC address of the Authoritative Key Distributor (AKD), a trusted
host acting as key repository. Each host sends its signed certificate containing the public
key and the IP address to the AKD, which inserts the public key and the IP address in a
local data base, after the network manager's validation.
In S-ARP all reply messages are digitally signed by the sender with the
corresponding private key. At the receiving side, the signature is verified using the host
public key. If the public key of the sender host is not present in the receiving host key
ring or the one in the key ring does not verify the signature, the public key of the sender
is requested from the AKD. The AKD sends it to the requesting host in a digitally signed
message. S-ARP adopted the Digital Signature Algorithm (DSA) as the signature
algorithm.
TARP [10] addresses the lack of authenticity in ARP replies by distributing
centrally generated attestations. These attestations, called tickets, authenticate the
association between IP and MAC addresses through statements signed by the Local
Ticket Agent (LTA). Each ticket encodes a validity period represented as a start time
and an expiration time. Of course, the use of time values assumes some form of loose
clock synchronization between the issuing LTA and the validating clients.
To securely perform address resolution using TARP, a host broadcasts an
ARP request. The host with the requested IP address sends a reply, attaching a
previously obtained ticket. The signature on the ticket proves that the LTA issued it, i.e.,
the IP-to-MAC address mapping is valid (or at least was at the time of issuance). The
requesting host receives the ticket, validating it with the LTAs public key. If the
signature is valid, the address association is accepted; otherwise, it is ignored. With the

18

introduction of TARP tickets, an adversary cannot successfully forge a TARP reply and,
therefore, cannot exploit ARP poisoning attacks.

Figure 8: Authenticating ARP replies using tickets in TARP [10]

Goyal et al. [11] proposes a solution for the prevention of ARP cache
poisoning based on a combination of digital signatures and one time passwords. This
protocol requires periodic generation of digital signatures, the rate of generation being
independent of the number of ARP requests being received. For this, we identify two
different components of an ARP reply, one is the <IP address, MAC address> mapping
and the recency of the mapping. The first component requires a digital signature since
the <IP, MAC> mapping must be authentic and its authenticity must be publicly
verifiable. The idea of this solution is to use the same digital signature again and again
in ARP replies for a long time.

Here one option could be to trust the ARP reply for recency and the only
check performed on the content of replies would be validation of the digital signature.
But then an attacker could get hold of that digital signature by simply sending an ARP
request to the target system and getting it in reply. It could then wait for the target
19

system to go down or it could crash the target system using known attacks or Denial of
Service attacks. As soon as the target system goes down or gets disconnected from the
network, the attacker could change her MAC address to that of the target system and
thus receive all packets sent to it. Now, even when the target system comes up later, it
cannot claim back its MAC address and has to change it. The attacker may continue to
poison the ARP cache of other hosts using the stored digital signature and thus receive
the packet sent to the target system. Hence it [11] proposes a method to securely indicate
the recency of the mapping indicated in the digital signature. This is done by including a
One Time Password in the ARP reply.
For a host to give an ARP reply, it generates a digital signature S containing
the IP address to MAC address mapping, the local clock time and the tip of a hash chain
used for verifying one time passwords. Now, for the first 20 minutes (cache entry
validity time), the host answers ARP requests by sending S as the ARP reply. For the
next 20 minutes, the host sends S and the first one time password (first link of the hash
chain) as ARP reply and so-on. In general for the ith 20 minute slot, the host sends S and
the (i-1)th one time password as the ARP reply. The sequence of events can be
visualized as follows

Figure 9: Authenticating ARP replies using Digital Signatures and OTP in [11]

20

3. Other Methods in Securing ARP

Various other schemes are proposed in securing the Address Resolution
Protocol against ARP Spoofing or Cache Poisoning. These schemes can be categorically
divided into 3 groups.
1. Detection using Tools
2. Static Binding and Stateful Cache
3. Modification of DHCP

3.1 Detection using Tools:

Specialized tools like Snort[3] and arpwatch[4] are used to snoop the network
and report abnormalities to the administrator. These tools are very lightweight and
widely available, but it depends on the network administrator being able to differentiate
between non-malicious events and ARP cache poisoning attacks, and also on his/her
ability to take appropriate and timely measures when an attack occurs.
Snort is a prominent example of a network IDS. The Intrusion Detection
System helps administrators detect attacks on the network at an early stage so they can
launch countermeasures. Snort has an Arpspoof preprocessor with four detection
mechanisms:
1. For each ARP request it detects, the Arpspoof preprocessor validates the source
address in the Ethernet frame against the source address in the ARP packet. If
these two addresses do not match, it issues a warning. ARP poisoning does not
imply using different addresses in these fields, which means that the attack
would go unnoticed.
2. For ARP replies, a comparison of the source and target addresses is performed. If
one of these address pairs does not match, Snort issues a warning. Again, this
will not detect ARP poisoning, although it does catch Proxy ARP on the other
hand, this technique is typically legitimate and involves one machine answering
ARP requests on behalf of another machine.
21

3. The system alerts on ARP requests that are sent to unicast addresses rather than
broadcast. Although this behavior does not comply with the (now 20 year old)
standard, there are good reasons for it. However, a genuine ARP attack does not
need to unicast ARP requests, so again, this mechanism would fail to detect an
ARP poisoning attack.
4. Snort checks all ARP packets based on a list of IP addresses and MAC addresses
supplied by the administrator. If the source IP address is on the list, the IDS will
read the corresponding MAC address from the list and compare it with the
source MAC address from the ARP packet and Ethernet frame. In case of
discrepancy, Snort issues a warning. This mechanism is only useful for small
networks, as the configuration effort is too high in any other case. There is no
way to use this functionality sensibly when faced with dynamic IP address
assignments (DHCP).
As we can observe from all the four cases, Snorts ability to detect ARP
poisoning is limited, as is the case for all Intrusion Detection Systems.
Arpwatch [4] is an open source tool for Unix platforms that monitors unusual
ARP activities. The computer running Arpwatch reads the address information stored in
each ARP packet that it sees and stores this information in a database. If the data fails to
match previously stored entries, Arpwatch mails an alert to the administrator. The
authors claim that the tool supports SNMP, although we were unable to confirm this in
our lab. Today, many networks use dynamic IP addresses assigned by DHCP (Dynamic
Host Configuration Protocol). In this kind of environment, Arpwatch will return large
numbers of false positives as it notifies users of any changed IP/ MAC mappings.
Note that, when using tools for detecting ARP attacks, by the time the
administrator notices the problem and takes appropriate measures, it may be too late as
the attacker may already have gained access to sensitive information.

22

3.2 Static Binding and Stateful Cache:

Static binding of the IP address and the MAC address in the ARP cache and
not modifying them is the most obvious solution to the ARP Spoof problem. But, this
doesn't work for a dynamic network where systems are allotted with different IP
addresses by the DHCP server every time the network is rebooted. Various
implementations of ARP have different 'cache holding times', meaning the time after
which a particular <IP, MAC> is invalid is different in different implementations. Such
timings can be in a range of 20 minutes to even few seconds.
ARP is a stateless protocol, it means when a host receives an ARP reply, the
stateless ARP cache will update the corresponding entry if it exists already in the ARP
cache. However, the stateful ARP cache will not update the corresponding entry unless
an ARP request has been generated before for that entry, even if the entry exists already
in the cache.
Zouheir et al. [5] discusses a new mechanism to prevent ARP spoofing. This
mechanism uses a stateful ARP cache and a Fuzzy Logic controller along with Cross
layer Controller to prevent malicious hosts from corrupting other hosts ARP caches
with fake entries. The mechanism is based on the use of a stateful ARP cache. When
host A generates an ARP request to get the MAC address of host B, an entry is created
in its stateful ARP cache, with the status of Waiting. Host A waits for an ARP reply,
within a predefined timeout. If an ARP reply comes, then host A waits another timeout
in order to collect other possible ARP replies sent by other hosts in the network. If host
A receives more than one ARP reply, then this means that most likely more than one
host has replied. Therefore, among those hosts, only one host is an honest host, which is
host B. The others are probably malicious hosts, performing ARP cache poisoning attack
to corrupt the ARP cache of host A.
This[5] mechanism also uses cross layer controller and fuzzy based cache to
identify the legitimate packets from fake packets. The normal ARP protocol
implementation does not make any cross layer control between the ARP layer and the
23

Ethernet layer to verify whether or not the source MAC addresses in these 2 layers are
similar. An extension of the implementation of the ARP protocol would proceed to do
this verification before accepting any ARP reply packet. Any ARP packet, whose source
MAC addresses in the Ethernet layer is different from the source MAC addresses in the
ARP header, is considered a fake packet and must be discarded.
If the cross layer controller fails to resolve the ambiguity of fake packets, they
are handed over to fuzzy logic control to determine the fake packet. During the network
setup time, each host in the network collects some information about the other hosts it is
communicating with. This information includes 2 numerical values describing the Trust
Level (TL) and Importance (Im) of each host. TL indicates the trust level of the host for
example, highly trusted or not trusted at all. Im indicates the importance of the host. The
collected information is stored locally on host A. Later on, it will be used to classify
certain hosts as attackers or honests. TL and Im are completely dynamic and they adapt
to the network changes. Finally, the value Security Level (SL) is obtained as a function
of TL and Im. The packet with highest SL value among ambiguous packets is retained
and remaining packets will be discarded as fake packets.
But, the mechanism doesnt provide any specific characteristics to determine
the value of TL. This mechanism also fails when legitimate host is shut down from the
time a network boots up and the malicious host starts communicating with the host from
the start.
Some operating systems like Solaris only accept ARP replies after the entry in
the table has expired. This makes it harder for the attacker to poison the cache. Modern
operating systems like Windows and several Linux based systems, accept an ARP reply
whenever they receive one, even if they didn't send the ARP request. This is to ease the
communication in network, but they will be easily prone to spoofing attacks. Static
binding though simple, puts lot of work for the administrator to map the IP and MAC
addresses of several systems in a large network. And also such static binding won't work
in a scenario where addresses are allocated dynamically through a DHCP.

24

3.3 Modification of the DHCP:

Much research has gone into using the DHCP server in the network to
somehow mitigate the ARP Spoof attack. Some of them are mentioned below.
Pansa et al. [6] presents a design of architecture and protocols for the LAN
security preventing the process of MAC Address spoofing, ARP Spoof and MITM. Each
Network Card is designed to have a Certificate, a Private Key and a Public Key, all of
which are issued by the product vendor. A certificate is in a form of software-data which
may be available in the Card Network package, or can be downloaded from a vendor
websites. A Certificate will certify MAC Address value. DHCP is re-designed to
authenticate Network Cards before delivering IP Addresses. DHCP Server also assigned
to be the MAC-IP database center which stores the data about matching between
MAC Address and IP Address.
The following changes are proposed to the design of new DHCP protocol in this[6] work

DHCP must be added more function concerning answering the question in

resolving IP Address to MAC Address by using the existing data.

Design that inside the DHCP Packet, there is a Certificate that certifies the
matching between MAC Address and Public Key.

Detect whether the IP Address requester is the real MAC Address owner before
delivering the IP Address (checking from Certificate).

Design the system to have DHCP Request-MAC (to substitute ARP Request) by
sending the request directly to DHCP Server instead of enquiring by sending
Broadcast ARP Request to every Host.

Design the DHCP Request-MAC to have a Certificate which certifies the

matching between MAC Address and Public Key.

Design the system to have DHCP Reply-MAC (to substitute ARP Reply). The
operation is that when a DHCP Reply-MAC appears, it needs to be checked
whether it is from DHCP Server. If it is not from DHCP Server, do not update
the value in ARP Cache.
25

Craig et al. [7] develops a unified framework to secure prominent networking

protocols within a single domain. It begins with a secure version of the DHCP protocol,
which has the additional feature of providing each host with a certificate. It then
leverages these certificates to secure ARP, prevent spoofing within the domain. In doing
so, it develops an incrementally deployable public key infrastructure which can later be
leveraged to support inter-domain authentication.
This proposed scheme[7] secures ARP by adding operations to the protocol.
Under this scheme, an end host transmits the regular ARP request as is done today.
However, when replying to an ARP request, it must include the certificate it obtained
from the DHCP server showing the IP and MAC binding. The requester can then verify
the certificate to confirm that the response given by the responder is accurate. Clients
would reject ARP responses that lack valid certificates.
Their modifications to ARP create a secure association between a given MAC
and IP address, preventing a host from spoofing only its MAC or its IP address.
However, the host could spoof both the MAC and IP address of another valid host. This
can be prevented in two ways: by proving authenticity in each packet or leveraging
DHCP snooping. To prove authenticity at connection establishment, a client may begin a
Diffie-Hellman exchange and sign its values. The server would then sign a message with
its own DH value. In subsequent messages, the client and server may simply use a nonce
and the secret key derived from the DH exchange to construct a message authentication
code and embed this code in the body of each message, allowing the other client to
verify its authenticity.
Some switches today employ DHCP snooping to prevent ARP cache
poisoning and IP spoofing. Essentially, such switches monitor DHCP traffic to create
allowable MAC address and IP bindings, and associate them with individual switch
ports. When a packet arriving on an interface does not match the binding, the packet is
discarded. Though effective, providing authenticity of each message incurs an additional
overhead at the end-hosts.

26

Secure Unicast Address Resolution Protocol (S-UARP) [8] extends DHCP

thus creating a new protocol which will have a DHCP+ server in the network, which not
only allocated dynamic IP addresses to the hosts, but also stores the IP, MAC
associations of each host. So, whenever a host wants to communicate with another host,
it unicastly asks the DHCP+ server for the MAC address of the receiver host.
This is a centralized protocol unlike the decentralized approach in normal
ARP. A simple example showing how the new S-UARP protocol works is mentioned in
the work[8].
1. When a host A wants to communicate to host B, it sends a S-UARP request
packet (unicast packet) to the DHCP+ server (which answers the S-UARP
packets), instead of sending a broadcast to all. It assumes that the secret hashing
key (KSA) is distributed between the client and the server, using private-public
key mechanism or any other secure mechanism.
2. The DHCP+ server encrypts the response message using DES with cipher block
chaining. Use the CBC residue (that is the last block output by CBC process) as
a message integrity code (MIC). This MIC would act as a checksum. The
plaintext message plus the MIC would be transmitted to the host (receiver) or A.
3. Once the UARP response is received, host A checks for validity by using its
secret key. The receiver (Host A) encrypts the plaintext S-UARP_res using DES
that it received with the shared secret key and does the hashing process to
produce similar MIC sent by the server. Finally, the host A sends an encrypted
acknowledgment (ACK)KSA to the server. ACK contains the timestamp
generated by the host A to ensure that the message is fresh and is not a replay.
The new S-UARP protocol is more efficient in reducing broadcast congestion in
network, since the S-UARP request is unicast and directed to only DHCP+ server. The
protocol is also more secure and it is quite difficult for an attacker to do ARP poisoning
attack. Especially it is protected against message integrity attacks (when ARP packet
content can be modified by attacker) and masquerading attacks (when new ARP bogus
packet injection can be done by attacker).
27

4. Conclusion
This work presents the comprehensive view of various solutions that address
the problem of ARP spoofing. Though the usage of different tools to detect ARP
spoofing can be effective up to some level, they dont entirely prevent the problem. By
the time the administrator notices the problem and takes appropriate measures, it may be
too late as the attacker may already have gained access to sensitive information. The
schemes using modification of DHCP protocol and cryptographic techniques prevent the
problem from occurring, but they dont have the ease of implementation. Any new
protocol proposed is not easily backward compatible with existing protocols and
requires changes at every host across the network.

28

4. References
[1]. D. C. Plummer. An ethernet address resolution protocol. RFC 826, 1982.
[2]. T. Demuth and A. Leitner, ARP spoofing and poisoning: Traffic tricks, Linux
Magazine, vol. 56, pp. 2631, Jul. 2005.
[3]. Snort: The open
http://www.snort.org

source

network

intrusion

detection

system,

2006.

[4]. arpwatch, the ethernet monitor program : ftp://ftp.ee.lbl.gov/arpwatch.tar.gz

[5]. Zouheir Trabelsi, Wassim El-Hajj: Preventing ARP Attacks using a Fuzzy-Based
Stateful ARP Cache
[6]. Detchasit Pansa and Thawatchai Chomsiri Architecture and Protocols for Secure
LAN by Using a Software-level Certificate and Cancellation of ARP Protocol
[7]. Craig A. Shue, Andrew Kalafut, Minaxi Gupta - A Unified Approach to IntraDomain Security
[8]. Biju Issac and Lawan A. Mohammed - Secure Unicast Address Resolution Protocol
(S-UARP) by Extending DHCP
[9]. D. Bruschi, A. Ornaghi, E. Rosti - S-ARP: a Secure Address Resolution Protocol
[10]. Wesam Lootah, William Enck , Patrick McDaniel - TARP: Ticket-based address
resolution protocol
[11]. Vipul Goyal and Rohit Tripathy - An Efficient Solution to the ARP Cache
Poisoning Problem
[12]. Challenge Response Authentication
http://fanaticmedia.com/infosecurity/archive/June10/TECH%20FOCUS.htm

29