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 13:04:56 -0700 (GMT-07:00)

Hi -

>From: Kathleen Moriarty <[email-masked]>
>Sent: Jun 22, 2015 12:45 PM
>To: Michael MacFaden <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>, Randy Presuhn <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT)
>
>Hi Mike,
>
>Sent from my iPhone
>
>> On Jun 22, 2015, at 9:08 PM, Michael MacFaden <[email-masked]> wrote:
>> 
>> 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. 
>
>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.

I'm missing something here.  Why is a monitored VM (where the
MIB instrumentation is external to the VM) different from any other
threat?  It seems to me that "access to the management connection"
is a red herring - the privacy protocol, along with authentication
and access control (VACM) should just be left to do their job.

Randy

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 22 Jun 2015 16:12:45 -0400

On Mon, Jun 22, 2015 at 4:04 PM, Randy Presuhn <[email-masked]
> wrote:

> >Cc: "[email-masked]" <
> [email-masked]>, Randy Presuhn <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, The IESG <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> >Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on
> draft-ietf-opsawg-vmm-mib-03: (with COMMENT)
> >
> >Hi Mike,
> >
> >Sent from my iPhone
> >
> >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)?
> >

This came up in the SecDir review.  I was happy with the response provided
via email in how it was put out-of-scope.  The draft itself does not have
the explanation offered and I think it would be helpful to the reader in
case the same question comes up later.  I thought it was a reasonable
question given the content of the draft and possible threat space.

Thanks.

-- 

Best regards,
Kathleen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Jun 2015 16:05:36 +0200

> question given the content of the draft and possible threat space.

Hi,

the only meaningful way to implement this MIB is as part of the
hypervisor. I think this actually follows directly from section 3. I
am surprised that people got any different ideas from reading the
document or looking at Figure 1. The resources are managed by the
hypervisor so this is the natural authority for the information
exposed by the MIB module.

Given this, I do not really see why the security template text is not
sufficient.  If you expose the content of the MIB widely, then it does
not matter whether it is read from a VM on the hypervisor, a VM on a
different hypervisor or any other system with access to the Internet.
(Sure, if something on a VM wants to break out of its walled garden,
it might in principle help to know the hypervisor technology etc. But
frankly, it is far easier and more robust to simply try all different
break out techniques known to an attacker or to infer likely
technology via fingerprinting or even social and web engineering).

My preference is to make no change to the text. But, if the IESG feels
strongly, I won't object putting in additional (but in my view
unneeded) words if that helps to avoid spending cycles on discussions
that I find not really relevant. (Who cares whether the MIB module is
implemented on the hypervisor as part of a monolithic agent or a
subagent - the security trade offs are known and documented - at least
for the standardized protocols).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 23 Jun 2015 14:22:58 +0000

I concur with Randy and Juergen.
-- 
Regards,
Uri Blumenthal

On 6/23/15, 10:05 , "Juergen Schoenwaelder"
<[email-masked]> wrote:

>> > >> Agree there should be some warning here. But if this text is
>>intended
>> > for those who implement it
>> > >>  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
>_______________________________________________
>OPSAWG mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/opsawg

---

From: joel jaeggli <[email-masked]>
Date: Tue, 23 Jun 2015 07:34:04 -0700

> I concur with Randy and Juergen.

Ok thanks, I think we have dicussed us.

joel