Re: [PATCH nftables 8/8] test: py: add tests for shifted nat port-ranges

[Florian Westphal <fw@strlen.de>]

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 :-) )