Date: Sat, 19 Feb 2000 14:22:15 +0100 (CET) From: Luigi Rizzo <luigi@info.iet.unipi.it> To: Darren Reed <avalon@coombs.anu.edu.au> Cc: hackers@FreeBSD.ORG Subject: Re: post 4.0...adoption of pfil(9) from NetBSD ? Message-ID: <200002191322.OAA84928@info.iet.unipi.it> In-Reply-To: <200002191201.XAA01927@cairo.anu.edu.au> from Darren Reed at "Feb 19, 2000 11:01:26 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > The issue of one vs. multiple lists (per direction, interface, > > protocol, you name it) has been discussed some time ago. For sure > > multiple lists are a (minor, given that we can start the ipfw lists > > with a few of "skipto") performance improvement over a single one, > > at the possible price of having some duplication in writing filters > > and even defining how many lists are appropriate. > > To me, this outlines how bad the current system for ipfw support > has become. Need something ? Just hack the appropriate part of > the kernel. There's no real design in the infrastructure for hmmm... this criticism, which i partly share, seems unrelated to the single vs. multiple list issue. I agree with you that having a protocol-independent interface for the firewall would be nicer, but then you should also remember that things like divert, forward, tee and possibly also NAT can only be defined as hacks, and as such i am not very optimistic that one can find common mechanisms for calling the filter unless one tolerates some duplication of work. Example: when the filter forwards a packet to somewhere else, you might have to change the route info associated with the packet. When the filter duplicates or steals a packet, the things to do depend a lot on what the rest of the standard function does. E.g ip_input.c, the handling of diverted packets is scattered all around. I don;t know how easy would it be to pack all of this in one place, before or after the proto_input routine. And honestly, once the initial hooks are in the proto_input routine, it is unlikely that you have to touch them anymore. We don't add a protocol stack everyday, i think we have 3 functional ones at the moment. My second comment is on the usefulness of a unified filter. ipfw is clearly IPv4 centric, ip6fw is IP6 centric, and maybe there is no ipxfilter. Why ? because the authors of the 2/3 different filters know enough about their protocol but not enough about the others. Now we can work on each one separately, and at a much higher rate than we could achieve by having a single monolitic filter which people would be scared to touch fearing to break support of some of the other protocols (or, more likely, people would end up adding features to just one of the protos leaving the other ones unchanged). So, in my opinion a merging effort would be a threat to improvement (and the same applies to having to maintain portable software... i guess you know the problem very well with ipfilter!) Of course there are some common functionalities such as (to speak of a couple with which i am very familiar) traffic shaping, or keeping state. But the common infrastructure (a scheduler in the former case) is very very easy to share, while i see much more difficulty in maintaining a single unified filter for all protocols. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002191322.OAA84928>