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

[Ian Smith]

On Mon, 13 Jun 2016 22:59:19 +0800, Julian Elischer wrote:
 > On 7/06/2016 10:31 PM, Ian Smith wrote:
 > > On Tue, 7 Jun 2016 00:53:23 +0300, Andrey V. Elsukov wrote:
 > >   > On 06.06.16 22:41, Lev Serebryakov wrote:
 > >   > >
 > >   > >  I still hope to see https://reviews.freebsd.org/D1776 committed
 > > before
 > >   > > 11-RELEASE.
 > >   > >
 > >   > >  It seems to me, that I does everything what was requested by
 > > reviewers.
 > >   >
 > >   > Hi Lev,
 > >   >
 > >   > 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.
 > >   >
 > >   > 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."
 > >   >
 > >   > 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. Due to limits of implementation this
 > >   > looks impossible to solve. But proposed patch with deferred action
 > > looks
 > >   > too hackish to me.
 > >   >
 > >   > 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
 > > 
 > > If your patch does what Lev wanted to achieve with (I thought too many)
 > > new dynamic rule actions, then I think your simpler solution is better,
 > > not least because it's far easier to understand for non-Julians :)
 > 
 > actually I want only  subset..
 > what I want is a "set-state"  that is the same as keep-state, but does not
 > have
 > the implicit check-state before it. (if it has a collision with an existing
 > rule it overrides it)
 > I also want he named state tables.   :-)

Ok, but you're regularly referring to multiple state _tables_, but I 
think that what is proposed is one table with name added to protocol, 
addresses and ports as a parameter rather than as distinct tables?

Is that right, Andrey?  As I said, I'm not looking at the code now.

 > > Looking from a useability and documentation perspective only - I won't
 > > even be looking at this code - I have a few thoughts:
 > > 
 > > Thus far, keep-state and limit seem to be interchangeable options; limit
 > > rules will need to work the same with respect to named dynamic flows; do
 > > I assume that you've just started with only keep-state for testing?
 > > 
 > > I think flow names should be specified as an _optional_ parameter, thus:
 > > 
 > >      check-state [name]
 > > 
 > >      keep-state [name]
 > > 
 > >      limit {src-addr | src-port | dst-addr | dst-port} N [name]
 > > 
 > > where name (maybe flowname, for easier comprehension by man readers?) is
 > > optional, assigned as 'default' whenever omitted - as well as being for
 > > backwards ruleset compatibility, which then only needs mentioning once,
 > > and maybe also put another way in the STATEFUL FIREWALL section.

 > I think flowname  is a bad name..  it's a state table name.

I don't think so.  That was just a suggestion in place of generic 'name' 
but the more I read your following message, which I'll respond to next, 
the more I think you've made a good case for 'flowname', which Andrey 
has used in latest review in ipfw(8).  Onwards ..

cheers, Ian