[Snort-devel] an indictment of my protocol engine proposal

Fyodor fygrave at ...1...
Mon Apr 9 16:20:30 EDT 2001

On Mon, Apr 09, 2001 at 07:34:07AM -0400, Todd Lewis wrote:
> Last week I submitted a draft rfc entitled "A Proposal for Reengineering
> Snort's Packet Matching System".  I was just now reading RFC 2328,
> the latest OSPF RFC, when I started to question the wisdom behind this
> proposal.  In the interests of honesty and the good of the project, and
> since no one else has done it, I will now procede to gut the proposal
> that I spent five days crafting:

Err.. still reading/putting inlined comments in it. Hoperfully will post it
tomorrow.. :)

> The protocol engine mechanism I propose is too heavyweight.
> With the single exception of regexps, I can't think of any protocol
> operations that merit having a separately coded implementation.  They are

IMHO if there's a choice between regexps and protocol-specific processing engine,
I would stick with the later, most of the regexp implementations I know are quite
complicated and 'cpu-hungry'.

> all just integer compares and mask events (bit-wise ands) and more
> integer compares, all duct-taped together with simple boolean operators.

For some protocols stateful analysis may be wanted. IMHO that's a way easier to
handle within a protocol plugin than trying to invent a language which could be
used to track down the protocol. (events variables, events masks, and
state-conditional content matches. Sounds like a big coding issue, plus would
involve alot of expertise from a user-side to be able to create new rules. Do
we want to be another NFR?)

> Every one of them is doable in a single machine instruction on any
> processor I've ever read the manual for.  Does this really merit the,
> what, 30, 50 instructions that a (pointer-jumping) function call into
> PIC code is going to take, never mind the memory access costs of a code
> footprint that big?

PIC code shouldn't really slow down the implementation, last time I looked
shared library stubs just involved a a couple of extra jumps/returns on in
and out of the procedure.

>  Is having the primitive operations so far removed
> from their logical organization a good idea?  I recently think not.

"recently think"...? :) 

> I do stand by the design criteria.  Snort rules should be writable which
> combine protocol operations at any layer in the stack.  Matching packets
> to rules should be an optimizeable operation.  Adding new protocols
> should be easy to do.  I just am skeptical that having code for each
> protocol is the best way to do it.

Adding new rules should be easy, protocols should not nessesarily be easy thing
to do (it should be modular so new protocol modules could be easily plugged
though). It takes a great expertise of understanding the protocol itself to be
able to describe protocol-specific rules properly. I don't think 'everyday
users' are willing to deal with this stuff. I quite the approach which has been
taken with sp_* plugins in snort 1.x, those who can code protocol specific
modules: code and contribute it...

> An alternative that springs to mind would be to write a language for
> protocol description.  The idea of decomposing successive protocol
> layers would still apply, but it would be done by an engine that has been
> primed by the protocol descriptions.  Adding support for a new protocol
> would consist of writing a protocol description for it and passing the
> description into snort.

Sounds a way complicated to me. I read a couple of papers on
protocol-desciptive languages and most of them sound like high-math sci theory
rather than something practical that we could apply.. The best approach which
could be taken is something similar to current tcpdump code, where you could
match packet offsets/transport protocols/parameters. By adding some kind of event
table to this model we could get something useful, but it sounds a way huge to be
implemented to me.

> I am not sure at all what this would look like.  Protocol engines may
> still be needed for some functions, like defrag'ing, in which case
> the resulting system would look a lot more like the status quo than
> my proposal.

tcp streaming as well.. IMHO, most of protocol engines should be

'octets stream in -- octets stream out', and each protocol engine should be able to:

1. suppress stream out until additional data is received.
2. drop packet and avoid further processing.
3. Select which protocol engines are capable of further processing of
certain octets stream... 

>  (Not that that is a bad or a good thing; I don't know.)
> Perhaps we could reuse pcap's bytecode system for this, or maybe not.
> I just don't know right now.

You mean for the protocol language? that's what I am refering above..

PGP fingerprint = 56DD 1511 DDDA 56D7 99C7  B288 5CE5 A713 0969 A4D1

More information about the Snort-devel mailing list