netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>,
	netfilter-devel <netfilter-devel@vger.kernel.org>
Subject: Re: [RFC] conntrack event framework speedup
Date: Wed, 16 Mar 2022 13:18:46 +0100	[thread overview]
Message-ID: <20220316121846.GD9936@breakpoint.cc> (raw)
In-Reply-To: <YjGp7pPqw8EzACDL@salvia>

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Hmmm, I don't think that will work.  The -j CT thing can be used to
> > enable event reporting (including the event type) for particular flows
> > only.
> 
> IIRC, it allows to filter what events are of your interest in a global
> fashion.
> 
> > E.g. users might do:
> > 
> > nf_conntrack_events=0
> > and then only enable destroy events for tcp traffic on port 22, 80, 443
> > (arbitrary example).
> > 
> > If I bump the listen-count, then they will see event reports for
> > for udp timeouts and everything else.
> 
> Are you sure? -j CT sets on the event mask. The explicit -j CT rules
> means userspace want to listen to events, but only those that you
> specified. So it is the same as having a userspace process to listen,
> but the global filtering applies.

The filtering isn't global, its per flow.  Provided
nf_conntrack_events=0, then only flows where the first packet matched
a -j CT rule will generate events, AND only those events that were
specified in its event mask.

So, flows that did not match any CT rule never generate an event, and,
therefore, changes to the kernel should not auto-add the extension for
them.

I don't see how that mechanism can be preserved without the ability to
set nf_conntrack_events=0.

When a new conntrack is generated, the test is (in current kernels):

'add the event cache extension if the template has an event cache
 extension OR if the sysctl is enabled'.

So, changing it to
'add the event cache extension if the template has an event cache
 extension OR if we have a listener' is not the same, unfortunately.

> My understanding is that the listen-count tells that packets should
> follow ct netlink event path.

Yes, thats correct, it tells kernel there is an active subscriber for
events.

> What am I missing?

I can't tell the following two cases apart:

1. templates are active and user wants events ONLY for the chosen flow,
   e.g. tcp.
2. templates are active and user wants only particular events for the
   chosen flows, but all events for the rest.


1) is done by templates + setting the sysctl to 0.
2) is done by templates + setting the sysctl to 1.

With 'assume 1 if listener active', we can only provide functionality of 2).

I finished testing of a prototype and it appears that functionality is ok,
I've pushed this here:
https://git.breakpoint.cc/cgit/fw/nf-next.git/log/?h=nf_ct_events_02

(only the top-most 4 changes are relevant).

  reply	other threads:[~2022-03-16 12:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15 12:05 [RFC] conntrack event framework speedup Florian Westphal
2022-03-15 21:30 ` Pablo Neira Ayuso
2022-03-15 21:41   ` Florian Westphal
2022-03-15 21:53     ` Pablo Neira Ayuso
2022-03-15 22:07       ` Florian Westphal
2022-03-16  9:12         ` Pablo Neira Ayuso
2022-03-16 12:18           ` Florian Westphal [this message]
2022-03-17  9:13             ` 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=20220316121846.GD9936@breakpoint.cc \
    --to=fw@strlen.de \
    --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).