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
