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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64d6bdea-fa32-f16f-2fdd-abd33d54d04e>