From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 20:57:18 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 0BE8F16A4CE for ; Tue, 14 Dec 2004 20:57:18 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2236643D48 for ; Tue, 14 Dec 2004 20:57:16 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so358905wri for ; Tue, 14 Dec 2004 12:57:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=goBDSnN578IQ0yYfyVpXdR6ULk+eKMUKF+I/M7vGkxOdUdZ8IgJGhFXtQfcHbSIpUt2EoGJ3h0sE2Yk/uhGITCgBpWH6mKgdApT5O3lU1Xp6oFy0tnEQ2ClmwjluTgajaqR7KJrxBMy8Qe8Q9TOFlcpnti+lXdO3CvlDYcxoRo0= Received: by 10.54.10.76 with SMTP id 76mr134441wrj; Tue, 14 Dec 2004 12:56:26 -0800 (PST) Received: by 10.54.23.33 with HTTP; Tue, 14 Dec 2004 12:56:26 -0800 (PST) Message-ID: <7c8f2792041214125637459c71@mail.gmail.com> Date: Tue, 14 Dec 2004 15:56:26 -0500 From: Josh Kayse To: freebsd-net@freebsd.org In-Reply-To: <7c8f279204121411275ad919f9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41BEF2AF.470F9079@freebsd.org> <7c8f279204121411275ad919f9@mail.gmail.com> Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: gtg062h@mail.gatech.edu 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 20:57:18 -0000 On Tue, 14 Dec 2004 14:27:01 -0500, Josh Kayse wrote: > As someone who is quite new to all of this, take my thoughts with a > grain of salt. That being said, this is my view on the matter. > > On Tue, 14 Dec 2004 15:03:27 +0100, 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: > > > 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. > > I don't think so because as has been said, the PFIL_HOOKS API provides > all the needed information. > > > 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 > > _______________________________________________ > > I'm spreaking of d3. > I think so as it would be the best change, in my oblivious opinion. I > would see it as the firewall package receives the mbuf, checks the > interface, if it is processing rules on the interface, or if there is > a global set of rules, to then continue processing the packet. If it > isn't, it should just return/get out, whatever. I do believe this > would require a change in rule processing. The firewall package would > keep track of the different 'chains' for the rulesets. > > As far as writing rules go, I think that it would be simple to make a > script that takes a set of firewall configuration rulesets and merges > them so that they do not collide. I think it take more work to get it > to make it pretty, but I don't see it being impossible. > > I'm sure that I'm not understanding exactly what the problem is, so > please, let me know what I'm missing, thanks. > > -- > Joshua Kayse > Computer Engineering > -- Joshua Kayse Computer Engineering