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

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