it has not received widespread acceptance. That's because while the functional enhancements have been welcome, developers found the security facility for SNMPv2 too complex.
The IESG worked on an enhancement to SNMPv2. It completed the task in January and announced the revised standard as SNMPv2c. This version employs the SNMPv1 message wrapper, with its use of the community concept, which has a simple password-based security model. This "administrative framework" for SNMPv2 is termed community-based SNMPv2, which explains the
c
suffix.
The results of this effort have been one minor success and one major failure. The minor success is the tune-up of the functional aspects of SNMPv2. The major failure is in the area of security. SNMPv2c's password-based approach to security
is anything but secure. The IESG was unable to resolve the issue, and two competing approaches emerged.
The first approach is User-Based Security Model for SNMP, or SNMPv2u. SNMPv2u takes a minimalist approach to providing security and is centered on capabilities provided by the agent. (An agent is a software package running on any system that is to be managed, such as PCs, workstations, bridges, routers, servers, and hosts.) SNMPv2u provides the basic elements for network management security, namely, the ability to authenticate managers and provision for confidentiality of exchanged messages. (A manager or management system is a desktop computer running management software and operated by a user.)
The second approach is SNMPv2*. This more ambitious approach adds to SNMPv2u features implemented at the management station and deals with issues of remote configuration not addressed in SNMPv2u. SNMP is able to remotely configure an agent to include new Management Information Base (MIB) objects.
Because of this schism, the IESG will revisit the SNMP security matter. For this reason, we will instead look into the performance areas that the standard fixes.
Data Transfer Enhancements
SNMPv1 can generate considerable traffic when managers communicate with agents. That's because a single SNMPv1 transaction can exchange only a limited amount of data, forcing management workstations and agents to often generate multiple transactions. The result is a heavy load on the network.
To help streamline these exchanges, SNMPv2 adds a new command,
GetBulkRequest
.
GetBulkRequest
targets the one area of information exchange capable of generating the most traffic: retrieval of tables. A table represents a related set of information about a resource (e.g., a router) or activity (the traffic over a TCP connection). It is organized as a collection of rows of variables, with each row having the same sequence of variables.
With SNMPv1, you could retrieve information from
such a table only one row at a time. If a manager had to see an entire routing table, he or she needed a tedious series of get/response transactions, one for each row.
Using
GetBulkRequest
, a manager can retrieve the entire table with one transaction and even retrieve additional nontable information in that same transaction. Suppose a manager wants to retrieve a router's entire routing table plus the variable
sysUpTime
, so that it could associate a system time with the retrieved table. The manager issues a
GetBulkRequest
command that lists the variable
sysUpTime
, plus the variables that correspond to each of the fields in the table.
GetBulkRequest
also includes two parameters. The
nonrepeaters
parameter indicates how many of the listed variables are to return just one value. In our example, there is only one such variable,
sysUpTime
, so
nonrepeaters
is set to 1. The
max-repetitions
parameter indicates how many rows o
f the table are to be retrieved. If the manager knows the number of rows in the table,
max-repetitions
is set to that value. Otherwise, the manager makes an educated guess and, if necessary, issues additional
GetBulkRequest
commands to get additional rows. (See the figure "
GetBulkRequest
Reduces Network Transactions"
for more information.)
Another feature of SNMPv2 that improves the efficiency of data transfer is the nonatomic
Get
command. Management stations in both SNMP and SNMPv2 use
Get
to obtain the value of one or more variables. In SNMPv1, if a
Get
command lists multiple variables, and if the agent can't return a value for even one of those variables, the entire command is rejected. SNMPv2c's nonatomic
Get
command allows partial results to be returned (hence the term
nonatomic
). This lets the agent return those values that it can and ignore the rest of the command. Again, this improves efficiency by redu
cing the number of exchanges across the network.
Cooperation Among Managers
Another major concern users had with SNMPv1 was the difficulty in providing manager-to-manager cooperation. The only reliable way to send information between managers was through vendor-specific mechanisms. This isn't a practical solution for networks made up of a mix of machines from different vendors. As the number of end-user systems and networks in an enterprise network configuration grows, it becomes impractical to manage the system from one network management station. Many users would like to see a decentralized management strategy, in which there may be one or a few top-level manager stations, each controlling a number of lower-level manager stations that are responsible for their portion of the network.
To support manager-to-manager cooperation, SNMPv2 introduces an
Inform
command. A manager uses
Inform
to send unsolicited information to another manager. For example, through
Inform
, a manager notifies another manager when an unusual event occurs, like the loss of a physical link or an excessive rate of traffic at some point in the network. Such unsolicited notifications provide an ideal tool for configuring a decentralized network management scheme.
Higher-level managers need not concern themselves with the details of remote parts of the network until a local event that requires central attention occurs. For example, the local manager can use
Inform
to alert the central manager that a part of its subnet has disappeared. This ability for one manager to alert another is lacking in SNMPv1.
"A Distributed SNMP Management Scheme"
illustrates one kind of network configuration possible with SNMPv2.
SNMP's Future
When and whether the security portion of SNMPv2 gets resolved is anyone's guess. As mentioned earlier, the IESG will revisit the issue. Because the project will start at the requirements level, it's a
chance to begin with a clean slate and resolve the security issue once and for all.
Meanwhile, the functional enhancements provided in SNMPv2c should attract wide support. The technology is stable, and the cost of implementation is low for those who have implemented network resources using SNMPv1. We can expect to see a wide array of offerings from software and equipment vendors. For example, IBM announced a version of SystemView, its AIX network management software, that is compliant with the new protocol and supports the SNMPv2u security mechanism.
For More Information
SNMP
http://www.simple-times.org/pub/simple-times/usec
http://www.snmp.com
Patching the Cracks in SNMP
