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: netfilter-devel <netfilter-devel@vger.kernel.org>
Subject: Re: [RFC PATCH] netfilter: add connlabel conntrack extension
Date: Thu, 18 Oct 2012 18:51:04 +0200	[thread overview]
Message-ID: <20121018165104.GA15142@1984> (raw)
In-Reply-To: <1350577344-16321-1-git-send-email-fw@strlen.de>

On Thu, Oct 18, 2012 at 06:22:24PM +0200, Florian Westphal wrote:
> When users wish to annotate connections with extra information,
> (e.g. "connection came in on interface eth1"), the only way of doing so
> at the moment is using connmarks.
> 
> As connmark is only 32-bit wide, this can become a problem when the
> number of desired meta-information increases (especially true when also
> using connmarks to label policy routing marks, and/or using dpi crap, etc).
> 
> This patch essentially adds a kernel store of (user-defined) label names.
> Users can then assign these names to connections, with as many names per
> connection as desired (current - arbitrarily chosen - limit is 32k
> different names total).
> 
> Also includes match/target extensions to add/match based on connection names
> (or "connection labels").

I like this feature, but I'd propose that the kernel stores a specific
32-bits integer instead (not connmark, something new added as
extension. In user-space we would have a file like:

$ cat /etc/iptables/connlabel.conf
1 "traffic leaving from eth0"
2 "traffic entering eth0"
3 "http traffic"
...

So we can do something like:

iptables -I INPUT -i eth0 -m connlabel --set-connlabel "traffic leaving from eth0"

[ Note I'm proposing (ab)using the match so we can use it together with
targets in one single rule, we're doing that for nfacct so it should
not be a problem ]

The connlabel match will open the file and will look up for that
string.

Then, ctnetlink only dumps a 32-bits integer with the connlabel. We
can extend conntrack to translate connlabels to strings.

The kernel will work with integer, which is good for performance and
memory. User-space will work on the translation.

Adding rules will be slow via iptables, but we can add some quick path
in iptables-restore to open the file once and populate some array that
we can use for fast lookups. Same thing for the conntrack utility.

Does this match with your initiali idea or I'm missing anything?

Regards.

  reply	other threads:[~2012-10-18 16:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-18 16:22 [RFC PATCH] netfilter: add connlabel conntrack extension Florian Westphal
2012-10-18 16:51 ` Pablo Neira Ayuso [this message]
2012-10-18 20:38   ` Florian Westphal
2012-10-19  8:19     ` Pablo Neira Ayuso
2012-10-19  8:50       ` Florian Westphal
2012-10-19 13:15         ` Pablo Neira Ayuso
2012-10-19 13:52           ` Florian Westphal
2012-10-20 13:15           ` Ed W

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=20121018165104.GA15142@1984 \
    --to=pablo@netfilter.org \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.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).