Re: per-interface packet filters [summary]
From: Andre Oppermann (andre_at_freebsd.org)
Date: 12/14/04
- Previous message: Gleb Smirnoff: "Re: per-interface packet filters [summary]"
- In reply to: Gleb Smirnoff: "Re: per-interface packet filters [summary]"
- Next in thread: Kelly Yancey: "Re: per-interface packet filters [summary]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 14 Dec 2004 14:16:53 +0100 To: Gleb Smirnoff <glebius@freebsd.org>
Gleb Smirnoff wrote:
>
> On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote:
> A> > Implementationwise, the kernel side is evidently trivial as the
> A> > original code already supports the idea of multiple chains. All
> A> > you need is to extend the struct ifnet with a pointer to the chain,
> A> > or use some other trick (e.g. going through ifindex) to quickly
> A> > associate a chain to the input (and possibly output) interface.
> A>
> A> Nonononononononononononononononononononononono.
> A>
> A> There MUST NOT be any firewall specific pointers or other information
> A> in struct ifnet or any other non-firewall private part of the kernel.
> A> Otherwise the entire independence we've gained with the nice and clean
> A> PFIL_HOOKS API goes down the drain. This MUST NOT happen again.
> A>
> A> The whole idea of the PFIL_HOOKS is to have independend and loadable
> A> firewall modules with different approaches, internal designs and so
> A> on.
>
> The whole idea of PFIL_HOOKS is to have independend and loadable firewall
> modules, which can be attached to different parts of kernel! There is no
> such requirement that, pfil hooks MUST be sticked to a single entry point
> in ip_input() and ip_output().
PFIL_HOOKS is meant to be once on input and output per protocol and not
per interface. That is the reason why there is the interface pointer in
the argument list.
> Pfils attached to interface belong to interface, and thus should be stored
> in struct ifnet. This is the way it is done in per-interface filters.
Again, you are changing the way PFIL_HOOKS are called.
> A> For example a way Gleb can get his way without any bickering from us
> A> is by creating his own gleb-firewall module using the PFIL_HOOKS API
> A> and put it into the ports tree for easy access, provided he doesn't
> A> modify the PFIL_HOOKS API (which he doesn't have to).
>
> I am not going to create a new firewall or change PFIL_HOOKS. I'm going
> to attach *the existing* pfil_hooks to a different place, to perform
> filtering with *existing* firewalls.
The existing firewalls need to be modified anyway to be able to deal with
per-interface hooks. They are not made for it. This makes your argument
moot.
But please hold on, I'm writing an email with a different proposed approach.
Let's continue the discussion when all have read it. Give me a few minutes.
-- Andre _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
- Previous message: Gleb Smirnoff: "Re: per-interface packet filters [summary]"
- In reply to: Gleb Smirnoff: "Re: per-interface packet filters [summary]"
- Next in thread: Kelly Yancey: "Re: per-interface packet filters [summary]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
