Date: Mon, 20 Jun 2016 21:59:48 +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: <d7bef617-70a4-f761-7d09-9413eb720b11@freebsd.org> In-Reply-To: <20160616005016.A15883@sola.nimnet.asn.au> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d7bef617-70a4-f761-7d09-9413eb720b11>