Re: [MIB-DOCTORS] Change the boilerplate

["Bert Wijnen (IETF)" <[e-mail]>]

it is always interesting to see that when we get new ADs that we must rediscuss this whole topic.

But yes, there are/were implementations/deployments where one uses dedicated (secure) networks
for the network management systems, and so that would work under a SHOULD.

I do not recall if that was/is the only reason why we agreed on a SHOULD instead of MUST.

Bert

On 09/07/14 17:58, Benoit Claise wrote:
> MIB doctors,
>
> Let me focus the discussion a little bit.
> Alissa refers to this sentence in the boilerplate at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
>
>         Implementations SHOULD provide the security features described by the
>         SNMPv3 framework (see [RFC3410]), and implementations claiming compliance
>         to the SNMPv3 standard MUST include full support for authentication and
>         privacy via the User-based Security Model (USM) [RFC3414] with the AES
>         cipher algorithm [RFC3826].
>
>
> Alissa's feedback is:
>
>     It is a little disconcerting that use of SNMPv3 is provided as a SHOULD-level requirement without discussion of deployment
>     scenarios and regardless of the sensitivity of the data being made available by any new MIB. For example, the tradeoffs between
>     security and utility might be reasonable if (1) I’m using an older SNMP version on my closed home network to monitor my own
>     energy use, but not if (2) my ISP is using it to monitor the same thing. The text quoted above basically  endorses unauthorized
>     energy monitoring if the provider does not support SNMPv3, whereas it seems like what we would want to be saying is that in
>     cases like (2) SNMPv3 is required.
>
> Can one of the old timers (who was part of the discussion) explain the SHOULD rational? Personally, I can see two use cases in favor
> off the SHOULD: an older SNMP version in a closed network,  or a private data communication network dedicated to network management
> with special protection out of SNMP (like encrypted tunnel)
>
> Should we now modify this sentence to say?
>
>     MUST provide the security features described by the
>     SNMPv3 framework (see [RFC3410])
>
> Regards, Benoit
>
>> MIB doctors,
>>
>> It seems that the "Security Guidelines for IETF MIB modules" receives comment for each MIB module submitted to the IESG.
>> Is it time to modify it, or are we redoing the same discussions over and over?
>>
>> Regards, Benoit
>>
>>
>> -------- Original Message --------
>> Subject: 	Re: Alissa Cooper's Discuss on draft-ietf-eman-energy-monitoring-mib-12: (with DISCUSS and COMMENT)
>> Date: 	Tue, 8 Jul 2014 13:02:50 -0700
>> From: 	Alissa Cooper <[e-mail]>
>> To: 	Benoit Claise <[e-mail]>, The IESG <[e-mail]>
>> CC: 	<[e-mail]>, <[e-mail]>
>>
>>
>>
>> Hi Benoit,
>>
>> On 7/8/14, 1:44 AM, "Benoit Claise" <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     Hi Alissa,
>>
>>     Thanks for your review.
>>>     Alissa Cooper has entered the following ballot position for
>>>     draft-ietf-eman-energy-monitoring-mib-12: Discuss
>>>
>>>     When responding, please keep the subject line intact and reply to all
>>>     email addresses included in the To and CC lines. (Feel free to cut this
>>>     introductory paragraph, however.)
>>>
>>>
>>>     Please refer tohttp://www.ietf.org/iesg/statement/discuss-criteria.html
>>>     for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>>     The document, along with other ballot positions, can be found here:
>>>     http://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/
>>>
>>>
>>>
>>>     ----------------------------------------------------------------------
>>>     DISCUSS:
>>>     ----------------------------------------------------------------------
>>>
>>>     Section 11 is missing a discussion of the privacy considerations of
>>>     energy and power monitoring. I would suggest something along the lines of
>>>     the following:
>>>
>>>     "In certain situations, energy and power monitoring can reveal sensitive
>>>     information about individuals' activities and habits. Implementors of
>>>     this specification should use appropriate privacy protections as
>>>     discussed in Section 9 of RFC 6988 and monitoring of individuals and
>>>     homes should only occur with proper authorization."
>>
>>     Regarding your first sentence, I propose the following text, which would be in line with Security Guidelines for IETF MIB
>>     modules at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
>>
>>         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
>>         control even GET and/or NOTIFY access to these objects and possibly
>>         to even encrypt the values of these objects when sending them over
>>         the network via SNMP.  These are the tables and objects and their
>>         sensitivity/vulnerability:
>>
>>         Access to the content of the eoPowerStateTable, eoEnergyTable, and
>>         eoACPwrAttributesTable MIB tables can reveal sensitive
>>         information about individuals' activities and habits
>>
>> Sounds good to me.
>>
>>
>>     Since this document is essentially a MIB module, your last sentence is covered by
>>
>>              implementations
>>              claiming compliance to the SNMPv3 standard MUST include full
>>              support for authentication and privacy via the User-based
>>              Security Model (USM) [RFC3414  <http://tools.ietf.org/html/rfc3414>] with the AES cipher algorithm
>>              [RFC3826  <http://tools.ietf.org/html/rfc3826>].
>>
>> RFC 6988 notes the need for privacy protections for stored data, which the above text does not speak to, so I still think a
>> reference to RFC 6988 would add value here.
>>
>> It is a little disconcerting that use of SNMPv3 is provided as a SHOULD-level requirement without discussion of deployment
>> scenarios and regardless of the sensitivity of the data being made available by any new MIB. For example, the tradeoffs between
>> security and utility might be reasonable if (1) I’m using an older SNMP version on my closed home network to monitor my own energy
>> use, but not if (2) my ISP is using it to monitor the same thing. The text quoted above basically  endorses unauthorized energy
>> monitoring if the provider does not support SNMPv3, whereas it seems like what we would want to be saying is that in cases like
>> (2) SNMPv3 is required.
>>
>> I understand that this is basically boilerplate language for MIB docs, so I’m not sure what can be done, but it seems unfortunate.
>>
>> Alissa
>>
>>
>>
>>>     ----------------------------------------------------------------------
>>>     COMMENT:
>>>     ----------------------------------------------------------------------
>>>
>>>     Section 12.1:
>>>     "New Assignments (and potential deprecation) to Power State Sets
>>>              shall be administered by IANA and the guidelines and procedures
>>>              are specified in [EMAN-FMWK], and will, as a consequence, the
>>>              IANAPowerStateSet Textual Convention should be updated."
>>>
>>>     Not sure what this sentence means.
>>     Good catch.
>>     NEW:
>>
>>              "New Assignments (and potential deprecation) to Power State Sets
>>              shall be administered by IANA and the guidelines and procedures
>>              are specified in [EMAN-FMWK], and will, as a consequence, update the
>>              IANAPowerStateSet Textual Convention."
>>
>>
>>     Regards, Benoit (as a document author)
>>
>>
>>
>>
>>
>> _______________________________________________
>> MIB-DOCTORS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mib-doctors
>
>
>
> _______________________________________________
> MIB-DOCTORS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>