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

[George Jones <eludom@gmail.com>]

On Sun, 6 Mar 2005 17:35:12 +0200 (EET), Pekka Savola <pekkas@netcore.fi> wrote:
> Hi,
> 
> A few notes I jotted down on the flight..
> 
> Generic comment: these basic filtering capabilities (except for unclear
> applications) appear to be good enough for routers at least in our
> environment.  A few observations:
>   - the document does not yet address uRPF filtering.  That's a pretty strong
> must for us at least (strict uRPF at line rate).  In addition, we really
> want "feasible path strict uRPF" (see RFC3704) as well.  We don't really
> care that much about loose RPF.

I'm all for avoiding duplication of effort...and you and Fred covered uRPF 
prety darn well in 3704 (note that early revs of 3871 talked about turning
off directed broadcasts, but it was dropped in the final because 2644 
addressed the issue).

That being said, the "cannonical" breakdown in OPSEC (per the framework) is:

    Practices [Merike]  <===> Capability Draft
                                                     * Capability/what
[device is able to....]
                                                     * Supported
Practice(s)/why [cite practices]
                                                     * Current
implementations/how [e.g. uRPF]
                                                     * Considerations
[other issues/warnings/etc]

>   - if this doc should also apply to non-routers (like ethernet switches),
> more filtering capabilities would likely be needed -- like MAC address based
> filters and sane port security (you can put an interface to learning mode,
> then turn it to "lock", and those MAC addresses are the only ones allowed --
> indefinitely, without timeouts.  Just to reduce the typing.)

I think, per discussion in other thread we've concluded that layer 2 filtering
not done in practice in large network cores for several possible reasons.


> 
> 2)
> 
> 2.1.3  Ability to Filter Traffic To the Device - Minimal Performance
>        Degradation
> 
> ==> this section is too ambiguous to be of any real use.  I guess you'll
> _have_ to specify at least "minimum" minimum performance degradation -- if
> the vendor can't perform even _that_, it shouldn't claim to be compliant
> (e.g., a device should be able to deal with 50 address/port based rules
> with no change to the maximum transfer rate with 20 byte packets).

Sigh.  We went over that.   I guess it's time to revisit.  I'm having lunch
with Scott Poretsky of the benchmark methodology working group today....
I'll get his take.

Bottom line, I think, is that the degredation that is acceptable will
vary from situation to situation & what's needed is for the operator
to know what their requirements are and to have some way of knowing
what the degredation pattern for a particular device is going to be.


> 3)
> 
>       While silently dropping traffic without sending notification may
>        be the correct action in security terms, consideration should be
>        given to operational implications.  See [RFC3360] for
>        consideration of potential problems caused by sending
>        inappropriate TCP Resets.
> 
> ==> rfc3360 is a nifty reference, but IMHO doesn't belong here.

It does a good job listing considerations when sending/not sending
resets....it's listed in the "considerations" section....If I were considering
sending/not sending resets, I'd appriciate having the reference....

> ==> 32 bit counters are soooo last millenium.  I doubt we'd be getting any
> equipment which doesn't do 64 bit counters.

I'm convinced.

>  I'd make it a must.

In this context, we're listing capabilities, not requirements (musts...)

---George