Last Call Review of draft-ietf-eman-framework-15

Request Review of draft-ietf-eman-framework
Requested rev. no specific revision (document currently at 19)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-02-24
Requested 2014-02-13
Authors John Parello, BenoƮt Claise, Brad Schoening, Juergen Quittek
Draft last updated 2014-02-27
Completed reviews Genart Last Call review of -15 by Christer Holmberg (diff)
Genart Telechat review of -16 by Christer Holmberg (diff)
Secdir Last Call review of -15 by Yoav Nir (diff)
Secdir Telechat review of -16 by Yoav Nir (diff)
Assignment Reviewer Yoav Nir
State Completed
Review review-ietf-eman-framework-15-secdir-lc-nir-2014-02-27
Reviewed rev. 15 (document currently at 19)
Review result Has Issues
Review completed: 2014-02-27


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.

Although I am reviewing this for SECDIR, I have to begin with some editorial remarks. I don't know what tool was used, but it's producing a very ill-formatted draft. It's true that the RFC editor staff will get it right, but it is apparent that this is a combination of several sources. See for example section 2 for a jarring mixture of line lengths.  Or the broken-in-half artwork of Figure 1 at the bottom of page 14. When you do that, someone (that's the RFC editor) has to put your diagrams back together, an error-prone process that should be done by the authors.

The middle of section 1 has a paragraph whose entire text is "Energy Management Documents Overview". Was this supposed to be the title to a subsection?

The document also contains some parts that are supposed to be removed before publication, for example the URL to the issue tracker. Please add a label like "RFC EDITOR NOTE: REMOVE THE FOLLOWING PARAGRAPH" before this. They know to look for it, and we don't end up with things we didn't want in the draft.

Speaking of issues, I followed that URL, and found that it is showing three open issues. Are these resolved?

I confess to being totally ignorant of the subject matter, but reading through this I noticed something that surprised me. In section 3.1 there is this paragraph:
        A simple device such as a light bulb can be switched on or off 
        only by switching its power supply.  More complex devices may 
        have the ability to switch off themselves or to bring 
        themselves to states in which they consume very little power.
Is the "may" here appropriate? Don't these complex devices *require* that they switch themselves off rather than have their power switched off?

Finally, the security considerations section. The most important recommendation there is to use SNMPv3, because it includes authentication and privacy, unlike earlier versions. I agree with the recommendation, but it should be noted that authentication was part of SNMPv1 as well, although different mechanisms (not based on community strings) were only added in SNMPv3. "Privacy" is a loaded term with multiple meanings. In SNMP privacy simply means confidentiality, and it's preferable to use that term rather than "privacy" which today is no longer used interchangeably with confidentiality.

The section does an OK job of enumerating the risks, but IMO downplays them. For example, "Unauthorized changes to the Energy Management Domain or business context of an Energy Object may result in misreporting or interruption of power."  There's no "may" about it. If an attacker can modify the energy management domain, then they can at least shut down the network.