SNMPv2c draft
Bert Wijnen <wijnen@vnet.ibm.com> Fri, 15 September 1995 17:12 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16986; 15 Sep 95 13:12 EDT
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa16982; 15 Sep 95 13:12 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa15536; 15 Sep 95 13:11 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa12970; 15 Sep 95 12:12 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa12959; 15 Sep 95 11:57 EDT
Message-Id: <199509151545.LAA04776@relay.tis.com>
Received: from vnet.ibm.com(199.171.26.4) by relay.tis.com via smap (g3.0.1) id xma004770; Fri, 15 Sep 95 11:45:32 -0400
Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5504; Fri, 15 Sep 95 11:57:51 EDT
Date: Fri, 15 Sep 1995 17:57:37 -0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bert Wijnen <wijnen@vnet.ibm.com>
To: snmpv2@tis.com
Subject: SNMPv2c draft
As promised in my previous posting, here is a new SNMPv2c draft
for review and discussion. I have added change bars in the left
margin so you can quickly see where changes were made (no change
bars for spelling corrections and such).
Bert wijnen (for SNMPv2t/v2c team)
---------------------- cut here -------------------------------------
Internet Draft SNMPv2c September 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
Fri Sep 15th, 03:00pm CET 1995
| SNMPv2c
| Community-based Administrative Model for Version 2
| of the Simple Network Management Protocol (SNMPv2)
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 February 1996 [Page 1]
"
Internet-Draft SNMPv2c Sept 1995
| 1 Introduction
| A management system contains: several (potentially many)
| manageable nodes, each with a processing entity, termed an agent,
| which has access to management instrumentation; at least one
| management station; and, a management protocol. The management
| protocol is used to convey management information between the
| agent(s) and management station(s); and, for manager-to-manager
| communications, between management stations. Operations of the
| protocol are carried out under an administrative model which
| defines authentication, authorization, access control, and
| (possibly) privacy policies.
| Management stations execute management applications which monitor
| and control managed elements. Managed elements are devices such as
| hosts, routers, terminal servers, etc., which are monitored and
| controlled via access to their management information.
| It is the purpose of this document, the Community-based
| Administrative Model for SNMPv2, to define the management framework
| which realizes effective management using the SNMPv2 protocol
| operations.
| 1.1 A Note on Terminology
| The original Internet-standard Network Management Framework, as
| described in RFCs 1155 [1], 1157 [2], and 1212 [3] defined an
| initial community-based administrative model, and an initial set of
| protocol operations. For the purpose of exposition, this is termed
| the SNMP version 1 framework (SNMPv1).
| This document describes a similar community-based administrative
| model, in combination with the SNMP version 2 protocol operations.
| For the purpose of exposition, this is termed the SNMP version 2
| Community-based framework (SNMPv2c).
| It is recognized that this community-based administrative model is
| intrinsically insecure (that is, users must rely on mechanisms
| external to the protocol if they want increased authentication
| and/or privacy).
| Although the security inherent in the SNMPv2c management framework
| will not be stronger than that of the SNMPv1 framework, neither
| will it be lessened.
Expires February 1996 [Page 1]
"
Internet-Draft SNMPv2c Sept 1995
2 Elements of the Model
This section contains definitions required to realize the
| community-based administrative model defined by this memo. For the
| most part, readers should understand that the community-based
| administrative model intended is identical to that described in
RFC1157 [2] 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.
2.1 SNMPv2c Community Identities
| Management communications using this administrative model make use
of a defined set of community identities (community names). For
any SNMPv2c 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 February 1996 [Page 2]
"
Internet-Draft SNMPv2c Sept 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 SNMPv2c, the fundamental parameters of any
compliant access policy are defined in Section 3.2.5, "Definition
of Administrative Relationships", in RFC1157 [2]. 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 SNMPv2c 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, GetNext, GetBulk) 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 SNMPv2c Messages
The syntax of an SNMPv2c 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 SNMPv2c message is an ASN.1 value with the following syntax:
Expires February 1996 [Page 3]
"
Internet-Draft SNMPv2c Sept 1995
Message ::=
SEQUENCE {
version
| INTEGER {version2c (1)},
community -- as per RFC1157
OCTET STRING, -- 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 SNMPv2c 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 February 1996 [Page 4]
"
Internet-Draft SNMPv2c Sept 1995
3 Elements of Procedure
This section describes the procedures followed by an SNMPv2 entity
in processing SNMPv2c 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 [4] and [5] into a PDUs value.
3. An SNMPv2c 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 [4] and [5].
5. The serialized Message value is transmitted to the determined
transport address.
3.2 Processing a Received Communication
Note: Since SNMPv2c messages are authenticated based on a
communityName (the same as how SNMPv1 messages are authenticated),
we use the objects snmpV1BadCommunityNames and
snmpV1BadCommunityUses [6] as counters.
This section describes the procedure followed by an SNMPv2 entity
whenever it receives an SNMPv2c 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
conventions of [4] 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
Expires February 1996 [Page 5]
"
Internet-Draft SNMPv2c Sept 1995
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 SNMPv2c 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 [5].
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.
Expires February 1996 [Page 6]
"
Internet-Draft SNMPv2c Sept 1995
d. if the LCD information indicates the SNMPv2c 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 [5],
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 SNMPv2c 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 on page 6 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 [5].
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
Expires February 1996 [Page 7]
"
Internet-Draft SNMPv2c Sept 1995
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 7 above. If no such
correlated information is found, then the received
message is discarded without further processing.
2) a new SNMPv2c 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 SNMPv2c 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 SNMPv2c message,
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.
Expires February 1996 [Page 8]
"
Internet-Draft SNMPv2c Sept 1995
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 entity acting in a manager role may only generate
| a report-PDU in response to a Inform;
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 5), with these exceptions:
o The response is sent on behalf of the same community as the
request.
Expires February 1996 [Page 9]
"
Internet-Draft SNMPv2c Sept 1995
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 February 1996 [Page 10]
"
Internet-Draft SNMPv2c Sept 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 of (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] Marshall T. Rose and Keith McCloghrie, Structure and
Identification of Management Information for TCP/IP-based
internets, Performance Systems International, Hughes LAN
Systems, RFC 1155, May 1990.
[2] 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.
[3] Keith McCloghrie and Marshall T. Rose, Management Information
Base for Network Management of TCP/IP-based internets: MIB II,
Hughes LAN Systems, Performance Systems International, RFC
1213, March 1991.
[4] 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.
[5] 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.
Expires February 1996 [Page 11]
"
Internet-Draft SNMPv2c Sept 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.
Expires February 1996 [Page 12]
"
Internet-Draft SNMPv2c Sept 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
Phone: +1-301-258-9850
Fax: +1-301-921-0434
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 February 1996 [Page 13]
"
Internet-Draft SNMPv2c Sept 1995
8 Table of Contents
| 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
| 1.1 A Note on Terminology . . . . . . . . . . . . . . . . . . 1
2 Elements of the Model . . . . . . . . . . . . . . . . . . . . 2
2.1 SNMPv2c Community Identities . . . . . . . . . . . . . . . 2
2.2 Access Policy . . . . . . . . . . . . . . . . . . . . . . 3
2.3 SNMPv2c Messages . . . . . . . . . . . . . . . . . . . . . 3
2.4 Local Configuration Datastore (LCD) . . . . . . . . . . . 4
3 Elements of Procedure . . . . . . . . . . . . . . . . . . . . 5
3.1 Generating a Request or Notification . . . . . . . . . . . 5
3.2 Processing a Received Communication . . . . . . . . . . . 5
3.2.1 Additional Details . . . . . . . . . . . . . . . . . . . 9
3.2.1.1 ASN.1 Parsing Errors . . . . . . . . . . . . . . . 9
3.2.1.2 Generation of a Report-PDU . . . . . . . . . . . . 9
3.3 Generating a Response . . . . . . . . . . . . . . . . . . 9
4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 11
5 References . . . . . . . . . . . . . . . . . . . . . . . . 11
6 Security Considerations . . . . . . . . . . . . . . . . . . 13
7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13
Expires February 1996 [Page 14]
"
- SNMPv2c draft Bert Wijnen