From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 12:15:21 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 0C1EB16A4CE; Wed, 15 Dec 2004 12:15:21 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF73243D2F; Wed, 15 Dec 2004 12:15:20 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id iBFCFBB8085599; Wed, 15 Dec 2004 04:15:11 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id iBFCFBtf085598; Wed, 15 Dec 2004 04:15:11 -0800 (PST) (envelope-from rizzo) Date: Wed, 15 Dec 2004 04:15:10 -0800 From: Luigi Rizzo To: Gleb Smirnoff , Andre Oppermann , vova@fbsd.ru, freebsd-net@freebsd.org Message-ID: <20041215041510.A85138@xorpc.icir.org> References: <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <1103017203.1060.25.camel@localhost> <41BEE281.607DD0A8@freebsd.org> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> <20041215081810.GA53509@cell.sick.ru> <41C0170F.95449D19@freebsd.org> <20041215115709.GK54307@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20041215115709.GK54307@cell.sick.ru>; from glebius@freebsd.org on Wed, Dec 15, 2004 at 02:57:09PM +0300 Subject: Re: per-interface packet filters 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: Wed, 15 Dec 2004 12:15:21 -0000 On Wed, Dec 15, 2004 at 02:57:09PM +0300, Gleb Smirnoff wrote: > On Wed, Dec 15, 2004 at 11:50:55AM +0100, Andre Oppermann wrote: ... > A> Secondly the stuct ifnet would have to be extended with a pfil_head pointer > A> for every protocol family in the system. This would be non-dynamic and > A> would require a recompile of all drivers etc. when a protocol is added or > A> removed. Struct ifnet is not a dynamic structure. > > Yes, it needs to be extended. An alternative is handling a table of > interfaces vs chains inside firewalls. We are speaking a lot of design, > which of above designs is better? Is it going to be easy to edit all these > tables when an interface is destroyed? No. Would it be possible to know > which chains/filters are used on interface via ifconfig? No. Would it be > possible to avoid entering firewall functions when processing interfaces > without ACLs? No. gleb, andre is perfectly right here. struct ifnet should have as little protocol/module specific information as possible. The correct way to design things here is that each module (ipfw, netgraph, routing, ...) which is interested to interface-specific events (such as them being created, deleted, modified, printing the module-specific info related to the interface, etc.) should register a callback with ifconfig and be notified of the event, but store the module-specific information internally. Only in this way you can have loadable modules etc without making a mess. If you are worried about replicating the code that does the lookup from the interface-id to the module-specific info, this is a valid concern but could be worked around by providing a system-wide subsystem by which a module (e.g. a firewall) asks the system "please attach to the interface a chunk of 544 bytes with ID=0xff3022a0" and then can reply to requests such as "give me the pointer to the chunk with ID=0xff3022a0 for interface fxp12" This logically implements an extension of ifnet, but without all the disadvantages of adding fields for each new protocol/module/feature. I am not sure if the event signalling from ifconfig to the interested parties is already there, but that is trivial anyways to set up. Same for the module-specific if-related lookup. cheers luigi