netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: Krishna Kumar <krkumar2@in.ibm.com>,
	netfilter-devel@vger.kernel.org, svajipay@in.ibm.com,
	vivk@us.ibm.com, sri@us.ibm.com
Subject: Re: [RFC] [PATCH 0/4] netfilter: "fail-open" feature support for NFQUEUE
Date: Mon, 7 May 2012 11:14:14 +0200	[thread overview]
Message-ID: <20120507091414.GC27650@1984> (raw)
In-Reply-To: <20120507081029.GB5015@breakpoint.cc>

On Mon, May 07, 2012 at 10:10:29AM +0200, Florian Westphal wrote:
> Krishna Kumar <krkumar2@in.ibm.com> wrote:
> > Many users of an IBM security product, which uses netfilter's NFQUEUE
> > target to process packets in userspace, face a problem of dropped
> > connections during heavy load. Incoming packets are queued and
> > processed by the security module, which does deep packet analysis to
> > decide whether to accept or reject them. However during heavy load,
> > NFQUEUE queue (default 1024 entries) fills up and connections fail
> > after large number of packets drop during enqueue. Increasing the
> > queue size delays the problem and also worsens latency.
> > 
> > This patch set implements a "failopen" support to help keep connections
> > open during such failures. This is achieved by allowing acceptance of
> > packets temporarily when the queue is full, which enables existing
> > connections to be kept alive. Customers prefer this option as similar
> > feature is available on other systems.
> > 
> > This patch set implements failopen for NFQUEUE (though a similar patch
> > for IPQUEUE is also implemented but not submitted at this time). I will
> > submit the iptables changes which controls turning failopen mode on/off
> > later. The original requirement for sysctl option is not implemented -
> > please let me know whether that is acceptable/preferable.
> 
> I think that exposing this feature as userspace-changeable via netlink
> (eg. by adding "NFQA_CFG_FAILOPEN" attribute) rather than via ruleset
> would make most sense, as only the application can know wheter it
> can cope with missing packets.

Agreed.

I have a patch here to add NFAQ_CFG_FLAGS attribute, we can add some
new flag to specify this behaviour.

I'm using that with NFQNL_F_CONNTRACK flag to integrate
nfnetlink_queue with conntrack so it sends the conntrack together with
the packet via nfnetlink_queue.

  reply	other threads:[~2012-05-07  9:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-07  6:03 [RFC] [PATCH 0/4] netfilter: "fail-open" feature support for NFQUEUE Krishna Kumar
2012-05-07  6:03 ` [RFC] [PATCH 1/4] netfilter: Define FAILOPEN flag Krishna Kumar
2012-05-07  6:04 ` [RFC] [PATCH 2/4] netfilter: Add new argument to enqueue handlers Krishna Kumar
2012-05-07  6:04 ` [RFC] [PATCH 3/4] netfilter: Add support for failopen in nf_queue() Krishna Kumar
2012-05-07  6:04 ` [RFC] [PATCH 4/4] netfilter: Enable fail-open Krishna Kumar
2012-05-07  7:56   ` Florian Westphal
2012-05-07  9:04     ` Pablo Neira Ayuso
2012-05-07  8:10 ` [RFC] [PATCH 0/4] netfilter: "fail-open" feature support for NFQUEUE Florian Westphal
2012-05-07  9:14   ` Pablo Neira Ayuso [this message]
2012-05-07 13:51   ` Krishna Kumar2
2012-05-07 14:52     ` Florian Westphal

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=20120507091414.GC27650@1984 \
    --to=pablo@netfilter.org \
    --cc=fw@strlen.de \
    --cc=krkumar2@in.ibm.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=sri@us.ibm.com \
    --cc=svajipay@in.ibm.com \
    --cc=vivk@us.ibm.com \
    /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).