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

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

getting started reading comments...

On Sun, 6 Mar 2005, Pekka Savola 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.

ok, I'll see if this fits into the over all... uRPF might be an
'implementation' and out of scope for the doc.

>   - 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.)
>

mostly this is/was aimed initially at 'routing devices' (L3)

> 1)
>
>         2.1.1  Ability to Filter Traffic on All Interfaces  . . . . .   6
>         2.1.2  Ability to Filter Traffic To the Device  . . . . . . .   6
>
> ==> there is one subsection on filtering to any interface, and the rest are
> to the device only?  The text in 2.1.x is apparently taken from "all
> interfaces", because it doesn't always sit well.  So, what's the deal?
>

crack cocaine? Seriously though, the doc should/will have 2 basic parts:
1) device protections (to device)
2) network protections (through device)

> Maybe you should specify different scenarios where you can apply filtering
> in section 2.1 ("to the device", "on all interfaces", others if needed), and
> the capabilities which are independent of the applications in section 2.2
> (specify filter actions, etc.), or...?
>
> Note: is it required to be able to (easily) filter the traffic that is
> originated from the device?  At least we don't...
>

good question, I'm not sure anyone does this, but it may indeed be useful
to add.

> Note: it might be that it's more important for some operators to be able to
> perform a specific function _to the device_ rather than on any possible
> interface.
>

ala juniper loopback filter? or "just drop all protocol FOO on this
device" ?

> 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).

The performace degradation I was aiming at was: "console access" or
"management access" limitations... a 7206 can filter (sort of) 5kpps aimed
at the device once you put on recieve-path acls, but it won't be very
happy about that filtering and device CPU will shoot to 99% :( That's
unacceptable. Filtering "TO THE DEVICE" should have no impact on device
CPU/management/console...

>
> 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.
>

will check on this.

> 4)
>
> 2.1.16  Ability to Filter To the Device - Filter Counters are Accurate
>
>     Capability.
>
>        Filter counters are accurate.  They reflect the actual number of
>        matching packets since the last counter reset.  Filter counters
>        are be capable of holding up to 2^32 - 1 values without
>        overflowing and should be capable of holding up to 2^64 - 1
>        values.
>
> ==> 32 bit counters are soooo last millenium.  I doubt we'd be getting any
> equipment which doesn't do 64 bit counters.  I'd make it a must.
>

minimum requirements for the capability ...