OpenDPI v.s. L7-filter

[hdxia]

Hello all,

I just downloaded the openDPI package, and played with it a little
bit. At the same time, I downloaded the L7-filter implementation
http://l7-filter.sourceforge.net/. It looks to me that both of these
do the same thing. However, L7-filter maintains patterns for each
protocol, but OpenDPI seems hard code the parttern into C files. From
the architect perspective, I feel the approach that L7-filter uses is
better.

Sorry that I am completely new to openDPI and L7-filter. My
observation is just based on a very short time of observation.

Could any of you compare these two, and explain what is the advantage
of OpenDPI, or L7-filter? Note that I am not trying to say which one
is better, but just want to know the difference between these two
purely for my personal perspective.

thank you
Haidong

[Joel]

The big difference is that L7 uses Netfilter and OpenDPI uses pcap.

Also in its current state OpenDPI cannot read packets from an
interface and only processes pcap files.

The benefit for OpenDPI would be if they add the code for live
capture. There are hardware accelerators and appliances that work well
with pcap based applications.

So if high speed through put is a requirement L7 will fall short,
where as a modified OpenDPI can achieve very high processing speeds.

// Joel

On Oct 18, 12:48 pm, hdxia <haidong....@gmail.com> wrote:
> Hello all,
>
> I just downloaded the openDPI package, and played with it a little

> bit. At the same time, I downloaded the L7-filter implementationhttp://l7-filter.sourceforge.net/. It looks to me that both of these

[Haidong]

Yeah. OpenDPI is a user-level implementation, which is easier to play
with. L7-filter requires kernel patch.

However, I didn't see the benefit with OpenDPI for live capture. If
hardware accelerators are used, L7-filter can take the advantage too.
In addition, It may be easier for L7-filter to use the hardware
accelerators since its protocol pattern is written in regex. There are
many regex hardware accelerators there. So the porting effort may be
easier. However, OpenDPI blinds the protocol pattern with code written
in C, which may be hard to transit to the regex accelerator.

thanks
Haidong

[CleBeer]

I use the iptables string match... is less heavy than L7  and is working fine...

but I want to debug OpenDPI in netxt weeks....

[]s

--
-----------------------------
Cleber S. Brandão
Mob. +55 011 9333-9429

clebeerpub.blogspot.com
www.snort.org.br
 ,, _    
o"    )~    
  '' ''
http://www.linkedin.com/in/clebeer
-----------------------------------

[Joel Ebrahimi]

Actually this is not the case. Many of the packet accelerating technologies are designed for user space applications. This provides the most flexibility. Since L7-filter is a kernel level application it does not benefit from many or the appliances or cards that are on the market. Also user space applications can use regex accelerators as well

// Joel . 

[Haidong]

Hmm... I never used a hardware accelerator. So I cannot speak for
it. :)

I think my main point is whether or not a good idea to mix the
protocol patterns with the C code. Isn't it nice that I just write the
pattern for a new protocol without writing C code, and just add that
pattern into a pattern file. Then the packet inspection engine can
support that protocol instantly. That's what L7 filter does. Another
example is the snort IDS sensor. The sensor engine implementation is
seperated from the signature file (pattern). So you just need to
update the signature/pattern file without changing or recompiling your
detection engine.

With the current OpenDPI implementation, you have to recompile it
whenever you modify the pattern of a protocol, remove, or add a new
one.

thanks
Haidong

On Oct 21, 10:41 am, Joel Ebrahimi <joel.ebrah...@gmail.com> wrote:
> Actually this is not the case. Many of the packet accelerating technologies
> are designed for user space applications. This provides the
> most flexibility. Since L7-filter is a kernel level application it does not
> benefit from many or the appliances or cards that are on the market. Also
> user space applications can use regex accelerators as well
> // Joel .
>