Keiichi, note that there is outdated text on page 9 that should be updated:
The MIB module provides a few writable objects that can be used to make non-persistent changes, e.g., changing the memory allocation or the CPU allocation. It is not the goal of this MIB module to provide a configuration interface for virtual machines since other protocols and data modeling languages are more suitable for this task. In the security considerations, I assume Dan wants: OLD There are two objects defined in this MIB, vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that have a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. NEW There are two objects defined in this MIB, vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that have a MAX-ACCESS clause of read-write. Enabling notifications can lead to a noticeable number of notifications if many virtual machines change their state concurrently. Hence, such objects may be considered sensitive or vulnerable in some network environments. /js On Tue, May 26, 2015 at 07:23:17AM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > I would still recommend that you add text in the Security Considerations > section in which you describe the risk of intentional or unintentional > misconfiguration of the two writeable objects in the MIB module. It would > also be useful to mention explicitly that the authors considered the risks of > multiplication of notification and evaluated it as manageable for all > reasonably designed and sized networks. > > Thanks and Regards, > > Dan > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Tuesday, May 26, 2015 9:47 AM > > To: Keiichi SHIMA > > Cc: Romascanu, Dan (Dan); [email protected]; > > [email protected]; [email protected] > > Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 > > > > On Tue, May 26, 2015 at 10:45:48AM +0900, Keiichi SHIMA wrote: > > > Hi all, > > > > > > >> 17. I am concerned that the current way of defining the > > > >> notifications switches is too course. Hypervisors may have many VMs > > > >> in charge, and if each generates one notification per each state > > > >> changes the numbers can become big even in normal operation. Maybe > > > >> some throttling mechanism would be useful. Or maybe a couple of > > > >> more switches that allow to enable only 'critical' notifications > > > >> (e.g. vmCrashed). > > > > > > > > The only situation I can think of where the number of notifications > > > > will be significant is during restart of a whole rack with many > > > > hypervisors inside. But even then, things usually take time. (I > > > > think our Xen hypervisors actually create virtual machines > > > > sequentially and hence the notifications get actually spaced over > > > > time.) It is not unlikely that the operating systems inside the > > > > hypervisors during startup generate significantly more network > > > > traffic compared to a few hypervisor notifications. That said, > > > > during the development of the MIB module we moved from generic > > state > > > > change notifications to a set of specific notifications and this > > > > allows to use SNMPv3 notification filtering to filter out notifications > > people find not useful. > > > > > > > > > I and Asai talked locally and we agree Juergen that the number of > > notification events is manageable. > > > > > > However we noticed that the 'vmBlocked' notification may be a problem. > > The 'blocked' state is defined as 'The operational state of the virtual > > machine > > indicating the execution of the virtual machine is currently blocked, e.g., > > waiting for some action of the hypervisor to finish. This is a transient > > state > > from/to other states.' This state transition event may appear more > > frequently than other events, since the state is caused by the I/O scheduler > > of the hyper visor implementation. > > > > > > We think we can simply remove the 'vmBlocked' notification. The 'blocked' > > state is a transient state and typically return to the previous state > > immediately (once the pending I/O requests completed). > > > > > > > Yes, this makes sense to me. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs- > > 2Duniversity.de_&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O > > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=MgxJDgRk1TpLrZ2hiPqtqSLH_gUN > > Xo4hIzz7Czjm6c0&s=0FOhbeoR7FEAGZddNHtPDimJFq1MNfZlAEOjldkr1tA&e > > = > -- 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
