[secdir] Secdir review of draft-ietf-opsawg-vmm-mib-02

"Christian Huitema" <huitema@huitema.net> Thu, 14 May 2015 02:49 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB8B1A90A9 for <secdir@ietfa.amsl.com>; Wed, 13 May 2015 19:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoBAdVC8xvrH for <secdir@ietfa.amsl.com>; Wed, 13 May 2015 19:49:14 -0700 (PDT)
Received: from xsmtp02.mail2web.com (xsmtp02.mail2web.com [168.144.250.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2D01ACF1A for <secdir@ietf.org>; Wed, 13 May 2015 19:49:13 -0700 (PDT)
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1YsjCx-0005Qx-6y for secdir@ietf.org; Wed, 13 May 2015 22:49:11 -0400
Received: (qmail 28329 invoked from network); 14 May 2015 02:49:10 -0000
Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[72.235.170.243]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-opsawg-vmm-mib.all@tools.ietf.org>; 14 May 2015 02:49:09 -0000
From: Christian Huitema <huitema@huitema.net>
To: 'The IESG' <iesg@ietf.org>, secdir@ietf.org
Date: Wed, 13 May 2015 19:49:05 -0700
Message-ID: <00bb01d08df0$8d92f3f0$a8b8dbd0$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdCN7doYjrDBgdzuTDO0+ECXL1vNSA==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/ZCbE_k0aMg4mzSSkvQBuh-4aklM>
Cc: draft-ietf-opsawg-vmm-mib.all@tools.ietf.org
Subject: [secdir] Secdir review of draft-ietf-opsawg-vmm-mib-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2015 02:49:15 -0000

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

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