This section describes the requirements for SNMPv2 protocol entities in connection with recovery from system crashes or other service interruptions.
For each SNMPv2 party in the local database for a particular SNMPv2 entity, its identity, authentication clock, private authentication key, and private privacy key must enjoy non- volatile, incorruptible representations. If possible, lifetime should also enjoy a non-volatile, incorruptible representation. If said SNMPv2 entity supports other security protocols or algorithms in addition to the two defined in this memo, then the authentication protocol and the privacy protocol for each party also require non-volatile, incorruptible representation.
The authentication clock of a SNMPv2 party is a critical component of the overall security of the protocols. The inclusion of a reliable representation of a clock in a SNMPv2 entity is required for overall security. A reliable clock representation ensures that a clock's value is monotonically increasing, even across a power loss or other system failure of the local SNMPv2 entity. One example of a reliable clock representation is that provided by battery-powered clock- calendar devices incorporated into some contemporary systems. Another example is storing and updating a clock value in non- volatile storage at a frequency of once per U (e.g., 24) hours, and re-initialising that clock value on every reboot as the stored value plus U+1 hours. It is assumed that management stations always support reliable clock representations, where clock adjustment by a human operator during crash recovery may contribute to that reliability.
If a managed agent crashes and does not reboot in time for its responsible management station to prevent its authentication clock from reaching its maximal value, upon reboot the clock must be halted at its maximal value. The procedures specified in Section 5.3 would then apply.
Upon recovery, those attributes of each SNMPv2 party that do not enjoy non-volatile or reliable representation are initialized as follows.
Upon detecting that a managed agent has rebooted, a responsible management station must reset all other party attributes, including the lifetime if it was not retained. In order to reset the lifetime, the responsible management station should set the authentication timestamp in the message to the sum of the authentication clock and desired lifetime. This is an artificial advancement of the authentication timestamp in order to guarantee the message will be authentic when received by the recipient.