Re: let nftables indicate incomplete dissections

[Florian Westphal <fw@strlen.de>]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Add a "bool incomplete" to libnftnl strnct nftnl_expr, then set it
> > from each expr->parse callback if there is a new netlink attribute that
> > we did not understand.
> > 
> > nft then checks if this is incomplete-marker is set.
> 
> Is this sufficient? There are attribute values that could have an
> unknown/unsupported value, eg. exthdr type (assuming a new extension
> is supported).

No, but libnftnl can't known (and should not care) if nftables can
eat the value provided.

i.e., 'incomplete' means 'there were attributes that I did not understand',
nothing more.

> I am afraid setting incomplete for an unknown attribute also restricts
> netlink extensibility.

How so?

> Netlink allows for adding new attributes. Attributes also determine
> semantics, eg. exthdr type restricts the semantics of other existing
> attributes. There are also flags attributes which provide a hint on
> what is support or not, toggling such flag allows kernel to reject
> something that is not support.

But thats up to higher level tool, i.e. nftables?

I don't think libnftnl should try to guess if nftables can make
sense of the rule provided (or set, element, etc).

> > > > Related problem: entity that is using the raw netlink interface, it
> > > > that case libnftnl might be able to parse everything but nft could
> > > > lack the ability to properly print this.
> > > 
> > > There are two options here:
> > > 
> > > - Add more raw expressions and dump them, eg. meta@15, where 15 is the type.
> > >   This is more compact. If there is a requirement to allow to restore
> > >   this from older nftables versions, then it might be not enough since
> > >   maybe there is a need for meta@type,somethingelse (as in the ct direction
> > >   case).
> > 
> > Yes, for attributes that libnftnl knows about but where nft lacks a name
> > mapping (i.e., we can decode its META_KEY 0x42 but we have no idea what
> > that means we could in fact add such a representation scheme.
> > 
> > > - Use a netlink representation as raw expression: meta@1,3,0x0x000000004
> > >   but this requires dumping the whole list of attributes which is chatty.
> > 
> > Yes.  Perhaps its better to consider adding a new tool (script?) that
> > can dump the netlink soup without interpretation.  IIRC libmnl debug
> > already provides this functionality.
> > 
> > Very chatty but it would be good enough to figure out what such
> > hypothetical raw client did.
> 
> I see, a binary netlink dump format.

Yes, kinda like objump/readelf.