SNMP Technology White Paper

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Contents

Overview· 1

Technical background· 1

Benefits· 1

SNMP implementation· 1

SNMP network structure· 1

NMS· 2

Agent 2

MIB· 2

SNMP versions· 3

SNMPv1· 4

SNMPv2c· 4

SNMPv3· 4

SNMP operations· 4

SNMP messages· 5

SNMPv1 message· 5

SNMPv2c message· 6

SNMPv3 message· 6

SNMP mechanism·· 7

SNMPv1 and SNMPv2c mechanism·· 7

SNMPv3 mechanism·· 8

SNMP silence· 9

H3C implementation of SNMP· 9

Application scenarios· 9

References· 10

 

Overview

Technical background

With the fast development of the Internet, two issues were introduced:

·          The increase of networks and network devices makes it hard for the administrators to monitor the status of all the devices in time, and find and correct network faults.

·          Network devices might be from different vendors. If each vendor provides an independent set of management interfaces (for example, command lines), network management might become more and more complicated.

To solve the above mentioned issues, a set of standards (SNMP) covering service, protocol and management information base (MIB) is introduced.

Benefits

SNMP is an application-layer protocol between an NMS and several agents. It defines the standardized management framework, common languages in communication, security and access control mechanisms used in monitoring and managing devices in a network. The administrators can query device information, modify device parameters, monitor device status, and enable automatic detection of network faults and generation of reports by using SNMP.

SNMP features the following advantages:

·          TCP/IP-based standard protocol, with UDP as the transportation layer protocol.

·          Automatic network management. The administrators can search and modify information, find and diagnose network issues, plan for network growth, and generate reports on network nodes.

·          Shielding of the physical differences between various devices, realizing automatic management of products from different vendors. Offering only the basic set of functions, SNMP makes the management tasks independent of both the physical features of the managed devices and the underlying networking technology. As a result, SNMP achieves effective management of devices from different vendors.

·          Combination of simple request-reply mode and active notification mode, timeout and retransmission mechanism.

·          Few packet types and simple packet format, which facilitates resolution and implementation.

·          Authentication and privacy mechanisms provided in SNMPv3, which enhances security by user based and view based access control function.

SNMP implementation

SNMP network structure

An SNMP enabled network contains a Network Management Station (NMS), agent, and MIB.

NMS

An NMS manages an SNMP-enabled network. It uses SNMP to manage and monitor the network devices in the network. An NMS can be a server that manages the network or an application that performs management function on a device.

An NMS can send a request to an agent to query or modify one or more variables. At the same time, the NMS can receive traps sent by the agent to obtain the status of the managed device.

Agent

An agent works on a managed device to receive and handle requests from the NMS, and sends notifications to the NMS when events, such as an interface state change, occur.

Upon receiving an NMS request, an agent completes the querying or modification operations, and sends the result to the NMS. If the device fails or other events occur, the agent will send unsolicited traps to the NMS to notify it of the status changes of the device.

MIB

MIB

A Management Information Base (MIB) is a collection of all the managed objects. It defines a set of characteristics associated with the managed objects, such as the object identifier (OID), access right and data type of the objects. Each agent has its own MIB. An NMS can read or write the managed objects in the MIB. The relationship between NMS, agent, and MIB is shown in Figure 1.

Figure 1 Relationship between NMS, agent, and MIB

 

MIB view

A MIB view represents a set of MIB objects (or MIB object hierarchies) with certain access privileges and is identified by a view name. The MIB objects included in the MIB view are accessible while those excluded from the MIB view are inaccessible.

OID and subtree

A MIB stores variables called "nodes" or "objects" in a tree hierarchy and identifies each node with a unique OID. An OID is a dotted numeric string that uniquely identifies the path from the root node to a leaf node. As shown in Figure 2, the managed object system can be uniquely identified by a string of numbers {1.3.6.1.2.1.1}. This string of numbers is the OID of the managed object system.

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

Figure 2 MIB tree

 

Subtree mask

A subtree OID used with a subtree mask defines a view subtree. A subtree mask is in the hexadecimal format. After it is converted to binary bits, each bit corresponds to a node of the OID, where:

·          1 means full match. The OID of the MIB object to be accessed must be identical to the subtree OID.

·          0 means wildcard match. The OID of the MIB object to be accessed can be different from the subtree OID.

