[NCLUG] Egress Filtering

[John L. Bass]

	On Tue, Aug 14, 2001 at 11:57:23PM -0600, John L. Bass wrote:
	>What is personal are slurs like Sean's which twist my stated position and
	>use highly directed language like:
	>
	>Sean Reifschneider <jafo-nclug at tummy.com> wrote on Sat, 11 Aug 2001 11:02:44 -0600:
	>| If you're not part of the solution, you're probably part of the problem.

	Whoa, simmer down, dude...  That's a relatively well-know quote which was
	applicable to this discussion.  In this context it's fits as: If you aren't
	preventing trash from getting out of your network, you are contributing to
	the problem.  I honestly can't understand how you could take that as a
	slur, but I'm sorry that you interpreted it that way.

	Now you can appologise for calling me stupid...  The last S in KISS, right?

	Sean

Your continued assertion (and slur) is that I have no interest in solving
the problem, is FALSE at minimum, especially when I've stated all along in
this discussion that I agree with the goal and offered an alternative site
methodolgy that deals with it.  Your restating that slur in the above text
AGAIN, with the assertion it "fits" either shows a total lack of comprehension
on your part, or some other less noble intent.

The whole point of this discussion, is that I also agree the packets don't
belong on the network, but with a different management philosphy/style that
achieves the same end.  Yes it might leak a few in the short term, while you
identify the source, but you do stop them using nearly the same procedures
that would be required back tracking from router filter logs. But with the
BIG difference that it doesn't risk choking the router with snmp/syslog events
and add a bunch of extra trash to logs that runs up the log file space necessawry.
The problem with most filtering approachs is that the events will not be logged
(to avoid choking the router and log machine) and the REAL problem will never
be fixed, and the customer(s) involved don't have a clue until it contributes to
some major and difficult problem to locate because 30 customers are triggering it.
Some might even claim, let the customer continue to send the packets out his
port - so we can charge him for the trash since we discard them anyway.

A well armed network managment station with key facility packet taps can
trace/debug/monitor a wide variety of both problems and normal traffic
management issues - like site profiling.  This station is also key to generate
alarms for other events, and identify a number of issues that would never
be visible from router logs without a lot of unncessary and complex router
coding. My management philosphy includes keeping changes out of mission
critical gear - if it ain't broke, don't fix it, if there is any other
way, keep your damn hands off it.

In short - a router is a data transfer device - burdening it with extra
rule sets to implement monitoring is poor network design when better
alternatives exist. Furthermore, manageing the monitoring rule sets
adds an unnecessary risk of creating accidental failures for the device
and facility.

The acronym KISS is a core professional/management philosphy, which I live
by, was injected into the conversation to make the point that a draconian
nightmare of unnecessary router filters is the recipe for creating an
unmanageable facility.  Such designs are typically referred to as "job security",
I don't know why since any good manager fires that kind on the spot and
gets someone who knows how to do the job with shared team values that
minimize facility risk.

John