We all know the gist: linked lists are cool, but they when they tend to grow performance drops considerably. Lookup speed and allocation overhead can be costly. The migration to trees or other structures may or may not bring the desired results. In contrast, embedding a number of elements into linked list node can help quite a bit with all of these issues.
Just to get it out of the way: the simplicity and effectiveness of netmap(4) is an achievement in itself. I’ve had the opportunity to work on similar proprietary code in my past, but we faced ever new complications and bottlenecks. There are no immediate problems with netmap(4). I’m especially intrigued by the zero-copy feature, which boosts both latency and throughput considerably.
A really tricky issue with DPI is how to avoid port checks inside the code while making sure the code doesn’t produce false positives. For example, it’s not possible to reliably detect data transfer connections in FTP. If one doesn’t add port 20 to the equation, it’s not possible to detect those transfers properly. That’s just one of a couple of cases where one is inclined to use the port-based approach to make the detection more reliable. But here comes the kicker: It makes hiding traffic easy while also providing the administrator with a false sense of security.
Happy DPI release day, everyone! Three months ago we were talking about how DPI technology could be improved further. Essentially, we were not satisfied with the current state of things. And there is no viable BSD-licensed code that’s fit for use with high load and mission critical networking infrastructure. Then we read a lot of papers floating around regarding the topic and started hacking. Now we proudly present our Lightweight Inspection to the public.
Our key requirements were as follows:
A Short Introduction
The time is nigh! I know all the teasing about DPI is annoying, but this will be the last article before the release of libpeak’s lightweight inspection. Thirty protocols have been prepared and polished so far. But back to the Domain Name System (DNS) for the time being. We all use it on a daily basis. And, well… covering this topic is too much for this context. If you want to learn about the implementation details, please kindly look at RFC 1035. Let’s get straight to the biscuits.
Welcome, this is a service announcement. It has come to my attention that there already is a libpeak library, but it hasn’t been active for years, so I don’t mind. Does anyone advise against that? Anyway, since I’m working on releasing fresh DPI code, there is still some code glue missing to invoke it properly. I’ve taken the time to implement simple flow tracking based on red-black trees. I know the implementation doesn’t hold up against the speed of hash tables (and has absolutely no optimisations), but the thing is that hash tables are not really optimal in all other aspects. Let’s get into the science for the sake of it!
A Short Introduction
Okay, this is going to be sort of demanding. Secure Socket Layer (SSL) and now rather Transport Layer Security (TLS) are at the heart of our current encrypted communication via the Internet. Let’s not get too much into the history here, but consider this: SSL was developed by Netscape in the nineties and version 3.0 was used as the base for the open standard TLS 1.0 via RFC 2246 in 1999. On the wire, the protocol presents itself on top of TCP. (A variation is DTLS, which is used on top of UDP.) The unencrypted header structures are well-defined and thus perfect candidates for DPI, especially for Lightweight Inspection (LI). I’m going to refrain from putting “packet” into the term, because LI may work on top of streams as well, as it is not aware of packets. That makes things easy by unwinding the protocol stack and avoiding packet parsing/manipulation inside the engine itself.