Hi - >From: Kathleen Moriarty <[email protected]> >Sent: Jun 22, 2015 12:49 PM >To: Randy Presuhn <[email protected]> >Cc: The IESG <[email protected]>, "[email protected]" ><[email protected]>, >"[email protected]" <[email protected]>, >"[email protected]" <[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, > >Sent from my iPhone > >> On Jun 22, 2015, at 6:58 PM, Randy Presuhn <[email protected]> >> wrote: >> >> Hi - >> >>> From: Kathleen Moriarty <[email protected]> >>> Sent: Jun 22, 2015 4:57 AM >>> To: The IESG <[email protected]> >>> Cc: [email protected], >>> [email protected], [email protected], >>> [email protected], [email protected] >>> 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. >> >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.
I guess what I'm missing here is that I don't see how a managed virtual machine is different from any other managed resource. Whether a given managed virtual machine has been granted access (via VACM) and has the necessary network connectivity to reach the SNMP engine is a question of what that virtual machine is supposed to do and of security/administrative policy. For example, if that VM is hosting implementations of some of the distributed management MIB modules, it would be perfectly reasonable for an entity running on it to be an authorized user granted access by VACM to this MIB module. If, on the other hand, that VM hosts malware for observation purposes, one would probably not allow it to monitor or configure the hypervisor, and might choose to severely limit its connectivity. I don't see how this is substantially different from any other managed application. Randy _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
