Skip to main content

Last Call Review of draft-ietf-opsawg-syslog-msg-mib-

Request Review of draft-ietf-opsawg-syslog-msg-mib
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-07-13
Requested 2009-07-03
Authors Alexander Clemm , Jürgen Schönwälder , Anirban Karmakar
Draft last updated 2009-07-22
Completed reviews Secdir Last Call review of -?? by Magnus Nystrom
Assignment Reviewer Magnus Nystrom
State Completed Snapshot
Review review-ietf-opsawg-syslog-msg-mib-secdir-lc-nystrom-2009-07-22
Completed 2009-07-22
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 document defines a MIB module for use when mapping SYSLOG messages to 

SNMP notifications.


- In the SYSLOG-MSG-MIB module, the syslogMsgSDTable is defined with the

  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