CURRENT_MEETING_REPORT_ Reported by Keith McCloghrie/cisco Systems Minutes of the SNMP Version 2 Working Group (SNMPV2) MONDAY, 5 DECEMBER Chairman, Bob Stewart, began the meeting by outlining the agenda as follows: o Rules of Engagement o Identify Topics and Speakers o Implementation Reports o Proposals Rules of Engagement Bob explained the ``rules of engagement'' as requiring those speakers making proposals to first state the problem they will seek to solve before proposing their solution. In stating the problem, the speaker would need to convince the working group that there is a problem which is worthy of an attempted solution. No topics would be completely out-of-bounds, but it was unlikely that the whole framework would be reworked. The output of the group is defined in the charter (i.e., as making a recommendation on the changes and standardization status of SNMPv2). However, it is possible that different parts of SNMPv2 could be identified with different recommendations for each part. Identify Topics and Speakers The following volunteered to give implementation reports: o Jeff Johnson, cisco Systems o Shawn Routhier, Epilogue o Dave Harrington, Cabletron o J. Hien, IBM Research o Jeff Case, SNMP Research o Peter Houck, Hewlett-Packard o Marshall Rose, DBC o Steve Waldbusser, CMU The following volunteered to make proposals on specific topics: Ran Atkinson, NRL -- Key Updates Maria Greene, Ascom Timeplex -- Agent Capabilities -- Logical Devices Reuben Sivan, Multiport -- CreateAndGo Dave Harrington, Cabletron -- Key Re-use -- Auto Discovery -- Auth/Priv optional -- Indexes -- Privacy and Data Jeff Case, SNMP Research -- List of various items -- Admin Framework Steve Waldbusser, CMU -- Simplified Security Dave Arneson, Cabletron -- IPv6 Bob Natale, American Computer -- Modular Advancement Karl Auerbach, Cavebear -- OID Compression Dave Perkins, Bay Networks -- Sub-typing -- SMI and Compliance It was noted in passing that the IP, TCP and UDP MIBs (identical to MIB-II, but in SNMPv2 SMI format) which had been distributed as new Internet-Drafts were not expected to be modified. Implementation Reports Cisco's IOS 10.2 software release which includes a bilingual SNMPv1/SNMPv2 agent has been shipping since October on all current cisco IOS-based products. It includes all functionality required of an SNMPv2 agent, including the complete Party MIB and Simplified Security, but not the M2M MIB, nor does it send Inform-Requests. It is based on SNMP Research's stack. The code, including DES support, was tested at the CMU SNMPv2 Interoperability Testing Event, although DES is not currently shipped as part of the product due to export restrictions. Simplified Security is implemented as a user-interface (command-line) means to configure the Party MIB. However, few customers are using SNMPv2 so far. Epilogue's SNMPv2 implementation is a source-code product. They had few implementation problems, which were easily fixed. The size of the code is approximately 2.5 times the size of their SNMPv1 product, but most of the increase is in the method routines which implement the Party MIB. Some code optimizations (e.g., when to do view-checking) are still to be done. They are using Agent-Capabilities. At least one of their customers is using SNMPv2 security, both manager and agent. Most of the issues in Cabletron's implementation are related to the Party MIB, e.g., how the tables are related. The agent is fully bilingual, and its size is just less than twice the size of SNMPv1 agent, but they expect to reduce that by ``clean-up.'' View-checking for GetNext processing can be expensive. They do not implement the M2M MIB; they have code to send Inform-Requests but it's not currently used. They also have a SNMPv2 manager stack, but GetBulk is not yet in use due to lack of a way to invoke it from their user-interface. They have not seen much customer demand, but expect to ship in products in February. The Party MIB was the most time-consuming to implement. They see Agent-Capabilities as a very useful feature. IBM Research's bilingual code is currently being beta tested on AIX, including use with the DPI agent/sub-agent capability. It is considerably larger than SNMPv1. They tested at the CMU Interoperability Event. They support proxy, but it is not currently in use. SNMP Research has bilingual agent source code for numerous platforms. The code has been shipped to over 100 customers. They have a subsystem by which a single SNMPv2 Configuration DataStore can be shared by multiple management applications. They support proxy as defined in RFC 1452, as well as ``per-varbind proxy.'' Jeff suggested that bilingual support should be added to the Co-Existence document, but with warnings about security (not just guarding the ``front door'' with SNMPv2 access, but also taking care to guard the ``back door'' with SNMPv1 access). SNMP Research has obtained a general export license for source and binary distribution of MD5 technology for all but a handful of countries in the world. A minimal system of a bilingual agent implementing MIB-II, the UPS MIB, and the Party MIB has been implemented on a 80C188 processor with 256K RAM and 256K ROM. Customers in Europe seem to be moving to SNMPv2 faster than those in the US, probably because they do not have an installed base of SNMPv1 users, and in order to take advantage of SNMPv2's support for proxying to X.25 and other diverse equipment. It was also reported that SunNet Manager has been shipping SNMPv2 for over a year with noAuth/noPriv; an export license was not obtained in time to include support for MD5. This implementation performs all its table retrievals via GetBulk. Hewlett-Packard has a prototype SNMPv2 package on both the manager and agent sides. They stressed that Security, particularly the configuration of security, is never easy, especially on large (e.g., 25,000 nodes) networks, and not just the initial configuration but also the need to maintain it. The SNMPv2 Admin framework is sound. It provides flexibility without too much being superfluous. With the Simplified Security Conventions on top of the framework, about 99% of the functionality is obtained in a tractable manner. However, a common model is needed in an NMS. The Simplified Security Conventions are just one model; SNMP Research's ``clusters'' present a different model, and RFC 1503 yet another. A common approach is needed. The 4BSD ISODE SNMPv2 package contains manager and agent support for SNMPv2. The method routines for the Party MIB are where most of the overhead lies. View-checking is pre-computed if no instance-level granularity is configured; otherwise view-checking also involves significant overhead. Proxy is supported. End-user Tcl/Tk-based management applications are implemented on top on the package using the RFC 1503 model. Agent-Capability statements are used to good effect to customize applications for particular agents, and also to test an agent to compare its Agent-Capabilities statement against its actual behaviour. In a discussion of code-size and execution-time, Steve Waldbusser suggested that for normal agents implementing multiple MIBs, even though the size of the Party MIB's method routines do increase the size of the agent, that increase is not significant compared to the size of the method routines for other MIBs. Further, that the difference in SNMPv1 versus SNMPv2 execution-time is within the realm of coding efficiency (i.e., an optimized SNMPv2 stack will run faster than an un-optimized SNMPv1 stack). PROPOSALS Ran Atkinson -- Key Updates Ran asserted that there are active attacks in the Internet today. Chrysler and Boeing, in particular, are taking measures to protect against these. His concern with SNMPv2 Security has always been its Key Management procedures, and in particular, its use of XOR which causes the breaking of one key to make all keys related to the broken one to become vulnerable, both those derived from it and those from which it was derived, etc. He indicated that he had been apprised of a proposal to be presented subsequently to the group (see below) which would use a one-way function instead of XOR, which would significant ease his concerns. TUESDAY, 6 DECEMBER Bob Natale -- Modular Advancement Bob presented a proposal to consider modular advancement of SNMPv2. In particular, the proposal suggested that the first step would be to make manager implementations bilingual, so that agents can be upgraded over time. The first stage could be all of the current SNMPv2 except for using the new message wrappers, and the Admin and Security framework. The second stage would then incorporate these additional capabilities. Discussion highlighted that the Maximum Message Size would not be available in the first stage which would lead to problems with GetBulk. Other objections to the proposal were that it would result in multiple incompatible transitions between versions, and difficulties in an agent knowing how to respond to a Stage 1 request. It was also pointed out that the hope that managers will be become bilingual before agents is unrealistic. An alternative suggestion was to use the SNMPv2 wrappers but with fixed values for the source/destination parties and context. OID 0 0 was suggested as the fixed party, and perhaps contexts as a fixed OID with a community string. It was observed that this would need to fit within the Admin Framework, or otherwise it would break with full implementations; fixed party OIDs for noAuth/noPriv parties might be OK, but fixed contexts could be problematic. Other opinions were that time and effort should be spent on adding whatever fixes are needed in the model, rather than spending time ``going around it.'' Further consideration was postponed until discussion of the Admin framework. Reuben Sivan -- CreateAndGo Reuben suggested that CreateAndGo was harder to implement than CreateAndWait. Many people disagreed. Jeff Case -- List of Various Items Jeff presented several items from the list which had previously been sent out on the mailing-list and distributed to attendees. The problem for item #13 was explained as follows: the Co-existence rules for a proxy agent to forward an SNMPv1 trap as a SNMPv2 trap specify that 0 be inserted as a sub-identifier in the varbind value for snmpTrapOID. With the apparent conversion rules between SNMPv1's TRAP-TYPE macro and SNMPv2's NOTIFICATION-TYPE macro, this 0 would not be present in a SNMPv2 trap generated by a SNMPv2 agent. In order to make the SNMPv2 traps be the same in both of these cases, it was proposed that SNMPv2 NOTIFICATION-TYPE macros be defined with an additional 0 in their OIDs, and that 0 be dropped when converting it to a TRAP-TYPE. Discussion concluded that there is a problem here, but nobody was wildly enthusiastic about the proposed solution. Thus, the solution was only tentatively accepted in lieu of any better proposal. The problem for item #20 was explained that ``brain-dead'' SNMPv1 managers expect auxiliary objects to be accessible, whereas in SNMPv2 they are non-accessible. The proposed solution was to mention bilingual agents in the Co-Existence document (since all SNMPv2 agent implementations appear to be bilingual), and to allow them when responding to SNMPv1 requests the option of treating auxiliary objects as read-only. Discussion suggested that the proposal would result in customer support calls complaining about an SNMPv2 agent which did not treat auxiliary objects in this way. It was pointed out that this was only a transition problem with ``brain-dead'' managers, and it would be better to fix such managers. Discussion concluded that agents having this problem might bend the rules if they wish to, but that the current rules should not be changed. However, it was agreed to add mention of bilingual agents in the Co-Existence document. Marshall Rose presented a related problem (not on the list) regarding a user interface issue of having to wait for timeouts when a management application is mis-configured. In particular, he cited experience of a management application which used the Simplified Security Conventions and prompted the user to enter a username and password. If the password was typed incorrectly, the user had to wait many seconds in order to be told there was a problem, and then received no feedback as to what the problem was. Furthermore, this problem occurs for each type of error for which the agent drops an incoming packet (i.e., the set of problems for which the SNMPv2 MIB has counters). The suggested solution was to introduce a new PDU type, called a ``Report.'' This PDU would have the same format as all other PDUs, and would be sent back to the manager (just like a Response) instead of a silent drop; it would always be sent using noAuth/noPriv, with error-status/index of 0, the same request-id as the request (if possible), and one varbind. The varbind would be the particular SNMPv2 counter which was incremented as to why the request was dropped. (Of course, a Report PDU would never be sent as a result of receiving a Report PDU.) There was considerable support for this proposal. Discussion of the security aspects revealed no adverse impact of the solution. It was also observed that this solution was better than sending a trap because it gave feedback directly the requestor, and that a trap would still be sent in the case of authentication failures. It would probably be useful to have a MIB object to enable/disable the sending of Report PDUs. It was also suggested that a Report should never be sent as a result of receiving a message sent to a non-unicast address. Karl Auerbach -- OID Compression Karl stated a problem that a significant portion of SNMP messages are taken up by OIDs. It would be valuable to introduce an OID compression technique. He then proposed the technique of defining one (or more) new Application-Specific tag(s) which would represent an OID with a fixed prefix (say, 1.3.6.1.2) allowing the fixed prefix to be omitted from the encoding. The tags would be ASN.1-encoded as OCTET STRINGs with the same encoding as an OID but without the fixed prefix. WEDNESDAY, 7 DECEMBER It was decided to devote this session to consideration of the Admin Framework, with the intention to first look at the problem and broad solutions. Steve Waldbusser -- Simplified Security Conventions Steve first discussed the problem. He reviewed an updated statement of the problem from that he had used when introducing the Simplified Security Conventions at a previous IETF meeting. In particular, he emphasized that the real problem is not only that there is too much information for humans to remember, but more importantly that there is no standard way to get the information configured into new entities. He suggested that the best solution at this stage was to introduce a model on top of the existing framework. Leaving the basic framework unchanged would have the advantages that we know it, and it leaves room for other models to be introduced on top of it to handle features omitted in Simplified Security (e.g., proxy). It was pointed out that ``Simplified Security'' may be a misnomer, since the level of security is almost the same as in RFC 1446; rather, it is the admin. facilities which are simplified. It was also pointed out that implementing less than the whole of 1445/6/7 is a matter of conformance, rather than of specification. Steve also proposed that the noAuth/noPriv parties be 0.0 and be used with a constant context. He further questioned whether the noAuth/noPriv parties need to be stored in the partyTable. He gave an example of how an agent would be configured; he claimed a manager would not need to be configured but would rather receive all the information it needed from the user. To support this model, it is necessary that a party's clock never be artificially advanced. On completion of Steve's presentation, Bob Stewart asked if there was consensus on this approach, but Jeff Case asked to make a presentation before deciding this. Jeff Case -- Problems With the Admin Framework Jeff gave a different perspective on the Admin framework. He stated that he was willing to consider changes where necessary, including changing INDEX clauses or whatever else was deemed necessary. He went on to briefly outline several areas of concern: o Having a user-based model (i.e., Simplified Security Conventions) on top of a machine-based model (i.e., 1445/6/7) leads to some issues that are as yet unresolved. o The use of XOR as the sole means of changing secrets is problematic. o SET requests need to be able to configure both managers and agents (running in the same system). o Well-known party OIDs should be used. o The mechanism for determining where Informs are sent is unclear, and how is it related to where Traps are sent. o The amount of replication of information needed to handle multiple transport addresses, both agents with multiple addresses and multiple addresses as the destination of traps. o The need for changes in the meanings of StorageType (e.g., in the meaning of `permanent'). o The greater-than-necessary replication of rows in the context/party/ACL tables, e.g., in the contextTable when different views are needed for read-only and read-write views, and in the partyTable by having multiple rows for each ``secure-id''; both of these also result in additional aclTable rows. o The use of the word ``clock'' with a different meaning to regular English usage; the word ``ratchet'' would be better. o The use of conventions (e.g., initialPartyId) which are not mandatory. Robust implementations cannot assume that all other systems will conform to the conventions. o The nature and amount of information which is needed to specify how a SNMPv2 message is to be sent. In particular, the M2M MIB specifies just a context; RFC 1503 specifies a context and a QoS. Whichever is correct needs to be standardized. o With bilingual agents being the norm, the use of the Party MIB to represent SNMPv1 communication is essential. However, the method of storing the length of a community string in partyAuthPrivate is problematic. After Jeff's presentation, there was discussion of how much change was desirable. Marshall Rose, speaking as a member of the working-group, not as the Area Director, stated that 1445/6/7 represented the fifth or sixth model of the admin framework which he had implemented; each of these succeeding models had made improvements in some areas but had introduced problems in others. As such, making drastic changes to the admin framework at this time would be ``looney tunes.'' Keith McCloghrie stated that he agreed with some of Jeff's points, but not all of them. This lack of consensus led to some concern amongst attendees. THURSDAY, 8 DECEMBER Bob Stewart outlined a timetable for the working group, as follows: 9 January - Deadline for problem statements 30 January - Deadline for solution outlines 13-17 February - Interim meeting 27 February - Deadline for revised solutions 20 March - Consensus on solutions 3 April - Danvers IETF The intent is to be finished and have no SNMPv2 meeting at the Danvers IETF. Solutions would need to contain exact instructions to the editor for updating the documents. Deirdre Kostik then presented a taxonomy and vocabulary which several folks had worked on since the previous session, as follows: Administrative Framework ____________________________________________________________________ | | | +----------+ +------------+ +-----------+ | | Config. |Simplified| |Initial | |Private Key| | | Models ----> |Config | |Party Config| ... |Config | | | |Model(1) | |Model | |Model | | | +----------+ +------------+ +-----------+ | | | | Administrative Infrastructure | | ================================================== | | ! +---------+ +------------+ +--------+ ! | | ! | Admin | | Security | | Party | ! | | ! | Model | | Protocols | | MIB | ! | | ! | 1445 | | 1446 | | 1447 | ! | | ! +---------+ +------------+ +--------+ ! | | ================================================== | |__________________________________________________________________| (1) - a renaming of the Simplified Security Conventions Deirdre suggested that we do not really want infrastructure changes. She therefore proposed the following classification of changes: Type 1 changes - clarifications, typos - the editor would be charged to make these changes as and when necessary. Type 2 changes - non-invasive optimizations, fixes, etc. Type 3 changes - changes which would result in fundamental changes to the infrastructure. The consensus was that all Type 1 changes would be accepted, and that Type 3 changes were to be avoided. Observations: o Cannot tell the difference between Type 2 and Type 3 until seeing the solution. o Does not preclude a Type-2 solution which fixes 80% of a Type 3 problem. This classification of changes applies across the board (not just for the admin framework). Bob Stewart then proceeded with the remaining outstanding proposals. Each presenter was asked to limit his/her presentation to 5 minutes, if possible, in the interests of allowing time for every one to present. [Reporter's note: as a result of this, most proposals were only covered in outline; full explanation will require the proposals to be mailed to the mailing-list.] Dave Harrington -- Indexes Dave stated a problem that very large networks require more than 64K parties. He thus proposed that the syntax of the indexes in the Party MIB should be UInteger32. He further proposed that it be explicitly stated that an agent is free to choose any values of these indexes at its own discretion. Jeff Case -- Algorithm for Changing Secrets Jeff cited the problem stated by Ran Atkinson at the earlier session (see above). In particular, that XOR is an invertible function. A solution is needed which does not use encryption. He then briefly outlined a solution using a one-way function. The manager would initiate the operation. The agent would use an unpredictable value, u, and the existing secret, s, as input to a one-way function (e.g., MD5) to generate a new secret; that is, new-secret = f(u,s). The manager would then read the value of u from the agent and perform the same calculation. A spin-lock (e.g., TestAndIncrement) would be needed to avoid problems with loss/duplication of requests. Uri Blumenthal -- New OIDs and Protocols Uri presented several proposals: o New OIDs for new Authentication and Privacy protocols. o Adding partyTAddrMask. o Adding a ViewFamilyName as an OCTET STRING. o Adding party...KeyExpirationTime o The use of 0.0 as party OIDs, but with the ability to turn off their use. o The use of community strings in defining context OIDs. Uri was asked to present more detail on these in a problem/solution format on the mailing-list. Steve Waldbusser -- Auto-Discovery Steve stated the problem that there is no mechanism for auto-discovery of SNMP agents. A solution is needed which works for small and large environments. His proposal was to send a SET request having fixed party/party/context values in its message wrapper which would be applicable at all agents, but only for discovery. The SET request would include values for two variables. Each agent receiving such a message would generate a pseudo-random number and respond if the number was in a particular range indicated by the variables. A manager would vary the values of the variables so as to adjust the behaviour to the size of the network. Discussion raised the issue that a fixed context applicable to all agents does not fit the administrative framework. There was also brief discussion of the need for auto-discovery. Steve Waldbusser - Transport Addresses Steve stated a problem that a management application sometimes needs to specify the address to which a request is sent. He proposed that the administrative framework be clarified/modified to allow transport addresses to be specified by an application. He further suggested that the identification of trap destinations should not be part of the admin framework. Dave Harrington -- Auto Discovery Dave's solution for auto-discovery was to use well-known values for party/party/context for an initial message; the MIB view for these well-known values would be restricted to obtaining party/party/context values for subsequent messages. Maria Greene -- Agent Capabilities Maria stated a problem that a significant portion of an agent's capabilities remain unchanged from one release to the next. This leads to unnecessary duplication in generating AGENT-CAPABILITIES statements. She proposed that the AGENT-CAPABILITIES macro be modified to allow one invocation to include, by reference, all capabilities defined in a different invocation. Jeff Johnson -- Agent Capabilities Jeff presented a problem that the meaning of sysObjectId is overloaded. In particular, MIB-II states it is a ``kind of box'' which many perceive as being the type of hardware, whereas the use of the value of sysObjectId is also the value of an AGENT-CAPABILITIES statement for which there are different values for different software releases. Further, RFC 1444 states that snmpORID is for dynamic addition/removal of supplementary AGENT-CAPABILITIES statements. The proposed solution: a. The snmpORTable be used to indicated both static and dynamic capabilities, b. AGENT-CAPABILITIES to be referenced only by an instance of snmpORID (i.e., never by sysObjectID) c. multiple snmpORTable entries may be used to represent the static capabilities of an agent. An additional suggestion was that it would probably be desirable to include the snmpORTable in the default (noAuth/noPriv) view. Maria Greene -- Logical Devices Maria stated a problem of managers not being able to recognize which context represents a particular logical device when multiple instances of logical devices (same MIB) are supported by a single agent. She proposed that semantics be added to the snmpORTable in order to allow a row in the snmpORTable to represent a logical device. David Perkins -- Sub-Typing Dave stated a problem that the SMI does not clearly state the restrictions on sub-typing. In fact, the SMI is unnecessarily liberal in what it allows. Dave proposed a set of restrictions which would allow all sub-typing in current usage, but prohibit some of the more esoteric variations allowed by ASN.1. David Perkins -- Table Relationships Dave illustrated various ways in which MIB tables can be related: o one-to-one (c.f. AUGMENTS), o one-to-zeroOrOne (c.f. Sparse-AUGMENTS), o one-to-many (AUGMENTS-EXTENSION?), o one-to-zeroOrMany (Sparse-AUGMENTS-EXTENSION?), o one-to-one but re-ordered He proposed additional alternatives (to the INDEX clause) in the OBJECT-TYPE macro to represent some of these relationships. Conclusion Bob Stewart asked for all the presenters to send e-mail to the mailing-list in a problem/solution format and giving specific details of their solutions.