Subject: [MIB-DOCTORS] Fwd: Re: Alissa Cooper's Discuss on draft-ietf-eman-energy-monitoring-mib-12: (with DISCUSS and COMMENT)

From: Benoit Claise <[email-masked]>
Date: Tue, 08 Jul 2014 22:11:45 +0200

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 <[email-masked]>
To: 	Benoit Claise <[email-masked]>, The IESG <[email-masked]>
CC: 	<[email-masked]>, 
<[email-masked]>

Hi Benoit,

On 7/8/14, 1:44 AM, "Benoit Claise" <[email-masked] 
<mailto:[email-masked]>> 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)

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 8 Jul 2014 16:26:15 -0400

Good idea.

On Jul 8, 2014:4:11 PM, at 4:11 PM, Benoit Claise <[email-masked]> wrote:

> 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
> 
> 
> Subject:	Re: Alissa Cooper's Discuss on draft-ietf-eman-energy-monitoring-mib-12: (with DISCUSS and COMMENT)
> CC:	<[email-masked]>, <[email-masked]>
> 
> Hi Benoit,
> 
> On 7/8/14, 1:44 AM, "Benoit Claise" <[email-masked]> wrote:
> 
> Hi Alissa,
> 
> Thanks for your review.
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> 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
> Since this document is essentially a MIB module, your last sentence is covered by 
>         implementations
>         Security Model (USM) [RFC3414] with the AES cipher algorithm
>         [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
> 
> 
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Benoit Claise <[email-masked]>
Date: Wed, 09 Jul 2014 17:58:08 +0200

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

> 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.
>
> so I'm not sure what can be done, but it seems unfortunate.
>
> Alissa
>
>
>

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 10 Jul 2014 09:15:10 +0200

it is always interesting to see that when we get new ADs that we must rediscuss this whole topic.

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:
> Alissa refers to this sentence in the boilerplate at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
>
>     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)
>
>> On 7/8/14, 1:44 AM, "Benoit Claise" <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Hi Alissa,
>>
>>     Thanks for your review.
>>     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
>>
>> 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.
>>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 10 Jul 2014 09:26:16 +0200

