Juergen, thanks, I'm now working on updating the text with Hirochika.
> 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. OK, we've removed the above paragraph. The latest text in the repository does't have it. > 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. OK, the above text has been merged. --- Keiichi SHIMA (島 慶一) WIDE project <[email protected]> Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> > On 2015/05/26, at 17:52, Juergen Schoenwaelder > <[email protected]> wrote: > > 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
