• About ISSO
• Research Areas
• Projects
• Finished Projects and Archive
• Opensource Projects

Finished Projects

Network Security

SNMP - Interim Report

Abstract
At the Montreal IETF, the IETF Network Management Area Director announced the intention to form an advisory team to analyze the proposed, existing approaches for SNMP security. These approaches are commonly known as USEC and v2*. The general direction to the advisory group was to analyze the two approaches and provide recommendations to the Network Management community. This report provides a brief background on the activities and the status of work (as of November 1996) including a very high-level description of the recommendations.

Background
During the past several years, there have been a number of activities aimed at incorporating security improvements to the Simple Network Management Protocol (SNMP). This was one of the principal purposes of developing version 2 of SNMP. Unfortunately, strongly held differences on how to incorporate security into SNMP prevented the SNMPV2 Working Group from coming to closure on a single security approach. As a result, two approaches have emerged. These approaches are commonly known as USEC and v2*.

At the 36th IETF in Montreal, the Network Management Area Director announced the intention to form an advisory team to analyze the two proposed approaches for SNMP security. The chartered name for the group is the Security and Administrative Framework Evolution for SNMP Advisory Team. A copy of the August 27, 1996 announcement of the group's formation is contained in Appendix A to this report. Since the group has mostly referred to itself as just the "Advisory Team", that terminology will be used for the remainder of this report.

The group is made up of the following individuals:

David Harrington

Jeff Johnson

David Levi

John Linn

Russ Mundy (Chair)

Shawn Routhier

Glenn Waters

Bert Wijnen

As stated in the charter, the Advisory Team intended to publish one status report at the end of September and a white paper in early November. This would provide information for the network management community a month prior to the December 1996 IETF in San Jose. As with most IETF activities, the Advisory Team is supported essentially on a volunteer basis and progress was not as rapid as anticipated. Short but not particularly informative reports were provided in early October and November.

In accord with the Team's Charter, a large portion of the work was done via private mail list. This resulted in steady but slow progress in resolving differences between the two approaches and developing recommendations. In November, the Team decided that we were not satisfied with our progress on the mail list and that a face-to-face meeting was needed. As a result of this meeting, we resolved all of the larger issues necessary to define a merged, single approach. Though some areas of disagreement still exist, we do not believe that these are critical to the overall recommended approach. This report provides a very high-level description of the recommended approach from the Team. We hope to make additional information available prior to the IETF and plan on providing a fairly detailed presentation during the IETF meeting.

Advisory Team Process
As described in the Charter, our process was to identify the commonalities of the proposals that can be merged and the differences between the proposals including understanding the requirements that drove these differences. Based on these commonalities, differences and requirements, a set of recommendations and rationale were to be developed.

The Team reviewed material from mailing lists as well as USEC and v2* publications to identify areas of agreement and disagreement. We also discovered that there were some areas that we were initially unsure about whether there was agreement or disagreement between the approaches. The Team discussed and debated the various areas that were identified and categorized them into a set of issues to better focus our discussions. The names of the initial issues as posted to the snmp and snmpv2 mail lists on November 8th are:

Issue List (Version 0.9)

I. Timeliness Check Module

II. Authentication Module

III. Encryption Module

IV. Proxy Determination Module

V. Proxy Handling Module

VI. Access Control Module

VII. Varbind Processing Module

VIII. Overall Framework Issues

IX. The Layers Issue

Appendix B provides a short description for each of these issues. As we worked through our process, each of these issues had a listing of items on which USEC and v2* agreed and items on which there was disagreement. There was also a list of items that the Team was unsure about. The Team was able to reach agreement and develop recommendations on a number of items through the mail list but when November arrived, the Team was not satisfied with our progress. Consequently, we met to work out our differences on unresolved areas and confirm consensus in areas where there was less than full agreement. During the face-to-face meeting, there was a significant amount of discussion about how we should categorize the various issues and items. We worked rigorously to understand areas and causes of disagreement as well as requirements driving implementation choices. The result of our efforts is definition of a set of modules, sub-modules, structures and interfaces for SNMP messages and processing.

