Dino and I were chatting in IRC last night about "solutions" to various
ARP poisoning techniques.
While googling what various vendors proposed (and how they've differed
from what I've used in the past), I found this PDF talking about how, in
some cases, the poison in worse than the cure.
http://www.cs.sjsu.edu/faculty/stamp/students/Roney298report.pdf
p. 19/20 is where the interesting stuff begins. Before that, it's stuff
that most of us know. (Here is a snippet below, in case you're too lazy
to click the above URL)
*************************************************************
There are several existing solutions to ARP Cache Poisioning; however, a
detailed study shows that there are some disadvantages in the existing
solutions.
Issac, B. et al [2] proposes ‘Secure Unicast ARP by extending DHCP’ to
prevent ARP cache poisoning. In this solution, when Host A wants to
communicate with Host B, it first sends a secure unicast ARP request
packet to a DHCP+ server. A Secure Unicast ARP (S-UARP) request packet
is a unicast ARP request packet sent to a DHCP+ server. The DHCP+ server
is an enhanced DHCP server that understands Secure Unicast ARP packet
formats. The DHCP+ server has information about the IP and MAC address
mapping of all the hosts to which it has leased an IP address. Hence it
responds with the MAC address mapped to the requested IP address in an
encrypted format. It is a trusted party and the messages are encrypted
before transmission, with a secret key that has been distributed to the
client and the server by a Certification Authority. This makes sure that
Host A will not get an ARP packet, which could cause poisoning.
The drawback of this solution is that it requires modification to the
ARP protocol, which means that all the Hosts in a LAN that want to
prevent ARP Cache poisoning would have to modify their kernels to
reflect the modified ARP protocol.
It would also require a DHCP+ server, which would understand the secure
unicast ARP packet and respond to it. Another modification that would be
required is to the DHCP relay agent, as it has to be able to identify an
S-UARP packet and forward it to the DHCP+ server.
Brushi et al [9] has proposed a Secure ARP (S-ARP), which uses
asymmetric key cryptography to authenticate the hosts in a LAN. A
Certification Authority assigns a private/public key pair to every host
in the LAN. Each ARP packet sent from a host is signed with the host’s
private key. The receiving host verifies the signature of the ARP packet
using the sending host’s public key. To include the signature of the
sending host in the ARP packet, an additional header is inserted at the
end of the standard ARP protocol header. The solution in [9] also
requires modification to the ARP protocol as the sender needs to sign
each ARP message with his private key and the receiving host needs to
verify the signature with the sender’s public key. The author mentions
in [9] that to get the entire LAN completely secure, all the hosts
should be S-ARP enabled. S-ARP also introduces additional overhead and
time for signature and verification by the sender and the receiver
respectively, for each ARP message. The other issue with this solution
is that this is not a feasible approach for a wireless network
environment like a hotspot, where the wireless clients entering the
network are random and short-time users who cannot be expected to have
S-ARP enabled.
Tripunithara, et al proposed a Middleware approach to prevent ARP cache
poisoning in [10]. This approach maintains a ‘requested’ queue and a
‘responded’ queue in each host. If the host has sent an ARP request, it
will be entered in the ‘requested’ queue and when the corresponding
reply is received, it is entered in the ‘responded’ queue. Hence,
whenever an ARP response is received, it is allowed to update the ARP
cache only if there is a corresponding request in its request queue. The
solution prevents the ARP Cache Poisoning attacks, but each and every
host in the LAN has to be modified. The scale of deployment is very high.
