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-unsubscr...@freebsd.org"
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
