So there I was reading up on the latest advancements of DPI (Deep Packet Inspection) while stumbling upon on this promising achievement. It goes like this:
In order to create a rock-solid IPS (Intrusion Prevention System), capable of handling network speeds of up to 1 gigabit with standard Intel hardware, we had to devise a technology breakthrough in Layer 7 processing. Existing technologies were just too slow to keep up with network speed expectations.
It goes on to tell the reader their old engine was only capable of detecting P2P streams analyzing only headers, which barely even classifies as a Layer 7 engine. A true engine would at least be capable of detecting things like HTTP, FTP, SSL, SSH, mail protocols, and the like. It gets even more stunning when their throughput decreases from at least 1 GB/s to 20 MB/s when passing all packets to the old engine. I can only imagine the way the packets were being extracted from the Kernel and moved to user space and back was completely awful. Or maybe the pattern matching was so naive, it just couldn’t handle skimming through all the traffic anymore. It doesn’t matter. What’s interesting is that they claim their Layer 7 engine could only handle roughly 20 MB/s of P2P traffic while the whole thing was working with at least 1 GB/s. That isn’t very much DPI per GB/s.
But that’s not all. Apparently, it now seemed like a good idea to start using multiple processors for analysis at once. Like you could achieve several GB/s without it. All the vendors I can think have used this kind of leap in technology for many years. But I don’t want to be picky. The proposed solution is to clone a Socket Buffer, which is the Linux Kernel’s way of keeping track of a packet through its network stack. This was coupled with a mechanism called Kernel threading, which is just having threads that run in Kernel mode. There are a number of problems with this approach:
- It is stated that the skb is being cloned so that it can be analyzed by a different thread. What this also means is that the original skb will not be put into a temporary buffer. It will be passed through the appliance at this instance, which means it’s potentially compromising the network’s security. The claim is that the attack will be known a millisecond later, but for some types of attacks that might be to late. What this does is essentially downgrading IPS to IDS (Intrusion Detection System) functionality.
- Implementing such a mechanism is not hard, but running DPI in Kernel space can be a source of immense pain. Once the Kernel panics, it is gone, which means you have rendered your appliance useless. And believe me, implementing DPI yields a lot of those segmentation-fault-magic moments.
- If packets are sent away unmodified, there’s no SSL decryption. Attacks concealed using SSL will never be never found.
- GPL implications. That’s a very nasty subject. Legally, you are enforced to share all of the code you wrote which was derived from GPL code. Especially when you give it to someone else to generate revenue. In this case it is obvious the Kernel is being modified to do DPI. There’s a tiny loop-hole called Kernel modules, which can be licensed as “proprietary“. This feature was introduced ages ago to allow vendors to not share their code under the terms of the GPL, because it wasn’t written for the Linux Kernel specifically. Nowadays, this no longer holds true, because the Linux Kernel is the base for most products and so everything you do is derivative work – even if you hide it in a proprietary module. There are numerous other drawbacks like no support form the developer community, restricted use of Kernel APIs, and the like.
Last but not least, a commenter added that numerous vendors use standard Intel hardware by default while being able to achieve tremendous amounts of GB/s, so the approach can’t be that novel. The author chipped in to argue the price per GB/s ratio is better, which may be true, but I would argue the quality per GB/s is something else entirely.