NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Russ Mundy <firstname.lastname@example.org>
Operations and Management Area Director(s):
John Curran <email@example.com>
Michael O''Dell <firstname.lastname@example.org>
Operations and Management Area Advisor:
Michael O''Dell <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
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:
Working Group meeting at Memphis IETF to discuss SNMPv3 recommended approach, discuss Working Group Charter and the plan for completion.
Post first SNMPv3 Internet-Draft, Modules and Interface Definitions.
Post revised SNMPv3 Modules and Interface Definitions Internet-Drafts.
Post initial SNMPv3 Message Processing and Control Module Internet-Draft.
Post initial SNMPv3 Security Model Module Internet-Draft.
Finalize SNMPV3 Modules and Interface Definitions Internet-Draft and review other I-Ds at Munich IETF.
Post revised SNMPv3 Message Processing and Control Module Internet-Draft.
Post initial SNMPv3 Proxy Specification Internet-Draft.
Post revised SNMPv3 Security Model Module Internet-Draft.
Post revised SNMPv3 Local Processing Module Internet-Draft.
Submit SNMPv3 Modules and Interface Definitions to IESG for consideration as a Proposed Standard.
All SNMPv3 specifications submitted to IESG for consideration as Proposed Standards.
· An Architecture for Describing SNMP Management Frameworks
· Local Processing Model for version 3 of the Simple Network Management Protocol (SNMPv3)
· Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
· User-based Security Model for version 3 of the Simple Network Management Protocol (SNMPv3)
· View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
· User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
· SNMPv3 Applications
No Request For Comments
Minutes of SNMPv3 Working Group Meeting
We had two meeting slots. Both were well attended in an over-packed, too-small, and too-hot room.
Area Co-director Mike O'Dell expressed his appreciation for what he called a remarkable level of sustained intellectual exercise.
Chair Russ Mundy briefly presented the agenda that had previously been published on the mailing list. He emphasized that we would have no tutorial, gave us a quick look at an overall diagram from the architecture document, then proceeded with discussion of issues led by an editor for each document.
I. Architecture - Dave Harrington
Dave presented the issues list and his reading of apparent consensus, soliciting any strong disagreement from the assembled working group.
There was some objection that Application Service Interfaces (ASIs) look too much like Application Programming Interfaces (APIs). This was dismissed as too late in the process to try to change directions.
A discussion on the length of the engine ID resulted in some clarifications and consensus that it is a variable length value with a maximum of 32 bytes.
There was considerable discussion on the use of strings as indexes for tables of direct interest to humans. The following points were made.
· An objection was raised to the overhead of a string in every varbind, along with skepticism that people will directly configure such information.
· Names offer better consistency.
· That is not necessarily true. Small, numeric indexes with a descriptor string are functionally equivalent and more efficient.
· Use of a string doesn't guarantee semantics. Application writers must inspect string contents. Can we depend on this?
· Such enforcement is an administrative procedure.
· Existing experience with small integer indexes indicates that using names relieves users by spending some machine resources, and you can force the use of short names if necessary.
· A textual description is not trustworthy either.
· The major issue is message overhead.
· This is not a frequent operation.
· How about adding a number to go with the name?
· Objector is willing to drop the issue.
· Conclusion: We made no change.
We then discussed the use of UTF8 for some time with the following points made.
· Some people want a general UTF8 replacement for DisplayString.
· AdminString is not that as it is more restricted.
· UTF8 is not a panacea.
· Is this problem bigger than management needs? People are picking up UTF8 in other places. Research will be provided.
· We need our solution now.
· Adding DisplayString-like carriage control is unnecessarily complex.
· That was added to DisplayString due to demonstrated need.
· Applications must handle carriage control and non-printing characters anyway. How do restrictions help?
· The problem is garbage restriction versus end-to-end recognition of character meanings.
· What if we simply say that carriage-return/linefeed represents the canonical end of line and make other restrictions simply suggestions?
· What we're discussing is a DisplayString replacement. AdminString is for restricted use and has no carriage control and no leading or trailing white space.
· Conclusion: We won't try to do anything more general now.
We discussed Report PDUs with the following points being made.
· All Report PDUs are noAuth/noPriv except NotInTimeWindow which is auth/noPriv.
· We need to allow other security models to have other definitions.
· Changing this would not be an easy edit.
· Let the requester of the Report send it specification for level of security.
· Such a fix would require multiple changes to say what happens if the report can't be sent that way.
· The issue is an architectural layer violation.
· What if the security module could specify but not application modules?
· That information is not available.
· What if we say noAuth/noPriv is the default and pass differing desires in status information?
· Conclusion: Agreed to last suggestion.
The question was asked if it is OK that the USM is bound to v3. There was violent agreement that we would be better off to stick closer to v3 and this isn't the only place.
We discussed whether an OID or an enumeration is better for identifying the security protocol. The following points were made.
· Using OIDs you can't find the inclusive list, can't figure out what a value means, and can't reuse existing values. Use of OIDs here is not appropriate.
· Let's simplify this by deleting the column from the table.
· Doing that will require a change in how we recognize protocols.
· We can use a new model number for new protocols and simply say it is similar to an older one.
· We need to support changes of protocol.
· A single column is better than separate tables.
· Add the model as an index and delete the column.
· That's more complex.
· Determining what protocols are supported is a problem.
· The conversation became emotional and pointed.
· We deferred the issue until later.
An objection to passing parameters that have unchangeable values was answered that this is to provide placeholders for future flexibility although the detail does create some burden.
There is no distinguished value that can be used as a wildcard for a contextEngineID. The solution to this is implementation-specific, such as using a flag. This explanation will be added as implementer's notes in the specification for PDU types and contextEngineID in the Register and Unregister ASIs.
We discussed the need to add a PDU version in the ASI. The following points were made.
· This is not a good solution to the problem of supporting multiple versions. A better solution would be disjoint PDU function codes for different versions.
· Behind this suggestion is a desire to change the PDU function codes on the wire.
· Even if v3 has different types we will have to distinguish v1 and v2c.
· We deferred this issue to the discussion of Message Processing.
A suggestion was made and strongly supported to make the architecture explicitly v3.
· The chair ruled the support was not strong enough for such a drastic change.
· The present architecture is not general enough.
· It is flexible enough, up to a point.
· The ASIs do not accomplish the flexibility they should.
· The chair informed us that due to IESG input we need to change MD5 to HMAC and doing so may improve functional separation as long as such improvement is not too disruptive.
We returned to the issue of OID versus enumeration for security protocol identification.
· Some people want time to consider the issue of OID versus enumeration versus removing it.
· The chair ruled that we should leave it as it is (OID), note the objection, and reexamine our position if it comes up again.
We discussed the need for an overview/roadmap document. The following points were made.
· We shouldn't make any changes in the present architecture document. We need the overview document.
· Conclusion: If the overview appears soon and we like it, duplicate overview text will be removed from architecture.
· Conclusion: Doing the overview is OK. We'll see if we like it when we have it in hand.
We debated whether "should" is too strong or too weak regarding the architecture's list of security threats. We decided to leave it as is.
We debated whether an agent should have MIB objects to say the length of AdminStrings it supports. The following points were made.
· Strong support was expressed since agents can limit the length of these strings.
· That should be covered by AGENT-CAPABILITIES.
· It's not since managers don't have or use that information.
· Without this information writing applications is too hard. Past experience indicates we will have limited agents and will need this information.
· AGENT-CAPABILITIES does supply this information. Applications should use that.
· Experience says AGENT-CAPABILITIES isn't trustworthy.
· The agent should return an error to say too big. Such objects as this are not good.
· These objects could indicate no new entries allowed by indicating maximum length of zero.
· What is the proper error return? There isn't one for index too. long. All we have is inconsistentName.
· We should go back to integer indexes.
· Using integers is just too hard for people.
· There are other places this could apply. Why do it here and not there?
· We should do it for the most important structures.
· We deferred this issue due to being 45 minutes over time and one document behind.
To ensure that we could finish our business in the one meeting we had left the chair-established midnight of the next day as the deadline to publish to the mailing list those issues that must be addressed in the second meeting. A Web site for those was volunteered.
Since Dave Perkins had many issues, the chair asked for his key issues to help understand what was left. They were:
· There are problems with the use of message ID versus request ID.
· Use of engine ID is unclear for transient versus persistent applications.
· Is access control required or not?
The first meeting was adjourned.
Due to the painfully slow progress at the last meeting, the chair revised the procedure for this meeting to speed progress. He presented the following categories, in priority order:
1. Will NOT function.
2. Prevents doing secure Sets.
3. Won't support v2 SMI.
All issues must be categorized and will be handled in priority order until the top three categories are empty and we run out of time. We went through the issues submitted on the mailing list, and the submitters categorize their own issues. We had category 1-3 issues from Perkins, Case, and McCloghrie as follows:
All were category 1.
We then proceeded with the issues, by document.
Problems with message ID space uniqueness among systems were judged editorial, to be fixed by the editor.
The v3 message format was changed to create a HeaderData sequence. When parsing for previous versions this causes an ASN.1 parser error instead of a version mismatch. After a small amount of discussion, we deferred the issue for further consideration.
The destination contextEngineID can not be discovered if Reports are optional. This is not a problem since Reports are not optional. Reports can not be optional. They're not.
· What happens if the Report receiver? This is fixed by retrying when a Report is received.
· A group Inform should not be satisfied by a single ACK. This is an optimization, working as intended. If each destination must ACK, don't make them a group.
· Some Informs do not synchronize clocks. We deferred this.
· Another issue was the same as the group Inform issue.
· Proxy needs processing for maximum message sizes. This will be fixed.
· Proxy sends notifications to multiple targets. This will be clarified as a feature.
· Some proxy TAddress processing can't happen. This will be fixed.
· We need the ability to use source address as input to authorization processing. This was relegated to "other."
· We need a MIB table for clock information. This is not broken so we won't fix it.
· There is bad logic in section 3.1 step 6. No there isn't.
· Section 3.2 step 7 part b step 1 is broken. This will be reconsidered for unclear wording.
· Section 3.2 step 7 part b step 2 needs an added case. This is part of the previous issue.
Some issues were dismissed by their presenter.
The algorithm in the DESCRIPTION for acmAccessTable is too complex and loses some good cases. Changing this is a major issue, requiring an index change. The way it is was the best we could find for the present indexing and is believed to operate properly even if somewhat complex.
The chair ruled that the final issue didn't meet the criteria for further discussion.
The snmpTargetAccessSpinLock process is too burdensome, overly complex, causing retrieval of all entries. Juergen's "tag" solution fixes this. We deferred discussion of that solution until later. There was also a comment that RowStatus should be sufficient without a spin lock.
An issue that a command generator should not accept mismatched responses was judged editorial.
The engine ID value generation algorithm doesn't work for multiple engines on the same system. We deferred this for later.
We returned to the deferred issues.
VII. MP - HeaderData Issue.
The desire is to put the version back where it was in the message format. It will be fixed that way if the change is clean and obvious. This was done to make the architecture cleaner. It is observed that message format and architecture need not be so closely bound and that this issue is touched somewhat by the pending change from MD5 to HMAC.
VIII. Applications - Inform Clock Synchronization.
If sender is slower than the receiver and the difference in clocks is too great, manual synchronization is required. This is a burdensome exception.
This was changed from a fully automatic operation due to security considerations. The consensus was that the fully automatic synchronization is strongly preferred. The chair was requested to discuss this issue with appropriate security folk to determine if the fully automatic clock synchronization could be used in all situations. Based on discussions subsequent to the meeting, the chair determined that to be the case, i.e., fully automatic clock synchronization should be used in all situations.
IX. Architecture - Engine ID Algorithm.
Multiple engines following the algorithm on the same system will end up with the same ID. The suggested algorithms are thus dangerous in some common situations. A warning will be added, explaining the problem and stating that the algorithms suggested do not solve it.
X. Applications - Spin Lock Problem.
The proposed solution is to change the indexing and add tags to use for selecting targets. Each target has a set of tags. Targets are selected by listing the tags of interest. This could be helpful for Distributed Management. Further discussion was deferred to the mailing list.
We then discussed the overall readiness of the four documents other than Security that will be changing to HMAC. The following points were made:
· The applications document needs another working group last call.
· Mostly the documents are very close to sufficient for submission for Proposed Status. The Area Co-director reinforced the statement that "Proposed" means ready to do implementation, not locked in stone or perfect or finished.
· Working group and IETF last call can't overlap.
· IPng coverage needs to be added.
· The area co-director stated that IPv6 may be included only if it is trivial to do so.
· DEADLINE: New documents will be available by 15 September.
· An explicit list of changes will be provided.
· Remaining issues may be answered by referring to previous consensus rather than discussing them again.
· DEADLINE: The chair preferred a one-week last call but after discussion we decided on a two-week last call, the last two weeks of September.
· After the September working group last call we're ready for IESG submission and IETF last call.
We discussed the need for a roadmap/overview. We decided it would be helpful but must not slow down or be referenced by the other documents. Editors are to be identified.
The meeting was adjourned.
go to list