Re: [PATCH] selftests: nft_queue: conntrack expiration requeue

[Florian Westphal <fw@strlen.de>]

Antonio Ojea <aojea@google.com> wrote:
> The nfqueue mechanism allows userspace daemons to implement complex,
> dynamic filtering rules. This is particularly useful in distributed
> platforms like Kubernetes, where security policies may be too numerous
> or change too frequently (in the order of seconds) to be implemented
> efficiently in the dataplane.
> 
> To avoid the performance penalty of crossing between kernel and
> userspace for every packet, a common optimization is to use stateful
> nftables rules (e.g., ct state established,related accept) to bypass the
> queue for packets belonging to known flows.
> 
> However, if there is the need to reevaluate the established connections
> using the existing rules, we should have a way to stop tracking the
> connections so they are sent back to the queue for reevaluation.
> 
> Simply flushing the conntrack entries does not work for TCP if tcp_loose
> is enabled, since the conntrack stack will recover the connection

you mean disabled?
loose tracking (midstream pickup) is on by default.

> state. Setting the conntrack entry timeout to 0 allows to remove the state
> and the packet is sent to the queue.

But its the same as --delete, entry gets tossed (its timed out) and is
re-created from scratch.

> This tests validates this scenario, it establish a TCP connection,
> confirms that established packets bypass the queue, and that after
> setting the conntrack entry timeout to 0 subsequent packets are
> requeued.

That zaps the entry and re-creates it, all state is lost.
Wouldn't it make more sense to bypass based on connmark or ctlabels?

I'm not sure what the test is supposed to assert.

That setting timeout via ctnetlink to 0 kicks the entry out of the ct hash?