All of lore.kernel.org
 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: [PATCH nf-next] netfilter: exthdr: add support for tcp option removal
Date: Mon, 27 Dec 2021 15:28:16 +0100	[thread overview]
Message-ID: <YcnNgMtCPSeUQbIi@salvia> (raw)
In-Reply-To: <20211227141121.GB21386@breakpoint.cc>

On Mon, Dec 27, 2021 at 03:11:21PM +0100, Florian Westphal wrote:
> 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.

It's OK if you prefer this way. I can see references on the web to
reseting multiple options, not sure if it is actually useful in
practise, in such you can to parse the packet several times.

> 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.

'reset' also exists as a token. This is setting to nop, I just though
reset might make more sense, there might be a nice to really remove
TCP options in the future (costful but paranoid scenario, an observer
can spot options that have been nop)

      reply	other threads:[~2021-12-27 14:28 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
2021-12-27 14:28     ` Pablo Neira Ayuso [this message]

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=YcnNgMtCPSeUQbIi@salvia \
    --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 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.