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

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

On Sun, 6 Mar 2005, Vishwas Manral wrote:

> Hi George/ Pekka,
>
> I just want to add to the few things Pekka has stated: -
>
> ==> 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).
>
> Would working at line-rate be the requirement for the above in case of
> filtering?

yes, I thought that was captured, but the 'performance degradation' was
not 'traffic' but 'management' related. I'll clarify that as well.

>
> ==> 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.
>
> I agree packet filters for forwarded packets/bytes should be 64 bit
> counters. Also instead of telling ranges of values we could very well
> tell the size of the counters.
>

will check on this as well, but keep in mind it's a minimum...

> Thanks,
> Vishwas
> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On Behalf Of
> Pekka Savola
> Sent: Sunday, March 06, 2005 9:05 PM
> To: opsec@ops.ietf.org
> Subject: draft-morrow-filter-caps-00 comments
>
> 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.
>   - 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.)
>
> 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?
>
> 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...
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>