On Mon, 28 Apr 1997 19:23:02 -0700 
 Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:

 > Well, then, we'll be even;).  Your ``fix'' added a bug to my firewall.

...Well, relying on a bug is never a good idea ... someone might come
along and fix them :-)

Besides, if that change broke your firewall, I'd assert that your firewall
was too fragile in the first place.

 > Jason, I don't agree. If the user configured ipfilter into their
 > kernel, then passing every packet through the rule-filter engine is
 > exactly what the user _asked_ for.  Not passing all packets through
 > the rulefilter is a _bug_.  I think that's what Darren is saying, too.  

I'm sorry, but you're just wrong.  Just because the user has ipfilter
configured into their kernel does _NOT_ mean they intend on using it
Right Now.  Packets should _NOT_ be passed through the filter rules
unless the filter is enabled.  The _ability_ to enable the filter
is not the same thing as actually enabling it.

...see below...

 > I thought Darren was saying that loading an ipfilter LKM should _also_
 > pass all packets through the rule-filter, unless otherwise specified.
 > Darren, could you clarify that?

Yes, I believe that is what Darren was saying, as well.  Again, see below...

 > >If you want the behavior you describe, _please_ implement it as
 > >a kernel compile option, like:
 > >
 > >options         IPF_EARLY_ENABLE        # ipf enabled early, no "ipf -E" req'd.
 > 
 > If anything, the default should be the other way around, for
 > compatibility with the standard ip_filter distribution, and with
 > ip_filter on other platforms.  ip_filter has always worked this
 > way. In fact, that's one of the reasons I recommended we choose it.

...There are lots of things that "have always worked foo way" that
have changed for various reasons... But, that's not really an argument
I care to get into right now... I suspect I'll be busy enough with
this one :-|

 > Jason, could you explain *why* you want that behaviour?  
 > And *why* you think the previous default behaviour was a bug?
 > I don't recall ever seeing such a thing.
 > 
 > It's very likely we're alltalking past each other. Perhaps we have
 > different ideas of what ipfilter is for, and what is sensible default
 > behaviour.  Making blanket statements like "Do X" (or "don't do X")
 > doesn't help resolve that at all.

Ok, here 'goes...

Part of his is a simple matter of consistency.  If I configure a file system
into the kernel, I have to enable it before I use it.  If I configure
a network interface into the system, I have to enable it before I
use it.  If I load the FDDI LKM under SunOS, I have to enable the interface
before I use it.  It doesn't magically start up with some default
configuration and start sending packets out to the network.

The second is the principle of least astonishment.  Let's look at a couple
of scenarios:

	(1) New NetBSD user downloads a binary snapshot that a portmaster
	    built, which just happenes to have "ipfilter" in the
	    catch-all kernel.  Unsuspecting user configures network,
	    notices it doesn't work.  Puzzled, new NetBSD user either
	    gives up on NetBSD, or posts, confused at why networking
	    doens't work in NetBSD.

	(2) Experienced NetBSD user decides he/she wants to try out
	    ipfilter, in his/her spare time.  Builds kernel with
	    ipfilter option, thinking "Ok, I'll sit down to learn this
	    thing this weekend..." ... reboots, and is annoyed to discover
	    that the network doens't function without a magick option
	    or learning ipfilter Right Now to install an "all-pass" rule.

	(3) "But, the ipf(8) manual page says that -E enables the
	    filter.  Why does it return an error message?"

(Yes, I know it says "not effective for loadable kernel verions".  I
consider that inconsistency a bug, as well.  An LKM should function
no differently than a statically compiled in subsystem.)

My third and final reason is this:

	Whether ipfilter is "enabled early" or not _should not matter_!
	(If it does, please don't muck with my firewall, okay?)

Let's look at this for a second...

	(1) ipf -E in /etc/netstart before any interfaces are ifconfig'd up.
	    This gets the rules in place before you can even _receive_
	    packets.  If the rules are installed before any interfaces
	    are enabled, this gives you the behavior that you want.
	    (That is, unless you are _completely_ miscommunicating
	    what it is that you want.)

	(2) The previous default rule when ipfilter was enabled was
	    "all pass" (this is obvious, otherwise the networking
	    on my hp380, which has ipfilter in the kernel, but didn't
	    have rules installed at the time, would not have worked).
	    Thus, you needed an option _anyway_ to get the behavior
	    you want.

	(3) Previously, you mentioned that diskless systems acting
	    as firewalls were somehow at risk.  Bull...err, feathers.
	    Only one interface is enabled during diskless boot, and
	    it had BETTER be one on a safe, trusted, internal network!
	    Because of (1), filter rules will be installed before the
	    rest of the interfaces are enabled, and so this is simply
	    not an issue.

 > I've tried to explain why I think the current, `fixed' default
 > behaviour is a bug.  I haven't seen any substantive response to those
 > messages.  (sorry, but I don't think saying "run ipf -E" is a
 > substantive response).
 > 
 > Jason, could you please do the same, so that Darren has some more
 > information to proceed with?

"See above."

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939