Date: Wed, 04 Feb 2015 16:03:09 +0300 From: Lev Serebryakov <lev@FreeBSD.org> To: Ian Smith <smithi@nimnet.asn.au>, Julian Elischer <julian@freebsd.org> Cc: freebsd-ipfw@freebsd.org Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny Message-ID: <54D2188D.5080800@FreeBSD.org> In-Reply-To: <20150204231922.X38620@sola.nimnet.asn.au> References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> <54D1AA60.4030907@freebsd.org> <54D1E4D4.10106@FreeBSD.org> <54D1FE72.1020508@freebsd.org> <20150204231922.X38620@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 04.02.2015 15:34, Ian Smith wrote:
> I don't get this .. we're always working on just one packet at any
> time, either inbound or outbound (to kernel), so how can
> check_state (or the check also on keep-state) apply to any other
> packets than that one?
Simply enough: assume packet goes from internal network ("in recv
em0", say) to external one, ("out xmit em1"). It passes firewall
twice, really. In ip_input() (it is matched by "in") and ip_output()
(it is matched by "out").
Say, we have "keep-state" for this packet when it is "in" as last
action, something like "allow keep-state" to have this state to check
answer packet "in recv em1" (note, "em1" here) appropriately.
And in "out" section we could have OTHER "keep-state" rule, for
locally originated packets (which never pass through as "in" ones). Of
course, this, second, "keep-state" is equipped with additional
conditions like "src-ip me".
Now, our transit packet creates state in "in" section and is passed
to "out" section. And it triggers this state on "src-ip me keep-state"
rule! It doesn't belong to this rule! But doesn't pass conditions of
this rule! It SHOULD NOT BE AFFECTED by this rule, match failed, try
next one! But -BANG-! "keep-state" has implicit UNCONDITIONAL
"check-state"! So, we need additional stupid skipto like this:
XXX skipto ZZZ not src-ip me
YYY allow src-ip me keep-state
ZZZ nat 1 // out
To me, it is stupid, contra-intuitive, non-orthogonal and bad design.
I think, there is THREE DIFFERENT things:
(1) Creation/updating of state, with normal condition checks on packet.
(2) Checking packet against state table, updating state, performing
action (if appropriate state is found, of course).
(3) Performing action WHEN state is created (not checked!)
Now ipfw has very tangled way to do this. We have:
(A) (2) + (1) + (3) (in this order, please, note that condition
checks are done in (1), not BEFORE this chain). It is keep-state.
(B) (2). It is check-state
(c) (3). It is stateless rule.
That's all! You could not do (1) without (2). You could not do
conditional (1). You could not do (1) but not (3). Nothing!
And if "conditional (2)" may be too much, but only possible to go to
(1) is via (2) and inevitable (3) after that is too much, IMHO! It is
very obscure behavior!
To be honest, I want add not only "keep-state-only" (pure (1)), but,
also have "keep-state-do-action-no-check" to have (1) + (3) without (2).
- --
// Lev Serebryakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQJ8BAEBCgBmBQJU0hiMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePd60P/iTr55i4uyLfa7cf/TH9ypdt
S9iP23qGZDPo+YzjVfmcyBNWbYJ2eNfkve9DhYHoizpacqHeepnWfMxNPdSf0kLI
lZ0qYt/EtwTDCOoSx+wE/c1ywzvHUKO7k631GS/EpRbUwli5yEZnJEFwJPlEJ8WY
A3uBtPxBAn3CEiS7ps91Da260Qt3xgw4Sv99YOzY7k2etUOsj8r2EEkLG8gsH96V
Pk4udb17Kc0WygwNN7OaI1mxXaoKkd6NzZM4W0WvWy5fKgD/Rhep5hD4/oFixfsJ
HKxjYjUDrzc6/elL5GW1+OwzQ08+KziriRqBT2QMOJnso9a1yQc/5jvO1C4zol9Y
wF3ZgcMIAJKBmOdkWHPMfrhNYMutI8gPsKH063BRkHFTtTQb7yL8bysLYE1P23lM
hzl3ubZtcas7Z5kBpsAL2L0xXLReMCCTSULv0oQDitb6H4z3eUeN5iq2Sk6b0uwB
J6mZiHCYU48KU0ST4/UAnZFYX4mUFTiIfP2KzekdZ+BUNdGgdVr177EJChZxBL4M
x/In6x944pwRxCExFa10OSMzQqdOJ+IQEfS1LfG+l/A4X7Rjx87Gbb4A/3ePkkdA
HoZLACmRfFGxmWILZa8EtldUvDsOjXs+Q08rpvp2So0szcM0N5XIixDbnLEvCqFu
xn6GOWuyaJVzZlpllCV0
=ALXi
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54D2188D.5080800>