As per Relevance of the word framework, we have this rfc below:
Network Working Group D.
Request for Comments: 2571 Cabletron Systems, Inc
Obsoletes: 2271 R.
Category: Standards Track BMC Software, Inc
B.
IBM T. J. Watson
April 1999
An Architecture for
SNMP Management
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document describes an architecture for describing
Management Frameworks. The architecture is designed to be modular
allow the evolution of the SNMP protocol standards over time.
major portions of the architecture are an SNMP engine containing
Message Processing Subsystem, a Security Subsystem and an
Control Subsystem, and possibly multiple SNMP applications
provide specific functional processing of management data
Table of
1. Introduction ................................................ 4
1.1. Overview .................................................. 4
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 ...................................... 9
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
SNMPv3 Working Group Standards Track [Page 1]
RFC 2571 Architecture for SNMP Frameworks April 1999
2.6. Security .................................................. 11
2.7. Access Control ............................................ 12
2.8. Protocol Operations ....................................... 12
2.9. Applications .............................................. 13
2.10. Structure of Management Information ...................... 14
2.11. Textual Conventions ...................................... 14
2.12. Conformance Statements ................................... 14
2.13. Management Information Base Modules ...................... 14
2.13.1. SNMP Instrumentation MIBs .............................. 14
2.14. SNMP Framework Documents ................................. 14
3. Elements of the Architecture ................................ 15
3.1. The Naming of Entities .................................... 16
3.1.1. SNMP engine ............................................. 17
3.1.1.1. snmpEngineID .......................................... 17
3.1.1.2. Dispatcher ............................................ 17
3.1.1.3. Message Processing Subsystem .......................... 18
3.1.1.3.1. Message Processing Model ............................ 18
3.1.1.4. Security Subsystem .................................... 18
3.1.1.4.1. Security Model ...................................... 19
3.1.1.4.2. Security Protocol ................................... 19
3.1.2. Access Control Subsystem ................................ 19
3.1.2.1. Access Control Model .................................. 20
3.1.3. Applications ............................................ 20
3.1.3.1. SNMP Manager .......................................... 20
3.1.3.2. SNMP Agent ............................................ 22
3.2. The Naming of Identities .................................. 23
3.2.1. Principal ............................................... 23
3.2.2. securityName ............................................ 23
3.2.3. Model-dependent security ID ............................. 24
3.3. The Naming of Management Information ...................... 25
3.3.1. An SNMP Context ......................................... 26
3.3.2. contextEngineID ......................................... 26
3.3.3. contextName ............................................. 27
3.3.4. scopedPDU ............................................... 27
3.4. Other Constructs .......................................... 27
3.4.1. maxSizeResponseScopedPDU ................................ 27
3.4.2. Local Configuration Datastore ........................... 27
3.4.3. securityLevel ........................................... 27
4. Abstract Service Interfaces ................................. 28
4.1. Dispatcher Primitives ..................................... 28
4.1.1. Generate Outgoing Request or Notification ............... 28
4.1.2. Process Incoming Request or Notification PDU ............ 29
4.1.3. Generate Outgoing Response .............................. 29
4.1.4. Process Incoming Response PDU ........................... 29
4.1.5. Registering Responsibility for Handling SNMP PDUs ....... 30
4.2. Message Processing Subsystem Primitives ................... 30
4.2.1. Prepare Outgoing SNMP Request or Notification Message ... 31
4.2.2. Prepare an Outgoing SNMP Response Message ............... 31
SNMPv3 Working Group Standards Track [Page 2]
RFC 2571 Architecture for SNMP Frameworks April 1999
4.2.3. Prepare Data Elements from an Incoming SNMP Message ..... 32
4.3. Access Control Subsystem Primitives ....................... 32
4.4. Security Subsystem Primitives ............................. 33
4.4.1. Generate a Request or Notification Message .............. 33
4.4.2. Process Incoming Message ................................ 33
4.4.3. Generate a Response Message ............................. 34
4.5. Common Primitives ......................................... 34
4.5.1. Release State Reference Information ..................... 35
4.6. Scenario Diagrams ......................................... 36
4.6.1. Command Generator or Notification Originator ............ 36
4.6.2. Scenario Diagram for a Command Responder Application .... 37
5. Managed Object Definitions for SNMP Management Frameworks ... 38
6. IANA Considerations ......................................... 48
6.1. Security Models ........................................... 48
6.2. Message Processing Models ................................. 48
6.3. SnmpEngineID Formats ...................................... 49
7. Intellectual Property ....................................... 49
8. Acknowledgements ............................................ 49
9. Security Considerations ..................................... 51
10. References ................................................. 52
11. Editor's Addresses ......................................... 54
A. Guidelines for Model Designers .............................. 55
A.1. Security Model Design Requirements ........................ 55
A.1.1. Threats ................................................. 55
A.1.2. Security Processing ..................................... 56
A.1.3. Validate the security-stamp in a received message ....... 56
A.1.4. Security MIBs ........................................... 57
A.1.5. Cached Security Data .................................... 57
A.2. Message Processing Model Design Requirements .............. 57
A.2.1. Receiving an SNMP Message from the Network .............. 58
A.2.2. Sending an SNMP Message to the Network .................. 58
A.3. Application Design Requirements ........................... 59
A.3.1. Applications that Initiate Messages ..................... 59
A.3.2. Applications that Receive Responses ..................... 59
A.3.3. Applications that Receive Asynchronous Messages ......... 60
A.3.4. Applications that Send Responses ........................ 60
A.4. Access Control Model Design Requirements .................. 60
B. Full Copyright Statement .................................... 62
SNMPv3 Working Group Standards Track [Page 3]
RFC 2571 Architecture for SNMP Frameworks April 1999
1.
1.1.
This document defines a vocabulary for describing SNMP
Frameworks, and an architecture for describing the major portions
SNMP Management Frameworks
This document does not provide a general introduction to SNMP.
documents and books can provide a much better introduction to SNMP
Nor does this document provide a history of SNMP. That also can
found in books and other documents
Section 1 describes the purpose, goals, and design decisions of
architecture
Section 2 describes various types of documents which define (
of) SNMP Frameworks, and how they fit into this architecture. It
provides a minimal road map to the documents which have
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
architecture
Section 4 describes the primitives used for the abstract
interfaces between the various subsystems, models and
within this architecture
Section 5 defines a collection of managed objects used to
SNMP entities within this architecture
Sections 6, 7, 8, 9, 10 and 11 are administrative in nature
Appendix A contains guidelines for designers of Models which
expected to fit within this architecture
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC2119].
1.2.
An SNMP management system contains
- several (potentially many) nodes, each with an SNMP
containing command responder and notification
SNMPv3 Working Group Standards Track [Page 4]
RFC 2571 Architecture for SNMP Frameworks April 1999
applications, which have access to management
(traditionally called agents);
- at least one SNMP entity containing command generator and/
notification receiver applications (traditionally called
manager) and
- a management protocol, used to convey management
between the SNMP entities
SNMP entities executing command generator and notification
applications monitor and control managed elements. Managed
are devices such as hosts, routers, terminal servers, etc., which
monitored and controlled via access to their management information
It is the purpose of this document to define an architecture
can evolve to realize effective management in a variety
configurations and environments. The architecture has been
to meet the needs of implementations of
- minimal SNMP entities with command responder and/
notification originator applications (traditionally called
agents),
- SNMP entities with proxy forwarder applications (
called SNMP proxy agents),
- command line driven SNMP entities with command generator and/
notification receiver applications (traditionally called
command line managers),
- SNMP entities with command generator and/or
receiver, plus command responder and/or notification
applications (traditionally called SNMP mid-level managers
dual-role entities),
- SNMP entities with command generator and/or
receiver and possibly other types of applications for
a potentially very large number of managed nodes (
called (network) management stations).
1.3. Goals of this
This architecture was driven by the following goals
- Use existing materials as much as possible. It is heavily
on previous work, informally known as SNMPv2u and SNMPv2*,
based in turn on SNMPv2p
SNMPv3 Working Group Standards Track [Page 5]
RFC 2571 Architecture for SNMP Frameworks April 1999
- Address the need for secure SET support, which is
the most important deficiency in SNMPv1 and SNMPv2c
- Make it possible to move portions of the architecture
in the standards track, even if consensus has not been
on all pieces
- Define an architecture that allows for longevity of the
Frameworks that have been and will be defined
- Keep SNMP as simple as possible
- Make it relatively inexpensive to deploy a minimal
implementation
- Make it possible to upgrade portions of SNMP as new
become available, without disrupting an entire SNMP framework
- Make it possible to support features required in
networks, but make the expense of supporting a feature
related to the support of the feature
1.4. Security Requirements of this
Several of the classical threats to network protocols are
to the management problem and therefore would be applicable to
Security Model used in an SNMP Management Framework. Other
are not applicable to the management problem. This section
principal threats, secondary threats, and threats which are of
importance
The principal threats against which any Security Model used
this architecture SHOULD provide protection are
Modification of
The modification threat is the danger that some
entity may alter in-transit SNMP messages generated on
of an authorized principal in such a way as to
unauthorized management operations, including falsifying
value of an object
The masquerade threat is the danger that management
not authorized for some principal may be attempted by
the identity of another principal that has the
authorizations
SNMPv3 Working Group Standards Track [Page 6]
RFC 2571 Architecture for SNMP Frameworks April 1999
Secondary threats against which any Security Model used within
architecture SHOULD provide protection are
Message Stream
The SNMP protocol is typically based upon a
transport service which may operate over any
service. The re-ordering, delay or replay of messages can
does occur through the natural operation of many
subnetwork services. The message stream modification threat
the danger that messages may be maliciously re-ordered,
or replayed to an extent which is greater than can
through the natural operation of a subnetwork service, in
to effect unauthorized management operations
The disclosure threat is the danger of eavesdropping on
exchanges between SNMP engines. Protecting against this
may be required as a matter of local policy
There are at least two threats against which a Security Model
this architecture need not protect, since they are deemed to be
lesser importance in this context
Denial of
A Security Model need not attempt to address the broad range
attacks by which service on behalf of authorized users
denied. Indeed, such denial-of-service attacks are in
cases indistinguishable from the type of network failures
which any viable management protocol must cope as a matter
course
Traffic
A Security Model need not attempt to address traffic
attacks. Many traffic patterns are predictable - entities
be managed on a regular basis by a relatively small number
management stations - and therefore there is no
advantage afforded by protecting against traffic analysis
1.5. Design
Various design decisions were made in support of the goals of
architecture and the security requirements
-
An architecture should be defined which identifies
conceptual boundaries between the documents. Subsystems
be defined which describe the abstract services provided
specific portions of an SNMP framework. Abstract
SNMPv3 Working Group Standards Track [Page 7]
RFC 2571 Architecture for SNMP Frameworks April 1999
interfaces, as described by service primitives, define
abstract boundaries between documents, and the
services that are provided by the conceptual subsystems of
SNMP framework
- Self-contained
Elements of procedure plus the MIB objects which are needed
processing for a specific portion of an SNMP framework
be defined in the same document, and as much as possible
should not be referenced in other documents. This allows
to be designed and documented as independent and self-
parts, which is consistent with the general SNMP MIB
approach. As portions of SNMP change over time, the
describing other portions of SNMP are not directly impacted
This modularity allows, for example, Security Models
authentication and privacy mechanisms, and message formats
be upgraded and supplemented as the need arises. The self
contained documents can move along the standards track
different time-lines
This modularity of specification is not meant to be interpreted
imposing any specific requirements on implementation
-
The Security Models in the Security Subsystem SHOULD
against the principal and secondary threats: modification
information, masquerade, message stream modification
disclosure. They do not need to protect against denial
service and traffic analysis
- Remote
The Security and Access Control Subsystems add a whole new
of SNMP configuration parameters. The Security Subsystem
requires frequent changes of secrets at the various
entities. To make this deployable in a large
environment, these SNMP parameters must be
configurable
- Controlled
It is recognized that producers of simple managed devices
to keep the resources used by SNMP to a minimum. At the
time, there is a need for more complex configurations which
spend more resources for SNMP and thus provide
functionality. The design tries to keep the
requirements of these two environments in balance and
the more complex environments to logically extend the
environment
SNMPv3 Working Group Standards Track [Page 8]
RFC 2571 Architecture for SNMP Frameworks April 1999
2. Documentation
The following figure shows the set of documents that fit within
SNMP Architecture
+------------------------- Document Set ----------------------------+
| |
| +----------+ +-----------------+ +----------------+ |
| | Document | | Applicability * | | Coexistence | |
| | Roadmap | | Statement | | & Transition | |
| +----------+ +-----------------+ +----------------+ |
| |
| +---------------------------------------------------------------+ |
| | Message Handling | |
| | +----------------+ +-----------------+ +-----------------+ | |
| | | Transport | | Message | | Security | | |
| | | Mappings | | Processing and | | | | |
| | | | | Dispatcher | | | | |
| | +----------------+ +-----------------+ +-----------------+ | |
| +---------------------------------------------------------------+ |
| |
| +---------------------------------------------------------------+ |
| | PDU Handling | |
| | +----------------+ +-----------------+ +-----------------+ | |
| | | Protocol | | Applications | | Access | | |
| | | Operations | | | | Control | | |
| | +----------------+ +-----------------+ +-----------------+ | |
| +---------------------------------------------------------------+ |
| |
| +---------------------------------------------------------------+ |
| | Information Model | |
| | +--------------+ +--------------+ +---------------+ | |
| | | Structure of | | Textual | | Conformance | | |
| | | Management | | Conventions | | Statements | | |
| | | Information | | | | | | |
| | +--------------+ +--------------+ +---------------+ | |
| +---------------------------------------------------------------+ |
| |
| +---------------------------------------------------------------+ |
| | MIB Modules written in various formats, e.g.: | |
| | +-------------+ +-------------+ +----------+ +----------+ | |
| | | Standard v1 | | Standard v1 | | Historic | | Draft v2 | | |
| | | RFC 1157 | | RFC 1212 | | RFC 14xx | | RFC 19xx | | |
| | | format | | format | | format | | format | | |
| | +-------------+ +-------------+ +----------+ +----------+ | |
| +---------------------------------------------------------------+ |
| |
+-------------------------------------------------------------------+
SNMPv3 Working Group Standards Track [Page 9]
RFC 2571 Architecture for SNMP Frameworks April 1999
Those marked with an asterisk (*) are expected to be written in
future. Each of these documents may be replaced or supplemented
This Architecture document specifically describes how new
fit into the set of documents in the area of Message and
handling
2.1. Document
One or more documents may be written to describe how sets
documents taken together form specific Frameworks. The
of document sets might change over time, so the "road map" should
maintained in a document separate from the standards
themselves
An example of such a roadmap is "Introduction to Version 3 of
Internet-standard Network Management Framework" [RFC2570].
2.2. Applicability
SNMP is used in networks that vary widely in size and complexity,
organizations that vary widely in their requirements of management
Some models will be designed to address specific problems
management, such as message security
One or more documents may be written to describe the environments
which certain versions of SNMP or models within SNMP would
appropriately applied, and those to which a given model might
inappropriately applied
2.3. Coexistence and
The purpose of an evolutionary architecture is to permit new
to replace or supplement existing models. The interactions
models could result in incompatibilities, security "holes", and
undesirable effects
The purpose of Coexistence documents is to detail
anomalies and to describe required and recommended behaviors
resolving the interactions between models within the architecture
Coexistence documents may be prepared separately from
definition documents, to describe and resolve interaction
between a model definition and one or more other model definitions
Additionally, recommendations for transitions between models may
be described, either in a coexistence document or in a
document
SNMPv3 Working Group Standards Track [Page 10]
RFC 2571 Architecture for SNMP Frameworks April 1999
One such coexistance document is [SNMP-COEX], "Coexistence
Version 1, Version 2, and Version 3 of the Internet-standard
Management Framework".
2.4. Transport
SNMP messages are sent over various transports. It is the purpose
Transport Mapping documents to define how the mapping between
and the transport is done
2.5. Message
A Message Processing Model document defines a message format,
is typically identified by a version field in an SNMP message header
The document may also define a MIB module for use in
processing and for instrumentation of version-specific interactions
An SNMP engine includes one or more Message Processing Models,
thus may support sending and receiving multiple versions of
messages
2.6.
Some environments require secure protocol interactions. Security
normally applied at two different stages
- in the transmission/receipt of messages,
- in the processing of the contents of messages
For purposes of this document, "security" refers to message-
security; "access control" refers to the security applied to
operations
Authentication, encryption, and timeliness checking are
functions of message level security
A security document describes a Security Model, the threats
which the model protects, the goals of the Security Model,
protocols which it uses to meet those goals, and it may define a
module to describe the data used during processing, and to allow
remote configuration of message-level security parameters, such
keys
An SNMP engine may support multiple Security Models concurrently
SNMPv3 Working Group Standards Track [Page 11]
RFC 2571 Architecture for SNMP Frameworks April 1999
2.7. Access
During processing, it may be required to control access to
objects for operations
An Access Control Model defines mechanisms to determine
access to a managed object should be allowed. An Access
Model may define a MIB module used during processing and to allow
remote configuration of access control policies
2.8. Protocol
SNMP messages encapsulate an SNMP Protocol Data Unit (PDU).
PDUs define the operations performed by the receiving SNMP engine
It is the purpose of a Protocol Operations document to define
operations of the protocol with respect to the processing of
PDUs. Every PDU belongs to one or more of the PDU classes
below
1) Read Class
The Read Class contains protocol operations that
management information. For example, RFC 1905 defines
following protocol operations for the Read Class: GetRequest
PDU, GetNextRequest-PDU, and GetBulkRequest-PDU
2) Write Class
The Write Class contains protocol operations which attempt
modify management information. For example, RFC 1905
the following protocol operation for the Write Class
SetRequest-PDU
3) Response Class
The Response Class contains protocol operations which are
in response to a previous request. For example, RFC 1905
defines the following for the Response Class: Response-PDU
Report-PDU
4) Notification Class
The Notification Class contains protocol operations which
a notification to a notification receiver application.
example, RFC 1905 defines the following operations for
Notification Class: Trapv2-PDU, InformRequest-PDU
SNMPv3 Working Group Standards Track [Page 12]
RFC 2571 Architecture for SNMP Frameworks April 1999
5) Internal Class
The Internal Class contains protocol operations which
exchanged internally between SNMP engines. For example,
1905 defines the following operations for the Internal Class
Report-PDU
The preceding five classifications are based on the
properties of a PDU. It is also useful to classify PDUs based
whether a response is expected
6) Confirmed Class
The Confirmed Class contains all protocol operations
cause the receiving SNMP engine to send back a response.
example, RFC 1905 defines the following operations for
Confirmed Class: GetRequest-PDU, GetNextRequest-PDU
GetBulkRequest-PDU, SetRequest-PDU, and InformRequest-PDU
7) Unconfirmed Class
The Unconfirmed Class contains all protocol operations
are not acknowledged. For example, RFC 1905 defines
following operations for the Unconfirmed Class: Report-PDU
Trapv2-PDU, and GetResponse-PDU
An application document defines which Protocol Operations
supported by the application
2.9.
An SNMP entity normally includes a number of applications
Applications use the services of an SNMP engine to
specific tasks. They coordinate the processing of
information operations, and may use SNMP messages to communicate
other SNMP entities
Applications documents describe the purpose of an application,
services required of the associated SNMP engine, and the
operations and informational model that the application uses
perform management operations
An application document defines which set of documents are used
specifically define the structure of management information,
conventions, conformance requirements, and operations supported
the application
SNMPv3 Working Group Standards Track [Page 13]
RFC 2571 Architecture for SNMP Frameworks April 1999
2.10. Structure of Management
Management information is viewed as a collection of managed objects
residing in a virtual information store, termed the
Information Base (MIB). Collections of related objects are defined
MIB modules
It is the purpose of a Structure of Management Information
to establish the notation for defining objects, modules, and
elements of managed information
2.11. Textual
When designing a MIB module, it is often useful to define new
similar to those defined in the SMI, but with more precise semantics
or which have special semantics associated with them. These
defined types are termed textual conventions, and may be defined
separate documents, or within a MIB module
2.12. Conformance
It may be useful to define the acceptable lower-bounds
implementation, along with the actual level of
achieved. It is the purpose of the Conformance Statements document
define the notation used for these purposes
2.13. Management Information Base
MIB documents describe collections of managed objects
instrument some aspect of a managed node
2.13.1. SNMP Instrumentation
An SNMP MIB document may define a collection of managed objects
instrument the SNMP protocol itself. In addition, MIB modules may
defined within the documents which describe portions of the
architecture, such as the documents for Message processing Models
Security Models, etc. for the purpose of instrumenting those Models
and for the purpose of allowing remote configuration of the Model
2.14. SNMP Framework
This architecture is designed to allow an orderly evolution
portions of SNMP Frameworks
Throughout the rest of this document, the term "subsystem" refers
an abstract and incomplete specification of a portion of a Framework
that is further refined by a model specification
SNMPv3 Working Group Standards Track [Page 14]
RFC 2571 Architecture for SNMP Frameworks April 1999
A "model" describes a specific design of a subsystem,
additional constraints and rules for conformance to the model.
model is sufficiently detailed to make it possible to implement
specification
An "implementation" is an instantiation of a subsystem, conforming
one or more specific models
SNMP version 1 (SNMPv1), is the original Internet-standard
Management Framework, as described in RFCs 1155, 1157, and 1212.
SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from
SNMPv1 Framework. It is described in STD 58, RFCs 2578, 2579, 2580,
and RFCs 1905-1907. SNMPv2 has no message definition
The Community-based SNMP version 2 (SNMPv2c), is an experimental
Framework which supplements the SNMPv2 Framework, as described in
1901. It adds the SNMPv2c message format, which is similar to
SNMPv1 message format
SNMP version 3 (SNMPv3), is an extensible SNMP Framework
supplements the SNMPv2 Framework, by supporting the following
- a new SNMP message format
- Security for Messages
- Access Control,
- Remote configuration of SNMP parameters
Other SNMP Frameworks, i.e., other configurations of
subsystems, are expected to also be consistent with
architecture
3. Elements of the
This section describes the various elements of the architecture
how they are named. There are three kinds of naming
1) the naming of entities
2) the naming of identities,
3) the naming of management information
SNMPv3 Working Group Standards Track [Page 15]
RFC 2571 Architecture for SNMP Frameworks April 1999
This architecture also defines some names for other constructs
are used in the documentation
3.1. The Naming of
An SNMP entity is an implementation of this architecture. Each
SNMP entity consists of an SNMP engine and one or more
applications
The following figure shows details about an SNMP entity and
components within it
+-------------------------------------------------------------------+
| SNMP entity |
| |
| +-------------------------------------------------------------+ |
| | SNMP engine (identified by snmpEngineID) | |
| | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | | | | | | | | | |
| | | Dispatcher | | Message | | Security | | Access | | |
| | | | | Processing | | Subsystem | | Control | | |
| | | | | Subsystem | | | | Subsystem | | |
| | | | | | | | | | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | |
| +-------------------------------------------------------------+ |
| |
| +-------------------------------------------------------------+ |
| | Application(s) | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Proxy | | |
| | | Generator | | Receiver | | Forwarder | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Other | | |
| | | Responder | | Originator | | | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| +-------------------------------------------------------------+ |
| |
+-------------------------------------------------------------------+
SNMPv3 Working Group Standards Track [Page 16]
RFC 2571 Architecture for SNMP Frameworks April 1999
3.1.1. SNMP
An SNMP engine provides services for sending and receiving messages
authenticating and encrypting messages, and controlling access
managed objects. There is a one-to-one association between an
engine and the SNMP entity which contains it
The engine contains
1) a Dispatcher
2) a Message Processing Subsystem
3) a Security Subsystem,
4) an Access Control Subsystem
3.1.1.1.
Within an administrative domain, an snmpEngineID is the unique
unambiguous identifier of an SNMP engine. Since there is a one-to-
association between SNMP engines and SNMP entities, it also
and unambiguously identifies the SNMP entity within
administrative domain. Note that it is possible for SNMP entities
different administrative domains to have the same value
snmpEngineID. Federation of administrative domains may
assignment of new values
3.1.1.2.
There is only one Dispatcher in an SNMP engine. It allows
concurrent support of multiple versions of SNMP messages in the
engine. It does so by
- sending and receiving SNMP messages to/from the network
- determining the version of an SNMP message and interacting
the corresponding Message Processing Model
- providing an abstract interface to SNMP applications
delivery of a PDU to an application
- providing an abstract interface for SNMP applications
allows them to send a PDU to a remote SNMP entity
SNMPv3 Working Group Standards Track [Page 17]
RFC 2571 Architecture for SNMP Frameworks April 1999
3.1.1.3. Message Processing
The Message Processing Subsystem is responsible for
messages for sending, and extracting data from received messages
The Message Processing Subsystem potentially contains
Message Processing Models as shown in the next figure
* One or more Message Processing Models may be present
+------------------------------------------------------------------+
| |
| Message Processing Subsystem |
| |
| +------------+ +------------+ +------------+ +------------+ |
| | * | | * | | * | | * | |
| | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | |
| | Message | | Message | | Message | | Message | |
| | Processing | | Processing | | Processing | | Processing | |
| | Model | | Model | | Model | | Model | |
| | | | | | | | | |
| +------------+ +------------+ +------------+ +------------+ |
| |
+------------------------------------------------------------------+
3.1.1.3.1. Message Processing
Each Message Processing Model defines the format of a
version of an SNMP message and coordinates the preparation
extraction of each such version-specific message format
3.1.1.4. Security
The Security Subsystem provides security services such as
authentication and privacy of messages and potentially
multiple Security Models as shown in the following
SNMPv3 Working Group Standards Track [Page 18]
RFC 2571 Architecture for SNMP Frameworks April 1999
* One or more Security Models may be present
+------------------------------------------------------------------+
| |
| Security Subsystem |
| |
| +----------------+ +-----------------+ +-------------------+ |
| | * | | * | | * | |
| | User-Based | | Other | | Other | |
| | Security | | Security | | Security | |
| | Model | | Model | | Model | |
| | | | | | | |
| +----------------+ +-----------------+ +-------------------+ |
| |
+------------------------------------------------------------------+
3.1.1.4.1. Security
A Security Model specifies the threats against which it protects,
goals of its services, and the security protocols used to
security services such as authentication and privacy
3.1.1.4.2. Security
A Security Protocol specifies the mechanisms, procedures, and
objects used to provide a security service such as authentication
privacy
3.1.2. Access Control
The Access Control Subsystem provides authorization services by
of one or more (*) Access Control Models
+------------------------------------------------------------------+
| |
| Access Control Subsystem |
| |
| +---------------+ +-----------------+ +------------------+ |
| | * | | * | | * | |
| | View-Based | | Other | | Other | |
| | Access | | Access | | Access | |
| | Control | | Control | | Control | |
| | Model | | Model | | Model | |
| | | | | | | |
| +---------------+ +-----------------+ +------------------+ |
| |
+------------------------------------------------------------------+
SNMPv3 Working Group Standards Track [Page 19]
RFC 2571 Architecture for SNMP Frameworks April 1999
3.1.2.1. Access Control
An Access Control Model defines a particular access decision
in order to support decisions regarding access rights
3.1.3.
There are several types of applications, including
- command generators, which monitor and manipulate
data
- command responders, which provide access to management data
- notification originators, which initiate asynchronous messages
- notification receivers, which process asynchronous messages
- proxy forwarders, which forward messages between entities
These applications make use of the services provided by the
engine
3.1.3.1. SNMP
An SNMP entity containing one or more command generator and/
notification receiver applications (along with their associated
engine) has traditionally been called an SNMP manager
SNMPv3 Working Group Standards Track [Page 20]
RFC 2571 Architecture for SNMP Frameworks April 1999
* One or more models may be present
(traditional SNMP manager
+-------------------------------------------------------------------+
| +--------------+ +--------------+ +--------------+ SNMP entity |
| | NOTIFICATION | | NOTIFICATION | | COMMAND | |
| | ORIGINATOR | | RECEIVER | | GENERATOR | |
| | applications | | applications | | applications | |
| +--------------+ +--------------+ +--------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------+--------+-----------------+ |
| ^ |
| | +---------------------+ +----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | |
| | | | | +------------+ | | | Other | | |
| | | | | +------------+ | | | Security | | |
| | | | +->| v2cMP * |<--->| | Model | | |
| | Message | | | +------------+ | | +------------+ | |
| | Dispatcher <--------->+ | | | |
| | | | | +------------+ | | +------------+ | |
| | | | +->| v3MP * |<--->| | User-based | | |
| | Transport | | | +------------+ | | | Security | | |
| | Mapping | | | +------------+ | | | Model | | |
| | (e.g RFC1906) | | +->| otherMP * |<--->| +------------+ | |
| +-------------------+ | +------------+ | | | |
| ^ +---------------------+ +----------------+ |
| | |
| v |
+-------------------------------------------------------------------+
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+
^ ^ ^
| | |
v v
+------------------------------+
| Network |
+------------------------------+
SNMPv3 Working Group Standards Track [Page 21]
RFC 2571 Architecture for SNMP Frameworks April 1999
3.1.3.2. SNMP
An SNMP entity containing one or more command responder and/
notification originator applications (along with their
SNMP engine) has traditionally been called an SNMP agent
+------------------------------+
| Network |
+------------------------------+
^ ^ ^
| | |
v v
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+ (traditional SNMP agent
+-------------------------------------------------------------------+
| ^ |
| | +---------------------+ +----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | Transport | | +->| v1MP * |<--->| +------------+ | |
| | Mapping | | | +------------+ | | | Other | | |
| | (e.g. RFC1906) | | | +------------+ | | | Security | | |
| | | | +->| v2cMP * |<--->| | Model | | |
| | Message | | | +------------+ | | +------------+ | |
| | Dispatcher <--------->| +------------+ | | +------------+ | |
| | | | +->| v3MP * |<--->| | User-based | | |
| | | | | +------------+ | | | Security | | |
| | PDU Dispatcher | | | +------------+ | | | Model | | |
| +-------------------+ | +->| otherMP * |<--->| +------------+ | |
| ^ | +------------+ | | | |
| | +---------------------+ +----------------+ |
| v |
| +-------+-------------------------+---------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------------+ +---------+ +--------------+ +-------------+ |
| | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | |
| | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |
| | application | | | | applications | | application | |
| +-------------+ +---------+ +--------------+ +-------------+ |
| ^ ^ |
| | | |
| v v |
| +----------------------------------------------+ |
| | MIB instrumentation | SNMP entity |
+-------------------------------------------------------------------+
SNMPv3 Working Group Standards Track [Page 22]
RFC 2571 Architecture for SNMP Frameworks April 1999
3.2. The Naming of
^
|
|
+----------------------------|-------------+
| SNMP engine v |
| +--------------+ |
| | | |
| +-----------------| securityName |---+ |
| | Security Model | | | |
| | +--------------+ | |
| | ^ | |
| | | | |
| | v | |
| | +------------------------------+ | |
| | | | | |
| | | Model | | |
| | | Dependent | | |
| | | Security ID | | |
| | | | | |
| | +------------------------------+ | |
| | ^ | |
| | | | |
| +-------------------------|----------+ |
| | |
| | |
+----------------------------|-------------+
|
3.2.1.
A principal is the "who" on whose behalf services are provided
processing takes place
A principal can be, among other things, an individual acting in
particular role; a set of individuals, with each acting in
particular role; an application or a set of applications;
combinations thereof
3.2.2.
A securityName is a human readable string representing a principal
It has a model-independent format, and can be used outside
particular Security Model
SNMPv3 Working Group Standards Track [Page 23]
RFC 2571 Architecture for SNMP Frameworks April 1999
3.2.3. Model-dependent security
A model-dependent security ID is the model-specific representation
a securityName within a particular Security Model
Model-dependent security IDs may or may not be human readable,
have a model-dependent syntax. Examples include community names,
user names
The transformation of model-dependent security IDs into
and vice versa is the responsibility of the relevant Security Model
SNMPv3 Working Group Standards Track [Page 24]
RFC 2571 Architecture for SNMP Frameworks April 1999
3.3. The Naming of Management
Management information resides at an SNMP entity where a
Responder Application has local access to potentially
contexts. This application uses a contextEngineID equal to
snmpEngineID of its associated SNMP engine
+-----------------------------------------------------------------+
| SNMP entity (identified by snmpEngineID, example: abcd) |
| |
| +------------------------------------------------------------+ |
| | SNMP engine (identified by snmpEngineID) | |
| | | |
| | +-------------+ +------------+ +-----------+ +-----------+ | |
| | | | | | | | | | | |
| | | Dispatcher | | Message | | Security | | Access | | |
| | | | | Processing | | Subsystem | | Control | | |
| | | | | Subsystem | | | | Subsystem | | |
| | | | | | | | | | | |
| | +-------------+ +------------+ +-----------+ +-----------+ | |
| | | |
| +------------------------------------------------------------+ |
| |
| +------------------------------------------------------------+ |
| | Command Responder Application | |
| | (contextEngineID, example: abcd) | |
| | | |
| | example contextNames: | |
| | | |
| | "bridge1" "bridge2" "" (default) | |
| | --------- --------- ------------ | |
| | | | | | |
| +------|------------------|-------------------|--------------+ |
| | | | |
| +------|------------------|-------------------|--------------+ |
| | MIB | instrumentation | | | |
| | +---v------------+ +---v------------+ +----v-----------+ | |
| | | context | | context | | context | | |
| | | | | | | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | | bridge MIB | | | | bridge MIB | | | | some MIB | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | | | | | | | |
| | | | | | | +------------+ | | |
| | | | | | | | other MIB | | | |
| | | | | | | +------------+ | | |
| | | | | | | | | |
+-----------------------------------------------------------------+
SNMPv3 Working Group Standards Track [Page 25]
RFC 2571 Architecture for SNMP Frameworks April 1999
3.3.1. An SNMP
An SNMP context, or just "context" for short, is a collection
management information accessible by an SNMP entity. An item
management information may exist in more than one context. An
entity potentially has access to many contexts
Typically, there are many instances of each managed object
within a management domain. For simplicity, the method
identifying instances specified by the MIB module does not allow
instance to be distinguished amongst the set of all instances
a management domain; rather, it allows each instance to be
only within some scope or "context", where there are multiple
contexts within the management domain. Often, a context is
physical device, or perhaps, a logical device, although a context
also encompass multiple devices, or a subset of a single device,
even a subset of multiple devices, but a context is always defined
a subset of a single SNMP entity. Thus, in order to identify
individual item of management information within the
domain, its contextName and contextEngineID must be identified
addition to its object type and its instance
For example, the managed object type ifDescr [RFC2233], is defined
the description of a network interface. To identify the
of device-X's first network interface, four pieces of information
needed: the snmpEngineID of the SNMP entity which provides access
the management information at device-X, the contextName (device-X),
the managed object type (ifDescr), and the instance ("1").
Each context has (at least) one unique identification within
management domain. The same item of management information can
in multiple contexts. An item of management information may
multiple unique identifications. This occurs when an item
management information exists in multiple contexts, and this
occurs when a context has multiple unique identifications
The combination of a contextEngineID and a contextName
identifies a context within an administrative domain; note that
may be multiple unique combinations of contextEngineID
contextName that unambiguously identify the same context
3.3.2.
Within an administrative domain, a contextEngineID
identifies an SNMP entity that may realize an instance of a
with a particular contextName
SNMPv3 Working Group Standards Track [Page 26]
RFC 2571 Architecture for SNMP Frameworks April 1999
3.3.3.
A contextName is used to name a context. Each contextName MUST
unique within an SNMP entity
3.3.4.
A scopedPDU is a block of data containing a contextEngineID,
contextName, and a PDU
The PDU is an SNMP Protocol Data Unit containing information named
the context which is unambiguously identified within
administrative domain by the combination of the contextEngineID
the contextName. See, for example, RFC1905 for more information
SNMP PDUs
3.4. Other
3.4.1.
The maxSizeResponseScopedPDU is the maximum size of a scopedPDU
a PDU's sender would be willing to accept. Note that the size of
scopedPDU does not include the size of the SNMP message header
3.4.2. Local Configuration
The subsystems, models, and applications within an SNMP entity
need to retain their own sets of configuration information
Portions of the configuration information may be accessible
managed objects
The collection of these sets of information is referred to as
entity's Local Configuration Datastore (LCD).
3.4.3.
This architecture recognizes three levels of security
- without authentication and without privacy (noAuthNoPriv
- with authentication but without privacy (authNoPriv
- with authentication and with privacy (authPriv
These three values are ordered such that noAuthNoPriv is less
authNoPriv and authNoPriv is less than authPriv
SNMPv3 Working Group Standards Track [Page 27]
RFC 2571 Architecture for SNMP Frameworks April 1999
Every message has an associated securityLevel. All
(Message Processing, Security, Access Control) and applications
REQUIRED to either supply a value of securityLevel or to abide by
supplied value of securityLevel while processing the message and
contents
4. Abstract Service
Abstract service interfaces have been defined to describe
conceptual interfaces between the various subsystems within an
entity. The abstract service interfaces are intended to help
the externally observable behavior of SNMP entities, and are
intended to constrain the structure or organization
implementations in any way. Most specifically, they should not
interpreted as APIs or as requirements statements for APIs
These abstract service interfaces are defined by a set of
that define the services provided and the abstract data elements
are to be passed when the services are invoked. This section
the primitives that have been defined for the various subsystems
4.1. Dispatcher
The Dispatcher typically provides services to the SNMP
via its PDU Dispatcher. This section describes the
provided by the PDU Dispatcher
4.1.1. Generate Outgoing Request or
The PDU Dispatcher provides the following primitive for
application to send an SNMP Request or Notification to another
entity
statusInformation = -- sendPduHandle if
