How does one tell, in principle, that the source IP
address (ar$spa) in
an ARP packet is in fact spoofed?
Not without cryptographic authentication, in general.
But for this particular issue, not updating the local cache
based on
snooped ARP exchanges (i.e. what Linux does) may make
sense. Also, under
this particular misconfiguration, there'll very likely be two ARP
responses for a lookup of the IP address in question, so
maybe could be
used as an indicator that there's a problem.
If you ignore gratuitous ARP, then what happens when a
station goes down
and then comes back up with a different MAC address? That
happens when
the station is given new hardware or in some fail-over schemes.
Let's face it: ARP in insecure. The proposed heuristic don't really
help: there is no way to tell which of several ARP responses is the
"real" one. Not using gratuitous ARP helps somewhat, in the sense that
an attacker will have to expend more resources, but it also hurts,
because there will be no way to flush "erroneous" values from the ARP
cache. In any case, an attacker, or a misconfigured node, can easily
send ARP responses to ARP requests for a target address; indeed, it can
just as well respond to ping and other requests for that address. The
attacker's MAC address will end up in the cache, which won't be flushed
for some time...
Bottom line: if we want to run ARP in networks that are not protected by
some form of physical security, then we need to secure the protocol. I
don't know whether expending that energy on ARP is in fact a good idea,
since ARP is almost as old as IPv4, and we are moving to IPv6. But for
IPv6, there is no question: we should certainly develop a secure
vbersion of neighbor discovery.
-- Christian Huitema