From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf-next] netfilter: exthdr: add support for tcp option removal
Date: Mon, 27 Dec 2021 15:11:21 +0100 [thread overview]
Message-ID: <20211227141121.GB21386@breakpoint.cc> (raw)
In-Reply-To: <YcO5tQz5ImOxtZLx@salvia>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Mon, Dec 20, 2021 at 03:32:47PM +0100, Florian Westphal wrote:
> > This allows to replace a tcp option with nop padding to selectively disable
> > a particular tcp option.
> >
> > Optstrip mode is chosen when userspace passes the exthdr expression with
> > neither a source nor a destination register attribute.
> >
> > This is identical to xtables TCPOPTSTRIP extension.
>
> Is it worth to retain the bitmap approach?
I don't think so. For TCPOPTSTRIP it makes sense because
you can't use multiple targets in one rule.
I'd rework this to not set BREAK if the option wasn't present
in the first place, so you could do
delete tcp option sack-perm delete tcp option timestamp ...
and so on.
Let me know if you disagree.
I could also rework it so that option comes from sreg instead
of imm, but i could not find a use-case where having the option number
coming from a map lookup would make sense.
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> > ---
> > proposed userspace syntax is:
> >
> > nft add rule f in delete tcp option sack-perm
>
> nft add rule f in tcp option reset sack-perm,...
Why 'reset'? My initial version had 'remove' but 'delete'
already exists as a token so it was simpler.
next prev parent reply other threads:[~2021-12-27 14:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-20 14:32 [PATCH nf-next] netfilter: exthdr: add support for tcp option removal Florian Westphal
2021-12-22 23:50 ` Pablo Neira Ayuso
2021-12-24 16:07 ` Pablo Neira Ayuso
2021-12-27 14:11 ` Florian Westphal [this message]
2021-12-27 14:28 ` Pablo Neira Ayuso
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=20211227141121.GB21386@breakpoint.cc \
--to=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.