2.3.14 SNMP Version 3 (snmpv3)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00

Chair(s):

Russ Mundy <mundy@tislabs.com>
David Harrington <dbh@cabletron.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>

Mailing Lists:

General Discussion:snmpv3@lists.tislabs.com
To Subscribe: snmpv3-request@lists.tislabs.com
Archive: ftp://ftp.tislabs.com/pub/ietf/snmpv3

Description of Working Group:

The SNMPv3 Working Group is chartered to prepare recommendations for the next generation of SNMP. The goal of the Working Group is to produce the necessary set of documents that will provide a single standard for the next generation of core SNMP functions.

During the past several years, there have been a number of activities aimed at incorporating security and other improvements to SNMP. Unfortunately, strongly held differences on how to incorporate these improvements into SNMP prevented the SNMPV2 Working Group from coming to closure on a single approach. As a result, two different approaches (commonly called V2u and V2*) have emerged.

The Security and Administrative Framework Evolution for SNMP Advisory Team (the Advisory Team) was formed to provide a single recommended approach for SNMP evolution. The technical starting point for this Working Group will be the recommended approach provided by the Advisory Team.

This approach provides for the convergence of concepts and technical elements of V2u and V2*. The SNMPv3 Working Group is not starting new work and will use as many concepts, technical elements and documentation as practical from the V2u and V2* activities. Previous delays in providing a single standard for the next generation of SNMP core functions dictate that the Working Group move forward as quickly as possible to document and publish Internet Drafts and RFC's. To this end, the Working Group will make use of as much existing documentation as practical. Additionally, functional changes beyond those needed to provide a single approach will be strongly discouraged.

Timely completion of a single approach for SNMPv3 is crucial for the continued success of SNMP. Recognizing the need for prompt completion, the following objectives are provided to the Working Group:

- accommodate the wide range of operational environments with differing management demands;

- facilitate the need to transition from previous, multiple protocols to SNMPv3;

- facilitate the ease of setup and maintenance activities.

Note: SNMPv3 planned specifications:

SNMPv3 Modules and Interface Definitions SNMPv3 Message Processing and Control Module Specification SNMPv3 Security Model Module Specification SNMPv3 Local Processing Mosule Specification SNMPv3 Proxy Specification

Goals and Milestones:

Done

  

Post first SNMPv3 Internet-Draft, Modules and Interface Definitions.

Done

  

Working Group meeting at Memphis IETF to discuss SNMPv3 recommended approach, discuss Working Group Charter and the plan for completion.

Done

  

Post revised SNMPv3 Modules and Interface Definitions Internet-Drafts.

Done

  

Post initial SNMPv3 Message Processing and Control Module Internet-Draft.

Done

  

Post initial SNMPv3 Security Model Module Internet-Draft.

Done

  

Finalize SNMPV3 Modules and Interface Definitions Internet-Draft and review other I-Ds at Munich IETF.

Done

  

Post revised SNMPv3 Local Processing Module Internet-Draft.

Done

  

Post revised SNMPv3 Security Model Module Internet-Draft.

Done

  

Post revised SNMPv3 Message Processing and Control Module Internet-Draft.

Done

  

Post initial SNMPv3 Proxy Specification Internet-Draft.

Done

  

Submit SNMPv3 Modules and Interface Definitions to IESG for consideration as a Proposed Standard.

Done

  

All SNMPv3 specifications submitted to IESG for consideration as Proposed Standards.

Jul 98

  

Testing of interoperability between independent implementations of SNMPv3 core specifications.

Jul 98

  

Post the initial Internet Draft of the Intro document.

Aug 98

  

Post initial Internet Drafts for updating the SNMPv3 core specifications.

Aug 98

  

Post initial version of the Coexistence document as an Internet-Draft.

Aug 98

  

SNMPv3 Working Group Meeting at 42nd IETF.

Sep 98

  

Post revised version of the Intro document Internet-Draft.

Sep 98

  

Post revised version of the Coexistence document as an Internet-Draft.

Oct 98

  

Complete Working Group actions on revisions to core specifications and forward documents to the IESG for consideration as Draft Standard RFCs.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2573

