netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Karl Hiramoto <karl@hiramoto.org>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [RFC 0/4] nfnetlink_queue bypass queue to userspace X bytes of connection
Date: Mon, 26 Jul 2010 08:50:00 +0200	[thread overview]
Message-ID: <4C4D3018.7050907@hiramoto.org> (raw)
In-Reply-To: <4C4C1524.8070805@netfilter.org>

 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


> 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.


[1]
http://torrentfreak.com/http-traffic-overtakes-p2p-courtesy-of-youtube/

[2]
http://www.nanog.org/meetings/nanog47/abstracts.php?pt=MTQ1MyZuYW5vZzQ3&nm=nanog47 <http://www.nanog.org/meetings/nanog47/abstracts.php?pt=MTQ1MyZuYW5vZzQ3&nm=nanog47>
[3]
http://www.cisco.com/en/US/netsol/ns827/networking_solutions_sub_solution.html#~forecast <http://www.cisco.com/en/US/netsol/ns827/networking_solutions_sub_solution.html#%7Eforecast>
NOTE talking about video being the most popular, a lot of video is delivered over HTTP. 


--
Karl



  reply	other threads:[~2010-07-26  6:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-24 15:44 [RFC 0/4] nfnetlink_queue bypass queue to userspace X bytes of connection Karl Hiramoto
2010-07-24 15:44 ` [RFC 1/4] netfilter/Kconfig: NF_QUEUE_CONNBYTES_BYPASS Karl Hiramoto
2010-07-24 15:44 ` [RFC 2/4] nf_conntrack_queue: define struct that will be stored in nf_ct_extend Karl Hiramoto
2010-07-24 15:44 ` [RFC 3/4] nf_conntrack: add nf_queue extension Karl Hiramoto
2010-07-24 15:44 ` [RFC 4/4] nfnetlink_queue: allow part of a connection to bypass the queue Karl Hiramoto
2010-07-24 18:26 ` [RFC 0/4] nfnetlink_queue bypass queue to userspace X bytes of connection Pablo Neira Ayuso
2010-07-25  6:55   ` Karl Hiramoto
2010-07-25 10:42     ` Pablo Neira Ayuso
2010-07-26  6:50       ` Karl Hiramoto [this message]
     [not found]       ` <4C4D2C33.6050901@hiramoto.org>
2010-07-26 17:35         ` Pablo Neira Ayuso

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=4C4D3018.7050907@hiramoto.org \
    --to=karl@hiramoto.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /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).