On 7/23/02, Vernon Schryver wrote: >> From: Lars Eggert <larse@ISI.EDU> > >> > 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. > There are some simple confidence counter techniques that would filter out most spoofs but still allow fail-overs. Basically, you use some simple counters and state variables to detect when an IP address is being repeatedly switched to one MAC address, and then back to the original value. When this is detected the original mac address could then be queried to confirm that it indeed thought it was the IP address in question (just in case this is some sort of migration feature and the flip-flopping was valid). You could probe the original MAC address on *any* change, but that could prove nasty on a large subnet. Having a designated ARP validator on a subnet might make sense if a network administrator was trying to prevent unauthorized use of IP addresses on their network. It's much easier to deal with spoofed source IP addresses on a network basis than from inside one host. At the network level the source IP address can be cross-checked against the physical link it arrived on. Even with automatic fail-over, the network administrator should know where an IP address *could* come from. This is especially true of the IP addresses most worth stealing.