[Snort-users] Large receive offload, good or bad?

Joel Esler jesler at ...1935...
Thu Aug 30 10:59:24 EDT 2012

Response is from a fellow VRT member who is not on list, but is very smart in these things:

On Aug 30, 2012, at 5:25 AM, elof at ...6680... wrote:

> LRO sounds like a good thing - aggregating multiple incoming packets from 
> a single stream into a larger buffer before they are passed higher up the 
> networking stack will reduce CPU overhead.

While it is true that LRO does for the most part reduce the host cpu
overhead, there are a number of other things to consider.

As far as I know, there has been no research into security bugs in the
network cards and their firmware.  Or even into how their reassembly
and de-fragmentation engines deal with common evasion techniques such
as overlapping segments.

There is no way to set the max reassembly size in the network card,
this means that there is no way to ensure that snort does not truncate
a frame during processing.

> If one does not use target-based reassembly in snort,
> can/should LRO be enabled? What's you opinion?

There is no such thing as not using target based reassembly, if you
don't define rules stream5 will use the default reassembly target
(windows in the shipping config).

If I was deploying an I[DP]S I would investigate using a operating
system and network card that supports zero copy bpf sockets. This will
save you much more CPU time than using LRO and have much more
predictable results.

Joel Esler
Senior Research Engineer, VRT
OpenSource Community Manager

More information about the Snort-users mailing list