Date: Sat, 19 Jun 1999 18:40:38 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Brian Fundakowski Feldman <green@unixhelp.org> Cc: Darren Reed <darrenr@reed.wattle.id.au>, npp@distortion.dk, ru@ucb.crimea.ua, hackers@FreeBSD.ORG Subject: Re: firewalling (Was Re: Introduction) Message-ID: <Pine.BSF.3.95.990619182222.13715A-100000@current1.whistle.com> In-Reply-To: <Pine.BSF.4.10.9906182232290.85521-100000@janus.syracuse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
We use IPFW to great effect in the interjet whatever we end up with had better have the same features or we can't use it.. 1/ simple to use programatic API 2/ Divert sockets are a MUST. We do a lot of our filtering in userland. 3/ The ability to branch the rules using 'skipto' (goto?) is used heavily and the goto optimisations are very important to our performance. 4/ The 'fwd' facility is also very important. 5/ Line numbers are crucial to the way we control rules in the product. 6/ the ability to log but not halt processing of a packet is also crucial. If you change the semantics of how rules interact, you could screw us. Maybe you should look at what BSDI have.. A bpf based filter for link layer, and a separate IP layer filter.. Also look at the DPF code from MIT (in the exokernel). If we are going to do a replacement we shouldn't junk ipfw for something of equivalent technology (ipf), but consider doing something like DPF which is truely revolutionary. DPF generates att addition time, Dynamically generated machine instructions for an optimal packet classifier. When you add a rule, it re-writes the machine code.. there are ports for several architectures and it's very portable. Making a tree of indivdually created DPF filters would lead to incredibly high processing rates of very complicated rules. If you are not going to go the whole hog, then better to leave things the way they are (but with some cleaning). Security mechanisms are not the things you want to futz with too much. WHile I agree that ipf is "standard in NetBSD and OpenBSD, ipfw is closer to the Linux ipfw and as such, it would be a better maketting plan to ether leave it as is or move more towards what they do or leave it much as it is.. the others are pretty irrelevant when it comes to market and especially when it comes to our share of it. After 23 years in this industry I've learned (it took a long time) that a working but not perfect feature is better than a perfect one if the perfect one has marketting drawbacks. The present system is real easy to understand and many people use it. Think REAL HARD before removing it. IPF can already beadded by those that want it. Don't screw over the project in your eagerness to do good. Having said that I know IPFW's weaknesses. Most of it comes from the fact that we are working "out of the correct layer" sometimes. I'd LOVE to see a good DPF implementation.... julian On Fri, 18 Jun 1999, Brian Fundakowski Feldman wrote: > On Sat, 19 Jun 1999, Darren Reed wrote: > > > In some email I received from Brian Fundakowski Feldman, sie wrote: > > > How do you feel about (after getting it fixed in -CURRENT) helping with > > > converting ipfw(8) to just a front-end to ipf? I think it's worth discussing > > > whether it's actually worth it to rewrite IPFW or just work on improving > > > ipfilter. (discussion moved to -hackers) > > > > I imagine they might be fighting words to some ;) As I see it, if you > > added hooks for divert to ipfilter in FreeBSD and maybe added the rule > > number bits (I *know* there are going to be people who'd just die without > > it) then I can't see why you'd need ipfw. I imagine that would be a hell > > of a lot less work than bringing the features of ipfilter into ipfw. > > > > It'd also be one of those steps forward in compatibility between the various > > BSDs... > > Yes, and I know it might take some work. I'd like to have something good be > the default in FreeBSD, and I feel that maybe if ipfilter can be brought > to the foreground well and made backward compatible (i.e. ipfw(8) to translate > (perl? /bin/sh? idunno)), it will be a winning thing. I'd of course like to > add UID/GID support to ipfilter like I did to IPFW (but didn't commit). > IPFW is nearing the end of its maintainable life. It needs a pretty large > rewrite or full replacement pretty soon. If we can get ipfilter in src/contrib > kept up-to-date and working, supplying a replacement for ipfw(8) as a front-end, > I don't see why ipfilter can't be the "FreeBSD firewall." > > > > > > Darren > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > green@FreeBSD.org _ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | > http://www.FreeBSD.org/ _ |___/___/___/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > 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.95.990619182222.13715A-100000>