Assume that the subtree mask is 0xDB (11011011 in binary) and the subtree OID is 1.3.6.1.6.1.2.1. Their relationship is as shown in Figure 3. The view determined by them includes all the nodes under the subtree whose OID is 1.3.*.1.6.*.2.1, where * represents any number.

Figure 3 Subtree OID and subtree mask

 

NOTE: ·      If the number of bits in the subtree mask is greater than the number of nodes of the OID, the excessive bits of the subtree mask will be ignored during subtree mask-OID matching. ·      If the number of bits in the subtree mask is smaller than the number of nodes of the OID, the short bits of the subtree mask will be set to 1 during subtree mask-OID matching. ·      If no subtree mask is specified, the default subtree mask (all ones) will be used for mask-OID matching.

 

SNMP versions

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

SNMPv1

SNMPv1 is the first version of the SNMP protocol, providing a minimum network management function. The Structure of Management Information (SMI) and MIB of SNMPv1 are simple and have many security defects.

SNMPv1 uses community names for authentication. To access an SNMP agent, an NMS must use the same community name as set on the SNMP agent. If the community name used by the NMS differs from the community name set on the agent, the NMS cannot establish an SNMP session to access the agent or receive traps from the agent.

SNMPv2c

SNMPv2c uses community names for authentication. SNMPv2c is compatible with SNMPv1, but supports more operation types such as GetBulk, more data types such as Counter32, and more error codes.

SNMPv3

SNMPv3 uses a user-based security model (USM) to secure SNMP communication. You can configure authentication and privacy mechanisms to authenticate and encrypt SNMP packets for integrity, authenticity, and confidentiality.

USM

USM introduces the concepts of username and group. You can set the authentication and privacy functions. The former is used to authenticate the validity of the sending end of the authentication packets, preventing access of illegal users; the latter is used to encrypt packets between the NMS and Agent, preventing the packets from being intercepted. USM ensures a more secure communication between SNMP NMS and SNMP Agent by authentication with privacy, authentication without privacy, or no authentication no privacy.

VACM

View-based Access Control Model (VACM) defines five elements, group, security level, context, MIB view, and access policy for user access control. You can define different groups on the same SNMP entity; these groups are bound with MIB views. In addition, you can define multiple users in one group. When a user accesses the management information, he can access only the objects defined by the corresponding MIB view. mode controls access to MIB objects by assigning MIB views to SNMP communities or users.

SNMP operations

SNMP provides the following basic operations:

·          Get—An NMS retrieves the value of an object node in an agent MIB.

·          GetNext— An NMS retrieves the value of the next object node in an agent MIB.

·          Set—An NMS modifies the value of an object node in an agent MIB.

·          Response—An agent sends a response to an NMS.

·          Trap—An agent sends an unsolicited response to report events to an NMS.

·          Inform—An agent sends an unsolicited response to report events to an NMS. The NMS must send an acknowledgement to the agent after receiving an inform packet.

By default, the device sends the first four kinds of packets to UDP port 161, and the agent sends traps and informs to UDP port 162. By using two different port numbers, a single device can act as an agent and an NMS at the same time.

SNMP messages

The following packets are defined based on different versions and operations of SNMP.

SNMPv1 message

Figure 4 SNMPv1 message format

 

As shown in Figure 4, an SNMPv1 message contains the following fields:

·          Version—SNMP version.

·          Community—Community name, used for the authentication between an agent and the NMS. Community name falls into read and write. If NMS performs Get or GetNext operation, read community name is used for authentication; if NMS performs Set operation, write community name is used for authentication.

·          Request ID—Matches a response to a request. SNMP assigns a unique ID to each request.

·          Error status—Indicates the errors when the agent processes the request, including noError, tooBig, noSuchName, badValue, readOnly, and genErr.

·          Error index—Provides information about the variables that caused the error when an error occurred.

·          Variable bindings—Contains a variable name and value.

·          enterprise—Type of the device that generates traps.

·          Agent addr—Address of the device that generates traps.

·          Generic trap—Includes coldStart, warmStart, linkDown, linkup, authenticationFailure, egpNeighborLoss, and enterpriseSpecific.

·          Specific trap—Specific trap information for a vendor.

·          Time stamp (the value of sysUpTime)—The amount of time between the time when the SNMP entity sending this message reinitialized and the time when traps were generated.

