Date: Tue, 14 Dec 2004 16:20:31 +0300 From: Gleb Smirnoff <glebius@freebsd.org> To: Andre Oppermann <andre@freebsd.org> Cc: net@freebsd.org Subject: Re: per-interface packet filters Message-ID: <20041214132031.GB46386@cell.sick.ru> In-Reply-To: <41BEE50E.6AA4FA4@freebsd.org> References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> <20041213184700.GA37107@cell.sick.ru> <41BE0E89.AE21445@freebsd.org> <20041214091652.GE42820@cell.sick.ru> <41BEE50E.6AA4FA4@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 14, 2004 at 02:05:18PM +0100, Andre Oppermann wrote:
A> > A> > (Now I speak only about ipfw. But other filters can be used in same
A> > A> > manner with a very small changes.)
A> > A> >
A> > A> > We have list of rules defined in struct ip_fw_chain. At this moment
A> > A> > we have only one instance of it - a global variable layer3_chain.
A> > A> > What I'm going to do:
A> > A> > 1) adding possibility to add new chains and editing them.
A> > A> > 2) adding possibility to run ipfw_chk() against a chain other than
A> > A> > layer3_chain.
A> > A> > 3) Edit ip_fw_check_{in,out}, so that it can call ipfw_chk()
A> > A> > on different chains. Supply chain identifier in void arg. Edit
A> > A> > ipfw_hook() so that it can register ipfw as a pfil, but with
A> > A> > chain different to layer3_chain.
A> > A>
A> > A> This is what I don't get. You can register only once with pfil.
A> >
A> > in ipfw_hook():
A> >
A> > pfil_add_hook(ipfw_check_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet);
A> > pfil_add_hook(ipfw_check_out, NULL, PFIL_OUT | PFIL_WAITOK, pfh_inet);
A> >
A> > smth like: s/pfh_inet/ifp->pfil_head/
A>
A> Not neccessary. You get the ifp when pfil_run_hooks() is called and you
A> can do the per-interface multiplexing just as simple in your firewall
A> package.
I do not want to enter any filtering related functions on an interface where no
filtering is performed. I think this argument is heavy for such fan of perfect
design as you are.
A> > No API change.
A>
A> Sure it is. Not directly with PFIL_HOOKS itself but in the way it is
A> hooked into the kernel and it is called. You want to pass redundant
A> information.
Is it going to hurt you that ipfw_hook() can accept *optional* parameter
which can tell it to hook to non-default pfil_hook?
A> > A> > 4) add possibility to register a pfil_head for an interface. Once the
A> > A> > pfil_head is registered, administrator can call ipfw_hook() on
A> > A> > it, and hook ipfw chain to this pfil_head, either in or out.
A> > A> > 5) In ip_input()/ip_output() check if interface has pfil_head
A> > A> > associated with it. If it does pfil_run_hooks on it.
A> > A>
A> > A> You are going to change the pfil API. This is not neccessary. pfil
A> > A> passes the ifp to the hook, this is sufficient.
A> >
A> > Yes. It is possible to do this on level of ipfw. But I'd prefer to do
A> > this on level of pfil. This will give possibility to run pf on one
A> > interface and ipfw on other. (tools, not policy).
A>
A> But any firewall package needs to be modified to be able to deal with this.
Yes. If some developer likes idea of per-interface filters and prefers smth
other than ipfw, he can add support for his favorite filter.
A> Tools, not policy does not apply in this context because we are not going
A> to do an policy decision here.
We can give people possibility to attach ipfw chains to interfaces, we can
give possibility to attach any pfil-compatible filters. The second one is
less strict.
A> > A> > Important points:
A> > A> > 1. No API breakage in PFIL, at least I don't see any problems now.
A> > A>
A> > A> But Max and me see problems. The API does not break but it is different.
A> > A> We don't want it to be different in such a way.
A> >
A> > AFAIU, the pfil API is designed to attach a list of generic filters to
A> > a any place you want. If you say that pfil is designed to perform filtering in
A> > ip_{in,out}put(), this sounds strange.
A>
A> No. PFIL_HOOKS can hook into two directions (in and out) for each protocol
A> class (INET, INET6 and so on).
I'm trying to show that PFIL_HOOKS are designed not solely for filtering
on protocol level. They can be utilized in any code which deals with mbufs.
A> > A> > 2. No conflicts with current filtering. Interface filters can happily
A> > A> > coexist with global ones.
A> > A>
A> > A> You haven't talked about the presentation interface towards the user.
A> > A> This is where everything has to start. How would the ipfw syntax look
A> > A> like? Provide some examples please.
A> >
A> > ipfw syntax will be 100% backward compatible. The following keywords would
A> > be added:
A> >
A> > ipfw chain list - list configured chains
A> > ipfw chain add | delete - delete, remove chain
A> > ipfw chain _number_ [common rule definition] - add/delete rules to
A> > non-default chain
A> >
A> > It would be possible to attach chains to interfaces specifing also
A> > direction. It will be done with ifconfig, or a specific utility (not yet
A> > decided).
A>
A> Why don't you specify the interface directly in the syntax? That would be
A> more in line with ease of use instead of having yet another logical
A> indirection?
A>
A> ipfw fxp0 add permit ip from any to any
Because one chain may be used for several interfaces. One can be used for
ng_pfil node. One can be not used at all, but it is hanging there, so that it can
replace the one used by interface (this is what bms requested for XORP).
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041214132031.GB46386>