Which SNMP version do not support encryption?

What kind of version for authentication and encryption method does PRTG support in snmp v3 ?

In the case of SHA for authentication, does PRTG support SHA-2 and SHA-3? Are the following cases also supported? SHA-256, SHA-384, SHA-512.

In the case of AES for encryption, does PRTG support AES-128, AES-192, and AES-256?

authentication encryption snmp snmpv3

5 Replies

Hello, currently SNMP supports only AES-128 Encryption. AES-192 and AES-256 are still not supported based on the Manual.

Thanks for your reply.

What about SHA ? Does PRTG support SHA-256, SHA-384, SHA-512 ?

Hello Jonathan, we were doing a research with our developers. They mentioned we're still using an older version of this library, so there is no support for the authentication methods you mentioned at the moment.

Hello, Most of our customers are using Cisco devices and they want to use the default AES-256 encryption. Is there a timeline for implementing AES-256 support? Thanks!

We dont have an specific date at the moment.

Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.

Overview of SNMP

The Simple Network Management Protocol (SNMP) is used to manage network devices. There are various types of network devices and the management interfaces (such as command line interfaces) provided by different vendors vary from each other, making network management more complex. SNMP is developed to simplify network management. SNMP is widely used on TCP/IP networks for network management. It provides unified interfaces to implement unified management of network devices of different types from different vendors.

SNMP has three versions: SNMPv1, SNMPv2c, and SNMPv3.

• SNMPv1 is the initial version of SNMP and provides the minimum network management functions. SNMPv1 provides authentication based on community names, causing low security. In addition, a limited number of error codes are returned in packets.
• SNMPv2c also provides authentication based on community names. Compared with SNMPv1, SNMPv2c has enhancements to standard error codes, data types (Counter64 and Counter32), and operations including GetBulk and Inform.
• SNMPv3 enhances security, and provides authentication and encryption based on the user-based security module (USM) as well as access control based on the view-based access control model (VACM). SNMPv3 supports the same operations as SNMPv2c.

Components in an SNMP System

An SNMP system consists of four key components: network management system (NMS), SNMP agent, managed object, and management information base (MIB). The NMS manages network elements on a network.

Each managed device contains an SNMP agent process, a MIB, and multiple managed objects. The NMS interacts with the SNMP agent on a managed device. When receiving an instruction from the NMS, the SNMP agent performs operations in the MIB on the managed device.

Figure 1-1 Components in an SNMP system

NMS

The NMS is a network manager that uses SNMP to manage and monitor network devices. The NMS software runs on NMS servers to implement the following functions:

• Sends requests to SNMP agents on managed devices to query or modify variables.

• Receives SNMP traps from SNMP agents on managed devices to learn the device status.

SNMP Agent

An SNMP agent is a process running on a managed device. It maintains data on the managed device, responds to requests from the NMS, and returns management data to the NMS.

• Upon receiving a request from the NMS, the SNMP agent performs the required operation in the MIB and sends the operation result to the NMS.

• If a fault or event occurs on a managed device, the SNMP agent sends an SNMP trap containing the current device status to the NMS.

Managed Object

A managed object is an object to be managed on a network device. A managed device may contain multiple managed objects, for example, a hardware component and parameters configured for the hardware or software (such as a routing protocol).

MIB

A MIB contains the variables that a managed device maintains. The MIB defines the attributes of the managed device, including the name, status, access rights, and data type of managed objects. The MIB can be regarded as an interface between the NMS and SNMP agent. Through this interface, the NMS queries and sets the variables maintained by a managed device.

A MIB uses a tree structure to store data, as shown in Figure 1-2. A tree node indicates a managed object, which is uniquely identified by a path starting from the root. This path is called an object identifier (OID). For example, the OID of system is 1.3.6.1.2.1.1, and the OID of interfaces is 1.3.6.1.2.1.2.

A subtree can be identified by the OID of the root node of the subtree. For example, the OID of the subtree with private as the root node is the OID of private, that is, {1.3.6.1.4}.

Figure 1-2 OID tree

You can specify the MIB objects that the NMS can access in MIB views. A MIB view is a subset of a MIB. You can set the status of objects in a MIB view to exclude or include. exclude indicates that the current view does not contain all nodes of the MIB subtree. include indicates that the current view contains all nodes of the MIB subtree.

SNMP Get

The NMS can send get requests to an SNMP agent to obtain data, as shown in Figure 1-3. After receiving a get request, the SNMP agent executes the corresponding instruction in the MIB and sends the result to the NMS.

