So, in fact, all these cases collapse into RFC 826-compliant behavior: as you
say, no matter how I receive the ARP nor which type of ARP frame it is, I should
glean information from it
Yes, I can see how Ethernet filtering would allow the administrator to defend
the host against such behavior, in an ad hoc way. Still a hack.
I understand that some Ethernet switches allow one to lock down IP address /
port mappings. But this just moves the administrative problem to someone else,
it doesn't solve it.
OK, I'm going hunting for confused machines.
Thanx for the discussion,
--sk
James Carlson wrote:
Stuart Kendrick wrote:
Ahh. I've been staring at a lot of ARP frames these last few days. But
I hadn't thought through this.
I see three classes of ARP gleaning, all of them rely on the entry
already existing in Solaris' cache, per your point.
(1) Remote station emits a gratuitous broadcast ARP: Solaris updates
its cache
(2) Remote station emits a gratuitous unicast ARP: Solaris updates
its cache
(3) Remote station emits an ARP Request for the Solaris box's address:
Solaris
responds *and* uses the information in the ARP Request to update its
cache
Actually, as of my ARP RFC 826 fixes in OpenSolaris and Solaris 10,
there's a fourth case to consider:
(4) Remote station emits an ARP message of any type with either the
Solaris box or broadcast as the destination, and the Solaris box
has a mapping for the ar$spa IP address in its cache. The Solaris
system will update its mapping based on ar$sha.
What the RFC says is that when you receive an ARP message, no matter how
you got it, you first look at ar$spa and ar$sha, before looking at the
type (request or response) of the message. If ar$spa matches something
in your cache, then update.
#3 is where I'm encountering confused machines: the source IP address
in these ARP Requests is accurate, but the source MAC address is not.
Yep; that's toxic.
Besides defenestrating the bad boxes -- which would be my first choice
-- it'd probably be helpful if there were Ethernet level filtering
available for Solaris as a temporary work-around. The negative aspect
of that "fix," besides the fact that it's not yet available, is that the
Solaris system is not likely to be the only system on the network that's
confused by bad messages, and teaching all of the possible listeners to
ignore the idiot may be prohibitively difficult to achieve.
_______________________________________________
networking-discuss mailing list
[email protected]
