[10628] in bugtraq
Re: NetBSD Security Advisory 1999-010
daemon@ATHENA.MIT.EDU (der Mouse)
Tue May 25 15:07:24 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-Id: <199905251822.OAA21245@Twig.Rodents.Montreal.QC.CA>
Date: Tue, 25 May 1999 14:22:48 -0400
Reply-To: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
From: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
To: BUGTRAQ@NETSPACE.ORG
>> My personal opinion is that ARP should be fixed on all IP stacks
>> (well.. ARP "stack") so that they won't accept multicasts
>> addresses.. I can't think of any reason why they should.
My opinion is that they shouldn't stop you from doing stupid things
when that also stops you from doing clever things.
> One thing that can be configured to use multicast Ethernet addresses
> for unicast IP addresses is Microsoft's WLBS (Windows Load Balancing
> Server/Service).
Auspex has a product that does likewise; ServerGuard, I think they call
it. It too will break (or be broken by, depending on your point of
view) any box that doesn't accept multicast MAC addresses in ARP
replies. (At least if what I retain of what I read of the ServerGuard
docs way back when is correct. We've never used ServerGuard, but when
I saw the description I was puzzled enough to ask the Auspex techies
how it could possibly work....)
It might be nice to have knobs so that the sysadmin can disable
acceptance of multicast and broadcast MAC addresses in ARP replies. I
would call it broken to refuse them without providing a knob for the
sysadmin to change that behavior.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
