SNMPv2 Support in IBM SystemView for AIX

Date: 1/24/96
By  Bert Wijnen (IBM T.J. Watson Research Center)
and Barry Sheehan (IBM SystemView for AIX Development)

INTRODUCTION

As announced back in July 1995, IBM SystemView for AIX is committed to OPEN Standards and would support Version 2 of the Simple Network Management Protocol (SNMPv2) when the Internet Engineering Steering Group (IESG) concluded its standardization efforts. On Jan 4th 1996, the IESG announced a new Internet Draft-Standard known as the Community-based Administrative Framework for SNMPv2 (SNMPv2c). This latest Draft-Standard is formally defined in Internet RFC documents 1901-1908.

Consequently, IBM SystemView for AIX V1R2 will be shipping introductory support for SNMPv2 in its 1Q96 deliverable. This is IBM SystemView's initial deployment of SNMPv2 technology intended to expose our customers to this leading edge technology. In addition, IBM is pleased to demonstrate the first commercial implementation of SNMPv2 in a major network management platform at ComNet 96, less than a month after the new Draft-Standard has been finalized.

SystemView for AIX will allow its customers to take their first steps into the SNMPv2 world by providing the following deliverables:

SNMPv1 DEFICIENCIES

The SNMPv2 effort within the IESG began several years ago, as several problems with the popular and widely deployed SNMPv1 protocol were identified by network managers. Among these problems were:
  1. Unreliable communication between Mid-Level-Managers and the central Manager.
    In the absence of a defined Manager to Manager protocol operation, Mid-Level-Managers (or peer Managers for that matter) could only communicate with another Manager via the Trap PDU or through some proprietary mechanism. The problem with using the Trap PDU was that the Mid-Level-Manager had no way of confirming whether its critical information ever reached its destination. The use of a proprietary mechanism could correct this problem, but at the expense of interoperability between management platforms from different vendors. A standardized communication operation was desired.
  2. Performance problems when retrieving large management information (MIB) tables.
    Accessing MIB tables which contained repeating variables required successive GetNext calls to an agent. If the MIB table was very large, it would take a considerable amount of time to complete all of the necessary transactions. A bulk retrieval mechanism was desired.
  3. Lack of SNMP security.
    SNMPv1 provided for access control through the use of a ``community string''. A management station had to provide the correct community string (password) within its SNMPv1 request in order for the agent to grant access to its management data. However, the community string was sent in clear text within the SNMPv1 request, unprotected from disclosure. A secure SNMP administrative framework was desired.

SNMPv2 IESG EFFORT

As a result of the problems identified above, the IESG chartered a working group over 3 years ago to solve some/all of these problems.

The effort expended within the IESG over the past years has resulted in many proposed models including (but not limited to) the SNMPv2-Party-Based security model and the Simple Configuration Model (SCM). SCM was designed to run on top of the SNMPv2-Party-Based security. IBM Research took part in prototyping both technologies. Although SCM provided some simplification for the end-user over the Party Based approach, the complexity in its configuration and implementation was problematic. IBM, along with most vendors in the industry, felt that the solution was not deployable and therefore did not release products based on the technology.

During 1995, the SNMPv2 Working Group within the Network Management area of the IETF came to the same conclusion. As a result, the Proposed-standard SNMPv2-Party-Based RFCs were moved to HISTORIC. The SCM model never made it into an RFC.

Several replacements to the Party-Based model were submitted during the latter part of 1995 (most notably SNMPv2u and SNMPv2*), but the SNMPv2 Working Group could not reach consensus on SNMPv2 Security and its Remote Agent Administration. The SNMPv2 Working Group did, however, agree on enhancements made in other areas of SNMPv2. As a result, the new Draft-Standard SNMPv2 Community-based Administrative Framework has emerged.

The IETF NM area director has dissolved the SNMPv2 working group for a cool-off period. Sometime later this year, it is believed that work on the SNMP security will restart at the requirements phase. It is our belief that a standards-based SNMP security should not be expected before well into 1997.

SNMPv2c HIGHLIGHTS

The new SNMPv2c Draft-Standard Protocol solves 2 of the 3 problems identified earlier for SNMPv1, namely Manager-to-Manager communication and Bulk MIB data retrieval.

