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.