analysis of proposals

[[e-mail]]

several of us have been looking carefully at the various proposals

the following document is a resulting analysis

it is clear that every proposal had good ideas

regrettably, every proposal also had architectural as well as technical
defects, some severe

as such, no proposal, on its own, is adequate or acceptable

consequently, it looks like the working group must come up with a synthesis
but it looks like such a synthesis is possible, and if done properly, can
be better than the original snmpv2 design

we welcome your comments to the list

regards,
jdc
----------------------------------------------------------------------------






                   Problems with the SNMPv2 Proposals







                   Problems with the SNMPv2 Proposals

                               Tue Aug 22

                            Jeffrey D. Case
                          SNMP Research, Inc.
                             [e-mail]

                            Dave Harrington
                        Cabletron Systems, Inc.
                             [e-mail]

                               David Levi
                          SNMP Research, Inc.
                             [e-mail]

                            Brian J. O'Keefe
                        Hewlett Packard Company
                             [e-mail]

                              Jon Saperia
                           BGS Systems, Inc.
                            [e-mail]

                            Steve Waldbusser
                     International Network Services
                           [e-mail]


1.  Introduction

This document is an analysis of the proposals which have been submitted
for consideration by the SNMPv2 working group in response to a call for
alternate designs of an administrative model.  It outlines some of the
problems with regard to the current set of proposals.  Rather than
analyze each specific proposal, it concentrates on the problems to be
resolved by synthesizing the proposals.








                                                                [Page 1]





                   Problems with the SNMPv2 Proposals


The documents considered in this analysis are:
             draft-kzm-snmpv2-sec-alt-00.txt (usec)
             draft-kzm-snmpv2-adminv2-alt-00.txt (usec admin)
             draft-kzm-snmpv2-proto-alt-00.txt (proto)
             draft-kzm-snmpv2-mib-alt-00.txt (mib4v2)
             draft-kzm-snmpv2-usec-conf-alt-00.txt (configmib)
             draft-alten-snmp-sec-encap-00.txt (alten)
             draft-blumenthal-snmpv2a-community-00.txt (snmpv2a)
             draft-wijnen-snmpv2-snmpv2t-00.txt (snmpv2t)
             draft-kornegay-snmpv2-emf-00.txt (emf)
             draft-mahoney-snmpv2-features-00.txt (features)
             draft-mahoney-snmpv2-proto-alt-00.txt (mahoney protocol)
             draft-harrington-data-filter-mib-00.txt (datafilter)
             draft-harrington-control-mib-00.txt (controlmib)
             draft-romanov-simple-snmp-00.txt (simple)

While this document makes occasional references to the 17 documents
which describe the SNMPv2 Classic proposal and the 16 documents which
describe the SNMPv2 Classic+ proposal, it does not review the problems
which are particular to them.  This does not imply that these two
proposals are believed to be flawless.  Indeed, both clearly have
problems as well; they are merely outside the scope of this document.

Regrettably, some of the documents considered in this analysis "borrow"
from those two designs and have inherited one or more of their defects
from flaws in the previous two designs.

There are a number of problems with the proposals and the documents
which present them.  In the interest of brevity, this note introduces
only some of them.  The primary problems can be categorized into five
broad areas:

(1)  Model Consistency

(2)  Transmission and Processing of Notifications

(3)  Proxy Operations and the Transparency Principle

(4)  Extensibility of Authentication and Privacy Mechanisms

(5)  Standards-Based Remote Configuration

Ancillary issues and minor editorial items are not discussed herein.







                                                                [Page 2]





                   Problems with the SNMPv2 Proposals


The problems identified herein are intended as examples and are not
exhaustive.

Since many of the proposals are complementary to the user-based security
model for SNMPv2 (USEC), and the USEC documents are therefore important
to the implementation of many of the proposals, the USEC documents will
be used for most text examples.

2.  Model Consistency

