INTERIM_MEETING_REPORT_ Reported by Keith McCloghrie/cisco Systems Minutes of the SNMP Version 2 Working Group (SNMPV2) The SNMPv2 Woking Group held an interim meeting in Dallas. The meeting ran from 9 am Monday, 13 February, through noon on Friday, 17 February 1995 (including some evening sessions). The following changes in status were made to the outstanding proposals: {6} Set Error Ordering The Step 2 error (noCreation) was moved to be immediately after Step 7 (as proposed in recent discussion on the mailing list). Several other clarifications to the wording of other error conditions were also agreed. {7} Autodiscovery Several alternative solutions were discussed but no final resolution was achieved. {20} Simplify Context and View A revised (see {56} below) version was accepted whereby a Acl which points to a view with no active subtrees is considered to be a valid Acl and the view a valid but empty view. To resolve the problem in which two managers collide when each create a new view with the same viewIndex, a new read-only scalar object viewNextIndex will be added whose value gives a currently unused viewIndex; the agent must guarantee that the value is not assigned to any in-use value of viewIndex (e.g., every time it is read, its value must change). An agent can use values up to 2 billion (and not wrap), or wrap the value at a smaller maximum value and ensure that re-used values are no longer used (e.g., not pointed to by any other MIB object). {23} TestAndIncr Cleanup The solution for this proposal was amended to require that the value of a TestAndIncr variable must be incremented on a reboot (since a reboot causes the state of the agent to change). {37} MIB-Level Error Code It was decided that the consensus on the level of need for this proposal was unclear, and that the solution is incomplete. Changing the PDU structure was rejected as too problematic. Including a MIB-level error code in the MSB bytes of error-status was also rejected as problematic (kludgy and leading to interoperability problems). {39} Add Auth and Encrypt OIDs The potential of CDMF being an exportable encryption algorithm, and the effect of its patent was presented, but no definitive status on these issues was available. No change will be made at this time; instead, the addition of CDMF (or any other) as a new privacy algorithm will be considered in the future as and when the export/patent issues become clearer. {43} NetworkAddress TC Due to registration issues and the current non-use of ``unions'' in TCs, this proposal was rejected. In the event that MIB objects are needed in the future which can take the value of an IPv4 or IPv6 address, the relevant working group can make its own decision. For consistency, it was also agreed to obsolete the ASN.1 tag for NsapAddress and as a replacement, define a Textual Convention for an NSAP address. {44} IPv6 Transport Mapping The use of DISPLAY-HINT for IPv6 addresses was researched. DISPLAY-HINT does not have the capability to display every format being discussed on the IPng mailing list. However, DISPLAY-HINT ``2x:'' -- an IPv6 address DISPLAY-HINT ``2x:2x:2x:2x:2x:2x:2x:2x:2d''-- for SnmpUdpIPv6TAddress were accepted. The transport mapping will also say that SnmpUdpIPv6TDomain will possibly become the preferred mapping at some future date. {49} New Enumeration for StorageType The accepted solution was modified to require every usage of StorageType to specify the columnar objects which a `permanent' row must at a minimum allow to be writable. {55} Maintenance Access The 0.0 context and the 0.0 party will not be represented in the contextTable and partyTable respectively, nor will the corresponding view and Acl in their tables. This will prevent them from being modified. The view will be partyTable and snmpStats. Creation of new entries in the partyTable and contextTable for 0.0 will be prohibited. The 0.0 context will be used for maintenance only. Use of the (noAuth) 0.0 party will be allowed to do Get/GetNext/GetBulk but not Sets (since this would allow an attacker to change the secret and reduce the clock value, and then change the secret back to its original value, thereby allowing replay attacks). It was also agreed that a view is still active if it has one or more active view subtrees, even if some of its view subtrees are notReady or notInService. An agent must return the request-id in a Report-PDU unless it gets an ASN.1 decoding error, where an ASN.1 decoding error can result either from a malformed message, or when an agent attempts to decode a message for which it does not know the destination party and thus attempts to decode by assuming it is a noPriv party. Dave Perkins proposed edits for specifying the varbinds which must be included in the Report-PDU. {56} Move viewIndex to aclEntry A revised version of this proposal was accepted due to its ability to reduce the number of required contexts and Acls. Three new columns will be added to the aclEntry: one for a read-view index, one for a write-view index, and one for a notify-view index. aclPriviliges will be retained. contextViewIndex will also be retained, but now only as an indication of whether the context is proxy/non-proxy. The use of an Acl to perform access-control was also discussed, and it was agreed that: all types of Get requests and Set requests are checked on receipt; Trap and Inform requests are checked prior to transmission; and Responses are never subject to access-control checking. Each of these tests will be performed from a single aclEntry for the party/party/context, where aclTarget refers to the party co-resident with the context and aclSubject to the other party. (For example, consider the noAuth/noPriv parties in 1447: the agent will no longer have both a 1/2/1/35 Acl and a 2/1/1/132 Acl; instead, it will have just one: a 1/2/1/163 Acl.) {65} UInteger32 and INTEGER It was agreed to retain UInteger32 for backward compatibility, but deprecate its use. A new data type Unsigned32 will be defined to use the same ASN.1 tag as Gauge32. {79} Read-Create Access Subsumed by {90}. {83} BIT STRINGs The use of BIT STRING will be removed from the SMI, due to confusion over its encoding, and to enhance capability with SNMPv1. As a replacement, the OBJECT-TYPE macro will be enhanced to allow: SYNTAX BITS { label1(0), label2(1) } with identical semantics to BIT STRING. Additional enumerations over time will be prohibited. In a v2 to v1 MIB conversion, BITS will be converted to an OCTET STRING with the enumerations contained in ASN.1 comments. The edits for updated OBJECT-TYPE and TEXTUAL CONVENTION macros will be written up. {90} Conditions on DEFVAL clauses Redefining DEFVAL to have ``teeth'' would be problematic for exiting MIBs. The potential of adding a new clause with this functionality was discussed. The result was not finally resolved. The use of read-create will be unchanged. The possibility of defining read-create-only as a new value of MAX-ACCESS (and corresponding value in other macros) was discussed. The possibility of defining another new value, accessible-for-notify, for MAX-ACCESS will also discussed. The addition of these new ACCESS values was not finally resolved. {104} ASN.1 for MIB Syntax The potential of having the SMI use BNF rather than ASN.1 to specify the syntax of a MIB was rejected due to its benefit not being worth its perceived cost. Instead, additional examples of MIB syntax will be included to cover the use of all clauses/etc. {108} GetBulk Warning The description of GetBulk processing will be clarified to mention the potential for requests with many repetitions to require a significantly greater amount of processing time. The description will also allow the ``local limitation'' due to which an agent can terminate a GetBulk to include termination due to time constraint. However, termination for this reason will not be allowed prior to one whole repetition. {110} Default MIB View Three views were defined. An agent must allow one of these to be defined as the default set of views: ___________________________________________________________________________ | | Allows |noAuth/noPriv | auth/noPriv | auth/priv | | | |--------------|-----------------|-----------------| | |Discovery| RO | RW | RO | RW | RO | RW | |--------------|---------|--------|-----|--------|--------|--------|--------| |minimum-secure| yes |internet| - |internet|internet|internet|internet| |semi-secure | yes |system | - |internet|internet|internet|internet| | | |partyMIB| | | | | | | | | + same | | | | | | | | | as 0.0 | | | | | | |--------------|---------|--------|-----|--------|--------|--------|--------| |very-secure | no |same as | - |internet|internet|internet|internet| | | | 0,0 | | | | | | |______________|_________|________|_____|________|________|________|________| {115} Multiple Logical Entities It was agreed that when logical entities are represented by contextLocalEntity, all contexts with the same value of contextLocalEntity identify the same logical entity. The snmpORTable is moved to the system group (and renamed to be sysORTable). All contexts must have a system group and a sysORTable. No other framework changes are needed to support this proposal, and thus it will be pursued outside of the SNMPv2 Working Group (which may also allow the solution to be applied to SNMPv1 agents). {117} Specifying Destinations After much discussion, no consensus was reached on this proposal. {118} Reduce Party Table Redundancy Mostly subsumed by {56}. {120} Variable length secrets in partyTable The solution of {122} will provide support for variable-length secrets, either by truncation or by extension with zeros. While extension with zeros has a weakness from a security viewpoint, it is still stronger than the use of community strings. Thus, it is presumed that this problem will be subsumed by {122}; as and when {122} is complete, we will see whether that is true. {121} IMPLIED INDEX Not Last Assuming that no standard MIBs use IMPLIED except on the last object-type in an INDEX clause, the change to allow its use only on the last object-type was accepted. [Reporter's note: a subsequent search of existing RFCs and Internet-Drafts revealed no such usage, and thus, the proposal is effectively accepted.] {122} XOR Weak for Keys It was agreed to have a single algorithm for all keys irrespective of the value of partyAuthProtocol and partyPrivProtocol. There was discussion of whether the agent or the manager should generate the new unpredictable value. The exact details of the algorithm are not yet resolved. {125} Complex Clock Rollover Recovery Part of the underlying rationale for {125} was that clock rollover caused problems for the sharing of parties. So, with the resolution of {126} (see below) the need for {125} is reduced. Thus, {125} should now be re-evaluated, and maybe rejected. {126} Simplified Configuration Model There was much discussion of the sharing of parties, which eventually reached a consensus that parties should not be shared. The view was expressed that the sharing of parties leads to a number of problems with authenticated parties, and a lesser set of problems with unauthenticated parties. As a result, SCM was modified to retain the concept of a user and a user's capabilities, but to have separate parties and Acls created for each activation of the user. These parties and the context that the user can access are named (i.e, instanced) through use of an ``agentId'' (rather than by a network-layer address). The agentId is generated by the agent to be globally unique. Further details of this modification will be written up. {128} Trap Destination This proposal was rejected after much discussion. {130} Basic Config Model Both general usage of this model and its use for bootstrapping was discussed, and a significantly modified version of this proposal was accepted. Minimum compliance will not require read-create access to the partyTable. The details of the modified proposal will be written up.