The SNMPv2c protocol helps to solve the problem of reliable communication between Mid-Level-Managers and the central Manager by defining a new Inform PDU protocol operation. Besides providing better error-codes and exception-reporting, the SNMPv2 Inform PDU can be used to send acknowledged notifications between managers. IBM already provides a proprietary solution for reliable communication using an established TCP connection. The new Inform mechanism, however, allows for a standards-based solution fostering interoperability.

Through a new GetBulk PDU protocol operation, SNMPv2c now also provides for the Bulk retrieval of MIB table data, solving the second SNMPv1 shortfall.

As mentioned earlier, SNMPv2c does not solve the security and remote agent administration problem.

SNMPv2u HIGHLIGHTS

In the absence of an IESG standard for Secure SNMP, IBM SystemView for AIX is employing the User-Based Security Model for SNMPv2 (SNMPv2u) to perform Authenticated communication with agents who also support SNMPv2u. Authentication can prevent restricted SNMP operations from occurring unless the originator has knowledge of a secret password or key.

The model advocates simplicity and a robust solution to the core security problem. In an incremental next step, it will provide for a solution to the problem of remote agent administration.

Benefits of SNMPv2u include:

IBM SystemView for AIX solves the Security Problem today. SNMP Security is a universal problem and a universal requirement. Using this model, SNMP messages on the wire can now be protected against:

As a next logical step, an SNMP Remote Agent Administration MIB must be defined. This is an important problem, but not necessarily a universal requirement for every SNMPv2 agent. The SNMPv2u approach recognizes this and has plans to make the MIB optional. This is very important for SNMP agent implementations where footprint and complexity is an issue. A new public mailing list (usec-mib@fv.com) has been opened to refine the initial SNMPv2u User Configuration MIB as it was published in August 1995. IBM will take a leading role in this effort.

The documents describing the SNMPv2u model have been submitted for publication as experimental RFCs, so any vendor can now implement these security features and interoperate with other implementations. This model will also be submitted as a candidate for future IESG standardization.

PROTECTING MANAGEMENT APPLICATIONS USING WinSNMP

SystemView for AIX is introducing a NEW library for performing SNMP Communications. This library is based upon the WinSNMP/Manager API V1.1a OPEN specification which is the result of the successful collaboration of many companies within the computer industry. Although originally drafted for the Windows environment, the design of the API is platform independent. IBM is the first vendor to implement the WinSNMP API on the AIX/UNIX platform.

This new WinSNMP API has 3 modes of operation:

The TRANSLATED mode hides the underlying SNMP protocol details from the application. The protocol to be used and the parameters needed for this protocol are obtained by WinSNMP internals from a configuration database.

In UNTRANSLATED V1 mode, the application can pass specific parameters needed to communicate using the SNMPv1 protocol.

In UNTRANSLATED V2 mode, the application can pass specific parameters needed to communicate using the SNMPv2c protocol.

These 3 modes allow for transparent, concurrent communication with SNMPv1, SNMPv2c, and SNMPv2u agents!

There is currently no UNTRANSLATED SNMPv2u mode. Since it not yet an IESG standard, IBM is supporting SNMPv2u in TRANSLATED mode only. This insulates management applications from having to know about specific SNMPv2u information. If a future change is made to secure SNMP as a result of new IESG standardization activity, applications will not have to be modified! IBM will simply modify/replace the underlying SNMPv2 security engine in order to support whatever final standard emerges.

WinSNMP also provides the following benefits:

PROTECTING AGENT INSTRUMENTATION

The IBM SystemView common agent technology provides a sub-agent interface in the form of the SNMP DPI protocol, as specified in RFC1592. It also provides a mapping between DPI and DMI (DMTF). Customers who instrument their MIFs or MIBs in the form of a DPI or DMI subagent are also shielded from SNMP protocol dependencies.

IBM intends to make SNMPv1/SNMPv2c/SNMPv2u enabled agents available later this year.

COMNET 96

IBM is proud to demonstrate our initial SNMPv2c and SNMPv2u technology with other leading SNMP implementers. The demonstration will show how SystemView for AIX can interoperate with other SNMPv1/SNMPv2c/SNMPv2u compliant implementations including:

WHERE TO GET MORE INFORMATION

Last modified: Mon Mar 18 10:21:54 PST 1996