Network Working Group D. Harrington Request for Comments: 2271 Cabletron Systems, Inc. Obsoletes: 2261 R. Presuhn Category: Standards Track BMC Software, Inc. B. Wijnen IBM T. J. Watson Research January 1998 An Architecture for Describing SNMP Management Frameworks Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. IANA Note Due to a clerical error in the assignment of the snmpModules in this memo, this RFC provides the corrected number assignment for this protocol. This memo obsoletes RFC 2261. Abstract This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. Table of Contents 1. Introduction ................................................ 3 1.1. Overview .................................................. 3 1.2. SNMP ...................................................... 4 1.3. Goals of this Architecture ................................ 5 1.4. Security Requirements of this Architecture ................ 6 1.5. Design Decisions .......................................... 7 2. Documentation Overview ...................................... 8 Harrington, et. al. Standards Track [Page 1] RFC 2271 SNMPv3 Architecture January 1998 2.1. Document Roadmap .......................................... 10 2.2. Applicability Statement ................................... 10 2.3. Coexistence and Transition ................................ 10 2.4. Transport Mappings ........................................ 11 2.5. Message Processing ........................................ 11 2.6. Security .................................................. 11 2.7. Access Control ............................................ 11 2.8. Protocol Operations ....................................... 12 2.9. Applications .............................................. 12 2.10. Structure of Management Information ...................... 12 2.11. Textual Conventions ...................................... 13 2.12. Conformance Statements ................................... 13 2.13. Management Information Base Modules ...................... 13 2.13.1. SNMP Instrumentation MIBs .............................. 13 2.14. SNMP Framework Documents ................................. 13 3. Elements of the Architecture ................................ 14 3.1. The Naming of Entities .................................... 14 3.1.1. SNMP engine ............................................. 15 3.1.1.1. snmpEngineID .......................................... 16 3.1.1.2. Dispatcher ............................................ 16 3.1.1.3. Message Processing Subsystem .......................... 16 3.1.1.3.1. Message Processing Model ............................ 17 3.1.1.4. Security Subsystem .................................... 17 3.1.1.4.1. Security Model ...................................... 17 3.1.1.4.2. Security Protocol ................................... 18 3.1.2. Access Control Subsystem ................................ 18 3.1.2.1. Access Control Model .................................. 18 3.1.3. Applications ............................................ 18 3.1.3.1. SNMP Manager .......................................... 19 3.1.3.2. SNMP Agent ............................................ 20 3.2. The Naming of Identities .................................. 21 3.2.1. Principal ............................................... 21 3.2.2. securityName ............................................ 21 3.2.3. Model-dependent security ID ............................. 22 3.3. The Naming of Management Information ...................... 22 3.3.1. An SNMP Context ......................................... 23 3.3.2. contextEngineID ......................................... 24 3.3.3. contextName ............................................. 24 3.3.4. scopedPDU ............................................... 25 3.4. Other Constructs .......................................... 25 3.4.1. maxSizeResponseScopedPDU ................................ 25 3.4.2. Local Configuration Datastore ........................... 25 3.4.3. securityLevel ........................................... 25 4. Abstract Service Interfaces ................................. 26 4.1. Dispatcher Primitives ..................................... 26 4.1.1. Generate Outgoing Request or Notification ............... 26 4.1.2. Process Incoming Request or Notification PDU ............ 26 4.1.3. Generate Outgoing Response .............................. 27 Harrington, et. al. Standards Track [Page 2] RFC 2271 SNMPv3 Architecture January 1998 4.1.4. Process Incoming Response PDU ........................... 27 4.1.5. Registering Responsibility for Handling SNMP PDUs ....... 28 4.2. Message Processing Subsystem Primitives ................... 28 4.2.1. Prepare Outgoing SNMP Request or Notification Message ... 28 4.2.2. Prepare an Outgoing SNMP Response Message ............... 29 4.2.3. Prepare Data Elements from an Incoming SNMP Message ..... 29 4.3. Access Control Subsystem Primitives ....................... 30 4.4. Security Subsystem Primitives ............................. 30 4.4.1. Generate a Request or Notification Message .............. 30 4.4.2. Process Incoming Message ................................ 31 4.4.3. Generate a Response Message ............................. 31 4.5. Common Primitives ......................................... 32 4.5.1. Release State Reference Information ..................... 32 4.6. Scenario Diagrams ......................................... 32 4.6.1. Command Generator or Notification Originator ............ 32 4.6.2. Scenario Diagram for a Command Responder Application .... 33 5. Managed Object Definitions for SNMP Management Frameworks ... 35 6. Intellectual Property ....................................... 44 7. Acknowledgements ............................................ 45 8. Security Considerations ..................................... 46 9. References .................................................. 46 10. Editors' Addresses ......................................... 48 A. Guidelines for Model Designers .............................. 49 A.1. Security Model Design Requirements ........................ 49 A.1.1. Threats ................................................. 49 A.1.2. Security Processing ..................................... 50 A.1.3. Validate the security-stamp in a received message ....... 51 A.1.4. Security MIBs ........................................... 51 A.1.5. Cached Security Data .................................... 51 A.2. Message Processing Model Design Requirements .............. 52 A.2.1. Receiving an SNMP Message from the Network .............. 52 A.2.2. Sending an SNMP Message to the Network .................. 52 A.3. Application Design Requirements ........................... 53 A.3.1. Applications that Initiate Messages ..................... 53 A.3.2. Applications that Receive Responses ..................... 54 A.3.3. Applications that Receive Asynchronous Messages ......... 54 A.3.4. Applications that Send Responses ........................ 54 A.4. Access Control Model Design Requirements .................. 55 B. Full Copyright Statement .................................... 56 1. Introduction 1.1. Overview This document defines a vocabulary for describing SNMP Management Frameworks, and an architecture for describing the major portions of SNMP Management Frameworks. Harrington, et. al. Standards Track [Page 3] RFC 2271 SNMPv3 Architecture January 1998 This document does not provide a general introduction to SNMP. Other documents and books can provide a much better introduction to SNMP. Nor does this document provide a history of SNMP. That also can be found in books and other documents. Section 1 describes the purpose, goals, and design decisions of this architecture. Section 2 describes various types of documents which define SNMP Frameworks, and how they fit into this architecture. It also provides a minimal road map to the documents which have previously defined SNMP frameworks. Section 3 details the vocabulary of this architecture and its pieces. This section is important for understanding the remaining sections, and for understanding documents which are written to fit within this architecture. Section 4 describes the primitives used for the abstract service interfaces between the various subsystems, models and applications within this architecture. Section 5 defines a collection of managed objects used to instrument SNMP entities within this architecture. Sections 6, 7, 8, and 9 are administrative in nature. Appendix A contains guidelines for designers of Models which are expected to fit within this architecture. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. SNMP An SNMP management system contains: - several (potentially many) nodes, each with an SNMP entity containing command responder and notification originator applications, which have access to management instrumentation (traditionally called agents); - at least one SNMP entity containing command generator and/or notification receiver applications (traditionally called a manager) and, Harrington, et. al. Standards Track [Page 4] RFC 2271 SNMPv3 Architecture January 1998 - a management protocol, used to convey management information between the SNMP entities. SNMP entities executing command generator and notification receiver applications 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. It is the purpose of this document to define an architecture which can evolve to realize effective management in a variety of configurations and environments. The architecture has been designed to meet the needs of implementations of: - minimal SNMP entities with command responder and/or notification originator applications (traditionally called SNMP agents), - SNMP entities with proxy forwarder applications (traditionally called SNMP proxy agents), - command line driven SNMP entities with command generator and/or notification receiver applications (traditionally called SNMP command line managers), - SNMP entities with command generator and/or notification receiver, plus command responder and/or notification originator applications (traditionally called SNMP mid-level managers or dual-role entities), - SNMP entities with command generator and/or notification receiver and possibly other types of applications for managing a potentially very large number of managed nodes (traditionally called (network) management stations). 1.3. Goals of this Architecture This architecture was driven by the following goals: - Use existing materials as much as possible. It is heavily based on previous work, informally known as SNMPv2u and SNMPv2*. - Address the need for secure SET support, which is considered the most important deficiency in SNMPv1 and SNMPv2c. - Make it possible to move portions of the architecture forward in the standards track, even if consensus has not been reached on all pieces. Harrington, et. al. Standards Track [Page 5] RFC 2271 SNMPv3 Architecture January 1998 - Define an architecture that allows for longevity of the SNMP Frameworks that have been and will be defined. - Keep SNMP as simple as possible. - Make it relatively inexpensive to deploy a minimal conforming implementation. - Make it possible to upgrade portions of SNMP as new approaches become available, without disrupting an entire SNMP framework. - Make it possible to support features required in large networks, but make the expense of supporting a feature directly related to the support of the feature. 1.4. Security Requirements of this Architecture Several of the classical threats to network protocols are applicable to the management problem and therefore would be applicable to any Security Model used in an SNMP Management Framework. Other threats are not applicable to the 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: Modification of Information The modification threat is the danger that some unauthorized SNMP entity may alter in-transit SNMP messages generated on behalf of an authorized principal 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 principal may be attempted by assuming the identity of another principal that has the appropriate authorizations. Message Stream Modification The SNMP 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 Harrington, et. al. Standards Track [Page 6] RFC 2271 SNMPv3 Architecture January 1998 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