Draft Introduction to SNMPv2 Oct 92
Introduction to version 2 of the
Network Management Framework
Thu Nov 12 08:51:15 1992 |
Jeffrey D. Case
SNMP Research, Inc.
University of Tennessee, Knoxville
case@cs.utk.edu
Keith McCloghrie
Hughes LAN Systems
kzm@hls.com
Marshall T. Rose
Dover Beach Consulting, Inc.
mrose@dbc.mtview.ca.us
Steven L. Waldbusser
Carnegie Mellon University
waldbusser@andrew.cmu.edu
1. 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 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 a "work in progress".
Expires May 12, 1993 [Page 1]
Draft Introduction to SNMPv2 Oct 92
2. Introduction
The purpose of this document is to provide an overview of |
version 2 of |
the Internet-standard Network Management Framework, termed the |
SNMP version 2 framework (SNMPv2). This framework is derived |
from the original Internet-standard Network Management |
Framework (SNMPv1): |
RFC 1155 [1] which defines the Structure of Management |
Information (SMI), |
the mechanisms used for describing and naming objects for
the purpose of management. RFC 1212 [2] defines a more |
concise description mechanism, |
which is wholly consistent with the SMI.
RFC 1213 [3] which defines the TCP/IP Management |
Information Base 2 (MIB-II), |
the core set of managed objects for the Internet suite of
protocols.
RFC 1157 [4] which defines the Simple Network Management |
Protocol (SNMP), |
the protocol used for network access to managed objects.
For information on coexistence between SNMPv1 and SNMPv2, |
consult [5]. |
Expires May 12, 1993 [Page 2]
Draft Introduction to SNMPv2 Oct 92
3. Components of the SNMPv2 Framework
A network management system contains: several (potentially
many) nodes, each with a processing entity, termed an agent,
which has access to management instrumentation; at least one
management station; and, a management protocol, used to convey
management information between the agents and management
stations. Operations of the protocol are carried out under an
administrative framework which defines both authentication and
authorization policies.
Network management stations execute management applications
which monitor and control network elements. Network elements
are devices such as hosts, routers, terminal servers, etc.,
which are monitored and controlled through access to their
management information.
3.1. Structure of Management Information
Management information is viewed as a collection of managed
objects, residing in a virtual information store, termed the
Management Information Base (MIB). Collections of related
objects are defined in MIB modules. These modules are written
using a subset of OSI's Abstract Syntax Notation One (ASN.1)
[6]. It is the purpose of the Structure of Management
Information for SNMPv2 document [7] to define that subset.
The SMI is divided into four parts: object definitions, trap
definitions, compliance definitions, and capabilities
definitions.
(1) Object definitions are used when describing managed
objects. An ASN.1 macro, OBJECT-TYPE, is used to
concisely convey the syntax and semantics of a managed
object. Collections of related objects are grouped
together to form a unit of conformance. An ASN.1 macro,
OBJECT-GROUP, is used to concisely convey the syntax and
semantics of a group.
(2) Notification definitions are used when describing an |
unsolicited transmission of management information. |
An ASN.1 macro, NOTIFICATION-TYPE, is used to concisely |
convey the syntax and semantics of a notification. |
Expires May 12, 1993 [Page 3]
Draft Introduction to SNMPv2 Oct 92
(3) Compliance definitions are used when describing
requirements for management agents with respect to object
definitions. An ASN.1 macro, MODULE-COMPLIANCE, is used
to concisely convey such requirements.
(4) Capability definitions are used when describing the
capabilities of agents with respect to object
definitions. An ASN.1 macro, AGENT-CAPABILITIES, is used
to concisely convey such capabilities.
3.2. Textual Conventions
When designing a MIB module, it is often useful to define
types, with a different name, but the same syntax, as one of
the types defined in the SMI. These are termed textual
conventions, and are used for the convenience of humans
reading the MIB module. It is the purpose of the Textual
Conventions for SNMPv2 document [8] to define the initial set
of textual conventions available to all MIB modules.
Objects defined using a textual convention are always encoded
by means of the rules that define their primitive type.
However, textual conventions often have special semantics
associated with them. As such, an ASN.1 macro, TEXTUAL-
CONVENTION, is used to concisely convey the syntax and
semantics of a textual convention.
3.3. Protocol Operations
The management protocol provides for the exchange of messages
which convey management information between the agents and the
management stations. The form of these messages is a message
"wrapper" which encapsulates a Protocol Data Unit (PDU). The
form and meaning of the "wrapper" is determined by an
administrative framework which defines both authentication and
authorization policies.
It is the purpose of the Protocol Operations for SNMPv2
document [9] to define the operations of the protocol with
respect to the sending and receiving of the PDUs.
Expires May 12, 1993 [Page 4]
Draft Introduction to SNMPv2 Oct 92
3.4. Transport Mappings
The management protocol, version 2 of the Simple Network
Management Protocol, may be used over a variety of protocol
suites. It is the purpose of the Transport Mappings for
SNMPv2 document [10] to define how the SNMPv2 maps onto an
initial set of transport domains. Other mappings may be
defined in the future.
Although several mappings are defined, the mapping onto UDP is
the preferred mapping. As such, to provide for the greatest
level of interoperability, systems which choose to deploy
other mappings should also provide for proxy service to the
UDP mapping.
3.5. Protocol Instrumentation
It is the purpose of the Management Information Base for
SNMPv2 document [11] to define managed objects which describe
the behavior of a SNMPv2 entity. The Manager to Manager MIB
document [12] defines an initial set of managed objects which
describe the behavior of a SNMPv2 entity which acts in a
manager role. It is expected that extensions to this MIB will
be defined in the future.
3.6. Administrative Framework
The administrative framework used by the SNMPv2 is based on
the SNMP Administrative Framework defined in [13], with these
modifications:
(1) For every occurrence of the term "SNMP", substitute the
term "SNMPv2".
(2) For every occurrence of the term "Internet-standard
Network Management Framework", substitute the term
"SNMPv2 Framework".
(3) The mapping of SNMPv2 over UDP is termed "snmpUDPDomain",
as defined in [10]. This replaces any use of
"rfc1351domain".
Expires May 12, 1993 [Page 5]
Draft Introduction to SNMPv2 Oct 92
(4) Any ASN.1 objects IMPORTed from RFC 1157 are imported
from [9] instead.
(5) SNMPv2 uses a modified Digest Authentication Protocol,
smpMD5AuthProtocol [7], which differs from the Digest
Authentication Protocol in [14] in two ways: there is no
ordered delivery mechanism, and, the clock
synchronization algorithm is simplified.
The initial configuration assigned, by convention, to the
initialPartyIds uses smpMD5AuthProtocol as the value of
partyAuthProtocol for parties 3, 4, 5, and 6.
The Ordered Delivery Mechanism described in Section 7.3.5
of [14] is not used in the modified Digest Authentication
Protocol.
As a result:
All references to `nonce' and `last-timestamp' are
deleted.
Step 3 of Section 4.1 of [14] is omitted.
Steps 4 and 5 of Section 4.2 of [14] are omitted.
The AuthInformation data type is modified, as
described below.
Appendix A explains the rationale for the removal of
ordered delivery.
In order to simplify clock synchronization, the Selective
Clock Acceleration Mechanism described in Section 7.3.7
of [14] is extended to apply to the authentication clocks
of both the source and destination parties of a message.
To facilitate this, the sender's notion of both the
source party's clock and the destination party's clock
are included as authentication information in a message
when using the modified Digest Authentication Protocol.
As a result:
For every occurrence of the term "authTimeStamp",
substitute the term "authSrcTimeStamp".
Expires May 12, 1993 [Page 6]
Draft Introduction to SNMPv2 Oct 92
The AuthInformation data type is modified to be:
AuthInformation ::=
CHOICE {
[2]
IMPLICIT SEQUENCE {
authDigest
OCTET STRING,
authDstTimestamp
INTEGER (0..2147483647),
authSrcTimestamp
INTEGER (0..2147483647)
},
OCTET STRING
}
Step 2 of Section 4.1 of [14] is modified to set
authSrcTimestamp to the authentication clock value
of the message's source party, and to retrieve the
value of the authentication clock for the
destination party from the local database and set
authDstTimestamp to this retrieved value.
Step 11 of Section 4.2 of [14] is modified to update
the local database's values of whichever one or both
of the authentication clocks for the source and
destination parties is less than the values of
authSrcTimestamp and authDstTimestamp, respectively.
The Clock Synchronization algorithm described in
Section 6.3 of [14] is modified to omit both the
retrieval of the agent's notion of the
authentication clock of the party executing at the
agent, and the checking for and rectification of
case 1 (i.e., the issuing of a set operation to
advance the agent's notion of that clock.)
Appendix B explains the rationale for this approach to
clock synchronization.
(6) In order to calculate the digest, Step 7 in Section 4.2
of [14] indicates that the receiving party must
reconstruct the SnmpAuthMsg generated by the sending
party. This reconstruction must exactly reproduce the BER
Expires May 12, 1993 [Page 7]
Draft Introduction to SNMPv2 Oct 92
encoding generated by the sending party. In particular,
although BER encodings are unambiguous, they are not
unique, because a length field may use more than the
minimum number of octets necessary. (Note that
regenerating the BER encoding is trivial; once the
privData field of the SnmpPrivMsg has been deciphered,
the privData field contains the original BER encoding
used by the sending party.)
(7) The use of a privacy protocol (e.g., the Symmetric
Privacy Protocol which is specified to use DES) is
required only for the distribution of party secrets when
creating new parties via the SNMPv2. That is, the use of
DES is not required for the maintenance of existing
party, in particular for the changing of party secrets;
but, in order to create a new party using SNMPv2, a
privacy protocol, which offers protection from non-
disclosure, must be used by both the source and
destination parties.
(8) Instead of returning a `readOnly' error on an
authorization failure, an `authorizationError' [9] is
returned instead.
(9) Access control with instance-level granularity is
considered beyond the scope of a SNMPv2 entity acting in
an agent role. As such, no implementation of a SNMPv2
entity acting in an agent role is required to support
values of viewSubtree [15] which have more sub-
identifiers than is necessary to identify a particular
leaf object type. However, access control is used in
determining which SNMPv2 entities acting in a manager
role should receive trap notifications (Section 8.5 of
[9]). As such, agent implementors might wish to provide
instance-level granularity in order to allow a management
station to use fine-grain configuration of trap
notifications.
(10) A restriction on any valid entry in the aclTable [15] is
that the parties identified by the aclTarget and
aclSubject columns use identical authentication protocols
(partyAuthProtocol [15]).
(11) The aclPrivileges object [15] has a syntax of:
Expires May 12, 1993 [Page 8]
Draft Introduction to SNMPv2 Oct 92
INTEGER (0..255)
so that permissions for the three new PDUs defined in [9]
(GetBulkRequest-PDU, InformRequest-PDU, and SNMPv2-Trap-
PDU) may be present in this object. Accordingly, the
values:
Get-Bulk: 32
Inform: 64
SNMPv2-Trap: 128
are used. Further, the value of the DEFVAL clause for
this object is now 35 (Get, Get-Next, & Get-Bulk).
(12) The access control parameters assigned, by convention, to
the initialPartyIds are:
aclTarget = { initialPartyId a b c d 1 }
aclSubject = { initialPartyId a b c d 2 }
aclPrivileges = 35 (Get, Get-Next & Get-Bulk)
aclTarget = { initialPartyId a b c d 2 }
aclSubject = { initialPartyId a b c d 1 }
aclPrivileges = 132 (Response, SNMPv2-Trap)
aclTarget = { initialPartyId a b c d 3 }
aclSubject = { initialPartyId a b c d 4 }
aclPrivileges = 43 (Get, Get-Next, Set & Get-Bulk)
aclTarget = { initialPartyId a b c d 4 }
aclSubject = { initialPartyId a b c d 3 }
aclPrivileges = 132 (Response, SNMPv2-Trap)
aclTarget = { initialPartyId a b c d 5 }
aclSubject = { initialPartyId a b c d 6 }
aclPrivileges = 43 (Get, Get-Next, Set & Get-Bulk)
aclTarget = { initialPartyId a b c d 6 }
aclSubject = { initialPartyId a b c d 5 }
aclPrivileges = 132 (Response, SNMPv2-Trap)
Expires May 12, 1993 [Page 9]
Draft Introduction to SNMPv2 Oct 92
(13) The initial MIB views assigned, by convention, to the
initialPartyIds are:
viewParty = { initialPartyId a b c d 1 }
viewSubtree = { system }
viewStatus = { included }
viewMask = { ''h }
viewParty = { initialPartyId a b c d 1 }
viewSubtree = { snmp }
viewStatus = { included }
viewMask = { ''h }
viewParty = { initialPartyId a b c d 1 }
viewSubtree = { snmpParties }
viewStatus = { included }
viewMask = { ''h }
viewParty = { initialPartyId a b c d 1 }
viewSubtree = { snmpStats } -- defined in [11]
viewStatus = { included }
viewMask = { ''h }
viewParty = { initialPartyId a b c d 3 }
viewSubtree = { internet }
viewStatus = { included }
viewMask = { ''h }
viewParty = { initialPartyId a b c d 3 }
viewSubtree = { snmpv2 }
viewStatus = { included }
viewMask = { ''h }
viewParty = { initialPartyId a b c d 5 }
viewSubtree = { internet }
viewStatus = { included }
viewMask = { ''h }
viewParty = { initialPartyId a b c d 5 }
viewSubtree = { snmpv2 }
viewStatus = { included }
viewMask = { ''h }
Expires May 12, 1993 [Page 10]
Draft Introduction to SNMPv2 Oct 92
4. Acknowledgements
The SNMPv2 framework is based on the outstanding technical
direction pioneered by the original authors of the SGMP: James
R. (Chuck) Davin, of the MIT Laboratory for Computer Science,
Mark S. Fedor, of Performance Systems International, Inc.,
Martin L. Schoffstall, also of PSI, and Jeffrey D. Case.
Since the invention of the SGMP in 1987, many individuals have
devoted much energy toward creating the unprecedented success
of the Internet-standard Network Management Framework. As
such, the list of people worthy of acknowledgement is too
great to enumerate here.
However, in retrospect, it seems clear that the concepts in
the original architecture, as envisioned by Chuck Davin, have
provided the basis for the success of the current framework.
We hope that the SNMPv2 framework will be able to successfully
build on this work.
Finally, the comments of the SNMP Version 2 working group are
gratefully acknowledged:
Steve Alexander, Interactive Systems
Uri Blumenthal, International Business Machines
Jeffrey D. Case, SNMP Research, Inc.
Tracy Cox, Bellcore
James R. (Chuck) Davin, Bellcore
Mike Davison, FiberCom
Taso N. Devetzis, Bellcore
Gary W. Haney, Martin Marietta Energy Systems
Matt Hecht, SNMP Research, Inc.
Susan E. Hicks, Martin Marietta Energy Systems
Satish Joshi, SynOptics
Mark Kepke, Hewlett-Packard
Ken Key, SNMP Research, Inc.
Michael Kornegay, Visisoft
Deidre C. Kostick, Bellcore
Cheryl Krupczak, Georgia Tech
Robert C. Lushbaugh, Martin Marietta Energy Systems
Keith McCloghrie, Hughes LAN Systems
Dave Minnich, FiberCom
Dave Perkins, SynOptics
Marshall T. Rose, Dover Beach Consulting, Inc.
Shawn A. Routhier, Epilogue Technology
Expires May 12, 1993 [Page 11]
Draft Introduction to SNMPv2 Oct 92
Jon Saperia, Digital Equipment Corporation
Bob Stewart, Xyplex (chair)
Robert Synder, Cisco Systems
Maurice Turcotte, Racal Datacom
Steven L. Waldbusser, Carnegie Mellon University
Bert Wijnen, International Business Machines
Peter Wilson, 3Com
Steven Wong, Digital Equipment Corporation
Chris Young, Cabletron
Kiho Yum, 3Com
Expires May 12, 1993 [Page 12]
Draft Introduction to SNMPv2 Oct 92
5. References
[1] M.T. Rose and K. McCloghrie, Structure and Identification
of Management Information for TCP/IP-based internets.
Request for Comments 1155, (May, 1990).
[2] M.T. Rose and K. McCloghrie, Concise MIB Definitions.
Request for Comments 1212, (March, 1991).
[3] K. McCloghrie and M.T. Rose, Management Information Base
for Network Management of TCP/IP-based internets: MIB-II.
Request for Comments 1213, (March, 1991).
[4] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
Simple Network Management Protocol. Request for Comments
1157, (May, 1990).
[5] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Coexistence between version 1 and version 2 of the
Internet-standard Network Management Framework,
Internet-Draft, (October 7, 1992).
[6] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization. International Standard 8824, (December,
1987).
[7] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Structure of Management Information for version 2 of the
Simple Network Management Protocol, Internet-Draft,
(October 7, 1992).
[8] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Textual Conventions for version 2 of the the Simple
Network Management Protocol (SNMPv2), Internet-Draft,
(October 7, 1992).
[9] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Protocol Operations for version 2 of the Simple Network
Management Protocol (SNMPv2), Internet-Draft, (October 7,
1992).
[10] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Transport Mappings for version 2 of the Simple Network
Expires May 12, 1993 [Page 13]
Draft Introduction to SNMPv2 Oct 92
Management Protocol (SNMPv2), Internet-Draft, (October 7,
1992).
[11] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Management Information Base for version 2 of the Simple
Network Management Protocol, Internet-Draft, (October 7,
1992).
[12] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Manager to Manager Management Information Base,
Internet-Draft, (October 7, 1992).
[13] J.R. Davin, J.M. Galvin, K. McCloghrie, SNMP
Administrative Model. Request for Comments 1351, (July,
1992).
[14] J.M. Galvin, K. McCloghrie, J.R. Davin, SNMP Security
Protocols. Request for Comments 1352, (July, 1992). +
[15] K. McCloghrie, J.R. Davin, J.M. Galvin, SNMP Security +
Protocols. Request for Comments 1353, +
(July, 1992).
Expires May 12, 1993 [Page 14]
Draft Introduction to SNMPv2 Oct 92
Appendix A: Rationale for Removal of Ordered Delivery
Mechanism
The Ordered Delivery Mechanism described in Section 7.3.5 of
[14] is used by the Digest Authentication Protocol. This
mechanism causes messages which are delivered out of order to
be declared unauthentic. This is unnecessary, detrimental to
the efficiency of network management, and overlaps with other
mechanisms used by the Digest Authentication Protocol. In
particular:
(1) There is no security requirement to protect against
malicious re-ordering of network management retrieval
operations, especially since such re-ordering can and
does happen through normal, non-malicious, operation of a
network. Thus, the use of the Ordered Delivery mechanism
can cause genuine authentic messages to be declared
unauthentic due to the normal operation of a network.
Even worse, this behavior is likely to happen more
frequently under conditions of network stress, at which
times network management needs to perform at its best.
Thus, use of the Ordered Delivery mechanism is
detrimental to efficiency of network management.
(2) There is a security requirement to protect against
malicious re-ordering of network management set
operations. However, this requirement is not just
protection for those issued by one network manager, but
is in fact across set operations issued on behalf of all
network managers (i.e., across set operations directed to
all SNMPv2 parties.) The Ordered Delivery mechanism
operates only within parties, not across parties, and
therefore, is not sufficient to provide the required
protection. To address this issue, SNMPv2 defines a new
MIB object, snmpSetSerialNo [11], which provides the
required protection. Thus, not only is Ordered Delivery
not sufficient, it is now also unnecessary.
(3) The Digest Authentication Protocol in [14] specifies the
use of the Message Timeliness Mechanism described in
Section 7.3.6 of [14] as well as the Ordered Delivery
mechanism. There was overlap in the functionality of
these two mechanisms. With use of the Ordered Delivery
mechanism removed, this overlap is removed. The Message
Timeliness Mechanism is retained to provide protection
Expires May 12, 1993 [Page 15]
Draft Introduction to SNMPv2 Oct 92
against malicious replay of a (retrieval) operation
outside of the designated period (i.e., the lifetime)
during which replay and/or out-of-order delivery can
occur non-maliciously due to the normal operation of the
network.
Expires May 12, 1993 [Page 16]
Draft Introduction to SNMPv2 Oct 92
Appendix B: Rationale for Extending the Selective Clock
Acceleration Mechanism
The Selective Clock Acceleration Mechanism described in
Section 7.3.7 of [14] is used by the Digest Authentication
Protocol. This mechanism causes the receiver's notion of the
authentication clock of a message's source party to be
advanced, if necessary, to match that party's timestamp value
in a received message. By extending this mechanism to apply
also to a message's destination party, the regular operation
of this mechanism corrects not only cases 2 and 3 as described
in Section 6.3 of [14], but also case 1. The clock
synchronization algorithm described in Section 6.3 of [14] is
thereby simplified.
Note that while this extension requires the AuthInformation
data type to be modified, a modification to this data type is
already required by the removal of the Ordered Delivery
mechanism as described earlier in Appendix A.
Expires May 12, 1993 [Page 17]
Draft Introduction to SNMPv2 Oct 92
Table of Contents
1 Status of this Memo ................................... 1
2 Introduction .......................................... 2
3 Components of the SNMPv2 Framework .................... 3
3.1 Structure of Management Information ................. 3
3.2 Textual Conventions ................................. 4
3.3 Protocol Operations ................................. 4
3.4 Transport Mappings .................................. 5
3.5 Protocol Instrumentation ............................ 5
3.6 Administrative Framework ............................ 5
4 Acknowledgements ...................................... 11
5 References ............................................ 13
A Rationale for Removal of Ordered Delivery Mechanism
.................................................... 15
B Rationale for Extending the Selective Clock Ac-
celeration Mechanism ............................... 17
Expires May 12, 1993 [Page 18]