> 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
>> 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
>> 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
>>> It seems that the "Security Guidelines for IETF MIB modules" 
>>> receives comment for each MIB module submitted to the IESG.
>>>>     Please refer 
>>>> tohttp://www.ietf.org/iesg/statement/discuss-criteria.html
>>>     Regarding your first sentence, I propose the following text, 
>>> which would be in line with Security Guidelines for IETF MIB
>>>     modules at 
>>>              Security Model (USM) [RFC3414 
>>> <http://tools.ietf.org/html/rfc3414>] with the AES cipher algorithm
>>> RFC 6988 notes the need for privacy protections for stored data, 
>>> which the above text does not speak to, so I still think 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
>>>
>>>
>>>
> .

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 10 Jul 2014 10:00:51 +0200

I can see that for IoT related MIB modules there might be specific privacy concerns that
you might want to describe in a special section. Not sure this should become a standard
section in all MIB related documents though.

My 2 cents.

Bert

On 10/07/14 09:26, Benoit Claise wrote:
> Wait, there is more, two DISCUSSes from Kathleen regarding the boilerplate (copied the Security ADs):

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 10 Jul 2014 08:02:48 +0000

That is what I remember as well. I inherited the boilerplate text from Bert, and during my tenure as AD we had at least one round of text revision (maybe two?). AFAICT this part did not change for the reasons described by Bert. Another reason may have been that 3410 describes a number of security features, each of them may use different cryptographic algorithms, and not all are mandatory to implement (and of course to deploy) in order to obtain a secure solution.

Regards,

Dan

> -----Original Message-----
> From: MIB-DOCTORS [mailto:[email-masked]] On Behalf Of
> Bert Wijnen (IETF)
> Sent: Thursday, July 10, 2014 10:15 AM
> To: Benoit Claise; MIB Doctors (E-mail)
> Cc: Adrian Farrel; 'Alissa Cooper'
> Subject: Re: [MIB-DOCTORS] Change the boilerplate
> 
> 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.
> 
> >     It is a little disconcerting that use of SNMPv3 is provided as a SHOULD-
> level requirement without discussion of deployment
> >     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
> >> Subject: 	Re: Alissa Cooper's Discuss on draft-ietf-eman-energy-
> monitoring-mib-12: (with DISCUSS and COMMENT)
> >>     Regarding your first sentence, I propose the following text, which would
> be in line with Security Guidelines for IETF MIB
> >>     modules at
> >> which the above text does not speak to, so I still think a reference to RFC
> >> 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
> >>
> >>
> >>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Jul 2014 09:35:13 +0100

> section in all MIB related documents though.

Yep, that's what I thought too. OTOH, its not clear that
boilerplate is really the right thing here - one common
way to handle privacy concerns is data minimisation which
here could map to not exposing an element or to only
exposing aggregate information rather than fine grained
values. Those are things that have to be thought about
by the MIB developers and can't just be handled via
current SNMP security since once the data is out there
the privacy breach has happened.

Cheers,
S.

PS: I'll add the above as a comment to the ballot later.

>>> dedicated (secure) networks
>>>>     energy use, but not if (2) my ISP is using it to monitor the
>>>> same thing. The text quoted above basically  endorses unauthorized
>>>>> 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.
>>>>>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 10 Jul 2014 09:01:44 -0400

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

> 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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 10 Jul 2014 15:52:24 +0200

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Jul 2014 14:55:52 +0100

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

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 10 Jul 2014 13:56:14 +0000

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

> Benoit Claise
> Sent: Thursday, July 10, 2014 4:52 PM
> To: Thomas D. Nadeau; Bert Wijnen (IETF)
> Cc: MIB Doctors (E-mail); Alissa Cooper; [email-masked]; Farrel Adrian
> Subject: Re: [MIB-DOCTORS] Change the boilerplate - Kathleen'DISCUSS
> point 2
> 
> Dear all,
> 
> > 	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.
> >
> >> dedicated (secure) networks for the network management systems, and
> so that would work under a SHOULD.
> > 	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
> >>
> >>>     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
> >>>> which the above text does not speak to, so I still think a reference to
> RFC 6988 would add value here.
> >>>>
> scenarios
> >>>> 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
> >>>>
> >>>>
> >>>>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 10 Jul 2014 16:13:08 +0200

Dear all,

The email below refers to Alissa's DISCUSS
See 
http://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/ballot/#alissa-cooper

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

 From the discussion (Dan andBert's feedback, on top of mine) , it seems 
that there are valid reasons to keep a SHOULD here in the generic 
boilerplate.

So what next?
- Should we justify the reasons in the boiler plate
- Should we  give some freedom in the boilerplate?

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

         <if there are use cases where a MUST is required, described 
them here>

   Now, I hope it will not be abused by Security ADs, requesting a MUST 
for every single MIB module.
- Something else?
- Stop writing MIB modules :-)

Regards, Benoit

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 10 Jul 2014 10:22:17 -0400

On Thu, Jul 10, 2014 at 9:56 AM, Romascanu, Dan (Dan) <[email-masked]>
wrote:

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

I think I'm okay with 'devices connected to the network'.  Normally I would
agree to nix the 'cyber' in cyber physical, but it is the term used for all
of the stuff related to industrial control systems that are moving into the
networking space.  It lumps in the IoT devices, includes energy and other
industrial control systems.  It's the term being used to cover that space,
industrial control system doesn't go far enough.  Correct me if I am wrong
here, but I believe that is the right term that the industry will
understand.  But I guess if you guys have trouble with it, others not in
that space will too.

Thanks,
Kathleen

> these
> > >> I do not recall if that was/is the only reason why we agreed on a
> SHOULD
> > instead of MUST.
> fact, I
> > >>>         privacy via the User-based Security Model (USM) [RFC3414]
> with the
> > AES
> SHOULD-
> made
> same thing.
> whereas
> receives
> draft-ietf-eman-energy-
> > >>>> To:      Benoit Claise <[email-masked]>, The IESG <[email-masked]
> >
> > >>>>>     When responding, please keep the subject line intact and reply
> to
> > all
> > >>>>>     energy and power monitoring. I would suggest something along
> the
> > lines of
> > >>>>>     the following:
> > >>>>>
> which
> > >>>>         Some of the readable objects in this MIB module (i.e.,
> objects with
> > a
> > >>>>         to even encrypt the values of these objects when sending
> them
> > over
> > >>>>         Access to the content of the eoPowerStateTable,
> eoEnergyTable,
> > and
> docs, so
> > >>>>              "New Assignments (and potential deprecation) to Power
> State
> > Sets
> > >>>>              are specified in [EMAN-FMWK], and will, as a
> consequence,
> > update the

-- 

Best regards,
Kathleen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Jul 2014 17:09:10 +0200

> I believe this new proposal makes sense. Does anybody object?

Change to "or leave devices vulnerable to attack". Since we talk about
boilerplate, the text needs to be generic.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Jul 2014 17:11:38 +0200

> - Stop writing MIB modules :-)

Do nothing, re-discuss this every other year. ;-)

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 10 Jul 2014 15:32:51 +0000

