From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:48:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBCA416A4CE for ; Tue, 14 Dec 2004 14:48:33 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDD6743D41 for ; Tue, 14 Dec 2004 14:48:32 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id iBEEjV8d097443 for freebsd-net@freebsd.org.checked; Tue, 14 Dec 2004 17:45:31 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from [144.206.181.94] (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id iBEEi4qk097407; Tue, 14 Dec 2004 17:44:04 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <41BEFD67.2060501@cronyx.ru> Date: Tue, 14 Dec 2004 17:49:11 +0300 From: Roman Kurakin User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <41BEF2AF.470F9079@freebsd.org> In-Reply-To: <41BEF2AF.470F9079@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 14:48:33 -0000 Hi, Could we also add ability to keep state between reseting of the rules? For, example, if I use keepstates, after flushing and setting new rules that could be different by two lines from an old one I kick my self from that server with out any serious reason, I didn't change anything for ssh. IMHO this could be done by keepstate for a while after flushing, but I didn't ever look inside this code. rik Andre Oppermann wrote: >Let's take a high level view of the issue at hand and the consider >some alternative approaches to the situation. > >Current situation: > > a1. There is a need to have per-interface specific firewall rules. > a2. We have multiple firewall packages which have multiple way to > specify interface specific rules. > a3. With large numbers of interface specific rules the rulesets get > complex and hard to manage. > a4. This seems to be mainly a problem with ipfw and it's skipto > actions. > >Request: > > b1. Users request a less complicated way of doing interface specific > firewall rules. > >Analysis: > > c1. This is primarily a USER interface/syntax/semantics issue. > c2. The different user interface approaches of the different firewall > packages we have require different changes to their USER interfaces > to make it easier for per-interface rule sets. > c3. The firewall packages we have can only deal with one global rule > set per protocol family and direction currently. They can't be > loaded multiple times and can't have multiple rule set heads (only > one entry point). > >Implementation approaches: > > d1. The PFIL_HOOKS API has one hook per direction per protocol and > passes the interface information to the firewall package. > d2. Should the PFIL_HOOKS API be changed and be per interface instead > of per protocol? All firewall packages need to be modified and > we are no longer compatible with the PFIL_HOOKS API. > d3. Should the interface specific rules sets be per firewall package > in the way that best suits the package? No kernel API is changed. > d4. What is the user interface syntax and semantics for each firewall > package that someone wants to be modified? Provide examples for > those you are interested in. > d5. Should it be a replica of Cisco|Juniper approaches or can we do > better in syntax or semantics? Think outside of the box. > >Lets continue the discussion from here. > > >