The first type of problems relate to correctness and clarity issues with
regard to consistent application of a model.  These involve areas which
are presently unworkable and which will negatively impact
implementability and interoperability.

The documents which describe the proposals are confusing as a result of
multiple fundamental shifts in the underlying model which were not
carefully carried through to completion.  A synthesis of the proposals
must reconcile these shifts and present a consistent, complete model.

There are several areas of concern in this regard.  Three are:

(1)  Context uniqueness

(2)  Roles and Informs

(3)  Notification Endpoints

2.1.  Context Uniqueness

The proposals are not consistent in requiring uniqueness of contexts.
For example, the usec document says:

     Each SNMPv2 message contains a context selector which uniquely
     identifies an SNMPv2 context accessible by the SNMPv2 agent to
     which the message is directed.  At the option of the administrator,
     a context selector may uniquely identify an SNMPv2 context among
     all SNMPv2 contexts within the administrative domain.

That is, an SNMPv2 context may or may not be unique within an
administrative domain; whereas the usec admin document says:

     Thus, in order to identify an individual item of management
     information within the management domain, its context must be
     identified in addition to its object type and its instance.  Note





                                                                [Page 3]





                   Problems with the SNMPv2 Proposals


     that this requires each context to have a globally-unique
     identification within the management domain.

However, it is quite clear from the recommendations in the Appendix of
the USEC Security document that contextSelectors are most likely to be
equal to the constant zero-length string, and not at all globally
unique.

It is expected that many contexts will be administratively assigned by
agents using vendor-specific naming conventions, rather than by an
administrator using a domain-consistent administrative naming
convention.  Therefore, context names cannot be expected to be unique
within an administrative domain.

To reconcile these requirements, contexts need not be unique but must
always be coupled implicitly or explicitly with a unique identifier of
the relevant node where that context "lives" and the combination is
therefore always unique within the administrative domain.

There is, of course, a distinction between a context being uniquely
identified within an administrative domain and the need for
contextSelector to be globally unique.  Specifically, there is nothing
wrong with defining the "fully distinguished name" of a context (global
identification) to be the specified by the pair of AgentID and
ContextSelector.  It appears that this was the intention of the USEC
document and its accompanying admin document; however they need to be
more clear in this regard.  Furthermore, the overloading of AgentID is
problematic as described elsewhere in this document.

It is crucial that the USEC documents be self-consistent, and the
correct behavior in this case is for the document to be modified to
require the uniqueness of contexts.  This is one of the prerequisites to
solving problems with transparent proxies, informs, informs through
proxies, and to restore harmony with the transparency principle.

2.2.  Roles and Informs

Text describing the roles involved in an SNMPv2 transaction, and text
describing the roles involved in an inform transaction are inconsistent.

The USEC protocol document says:

     A SNMPv2 entity acts in an agent role when it performs SNMPv2
     management operations in response to received SNMPv2 protocol
     messages (other than an inform notification) or when it sends trap





                                                                [Page 4]





                   Problems with the SNMPv2 Proposals


     notifications.

     A SNMPv2 entity acts in a manager role when it initiates SNMPv2
     management operations by the generation of SNMPv2 protocol messages
     or when it performs SNMPv2 management operations in response to
     received trap or inform notifications.

Hence, it indicates that inform notifications are initiated by an entity
in a manager role and sent to another entity also acting in a manager
role.  This is the expected text, i.e., manager-to-manager inform
notifications are conducted between managers.

But in the usec document, it states

     It is that entity acting in an agent role which is authoritative
     with respect to these variables for the Inform-Request.

Since the purpose of an Inform request is to transmit information from
one manager to another, and it cannot be assumed that all managers will
be dual-role entities, i.e., with an agent component, it cannot be
assumed that all communications involve an agent.

2.3.  Notification Endpoints