SNMPv2c message

Figure 5 SNMPv2c message format

 

Compared with SNMPv1, GetBulk packets are added in SNMPv2c. GetBulk operation corresponds to GetNext operation. In a GetBulk operation, the setting of Non repeaters and Max repetitions parameters enables NMS to obtain data of many managed objects from an agent.

In SNMPv2c, the trap message format is different from that in SNMPv1. SNMPv2c trap PDUs use the format of SNMPv1 Get/GetNext/Set PDUs, and sysUpTime and snmpTrapOID are used as variables in variable bindings to create a packet.

SNMPv3 message

The SNMPv3 message format is modified, but the PDU format is the same as that in SNMPv2c. Figure 6 shows the SNMPv3 message format.

Figure 6 SNMPv3 message format

 

The entire SNMPv3 message can be authenticated, and EngineID, ContextName, and PDU are encrypted. RequestID, MaxSize, Flags, SecurityModel, and SecurityParameters form the SNMPv3 message header.

The following describes the main fields in an SNMPv3 message:

·          RequestID—Request ID.

·          MaxSize—Maximum size of the message that the sender can send and the maximum size of the message that the sender can receive.

·          Flags—Message flag, which occupies one byte. Only the lowest three bytes are valid. 0x0 indicates no authentication no privacy, 0x1 indicates authentication without privacy, 0x3 indicates authentication with privacy, and 0x4 indicates to send a report PDU.

·          SecurityModel—Message security model, in the range 0 to 3. 0 indicates any model, 1 indicates SNMPv1 security model, 2 indicates SNMPv2c security model, and 3 indicates SNMPv3 security model.

·          ContextEngineID—Uniquely identifies an SNMP entity. For a received message, this field defines how this message will be processed. For a sent message, this field is provided by the sender.

·          ContextName—Identifies a context. Each contextName must be unique within an SNMP entity.

SecurityParameters includes the following fields:

·          AuthoritativeEngineID—Specifies the snmpEngineID of the authoritative SNMP engine involved in the exchange of the message, used for identification, authentication and encryption for an SNMP entity. This field refers to the source for a trap, response, or report, and to the destination for a Get, GetNext, GetBulk, or Set operation.

·          AuthoritativeEngineBoots—Specifies the snmpEngineBoots value at the authoritative SNMP engine involved in the exchange of the message. It indicates the number of times that this SNMP engine has initialized or reinitialized itself since its initial configuration.

·          AuthoritativeEngineTime—Specifies the snmpEngineTime value at the authoritative SNMP engine involved in the exchange of the message. It is used for time window check.

·          UserName—Specifies the user (principal) on whose behalf the message is being exchanged. Usernames configured on NMS and Agent must be the same.

·          AuthenticationParameters—A key used in authentication calculation. If no authentication is performed, this field is null.

·          PrivacyParameters—A parameter used in privacy calculation, for example, the value used for generating the initialization vector (IV) in the DES CBC algorithm. If no privacy is used, this field is null.

SNMP mechanism

SNMPv1 and SNMPv2c mechanism

SNMPv1 and SNMPv2c use almost the same mechanism. New error codes and GetBulk operation are added in SNMPv2c. The following describes the SNMPv1/v2c mechanisms.

Get operation

NMS wants to obtain the value of the node sysName of a managed device (the sysName object is in the accessible view), using public as the read community name:

1.        The NMS sends a Get request to the agent, with the version set to 1, community to public, and name 1 in variable bindings in the PDU to sysName.0.

2.        The agent sends a get response to the NMS. If the operation succeeds, the field Value1 in Variable bindings in the response PDU is the device name (for example, Agent010-H3C). If the operation fails, the reason for the error will be added to the Error status field, and error location will be added to the Error index field.

Figure 7 Get operation

 

GetNext operation

The NMS wants to obtain the value of the node sysLocation next to node sysName of a managed device (the sysName and sysLocation objects are in the accessible view), using public as the read community name:

1.        The NMS sends a GetNext request to the agent, with the version set to 1, community to public, and Name 1 in variable bindings in the PDU to sysName.0.

