On Mon, Jun 22, 2015 at 04:12:45PM -0400, Kathleen Moriarty wrote: > On Mon, Jun 22, 2015 at 4:04 PM, Randy Presuhn <randy_pres...@mindspring.com > > wrote: > > > Hi - > > > > >From: Kathleen Moriarty <kathleen.moriarty.i...@gmail.com> > > >Sent: Jun 22, 2015 12:45 PM > > >To: Michael MacFaden <m...@vmware.com> > > >Cc: "draft-ietf-opsawg-vmm-mib.sheph...@ietf.org" < > > draft-ietf-opsawg-vmm-mib.sheph...@ietf.org>, Randy Presuhn < > > randy_pres...@mindspring.com>, "draft-ietf-opsawg-vmm-...@ietf.org" < > > draft-ietf-opsawg-vmm-...@ietf.org>, "opsawg-cha...@ietf.org" < > > opsawg-cha...@ietf.org>, The IESG <i...@ietf.org>, "opsawg@ietf.org" < > > opsawg@ietf.org>, "draft-ietf-opsawg-vmm-mib...@ietf.org" < > > draft-ietf-opsawg-vmm-mib...@ietf.org> > > >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 <m...@vmware.com> 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. > > > > 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. >
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/> _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
