netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Graf <tgraf@suug.ch>
To: Pablo Neira <pablo@eurodev.net>, Harald Welte <laforge@gnumonks.org>
Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org
Subject: [RFC] string matching based packet classification/filtering
Date: Tue, 15 Feb 2005 21:32:11 +0100	[thread overview]
Message-ID: <20050215203211.GL31837@postel.suug.ch> (raw)

We have been discussing string matching based packet classification and
filterings a few times already and I'd like to make it serious this time
to get the string matching ematch ready for 2.6.12 inclusion. I'm aware
of the bayer-moore based patch by Emmanuel Roger, Gianni Tedesco, and Pablo
but I also heard about a generic string matching architecture supporting
various algorithms I haven't found that patchset though.

Is there any effort going into the generic architecture? Any plans for
a stateful string matching netfilter module? As it was mentioned already
we could share some code between the ematch and netfilter. I do not care
for the algorithm, actually I think it doesn't matter at all as long as
it's not a naive linear search. The essential parts are to be able to
define a searching range and to support paged skbs. If there is someone
going for the generic architecture fullfilling the essential parts
just described then I'll be more than happy to use that bit of code
otherwise I'd be happy to discuss the requirements of both sides and
try to find a compromise both sides can live with.

The requirements from my side:
 In:
  o pattern as byte stream
  o length of pattern
  o begin of search range (skb layer + offset)
  o end of search range (skb layer + offset)
  o (p)skb
 Out:
  o true or false

Applying this on the recently posted implementation by Pablo it shows
that it nearly fits already except for the search range. Additionaly
it could be improved by using prefix optimizations for the fragment
border regions instead of a naive string search which would help for
large patterns on paged skbs.

If needed an additional input argument could be added specifying the
algorithm to be used. Eventually it requires an additional algoirthm
specific argument carrying meta data such as prefix lookup tables.

Thoughts?

             reply	other threads:[~2005-02-15 20:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-15 20:32 Thomas Graf [this message]
2005-02-15 21:41 ` [RFC] string matching based packet classification/filtering Pablo Neira
2005-02-15 21:56   ` Thomas Graf
2005-02-16 22:30   ` Thomas Graf
2005-02-17  1:00     ` Pablo Neira
2005-02-17 13:31       ` Thomas Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050215203211.GL31837@postel.suug.ch \
    --to=tgraf@suug.ch \
    --cc=laforge@gnumonks.org \
    --cc=netdev@oss.sgi.com \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=pablo@eurodev.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).