draft-ietf-snmpv3-next-gen-arch-01.txt   draft-ietf-snmpv3-next-gen-arch-02.txt 
Architecture for the Next Generation An Architecture for Describing
Simple Network Management Protocol (SNMPng) Internet Management Frameworks
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-01.txt> <draft-ietf-snmpv3-next-gen-arch-02.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, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working 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 describing Internet
the Simple Network Management Protocol (SNMPng). The architecture Management Frameworks. The architecture is designed to be modular
is designed to be modular to allow the evolution of the protocol to allow the evolution of the protocol over time. The major portions
over time. The major portions of the architecture are 1) a message of the architecture are a messaging engine containing a message
processing and control subsystem, 2) a security subsystem, and processing and control subsystem and a security subsystem, plus a
3) a local processing subsystem. data processing engine, called a context engine, which contains an
access control subsystem, a MIB access subsystem, and possibly
multiple orangelets which provide specific functional processing
of network management data.
Harrington/Wijnen Expires November 1977 [Page 1] Harrington/Wijnen Expires December 1977 [Page 1]
\
0. Change Log Harrington/Wijnen Expires December 1977 [Page 2]
[version 2.2] 0. Issues
. fix PDU back to scopedPDU where appropriate
. MIB definitions contained some terms that need defining (MMS, etc)
look them up and add to "abstract data elements"
. fixes suggested by Bob Moore:
contextID identifies engine not agent
. fixed intro to allow manager-to-manager "conveyance"
. For interfaces which pass both the securityCookie and the security
model, removed the securityModel, since it can be derived from the
securityCookie.
. eliminated requirement of group to <users> mapping, since movement
of traps to application eliminates the need for this mapping.
. eliminated "end-user"; substitutes security entity.
. removed discussion of traps as part of LPM, replaced with discussion
of notifications sent/received by application.
. separated architectural textual conventions from MPC-specific MIB
(put TCs in architecture doc, objects in MPC doc)
. changed security entity to securityIdentity
[version 2.1]
. changed Quality of Service (QoS) to Level of Security (LoS)
. changed QoS field to msgFlags (includes LoS plus reportFlag)
. modified "Abstract Functionality"
. expanded subsystem descriptions to include introductory text on
SMI, textual conventions, conformance, protocol operations, SNMP MIB,
coexistence, etc.
. added reference citations as needed
. replaced "interface" with "abstract data elements to transfer data"
to avoid the dreaded "interface = API" assumption.
. modified scopedPDU text to permit a snmpv1 community-scoped PDU,
including one which uses the community to control proxy
i.e snmpv3 uses engineID/contextName for naming scope
snmpv1 uses community alone for naming scope
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 November 1977 [Page 2] 0.1. Issues to be resolved
\ . Need the "readable" introduction supplement
. taxonomy:
orangelets
. should the scopedPDU be contained in the securityParameters
SEQUENCE, so encryption can include the PDU and some of the
security parameters?
. Who counts SNMP messages? who counts snmpv3 messages?
. reportPDUs created from an error status or OID returned by the appropriate
subsystem/model?
. foward refreences need to be handled
. some TCs were defined for interface parameters, but aren't part of a mIB.
move to Glossary?
. Is AdminString appropriate for all strings, such as securityidentifier and
context and group? These had different sizes and semantics.
. AdminString has size (1..255); what about default context of ""?
. snmpEngineMaxMessageSize maximum size? 65507? what about non-UDP transports?
. description of max message size
. definitioon/description of MD5/DES protocol OIDs.
. should the tree for registering protocols be in basicGroup?
. should User-based be in basicgroup conformance?
. how does MPC match incoming requests with outgoing responses?
. generateRequestMessage( globalData, scopedPDU, MIID, engineID )
why do we need engineID? isn't that implicit?
. I rearranged primitive parameters: transport/engine/contextEngine/PDU
. state_refernce releases - are these consistently defined?
. should the MPC release the state_reference when it receives a response?
. How is duplicate registration handled? error or ignore?
Harrington/Wijnen Expires November 1977 [Page 3] 0.2. Change Log
\
[version 3.1]
. change securityIdentity to MIID
. write text to explain the differences between security-identities,
model-dependent identifiers, and model-independent identifiers.
. write text to explain distinction within the LCD of the security
data, the access control data, and the oranglet data.
. identify issues
. publish as <draft-ietf-snmpv3-next-gen-arch-02.txt>
[version 3.0]
. add section on threats for message security
. add section on threats for access control
. change application to orangelet
. remove references to F-Ts
. change securityIdentity to security-identity
. change securityCookie to securityIdentity
. the format of securityIdentity is defined by the model
. add securityModel to passed parameters as needed
Harrington/Wijnen Expires December 1977 [Page 3]
. eliminate group from passed parameters
. remove unused IMPORTS
. add glossary section with initial set of words to define
. differentiate the messageEngine from the contextEngine
. eliminate the term SNMPng
. rewrote 1.1. A Note on Terminology
. eliminated assumptions about SNMP processing always being
message related
. rewrote 4.x to reflect new thinking
. rewrote 5.x to reflect new thinking
. rewrote 6.x (the MIB) to reflect new thinking
. added MIB objects at this level (previously only T-Cs)
. rewrote 7.x
. sent to v3edit list
Harrington/Wijnen Expires December 1977 [Page 4]
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, or between management stations and agents and management stations, or between management stations and
other management stations. 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 requirements for standard services,
message-level security, access control for managed objects, and such as sending and receiving messages, countering security threats to
interaction between the protocol engine and the applications which use messages, controlling access to managed objects, and processing various
the services of the engine. types of requests.
It is the purpose of this document to define an architecture which It is the purpose of this document to define an architecture which
can evolve to realize effective network management in a variety can evolve to realize effective network management in a variety
of configurations and environments. The architecture has been of configurations and environments. The architecture has been
designed to meet the needs of implementors of both minimal agents designed to meet the needs of implementors of minimal agents, command
and full-function network enterprise management stations. line driven managers, mid-level managers, and full-function network
enterprise management stations.
1.1. A Note on Terminology 1.1. A Note on Terminology
This architecture is designed to allow an orderly evolution of
portions of SNMP Frameworks.
Throughout the rest of this document, the term "subsystem" will
refer to an abstract and incomplete specification of a portion of
a Framework, that will be further refined by a model specification.
A "model" describes a specific design of a subsystem, defining
additional constraints and rules for conformance to the model.
A model is sufficiently detailed to make it possible to implement
the specification.
A "implementation" is an instantiation of a subsystem, conforming to a
specific model.
SNMP version 1 (SNMPv1), is the original Internet-standard Network SNMP version 1 (SNMPv1), is the original Internet-standard Network
Management Framework, as described in RFCs 1155, 1157, and 1212. Management Framework, as described in RFCs 1155, 1157, and 1212.
SNMP version 2 (SNMPv2) is an updated design of portions of SNMPv1, SNMP version 2 (SNMPv2) is an updated design of portions of SNMPv1,
as described in RFCs 1902-1908. as described in RFCs 1902-1908. SNMPv2 has an incomplete message
definition.
SNMP next generation (SNMPng) is an architecture designed to allow Harrington/Wijnen Expires December 1977 [Page 5]
an orderly evolution of SNMP subsystems. This document describes the
SNMPng architecture.
Throughout the rest of this document, the term subsystem will Community-based SNMP version 2 (SNMPv2c) is an experimental Framework
refer to an abstract and incomplete specification of a portion of which supplements the incomplete message format of SNMPv2 with
SNMPng, that will be further refined by a model specification. portions of the message format of SNMPv1, as described in RFC1901.
A model describes a specific design of a subsystem, defining SNMP version 3 (SNMPv3) Framework is a particular configuration of
additional constraints and rules for conformance to the model. implemented subsystems, consistent with the architecture described
A model is sufficiently detailed a design to make it possible in this document.
to implement the specification.
A Implementation is an instantiation of a subsystem, conforming to a Other SNMP Frameworks, i.e. other configurations of implemented
specific model. subsystems, are expected to also be consistent with this architecture.
Harrington/Wijnen Expires November 1977 [Page 4] This document does not describe any framework, but describes an
\ architecture into which multiple frameworks may be fitted.
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 allow the evolution of portions of SNMP without requiring a redesign
of the general architecture of SNMP. of the general architecture of SNMP.
The processing of SNMP messages is procedural - there are specific SNMP processing must be performed in consistently ordered steps, which
steps which must be accomplished in specific order of processing. fall into general categories of similar functionality. This document
These steps fall into general categories of similar functionality. will describe major abstractions of functionality required during
This document will describe major abstractions of functionality SNMP processing, and the abstract interactions between these major
required of an SNMP engine, and the abstract interactions between categories of functionality.
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 November 1977 [Page 5] Harrington/Wijnen Expires December 1977 [Page 6]
\
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
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 In this architecture, all data used for processing only within
a 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.
For instance, authentication and encryption are both security functions Similarity of the data used to perform functions can be a good
which act on the message. Access control, while similar in some ways, indicator of the similarity of the functions.
is not similar in that it does not work on the message, it works on the
contents of the message. The similarity of the data used to perform For example, authentication and encryption are both security functions
functions can be a good indicator of the similarity of the functions. which are applied to a message. Access control, while similar in some
ways, is dissimilar in that it is not applied to a message, it is
applied to a (proposed) request for a management operation.
The data required to perform authentication and encryption are
different than the data needed to perform access control, and the
two sets of services can be described independently.
Similar functions, especially those that use the same data elements, Similar functions, especially those that use the same data elements,
should be defined together. The security functions which operate at should be defined together. The security functions which operate at
the message level should be defined in a document together with the the message level should be defined in a document together with the
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.
Harrington/Wijnen Expires December 1977 [Page 7]
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.
The SNMPng architecture uses the hierarchical approach by defining This architecture uses the hierarchical approach by defining
Harrington/Wijnen Expires November 1977 [Page 6]
\
subsystems, which specify the general rules of a portion of the system, subsystems, 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
skipping to change at page 10, line ? skipping to change at page 10, line ?
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
for transferring data between the parts of the system. The concept of for transferring data between the parts of the system. The concept of
plug-and-play hardware components is based on that type of interface plug-and-play hardware components is based on that type of interface
between the hardware component and system into which it will be between the hardware component and system into which it will be
"plugged." "plugged."
SNMPng has chosen this approach so individual portions of the system This approach has been chosen 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.
To avoid specifying fixed interfaces, which would constrain a vendor's To avoid specifying fixed interfaces, which would constrain a vendor's
choice of implementation strategies, SNMPng defines a set of abstract choice of implementation strategies, a set of abstract data elements
data elements to be used for (conceptually) transferring data between is used for (conceptually) transferring data between subsystems in
subsystems in documents which describe subsystem or model interactions. documents which describe subsystem or model interactions. Documents
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 Harrington/Wijnen Expires December 1977 [Page 8]
separate message-handling from security and from local processing,
Harrington/Wijnen Expires November 1977 [Page 7] describing the interaction of subsystems or models should use only
\ the abstract data elements provided for transferring data but vendors
are not constrained to using the described data elements for
transferring data between portions of their implementation.
Loose coupling works well with the IETF standards process. If we
separate message-handling from security and from local processing,
then the separate portions of the system can move through the standards 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 November 1977 [Page 8] Harrington/Wijnen Expires December 1977 [Page 9]
\
4. Abstract Functionality 4. Abstract Functionality
The architecture described here is composed of four subsystems, each DBH: {ref: Get-Request, PDU, authentication, encryption, timeliness,
capable of being defined as different models which may be replaced managed objects, proxy, }
or supplemented as the growing needs of network management require.
The subsystems are a Message Processing and Control subsystem, a The architecture described here contains four subsystems, each
Security subsystem, a Local Processing subsystem, and an Application capable of being defined as one or more different models which may
Support subsystem. be replaced or supplemented as the growing needs of network management
require. The subsystems are a Message Processing and Control
subsystem, a Security subsystem, an Orangelet subsystem, and an
Access Control subsystem.
The term "engine" refers to a combination of Message Processing and The subsystems are contained in two "engines".
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 A messageEngine deals with SNMP messages, and is responsible for
sending and receiving messages, including having authentication
and encryption services applied to the messages, and determining
to which Orangelet the message contents should be delivered.
The Message Processing and Control subsystem of an SNMP engine A contextEngine deals with processing network management operations,
interacts with the network using SNMP messages, and interacts with and contains subsystems for Access Control, MIB access, and
applications using data elements defined by the Message Processing Orangelets which provide specific functional processing.
and Control model, within the constraints of the Architecture. Depending on the network management service needed, an Orangelet
may use the access control and MIB access subsystems, and may use
SNMP messages to communicate with remote nodes. The network
management service may be requested via the payload of an SNMP
message, or may be requested via a local process.
A Message Processing and Control model has the responsibility for 4.1. The messageEngine
coordinating the sending and receiving of SNMP messages, and for
coordinating the interaction with other subsystems to acquire the
desired services for the processing of a message.
4.1.1. Transport Mappings The messageEngine interacts with the network using SNMP messages,
and with the message processing subsystem and the security subsystem
and with orangelets using service interfaces defined within this
architecture.
SNMP messages are sent to, or received from, the network using a 4.1.1. Transport Mappings
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 SNMP messages are sent to, or received from, the network using
documents are supported by the model. transport addresses. It is the responsibility of the messageEngine
to listen at the appropriate local addresses, and to send messages
through the appropriate addresses, consistent with mappings defined
by SNMP Transport Mapping documents, such as RFC1906.
4.1.2. SNMP-Based Message Formats 4.1.2. SNMP-Based Message Formats
SNMP messages sent to, or received from, the network use a format SNMP messages sent to, or received from, the network use a format
defined by the Message Processing and Control model. defined by a version-specific Message Processing and Control model.
The messageEngine determines to which version-specific model the
message should be given.
4.1.3. Application-Based Message Formats The version-specific model interacts with the security subsystem,
Messages being sent to, or received from, applications use formats using a service interface defined by this architecture, to procure
which are defined by the Message Processing and Control Model. security services to meet the requirements of the version-specific
Note that these are not SNMP messages, but are abstract data elements protocol.
used to transfer data between the Message Processing and Control
subsystem and an Application Support subsystem.
4.1.4. Protocol Instrumentation 4.1.3. The Interface to Orangelets
Harrington/Wijnen Expires November 1977 [Page 9] A messageEngine, as a result of the receipt of an SNMP message, may
\ initiate a transaction with an Orangelet, such as for an incoming
request, or an Orangelet may initiate a transaction with a
messageEngine, such as for an outgoing request. The messageEngine
determines to which orangelet a message should be given.
It is the purpose of a Management Information Base for SNMP document 4.1.4. Protocol Instrumentation
to define managed objects which describe the behavior of an SNMP
engine.
A Message Processing and Control model defines which SNMP MIB Module To monitor and manage an SNMP engine, a Management Information Base
documents are supported to instrument the model. for SNMP defines the collection of managed objects which instrument
the SNMP protocol itself. The messageEngine has the responsibility
for maintaining the instrumentation that is described by the
SNMPv2 MIB module [RFC1907] plus the instrumentation which is
described by the IMFMIB module defined in this document.
A Message Processing and Control model may require support for
MIB modules related to instrumenting version-specific aspects
of the SNMP protocol.
4.2. Security 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.
4.3. Local Processing 4.3. Orangelets
Local Processing deals with the contents of messages, called the PDU, Orangelets coordinate the processing of management information
providing access to instrumentation and applying access control operations.
according the rules of the Local Processing model being used.
An overview of management information and processing operations is This document describes three common types of orangelets
provided here, but a Local Processing model defines which set of and how they interact within the architecture - 1) an orangelet
may process requests to perform an operation on managed objects,
2) an orangelet may initiate a transaction as the result of a
local event, and 3) an orangelet may act as an intermediary,
forwarding an operation to another network management entity.
Orangelets provide access to MIB information, and coordinate
the application of access control to management operations.
A discussion of the management information and processing is
provided here, but an Orangelet model defines which set of
documents are used to specifically define the structure of management documents are used to specifically define the structure of management
information, textual conventions, conformance requirements, and information, textual conventions, conformance requirements, and
operations supported by the model. operations supported by the Orangelet.
During local processing, it may be required to control access to
certain instrumentation for certain operations. The enforcement of
access rights requires the means to identify the access allowed for
the securityIdentity on whose behalf a request is generated. A Local
Processing model defines which set of documents are used to define
the mechanisms to realize access control within that model.
4.3.1. Structure of Management Information 4.4.1. Structure of Management Information
Management information is viewed as a collection of managed objects, Management information is viewed as a collection of managed objects,
residing in a virtual information store, termed the Management residing in a virtual information store, termed the Management
Information Base (MIB). Collections of related objects are defined Information Base (MIB). Collections of related objects are defined
in MIB modules. in MIB modules.
It is the purpose of a Structure of Management Information It is the purpose of a Structure of Management Information
document to establish the syntax for defining objects, modules, and document to establish the syntax for defining objects, modules, and
other elements of managed information. other elements of managed information.
A Local Processing model defines which SMI documents are supported An Orangelet model defines which SMI documents are supported
by the model. by the model.
\ 4.4.2. Textual Conventions
4.3.2. Textual Conventions
When designing a MIB module, it is often useful to define new types When designing a MIB module, it is often useful to define new types
similar to those defined in the SMI, but with more precise semantics, similar to those defined in the SMI, but with more precise semantics,
or which have special semantics associated with them. These newly or which have special semantics associated with them. These newly
defined types are termed textual conventions. defined types are termed textual conventions.
A Local Processing model defines which Textual Conventions documents An Orangelet model defines which Textual Conventions documents
are supported by the model. are supported by the model.
4.3.3. Conformance Statements 4.4.3. Conformance Statements
It may be useful to define the acceptable lower-bounds of It may be useful to define the acceptable lower-bounds of
implementation, along with the actual level of implementation implementation, along with the actual level of implementation
achieved. It is the purpose of Conformance Statements to define achieved. It is the purpose of Conformance Statements to define
the notation used for these purposes. the notation used for these purposes.
A Local Processing model defines which Conformance Statement documents An Orangelet model defines which Conformance Statement documents
are supported by the model. are supported by the model.
4.3.4. Protocol Operations 4.4.4. Protocol Operations
SNMP messages encapsulate a Protocol Data Unit (PDU). It is the SNMP messages encapsulate a Protocol Data Unit (PDU). It is the
purpose of a Protocol Operations document to define the operations purpose of a Protocol Operations document to define the operations
of the protocol with respect to the processing of the PDUs. of the protocol with respect to the processing of the PDUs.
A Local Processing model defines which Protocol Operations documents An Orangelet model defines which Protocol Operations documents
are supported by the model. are supported by the model.
4.4. Applications 4.5. Access Control
Applications are developed to achieve certain goals. They use the SNMP During processing, it may be required to control access to certain
engine to achieve their goals, and interact with the engine in a manner instrumentation for certain operations. The determination of
consistent with the SNMP architecture, but the purpose of specific access rights requires the means to identify the access allowed for
applications is outside the scope of the SNMP architecture. the security-identity on whose behalf a request is generated.
Applications interact with the SNMP engine using application-support An Access Control model provides an advisory service for an
messages whose format is defined by the Message Processing and Control Orangelet. The determination of whether to check access control
model in use. policy is the responsibility of the Orangelet model. The mechanism
by which access control is checked is defined by the Access Control
model.
4.5 Coexistence 4.6. Coexistence
The purpose of an evolutionary architecture is to permit new models The purpose of an evolutionary architecture is to permit new models
to replace or supplement existing models. The interactions between to replace or supplement existing models. The interactions between
models could result in incompatibilities, security "holes", and models could result in incompatibilities, security "holes", and
other undesirable effects. other undesirable effects.
The purpose of a Coexistence document is to detail recognized anomalies The purpose of a Coexistence document is to detail recognized anomalies
and to describe required and recommended behaviors for resolving the and to describe required and recommended behaviors for resolving the
interactions between models within the architecture. interactions between models within the architecture.
\
It would be very difficult to document all the possible interactions It would be very difficult to document all the possible interactions
between a model and all other previously existing models while in the between a model and all other previously existing models while in the
process of developing a new model. process of developing a new model.
Coexistence documents are therefore expected to be prepared separately Coexistence documents are therefore expected to be prepared separately
from model definition documents, to describe and resolve interaction from model definition documents, to describe and resolve interaction
anomalies between a model definition and one or more other model anomalies between a model definition and one or more other model
definitions. definitions.
\
5. Abstract Data Elements of the Architecture 5. Abstract Data Elements of the Architecture
This section contains definitions of abstract data elements used to This section contains definitions of abstract data elements used to
transfer data between subsystems. transfer data between subsystems.
5.1 engineID 5.1. engineID
Each SNMP engine, consisting of potentially many subsystems, must be Each SNMP engine, consisting of potentially many subsystems, must be
able to be uniquely identified. The mechanism by which this can be able to be uniquely identified. The mechanism by which this can be
done is defined the Message Processing and Control model in use. done is defined in the IMFMIB module, described in this document,
since it is desirable that engine identification span all frameworks.
DBH: this is so the IP or MAC address can be used as the engineID
for old snmpv1 implementations which are being retrofitted into this
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.
5.2. SecurityIdentity 5.2. SecurityIdentity
A generic term for an uniquely-identifiable entity on whose behalf A generic term for an uniquely-identifiable entity on whose behalf
a message can be generated. The term is deliberately abstract to allow a message can be generated. Each security subsystem may define a
the security subsystem to define the format and nature of the model-specific mechanism for entity identification, such as a
identities it will use. community [RFC1157] or user [RFC1910] or party-pair [RFC1445].
This model-specific identifier is not guaranteed to be represented
in a character set readable by humans.
Sample securityIdentities include communities [RFC1157], parties 5.3. Model Independent Identifier (MIID)
[RFC1445], and users [RFC1910].
5.3. Level of Security Each security model must also provide a mapping from the model
specific identification to an SnmpAdminString representation,
called the MIID, which, in combination with the securityModel,
can be used by all other subsystems within an engine to identify
a security identity, regardless of the security mechanisms used to
provide security services.
The combination of engineID and securityModel and MIID provides a
globally-unique identifier for an entity on whose behalf a message
can be generated.
5.4. Level of Security
Messages may require different levels of security. The acronym LoS is Messages may require different levels of security. The acronym LoS is
used to refer to the level of security. used to refer to the level of security.
SNMPng recognizes three levels of security: This architecture recognizes three levels of security:
- without authentication and without privacy (noAuth/noPriv) - without authentication and without privacy (noAuth/noPriv)
- with authentication but without privacy (auth/noPriv) - with authentication but without privacy (auth/noPriv)
- with authentication and with privacy (auth/Priv) - with authentication and with privacy (auth/Priv)
Every message has an associated LoS; all subsystems (security, access Every message has an associated LoS; all subsystems (security, access
control, applications, message processing and control) are required control, orangelets, message processing and control) are required
to abide the specified LoS. to abide the specified LoS while processing the message and its
contents.
5.4. Groups
A Group identifies a set of zero or more security entities on whose
behalf SNMP managed objects are being processed, subject to access
control policies common to all members of the group.
5.5. Contexts 5.5. Contexts
An SNMP context is a collection of management information An SNMP context is a collection of management information
\
accessible by an SNMP engine. An item of management information accessible by an SNMP engine. An item of management information
may exist in more than one context. An SNMP engine potentially may exist in more than one context. An SNMP engine potentially
has access to many contexts. has access to many contexts.
5.6. ContextEngineID 5.6. ContextName
A contextEngineID is a field in a message to uniquely identify the
engine that contains the context which realizes the managed objects
referenced in the PDUs.
5.7. ContextName
An octet string used to name a context. Each context must be uniquely An octet string used to name a context. Each context must be uniquely
named within an engine. named within an engine.
5.8. Naming Scope 5.7. ContextEngineID
The data necessary to uniquely identify a context within an A contextEngineID uniquely identifies an engine that may realize
administrative domain is called a naming scope. an instance of a named context.
The format of the naming scope data is defined by a Message Processing 5.8. Naming Scope
and Control model.
The combination of a contextEngineID and a contextName uniquely
identifies a context within an administrative domain, and is called
a naming scope.
5.9. Scoped-PDU 5.9. Scoped-PDU
A scopedPDU contains a Naming-Scope and a PDU. A scopedPDU contains a Naming-Scope and a PDU.
The Naming Scope unambiguously identifies, within the administrative The Naming Scope unambiguously identifies, within the administrative
domain, the context to which the SNMP management information in domain, the context to which the SNMP management information in
the PDU refers. the PDU refers.
The PDU format is defined by the Local Processing model in use, or The PDU format is defined by an Orangelet model, or a document
by a document referenced by the Local processing model. referenced by an Orangelet model, which processes the PDU contents.
5.10. PDU-MMS 5.10. PDU-MMS
the maximum size of a scopedPDU to be included in a response message, 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 given the amount of reserved space in the message for the anticipated
security parameters. security parameters.
5.11. Security Configuration Datastore 5.11. Local Configuration Datastore
The subsystems and models in an SNMP engine may need to retain their
own, possibly multiple, sets of information to perform their
processing. To allow these sets of information to be remotely
configured, portions may need to be accessible as managed objects.
The collection of these possibly multiple sets of information is
referred to collectively as an engine's Local Configuration Datastore
(LCD).
5.11.1. Security Portion of the Local Configuration Datastore
Each Security model may need to retain its own set of information about Each Security model may need to retain its own set of information about
security entities, mechanisms, and policies. The collection of these, security entities, mechanisms, and policies.
possibly multiple, sets of information is referred to collectively as
the SNMPng engine's Security Configuration Datastore (SCD).
In order to allow an SNMPng engine's SCD to be remotely configured,
portions may need to be accessible as managed objects.
5.12. Local Configuration Datastore 5.11.2. Orangelet Portion of the Local Configuration Datastore
\ Each Orangelet model may need to retain its own set of information
about contexts, naming scopes, and other configuration data.
Each Local Processing model may need to retain its own set of 5.11.3. Access Control Portion of the Local Configuration Datastore
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.
\ Each Access Control model may need to retain its own set of
information about access control policies, and the MIIDs
to which the policies apply.
6. Textual Conventions for the SNMPng Architecture 5.12. Groups
snmpNg-TC DEFINITIONS ::= BEGIN A Group identifies a set of zero or more MIIDs on whose
behalf SNMP managed objects are being processed, subject to access
control policies common to all members of the group.
IMPORTS 6. Definition of Managed Objects for Internet Management Frameworks
ObjectSyntax, TimeTicks
FROM SNMPv2-SMI;
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
snmpNg-MIB DEFINITIONS ::= BEGIN IMF-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI MODULE-IDENTITY, OBJECT-TYPE, snmpModules,
TEXTUAL-CONVENTION, TestAndIncr, Unsigned32, Integer32 FROM SNMPv2-SMI
RowStatus, AutonomousType, StorageType, TEXTUAL-CONVENTION FROM SNMPv2-TC
TDomain, TAddress FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
snmpNgMIB MODULE-IDENTITY imfMIB MODULE-IDENTITY
LAST-UPDATED "9703260000Z" -- 26 Mar 1997, midnight LAST-UPDATED "9706160000Z" -- 16 June 1997, midnight
ORGANIZATION "SNMPv3 Working Group" ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@tis.com CONTACT-INFO "WG-email: snmpv3@tis.com
Subscribe: majordomo@tis.com Subscribe: majordomo@tis.com
In message body: subscribe snmpv3 In message body: subscribe snmpv3
Chair: Russ Mundy Chair: Russ Mundy
Trusted Information Systems Trusted Information Systems
postal: 3060 Washington Rd postal: 3060 Washington Rd
Glenwood MD 21738 Glenwood MD 21738
email: mundy@tis.com email: mundy@tis.com
phone: 301-854-6889 phone: 301-854-6889
Co-editor: Dr. Jeffrey Case
Snmp Research International, Inc.
postal:
phone:
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
"
DESCRIPTION "The snmpNg architecture MIB"
::= { snmpModules xx }
\ Co-editor: Bert Wijnen
IBM T.J. Watson Research
postal: Schagen 33
3461 GL Linschoten
Netherlands
email: wijnen@vnet.ibm.com
phone: +31-348-412-498
"
DESCRIPTION "The Internet Management Architecture MIB"
::= { snmpModules 99 }
SnmpNgEngineID ::= TEXTUAL-CONVENTION -- Textual Conventions used in the Internet Management Architecture ***
SnmpEngineID ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION "An SNMPng engine's administratively-unique identifier. DESCRIPTION "An SNMP engine's administratively-unique identifier.
The value for this object may not be all zeros or The value for this object may not be all zeros or
all 'ff'H. all 'ff'H.
The initial value for this object may be configured The initial value for this object may be configured
via an operator console entry or via an algorithmic via an operator console entry or via an algorithmic
function. In the later case, the following function. In the later case, the following
guidelines are recommended: guidelines are recommended:
1) The first four octets are set to the binary 1) The first four octets are set to the binary
skipping to change at page 17, line 46 skipping to change at page 18, line 38
or the MAC address of one of the interfaces, or the MAC address of one of the interfaces,
with each address suitably padded with random with each address suitably padded with random
octets. If multiple methods are defined, then octets. If multiple methods are defined, then
it is recommended that the cookie be further it is recommended that the cookie be further
divided into one octet that indicates the divided into one octet that indicates the
method being used and seven octets which are method being used and seven octets which are
a function of the method. a function of the method.
" "
SYNTAX OCTET STRING (SIZE (12)) SYNTAX OCTET STRING (SIZE (12))
SnmpNgMms OBJECT-TYPE SnmpSecurityModel ::= TEXTUAL-CONVENTION
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 }
SnmpNgSecurityModel ::= TEXTUAL-CONVENTION
\
STATUS current STATUS current
DESCRIPTION "An identifier that uniquely identifies a model of DESCRIPTION "An identifier that uniquely identifies a model of
security subsystem within the SNMPng Framework. security subsystem within the Internet
Management Architecture.
" "
SYNTAX INTEGER(0..2147483647) SYNTAX INTEGER(0..2147483647)
SnmpNgSecurityIdentity ::= TEXTUAL-CONVENTION -- BW to DBH: why do we need the following TC? It is never used in a MIB
STATUS current -- is it?
DESCRIPTION "A octet string which contains data in a format -- DBH to BW: I defined this only because it was used in an architectural
defined by a security model which identifies a -- interface, and felt that the architecture should define the
unique <thing> for which messages may be generated. -- limits of the syntax, and provide a common description.
--
-- SnmpSecurityStateReference ::= TEXTUAL-CONVENTION
-- STATUS current
-- DESCRIPTION "An implementation-defined reference to the retained
-- security information required to send a response.
For example, a securityIdentity for user-based -- The security model defines what information must be
security contains a user; a securityIdentity for -- retained for use in sending the response.
community-based security contains a community. -- "
The format is not restricted to human-readable text. -- SYNTAX OCTET STRING
"
SYNTAX OCTET STRING (SIZE (0..32))
SnmpNgLoS ::= TEXTUAL-CONVENTION SnmpLoS ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION "A level of security at which SNMP messages can be DESCRIPTION "A level of security at which SNMP messages can be
sent; in particular, one of: sent; in particular, one of:
noAuth - without authentication and without privacy, noAuth - without authentication and without privacy,
auth - with authentication but without privacy, auth - with authentication but without privacy,
priv - with authentication and with privacy. priv - with authentication and with privacy.
" "
SYNTAX INTEGER { noAuth(1), auth(2), priv(3) } SYNTAX INTEGER { noAuth(1), auth(2), priv(3) }
SnmpNgGroupName ::= TEXTUAL-CONVENTION SnmpAdminString ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION "An octet string which identifies a set of zero or DESCRIPTION "An octet string containing an SNMP administrative
more security entities on whose behalf SNMP managed string. Preferably this a a human readable string.
objects are being processed, subject to access We're still thinking if this could use the UTF8
control policies common to all members of the group. character set.
" "
SYNTAX OCTET STRING (SIZE(1..16)) SYNTAX OCTET STRING (SIZE(1..255))
SnmpNgContextName ::= TEXTUAL-CONVENTION -- BW to DBH: I think these are no longer needed. They now use the
-- SnmpV3AdminString TC.
-- DBH to BW: so now all securityidentities, Gropups, and Contxets
-- can be up to 255 bytes long, and MUST always be at least
-- one byte in length? What is our new default context?
--
-- SnmpSecurityIdentity ::= TEXTUAL-CONVENTION
-- STATUS current
-- DESCRIPTION "A octet string which contains data in a format
-- defined by a security model which identifies a
-- unique identity for which messages may be generated.
-- The securityIdentity must be unique across all
-- securityModels supported by the engine.
-- "
-- SYNTAX DisplayString (SIZE (0..32))
--
-- SnmpGroupName ::= TEXTUAL-CONVENTION
-- STATUS current
-- DESCRIPTION "An octet string which identifies a set of zero or
-- more security entities on whose behalf SNMP managed
-- objects are being processed, subject to access
-- control policies common to all members of the group.
-- "
-- SYNTAX OCTET STRING (SIZE(1..16))
--
--SnmpContextName ::= TEXTUAL-CONVENTION
-- STATUS current
-- DESCRIPTION "A name which uniquely identifies a set of
-- management information realized by an SNMP engine.
-- "
-- SYNTAX OCTET STRING (SIZE (0..32))
--
--
-- The IMF Engine Group
--
-- Administrative assignments ****************************************
imfAdmin OBJECT IDENTIFIER ::= { imfMIB 1 }
imfMIBObjects OBJECT IDENTIFIER ::= { imfMIB 2 }
imfMIBConformance OBJECT IDENTIFIER ::= { imfMIB 3 }
-- the imfEngine group ***********************************************
imfEngine OBJECT IDENTIFIER ::= { imfMIBObjects 1 }
snmpEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION "A name which uniquely identifies a set of DESCRIPTION "An SNMP engine's administratively-unique identifier.
management information realized by an SNMP engine.
" "
SYNTAX OCTET STRING (SIZE (0..32)) ::= { imfEngine 1 }
END snmpEngineBoots OBJECT-TYPE
SYNTAX Unsigned32 -- (1..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times that the engine has re-initialized
itself since its initial configuration.
"
::= { imfEngine 2 }
\ snmpEngineTime OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of seconds since the engine last
incremented the snmpEngineBoots object.
"
::= { imfEngine 3 }
snmpEngineMaxMessageSize OBJECT-TYPE
-- SYNTAX Integer32 (484..2147483647)
-- From BW to DBH: why did you use that large range? The 65507 is the
-- max that fits in a UDP datagram. I thought we
-- reached consensus on that on the mailinglist.
-- DBH to BW: did we? I thought there were arguments that we should
-- not work with the limits of UDP, since other transports
-- are now officially supported. If I write an engine that
-- has a larger buffer, and use a transport that can handle
-- the larger size, why artficially limit it? The type can
-- handle the larger number; why impose unnecessary limits?
SYNTAX Integer32 (484..65507)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The maximum length in octets of an SNMP message
which this SNMP engine can send or receive and
process, determined as the minimum of the maximum
message size values supported among all of the
transports available to and supported by the engine.
"
-- From BW to DBH: How do you like this (picked it from RFC1910):
-- I think it is only meant to state what it can
-- receive!!!
-- DBH to BW: I think the one above came from snmpv2*. I think the send
-- was included to indictae
-- to an enquiring manager how large a getBulk might be
-- supported, so a manager didn't send one obviously too large,
-- and to reflect that a message might be receivable, but not
-- be able to be processed due to resource limitations (such
-- as an ASN.1-decoded message being larger than the encoded
-- message, or a secured message with a non-sent key that led
-- to resource allocation problems...)
-- DESCRIPTION "The maximum length in octets of an SNMP message which
-- this agent will accept using any transport mapping.
-- "
::= { imfEngine 4 }
-- From BW to DBH: Was the following decided at the interim?
-- We had those defined in USEC doc.... so if we
-- do define these protocols here, then I can
-- remove them from USEC doc.
-- DBH to BW: Not sure if decided; If we want protocols defined
-- in a common place, the arch mib should provide the tree.
-- I don't object to MD5 and DES being defined in USEC, but
-- the arch doc does specify they are expected, so I think
-- it treasonable to define here, especially if we want to
-- make it mandatory for basic compliance.
--
-- The IMF IETF-Standard Authentication Protocols Group
--
imfAuthProtocols OBJECT IDENTIFIER ::= { imfAdmin 1 }
imfNoAuthProtocol OBJECT IDENTIFIER ::= { imfAuthProtocols 1 }
imfAuthMD5Protocol OBJECT IDENTIFIER ::= { imfAuthProtocols 2 }
DBH to BW: should we have a description of this object to make it
meaningful? ditto for DES below.
--
-- The IMF IETF-Standard Privacy Protocols Group
--
imfPrivProtocols OBJECT IDENTIFIER ::= { imfAdmin 2 }
imfNoPrivProtocol OBJECT IDENTIFIER ::= { imfPrivProtocols 1 }
imfDESPrivProtocol OBJECT IDENTIFIER ::= { imfPrivProtocols 2 }
-- conformance information
imfMIBCompliances
OBJECT IDENTIFIER ::= { imfMIBConformance 1 }
imfMIBGroups
OBJECT IDENTIFIER ::= { imfMIBConformance 2 }
-- compliance statements
imfMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP engines which
implement the IMF MIB.
"
MODULE -- this module
MANDATORY-GROUPS {
imfEngineBasicGroup
}
::= { imfMIBCompliances 1 }
-- units of conformance
imfEngineBasicGroup OBJECT-GROUP
OBJECTS {
snmpEngineID,
snmpEngineMaxMessageSize,
snmpEngineBoots,
snmpEngineTime
}
STATUS current
DESCRIPTION "A collection of objects for identifying and
determining the configuration limits of an
SNMP agent.
"
::= { imfMIBGroups 1 }
-- DBH to BW: should the tree for registering protocols be in basicGroup?
-- I thouhgt we had consensus that user-based security was required
-- as a minimum. No?
END
7. Model Design Requirements 7. Model Design Requirements
The basic design elements come from SNMPv2u and SNMPv2*, as The basic design elements come from SNMPv2u and SNMPv2*, as
described in RFCs 1909-1910, and from a set of internet drafts. described in RFCs 1909-1910, and from a set of internet drafts.
these are the two most popular de facto "administrative framework" these are the two most popular de facto "administrative framework"
standards that include security and access control for SNMPv2. standards that include security and access control for SNMPv2.
SNMPv1 and SNMPv2c [RFC1901] are two administrative frameworks based SNMPv1 and SNMPv2c [RFC1901] are two administrative frameworks based
on communities to provide trivial authentication and access control. on communities to provide trivial authentication and access control.
SNMPng allows implementations to add support for features of SNMPv1 SNMPv1 and SNMPv2c Frameworks can coexist with Frameworks designed
and SNMPv2c, and to coexist with SNMPv1 and SNMPv2c engines, but to fit into this architecture, and modified versions of SNMPv1 and
this document does not provide guidelines for that coexistence. SNMPv2c Frameworks could be fit into this architecture, but this
document does not provide guidelines for that coexistence.
Within any subsystem model, there should be no reference to any Within any subsystem model, there should be no reference to any
specific model of another subsystem, or to data defined by a specific specific model of another subsystem, or to data defined by a specific
model of another subsystem. model of another subsystem.
For any subsystem model, the model definition is constrained to using Transfer of data between the subsystems is deliberately described as a fixed
the abstract data elements, defined in this document, for transferring set of abstract data elements and primitive functions which can be overloaded
data between the subsystem and any other subsystem. (Note that the to satisfy the needs of multiple model definitions.
model definition is so constrained, but implementations are not so
constrained). Documents which define models to be used within this architecture are constrained
to using the abstract data elements for transferring data between subsystems,
possibly defining specific mechanisms for converting the abstract data into
model-usable formats. This constraint exists to allow subsystem and model
documents to be written recognizing common borders of the subsystem and model.
Vendors are not constrained to recognize these borders in their implementations.
The architecture defines certain standard services to be provided
between subsystems, and the architecture defines abstract data
elements to transfer the data necessary to perform the services.
Each model definition for a subsystem must support the standard service
interfaces, but whether, or how, or how well, it performs the service
is defined by the model definition.
7.1. Security Model Design Requirements 7.1. Security Model Design Requirements
Received messages must be validated by a model of the Security 7.1.1. Threats
subsystem.
Validation includes authentication and privacy processing if needed, Several of the classical threats to network protocols are applicable
but it is explicitly allowed to send messages which do not require to the network management problem and therefore would be applicable
authentication or privacy. to any security model used in an Internet Management Framework. Other
threats are not applicable to the network management problem. This
section discusses principal threats, secondary threats, and threats
which are of lesser importance.
The principal threats against which any security model used within
this architecture should provide protection are:
Modification of Information
The modification threat is the danger that some unauthorized
entity may alter in-transit SNMP messages generated on behalf
of an authorized security-identity in such a way as to effect
unauthorized management operations, including falsifying the
value of an object.
Masquerade
The masquerade threat is the danger that management operations
not authorized for some security-identity may be attempted by
assuming the identity of another security-identity that has the
appropriate authorizations.
Message Stream Modification
The SNMPv3 protocol is typically based upon a connectionless
transport service which may operate over any subnetwork service.
The re-ordering, delay or replay of messages can and does occur
through the natural operation of many such subnetwork services.
The message stream modification threat is the danger that messages
may be maliciously re-ordered, delayed or replayed to an extent
which is greater than can occur through the natural operation of a
subnetwork service, in order to effect unauthorized management
operations.
Disclosure
The disclosure threat is the danger of eavesdropping on the
exchanges between SNMP engines. Protecting against this threat
may be required as a matter of local policy.
There are at least two threats against which a security model used
by a framework within this architecture need not protect.
Denial of Service
A security model need not attempt to address the broad range of
attacks by which service on behalf of authorized users is denied.
Indeed, such denial-of-service attacks are in many cases
indistinguishable from the type of network failures with which any
viable network management protocol must cope as a matter of
course.
Traffic Analysis
A security model need not attempt to address traffic analysis
attacks. Many traffic patterns are predictable - agents may be
managed on a regular basis by a relatively small number of
management stations - and therefore there is no significant
advantage afforded by protecting against traffic analysis.
7.1.2. Security Processing
Received messages must be validated by a model of the security
subsystem. Validation includes authentication and privacy processing
if needed, but it is explicitly allowed to send messages which do
not require authentication or privacy.
A received message will contain a specified Level of Security to be A received message will contain a specified Level of Security to be
used during processing. All messages requiring privacy must also used during processing. All messages requiring privacy must also
require authentication. require authentication.
A Security model specifies rules by which authentication and privacy A security model specifies rules by which authentication and privacy
are to be done. A model may define mechanisms to provide additional are to be done. A model may define mechanisms to provide additional
security features, but the model definition is constrained to using security features, but the model definition is constrained to using
(possibly a subset of) the abstract data elements defined in this (possibly a subset of) the abstract data elements defined in this
document for transferring data between subsystems. document for transferring data between subsystems.
Each Security model may allow multiple security mechanisms to be used Each Security model may allow multiple security mechanisms to be used
concurrently within an implementation of the model. Each Security model concurrently within an implementation of the model. Each Security model
defines how to determine which protocol to use, given the LoS and the defines how to determine which protocol to use, given the LoS and the
security parameters relevant to the message. Each Security model, with security parameters relevant to the message. Each Security model, with
its associated protocol(s) defines how the sending/receiving entities its associated protocol(s) defines how the sending/receiving entities
are identified, how secrets are configured, and how security entities are identified, and how secrets are configured.
map to groups.
Authentication and Privacy protocols supported by security models
are uniquely identified using Object Identifiers. IETF standard
protocol for authentication or privacy should have an identifier
defined within the ImfAuthenticationProtocols or ImfPrivacyProtocols
subtrees. Enterprise-specific protocol identifiers should be defined
within the enterprise subtree.
For privacy, the Security model defines what portion of the message For privacy, the Security model defines what portion of the message
is encrypted. is encrypted.
\ The persistent data used for security should be SNMP-manageable, but
the Security model defines whether an instantiation of the MIB is a
conformance requirement.
Security models are replaceable within the SNMPng subsystem. Multiple Security models are replaceable within the security subsystem. Multiple
Security model Implementations may exist concurrently within an engine. Security model Implementations may exist concurrently within an engine.
The number of Security models defined by the SNMP community should The number of Security models defined by the SNMP community should
remain small to promote interoperability. It is required that an remain small to promote interoperability. It is required that an
implementation of the User-Based Security model be used in all implementation of the User-Based Security model be used in all
engines to ensure at least a minimal level of interoperability. engines to ensure at least a minimal level of interoperability.
Each Security model must define a mapping to be used between a unique 7.1.3. validate the security-stamp in a received message
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.
Each Security model defines the MIB moduless required for security given a message, the MMS, LoS, and the security parameters from that
processing, including any MIB modules required for the security message, verify the message has not been altered, and authenticate
mechanism(s) supported. The MIB modules must be defined concurrently the identification of the security-identity for whom the message was
with the procedures which use the MIB module. The MIB modules are generated.
subject to normal security and access control rules.
The persistent data used for security should be SNMP-manageable, but If encrypted, decrypt the message
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.
Protocols should be uniquely identified using Object Identifiers. Additional requirements may be defined by the model, and additional
Enterprise-specific protocols should be defined within the enterprise
subtree. A protocolID MIB should be defined for IETF standard
protocols for authentication and privacy.
7.2. Local Processing Model Design Requirements 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.
Within any Local Processing model, there should be no reference to return a MIID identifying the security-identity for whom
any specific Security model, or any specific Message Processing and the message was generated and return the portions of the message
Control model, or any data defined by a specific Security or Message needed for further processing:
Processing and Control model. a PDU - a PDU containing varbinds and a verb according to
the rules of the Local Processing model to be used.
LoS - the level of security required. The same level of
security must also be used during application of access
control.
MMS - the maximum size of a message able to be generated
by this engine for the destination agent.
PDU-MMS - the maximum size of a PDU to be included in a
response message, given the amount of
reserved space in the message for the anticipated
security parameters.
A Local Processing model only processes PDUs which are destined for 7.1.4. Security Identity
processing by the current engine, according to the rules of the
Local Processing model.
\ Different security models define identifiers which represent some
<thing> which somehow exists, and is capable of using SNMP.
The <thing> may be person, or a network-management platform, or
an aggregate of persons, or an aggregation of persons and devices,
or some other abstraction of entities that are recognized as
being able to use SNMP-defined services.
A Local Processing model must determine whether the specified group is This document will refer to that abstraction as a security-identity.
allowed to perform the requested operation on the managed objects in
the PDU, according to the rules of the Local Processing model being
used.
A Local Processing model specifies the rules by which access control 7.1.5. Model Dependent Identifier
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 persistent data used for local processing should be manageable Each Security model defines how security-identities are identified
using SNMP, but the Local Processing model defines whether an within the model, i.e. how they are named. Model-dependent identifiers
instantiation of the MIB is a conformance requirement. must be unique within the model. The combination of engineID,
securityModel, and the correct model-dependent identifier can be
used to uniquely identify a security-identity.
7.3. Message Processing and Control Requirements For example, David Harrington may be represented on a particular
engine by multiple security models - as the user "davidh", the
community "david", and the foobar "david". It is legal to use
"david" in more than one model, since uniqueness is only guaranteed
within the model, but there cannot be two "david" communities.
The combination of the engineID, the <user> model, and the user
"davidh" uniquely identifies the security-entity David Harrington.
Within any Message Processing and Control model, there should be no 7.1.6. Model Independent Identifier
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 Message Processing and Control model must always (conceptually) It is desirable to be able to refer to a security-entity using a human
pass the complete PDU, i.e. it never forwards less than the complete readable identifier, such as for audit trail entries.
list of varbinds. Therefore, each Security model is required to define a mapping between
The Message Processing and Control model specifies how to determine a model-dependent identifier and an identifier restricted to a human
whether the PDU in a received message should be processed by the readable character set. This identifier is called a MIID.
current engine or by an application [FT].
A model may define mechanisms to provide additional processing The type of a MIID is a human-readable OCTET STRING following the
features, but is constrained to using the abstract data elements conventions of the SnmpAdminString TEXTUAL-CONVENTION, defined below.
defined in this document for transferring data between subsystems.
7.4. Applications The combination of engineID and securityModel and MIID can be used as a
globally-unique identifier for a security-identity.
Applications are beyond the scope of this document, but there are It is important to note that since the MIID may be accessible outside
certain issues that must be clarified regarding the relation and the engine, care must be taken to not disclose sensitive data, such
the abstract data elements used for transferring data between as by including passwords in open text in the MIID.
applications and the engine.
7.4.1. Application Responsibilities 7.1.5. Security MIBs
An application has the responsibility to define any MIB modules used Each Security model defines the MIB modules required for security
to provide application-specific services. 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.
An engine supports one conceptual interface to applications, provided The mapping between the model-dependent identifier and the MIID
using the abstract data elements for transferring data between the must be able to be determined using SNMP, if the model-dependent
engine and applications. It is implementation-specific how data passed MIB is instantiated and access control policy allows.
from the engine is routed to the appropriate application.
\ 7.1.6. Security State Cacheing
No access control is applied to the PDU by the engine which passes the For each message received, the security subsystem caches the state information
PDU to the application. A PDU passed to an application must be a such that a response message can be generated using the same security
complete PDU, i.e the engine never partially processes a PDU which state information, even if the security portion of the Local Configuration
is to be passed to an application. Datastore is altered between the time of the incoming request and the
outgoing response.
\ The Orangelet subsystem has the responsibility for explicitly releasing
the cached data. To enable this, an abstract state_reference data element
is passed from the security subsystem to the message processing and control
subsystem, which passes it to the orangelet subsystem.
8. Subsystems and Transferring Data Between Subsystems The cached security data must be implicitly released via the generation of a
response, or explicitly released by using the state_release() primitive:
Transfer of data between the subsystems is deliberately described state_release( state_reference )
as a fixed set of abstract data elements which can be overloaded to
satisfy the needs of multiple model definitions.
Documents which define models to be used within this architecture are 7.2. MessageEngine and Message Processing and Control Model Requirements
constrained to using the abstract data elements for transferring data
between subsystems, possibly defining specific mechanisms for
converting the abstract data into model-usable formats. This
constraint exists to allow subsystem and model documents to be
written recognizing common borders of the subsystem and model.
Vendors are not constrained to recognize these borders in their
implementations.
The architecture defines certain standard services to be provided A messageEngine may contain multiple version-specific Message Processing and
between subsystems, and the architecture defines abstract data Control models.
elements to transfer the data necessary to perform the services.
Each model definition for a subsystem must support the standard service Within any version-specific Message Processing and Control model, there may be
interfaces, but whether, or how, or how well, it performs the service an explicit binding to a particular security model but there should be no
is defined by the model definition. reference to any data defined by a specific security model. there should be
8.1. Standard Services of Message Processing and Control Models no reference to any specific Orangelet model, or to any data defined by a
specific Orangelet model; there should be no reference to any specific Access
Control model, or to any data defined by a specific Access Control model.
8.1.1. Receive SNMP messages from the network The Message Processing and Control model must always (conceptually)
pass the complete PDU, i.e. it never forwards less than the complete
list of varbinds.
Upon receipt of an SNMPng message from the network, a Message Processing 7.2.1. Receiving an SNMP Message from the Network
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 Message Processing and Control model will specify how to determine Upon receipt of a message from the network, the messageEngine will,
the values of the MMS, the securityModel, the LoS, and the security in an implementation-defined manner, establish a mechanism for coordinating
parameters block. all processing regarding this received message, e.g. it may assign a "handle"
to the message.
DBH: It is no longer valid that the MPC coordinates all processing. But it
still needs to match requests and responses. how does an incoming request get
matched to the outgoing response?
The Message Processing and Control will (conceptually) pass the A Message Processing and Control model will specify how to determine the values
extracted MMS, the LoS, the message, and the block of security of the global data (MMS, the securityModel, the LoS), and the security
parameters to the appropriate Security model. parameters block. The Message Processing and Control will call the security
model to provide security processing for the message using the primitive:
processMsg( globalData, securityParameters, wholeMsg, wholeMsgLen )
The Security model, after completion of its processing, will return to The Security model, after completion of its processing, will return to
the Message Processing and Control model the group, the securityCookie, the Message Processing and Control model the extracted information, using
the PDU-MMS, and the PDU. the returnProcess() primitive:
In the event of an error in security processing, an errorCode may be returnProcess( scopedPDUmms, MIID, cachedSecurityData, scopedPDU, statusCode )
returned instead.
8.1.2. Send SNMP messages to the network 7.2.2. Send SNMP messages to the network
The Message Processing and Control model will pass a PDU, the The Message Processing and Control model will pass a PDU, the
securityCookie, and all global data to be included in the message to MIID, and all global data to be included in the message to
the Security model using the following primitives:
\ For requests and notifications:
the Security model. generateRequestMessage( globalData, scopedPDU, MIID, engineID )
DBH: why do we need engineID? isn't that implicit?
For response messages:
generateResponseMessage( globalData, scopedPDU, MIID, cachedSecurityData )
The Security model will construct the message, and return the completed The Security model will construct the message, and return the completed
message to the Message Processing and Control model, which will send message to the messageEngine using the returngenerate() primitive:
the message to the desired address using the appropriate transport.
8.1.3. Coordinate the Local Processing of a Received Request Message returnGenerate( wholeMsg, wholeMsglen, statusCode )
The Message Processing and Control will receive the SNMP message The messageEngine will send the message to the desired address using the
according to the process described in 8.1.1. appropriate transport.
The Message Processing and Control model will specify how to determine 7.2.3. Generate a Request or Notification Message for an Orangelet
whether the request should be processed by the Local Processing model
or by an application [FT].
If the request should be processed locally, the Message Processing and The messageEngine will receive a request for the generation of an SNMP message
Control model will (conceptually) pass the PDU, the Group, the PDU-MMS, from an orangelet via the send_pdu primitive:
and the LoS, to the Local Processing model.
It will accept a completed PDU containing the responsePDU send_pdu( transportDomain, transportAddress, snmpVersion,
from the Local Processing model, and generate a response message LoS, securityModel, MIID, contextEngineID,
according to the process described in 8.1.2. contextName, PDU,
8.1.4. Forward Received Request Message to an Application The messageEngine checks the verb in the PDU to determine if it is a message
which may receive a response, and if so, caches the msgID of the generated
message and the associated orangelet.
The messageEngine will generate the message according to the process described
in 7.2.2.
7.2.4. Forward Received Response Message to an Orangelet
The Message Processing and Control will receive the SNMP message The Message Processing and Control will receive the SNMP message
according to the process described in 8.1.1. according to the process described in 7.2.1.
The Message Processing and Control model will specify how to determine The Message Processing and Control will determine which orangelet is
whether the request should be processed by the Local Processing model awaiting a response, using the msgID and the cached information from
or by an application [FT]. step 7.2.3
If the request should be processed by an application [FT], the Message The messageEngine matches the msgID of an incoming response to the cached
Processing and Control model will assign an implementation-defined msgIDs of messages sent by this messageEngine, and forwards the response to the
handle to the message. The Message Processing and Control model will associated Orangelet using the process_pdu() primitive:
specify how to determine, and will (conceptually) pass the SNMP
version, the LoS, the securityCookie, and the assigned handle to the
application [FT].
8.1.5. Generate a Request Message for an Application process_pdu( contextEngineID, contextName, pdu, LoS, scopedPdu-MMS,
securityModel, MIID, state-reference )
The Message Processing and Control will receive a request for the 7.2.5. Forward Received Request or Notification Message to an Orangelet
generation of an SNMP request message from an application. The
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 The messageEngine will receive the SNMP message according to the process
determine that it is a request message, and if so, skips local described in 7.2.1.
processing of the PDU.
\ The messageEngine will look into the scopedPDU to determine the contextEngineID,
then determine which orangelet has registered to support that contextEngineID,
and forwards the request or notification to the registered Orangelet using the
process_pdu() primitive:
The Message Processing and Control will generate the message according process_pdu( contextEngineID, contextName, pdu, LoS, scopedPdu-MMS,
to the process described in 8.1.2. securityModel, MIID, state-reference )
8.1.6. Forward Received Response Message to an Application 7.2.6. Generate a Response Message for an Orangelet
The Message Processing and Control will receive the SNMP message The messageEngine will receive a request for the generation of an SNMP response
according to the process described in 8.1.1. message from an orangelet via the return_pdu primitive:
The Message Processing and Control will determine which application is return_pdu( contextEngineID, contextName, LoS, MIID, state_reference,
awaiting a response, using the handle assigned to the transaction in PDU, PDU-MMS, status_code )
step 8.1.3
The Message Processing and Control will pass to the application the The messageEngine will generate the message according to the process described
LoS, the securityCookie, the PDU-MMS, and the PDU. in 7.2.2.
An Application, using the securityCookie, can determine the 7.3. Orangelet Model Design Requirements
securityIdentity on whose behalf the response should be processed.
8.1.7. Forward Received Notification Message to an Application Within an Orangelet model, there may be an explicit binding to a specific
SNMP message version, i.e. a specific Message Processing and Control model,
and to a specific Access Control model, but there should be no reference to
any data defined by a specific Message Processing and Control model or Access
Control model.
The Message Processing and Control will receive the SNMP message Within an Orangelet model, there should be no reference to any
according to the process described in 8.1.1. specific Security model, or any data defined by a specific Security
model.
The Message Processing and Control will determine to which application An Orangelet determines whether explicit or implicit access control
traps should be forwarded. should be applied to the operation, and, if access control is needed,
DBH: is this true? isn't this a function of an application support which Access Control model should be used.
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)
The Message Processing and Control subsystem will pass to the An orangelet has the responsibility to define any MIB modules used
application the LoS, the securityCookie, the PDU-MMS, and the PDU. to provide orangelet-specific services.
An Application, using the securityCookie, can determine the Orangelets interact with the messageEngine to initiate messages, receive
securityIdentity on whose behalf the notification should be processed. responses, receive asynchronous messages, and send responses.
8.1.8. Send a Notification 7.3.1. Orangelets that Initiate Messages
The Message Processing and Control subsystem accepts from an Orangelets may request that the messageEngine send messages containing SNMP
application a request to send a notification message. The application polling requests or notifications using the send_pdu() primitive:
provides the address to which the notification should be sent, the
SecurityCookie to use, the LoS, and a completed scopedPDU.
Notifications are not processed by a Local Processing model, and send_pdu( transportDomain, transportAddress, snmpVersion,
therefore are not subject to access control of their contents. LoS, securityModel, MIID, contextEngineID,
contextName, PDU,
8.1.9. Send a Response Message from an Application [DBH: I rearranged these parameters into groups of related data organized
roughly by order of locality - transport/engine/contextEngine/PDU.]
An application, using local information can determine the If it is desired that a message be sent to multiple targets, it is the
securityCookie to use to generate the message. reponsibility of the orangelet to provide the iteration.
\ The messageEngine assumes necessary access control has been applied
to the PDU, and provides no access control services.
The application will pass to the Message Processing and Control The messageEngine looks at the verb, and for operations which will elicit a
subsystem the securityCookie, the LoS, and the scopedPDU. response, the msgID and the associated orangelet are cached.
The Message Processing and Control will send the SNMP message 7.3.2. Orangelets that Receive Responses
according to the process described in 8.1.2.
8.2. Standard Services Required of Security Models The messageEngine matches the msgID of an incoming response to the cached
msgIDs of messages sent by this messageEngine, and forwards the response to the
associated Orangelet using the process_pdu() primitive:
8.2.1. validate the security-stamp in a received message process_pdu( contextEngineID, contextName, pdu, LoS, scopedPdu-MMS,
securityModel, MIID, state-reference )
given a message, the MMS, LoS, and the security parameters from that DBH: should the MPC release the state_reference when it receives a response?
message, verify the message has not been altered, and authenticate There isn't much reason to force the orangelet to handle this if the MPC
the identification of the securityIdentity for whom the message was already knows it is a response message, i.e. the end of a transaction.
generated.
If encrypted, decrypt the message 7.3.3. Orangelets that Receive Asynchronous Messages
Additional requirements may be defined by the model, and additional When a messageEngine receives a message that is not the response to a request
services provided by the model, but the model is constrained to use from this messageEngine, it must determine to which Orangelet the message
only the defined abstract data elements for transferring data between should be given.
subsystems. Implementations are no so constrained.
return a securityCookie identifying the securityIdentity for whom the An Orangelet that wishes to receive asynchronous messages registers
message was generated and return the portions of the message needed for itself with the messageEngine using the registration primitive.
further processing: An Orangelet that wishes to stop receiving asynchronous messages
a PDU - a PDU containing varbinds and a verb according to should un-register itself with the messageEngine.
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.
8.2.2. security-stamp a message register_contextEngineID ( contextEngineID )
unregister_contextEngineID ( contextEngineID )
Given a PDU, LoS, MMS, and a securityCookie, the Security model Only one registration per contextEngineID is permitted at the same
must determine the security parameters for the message, the contents time. Duplicate registrations are ignored.
and format of which are defined by the model.
The Security model will return a message including the appropriate [DBH: there is no provision for an error for this. Is the second
security parameters, encrypted if required. just ignored?]
8.2.3. Provide mappings between security entities and securityCookies All asynchronously received messages referencing a registered contextEngineID
will be sent to the orangelet which registered to support that contextEngineID.
This includes incoming requests, incoming notifications, and proxies.
\ It forwards the PDU to the registered Orangelet, using the process_pdu()
primitive:
Given model-specific parameters to identify a securityIdentity, process_pdu( contextEngineID, contextName, PDU, PDU-MMS,
an Security model must return a securityCookie LoS, securityModel, MIID, state_reference )
Given a securityCookie generated by this Security model, the Security 7.3.4. Orangelets that Send Responses
model must return model-specific data identifying the corresponding
securityIdentity.
8.3. Standard Services of a Local-Processing Model Request operations require responses. These operations include Get requests,
set requests, and inform requests. An Orangelet sends a response via the
return_pdu primitive:
8.3.1. Process a request return_pdu( contextEngineID, contextName, LoS, MIID, state_reference,
PDU, PDU-MMS, status_code )
Given a PDU, Group, LoS, and PDU-MMS, a Local Processing model must The contextEngineID, contextName, LoS, MIID, and state_reference parameters
return a PDU processed according to the protocol rules defined by the are from the initial process_pdu() primitive. The PDU and status_code are
Local Processing model. the results of processing.
\ DBH: in the v2adv approach, a handle was passed so the messageEngine
could match the response to the incoming request. How is it done now?
9. Security Consideration 7.4. Access Control Model Design Requirements
This document describes how the SNMPng uses a Security model and a An Access Control model must determine whether the specified
Local Processing model to achieve a level of security for network MIID is allowed to perform the requested operation on
management messages and controlled access to data. a specified managed object. The Access Control model specifies the
rules by which access control is determined.
A model may define mechanisms to provide additional processing
features, but is constrained to using the abstract data elements
defined in this document for transferring data between subsystems.
The persistent data used for access control should be manageable
using SNMP, but the Access Control model defines whether an
instantiation of the MIB is a conformance requirement.
8. Security Consideration
This document describes how a framework can use a Security model
and a Local Processing model to achieve a level of security for
network management messages and controlled access to data.
The level of security provided is determined by the specific Security The level of security provided is determined by the specific Security
model implementation(s) and the specific Local Processing model model implementation(s) and the specific Local Processing model
implementation(s) incorporated into this framework. implementation(s) incorporated into this framework.
Applications have access to data which is not secured. Applications Orangelets have access to data which is not secured. Orangelets
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 a management framework
ensure that: implementation to 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 defined by this architecture,
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 orangelets comply
with the rules of this framework relative to applications, with the rules of this framework relative to orangelets,
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 the framework satisfy the security needs of the organization,
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 the framework satisfy the access control policies of the
organization using the SNMPng engine, organization,
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 implementation of the orangelets protect security and
reasonable steps to protect the security and access control access control configuration secrets from disclosure.
configuration secrets from disclosure.
\ 9. Glossary
10. References 10. References
[RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", STD 16, RFC Management Information for TCP/IP-based internets", STD 16, RFC
1155, May 1990. 1155, May 1990.
[RFC1157] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple [RFC1157] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
Network Management Protocol", RFC 1157, University of Tennessee Network Management Protocol", RFC 1157, University of Tennessee
at Knoxville, Performance Systems International, Performance at Knoxville, Performance Systems International, Performance
skipping to change at page 30, line 4 skipping to change at page 37, line 4
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.
[RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure
for SNMPv2", RFC1909, February 1996 for SNMPv2", RFC1909, February 1996
[RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2",
RFC1910, February 1996 RFC1910, February 1996
\
11. 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
\
12. Acknowledgements 12. Acknowledgements
This document builds on the work of the SNMP Security and This document builds on the work of the SNMP Security and
Administrative Framework Evolution team, comprised of 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. Issues 3
1. Introduction 4 0.1. Issues to be resolved 3
1.1. A Note on Terminology 4 0.2. Change Log 3
2. Overview 5 1. Introduction 5
3. An Evolutionary Architecture - Design Goals 6 1.1. A Note on Terminology 5
3.1. Encapsulation 6 2. Overview 6
3.2. Cohesion 6 3. An Evolutionary Architecture - Design Goals 7
3.3. Hierarchical Rules 6 3.1. Encapsulation 7
3.4. Coupling 7 3.2. Cohesion 7
4. Abstract Functionality 9 3.3. Hierarchical Rules 8
4.1. Message Processing and Control 9 3.4. Coupling 8
4.1.1. Transport Mappings 9 4. Abstract Functionality 10
4.1.2. SNMP-Based Message Formats 9 4.1. The messageEngine 10
4.1.3. Application-Based Message Formats 9 4.1.1. Transport Mappings 10
4.1.4. Protocol Instrumentation 9 4.1.2. SNMP-Based Message Formats 10
4.2. Security 10 4.1.3. The Interface to Orangelets 11
4.3. Local Processing 10 4.1.4. Protocol Instrumentation 11
4.3.1. Structure of Management Information 10 4.2. Security 11
4.3.2. Textual Conventions 11 4.3. Orangelets 11
4.3.3. Conformance Statements 11 4.4.1. Structure of Management Information 12
4.3.4. Protocol Operations 11 4.4.2. Textual Conventions 12
4.4. Applications 11 4.4.3. Conformance Statements 12
4.5 Coexistence 11 4.4.4. Protocol Operations 12
5. Abstract Data Elements of the Architecture 13 4.5. Access Control 13
5.1 engineID 13 4.6. Coexistence 13
5.2. SecurityIdentity 13 5. Abstract Data Elements of the Architecture 14
5.3. Level of Security 13 5.1. engineID 14
5.4. Groups 13 5.2. SecurityIdentity 14
5.5. Contexts 13 5.3. Model Independent Identifier (MIID) 14
5.6. ContextEngineID 14 5.4. Level of Security 14
5.7. ContextName 14 5.5. Contexts 15
5.8. Naming Scope 14 5.6. ContextName 15
5.9. Scoped-PDU 14 5.7. ContextEngineID 15
5.10. PDU-MMS 14 5.8. Naming Scope 15
5.11. Security Configuration Datastore 14 5.9. Scoped-PDU 15
5.12. Local Configuration Datastore 14 5.10. PDU-MMS 15
6. Textual Conventions for the SNMPng Architecture 16 5.11. Local Configuration Datastore 15
7. Model Design Requirements 19 5.11.1. Security Portion of the Local Configuration Datastore 16
7.1. Security Model Design Requirements 19 5.11.2. Orangelet Portion of the Local Configuration Datastore 16
7.2. Local Processing Model Design Requirements 20 5.11.3. Access Control Portion of the Local Configuration Datastore 16
7.3. Message Processing and Control Requirements 21 5.12. Groups 16
7.4. Applications 21 6. Definition of Managed Objects for Internet Management Frameworks 17
7.4.1. Application Responsibilities 21 7. Model Design Requirements 24
8. Subsystems and Transferring Data Between Subsystems 23 7.1. Security Model Design Requirements 24
8.1. Standard Services of Message Processing and Control Models 23 7.1.1. Threats 24
8.1.1. Receive SNMP messages from the network 23 7.1.2. Security Processing 25
8.1.2. Send SNMP messages to the network 23 7.1.3. validate the security-stamp in a received message 26
8.1.3. Coordinate the Local Processing of a Received Request Message 24 7.1.4. Security Identity 27
8.1.4. Forward Received Request Message to an Application 24 7.1.5. Model Dependent Identifier 27
8.1.5. Generate a Request Message for an Application 24 7.1.6. Model Independent Identifier 27
8.1.6. Forward Received Response Message to an Application 25 7.1.5. Security MIBs 28
8.1.7. Forward Received Notification Message to an Application 25 7.1.6. Security State Cacheing 28
8.1.8. Send a Notification 25 7.2. MessageEngine and Message Processing and Control Model Requirements 28
8.1.9. Send a Response Message from an Application 25 7.2.1. Receiving an SNMP Message from the Network 29
8.2. Standard Services Required of Security Models 26 7.2.2. Send SNMP messages to the network 29
8.2.1. validate the security-stamp in a received message 26 7.2.3. Generate a Request or Notification Message for an Orangelet 30
8.2.2. security-stamp a message 26 7.2.4. Forward Received Response Message to an Orangelet 30
8.2.3. Provide mappings between security entities and securityCookies 26 7.2.5. Forward Received Request or Notification Message to an Orangelet 30
8.3. Standard Services of a Local-Processing Model 27 7.2.6. Generate a Response Message for an Orangelet 31
8.3.1. Process a request 27 7.3. Orangelet Model Design Requirements 31
9. Security Consideration 28 7.3.1. Orangelets that Initiate Messages 31
10. References 29 7.3.2. Orangelets that Receive Responses 32
11. Editor's Addresses 31 7.3.3. Orangelets that Receive Asynchronous Messages 32
12. Acknowledgements 32 7.3.4. Orangelets that Send Responses 32
7.4. Access Control Model Design Requirements 33
8. Security Consideration 34
9. Glossary 35
10. References 36
11. Editor's Addresses 38
12. Acknowledgements 39
 End of changes. 219 change blocks. 
602 lines changed or deleted 892 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/