2.        The agent sends a GetNext response to the NMS. If the operation succeeds, the value of Name 1 in Variable bindings in the response PDU is the next node sysLocation.0 of node sysName.0, and the value of Value 1 is, for example, Beijing China. If the operation fails, the reason for the error will be added to the Error status field, and position will be added to the Error index field.

Figure 8 GetNext operation

 

Set operation

The NMS wants to set the value of node sysName of the managed device to Device01, using private as the read community name:

1.        The NMS sends a Set request to the agent, with the version set to 1, community to private, Name 1 in variable bindings in the PDU to sysName.0, and Value1 to Device01.

2.        The agent sends a Set response to the NMS. If the operation succeeds, the value of Value1 in Variable bindings in the response PDU is the new name of the device (for example, Device01). If the operation fails, the reason for the error will be added to the Error status field, and position will be added to the Error index field.

Figure 9 Set operation

 

Trap operation

If abnormalities occur on a device, the agent will notify NMS by sending unsolicited traps. For example, if the cable on a port of the device is removed, Agent will send a linkDown trap to the NMS. In the trap, the values of the Version, Community, enterprise, Generic trap fields are 1, public, the value of sysObjectID.0 (for example, enterprises.25506), and linkDown, respectively, and the Variable bindings field contains the interface information.

Figure 10 Trap operation

 

SNMPv3 mechanism

Compared to the SNMPv1 and SNMPv2c mechanisms, authentication, encryption, and decryption are added in SNMPv3 mechanism. In the following example, Get operations are performed using authentication and encryption.

1.        The NMS sends a Get request without any authentication and encryption parameters. In the request, the Flags field is set to 0x4 to obtain the values of the related parameters such as contextEngineID, contextName, AuthoritativeEngineID, AuthoritativeEngineBoots, and AuthoritativeEngineTime.

2.        The agent processes the request, and sends a report, which contains the values of the above parameters.

3.        The NMS sends a Get request again to the agent. In the request, the main fields are set as follows: Version to 3, the parameter values obtained in step 2 are added to the corresponding fields, the value of Name1 field in Variable bindings in the PDU to sysname.0, AuthenticationParameters is calculated by the configured authentication algorithm, PrivacyParameters is calculated by the configured encryption algorithm, and encrypt the PDU data using the configured privacy protocol.

4.        The agent authenticates the Get request first. If the Get request passes the authentication, the agent will decrypt the PDU. If decryption succeeds, the agent will obtain the value of sysName.0, and add the device name (for example, Agent010) to the field Value1 in Variable bindings in the response PDU. If authentication or decryption fails, or obtaining parameter values fails, the error reason will be added to the Error status field, and the error location will be added to the Error index field. At last, Agent will encrypt the PDU, set the parameters contextEngineID, contextName, AuthoritativeEngineID, AuthoritativeEngineBoots, AuthoritativeEngineTime, AuthenticationParameters and PrivacyParameters, and then send a response.

Figure 11 SNMPv3 get operation

 

SNMP silence

SNMP silence enables the device to automatically detect and defend against SNMP attacks.

After you enable SNMP, the device automatically starts an SNMP silence timer and counts the number of packets that fail SNMP authentication within 1 minute.

·          If the number of the packets is smaller than 100, the device restarts the timer and counting.

·          If the number of the packets is equal to or greater than 100, the SNMP module enters a 5-minute silence period, during which the device does not respond to any SNMP packets. After the 5 minutes expire, the device restarts the timer and counting.

H3C implementation of SNMP

An H3C device supports SNMPv1, SNMPv2c, and SNMPv3.

To make SNMPv1 and SNMPv2c compatible with SNMPv3, you can configure group, user, and view for these two versions and make sure the community name configured on the NMS is identical with the username configured on the device.

You can enable multiple SNMP versions on the device. For the NMS to access the agent, configure the same SNMP versions on the NMS and device.

Application scenarios

As shown in Figure 12, the vendors of the network devices are different, and device models are different. The NMS uses SNMP to monitor and manage the devices. The devices allow management only from the NMS at 1.1.1.1 and send traps and informs to the NMS when an event occurs.

Figure 12 SNMP network diagram

 

References

·          RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets

·          RFC 2578: Structure of Management Information Version 2 (SMIv2)

·          RFC 2579: Textual Conventions for SMIv2

·          RFC 3411: An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks

·          RFC 3412: Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)

·          RFC 3414: User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)

·          RFC 3415: View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)