I
        reviewed this document as part of the security directorate's
        ongoing effort to
        review all IETF documents being processed by the IESG.

  

These comments were written
        primarily for the
        benefit of the security area directors.

 
        

Document editors and WG chairs should treat these
        comments just like any
        other last call comments. Since I am not a MIB expert, my
        comments are strictly
        related to the security-relevant aspects of this document.




 




This
        document, as its name
        implies, defines a MIB for energy management devices. Given
        increasing concern
        over security in the so-called “cyber-physical” realm, a MIB for
        such devices
        clearly merits scrutiny. Also, to the extent that such devices
        (e.g., meters)
        might be associated with residences, there are personal privacy
        issues that
        ought to be addressed, in the PERPASS era.




 




The document
        is clearly
        written; my compliments to the authors in that regard. The one
        odd thing I
        noted was that Sections 11.1 and 11.2 appear between Sections 6
        and 7! I think
        this was a cut and paste error that is easily remedied.




 




The Security
        Considerations section (7) is about one-half page in length. I
        have several
        concerns with the text here.




 




First, the
        text says “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.” This seems to be an understatement. I’d like
        to see the text
        here RECOMMEND use of encryption to provide confidentiality.
        This would be
        supportive of personal privacy, in residential contexts, and
        physical security
        in residential and enterprise settings. I can imagine a movie in
        which burglars
        use a lack of encryption to gain critical information about
        building
        infrastructure from a an energy MIB 

J

.




 




The text
        later says “There
        are a number of management objects defined in these MIB modules
        with a
        MAX-ACCESS clause of read-write and/or read-create.

  

Such objects MAY be
        considered sensitive or
        vulnerable in some network environments.

 
        

The support for SET operations in a non-secure
        environment without
        proper protection can have a negative effect on network
        operations. Again, this
        strikes me as a significant understatement, i.e., the scope of
        the “negative
        effect” could be much broader that just a network. (Power
        outlets are cited as
        examples of objects, so anything plugged into an outlet could be
        effected,
        right?) 

 

There should be
        more emphasis on
        the need for access control.




 




The text
        later says “SNMP
        versions prior to SNMPv3 did not include adequate security. Even
        if the network
        itself is secure (for example, by using IPsec), there is still
        no secure
        control over who on the secure network is allowed to access and
        GET/SET 

(read/change/create/delete)
the
        objects in these MIB modules.” This is a misleading. IPsec
        natively
        provides access control. It would be accurate to say that the
        access controls
        offered by IPsec would only limit who could access the MIB. What
        the authors
        seem to suggest here is finer-grained access control, so that
        one can manage
        GET/SET privileges for the set of individuals who are authorized
        to connect to
        the MIB via the SMTP port, right?







 




The text
        discussing use of
        SNMPv3 security is a bit confusing.




It RECOMMENDS that implementers
      “consider”
      SMNPv3 security features, but then says deployment of SNMP
      versions prior to v3
      is NOT RECOMMENDED. The first paragraph discussing this topic
      deals with
      thinking about support (vs. use) of SNMPv3, while the second
      paragraph makes a
      much stronger statement about deployment. It would be more
      consistent to mandate
      support (MUST or SHOULD) for SNMPv3 in entities that incorporate
      this MIB.
      Separately the document can RECOMMEND enabling SNMPv3 security
      features in
      deployments, for the reasons cited.