Date:         Fri, 3 Sep 1999 22:02:39 -0500
From: Strange <strange@CULTURAL.COM>
Subject:      Re: VLAN Security
To: BUGTRAQ@SECURITYFOCUS.COM

The following is a stereo (2 Mikes) message [Mike S=strange@cultural.com -
Mike F=frantzen@expert.cc.purdue.edu]....

Taylor and Schupp wrote of their neat evaluation:
> We have recently conducted some testing into the security of the
> implementation of VLANs on a pair of Cisco Catalyst 2900 series
> switches and we feel that the results of this testing might be of some
> value to the readers.  Testing basically involved  injecting 802.1q

[. . .]

[Mike S:] While I think it's immensely useful that your study has debunked
in hard testing a common myth (that VLANs provide unbeatable isolation),
the limits of inter-switch VLAN isolation are discussed already in Cisco's
documentation.  See, e.g.:

http://www.cisco.com/univercd/cc/td/doc/product/lan/28201900/1928v8x/eescg8x/aleakyv.htm

Indeed, according to the document, all one needs to jump VLANs involving
more than one switch is the MAC of the target system.  Is that NOT the
case?

[Mike F:]
It likely filters out arp requests to the broadcast MAC and responds with
the MAC of the trunk end router.

[Mike S:]
Cisco also mentions "local VLAN isolation" on enterprise model switches,
and implies it prevents this escape behavior where only a single switch is
cut into multiple VLANs (our Cisco rep was unable to provide further
details).

[Mike F:]
I tested this feature on a 2924 Enterprise switch with a Cisco 2514 (IOS
12.0 IP Enterprise feature set) recently, and it appears indeed to provide
protection against directly writing to the MAC of the target.

To further confuse the reader, I must point out that the 802.10 frame spec
(for use on the trunk line) includes a boolean flag for fragmented ether
frames.  Cisco's documentation claims to ignore the fragmentation field...

I'm going roller blading now :)

[Mike S]:
Hmm.

 . . .

[Mike F]:
You may want to include that we threw 15bil [Mike S. -- yes, folks,
that's billion] packets against the 2924 vlan config and filtered on the
multicast MAC and nothing got through.  We did manage to watchdog reboot
the switch or router (can't remember which) but were unable to track it
down due to the length of time needed to send the packets.

[Mike S]:
The time-consuming part of a multi-billion semi-random packet series is
figuring out precisely what killed or froze what when.

[Mike F]:
really going blading now

[Mike S]:
And there you have it.

      -MS