RE: draft-ietf-opsec-logging-caps-03

["Smith, Donald" <Donald.Smith@qwest.com>]

Rate limiting SNMP traps and counting the number of traps dropped would almost be good enough.
If you saw 80 failed login attempts and knew you missed 1000 additional messages you could guess that most of those 1000 were failed login attempts.
 
Some routers have generic logging features which can use multiple different logging delivery mechanisms. In that case if they could aggregate the LIKE messages first then deliver a "like message XX times" follow-up at the end of an incident or after a reasonable (configurable) time-out.
If someone is trying to ssh brute force your network element you don't want to know about it tomorrow even if the attack lasts all night. So a time out is good idea.
 
In every case I can think of the network element won't know if a remote logging device is full.
So only when a local log device (drive, memory...) is full or near full would the full device case be activated.  We probably need the concept of a high and low water mark to define "full" if the local log device is a shared resource needed for other operations support. That would allow you to reserve room for an new image if needed or an additional copy of the config so you can make changes to the config even while the local storage device is "nearly" full.
 
 
 
 
donald.smith@qwest.com giac

________________________________

From: owner-opsec@psg.com on behalf of patrick cain
Sent: Tue 7/3/2007 8:32 AM
To: 'Ron Bonica'; opsec@ops.ietf.org
Subject: RE: draft-ietf-opsec-logging-caps-03



Ron,

When George and I wrote the logging caps doc, we specifically stayed away
from the log message 'collector' as opposed to the log message 'generator'.
We had some, um, disagreements, but George convinced me that was the right
thing to do. I expected some of the log processing things, like "what
happens when a component send a million messages" would fall into the
collector category. But I guess one of the router interfaces could be
considered a 'component' so we should address the issue.

So...

1. I will craft some capabilities for the million message scenario. I'm not
sure that there are 'bcps' for these actions, though.
        - I will add a capability to efficiently handle rapidly generating
significant numbers of log messages to not overwhelm the delivery mechanism.
Example is syslog's "last message received XX times". I'm not sure than SNMP
has an equivalent mechanism, unless rate limiting outbound SNMP counts. :(
       
        - for the 'log is full' case:
                "The device should be configurable to either: a) stop
logging to all devices, b) drop the oldest log messages, or c) stop logging
to the local device, when the local logging device is full."

2. I will add words to 2.16 for "sensitive configuration information".

3. The original goal of the document and the WG was to make the three
capability documents BCPs. Otherwise we could have saved lots of time just
spewing words, not trying to figure out what ISPs and vendors actually do or
want.

Pat


-----Original Message-----
From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On Behalf Of Ron
Bonica
Sent: Thursday, June 28, 2007 4:55 PM
To: opsec@ops.ietf.org
Subject: draft-ietf-opsec-logging-caps-03

Folks,

The following are a few comments from AD review:

- In Section 2.16, all sensitive configuration information needs to be
protected. This includes thinks like cryptographic keys as well as
passwords.

- Do we need another requirement that says that it should be difficult, if
not impossible, to alter the local copy of a log?

- How should the system behave if some components spews 1,000,000 instances
of the same log message in a 5 second period?

- How should the system behave if some component spews 1,000,000 different
messages in a 5 second period.

- How should the system behave when all of the space for local logging is
exhausted. Drop oldest messages? Tail drop?

- We will probably have to decide if this doc is BCP or INFO.

                                     Ron





This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.