Re: [MIB-DOCTORS] Change the boilerplate - Kathleen'DISCUSS point 2

[Stephen Farrell <[e-mail]>]

On 10/07/14 14:52, Benoit Claise wrote:
> Dear all,
> 
> Let's try to address one point at a time, and get closure one by one.
> https://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib/ballot/#kathleen-moriarty
> 
> 
> Kathleen proposes:
> OLD:
> 
>    "The
>    support for SET operations in a non-secure environment without proper
>    protection can have a negative effect on network operations."
> 
> NEW:
> 
>    "The
>    support for SET operations in a non-secure environment without proper
>    protection can have a negative effect on network operations or leave
>    cyber physical devices used by individuals, homes, and business
>    vulnerable to attack."
> 
> 
> I believe this new proposal makes sense. Does anybody object?

s/cyber physical// or replace it with something that does not
use the word cyber which is utterly laden with marketing and
other BS IMO. (Apologies to those of you who partly make a
living from such, which I do understand, but don't have to
do:-) I think we should avoid including such non-technical
terms in things like this. (Think "cloud":-)

S.


> 
> Regards, Benoit
> 
>> On Jul 10, 2014:3:15 AM, at 3:15 AM, Bert Wijnen (IETF)
>> <[e-mail]> wrote:
>>
>>> it is always interesting to see that when we get new ADs that we must
>>> rediscuss this whole topic.
>>     This is precisely one of the things that is broken about the IETF
>> these days, if you ask me: the re-re-re-discussion of topics at the
>> 11:59th hour of a document's progress through the gauntlet.
>>
>>> 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 agree. Not all network operators use a secure management
>> network, but many do.
>>
>>> I do not recall if that was/is the only reason why we agreed on a
>>> SHOULD instead of MUST.
>>     I don't think you can do a MUST here; not everyone uses v3 - in
>> fact, I think if you poll implementations you'll find VERY FEW using v3.
>>
>>     --Tom
>>
>>
>>
>>> 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
>>>>
>>> _______________________________________________
>>> MIB-DOCTORS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mib-doctors
>>>
>