Re: [PATCH iptables v2 0/8] extensions: libxt_NFLOG: use nft back-end for iptables-nft

[Jeremy Sowden <jeremy@azazel.net>]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

On 2022-01-17, at 11:40:51 +0100, Phil Sutter wrote:
> On Sun, Jan 16, 2022 at 08:08:15PM +0100, Florian Westphal wrote:
> > Jeremy Sowden <jeremy@azazel.net> wrote:
> > > On 2021-10-01, at 18:41:34 +0100, Jeremy Sowden wrote:
> > > > nftables supports 128-character prefixes for nflog whereas
> > > > legacy iptables only supports 64 characters.  This patch series
> > > > converts iptables-nft to use the nft back-end in order to take
> > > > advantage of the longer prefixes.
> > > >
> > > >   * Patches 1-5 implement the conversion and update some related
> > > >     Python unit-tests.
> > > >   * Patch 6 fixes an minor bug in the output of nflog prefixes.
> > > >   * Patch 7 contains a couple of libtool updates.
> > > >   * Patch 8 fixes some typo's.
> > >
> > > I note that Florian merged the first patch in this series
> > > recently.
> >
> > Yes, because it was a cleanup not directly related to the rest.
> > I've now applied the last patch as well for the same reason.

Thanks for that.

> > > Feedback on the rest of it would be much appreciated.
> >
> > THe patches look ok to me BUT there is the political issue that we
> > will now divert, afaict this means that you can now create
> > iptables-nft rulesets that won't ever work in iptables-legacy.
> >
> > IMO its ok and preferrable to extending xt_(NF)LOG with a new
> > revision,

Indeed.  The original proposal from Cloudflare was to extend xt_NFLOG,
but Pablo requested that iptables-nft be modified instead.  Hence this
series.

> > but it does set some precedence, so I'm leaning towards just
> > applying the rest too.
> >
> > Pablo, Phil, others -- what is your take?
>
> I think the change is OK if existing rulesets will continue to work
> just as before and remain compatible with legacy. IMHO, new rulesets
> created using iptables-nft may become incompatible if users explicitly
> ask for it (e.g. by specifying an exceedingly long log prefix.
>
> What about --nflog-range? This series seems to drop support for it, at
> least in the sense that ruleset dumps won't contain the option. In
> theory, users could depend on identifying a specific rule via nflog
> range value.

Fair enough.  I'll add a check so that nft is not used for targets that
specify `--nflog-range`.

J.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]