It is better to have a secured host,
	than an unsecured host behind a firewall.


=46or the statement above, "secured" means a host whose software and
configuration is correct, and operating properly.

If you agree with this philosophy, then fixing every bug (security or
otherwise) found is important. From a systems design perspective, this is
the right attitude to have, and, generally, the people working on NetBSD
have this attitude.

People working operations tend to want to just "make things work" with
whatever resources they have available, and the least amount of effort.
Been there myself, done that. Given the state of typical UNIX vendor
software and systems engineering today, this means deploying a firewall.
Sad, but true. However, one should never lose sight of the fact that a
firewall is strictly a *stopgap* measure to cover for missing or incorrect
software on the hosts one is "protecting" in this manner.

Some of the argument over NFS stems from a conflict between these two
points of view. I believe the other part of it is a conflict between the
desire for ultimate performance (i.e. lowest possible overhead) for any
given hardware platform, versus having real secured systems, which, alas,
often requires serious overhead on a per-transaction basis. Worse, since
security is almost always an afterthought, the associated overhead almost
always a performance take-away.

The question is principally whether "security overhead" is necessary or
unnecessary against the desire for ultimate performance. Sun once thought
that UDP checksums were unnecessary overhead. PC manufacturers seem to feel
that RAM parity is unnecessary overhead. I would argue that the people who
feel that various integrity and security checks are "unnecessary overhead"
simply haven't been burned yet.

It is important to remember that the "secured host" is a goal; an ideal.
Given the tools we have and human fallibility, we'll probably never achieve
it. However, I believe we should always be striving to get there with the
architecturally cleanest solutions.

	Erik Fair <fair@clock.org>