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

["Romascanu, Dan (Dan)" <[e-mail]>]

I do not know exactly what 'cyber physical devices' means. I think that you mean 'devices connected to the network'. Otherwise, looks fine to me. 

Regards,

Dan


> -----Original Message-----
> From: MIB-DOCTORS [mailto:[e-mail]] On Behalf Of
> Benoit Claise
> Sent: Thursday, July 10, 2014 4:52 PM
> To: Thomas D. Nadeau; Bert Wijnen (IETF)
> Cc: MIB Doctors (E-mail); Alissa Cooper; [e-mail]; Farrel Adrian
> Subject: Re: [MIB-DOCTORS] Change the boilerplate - Kathleen'DISCUSS
> point 2
> 
> 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
> >>
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mib-doctors