Date: Sun, 20 Feb 2000 00:52:01 +1100 (Australia/NSW) From: Darren Reed <avalon@coombs.anu.edu.au> To: luigi@info.iet.unipi.it (Luigi Rizzo) Cc: hackers@FreeBSD.ORG Subject: Re: post 4.0...adoption of pfil(9) from NetBSD ? Message-ID: <200002191352.AAA06539@cairo.anu.edu.au> In-Reply-To: <200002191322.OAA84928@info.iet.unipi.it> from "Luigi Rizzo" at Feb 19, 2000 02:22:15 PM
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Luigi Rizzo, sie said: > > > > 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. NAT can easily be implemented as a `filter'. I suspect all of the others you mention (divert/forward/tee) also can be. IP Filter has, for years, supported a "tee-like" feature where it will send a duplicate of a packet out another interface. It may even do "forward" but not "divert"...I don't follow ipfw features very closely O:-) > 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. Changing routing information is not a problem. For starters, with inbound packets, there is none. > 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. "divert" is just a mess :-) [...] > 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. Just because ipfw/ip6fw are only associated with a single protocol does not mean they can't use a generic interface in place of one specific to them. I think it is short sighted to assume that whatever is there now will be there in X years time or that nobody will want to use their own whatever. By building a generic framework (not that of a unified filer), you support multiple filters out of the box and each can work without any special changes to the kernel. > 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!) I'm not saying merge anything. But in the case of ipfilter, easier to merge ipv6 in than create a whole new 'ipfilter6'. > 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. That depends on how you view and design it, doesn't it ? In so far as IP is concerned, the only significant difference is address size. If you look at how linux's iptables works, there are separate modules for each of ip, tcp, udp, icmp, etc. A packet is filtered by calling the appropriate filter routine for that protocol. In comparison to ipfw which does all its port checking, etc, in `one place'. The idea with pfil(9) as it is in NetBSD now is to allow a filter module to register if it wants to filter inbound (or outbound or both) packets for a given protocol. e.g. I could write a small anti DDoS thing and filter inbound IPv4 packets only and not need to make any changes to the standard kernel source. Using this approach, ipfw would register for in/fwd/out ipv4 packets and ip6fw would register for in/fwd/out ipv6 packets. Darren 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?200002191352.AAA06539>