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

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 1 Jul 2008 10:50:37 -0400

The text in mib-security.html uses parentheses for parenthetical
remarks. The text in the document being reviewed has replaced
those parentheses with double quotes for some reason. This change
completely garbles the text and is probably the cause of the
confusion. Changing back to parentheses should solve the problem.

Thanks,

Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Romascanu, Dan (Dan)
Sent: Sunday, June 29, 2008 7:09 AM
To: Scott G. Kelly; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: MIB Doctors
Subject: Re: [secdir] secdir review of draft-ietf-pwe3-tdm-mib-10

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

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors