Current Meeting Report
Slides


2.3.17 SNMP Version 3 (snmpv3)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 09-Nov-01
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.
Done   Testing of interoperability between independent implementations of SNMPv3 core specifications.
Done   Post the initial Internet Draft of the Intro document.
Done   Post initial Internet Drafts for updating the SNMPv3 core specifications.
Done   Post initial version of the Coexistence document as an Internet-Draft.
Done   SNMPv3 Working Group Meeting at 42nd IETF.
Done   Post revised version of the Intro document Internet-Draft.
Done   Post revised version of the Coexistence document as an Internet-Draft.
Done   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:
RFCStatusTitle
RFC2573DSSNMPv3 Applications
RFC2574DSUser-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
RFC2575DSView-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
RFC2570 Introduction to Version 3 of the Internet standard Network Management Framework
RFC2571DSAn Architecture for Describing SNMP Management Frameworks
RFC2572DSMessage Processing and Dispatching for the Simple Network Management Protocol (SNMP)
RFC2576PSCoexistence between SNMP versions

Current Meeting Report

SNMPv3 Working Group 52nd IETF
Salt Lake City, Utah , USA
11 December 2001

Chairs:
Russ Mundy (mundy@tislabs.com)
Dave Harrington (dbh@enterasys.com)

Area Advisor:
Randy Bush (randy@psg.com)

Notes:
Mike Baer (baerm@tislabs.com)

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

Status:
Updates to RFCs 1905-1907 have been approved for advancement to full Standard by the IESG, currently awaiting publication.

The WG has completed all of their actions on the updates to RFCs 2571-2575 and the chairs have submitted the request for advancement to IESG.

Discussion related to 2574 related to key localization problem. I.e. saving a config and moving to new machine. Engine ID <-> password problem. (EngID is associated with keys). Conclusion: this is an implementation consideration and not a protocol problem - no action is required.

RFC 2576 is currently awaiting information for the implementation report.
The chairs requested that any implementation related information be provided as soon as possible.

RFC 2570 should be updated to incorporate minor changes to the status of various other documents.

RFC 2576 implementation:
Chairs: Not aware of any Interoperability tests as of yet.
W.Hardaker: suggest using a standard form for implementation reports.
Chair: Anyone using a v1<->v3 proxy please let WG know about it.

Charter Updated: There was no discussion (or disagreement) with the up-dated charter that is on the IETF web site.

No one wanted to introduce new work.

Discussion about whether or not the status of SNMPv1/v2 and SMIv1 should be changed in conjunction with the advancement of SNMPv3 to full Standard. Although this had been discussed on the list, the general conclusion of those in the room was that SNMPv1/v2 should become historic, the maturity level of SMIv1 should not be changed but the requirement level should be changed to 'not recommended' per RFC 2026.

After completing the Working Group normal activities, Glenn Mansfield Keeni gave a presentation on several interesting SNMPv3 Applications (slides provided but a short summary follows to provide a text record of the presentation).

METI, Japan
Wide Project, Keio University
Toyota

using IPv6 and SNMPv3
ICar MIB
ICar field test 2001. 280 vehicles
another test next year.

Network Information Service,
Tohoku University, TAO, and something else.
JaNI: very high resolution ~ milliseconds
massive payload reduction techniques, a draft RFC available?

JGN-IPv6 Project
Tao, Wide Project, Keio University, several organizations
high speed test bed
various SNMPv3 expericments
IPv6 programable probes
IPv6 enabled net-snmp

Experimental Intrusion Detection systems using SNMPv3

SNMPv3 for elementary, junior-high prefectory (sic) school system

Conclusions: SNMPv3 is powerful, bad look and feel, it needs good API'S, need good app's.

Questions
Was UTF-8 support and advantage or disadvantage in implementation? It wasn't used in these implementations.

Slides

Agenda
Experiments and Experience with SNMPv3