SNMP get operations include Get, GetNext, and GetBulk. SNMPv1 does not support the GetBulk operation.

• Get: This operation allows the NMS to obtain one or more variables from the SNMP agent.
• GetNext: This operation allows the NMS to obtain one or more subsequent variables from the SNMP agent.

• GetBulk: This operation is equal to consecutive GetNext operations. You can set the number of GetNext operations to be included in one GetBulk operation.

Figure 1-3 SNMP get operations

SNMP Get Packets

Figure 1-4 shows the format of SNMPv1 and SNMPv2c get packets, which mainly consist of the version, community name, and SNMP protocol data unit (PDU). Packets of various SNMP operations are encapsulated in SNMP PDUs.

Figure 1-4 Format of SNMPv1 and SNMPv2c get packets

The fields in SNMPv1 and SNMPv2c get packets are as follows:

• Version: specifies the SNMP version. The value is 0 for SNMPv1 or 1 for SNMPv2c.
• Community name: is used for authentication between the SNMP agent and NMS. The value is a user-defined string of characters. The community name can be read or write. When SNMP get operations are performed, the read community name is used for authentication. When SNMP set operations are performed, the write community name is used for authentication.
• Request ID: specifies the unique ID of each request. It is used to match a request and the corresponding response.
• Non repeaters/Max repetitions: A GetBulk operation is equal to consecutive GetNext operations. The two parameters are used to set the number of GetNext operations to be included in one GetBulk operation.
• Error status: specifies the status of an error occurring when a request is processed.
• Error index: specifies the index of an error. If an exception occurs, information about the variable (in variable bindings) that causes the exception is provided.
• Variable bindings: specifies the list of variable names and corresponding values.

SNMPv2c get request packets sent by the device are obtained using a tool. Figure 1-5 shows an SNMPv2c GetRequest packet. Figure 1-6 shows an SNMPv2c GetNextRequest packet. Figure 1-7 shows an SNMPv2c GetBulkRequest packet.

Figure 1-5 SNMPv2c GetRequest packet

Figure 1-6 SNMPv2c GetNextRequest packet

Figure 1-7 SNMPv2c GetBulkRequest packet

Figure 1-8 shows the format of SNMPv3 get packets. The SNMP PDU format of SNMPv3 is the same as that of SNMPv2c. SNMPv3 support authentication, and the Context EngineID, Context Name, and SNMP PDU fields can be encrypted in SNMPv3 packets.

Figure 1-8 Format of an SNMPv3 get packet

The fields in an SNMPv3 get packet are as follows:

• Version: specifies the SNMP version. The value is 3 for SNMPv3.
• MsgID: specifies the sequence number of a request packet.
• MaxSize: specifies the maximum number of bytes in a message that a sender supports.
• Flags: This field occupies one byte and has three characteristics flags: reportableFlag, privFlag, and authFlag.
  • When the value of reportableFlag is 1, the receiver of SNMPv3 packets must return a Report PDU to the sender under conditions that can cause the generation of Report PDUs. When the value of reportableFlag is 0, the receiver of SNMPv3 packets does not return any Report PDU. Report PDUs are used only when the SNMP PDU portion cannot be decrypted (for example, decryption fails due to an incorrect key).
  • When the value of privFlag is 1, SNMPv3 packets are encrypted. When the value of privFlag is 0, SNMPv3 packets are not encrypted.
  • When the value of authFlag is 1, authentication is performed on SNMPv3 packets. When the value of authFlag is 0, authentication is not performed on SNMPv3 packets.

    Only the combination of privFlag=1 and authFlag=0 is not supported. Therefore, when configuring the SNMPv3 security level, pay attention to the following points: If the user group is of the privacy level, the user and alarm host must be of the privacy level. If the user group is of the authentication level, the user and alarm host can be of the privacy or authentication level.

• SecurityModel: specifies the security model used by messages. The sender and receiver must use the same security model.
• SecurityParameters: include information about the SNMP entity engine, user name, authentication parameters, and encryption parameters.
• Context EngineID: specifies the unique SNMP ID. The combination of Context EngineID and PDU type determines the application to which PDUs are to be sent.

• Context Name: determines the Context EngineID MIB view of the managed device.

SNMPv3 provides an authentication mechanism, and therefore is recommended. SNMPv3 GetRequest packets sent by the device are obtained using a tool. Figure 1-9 shows an encrypted SNMPv3 GetRequest packet. Figure 1-10 shows an unencrypted SNMPv3 GetRequest packet.

