From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:03:28 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 E912C16A4CE for ; Tue, 14 Dec 2004 14:03:28 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27DA443D46 for ; Tue, 14 Dec 2004 14:03:28 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26864 invoked from network); 14 Dec 2004 13:52:19 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 13:52:19 -0000 Message-ID: <41BEF2AF.470F9079@freebsd.org> Date: Tue, 14 Dec 2004 15:03:27 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: 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:03:29 -0000 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. -- Andre