[RFC nft] ct expr: make directional keys work

[Florian Westphal <fw@strlen.de>]

some ct expressions don't work at the moment since we never set the
'direction' attribute, but kernel mandates it.

The current approach i've been working splits ct keywords into
two groups, one mandates a 'direction' argument (saddr, protocol),
others do not (mark for example).

Would this syntax be acceptable?

ct saddr original 192.168.0.1

If not, I'd like suggestions on how this should look like instead.

Since the saddr (and a few other) arguments have unknown size
(depends on the l3 tracker tuple sizes), its currently filled in
later depending on NH base (i.e. in nft upstream).

This means that

ct proto-dst original ssh

will NOT work, but

ct protocol original tcp ct proto-dst original ssh

would.  Is that ok?  I don't see how I could auto-add the dependency in
such case.

Moreover, while this is currently implemented as a dependency (type set to
inet_service if PROTO_BASE_TRANSPORT_HDR present) the kernel does just
fetch a 16 bit quantity from the tuple so there is no real dependency
-- its just raw data.

So we could actually allow things like

ct proto-dst original 22

and it would match anything that has a 22 in the dst.tuple.all field...
but -- does that make sense?

Finally, I'm working on support for packets and byte counters.

Fetching original or reply directions would 'just work' after
directional keys are supported, i.e.:

ct packets original > 100

But I'm not sure how we should handle the case where someone wants to test
'X bytes/packets in total'.

ct packets > 100:
could be confusing, also not sure how difficult it is
to allow ct keywords that have an optional direction

ct packets both > 100: also looks wrong to me

ct packets original + ct packets reply > 100:
Looks like the most nft-esque solution to me, but would need new EXPR_ADD.

Thoughts?

Thanks,
Florian