From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 12:53:51 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 79F7516A4CF for ; Wed, 15 Dec 2004 12:53:51 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F1EE43D5A for ; Wed, 15 Dec 2004 12:53:50 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 35392 invoked from network); 15 Dec 2004 12:42:32 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Dec 2004 12:42:32 -0000 Message-ID: <41C033DE.B3DE1F26@freebsd.org> Date: Wed, 15 Dec 2004 13:53:50 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20041213124051.GB32719@cell.sick.ru> <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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: vova@fbsd.ru cc: Luigi Rizzo cc: freebsd-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: Wed, 15 Dec 2004 12:53:51 -0000 Gleb Smirnoff wrote: > > On Wed, Dec 15, 2004 at 11:50:55AM +0100, Andre Oppermann wrote: > A> First you change the way pfil_hooks is used in a multiprotocol incompatible > A> way. Lets have a look at ip_input(): > A> > A> pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN, NULL); > A> ^^^^^^^^^^^^^^ > A> > A> PFIL_HOOKS is a generic API with clear semantics. You can't just replace > A> this inet_pfil_hook with an interface specific one. That would be INET > A> only and you'd have to do the same for IPv6, IPX and whatever other protocols > A> may come. > A> > 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 Handling it inside firewalls is the correct design. > tables when an interface is destroyed? No. Would it be possible to know Yes, you can subscribe to the routing socket where such information of interface arrivals, departures and changes are announced. The same way routing daemons get their information. Maybe this can be extended to provide a generic call-back handler interface to avoid duplication of the parsing code for each firewall. > which chains/filters are used on interface via ifconfig? No. Would it be Which chains/filters are used on an interface is firewall package specific anyway. IPFW, PF and IPF have different semantics and syntax for this. With Sam's recent modularization changes to ifconfig it would be possible to have a module doing that via ifconfig for each of these. > possible to avoid entering firewall functions when processing interfaces > without ACLs? No. It would go into the pfil_hook chain and the firewall code would just issue a return (0). One function call. Please remember that there can be other things besides firewalls residing in a PFIL_HOOKS chain. You can implement IPSEC via a pfil hook module. These may want to run independently of your firewall passing all traffic. > So, we are changing design in strange direction, because we don't want > struct ifnet to grow? No, I'm *designing* kernel functionality compared to bolt-on hacking it. > In Juniper|Cisco world, the fact that ACLs are attached in configuration > of interfaces, but not firewalls, gives a strong suspection that they have > it in their analog of struct ifnet. So what? Are we Cisco or Juniper? Do you jump out of the window on 13th floor if your pop idol does? No, you think first. I'm not saying what Cisco|Juniper do is bad, but neither am I saying it's the one and only truth in networking. There may be better or more clever approaches. Much of what they do is based on legacy requirements especially on Cisco. We have to look at the high-level goal first, not the specific implementation of someone else. > A> Thirdly have the modules that are hooked into the pfil_hooks no idea that > A> they have to register multiple times with multiple chains and so on. This > A> means that all firewall packages in FreeBSD need to be adjusted to deal > A> with these changes, often in a non-trivial way, to continue to function. > > I'd like to avoid autohooking here. I'd prefer to have a userland utility > which allows sysadmin to hook chain X from packet filter Y to interface > fxp0 direction IN, protocol IPv4. This is firewall package specific anyway. > Now we have autohooking to preserve compatibility with pre-pfil firewalls. > > A> And we lose the compatibility with NetBSD where the PFIL_HOOKS API comes > A> from. > > Why? We just have more places where filters can be hooked. No. Modules using PFIL_HOOKS would have to be written especially for FreeBSD to deal with your new behaviour. You can't just take a module written for NetBSD and compile it on FreeBSD and vice versa. The goal of the common PFIL_HOOKS API was to make especially that possible. > A> I hope you understand now that you change the PFIL_HOOKS API not in the > A> binary or structure way but in use and semantics. > > Yes. Let's call it smth different to word API. No. > A> So please put the PFIL_HOOKS discussion to a rest now as it simply won't > A> happen. There are perfect alternatives to change IPFW to fit your needs > A> within IPFW itself and with the information supplied by the PFIL_HOOKS API. > > Ok, "simply won't happen", is the words I was awaiting for. Good. PFIL_HOOKS case closed now? -- Andre