In both the mail list and meeting forums, we had good technical exchanges and debates including disagreements on SNMP philosophies and approaches but at no time in this process did any of the exchanges become acrimonious. As a result of these exchanges, we were able to define an approach which incorporates pieces and concepts from both USEC and v2*. Although the approach defined by the Team will require some changes to current USEC and v2* implementations, we believe this approach should result in the merger of USEC and v2* back into a single standard. The approach defined by the Team essentially constitutes our recommendations. The approach will be described at a high level in the following section of this report and with additional detail to be provided at the December 1996 IETF.

The Recommended Approach: A High Level View
The Team considered using either USEC or v2* as the basis for our recommendations but rejected that approach. We concluded that it would be more effective to use portions of both approaches in developing our recommendations rather than trying to modify either the USEC or v2* approach. The Team's recommended approach defines a set of modules, sub-modules and interfaces for an SNMP engine. It identifies interfaces to associated applications that can perform functions external to the SNMP engine. The approach also defines revisions to a part of the message structure.

The Administrative and Security Framework of the recommended approach are built to the greatest extent possible on the existing base. For example, the PDU portion of the message structure comes from RFC-1905. It was our general consensus that the user based security framework from the USEC approach was acceptable for the v2* approach and, therefore, provided a large amount of the detail for the security specific portions of our recommended approach. Additionally, we believe that the recommended approach is generally compliant with the current SNMP Standards Track RFCs (RFC-1902 through RFC-1908).

The requirements, functions and modules were carefully examined by the Team. During the process, we were able to define three modules (some with sub-modules) that perform the principal functions of an SNMP engine. The current names for these modules are Message Processing and Control, Security Model, and Local Processing. The Message Processing and Control module handles SNMP message creation and parsing functions. In some ways it can be thought of as the traffic cop for the snmp engine including determining if proxy handling is required for any particular snmp message. The Security Model module provides authentication and encryption functions. This module also checks the timeliness of certain snmp messages. The Local Processing module performs access control for varbind data, processing varbind data and trap processing.

The interfaces between these modules and applications for the principal SNMP functions, such as generating or receiving a request message, have been defined. In general, we believe that modules, sub-modules and applications can be replaced independently without effecting other components providing that the new components maintain the same interface. We believe that the recommended approach permits proxy functions as well as network management station functions to be placed in applications with defined interfaces rather than being entwined with the protocol engine. Another portion of the recommended approach identifies the data required in the message header.

To help define the recommended approach, we have developed illustrations for the message structure and scenario diagrams. The message structure illustrations show the header information needed for this modular approach while the scenario diagrams identify the sequence of events and the information that must pass between the modules and/or application. We are currently in the process of cleaning up the drafts of these illustrations and have begun documenting the textual descriptions of the events in the scenario diagrams.

Additional Material
We are continuing to work on the details of our recommended approach and will make a full presentation at the IETF. Additionally, we plan on making some additional material, such as scenario diagrams, available via the web prior to the IETF. When this material becomes available, it will be announced on both the snmp and snmpv2 mail lists.

Our recommended approach should be considered work in progress and not attacked because it incomplete. We know that there are some details and scenarios that we will not have time to document. We hope that the approach we present at the San Jose IETF will provide a sufficient basis for transfer to a Working Group that is chartered to carry this merger forward to a single network management standard for the IETF community.

Appendix A: Security and Administrative Framework Evolution Announcement

Appendix B: Orignial Advisory Team Issue List and Description Listing & short description of original set of issues

I. Timeliness Check Module
Within the User-Based Security Model:

• Verifies that the message has been received within an administratively-defined time window from its generation.
• Keeps notions of time for other entities in sync with those other (authoritative) entities.

II. Authentication Module
Within the User-Based Security Model it provides for:

• Verifying the integrity of a received message.
• Verifying the user on whose behalf a message was generated.

III. Encryption Module
Within the User-Based Security Model it privides for:

• Data-confidentiality of a portion of the message based on secrets associated with the user on whose behalf the message was generated.

IV. Proxy Determination Module
Determines whether the message should be processed locally or forwarded to the proxy handling module.

V. Proxy Handling Module
Performs the proxy forwarding operations to support various operational configurations and/or to accomodate incompatibilities between various entities.

VI. Access Control Module
Determines if the requested operation is allowed within the requested context and upon the objects in the varBindList.

VII. Varbind Processing Module
Performs the processing of the varBinds in the varBindList and interfaces to the instrumentation methods.

VIII. Overall Framework Issues
Defines Admin and Security Framework.

IX. The Layers Issue

• Defines the layers and their interfaces.
• Defines the layers that are replaceable.