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