The language used to refer to notification endpoints is inconsistent
among the proposals and within the proposals.  Common description of
procedure for traps and informs often use terms which are accurate only
for a trap or an inform, but are inaccurate when used to describe both
operations.

Some text assumes that all transactions will have an agent as one of the
endpoints but this is specifically not the case for inform requests
which are sent from one manager to another.

For example, the usec document states

     Included in each message is an identifier unique to the SNMPv2
     agent which is the sender or intended recipient of the message.

and the mahoney protocol document states

     If the agent is able to determine the request-id field of the
     received PDU, then it uses that value for the request-id field of
     the report PDU.






                                                                [Page 5]





                   Problems with the SNMPv2 Proposals


These assume that all transactions will have an agent as one of the
endpoints but this is specifically not the case for inform requests
which are sent from one manager to another.

Text which assumes incorrectly that all transactions include an agent
and a manager should be modified to reflect that all transactions
include two SNMPv2 entities.

3.  Traps and Informs

The current proposals devote considerably more attention to get and set
operations than to notifications.  As a result, trap and inform
operations have severe problems in the current proposals.  There are
problems with agent identification, clock synchronization, and use of
the context selector.

This section also describes how the overloading of AgentID within the
USEC proposal is problematic because the value of AgentID is used to
qualify, or scope, both the authentication information in the header as
well as the payload information in the PDU but sometimes these two uses
are in conflict with one another and a single value is insufficient for
both uses.

3.1.  Agent Identification

The usec document says:

     Each SNMPv2 agent maintains three objects:

     - agentID ...

     - agentBoots ...

     - agentTime ...

     An SNMPv2 agent is always authoritative with respect to these
     variables.  It is the responsibility of an SNMPv2 manager to
     synchronize with the agent, as appropriate.

For a manager-to-manager communication, it is possible that neither
entity is associated with an agent and thereby may not have access to
agentID, agentBoots, and agentTime.

This information is critical to clock synchronization - if neither
endpoint has access to these objects, it is impossible to synchronize





                                                                [Page 6]





                   Problems with the SNMPv2 Proposals


clocks, and it is therefore impossible to authenticate messages.

Since potentially neither entity involved in an inform transaction is
associated with an agent, the proposed scheme is insufficient.

There are three possible sources for clock synchronization information
in an Inform request: the invoking manager, the responding manager, or
some neutral third party.  The use of a third party is disharmonious
with SNMP design philosophies so it will not be discussed further.

If one uses either the invoking manager or the responding manager, then
there must be provisions for establishing clock synchronization in the
absence of agent support.

It is misleading to refer to the manager's identification objects as
agentID, agentBoots, and agentTime, since the values do not necessarily
identify an agent, and therefore the objects should be renamed to
componentID, componentBoots, and componentTime [or snmpID, snmpBoots,
and snmpTime].

3.2.  Synchronizing Inform Requests

The usec and snmpv2d proposals use the combination of a unique
identifier, a reboot count, and a timer to guard against replay attacks.

According to the USEC document,

     An SNMPv2 manager achieves time synchronization with an agent by
     issuing a maintenance function to retrieve agentID.0, agentBoots.0,
     and, agentTime.0.

     It is recommended that after these values are retrieved, that the
     manager attempt an authenticated retrieval using the new values
     before updating its local configuration datastore.

Since there is no agent involved in an Inform request, the manager must
achieve time synchronization with a manager, not an agent.

However, there is also the issue of which end is authoritative when
sending Inform Requests.  According to the USEC document:

     An SNMPv2 agent is always authoritative with respect to these
     variables.  It is the responsibility of an SNMPv2 manager to
     synchronize with the agent, as appropriate.  In the case of an
     SNMPv2 dual-role entity sending an Inform-Request, it is that





                                                                [Page 7]





                   Problems with the SNMPv2 Proposals


     entity acting in an agent role which is authoritative with respect
     to these variables for the Inform- Request.

