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?
When OpenBSD first impelemented if_vlan, not all vlan tagging switches were created equal. I ported and improved if_vlan (we had it working in an OS release _before_ FreeBSD did.) So I was paying attention to this area fairly closely. Vlan hopping bugs with 802.1Q (and ISL) were not entirely unheard of! Certain switches had designs that paid attention to the MAC address tables and didn't properly filter based on the vlan tag, even when ports were set to only pass packets with a certain vlan tag. This would depend on certain configuration options or combinations of options. Some would only exhibit this behavior under certain stress situations. For instance, when the MAC address table was full, the switch would basically turn into a sort of full-duplex hub. 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. 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. Many networks use vlans for privacy very extensively these days. Open source implementatons rule on 802.11 based wireless (Ubiquiti, Mikrotik, Deliberant, and all the companies that use their hardware in similar products with some Linux derivative kernel), also there is a variety of Linux and BSD in firewall and router gear. I hope most gear configures their vlan tagging kernel interfaces and bridges correctly, configures their switch ASICs or FPGAs correctly, and so on. Don't forget the NSA loves your routers :) If you want to test your gear, there are various tools out there that you can test with. There are some MAC- address-table flooding tools. You can also use if_vlan, arp -s and ping to test for MAC address forwarding (for instance, will a software bridge or switch send a packet to a MAC address destination that in a different vlan that is learned on a port configured to only pass traffic for a certain vlan.) Basically anything that your users could possibly do, you can test for. I'd be curious if anyone who has done this kind of testing with recent hardware and software implementations can share their results. > > I recall the performance question coming up at BSDCan, and Henning saying > that under ideal circumstances, yes, OpenBSD could usefully fill a 10GE pipe, > but that non-ideal circumstances would degrade performance faster than the > equivalent $250k+ hardware 10GE router. > > Reyk@ is, I believe, running an entire company predicated on high-performance > routing, including multiple-10GE but that's second-hand knowledge. > > Certainly OpenBSD is easily capable of pushing many gigabits per second of > traffic, I just don't know what the absolute upper limits are today. > Reyk's new company is Esdenera Networks. He hasn't released much in the way of technical details but he did recently commit if_vxlan which just might be one component of the Esdenera secret sauce :) OpenBSD's networking capabilities are constantly being improved. 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. Chris
