RE: switch jamming

[blast <blast () baymoo org>]

This topic has been going on for a while and there are some
important points that need to be made regarding "switch jamming"
and "port mirroring".

Port Mirroring
--------------
This is a feature-set provided by a switch vendor to allow
the ability to mirror the TX, RX or TX/RX port buffers of
any port on the switch to a designated port.  Cisco calls
this feature SPAN, Port Monitor, and VACL's capture. The
feature differs depending on your switch type and hardware
capabilities.
The main idea here is that an network analyzer needs
to get in the middle of full-duplex traffic and the idea
of physically tapping each station cable is unattractive.
Declarations when provisioning this type of feature on
all vendors has the administrator describing the SOURCE
as ALL TRAFFIC YOU WOULD LIKE TO SEE and the DEST as
WHERE TO SEND THIS STUFF.  The SOURCE and DEST parameters
have many constraints depending on make and model.
It is common that you would have criteria for SOURCE that
describes VLANs or Ports in a contiguous or discontiguous manner.
It is common that you would have criteria for the DEST
that is a port and you can choose to get just the TX, RX
or both of your SOURCE.
Your millage will vary even within a single vendor.

"Switch Jamming"
-----------------
This has nothing to do with a feature, it is all about resource
exhaustion.  It also mutually exclusive to any type of arp-poisoning
since it is about CAM table exhaustion which is strictly a L1/L2
problem.  arp-poisoning is a L2/L3 issue.
This "hub-mode" that was talked about in the starting of this
thread is something that needs to be clarified.
A switch is nothing more than a Ethernet Bridge.  The "switching" takes
place because of learned knowledge called a CAM table.  The CAM table
contains 48bit MAC addrs that are associated with physical ports.
It is a physical_port<->MACaddr mapping (L1/L2)
(there are feature sets that vendors provide to do fancy things
 with the CAM table but I'll address them later)
This CAM (content addressable memory) table is only so many entries
deep.  This is where the exhaustion occurs.
The rule on how the CAM table is populated dynamically goes
something like this:
1) If you get a Frame and you don't know the DEST, send
it out all ports and record (to the CAM table) the SRC.
The CAM now has an entry of MAC that lives downstream from
that port.
2) If you get a Frame and you do know the DEST MAC, send it out
that port. CAM table match.
There are other rules but we dont need them to understand
the exhaustion condition.

If the CAM table is 20000 entries deep, and you have the
proper kernel mods and libs, you can put together a simple
util that would send 20000 uniquely addressed frames thus
filling up the table.

At this point, the behavior is un-deterministic on make,
model and os-rev.  The only thing you can be sure of is
that deterministic behavior of the switch is lost.
un-deterministic profiles range from going in to a "hub-mode"
where because there is no room for another CAM entry, send
out all ports to rebooting and even ports losing link
status causing Spanning Tree to recalc.

Hope this helps.
-blast













problem.