6.1. Recommended Practices

This section describes practices that contribute to the secure, effective operation of the mechanisms defined in this memo.

• A management station should discard SNMPv2 responses for which neither the request-id component nor the represented management information corresponds to any currently outstanding request.

  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).

• A management station should not interpret an agent's lack of response to an authenticated SNMPv2 management communication as a conclusive indication of agent or network failure.

  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.

• The lifetime value for a SNMPv2 party should be chosen (by the local administration) to be as small as possible, given the accuracy of clock devices available, relevant round-trip communications delays, and the frequency with which a responsible management station will be able to verify all clock values.

  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.

• When sending state altering messages to a managed agent, a management station should delay sending successive messages to the managed agent until a positive acknowledgement is received for the previous message or until the previous message expires.

  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 [14], 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.

• The frequency with which the secrets of a SNMPv2 party should be changed is indirectly related to the frequency of their use.

  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.

• In order to foster the greatest degree of security, a management station implementation must support constrained, pairwise sharing of secrets among SNMPv2 entities as its default mode of operation.

  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.