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

[Kathleen Moriarty <[e-mail]>]

David,

Do you have alternate text to suggest?  The point was to expand the
possibilities beyond just effecting the network.  Attacks exploiting
vulnerabilities, other than DoS or similar attacks, are not targeting
network disruption.  There is a lot of information that could be gathered
that privacy implications (individuals, homes, businesses), could effect
business (reconnaissance leading to simple attacks or even espionage, etc.
- this is very real), etc.

Thanks.


On Thu, Jul 10, 2014 at 11:29 PM, ietfdbh <[e-mail]> wrote:

> I think the new text is wordier, but doesn't really say more than the
> original.
> The devices being vulnerable to attack can have a negative effect on
> network
> behavior.
> I feat that readers of the wordier text would "tune out".
>
> Rather than putting more details into the boilerplate, concerns should be
> detailed in the security considerations, including an explanation of which
> objects are sensitive, and how they increase vulnerability or impact
> network
> behavior.
>
> David Harrington
> [e-mail]
> [phone]
> > -----Original Message-----
> > From: MIB-DOCTORS [mailto:[e-mail]] On Behalf Of
> > Benoit Claise
> > Sent: Thursday, July 10, 2014 9:52 AM
> > 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
>
>


-- 

Best regards,
Kathleen