per-interface packet filters

[Andre Oppermann]

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