Date: Wed, 15 Dec 2004 14:57:09 +0300 From: Gleb Smirnoff <glebius@freebsd.org> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters Message-ID: <20041215115709.GK54307@cell.sick.ru> In-Reply-To: <41C0170F.95449D19@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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. So, we are changing design in strange direction, because we don't want struct ifnet to grow? 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. 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. 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. 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. 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. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041215115709.GK54307>