I was there when they announced the proud arrival of the open source DPI engine OpenDPI. Totally in awe, I may add. A generous move towards the community. A chance to better the bitter fight in the field of net neutrality. The promise of easing the fear-mongering between governments and digital rights activists. Or just a clever marketing move? The industry cried out, but nobody heard their screams. The masses rejoiced, at least for a while.
So what was OpenDPI?
It was a stripped version of the commercial product called PACE – the Protocol Application Classification Engine. Encrypted protocol detections were being excluded as well as any performance optimisations (of which there have been quite a few).
Ok, but what did it mean?
It meant a lot to this young network technology branch. It brought transparency into the big cloud of uncertainty associated with available commercial products of its caliber. It also showed that there’s still a lot to learn and to advance. Detecting application layer protocols can be as simple as searching for a character in a byte stream, but it can also be fooled by simple displacement of that character.
And then what happened?
Life happened. The vibe that this wasn’t the best move was always with the project. It was a disaster to maintain as a LGPL licensed library, which made it hard to benefit from as a company. It was also hard to advance the project with the lack of a clear goal or roadmap. There just wasn’t interest in making the commitment implied by the release itself. There was a general lack of support and acceptance of patches.
On the other hand, it really did work. There was a lot of fuzz about the project and the company behind it. And, eventually, ipoque was acquired by Rohde & Schwarz. Allegedly, that’s why “OpenDPI is currently not available” looms on the official OpenDPI website nowadays.
Blowback time?
People got annoyed by the lack of commitment and did what was best: OpenDPI was forked by the ntop developers and named nDPI. Since then, there have been quite a few additions for the protocol detection, especially in the encrypted range. And also in the not-yet-supported-by-the-commercial-equivalent range. They also added a SSL decoder. Really, it’s impressive what OpenDPI could have been, but apparently, it did its business duty. Rest in peace, old lad.
Thank you for your article on OpenDPI. I used it in 2011 but felt that it needs to improve a lot to be a useful tool for developers. Hope that the nDPI project does what OpenDPI intended to do when it was started !!
You are right, but, for what it’s worth, the commercial engine is a good product with interesting ideas and bleeding edge approaches to DPI. Simply solid German engineering. However, I do not feel the general direction is completely promising anymore. I would like to see more parser/lexer-oriented approaches to application detection working on the actual application data streams. It seems way more natural in the networking context. If you can believe Wikipedia, it’s the shift from DPI to Deep Content Inspection (DCI). I don’t like the new name, but the ideas behind it are perfectly valid. ;)
I used to use iPoque appliance some years ago (2009-2011) for QoS and it was a very efficient product. I was very much happy when openDPI was freed.
Anyway, it is not dead, it’s in NTop which is also a very good product.