From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 13:03:21 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CAB31C7; Wed, 4 Feb 2015 13:03:21 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id CA216E9; Wed, 4 Feb 2015 13:03:20 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 819725C002; Wed, 4 Feb 2015 16:03:09 +0300 (MSK) Message-ID: <54D2188D.5080800@FreeBSD.org> Date: Wed, 04 Feb 2015 16:03:09 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ian Smith , Julian Elischer Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny 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> In-Reply-To: <20150204231922.X38620@sola.nimnet.asn.au> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 13:03:21 -0000 -----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-----