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 republished. Sep 28: Begin Working Group Last Call on Core documents and Introduction document. Oct 12: End Working Group Last Call on Core documents and Introduction document. 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.