Draft Introduction to SMP Jul 92
Introduction to the
Simple Management Protocol (SMP) Framework
Sat Jul 4 17:76:01 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 draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material or to
cite them other than as a "working draft" or "work in
progress".
Expires January 4, 1993 [Page 1]
Draft Introduction to SMP Jul 92
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil,
nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au to learn the current status of any Internet
Draft.
Please send comments to the SNMP discussion group,
<snmp@psi.com>.
Expires January 4, 1993 [Page 2]
Draft Introduction to SMP Jul 92
2. Introduction
The Simple Management Protocol (SMP) is the next-generation in
the genus of a management framework originally derived from
the Simple Gateway Monitoring Protocol (SGMP) [1].
The current framework, the Internet-standard Network
Management Framework, consists of three components. They are:
RFC 1155 [2] which defines the Structure of Management
Information (SMI), the mechanisms used for describing and
naming objects for the purpose of management. RFC 1212 [3]
defines a more concise description mechanism, which is
wholly consistent with the SMI.
RFC 1213 [4] 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 [5] which defines the Simple Network Management
Protocol (SNMP), the protocol used for network access to
managed objects.
Just as the current framework is derived from the SGMP, so is
the SMP framework derived from the Internet-standard Network
Management Framework. The purpose of this document is to
provide an overview of the SMP framework. In contrast, the
SNMP/SMP coexistence document [6] discusses coexistence
between the two frameworks.
Expires January 4, 1993 [Page 3]
Draft Introduction to SMP Jul 92
3. Components of the SMP 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)
[7]. It is the purpose of the Structure of Management
Information for SMP document [8] 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) Trap definitions are used when describing extraordinary
events. An ASN.1 macro, TRAP-DEFINITION, is used to
concisely convey the syntax and semantics of a trap.
Expires January 4, 1993 [Page 4]
Draft Introduction to SMP Jul 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 SMP document [9] 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, SMP, 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 SMP document
[10] to define the operations of the protocol with respect to
the sending and receiving of the PDUs.
Expires January 4, 1993 [Page 5]
Draft Introduction to SMP Jul 92
3.4. Transport Mappings
The management protocol, SMP, may be used over a variety of
protocol suites. It is the purpose of the Transport Mappings
for SMP document [11] to define how the SMP 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 SMP
document [12] to define managed objects which describe the
behavior of a SMP entity. The Manager to Manager MIB for SMP
document [13] defines an initial set of managed objects which
describe the behavior of a SMP 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 SMP is based on the
SNMP Administrative Framework defined in [14], with these
modifications:
(1) For every occurrence of the term "SNMP", substitute the
term "SMP".
(2) For every occurrence of the term "Internet-standard
Network Management Framework", substitute the term "SMP
Framework".
(3) The mapping of SMP over UDP is termed "smpUDPdomain", as
defined in [11]. This replaces any use of
"rfc1351domain".
(4) Any ASN.1 objects IMPORTed from RFC 1157 are imported
from [10] instead.
Expires January 4, 1993 [Page 6]
Draft Introduction to SMP Jul 92
(5) SMP uses a modified Digest Authentication Protocol,
smpMD5AuthProtocol [8], which differs from the Digest
Authentication Protocol in [15] 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 [15] 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 [15] is omitted.
Steps 4 and 5 of Section 4.2 of [15] 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 [15] 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 January 4, 1993 [Page 7]
Draft Introduction to SMP Jul 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 [15] 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 [15] 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 [15] 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 [15] indicates that the receiving party must
reconstruct the SnmpAuthMsg generated by the sending
party. This reconstruction must exactly reproduce the BER
Expires January 4, 1993 [Page 8]
Draft Introduction to SMP Jul 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 SMP. 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 SMP, 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' [10] is
returned instead.
(9) Access control with instance-level granularity is
considered beyond the scope of a SMP entity acting in an
agent role. As such, no implementation of a SMP entity
acting in an agent role is required to support values of
viewSubtree [16] which have more sub-identifiers than is
necessary to identify a particular leaf object type.
However, access control is used in determining which SMP
entities acting in a manager role should receive trap
notifications (Section 6.4 of [8]). 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 [16] is
that the parties identified by the aclTarget and
aclSubject columns use identical authentication protocols
(partyAuthProtocol [16]).
(11) The aclPrivileges object [16] has a syntax of:
INTEGER (0..255)
Expires January 4, 1993 [Page 9]
Draft Introduction to SMP Jul 92
so that permissions for the three new PDUs defined in
[10] (GetBulkRequest-PDU, InformRequest-PDU, and SMP-
Trap-PDU) may be present in this object. Accordingly,
the values:
Get-Bulk: 32
Inform: 64
SMP-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, SMP-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, SMP-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, SMP-Trap)
Expires January 4, 1993 [Page 10]
Draft Introduction to SMP Jul 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 = { smpInOut } -- defined in [12]
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 = { smp }
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 = { smp }
viewStatus = { included }
viewMask = { ''h }
Expires January 4, 1993 [Page 11]
Draft Introduction to SMP Jul 92
4. Acknowledgements
The SMP 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 SMP framework will be able to successfully
build on this work.
Expires January 4, 1993 [Page 12]
Draft Introduction to SMP Jul 92
5. References
[1] J.R. Davin, J.D. Case, M.S. Fedor, M.L. Schoffstall, The
Simple Gateway Monitoring Protocol. Request for Comments
1028, (November, 1987).
[2] M.T. Rose and K. McCloghrie, Structure and Identification
of Management Information for TCP/IP-based internets.
Request for Comments 1155, (May, 1990).
[3] M.T. Rose and K. McCloghrie, Concise MIB Definitions.
Request for Comments 1212, (March, 1991).
[4] 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).
[5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
Simple Network Management Protocol. Request for Comments
1157, (May, 1990).
[6] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Coexistence between the Internet-standard Network
Management Framework and the Simple Management Protocol
(SMP) Framework, (July, 1992).
[7] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization. International Standard 8824, (December,
1987).
[8] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Structure of Management Information for the Simple
Management Protocol (SMP) Framework, (July, 1992).
[9] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Textual Conventions for the Simple Management Protocol
(SMP) Framework, (July, 1992).
[10] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Protocol Operations for the Simple Management Protocol
(SMP) Framework, (July, 1992).
Expires January 4, 1993 [Page 13]
Draft Introduction to SMP Jul 92
[11] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Transport Mappings for the Simple Management Protocol
(SMP) Framework, (July, 1992).
[12] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Management Information Base for the Simple Management
Protocol (SMP) Framework, (July, 1992).
[13] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
Manager to Manager Management Information Base for the
Simple Management Protocol (SMP) Framework, (July, 1992).
[14] J.R. Davin, J.M. Galvin, K. McCloghrie, SNMP
Administrative Model. Request for Comments 1351, (July,
1992).
[15] J.M. Galvin, K. McCloghrie, J.R. Davin, SNMP Security
Protocols. Request for Comments 1352, (July, 1992).
[16] K. McCloghrie, J.R. Davin, J.M. Galvin, Definitions of
Managed Objects for Administration of SNMP Parties.
Request for Comments 1353, (July, 1992).
Expires January 4, 1993 [Page 14]
Draft Introduction to SMP Jul 92
Appendix A: Rationale for Removal of Ordered Delivery
Mechanism
The Ordered Delivery Mechanism described in Section 7.3.5 of
[15] 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 SMP 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, SMP defines a new MIB object,
smpSetSerialNo [12], which provides the required
protection. Thus, not only is Ordered Delivery not
sufficient, it is now also unnecessary.
(3) The Digest Authentication Protocol in [15] specifies the
use of the Message Timeliness Mechanism described in
Section 7.3.6 of [15] 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 January 4, 1993 [Page 15]
Draft Introduction to SMP Jul 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 January 4, 1993 [Page 16]
Draft Introduction to SMP Jul 92
Appendix B: Rationale for Extending the Selective Clock
Acceleration Mechanism
The Selective Clock Acceleration Mechanism descrbed in Section
7.3.7 of [15] 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 [15], but also case 1. The clock
synchronization algorithm described in Section 6.3 of [15] 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 January 4, 1993 [Page 17]
Draft Introduction to SMP Jul 92
Table of Contents
1 Status of this Memo ................................... 1
2 Introduction .......................................... 3
3 Components of the SMP Framework ....................... 4
3.1 Structure of Management Information ................. 4
3.2 Textual Conventions ................................. 5
3.3 Protocol Operations ................................. 5
3.4 Transport Mappings .................................. 6
3.5 Protocol Instrumentation ............................ 6
3.6 Administrative Framework ............................ 6
4 Acknowledgements ...................................... 12
5 References ............................................ 13
A Rationale for Removal of Ordered Delivery Mechanism
.................................................... 15
B Rationale for Extending the Selective Clock Ac-
celeration Mechanism ............................... 17
Expires January 4, 1993 [Page 18]