Skip to main content

11.4. Use of Reports

11.4. Use of Reports​

This section describes how USM uses the SNMP Report mechanism to communicate errors and other information.

Report PDU​

The Report PDU, defined in [RFC3416], is used by USM to return information about errors that occurred during message processing. Reports are particularly important for:

  1. Discovery - returning the authoritative engine's snmpEngineID
  2. Time synchronization - returning current engine time values
  3. Error notification - indicating authentication, privacy, or other security-related errors

USM Statistics​

The USM maintains several counters that track various error conditions. These counters are defined in the usmStats group of the MIB module (section 5):

  • usmStatsUnsupportedSecLevels - Messages with unsupported security levels
  • usmStatsNotInTimeWindows - Messages outside the time window
  • usmStatsUnknownUserNames - Messages with unknown user names
  • usmStatsUnknownEngineIDs - Messages with unknown engine IDs
  • usmStatsWrongDigests - Messages with incorrect authentication digests
  • usmStatsDecryptionErrors - Messages with decryption errors

Report Generation​

When USM detects an error during incoming message processing, it MAY generate a Report-PDU containing:

  1. The appropriate USM statistics counter object
  2. The current value of that counter
  3. Relevant msgID from the received message (for matching)

Important considerations:

  • Reports are NOT always generated for every error. The decision depends on the security level and error type.
  • Reports for certain errors (like usmStatsNotInTimeWindows for discovery) are used constructively.
  • Reports MUST NOT be sent in response to another Report to avoid infinite loops.

Security Levels for Reports​

Reports are sent with varying security levels depending on the error:

  1. noAuthNoPriv - Used for:

    • Discovery (unknown engineID)
    • Time synchronization failures
    • Unknown user names

  2. Same as request - Used for:

    • Authentication failures (wrong digest)
    • Decryption errors
    • Out-of-time-window errors (after synchronization)

Report Reception​

When a command generator or notification originator receives a Report-PDU:

  1. Discovery response: If the report contains usmStatsUnknownEngineIDs and the varBind contains a non-zero engineID, the application has successfully discovered the authoritative engine's identity.

  2. Time synchronization response: If the report contains usmStatsNotInTimeWindows, the application should extract the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime from the securityParameters and update its local cache.

  3. Error indication: For other report types, the application should treat the report as an indication that the original request failed for the specified reason.

Report Handling Best Practices​

  1. Avoid report storms: Implementations should rate-limit or suppress report generation to prevent network congestion.

  2. Log reports: Security-related reports should be logged for audit and security analysis.

  3. User feedback: Applications should provide clear feedback to users when reports indicate authentication or authorization failures.

  4. Time window errors: After multiple usmStatsNotInTimeWindows reports, implementations should suspect clock skew and may require manual intervention.

Privacy and Reports​

Reports generated in response to messages with privacy may need special handling:

  • If decryption fails, the report should indicate usmStatsDecryptionErrors.
  • The report itself should be sent with the same security level as requested in the original message, if possible.
  • If the security level cannot be determined (e.g., due to severe message corruption), the report should be sent with noAuthNoPriv.