Internet Draft An Architecture for Describing Internet Management Frameworks 17 June 1997 D. Harrington Cabletron Systems, Inc. dbh@cabletron.com B. Wijnen IBM T.J. Watson Research wijnen@vnet.ibm.com <draft-ietf-snmpv3-next-gen-arch-02.txt> 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 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 ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document describes an architecture for describing Internet Management Frameworks. The architecture is designed to be modular to allow the evolution of the protocol over time. The major portions of the architecture are a messaging engine containing a message processing and control subsystem and a security subsystem, plus a data processing engine, called a context engine, which contains an access control subsystem, a MIB access subsystem, and possibly multiple orangelets which provide specific functional processing of network management data. Harrington/Wijnen Expires December 1977 [Page 1] Draft Architecture for Describing Internet Management Frameworks March 1997 Harrington/Wijnen Expires December 1977 [Page 2] Draft Architecture for Describing Internet Management Frameworks March 1997 0. Issues 0.1. Issues to be resolved . Need the "readable" introduction supplement . taxonomy: orangelets . should the scopedPDU be contained in the securityParameters SEQUENCE, so encryption can include the PDU and some of the security parameters? . Who counts SNMP messages? who counts snmpv3 messages? . reportPDUs created from an error status or OID returned by the appropriate subsystem/model? . foward refreences need to be handled . some TCs were defined for interface parameters, but aren't part of a mIB. move to Glossary? . Is AdminString appropriate for all strings, such as securityidentifier and context and group? These had different sizes and semantics. . AdminString has size (1..255); what about default context of ""? . snmpEngineMaxMessageSize maximum size? 65507? what about non-UDP transports? . description of max message size . definitioon/description of MD5/DES protocol OIDs. . should the tree for registering protocols be in basicGroup? . should User-based be in basicgroup conformance? . how does MPC match incoming requests with outgoing responses? . generateRequestMessage( globalData, scopedPDU, MIID, engineID ) why do we need engineID? isn't that implicit? . I rearranged primitive parameters: transport/engine/contextEngine/PDU . state_refernce releases - are these consistently defined? . should the MPC release the state_reference when it receives a response? . How is duplicate registration handled? error or ignore? 0.2. Change Log [version 3.1] . change securityIdentity to MIID . write text to explain the differences between security-identities, model-dependent identifiers, and model-independent identifiers. . write text to explain distinction within the LCD of the security data, the access control data, and the oranglet data. . identify issues . publish as <draft-ietf-snmpv3-next-gen-arch-02.txt> [version 3.0] . add section on threats for message security . add section on threats for access control . change application to orangelet . remove references to F-Ts . change securityIdentity to security-identity . change securityCookie to securityIdentity . the format of securityIdentity is defined by the model . add securityModel to passed parameters as needed Harrington/Wijnen Expires December 1977 [Page 3] Draft Architecture for Describing Internet Management Frameworks March 1997 . eliminate group from passed parameters . remove unused IMPORTS . add glossary section with initial set of words to define . differentiate the messageEngine from the contextEngine . eliminate the term SNMPng . rewrote 1.1. A Note on Terminology . eliminated assumptions about SNMP processing always being message related . rewrote 4.x to reflect new thinking . rewrote 5.x to reflect new thinking . rewrote 6.x (the MIB) to reflect new thinking . added MIB objects at this level (previously only T-Cs) . rewrote 7.x . sent to v3edit list Harrington/Wijnen Expires December 1977 [Page 4] Draft Architecture for Describing Internet Management Frameworks March 1997 1. Introduction A 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, or between management stations and other management stations. Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information. Operations of the protocol are carried out under an administrative framework which defines minimum requirements for standard services, such as sending and receiving messages, countering security threats to messages, controlling access to managed objects, and processing various types of requests. It is the purpose of this document to define an architecture which can evolve to realize effective network management in a variety of configurations and environments. The architecture has been designed to meet the needs of implementors of minimal agents, command line driven managers, mid-level managers, and full-function network enterprise management stations. 1.1. A Note on Terminology This architecture is designed to allow an orderly evolution of portions of SNMP Frameworks. Throughout the rest of this document, the term "subsystem" will refer to an abstract and incomplete specification of a portion of a Framework, that will be further refined by a model specification. A "model" describes a specific design of a subsystem, defining additional constraints and rules for conformance to the model. A model is sufficiently detailed to make it possible to implement the specification. A "implementation" is an instantiation of a subsystem, conforming to a specific model. SNMP version 1 (SNMPv1), is the original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212. SNMP version 2 (SNMPv2) is an updated design of portions of SNMPv1, as described in RFCs 1902-1908. SNMPv2 has an incomplete message definition. Harrington/Wijnen Expires December 1977 [Page 5] Draft Architecture for Describing Internet Management Frameworks March 1997 Community-based SNMP version 2 (SNMPv2c) is an experimental Framework which supplements the incomplete message format of SNMPv2 with portions of the message format of SNMPv1, as described in RFC1901. SNMP version 3 (SNMPv3) Framework is a particular configuration of implemented subsystems, consistent with the architecture described in this document. Other SNMP Frameworks, i.e. other configurations of implemented subsystems, are expected to also be consistent with this architecture. This document does not describe any framework, but describes an architecture into which multiple frameworks may be fitted. 2. Overview The architecture presented here emphasizes the use of modularity to allow the evolution of portions of SNMP without requiring a redesign of the general architecture of SNMP. SNMP processing must be performed in consistently ordered steps, which fall into general categories of similar functionality. This document will describe major abstractions of functionality required during SNMP processing, and the abstract interactions between these major categories of functionality. This document will describe how this architecture is meant to allow modules of functionality corresponding to these abstract categories to be designed to allow the evolution of the whole by modifying discrete modules within the architecture. Harrington/Wijnen Expires December 1977 [Page 6] Draft Architecture for Describing Internet Management Frameworks March 1997 3. An Evolutionary Architecture - Design Goals The goals of the architectural design are to use encapsulation, cohesion, hierarchical rules, and loose coupling to reduce complexity of design and make the evolution of portions of the architecture possible. 3.1. Encapsulation Encapsulation describes the practice of hiding the details that are used internal to a process. Some data is required for a given procedure, but isn't needed by any other part of the process. In networking, the concept of a layered stack reflects this approach. The transport layer contains data specific to its processing; the data is not visible to the other layers. In programming this is reflected in language elements such as "file static" variables in C, and "private" in C++, etc. In this architecture, all data used for processing only within a functional portion of the architecture should have its visibility restricted to that portion if possible. The data should be accessed only by that functionality defined with the data. No reference to the data should be made from outside the functional portion of the architecture, except through predefined public interfaces. 3.2. Cohesion Similar functions can be grouped together and their differences ignored, so they can be dealt with as a single entity. It is important that the functions which are grouped together are actually similar. Similarity of the data used to perform functions can be a good indicator of the similarity of the functions. For example, authentication and encryption are both security functions which are applied to a message. Access control, while similar in some ways, is dissimilar in that it is not applied to a message, it is applied to a (proposed) request for a management operation. The data required to perform authentication and encryption are different than the data needed to perform access control, and the two sets of services can be described independently. Similar functions, especially those that use the same data elements, should be defined together. The security functions which operate at the message level should be defined in a document together with the definitions for those data elements that are used only by those security functions. For example, a MIB with authentication keys is used only by authentication functions; they should be defined together. Harrington/Wijnen Expires December 1977 [Page 7] Draft Architecture for Describing Internet Management Frameworks March 1997 3.3. Hierarchical Rules Functionality can be grouped into hierarchies where each element in the hierarchy receives general characteristics from its direct superior, and passes on those characteristics to each of its direct subordinates. This architecture uses the hierarchical approach by defining subsystems, which specify the general rules of a portion of the system, models which define the specific rules to be followed by an implementation of the portion of the system, and implementations which encode those rules into reality for a portion of the system. It is expected that within portions of the system, hierarchical relationships will be used to compartmentalize, or modularize, the implementation of specific functionality. For example, it is expected that within the security portion of the system, authentication and privacy will probably be contained in separate modules, and that multiple authentication and privacy mechanisms will be supported by allowing supplemental modules that provide protocol-specific authentication and privacy services. 3.4. Coupling Coupling describes the amount of interdependence between parts of a system. Loose coupling indicates that two sub-systems are relatively independent of each other; tight coupling indicates a high degree of mutual dependence. To make it possible to evolve the architecture by replacing only part of the system, or by supplementing existing portions with alternate mechanisms for similar functionality, without obsoleting the complete system, it is necessary to limit the coupling of the parts. Encapsulation and cohesion help to reduce coupling by limiting the visibility of those parts that are only needed within portions of a system. Another mechanism is to constrain the nature of interactions between various parts of the system. This can be done by defining fixed, generic, flexible interfaces for transferring data between the parts of the system. The concept of plug-and-play hardware components is based on that type of interface between the hardware component and system into which it will be "plugged." This approach has been chosen so individual portions of the system can be upgraded over time, while keeping the overall system intact. To avoid specifying fixed interfaces, which would constrain a vendor's choice of implementation strategies, a set of abstract data elements is used for (conceptually) transferring data between subsystems in documents which describe subsystem or model interactions. Documents Harrington/Wijnen Expires December 1977 [Page 8] Draft Architecture for Describing Internet Management Frameworks March 1997 describing the interaction of subsystems or models should use only the abstract data elements provided for transferring data but vendors are not constrained to using the described data elements for transferring data between portions of their implementation. Loose coupling works well with the IETF standards process. If we separate message-handling from security and from local processing, then the separate portions of the system can move through the standards process with less dependence on the status of the other portions of the standard. Security models may be able to be re-opened for discussion due to patents, new research, export laws, etc., as is clearly expected by the WG, without needing to reopen the documents which detail the message format or the local processing of PDUs. Thus, the standards track status of related, but independent, documents is not affected. Harrington/Wijnen Expires December 1977 [Page 9] Draft Architecture for Describing Internet Management Frameworks March 1997 4. Abstract Functionality DBH: {ref: Get-Request, PDU, authentication, encryption, timeliness, managed objects, proxy, } The architecture described here contains four subsystems, each capable of being defined as one or more different models which may be replaced or supplemented as the growing needs of network management require. The subsystems are a Message Processing and Control subsystem, a Security subsystem, an Orangelet subsystem, and an Access Control subsystem. The subsystems are contained in two "engines". A messageEngine deals with SNMP messages, and is responsible for sending and receiving messages, including having authentication and encryption services applied to the messages, and determining to which Orangelet the message contents should be delivered. A contextEngine deals with processing network management operations, and contains subsystems for Access Control, MIB access, and Orangelets which provide specific functional processing. Depending on the network management service needed, an Orangelet may use the access control and MIB access subsystems, and may use SNMP messages to communicate with remote nodes. The network management service may be requested via the payload of an SNMP message, or may be requested via a local process. 4.1. The messageEngine The messageEngine interacts with the network using SNMP messages, and with the message processing subsystem and the security subsystem and with orangelets using service interfaces defined within this architecture. 4.1.1. Transport Mappings SNMP messages are sent to, or received from, the network using transport addresses. It is the responsibility of the messageEngine to listen at the appropriate local addresses, and to send messages through the appropriate addresses, consistent with mappings defined by SNMP Transport Mapping documents, such as RFC1906. 4.1.2. SNMP-Based Message Formats SNMP messages sent to, or received from, the network use a format defined by a version-specific Message Processing and Control model. The messageEngine determines to which version-specific model the message should be given. The version-specific model interacts with the security subsystem, Harrington/Wijnen Expires December 1977 [Page 10] Draft Architecture for Describing Internet Management Frameworks March 1997 using a service interface defined by this architecture, to procure security services to meet the requirements of the version-specific protocol. 4.1.3. The Interface to Orangelets A messageEngine, as a result of the receipt of an SNMP message, may initiate a transaction with an Orangelet, such as for an incoming request, or an Orangelet may initiate a transaction with a messageEngine, such as for an outgoing request. The messageEngine determines to which orangelet a message should be given. 4.1.4. Protocol Instrumentation To monitor and manage an SNMP engine, a Management Information Base for SNMP defines the collection of managed objects which instrument the SNMP protocol itself. The messageEngine has the responsibility for maintaining the instrumentation that is described by the SNMPv2 MIB module [RFC1907] plus the instrumentation which is described by the IMFMIB module defined in this document. A Message Processing and Control model may require support for MIB modules related to instrumenting version-specific aspects of the SNMP protocol. 4.2. Security Some environments require secure protocol interactions. Security is normally applied at two different stages - in the transmission/receipt of messages, and in the processing of the contents of messages. For purposes of this document, "security" refers to message-level security; "access control" refers to the security applied to protocol operations. Authentication, encryption, and timeliness checking are common functions of message level security. 4.3. Orangelets Orangelets coordinate the processing of management information operations. This document describes three common types of orangelets and how they interact within the architecture - 1) an orangelet may process requests to perform an operation on managed objects, 2) an orangelet may initiate a transaction as the result of a local event, and 3) an orangelet may act as an intermediary, forwarding an operation to another network management entity. Orangelets provide access to MIB information, and coordinate the application of access control to management operations. Harrington/Wijnen Expires December 1977 [Page 11] Draft Architecture for Describing Internet Management Frameworks March 1997 A discussion of the management information and processing is provided here, but an Orangelet model defines which set of documents are used to specifically define the structure of management information, textual conventions, conformance requirements, and operations supported by the Orangelet. 4.4.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. It is the purpose of a Structure of Management Information document to establish the syntax for defining objects, modules, and other elements of managed information. An Orangelet model defines which SMI documents are supported by the model. 4.4.2. Textual Conventions When designing a MIB module, it is often useful to define new types similar to those defined in the SMI, but with more precise semantics, or which have special semantics associated with them. These newly defined types are termed textual conventions. An Orangelet model defines which Textual Conventions documents are supported by the model. 4.4.3. Conformance Statements It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of Conformance Statements to define the notation used for these purposes. An Orangelet model defines which Conformance Statement documents are supported by the model. 4.4.4. Protocol Operations SNMP messages encapsulate a Protocol Data Unit (PDU). It is the purpose of a Protocol Operations document to define the operations of the protocol with respect to the processing of the PDUs. An Orangelet model defines which Protocol Operations documents are supported by the model. Harrington/Wijnen Expires December 1977 [Page 12] Draft Architecture for Describing Internet Management Frameworks March 1997 4.5. Access Control During processing, it may be required to control access to certain instrumentation for certain operations. The determination of access rights requires the means to identify the access allowed for the security-identity on whose behalf a request is generated. An Access Control model provides an advisory service for an Orangelet. The determination of whether to check access control policy is the responsibility of the Orangelet model. The mechanism by which access control is checked is defined by the Access Control model. 4.6. Coexistence The purpose of an evolutionary architecture is to permit new models to replace or supplement existing models. The interactions between models could result in incompatibilities, security "holes", and other undesirable effects. The purpose of a Coexistence document is to detail recognized anomalies and to describe required and recommended behaviors for resolving the interactions between models within the architecture. It would be very difficult to document all the possible interactions between a model and all other previously existing models while in the process of developing a new model. Coexistence documents are therefore expected to be prepared separately from model definition documents, to describe and resolve interaction anomalies between a model definition and one or more other model definitions. Harrington/Wijnen Expires December 1977 [Page 13] Draft Architecture for Describing Internet Management Frameworks March 1997 5. Abstract Data Elements of the Architecture This section contains definitions of abstract data elements used to transfer data between subsystems. 5.1. engineID Each SNMP engine, consisting of potentially many subsystems, must be able to be uniquely identified. The mechanism by which this can be done is defined in the IMFMIB module, described in this document, since it is desirable that engine identification span all frameworks. 5.2. SecurityIdentity A generic term for an uniquely-identifiable entity on whose behalf a message can be generated. Each security subsystem may define a model-specific mechanism for entity identification, such as a community [RFC1157] or user [RFC1910] or party-pair [RFC1445]. This model-specific identifier is not guaranteed to be represented in a character set readable by humans. 5.3. Model Independent Identifier (MIID) Each security model must also provide a mapping from the model specific identification to an SnmpAdminString representation, called the MIID, which, in combination with the securityModel, can be used by all other subsystems within an engine to identify a security identity, regardless of the security mechanisms used to provide security services. The combination of engineID and securityModel and MIID provides a globally-unique identifier for an entity on whose behalf a message can be generated. 5.4. Level of Security Messages may require different levels of security. The acronym LoS is used to refer to the level of security. This architecture recognizes three levels of security: - without authentication and without privacy (noAuth/noPriv) - with authentication but without privacy (auth/noPriv) - with authentication and with privacy (auth/Priv) Every message has an associated LoS; all subsystems (security, access control, orangelets, message processing and control) are required to abide the specified LoS while processing the message and its contents. Harrington/Wijnen Expires December 1977 [Page 14] Draft Architecture for Describing Internet Management Frameworks March 1997 5.5. Contexts An SNMP context is a collection of management information accessible by an SNMP engine. An item of management information may exist in more than one context. An SNMP engine potentially has access to many contexts. 5.6. ContextName An octet string used to name a context. Each context must be uniquely named within an engine. 5.7. ContextEngineID A contextEngineID uniquely identifies an engine that may realize an instance of a named context. 5.8. Naming Scope The combination of a contextEngineID and a contextName uniquely identifies a context within an administrative domain, and is called a naming scope. 5.9. Scoped-PDU A scopedPDU contains a Naming-Scope and a PDU. The Naming Scope unambiguously identifies, within the administrative domain, the context to which the SNMP management information in the PDU refers. The PDU format is defined by an Orangelet model, or a document referenced by an Orangelet model, which processes the PDU contents. 5.10. PDU-MMS the maximum size of a scopedPDU to be included in a response message, given the amount of reserved space in the message for the anticipated security parameters. 5.11. Local Configuration Datastore The subsystems and models in an SNMP engine may need to retain their own, possibly multiple, sets of information to perform their processing. To allow these sets of information to be remotely configured, portions may need to be accessible as managed objects. The collection of these possibly multiple sets of information is referred to collectively as an engine's Local Configuration Datastore (LCD). Harrington/Wijnen Expires December 1977 [Page 15] Draft Architecture for Describing Internet Management Frameworks March 1997 5.11.1. Security Portion of the Local Configuration Datastore Each Security model may need to retain its own set of information about security entities, mechanisms, and policies. 5.11.2. Orangelet Portion of the Local Configuration Datastore Each Orangelet model may need to retain its own set of information about contexts, naming scopes, and other configuration data. 5.11.3. Access Control Portion of the Local Configuration Datastore Each Access Control model may need to retain its own set of information about access control policies, and the MIIDs to which the policies apply. 5.12. Groups A Group identifies a set of zero or more MIIDs on whose behalf SNMP managed objects are being processed, subject to access control policies common to all members of the group. Harrington/Wijnen Expires December 1977 [Page 16] Draft Architecture for Describing Internet Management Frameworks March 1997 6. Definition of Managed Objects for Internet Management Frameworks IMF-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, snmpModules, Unsigned32, Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; imfMIB MODULE-IDENTITY LAST-UPDATED "9706160000Z" -- 16 June 1997, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@tis.com Subscribe: majordomo@tis.com In message body: subscribe snmpv3 Chair: Russ Mundy Trusted Information Systems postal: 3060 Washington Rd Glenwood MD 21738 email: mundy@tis.com phone: 301-854-6889 Co-editor Dave Harrington Cabletron Systems, Inc postal: Post Office Box 5005 MailStop: Durham 35 Industrial Way Rochester NH 03867-5005 email: dbh@cabletron.com phone: 603-337-7357 Co-editor: Bert Wijnen IBM T.J. Watson Research postal: Schagen 33 3461 GL Linschoten Netherlands email: wijnen@vnet.ibm.com phone: +31-348-412-498 " DESCRIPTION "The Internet Management Architecture MIB" ::= { snmpModules 99 } -- Textual Conventions used in the Internet Management Architecture *** SnmpEngineID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNMP engine's administratively-unique identifier. Harrington/Wijnen Expires December 1977 [Page 17] Draft Architecture for Describing Internet Management Frameworks March 1997 The value for this object may not be all zeros or all 'ff'H. The initial value for this object may be configured via an operator console entry or via an algorithmic function. In the later case, the following guidelines are recommended: 1) The first four octets are set to the binary equivalent of the agent's SNMP network management private enterprise number as assigned by the Internet Assigned Numbers Authority (IANA). For example, if Acme Networks has been assigned { enterprises 696 }, the first four octets would be assigned '000002b8'H. 2) The remaining eight octets are the cookie whose contents are determined via one or more enterprise specific methods. Such methods must be designed so as to maximize the possibility that the value of this object will be unique in the agent's administrative domain. For example, the cookie may be the IP address of the agent, or the MAC address of one of the interfaces, with each address suitably padded with random octets. If multiple methods are defined, then it is recommended that the cookie be further divided into one octet that indicates the method being used and seven octets which are a function of the method. " SYNTAX OCTET STRING (SIZE (12)) SnmpSecurityModel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An identifier that uniquely identifies a model of security subsystem within the Internet Management Architecture. " SYNTAX INTEGER(0..2147483647) -- BW to DBH: why do we need the following TC? It is never used in a MIB -- is it? -- DBH to BW: I defined this only because it was used in an architectural -- interface, and felt that the architecture should define the -- limits of the syntax, and provide a common description. -- -- SnmpSecurityStateReference ::= TEXTUAL-CONVENTION -- STATUS current -- DESCRIPTION "An implementation-defined reference to the retained -- security information required to send a response. Harrington/Wijnen Expires December 1977 [Page 18] Draft Architecture for Describing Internet Management Frameworks March 1997 -- The security model defines what information must be -- retained for use in sending the response. -- " -- SYNTAX OCTET STRING SnmpLoS ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A level of security at which SNMP messages can be sent; in particular, one of: noAuth - without authentication and without privacy, auth - with authentication but without privacy, priv - with authentication and with privacy. " SYNTAX INTEGER { noAuth(1), auth(2), priv(3) } SnmpAdminString ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An octet string containing an SNMP administrative string. Preferably this a a human readable string. We're still thinking if this could use the UTF8 character set. " SYNTAX OCTET STRING (SIZE(1..255)) -- BW to DBH: I think these are no longer needed. They now use the -- SnmpV3AdminString TC. -- DBH to BW: so now all securityidentities, Gropups, and Contxets -- can be up to 255 bytes long, and MUST always be at least -- one byte in length? What is our new default context? -- -- SnmpSecurityIdentity ::= TEXTUAL-CONVENTION -- STATUS current -- DESCRIPTION "A octet string which contains data in a format -- defined by a security model which identifies a -- unique identity for which messages may be generated. -- The securityIdentity must be unique across all -- securityModels supported by the engine. -- " -- SYNTAX DisplayString (SIZE (0..32)) -- -- SnmpGroupName ::= TEXTUAL-CONVENTION -- STATUS current -- DESCRIPTION "An octet string which identifies a set of zero or -- more security entities on whose behalf SNMP managed -- objects are being processed, subject to access -- control policies common to all members of the group. -- " -- SYNTAX OCTET STRING (SIZE(1..16)) -- --SnmpContextName ::= TEXTUAL-CONVENTION -- STATUS current Harrington/Wijnen Expires December 1977 [Page 19] Draft Architecture for Describing Internet Management Frameworks March 1997 -- DESCRIPTION "A name which uniquely identifies a set of -- management information realized by an SNMP engine. -- " -- SYNTAX OCTET STRING (SIZE (0..32)) -- -- -- The IMF Engine Group -- -- Administrative assignments **************************************** imfAdmin OBJECT IDENTIFIER ::= { imfMIB 1 } imfMIBObjects OBJECT IDENTIFIER ::= { imfMIB 2 } imfMIBConformance OBJECT IDENTIFIER ::= { imfMIB 3 } -- the imfEngine group *********************************************** imfEngine OBJECT IDENTIFIER ::= { imfMIBObjects 1 } snmpEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "An SNMP engine's administratively-unique identifier. " ::= { imfEngine 1 } snmpEngineBoots OBJECT-TYPE SYNTAX Unsigned32 -- (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that the engine has re-initialized itself since its initial configuration. " ::= { imfEngine 2 } snmpEngineTime OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds since the engine last incremented the snmpEngineBoots object. " ::= { imfEngine 3 } snmpEngineMaxMessageSize OBJECT-TYPE -- SYNTAX Integer32 (484..2147483647) -- From BW to DBH: why did you use that large range? The 65507 is the -- max that fits in a UDP datagram. I thought we -- reached consensus on that on the mailinglist. -- DBH to BW: did we? I thought there were arguments that we should Harrington/Wijnen Expires December 1977 [Page 20] Draft Architecture for Describing Internet Management Frameworks March 1997 -- not work with the limits of UDP, since other transports -- are now officially supported. If I write an engine that -- has a larger buffer, and use a transport that can handle -- the larger size, why artficially limit it? The type can -- handle the larger number; why impose unnecessary limits? SYNTAX Integer32 (484..65507) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum length in octets of an SNMP message which this SNMP engine can send or receive and process, determined as the minimum of the maximum message size values supported among all of the transports available to and supported by the engine. " -- From BW to DBH: How do you like this (picked it from RFC1910): -- I think it is only meant to state what it can -- receive!!! -- DBH to BW: I think the one above came from snmpv2*. I think the send -- was included to indictae -- to an enquiring manager how large a getBulk might be -- supported, so a manager didn't send one obviously too large, -- and to reflect that a message might be receivable, but not -- be able to be processed due to resource limitations (such -- as an ASN.1-decoded message being larger than the encoded -- message, or a secured message with a non-sent key that led -- to resource allocation problems...) -- DESCRIPTION "The maximum length in octets of an SNMP message which -- this agent will accept using any transport mapping. -- " ::= { imfEngine 4 } -- From BW to DBH: Was the following decided at the interim? -- We had those defined in USEC doc.... so if we -- do define these protocols here, then I can -- remove them from USEC doc. -- DBH to BW: Not sure if decided; If we want protocols defined -- in a common place, the arch mib should provide the tree. -- I don't object to MD5 and DES being defined in USEC, but -- the arch doc does specify they are expected, so I think -- it treasonable to define here, especially if we want to -- make it mandatory for basic compliance. -- -- The IMF IETF-Standard Authentication Protocols Group -- imfAuthProtocols OBJECT IDENTIFIER ::= { imfAdmin 1 } imfNoAuthProtocol OBJECT IDENTIFIER ::= { imfAuthProtocols 1 } imfAuthMD5Protocol OBJECT IDENTIFIER ::= { imfAuthProtocols 2 } Harrington/Wijnen Expires December 1977 [Page 21] Draft Architecture for Describing Internet Management Frameworks March 1997 DBH to BW: should we have a description of this object to make it meaningful? ditto for DES below. -- -- The IMF IETF-Standard Privacy Protocols Group -- imfPrivProtocols OBJECT IDENTIFIER ::= { imfAdmin 2 } imfNoPrivProtocol OBJECT IDENTIFIER ::= { imfPrivProtocols 1 } imfDESPrivProtocol OBJECT IDENTIFIER ::= { imfPrivProtocols 2 } -- conformance information imfMIBCompliances OBJECT IDENTIFIER ::= { imfMIBConformance 1 } imfMIBGroups OBJECT IDENTIFIER ::= { imfMIBConformance 2 } -- compliance statements imfMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the IMF MIB. " MODULE -- this module MANDATORY-GROUPS { imfEngineBasicGroup } ::= { imfMIBCompliances 1 } -- units of conformance imfEngineBasicGroup OBJECT-GROUP OBJECTS { snmpEngineID, snmpEngineMaxMessageSize, snmpEngineBoots, snmpEngineTime } STATUS current DESCRIPTION "A collection of objects for identifying and determining the configuration limits of an SNMP agent. " ::= { imfMIBGroups 1 } -- DBH to BW: should the tree for registering protocols be in basicGroup? -- I thouhgt we had consensus that user-based security was required Harrington/Wijnen Expires December 1977 [Page 22] Draft Architecture for Describing Internet Management Frameworks March 1997 -- as a minimum. No? END Harrington/Wijnen Expires December 1977 [Page 23] Draft Architecture for Describing Internet Management Frameworks March 1997 7. Model Design Requirements The basic design elements come from SNMPv2u and SNMPv2*, as described in RFCs 1909-1910, and from a set of internet drafts. these are the two most popular de facto "administrative framework" standards that include security and access control for SNMPv2. SNMPv1 and SNMPv2c [RFC1901] are two administrative frameworks based on communities to provide trivial authentication and access control. SNMPv1 and SNMPv2c Frameworks can coexist with Frameworks designed to fit into this architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks could be fit into this architecture, but this document does not provide guidelines for that coexistence. Within any subsystem model, there should be no reference to any specific model of another subsystem, or to data defined by a specific model of another subsystem. Transfer of data between the subsystems is deliberately described as a fixed set of abstract data elements and primitive functions which can be overloaded to satisfy the needs of multiple model definitions. Documents which define models to be used within this architecture are constrained to using the abstract data elements for transferring data between subsystems, possibly defining specific mechanisms for converting the abstract data into model-usable formats. This constraint exists to allow subsystem and model documents to be written recognizing common borders of the subsystem and model. Vendors are not constrained to recognize these borders in their implementations. The architecture defines certain standard services to be provided between subsystems, and the architecture defines abstract data elements to transfer the data necessary to perform the services. Each model definition for a subsystem must support the standard service interfaces, but whether, or how, or how well, it performs the service is defined by the model definition. 7.1. Security Model Design Requirements 7.1.1. Threats Several of the classical threats to network protocols are applicable to the network management problem and therefore would be applicable to any security model used in an Internet Management Framework. Other threats are not applicable to the network management problem. This section discusses principal threats, secondary threats, and threats which are of lesser importance. The principal threats against which any security model used within this architecture should provide protection are: Harrington/Wijnen Expires December 1977 [Page 24] Draft Architecture for Describing Internet Management Frameworks March 1997 Modification of Information The modification threat is the danger that some unauthorized entity may alter in-transit SNMP messages generated on behalf of an authorized security-identity in such a way as to effect unauthorized management operations, including falsifying the value of an object. Masquerade The masquerade threat is the danger that management operations not authorized for some security-identity may be attempted by assuming the identity of another security-identity that has the appropriate authorizations. Message Stream Modification The SNMPv3 protocol is typically based upon a connectionless transport service which may operate over any subnetwork service. The re-ordering, delay or replay of messages can and does occur through the natural operation of many such subnetwork services. The message stream modification threat is the danger that messages may be maliciously re-ordered, delayed or replayed to an extent which is greater than can occur through the natural operation of a subnetwork service, in order to effect unauthorized management operations. Disclosure The disclosure threat is the danger of eavesdropping on the exchanges between SNMP engines. Protecting against this threat may be required as a matter of local policy. There are at least two threats against which a security model used by a framework within this architecture need not protect. Denial of Service A security model need not attempt to address the broad range of attacks by which service on behalf of authorized users is denied. Indeed, such denial-of-service attacks are in many cases indistinguishable from the type of network failures with which any viable network management protocol must cope as a matter of course. Traffic Analysis A security model need not attempt to address traffic analysis attacks. Many traffic patterns are predictable - agents may be managed on a regular basis by a relatively small number of management stations - and therefore there is no significant advantage afforded by protecting against traffic analysis. 7.1.2. Security Processing Received messages must be validated by a model of the security subsystem. Validation includes authentication and privacy processing Harrington/Wijnen Expires December 1977 [Page 25] Draft Architecture for Describing Internet Management Frameworks March 1997 if needed, but it is explicitly allowed to send messages which do not require authentication or privacy. A received message will contain a specified Level of Security to be used during processing. All messages requiring privacy must also require authentication. A security model specifies rules by which authentication and privacy are to be done. A model may define mechanisms to provide additional security features, but the model definition is constrained to using (possibly a subset of) the abstract data elements defined in this document for transferring data between subsystems. Each Security model may allow multiple security mechanisms to be used concurrently within an implementation of the model. Each Security model defines how to determine which protocol to use, given the LoS and the security parameters relevant to the message. Each Security model, with its associated protocol(s) defines how the sending/receiving entities are identified, and how secrets are configured. Authentication and Privacy protocols supported by security models are uniquely identified using Object Identifiers. IETF standard protocol for authentication or privacy should have an identifier defined within the ImfAuthenticationProtocols or ImfPrivacyProtocols subtrees. Enterprise-specific protocol identifiers should be defined within the enterprise subtree. For privacy, the Security model defines what portion of the message is encrypted. The persistent data used for security should be SNMP-manageable, but the Security model defines whether an instantiation of the MIB is a conformance requirement. Security models are replaceable within the security subsystem. Multiple Security model Implementations may exist concurrently within an engine. The number of Security models defined by the SNMP community should remain small to promote interoperability. It is required that an implementation of the User-Based Security model be used in all engines to ensure at least a minimal level of interoperability. 7.1.3. validate the security-stamp in a received message given a message, the MMS, LoS, and the security parameters from that message, verify the message has not been altered, and authenticate the identification of the security-identity for whom the message was generated. If encrypted, decrypt the message Additional requirements may be defined by the model, and additional Harrington/Wijnen Expires December 1977 [Page 26] Draft Architecture for Describing Internet Management Frameworks March 1997 services provided by the model, but the model is constrained to use only the defined abstract data elements for transferring data between subsystems. Implementations are no so constrained. return a MIID identifying the security-identity for whom the message was generated and return the portions of the message needed for further processing: a PDU - a PDU containing varbinds and a verb according to the rules of the Local Processing model to be used. LoS - the level of security required. The same level of security must also be used during application of access control. MMS - the maximum size of a message able to be generated by this engine for the destination agent. PDU-MMS - the maximum size of a PDU to be included in a response message, given the amount of reserved space in the message for the anticipated security parameters. 7.1.4. Security Identity Different security models define identifiers which represent somewhich somehow exists, and is capable of using SNMP. The may be person, or a network-management platform, or an aggregate of persons, or an aggregation of persons and devices, or some other abstraction of entities that are recognized as being able to use SNMP-defined services. This document will refer to that abstraction as a security-identity. 7.1.5. Model Dependent Identifier Each Security model defines how security-identities are identified within the model, i.e. how they are named. Model-dependent identifiers must be unique within the model. The combination of engineID, securityModel, and the correct model-dependent identifier can be used to uniquely identify a security-identity. For example, David Harrington may be represented on a particular engine by multiple security models - as the user "davidh", the community "david", and the foobar "david". It is legal to use "david" in more than one model, since uniqueness is only guaranteed within the model, but there cannot be two "david" communities. The combination of the engineID, the model, and the user "davidh" uniquely identifies the security-entity David Harrington. 7.1.6. Model Independent Identifier It is desirable to be able to refer to a security-entity using a human readable identifier, such as for audit trail entries. Therefore, each Security model is required to define a mapping between Harrington/Wijnen Expires December 1977 [Page 27] Draft Architecture for Describing Internet Management Frameworks March 1997 a model-dependent identifier and an identifier restricted to a human readable character set. This identifier is called a MIID. The type of a MIID is a human-readable OCTET STRING following the conventions of the SnmpAdminString TEXTUAL-CONVENTION, defined below. The combination of engineID and securityModel and MIID can be used as a globally-unique identifier for a security-identity. It is important to note that since the MIID may be accessible outside the engine, care must be taken to not disclose sensitive data, such as by including passwords in open text in the MIID. 7.1.5. Security MIBs Each Security model defines the MIB modules required for security processing, including any MIB modules required for the security mechanism(s) supported. The MIB modules must be defined concurrently with the procedures which use the MIB module. The MIB modules are subject to normal security and access control rules. The mapping between the model-dependent identifier and the MIID must be able to be determined using SNMP, if the model-dependent MIB is instantiated and access control policy allows. 7.1.6. Security State Cacheing For each message received, the security subsystem caches the state information such that a response message can be generated using the same security state information, even if the security portion of the Local Configuration Datastore is altered between the time of the incoming request and the outgoing response. The Orangelet subsystem has the responsibility for explicitly releasing the cached data. To enable this, an abstract state_reference data element is passed from the security subsystem to the message processing and control subsystem, which passes it to the orangelet subsystem. The cached security data must be implicitly released via the generation of a response, or explicitly released by using the state_release() primitive: state_release( state_reference ) 7.2. MessageEngine and Message Processing and Control Model Requirements A messageEngine may contain multiple version-specific Message Processing and Control models. Within any version-specific Message Processing and Control model, there may be an explicit binding to a particular security model but there should be no reference to any data defined by a specific security model. there should be Harrington/Wijnen Expires December 1977 [Page 28] Draft Architecture for Describing Internet Management Frameworks March 1997 no reference to any specific Orangelet model, or to any data defined by a specific Orangelet model; there should be no reference to any specific Access Control model, or to any data defined by a specific Access Control model. The Message Processing and Control model must always (conceptually) pass the complete PDU, i.e. it never forwards less than the complete list of varbinds. 7.2.1. Receiving an SNMP Message from the Network Upon receipt of a message from the network, the messageEngine will, in an implementation-defined manner, establish a mechanism for coordinating all processing regarding this received message, e.g. it may assign a "handle" to the message. DBH: It is no longer valid that the MPC coordinates all processing. But it still needs to match requests and responses. how does an incoming request get matched to the outgoing response? A Message Processing and Control model will specify how to determine the values of the global data (MMS, the securityModel, the LoS), and the security parameters block. The Message Processing and Control will call the security model to provide security processing for the message using the primitive: processMsg( globalData, securityParameters, wholeMsg, wholeMsgLen ) The Security model, after completion of its processing, will return to the Message Processing and Control model the extracted information, using the returnProcess() primitive: returnProcess( scopedPDUmms, MIID, cachedSecurityData, scopedPDU, statusCode ) 7.2.2. Send SNMP messages to the network The Message Processing and Control model will pass a PDU, the MIID, and all global data to be included in the message to the Security model using the following primitives: For requests and notifications: generateRequestMessage( globalData, scopedPDU, MIID, engineID ) DBH: why do we need engineID? isn't that implicit? For response messages: generateResponseMessage( globalData, scopedPDU, MIID, cachedSecurityData ) The Security model will construct the message, and return the completed message to the messageEngine using the returngenerate() primitive: returnGenerate( wholeMsg, wholeMsglen, statusCode ) Harrington/Wijnen Expires December 1977 [Page 29] Draft Architecture for Describing Internet Management Frameworks March 1997 The messageEngine will send the message to the desired address using the appropriate transport. 7.2.3. Generate a Request or Notification Message for an Orangelet The messageEngine will receive a request for the generation of an SNMP message from an orangelet via the send_pdu primitive: send_pdu( transportDomain, transportAddress, snmpVersion, LoS, securityModel, MIID, contextEngineID, contextName, PDU, The messageEngine checks the verb in the PDU to determine if it is a message which may receive a response, and if so, caches the msgID of the generated message and the associated orangelet. The messageEngine will generate the message according to the process described in 7.2.2. 7.2.4. Forward Received Response Message to an Orangelet The Message Processing and Control will receive the SNMP message according to the process described in 7.2.1. The Message Processing and Control will determine which orangelet is awaiting a response, using the msgID and the cached information from step 7.2.3 The messageEngine matches the msgID of an incoming response to the cached msgIDs of messages sent by this messageEngine, and forwards the response to the associated Orangelet using the process_pdu() primitive: process_pdu( contextEngineID, contextName, pdu, LoS, scopedPdu-MMS, securityModel, MIID, state-reference ) 7.2.5. Forward Received Request or Notification Message to an Orangelet The messageEngine will receive the SNMP message according to the process described in 7.2.1. The messageEngine will look into the scopedPDU to determine the contextEngineID, then determine which orangelet has registered to support that contextEngineID, and forwards the request or notification to the registered Orangelet using the process_pdu() primitive: process_pdu( contextEngineID, contextName, pdu, LoS, scopedPdu-MMS, securityModel, MIID, state-reference ) Harrington/Wijnen Expires December 1977 [Page 30] Draft Architecture for Describing Internet Management Frameworks March 1997 7.2.6. Generate a Response Message for an Orangelet The messageEngine will receive a request for the generation of an SNMP response message from an orangelet via the return_pdu primitive: return_pdu( contextEngineID, contextName, LoS, MIID, state_reference, PDU, PDU-MMS, status_code ) The messageEngine will generate the message according to the process described in 7.2.2. 7.3. Orangelet Model Design Requirements Within an Orangelet model, there may be an explicit binding to a specific SNMP message version, i.e. a specific Message Processing and Control model, and to a specific Access Control model, but there should be no reference to any data defined by a specific Message Processing and Control model or Access Control model. Within an Orangelet model, there should be no reference to any specific Security model, or any data defined by a specific Security model. An Orangelet determines whether explicit or implicit access control should be applied to the operation, and, if access control is needed, which Access Control model should be used. An orangelet has the responsibility to define any MIB modules used to provide orangelet-specific services. Orangelets interact with the messageEngine to initiate messages, receive responses, receive asynchronous messages, and send responses. 7.3.1. Orangelets that Initiate Messages Orangelets may request that the messageEngine send messages containing SNMP polling requests or notifications using the send_pdu() primitive: send_pdu( transportDomain, transportAddress, snmpVersion, LoS, securityModel, MIID, contextEngineID, contextName, PDU, [DBH: I rearranged these parameters into groups of related data organized roughly by order of locality - transport/engine/contextEngine/PDU.] If it is desired that a message be sent to multiple targets, it is the reponsibility of the orangelet to provide the iteration. The messageEngine assumes necessary access control has been applied to the PDU, and provides no access control services. Harrington/Wijnen Expires December 1977 [Page 31] Draft Architecture for Describing Internet Management Frameworks March 1997 The messageEngine looks at the verb, and for operations which will elicit a response, the msgID and the associated orangelet are cached. 7.3.2. Orangelets that Receive Responses The messageEngine matches the msgID of an incoming response to the cached msgIDs of messages sent by this messageEngine, and forwards the response to the associated Orangelet using the process_pdu() primitive: process_pdu( contextEngineID, contextName, pdu, LoS, scopedPdu-MMS, securityModel, MIID, state-reference ) DBH: should the MPC release the state_reference when it receives a response? There isn't much reason to force the orangelet to handle this if the MPC already knows it is a response message, i.e. the end of a transaction. 7.3.3. Orangelets that Receive Asynchronous Messages When a messageEngine receives a message that is not the response to a request from this messageEngine, it must determine to which Orangelet the message should be given. An Orangelet that wishes to receive asynchronous messages registers itself with the messageEngine using the registration primitive. An Orangelet that wishes to stop receiving asynchronous messages should un-register itself with the messageEngine. register_contextEngineID ( contextEngineID ) unregister_contextEngineID ( contextEngineID ) Only one registration per contextEngineID is permitted at the same time. Duplicate registrations are ignored. [DBH: there is no provision for an error for this. Is the second just ignored?] All asynchronously received messages referencing a registered contextEngineID will be sent to the orangelet which registered to support that contextEngineID. This includes incoming requests, incoming notifications, and proxies. It forwards the PDU to the registered Orangelet, using the process_pdu() primitive: process_pdu( contextEngineID, contextName, PDU, PDU-MMS, LoS, securityModel, MIID, state_reference ) 7.3.4. Orangelets that Send Responses Request operations require responses. These operations include Get requests, set requests, and inform requests. An Orangelet sends a response via the return_pdu primitive: Harrington/Wijnen Expires December 1977 [Page 32] Draft Architecture for Describing Internet Management Frameworks March 1997 return_pdu( contextEngineID, contextName, LoS, MIID, state_reference, PDU, PDU-MMS, status_code ) The contextEngineID, contextName, LoS, MIID, and state_reference parameters are from the initial process_pdu() primitive. The PDU and status_code are the results of processing. DBH: in the v2adv approach, a handle was passed so the messageEngine could match the response to the incoming request. How is it done now? 7.4. Access Control Model Design Requirements An Access Control model must determine whether the specified MIID is allowed to perform the requested operation on a specified managed object. The Access Control model specifies the rules by which access control is determined. A model may define mechanisms to provide additional processing features, but is constrained to using the abstract data elements defined in this document for transferring data between subsystems. The persistent data used for access control should be manageable using SNMP, but the Access Control model defines whether an instantiation of the MIB is a conformance requirement. Harrington/Wijnen Expires December 1977 [Page 33] Draft Architecture for Describing Internet Management Frameworks March 1997 8. Security Consideration This document describes how a framework can use a Security model and a Local Processing model to achieve a level of security for network management messages and controlled access to data. The level of security provided is determined by the specific Security model implementation(s) and the specific Local Processing model implementation(s) incorporated into this framework. Orangelets have access to data which is not secured. Orangelets should take reasonable steps to protect the data from disclosure. It is the responsibility of the purchaser of a management framework implementation to ensure that: 1) an implementation of this framework is fully compliant with the rules defined by this architecture, 2) the implementation of the Security model complies with the rules of the Security model, 3) the implementation of the Local Processing model complies with the rules of the Local Processing model, 4) the implementation of associated orangelets comply with the rules of this framework relative to orangelets, 5) the Security model of the implementation(s) incorporated into the framework satisfy the security needs of the organization, 6) the Local Processing model of the implementation(s) incorporated into the framework satisfy the access control policies of the organization, 7) the implementation of the Security model protects against inadvertently revealing security secrets in its design of implementation-specific data structures, 8) the implementation of the Local Processing model protects against inadvertently revealing configuration secrets in its design of implementation-specific data structures, 9) and implementation of the orangelets protect security and access control configuration secrets from disclosure. Harrington/Wijnen Expires December 1977 [Page 34] Draft Architecture for Describing Internet Management Frameworks March 1997 9. Glossary Harrington/Wijnen Expires December 1977 [Page 35] Draft Architecture for Describing Internet Management Frameworks March 1997 10. References [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, Performance International, and the MIT Laboratory for Computer Science, May 1990. [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1445] Galvin, J., and McCloghrie, K., "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S., Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S., Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [RFC1904] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S., Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996. [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S., Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", Harrington/Wijnen Expires December 1977 [Page 36] Draft Architecture for Describing Internet Management Frameworks March 1997 RFC 1907 January 1996. [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996. [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure for SNMPv2", RFC1909, February 1996 [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", RFC1910, February 1996 Harrington/Wijnen Expires December 1977 [Page 37] Draft Architecture for Describing Internet Management Frameworks March 1997 11. Editor's Addresses Co-editor: Bert Wijnen IBM T.J. Watson Research postal: Schagen 33 3461 GL Linschoten Netherlands email: wijnen@vnet.ibm.com phone: +31-348-412-498 Co-editor Dave Harrington Cabletron Systems, Inc postal: Post Office Box 5005 MailStop: Durham 35 Industrial Way Rochester NH 03867-5005 email: dbh@cabletron.com phone: 603-337-7357 Harrington/Wijnen Expires December 1977 [Page 38] Draft Architecture for Describing Internet Management Frameworks March 1997 12. Acknowledgements This document builds on the work of the SNMP Security and Administrative Framework Evolution team, comprised of David Harrington (Cabletron Systems Inc.) Jeff Johnson (Cisco) David Levi (SNMP Research Inc.) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (IBM T.J. Watson Research) Harrington/Wijnen Expires December 1977 [Page 39] Draft Architecture for Describing Internet Management Frameworks March 1997 Table of Contents 0. Issues 3 0.1. Issues to be resolved 3 0.2. Change Log 3 1. Introduction 5 1.1. A Note on Terminology 5 2. Overview 6 3. An Evolutionary Architecture - Design Goals 7 3.1. Encapsulation 7 3.2. Cohesion 7 3.3. Hierarchical Rules 8 3.4. Coupling 8 4. Abstract Functionality 10 4.1. The messageEngine 10 4.1.1. Transport Mappings 10 4.1.2. SNMP-Based Message Formats 10 4.1.3. The Interface to Orangelets 11 4.1.4. Protocol Instrumentation 11 4.2. Security 11 4.3. Orangelets 11 4.4.1. Structure of Management Information 12 4.4.2. Textual Conventions 12 4.4.3. Conformance Statements 12 4.4.4. Protocol Operations 12 4.5. Access Control 13 4.6. Coexistence 13 5. Abstract Data Elements of the Architecture 14 5.1. engineID 14 5.2. SecurityIdentity 14 5.3. Model Independent Identifier (MIID) 14 5.4. Level of Security 14 5.5. Contexts 15 5.6. ContextName 15 5.7. ContextEngineID 15 5.8. Naming Scope 15 5.9. Scoped-PDU 15 5.10. PDU-MMS 15 5.11. Local Configuration Datastore 15 5.11.1. Security Portion of the Local Configuration Datastore 16 5.11.2. Orangelet Portion of the Local Configuration Datastore 16 5.11.3. Access Control Portion of the Local Configuration Datastore 16 5.12. Groups 16 6. Definition of Managed Objects for Internet Management Frameworks 17 7. Model Design Requirements 24 7.1. Security Model Design Requirements 24 7.1.1. Threats 24 7.1.2. Security Processing 25 7.1.3. validate the security-stamp in a received message 26 7.1.4. Security Identity 27 7.1.5. Model Dependent Identifier 27 7.1.6. Model Independent Identifier 27 7.1.5. Security MIBs 28 7.1.6. Security State Cacheing 28 7.2. MessageEngine and Message Processing and Control Model Requirements 28 7.2.1. Receiving an SNMP Message from the Network 29 7.2.2. Send SNMP messages to the network 29 7.2.3. Generate a Request or Notification Message for an Orangelet 30 7.2.4. Forward Received Response Message to an Orangelet 30 7.2.5. Forward Received Request or Notification Message to an Orangelet 30 7.2.6. Generate a Response Message for an Orangelet 31 7.3. Orangelet Model Design Requirements 31 7.3.1. Orangelets that Initiate Messages 31 7.3.2. Orangelets that Receive Responses 32 7.3.3. Orangelets that Receive Asynchronous Messages 32 7.3.4. Orangelets that Send Responses 32 7.4. Access Control Model Design Requirements 33 8. Security Consideration 34 9. Glossary 35 10. References 36 11. Editor's Addresses 38 12. Acknowledgements 39 Harrington/Wijnen Expires December 1977 [Page 40]