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.

The document defines a MIB module and I have not spent time reviewing
the MIB module itself. Instead, I have been focusing on the security
considerations section and I believe the security considerations
section needs some improvement in order to comply to RFC 4181 section
3.4 and the current MIB module security template. Let me go through
the security considerations in draft-ietf-ospf-ospfv3-mib-13.txt:

  6. Security Considerations
  
     There are a number of management objects defined in this MIB that
     have a MAX-ACCESS clause of read-write and/or read-create. Such
     objects may be considered sensitive or vulnerable in some network
     environments.  The support for SET operations in a non-secure
     environment without proper protection can have a negative effect on
     network operations.

Up to here, this is standard boilerplate text. What is missing is next
is the discussion of the sensitivity / vulnerability of the objects /
tables. See RFC 4181 section 3.4 and the boilerplate text posted at
<

http://www.ops.ietf.org/mib-security.html

>.

     It is recommended that attention be specifically given to
     implementing the MAX-ACCESS clause in objects in scenarios
     that DO NOT use SNMPv3 strong security (i.e. authentication and
     encryption). Extreme caution must be used to minimize the risk of
     cascading security vulnerabilities when SNMPv3 strong security is
     not used. When SNMPv3 strong security is not used, these objects
     should have access of read-only, not read-create.

This is new text and I dislike it because it recommends to not
implement objects as writable objects. I believe this is not what we
want to achieve; we want writable objects implemented since we want
operators to decide via access control configuration rules which
objects are accessible to whom. Having the implementors take the
decision by implemting them read-only makes it impossible for
operators to do what they might want to do.

     SNMPv1 by itself is not a secure environment. Even if the network
     itself is secure (for example by using IPsec), even then, there is
     no control as to who on the secure network is allowed to access and
     GET/SET (read/change/create/delete) the objects in this MIB.
  
     It is recommended that the implementers consider the security
     features as provided by the SNMPv3 framework. Specifically, the use
     of the User-based Security Model RFC 3414 [RFC3414] and the
     View-based Access Control Model RFC 3415 [RFC3415] is recommended.
  
     It is then a customer/user responsibility to ensure that the SNMP
     entity giving access to an instance of this MIB, is properly
     configured to give access to the objects only to those principals
     (users) that have legitimate rights to indeed GET or SET
     (change/create/delete) them.

The text in these three paragraphs does not match the current
boilerplate and I think it is also wrong since it ignores SNMPv2c and
SNMPv3 in noAuth/noPriv mode. This text is also misleading since you
can have access control with SNMPv1 - all you miss in that scenario is
a secure binding to an authenticated principal. So I suggest to use
the current boilerplate text.

I am attaching a boilerplate template generated by smidump. Since the
MIB module is large, you end up with a long list of objects and it
likely makes sense to group them and to discuss things at the level of
table rows instead of individual objects or so (smidump is currently
not smart enough to do this). Take this as a starting point if you
want.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <

http://www.jacobs-university.de/

>