Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Aug 2016 14:47:24 +0800
From:      Julian Elischer <julian@freebsd.org>
To:        Ian Smith <smithi@nimnet.asn.au>
Cc:        "Andrey V. Elsukov" <ae@freebsd.org>, lev@freebsd.org, "Alexander V. Chernikov" <melifaro@freebsd.org>, freebsd-ipfw@freebsd.org
Subject:   Re: IPFW: more "orthogonal? state operations, push into 11?
Message-ID:  <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org>
In-Reply-To: <d7bef617-70a4-f761-7d09-9413eb720b11@freebsd.org>
References:  <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <d7bef617-70a4-f761-7d09-9413eb720b11@freebsd.org>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>> To unsubscribe, send any mail to 
>> "freebsd-ipfw-unsubscribe@freebsd.org"
>>
>
> _______________________________________________
> freebsd-ipfw@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"
>




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?64d6bdea-fa32-f16f-2fdd-abd33d54d04e>