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 On Jul 4, 2014, at 3:08 PM, "Black, David" <[email protected]> wrote: >>> 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.” >> >> 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 not 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. > > 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 protected]] On Behalf Of Michael MacFaden >> Sent: Friday, July 04, 2014 1:43 PM >> To: David Harrington >> Cc: [email protected] >> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-vmm-mib-01.txt >> >> dbh writes: >>> 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.” >> >> 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 >> >> _______________________________________________ >> OPSAWG mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg -- Hirochika Asai <[email protected]>, The University of Tokyo _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
