Re: [RFC 0/4] nfnetlink_queue bypass queue to userspace X bytes of connection

[Pablo Neira Ayuso <pablo@netfilter.org>]

On 26/07/10 08:33, Karl Hiramoto wrote:
>  On 25/07/2010 12:42, Pablo Neira Ayuso wrote:
>>
>> You can limit the string matching for only a few bytes in the very
>> beginning of the packet. 
> That really doesn't help trying to find the "Host:" or path of or URL in
> HTTP because you don't know variables like cookie length, or other
> variables. String match also doesn't help me at all if the string is
> split across multiple packets

We can look for some string (in a limited range of bytes) that
preliminarily identifies some sort of traffic in kernel-space. In case
of matching, we pass the packet (or some short part of it) to user-space
via NFQUEUE. The whole specific packet parsing (such as looking at the
Host tokens of HTTP/1.1 that you refer) is done in user-space.

>> This extension seems to me very specific for HTTP/1.1.
> HTTP is the most popular protocol on the internet[1][2][3], optimizing
> the most common case has merits.
> 
> Besides HTTP  I can imagine this extension helping implementing a POP3
> or IMAP filter using NF_QUEUE.   For example many network UTM devices
> that scan attachments for viruses or other blocked content, will skip a
> compressed file that is over X bytes because there is not enough free
> memory to decompress and scan it.   In this case you could bypass the
> queue for X bytes, then continue scanning smaller files.

Making assumptions on the Content-Length and any other information in
the packet seems wrong to me. Someone could forge a packet to by-pass
filtering.