Illuminations

In-line versus Out-of-Band Revisited

Tim Greene over at Network World had another post today in his NAC Alert column on the "NAC placement debate", whether it's better to be in-line or out of band. He took the opportunity to highlight a new Infonetics report that showed the market was about evenly divided and that the debate was roughly a draw. Revenue apparently is about equally split as well, with in-line devices getting only a couple percent more of the revenue pie.

In all fairness, we haven't drilled into the Infonetics report yet, but most of the conclusions Tim points out we would agree with: deployments are increasing in size, 2/3 of the market is still North America, etc. What gets me going is the simplified view of the merits of each. Tim summarizes as follows: "In general, in-line NAC appliances are better for smaller deployments because as the size of the installation grows, so does the number of devices. Out-of-band scales better."

Call me biased, but, folks, this just ain't true. Rather than get all huffy and technical here, I'd just like to point out our recent whitepaper on this very topic for a more in-depth analysis. In reality, when deploying out-of-band, just to provide the authentication functionality, an appliance is required in every switch domain, so the number of appliances required tends to be comparable. The bottom line is there are a lot of myths out there, so be careful. [One out-of-band vendor states that the two terms refer not to analyzing packets in or out of the flow of network traffic, but to whether or not the communication to enforcement points (a downstream switch, e.g.) was in or out of the flow of traffic. (Note that if you are in-line you can BE the enforcement point).]

I just hate to see these misconceptions and myths get propagated any further than they need to. I hope that clears things up.

I'll See Your New Chips, and Raise You...

Eric Ogren has a nice blog over at ComputerWorld, but his post this week left me shaking my head. Eric anticipates that the new generation of Intel and AMD chips with built-in security processing is going to change the playing field for security appliance manufacturers. More importantly, he states, “it is becoming increasingly difficult to justify the large engineering investments in custom-built ASICs or hardware that is not built on a standard platform”. This assertion couldn’t be further from the truth, and doesn’t anticipate where the ultimate direction of all the emerging security services is going. Security has become increasingly complex due to the sophisticatation of blended malware attacks, among other reasons. The increase in mobile systems, as well as non-employees on corporate networks have reduced the effectiveness of the perimeter and requires security services within the network infrastructure. From Nevis’ perspective, the switch is the ideal security enforcement point because it can block threats in microseconds at the lowest common factor, the port. Existing departmental firewalls or out of band appliances cannot keep malware off the network because, by definition, the malware is already inside the corporate LAN before they even detect it. The future of LAN security is a fully secure access layer – both wireless and wired. Many of the people we speak to get this message. Secure switching at wirespeed is now a reality. Many of the traditional switch vendors understand this dynamic and are planning to build ‘stateful’, application aware switches that are secure.

The challenge thus far in the market has been with performance. Obviously switches are blazingly fast and designed with performance and scalability in mind. LAN technologies require high performance and low cost. Traditionally, security products have been low performance and high cost. As security merges into the network fabric, secure switches need to remain cost competitive AND fast. Something has to give.

If you are going to layer in deep packet inspection and analysis, and do it on every packet, you can’t sacrifice the performance that people expect. Access layer switches are now shipping with multiple 10 Gbps interfaces. Many of the fastest IPS devices in the market struggle to cope with this level of traffic. Eric might be surprised to learn that the fastest Intel and AMD silicon can scale to ‘maybe’ 1 Gbps of traffic when running L4-L7 services. How then can we secure tens of gigabits per second of traffic at the access layer, while keeping them cost competitive? The only answer is the development of customized ASICs or multicore processors that have hardware acceleration for the key L4-L7 services.

Nevis was built on the vision of high performance and low cost stateful services. Key to our success has been the development of our SuperNova™ security ASIC – which has 24 cores and 96 threads, architected to drive security services and application recognition. It mght surprise Eric to learn that 10 of Intel’s fastest CPU’s cannot keep up with 1 SuperNova. Don’t believe me, listen to what one of our customers had to say.

10:1 price performance – now that’s impressive.

How to Design a Secure Switch

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.

Technorati Tags: Joseph Tardo Joel Snyder