Date: Wed, 30 Mar 2005 15:04:24 -0700 (MST)
From: Joel Maslak <jmaslak@...elope.net>
To: bugtraq@...urityfocus.com
Subject: Re: DoS of LAN via D-Link switches


On Wed, 30 Mar 2005, Neil Watson wrote:

> I believe what you are describing is officially called a bridge loop.  A
> bridge loop occurs when a switch, or stack of switches are plugged into
> themselves.  The result is that the switches report the same MAC address
> at multiple ports.  The solution to this is called Spanning Tree
> Protocol.  STP is a set of algorithms that help switches remove
> redundant MAC entries.

Spanning tree does not prevent redundant MAC entries or even remove them.

It does however disable redundant links.  Spanning tree operates with no
knowledge of end device MAC addresses.

Description of the problem and why the switch is not broken:

Let's take a 4 port switch.  Vendor doesn't matter.  It's a cheap $25 job,
with no intelligence.  All it does is relay broadcast packets to all ports
except the source port and relay unicast packets to the last port where
the destination address was heard as a source of a layer 2 packet.

Port 1 is plugged into MAC A
Port 2 is plugged into MAC B
Port 3 and 4 are unused

Once the nodes on port 1 and port 2 each transmit one packet of any type,
the switch associated their MAC address with that port.  Thus, the MAC
table in the switch looks like:

PORT 1 -> "A"
PORT 2 -> "B"
PORT 3 -> NONE
PORT 4 -> NONE

If Port 3 is plugged into Port 4, and "A" transmits a packet to the
broadcast address, that packet is sent out on all ports.  Thus it is heard
*again* on both port 3 and 4.  Since switches cannot begin to transmit a
packet on other ports until it is at least partially received, the packet
is sent out on port 3 and 4 *after* it is sent to port 1.  Thus either
port 3 or 4 will become the owner of that MAC address.

Thus you will get:

PORT 1 -> NONE
PORT 2 -> "B"
PORT 3 -> "A"
PORT 4 -> NONE

Of course, if "B" sends a packet to "A", that packet is sent to port 3,
received at port 4, sent back to port 3, received at port 4, etc.  In the
process the MAC table gets changed to:

PORT 1 -> NONE
PORT 2 -> NONE
PORT 3 -> "A"
PORT 4 -> "B"

Now certainly one solution to this problem could be "Don't move a MAC
address from one switch port to another unless the link on that port goes
down."  But that will break all sorts of clustering solutions and also
break any wireless network where there is more then one AP and people roam
between them.

Some of the nicer managed switches will detect that the MAC is moving
between ports very quickly and flag an error.  But that method is hardly
foolproof.

Another solution is something like CDP and the switch intelligence to
detect that a switch is plugged into itself.  But this will probably break
when someone sticks another switch between the two ports (although the
problem described above will still likely exist).  If it doesn't, you'll
probably end up with, basically, Spanning Tree!  And if you are going to
the bother of implementing your own custom protocol to detect layer 2
loops, you might as well just implement spanning tree since most
networking professionals understand how it works and what its limitations
are (mainly: possibly slow convergence time and initial state where end
device cannot send traffic).

As mentioned before, the solution to this problem is Spanning Tree (or
some variant of Spanning Tree like Cisco's quicker-to-converge variant).
Basically, a $25 switch isn't "just as good as" a $800 switch, especially
not in an enterprise environment.  There is a reason those managed
switches start to cost real money!  Of course there are about 1000 ways
for an end user to take down an entire LAN other then plugging loops into
a switch (they can set up their own DHCP server, for instance; They can
enter the IP of the router in their computer, although most routers have a
defense against that; etc).  If you truly want to ensure that an end user
cannot affect others, you probably want them off a router port, not a
switch port (and even this is hardly foolproof).

-- 
Joel

Powered by blists - more mailing lists