One of the interesting things that emerged from the SDN World Congress was the multiplicity of roles associated with the concept we call “deep packet inspection” or DPI. Like almost everything in tech, DPI is being positioned or proposed in more missions than we have methodologies to support. I had an opportunity to spend quite a bit of time at the show with Qosmos, a company who is a leader in DPI not only in a functional sense but also in terms of how many places it’s already installed. What emerged was a useful view of how we might present DPI in a virtual age.
Qosmos DPI is available in what’s effectively three flavors; as a plugin to Open vSwitch, as a standalone software element that could be a virtual network function (Qosmos is presenting that to the NFV ISG), and as a set of libraries that can be used to construct stuff, including DPI in embedded applications/appliances. Like DPI overall, the Qosmos stuff is directed at sniffing into packets deeper than the normal IP headers to determine the higher-layer context of a given packet. This can be used to add “Level 4-7” processing to switching applications, to identify contextual flows, to screen packets for further processing or monitoring, to manage QoS-based routing or handling, etc.
Traditionally DPI would be used like routing or switching or firewalls are used, which means embedding it in an appliance and inserting it into the data path somewhere. This sort of thing is still possible in a virtual world, but it kind of violates the abstraction-driven spirit of virtualization, not to mention creating some very practical issues on how you’d stick a real box into a virtual process. If we have compute as a service, networking as a service, you should logically be able to get DPI-as-a-Service. The question is how, and what might the outcome do for us, and the “distributability” of Qosmos offers some insights here.
Qosmos’ material shows a diagram of an NFV-ish framework with OpenStack on top, operating through an SDN controller, to nodes underneath that might be OVS or something else that the controller can manage. In this structure, you could apply DPI at any level from network applications (VNFs for example) deployed by OpenStack, to applications inside the controller, down to stuff inside the nodes that are being controlled. So the high-level framework presented here is really similar to a server resource pool, and that’s the important point to consider.
DPI as Qosmos presents it is a bit like infrastructure, something you can harness virtually. There are places where you can utilize DPI and cast that utilization into a specific mission, but also places where DPI is potentially as flexible an abstraction as “routing” or “switching”. That’s why I think you have to consider it as a virtual element and the basis for an as-a-service modeling to get the most bang for your buck. You can still use DPI components in more static applications, of course, to apply policies from above or gather information from below, but the static model is a subset of the DPI-as-a-service picture, and the most general is the most valuable in a virtual world.
In a DPIaaS model, you would presume that a network/cloud was populated with a bunch of places where DPI functionality was available, much as it’s populated with OVS functionality. In fact, a lot of the DPI fabric might well be created because we’ve installed plugins in OVS or used the DPI libraries to add features to NICs or cloud host OS and middleware stacks. In any given service created by virtual means (orchestration) we presumably have a model that describes each element in the service and how it’s deployed. As we deploy stuff, we first look at policy and attributes of available resources to decide where to place/route something, then record where we put it.
The availability of DPI can be considered in our selection of resource placements, and we could also compose an explicit DPI virtual function into one of the components of a service. In the latter case, the service role of the DPI element is explicit. In the former case, we have a kind of “DPI in waiting”, there if we want to use it because we considered the chance of needing it in our decision of where to deploy something.
So let’s say that we have our vast web of Qosmos DPI stuff out there embedded in OVSs and other stuff, and that we have also composed DPI in some way (we’ll get to that) into services. How do we use it?
One easy application is IDP. We have a place where we think something bad is getting into the network. We could do a tap on that to look for packets addressed to our attack target to see if they’re emitted from a given place. That means letting OVS replicate a flow and direct it to Qosmos DPI, where we look for the attack signature. If we find it we move to Stage Two. That means either shutting down the port, or if we can’t because it’s shared, perhaps injecting DPI into the main flow to block the attack.
Monitoring as a service can work in a similar way, but let’s make it complicated to improve the example. We have a service that has a problem and the NOC wants to look at a particular packet stream. We know from the resource allocation where this particular stream goes (perhaps we get that from the OpenFlow controller), and we also have a map of where along that path we might have DPI points or taps where something could be diverted to DPI. So our management system shows our NOC expert the map and says “Where do you want to look?” When the operations person responds, the software sends a “Monitor-This” request to our MaaS service, and it responds by showing the NOC what they want to see at the point where they want to see it.
What I think this shows is that when you start virtualizing stuff, it’s hard to stop. You lose the benefit of a virtual environment any time you constrain it, and management, monitoring, policy control and other “non-service” elements are things that constrain as much as fixed boxes do, but because they’re behind the scenes in a functional sense we miss them. That’s bad, because we may miss opportunities that way too.