Proposal for SNMPv2t
Bert Wijnen <wijnen@vnet.ibm.com> Thu, 13 July 1995 22:53 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12381; 13 Jul 95 18:53 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12377; 13 Jul 95 18:53 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa22944; 13 Jul 95 18:53 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa27856; 13 Jul 95 17:46 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa27852; 13 Jul 95 17:24 EDT
Message-Id: <199507132117.RAA16827@relay.tis.com>
Received: from vnet.ibm.com(199.171.26.4) by relay.tis.com via smap (g3.0.1) id xma016825; Thu, 13 Jul 95 17:17:46 -0400
Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9198; Thu, 13 Jul 95 17:23:49 EDT
Date: Thu, 13 Jul 1995 23:22:33 -0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bert Wijnen <wijnen@vnet.ibm.com>
To: snmpv2@tis.com
cc: natale@acec.com, URI@watson.ibm.com, HIEN@watson.ibm.com
Reply-To: snmpv2@tis.com
Subject: Proposal for SNMPv2t
Dear Working Group members, first a preamable. Around line 100 you
then find the full text of our proposal.
A team consisting of Bert Wijnen, Uri Blumenthal, N. C. Hien, and
Bob Natale hereby submits a proposal for formal consideration by
the SNMPv2 Working Group. Our proposal centers on the concept
of "transitional authentication"; it derives from the basic ideas
formerly referred to as "SNMPv1.5", but it presents them in a
more technically precise and complete package and harmonizes
them with the latest adjustments to the overall SNMPv2 design
and draft documents.
We have done our best to be responsive to Bob Stewart's recent
set of recommendations wrt such proposals:
1. A proposal is not complete unless it has sufficient
written, public details for someone else to implement it.
Our proposal relies primarily upon (and makes reference to)
well-established existing specifications and presents complete
technical details wrt any adjustments that need to be made to
those specifications. Of course, we are willing to provide
more details in response to any questions or constructive
criticism offered during the WG's review of this proposal.
2. A proposal does not make the final cut unless it has at
least one implementation.
The team members plan to have multiple independent implementations
by the required date. We hereby solicit anyone else with an
interest in doing an implementation of this proposal to join
the effort at the earliest possible time. Many SNMP implementors
will find that they already have virtually all of the SNMPv2t
components in code.
3. Proposals may and should borrow from one another and be
refined and corrected up to the final cut. As this happens
authors must be quick to abandon their pride and sign up for
a common synthesis of solutions. The earlier this happens,
the better.
We have already borrowed heavily from existing SNMP specifications,
from other proposals which have already been aired, and from
several substantial pre-proposal postings which have appeared.
We are strongly inclined to continue with this approach in
a cooperative effort to help the WG reach consensus at the
earliest possible time. Adoption of the SNMPv2t proposal does
*not* entail the "defeat" or rejection of any other proposal.
4. Proposals must resolve the security threats of masquerade,
message modification, and message replay.
This recommendation presents something of a "Catch-22" for our
proposal. We believe we have addressed it in the following
ways:
- we do not introduce any new security threats
- we rely, temporarily, on the moral strategy of
"no offense is the best defense" in certain situations
- we (individually and/or collectively) plan to contribute
associated proposals to strengthen security options
that can augment the "transitional authentication"
- we are inclined to converge on a win/win basis with any
security model proposal that can meet our requirements
for support of the installed base, stability, and timeliness
- we are open to other ideas on this matter (and others)
5. Proposals must consider the limitations and needs of small
systems and environments with little need for security while
providing power for larger systems and more strong, flexible
security.
Our proposal should rate very highly wrt consideration for the
limitations and needs of the kinds of users characterized by
the first part of that recommendation. And we do nothing to
preclude any separate and/or any encompassing solutions that
satisfy the needs of users in the latter category.
6. Proposals and their results must be clear, easy to implement,
easy to understand, and easy to use.
We believe that most readers who examine our proposal will easily
recognize that it satisfies these recommended attributes quite fully.
7. Proposals must consider existing investments in SNMPv1
implementation and existing investments in understanding
SNMPv2 mechanisms, if not existing SNMPv2 code.
Again, we believe that most reviewers will see that we our
proposal is maximized on exactly this recommendation. The
fact that we have achieved that goal is, we believe, the
primary reason that the WG should come to consensus on it
at the earliest possible time.
With that long preamble (guess which of the author's is
responsible for that! :-), we now respectfully request a
half-hour or so of your time to review the SNMPv2t proposal,
after which we would welcome open discussion of your reactions
to it.
And we thank you in advance for your time and consideration.
Bert Wijnen, Bob Natale, Uri Blumenthal, Nguyen Hien.
--------------- cut here --------------------------------------------
Internet Draft SNMPv2t July 1995
SNMPv2t
Simple Network Management Protocol
Version 2 with Transitional Authentication
Thu Jul 13, 11:00pm CET 1995
Bert Wijnen, Uri Blumenthal, Nguyen C. Hien
T.J. Watson Research Center, IBM Corp.
Yorktown Heights, NY, USA
Bob Natale
ACE*COMM
Gaithersburg, MD, USA
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as 'work in
progress'.
Expires December 1995 [Page 1]
"
Internet-Draft SNMPv2t July 1995
1 Introduction
The SNMPv2 Working Group has accomplished much good work thus far
by refining and extending the definition of management information,
by improving protocol operations in several important ways, and by
enriching and formalizing compliance statements. Improvements in
these areas have been discussed and consensus has been reached on a
set of documents that are ready to be moved forward to Draft
Standard on the Internet standards track.
These documents are:
o INTRO - Introduction to SNMPv2 [1]
o SMI - Structure of Management Information for SNMPv2 [2]
o TC - Textual Conventions for SNMPv2 [3]
o PROTO - Protocol Operations for SNMPv2 [4]
o TM - Transport Mappings for SNMPv2 [5]
o MIBv2 - Management Information Base for SNMPv2 [6]
o CONF - Conformance Statements for SNMPv2 [7]
o COEX - Coexistence between SNMPv1 and SNMPv2 [8]
A few major issues have not been settled yet. For the most part,
those issues concern the SNMPv2 "security architecture",
encompassing the message wrappers, the administrative
infrastructure, and various aspects of the security protocols and
related security operations.
The authors of this document are quite familiar with the various
proposals that have been made concerning the SNMPv2 security
architecture and some authors have actually implemented the various
proposals and have shown that implementation is possible in an
interoperable manner.
However, it is apparent from this experience and other sources and
forms of evidence that the SNMPv2 security architecture has not
achieved the same degree of consensus that the other parts of
SNMPv2 have achieved. Furthermore, some analyses of the proposed
SNMPv2 security architecture suggest that it might face significant
hurdles in the marketplace due to its inherent complexity and
susceptibility to rapidly changing technology alternatives.
However, none of those observations is intended to suggest that any
of the authors of this document consider security in network
management operations to be unimportant or an improper goal for the
IETF network management area. We just share a concern over the
timeliness of deploying improvements to SNMP in commercial products
and reasonable ease-of-use attributes for a vast majority of
network management personnel.
In December 1994 at the San Jose IETF, it became clear that the
SNMPv2 security architecture needed some changes to simplify its
Expires December 1995 [Page 1]
"
Internet-Draft SNMPv2t July 1995
operational usage by network management personnel. But at that
time it also seemed that most (if not all) the changes would be of
an evolutionary type. However, since then we have seen several
proposals of a revolutionary type, and at the time of this writing
the floor is open for yet other (r)evolutionary proposals.
The latest proposal (USEC or User-based Security Model [9]) seems
quite easy to implement (some authors of this document are working
on this in parallel with this SNMPv2t proposal). However, it
leaves out one very important requirement that was addressed by the
previous SNMPv2 security architecture--namely, remote
configuration. And as soon as remote configuration needs to be
added, then we foresee another round of "healthy" (and lengthy)
debates...with additional negative impact on both the timeliness
and, possibly, ease-of-use attributes of the resulting
specification(s).
That is all well and good, and we all support and will continue to
support the efforts and goals of the SNMPv2 Working Group. A full
SNMPv2 standard, including an administrative framework, a security
architecture, and remote configuration, is indeed what we all
strive for. But the authors also feel that the SNMPv2 proposals to
date have failed to pay sufficient attention to the realistic
requirements of backwards compatibility with SNMPv1 products, user
configurations, and experience base.
In sum, we feel that a more "transitional" approach can match the
recognized achievements of the SNMPv2 Working Group to date with
the current needs of major segments of the marketplace, resulting
in the rapid and wide deployment of many SNMPv2 improvements and
the orderly transition of community-based user configurations to
more secure authentication and privacy mechanisms as they emerge
from the Working Group at some time in the future.
Therefore:
o We feel that the SNMPv2 Working Group is far from consensus on
the specifics of the security architecture and remote
configuration.
o Even if the Working Group reaches consensus by the currently
proposed deadline (9/20/95) then the mere fact that we have
seen such drastic and revolutionary changes since the December
1994 IETF meeting means (in our judgment) that no product
vendor can prudently assume the outcome to be stable enough to
justify shipping products based on that outcome to customers.
o We also feel that the SNMPv2 Working Group can no longer delay
the market introduction/exploitation of the many important
improvements that the Working Group has reached stable
Expires December 1995 [Page 2]
"
Internet-Draft SNMPv2t July 1995
consensus on--namely, those covered by the RFCs recommended for
advancement to Draft Standard by the Working Group Chairman
(see list of documents above).
o We recommend that the SNMPv2 Working Group and the Network
Management Area Director petition the IESG to move the
recommended documents to Draft Standard as soon as possible and
independently of the movement of the other documents.
o We recommend that the SNMPv2 Working Group quickly reach
consensus on this SNMPv2t transitional approach (using the
RFC1157 [10] message wrapper and community-based authentication
with the SNMPv2 SMI and PDUs) so that the SNMP marketplace--
vendors, buyers, and users--can start exploiting the fruits of
the long, hard work of the SNMPv2 Working Group without further
undue delay.
o We recommend that the SNMPv2 Working Group then take ample time
to further study, define, and specify the eventual SNMPv2
administrative framework, security architecture, and remote
configuration features necessary to provide and support
authentication and privacy.
This document defines how the stable pieces of the SNMPv2 RFCs
(those recommended by the Working Group Chairman for advancement to
Draft Standard on the Internet standards track) can be exploited
using the well-known and widely deployed RFC1157 (SNMPv1)[10]
message wrapper and community-based authentication scheme to carry
and process SNMPv2 "payloads" (SNMPv2 PDUs [4] using the SNMPv2 SMI
[2] and other SNMPv2 supporting components).
The authors recognize that RFC1157 (SNMPv1) [10] community-based
authentication is intrinsically insecure (that is, users must rely
on mechanisms external to the protocol if they want increased
authentication and/or privacy). But we also recognize that the
large installed base of existing community configurations will need
to be "transitioned" over time, in a gradual and orderly manner, to
a more secure SNMP security architecture when one or more such
designs eventually reach Draft Standard on the Internet standards
track.
That is why we have characterized our proposal as a "transitional"
one. (In fact, we think that all future major SNMP version
evolutions should, by default, have to include a transitional
alternative as well.) And, although the security inherent in the
network management protocol itself will not be improved with this
SNMPv2t specification, neither will it be lessened. Furthermore,
this proposal offers the SNMP marketplace numerous other benefits
at a very low incremental cost relative to the existing SNMPv1
installed base.
Expires December 1995 [Page 3]
"
Internet-Draft SNMPv2t July 1995
The following are among the major expected benefits of the SNMPv2t
implementation and deployment alternative:
o Widely understood and accepted parts of SNMPv2 will be put to
work with minimal additional delay.
o Easy and quick implementation and deployment by vendors.
o Slip-streamable introduction into the field.
o No administrative reconfiguration required by users to achieve
"better SNMP" with same level of security currently used today.
o Smoother transition to future more secure SNMP products
(certainly for the users; and possibly for most vendors too).
Expires December 1995 [Page 4]
"
Internet-Draft SNMPv2t July 1995
2 Elements of the Model
This section contains definitions required to realize the security
model defined by this memo. For the most part, readers should
understand that the security model intended is identical to that
described in RFC1157 [10] and we have opted not the replicate all
of the relevant text from that document here. The sections that
follow are meant to explain the small number of adaptations
required by certain features of the SNMPv2 specifications which
have been recommended for advancement to Draft Standard.
2.1 SNMPv2t Community Identities
Management operations using this security model make use of a
defined set of community identities (community names). For any
SNMPv2t community on whose behalf management operations are
authorized at a particular SNMPv2 agent, that agent must have
knowledge of that community. An SNMPv2 manager that wishes to
communicate with a particular agent must also have knowledge of a
community known to that agent, including knowledge of the
applicable attributes of that community.
A community and its attributes are defined as follows:
<communityName>
An octet string representing the name of the community.
<authorizedOperations>
operations that are allowed on behalf of this community.
<readView>
A MIBview defining all the object instances for which
access is granted for read operations.
<writeView>
A MIBview defining all the object instances for which
access is granted for write operations.
<type>
The type of this community (local, remote or proxy).
Note: The above list of attributes is not an exhaustive list.
Implementations may have other or different attributes. This list
is not meant to prescribe an implementation of community names and
their attributes. Instead, the list above is used to help explain
the Elements of Procedure later on in this document. For
example, an implementation may not have any proxy support, and so
the value of proxy for the <type> attribute will never hold. In
this case, an implementation may just assume that an SNMPv2 entity
Expires December 1995 [Page 5]
"
Internet-Draft SNMPv2t July 1995
in the manager role is using a community as if the <type=remote>,
while an agent uses the community as if the <type=local>.
2.2 Access Policy
An administration's access policy determines the access rights of
communities. For SNMPv2t, the fundamental parameters of any
compliant access policy are defined in Section 3.2.5, "Definition
of Administrative Relationships", in RFC1157 [10]. Compliant
implementations of that authoritative source allow for
implementation-specific extensions to support an associated
"authentication scheme". Many SNMP implementers have, in fact,
used such extensions to improve the degree of security provided by
the community model (e.g., using the source address as a further
qualifier).
For a particular SNMPv2t community, that community's access rights
are given by the associated <authorizedOperations>, and for a
<type=local> community, a <readView> and a <writeView>. The
read-view is the set of object instances authorized for the user
when reading objects. Reading objects occurs when processing a
retrieval (get, get-next, get-bulk) operation and when sending a
notification. The write-view is the set of object instances
authorized for the user when writing objects. Writing objects
occurs when processing a set operation. A community's access
rights may be different at different agents.
2.3 SNMPv2t Messages
The syntax of an SNMPv2t message differs from that of an SNMPv1
message as follows:
o The version component is changed to 1.
o The data component contains an SNMPv2 PDU
An SNMPv2t message is an ASN.1 value with the following syntax:
Expires December 1995 [Page 6]
"
Internet-Draft SNMPv2t July 1995
Message ::=
SEQUENCE {
version
INTEGER {v2t (1)},
community -- as per RFC1157
OCTET STRING, -- SNMPv1 communityName
data
PDUs -- SNMPv2 PDUs
}
2.4 Local Configuration Datastore (LCD)
Each SNMPv2 entity maintains a local conceptual database, called
the Local Configuration Datastore (LCD), which holds its known set
of information about SNMPv2t communities and other associated
(e.g., access control) information.
It is a local implementation issue as to whether information in the
LCD is stored information or whether it is obtained dynamically
(e.g., as a part of an SNMPv2 manager's API) on an as-needed basis.
Expires December 1995 [Page 7]
"
Internet-Draft SNMPv2t July 1995
3 Elements of Procedure
This section describes the procedures followed by an SNMPv2 entity
in processing SNMPv2t messages.
3.1 Generating a Request or Notification
This section describes the procedure followed by an SNMPv2 entity
whenever it generates a message containing a management operation
(either a request or a notification) on behalf of an application
belonging to a community.
1. Information concerning the communityName is extracted from the
LCD. The transport domain and transport address to which the
operation is to be sent is determined.
2. The operation is serialized (i.e., encoded) according to the
conventions of [5] and [4] into a PDUs value.
3. An SNMPv2t message is constructed using the ASN.1 Message
syntax with the version component set to the value 1.
4. The constructed Message value is serialized (i.e., encoded)
according to the conventions of [5] and [4].
5. The serialized Message value is transmitted to the determined
transport address.
3.2 Processing a Received Communication
Note: Since SNMPv2t messages are authenticated based on a
communityName similar to how SNMPv1 messages are authenticated, we
use the objects snmpV1BadCommunityNames and snmpV1BadCommunityUses
[6] as counters.
Note: We hope that the definition of the Report-PDU can be moved
into [4] before this document moves to an RFC at the Draft Standard
level. Based on that hope we have included the generation of
Report-PDUs. If this hope turns out to be false, then we will
remove the generation of the Report-PDU in the following steps.
This section describes the procedure followed by an SNMPv2 entity
whenever it receives an SNMPv2t message. This procedure is
independent of the transport service address at which the message
was received.
1. The snmpStatsPackets counter [6] is incremented. If the
received message is not the serialization (according to the
Expires December 1995 [Page 8]
"
Internet-Draft SNMPv2t July 1995
conventions of [5] of a Message value, then the
snmpStatsEncodingErrors counter [6] is incremented, and the
message is discarded without further processing.
2. If the value of the version component has a value other than 1,
then the message is either processed according to some other
version of this protocol, or the snmpStatsEncodingErrors
counter [6] is incremented, and the message is discarded
without further processing.
3. The communityName is extracted from the community component of
the Message value.
4. Information about the value of the communityName is extracted
from the LCD. If no information is available, then the
snmpV1BadCommunityNames counter[6] is incremented, a Report-PDU
is generated, and the received message is discarded without
further processing. However, if the SNMPv2 entity is acting
in an agent role and the snmpV2EnableAuthenTraps object [6] is
enabled, then it sends authenticationFailure traps [6]
according to its configuration.
5. The SNMPv2 operation type is determined from the ASN.1 tag
value associated with the PDUs component.
6. If the SNMPv2t message contains a Report-PDU, then the
request-id in the PDU is correlated to an outstanding request,
and if the correlation is successful, the appropriate function
(e.g., informing the application, proxy error propagation,
etc.) is invoked. Otherwise, the snmpV1BadCommunityUses
counter [6] is incremented, and the received message is
discarded without further processing.
7. If the SNMPv2 operation type is either a Get, GetNext, GetBulk,
or Set operation, then:
a. the LCD is consulted for access rights authorized for
communications on behalf of the community concerning
management information for the particular SNMPv2 operation
type.
b. if the SNMPv2 operation type is not among the authorized
access rights, then the snmpV1BadCommunityUses counter [6]
is incremented. The received message is then discarded
without further processing after generation and
transmission of a response message. This response message
is sent on behalf of the same community. Its var-bind-list
and request-id components are identical to those of the
received request. Its error-index component is zero and
its error-status component is authorizationError [4].
Expires December 1995 [Page 9]
"
Internet-Draft SNMPv2t July 1995
c. The information extracted from the LCD concerning the
community, together with the sending transport address of
the received message is cached for later use in generating
a response message.
d. if the LCD information indicates the SNMPv2t community is
of type local, then the management operation represented by
the PDUs value is performed by the receiving SNMPv2 entity
with respect to the relevant MIB view associated with this
community according to the procedures set forth in [4],
where the relevant MIB view is determined according to the
community and the type of operation requested.
e. if the LCD information indicates the community is of type
proxy, then:
1) the LCD is consulted to extract information on how to
forward the request (e.g. a communityName to be used
for forwarding). If this information is not available,
the snmpStatsProxyDrops counter [6] is incremented, a
Report-PDU is generated, and the received message is
discarded.
2) a new SNMPv2t message is constructed: its PDUs
component is copied from that in the received message
except that the contained request-id is replaced by a
unique value (this value will enable a subsequent
response message to be correlated with this request); A
new communityName (as extracted from the LCD) is used
as communityName.
3) the information cached in Step 7c above is augmented
with the request-id of the received message as well as
the request-id of the constructed message.
4) the constructed message is forwarded to the appropriate
transport address.
8. If the SNMPv2 operation type is either a SNMPv2-Trap, Inform,
or Response operation, then:
a. if the LCD information indicates the community is of type
local, then the received message is discarded without
further processing.
b. if the LCD information indicates the community is of type
remote then the management operation represented by the
PDUs value is performed by the receiving SNMPv2 entity
according to the procedures set forth in [4].
Expires December 1995 [Page 10]
"
Internet-Draft SNMPv2t July 1995
c. if the LCD information indicates the community is of type
proxy, and the SNMPv2 operation type is a Response, then:
1) the request-id is extracted from the PDUs component of
the received message. The communityName and extracted
request-id are used to correlate this response message
to the corresponding values for a previously forwarded
request by inspecting the cache of information as
augmented in 7e3 on page 10 above. If no such
correlated information is found, then the received
message is discarded without further processing.
2) a new SNMPv2t message is constructed: its PDUs
component is copied from that in the received message
except that the contained request-id is replaced by the
value saved in the correlated information from the
original request; its communityName is set to the value
saved from the original request.
3) the constructed message is forwarded to the transport
address saved in the correlated information as the
sending transport address of the original request.
4) the correlated information is deleted from the cache of
information.
d. if the LCD information indicates the community is of type
proxy and the SNMPv2 operation type is an Inform or
SNMPv2-Trap, then:
1) a unique request-id is selected for use by all
forwarded copies of this request. This value will
enable a subsequent response message to be correlated
with this request.
2) information is extracted from the LCD concerning all
communityNames with which the received message is to be
forwarded.
3) for each such combination whose access rights permit
Inform or SNMPv2-Trap operations (as appropriate) to be
forwarded, a new SNMPv2t message is constructed: its
PDUs component is copied from that in the received
message except that the contained request-id is
replaced by the value selected in 8d1 above; its
communityName is set to the value extracted in step
8d2.
4) if the SNMPv2 operation type of the received message is
an Inform, then for each constructed SNMPv2t message,
Expires December 1995 [Page 11]
"
Internet-Draft SNMPv2t July 1995
information concerning the communityName, request-id
and sending transport address of the received message,
as well as the request-id and communityName of the
constructed message, is cached for later use in
generating a response message.
5) each constructed message is forwarded to the
appropriate transport address.
3.2.1 Additional Details
For the sake of clarity and to prevent the above procedure from
being even longer, the following details were omitted from the
above procedure.
3.2.1.1 ASN.1 Parsing Errors
For ASN.1 parsing errors, the snmpStatsEncodingErrors counter [6]
is incremented and a Report-PDU is generated whenever such an ASN.1
parsing error is discovered.
3.2.1.2 Generation of a Report-PDU
Some steps specify that the received message is discarded without
further processing whenever a Report-PDU is generated. However,
first, an SNMPv2 manager never generates a Report-PDU; second, a
Report-PDU must not be generated unless and until the SNMPv2
operation type can be determined, so as to ensure that a Report-PDU
is not generated due to the receipt of a Report-PDU.
In addition, a generated Report-PDU must whenever possible contain
the same request-id value as in the PDU contained in the received
message. Meeting these constraints normally requires the message
to be further processed just enough so as to extract its SNMPv2
operation type and request-id. Even in the case where the
communityName is unknown, the SNMPv2 operation type and request-id
must be extracted. The only situation in which the SNMPv2
operation type and request-id cannot be extracted is when an ASN.1
parsing error occurs.
3.3 Generating a Response
The procedure for generating a response to an SNMPv2 management
request is identical to the procedure for transmitting a request
(see Section 3.1, "Generating a Request or Notification" on
page 8), with these exceptions:
Expires December 1995 [Page 12]
"
Internet-Draft SNMPv2t July 1995
o The response is sent on behalf of the same community as the
request.
o The PDUs value of the responding Message value is the response
which results from performing the operation specified in the
original PDUs value.
o The serialized Message value is transmitted using the transport
address and transport domain from which its corresponding
request originated - even if that is different from any
transport information obtained from the LCD.
Expires December 1995 [Page 13]
"
Internet-Draft SNMPv2t July 1995
4 Acknowledgements
The authors wish to thank the contributions of the SNMPv2 Working
Group in general. In particular the authors extend a special
thanks for the contributions (ideas, explanations and other forms
of support) to:
Karl Auerbach (karl@cavebear.com)
Iain Hanson (Independent Contractor, ihanson@pcs.dec.com)
Michael Kornegay (mlk@bir.com)
David Perkins (dperkins@baynetworks.com)
Aleksey Romanov (ralex@world.std.com)
5 References
[1] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Keith
Steven Waldbusser, Introduction to SNMPv2, SNMP Research Inc,
Cisco Systems Inc, Dover Beach Consulting Inc, Carnegie Mellon
University, draft-kzm-snmpv2-intro-alt-00.txt, June 1995.
[2] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Keith
Steven Waldbusser, SMI formation for version 2 of the Simple
Network Management Protocol (SNMPv2), SNMP Research Inc, Cisco
Systems Inc, Dover Beach Consulting Inc, Carnegie Mellon
University, draft-kzm-snmpv2-smi-alt-00.txt, June 1995.
[3] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Keith
Steven Waldbusser, Textual Conventions for version 2 of the
Simple Network Management Protocol (SNMPv2), SNMP Research
Inc, Cisco Systems Inc, Dover Beach Consulting Inc, Carnegie
Mellon University, draft-kzm-snmpv2-tc-alt-00.txt, June 1995.
[4] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Keith
Steven Waldbusser, Protocol Operations for version 2 of the
Simple Network Management Protocol (SNMPv2), SNMP Research
Inc, Cisco Systems Inc, Dover Beach Consulting Inc, Carnegie
Mellon University, draft-kzm-snmpv2-proto-alt-00.txt, June
1995.
[5] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Keith
Steven Waldbusser, Transport Mappings for version 2 of the
Simple Network Management Protocol (SNMPv2), SNMP Research
Inc, Cisco Systems Inc, Dover Beach Consulting Inc, Carnegie
Mellon University, draft-kzm-snmpv2-tm-alt-00.txt, June 1995.
Expires December 1995 [Page 14]
"
Internet-Draft SNMPv2t July 1995
[6] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Keith
Steven Waldbusser, Management Information Base for version 2
of the Simple Network Management Protocol (SNMPv2), SNMP
Research Inc, Cisco Systems Inc, Dover Beach Consulting Inc,
Carnegie Mellon University, draft-kzm-snmpv2-mib-alt-00.txt,
June 1995.
[7] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Keith
Steven Waldbusser, Conformance Statements for version 2 of the
Simple Network Management Protocol (SNMPv2), SNMP Research
Inc, Cisco Systems Inc, Dover Beach Consulting Inc, Carnegie
Mellon University, draft-kzm-snmpv2-conf-alt-00.txt, June
1995.
[8] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Keith
Steven Waldbusser, Coexistence between version 1 and version 2
of the Internet-standard Network Management Framework, SNMP
Research Inc, Cisco Systems Inc, Dover Beach Consulting Inc,
Carnegie Mellon University, draft-kzm-snmpv2-coex-alt-00.txt,
June 1995.
[9] James M. Galvin, Keith McCloghrie, Marshall T. Rose and Glen
Waters, User Based Security Model for version 2 of the Simple
Network Management Protocol (SNMPv2), Trusted Information
Systems, Cisco Systemc Inc, Dover Beach Consulting Inc, Bell
Northern Research, draft-kzm-snmpv2-sec-alt-00.txt, June 1995.
[10] Jeffrey D. Case, Mark Fedor, Martin Lee Schoffstall and James
R. Davin, Simple Network Management Protocol (SNMP), SNMP
Research, Performance Systems International, MIT Laboratory
for Computer Science, RFC 1157, May 1990.
Expires December 1995 [Page 15]
"
Internet-Draft SNMPv2t July 1995
6 Security Considerations
Security considerations are not discussed in this memo.
7 Authors' Addresses
Bert Wijnen
IBM International Operations
Watsonweg 2
1423 ND Uithoorn
The Netherlands
Phone: +31-2975-53316
Fax: +31-2975-62468
E-mail: wijnen@vnet.ibm.com
Bob Natale
ACE*COMM
209 Perry Pkwy
Gaitherburg MD 20877
USA
Fax: +1-301-921-0434
Phone: +1-301-258-9850
E-mail: natale@acec.com
Uri Blumenthal
IBM T.J.Watson Research Center
P. O. Box 218
Yorktown Heights, NY 10598
USA
Phone: +1-914-945-1267
E-mail: uri@watson.ibm.com
Nguyen C. Hien
IBM T.J.Watson Research Center
P. O. Box 218
Yorktown Heights, NY 10598
USA
Phone: +1-914-945-2806
E-mail: hien@watson.ibm.com
Expires December 1995 [Page 16]
"
Internet-Draft SNMPv2t July 1995
8 Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Elements of the Model . . . . . . . . . . . . . . . . . . . . 5
2.1 SNMPv2t Community Identities . . . . . . . . . . . . . . . 5
2.2 Access Policy . . . . . . . . . . . . . . . . . . . . . . 6
2.3 SNMPv2t Messages . . . . . . . . . . . . . . . . . . . . . 6
2.4 Local Configuration Datastore (LCD) . . . . . . . . . . . 7
3 Elements of Procedure . . . . . . . . . . . . . . . . . . . . 8
3.1 Generating a Request or Notification . . . . . . . . . . . 8
3.2 Processing a Received Communication . . . . . . . . . . . 8
3.2.1 Additional Details . . . . . . . . . . . . . . . . . . 12
3.2.1.1 ASN.1 Parsing Errors . . . . . . . . . . . . . . 12
3.2.1.2 Generation of a Report-PDU . . . . . . . . . . . 12
3.3 Generating a Response . . . . . . . . . . . . . . . . . 12
4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 14
5 References . . . . . . . . . . . . . . . . . . . . . . . . 14
6 Security Considerations . . . . . . . . . . . . . . . . . . 16
7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 16
Expires December 1995 [Page 17]
"
- Proposal for SNMPv2t Bert Wijnen
- Re: Proposal for SNMPv2t Aleksey Y Romanov
- Re: Proposal for SNMPv2t Karl Auerbach