The way I always understood the boilerplate is that it provided a minimal mandatory text (and thus a minimal set of advice) for the Security Considerations sections of the MIB documents. Authors can always add security related content according to the specific of the work, and this is what authors have done many times. 

Regards,

Dan

> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Thursday, July 10, 2014 6:28 PM
> To: Juergen Schoenwaelder; Benoit Claise
> Cc: Romascanu, Dan (Dan); Bert Wijnen (IETF); MIB Doctors (E-mail); Adrian
> Farrel; [email-masked]
> Subject: Re: [MIB-DOCTORS] Change the boilerplate - Alissa's DISCUSS
> 
> Perhaps rather than re-discussing the boilerplate, we could discuss what the
> purpose of the boilerplate is.
> 
> If the purpose of the boilerplate is to provide text that authors can look at
> and say, “yes, in the case of this document, the boilerplate fully covers the
> security considerations of the MIB being specified,” then I think it’s a great
> thing to have. If the purpose of the boilerplate is to keep any additional
> security consideration not covered in the boilerplate from being addressed in
> a MIB document, then it seems overly constricting.
> 
> Security considerations change over time. I’m assuming that home/device
> energy monitoring wasn’t really top of mind when SNMP was developed or
> when the boilerplate was originally written. So it’s not surprising that new
> security issues are arising that aren’t addressed within the boilerplate. If the
> boilerplate were just a suggestion of text and not a limitation on what can be
> documented, we could accommodate the changing times fairly easily.
> 
> In my original DISCUSS, all I suggested was text that could be provided in
> addition to the boilerplate:
> 
> 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.”
> 
> I have not had time to look at Stephen’s comments but I agree with him and
> Bert that adding a special section or extra text to discuss privacy concerns in
> the IoT-related documents is the right way to go.
> 
> Alissa
> 
> 
> On 7/10/14, 8:11 AM, "Juergen Schoenwaelder"
> <[email-masked]> wrote:
> 
> >> The email below refers to Alissa's DISCUSS See
> >>
> >>bal
> >>lot/#alissa-cooper
> >> with the AES
> >> From the discussion (Dan andBert's feedback, on top of mine) , it
> >> seems that there are valid reasons to keep a SHOULD here in the
> >> generic boilerplate.
> >>
> >> So what next?
> >> with the AES
> >>   Now, I hope it will not be abused by Security ADs, requesting a
> >> MUST for every single MIB module.
> >> - Something else?

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 10 Jul 2014 11:44:07 -0400

On Thu, Jul 10, 2014 at 11:32 AM, Romascanu, Dan (Dan) <[email-masked]>
wrote:

> The way I always understood the boilerplate is that it provided a minimal
> mandatory text (and thus a minimal set of advice) for the Security
> Considerations sections of the MIB documents. Authors can always add
> security related content according to the specific of the work, and this is
> what authors have done many times.
>
> OK, I think the problem we ran into this time is that three drafts have
additional considerations that are not covered in the template.  In my
discuss, I suggested an optional section to be included and was trying some
other security considerations to tie it into Alissa's text for IoT, for
both privacy and security.

I appreciate the addition of text in the template discussed in another
thread.

Thanks,
Kathleen

> this

-- 

Best regards,
Kathleen

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 10 Jul 2014 08:27:52 -0700

Perhaps rather than re-discussing the boilerplate, we could discuss what
the purpose of the boilerplate is.

If the purpose of the boilerplate is to provide text that authors can look
at and say, “yes, in the case of this document, the boilerplate fully
covers the security considerations of the MIB being specified,” then I
think it’s a great thing to have. If the purpose of the boilerplate is to
keep any additional security consideration not covered in the boilerplate
from being addressed in a MIB document, then it seems overly constricting.

Security considerations change over time. I’m assuming that home/device
energy monitoring wasn’t really top of mind when SNMP was developed or
when the boilerplate was originally written. So it’s not surprising that
new security issues are arising that aren’t addressed within the
boilerplate. If the boilerplate were just a suggestion of text and not a
limitation on what can be documented, we could accommodate the changing
times fairly easily.

occur
with proper authorization.”

I have not had time to look at Stephen’s comments but I agree with him and
Bert that adding a special section or extra text to discuss privacy
concerns in the IoT-related documents is the right way to go.

Alissa

---

From: "David Harrington" <[email-masked]>
Date: Thu, 10 Jul 2014 23:25:04 -0400

The design of IETF management is that the data models are separate from the
protocols that carry the data.
This is based on the precedent set by RFC1052, where the IAB made the
deliberate decision to separate them so that the temporary simple protocol
SNMP could be replaced by the more full-featured CMIP when it was ready.

A MIB module might be used with SNMPv3 (the recommended approach), or
SNMPv1/v2 (for secure networks, or at the administrator's discretion for
other reasons).
A MIB module might be used with a newer version of SNMP, such as SNMPv4,
should we ever choose to develop a later version.
A MIB module might also be used with other protocols, such as IPFIX or
Netconf or protocols standardized by other SDOs, and so on, when
appropriate.
A MIB module might also be used with other protocols, such as a proprietary
protocol used within a closed network.
So SHOULD is appropriate. 

David Harrington
[email-masked]
+1-603-828-1401
> Sent: Thursday, July 10, 2014 3:15 AM
by
> >         to the SNMPv3 standard MUST include full support for
authentication
the
SHOULD-
> >     energy use, but not if (2) my ISP is using it to monitor the same
thing. The
> >     energy monitoring if the provider does not support SNMPv3, whereas
it
> 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
<eman-
> [email-masked]>
> >>     Regarding your first sentence, I propose the following text, which
would
> >>         MAX-ACCESS other than not-accessible) may be considered
sensitive
> or
is
> covered by
> the above text does not speak to, so I still think a
SHOULD-
> 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
so I'm
> >>              "New Assignments (and potential deprecation) to Power
State Sets
> >>              are specified in [EMAN-FMWK], and will, as a consequence,
update

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 10 Jul 2014 23:29:49 -0400

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
[email-masked]
+1-603-828-1401
> Sent: Thursday, July 10, 2014 9:52 AM
these
SHOULD
fact, I
the
SHOULD-
> >>>     energy use, but not if (2) my ISP is using it to monitor the same
thing.
> >>> off the SHOULD: an older SNMP version in a closed network,  or a
private
draft-ietf-eman-energy-
to
which
objects with
> sensitive or
eoEnergyTable,
> >>>>     Since this document is essentially a MIB module, your last
sentence is
which
SHOULD-
text
docs, so
> >>>>>              are specified in [EMAN-FMWK], and will, as a
consequence, the
State
consequence,

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 10 Jul 2014 23:31:47 -0400

