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

Rob Austein <sra@hactrn.net> Tue, 25 August 2009 16:30 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B353A6AFE; Tue, 25 Aug 2009 09:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1bI2ztVoliU; Tue, 25 Aug 2009 09:30:39 -0700 (PDT)
Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) by core3.amsl.com (Postfix) with ESMTP id B4A1D3A6B32; Tue, 25 Aug 2009 09:30:39 -0700 (PDT)
Received: from orodruin.hactrn.net (c-66-30-16-106.hsd1.ma.comcast.net [66.30.16.106]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "orodruin.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id F0765BA9E; Tue, 25 Aug 2009 16:30:12 +0000 (UTC)
Received: from orodruin.hactrn.net (localhost [IPv6:::1]) by orodruin.hactrn.net (Postfix) with ESMTP id B6A8440C5; Tue, 25 Aug 2009 12:30:13 -0400 (EDT)
Date: Tue, 25 Aug 2009 12:30:13 -0400
From: Rob Austein <sra@hactrn.net>
To: iesg@ietf.org, secdir@ietf.org
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090825163013.B6A8440C5@orodruin.hactrn.net>
Cc: draft-ietf-opsawg-syslog-alarm@tools.ietf.org, opsawg-chairs@tools.ietf.org
Subject: [secdir] Review of draft-ietf-opsawg-syslog-alarm-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2009 16:30:40 -0000

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.