Simple Network Management Protocol SNMPv2

Understanding SNMP

SNMP is an application-layer protocol that provides a message format for communication between SNMP managers and agents. SNMP provides a standardized framework and a common language used for the monitoring and management of devices in a network.

The SNMP framework has three parts:

•An SNMP manager

•An SNMP agent

•A MIB

The SNMP manager is the system used to control and monitor the activities of network hosts using SNMP. The most common managing system is called a Network Management System (NMS). The term NMS can be applied to either a dedicated device used for network management, or the applications used on such a device. A variety of network management applications are available for use with SNMP. These features range from simple command-line applications to feature-rich graphical user interfaces (such as the CiscoWorks2000 line of products).

The SNMP agent is the software component within the managed device that maintains the data for the device and reports these data, as needed, to managing systems. The agent and MIB reside on the routing device (router, access server, or switch). To enable the SNMP agent on a Cisco routing device, you must define the relationship between the manager and the agent.

The Management Information Base (MIB) is a virtual information storage area for network management information, which consists of collections of managed objects. Within the MIB there are collections of related objects, defined in MIB modules. MIB modules are written in the SNMP MIB module language, as defined in STD 58, RFC 2578, RFC 2579, and RFC 2580 (see the "MIBs and RFCs" section for an explanation of RFC and STD documents). Note that individual MIB modules are also referred to as MIBs; for example, the Interfaces Group MIB (IF-MIB) is a MIB module within the MIB on your system.

The SNMP agent contains MIB variables whose values the SNMP manager can request or change through Get or Set operations. A manager can get a value from an agent or store a value into that agent. The agent gathers data from the MIB, the repository for information about device parameters and network data. The agent can also respond to manager requests to Get or Set data.

Below image illustrates the communications relationship between the SNMP manager and agent. A manager can send the agent requests to get and set MIB values. The agent can respond to these requests. Independent of this interaction, the agent can send unsolicited notifications (traps or informs) to the manager to notify the manager of network conditions.

Communication Between an SNMP Agent and Manager

SNMPv2

SNMPv2 currently exists in at least three flavors, SNMPv2c, SNMPv2u, and SNMPv2*. SNMPv2c is community-based and is specified in RFCs 1902 through 1908. SNMPv2u is user-based and is specified in RFCs 1909 and 1910. SNMPv2* is a separate protocol developed by a corporate consortium, and is not an official IETF standard. It is based largely on SNMPv2u, but the two are not compatible. The original party-based specification for SNMPv2 found in RFCs 1441 through 1452 is now obsolete.

The only change in SNMPv2c, for the agent, is the addition of the GetBulkRequest, which allows for bulk data retrieval. The GetBulkRequest is similar to the GetNextRequest, except instead of just returning the next MIB variable, the agent will return as many MIB variables as it can send in a packet. Thus a GetBulkRequest is equivalent to n GetNext requests, where n is the number of variable bindings the agent has room to put in an SNMP packet.

SNMPv2u provides for message authentication and privacy using a user-based security model. When an SNMPv2u agent or manager sends a packet, a username is included in the packet. Both the manager and agent maintain tables that show which passwords are associated with which usernames, but the password is not actually transmitted in the packet. There is a one-byte entry in the packet header, called Qos or quality-of-service, which determines the nature of the packet.

Possible values for Qos are:

1. No authentication, no privacy
2. Authentication, no privacy
3. Authentication and privacy

If Qos is set to zero, meaning that the message is neither private nor authenticated, then processing of the message is similar to processing an SNMPv2c packet or an SNMPv1 packet. If Qos is non-zero, meaning that the message is authenticated, then the user-based authentication scheme is carried out as specified in RFC 1910.

The following is a brief summary of the authentication process:

The manager sends an authenticated request to an SNMPv2u agent

• The manager determines what username and password are to be used for authentication. These are specified on the command line, in a dialog box, etc.
• The manager passes the password through the password-to-key algorithm described in RFC 1910 to generate what is called an intermediary key.
• The manager determines the AgentID of the agent it is sending to. The manager may have this information stored in a table. If the manager does not know the AgentID of the agent it is sending to, the manager may determine this by sending an unauthenticated GetRequest to the agent, using the username "public" and requesting no variables. The header of the agent's response will contain an AgentID field, and the manager can simply read the AgentID from this header.
• The intermediary key is "keyed" with the AgentID to produce a final authentication key. The manager creates a temporary buffer which contains the 12-byte AgentID, followed by the 16-byte intermediary key, followed again by the AgentID. A 16-byte "digest" is then calculated over this buffer using the MD5 algorithm described in RFC 1321. This 16-byte digest is the final authentication key.
• The final authentication key is inserted into the "authDigest" field of the message header.
• A 16-byte digest is calculated over the entire packet using MD5. This is the message digest.
• The message digest is inserted into the "authDigest" field of the message header, overwriting the final authentication key.
• The packet is sent.

The agent receives an authenticated request from the manager.

• The agent reads the username from the message header.
• The agent determines which password is associated with the username via table lookup.
• The agent uses the password-to-key algorithm described in RFC 1910 to generate an intermediary key.
• The agent puts its AgentID in a temporary buffer, followed by the intermediary key, followed again by the AgentID. An MD5 digest is calculated over this buffer to determine the final authentication key.
• The "authDigest" field in the message header is saved to a temporary buffer.
• The final authentication key is put into the "authDigest" field of the message.
• A 16-byte digest is calculated over the entire packet using MD5.
• The calculated digest is compared to the saved digest. If the two match, then the message is authentic. Otherwise, the message is unauthentic. If the message is authentic, message processing continues normally. If the message is not authentic, the message is discarded and the statistics counter usecStatsWrongDigestValues is incremented.

If Qos is 2, then in addition to authentication, the packet is encrypted with DES (Data Encryption Standard). DES is an ANSI standard (there are no real RFCs for DES). RTIP-32 currently does not support DES.

SNMP Commands

The following SNMP input commands are supported:

GetRequest

Retrieves an individual object.

GetNextRequest

Retrieves the next object; used to traverse objects.

GetBulkRequest

Retrieves a large number of objects (SNMPv2 only).

SetRequest

Sets a managed object to a requested value. The entire SET request is verified before any sets are performed.

RTIP-32 sends the following SNMP commands:

Response

sends values in response to a GetRequest, GetNextRequest, GetBulkRequest, or SetRequest command

Trap

sent in response to a predefined event