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

[Benoit Claise <[e-mail]>]

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?

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