[Snort-devel] an indictment of my protocol engine proposal
tlewis at ...255...
Mon Apr 9 07:34:07 EDT 2001
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:
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
all just integer compares and mask events (bit-wise ands) and more
integer compares, all duct-taped together with simple boolean operators.
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? Is having the primitive operations so far removed
from their logical organization a good idea? I recently think not.
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.
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.
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. (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.
Language design and compiler construction is definitely not my strong
suit, and so I can make no promises about how this will turn out. I
will definitely be giving the matter my full attention, and I will
keep you, my fellow snort developers, informed.
As always, I would love to discuss this with anyone who has a thought
on the matter.
tlewis at ...255...
More information about the Snort-devel