Skip to main content

Last Call Review of draft-ietf-opsawg-syslog-msg-mib-
review-ietf-opsawg-syslog-msg-mib-secdir-lc-nystrom-2009-07-22-00

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
I-D last updated 2009-07-22
Completed reviews Secdir Last Call review of -?? by Magnus Nyström
Assignment Reviewer Magnus Nyström
State Completed
Request Last Call review on draft-ietf-opsawg-syslog-msg-mib by Security Area Directorate Assigned
Completed 2009-07-22
review-ietf-opsawg-syslog-msg-mib-secdir-lc-nystrom-2009-07-22-00
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