From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 09:16:56 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 7171616A4CE; Tue, 14 Dec 2004 09:16:56 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DE9443D66; Tue, 14 Dec 2004 09:16:55 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id iBE9Grau063136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Dec 2004 12:16:54 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBE9GrIo044505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2004 12:16:53 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBE9Gq2D044504; Tue, 14 Dec 2004 12:16:53 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Tue, 14 Dec 2004 12:16:52 +0300 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20041214091652.GE42820@cell.sick.ru> References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> <20041213184700.GA37107@cell.sick.ru> <41BE0E89.AE21445@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41BE0E89.AE21445@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: mlaier@freebsd.org cc: net@freebsd.org 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: Tue, 14 Dec 2004 09:16:56 -0000 On Mon, Dec 13, 2004 at 10:50:01PM +0100, Andre Oppermann wrote: A> > (Now I speak only about ipfw. But other filters can be used in same A> > manner with a very small changes.) A> > A> > We have list of rules defined in struct ip_fw_chain. At this moment A> > we have only one instance of it - a global variable layer3_chain. A> > What I'm going to do: A> > 1) adding possibility to add new chains and editing them. A> > 2) adding possibility to run ipfw_chk() against a chain other than A> > layer3_chain. A> > 3) Edit ip_fw_check_{in,out}, so that it can call ipfw_chk() A> > on different chains. Supply chain identifier in void arg. Edit A> > ipfw_hook() so that it can register ipfw as a pfil, but with A> > chain different to layer3_chain. A> A> This is what I don't get. You can register only once with pfil. in ipfw_hook(): pfil_add_hook(ipfw_check_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet); pfil_add_hook(ipfw_check_out, NULL, PFIL_OUT | PFIL_WAITOK, pfh_inet); smth like: s/pfh_inet/ifp->pfil_head/ No API change. A> > 4) add possibility to register a pfil_head for an interface. Once the A> > pfil_head is registered, administrator can call ipfw_hook() on A> > it, and hook ipfw chain to this pfil_head, either in or out. A> > 5) In ip_input()/ip_output() check if interface has pfil_head A> > associated with it. If it does pfil_run_hooks on it. A> A> You are going to change the pfil API. This is not neccessary. pfil A> passes the ifp to the hook, this is sufficient. Yes. It is possible to do this on level of ipfw. But I'd prefer to do this on level of pfil. This will give possibility to run pf on one interface and ipfw on other. (tools, not policy). A> > Important points: A> > 1. No API breakage in PFIL, at least I don't see any problems now. A> A> But Max and me see problems. The API does not break but it is different. A> We don't want it to be different in such a way. AFAIU, the pfil API is designed to attach a list of generic filters to a any place you want. If you say that pfil is designed to perform filtering in ip_{in,out}put(), this sounds strange. A> > 2. No conflicts with current filtering. Interface filters can happily A> > coexist with global ones. A> A> You haven't talked about the presentation interface towards the user. A> This is where everything has to start. How would the ipfw syntax look A> like? Provide some examples please. ipfw syntax will be 100% backward compatible. The following keywords would be added: ipfw chain list - list configured chains ipfw chain add | delete - delete, remove chain ipfw chain _number_ [common rule definition] - add/delete rules to non-default chain It would be possible to attach chains to interfaces specifing also direction. It will be done with ifconfig, or a specific utility (not yet decided). A> The problem we have is that you have a specific solution in mind without A> adequatly stating the problem first. Because then we would sit down and A> work out what the best way is to implement it. So far Max and I do not A> agree with you on the your stated ideas to solve this. The fact that Juniper and Cisco (and I suspect other router vendors) use this technique, proves that it is handy for routers. I'm sure many sysadmins will agree at this point. Users, not developers. The fact that one have written some IP packet filter does not mean that he knows everything about its day to day usage. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE