The following is a stereo (2 Mikes) message [Mike S=strangeat_private - Mike F=frantzenat_private].... 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:01:51 PDT