Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/snmpv2/snmpv2-minutes-95feb.txt

Text File | 1995-05-27 | 13KB | 343 lines

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.