Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT)

From: Randy Presuhn <[email-masked]>
Date: Mon, 22 Jun 2015 09:58:44 -0700 (GMT-07:00)

Hi -

>From: Kathleen Moriarty <[email-masked]>
>Sent: Jun 22, 2015 4:57 AM
>To: The IESG <[email-masked]>
>Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
>Subject: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT)
...
>I found the SecDir review to be interesting, raising a point of
>clarification specific to this draft and not the agreed boilerplate text.
> Since there was confusion by the reader as to the access possibilities
>and where this mib is used, I think it's worth adding a sentence with the
>clarifying point from the discussion.  How about:
>
>This MIB module is typically implemented on the hypervisor not inside a
>virtual machine.  Virtual machines, possibly under other administrative
>domains, would not have access to this mib as the SNMP service would
>typically operate in a separate management network.
>
>https://www.ietf.org/mail-archive/web/secdir/current/msg05705.html 
>https://www.ietf.org/mail-archive/web/secdir/current/msg05706.html
>
>The suggested text, or something similar might fit into the introduction
>to limit the scope or after paragraph 2 in Section 3.

If I understand the concern correctly, I'd suggest this text as
an alternative.

  Instrumentation for this MIB module is typically implemented
  within the hypervisor for two reasons.  First, that is where
  the necessary information is most readily available.  Second,
  because individual virtual machines can be under other
  administrative domains and are thus not necessarily trusted
  by the hypervisor, there is no assurance that a given virtual
  machine will even contain supporting instrumentation,
  much less make it available in a trustworthy manner.

Randy

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 22 Jun 2015 19:08:20 +0000

Agree there should be some warning here. But if this text is intended for those who implement it
(like me) then I'd prefer to  make it clear as mud what the issue is:

  Any implementation of this MIB module in an agent where the Virtual Machines being monitored 
  have access to this very agent or this MIB module creates an attack vector on the system or on
  any other VM hosted by this system. 

Mike MacFaden

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 22 Jun 2015 21:45:22 +0200

Hi Mike,

Sent from my iPhone

> On Jun 22, 2015, at 9:08 PM, Michael MacFaden <[email-masked]> wrote:
> 

Yes and one of the responses to the SecDir review said this mib would just be on the hypervisor.  It also said the virtual images managed by the hypervisor typically does not have access to the management connection for SNMP to the hypervisor, limiting the risk.

Shouldn't the text include guidance that makes this clear (where this mib is and the reality of whether or not it's a risk from managed virtual images)?

Recommending a separate management connection is one way to do that.

Thanks,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 22 Jun 2015 21:49:20 +0200

Hi,

Sent from my iPhone

> On Jun 22, 2015, at 6:58 PM, Randy Presuhn <[email-masked]> wrote:
> 
> Hi -
> 
This text is close to what I was looking for, thanks.  It doesn't explicitly say that the managed virtual machines would not have access to the SNMP management interface clearly it just says they aren't trusted. Some recommendation would be helpful.

Thank you,
Kathleen