This choice of the inform sender as the authoritative node is extremely
problematic for the following reasons:

     1) The authoritative endpoint should be the endpoint that is most
     long-lived because it must be the non-volatile store of
     authentication information.  The receiver of informs is long-lived
     because it must exist at a well-known address that is advertised to
     receive informs.  In contrast, inform senders may be transient,
     especially in examples such as a user-initiated program that
     submits a trouble ticket in an Inform request.

     2) The authoritative endpoint, by definition, always knows the
     correct secrets for any communication for which it is
     authoritative.  In contrast, the non-authoritative endpoint may not
     have that information available, especially because it needs to
     have that information available for the many endpoints it may
     communicate with.  Because of this, it is especially convenient if
     the non-authoritative endpoint is the end that is more often able
     to ask a human for the correct secrets.

     This is more convincing when one realizes that the inform sender is
     the endpoint that chooses whether or not to send an inform.  It
     stands to reason that it can choose to send informs only to those
     managers it has information about.  In contrast, the inform
     receiver does not choose who will send informs to it, so any sender
     can send it messages without regard to whether the receiver has
     been configured with the correct security information.  If the
     receiver is authoritative, this is a much more stable situation -
     then senders will only send data after they have determined the
     correct information for the receiver, and the receiver will
     implicitly have the correct information at all times.

     3) When an inform receiver receives an authenticated inform, it
     needs to pass the inform and the authenticated identity to an
     application which will base its trust of the information on that
     authenticated identity.  It is easy for the receiver to know the
     trust level for a user who is authoritatively defined on the
     receiver.  It is difficult for the receiver to know the trust level
     for a user who is defined on some other system.

Therefore, the manager that receives informs must be authoritative for
inform transactions.





                                                                [Page 8]





                   Problems with the SNMPv2 Proposals


Upon receipt of the request by the receiving entity, the packet should
be checked for authenticity and if the values of componentID,
componentBoots, and componentTime are found to be problematic, then the
receiving entity should send an appropriate Report-PDU.

In this case, the receiving entity is a logically remote manager, acting
in a manager role, and it must send a Report-PDU.  This would require a
change to the text in the usec document which states:

     A report PDU is never sent by an SNMPv2 entity acting in a manager
     role, ...

When the Report-PDU is generated, the values of xxxID, xxxBoots, and
xxxTime relevant to the receiving manager should be included so that the
initiating manager can update its notions of the remote managers' notion
of these values.  This makes synchronization and resynchronization
possible in the absence of agent support.

However, when the authoritative endpoint is changed to the receiver of
informs, the agentID in the inform must then point to the receiver,
rather than the sender.  Unfortunately, the agentID is identifying both
the endpoint that is authoritative for the MIB data, as well as the
endpoint that is authoritative for the authentication information.
These two endpoints are the same for all get, set, and trap operations,
while they must be different for inform operations.  USEC currently only
allows one of these two endpoints to be specified, and the model doesn't
make it clear which endpoint is being specified.

3.3.  Contexts in Trap and Inform Messages

Some text assumes that all SNMPv2 messages are directed to agents, and
the text states that the context provided in the message refers to a
context local to the receiving entity. The usec document states:

     An SNMPv2 context is a collection of management information
     accessible (locally or via proxy) by an SNMPv2 agent.  An SNMPv2
     agent potentially has access to many contexts.  Each SNMPv2 message
     contains a context selector which uniquely identifies an SNMPv2
     context accessible by the SNMPv2 agent to which the message is
     directed.

Traps and informs are sent to managers, for whom the context will not be
local to the receiver, but to the sender.  The message should therefore
contain a context local to the sender rather than the receiver.






                                                                [Page 9]





                   Problems with the SNMPv2 Proposals


Messages should have the context selector related to the information in
the PDU.

4.  Proxy

