On Mon, 10 Sep 2001 [EMAIL PROTECTED] wrote:
> On 8 Sep 2001, at 22:41, Paul D. Robertson wrote:
>
> > Some switches will still broadcast packets when their buffers
> > start to get saturated, or if they get too many entries in their
> > ARP tables- if you really need seperation, then things should be
> > physically seperated and routed (per-port costs go up for users in
> > that scenerio, but on the good side you get big routers to play
> > with.)
>
> Some? That's the *correct* behaviour for a switch when it receives
> a packet whose destination MAC address is not in its tables, whether
> because it just hasn't yet seen traffic from the destination box yet,
> or whether its tables have filled and can't hold any more addresses.
I differentiated for a particular reason- if you have MAC latching on for
all ports, then you shouldn't be able to get more than $num_ports MAC
addresses if it's a stand-alone switch - which can be modled, tested and
validated for a particular implementation (though I still agree that it's
a poor thing to depend on for seperation.) That's not the same as a
failure case where full buffers start broadcast behaviour- and it's
important (IMO) to seperate the failure of the modes (full ARP
tables ~= unknown MAC from the logic perspective v.s. heavy traffic.)
> In either case, the switch doesn't know which is the correct
> destination port, and the safe fallback is to forward the packet to
> all ports on the VLAN/broadcast domain. Any switch that doesn't do
> that is broken, and anyone who considers this a security issue should
> stop relying on switches as a security mechanism....
It's most certainly a security issue if you're relying on latching a port
to a MAC address and expecting that to save you from the broadcast of what
should be unicast packets because the switch theoretically knows who everyone
connected to it is- though now that switches are getting higher-bandwidth
handling capabilities, I suspect that testing for all failure modes is
going to be pretty darned difficult.
Your Paranoia May Vary
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
