On 14-06-21 01:03 PM, Chris Cappuccio wrote:
Adam Thompson [athom...@athompso.net] wrote:
Yes, OT... But unless you've chosen to do something silly (like enabling MVRP, or blindly allowing 
all VLANs to an untrusted host) saying "VLANs aren't secure" is about as useful as 
"ICMP isn't secure".
Please explain how VLANs are not secure when you have control of the devices on 
both ends of an 802.1Q-tagged link?  That's no more or less secure than having 
multiple links to a switch running un-tagged ports on different VLANs.  Or are 
you saying I should have a separate physical switch for each subnet?
This is well documented by security researchers who were proving these
bugs at the time. And this was some 14 years ago. If you're still using
a 14+ year old switch that hasn't failed by now, (even a nice, high-end
one) you are doing better than many others. Realize that these issues
were taken fairly seriously by vendors because vlans were being used
as a security mechanism.

Henning already described it best as "last century's myths".
Technically this isn't actually a myth: I know that some VLAN-hopping bugs did exist, but they've been long-since squashed. Which is why I compared it to the "ICMP is evil" dogma... perhaps a better comparison would be the "autonegotiation is evil" dogma, which also was true back in the days of Cisco 2900XLs with their (ahem) interesting implementation of 802.3u's autonegotiation clause. The correct response to that today isn't "don't use autonegotiation", it's "don't use Cisco 2900XL switches". The correct response to VLAN security concerns today isn't "don't use VLANs for security", it's "use Cisco/Juiniper switches if possible, or at least tier-2 gear, and implement mitigation techniques". SANS has a reasonable paper covering VLAN security (http://www.sans.org/reading-room/whitepapers/networkdevs/virtual-lan-security-weaknesses-countermeasures-1090).

This situation is made more complicated because plenty of low-end
switches still exhibit odd behavior under stress situations. Don't
use them if you are using vlans for privacy. (If you are being paid
for co-location or ISP services, don't buy shit. You are being
paid for privacy.) Hopefully Broadcom and whoever else makes
switch ASICs has fixed their bugs by now, too.

Well-said. When someone starts talking about using 802.1Q-over-802.3ad[1] I automatically assume they aren't using absolute garbage. I've found the tier-2 switch vendors (e.g. Dell, Brocade, D-Link, Netgear(!), etc.) to be adequate but not ideal for layer 2.

Some people are looking at improving OpenBSD's MP networking
performance these days. Right now all routers and firewalls should
be on SP kernels or you will actually have worse performance.
There is a chance than this situation may improve in later
releases, a remote chance for 5.6.

I would certainly welcome that; my routers are all MP with useless amounts of CPU (in order to have a standard h/w platform, not because it's required) so anything that will make routing run more efficiently there will be welcome. Not that I'm pushing enough data to care right now, but it would be nice to see OpenBSD's routing performance get back into the same ballpark as FreeBSD or Linux on typical many-core systems today.

[1] Yes, I know it's been superseded by 802.1AX now but that's an old habit that will be hard to break.

--
-Adam Thompson
 athom...@athompso.net

Reply via email to