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

[Yoav Nir <[e-mail]>]

Generally you wait to the end of IETF last call and then fix whatever nits you're going to fix. It's up to you, your shepherd (Donald), and your AD.

Contact info should be fixed because all authors need to confirm to the RFC editor that they are ok with the edits. But that is at least two months away.

Regards,

Yoav

Sent from my Windows Phone 

-----Original Message-----
From: "Deepak Kumar (dekumar)" <[e-mail]>
Sent: ‎8/‎10/‎2015 5:07
To: "Yoav Nir" <[e-mail]>; "secdir" <[e-mail]>; "The IESG" <[e-mail]>; "[e-mail]" <[e-mail]>
Subject: Re: SecDir Review for draft-ietf-trill-oam-mib-06

Hi Yoav,


Thanks for review and comments. Please advise if we need to fix the nits
and comments and upload new version as I am not sure about procedure of
fixing comments during last call.

Tissa has moved out of Cisco and working in another Company, I don¹t have
privy of his new contact so I will contact him to get new contact and
update the document also.

Thanks,
Deepak

On 8/8/15, 2:18 PM, "Yoav Nir" <[e-mail]> wrote:

>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
>