Previous

Next

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 Agent

Managed Objects

Traps