IPFW: more "orthogonal? state operations, push into 11?

[Julian Elischer]

On 10/06/2016 5:11 AM, Lev Serebryakov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 07.06.2016 00:53, Andrey V. Elsukov wrote:
>
>> looking at provided description and examples, seems the main task
>> you want to solve is problem with NAT. But from my point of view,
>> you are trying to solve it in a easy way wrongly using existing
>> methods.
>    It is was initial driver for this patch, yes, but, please, read
> subject (? is mistype, of course, it is closing ").
>
>    Current set of primitives, dealing with state, is terribly wrong,
> IMHO. "keep-state" which trigger (any!) state check alone is awuful,
> and complete "keep-state / check-state" pair is ugly hack. It is like
> CISC vs RISC, actually.
>
>    New primitives are ORTHOGONAL. Each one solves one and only one
> well-defined task, state creation, state checking and command
> execution are well-separated. IMHO, "keep-state" in it current form
> should be killed with fire. Yes, I understand about backward
> compatibility and POLA, so I don't propose to really remove it, but,
> IMHO, new set is much, much better.
In writing complicated automatically generated firewalls,
I've wanted the following capacities:
1/ one state table for one part of the flow and another  for a 
different part...  e.g. a different table for "inside" nat to 
"outside" nat..
also a different table for the inside interface to the outside 
interface..  just because you allow a flow at one interface doesn't 
mean you want it to be allowed through a different one.
2/ The ability to  specifically add a flow's state rule to a table, 
without EVERY OTHER FLOW hitting a 'check-state' at that point.  If I 
select s particular flow , then I do not want other flows affected. 
just that flow should be affected.
3/ the ability to select a completley different firewall for a 
differnent interface.. this can be simulated at the moment. but it'd 
be nice to be able to specify a entry pont into the table or a 
separate table per interface..   ipfw interface xn0 in enter 5000 or 
something.
or maybe ipfw interface firewall 3
4/ the ability to have variables and set and test them. We ALMOST have 
that with tags .
  i] variables would hav eone of several scopes:
   a) a single transit..  you might set some flag at rule 40 and 
branch on it at rule 4000, but a separate packet would ahv ea 
different instance.
   b) per flow..  assigned at creation of the dynamic  rule and 
avaliable at any time after a packet has been associated with that flow.
   c) global
  ii] branching on values is possible.
there are others I've wanted (and forgotten) but that's the wish-list 
I have at the moment.





>> As you described in patch to ipfw(8) "Problem is, you need to
>> create dynamic rule before NAT and check it after NAT actions (or
>> vice versa) to have consistent addresses and ports."
>    It is only very rudimentary example to show the point of new
> primitives. All meaningful examples require big and complex rulesets,
> really.
>
>> In terms of ipfw(4) a state is represented by ipfw_flow_id
>> structure. To solve your task you just needs two states - one for
>> not translated flow and second - for translated.
>    For what?! Logically it is one flow. NAT is kludge itself, of
> course, but, IMHO, logically it doesn't create new flow, or
> connection, whatever your name it. It hacks existing one.
>
>> Due to limits of implementation this looks impossible to solve. But
>> proposed patch with deferred action looks too hackish to me.
>    IMHO, it untangles current very sad situation.
>
>> With the following patch you will be able create two different
>> states, I think, and solve your task with NAT and dynamic rules:
>> https://reviews.freebsd.org/D6674
>   Named states are great and very useful by themselves, but how this
> solve problem, that "keep-state" implies "check-state" rule, for example
> ?
>
>   I seen a thousand posts, messages and how-tos about stateful IPFW and
> all of them suffer from this "keep-state is check-state" problem,
> really, when you try to structure your firewall in "ingress / egress"
> per-interface sections and not one small ruleset for one interface.
>
> - -- 
> // Lev Serebryakov AKA Black Lion
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQJ8BAEBCgBmBQJXWdt4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
> QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePQ+kP/jTUZQ/W2srUhiRCkTzDsGpy
> dbODp6utMjQGwtZKgPRVN4+0KuchgJInA6odB/34WKfgW5THpevLkh5do8QGvm+5
> /8DcYZOYwCk45TRkjhctBH6u2t0v3TPvjd1pPkknmhd3qE9Zzkk2fi+0iUWBavMH
> LvLJ+afUlmw8l95Om8g4Per3C7TEWmxXews3k+vg1xgrTtPn6m1Vcwspp7gHe2Zo
> OIGTzDl0S95SUofQuQX3vD7gPqm6YTnRVhtHrb36saVpP2HCv6e+7vOkyfiTV4nd
> Mchu3T6e9zJ2cmWBRIE9d/wB18LRVjWE+pvosTf6EEIkRJnUUnCZF19EJj8BS+9X
> 7+zbPnVeUSo17YdxSTcDXL0cBuzRIsz50V2Q6bFgl313PB9u97a4FeLdNmqEZfnN
> jEgeonc8loN6Fw/Mgjdn2wjmAhZaWU+zCpozzDPcjevkl9NIVVkMys4iZUUCdRkG
> yGQtU18X3hHwrbM4uJs7K9JLJj1HHEgpT9mnZ3qxCQ1YKEWZ0plgPvXoFWOiYYIB
> Ecz19D/kLBad3gVZ0X9NZwqA2XM23UmfMiKqd0ZcoOPiMY1WY35PQWOocOhiCIW4
> mhcEwp9ZR2mV7OZEO1ObLiK1Jo/q0xNn2eV9UgSrYJGSjOSLPj+9rC2zOjBbO1EO
> o1H+cNxLn5zMM4sybo9X
> =WZgr
> -----END PGP SIGNATURE-----
>