Re: [secdir] Review of draft-ietf-opsawg-syslog-alarm-02

["Sharon Chisholm" <[e-mail]>]

Hi

Thanks for the review.

Rate limiting alarms is an interesting point and agree when you said
"A sentence or two in the security considerations section of this draft
mentioning the alarm flooding issue and giving a more explicit reference
to the rate limiting discussion in RFC 5424 would suffice"
We can add that.

I'm at a bit of a loss as to how better to represent 'conditional
mandatory' fields. Suggestions welcome.

Sharon

-----Original Message-----
From: Rob Austein [mailto:[e-mail]] 
Sent: Tuesday, August 25, 2009 12:30 PM
To: [e-mail]; [e-mail]
Cc: [e-mail];
[e-mail]
Subject: Review of draft-ietf-opsawg-syslog-alarm-02

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This draft proposes an encoding of certain elements from the RFC 3877
Alarm MIB as "structed data" within the (IETF-flavored RFC 5424) syslog
protocol, in effect using syslog as a transport for data semantically
equivilent to SNMP traps.  This draft only documents encodings for a
small subset of the data available in the Alarm MIB, presumably this was
not accidental (the Alarm MIB is a complex beast).

The security considerations section of this draft covers the obvious
issue (potential disclosure of sensitive information to unknown
parties), but does not discuss rate limiting except by reference to RFC
5424's security considerations.  The discussion of alarm throttling in
the Alarm MIB may be relevant here: it requires a two second gap between
repeated traps of the same type to reduce the risk of alarm flooding,
and warns that even with this restriction there's still a risk of alarm
flooding when multiple alarms of different types are active.  A sentence
or two in the security considerations section of this draft mentioning
the alarm flooding issue and giving a more explicit reference to the
rate limiting discussion in RFC 5424 would suffice, although a more
detailed treatment would not be a bad thing if the WG has something more
to say on the topic.

Minor editorial note: I found the repeated phrasing "MUST be
implemented" confusing when used in reference to optional fields.  I
understand the difference between "MUST be implemented" and "MUST be
used," but the intent wasn't obvious until I re-read the normative text
after reading the examples.