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, . 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]