DS

SNMPv3 Applications

RFC2574

DS

User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)

RFC2575

DS

View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

RFC2570

  

Introduction to Version 3 of the Internet standard Network Management Framework

RFC2571

DS

An Architecture for Describing SNMP Management Frameworks

RFC2572

DS

Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)

RFC2576

PS

Coexistence between SNMP versions

Current Meeting Report

The SNMPv3 working group met on Monday, July 31 at 7:30 PM during the 48th IETF. The chairs of the SNMPv3 working group (Russ Mundy and David Harrington) were both present, as was the area director (Randy Bush). The meeting was reported by Steve Moulton and Rob Frye. There were approximately 100 attendees present. The mailing list address for this working group is SNMPv3@lists.tislabs.com. The mailing list archives are available at ftp://ftp.tislabs.com/pub/ietf/snmpv3. The slides presented at this working group meeting are available at ftp://ftp.tislabs.com/pub/ietf/snmpv3/ietf48.

The first major item on the agenda was the usual administrivia.
The agenda was accepted as proposed.

Agenda Item 2: Working Group Last Call for updates to RFC1905
(draft-ietf-snmpv3-update-proto-04.txt), RFC1906
(draft-ietf-snmpv3-update-transmap-04.txt), and RFC1907
(draft-ietf-snmpv3-update-mib-04.txt).

The chairs announced that consensus has been reached on all items.
This presentation was led by Randy Presuhn <rpresuhn@bmc.com>.

The full document status material is available at ftp://amethyst.bmc.com/pub/snmpv3/update567/index.html. This presentation used the agenda slides discussed above.

RFC1905 - There are no open issues.

RFC1906 - One open issue.

1906-20: Should UDP transport mapping be mandatory.

The current text reads:

Although several mappings are defined, the mapping onto UDP over IPv4 is the preferred mapping. As such, to provide for the greatest level of interoperability, systems which choose to deploy other mappings should also provide for access via the UDP over IPv4 mapping.

The consensus from the mail list was to replace the current text with the following:

Although several mappings are defined, the mapping onto UDP over IPv4 is the preferred mapping for systems supporting IPv4. Systems implementing IPv4 MUST implement the mapping onto UDP over IPv4. To maximize interoperability, systems supporting other mappings SHOULD also provide for access via the UDP over IPv4 mapping.

Randy asked if there were any problems with the proposed text wording, and no response was received.

RFC1907 - There is one open issue, although that issue involves several changes to the conformance material.

1907-19: During working group last call, it became clear that some further clarification of the conformance material was required.

The proposed description text reads:

DESCRIPTION:

"The two notifications which an SNMP entity supporting both command generator and notification originator applications is required to implement."

Bert Wijnen immediately made the observation that text "command generator" should be replaced with "command responder". Immediate agreement was reached on what was a wording error.

Keith McCloghrie asked about what happens if you have an entity that is just a notification originator. Randy Presuhn replied that in the original framework there was no such thing as a pure notification originator. Much discussion followed on this point, centering around the issue of whether it makes sense to specifically mention notification originator. The question was raised on whether the "and notification responder" text should be dropped. Agreement was reached that it should.

The proposed description text reads:

DESCRIPTION:

"The notifications which an SNMP entity supporting both command responder and notification originator applications is required to implement if it is able to reinitialize itself such that its configuration is unaltered."

The question was raised on whether the "and notification originator" text be dropped? Agreement was reached that it should.

The snmpNotificationsGroup was originally included under snmpBasicCompliance in RFC1907. The statement was made that if we assume that any meaningful entity that supports this MIB will support both command responder and notification originator applications, it should probably be included, since this would be a non-change from RFC-1907.

Proposed resolution of this question is to restore this item to snmpBasicCompliance MODULE-COMPLIANCE. Agreement was reached.

David Perkins requested that in the future, when we specify a new notification operation, such new notifications have no impact on this.

Randy Presuhn stated that restoring the snmpBasicCompliance MODULE-COMPLIANCE was a fix of an inappropriate edit.

