Skip to main content

Last Call Review of draft-ietf-eman-applicability-statement-08
review-ietf-eman-applicability-statement-08-secdir-lc-shore-2014-12-04-00

Request Review of draft-ietf-eman-applicability-statement
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-12-01
Requested 2014-11-20
Authors Brad Schoening , Mouli Chandramouli , Bruce Nordman
I-D last updated 2014-12-04
Completed reviews Secdir Last Call review of -08 by Melinda Shore (diff)
Opsdir Last Call review of -08 by Qin Wu (diff)
Opsdir Last Call review of -08 by Fred Baker (diff)
Assignment Reviewer Melinda Shore
State Completed
Request Last Call review on draft-ietf-eman-applicability-statement by Security Area Directorate Assigned
Reviewed revision 08 (document currently at 11)
Result Has issues
Completed 2014-12-04
review-ietf-eman-applicability-statement-08-secdir-lc-shore-2014-12-04-00
I have 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.

Summary: Security considerations section is insufficient.  Otherwise
the document is in pretty good shape (with nits).

This document is essentially a set of use cases guiding the energy
management's (eman) working group's work, as well as providing a
description of the relationship of the IETF's eman's framework to
other relevant energy monitoring standards.

Of particular interest, perhaps, is that eman is using SNMP to convey
energy device information.

The use cases are very clearly described, and we're grateful for
the "essential properties" breakout summaries ("target devices,"
"how powered," and "reporting") at the bottom of each use case.

All that said, I was extremely surprised to get to the "Security
considerations" section and find that it consisted of but two
generic sentences about SNMP.  We are all aware of issues related
to the sensitivity of the electric grid, and powered devices,
to security vulnerabilities and that this is a time of heightened
scrutiny of how the grid is secured.  This necessarily extends to
monitoring, and there is certainly a *lot* of information that
may be gleaned by an attacker from monitoring power consumption,
as well as manipulation of the grid by an attacker inserting
bogus monitoring messages.

There does not appear to have been any work done within the
group on developing a threat model for energy monitoring, which
strikes me as problematic.  However, even in the absence of an
interest in developing one, a quick summary of the sorts of
attacks that must be considered in the development and deployment
of energy monitoring mechanisms strikes me as far, far, far
more useful than a one-sentence rundown of generic security mechanisms
provided by SNMPv3.

Minor comments:

1) This is more by way of guidance, but it should be noted that
   while the information model may be portable to YANG, netconf,
   and others, the security models and technologies used to secure
   those protocols may be (and are) different, and security
   properties need to be given serious consideration before
   moving the information model to another conveyance.

2) the I-D nit checker found a number of problems in the references,
   as well as a few other problems.


https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-eman-applicability-statement-08.txt



Trivial nits:

1) In section 1.2, the document name/reference should be separated
   from the document description by a colon and space

2) In that same section there's a stray period at the very bottom of
   page 4

3) Section 2, first paragraph:  "This section a presents energy
   management scenarios [ ... ]".  That 'a' (third word) needs to be
   removed.

4) For some reason the section header for section 2.8 does not appear
   bolded, while those for other subsections do.


Melinda