[Oisf-users] For those who haven't read this

[Robert Vineyard]

I'm somewhat familiar with PF_RING, having followed Luca Deri's work for
some time. I know that he also has a threaded driver for Intel cards that
allows them to perform even further load-balancing (using multiple rings)
in-kernel, but have not had a chance to test it yet.

My question is really whether the multi-threading in Suricata is comparable
to the approach described in Marty Roesch's analysis (multiple threads
analyzing the same data, resulting in performance hits due the complexity of
managing cache coherency) or whether it's more focused on the model of
letting separate threads/processes handle separate data streams along the
lines of what Endace and Napatech (and to some extent Luca's PF_RING and the
Sniffer10G project at Myricom) to avoid the need to synchronize thread-local
storage and CPU caches, which seems like a more efficient approach.

I'm really just asking to get an idea of the roadmap for the internals of
the Suricata engine, as I feel that the VRT blog article brings up some very
good points about reinventing the wheel. The OISF community has clearly
taken on a herculean project and seems to be producing quite impressive
results so far, but I'm wondering if the core packet decoding and dispatch
infrastructure was designed with scalability (perhaps to 100Gb) in mind?
Perhaps a hybrid approach similar to the BRO IDS is in order? (BRO can be
used in a clustered setup where the nodes can run on the same or separate
machines and communicate with each other using a specialized back-end API to
facilitate correlation of detection data across load-balanced data streams.

Today I'm running a setup with 16 copies of Snort load-balanced across 16
CPU cores using the Napatech / nPulse NT20E (aka PCAPExpress) 10Gb card,
which works very well but is quite complex to manage and of course the
capture card with dedicated FPGA hardware for doing the load-balancing was
not cheap (although it was more cost effective than the cPacket/Cisco
load-balancing solution proposed by the BRO cluster folks). Suricata seems
poised to alleviate the need for some of this expensive proprietary
hardware, although I'm definitely looking forward to seeing how the
refinement of support for CUDA and friends can contribute to the overall
throughput that the engine can handle.

--
[ Robert Vineyard | RHCE, Security+ ]    [ robert.vineyard at oit.gatech.edu  ]
[ Information Security Engineer III ]    [ 404.385.6900 | FAX 404.894.9548 ]
[Finding a needle in a haystack isn't hard when every straw is computerized]

On 07/21/2010 04:02 PM, Will Metcalf wrote:
> Aside from that we also support in kernel load balancing via PF_RING.
> You have the option of specifying the way in which it load balances on
> a per-flow or round-robin basis.  Basically suricata allows you to set
> a cluster-id and then packets are load balanced across
> threads/processes with the same cluster-id.
> 
> Regards,
> 
> Will
> 
> On Wed, Jul 21, 2010 at 1:58 PM, Robert Vineyard
> <robert.vineyard at oit.gatech.edu> wrote:
>> http://vrt-sourcefire.blogspot.com/2010/06/single-threaded-data-processing.html
>>
>> Here's another link (a writeup by Marty Roesch of Sourcefire) referenced
>> from the article you mentioned.
>>
>> In light of this discussion, does OISF / Suricata have a response to
>> Sourcefire's critique of a multi-threaded engine model that uses several
>> threads to process the same data simultaneously? It seems to me that the
>> most efficient way to do things would be to have a front-end load-balancer
>> that could distribute the traffic to multiple back-end threads or processes
>> that would each operate on independent data streams. This is the strategy
>> employed by Endace and others to accomplish high-throughput IDS inspection.
>> On a related note, are there any plans to implement native acceleration
>> support for other vendors besides Endace (in particular Napatech / nPulse)?
>>
>> Thanks!
>>
>> --
>> [ Robert Vineyard | RHCE, Security+ ]    [ robert.vineyard at oit.gatech.edu  ]
>> [ Information Security Engineer III ]    [ 404.385.6900 | FAX 404.894.9548 ]
>> [Finding a needle in a haystack isn't hard when every straw is computerized]
>>
>>
>> On 07/21/2010 07:05 AM, Kevin Ross wrote:
>>> http://vrt-sourcefire.blogspot.com/2010/07/innovation-you-keep-using-that-word.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Vrt+(Sourcefire+VRT+-+Vulnerability+Research%2C+Snort+Rules+and+Explosions)
>>> <http://vrt-sourcefire.blogspot.com/2010/07/innovation-you-keep-using-that-word.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Vrt+(Sourcefire+VRT+-+Vulnerability+Research%2C+Snort+Rules+and+Explosions)>
>>>
>>>
>>>
>>> _______________________________________________
>>> Oisf-users mailing list
>>> Oisf-users at openinfosecfoundation.org
>>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>> _______________________________________________
>> Oisf-users mailing list
>> Oisf-users at openinfosecfoundation.org
>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>