Best wishes for 2015!

[Franck BAUDIN]

Dear All,

 

Happy new year !

 

We finished 2014 with a bootstrap of specifications and API :

https://docs.google.com/document/d/1wnVY50O9ufSCX6E4f7s58U9_xyRMS80e5-9OnaVA30U

https://github.com/QosmosFranck/DPI-standard-API

 

Tomasz, Luca and Harold gave some feedback and we need to take some time to give more feedback, ideas, and API proposal. On the github, ,I pushed a skeleton of API that cannot be completely wrong as it’s over-simple and over-generic (to many void * ;-) ). Please commit your ideas directly, with /* XXX I’m not sure of this field */ when necessary, this is an easy way to move on and open debates.

 

Best Regards,

Franck

This message and any attachments (the "message") are confidential, intended solely for the addressees. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any other person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "message")sont confidentiels et établis à l'intention exclusive de ses destinataires. Si vous avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur par courrier électronique et d’effacer ce message de votre système. Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message et/ou en divulguer le contenu à un tiers. Tout message électronique est susceptible d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.

[Victor Julien]

Hi Franck, all,

On 01/12/2015 09:43 AM, Franck BAUDIN wrote:
> We finished 2014 with a bootstrap of specifications and API :
>
> https://docs.google.com/document/d/1wnVY50O9ufSCX6E4f7s58U9_xyRMS80e5-9OnaVA30U
>
> https://github.com/QosmosFranck/DPI-standard-API
>
>
>
> Tomasz, Luca and Harold gave some feedback and we need to take some time
> to give more feedback, ideas, and API proposal. On the github, ,I pushed
> a skeleton of API that cannot be completely wrong as it’s over-simple
> and over-generic (to many void * ;-) ). Please commit your ideas
> directly, with /* XXX I’m not sure of this field */ when necessary, this
> is an easy way to move on and open debates.

The main function seems to be:

int dpi_engine_inject_packet(void *opaque,

Where we have to pass an ethernet packet "packet: pointer to the first
byte of the packet Ethernet header"

In Suricata we run our own protocol parsing and detection:

1. header decoders (ethernet, ip, etc)
2. udp 'L7' detecting/parsing on top of UDP packet decoder
3. tcp 'L7' detection/parsing on top of TCP stream reassembly

Is the idea to introduce multiple entry points at multiple levels in the
stack? E.g. a function like:

int dpi_engine_inject_tcp_buffer(void *opaque, ...

So that we can include it in the proper place in our Suricata logic?

--
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------

[Franck BAUDIN]

Hi Julien,

> The main function seems to be:
>
> int dpi_engine_inject_packet(void *opaque,
>
> Where we have to pass an ethernet packet "packet: pointer to the first byte
> of the packet Ethernet header"
>
> In Suricata we run our own protocol parsing and detection:
>
> 1. header decoders (ethernet, ip, etc)
> 2. udp 'L7' detecting/parsing on top of UDP packet decoder 3. tcp 'L7'
> detection/parsing on top of TCP stream reassembly
>
> Is the idea to introduce multiple entry points at multiple levels in the stack?
> E.g. a function like:
>
> int dpi_engine_inject_tcp_buffer(void *opaque, ...
>
> So that we can include it in the proper place in our Suricata logic?

Yes, we should be able to inject packets, or payload (TCP, UDP, ...). This correspond to the 11h requirement of the google document:
"11. Compatible with external flow management and internal flow management"

I don't know (Harold should have an opinion on this) if we need a single L4-payload injection function or one per L4-protocol (UDP, TCP, SCTP, ...). Any thoughts on your side?