Re: [MIB-DOCTORS] Change the boilerplate

[Benoit Claise <[e-mail]>]

> it is always interesting to see that when we get new ADs that we must 
> rediscuss this whole topic.
Wait, there is more, two DISCUSSes from Kathleen regarding the 
boilerplate (copied the Security ADs):
http://datatracker.ietf.org/doc/draft-ietf-eman-battery-mib/ballot/#kathleen-moriarty
http://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib/ballot/#kathleen-moriarty

I would like to hear first from you guys before providing my opinion.

Regards, Benoit
>
> 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
>>
> .
>