nftables: syntax ambiguity with objref map and ct helper objects

nftables: syntax ambiguity with objref map and ct helper objects

[Florian Westphal]

Hi,

I wanted to allow creating objref maps that
return "ct timeout" or "ct helper" templates.

However:
  map .. {
    type ipv4_addr : ct timeout

  The above is fine, but this is not:

  map .. {
    type ipv4_addr : ct helper


It caues ambiguity in parser due to existing
"ct helper" expression, as in
"nft describe ct helper", not the freestanding
objref name.

I could just allow:
    type ipv4_addr : helper

... without "ct", but then we'd require different
keywords for the definition and the use as data
element in the key definition, and its inconsistent
with "ct timeout".

Should we add a new explicit keyword for
*both* objref names and the data element usage?

Perhaps:

object type ct helper "sip-external" {
    ....

And
    type ipv4_addr : object type ct helper

?

Any better ideas or suggesions on a sane syntax to avoid this?

Re: nftables: syntax ambiguity with objref map and ct helper objects

[Pablo Neira Ayuso]

Hi Florian,

On Fri, Jul 28, 2023 at 09:56:14PM +0200, Florian Westphal wrote:
> Hi,
> 
> I wanted to allow creating objref maps that
> return "ct timeout" or "ct helper" templates.
> 
> However:
>   map .. {
>     type ipv4_addr : ct timeout
> 
>   The above is fine, but this is not:
> 
>   map .. {
>     type ipv4_addr : ct helper

This is type, not typeof, is it intentional?

> It caues ambiguity in parser due to existing
> "ct helper" expression, as in
> "nft describe ct helper", not the freestanding
> objref name.
> 
> I could just allow:
>     type ipv4_addr : helper
> 
> ... without "ct", but then we'd require different
> keywords for the definition and the use as data
> element in the key definition, and its inconsistent
> with "ct timeout".
> 
> Should we add a new explicit keyword for
> *both* objref names and the data element usage?
> 
> Perhaps:
> 
> object type ct helper "sip-external" {
>     ....
> 
> And
>     type ipv4_addr : object type ct helper
> 
> ?
> 
> Any better ideas or suggesions on a sane syntax to avoid this?

This works fine with typeof:

table ip x {
        map x {
                typeof ip saddr : ct helper
        }
}

it seems typeof support for 'ct timeout' is missing?

Thanks for reporting.

Re: nftables: syntax ambiguity with objref map and ct helper objects

[Florian Westphal]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> Hi Florian,
> 
> On Fri, Jul 28, 2023 at 09:56:14PM +0200, Florian Westphal wrote:
> > Hi,
> > 
> > I wanted to allow creating objref maps that
> > return "ct timeout" or "ct helper" templates.
> > 
> > However:
> >   map .. {
> >     type ipv4_addr : ct timeout
> > 
> >   The above is fine, but this is not:
> > 
> >   map .. {
> >     type ipv4_addr : ct helper
> 
> This is type, not typeof, is it intentional?

Yes, but doesn't matter for this problem.
Same ambiguity with

typeof ip saddr : ct helper

> This works fine with typeof:
> 
> table ip x {
>         map x {
>                 typeof ip saddr : ct helper
>         }
> }

My point is how nft should differentiate between

ct helper "bla" {

rule add ct helper "foo"

In above map declaration.  What does

"typeof ip saddr : ct helper" declare?
As far as I can see its arbitrary 16-byte strings, so the
above doesn't delcare an objref map that maps ip addresses
to conntrack helper templates.

Re: nftables: syntax ambiguity with objref map and ct helper objects

[Pablo Neira Ayuso]

On Mon, Jul 31, 2023 at 02:46:37PM +0200, Florian Westphal wrote:
[...]
> My point is how nft should differentiate between
> 
> ct helper "bla" {
> 
> rule add ct helper "foo"
> 
> In above map declaration.  What does
> 
> "typeof ip saddr : ct helper" declare?
> As far as I can see its arbitrary 16-byte strings, so the
> above doesn't delcare an objref map that maps ip addresses
> to conntrack helper templates.

Oh, indeed. Selector semantics are overloaded, I proposed kernel
patches that have remained behind:

https://patchwork.ozlabs.org/project/netfilter-devel/patch/20210309210134.13620-2-pablo@netfilter.org/
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20210309210134.13620-3-pablo@netfilter.org/

I also proposed change to have two selectors, one for the helper type
and another for the user-defined helper name. I still have to update
libnftnl and nftables.

I don't think this is specifically related to the map definition
itself, but the fact that the selector semantics is ambiguous.

Re: nftables: syntax ambiguity with objref map and ct helper objects

[Florian Westphal]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Mon, Jul 31, 2023 at 02:46:37PM +0200, Florian Westphal wrote:
> [...]
> > My point is how nft should differentiate between
> > 
> > ct helper "bla" {
> > 
> > rule add ct helper "foo"
> > 
> > In above map declaration.  What does
> > 
> > "typeof ip saddr : ct helper" declare?
> > As far as I can see its arbitrary 16-byte strings, so the
> > above doesn't delcare an objref map that maps ip addresses
> > to conntrack helper templates.
> 
> Oh, indeed. Selector semantics are overloaded, I proposed kernel
> patches that have remained behind:
> 
> https://patchwork.ozlabs.org/project/netfilter-devel/patch/20210309210134.13620-2-pablo@netfilter.org/
> https://patchwork.ozlabs.org/project/netfilter-devel/patch/20210309210134.13620-3-pablo@netfilter.org/

Even if we had those two patches in tree, we would still need
a different userspace syntax for the two cases.

We can't go for

"typeof ip saddr : ct helpername"

because we need to continue to support
ct helper "foo"

So maybe

typeof ip saddr : objref ct helper

Or:

typeof ip saddr : ct helper
flags objref

(Might be able to make this work by internally mangling
 the type after the "objref" flag is found).

> I also proposed change to have two selectors, one for the helper type
> and another for the user-defined helper name. I still have to update
> libnftnl and nftables.

Did not recall that.