ipfw named objejcts, table values and syntax change

[Luigi Rizzo]

On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov <
melifaro at freebsd.org> wrote:

> Hello all.
>
> I'm currently working on to enhance ipfw in some areas.
> The most notable (and user-visible) change is named table support.
> The other one is support for different lookup algorithms for different
> key types.
>
> For example, new ipfw permits writing this:
>
> ipfw table tb1 create type cidr
> ipfw add allow ip from table(tl1) to any
> ipfw add allow ip from any lookup dst-ip tb1
>
> ipfw table if1 create type iface
> ipfw add skipto tablearg ip from any to any via table(if1)
>
> or even this:
> ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port
> ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444
> ipfw add allow ip from any to any flow table(fl1)
>
> all these changes fully preserve backward compatibility.
> (actually tables needs now to be created before use and their type needs
> to match with opcode used, but new ipfw(8) performs auto-creation
> for cidr tables).
>
> There is another thing I'm going to change and I'm not sure I can keep
> the same compatibility level.
>
> Table values, from one point of view, can be classified to the following
> types:
>
> - skipto argument
> - fwd argument (*)
> - link to another object (nat, pipe, queue)
> - plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit)
>
> There are the following reasons why I think it is necessary to implement
> explicit table values typing (like tables):
> - Implementing fwd tablearg for IPv6 hosts requires indirection table
> - Converting nat/pipe instance ids to names renders values unusable
> - retiring old hack with storing saved pointer of found object/rule
> inside rule w/o proper locking
> - making faster skipto
>

​​i don't buy the idea that you need typed arguments
for all the cases above. Maybe the case that
may make sense is the fwd argument (and in the future
something else).
We already discussed, i think, the fact that now it
is legal to have references to non existing things
(skipto, pipes etc.) implemented as u32.
Removing that would break configurations.

Efficiency is not affected, even for skipto,
and while i agree that unprotected writes to the pointers
in rules should not happen, these pointers are changed
infrequently so a global read-mostly lock should be
sufficient to protect all changes to the rules.

cheers
luigi


> So, as the result, table will have lookup key type (already done),
> value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some
> additional restrictions (like inability to add non-existing nat instance
> id).
>
> This change will break (at least) scenarios where people are
> using one table for both nat/pipe instances (and keep nat ids in sync
> with pipe ones). For example:
>
> ipfw table 1 add 10.0.10.0/24 110
> ipfw table 1 add 10.0.20.0/24 120
>
> ipfw add 100 nat tablearg from table(1) to any via vlanX in
> ..
> ipfw add 500 pipe tablearg from table(1) to any via ix0 out
>
> It looks like it is not so easy to bind values for given table to
> different objects (or different tasks) (and lack of compatibility kills
> hope for MFC).
>
> Ideas?
>
>
>
>
>
>
> _______________________________________________
> freebsd-ipfw at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
>



-- 
-----------------------------------------+-------------------------------
 Prof. Luigi RIZZO, rizzo at iet.unipi.it  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/        . Universita` di Pisa
 TEL      +39-050-2211611               . via Diotisalvi 2
 Mobile   +39-338-6809875               . 56122 PISA (Italy)
-----------------------------------------+-------------------------------