2.4.15 SNMP Version 3 (snmpv3)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 29-Jul-98

Chair(s):

Russ Mundy <mundy@tis.com>

Operations and Management Area Director(s):

Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>

Operations and Management Area Advisor:

Harald Alvestrand <Harald.Alvestrand@maxware.no>

Mailing Lists:

General Discussion:snmpv3@tis.com
To Subscribe: snmpv3-request@tis.com
Archive: ftp://ftp.tis.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:

Apr 97

  

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

Apr 97

  

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

Jun 97

  

Post revised SNMPv3 Modules and Interface Definitions Internet-Drafts.

Jul 97

  

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

Jul 97

  

Post initial SNMPv3 Security Model Module Internet-Draft.

Aug 97

  

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

Sep 97

  

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

Sep 97

  

Post initial SNMPv3 Proxy Specification Internet-Draft.

Sep 97

  

Post revised SNMPv3 Security Model Module Internet-Draft.

Sep 97

  

Post revised SNMPv3 Local Processing Module Internet-Draft.

Sep 97

  

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

Apr 98

  

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

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2271

PS

An Architecture for Describing SNMP Management Frameworks

RFC2272

PS

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

RFC2273

PS

SNMPv3 Applications

RFC2274

PS

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

RFC2275

PS

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

Current Meeting Report

Russ Mundy - Chair, SNMPv3 Working Group

Minutes of the SNMPv3 Working Group
42nd IETF Chicago
Minutes Reported by Jeff Johnson

After a quick non-bashing of the agenda, the meeting began with an SNMPv3
Implementation and Interoperability report. Jeff Case gave a quick overview of the
interoperability testing that has been performed to date, including April at the IETF,
May at Networld+InterOp, June in Seattle, July over the Internet, and late July at BMC.
In addition, there will be another round of testing at Networld+InterOp in October. He
then described in some detail the latest testing.

There were a half dozen independent implementations at the BMC testing event. Most
of the implementations had both agent and manager implementations. The testers
discovered some "rough places" in the documents. When it was discovered that all
of the implementations matched in their interpretation of the documents, new text was
written and fed back to the editors.

There were also some "ah ha"s that were discovered. One such case occurred when
testing user cloning. A user was cloned, and was given an authentication password of
"bertbert" and a privacy password of "bertbertbert". Unfortunately, one of the manager
implementations only allowed a single password to be specified for a user, and this
password was used for both authentication and privacy. But surprisingly, this
implementation was able to successfully communicate with the cloned user. It was
only after a few minutes of head-scratching that it was determined that when you
extend "bertbert" to one megabyte in length in order to perform the password to key
conversion, you get the same thing as when your extend "bertbertbert" to one megabyte.
The observation is that the password-to-key mechanism doesn't introduce as much
entropy as was originally anticipated. One other "ah ha" that was discovered is that
VACM can be quite a consumer of CPU resources if it is implemented inefficiently.

Jeff then gave a brief overview of what was tested. All of the implementations supported
noAuth/noPriv and hmac-md5-96/noPriv. Some supported hmac-sha-96/noPriv but not
cbc-des. Some supported hmac-md5-96/cbc-des but not hmac-sha-96. Some supported
the full set of combinations of auth and priv. Informs were tested, but proxy was not
since there was only a single proxy implementation present. Most of the testing centered
upon the basic functionality of the protocol, although some error condition testing was
performed with the help of the IWL test tool. Jeff pointed out that some minor stuff wasn't
tested (such as if the correct error counter was incremented when a error condition was
encountered), but that all of the big stuff was tested. He also pointed out that not all known
implementations were represented at BMC; there are some folks producing free
implementations that naturally don't have travel budgets.

The chair then did a call for consensus questioning if this is sufficient interoperability for
advancing the documents. Dave Perkins pointed out that without seeing the results of
the testing, no consensus could be reached. The AD took advantage of this comment to
review the requirements for advancement. Not only must there be two interoperable
implementations, but the Working Group must be able to convince the IESG that the
appropriate amount of testing has been performed. Specifically, all aspects of the
specifications must be tested.

This led to more discussion about what was tested. The test report will be sent to the
SNMPv3 Working Group mailing list [this has already occurred]. In addition to testing
security and other SNMPv3 functions, there was some multi-lingual testing performed in
the course of testing (i.e. the usual sequence of events when verifying a piece of functionality
was to verify SNMPv1, then SNMPv2C, then SNMPv3). There was also a question as to
the level of MIB testing. The MIBs have been tested pretty extensively, including verifying
the ability to remotely add, change keys for, and delete users.

