Re: [secdir] SecDir review of draft-ietf-opsawg-syslog-msg-mib-04

Hi,

MIBs arewritten using SMIv2. I don't believe SMIv2 supports the range
on a SEQUENCE.

As Dan pointed out, the recommendation of SNMP versions is boilerplate
that was worked out between Security and OPS ADs.

dbh 

> -----Original Message-----
> From: secdir-bounces@ietf.org 
> [mailto:secdir-bounces@ietf.org] On Behalf Of Magnus Nyström
> Sent: Monday, July 20, 2009 11:30 AM
> To: iesg@ietf.org; secdir@ietf.org; secdir-secretary@mit.edu; 
> j.schoenwalder@jacobs-university.de; alex@cisco.com; 
> akarmaka@cisco.com; sob@harvard.edu; ted.a.seely@sprint.com
> Subject: [secdir] SecDir review of
draft-ietf-opsawg-syslog-msg-mib-04
> 
> 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.
> 
> Background
> ----------
> This document defines a MIB module for use when mapping 
> SYSLOG messages to 
> SNMP notifications.
> 
> Comments
> --------
> 
> - In the SYSLOG-MSG-MIB module, the syslogMsgSDTable is 
> defined with the
>    syntax
> 
>    SEQUENCE OF SyslogMsgSDEntry
> 
>    Would it make sense to restrict this with an upper (and 
> perhaps lower)
>    bound to reduce the risk of either non-interop or 
> potential attacks?
>    E.g. like
> 
>    SEQUENCE SIZE (1..<upper-bound>) OF SyslogMsgSDEntry
> 
>    where <upper-bound> is replaced with something reasonable?
> 
> - (Editorial) In the Security Considerations section, there 
> is a paragraph
>    recommending against deployment of earlier versions of SNMP. For
>    clarity and correctness ("NOT RECOMMENDED" is not a key 
> word) I suggest
>    this paragraph is rewritten to (several changes in the below):
> 
>     Further, SNMP versions prior to SNMPv3 SHOULD NOT be deployed.
>     Instead, SNMPv3 with enabled cryptographic security 
> SHOULD be deployed.
>     It is then a customer/operator responsibility to ensure 
> that the SNMP
>     entity giving access to an instance of this MIB module is
properly
>     configured to give access to the objects only to those
principals
>     (users) that indeed have legitimate rights to GET or SET
>     (change/create/delete) them.
> 
> -- Magnus
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> 