Skip to main content

3.1. Generating an Outgoing SNMP Message

3.1. Generating an Outgoing SNMP Message

This section describes the procedure followed by an SNMP engine whenever it generates a message containing a management operation (like a request, a response, a notification, or a report) on behalf of a user, with a particular securityLevel.

Step 1: Determine User Information

1a) Response or Report Message

If any securityStateReference is passed (Response or Report message), then information concerning the user is extracted from the cachedSecurityData. The cachedSecurityData can now be discarded.

  • The securityEngineID is set to the local snmpEngineID
  • The securityLevel is set to the value specified by the calling module

1b) Request or Notification Message

Otherwise, based on the securityName, information concerning the user at the destination snmpEngineID, specified by the securityEngineID, is extracted from the Local Configuration Datastore (LCD, usmUserTable).

If information about the user is absent from the LCD, then an error indication (unknownSecurityName) is returned to the calling module.

Step 2: Check Privacy Support

If the securityLevel specifies that the message is to be protected from disclosure, but the user does not support both an authentication and a privacy protocol then the message cannot be sent.

An error indication (unsupportedSecurityLevel) is returned to the calling module.

Note: Privacy (encryption) requires authentication. The combination noAuth + privacy is not allowed.

Step 3: Check Authentication Support

If the securityLevel specifies that the message is to be authenticated, but the user does not support an authentication protocol, then the message cannot be sent.

An error indication (unsupportedSecurityLevel) is returned to the calling module.

Step 4: Encrypt the Message (if required)

4a) With Privacy (authPriv)

If the securityLevel specifies that the message is to be protected from disclosure, then the octet sequence representing the serialized scopedPDU is encrypted according to the user's privacy protocol.

To do so a call is made to the privacy module that implements the user's privacy protocol according to the abstract primitive:

statusInformation =       -- success or failure
encryptData(
IN encryptKey -- user's localized privKey
IN dataToEncrypt -- serialized scopedPDU
OUT encryptedData -- serialized encryptedPDU
OUT privParameters -- serialized privacy parameters
)

Parameters:

  • statusInformation: Indicates if the encryption process was successful or not

  • encryptKey: The user's localized private privKey is the secret key that can be used by the encryption algorithm

  • dataToEncrypt: The serialized scopedPDU is the data to be encrypted

  • encryptedData: The encryptedPDU represents the encrypted scopedPDU, encoded as an OCTET STRING

  • privParameters: The privacy parameters, encoded as an OCTET STRING

Error Handling:

If the privacy module returns failure, then the message cannot be sent and an error indication (encryptionError) is returned to the calling module.

If the privacy module returns success, then:

  • The returned privParameters are put into the msgPrivacyParameters field of the securityParameters
  • The encryptedPDU serves as the payload of the message being prepared

4b) Without Privacy (noAuthNoPriv or authNoPriv)

If the securityLevel specifies that the message is not to be protected from disclosure, then:

  • A zero-length OCTET STRING is encoded into the msgPrivacyParameters field of the securityParameters
  • The plaintext scopedPDU serves as the payload of the message being prepared

Step 5: Set msgAuthoritativeEngineID

The securityEngineID is encoded as an OCTET STRING into the msgAuthoritativeEngineID field of the securityParameters.

Note: An empty (zero length) securityEngineID is OK for a Request message, because that will cause the remote (authoritative) SNMP engine to return a Report PDU with the proper securityEngineID included in the msgAuthoritativeEngineID in the securityParameters of that returned Report PDU. This is part of the discovery mechanism.

Step 6: Set snmpEngineBoots and snmpEngineTime

6a) Authenticated Message

If the securityLevel specifies that the message is to be authenticated, then the current values of snmpEngineBoots and snmpEngineTime corresponding to the securityEngineID from the LCD are used.

6b) Response or Report Message (unauthenticated)

Otherwise, if this is a Response or Report message, then the current value of snmpEngineBoots and snmpEngineTime corresponding to the local snmpEngineID from the LCD are used.

6c) Other Unauthenticated Messages

Otherwise (this is an unauthenticated Request or Notification), both snmpEngineBoots and snmpEngineTime are set to zero.

Step 7: Encode Time Values

The values of msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime are set to the values determined in step 6 and are encoded as INTEGER values into the securityParameters.

Step 8: Set msgUserName

The msgUserName field is set to the securityName and is encoded as an OCTET STRING into the securityParameters.

Step 9: Authenticate the Message (if required)

9a) With Authentication (authNoPriv or authPriv)

If the securityLevel specifies that the message is to be authenticated, then the message is authenticated according to the user's authentication protocol.

The msgAuthenticationParameters field is set to the serialization according to the rules of the authentication protocol of:

authenticationInformation =
authenticationAlgorithm(
IN authKey -- user's localized authKey
IN wholeMsg -- unauthenticated message
)

Process:

  1. The msgAuthenticationParameters field is temporarily filled with a value determined by the authentication protocol (typically 12 zero octets for HMAC-MD5-96 and HMAC-SHA-96)

  2. The authentication algorithm is run over the entire serialized message (wholeMsg)

  3. The output of the authentication algorithm (the MAC/digest) replaces the temporary value in msgAuthenticationParameters

Parameters:

  • authKey: The user's localized private authKey is the secret key used by the authentication algorithm

  • wholeMsg: The unauthenticated message (with msgAuthenticationParameters temporarily set to zeros)

  • authenticationInformation: The computed authentication digest/MAC

The computed authentication digest is placed into the msgAuthenticationParameters field.

9b) Without Authentication (noAuthNoPriv)

If the securityLevel specifies that the message is not to be authenticated, then a zero-length OCTET STRING is encoded into the msgAuthenticationParameters field.

Step 10: Finalize and Return

The completed wholeMsg is returned to the calling module along with statusInformation indicating success.

Message Generation Flow Summary

1. Lookup user info (from cache or LCD)
2. Validate security level support
3. Check authentication support
4. Encrypt scopedPDU (if authPriv)
└─> Set msgPrivacyParameters
5. Set msgAuthoritativeEngineID
6. Determine time values (boots/time)
7. Encode time values
8. Set msgUserName
9. Authenticate message (if authNoPriv or authPriv)
└─> Calculate MAC/digest
└─> Set msgAuthenticationParameters
10. Return complete wholeMsg

Special Cases

Discovery Messages

For discovery messages:

  • securityEngineID is empty (zero-length)
  • securityLevel is noAuthNoPriv
  • msgAuthoritativeEngineID is empty
  • msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime are zero
  • msgUserName is empty
  • msgAuthenticationParameters is empty
  • msgPrivacyParameters is empty

Notification Messages

For notification messages (Trap, Inform):

  • The notification originator is the authoritative engine
  • securityEngineID is the local snmpEngineID
  • Use local snmpEngineBoots and snmpEngineTime values

Error Conditions

The following error indications may be returned:

ErrorCondition
unknownSecurityNameUser not found in LCD
unsupportedSecurityLevelUser lacks required authentication or privacy protocol
encryptionErrorPrivacy module failed to encrypt data

Implementation Notes

  1. Cached Security Data: For Response and Report messages, security information is retrieved from cached data saved during the processing of the original Request message

  2. Time Synchronization: Authenticated messages use the time values from the LCD for the target authoritative engine. These values must be kept synchronized (see Section 4 on Discovery)

  3. Key Usage: The localized authKey and privKey for the specific securityEngineID must be used

  4. Message Size: The implementation must ensure the generated message does not exceed the maxMessageSize negotiated with the remote engine