I concur with Randy and Juergen. -- Regards, Uri Blumenthal
On 6/23/15, 10:05 , "Juergen Schoenwaelder" <[email protected]> wrote: >On Mon, Jun 22, 2015 at 04:12:45PM -0400, Kathleen Moriarty wrote: >> On Mon, Jun 22, 2015 at 4:04 PM, Randy Presuhn >><[email protected] >> > wrote: >> >> > 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. >> > >> >> 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 >[email protected] >https://www.ietf.org/mailman/listinfo/opsawg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
