Skip to main content

Last Call Review of draft-ietf-opsawg-vmm-mib-02

Request Review of draft-ietf-opsawg-vmm-mib
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-05-18
Requested 2015-05-07
Authors Hirochika Asai , Michael MacFaden , Jürgen Schönwälder , Keiichi Shima , Tina Tsou (Ting ZOU)
I-D last updated 2015-05-15
Completed reviews Genart Last Call review of -02 by Paul Kyzivat (diff)
Genart Telechat review of -03 by Paul Kyzivat (diff)
Secdir Last Call review of -02 by Christian Huitema (diff)
Opsdir Last Call review of -02 by Dan Romascanu (diff)
Opsdir Telechat review of -03 by Dan Romascanu (diff)
Assignment Reviewer Christian Huitema
State Completed
Request Last Call review on draft-ietf-opsawg-vmm-mib by Security Area Directorate Assigned
Reviewed revision 02 (document currently at 04)
Result Has nits
Completed 2015-05-15
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.

For the security area directions, I consider this document to be "Ready with

This document specifies objects (MIB) for managing virtual machines
controlled by a hypervisor (a.k.a. virtual machine monitor) using SNMP.

The security section is thoroughly written, points out the operational risk
if some management variables can be SET, and the privacy or other security
risks if hostile parties can read some of the objects. The essential
recommendation is to use SNMPv3 strong security, or when that strong
security is not available, to disable the "SET" capabilities. 

There is an aggravating factor not mentioned in the security section. In
many large data centers, some virtual machines will not be under the direct
control of the data center manager. They may have been rented to third
parties, or they may have been subverted. These potentially hostile virtual
machines will have direct network connectivity with the hypervisor, and
potentially with other hypervisors in the same subnet. Attackers in control
of these machines can gain advantage of even read-only access to hypervisor
state variables. One wonders whether even GET access should be allowed in
the absence of authentication through SNMPv3. Attempting to support even GET
operations with prior versions of SNMP appears risky.

-- Christian Huitema