> > > 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