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

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



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?

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

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