[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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