[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 RFC 2261
Architecture for the Next Generation
Simple Network Management Protocol (SNMPng)
9 May 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-01.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 the Next-Generation of
the Simple Network Management Protocol (SNMPng). The architecture
is designed to be modular to allow the evolution of the protocol
over time. The major portions of the architecture are 1) a message
processing and control subsystem, 2) a security subsystem, and
3) a local processing subsystem.
Harrington/Wijnen Expires November 1977 [Page 1]
\
Draft Architecture for SNMPng May 1997
0. Change Log
[version 2.2]
. 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]
\
Draft Architecture for SNMPng May 1997
Harrington/Wijnen Expires November 1977 [Page 3]
\
Draft Architecture for SNMPng May 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 policies for mechanisms which provide
message-level security, access control for managed objects, and
interaction between the protocol engine and the applications which use
the services of the engine.
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 both minimal agents
and full-function network enterprise management stations.
1.1. A Note on Terminology
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.
SNMP next generation (SNMPng) is an architecture designed to allow
an orderly evolution of SNMP subsystems. This document describes the
SNMPng architecture.
Throughout the rest of this document, the term subsystem will
refer to an abstract and incomplete specification of a portion of
SNMPng, 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 a design to make it possible
to implement the specification.
A Implementation is an instantiation of a subsystem, conforming to a
specific model.
Harrington/Wijnen Expires November 1977 [Page 4]
\
Draft Architecture for SNMPng May 1997
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.
The processing of SNMP messages is procedural - there are specific
steps which must be accomplished in specific order of processing.
These steps fall into general categories of similar functionality.
This document will describe major abstractions of functionality
required of an SNMP engine, 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 November 1977 [Page 5]
\
Draft Architecture for SNMPng May 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 the SNMPng 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.
For instance, authentication and encryption are both security functions
which act on the message. Access control, while similar in some ways,
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
functions can be a good indicator of the similarity of the functions.
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.
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.
The SNMPng architecture uses the hierarchical approach by defining
Harrington/Wijnen Expires November 1977 [Page 6]
\
Draft Architecture for SNMPng May 1997
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."
SNMPng has chosen this approach 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, SNMPng defines a set of abstract
data elements to be used for (conceptually) transferring data between
subsystems in documents which describe subsystem or model interactions.
Documents describing the interaction of subsystems or models should
use only the abstract data elements provided for transferring data
but vendors are not constrained to using the described data elements
for transferring data between portions of their implementation.
Loose coupling works well with the IETF standards process. If we
separate message-handling from security and from local processing,
Harrington/Wijnen Expires November 1977 [Page 7]
\
Draft Architecture for SNMPng May 1997
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 November 1977 [Page 8]
\
Draft Architecture for SNMPng May 1997
4. Abstract Functionality
The architecture described here is composed of four subsystems, each
capable of being defined as 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, a Local Processing subsystem, and an Application
Support subsystem.
The term "engine" refers to a combination of Message Processing and
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
The Message Processing and Control subsystem of an SNMP engine
interacts with the network using SNMP messages, and interacts with
applications using data elements defined by the Message Processing
and Control model, within the constraints of the Architecture.
A Message Processing and Control model has the responsibility for
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
SNMP messages are sent to, or received from, the network using a
transport mechanism. It is the purpose of Transport Mapping documents
to define how SNMP maps onto transport domains.
A Message Processing and Control model defines which Transport Mappings
documents are supported by the model.
4.1.2. SNMP-Based Message Formats
SNMP messages sent to, or received from, the network use a format
defined by the Message Processing and Control model.
4.1.3. Application-Based Message Formats
Messages being sent to, or received from, applications use formats
which are defined by the Message Processing and Control Model.
Note that these are not SNMP messages, but are abstract data elements
used to transfer data between the Message Processing and Control
subsystem and an Application Support subsystem.
4.1.4. Protocol Instrumentation
Harrington/Wijnen Expires November 1977 [Page 9]
\
Draft Architecture for SNMPng May 1997
It is the purpose of a Management Information Base for SNMP document
to define managed objects which describe the behavior of an SNMP
engine.
A Message Processing and Control model defines which SNMP MIB Module
documents are supported to instrument the model.
4.2. Security
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. Local Processing
Local Processing deals with the contents of messages, called the PDU,
providing access to instrumentation and applying access control
according the rules of the Local Processing model being used.
An overview of management information and processing operations is
provided here, but a Local Processing model defines which set of
documents are used to specifically define the structure of management
information, textual conventions, conformance requirements, and
operations supported by the model.
During local processing, it may be required to control access to
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
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.
A Local Processing model defines which SMI documents are supported
by the model.
Harrington/Wijnen Expires November 1977 [Page 10]
\
Draft Architecture for SNMPng May 1997
4.3.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.
A Local Processing model defines which Textual Conventions documents
are supported by the model.
4.3.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.
A Local Processing model defines which Conformance Statement documents
are supported by the model.
4.3.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.
A Local Processing model defines which Protocol Operations documents
are supported by the model.
4.4. Applications
Applications are developed to achieve certain goals. They use the SNMP
engine to achieve their goals, and interact with the engine in a manner
consistent with the SNMP architecture, but the purpose of specific
applications is outside the scope of the SNMP architecture.
Applications interact with the SNMP engine using application-support
messages whose format is defined by the Message Processing and Control
model in use.
4.5 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.
Harrington/Wijnen Expires November 1977 [Page 11]
\
Draft Architecture for SNMPng May 1997
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 November 1977 [Page 12]
\
Draft Architecture for SNMPng May 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 the Message Processing and Control model in use.
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
A generic term for an uniquely-identifiable entity on whose behalf
a message can be generated. The term is deliberately abstract to allow
the security subsystem to define the format and nature of the
identities it will use.
Sample securityIdentities include communities [RFC1157], parties
[RFC1445], and users [RFC1910].
5.3. Level of Security
Messages may require different levels of security. The acronym LoS is
used to refer to the level of security.
SNMPng recognizes three levels of security:
- without authentication and without privacy (noAuth/noPriv)
- with authentication but without privacy (auth/noPriv)
- with authentication and with privacy (auth/Priv)
Every message has an associated LoS; all subsystems (security, access
control, applications, message processing and control) are required
to abide the specified LoS.
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
An SNMP context is a collection of management information
Harrington/Wijnen Expires November 1977 [Page 13]
\
Draft Architecture for SNMPng May 1997
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. ContextEngineID
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
named within an engine.
5.8. Naming Scope
The data necessary to uniquely identify a context within an
administrative domain is called a naming scope.
The format of the naming scope data is defined by a Message Processing
and Control model.
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 the Local Processing model in use, or
by a document referenced by the Local processing model.
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. Security Configuration Datastore
Each Security model may need to retain its own set of information about
security entities, mechanisms, and policies. The collection of these,
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
Harrington/Wijnen Expires November 1977 [Page 14]
\
Draft Architecture for SNMPng May 1997
Each Local Processing model may need to retain its own set of
information about access control, naming scopes, and policies.
The collection of these, possibly multiple, sets of information is
referred to collectively was the SNMPng engine's Local Processing
Configuration Datastore (LCD). In order to allow an SNMPng engine's
LCD to be remotely configured, portions may need to be accessible
as managed objects.
Harrington/Wijnen Expires November 1977 [Page 15]
\
Draft Architecture for SNMPng May 1997
6. Textual Conventions for the SNMPng Architecture
snmpNg-TC DEFINITIONS ::= BEGIN
IMPORTS
ObjectSyntax, TimeTicks
FROM SNMPv2-SMI;
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
snmpNg-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TestAndIncr,
RowStatus, AutonomousType, StorageType,
TDomain, TAddress FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
snmpNgMIB MODULE-IDENTITY
LAST-UPDATED "9703260000Z" -- 26 Mar 1997, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@tis.com
Subscribe: majordomo@tis.com
In message body: subscribe snmpv3
Chair: Russ Mundy
Trusted Information Systems
postal: 3060 Washington Rd
Glenwood MD 21738
email: mundy@tis.com
phone: 301-854-6889
Co-editor: Dr. Jeffrey Case
Snmp Research International, Inc.
postal:
phone:
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
"
DESCRIPTION "The snmpNg architecture MIB"
::= { snmpModules xx }
Harrington/Wijnen Expires November 1977 [Page 16]
\
Draft Architecture for SNMPng May 1997
-- Textual Conventions used throughout the SNMPng Framework
SnmpNgEngineID ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An SNMPng engine's administratively-unique identifier.
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))
SnmpNgMms OBJECT-TYPE
SYNTAX INTEGER(0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The maximum length in octets of an SNMP message
which this SNMPng engine will accept using any
transport mapping.
"
::= { snmpV3MPCMIBObjects 2 }
SnmpNgSecurityModel ::= TEXTUAL-CONVENTION
Harrington/Wijnen Expires November 1977 [Page 17]
\
Draft Architecture for SNMPng May 1997
STATUS current
DESCRIPTION "An identifier that uniquely identifies a model of
security subsystem within the SNMPng Framework.
"
SYNTAX INTEGER(0..2147483647)
SnmpNgSecurityIdentity ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "A octet string which contains data in a format
defined by a security model which identifies a
unique <thing> for which messages may be generated.
For example, a securityIdentity for user-based
security contains a user; a securityIdentity for
community-based security contains a community.
The format is not restricted to human-readable text.
"
SYNTAX OCTET STRING (SIZE (0..32))
SnmpNgLoS ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "A level of security at which SNMP messages can be
sent; in particular, one of:
noAuth - without authentication and without privacy,
auth - with authentication but without privacy,
priv - with authentication and with privacy.
"
SYNTAX INTEGER { noAuth(1), auth(2), priv(3) }
SnmpNgGroupName ::= 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))
SnmpNgContextName ::= 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))
END
Harrington/Wijnen Expires November 1977 [Page 18]
\
Draft Architecture for SNMPng May 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.
SNMPng allows implementations to add support for features of SNMPv1
and SNMPv2c, and to coexist with SNMPv1 and SNMPv2c engines, but
this document does not provide guidelines for that coexistence.
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.
For any subsystem model, the model definition is constrained to using
the abstract data elements, defined in this document, for transferring
data between the subsystem and any other subsystem. (Note that the
model definition is so constrained, but implementations are not so
constrained).
7.1. Security Model Design Requirements
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
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, how secrets are configured, and how security entities
map to groups.
For privacy, the Security model defines what portion of the message
is encrypted.
Harrington/Wijnen Expires November 1977 [Page 19]
\
Draft Architecture for SNMPng May 1997
Security models are replaceable within the SNMPng 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.
Each Security model must define a mapping to be used between a unique
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
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 persistent data used for security should be SNMP-manageable, but
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.
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
Within any Local Processing model, there should be no reference to
any specific Security model, or any specific Message Processing and
Control model, or any data defined by a specific Security or Message
Processing and Control model.
A Local Processing model only processes PDUs which are destined for
processing by the current engine, according to the rules of the
Local Processing model.
Harrington/Wijnen Expires November 1977 [Page 20]
\
Draft Architecture for SNMPng May 1997
A Local Processing model must determine whether the specified group is
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
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
using SNMP, but the Local Processing model defines whether an
instantiation of the MIB is a conformance requirement.
7.3. Message Processing and Control Requirements
Within any Message Processing and Control model, there should be no
reference to any specific Security model or any specific Local
Processing model, or to any data defined by a specific Security or
Local Processing model.
The Message Processing and Control model must always (conceptually)
pass the complete PDU, i.e. it never forwards less than the complete
list of varbinds.
The Message Processing and Control model specifies how to determine
whether the PDU in a received message should be processed by the
current engine or by an application [FT].
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.
7.4. Applications
Applications are beyond the scope of this document, but there are
certain issues that must be clarified regarding the relation and
the abstract data elements used for transferring data between
applications and the engine.
7.4.1. Application Responsibilities
An application has the responsibility to define any MIB modules used
to provide application-specific services.
An engine supports one conceptual interface to applications, provided
using the abstract data elements for transferring data between the
engine and applications. It is implementation-specific how data passed
from the engine is routed to the appropriate application.
Harrington/Wijnen Expires November 1977 [Page 21]
\
Draft Architecture for SNMPng May 1997
No access control is applied to the PDU by the engine which passes the
PDU to the application. A PDU passed to an application must be a
complete PDU, i.e the engine never partially processes a PDU which
is to be passed to an application.
Harrington/Wijnen Expires November 1977 [Page 22]
\
Draft Architecture for SNMPng May 1997
8. Subsystems and Transferring Data Between Subsystems
Transfer of data between the subsystems is deliberately described
as a fixed set of abstract data elements which can be overloaded to
satisfy the needs of multiple model definitions.
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.
8.1. Standard Services of Message Processing and Control Models
8.1.1. Receive SNMP messages from the network
Upon receipt of an SNMPng message from the network, a Message Processing
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
the values of the MMS, the securityModel, the LoS, and the security
parameters block.
The Message Processing and Control will (conceptually) pass the
extracted MMS, the LoS, the message, and the block of security
parameters to the appropriate Security model.
The Security model, after completion of its processing, will return to
the Message Processing and Control model the group, the securityCookie,
the PDU-MMS, and the PDU.
In the event of an error in security processing, an errorCode may be
returned instead.
8.1.2. Send SNMP messages to the network
The Message Processing and Control model will pass a PDU, the
securityCookie, and all global data to be included in the message to
Harrington/Wijnen Expires November 1977 [Page 23]
\
Draft Architecture for SNMPng May 1997
the Security model.
The Security model will construct the message, and return the completed
message to the Message Processing and Control model, which will send
the message to the desired address using the appropriate transport.
8.1.3. Coordinate the Local Processing of a Received Request Message
The Message Processing and Control will receive the SNMP message
according to the process described in 8.1.1.
The Message Processing and Control model will specify how to determine
whether the request should be processed by the Local Processing model
or by an application [FT].
If the request should be processed locally, the Message Processing and
Control model will (conceptually) pass the PDU, the Group, the PDU-MMS,
and the LoS, to the Local Processing model.
It will accept a completed PDU containing the responsePDU
from the Local Processing model, and generate a response message
according to the process described in 8.1.2.
8.1.4. Forward Received Request Message to an Application
The Message Processing and Control will receive the SNMP message
according to the process described in 8.1.1.
The Message Processing and Control model will specify how to determine
whether the request should be processed by the Local Processing model
or by an application [FT].
If the request should be processed by an application [FT], the Message
Processing and Control model will assign an implementation-defined
handle to the message. The Message Processing and Control model will
specify how to determine, and will (conceptually) pass the SNMP
version, the LoS, the securityCookie, and the assigned handle to the
application [FT].
8.1.5. Generate a Request Message for an Application
The Message Processing and Control will receive a request for the
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
determine that it is a request message, and if so, skips local
processing of the PDU.
Harrington/Wijnen Expires November 1977 [Page 24]
\
Draft Architecture for SNMPng May 1997
The Message Processing and Control will generate the message according
to the process described in 8.1.2.
8.1.6. Forward Received Response Message to an Application
The Message Processing and Control will receive the SNMP message
according to the process described in 8.1.1.
The Message Processing and Control will determine which application is
awaiting a response, using the handle assigned to the transaction in
step 8.1.3
The Message Processing and Control will pass to the application the
LoS, the securityCookie, the PDU-MMS, and the PDU.
An Application, using the securityCookie, can determine the
securityIdentity on whose behalf the response should be processed.
8.1.7. Forward Received Notification Message to an Application
The Message Processing and Control will receive the SNMP message
according to the process described in 8.1.1.
The Message Processing and Control will determine to which application
traps should be forwarded.
DBH: is this true? isn't this a function of an application support
subsystem to de-multiplex traps to the appropriate application? Isn't
this necessarily part of SNMP, since the indication of the appropriate
application may need to be provided by the SNMP message (e.g. msgID)
The Message Processing and Control subsystem will pass to the
application the LoS, the securityCookie, the PDU-MMS, and the PDU.
An Application, using the securityCookie, can determine the
securityIdentity on whose behalf the notification should be processed.
8.1.8. Send a Notification
The Message Processing and Control subsystem accepts from an
application a request to send a notification message. The application
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
therefore are not subject to access control of their contents.
8.1.9. Send a Response Message from an Application
An application, using local information can determine the
securityCookie to use to generate the message.
Harrington/Wijnen Expires November 1977 [Page 25]
\
Draft Architecture for SNMPng May 1997
The application will pass to the Message Processing and Control
subsystem the securityCookie, the LoS, and the scopedPDU.
The Message Processing and Control will send the SNMP message
according to the process described in 8.1.2.
8.2. Standard Services Required of Security Models
8.2.1. 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 securityIdentity for whom the message was
generated.
If encrypted, decrypt the message
Additional requirements may be defined by the model, and additional
services provided by the model, but the model is constrained to use
only the defined abstract data elements for transferring data between
subsystems. Implementations are no so constrained.
return a securityCookie identifying the securityIdentity 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.
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
Given a PDU, LoS, MMS, and a securityCookie, the Security model
must determine the security parameters for the message, the contents
and format of which are defined by the model.
The Security model will return a message including the appropriate
security parameters, encrypted if required.
8.2.3. Provide mappings between security entities and securityCookies
Harrington/Wijnen Expires November 1977 [Page 26]
\
Draft Architecture for SNMPng May 1997
Given model-specific parameters to identify a securityIdentity,
an Security model must return a securityCookie
Given a securityCookie generated by this Security model, the Security
model must return model-specific data identifying the corresponding
securityIdentity.
8.3. Standard Services of a Local-Processing Model
8.3.1. Process a request
Given a PDU, Group, LoS, and PDU-MMS, a Local Processing model must
return a PDU processed according to the protocol rules defined by the
Local Processing model.
Harrington/Wijnen Expires November 1977 [Page 27]
\
Draft Architecture for SNMPng May 1997
9. Security Consideration
This document describes how the SNMPng uses 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.
Applications have access to data which is not secured. Applications
should take reasonable steps to protect the data from disclosure.
It is the responsibility of the purchaser of an SNMPng engine to
ensure that:
1) an implementation of this framework is fully compliant with
the rules laid down by this framework,
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 applications comply
with the rules of this framework relative to applications,
5) the Security model of the implementation(s) incorporated into
this framework satisfy the security needs of the organization
using the SNMPng engine,
6) the Local Processing model of the implementation(s) incorporated
into this framework satisfy the access control policies of the
organization using the SNMPng engine,
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 the applications associated with this engine should take
reasonable steps to protect the security and access control
configuration secrets from disclosure.
Harrington/Wijnen Expires November 1977 [Page 28]
\
Draft Architecture for SNMPng May 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 November 1977 [Page 29]
\
Draft Architecture for SNMPng May 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 November 1977 [Page 30]
\
Draft Architecture for SNMPng May 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 November 1977 [Page 31]
\
Draft Architecture for SNMPng May 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 November 1977 [Page 32]
\
Draft Architecture for SNMPng May 1997
Table of Contents
0. Change Log 2
1. Introduction 4
1.1. A Note on Terminology 4
2. Overview 5
3. An Evolutionary Architecture - Design Goals 6
3.1. Encapsulation 6
3.2. Cohesion 6
3.3. Hierarchical Rules 6
3.4. Coupling 7
4. Abstract Functionality 9
4.1. Message Processing and Control 9
4.1.1. Transport Mappings 9
4.1.2. SNMP-Based Message Formats 9
4.1.3. Application-Based Message Formats 9
4.1.4. Protocol Instrumentation 9
4.2. Security 10
4.3. Local Processing 10
4.3.1. Structure of Management Information 10
4.3.2. Textual Conventions 11
4.3.3. Conformance Statements 11
4.3.4. Protocol Operations 11
4.4. Applications 11
4.5 Coexistence 11
5. Abstract Data Elements of the Architecture 13
5.1 engineID 13
5.2. SecurityIdentity 13
5.3. Level of Security 13
5.4. Groups 13
5.5. Contexts 13
5.6. ContextEngineID 14
5.7. ContextName 14
5.8. Naming Scope 14
5.9. Scoped-PDU 14
5.10. PDU-MMS 14
5.11. Security Configuration Datastore 14
5.12. Local Configuration Datastore 14
6. Textual Conventions for the SNMPng Architecture 16
7. Model Design Requirements 19
7.1. Security Model Design Requirements 19
7.2. Local Processing Model Design Requirements 20
7.3. Message Processing and Control Requirements 21
7.4. Applications 21
7.4.1. Application Responsibilities 21
8. Subsystems and Transferring Data Between Subsystems 23
8.1. Standard Services of Message Processing and Control Models 23
8.1.1. Receive SNMP messages from the network 23
8.1.2. Send SNMP messages to the network 23
8.1.3. Coordinate the Local Processing of a Received Request Message 24
8.1.4. Forward Received Request Message to an Application 24
8.1.5. Generate a Request Message for an Application 24
8.1.6. Forward Received Response Message to an Application 25
8.1.7. Forward Received Notification Message to an Application 25
8.1.8. Send a Notification 25
8.1.9. Send a Response Message from an Application 25
8.2. Standard Services Required of Security Models 26
8.2.1. validate the security-stamp in a received message 26
8.2.2. security-stamp a message 26
8.2.3. Provide mappings between security entities and securityCookies 26
8.3. Standard Services of a Local-Processing Model 27
8.3.1. Process a request 27
9. Security Consideration 28
10. References 29
11. Editor's Addresses 31
12. Acknowledgements 32
Harrington/Wijnen Expires November 1977 [Page 33]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/