From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: POM Xtables??? Date: Thu, 24 Jul 2008 11:43:47 +0200 Message-ID: <48884ED3.8080901@trash.net> References: <935fab200806271054oa7c340evbf465b7a9984498b@mail.gmail.com> <4866F152.7030109@riverviewtech.net> <935fab200806300904rc7dc7b2kf58ab7893c3ef20a@mail.gmail.com> <486907EA.60105@trash.net> <48694787.3080906@trash.net> <4887BCE0.2050902@trash.net> <38bcb3ec0807240131n1f5d4051k9e89731aa2fcb6c9@mail.gmail.com> <488849A5.6050401@netfilter.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <488849A5.6050401@netfilter.org> Sender: netfilter-devel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Pablo Neira Ayuso Cc: James King , Jan Engelhardt , Dave , netfilter@vger.kernel.org, Netfilter Development Mailinglist Pablo Neira Ayuso wrote: > James King wrote: >> On Wed, Jul 23, 2008 at 4:21 PM, Patrick McHardy wrote: >> >>> Just send it to netfilter-devel. If its the thing with lots >>> of hard-coded binary matches full of magic values I'm not >>> interested :) I'd be more interested in a discussion what >>> would be necessary to represent all those matches through >>> the FSM textsearch match or something similar. >> >> ipp2p is the one with hard coded magic values. >> >> What are your feelings on the kernel version of l7filter (regex >> patterns loaded from the filesystem)? Currently it requires a patch >> to add a structure to nf_conn, but I've been meaning to rewrite it to >> use ct_extend so that it could at least be included into xtables-addon >> and used with a stock kernel, although if there's interest in having >> it merged into mainline I'd be willing to focus on that. That is definitely a much better way than to hardcode the matches. I think there is some interest in having this in the kernel, yes. >> One thing >> I'm not sure of is whether the license used by the Henry Spencer regex >> library it depends on is acceptable by kernel standards (or whether >> it's permissive enough to relicense under GPL, as IANAL). I know of the regexp.old.zip library, which IIRC used a GPL compatible license (and a non-POSIX conform interface). > If we want to do this in-kernel I think that it's better if it must use > the textsearch infrastructure. Probably it would require some patches to > extend the existing infrastructure. I'd also prefer that over adding a regex library to the kernel. I think one of the bigger problems is that there are dependencies in the match that can't be easily expressed, like "byte 4 has skb->len - 10". At least ipp2p does something like that. But maybe thats not necessary, since l7filter already uses regexes there's apparently a different method for doing this. It would be useful if someone could post an excerpt from the l7filter expressions or simply the entire patch. > The other choise is userspace by means NFQUEUE. If we use some > heuristics, we may try to classify the traffic by means of the initial > data packets and then mark the connection. Thus, the number of packets > that go to userspace would be small and the classification logic is > implemented in userspace using whatever regex > engine/aho-corasick/bit-wise/boyer-moore/bayes whatsoever... Yes, thats another possibilty (and a lot of people are doing that), but it would still be nice to have a mechanism for doing this in the kernel.