This group is not in the snmpBasicCompliance statement in RFC1907. The proposed change was that the snmpCompliance should refer to the snmpAdditionalNotificationsGroup. It does not currently.

Keith McCloghrie stated that the conditions under which this particular notification group is required would move it into the conditional portion of the module compliance statement. David Perkins concurred.

This was modified to be consistent with RFC2578.

Chris Wellens asked if the module compliance statement was implemented in products in the field? There was no response.

Randy Presuhn stated that his concern is narrow - what we state in the document should specify what a conforming implementation should do. What is actually done in the marketplace is not our issue. What this does is give customers a way to demand this feature works.

The proposed resolution is that we will include text being written by Keith McCloghrie and David Perkins, once it has been approved in a brief comment period on the mailing list. [The wording Keith proposed makes moot some of the wording changes discussed earlier. -ed]

Summary of the RFC1905/6/7 Last Call Changes

Keith and David will supply text. (1907-19)

Agenda Item 3: Deployment Plans and Reports.

It is also distributed in RedHat Linux and FreeBSD.

Russ reiterated the need for deployment reports. He asked the SNMP vendors to encourage customers customers to let the IETF community know that they are using SNMPv3. This is currently the single biggest issue that is holding us back from advancement. We need deployment reports for RFC2571-5.

Agenda Item 4: Overview of proposed Work Items.

Russ Mundy discussed the response to his request for help setting priorities on future work items sent to the mailing list. He stated that there was a roughly equal split between "go dormant" and "consider additional work items".

Bert Wijnen stated that this is the best group of people to determine whether or not to do these items. He would like to prioritize top things to work on, and then decide "in this working group or somewhere else."

Keith McCloghrie stated that it is a good thing to have a central working group to which new work items could be brought.

Randy Bush stated that there is a concern that further perceived mucking with SNMPv3 would slow deployment. ( i.e., add FUD: Fear Uncertainty & Doubt)

Dave Harrington stated that there is also concern that if we walk away from further bulk data transfer improvements, that people will walk away from SNMPv3.

A commenter from the floor who is a former cable modem guy stated that the observation to make is that these things are being considered in the IRTF. Having stability in the specs will permit more inter-operating deployments. The way the specs kept changing have made it difficult to implement.

Randy Bush: As an operator, I am interested in stability stability stability. If I hear bulk transfer is coming down the pipe, I am going to stay with v2, as it takes me 4 to 6 months to roll out software.

Keith McCloghrie: Security must not be very important to you if you wait for bulk to implement.

Randy Bush: It still costs me 4 to 6 months each time.

Jeff Case: Our problem is that we have not been able to get these customers who have deployed to get here to talk about it. You are not getting operator reports because there are not very many operators in the room. Some customers are still concerned since they got burned by SNMPv2. All some vendors need is an excuse, and the perception is the excuse.

Michael St. Johns: Lets get it out. No more changes. Do this in SNMPv4, NOT in SNMPv3.

Rob Frye: Yes there are lots of holes we can fix and improvements we can make. Sure we need to do these, perhaps based on work in the NMRG, but we should not expand the charter of SNMPv3 beyond what is truly necessary for deployment acceptance.

Jeff: I know of vendors whose revenues are up 30% over last year due to SNMPv3. Customers neither agree to speak about it nor do they come to these meetings. We did a great job on SNMPv3 documents when we started it, but it is going slow now. I can't encourage customers to invest in the SNMPv3 list. We need to find a different method to get implementation reports.

We will post URLs of press releases to mailing list.

Chris Wellens: Get the universities to deploy SNMPv3 - give them product via grants, get them to product reports. Make deployments happen.

Russ Mundy: We need to focus on question of additional work. There are a number of people that think things need to be attacked, in particular efficiency improvements.

slide: Efficiency Proposals:

(from the proposed work items: Efficiency slide):

Strong support, real proposals:

comment from floor: All SNMP v1,v2c,v3 are working. The only deficiency I want to see addressed is bulk transfer. This is the key to deploying SNMPv3.

Dave Harrington: Due to the overhead of the security in SNMPv3, improving the efficiency will help diminish this.

