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]