Subject: Re: [MIB-DOCTORS] secdir review of draft-ietf-pwe3-tdm-mib-10

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Jun 2008 13:08:49 +0200

Scott (and other SECDIR reviewers),

Much if not all the text that you describe like having a 'surrounding
sentence structure a bit cumbersome' is being taken from
http://www.ops.ietf.org/mib-security.html which provides guidelines
agreed by the OPS and SEC areas and which authors of the MIB documents
must fully comply to according to Section 6 of RFC 4181. If you believe
that there is a need to improve or amend the guidelines we need to
engage in an effort to revise those. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Scott G. Kelly
> Sent: Friday, June 27, 2008 8:28 AM
> To: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: secdir review of draft-ietf-pwe3-tdm-mib-10
> 
> 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.
> 
> disclaimer: I have not been following the PWE3 wg, and I am 
> not a mib doctor.
> 
> This document defines a MIB for pseudo wire encapsulation of 
> structured or unstructured time division multiplexed (TDM) 
> circuits over a packet switched network.
> 
> From a security perspective, I see no issues with this 
> document. The security considerations section makes clear 
> that the there is information in the MIB which may be 
> considered sensitive, and that SNMPv{1,2} does not provide 
> adequate security. It also recommends the use of SNMPv3 with 
> granular role-based access controls to limit access to 
> sensitive elements and provide confidentiality where required.
> 
> I have a few editorial comments:
> 
> - I would suggest adding a sentence to the introduction which 
> articulates the background the reader is assumed to have, for 
> example, what RFCs they are expected to be conversant with, 
> in order to understand the content of this document.
> 
> - TDM should be expanded with first use
> 
> - there are several quoted phrases in the security 
> considerations section, and I found these and the surrounding 
> sentence structure a bit cumbersome. Below are some examples:
> 
>    Some of the readable objects in this MIB module "i.e., 
> objects with a
>    MAX-ACCESS other than not-accessible" may be considered 
> sensitive or
>    vulnerable in some network environments.  It is thus important to
> 
> -----
> 
>    SNMP versions prior to SNMPv3 did not include adequate security.
>    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 module.
> 
> -----
> 
>    It is RECOMMENDED that implementers consider the security 
> features as
>    provided by the SNMPv3 framework "see [RFC3410], section 8",
>    including full support for the SNMPv3 cryptographic mechanisms "for
>    authentication and privacy".
> 
> -----
> 
>    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 have legitimate
>    rights to indeed GET or SET "change/create/delete" them.
> 
> -----
> 
> I think these sections could use some editorial work to make 
> them more comprehensible.
> 
> --Scott
> 
> 
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors