netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: let nftables indicate incomplete dissections
Date: Tue, 18 Jun 2024 10:11:46 +0200	[thread overview]
Message-ID: <ZnFBQmrX9FgTG8rb@calendula> (raw)
In-Reply-To: <20240612075013.GA13354@breakpoint.cc>

On Wed, Jun 12, 2024 at 09:50:13AM +0200, Florian Westphal wrote:
> "nft list ruleset" currently omits things it does not understand
> and that it cannot represent in any other way.
> 
> This includes:
> 1. expression is unknown
> 2. expression is known (e.g. "cmp"), but attr contains unexpected value
> 3. expression is known but there is an unknown netlink attr contained in
> the dump
> 
> If backend (libnftl) could mark expressions as incomplete (from .parse
> callbacks?), it would be then possible for the frontend (nft) to document
> this, e.g. by adding something like "# unknown attributes", or similar.

ack, how do you plan to handle this?

> This is mainly needed for container environments, where host environment
> might be using a lot older version than what is used by a specific
> container image.
> 
> 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).
- Use a netlink representation as raw expression: meta@1,3,0x0x000000004
  but this requires dumping the whole list of attributes which is chatty.

Or explore a combination of both.

I am telling all this because I suspect maybe this "forward
compatibility" (a.k.a. "old tools support the future") could rise the
bar again and have a requirement to be able to load rulesets that
contains features that old tools don't understand.

> If noone has any objections, I would place this on my todo list and
> start with adding to libnftnl the needed "expression is incomplete"
> marking by extending the .parse callbacks.

Maybe it is worth exploring what I propose above instead of displaying
"expression is incomplete"?

  parent reply	other threads:[~2024-06-18  8:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-12  7:50 let nftables indicate incomplete dissections Florian Westphal
2024-06-12 13:02 ` Phil Sutter
2024-06-18  8:11 ` Pablo Neira Ayuso [this message]
2024-06-18  9:31   ` Florian Westphal
2024-06-24 18:14     ` Pablo Neira Ayuso
2024-06-24 21:24       ` Florian Westphal

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=ZnFBQmrX9FgTG8rb@calendula \
    --to=pablo@netfilter.org \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.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).