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

Mon Jun 20 14:00:02 UTC 2016

On 16/06/2016 12:11 AM, Ian Smith wrote:
> On Mon, 13 Jun 2016 23:18:24 +0800, Julian Elischer wrote:
>   > 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.
>
> Lev, is there any chance you and Andrey can work together here?  At the
> moment we seem to have two 'competing' models.  Can they be melded at
> all?  Or can you live with adding new opcodes on top of Andrey's named
> states?  (Feel free to tell me that this is none of my business ..)
yes, please..
>   > 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..
>
> Isn't one table with distinct flow-or-whatever names for matching not
> sufficient for this purpose?  Wouldn't that also be faster than having
> to consult multiple distinct tables?
if you name table entries then you effectively have different tables, 
but yes I was mistaken in how it was being done.
I had assumed a separate table
>
> In the end those are details the user doesn't need to know about .. but
> ze does need to comprehend the terms conveying the ideas.
>
>   > 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.
>
> Sure, so couldn't you have, say, 'inbound_outside', 'inbound_inside',
> 'outbound_outside' and 'outbound_inside', 'from_dmz' or whatever to
> distinguish multiple flows?
>
> Why doesn't 'flowname' sound right to describe what you call 'flows'?
multiple flows can end up in the same table/name
a flow to me is some set of packets that relate to each other in source,
destination and sequence.  you could almost say that each pair of 
sockets defines a flow.
Others probably have different definitions.. One could even say that 
in the context of
ipfw, any set of packets that can be discriminated by a set of rules 
can be a flow.
>
>   > 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.
>
> Isn't that the case with Andrey's code at the moment, if you specify a
> name on that keep-state rule, only that - erm - flow would be checked
> and not other flows (including 'default' where added by unnamed rules)?
no. but it is the case with Lev's patch (and Andrey's matching effort)
>
> Can I assume that if this is the first keep-state|limit for one flowname
> then an implicit check-state would check that flow only, finding none?
I don't know.  currently the selector part of the rule doesn't 
distinguish who does a check-state.
I'm guessing he finds the label and uses it but I don't know.

>
> Similarly, if I'm grokking this at all right, then only a check-state
> (or another keep-state or limit encountered) with that same name will
> match existing states having that same name?  Issue 2/ solved or not?

Issue 2 is mostly solved for many cases.
>
> I hope you can see my concern that this be easily described in ipfw(8)
> so people without high level of expertise can easily see how it works.
>
> I'll have some more suggestions re description along the way, but after
> seeing clear agreement that the proposed model/s cover the usage cases
> described (somewhat), and where not, what more needs doing to make it
> acceptable as a next step, if not entirely ideal for every case ..
>
> To that end, I'll leave wishes 3/ and 4/ well alone .. as usual, FWIW
>
> cheers, Ian
>
>   > 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.
> _______________________________________________
> freebsd-ipfw at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
>