Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-vmm-mib-01.txt

From: [email-masked]
Date: Fri, 04 Jul 2014 07:43:01 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF.

        Title           : Management Information Base for Virtual Machines Controlled by a Hypervisor
        Authors         : Hirochika Asai
                          Michael MacFaden
                          Juergen Schoenwaelder
                          Keiichi Shima
                          Tina Tsou
	Filename        : draft-ietf-opsawg-vmm-mib-01.txt
	Pages           : 56
	Date            : 2014-07-04

Abstract:
   This document defines a portion of the Management Information Base
   (MIB) for use with network management protocols in the Internet
   community.  In particular, this specifies objects for managing
   virtual machines controlled by a hypervisor (a.k.a. virtual machine
   monitor).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-vmm-mib-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Hirochika Asai <[email-masked]>
Date: Fri, 4 Jul 2014 23:50:29 +0900

Dear all,

Thanks to comments through the mailing list on the read-write objects in the MIB,
we have uploaded the new version of <draft-ietf-opsawg-vmm-mib>.

The differences are derived from the discussion on this mailing list:
1) Replace the read-write MAX-ACCESS with the read-only MAX-ACCESS
  except for vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled.
2) Add description stating "Changes to this object MUST NOT persist across
   re-initialization of the management system, e.g., SNMP agent." to these two
   read-write objects for clarification.

The security consideration is fixed according to these changes.  Some unclear
descriptions are also modified.

Thank you.
Hirochika

Begin forwarded message:

> From: [email-masked]
> Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-vmm-mib-01.txt
> Date: July 4, 2014 11:43:01 PM GMT+09:00
> To: [email-masked]
> Cc: [email-masked]
> 
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
Hirochika Asai <[email-masked]>, The University of Tokyo

---

From: David Harrington <[email-masked]>
Date: Fri, 4 Jul 2014 12:58:11 -0400

Hi,

I think there is an undocumented security vulnerability.
Because we REQUIRE the read-write objects to not persist across reboots, an undetected reboot of the SNMP system shuts off notifications.
If an operator turns on notifications via the enable objects in this module, they presumably want to be told of certain events that might occur.
If notifications are used to report security issues, an attacker that can somehow cause the system to restart will disable notifications, presumably including those that warn an operator of an attack.
(as well as those that warn an operator of an undesirable operational state, such as interface down).
I think that’s a problem.

I also question the use of MUST NOT persist.
How does an implementation allowing the enable setting to persist break the protocol or the managed entity?
I think an appropriate RFC2119 usage would be “implementations MAY choose to not persist the values.”

dbh

---

From: Michael MacFaden <[email-masked]>
Date: Fri, 4 Jul 2014 10:43:28 -0700 (PDT)

dbh writes:
> Because we REQUIRE the read-write objects to not persist across reboots, an
> undetected reboot of the SNMP system shuts off notifications.
> If an operator turns on notifications via the enable objects in this module,
> they presumably want to be told of certain events that might occur.
> If notifications are used to report security issues, an attacker that can
> somehow cause the system to restart will disable notifications, presumably
> including those that warn an operator of an attack.

Implementations that support SET for these objects can store the values
in transient storage such that a restart of the agent itself does not 
lose the configuration. One example implementation would be
writing the state to ramdisk which would persist across system reboot.
As usual sets can be complex to get right and its difficult to understand
what a mib module is telling you to do here.
Maybe some guidance on that point would be useful in the discussion.

Regarding notification state on/of and it being security issue, this isn't
only an issue in this mib module I think. Its common place problem with
with event/push only designs. We  could add text to explain that
any design that is 100% reliant  on notifications as the sole means 
of maintaining distributed state is a failed design to begin with. 
notification only designs must be bounded either by poll or reverse poll/periodic
event to detect a failure to receive notifications regardless of what caused
the failure.

Cheers,
Mike MacFaden

---

From: Michael MacFaden <[email-masked]>
Date: Fri, 4 Jul 2014 10:45:24 -0700 (PDT)

One correction, left out the 'not', sorry to confuse:
line should have read:

  One example implementation would be writing the state to ramdisk 
  which would not persist across system reboot.

Mike

---

From: "Black, David" <[email-masked]>
Date: Fri, 4 Jul 2014 15:08:11 -0400

> writing the state to ramdisk which would not persist across system reboot.

I concur w/Dave Harrington's original concern - "MUST NOT" seems excessive.

Suggestion:

OLD
      Changes to this	
	object MUST NOT persist across re-initialization of	
	the management system, e.g., SNMP agent.
NEW
      Changes to this	
	object may be lost when the management system, e.g., SNMP agent,
      is re-initialized.

I don't see the harm in persisting changes to notification enablement
settings.  Mike's point seems to be that one cannot and should not rely
on changes persisting, not that it's harmful or otherwise wrong to do so.

Thanks,
--David

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Michael MacFaden
> Sent: Friday, July 04, 2014 1:43 PM
> To: David Harrington
> Cc: [email-masked]
> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-vmm-mib-01.txt
> 
> dbh writes:

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 5 Jul 2014 09:54:45 +0200

> descriptions are also modified.

I read this in the security considerations:

   When SNMPv3 strong security is not used, these objects
   should have access of read-only, not read-write.

There is a access mode that is implemented and then there is an access
policy that is runtime configured in VACM. What does this allude to?
I assume the most sensible interpretation is that this sentence tries
to give advice to the security administrator configuring VACM but then
this sentence should be more explicit, e.g.:

   When SNMPv3 strong security is not used, the access control model
   (e.g., the View-based Access Control Model [RFC3415]) should be
   configured to disallow write access.

And perhaps add:

   It is recommended that default access control configurations
   shipped with an implementation exclude write access to these
   objects.

/js

PS: From an SMIv2 perspective, it is odd that the MAX-ACCESS of some
    of the objects has been changed from read-write to read-only but
    it seems the "political climate" overrules what MAX-ACCESS used to
    mean in STD 58.

-- 
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/>

---

From: Hirochika Asai <[email-masked]>
Date: Wed, 23 Jul 2014 06:36:31 -0400

Thank you for your suggestion.  I'm sorry for my delayed response .

I understand "MUST NOT" isn't good for these objects.
Then, I'd like to discuss your suggested sentence in the WG meeting today.

Thank you.
Hirochika