Rob Frye: A number of the inefficiencies have to do with management of the security.

Randy Presuhn: The inefficiency really is in the CPU demands of security.

Keith: In some usage scenarios, bulk transfer is important, some times not.

Jeff: I have heard complaints about configuration. Not about performance. We are addressing this with a GUI.

Keith: For many years, Cisco has had the complaint that when NNM reads the routing table, the CPU in the router goes to 100% for some time.

Chris Elliot: The routing table does not get stored in lexicographical order.

Jeff: The problem is not v1, v2c, v3. The problem is with the storage methodology.

Ram Kavasseri: We have proprietary bulk PDU and compression. It helps some.

slide: Documentation Proposals: no support for moving forward.

slide: Security Algorithms and key size: There is support for moving forward.

slide: Protocol extensions: There are no firm strong proposals but mild agreement on moving forwards.

slide: Information and Data Modeling: Mild agreement that many of these topics may be reasonably examined by the Network Management Research Group of the IRTF, and some should be examined in the IETF.

Keith: We should have an integrated language to describe both COPS and SNMP data structures. Other groups will benefit.

David Harrington asked that if, in light of the previous comments about not expanding the working group charter, we should still discuss Bulk Transfer proposals. There was no negative response.

Agenda Item 5: Proposals to Improve Efficiency.

Juergen Schoenwaelder made a presentation on several bulk transfer proposals. See slide references at the beginning of these minutes.

The presentation dealt with efficient handling of large amounts of data (typically hundreds of kilobytes of data) in a single logical transaction. Various approaches were proposed. The slides are complete and will not be reproduced here. Some parts of the presentation were abbreviated due to time constraints.

Randy Presuhn: Did you use consider the use of compression in a SNMP over TCP using IPPCP [RFC2393 -ed] ?

Juergen: That brings up interesting issues of MTU.

Presentation: Bulk Transfer Proposal using Bulk File and FTP Client MIBS.
Niraj Gopal. Cisco Systems.

Problems:

Main components:

This scheme is implemented by Cisco and they are willing to share it with the working group. There are three different file formats supported:

1. ASCII space separated instance values with row index and other tags.
2. Binary format that consists of tags and data fields. There is a tag to set a standard OID prefix, a tag for a single object, and some tags to encode tables.
3. BER Encoded that is the same as SNMP varbind list in a PDU.

Presentation: Subtree Retrieval MIB. Dave Thaler (dthaler@microsoft.com)

This work is based on an expired Internet Draft available at http://www.eecs.umich.edu/~thalerd/subtree.txt.

This proposal does not require any changes to SNMP.

The basic idea is that a single message is sent as a request, and data is carried back to the management application in a series of notifications containing sufficient serialization data to make sure all message are received. An intermediate message can be sent to terminate operation in progress.

Limitations: The agent must allow sets to the MIB, the target must be configured as a trap target, and the subagent implementing the MIB must be able to walk other object with proper access controls.

To be done: Need to update Internet Draft to get multiple subtrees in parallel.

Presentation: GetCols Operation, David Perkins (dperkins@dsperkins.com).

David Perkins gave a presentation on a proposed GetCols operation.
The slides are available at the location specified in the beginning of this document.

Problem: typical use of SNMP is to periodically retrieve status and statistics.

The proposed GetCols operation has problems with holes, no overshoot problems, and a higher packing factor than getbulk. Holes are plugged with noSuchInstance exceptions, and OIDs are highly compressed. Some performance numbers were presented (and are in the slides). A comparison with other approaches was presented.

Presentation: Extending SNMP to Support BULK MIB Data Transfers. Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de).

No attempt is made to reproduce the slides here.

Several approaches were presented, but compressed due to time limitations.
Approaches included:

The Network Management Research Group (IRTF) prefers the new PDU approach. There is a running implementation of this approach.

Agenda Item 6: Wrap up (Russ)
----

Slides

SMNPv3 and AAA
Agenda
Bulk Transfer Proposal
GetCols Operation
Subtree Retrieval MIB
Bulk MIB Data Transfer Solution Space
Extending SNMP to Support Bulk MIB Data Transfers