From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>,
Jeremy Sowden <jeremy@azazel.net>,
Netfilter Devel <netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH nftables 8/8] test: py: add tests for shifted nat port-ranges
Date: Tue, 11 Apr 2023 14:28:01 +0200 [thread overview]
Message-ID: <20230411122801.GE21051@breakpoint.cc> (raw)
In-Reply-To: <ZDVH+puTElQrkblc@calendula>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > so assuming a map that has
> >
> > typeof ip saddr . ip daddr : ip daddr . tcp dport
>
> I am not sure we can use . tcp dport here, we might need a specific
> datatype for offset.
Right. integer will work fine. We will need a pseudotype
for 'typeof', tcp dport won't work as-is because nftables won't
know it needs to do the offset thing under the hood (math op or
flag or whatever).
> > ... but the map content stores the delta to use, e.g.
> >
> > { 192.168.7.1 . 10.2.2.2 : 10.2.2.1 . 10000 }
> >
> > ... where 10000 isn't the new dport but a delta that has to be added.
> >
> > [ payload load 4b @ network header + 12 => reg 1 ] # saddr
> > [ payload load 4b @ network header + 16 => reg 9 ] # daddr
> > [ lookup reg 1 set m dreg 1 0x0 ] # now we have reg1: dnat addr, reg 9: delta to add
> > [ payload load 2b @ transport header + 2 => reg 10 ]
> > [ math add reg 9 + reg 10 => reg 9 ] # real port value from packet added with delta
> > [ nat dnat ip addr_min reg 1 addr_max reg 1 proto_min reg 9 proto_max reg 9 flags 0x3 ]
>
> It is very similar to my proposal, but using an explicit: payload +
> math.
Yes.
> How are you going to express this in syntax? Maybe this:
>
> { 192.168.7.1 . 10.2.2.2 : 10.2.2.1 . +10000 }
>
> or
>
> { 192.168.7.1 . 10.2.2.2 : 10.2.2.1 . -10000 }
>
> so + or - tells this is an offset. Parser will need this notation, so
> the evaluation step infers the map datatype from the element.
>
> For explicit maps, we need the datatype to interpret that this is an
> offset accordingly.
Yes. This will also mean you can't mix real port value with offsets.
(which i don't think is a problem).
> > add operation should probably also take a modulus (fixed immediate value)
> > so we can make a defined result for things like:
> >
> > 65532 + 10000
> >
> > ... without a need to wrap implicitly back to "0 + remainder".
>
> not sure I follow this modulus idea.
What should happen if you add, say, 20k, but the packet dport is larger
than (0xffff - 20k) ?
If I undertand correctly, with current iptables this will be placed
in the desired offset range, rather than wrap back to 0.
> > But maybe i'm missing something that the nat engone is already offering
> > that this approach can't handle, or some other limitation.
>
> Your proposal is not a deal breaker to me, I think it will be more
> work to explore than my proposal, but this delta datatype might be
> useful in the future for generic delta add/sub in other payload / meta
> fields.
Ok, right, I don't think there is anything bad with your proposal
either.
Even Jeremys rebased kernel patchset looks fine to me, I just dislike
the proposed syntax (since it follows the iptables one which I don't
like either :-) )
next prev parent reply other threads:[~2023-04-11 12:28 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-05 10:14 [PATCH nftables 0/8] Support for shifted port-ranges in NAT Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 1/8] nat: add support for shifted port-ranges Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 2/8] masq: " Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 3/8] redir: " Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 4/8] json: formatting fixes Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 5/8] json: add support for shifted nat port-ranges Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 6/8] doc: correct NAT statement description Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 7/8] doc: add shifted port-ranges to nat statements Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 8/8] test: py: add tests for shifted nat port-ranges Jeremy Sowden
2023-03-24 22:59 ` Florian Westphal
2023-03-25 10:35 ` Phil Sutter
2023-03-25 11:10 ` Jeremy Sowden
2023-03-26 20:41 ` Pablo Neira Ayuso
2023-03-26 20:39 ` Pablo Neira Ayuso
2023-03-27 11:08 ` Jeremy Sowden
2023-04-11 12:21 ` Jeremy Sowden
2023-04-12 11:06 ` Pablo Neira Ayuso
2023-04-25 19:51 ` Jeremy Sowden
2023-05-03 20:54 ` Pablo Neira Ayuso
2023-05-08 17:58 ` Jeremy Sowden
2023-05-08 19:47 ` Pablo Neira Ayuso
2023-04-11 8:28 ` Pablo Neira Ayuso
2023-04-11 10:25 ` Florian Westphal
2023-04-11 10:53 ` Pablo Neira Ayuso
2023-04-11 11:20 ` Florian Westphal
2023-04-11 11:43 ` Pablo Neira Ayuso
2023-04-11 12:28 ` Florian Westphal [this message]
2023-04-11 12:36 ` Florian Westphal
2023-04-12 11:22 ` Pablo Neira Ayuso
2023-04-12 11:43 ` Florian Westphal
2023-04-12 12:54 ` Pablo Neira Ayuso
2023-03-24 14:18 ` [PATCH nftables 0/8] Support for shifted port-ranges in NAT Florian Westphal
2023-03-24 16:07 ` Jeremy Sowden
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=20230411122801.GE21051@breakpoint.cc \
--to=fw@strlen.de \
--cc=jeremy@azazel.net \
--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 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).