Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/snmpv2/snmpv2-minutes-94dec.txt

Text File | 1995-02-28 | 28KB | 651 lines

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.