The elements of procedure in some proposals do not provide descriptions
of the data elements to be examined in the Local Configuration Datastore
(LCD) for proxy operations.  The lack of specifics makes it virtually
impossible to determine what must be supported in a compliant
implementation, in order to construct independent interoperable
implementations.

For example, in the usec proposal, the manipulations of context
identifiers as they pass through proxies is unclear.  The defined
transparency principle implies that the context identifiers remain
constant as traffic passes through proxies.  However, the authentication
mechanism implies that the context must change as traffic passes through
proxies.  An implementer cannot determine if a compliant implementation
must, may, or shall not allow a configuration which allows, requires, or
prohibits the remapping of context identifiers as traffic passes through
proxies.

4.1.  SNMPv2 to SNMPv1 Proxies

Although the usec coexistence document presents SNMPv2 to SNMPv1 proxies
as one of the viable coexistence and transition strategies, the elements
of procedure and the MIB design obviate this possibility.

4.2.  Notification Forwarding Through Proxies

The problems with regard to notifications and problems with regard to
proxies renders the analysis of notifications through proxies
impossible.

5.  Extensibility Mechanisms

There are several architectural issues with extensibility mechanisms in
the proposals.  Since the USEC proposals are the basis for other
proposals, the architectural problems of USEC are critical.

Areas of concern:

(1)  Proliferation of Authentication and Privacy Extensibility
     Mechanisms






                                                               [Page 10]





                   Problems with the SNMPv2 Proposals


(2)  Implementation Costs of Extensibility

(3)  Mapping Mechanisms to Users

5.1.  Proliferation

The administrative frameworks described in the proposals are extensible
to allow for future security models.  This was intended to be a feature,
and in some ways, it is, but it is also a weakness.

It is almost certain that extensibility will be required during the
useful life of the SNMPv2 specification.  New authentication and privacy
mechanisms may be needed for a number of reasons:

     - to enable new features

     - to improve ease-of-use

     - to replace mechanisms that are found to be unsound

     - to enable public key authentication once relevant patents expire

     - to enable delegated certification for addressing problems
     associated with management across administrative domains

     - to allow privacy mechanisms less encumbered by export controls


Providing for extensibility within the framework to accommodate each of
these possibilities is a GOOD THING.  SNMPv2 classic allowed for
multiple authentication and privacy protocols within a consistent naming
scheme.

However, some proposals allow for unbridled change.  The proposed
administrative frameworks allow models to specify virtually any naming
scheme.  New models can make changes to key elements such as the way
contexts are named, mechanisms for accessing views, and redefinition of
access control.  These key areas need stability.

A single, consistent naming scheme needs to be identified and adopted as
a part of a single unchanging model but with that model allowing
constrained change to accommodate changing needs, requirements,
capabilities, and perceived threats.  The constrained change needs to be
within a consistent naming scheme in order to preserve investments and
encourage reuse of stable code.





                                                               [Page 11]





                   Problems with the SNMPv2 Proposals


5.2.  Implementation Costs

As a result of unbounded extensibility, the cost of including future
models is unnecessarily high.  The cost within an agent application of a
change in the administrative framework is normally concentrated in the
core agent engine, configuration store (configuration files on open
systems or NV-RAM on embedded systems), console interfaces, a remote
configuration MIB, and remote configuration applications which effect
configuration through the MIB.  However, the cost of change is not
limited to the core agent engine and configuration- related aspects but
also includes method routines.

This may affect not only the method routines for remote configuration of
an entity, but ALL method routines.  The investment in method routines
is by far the most significant cost in implementing and deploying the
management portion of an SNMP-manageable product, and there necessarily
is a strong wish in the community to preserve investments in method
routines.

Method routines are impacted because implementation of certain classes
of MIB objects require knowledge of context information and/or knowledge
of the remote entity requesting a particular operation.  Examples
include customer network management (CNM) with multiple virtual agents
being implemented within method routines for certain MIB objects.  Other
examples include per-varbind (foreign) proxies.

