This section describes practices that contribute to the secure, effective operation of the mechanisms defined in this memo.
Although it would be typical for a management station to do this as a matter of course, in the context of these security protocols it is significant owing to the possibility of message duplication (malicious or otherwise).
It is possible for authentication failure traps to be lost or suppressed as a result of authentication clock skew or inconsistent notions of shared secrets. In order either to facilitate administration of such SNMPv2 parties or to provide for continued management in times of network stress, a management station implementation may provide for arbitrary, artificial advancement of the timestamp or selection of shared secrets on locally generated messages.
A large lifetime increases the vulnerability to malicious delays of SNMPv2 messages. The implementation of a management station may accommodate changing network conditions during periods of network stress by effectively increasing the lifetimes of the source and destination parties. The management station accomplishes this by artificially advancing its notion of the source party's clock on messages it sends, and by artificially increasing its notion of the source party`s lifetime on messages it receives.
No message ordering is imposed by the SNMPv2. Messages may be received in any order relative to their time of generation and each will be processed in the ordered received. Note that when an authenticated message is sent to a managed agent, it will be valid for a period of time that does not exceed lifetime under normal circumstances, and is subject to replay during this period.
Indeed, a management station must cope with the loss and re-ordering of messages resulting from anomalies in the network as a matter of course.
However, a managed object, snmpSetSerialNo , is specifically defined for use with SNMPv2 set operations in order to provide a mechanism to ensure the processing of SNMPv2 messages occurs in a specific order.
Protecting the secrets from disclosure is critical to the overall security of the protocols. Frequent use of a secret provides a continued source of data that may be useful to a cryptanalyst in exploiting known or perceived weaknesses in an algorithm. Frequent changes to the secret avoid this vulnerability.
Changing a secret after each use is generally regarded as the most secure practice, but a significant amount of overhead may be associated with that approach.
Note, too, in a local environment the threat of disclosure may be insignificant, and as such the changing of secrets may be less frequent. However, when public data networks are the communication paths, more caution is prudent.
Owing to the use of symmetric cryptography in the protocols defined here, the secrets associated with a particular SNMPv2 party must be known to all other SNMPv2 parties with which that party may wish to communicate. As the number of locations at which secrets are known and used increases, the likelihood of their disclosure also increases, as does the potential impact of that disclosure. Moreover, if the set of SNMPv2 protocol entities with knowledge of a particular secret numbers more than two, data origin cannot be reliably authenticated because it is impossible to determine with any assurance which entity of that set may be the originator of a particular SNMPv2 message. Thus, the greatest degree of security is afforded by configurations in which the secrets for each SNMPv2 party are known to at most two protocol entities.