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

[Warren Kumari <warren@kumari.net>]

Comments inline.
On Jul 3, 2007, at 10:32 AM, patrick cain wrote:

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

One possible concern with rate-limiting syslog / SNMP / whatever is  
that people will then try and generate non-critical events that cause  
alerts to be generated in the hope that they can then slip a more  
nefarious event in and have it also be caught by the rate-limiter.  
What would be great would be, if there were a rate-limiter it would  
prioritize high severity messages over lower severity ones (whee! QoS  
for logs!). I am suspecting that this isn't feasible, more of a   
"wouldn't it be cool if..." idea and not worth putting in the doc...

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

For devices that have the concept of multiple severities I would also  
like to see a pruning method that drops the oldest message *of the  
lowest severity* (I'd rather keep old "failed login" messages than  
old "Whoo! Look, A CRC!" messages...)

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

:-)

W

> 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

--
She'd even given herself a middle initial - X - which stood for  
"someone who has a cool and exciting middle name".

    -- (Terry Pratchett, Maskerade)