Date: Thu, 16 Jun 2016 02:11:04 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Julian Elischer <julian@freebsd.org> Cc: lev@freebsd.org, "Andrey V. Elsukov" <ae@freebsd.org>, freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" <melifaro@freebsd.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? Message-ID: <20160616005016.A15883@sola.nimnet.asn.au> In-Reply-To: <3d09497c-136c-e217-154c-ba00e6879c6f@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ..) > 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? 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'? > 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)? 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? 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? 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160616005016.A15883>