Date: Sun, 20 Feb 2000 09:01: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: <200002192201.JAA28785@cairo.anu.edu.au> In-Reply-To: <200002191459.PAA85263@info.iet.unipi.it> from "Luigi Rizzo" at Feb 19, 2000 03:59:30 PM
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Luigi Rizzo, sie said: > > > Changing routing information is not a problem. For starters, > > with inbound packets, there is none. > > for outbound there is, and one of the biggest problems i had > with dummynet (as an example) was that some code passed > around route structures held in the stack, so you couldn't just keep > a reference and reuse it later. Bad engineering you can say, > and i agree, but fixing this requires fixing the source, not > just defining a filter interface. mmm, fixing the source. > > 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'. > > but layer boundaries are just on paper, in reality especially a firewall > looks all over the headers (and maybe in even more places). > When you filter TCP, you still look at the IP addresses. In ipfw, you > can even look at the UID of the associated PCB. So ? > By registering filters per protocol at different layers, you have a problem: > suppose your rules are the following (in ipfw style, first match wins): > > 1: deny ip from A to any > 2: allow tcp from any 23 to any > > when you get a TCP packet, when do you invoke the filter, in > tcp_input() or in ip_input() ? You should probably do the call > at the highest possible level in the stack (TCP in this case), > but then you should duplicate rule 1 in the TCP chain or > you are in trouble. Urgh, I see you're not familiar with theirs either. The filtering is invoked from IP (just like ipfw) but rather than do "if tcp then check ports and flags", it does "call per-protocol check". Maybe I'm just not explaining this clearly... > Furthermore you need hooks in all protocol at all levels, and you > depend on upper-level protocols to be implemented properly or > filtering fails -- e.g. if the protocol PGM (to name another one > i am working on) forgets to call the filter, then all PGM packet > will skip the IP check. Huh ? I think you're not understanding what I'm saying. > What we have now in ipfw is a bit more messy (as you do a lot of > work trying to classify packets) but at least understanding the ruleset is > rather easy, and the places in the kernel where the match is done > are more limited. I wouldn't call it "limited" :) There are more ipfw hooks required than ipfilter hooks for basically the same job :-) You would do well to download a linux kernel and see what they do, as well as looking at how NetBSD now handles it. My descriptions have been heavily modified to be concise and are not doing either OS justice. 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?200002192201.JAA28785>