SNMPv2 -- Extending the services of SNMP
Security, Large System Management, Distributed-Managers
With the increasing growth and sophistication of networks, concerns about the lack of standard
services for security, manager to manager communications, and inefficiencies in the SNMP protocols led to several new standardization efforts. Through these efforts, a new set of
network management standards, SNMP version 2 (also known as SNMPv2), were published as a series of Requests For Comment (RFC).
Based on the original SNMP standards, SNMPv2 offers enhancements in providing users with better security, more flexibility in establishing heirarchical management structures, and simpler MIB discovery through the use of the GetBulk PDU in place of several iterative GetNext operations. Many of the new features are derived from Secure SNMP, the System Management Protocol, and portions of the remote monitoring (RMON) MIB. Going beyond the ability to manage communications equipment, the developers of SNMPv2 also considered general applications and system management in the design.
Main features of SNMPv2
Table Management... Creating and Deleting Rows
One of the features considered in the development of SNMPv2 was the addition of PDUs to support the creation and deletion of rows from the table. They weren't added. An alternative
approach based on the RMON row manipulation scheme was adopted however. In this approach, the MIB structure contains two useful features. An object type of read-create has
been added. When a manager issues set requests to all read-create elements of a non-existant row, the agent adds the row to its table. Creation can be performed through either a
createAndWait or a createAndGo method. In the createAndWait method, two phases are performed, with the manager first issuing sets to create the rows, followed by gets to verify
that the intended row has been created. Once the manager has verified all information, a MIB variable in the row is set to activate the inforamtion. In the createAndGo method, the
manager merely issues the set operations needed to create the row, and the agent automatically creates the row. Depending on the criticality of the information being added to the table,
each approach has its place. With most SNMP operations being transmitted over an unguaranteed delivery service, only those rows not critical to management operations should be
created using the createAndGo operation. If performance and network overhead are the overriding concerns, the createAndGo operation becomes more appropriate.
Security... Protecting Managed Elements From Unauthorized Management Activity
In response to significant concerns in the security of deploying SNMP in mission critical systems on publicly available networks, security features from S-SNMP are included in
SNMPv2. SNMP security was limited to the use of a community string in each SNMP PDU. Problems in the use of this string included the fact that it is transmitted in plaintext, making
the string easy to capture, and no standard mechanisms for the management of security information. A further complicating factor is that many of the standard network management
products do not provide easily accessible mechanisms for the management and control of the community strings use in conversing with agents. As a result, many equipment vendors
chose to provide SNMP services for monitoring only, leaving configuration and control activities for the domain of remote login (telnet) access to their equipment. While passwords are
no more secure than the SNMP community strings, the developer's could easily control the configuration and monitoring of username/password privileges in managing their equipment.
Where the SNMP security was limited to password type checks of the community name field of the PDUs, SNMPv2 adds support for integrity, confidentiality, authentication, and access control. With these services, systems can be more safely integrated into public networks with a significantly reduced risk of either inadvertent or malicious tampering with the system. Largely derived from the S-SNMP standard, SNMPv2 security consists of two major components:
The SNMPv2 Party MIB contains information defining authorized "parties", the context in which they are to interact with the local agent's services, access privelages, views of the MIB, security protocols to be used, and control information to manage the secure information exchange. The party group contains a list of local and remote users. The access priveleges database group defines the access portion of the security policy for the local entity. Information in the access table includes the affected parties, their operating context and associated access priveleges. The MIB view table defines subsets of the entities MIB on MIB tree branch nodes that can be referenced by indices through the view table.
Extensions to the SNMP base protocol provide authentication and privacy. Depending on the party initiating the request, these services can be selectively enabled. An "authInfo" field provides information that can be used to authenticate the contents of received requests. When the authentication services are used, the authInfo field contains a message digest field and timestamp information. The message digest field, computed using the MD5 algorithm, provides the receiving station with adequate information to authenticate that the originator of the message is the expected party. Timestamp information is used to help protect against the threat of an unauthorized user replaying SNMP messages, potentially disrupting the operation of the addressed station. Privacy can be provided through encryption of the majority of the SNMP packet, including the authentication information if authentication is selected for the communicating parties.
While the SNMP security services are full-featured, be aware that they only serve to protect the SNMP service portion of the network services. Use of the SNMP security features will not protect the privacy of other network traffic such as Telnet, World Wide Web, FTP and others. Other mechanisms must be in place in user networks and equipment to provide a complete set of security features.
Manager to Manager MIB
The Manager to Manager MIB has been added to SNMP to support information transfer between SNMPv2 capable managers. This MIB is largely based on the remote monitoring
(RMON) MIB definitions of the alarm and event groups. The alarm group is a table of thresholds that can be configured by managers to indicate points at which alarms are to be
generated. For example, a manager can setup the alarm table to generate an alarm any time a queue depth rises above a specified threshold, with a separate alarm set for generation
whenever the same queue falls below some other threshold. Where the alarm group (table) provides a mechanism for monitoring the state of MIB variables, the Event group controls the
record keeping and notification services for system events. As alarms and/or other notifications occur within a managed system, the Event table can be used to count occurrences of an
event, control the transmission of event notification to other system elements (managers, other processes). To receive events, a management system adds an entry to the monitored
systems event table, specifying criteria such as the conditions to trigger an event, recipients of the event notification, and the amount of time that the event entry is to be sustained. On
expiration of the event timer, the entry is removed from the target system's event table, helping to avoid conditions in which managers continually place entries in the event table
The SNMPv2 protocol operations extend the capabilities provided by earlier versions of SNMP. Most notably, GetBulk provides a mechanism to retrieve large amounts of data that would have required multiple GetRequest or GetNextRequests in version 1. The SNMPv2 protocol operations include:
Where the first versions of SNMP most typically use UDP, the SNMPv2
call out a series of protocol mappings to help standardize the use of SNMPv2 in environments beyond
TCP/IP. Mappings have been defined for AppleTalk (RFC1419), Novell's Internetwork Packet Exchange (IPX) (RFC1420), and OSI transport services (RFC 1418). For the most part, the
mappings tend to specify connectionless, datagram services, retaining the architectural goal of being able to manage networks in the worst of conditions. SNMP transfers require only a
minimal set of network services, and avoid the use of services that can aggravate the system through retransmissions when network services are already degraded.
With support for SNMPv2 agents becoming widespread, and management products beginning to emerge, SNMPv2 offers a full featured set of services to help in the management of network services. The additional MIB definitions further standardize network management services. When combined with security and protocol enhancements, users and administrators are better equipped to take control of the network operations. The SNMPv2 features begin to blur some of the distinctions that had been (and will probably continue to be) drawn between the simplicity and low overhead of SNMP and the sophistication and expense of the OSI based CMIP services.
Miller, M. "Managing Internetworks with SNMP" 1993, M&T Books, New York, N.Y.
Rose, M, "The Simple Book -- An Introduction To Internet Management", Prentice Hall Englewood Cliffs New Jersey, 1994
Stallings, W., "SNMP, SNMPv2, and CMIP, The Practical Guide to Network-Management Standards," 1993 Addison-Wesley Publishing Company, Reading Massachusetts