Re: draft-morrow-filter-caps-00 comments

["Christopher L. Morrow" <christopher.morrow@mci.com>]

On Thu, 10 Mar 2005, George Jones wrote:

> On Thu, 10 Mar 2005 08:58:57 -0500, Howard C. Berkowitz
> <hcb@gettcomm.com> wrote:
> > I'm sorry if I missed this being there already, but I'd like to see a
> > survey of statistics/logging with respect to filters in operational
> > practice.
>
> Seems like another fine candidate for the Benchmark Methodology WG.
>
>   Clearly, too fine-grained a level of filtering (e.g., with
> > static ACL logging), with a high traffic volume, will overwhelm most
> > processors.  Some means of reducing this load is probably going to be
> > needed in any production system.

As george said, I think the capability is 'log filtered things when
logging is enabled', the implementation might have a maximum num log
messages created/sent per second... that will likely be far less than a
compltee oc-192 of traffic at any packet size. So, understanding that the
filtering tag 'log' makes logs is good, someone testing the vendor's
implementation will want to find the upper limit on 'logs persecond' or
'accuracy of logging relative to actual traffic loads through the logging
portion of the filter'.

>
> Or at least an understanding of the potential impact (silent drop, spike
> processor, increased traffic due to logging)
>
> >
> > And what are these means?  Certainly there's a spectrum.  I'd put
> > "diversion" at the top of the list -- rerouting problematic traffic
> > to a sinkhole where detailed analysis can be done.
> >

This should be in Merike's document, but in practice (speaking as a
practiioner here) we will more often just:

access-l 100 permit ip any any log
access-l 100 permit udp any any eq 98

and apply that to the interface, watch logs and 'fix' the problem... This
is because the implementation we have allows us to not shoot ourselves in
the foot (where acls are implementable of course). Sinkholing pre-supposes
a place in your network which can sustain gianormous traffic spikes
successfully. :)

> > At whatever point the filtering/inspection/whatever is done, there
> > are a range of levels of detail that can be taken, such as:
> >
> >      Complete packet capture with decode [1]
> >      Complete packet capture [1]
> >      Header capture [1]
>
> Isn't that what PSAMP was doing ?
>

I think the 'log' tag would require a spec on 'what minimum to log' (s/d
add, s/d port, ingress interface?, protocol, #repeats ... as an example)
Else you could 'satisfy' this with a message logged of: "orange",
provided your documentation says: "Log messages of 'orange' mean a
packetfilter log"

> >      Exact counts of packets matching complex expression [2]
> >      Exact counts of packets matching simple expression (e.g., source)
>
> Counts are good.  Accurate counts are better.    I believe these are
> already addressed.
>
> >      Sampling counts of packets matching complex expressions [3]
> >      Sampling counts of packets meeting expressions of lesser complexity [3]
>
> See PSAMP ?
>

Yes, 'sample' is another acl/filter tag like /log/ or /discard/ or
/reject/ or .... is this a base requirement?