One of the coolest demonstrations at the RSA Conference in San Francisco was of a network functions virtualization (NFV)-based firewall and Deep Content Inspection engine embedded into the software-defined networking (SDN) control plane of a heavily laden network. The firewall/DCI engine filtered content and blocked SQL injection attacks in real time, without slowing down the simulated network.
The OpenStack-based testbed was created and run by Spirent, a Southern California firm well known for its network testing platform. The security firm with the firewall and DCI engine was Wedge Networks, a Canadian company that's focused on the cloud.
The testbed validated the ability of WedgeOS – Wedge's virtualized firewall and Deep Content Inspector – to block identified content in the OpenStack-based virtual environment.
The test load came from Spirent's Avalanche, which generated simulated Layer 4-7 Web client and server traffic. The tests were orchestrated by Velocity, Spirent's integrated lab management system for virtual and physical environments. In the test, WedgeOS blocked malicious content based on configured policies, without affecting throughput, even when the network was flooded with traffic.
One of the tests did content blocking, filtering out all traffic that contains specific keywords. Another test detected and filtered malware, including virus attacks and XSS (Cross Site Scripting) and SQL Injection attacks. Both of these simulations were realistic, in that both types of attacks can occur on physical and cloud-based networks.
Wedge's name for its embedded security platform is NFV-S, or Network Functions Virtualization for Security. According to Wedge, NFV-S builds on NFV to provide scalable, elastic security that can be embedded into an SDN-based network as a predictable service. I think that Wedge hopes that NFV-S becomes a widely adopted specification, but to the best of my knowledge, at this point it's specific to Wedge's own products.
While this test showed that NFV-based security functions run well in a simulated SDN network, the whole point was predictability. When it comes to virtualized networks, there are incredible numbers of variables. Because of the number of nested abstraction layers, it's hard to know what type of hardware those NFV services will run on, and how much of that hardware will be available for that function. This is NFV:
- What's the processor and memory? You'll never know.
- What's the real-world bandwidth and throughput? You'll never know.
- What else is running there? You'll never know.
- Will the NFV functions run? Yes.
- Will the NFV functions run fast? Maybe. Maybe not.
- Can the NFV functions handle spikes in traffic? Hard to say, but probably yes.
- What impact will other NFV functions running on that hardware have on performance? Impossible to say for sure, but tests and simulations might give you a reasonably good idea.
That's where the test at the RSA Conference came in, showing that Spirent's tools can mimic real-world traffic on the virtual network, and WedgeOS handled that workload in a predictable manner to virtually ensure that guaranteed service levels are met under stressful conditions.
By the way, this test is an update of a test that these two companies ran in April 2014. However, the old 2014 test was focused more on showcasing Spirent's SDN testbed facilities, with the Wedge security system as a proof-of-concept application on that testbed. The new 2015 test showed that the security software filtered content and blocked attacks, and could do so on a heavily trafficked simulated network.
A year is a long time in this business, and it's great that NFV software embedded in a software-defined network has moved from "by golly, it works!" proof-of-concept to a hard-driving test that shows reliable performance under load. As more organizations look to move network traffic to SDN-based networks, we're going to need embedded security, we're going to need NFV, and we're going to need predictability.
After all, if we can't predict the performance of our virtual networks, what's the point?
This article is published as part of the IDG Contributor Network. Want to Join?