IPFW: more "orthogonal? state operations, push into 11?
Julian Elischer
julian at freebsd.org
Tue Aug 2 06:47:38 UTC 2016
Do we have any movement on these improvements?
even similar functionality by different names is ok.
1/ ability to use keep-state without an implicit check-state. <---
most important for me. (store-state)?
2/ ability to keep-state without actually doing it <---- less
important for me.
3/ multiple state tables? this was discussed and I thought I saw
patches but I haven't seen it going in, <-- super luxurious
On 20/06/2016 9:59 PM, Julian Elischer wrote:
> 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"
>>
>
> _______________________________________________
> 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"
>
More information about the freebsd-ipfw
mailing list