draft-ietf-snmpv3-next-gen-arch-00.txt   draft-ietf-snmpv3-next-gen-arch-01.txt 
skipping to change at page 10, line ? skipping to change at page 10, line ?
Architecture for the Next Generation Architecture for the Next Generation
Simple Network Management Protocol (SNMPng) Simple Network Management Protocol (SNMPng)
D. Harrington D. Harrington
Cabletron Systems, Inc. Cabletron Systems, Inc.
dbh@cabletron.com dbh@cabletron.com
B. Wijnen B. Wijnen
IBM T.J. Watson Research IBM T.J. Watson Research
wijnen@vnet.ibm.com wijnen@vnet.ibm.com
<draft-ietf-snmpv3-next-gen-arch-00.txt> <draft-ietf-snmpv3-next-gen-arch-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas,
its working groups. Note that other groups may also distribute working and its working groups. Note that other groups may also distribute
documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.'' or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Abstract Abstract
This document describes an architecture for the Next-Generation of This document describes an architecture for the Next-Generation of
the Simple Network Management Protocol (SNMPng). The architecture the Simple Network Management Protocol (SNMPng). The architecture
is designed to be modular to allow the evolution of the protocol is designed to be modular to allow the evolution of the protocol
over time. The major portions of the architecture are 1) a message over time. The major portions of the architecture are 1) a message
processing and control framework, 2) a security framework, and processing and control subsystem, 2) a security subsystem, and
3) a local processing framework. 3) a local processing subsystem.
Harrington/Wijnen Expires October 1977 [Page 1] Harrington/Wijnen Expires November 1977 [Page 1]
\ \
0. Change Log 0. Change Log
[version 1.8] [version 2.2]
1. changed filename to internet-drafts assigned name . fix PDU back to scopedPDU where appropriate
[version 1.7] . MIB definitions contained some terms that need defining (MMS, etc)
1. Truncate lines to 72 (more to be done) look them up and add to "abstract data elements"
2. Prepare for pagination . fixes suggested by Bob Moore:
3. Added references section contextID identifies engine not agent
4. Let table of contents be generated . fixed intro to allow manager-to-manager "conveyance"
[version 1.6] . For interfaces which pass both the securityCookie and the security
1. added abstract model, removed the securityModel, since it can be derived from the
2. davel's comments securityCookie.
3. bert's comments . eliminated requirement of group to <users> mapping, since movement
4. reverted to QoS since it was less work. of traps to application eliminates the need for this mapping.
5. completed section 8 . eliminated "end-user"; substitutes security entity.
6. Security Considerations, etc . removed discussion of traps as part of LPM, replaced with discussion
7. table of contents of notifications sent/received by application.
[version 1.5] . separated architectural textual conventions from MPC-specific MIB
1. add goals/constraints from issues list (put TCs in architecture doc, objects in MPC doc)
2. add discussion of proxy as App . changed security entity to securityIdentity
3. move ngMIB to arch from LPM doc [version 2.1]
4. define LCD versus SCD . changed Quality of Service (QoS) to Level of Security (LoS)
5. copy Bert's 2.x that apply to framework . changed QoS field to msgFlags (includes LoS plus reportFlag)
6. modify Message definition to better match Bert's ASN.1 . modified "Abstract Functionality"
[version 1.4] . expanded subsystem descriptions to include introductory text on
1. modified intro SMI, textual conventions, conformance, protocol operations, SNMP MIB,
2. added section on design principles/goals coexistence, etc.
3. added section on message contents and service interfaces . added reference citations as needed
4. defined LP-F versus LP-M . replaced "interface" with "abstract data elements to transfer data"
5. changed QoS to msgFlags to avoid the dreaded "interface = API" assumption.
[version 1.3] . modified scopedPDU text to permit a snmpv1 community-scoped PDU,
1. modified title from Security and Framework Evolution to including one which uses the community to control proxy
Next Generation i.e snmpv3 uses engineID/contextName for naming scope
2. expanded section 4 - architectural design goals snmpv1 uses community alone for naming scope
3. replaced all acronyms with the new acronyms a snmpv1 MPC can "scope" the snmpv1 PDU by using the community as the
the naming scope in the interface between MPC and LPM or Apps
. rewrote (and renamed) "Abstract Data Elements of the Architecture"
. added a definition for an abstract "engineID
. modified naming scope and scopedPDU to be more generic
. removed the MIB definitions
[version 2.0]
. separated architecture from Message Processing and Control
model for SNMPv3
. changed filename to internet-drafts assigned name
. changed contextID to contextEngineID
. changed sub-frameworks to subsystems
. changed Model to model
. changed scopedPDU to PDU
. expanded acronyms
. removed reference citations to arch, mpc, and usec drafts
Harrington/Wijnen Expires October 1977 [Page 2] Harrington/Wijnen Expires November 1977 [Page 2]
\
Harrington/Wijnen Expires November 1977 [Page 3]
\ \
1. Introduction 1. Introduction
A management system contains: several (potentially many) nodes, each A management system contains: several (potentially many) nodes, each
with a processing entity, termed an agent, which has access to with a processing entity, termed an agent, which has access to
management instrumentation; at least one management station; and, a management instrumentation; at least one management station; and, a
management protocol, used to convey management information between the management protocol, used to convey management information between the
agents and management stations. agents and management stations, or between management stations and
other management stations.
Management stations execute management applications which monitor and Management stations execute management applications which monitor and
control managed elements. Managed elements are devices such as hosts, control managed elements. Managed elements are devices such as hosts,
routers, terminal servers, etc., which are monitored and controlled via routers, terminal servers, etc., which are monitored and controlled via
access to their management information. access to their management information.
Operations of the protocol are carried out under an administrative Operations of the protocol are carried out under an administrative
framework which defines minimum policies for mechanisms which provide framework which defines minimum policies for mechanisms which provide
message-level security, access control for managed objects, and message-level security, access control for managed objects, and
interaction between the protocol engine and the applications which use interaction between the protocol engine and the applications which use
the services of the engine. the services of the engine.
It is the purpose of this document to define a framework which can It is the purpose of this document to define an architecture which
evolve to realize effective SNMP network management in a variety of can evolve to realize effective network management in a variety
configurations and environments. The framework has been designed to of configurations and environments. The architecture has been
meet the needs of implementors of both minimal agents and full-function designed to meet the needs of implementors of both minimal agents
network enterprise management stations. and full-function network enterprise management stations.
1.1. A Note on Terminology 1.1. A Note on Terminology
For the purpose of exposition, the original Internet-standard Network SNMP version 1 (SNMPv1), is the original Internet-standard Network
Management Framework, as described in RFCs 1155, 1157, and 1212, is Management Framework, as described in RFCs 1155, 1157, and 1212.
termed the SNMP version 1 framework (SNMPv1). A partially-updated
Internet-standard Network Management framework , as described
in RFCs 1902-1908, is termed the SNMP version 2 framework (SNMPv2).
The current framework, meant to complement the SNMPv2 framework,
is termed the SNMP next generation framework (SNMPng).
SNMPng provides a framework for the evolution of multiple SNMP version 2 (SNMPv2) is an updated design of portions of SNMPv1,
(sub-)frameworks. as described in RFCs 1902-1908.
Throughout the rest of this document, the term Framework will SNMP next generation (SNMPng) is an architecture designed to allow
an orderly evolution of SNMP subsystems. This document describes the
SNMPng architecture.
Throughout the rest of this document, the term subsystem will
refer to an abstract and incomplete specification of a portion of refer to an abstract and incomplete specification of a portion of
SNMPng, that will be further refined by a Model specification. SNMPng, that will be further refined by a model specification.
A Model describes a specific design of a Framework, defining A model describes a specific design of a subsystem, defining
additional constraints and rules for conformance to the model. additional constraints and rules for conformance to the model.
A model is sufficiently detailed a design to make it possible A model is sufficiently detailed a design to make it possible
to implement the specification. to implement the specification.
A Implementation is an instantiation of a Framework, conforming to a A Implementation is an instantiation of a subsystem, conforming to a
specific Model. specific model.
Harrington/Wijnen Expires October 1977 [Page 3] Harrington/Wijnen Expires November 1977 [Page 4]
\ \
2. Overview 2. Overview
The architecture presented here emphasizes the use of modularity to The architecture presented here emphasizes the use of modularity to
allow the evolution of portions of SNMP without requiring a redesign of allow the evolution of portions of SNMP without requiring a redesign
the general architecture of SNMP. of the general architecture of SNMP.
The processing of SNMP messages is procedural - there are specific The processing of SNMP messages is procedural - there are specific
steps which must be accomplished in specific order of processing. steps which must be accomplished in specific order of processing.
These steps fall into general categories of similar functionality. These steps fall into general categories of similar functionality.
This document will describe major abstractions of functionality This document will describe major abstractions of functionality
required of an SNMP engine, and the abstract interactions between required of an SNMP engine, and the abstract interactions between
these major categories. these major categories of functionality.
This document will describe how this architecture is meant to allow This document will describe how this architecture is meant to allow
modules of functionality corresponding to these abstract categories to modules of functionality corresponding to these abstract categories to
be designed to allow the evolution of the whole by modifying discrete be designed to allow the evolution of the whole by modifying discrete
modules within the architecture. modules within the architecture.
Harrington/Wijnen Expires October 1977 [Page 4] Harrington/Wijnen Expires November 1977 [Page 5]
\ \
3. An Evolutionary Architecture - Design Goals 3. An Evolutionary Architecture - Design Goals
The goals of the architectural design are to use encapsulation, The goals of the architectural design are to use encapsulation,
cohesion, hierarchical rules, and loose coupling to reduce complexity cohesion, hierarchical rules, and loose coupling to reduce complexity
of design and make the evolution of portions of the architecture of design and make the evolution of portions of the architecture
possible. possible.
3.1. Encapsulation 3.1. Encapsulation
skipping to change at page 10, line ? skipping to change at page 10, line ?
Encapsulation describes the practice of hiding the details that are Encapsulation describes the practice of hiding the details that are
used internal to a process. Some data is required for a given used internal to a process. Some data is required for a given
procedure, but isn't needed by any other part of the process. procedure, but isn't needed by any other part of the process.
In networking, the concept of a layered stack reflects this approach. In networking, the concept of a layered stack reflects this approach.
The transport layer contains data specific to its processing; the data The transport layer contains data specific to its processing; the data
is not visible to the other layers. In programming this is reflected is not visible to the other layers. In programming this is reflected
in language elements such as "file static" variables in C, and in language elements such as "file static" variables in C, and
"private" in C++, etc. "private" in C++, etc.
In the SNMPng architecture, all data used for processing only within a In the SNMPng architecture, all data used for processing only within
functional portion of the architecture should have its visibility a functional portion of the architecture should have its visibility
restricted to that portion if possible. The data should be accessed restricted to that portion if possible. The data should be accessed
only by that functionality defined with the data. No reference to the only by that functionality defined with the data. No reference to the
data should be made from outside the functional portion of the data should be made from outside the functional portion of the
architecture, except through predefined public interfaces. architecture, except through predefined public interfaces.
3.2. Cohesion 3.2. Cohesion
Similar functions can be grouped together and their differences Similar functions can be grouped together and their differences
ignored, so they can be dealt with as a single entity. It is important ignored, so they can be dealt with as a single entity. It is important
that the functions which are grouped together are actually similar. that the functions which are grouped together are actually similar.
skipping to change at page 10, line ? skipping to change at page 10, line ?
definitions for those data elements that are used only by those definitions for those data elements that are used only by those
security functions. For example, a MIB with authentication keys is security functions. For example, a MIB with authentication keys is
used only by authentication functions; they should be defined together. used only by authentication functions; they should be defined together.
3.3. Hierarchical Rules 3.3. Hierarchical Rules
Functionality can be grouped into hierarchies where each element in the Functionality can be grouped into hierarchies where each element in the
hierarchy receives general characteristics from its direct superior, hierarchy receives general characteristics from its direct superior,
and passes on those characteristics to each of its direct subordinates. and passes on those characteristics to each of its direct subordinates.
Harrington/Wijnen Expires October 1977 [Page 5] The SNMPng architecture uses the hierarchical approach by defining
Harrington/Wijnen Expires November 1977 [Page 6]
\ \
The SNMPng architecture uses the hierarchical approach by defining subsystems, which specify the general rules of a portion of the system,
frameworks, which specify the general rules of a portion of the system,
models which define the specific rules to be followed by an models which define the specific rules to be followed by an
implementation of the portion of the system, and implementations which implementation of the portion of the system, and implementations which
encode those rules into reality for a portion of the system. encode those rules into reality for a portion of the system.
It is expected that within portions of the system, hierarchical It is expected that within portions of the system, hierarchical
relationships will be used to compartmentalize, or modularize, the relationships will be used to compartmentalize, or modularize, the
implementation of specific functionality. For example, it is expected implementation of specific functionality. For example, it is expected
that within the security portion of the system, authentication and that within the security portion of the system, authentication and
privacy will probably be contained in separate modules, and that privacy will probably be contained in separate modules, and that
multiple authentication and privacy mechanisms will be supported by multiple authentication and privacy mechanisms will be supported by
skipping to change at page 10, line ? skipping to change at page 10, line ?
To make it possible to evolve the architecture by replacing only part To make it possible to evolve the architecture by replacing only part
of the system, or by supplementing existing portions with alternate of the system, or by supplementing existing portions with alternate
mechanisms for similar functionality, without obsoleting the complete mechanisms for similar functionality, without obsoleting the complete
system, it is necessary to limit the coupling of the parts. system, it is necessary to limit the coupling of the parts.
Encapsulation and cohesion help to reduce coupling by limiting the Encapsulation and cohesion help to reduce coupling by limiting the
visibility of those parts that are only needed within portions of a visibility of those parts that are only needed within portions of a
system. Another mechanism is to constrain the nature of interactions system. Another mechanism is to constrain the nature of interactions
between various parts of the system. between various parts of the system.
This can be done by defining fixed, generic, flexible, interfaces This can be done by defining fixed, generic, flexible interfaces
between the parts of the system. The concept of plug-and-play hardware for transferring data between the parts of the system. The concept of
components is based on that type of interface between the hardware plug-and-play hardware components is based on that type of interface
component and system into which it will be "plugged." between the hardware component and system into which it will be
"plugged."
SNMPng has chosen this approach so individual portions of the system SNMPng has chosen this approach so individual portions of the system
can be upgraded over time, while keeping the overall system intact. can be upgraded over time, while keeping the overall system intact.
Cross-references between document describing the subsystems should be
limited to Framework or Model defined interfaces wherever possible. To avoid specifying fixed interfaces, which would constrain a vendor's
choice of implementation strategies, SNMPng defines a set of abstract
data elements to be used for (conceptually) transferring data between
subsystems in documents which describe subsystem or model interactions.
Documents 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 Loose coupling works well with the IETF standards process. If we
separate message-handling from security and from local processing, separate message-handling from security and from local processing,
Harrington/Wijnen Expires November 1977 [Page 7]
\
then the separate portions of the system can move through the standards 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 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 standard. Security models may be able to be re-opened for discussion
due to patents, new research, export laws, etc., as is clearly expected due to patents, new research, export laws, etc., as is clearly expected
by the WG, without needing to reopen the documents which detail the by the WG, without needing to reopen the documents which detail the
message format or the local processing of PDUs. Thus, the standards message format or the local processing of PDUs. Thus, the standards
track status of related, but independent, documents is not affected. track status of related, but independent, documents is not affected.
Harrington/Wijnen Expires October 1977 [Page 6] Harrington/Wijnen Expires November 1977 [Page 8]
\ \
4.0. Abstract Functionality 4. Abstract Functionality
The architecture described here is composed of four "major" frameworks, The architecture described here is composed of four subsystems, each
each capable of being defined as different models, and which may be capable of being defined as different models which may be replaced
implemented as modules which can be replaced or supplemented as the or supplemented as the growing needs of network management require.
growing needs of network management require.
The major frameworks are a Message Processing and Control Framework, a The subsystems are a Message Processing and Control subsystem, a
Security Framework, a Local Processing Framework, and Applications. Security subsystem, a Local Processing subsystem, and an Application
Interfaces between the major frameworks are deliberately abstract and Support subsystem.
fixed. An SNMPng engine is comprised of implementations of a
Message Processing and Control Framework, a Security Framework, and The term "engine" refers to a combination of Message Processing and
a Local Processing Framework. Applications are external to the engine. Control subsystem(s), Security subsystem(s), and Local Processing
subsystem(s). Applications are external processes which use the engine
to send or receive SNMP messages, or otherwise use the services of the
SNMP engine, to accomplish their tasks.
4.1. Message Processing and Control 4.1. Message Processing and Control
An SNMP engine interacts with the network and with applications through The Message Processing and Control subsystem of an SNMP engine
the Message Processing and Control Framework. interacts with the network using SNMP messages, and interacts with
applications using data elements defined by the Message Processing
and Control model, within the constraints of the Architecture.
Messages being sent to, or received from, the network use a format A Message Processing and Control model has the responsibility for
defined by the SNMP protocol. The possible contents, and their coordinating the sending and receiving of SNMP messages, and for
format, are also defined by the SNMP protocol. coordinating the interaction with other subsystems to acquire the
desired services for the processing of a message.
4.1.1. Transport Mappings
SNMP messages are sent to, or received from, the network using a
transport mechanism. It is the purpose of Transport Mapping documents
to define how SNMP maps onto transport domains.
A Message Processing and Control model defines which Transport Mappings
documents are supported by the model.
4.1.2. SNMP-Based Message Formats
SNMP messages sent to, or received from, the network use a format
defined by the Message Processing and Control model.
4.1.3. Application-Based Message Formats
Messages being sent to, or received from, applications use formats Messages being sent to, or received from, applications use formats
which may be protocol-defined or may be implementation-specific. The which are defined by the Message Processing and Control Model.
possible contents, and their format, may be protocol-defined or Note that these are not SNMP messages, but are abstract data elements
implementation-specific. used to transfer data between the Message Processing and Control
subsystem and an Application Support subsystem.
The processing of messages must be controlled to ensure that applicable 4.1.4. Protocol Instrumentation
rules are followed during the processing. Some messages, such as an
SNMP Get-Request received from the network for objects managed by this
engine, can be processed directly by the engine; other messages must be
passed to external processes, such as a remote SNMP engine or an
application. Some messages require security; others don't. Some engines
support multiple versions of SNMP messages and/or PDU formats.
The engine must control the order and the combinations of options used Harrington/Wijnen Expires November 1977 [Page 9]
in processing and generating messages. \
It is the purpose of a Management Information Base for SNMP document
to define managed objects which describe the behavior of an SNMP
engine.
A Message Processing and Control model defines which SNMP MIB Module
documents are supported to instrument the model.
4.2. Security 4.2. Security
Some environments require secure protocol interactions. Security is Some environments require secure protocol interactions. Security is
normally applied at two different stages - in the transmission/receipt normally applied at two different stages - in the transmission/receipt
of messages, and in the processing of the contents of messages. For of messages, and in the processing of the contents of messages. For
purposes of this document, "security" refers to message-level security; purposes of this document, "security" refers to message-level security;
"access control" refers to the security applied to protocol operations. "access control" refers to the security applied to protocol operations.
Authentication, encryption, and timeliness checking are common Authentication, encryption, and timeliness checking are common
functions of message level security. functions of message level security.
Harrington/Wijnen Expires October 1977 [Page 7]
\
4.3. Local Processing 4.3. Local Processing
Local Processing deals with the contents of messages. It interacts with Local Processing deals with the contents of messages, called the PDU,
the underlying operating system to access the instrumentation which is providing access to instrumentation and applying access control
represented as managed objects in SNMP. according the rules of the Local Processing model being used.
An overview of management information and processing operations is
provided here, but a Local Processing 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 model.
During local processing, it may be required to control access to During local processing, it may be required to control access to
certain instrumentation for certain operations. The enforcement of certain instrumentation for certain operations. The enforcement of
access rights requires the means to identify the access allowed for access rights requires the means to identify the access allowed for
the entity on whose behalf a request is generated. the securityIdentity on whose behalf a request is generated. A Local
Processing model defines which set of documents are used to define
4.4. Applications the mechanisms to realize access control within that model.
Applications are processes which interact with the SNMP engine using
messages that may use formats defined by a protocol, or that may use
implementation-specific formats.
Applications are developed to achieve certain goals. They use the SNMP
engine to achieve their goals, but their purpose is outside the scope
of the SNMP protocol definitions.
For example, management stations execute applications which monitor
and control managed elements. A proxy application may forward a
message from one SNMP engine to another (an snmp proxy), or convert
a message from one SNMP format to another (also an snmp proxy), or
from SNMP to another protocol ( a foreign proxy). The purpose and
design of applications are beyond the scope of the SNMPng engine
architecture.
4.5. Definition of SNMPng acronyms and terms:
MPC-F - Message Processing and Control Framework 4.3.1. Structure of Management Information
MPC-M - Message Processing and Control Model
MPC-I - Message Processing and Control Implementation
SF-F - Security Framework Management information is viewed as a collection of managed objects,
SF-M - Security Framework Model residing in a virtual information store, termed the Management
SF-I - Security Framework Implementation Information Base (MIB). Collections of related objects are defined
in MIB modules.
LP-F - Local Processing Framework It is the purpose of a Structure of Management Information
LP-M - Local Processing Model document to establish the syntax for defining objects, modules, and
LP-I - Local Processing Implementation other elements of managed information.
LCD - Local Configuration Datastore A Local Processing model defines which SMI documents are supported
SCD - Security Configuration Datastore by the model.
Harrington/Wijnen Expires October 1977 [Page 8]
\ \
5. Elements of the Framework 4.3.2. Textual Conventions
This section contains definitions of terms used in the interfaces When designing a MIB module, it is often useful to define new types
between Frameworks 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.
5.1. Groups A Local Processing model defines which Textual Conventions documents
are supported by the model.
A Group identifies a set of zero or more security entities on whose 4.3.3. Conformance Statements
behalf SNMP messages are being processed.
5.2. Quality of Service 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.
Messages may require different levels of security. The term used to A Local Processing model defines which Conformance Statement documents
refer to the level of security required is "Quality of Service" or QoS. are supported by the model.
SNMPng recognizes three levels of security: 4.3.4. Protocol Operations
- 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 QoS; all processing (security, access SNMP messages encapsulate a Protocol Data Unit (PDU). It is the
control, applications, message processing and control) is required purpose of a Protocol Operations document to define the operations
to abide the specified QoS. of the protocol with respect to the processing of the PDUs.
5.3. Contexts A Local Processing model defines which Protocol Operations documents
are supported by the model.
An SNMP context is a collection of management information 4.4. Applications
accessible by an SNMP agent. An item of management information
may exist in more than one context. An SNMP agent potentially
has access to many contexts.
5.4. Scoped-PDU Applications are developed to achieve certain goals. They use the SNMP
engine to achieve their goals, and interact with the engine in a manner
consistent with the SNMP architecture, but the purpose of specific
applications is outside the scope of the SNMP architecture.
A scoped-PDU contains a Naming-Scope that unambiguously Applications interact with the SNMP engine using application-support
identifies an SNMP agent and the context, (locally) accessible messages whose format is defined by the Message Processing and Control
by that agent, to which the SNMP management information model in use.
in the SNMP-PDU refers.
A Naming-Scope contains a contextID that unambiguously identifies 4.5 Coexistence
the SNMP agent which has (local) access to the management
information referred to by the contextName and the SNMP-PDU.
A Naming-Scope contains a contextName which unambiguously identifies The purpose of an evolutionary architecture is to permit new models
an SNMP context accessible by the SNMP agent to which the SNMP-PDU to replace or supplement existing models. The interactions between
is directed or from which the SNMP-PDU is originated. models could result in incompatibilities, security "holes", and
other undesirable effects.
An implementation of a Message Processing and Control Model The purpose of a Coexistence document is to detail recognized anomalies
must determine if the contextID in the scopedPDU of a received message and to describe required and recommended behaviors for resolving the
matches the snmpNgEngineID of the current engine. If so, the scopedPDU interactions between models within the architecture.
should be processed by the Local Processing implementation.
Harrington/Wijnen Expires October 1977 [Page 9]
\ \
5.5. Security Configuration Datastore It would be very difficult to document all the possible interactions
between a model and all other previously existing models while in the
Each Security Model may need to retain its own set of information about process of developing a new model.
security entities, mechanisms, and policies. This set of information
is called the SNMPng entity's Security Configuration Datastore (SCD).
In order to allow an SNMPng entity's SCD to be remotely configured,
portions may need to be accessible as managed objects.
5.6. Local Configuration Datastore
Each Local Processing Model may need to retain its own set of Coexistence documents are therefore expected to be prepared separately
information about access control, naming scopes, and policies. from model definition documents, to describe and resolve interaction
This set of information is called the SNMPng entity's Local anomalies between a model definition and one or more other model
Processing Configuration Datastore (LCD). definitions.
In order to allow an SNMPng entity's LCD to be remotely configured,
portions may need to be accessible as managed objects.
\ \
6. Model Design Requirements 5. Abstract Data Elements of the Architecture
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 This section contains definitions of abstract data elements used to
on communities to provide trivial authentication and access control. transfer data between subsystems.
SNMPng allows implementations to add support for features of SNMPv1
and SNMPv2c, and to coexist with SNMPv1 and SNMPv2c engines, but
this document does not provide guidelines for that coexistence.
6.1. Security Model Design Requirements 5.1 engineID
Received messages must be validated by a model of the Security Each SNMP engine, consisting of potentially many subsystems, must be
Framework before being processed by the Local Processing Framework. able to be uniquely identified. The mechanism by which this can be
Validation includes authentication and privacy processing if needed, done is defined the Message Processing and Control model in use.
but it is explicitly allowed to send messages which do not require
authentication or privacy.
A received message will contain a specified Quality of Service to be DBH: this is so the IP or MAC address can be used as the engineID
used during processing. All messages requiring privacy must also for old snmpv1 implementations which are being retrofitted into this
require authentication. architecture for use with old snmpv1 management stations. A partial
alternative would be to define the engineID MIB as a separate module
that can be recognized and supported by snmpv1 engines as well as
newer engines that fit this architecture.
A Security Model specifies rules by which authentication and privacy 5.2. SecurityIdentity
are to be done. A model may define mechanisms to provide additional
security features, but is restricted to using the interface, defined in
this document, between the Message Processing and Control Framework and
the Security Framework.
Each Security Model may allow multiple security mechanisms to be used A generic term for an uniquely-identifiable entity on whose behalf
concurrently within an implementation of the model. Each Security Model a message can be generated. The term is deliberately abstract to allow
defines how to determine which protocol to use, given the QoS and the the security subsystem to define the format and nature of the
security parameters passed in the message. Each Security Model, with identities it will use.
its associated protocol(s) defines how the sending/receiving entities
are identified, how secrets are configured, and how security entities
map to groups.
For privacy, the Security Model defines what portion of the message Sample securityIdentities include communities [RFC1157], parties
is encrypted. [RFC1445], and users [RFC1910].
Security Models are replaceable within the SNMPng Framework. Multiple 5.3. Level of Security
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.
Each Security Model must define a mapping to be used between a unique Messages may require different levels of security. The acronym LoS is
entity within the model's SCD, and a securityCookie. A securityCookie used to refer to the level of security.
\ SNMPng 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)
is an implementation-specific handle to identify the unique entity to Every message has an associated LoS; all subsystems (security, access
which it maps. If an implementation supports multiple Security Models, control, applications, message processing and control) are required
the securityCookie must include a mechanism for determining which to abide the specified LoS.
Security Model SCD is referenced. The securityCookie, in combination
with the engineID of the engine which instantiates the securityCookie,
can be used as a globally-unique identifier for a security entity. The
type of a securityCookie is an OCTET STRING, but the format of the
contents is implementation-specific. It is important to note that
since the securityCookie may be accessible outside the engine, the
securityCookie must not disclose any sensitive data, such as by
including passwords in open text in the securityCookie.
Each Security Model defines the MIBs required for security processing, 5.4. Groups
including any MIBs required for the protocol(s) supported. The MIB
formats must be defined concurrently with the procedures which use
the MIB. The MIBs are subject to normal security and access control
rules.
The persistent data used for security should be SNMP-manageable, but A Group identifies a set of zero or more security entities on whose
the Security Model defines whether an instantiation of the MIB is a behalf SNMP managed objects are being processed, subject to access
conformance requirement. The mapping between a securityCookie and the control policies common to all members of the group.
unique security entity within the engine must be able to be determined
using SNMP, if the MIB is instantiated and access control policy
allows.
Protocols should be uniquely identified using Object Identifiers. 5.5. Contexts
Enterprise-specific protocols should be defined within the enterprise
subtree. A protocolID MIB should be defined for IETF standard
protocols for authentication and privacy.
Within any Security Model, there should be no reference to any specific An SNMP context is a collection of management information
Local Processing Model, or to data defined by a Local Processing Model.
6.2. Local Processing Model Design Requirements \
A Local processing Model only processes scopedPDUs which contain a accessible by an SNMP engine. An item of management information
contextID which matches the engineID of the current engine. may exist in more than one context. An SNMP engine potentially
has access to many contexts.
A Local Processing Model must determine whether the specified group is 5.6. ContextEngineID
allowed to perform the requested operation on the managed objects in
the PDU. For messages with a QoS specifying authentication, the group
used for access control must be the same group provided by the Message
Processing and Control Framework.
A Local Processing Model specifies the rules by which access control A contextEngineID is a field in a message to uniquely identify the
and PDU processing are to be done. A model may define mechanisms to engine that contains the context which realizes the managed objects
provide additional processing features, but is restricted to using the referenced in the PDUs.
interface, defined in this document, between the Message Processing
and Control Framework and the Local Processing Framework.
\ 5.7. ContextName
The persistent data used for local processing should be manageable An octet string used to name a context. Each context must be uniquely
using SNMP, but the Local Processing Model defines whether an named within an engine.
instantiation of the MIB is a conformance requirement.
Within any Local Processing Model, there should be no reference to 5.8. Naming Scope
any specific Security Model, or any data defined by a Security Model.
6.3. Message Processing and Control Requirements The data necessary to uniquely identify a context within an
administrative domain is called a naming scope.
The MPC Model must always pass the complete scopedPDU, i.e. it never The format of the naming scope data is defined by a Message Processing
forwards less than the complete list of varbinds. and Control model.
The MPC Model must determine whether a scopedPDU should be processed 5.9. Scoped-PDU
by the current engine or by an application. If a received message
contains a scopedPDU with a contextID matching the engineID of the
current engine, then the scopedPDU should be passed to the Local
Processing Model implementation for processing.
If the MPC Model determines that the contextID does not match the A scopedPDU contains a Naming-Scope and a PDU.
engineID of the current engine, then the message parts, as specified in
the interface section, are passed to a proxy application for
processing.
6.4. Applications The Naming Scope unambiguously identifies, within the administrative
domain, the context to which the SNMP management information in
the PDU refers.
Applications are beyond the scope of this document, but earlier The PDU format is defined by the Local Processing model in use, or
attempts to define an SNMP Framework considered proxy as a possible by a document referenced by the Local processing model.
function of the protocol. SNMPng does not mandate support for proxy
in an SNMPng implementation.
6.4.1. A Proxy Application 5.10. PDU-MMS
The SNMPng Framework explicitly considers proxy to be an external the maximum size of a scopedPDU to be included in a response message,
application. There are certain issues that must be clarified regarding given the amount of reserved space in the message for the anticipated
the relation and interface between proxy and the engine, however. security parameters.
A proxy application has the responsibility to define any MIBs used 5.11. Security Configuration Datastore
to forward message contents, and to determine the address and
identity to whom the message should be forwarded.
An engine supports at most one interface to proxy applications; if an Each Security model may need to retain its own set of information about
implementation wishes to support multiple proxy applications, the security entities, mechanisms, and policies. The collection of these,
determination of which type of proxy, and hence which proxy application possibly multiple, sets of information is referred to collectively as
should handle it, should be handled by the single proxy application to the SNMPng engine's Security Configuration Datastore (SCD).
which the engine has an interface. In order to allow an SNMPng engine's SCD to be remotely configured,
portions may need to be accessible as managed objects.
If proxy is supported, the engine passes all scopedPDUs with a 5.12. Local Configuration Datastore
contextID that does not match the current engine's snmpNgEngineID to
the proxy application. No access control is applied to the message by
the engine which passes the request to the proxy application. A
scopedPDU passed to a proxy application must be a complete scopedPDU.
\ \
Each Local Processing model may need to retain its own set of
information about access control, naming scopes, and policies.
The collection of these, possibly multiple, sets of information is
referred to collectively was the SNMPng engine's Local Processing
Configuration Datastore (LCD). In order to allow an SNMPng engine's
LCD to be remotely configured, portions may need to be accessible
as managed objects.
\ \
7. The SNMPng message format: 6. Textual Conventions for the SNMPng Architecture
DEFINITIONS ::=3D BEGIN snmpNg-TC DEFINITIONS ::= BEGIN
snmpNgMessage ::=3D IMPORTS
SEQUENCE { ObjectSyntax, TimeTicks
-- global parameters FROM SNMPv2-SMI;
version TEXTUAL-CONVENTION
INTEGER { snmpng (3) }, FROM SNMPv2-TC;
msgID
INTEGER,
MMS
INTEGER,
QoS snmpNg-MIB DEFINITIONS ::= BEGIN
OCTET STRING (SIZE(1)),
-- .... ..00 noAuth/noPriv
-- .... ..01 auth/noPriv
-- .... ..1. auth/priv
-- .... .1.. reportableFlag
securityModel IMPORTS
snmpNgSecurityModel, MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TestAndIncr,
RowStatus, AutonomousType, StorageType,
TDomain, TAddress FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
-- security model-specific parameters snmpNgMIB MODULE-IDENTITY
securityParameters LAST-UPDATED "9703260000Z" -- 26 Mar 1997, midnight
OCTET STRING, -- format defined by Security Model ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@tis.com
Subscribe: majordomo@tis.com
In message body: subscribe snmpv3
-- local-processing model-specific data Chair: Russ Mundy
data Trusted Information Systems
ScopedPduData postal: 3060 Washington Rd
} Glenwood MD 21738
email: mundy@tis.com
phone: 301-854-6889
ScopedPduData ::=3D Co-editor: Dr. Jeffrey Case
CHOICE { Snmp Research International, Inc.
plaintext postal:
ScopedPDU, phone:
encrypted
OCTET STRING -- encrypted ScopedPDU
}
scopedPDU ::=3D Co-editor Dave Harrington
SEQUENCE { Cabletron Systems, Inc
contextID postal: Post Office Box 5005
snmpNgEngineID, MailStop: Durham
contextName 35 Industrial Way
snmpNgContextName, Rochester NH 03867-5005
data email: dbh@cabletron.com
ANY -- e.g. PDUs as defined in RFC1905 phone: 603-337-7357
} "
END DESCRIPTION "The snmpNg architecture MIB"
::= { snmpModules xx }
\ \
7.1. SNMP version -- Textual Conventions used throughout the SNMPng Framework
The SNMP version identifies the version of the MPC framework in use. SnmpNgEngineID ::= TEXTUAL-CONVENTION
For purposes of discouraging, but not preventing, the replacement of STATUS current
the Local Processing Model, the SNMP version also implies the version DESCRIPTION "An SNMPng engine's administratively-unique identifier.
of the Local Processing Model.
7.2. msgID The value for this object may not be all zeros or
all 'ff'H.
The msgID is used by SNMP engines to coordinate the processing of the The initial value for this object may be configured
message by different portions of the framework. via an operator console entry or via an algorithmic
function. In the later case, the following
guidelines are recommended:
Note that the requestID used during local processing identifies the 1) The first four octets are set to the binary
request, not the message that carried the request, and therefore might equivalent of the agent's SNMP network management
not be equal to the msgID. 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.
7.3. MMS 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))
The maximum message size supported by the sender of the message. SnmpNgMms OBJECT-TYPE
SYNTAX INTEGER(0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The maximum length in octets of an SNMP message
which this SNMPng engine will accept using any
transport mapping.
"
::= { snmpV3MPCMIBObjects 2 }
7.4. securityModel SnmpNgSecurityModel ::= TEXTUAL-CONVENTION
Multiple security models may exist concurrently in the engine. \
This model number identifies which security model should be used to STATUS current
provide security processing for the message. The mapping to the DESCRIPTION "An identifier that uniquely identifies a model of
appropriate implementation within the agent is done in an security subsystem within the SNMPng Framework.
implementation-dependent manner. "
SYNTAX INTEGER(0..2147483647)
The initial model of the SNMPng Security Framework is the User-Based SnmpNgSecurityIdentity ::= TEXTUAL-CONVENTION
Security Model of the SNMPng Security Framework. STATUS current
DESCRIPTION "A octet string which contains data in a format
defined by a security model which identifies a
unique <thing> for which messages may be generated.
7.5. QoS For example, a securityIdentity for user-based
security contains a user; a securityIdentity for
community-based security contains a community.
The format is not restricted to human-readable text.
"
SYNTAX OCTET STRING (SIZE (0..32))
The QoS field contains flags to control the processing of the message. SnmpNgLoS ::= 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) }
If the reportableFlag is set, then reportPDUs are allowed to be SnmpNgGroupName ::= TEXTUAL-CONVENTION
returned to the sender under those conditions which cause the STATUS current
generation of reportPDUs. If the reportableFlag is zero, then a DESCRIPTION "An octet string which identifies a set of zero or
reportPDU must not be sent. The reportableFlag should always be zero more security entities on whose behalf SNMP managed
when the message is a reportPDU, a responsePDU, or a trapPDU. objects are being processed, subject to access
control policies common to all members of the group.
"
SYNTAX OCTET STRING (SIZE(1..16))
If the auth flag is set, then the security implementation is required SnmpNgContextName ::= TEXTUAL-CONVENTION
to identify the entity on whose behalf a request is generated and to STATUS current
authenticate such identification. If the auth flag is zero, DESCRIPTION "A name which uniquely identifies a set of
authentication of the identification is not required. management information realized by an SNMP engine.
"
SYNTAX OCTET STRING (SIZE (0..32))
If the priv flag is set, then the security implementation is required END
to protect the data within an SNMP operation from disclosure, i.e. to
encrypt the data. If the priv flag is zero, then the security
\ \
implementation does not need to protect the data using encryption. 7. Model Design Requirements
It is an explicit requirement of the SNMPng Framework that if privacy
is selected, then authentication of the identification is required,
i.e. priv flag can only be set if auth flag is also set.
7.6. security parameters 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.
This octet string is not interpreted by the MPC-F. This data is used SNMPv1 and SNMPv2c [RFC1901] are two administrative frameworks based
exclusively by the security model, and the contents and format of the on communities to provide trivial authentication and access control.
data is defined by the security model. SNMPng allows implementations to add support for features of SNMPv1
and SNMPv2c, and to coexist with SNMPv1 and SNMPv2c engines, but
this document does not provide guidelines for that coexistence.
7.7. scopedPDU 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.
The scopedPDU contains a PDU and the scope in which it is to be For any subsystem model, the model definition is constrained to using
processed, as defined by the ID of the engine and the context within the abstract data elements, defined in this document, for transferring
which the management data is realized on that engine. data between the subsystem and any other subsystem. (Note that the
model definition is so constrained, but implementations are not so
constrained).
7.7.1. contextID 7.1. Security Model Design Requirements
This is the engineID of the engine which realizes the managed objects Received messages must be validated by a model of the Security
referenced in the PDUs. subsystem.
Validation includes authentication and privacy processing if needed,
but it is explicitly allowed to send messages which do not require
authentication or privacy.
7.7.2. contextName A received message will contain a specified Level of Security to be
used during processing. All messages requiring privacy must also
require authentication.
This is the name of the context, on the contextID-specified engine, A Security model specifies rules by which authentication and privacy
which realizes the managed objects referenced within the PDUs. 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.
7.7.3. data 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, how secrets are configured, and how security entities
map to groups.
The data contains the PDUs. The Local Processing Model defines the For privacy, the Security model defines what portion of the message
content and format of the PDUs. The initial model of the SNMPng Local is encrypted.
Processing Framework supports SNMPv2 PDUs as defined in RFC1905.
\ \
8. The Frameworks and their standard "services" interfaces Security models are replaceable within the SNMPng subsystem. Multiple
Security model Implementations may exist concurrently within an engine.
Each Framework defines certain standard services, accessible The number of Security models defined by the SNMP community should
through protocol-fixed interfaces. remain small to promote interoperability. It is required that an
implementation of the User-Based Security model be used in all
Each Model for a Framework must provide the standard services, engines to ensure at least a minimal level of interoperability.
but how it performs the service is defined by the model.
8.1. Standard Services of Message Processing and Control Models
8.1.1. Receive SNMP messages from the network
Upon receipt of an SNMPng message from the network, an MPC-M
will extract the MMS, and the QoS, and will determine where the
block of security parameters start in the message.
It 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.
The MPC-M will pass the MMS, the QoS, a pointer to the message, and a
pointer to the block of security parameters to the implementation
of the Security Model specified in the message header.
The Security Model, after completion of its processing, will return to
the Message Processing and Control implementation the group, the
securityCookie, the scopedPDU-MMS, and the scopedPDU.
In the event of an error in security processing, an errorCode may be Each Security model must define a mapping to be used between a unique
returned instead. securityIdentity within the model's SCD, and a securityCookie. A
securityCookie is an implementation-specific handle to identify the
securityIdentity to which it maps. If an implementation supports
multiple Security models, the securityCookie must include a mechanism
for determining which Security model SCD is referenced. The
securityCookie, in combination with the engineID of the engine which
instantiates the securityCookie, can be used as a globally-unique
identifier for a securityIdentity. The type of a securityCookie is an
OCTET STRING, but the format of the contents is
implementation-specific. It is important to note that since the
securityCookie may be accessible outside the engine, the
securityCookie must not disclose any sensitive data, such as by
including passwords in open text in the securityCookie.
8.1.2. Send SNMP messages to the network Each Security model defines the MIB moduless 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 MPC-M will pass a scopedPDU, the securityCookie, and all global The persistent data used for security should be SNMP-manageable, but
data to be included in the message to the Security Model. the Security model defines whether an instantiation of the MIB is a
conformance requirement. The mapping between a securityCookie and the
unique securityIdentity within the engine must be able to be
determined using SNMP, if the MIB is instantiated and access control
policy allows.
The Security Model will construct the message, and return the completed Protocols should be uniquely identified using Object Identifiers.
message to the MPC-M, will will send the message to the desired Enterprise-specific protocols should be defined within the enterprise
address using the appropriate transport. subtree. A protocolID MIB should be defined for IETF standard
protocols for authentication and privacy.
8.1.3. Coordinate the Local Processing of a Received Request Message 7.2. Local Processing Model Design Requirements
The MPC will receive the SNMP message according to the process Within any Local Processing model, there should be no reference to
described in 8.1.1. any specific Security model, or any specific Message Processing and
Control model, or any data defined by a specific Security or Message
Processing and Control model.
The Message Processing and Control implementation will compare the A Local Processing model only processes PDUs which are destined for
contextID in the scopedPDU with its snmpNgEngineID. If they match, the processing by the current engine, according to the rules of the
MPC will forward the scopedPDU to the Local Processing implementation. Local Processing model.
The MPC will pass the scopedPDU, the Group, and the scopedPDU-MMS
provided by the Security Model implementation, plus the QoS, to the
Local Processing implementation.
\ \
It will accept a completed scopedPDU containing the responsePDU A Local Processing model must determine whether the specified group is
from the LP-I, and generate a response message according to the allowed to perform the requested operation on the managed objects in
process described in 8.1.2. the PDU, according to the rules of the Local Processing model being
used.
8.1.4. Forward Received Request Message to a Proxy Application A Local Processing model specifies the rules by which access control
and PDU processing are to be done. 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 MPC will receive the SNMP message according to the process The persistent data used for local processing should be manageable
described in 8.1.1. using SNMP, but the Local Processing model defines whether an
instantiation of the MIB is a conformance requirement.
The MPC will determine whether a scopedPDU in a received message 7.3. Message Processing and Control Requirements
contains a contextID which differs from its snmpNgEngineID.
If it does differ, and if a proxy application is supported by this
engine, the MPC will assign an implementation-defined handle to the
message. The MPC will determine, from the message header, the SNMP
version, the securityModel, the MMS, and the QoS. It will pass to the
proxy application the handle, the SNMP version, securityModel, MMS,
QoS, plus the securityCookie provided by the Security Model
implementation.
8.1.5. Generate a Request Message for an Application Within any Message Processing and Control model, there should be no
reference to any specific Security model or any specific Local
Processing model, or to any data defined by a specific Security or
Local Processing model.
The MPC will receive a request for the generation of a request message The Message Processing and Control model must always (conceptually)
from an application. The application has the responsibility for pass the complete PDU, i.e. it never forwards less than the complete
providing list of varbinds.
the Destination Address, the SNMP version, the QoS desired, the MMS of
the current engine, the SecurityModel to use, the securityCookie to
use, a scopedPDU containing the desired operation, and a handle used
for matching up an incoming response to the application making the
request.
The MPC checks the verb in the scopedPDU to determine that it is a The Message Processing and Control model specifies how to determine
request message, and if so, skips local processing of the scopedPDU. whether the PDU in a received message should be processed by the
current engine or by an application [FT].
The MPC will generate the message according to the process described A model may define mechanisms to provide additional processing
in 8.1.2. features, but is constrained to using the abstract data elements
defined in this document for transferring data between subsystems.
8.1.6. Forward Received Response Message to an Application 7.4. Applications
The MPC will receive the SNMP message according to the process Applications are beyond the scope of this document, but there are
described in 8.1.1. certain issues that must be clarified regarding the relation and
the abstract data elements used for transferring data between
applications and the engine.
The MPC will determine which application is awaiting a response, using 7.4.1. Application Responsibilities
the handle assigned to the transaction in step 8.1.3
The MPC will pass to the application the QoS, the MMS, the Security An application has the responsibility to define any MIB modules used
Model, the securityCookie, the scopedPDU-MMS, and the scopedPDU. to provide application-specific services.
The Application, using the securityCookie, will determine the end-user An engine supports one conceptual interface to applications, provided
on whose behalf the response should be processed. using the abstract data elements for transferring data between the
engine and applications. It is implementation-specific how data passed
from the engine is routed to the appropriate application.
\ \
8.1.7. Forward Received Notification Message to an Application No access control is applied to the PDU by the engine which passes the
PDU to the application. A PDU passed to an application must be a
The MPC will receive the SNMP message according to the process complete PDU, i.e the engine never partially processes a PDU which
described in 8.1.1. is to be passed to an application.
The MPC will determine to which application traps should be forwarded.
The MPC will pass to the application the QoS, the MMS, the Security \
Model, the securityCookie, the scopedPDU-MMS, and the scopedPDU.
The Application, using the securityCookie, will determine the end-user 8. Subsystems and Transferring Data Between Subsystems
on whose behalf the notification should be processed.
8.1.8. Generate a Trap Message Transfer of data between the subsystems is deliberately described
as a fixed set of abstract data elements which can be overloaded to
satisfy the needs of multiple model definitions.
The MPC accepts from the LP-I a Destination Address, the QoS, the Documents which define models to be used within this architecture are
SecurityModel, the Group, and the scopedPDU. 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 MPC uses the group and QoS to request a list of securityCookies The architecture defines certain standard services to be provided
from the Security Model for security entities contained in the group. between subsystems, and the architecture defines abstract data
For each securityCookie in the list, the MPC generates an SNMP message elements to transfer the data necessary to perform the services.
according to the process described in 8.1.2.
8.1.9. Send a Response Message from a Proxy Application 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.
The MPC will send the SNMP message according to the process 8.1. Standard Services of Message Processing and Control Models
described in 8.1.1.
The MPC will determine which application is awaiting a response, using 8.1.1. Receive SNMP messages from the network
the handle assigned to the transaction in step 8.1.3
The MPC will pass to the application the QoS, the MMS, the Security Upon receipt of an SNMPng message from the network, a Message Processing
Model, the securityCookie, the scopedPDU-MMS, and the scopedPDU. and Control model 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.
The Application, using the securityCookie, will determine the end-user The Message Processing and Control model will specify how to determine
on whose behalf the response should be processed. the values of the MMS, the securityModel, the LoS, and the security
parameters block.
8.2. Standard Services Required of Security Models The Message Processing and Control will (conceptually) pass the
extracted MMS, the LoS, the message, and the block of security
parameters to the appropriate Security model.
8.2.1. validate the security-stamp in a received message The Security model, after completion of its processing, will return to
the Message Processing and Control model the group, the securityCookie,
the PDU-MMS, and the PDU.
given a message, the MMS, QoS, and the security parameters from that In the event of an error in security processing, an errorCode may be
message, verify the message has not been altered, and authenticate returned instead.
the identification of the security entity for whom the message was
generated.
If encrypted, decrypt the message 8.1.2. Send SNMP messages to the network
additional requirements may be defined by the model, but they The Message Processing and Control model will pass a PDU, the
cannot require changes to the framework interface securityCookie, and all global data to be included in the message to
\ \
return a securityCookie identifying the entity for whom the message the Security model.
was generated and return the portions of the message needed for
further processing:
a scopedPDU - a PDU enclosed by a header which contains
an snmpID and a contextName
QoS - the quality of service specified for security
validation. The same quality of service 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.
scopedPDU-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.
acGroup - the acGroup to be applied for access control for
the entity for whom the request was generated.
8.2.2. security-stamp a message
Given a scopedPDU, QoS, MMS, and a securityCookie, the Security Model The Security model will construct the message, and return the completed
must determine the security parameters for the message, the contents message to the Message Processing and Control model, which will send
and format of which are defined by the model. the message to the desired address using the appropriate transport.
The Security Model will return a message including the appropriate 8.1.3. Coordinate the Local Processing of a Received Request Message
security parameters, encrypted if required.
8.2.3. Provide mappings between security entities and securityCookies The Message Processing and Control will receive the SNMP message
according to the process described in 8.1.1.
Given model-specific parameters to identify a security entity, The Message Processing and Control model will specify how to determine
an SF-M must return a securityCookie whether the request should be processed by the Local Processing model
or by an application [FT].
Given a securityCookie generated by this SF-M, the SF-M must return If the request should be processed locally, the Message Processing and
model-specific data identifying the corresponding security entity. Control model will (conceptually) pass the PDU, the Group, the PDU-MMS,
and the LoS, to the Local Processing model.
8.2.4. Provide mapping between group and securityCookies It will accept a completed PDU containing the responsePDU
from the Local Processing model, and generate a response message
according to the process described in 8.1.2.
Given a group, the SF-M must return an array of securityCookies 8.1.4. Forward Received Request Message to an Application
identifying the entities which are members of the specified group.
8.3. Standard Services of a Local-Processing Model The Message Processing and Control will receive the SNMP message
according to the process described in 8.1.1.
8.3.1. Process a request The Message Processing and Control model will specify how to determine
whether the request should be processed by the Local Processing model
or by an application [FT].
Given a ScopedPDU, Group, QoS, and ScopedPDU-MMS, an LP-M must return If the request should be processed by an application [FT], the Message
a scopedPDU processed according to the protocol rules of the LP-M Processing and Control model will assign an implementation-defined
handle to the message. The Message Processing and Control model will
specify how to determine, and will (conceptually) pass the SNMP
version, the LoS, the securityCookie, and the assigned handle to the
application [FT].
8.3.2. Generate a Trap 8.1.5. Generate a Request Message for an Application
When an event occurs that requires the generation of a trap, the LP-M The Message Processing and Control will receive a request for the
must pass to the MPC a Destination Address, QoS, MMS, SecurityModel, a generation of an SNMP request message from an application. The
Group, and a scopedPDU, according to the protocol rules of the LP-M. application has the responsibility for providing a Destination Address,
the SNMP version, the LoS desired, the securityCookie to use, a
scopedPDU containing the desired operation, and a handle used for
matching up an incoming response to the application making the request.
\ The Message Processing and Control checks the verb in the PDU to
determine that it is a request message, and if so, skips local
processing of the PDU.
\ \
9. Definitions The Message Processing and Control will generate the message according
to the process described in 8.1.2.
9.1. Definitions for the Architectural Model for SNMPng
snmpNg-MIB DEFINITIONS ::=3D BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TestAndIncr,
RowStatus, AutonomousType, StorageType,
TDomain, TAddress FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
snmpNgMIB MODULE-IDENTITY
LAST-UPDATED "9703260000Z" -- 26 Mar 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 8.1.6. Forward Received Response Message to an Application
Trusted Information Systems
postal: 3060 Washington Rd
Glenwood MD 21738
email: mundy@tis.com
phone: 301-854-6889
Co-editor: Bert Wijnen The Message Processing and Control will receive the SNMP message
IBM T.J. Watson Research according to the process described in 8.1.1.
postal: Schagen 33
3461 GL Linschoten
Netherlands
email: wijnen@vnet.ibm.com
phone: +31-348-412-498
Co-editor Dave Harrington The Message Processing and Control will determine which application is
Cabletron Systems, Inc awaiting a response, using the handle assigned to the transaction in
postal: Post Office Box 5005 step 8.1.3
MailStop: Durham
35 Industrial Way
Rochester NH 03867-5005
email: dbh@cabletron.com
phone: 603-337-7357
"
DESCRIPTION "The snmpNg engine MIB"
::=3D { snmpModules xx }
The Message Processing and Control will pass to the application the
LoS, the securityCookie, the PDU-MMS, and the PDU.
snmpNgMIBObjects OBJECT IDENTIFIER ::=3D { snmpNgMIB 1 } An Application, using the securityCookie, can determine the
securityIdentity on whose behalf the response should be processed.
\ 8.1.7. Forward Received Notification Message to an Application
snmpNgMIBConformance OBJECT IDENTIFIER ::=3D { snmpNgMIB 2 } The Message Processing and Control will receive the SNMP message
according to the process described in 8.1.1.
The Message Processing and Control will determine to which application
traps should be forwarded.
DBH: is this true? isn't this a function of an application support
subsystem to de-multiplex traps to the appropriate application? Isn't
this necessarily part of SNMP, since the indication of the appropriate
application may need to be provided by the SNMP message (e.g. msgID)
snmpNgGroupName ::=3D TEXTUAL-CONVENTION The Message Processing and Control subsystem will pass to the
STATUS current application the LoS, the securityCookie, the PDU-MMS, and the PDU.
DESCRIPTION "An octet string representing the name of a group
for use in accordance with the SNMPng Architectural
Framework.
"
SYNTAX OCTET STRING (SIZE(1..16))
snmpNgContextName ::=3D TEXTUAL-CONVENTION An Application, using the securityCookie, can determine the
STATUS current securityIdentity on whose behalf the notification should be processed.
DESCRIPTION "An SNMPng context name which unambiguously
identifies a set of management information
directly accessible by the Local Processing Module
(implementation or LP-I) of an SNMPng engine.
"
SYNTAX OCTET STRING (SIZE (0..32))
snmpNgQoS ::=3D TEXTUAL-CONVENTION 8.1.8. Send a Notification
STATUS current
DESCRIPTION "A level of security at which SNMPng 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) }
snmpNgEngineID ::=3D TEXTUAL-CONVENTION The Message Processing and Control subsystem accepts from an
STATUS current application a request to send a notification message. The application
DESCRIPTION "An SNMPng entity's administratively-unique identifier. provides the address to which the notification should be sent, the
SecurityCookie to use, the LoS, and a completed scopedPDU.
The value for this object may not be all zeros or Notifications are not processed by a Local Processing model, and
all 'ff'H. therefore are not subject to access control of their contents.
The initial value for this object may be configured 8.1.9. Send a Response Message from an Application
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 An application, using local information can determine the
equivalent of the agent's SNMP network management securityCookie to use to generate the message.
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))
snmpNgSecurityModel ::=3D TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An identifier that uniquely identifies an SNMPng
Security Model within the SNMPng Framework.
"
SYNTAX INTEGER
The application will pass to the Message Processing and Control
subsystem the securityCookie, the LoS, and the scopedPDU.
snmpNgEngineID OBJECT-TYPE The Message Processing and Control will send the SNMP message
SYNTAX snmpNgEngineID according to the process described in 8.1.2.
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The SNMPng entity's administratively-unique
SNMP-Engine identifier.
"
::=3D { snmpNgMIBObjects 1 }
snmpNgEngineMms OBJECT-TYPE 8.2. Standard Services Required of Security Models
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The maximum length in octets of an SNMPng message
which this SNMPng entity will accept using any
transport mapping.
"
::=3D { snmpNgMIBObjects 2 }
8.2.1. validate the security-stamp in a received message
snmpNgMIBCompliances OBJECT IDENTIFIER ::=3D { snmpNgMIBConformance 1 } given a message, the MMS, LoS, and the security parameters from that
snmpNgMIBGroups OBJECT IDENTIFIER ::=3D { snmpNgMIBConformance 2 } message, verify the message has not been altered, and authenticate
the identification of the securityIdentity for whom the message was
generated.
\ If encrypted, decrypt the message
Additional requirements may be defined by the model, and additional
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.
snmpNgMIBCompliance MODULE-COMPLIANCE return a securityCookie identifying the securityIdentity for whom the
STATUS current message was generated and return the portions of the message needed for
DESCRIPTION further processing:
"The compliance statement for SNMPng entities which a PDU - a PDU containing varbinds and a verb according to
implement the SNMPng (MPC) remote configuration MIB. 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.
GroupName - the GroupName to be applied for access control for
the securityIdentity for whom the request was generated.
MODULE -- this module 8.2.2. security-stamp a message
MANDATORY-GROUPS { snmpNgBasicGroup }
::=3D { snmpNgMIBCompliances 1 } Given a PDU, LoS, MMS, and a securityCookie, the Security model
must determine the security parameters for the message, the contents
and format of which are defined by the model.
snmpNgBasicGroup OBJECT-GROUP The Security model will return a message including the appropriate
OBJECTS { snmpNgEngineID, security parameters, encrypted if required.
snmpNgEngineMms
}
STATUS current
DESCRIPTION
"A collection of objects providing for remote configuration
of an SNMPng entity which implements the SNMPng MPC-Model.
"
::=3D { snmpNgMIBGroups 1 }
END 8.2.3. Provide mappings between security entities and securityCookies
\ \
10. Agent Installation Parameters Given model-specific parameters to identify a securityIdentity,
an Security model must return a securityCookie
During installation, an SNMPng entity acting in an agent role is
configured with several parameters. These include:
(1) a security posture
The choice of security posture determines the extent of the view Given a securityCookie generated by this Security model, the Security
configured for unauthenticated access. One of three possible model must return model-specific data identifying the corresponding
choices is selected: securityIdentity.
minimum-secure, 8.3. Standard Services of a Local-Processing Model
semi-secure, or
very-secure.
(2) one or more transport service addresses 8.3.1. Process a request
These parameters may be specified explicitly, or they may be Given a PDU, Group, LoS, and PDU-MMS, a Local Processing model must
specified implicitly as the same set of network-layer addresses return a PDU processed according to the protocol rules defined by the
configured for other uses by the device together with the well- Local Processing model.
known transport-layer "port" information for the appropriate
transport domain 13. The agent listens on each of these
transport service addresses for messages.
\ \
11. Security Consideration 9. Security Consideration
This document describes how the SNMPng uses a Security Model and a This document describes how the SNMPng uses a Security model and a
Local processing Model to achieve a level of security for network Local Processing model to achieve a level of security for network
management messages and controlled access to data. management messages and controlled access to data.
The level of security actually provided is primarily determined by The level of security provided is determined by the specific Security
the specific Security Model implementation(s) and the specific Local model implementation(s) and the specific Local Processing model
Processing Model implementation(s) incorporated into this framework. implementation(s) incorporated into this framework.
Applications have access to data which is not secured. Applications Applications have access to data which is not secured. Applications
should take reasonable steps to protect the data from disclosure. should take reasonable steps to protect the data from disclosure.
It is the responsibility of the purchaser of an SNMPng engine to It is the responsibility of the purchaser of an SNMPng engine to
ensure that: ensure that:
1) an implementation of this framework is fully compliant with 1) an implementation of this framework is fully compliant with
the rules laid down by this framework, the rules laid down by this framework,
2) the implementation of the Security Model complies with the 2) the implementation of the Security model complies with the
rules of the Security Model, rules of the Security model,
3) the implementation of the Local Processing Model complies 3) the implementation of the Local Processing model complies
with the rules of the Local Processing Model, with the rules of the Local Processing model,
4) the implementation of associated applications comply 4) the implementation of associated applications comply
with the rules of this framework relative to applications, with the rules of this framework relative to applications,
5) the Security Model of the implementation(s) incorporated into 5) the Security model of the implementation(s) incorporated into
this framework satisfy the security needs of the organization this framework satisfy the security needs of the organization
using the SNMPng engine, using the SNMPng engine,
6) the Local Processing Model of the implementation(s) incorporated 6) the Local Processing model of the implementation(s) incorporated
into this framework satisfy the access control policies of the into this framework satisfy the access control policies of the
organization using the SNMPng engine, organization using the SNMPng engine,
7) the implementation of the Security Model protects against 7) the implementation of the Security model protects against
inadvertently revealing security secrets in its design of inadvertently revealing security secrets in its design of
implementation-specific data structures, implementation-specific data structures,
8) the implementation of the Local Processing Model protects against 8) the implementation of the Local Processing model protects against
inadvertently revealing configuration secrets in its design of inadvertently revealing configuration secrets in its design of
implementation-specific data structures, implementation-specific data structures,
9) and the applications associated with this engine should take 9) and the applications associated with this engine should take
reasonable steps to protect the security and access control reasonable steps to protect the security and access control
configuration secrets from disclosure. configuration secrets from disclosure.
\ \
12. References 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., [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S., Waldbusser, "Introduction to Rose, M., and S., Waldbusser, "Introduction to
Community-based SNMPv2", RFC 1901, January 1996. Community-based SNMPv2", RFC 1901, January 1996.
[RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S., Waldbusser, "Structure of Management Rose, M., and S., Waldbusser, "Structure of Management
Information for Version 2 of the Simple Network Management Information for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1905, January 1996. 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., [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S., Waldbusser, "Protocol Operations for Rose, M., and S., Waldbusser, "Protocol Operations for
Version 2 of the Simple Network Management Protocol (SNMPv2)", Version 2 of the Simple Network Management Protocol (SNMPv2)",
RFC 1905, January 1996. RFC 1905, January 1996.
[RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S. Waldbusser, "Transport Mappings for Rose, M., and S. Waldbusser, "Transport Mappings for
Version 2 of the Simple Network Management Protocol (SNMPv2)", Version 2 of the Simple Network Management Protocol (SNMPv2)",
RFC 1906, January 1996. RFC 1906, January 1996.
[RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S. Waldbusser, "Management Information Base for Rose, M., and S. Waldbusser, "Management Information Base for
Version 2 of the Simple Network Management Protocol (SNMPv2)", Version 2 of the Simple Network Management Protocol (SNMPv2)",
\
RFC 1907 January 1996. RFC 1907 January 1996.
[RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S. Waldbusser, "Coexistence between Version 1 Rose, M., and S. Waldbusser, "Coexistence between Version 1
and Version 2 of the Internet-standard Network Management and Version 2 of the Internet-standard Network Management
Framework", RFC 1908, January 1996. Framework", RFC 1908, January 1996.
[SNMPng-ARCH] The SNMPng Working Group, Harrington, D., Wijnen, B., [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure
"Architecture for the Next Generation Simple Network Management for SNMPv2", RFC1909, February 1996
Protocol (SNMPng)", draft-ietf-snmpv3-next-gen-arch-00.txt,
April 1997.
[SNMPng-LPM] The SNMPng Working Group, Wijnen, B., Harrington, D.,
"Local Processing Model for the Next Generation Simple Network
Management Protocol (SNMPng)", draft-ietf-snmpng-lpm-00.txt,
April 1997.
[SNMPng-USEC] To be written [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2",
The SNMPng Working Group, Editors...Names, RFC1910, February 1996
"The User-Based Security Model for the Next Generation Simple
Network Management Protocol (SNMPng)",
draft-ietf-snmpng-usec-00.txt, April 1997.
\ \
13. Editor's Addresses 11. Editor's Addresses
Co-editor: Bert Wijnen Co-editor: Bert Wijnen
IBM T.J. Watson Research IBM T.J. Watson Research
postal: Schagen 33 postal: Schagen 33
3461 GL Linschoten 3461 GL Linschoten
Netherlands Netherlands
email: wijnen@vnet.ibm.com email: wijnen@vnet.ibm.com
phone: +31-348-412-498 phone: +31-348-412-498
Co-editor Dave Harrington Co-editor Dave Harrington
Cabletron Systems, Inc Cabletron Systems, Inc
postal: Post Office Box 5005 postal: Post Office Box 5005
MailStop: Durham MailStop: Durham
35 Industrial Way 35 Industrial Way
Rochester NH 03867-5005 Rochester NH 03867-5005
email: dbh@cabletron.com email: dbh@cabletron.com
phone: 603-337-7357 phone: 603-337-7357
14. Acknowledgements \
This document describes the work of the SNMP Security and Administrative 12. Acknowledgements
Framework Evolution team, comprised of
This document builds on the work of the SNMP Security and
Administrative Framework Evolution team, comprised of
David Harrington (Cabletron Systems Inc.) David Harrington (Cabletron Systems Inc.)
Jeff Johnson (Cisco) Jeff Johnson (Cisco)
David Levi (SNMP Research Inc.) David Levi (SNMP Research Inc.)
John Linn (Openvision) John Linn (Openvision)
Russ Mundy (Trusted Information Systems) chair Russ Mundy (Trusted Information Systems) chair
Shawn Routhier (Epilogue) Shawn Routhier (Epilogue)
Glenn Waters (Nortel) Glenn Waters (Nortel)
Bert Wijnen (IBM T.J. Watson Research) Bert Wijnen (IBM T.J. Watson Research)
\ \
Table of Contents Table of Contents
0. Change Log 2 0. Change Log 2
1. Introduction 3 1. Introduction 4
1.1. A Note on Terminology 3 1.1. A Note on Terminology 4
2. Overview 4 2. Overview 5
3. An Evolutionary Architecture - Design Goals 5 3. An Evolutionary Architecture - Design Goals 6
3.1. Encapsulation 5 3.1. Encapsulation 6
3.2. Cohesion 5 3.2. Cohesion 6
3.3. Hierarchical Rules 5 3.3. Hierarchical Rules 6
3.4. Coupling 6 3.4. Coupling 7
4.0. Abstract Functionality 7 4. Abstract Functionality 9
4.1. Message Processing and Control 7 4.1. Message Processing and Control 9
4.2. Security 7 4.1.1. Transport Mappings 9
4.3. Local Processing 8 4.1.2. SNMP-Based Message Formats 9
4.4. Applications 8 4.1.3. Application-Based Message Formats 9
4.5. Definition of SNMPng acronyms and terms: 8 4.1.4. Protocol Instrumentation 9
5. Elements of the Framework 9 4.2. Security 10
5.1. Groups 9 4.3. Local Processing 10
5.2. Quality of Service 9 4.3.1. Structure of Management Information 10
5.3. Contexts 9 4.3.2. Textual Conventions 11
5.4. Scoped-PDU 9 4.3.3. Conformance Statements 11
5.5. Security Configuration Datastore 10 4.3.4. Protocol Operations 11
5.6. Local Configuration Datastore 10 4.4. Applications 11
6. Model Design Requirements 11 4.5 Coexistence 11
6.1. Security Model Design Requirements 11 5. Abstract Data Elements of the Architecture 13
6.2. Local Processing Model Design Requirements 12 5.1 engineID 13
6.3. Message Processing and Control Requirements 13 5.2. SecurityIdentity 13
6.4. Applications 13 5.3. Level of Security 13
6.4.1. A Proxy Application 13 5.4. Groups 13
7. The SNMPng message format: 15 5.5. Contexts 13
7.1. SNMP version 16 5.6. ContextEngineID 14
7.2. msgID 16 5.7. ContextName 14
7.3. MMS 16 5.8. Naming Scope 14
7.4. securityModel 16 5.9. Scoped-PDU 14
7.5. QoS 16 5.10. PDU-MMS 14
7.6. security parameters 17 5.11. Security Configuration Datastore 14
7.7. scopedPDU 17 5.12. Local Configuration Datastore 14
7.7.1. contextID 17 6. Textual Conventions for the SNMPng Architecture 16
7.7.2. contextName 17 7. Model Design Requirements 19
7.7.3. data 17 7.1. Security Model Design Requirements 19
8. The Frameworks and their standard "services" interfaces 18 7.2. Local Processing Model Design Requirements 20
8.1. Standard Services of Message Processing and Control Models 18 7.3. Message Processing and Control Requirements 21
8.1.1. Receive SNMP messages from the network 18 7.4. Applications 21
8.1.2. Send SNMP messages to the network 18 7.4.1. Application Responsibilities 21
8.1.3. Coordinate the Local Processing of a Received Request Message 18 8. Subsystems and Transferring Data Between Subsystems 23
8.1.4. Forward Received Request Message to a Proxy Application 19 8.1. Standard Services of Message Processing and Control Models 23
8.1.5. Generate a Request Message for an Application 19 8.1.1. Receive SNMP messages from the network 23
8.1.6. Forward Received Response Message to an Application 19 8.1.2. Send SNMP messages to the network 23
8.1.7. Forward Received Notification Message to an Application 20 8.1.3. Coordinate the Local Processing of a Received Request Message 24
8.1.8. Generate a Trap Message 20 8.1.4. Forward Received Request Message to an Application 24
8.1.9. Send a Response Message from a Proxy Application 20 8.1.5. Generate a Request Message for an Application 24
8.2. Standard Services Required of Security Models 20 8.1.6. Forward Received Response Message to an Application 25
8.2.1. validate the security-stamp in a received message 20 8.1.7. Forward Received Notification Message to an Application 25
8.2.2. security-stamp a message 21 8.1.8. Send a Notification 25
8.2.3. Provide mappings between security entities and securityCookies 21 8.1.9. Send a Response Message from an Application 25
8.2.4. Provide mapping between group and securityCookies 21 8.2. Standard Services Required of Security Models 26
8.3. Standard Services of a Local-Processing Model 21 8.2.1. validate the security-stamp in a received message 26
8.3.1. Process a request 21 8.2.2. security-stamp a message 26
8.3.2. Generate a Trap 21 8.2.3. Provide mappings between security entities and securityCookies 26
9. Definitions 23 8.3. Standard Services of a Local-Processing Model 27
9.1. Definitions for the Architectural Model for SNMPng 23 8.3.1. Process a request 27
10. Agent Installation Parameters 27 9. Security Consideration 28
11. Security Consideration 28 10. References 29
12. References 29 11. Editor's Addresses 31
13. Editor's Addresses 30 12. Acknowledgements 32
14. Acknowledgements 30
 End of changes. 231 change blocks. 
778 lines changed or deleted 770 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/