[secdir] SecDir Review for draft-ietf-trill-oam-mib-06

[Yoav Nir <[e-mail]>]

Hi.

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.

TL;DR: The document is ready with nits.

The document contains a MIB for operations, administration, and maintenance (OAM) of TRILL. As is common for such documents, 34 of its 45 pages is section 7 ("Definition of the TRILL OAM MIB module”). Being an expert on neither TRILL nor MIBs I have mostly skipped that section.

Usually with MIB documents, the security considerations for the protocol (several TRILL RFCs in this case) are in the protocol documents, while the security considerations for SNMP are in the SNMP document (RFC 3410). The MIB document only points data that is sensitive (in terms of privacy or information leakage), and data which is dangerous in the sense that falsified or modified data could lead to damage. 

In this document the Security Considerations section does a good job of explaining that modified data can lead to changes in routing and potentially to denial of service. The second paragraph is a little hand-wavy for my taste: 

   There are number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-create. Such objects may be
   considered sensitive or vulnerable in some network environments.

What network environment? Why in some but not in others? The third paragraph is similar:

   Some of the readable objects in this MIB module (objects with a MAC-
   ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.

The section concludes with text that looks very familiar from other MIB documents, basically saying that you should use SNMPv3 because it has protections whereas earlier versions don’t. It is also important to have proper access control rules. One nit is that the section says that the cryptographic mechanisms in SNMPv3 provide “privacy”. As of late we tend to use that word for the protection of information about humans, not so much about link status.

A few general nits:
 - In most documents that I see, the content of sections 1-4 is in a single section.
 - OAM is not expanded before first use.
 - The MODULE-IDENTITY has “TBD” for ORGANIZATION and authors’ names in CONTACT-INFO. looking at a few recent MIB documents, the working group is usually given as ORGANIZATION and its mailing list is given as contact info.

Yoav