Finally, the question was raised if the current specifications are more usable than SNMPv2
Classic which, it was pointed out, also went through several rounds of interoperability
testing but never found marketplace acceptance. One vendor indicated that SNMPv3
appears much more deployable than party/party/context.

This discussion prompted the Chair to focus on the next agenda item, discussion of the
SNMPv3 Core Specifications (arch, mpc, appl, usm, and vacm). Are these ready for
advancement from Proposed to Draft standard? Dave Perkins expressed the belief that
the documents did not meet the criteria set forth in RFC 2026 (The Internet Standards
Process). He also raised a concern about the effects of the documents on the discovery
process. In response, it was pointed out that the conventions that are currently used to
make SNMPv1 discovery work (i.e. usage of the well-known community "public") are
not specified in any document. Randy Presuhn wrapped up the discussion of the core
documents by observing that there are still some open issues, and that although he is one
of the editors, he "doesn't know edits." These should be worked on the list. The consensus
at this point was that more work needs to be done, both in cleaning up the documents and
making sure the interoperability can be sufficiently demonstrated for the IESG.

The next topic on the agenda was discussion of the new Introduction document. No issues
had been raised on the list. Bert indicated that he had a negative reaction to the document
in that it gives a lot of praise to the original authors of SNMP while apparently relegating
the recent work of the SNMPv3 Working Group as administrative in nature.

A comment was made that the Intro document leaves out two seemingly important aspects
of SNMP-based management. First, it would be useful to have a "cookbook" for new
implementers who are not familiar with all of the history and just want to build an
implementation from scratch. Second, it would be useful to have guidelines for deployers
of the technology.

At this point there was a call for consensus on the Intro document. It was suggested that
the document needs a table of contents as well as additional text to answer the question
"why v3?" The cookbook and deployment guidelines, while useful, were not seen as an
integral part of the Introduction. The consensus was that the revised document would be
appropriate for publication as an Informational RFC.

The next topic was discussion of the Coexistence document. It was observed that no
issues had been raised on the SNMPv3 mailing list, but this didn't keep those present
from making comments. One observation was that clarifications of the SMI would
affect this document. Another observation was that proxy is under-described.

One question that was raised was whether it would make sense to have a pointer from
the Architecture document to the Coexistence document. There was consensus that this
would be a good idea to have pointers from both the Architecture document and the proxy
portion of the Applications document to the Coexistence document, although the AD
warned the Working Group that pointers between standards track documents can cause
problems in the standards track advancement. There should not be any normative
references, i.e. references that would cause the Architecture or Applications documents
to depend upon the Coexistence document.

One last comment was concern about the community MIB, and the fact that it may create
a security hole if not deployed wisely.

At this point the chair raised the question as to what kind of document should this be, a
BCP or standards-track. This resulted in quite a bit of discussion. The point was made
that since the document contains a MIB, it should be placed on the standards track. A
counter argument was that the MIB didn't belong, that it should be removed and the
resulting document should be made an Informational RFC. A counter to this argument
was even if the MIB were removed, the document described transaction processing and,
hence, was still standards-track material. As a counter to this argument was the
observation that a BCP can describe transactional processing without being standards-
track. Other observations were placing the Coexistence document on the standards track
puts too much focus on the prior versions of the protocol and that the limited applicability
of the document may prevent it from later meeting the advancement criteria from RFC 2026.
Although a strong consensus was not reached, the majority of the folks present who
expressed an opinion seemed to prefer a standards-track document.
The final agenda item was to review the Working Group schedule and to make work
assignments. The following items were scheduled:

Sep 4: Russ to update charter milestones
Sep 8: Introduction document updated and republished
Sep 28: Coexistence document updated and republished.
Sep 28: Core documents (arch/mpc/appl/usm/vacm/intro) updated and

Sep 28: Begin Working Group Last Call on Core documents and Introduction

Oct 12: End Working Group Last Call on Core documents and Introduction

Oct 28: Revised core documents and Introduction document forwarded to IESG.

A call for volunteers was made for working on the proposed deployment and implementers
documentations. David Perkins volunteered, and Jeff Case indicated that he would find
someone back on the farm to volunteer.

That concluded the activities of the Working Group.

Slides

None received.

Attendees List

go to list