Date: Sun, 20 Feb 2000 14:11:35 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Luigi Rizzo <luigi@info.iet.unipi.it> Cc: Darren Reed <avalon@coombs.anu.edu.au>, hackers@FreeBSD.ORG Subject: Re: post 4.0...adoption of pfil(9) from NetBSD ? Message-ID: <Pine.BSF.3.96.1000220140510.78759D-100000@fledge.watson.org> In-Reply-To: <200002191459.PAA85263@info.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 19 Feb 2000, Luigi Rizzo wrote: > > 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. Luigi, Don't know if you've had a chance to look at the BSDI work at all, but last I heard they were actually using an extended bpf to do a log of the abstraction work for packet filtering, nat, and management. Right now we have a diverse set of packet filtering mechanisms, and as Darren points out, filtering languages depend on the layer where they must be applied. The BSDI solution allows bpf to be used to match a variety of protocols, and rather than making layer-specific filtering code in the kernel, you push in layer-specific bpf filters from userland. As I understand it, they also allow appropriately privileged bpf filters to do live-modification of the packets in transit, allowing flexible user-defined NAT behavior, etc. You could imagine ipfw converting its rule matching to bpf filters before pushing the code into kernel, etc. I'm really not very familiar with the BSD/OS work, it was pointed out to be at a recent DCFUG, but it might be worth looking into. Another interesting question about filtering behavior is how it should be integrated with NetGraph, as NetGraph provides the opportunity for much greater flexibility in network stack construction. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services 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?Pine.BSF.3.96.1000220140510.78759D-100000>