Hi - >From: Kathleen Moriarty <[email protected]> >Sent: Jun 22, 2015 12:45 PM >To: Michael MacFaden <[email protected]> >Cc: "[email protected]" ><[email protected]>, Randy Presuhn ><[email protected]>, "[email protected]" ><[email protected]>, "[email protected]" ><[email protected]>, The IESG <[email protected]>, "[email protected]" ><[email protected]>, "[email protected]" ><[email protected]> >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 protected]> 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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
