What’s the best way to secure an internal network? When Nevis started three years ago with the goal of integrating switching and security, the big challenge was how to do it at all. You could adopt existing technologies such as stateful firewalls, IPS, and NBAD, but the important word here is stateful. Look at the traffic banging around a LAN sometime – random duplicated packets due to flooding, asymmetric routing (sometimes intentional, usually inadvertent), legacy L2 frames with proprietary framing taking liberties with 802.3, such as using the source MAC as an additional protocol field, spanning tree frames pouring out of access ports, things like that. Clearly you need to be at some kind of choke point. But most existing LANs have just evolved with little need for planning beyond capacity, thanks to Ethernet technology, so much so that choke points are hard to find and, in fact, are something to be avoided.
We also looked at the best practices of the day. I have to say that a real eye opener was Joel Snyder’s article back in 2003 on securing internal networks. The short answer was, unfortunately, you can’t get there from here. We then looked at some of the endpoint software solutions out there – despite the fact that we were told over and over that clients were an undesirable last resort – and many of these products simply took the same technology (stateful firewall, signature matching) and put it in the host network driver anyway. So, why not put this kind security at the access switch port? It’s a natural choke point, the point of user entry to the LAN (another crack in the perimeter, so to speak) allowing control over admission; you don’t have to trust that clients haven’t been tampered with; you can deflect attacks on the LAN itself such as FDB overruns; and you can centrally manage it all! Clearly this was the way to go. Why hadn’t someone thought of it before?
Well, there were some obvious answers. Access switches have become commodities, glorified punch-down blocks built from commodity ASICs available from multiple vendors, like Broadcom, competing on price and features, making them ever faster, bigger, and cheaper. But this also makes it hard to put in features that the vendors didn’t think to bake into their chips, like, security. You can put it in the control plane, even try to repurpose more powerful multi-processor ASICs as “security” planes, but this ultimately limits what you can do – LAN security is so tightly coupled with switching and inherently flow-based that it is a challenge to separate the two without compromising one or the other. You have to be able to track every packet if need be, and get packets through with minimal latency. Or you can use alternative data planes, like NPUs, but even if you could find a suitable one, it’s hard to match the system cost and performance.
Ultimately, we chose to design our own ASIC, taking the best ideas around, building on them, and adding our own innovations. It had to be able to do fast flow-based processing and be easy to upgrade with additional features. We made it fast and programmable, integrating features that facilitate doing switching at 10 Gig without compromising security, using accelerators for doing things like buffer management, in-line signature matching, hash lookups, and such, enabling it to quickly react to changing conditions during a connection. And we proudly shipped the product a year ago, the world’s first built-from-the-ground-up secure 48-port access switch - configured like a switch, not an appliance, and providing centrally managed, user-based access control policies with protection against malware.
I believe that we’ve played a pivotal role in the vision for secure switching by being the only company to purpose build a secure switching ASIC from the ground up. Other companies have taken short cuts using more general purpose control plane processor architectures, but on the way they have sacrificed performance and functionality, and are missing features such as signature matching and encryption that are integral and critical parts of a secure architecture.
We’ve proven that Secure Switching can be done without compromising on either security or performance, so where do things go now? Well, here we are, shipping our third software version and coming up with more and more ideas for better and faster solutions, including dreaming up next generation ASICs and accommodating new customer deployment scenarios, but my bottom line prediction is that, within twelve months or so, you will see the emergence of secure switches from major vendors and secure switching will have jumped across the proverbial chasm.
Joseph Tardo, Ph.D.
Comments