Method routines which support these classes of MIB objects typically
need to have access to these data which are a part of the administrative
framework.  These data are often available today in SNMPv1 agents and
are required of SNMPv2 agents if they are to displace the installed base
and transition to SNMPv2.  The need for these data directly leads to a
need for stability in the naming of these data, including their number,
type, and size.

The cost of transitioning from SNMPv2 to the usec proposal is
illustrative. While some vendors are willing to re-engineer their
existing method routine interfaces to transition from party-party-
context naming to a new naming scheme, they are not willing to do this
each and every time a new model is developed, especially considering the
probability that multiple additional models will be proposed and
adopted.

The extensibility mechanism must be bounded by a consistent naming
scheme.






                                                               [Page 12]





                   Problems with the SNMPv2 Proposals


5.3.  Mapping Mechanisms to Users

The usec proposal introduces the concept of quality of service, or qoS.
However, the proposed use of qoS limits a user to at most one (non-null)
authentication protocol and at most one (non-null) privacy protocol.

Since qoS is defined as an ordered set, it is not easily extended to
support multiple authentication and privacy technologies which might
demand a different ordering.

The way qoS is defined makes it unnecessarily difficult to deploy
multiple authentication and privacy schemes within an administrative
domain because any given user is limited to exactly one of each and
additional pseudo-users would need to be defined to use these
alternatives, with the attendant additional administrative burden.

The qoS mechanism must be modified to better match the extensibility of
the admin and security models.

6.  Standards-based Remote Administrative Configuration

The architectural decision to exclude remote configuration from the
basic administrative framework does not adequately address market
requirements.  The timely inclusion of standards-based remote
configuration of the administrative framework is absolutely essential to
enterprise management and the success of SNMPv2.

The administrative description documents provided with the usec,
snmpv2d, and snmpv2emf proposals state that it is the role of a security
model to describe the details of the MIB for the remote configuration of
security.  However, there are several instances where this is not
sufficient.

For example, the usec design retains virtually every concept from the
original SNMPv2; however, wherever the old model contained details as to
how something related to a party, instead the new model explains that it
is the role of a security model to describe these details.

o    The original design allows a logically remote manager to configure
     the LCD of an agent

o    The original design allows a logically remote manager to configure
     a proxy agent







                                                               [Page 13]





                   Problems with the SNMPv2 Proposals


o    The original design allows a logically remote manager to configure
     the LCD of a mid-level manager

o    The original design allows a logically remote manager to configure
     the LCD of another logically remote manager

o    The original design allows a logically remote manager to configure
     an agent for trap destinations

o    The original design allows a logically remote manager to configure
     an agent for trap filtering

o    The original design allows non-privileged users to alter their
     secret keys

o    The original design accommodates the configuration requirements of
     the SNMPv1 portion of bilingual entities (albeit imperfectly)

The proposed usec design has no such capabilities or their equivalent.

The needs for remote configuration require a standards-based solution
because proliferation of private MIB-based solutions in this space would
be especially problematic and would stunt the growth and ultimate
success of SNMPv2.

These needs must be addressed in a timely fashion, contemporaneous with
the other portions of the specification, because failure to do so will:

(1)  make it impossible to be sufficiently specific in the elements of
     procedure to have an unambiguous specification;

(2)  result in the unnecessary and harmful proliferation of private
     MIB-based solutions;

(3)  cause otherwise avoidable confusion about what constitutes a
     compliant SNMPv2 implementation; and

(4)  delay implementations.

Each of these problems can and must be avoided.










                                                               [Page 14]





                   Problems with the SNMPv2 Proposals


7.  Conclusion

There is much work to be done if the proposals are to be synthesized
into a viable composite.  If the work is done to satisfactorily address
the problems identified in this document and elsewhere, then the
resultant proposal can become a positive step and a useful replacement
for the original SNMPv2 administrative framework and related documents.











































                                                               [Page 15]