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

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



Hi Chris,

Some minor comments: -

>   - 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.)
In this case VLAN based an etherType based filtering besides the above
are necessary.

> Seriously though, the doc should/will have 2 basic parts:
> 1) device protections (to device)
> 2) network protections (through device)
I think you may have missed the "from device" case. In Linux IP Chains
we have the 3 sets of chains: - 1) From 2) To 3) Forward. It is
considerably more complex for the IP Tables.

> ala juniper loopback filter? or "just drop all protocol FOO on this
> device" ?
This could be part of filtering based on protocol header (protocol field
in IP Header), however specifying checks explicitly would help.

> ==> 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 ...
Would the minimum requirement be based on the link speed?

Thanks,
Vishwas
-----Original Message-----
From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On Behalf Of
Christopher L. Morrow
Sent: Monday, March 07, 2005 1:07 PM
To: Pekka Savola
Cc: opsec@ops.ietf.org
Subject: Re: draft-morrow-filter-caps-00 comments

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