From owner-freebsd-hackers Sat Feb 19 6:59:54 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 8323C37BC42 for ; Sat, 19 Feb 2000 06:59:49 -0800 (PST) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id PAA85263; Sat, 19 Feb 2000 15:59:30 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200002191459.PAA85263@info.iet.unipi.it> Subject: Re: post 4.0...adoption of pfil(9) from NetBSD ? In-Reply-To: <200002191352.AAA06539@cairo.anu.edu.au> from Darren Reed at "Feb 20, 2000 00:52:01 am" To: Darren Reed Date: Sat, 19 Feb 2000 15:59:30 +0100 (CET) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. > > 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 :-) i know. But who has the time to fix it! > I'm not saying merge anything. But in the case of ipfilter, easier > to merge ipv6 in than create a whole new 'ipfilter6'. that's up to the maintainer. does not make a big difference (well, maybe just the syntax becomes a bit more complex -- ipfw syntax in this respect is already a mess). > 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. 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. 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. 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. 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