Figure 1-9 Encrypted SNMPv3 GetRequest packet

Figure 1-10 Unencrypted SNMPv3 GetRequest packet

Implementation of SNMP Get Operations

Implementations of get operations in different SNMP versions are similar. The only difference lies in that SNMPv3 supports identity authentication and encryption. The following uses the Get operation of SNMPv2c as an example.

In this example, the NMS intends to use the read community name public to obtain the value of the sysContact object on a managed device. The procedure is as follows:

1. The NMS sends a GetRequest packet to the SNMP agent. The fields in the packet are as follows:

   • Version: SNMP version that the NMS is using

   • Community name: public

   • PDU type: Get

   • MIB object: sysContact

2. The SNMP agent authenticates the SNMP version and community name in the packet. If authentication is successful, the SNMP agent queries the sysContact value from the MIB, encapsulates the sysContact value into the PDU of a response packet, and sends the response packet to the NMS. If the SNMP agent fails to obtain the sysContact value, it returns an error message to the NMS.

SNMP Set

The NMS can send set requests to an SNMP agent to complete configurations on the managed device, as shown in Figure 1-11. After receiving a set request, the SNMP agent executes the corresponding instruction in the MIB and sends the result to the NMS.

Using the SNMP set operation, the NMS can configure one or more parameters for an SNMP agent.

Figure 1-11 SNMP set operation

SNMP Set Packets

Figure 1-12 shows the format of SNMPv1 and SNMPv2c set packets. Generally, information about the SNMPv3 set operation is encrypted and encapsulated in an SNMP PDU. The format of the SNMP PDU in an SNMPv3 set packet is the same as that in an SNMPv2c set packet.

Figure 1-12 Format of SNMPv1 and SNMPv2c set packets

The fields in SNMPv1 and SNMPv2c set packets are as follows:

• Request ID: specifies the unique ID of each request. It is used to match a request and the corresponding response.

• Error status: specifies the status of an error occurring when a request is processed.
• Error index: specifies the index of an error. If an exception occurs, information about the variable (in variable bindings) that causes the exception is provided.
• Variable bindings: specifies the list of variable names and corresponding values.

Figure 1-13 shows an SNMPv2c SetRequest packet obtained by a tool.

Figure 1-13 SNMPv2c SetRequest packet

Implementation of the SNMP Set Operation

Implementations of the set operation in different SNMP versions are similar. The only difference lies in that SNMPv3 supports identity authentication and encryption. The following uses the set operation of SNMPv3 as an example.

In this example, the NMS intends to set the sysName object on a managed device to HUAWEI. The procedure is as follows:

1. The NMS sends a SetRequest packet without security parameters to the SNMP agent to request the values of Context EngineID, Context Name, and security parameters (information about the SNMP entity engine).
2. The SNMP agent returns a response that contains the requested parameters.
3. The NMS sends a SetRequest packet to the SNMP agent again. The fields in the packet are as follows:
   • Version: SNMPv3
   • Header: specifies the authentication and encryption modes.
   • Security parameters: The NMS calculates the authentication and encryption parameters based on the configured algorithm. The NMS then fills the authentication, encryption, and security parameters in the corresponding fields.
   • PDU: The NMS fills the obtained Context EngineID and Context Name in the corresponding fields, sets the PDU type to Set, enters the MIB object sysName and its value HUAWEI, and uses the configured encryption algorithm to encrypt the PDU.

4. The SNMP agent authenticates the SNMP version and community name in the packet. If authentication is successful, the SNMP agent sets the managed variable in the MIB according to the request, and sends a response packet to the NMS. If the SNMP agent fails to set the variable, it returns an error response to the NMS.

SNMP Traps

SNMP traps are notification messages sent by an SNMP agent to inform the NMS of alarms or events generated by the device. In this way, the administrator can learn the running status of the device in a timely manner.

There are two types of SNMP traps: trap and inform. SNMPv1 does not support inform. The difference between trap and inform is that, after an SNMP agent sends an alarm or event to the NMS through an InformRequest message, the NMS needs to reply with an InformResponse message, as shown in Figure 1-14.

Figure 1-14 SNMP trap operation

Format of SNMP Traps

Figure 1-15 shows the format of an SNMPv1 trap.

Figure 1-15 Format of an SNMPv1 trap

The fields in an SNMPv1 trap are as follows:

