From owner-freebsd-hackers  Sun Aug 18 14:50:38 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA14828
          for hackers-outgoing; Sun, 18 Aug 1996 14:50:38 -0700 (PDT)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA14811
          for <hackers@FreeBSD.ORG>; Sun, 18 Aug 1996 14:50:29 -0700 (PDT)
Message-Id: <199608182150.OAA14811@freefall.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA133605005; Mon, 19 Aug 1996 07:50:06 +1000
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: ipfw vs ipfilter
To: imp@village.org (Warner Losh)
Date: Mon, 19 Aug 1996 07:50:05 +1000 (EST)
Cc: phk@critter.tfs.com, jkh@time.cdrom.com, ugen@latte.worldbank.org,
        hackers@FreeBSD.ORG
In-Reply-To: <199608181615.KAA00454@rover.village.org> from "Warner Losh" at Aug 18, 96 10:15:05 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from Warner Losh, sie said:
> 
> : The only think I have against ditching ipfw and replacing with ipfilter
> : is that the later is getting to big for comfort.
[...]
> He preferred ipfw to ipfilter (which we've been using for a long time)
> because ipfw was easier to verify than ipfilter because ipfilter has
> added too many bells and whistles for his confort.

Many of the "bells and whilsts" have been added after sugestions from users
or just improving it to be on a par with commercial systems (or better) or
just so that it is `complete'.  In some cases, the grammar has been
extended not to invent a new feature, but because the code already made it
possible so it seemed reasonable to take advantage of that.

IP Filter has its own set of regression tests, which you can verify yourself
and then against a test run, if you like.  Not to mention that this has
helped find bugs.  Both rule parsing and rule processing are tested for
correctness.  This is seen in neither ipfw or ipfwadm for FreeBSD/Linux.
In a security concious world, how can you not want to be sure of something
like this ?

Whilst it might be considered to be "feature rich", I don't think any of
them are superflous.  Granted, not many people care about security options
in TCP/IP packets, but the same sort of functionality is in Ciscos, not to
mention it does get used in IP Filter by some people...

Darren