OpenDPI Future Plans

[Joel]

It is hard to infer from the press release and existing documentation
what the overall goal is for this open source project.

It would seem there some key pieces that could be added to make this
software much more valuable, such as live pcap processing and traffic
management. Also increasing the number of protocol decoders and
analyzers is key.

It sounds like from reading the OpenDPI Integration Manual that a
number of protocol analyzers already exist but have been removed.
Handling IPv6 traffic has also been removed. So to some extent it
would seem that for this software to be more useful, developers here
would need to reinvent the wheel.

So it makes it difficult to understand this project. Could someone
maybe explain the goals, actions and contributions they would like to
see.

Thanks

// Joel

[hendrik...@ipoque.com]

Joel,

thanks for your detailed thoughts. I will use the chance to explain
our strategy in a little bit more detail.

The overall objective is to make OpenDPI more valuable. We plan to do
this in multiple ways: pattern updates, new protocols and features,
and external interfaces and tools to "really" use OpenDPI.

Pattern Updates:
================
We will update detection patterns for existing protocols frequently.
ipoque's commercial DPI engine and OpenDPI will be kept synchronized
here.

New Protocols and Features:
===========================
... will follow. A main point on our agenda is IPv6 support. For IPv6
we currently disentangle dependencies from proprietary code. I will
provide a list of protocols we are working on (hopefully in October).
Another feature we are working on is the support of asymmetric
traffic. This has the same status like IPv6.

In general I see a lot of potential for volunteers here.

Interfaces and Tools:
=====================
The most useful thing would be an iptables integration. This would
allow the use of its powerful traffic shaping and firewall
functionalities. The "live pcap processing" is a great idea, but we
are lacking the resources to implement this, so it would be great if
this is done by a volunteer too.


Here is our preliminary roadmap:
================================
- IPv6 support
- asymmetric traffic
- iptables wrapper


In general, we invite everybody to contribute to this project.
Therefore we have activated the code repository and the issue tracker.


Hendrik

[Joel]

Thanks Hendrik!

That clears a number of things up for me. I look forward to seeing how
this progresses.

// Joel

[pollux]

Hi,

First of all thanks for releasing OpenDPI under a free license.

On Sep 16, 11:37 am, hendrik.schu...@ipoque.com wrote:
> Interfaces and Tools:
> =====================
> The most useful thing would be an iptables integration. This would
> allow the use of its powerful traffic shaping and firewall
> functionalities. The "live pcap processing" is a great idea, but we
> are lacking the resources to implement this, so it would be great if
> this is done by a volunteer too.
>

For iptables integration, I just wrote some code that may interest
you: I have adapted the demo code to use libnetfilter_queue, so the
daemon receives paquets sent through the netfilter NFQUEUE target.
This required minimal modifications of the code (it uses the same
algorithm and kind of callback), works in userspace (so does not need
any kernel patch) and does not need any refragmentation since
netfilter handles it :)

If you're interested just tell me.

Cheers,
Pierre

[pollux]

I just forgot the link to the post:
http://www.wzdftpd.net/blog/index.php?2009/09/17/42-playing-with-opendpi

/P