INTERNET-DRAFT July 1990 Experimental Definitions of Managed Objects for Administration of SNMP Communities Keith McCloghrie Hughes LAN Systems, Inc. James R. Davin MIT Laboratory for Computer Science James M. Galvin Trusted Information Systems, Inc. July 3, 1990 1 Status of this Memo This draft document will be submitted to the RFC editor as an experimental extension to the SNMP MIB. Distribution of this memo is unlimited. Please send comments to the authors: Keith McCloghrie , James R. Davin , and James M. Galvin . 2 Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes a representation of the authentication communities defined in [5] as objects in the Internet Common MIB [8]. These definitions are consistent with the administrative strategies set forth in [4]. McCloghrie, Davin, Galvin [Page 1] INTERNET-DRAFT July 1990 3 Historical Perspective As reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [2], a two-prong strategy for network management of TCP/IP- based internets was undertaken. In the short-term, the Simple Network Management Protocol (SNMP) [1] was to be used to manage nodes in the Internet community. In the long- term, the use of the OSI network management framework was to be examined. Two documents were produced to define the management information: RFC 1065, which defined the Structure of Management Information (SMI) [9], and RFC 1066, which defined the Management Information Base (MIB) [8]. Both of these documents were designed so as to be compatible with both the SNMP and the OSI network management framework. This strategy was quite successful in the short-term: Internet- based network management technology was fielded, by both the research and commercial communities, within a few months. As a result of this, portions of the Internet became network manageable in a timely fashion, and each of the SMI, the MIB, and the SNMP became Internet (draft) standards. Later, as reported in RFC 1109, Report of the Second Ad Hoc Network Management Review Group [3], the requirements of the SNMP and the OSI network management frameworks were found to be more different than anticipated. As such, the requirement for compatibility between the SMI/MIB and both frameworks was suspended. This action permitted the operational network management framework, the SNMP, to respond to new operational needs in the Internet by producing a new document, termed MIB-II. Consistent with the IAB directive to produce simple, workable systems in the short-term, the list of managed objects defined in the Internet-standard MIB was derived by taking only those elements which are considered essential. However, the SMI defined three extensibility mechanisms: one, the addition of new standard objects through the definitions of new versions McCloghrie, Davin, Galvin [Page 2] INTERNET-DRAFT July 1990 of the MIB; two, the addition of widely-available but non- standard objects through the experimental subtree; and three, the addition of private objects through the enterprises subtree. Such additional objects can not only be used for vendor-specific elements, but also for experimentation as required to further the knowledge of which other objects are essential. This memo defines extensions to the MIB using the second method. It contains definitions of managed objects used for experimentation. After experimentation, if sufficient consensus is reached in the Internet community, then a subsequent revision of this memo may be placed in the Internet-standard MIB. 4 Objects Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using Abstract Syntax Notation One (ASN.1) [6]. The mechanisms used for describing these objects are specified in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. The SMI specifies the use of the basic encoding rules McCloghrie, Davin, Galvin [Page 3] INTERNET-DRAFT July 1990 of ASN.1 [7], subject to the additional requirements imposed by the SNMP. 4.1 Format of Definitions The next section contains the specification of all object types contained in this extension to the MIB. Following the conventions of the SMI, the object types are defined using the following fields: o OBJECT: A textual name, termed the OBJECT DESCRIP- TOR, for the object type, along with its corresponding OBJECT IDENTIFIER. o Syntax: The abstract syntax for the object type, presented using ASN.1. This must resolve to an instance of the ASN.1 type ObjectSyntax defined in the SMI. o Definition: A textual description of the semantics of the object type. Implementations should ensure that their interpretation of the object type fulfills this definition since this MIB is intended for use in multi-vendor environments. As such it is vital that object types have consistent meaning across all machines. o Access: A keyword, one of read-only, read-write, write-only, or not-accessible. Note that protocol-specific "views" (e.g., those implied by an SNMP community) may make further restrictions on access to a variable. o Status: A keyword, one of mandatory, optional, obsolete, or deprecated. Use of deprecated implies mandatory status. McCloghrie, Davin, Galvin [Page 4] INTERNET-DRAFT July 1990 5 Object Definitions RFCxxxx-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, OBJECT-TYPE, TimeTicks FROM RFC1155-SMI; ap OBJECT IDENTIFIER ::= { experimental 12 } END 5.1 apTable Object OBJECT: apTable { ap 1 } Syntax: SEQUENCE OF ApEntry Definition: A particular SNMP authentication service. Access: not-accessible. Status: mandatory. 5.2 apEntry Object OBJECT: apEntry { apTable 1 } McCloghrie, Davin, Galvin [Page 5] INTERNET-DRAFT July 1990 Syntax: ApEntry ::= SEQUENCE { apName OCTET STRING, apAlgorithm OBJECT IDENTIFIER, apPrivate OCTET STRING, apPublic OCTET STRING, apClock TimeTicks, apInterval INTEGER, apAdmin OCTET STRING, apAdminTime TimeTicks } Definition: A particular SNMP authentication community. Access: not-accessible. Status: mandatory. 5.3 apName Object OBJECT: apName { apEntry 1 } McCloghrie, Davin, Galvin [Page 6] INTERNET-DRAFT July 1990 Syntax: OCTET STRING Definition: A name that uniquely identifies a particular authen- tication community among all others supported by a particular authentication service. Access: read-only. Status: mandatory. 5.4 apAlgorithm Object OBJECT: apAlgorithm { apEntry 2 } Syntax: OBJECT IDENTIFIER Definition: The authentication algorithm for a particular authentication community. Access: read-only. Status: mandatory. McCloghrie, Davin, Galvin [Page 7] INTERNET-DRAFT July 1990 5.5 apPrivate Object OBJECT: apPrivate { apEntry 3 } Syntax: OCTET STRING Definition: The private key for a particular authentication community. Access: write-only. Status: mandatory. 5.6 apPublic Object OBJECT: apPublic { apEntry 4 } Syntax: OCTET STRING Definition: The public key for a particular authentication community. Access: read-write. Status: mandatory. McCloghrie, Davin, Galvin [Page 8] INTERNET-DRAFT July 1990 5.7 apClock Object OBJECT: apClock { apEntry 5 } Syntax: TimeTicks Definition: The clock for a particular authentication commu- nity. Access: read-write. Status: mandatory. 5.8 apInterval Object OBJECT: apInterval { apEntry 6 } Syntax: INTEGER Definition: The allowed interval for a particular authentication community. Access: read-write. Status: mandatory. McCloghrie, Davin, Galvin [Page 9] INTERNET-DRAFT July 1990 5.9 apAdmin Object OBJECT: apAdmin { apEntry 7 } Syntax: OCTET STRING Definition: The administrative key for a particular authentica- tion community. Access: write-only. Status: mandatory. 5.10 apAdminTime Object OBJECT: apAdminTime { apEntry 8 } Syntax: TimeTicks Definition: The administrative clock for a particular authenti- cation community. Access: McCloghrie, Davin, Galvin [Page 10] INTERNET-DRAFT July 1990 read-write. Status: mandatory. McCloghrie, Davin, Galvin [Page 11] INTERNET-DRAFT July 1990 6 Definitions RFCxxxx-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, OBJECT-TYPE, TimeTicks FROM RFC1155-SMI; ap OBJECT IDENTIFIER ::= { experimental 12 } apTable OBJECT-TYPE SYNTAX SEQUENCE OF ApEntry ACCESS not-accessible STATUS mandatory ::= { ap 1 } apEntry OBJECT-TYPE SYNTAX ApEntry ACCESS not-accessible STATUS mandatory -- INDEX { apName } ::= { apTable 1 } ApEntry ::= SEQUENCE { apName OCTET STRING, apAlgorithm OBJECT IDENTIFIER, apPrivate OCTET STRING, apPublic OCTET STRING, apClock TimeTicks, apInterval INTEGER, apAdmin OCTET STRING, McCloghrie, Davin, Galvin [Page 12] INTERNET-DRAFT July 1990 apAdminTime TimeTicks } apName OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory ::= { apEntry 1 } apAlgorithm OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory ::= { apEntry 2 } -- definitions of Authentication Algorithms apAlgorithms OBJECT IDENTIFIER ::= { ap 2 } -- Trivial Authentication Algorithm apTrivialAuthAlg OBJECT IDENTIFIER ::= { apAlgorithms 1 } -- SNMP Authentication Algorithm apMD4AuthAlg OBJECT IDENTIFIER ::= { apAlgorithms 2 } -- SNMP Authentication and Privacy Algorithm apMD4PrivAlg OBJECT IDENTIFIER ::= { apAlgorithms 3 } apPrivate OBJECT-TYPE SYNTAX OCTET STRING ACCESS write-only STATUS mandatory ::= { apEntry 3 } McCloghrie, Davin, Galvin [Page 13] INTERNET-DRAFT July 1990 apPublic OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory ::= { apEntry 4 } apClock OBJECT-TYPE SYNTAX TimeTicks ACCESS read-write STATUS mandatory ::= { apEntry 5 } apInterval OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory ::= { apEntry 6 } apAdmin OBJECT-TYPE SYNTAX OCTET STRING ACCESS write-only STATUS mandatory ::= { apEntry 7 } apAdminTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-write STATUS mandatory ::= { apEntry 8 } END McCloghrie, Davin, Galvin [Page 14] INTERNET-DRAFT July 1990 7 Identification of OBJECT instances for use with the SNMP The names for all object types in the MIB are defined explicitly either in the Internet-standard MIB or in other documents which conform to the naming conventions of the SMI. The SMI requires that conformant management protocols define mechanisms for identifying individual instances of those object types for a particular network element. Each instance of any object type defined in the MIB is identified in SNMP operations by a unique name called its "variable name." In general, the name of an SNMP variable is an OBJECT IDENTIFIER of the form x.y, where x is the name of a non-aggregate object type defined in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way specific to the named object type, identifies the desired instance. This naming strategy admits the fullest exploitation of the semantics of the powerful SNMP get-next operator, because it assigns names for related variables so as to be contiguous in the lexicographical ordering of all variable names known in the MIB. The type-specific naming of object instances is defined below for a number of classes of object types. Instances of an object type defined in this memo to which none of the following naming conventions are applicable are named by OBJECT IDENTIFIERs of the form x.0, where x is the name of said object type in the MIB definition. For example, suppose one wanted to identify an instance of the variable sysDescr in the Internet-standard MIB. The object class for sysDescr is: iso org dod internet mgmt mib system sysDescr 1 3 6 1 2 2 1 1 Hence, the object type, x, would be 1.3.6.1.2.2.1.1 to which is appended an instance sub-identifier of 0. That is, 1.3.6.1.2.2.1.1.0 identifies the one and only instance of sysDescr. McCloghrie, Davin, Galvin [Page 15] INTERNET-DRAFT July 1990 7.1 apTable Object Type Names The name of a community entry, e, is the OBJECT IDENTIFIER fragment of the form k.a1.a2 ... ak, where the ai are decimal representations of successive octets of the value of that instance of the apName object type associated with e. For each object type, t, for which the defined name, n, has a prefix of apEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.s, where s is the name of the community entry about which i represents information. For example, suppose one wanted to identify that instance of the apAlgorithm object type associated with the community entry whose name is 6.112.117.98.108.105.99 -- that is, the community entry associated with an apName value of "public" (in ASCII). Then, apAlgorithm.6.112.117.98.108.105.99 would identify the desired instance. McCloghrie, Davin, Galvin [Page 16] INTERNET-DRAFT July 1990 References [1] Jeffrey D. Case, Mark S. Fedor, Martin L. Schoffstall, and James R. Davin. A Simple Network Management Protocol. Request for Comments 1098, DDN Network Information Center, SRI International, April 1989. [2] Vinton G. Cerf. IAB Recommendations for the Development of Internet Network Management Standards. Request for Comments 1052, DDN Network Information Center, SRI International, April 1988. [3] Vinton G. Cerf. Report of the Second Ad Hoc Network Management Review Group. Request for Comments 1109, DDN Network Information Center, SRI International, August 1989. [4] James R. Davin, James M. Galvin, and Keith McCloghrie. Administration of SNMP Communities. Internet Draft, DDN Network Information Center, SRI International, June 1990. [5] James M. Galvin, Keith McCloghrie, and James R. Davin. Authentication and Privacy in the SNMP. Internet Draft, DDN Network Information Center, SRI International, June 1990. [6] Information Processing -- Open Systems Interconnection -- Specification of Abstract Syntax Notation One (ASN.1). In- ternational Organization for Standardization/International Electrotechnical Institute, 1987. International Standard 8824. [7] Information Processing -- Open Systems Interconnection -- Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). International Organization for Standardization/International Electrotechnical Institute, 1987. International Standard 8825. [8] Keith McCloghrie and Marshall T. Rose. Management Information Base Network Management of TCP/IP based McCloghrie, Davin, Galvin [Page 17] INTERNET-DRAFT July 1990 internets. Request for Comments 1066, DDN Network Information Center, SRI International, August 1988. [9] Marshall T. Rose and Keith McCloghrie. Structure and Identification of Management Information for TCP/IP based internets. Request for Comments 1065, DDN Network Information Center, SRI International, August 1988. McCloghrie, Davin, Galvin [Page 18] INTERNET-DRAFT July 1990 Contents 1 Status of this Memo 1 2 Abstract 1 3 Historical Perspective 2 4 Objects 3 4.1 Format of Definitions 4 5 Object Definitions 5 5.1 apTable Object 5 5.2 apEntry Object 5 5.3 apName Object 6 5.4 apAlgorithm Object 7 5.5 apPrivate Object 8 5.6 apPublic Object 8 5.7 apClock Object 9 5.8 apInterval Object 9 5.9 apAdmin Object 10 5.10 apAdminTime Object 10 6 Definitions 12 7 Identification of OBJECT instances for use with the SNMP 15 7.1 apTable Object Type Names 16 McCloghrie, Davin, Galvin [Page 19] ------- End of Forwarded Message