DoS of LAN via D-Link switches

[Frank Bures]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

D-Link switch Model: DSS-16+

When user connects the same patch cable to two ports of the switch, the
switch will ultimately bring down hierarchically higher branches of the
LAN.

We have this D-link local switch connected to a 3COM 3300 family switch. A
user connected a patch cable to two ports of the D-Link switch effectively
shorting them together. The switch started to send out large packets that
would periodically overwhelm the 3COM 3300 switch and propagate father
through the network.

The first symptom of this phenomena were log entries from Linux machines
running ntpd complaining about "too many recvbufs allocated". Those
machines were on the LAN way beyond the shorted D-Link switch. The
problem kept spreading through the LAN and it finally took down three SGI
Octane machines running IRIX 6.5, effectively DoSing them from the network.
There were problems with NFS and other services, again way beyond the
initial D-Link and its connected 3COM switch. The 3COM 3300 switch
connected directly to the "shorted" D-Link switch became unusable together
with the part of the LAN it serves.

In my opinion, a switch should be immune to this admittedly insane
manipulation. Otherwise, one can DoS the entire network just by shorting
two RJ-45 network outlets in one's office together.

Ours is a rather large LAN. One part of it is served by Extreme Networks
switches. None of the SGI machines behind these switches were affected by
the short. In fact no adverse effects were observed in that part of the
LAN.

I contacted the D-Link with the description of the DoS. They have no record
of a similar report on file. They offered no solution.


Frank Bures, Dept. of Chemistry, University of Toronto, M5S 3H6
fbures@chem.toronto.edu
http://www.chem.utoronto.ca
PGP public key: http://pgp.mit.edu:11371/pks/lookup?op=index&search=Frank+Bures
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0 OS/2 for non-commercial use
Comment: PGP 5.0 for OS/2
Charset: cp850

wj8DBQFCST6zih0Xdz1+w+wRAkZfAJ9LBIcIDu+w6WCOxCZTsr nKeYReiwCg1xXo
Y0s7aBNl/VFiNCewyoYuldw=
=GQaY
-----END PGP SIGNATURE-----

[Tarmo Mamers]

> > From: Frank Bures [mailto:lisfrank@chem.toronto.edu]
> > Sent: Tuesday, March 29, 2005 4:41 AM

> > When user connects the same patch cable to two ports of the
> > switch, the
> > switch will ultimately bring down hierarchically higher
> > branches of the
> > LAN.

> > Ours is a rather large LAN. One part of it is served by
> > Extreme Networks
> > switches. None of the SGI machines behind these switches
> > were affected by
> > the short. In fact no adverse effects were observed in that
> > part of the
> > LAN.

This is natural behaviour of Ethernet ("natural" being dependent of your
network design, of course :) and has nothing to do with D-Link or any other
manufacturer.

Some switches offer automatic port disabling feature if BPDU is received on
a port defined as access port. All workstation ports should be defined as
access ports for this to work. Workstations are not taking part of any
Spanning Tree and they shouldn't generate any BPDUs and thus BPDUs shouldn't
come into the switch from any access port. When you interconnect two switch
ports defined as access ports, BPDUs generated by the switch reach another
access port and trigger the disabling feature. This works in case or a
single switch as well as between different switches as long as all your
switches are Spanning Tree enabled.

How the "short-circuit" affects specific switches depends how their unknown
frame forwarding is configured and where they stand in a multi-tier switch
topology.

> > In my opinion, a switch should be immune to this admittedly insane
> > manipulation. Otherwise, one can DoS the entire network just
> > by shorting
> > two RJ-45 network outlets in one's office together.

Switches _are_ immune to insane manipulation if configured correctly.
Excluding plugging out the power cord, unfortunately...


-tarmo-

[Neil Watson]

From: Frank Bures [mailto:lisfrank@chem.toronto.edu]
Sent: Tuesday, March 29, 2005 4:41 AM
> In my opinion, a switch should be immune to this admittedly insane
> manipulation. Otherwise, one can DoS the entire network just
> by shorting
> two RJ-45 network outlets in one's office together.

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.

Reference:
http://www.oreillynet.com/pub/a/network/2001/03/30/net_2nd_lang.html

--
Neil Watson | Gentoo Linux
Network Administrator | Uptime 12 days
http://watson-wilson.ca | 2.6.11.4 AMD Athlon(tm) MP 2000+ x 2

[Joel Maslak]

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

[Scott Nelson]

Neil Watson wrote:
> From: Frank Bures [mailto:lisfrank@chem.toronto.edu]
> Sent: Tuesday, March 29, 2005 4:41 AM
>> In my opinion, a switch should be immune to this admittedly insane
>> manipulation. Otherwise, one can DoS the entire network just
>> by shorting
>> two RJ-45 network outlets in one's office together.
>
> 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.

And it can be particularly hard to find. XO Communication's Irvine
Data Center has been struggling with what they believe to be the same
kind of problem for the last couple of days (and I've been struggling
with connectivity).