Date: Thu, 29 Feb 1996 12:02:58 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: hackers@freebsd.org Subject: Re: IP filtering strawman, comments please. Message-ID: <199602290101.RAA02493@freefall.freebsd.org> In-Reply-To: <12238.825366315@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I was passed this e-mail and asked to comment, which I don't mind doing, so long as someone will listen. > This is a strawman intended to foster discussion about the future support > for IP packet filtering in the FreeBSD kernel. [...] > The present support (as of 960226) provides the following support: > > There is one chain of rules, and it is applied at (A), (B), (Ci) > and (Co). The following information is available, in addition > to the packet itself: At (A) and (Ci), receiving interface. > At (B) and (Co), destination interface. > > Now, this is clearly not optimal from particular many points, therefore > I suggest the following model instead: > > There will be multiple chains of rules as follows: > > For each interface, two chains of rules. One filters > incoming packets, the other outgoing packets. In Fig 1 > these are the pairs (0i/0o), (1i/1o) &c. No information > is available apart from the packet itself. > > There will be a filter-chain at (A) to filter what packets > we let into the local protocol stack. In addition to the > packet, information about the arrival interface is available. > > There will be a filter-chain at (B) to filter what packets > we let out of the local protocol stack. In addition to the > packet, information about the destination interface is > available. > > There will be two filter-chains at (Ci) and (Co) to filter > what packets we route through this machine. At (Ci) the > arrival interface is known and at (Co) the destination > interface is known in addition to the packet itself. [...] > At each filtering point, the rules are applied in numeric order, > until one of them matches the packet, the action from that rule > is then taken. > > Just as important as where a rule can be applied, is what the rule can > express, I suggest this functionality, this is more or less what we have > now as well: [...] > Packet is (not) a broadcast. > Packet is (not) a multicast. This can (only) reliably come from looking at the MAC address and will need to be done in the driver, somewhere. ie if_ether.c and if_ppp.c (not if_ed.c, etc). If this is a requirement, then the current ipfw structure needs to be totally scrapped and something using BPF implemented. Having looked into this already, I'd suggest that a filter list would then be a set of BPF programs, with filter return statuses used bsed on what BPF thinks. There are some problems with this, however... > "printf" register the match with printf. > "syslog" register the match with syslog. > "verbose" be very detailed. > "hexdump" be very very detailed. > The changes to the code to support this scheme are rather simple: > Add reference counts to each rule. > Add two rule-chain headers to the if structure. > Add the logic to specify what chains a rule applies to. > Make sure ip_output knows if the packet was locally generated > or routed. > > Comments ? Have you considered what this does for management of packet filtering ? The complexity is increased too much, I fear. If I want to delete a rule, how many times do I have to delete it if it is referenced by several interfaces/control points ? At USENIX last year, Andrew Molitar presented a paper describing how his filter mechanism supported filtering at 5 different places during the packets possible lifetime. The main problem I see with this is: how easily can I view a complete list of rules that can possibly effect the packet and what do I have to do to verify that my access list rules are doing what I want ? Filtering packets being "routed onwards" is a dubious distinction from those being sent as output, IMHO. The only reason I'd be thinking about making changes like this would be for performance reasons. In testing IP Filter, I've noticed very little degradation on a P-100 with 1 or 100 rules for ftp across my own ethernet. The furthest I would consider breaking this up is per-interface, input and output. My reason for not doing this is that allows general rules to be used without complicating the model required to support it (just uses a single list for each of input and output). The correctness of the implementation also becomes harder to prove, requiring bits of the kernel to be used in testing. Currently, you could take the engine from ipfw and build a userland progam around it (I hope!) which could trivially test any/all packets. The problem of how to "log" packets is a side effect of how it is currently being done: either via log() or printf()/kprintf(). This is better solved by fixing the way interaction is done with the in-kernel filtering. On a separate note, prior to 2.1.0 release, a few people from freebsd-security asked about incorporating IP Filter. The reason given then for not including it (accounting) has since been fixed; URL: http://coombs.anu.edu.au/~avalon/ip-filter.html I guess what you end up doing depends upon what your goals and aims are. What problems are you trying to address (and solve) with your strawman ? darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602290101.RAA02493>