+1 
;-)

David Harrington
[email-masked]
+1-603-828-1401

> Juergen Schoenwaelder
> Sent: Thursday, July 10, 2014 11:12 AM
> To: Benoit Claise
> Cc: MIB Doctors (E-mail); 'Alissa Cooper'; [email-masked]; Adrian
> Farrel

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 10 Jul 2014 23:34:14 -0400

" adding a special section or extra text to discuss privacy
concerns in the IoT-related documents is the right way to go."

+1

David Harrington
[email-masked]
+1-603-828-1401

> Alissa Cooper
> Sent: Thursday, July 10, 2014 11:28 AM
> Cc: Adrian Farrel; [email-masked]; MIB Doctors (E-mail)
> >>http://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-
> mib/bal
> >>lot/#alissa-cooper
> >>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 11 Jul 2014 10:33:21 -0400

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 <[email-masked]> wrote:

> > days, if you ask me: the re-re-re-discussion of topics at the 11:59th
> hour
> of a
> with
> > >>>     security and utility might be reasonable if (1) I'm using an
> older
> SNMP
> > >>>>>     Section 11 is missing a discussion of the privacy
> considerations
> of
> > >>>>>     discussed in Section 9 of RFC 6988 and monitoring of
> individuals
> and
> The

-- 

Best regards,
Kathleen