• Enterprise: specifies the type of a trap source (device that generates the trap).
• Agent addr: specifies the IP address of a trap source.
• Generic trap: specifies a common trap type, including coldStart, warmStart, linkDown, linkUp, authenticationFailure, egpNeighborLoss, and enterpriseSpecific.
• Specific trap: specifies the private trap information of an enterprise.
• Time stamp: specifies the time elapsed between the time when the network entity is reinitialized and the time when the trap is generated.
• Variable bindings: specifies the list of variable names and corresponding values.

Figure 1-16 shows an SNMPv1 trap obtained by a tool.

Figure 1-16 SNMPv1 trap

Figure 1-17 shows the format of SNMPv2c trap and inform messages. Generally, information about the SNMPv3 trap and inform operations is encrypted and encapsulated in SNMP PDUs. The format of the SNMP PDU in an SNMPv3 trap or inform message is the same as that in an SNMPv2c trap or inform message.

Figure 1-17 Format of an SNMPv2c trap or inform message

The fields in an SNMPv2c trap or inform message are as follows:

• Request ID: specifies the unique ID of each request. It is used to match a request and the corresponding response.
• Variable bindings: specifies the list of variable names and corresponding values.

SNMPv2c traps sent by the device are obtained using a tool. Figure 1-18 shows an SNMPv2c trap. Figure 1-19 shows an SNMPv2c inform message.

Figure 1-18 SNMPv2c trap

Figure 1-19 SNMPv2c inform message

Implementation of SNMP Traps

Implementation of the trap operation

Trap is a spontaneous activity of a managed device. The trap operation is not a basic operation that the NMS performs on the managed device. If a trap triggering condition is met on a managed device, the SNMP agent sends a trap to notify the NMS of the exception. In this way, the administrator can process the exception in a timely manner. For example, when a managed device completes a warm start, the SNMP agent sends a warmStart trap to the NMS.

The SNMP agent sends a trap to the NMS only when a module on the managed device meets the trap triggering condition. This reduces management information exchanged between the NMS and managed devices.

Implementation of the inform operation

Inform is also a spontaneous activity of a managed device. In contrast to the trap operation, the inform operation requires an acknowledgement. After a managed device sends an InformRequest message to the NMS, the NMS returns an InformResponse message. If the managed device does not receive an acknowledgement, it performs the following operations:

1. Saves the alarm or event in the inform buffer.
2. Repeatedly sends the InformRequest message until the NMS returns an acknowledgement or the maximum number of retransmission attempts is reached.
3. Records a corresponding alarm or event log.

Therefore, inform messages occupy more system resources than traps.

SNMP Port Numbers

SNMP packets are common UDP packets. SNMP defines two default port numbers:

• Port 161: This port number is used when the NMS sends Get, GetNext, GetBulk, and Set requests and the SNMP agent responds to these requests.

  This port number is configurable. Ensure that the port number used by the NMS to send request packets is the same as that used by the SNMP agent to respond to request packets.

• Port 162: This port number is used by the SNMP agent to send traps or inform messages to the NMS.

  This port number is configurable. Ensure that the port number used by the SNMP agent to send traps or inform messages is the same as that used by the NMS to listen to traps or inform messages.

Related Information

For details about how to configure and use SNMP, see the following chapters in different documents:

SNMP Configuration in the S12700 V200R013C00 Configuration Guide - Network Management and Monitoring

SNMP Configuration in the CloudEngine 12800 and 12800E V200R005C10 Configuration Guide - Network Management and Monitoring

SNMP Configuration in the Wireless Access Controller (AC and FITAP) V200R010C00 CLI-based Configuration Guide

SNMP under "Configuration > Administrator Guide > System" in the HUAWEI USG6000, USG9500, and NGFW Module V500R005C00 Product Documentation

SNMP Configuration under "Configuration > CLI-based Configuration > Network Management and Monitoring Configuration Guide" in the Huawei AR100, AR120, AR150, AR160, AR200, AR1200, AR2200, AR3200, and AR3600 V200R010 Product Documentation

SNMP Configuration under "Configuration > System Management" in the NE20E-S V8R10C10SPC500 Product Documentation

SNMP Configuration under "Configuration > System Management" in the NE40E V8R10C10SPC500 Product Documentation

• Overview of SNMP
• Components in an SNMP System
• SNMP Get
• SNMP Set
• SNMP Traps
• SNMP Port Numbers
• Related Information

Which of the following SNMP version does not support encryption?

Which version of SNMP uses encryption?

Is SNMP v3 encrypted?

Does SNMP use encryption?