Architecture for the Next Generation
                Simple Network Management Protocol (SNMPng)
                               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-00.txt>

                   <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 framework, subsystem, 2) a security framework, subsystem, and
3) a local processing framework. subsystem.

Harrington/Wijnen         Expires October November 1977        [Page  1]
\

0.  Change Log

[version 1.8]
        1. changed filename 2.2]
 . fix PDU back to internet-drafts assigned name
[version 1.7]
        1. Truncate lines scopedPDU where appropriate
 . MIB definitions contained some terms that need defining (MMS, etc)
 look them up and add to 72 (more "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 done)
        2. Prepare for pagination
        3. Added references section
        4. Let table derived from the
 securityCookie.
 . eliminated requirement of contents be generated
[version 1.6]
        1. added abstract
        2. davel's comments
        3. bert's comments
        4. reverted group to QoS <users> mapping, since it was less work.
        5. completed section 8
        6. Security Considerations, etc
        7. table movement
 of contents
[version 1.5]
        1. add goals/constraints from issues list
        2. add traps to application eliminates the need for this mapping.
 . eliminated "end-user"; substitutes security entity.
 . removed discussion of proxy traps as App
        3. move ngMIB to arch part of LPM, replaced with discussion
 of notifications sent/received by application.
 . separated architectural textual conventions from LPM doc
        4. define LCD versus SCD
        5. copy Bert's 2.x that apply to framework
        6. modify Message definition MPC-specific MIB
 (put TCs in architecture doc, objects in MPC doc)
 . changed security entity to better match Bert's ASN.1 securityIdentity
[version 1.4]
        1. modified intro
        2. added section on design principles/goals
        3. added section on message contents and service interfaces
        4. defined LP-F versus LP-M
        5. 2.1]
 . changed Quality of Service (QoS) to Level of Security (LoS)
 . changed QoS field to msgFlags
[version 1.3]
        1. (includes LoS plus reportFlag)
 . modified title from Security and Framework Evolution to
           Next Generation
        2. "Abstract Functionality"
 . expanded section 4 - architectural design goals
        3. subsystem descriptions to include introductory text on
 SMI, textual conventions, conformance, protocol operations, SNMP MIB,
 coexistence, etc.
 . added reference citations as needed
 . replaced all acronyms "interface" with "abstract data elements to transfer data"
 to avoid the new acronyms

Harrington/Wijnen         Expires October 1977        [Page  2]
\

1. Introduction

A management system contains: several (potentially many) nodes, each
with dreaded "interface = API" assumption.
 . modified scopedPDU text to permit a processing entity, termed an agent, snmpv1 community-scoped PDU,
 including one which has access uses the community to
management instrumentation; at least one management station; and, control proxy
 i.e snmpv3 uses engineID/contextName for naming scope
 snmpv1 uses community alone for naming scope
 a
management protocol, 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]
\

Harrington/Wijnen         Expires November 1977        [Page  3]
\

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 a framework an architecture which
can evolve to realize effective SNMP network management in a variety
of configurations and environments. The framework 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

For the purpose of exposition,

SNMP version 1 (SNMPv1), is the original Internet-standard Network
Management Framework, as described in RFCs 1155, 1157, and 1212, is
termed the 1212.

SNMP version 1 framework (SNMPv1). A partially-updated
Internet-standard Network Management framework , 2 (SNMPv2) is an updated design of portions of SNMPv1,
as described in RFCs 1902-1908, is termed the SNMP version 2 framework (SNMPv2).
The current framework, meant to complement the SNMPv2 framework,
is termed the 1902-1908.

SNMP next generation framework (SNMPng).

SNMPng provides a framework for the (SNMPng) is an architecture designed to allow
an orderly evolution of multiple
(sub-)frameworks. SNMP subsystems. This document describes the
SNMPng architecture.

Throughout the rest of this document, the term Framework subsystem will
refer to an abstract and incomplete specification of a portion of
SNMPng, that will be further refined by a Model model specification.

A Model model describes a specific design of a Framework, 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 Framework, subsystem, conforming to a
specific Model. model.

Harrington/Wijnen         Expires October November 1977        [Page  3]  4]
\

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. 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 October November 1977        [Page  4]  5]
\

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.

Harrington/Wijnen         Expires October 1977        [Page  5]
\

The SNMPng architecture uses the hierarchical approach by defining
frameworks,

Harrington/Wijnen         Expires November 1977        [Page  6]
\

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, 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.
Cross-references between document describing the subsystems should be
limited

To avoid specifying fixed interfaces, which would constrain a vendor's
choice of implementation strategies, SNMPng defines a set of abstract
data elements to Framework be used for (conceptually) transferring data between
subsystems in documents which describe subsystem or Model defined interfaces wherever possible. 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]
\

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 October November 1977        [Page  6]  8]
\

4.0.

4. Abstract Functionality

The architecture described here is composed of four "major" frameworks, subsystems, each
capable of being defined as different models, and models which may be
implemented as modules which can be replaced
or supplemented as the growing needs of network management require.

The major frameworks subsystems are a Message Processing and Control Framework, subsystem, a
Security Framework, subsystem, a Local Processing Framework, and Applications.
Interfaces between the major frameworks are deliberately abstract subsystem, and
fixed. An SNMPng engine is comprised of implementations of an Application
Support subsystem.

The term "engine" refers to a combination of Message Processing and
Control Framework, a subsystem(s), Security Framework, subsystem(s), and
a  Local Processing Framework.
subsystem(s). Applications are external processes which use the engine
to send or receive SNMP messages, or otherwise use the engine. services of the
SNMP engine, to accomplish their tasks.

4.1. Message Processing and Control

An

The Message Processing and Control subsystem of an SNMP engine
interacts with the network using SNMP messages, and interacts with
applications through using data elements defined by the Message Processing
and Control Framework.

Messages being 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 use using a format
defined by
transport mechanism. It is the purpose of Transport Mapping documents
to define how SNMP protocol. The possible contents, maps onto transport domains.

A Message Processing and their
format, Control model defines which Transport Mappings
documents are also defined supported by the model.

4.1.2. SNMP-Based Message Formats

SNMP protocol. 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 may be protocol-defined or may be implementation-specific. The
possible contents, are defined by the Message Processing and their format, may be protocol-defined or
implementation-specific.

The processing of messages must be controlled to ensure Control Model.
Note that applicable
rules these are followed during the processing. Some not SNMP messages, such as but are abstract data elements
used to transfer data between the Message Processing and Control
subsystem and an
SNMP Get-Request received from Application Support subsystem.

4.1.4.  Protocol Instrumentation

Harrington/Wijnen         Expires November 1977        [Page  9]
\

It is the network purpose of a Management Information Base for objects SNMP document
to define managed by this
engine, can be processed directly by objects which describe the engine; other messages must be
passed to external processes, such as a remote SNMP engine or an
application. Some messages require security; others don't. Some engines
support multiple versions behavior of an SNMP messages and/or PDU formats.

The engine must control the order
engine.

A Message Processing and Control model defines which SNMP MIB Module
documents are supported to instrument the combinations of options used
in processing and generating messages. 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.

Harrington/Wijnen         Expires October 1977        [Page  7]
\

4.3. Local Processing

Local Processing deals with the contents of messages. It interacts with messages, called the underlying operating system PDU,
providing access to instrumentation and applying access control
according the instrumentation which rules of the Local Processing model being used.

An overview of management information and processing operations is
represented as managed objects in SNMP.
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 entity securityIdentity on whose behalf a request is generated.

4.4. Applications

Applications are processes A Local
Processing model defines which interact with the SNMP engine using
messages that may use formats defined by a protocol, or that may use
implementation-specific formats.

Applications set of documents are developed used to achieve certain goals. They use define
the SNMP
engine mechanisms to achieve their goals, but their purpose is outside the scope realize access control within that model.

4.3.1.  Structure of the SNMP protocol definitions.

For example, management stations execute applications which monitor
and control managed elements. A proxy application may forward a
message from one SNMP engine to another (an snmp proxy), or convert Management Information

Management information is viewed as a message from one SNMP format to another (also an snmp proxy), or
from SNMP to another protocol ( collection of managed objects,
residing in a foreign proxy). The purpose and
design virtual information store, termed the Management
Information Base (MIB).  Collections of applications related objects are beyond defined
in MIB modules.

It is the scope purpose of the SNMPng engine
architecture.

4.5. Definition a Structure of SNMPng acronyms and terms:

   MPC-F   - Message Processing and Control Framework
   MPC-M   - Message Processing and Control Model
   MPC-I   - Message Processing Management Information
document to establish the syntax for defining objects, modules, and Control Implementation

   SF-F    - Security Framework
   SF-M    - Security Framework Model
   SF-I    - Security Framework Implementation

   LP-F    - Local Processing Framework
   LP-M    - Local Processing Model
   LP-I    -
other elements of managed information.

A Local Processing Implementation

   LCD     - Local Configuration Datastore
   SCD     - Security Configuration Datastore

Harrington/Wijnen         Expires October 1977        [Page  8]
\

5. Elements of model defines which SMI documents are supported
by the Framework

This section contains definitions of terms used model.

\

4.3.2.  Textual Conventions

When designing a MIB module, it is often useful to define new types
similar to those defined in the interfaces
between Frameworks

5.1. Groups

A Group identifies a set of zero or SMI, but with more security entities on whose
behalf SNMP messages precise semantics,
or which have special semantics associated with them. These newly
defined types are being processed.

5.2. Quality of Service

Messages termed textual conventions.

A Local Processing model defines which Textual Conventions documents
are supported by the model.

4.3.3.  Conformance Statements

It may require different levels of security. The term used to
refer be useful to define the acceptable lower-bounds of
implementation, along with the actual level of security required is "Quality of Service" or QoS.

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 QoS; all processing (security, access
control, applications, message processing and control) implementation
achieved.  It is required
to abide the specified QoS.

5.3. Contexts

An SNMP context is a collection of management information
accessible by an SNMP agent. An item purpose of management information
may exist in more than one context. An SNMP agent potentially
has access Conformance Statements to many contexts.

5.4. Scoped-PDU

A scoped-PDU contains a Naming-Scope that unambiguously
identifies an SNMP agent and define
the context, (locally) accessible
by that agent, to 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 management information
in the SNMP-PDU refers.

A Naming-Scope contains messages encapsulate a contextID that unambiguously identifies Protocol Data Unit (PDU). It is the SNMP agent which has (local) access
purpose of a Protocol Operations document to define the management
information referred operations
of the protocol with respect to by the contextName and processing of the SNMP-PDU. PDUs.

A Naming-Scope contains a contextName Local Processing model defines which unambiguously identifies
an SNMP context accessible Protocol Operations documents
are supported by the model.

4.4. Applications

Applications are developed to achieve certain goals. They use the SNMP agent
engine to which achieve their goals, and interact with the SNMP-PDU
is directed or from which engine in a manner
consistent with the SNMP architecture, but the SNMP-PDU purpose of specific
applications is originated.

An implementation outside the scope of a the SNMP architecture.

Applications interact with the SNMP engine using application-support
messages whose format is defined by the Message Processing and Control Model
must determine if the contextID
model in the scopedPDU use.

4.5 Coexistence

The purpose of a received message
matches the snmpNgEngineID of the current engine. If so, the scopedPDU
should be processed by the Local Processing implementation.

Harrington/Wijnen         Expires October 1977        [Page  9]
\

5.5. Security Configuration Datastore

Each Security Model may need an evolutionary architecture is to retain its own set of information about permit new models
to replace or supplement existing models. The interactions between
models could result in incompatibilities, security entities, mechanisms, "holes", and policies. This set
other undesirable effects.

The purpose of information a Coexistence document is called the SNMPng entity's Security Configuration Datastore (SCD).
In order to allow an SNMPng entity's SCD detail recognized anomalies
and to describe required and recommended behaviors for resolving the
interactions between models within the architecture.

\

It would be remotely configured,
portions may need 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 accessible as managed objects.

5.6. Local Configuration Datastore

Each Local Processing Model may need prepared separately
from model definition documents, to retain its own set of
information about access control, naming scopes, describe and policies.
This set resolve interaction
anomalies between a model definition and one or more other model
definitions.

\

5. Abstract Data Elements of information is called the SNMPng entity's Local
Processing Configuration Datastore (LCD).
In order to allow an SNMPng entity's LCD 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 remotely configured,
portions may need
able to be accessible as managed objects.

\

6. Model Design Requirements uniquely identified. The basic design elements come from SNMPv2u mechanism by which this can be
done is defined the Message Processing and SNMPv2*, as
described Control model in RFCs 1909-1910, and from a set of internet drafts.
these are use.

DBH: this is so the two most popular de facto "administrative framework"
standards that include security and access control IP or MAC address can be used as the engineID
for SNMPv2.

SNMPv1 and SNMPv2c [RFC1901] are two administrative frameworks based
on communities to provide trivial authentication and access control.
SNMPng allows old snmpv1 implementations to add support for features of SNMPv1
and SNMPv2c, and to coexist with SNMPv1 and SNMPv2c engines, but which are being retrofitted into this document does not provide guidelines
architecture for use with old snmpv1 management stations. A partial
alternative would be to define the engineID MIB as a separate module
that coexistence.

6.1. Security Model Design Requirements

Received messages must can be validated 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 model of message can be generated. The term is deliberately abstract to allow
the Security
Framework before being processed by security subsystem to define the Local Processing Framework.
Validation includes authentication format and privacy processing if needed,
but nature of the
identities it is explicitly allowed to send messages which do not require
authentication or privacy.

A received message will contain a specified Quality use.

Sample securityIdentities include communities [RFC1157], parties
[RFC1445], and users [RFC1910].

5.3. Level of Service 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

Messages may define mechanisms to provide additional
security features, but require different levels of security. The acronym LoS is restricted
used to refer to using the interface, defined in
this document, between the Message Processing level of security.

SNMPng recognizes three levels of security:
    - without authentication and Control Framework without privacy (noAuth/noPriv)
    - with authentication but without privacy (auth/noPriv)
    - with authentication and
the Security Framework.

Each Security Model may allow multiple security mechanisms to be used
concurrently within with privacy (auth/Priv)

Every message has an implementation of the model. Each Security Model
defines how to determine which protocol to use, given the QoS 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 parameters passed in the message. Each Security Model, with
its associated protocol(s) defines how the sending/receiving entities on whose
behalf SNMP managed objects are identified, how secrets are configured, and how security entities
map being processed, subject to groups.

For privacy, the Security Model defines what portion access
control policies common to all members of the message group.

5.5. Contexts

An SNMP context is encrypted.

Security Models are replaceable within the SNMPng Framework. Multiple
Security Model Implementations may exist concurrently within a collection of management information

\

accessible by an SNMP engine.
The number An item of Security Models defined by the management information
may exist in more than one context. An SNMP community should
remain small engine potentially
has access to promote interoperability. It many contexts.

5.6. ContextEngineID

A contextEngineID is required a field in a message to uniquely identify the
engine that an
implementation of contains the User-Based Security Model be used context which realizes the managed objects
referenced in all
engines the PDUs.

5.7. ContextName

An octet string used to ensure at least name a minimal level of interoperability. context. Each Security Model context must define a mapping to be used between a unique
entity uniquely
named within the model's SCD, and a securityCookie. A securityCookie

\

is an implementation-specific handle engine.

5.8. Naming Scope

The data necessary to uniquely identify the unique entity to
which it maps. If an implementation supports multiple Security Models,
the securityCookie must include a mechanism for determining which
Security Model SCD context within an
administrative domain is referenced. called a naming scope.

The securityCookie, in combination
with the engineID format of the engine which instantiates the securityCookie,
can be used as naming scope data is defined by a globally-unique identifier for Message Processing
and Control model.

5.9. Scoped-PDU

A scopedPDU contains a security entity. The
type of Naming-Scope and a securityCookie is an OCTET STRING, but PDU.

The Naming Scope unambiguously identifies, within the format of administrative
domain, the
contents is implementation-specific. It is important context to note that
since the securityCookie may be accessible outside the engine, which the
securityCookie must not disclose any sensitive data, such as by
including passwords in open text SNMP management information in
the securityCookie.

Each Security Model defines the MIBs required for security processing,
including any MIBs required for the protocol(s) supported. PDU refers.

The MIB
formats must be PDU format is defined concurrently with by the procedures which use Local Processing model in use, or
by a document referenced by the MIB. The MIBs are subject Local processing model.

5.10. PDU-MMS

the maximum size of a scopedPDU to normal security and access control
rules.

The persistent data used for security should be SNMP-manageable, but included in a response message,
given the Security Model defines whether an instantiation amount of reserved space in the MIB is a
conformance requirement. The mapping between a securityCookie and message for the
unique anticipated
security entity within the engine must be able parameters.

5.11. Security Configuration Datastore

Each Security model may need to be determined
using SNMP, if the MIB is instantiated retain its own set of information about
security entities, mechanisms, and access control policy
allows.

Protocols should be uniquely identified using Object Identifiers.
Enterprise-specific protocols should be defined within policies. The collection of these,
possibly multiple, sets of information is referred to collectively as
the enterprise
subtree. A protocolID MIB should be defined for IETF standard
protocols for authentication and privacy.

Within any SNMPng engine's Security Model, there should be no reference Configuration Datastore (SCD).
In order to any specific
Local Processing Model, or allow an SNMPng engine's SCD to data defined by a be remotely configured,
portions may need to be accessible as managed objects.

5.12. Local Processing Model.

6.2. Configuration Datastore

\

Each Local Processing Model Design Requirements

A Local processing Model only processes scopedPDUs which contain a
contextID which matches the engineID model may need to retain its own set of the current engine.

A Local Processing Model must determine whether the specified group
information about access control, naming scopes, and policies.
The collection of these, possibly multiple, sets of information is
allowed
referred to perform the requested operation on the managed objects in
the PDU. For messages with a QoS specifying authentication, the group
used for access control must be the same group provided by collectively was the Message
Processing and Control Framework.

A SNMPng engine's Local Processing Model specifies the rules by which access control
and PDU processing are
Configuration Datastore (LCD). In order to allow an SNMPng engine's
LCD to be done. A model remotely configured, portions may define mechanisms to
provide additional processing features, but is restricted need to using the
interface, defined in this document, between be accessible
as managed objects.

\

6. Textual Conventions for the Message Processing
and Control Framework and the Local Processing Framework. 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 }

\

The persistent data

-- Textual Conventions used throughout the SNMPng Framework

SnmpNgEngineID ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "An SNMPng engine's administratively-unique identifier.

                 The value for local processing should this object may not be manageable
using SNMP, but the Local Processing Model defines whether all zeros or
                 all 'ff'H.

                 The initial value for this object may be configured
                 via an
instantiation 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 MIB is a conformance requirement.

Within any Local Processing Model, there should 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 no reference to
any assigned '000002b8'H.

                  2) The remaining eight octets are the cookie whose
                     contents are determined via one or more
                     enterprise specific Security Model, 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

\
    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.

6.3. Message Processing and Control Requirements

The MPC Model must always pass the complete scopedPDU, i.e. it never
forwards less than the complete list of varbinds.

The MPC Model must determine whether security model which identifies a scopedPDU should
                  unique <thing> for which messages may be processed
by the current engine or by an application. If generated.

                  For example, a received message securityIdentity for user-based
                  security contains a scopedPDU with user; a contextID matching the engineID of the
current engine, then the scopedPDU should be passed to the Local
Processing Model implementation securityIdentity for processing.

If the MPC Model determines that the contextID does
                  community-based security contains a community.
                  The format is not match the
engineID of the restricted to human-readable text.
                 "
    SYNTAX       OCTET STRING (SIZE (0..32))

SnmpNgLoS ::= TEXTUAL-CONVENTION
    STATUS       current engine, then the message parts, as specified
    DESCRIPTION "A level of security at which SNMP messages can be
                 sent; in
the interface section, are passed to 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 proxy application for
processing.

6.4. Applications

Applications set of zero or
                  more security entities on whose behalf SNMP managed
                  objects are beyond being processed, subject to access
                  control policies common to all members of the scope group.
                 "
    SYNTAX        OCTET STRING (SIZE(1..16))

SnmpNgContextName ::= TEXTUAL-CONVENTION
    STATUS        current
    DESCRIPTION  "A name which uniquely identifies a set of this document, but earlier
attempts to define
                  management information realized by an SNMP Framework considered proxy engine.
                 "
    SYNTAX       OCTET STRING (SIZE (0..32))

END

\

7. Model Design Requirements

The basic design elements come from SNMPv2u and SNMPv2*, as
described in RFCs 1909-1910, and from a possible
function set of the protocol. SNMPng does not mandate support for proxy
in an SNMPng implementation.

6.4.1. A Proxy Application

The SNMPng Framework explicitly considers proxy to be an external
application. There internet drafts.
these are certain issues that must be clarified regarding the relation and interface between proxy two most popular de facto "administrative framework"
standards that include security and the engine, however.

A proxy application has the responsibility to define any MIBs used
to forward message contents, access control for SNMPv2.

SNMPv1 and SNMPv2c [RFC1901] are two administrative frameworks based
on communities to determine the address provide trivial authentication and
identity to whom the message should be forwarded.

An engine supports at most one interface to proxy applications; if an
implementation wishes access control.
SNMPng allows implementations to add support multiple proxy applications, the
determination of which type for features of proxy, SNMPv1
and SNMPv2c, and hence which proxy application
should handle it, should be handled by the single proxy application to
which the engine has an interface.

If proxy is supported, the engine passes all scopedPDUs coexist with a
contextID that SNMPv1 and SNMPv2c engines, but
this document does not match the current engine's snmpNgEngineID to
the proxy application. No access control is applied to the message by
the engine which passes the request to the proxy application. A
scopedPDU passed to a proxy application must be a complete scopedPDU.

\

\

7. The SNMPng message format:

DEFINITIONS ::=3D BEGIN

snmpNgMessage ::=3D
    SEQUENCE {
        -- global parameters
        version
            INTEGER { snmpng (3) },
        msgID
            INTEGER,
        MMS
            INTEGER,

        QoS
            OCTET STRING (SIZE(1)),
                   --  .... ..00   noAuth/noPriv
                   --  .... ..01   auth/noPriv
                   --  .... ..1.   auth/priv
                   --  .... .1..   reportableFlag

        securityModel
            snmpNgSecurityModel,

        -- security model-specific parameters
        securityParameters
            OCTET STRING, -- format 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 Security Model

        -- local-processing model-specific data
        data
            ScopedPduData
    }

    ScopedPduData ::=3D
        CHOICE {
            plaintext
                ScopedPDU,
            encrypted
                OCTET STRING    -- encrypted ScopedPDU
        }

    scopedPDU ::=3D
        SEQUENCE {
            contextID
                snmpNgEngineID,
            contextName
                snmpNgContextName, a specific
model of another subsystem.

For any subsystem model, the model definition is constrained to using
the abstract data
                ANY -- e.g. PDUs as elements, defined in RFC1905
        }
END

\

7.1. SNMP version

The SNMP version identifies this document, for transferring
data between the version of subsystem and any other subsystem. (Note that the MPC framework in use.
For purposes of discouraging,
model definition is so constrained, but implementations are not preventing, the replacement of
the Local Processing Model, the SNMP version also implies the version so
constrained).

7.1. Security Model Design Requirements

Received messages must be validated by a model of the Local Processing Model.

7.2. msgID

The msgID Security
subsystem.
Validation includes authentication and privacy processing if needed,
but it is used by SNMP engines explicitly allowed to coordinate the processing of the send messages which do not require
authentication or privacy.

A received message by different portions will contain a specified Level of the framework.

Note that the requestID Security to be
used during local processing identifies 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
request, not model definition is constrained to using
(possibly a subset of) the message that carried 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 request, LoS and therefore might
not be equal the
security parameters relevant to the msgID.

7.3. MMS

The maximum message size supported by 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 sender Security model defines what portion of the message.

7.4. securityModel

Multiple security message
is encrypted.

\

Security models are replaceable within the SNMPng subsystem. Multiple
Security model Implementations may exist concurrently in the within an engine.
This model
The number identifies which security model should be used to
provide security processing for of Security models defined by the message. The mapping SNMP community should
remain small to the
appropriate implementation within the agent promote interoperability. It is done in required that an
implementation-dependent manner.

The initial model
implementation of the SNMPng Security Framework is the User-Based Security Model model be used in all
engines to ensure at least a minimal level of the SNMPng interoperability.

Each Security Framework.

7.5. QoS

The QoS field contains flags model must define a mapping to control the processing of the message.

If be used between a unique
securityIdentity within the reportableFlag model's SCD, and a securityCookie. A
securityCookie is set, then reportPDUs are allowed to be
returned an implementation-specific handle to identify the sender under those conditions
securityIdentity to which cause the
generation of reportPDUs. it maps. If an implementation supports
multiple Security models, the reportableFlag is zero, then a
reportPDU securityCookie must not be sent. include a mechanism
for determining which Security model SCD is referenced. The reportableFlag should always be zero
when
securityCookie, in combination with the message is engineID of the engine which
instantiates the securityCookie, can be used as a reportPDU, globally-unique
identifier for a responsePDU, or securityIdentity. The type of a trapPDU.

If the auth flag securityCookie is set, then an
OCTET STRING, but the security implementation format of the contents is
implementation-specific. It is required important to identify note that since the entity on whose behalf a request is generated and to
authenticate such identification. If
securityCookie may be accessible outside the auth flag is zero,
authentication of engine, the identification is
securityCookie must not required.

If disclose any sensitive data, such as by
including passwords in open text in the priv flag is set, then securityCookie.

Each Security model defines the MIB moduless required for security implementation is
processing, including any MIB modules required
to protect the data within an SNMP operation from disclosure, i.e. to
encrypt for the data. If security
mechanism(s) supported. The MIB modules must be defined concurrently
with the priv flag is zero, then procedures which use the security

\

implementation does not need MIB module. The MIB modules are
subject to protect the normal security and access control rules.

The persistent data using encryption.
It is used for security should be SNMP-manageable, but
the Security model defines whether an explicit requirement instantiation of the SNMPng Framework that if privacy MIB is selected, then authentication of a
conformance requirement. The mapping between a securityCookie and the identification is required,
i.e. priv flag can only
unique securityIdentity within the engine must be set able to be
determined using SNMP, if auth flag is also set.

7.6. security parameters

This octet string is not interpreted by the MPC-F. This data MIB is used
exclusively by the security model, instantiated and access control
policy allows.

Protocols should be uniquely identified using Object Identifiers.
Enterprise-specific protocols should be defined within the contents enterprise
subtree. A protocolID MIB should be defined for IETF standard
protocols for authentication and format of the 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 is defined by the security model.

7.7. scopedPDU

The scopedPDU contains a PDU specific Security or Message
Processing and the scope in Control model.

A Local Processing model only processes PDUs which it is to be
processed, as defined are destined for
processing by the ID of current engine, according to the engine and rules of the context within
which
Local Processing model.

\

A Local Processing model must determine whether the management data is realized on that engine.

7.7.1. contextID

This specified group is
allowed to perform the engineID of the engine which realizes requested operation on the managed objects
referenced in
the PDUs.

7.7.2. contextName

This is PDU, according to the name rules of the context, on Local Processing model being
used.

A Local Processing model specifies the contextID-specified engine, rules by which realizes the managed objects referenced within 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 PDUs.

7.7.3.
abstract data elements defined in this document for transferring data
between subsystems.

The persistent data contains used for local processing should be manageable
using SNMP, but the PDUs. The Local Processing Model model defines the
content and format whether an
instantiation of the PDUs. The initial 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 of the SNMPng or any specific Local
Processing Framework supports SNMPv2 PDUs as defined in RFC1905.

\

8. The Frameworks and their standard "services" interfaces

Each Framework defines certain standard services, accessible
through protocol-fixed interfaces.

Each Model for a Framework must provide the standard services,
but how it performs the service is model, or to any data defined by the model.

8.1. Standard Services of a specific Security or
Local Processing model.

The Message Processing and Control Models

8.1.1. Receive SNMP messages from the network

Upon receipt of an SNMPng message from the network, an MPC-M
will extract model must always (conceptually)
pass the MMS, and complete PDU, i.e. it never forwards less than the QoS, complete
list of varbinds.

The Message Processing and will Control model specifies how to determine where the
block of security parameters start in
whether the message.

It will, PDU in an implementation-defined manner, establish a mechanism
for coordinating all processing regarding this received message,
e.g. it message should be processed by the
current engine or by an application [FT].

A model may assign a "handle" define mechanisms to the message.

The MPC-M will pass the MMS, the QoS, a pointer provide additional processing
features, but is constrained to using the message, and a
pointer to abstract data elements
defined in this document for transferring data between subsystems.

7.4. Applications

Applications are beyond the block scope of security parameters to this document, but there are
certain issues that must be clarified regarding the implementation
of relation and
the Security Model specified in abstract data elements used for transferring data between
applications and the message header.

The Security Model, after completion of its processing, will return 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 Message Processing abstract data elements for transferring data between the
engine and Control implementation applications. It is implementation-specific how data passed
from the group, engine is routed to the
securityCookie, appropriate application.

\

No access control is applied to the scopedPDU-MMS, and PDU by the scopedPDU.

In engine which passes the event of an error in security processing, an errorCode may be
returned instead.

8.1.2. Send SNMP messages
PDU to the network

The MPC-M will pass application. A PDU passed to an application must be a scopedPDU,
complete PDU, i.e the securityCookie, and all global
data engine never partially processes a PDU which
is to be included in the message passed to the Security Model.

The Security Model will construct the message, an application.

\

8. Subsystems and return Transferring Data Between Subsystems

Transfer of data between the completed
message subsystems is deliberately described
as a fixed set of abstract data elements which can be overloaded to
satisfy the MPC-M, will will send the message needs of multiple model definitions.

Documents which define models to be used within this architecture are
constrained to the desired
address using the appropriate transport.

8.1.3. Coordinate abstract data elements for transferring data
between subsystems, possibly defining specific mechanisms for
converting the Local Processing abstract data into model-usable formats. This
constraint exists to allow subsystem and model documents to be
written recognizing common borders of a Received Request Message

The MPC will receive the SNMP message according subsystem and model.
Vendors are not constrained to the process
described recognize these borders in 8.1.1. their
implementations.

The Message Processing and Control implementation will compare the
contextID in the scopedPDU with its snmpNgEngineID. If they match, the
MPC will forward the scopedPDU architecture defines certain standard services to the Local Processing implementation.
The MPC will pass the scopedPDU, the Group, and the scopedPDU-MMS be provided by
between subsystems, and the Security Model implementation, plus architecture defines abstract data
elements to transfer the QoS, data necessary to perform the
Local Processing implementation.

\

It will accept services.

Each model definition for a completed scopedPDU containing subsystem must support the responsePDU
from standard service
interfaces, but whether, or how, or how well, it performs the LP-I, and generate a response message according to service
is defined by the
process described in 8.1.2.

8.1.4. Forward Received Request model definition.

8.1. Standard Services of Message to a Proxy Application

The MPC will receive the Processing and Control Models

8.1.1. Receive SNMP messages from the network

Upon receipt of an SNMPng message according to from the process
described in 8.1.1.

The MPC will determine whether network, a scopedPDU Message Processing
and Control model will, in an implementation-defined manner, establish
a mechanism for coordinating all processing regarding this received message
contains a contextID which differs from its snmpNgEngineID.
If message,
e.g. it does differ, and if a proxy application is supported by this
engine, the MPC will may assign an implementation-defined handle a "handle" to the message.

The MPC will determine, from the message header, the SNMP
version, the securityModel, the MMS, Message Processing and the QoS. It Control model will pass specify how to determine
the
proxy application values of the handle, MMS, the SNMP version, securityModel, MMS,
QoS, plus the securityCookie provided by LoS, and the Security Model
implementation.

8.1.5. Generate a Request Message for an Application security
parameters block.

The MPC Message Processing and Control will receive a request for the generation of a request message
from an application. The application has the responsibility for
providing (conceptually) pass the Destination Address,
extracted MMS, the SNMP version, LoS, the QoS desired, message, and the MMS block of
the current engine, the SecurityModel security
parameters to use, the securityCookie appropriate Security model.

The Security model, after completion of its processing, will return to
use, a scopedPDU containing
the desired operation, Message Processing and a handle used
for matching up an incoming response to the application making Control model the
request.

The MPC checks group, the verb in securityCookie,
the scopedPDU to determine that it is a
request message, PDU-MMS, and if so, skips local processing of the scopedPDU.

The MPC will generate the message according to PDU.

In the process described
in 8.1.2.

8.1.6. Forward Received Response Message to event of an Application

The MPC will receive the error in security processing, an errorCode may be
returned instead.

8.1.2. Send SNMP message according messages to the process
described in 8.1.1. network

The MPC Message Processing and Control model will determine which application is awaiting pass a response, using PDU, the handle assigned
securityCookie, and all global data to the transaction be included in step 8.1.3

The MPC will pass to the application the QoS, the MMS, message to

\

the Security
Model, the securityCookie, model.

The Security model will construct the scopedPDU-MMS, message, and return the scopedPDU.

The Application, using completed
message to the securityCookie, Message Processing and Control model, which will determine send
the end-user
on whose behalf message to the response should be processed.

\

8.1.7. Forward desired address using the appropriate transport.

8.1.3. Coordinate the Local Processing of a Received Notification Request Message to an Application

The MPC Message Processing and Control will receive the SNMP message
according to the process described in 8.1.1.

The MPC Message Processing and Control model will determine specify how to which application traps determine
whether the request should be forwarded.

The MPC will pass to processed by the Local Processing model
or by an application [FT].

If the QoS, request should be processed locally, the MMS, Message Processing and
Control model will (conceptually) pass the Security
Model, PDU, the securityCookie, Group, the scopedPDU-MMS, PDU-MMS,
and the scopedPDU.

The Application, using LoS, to the securityCookie, Local Processing model.

It will determine the end-user
on whose behalf the notification should be processed.

8.1.8. Generate a Trap Message

The MPC accepts from the LP-I accept a Destination Address, the QoS, the
SecurityModel, the Group, and completed PDU containing the scopedPDU.

The MPC uses responsePDU
from the group Local Processing model, and QoS to request generate a list of securityCookies
from the Security Model for security entities contained in the group.
For each securityCookie in the list, the MPC generates an SNMP response message
according to the process described in 8.1.2.

8.1.9. Send a Response

8.1.4. Forward Received Request Message from a Proxy to an Application

The MPC Message Processing and Control will send receive the SNMP message
according to the process described in 8.1.1.

The MPC will determine which application is awaiting a response, using
the handle assigned to the transaction in step 8.1.3

The MPC will pass to the application the QoS, the MMS, the Security
Model, the securityCookie, the scopedPDU-MMS, Message Processing and the scopedPDU.

The Application, using the securityCookie, Control model will specify how to determine
whether the end-user
on whose behalf the response request should be processed.

8.2. Standard Services Required of Security Models

8.2.1. validate the security-stamp in a received message

given a message, the MMS, QoS, and the security parameters from that
message, verify the message has not been altered, and authenticate
the identification of the security entity for whom the message was
generated.

If encrypted, decrypt the message

additional requirements may be defined processed by the model, but they
cannot require changes to the framework interface

\

return a securityCookie identifying the entity for whom the message
was generated and return the portions of the message needed for
further processing:
        a scopedPDU - a PDU enclosed Local Processing model
or by a header which contains an snmpID and a contextName
        QoS - the quality of service specified for security
                validation. The same quality of service must also
		be used during application of access control.
        MMS - [FT].

If the maximum size of a message able to request should be generated processed by this engine for an application [FT], the destination agent.
        scopedPDU-MMS - Message
Processing and Control model will assign an implementation-defined
handle to the maximum size of a scopedPDU message. The Message Processing and Control model will
specify how to be
                included in a response message, given determine, and will (conceptually) pass the amount of
                reserved space in SNMP
version, the message for LoS, the anticipated
                security parameters.
        acGroup - securityCookie, and the acGroup assigned handle to be applied for access control for
                the entity for whom the request was generated.

8.2.2. security-stamp a message

Given
application [FT].

8.1.5. Generate a scopedPDU, QoS, MMS, Request Message for an Application

The Message Processing and Control will receive a securityCookie, request for the Security Model
must determine
generation of an SNMP request message from an application. The
application has the security parameters responsibility for providing a Destination Address,
the message, SNMP version, the contents
and format of which are defined by LoS desired, the model.

The Security Model will return securityCookie to use, a message including
scopedPDU containing the appropriate
security parameters, encrypted if required.

8.2.3. Provide mappings between security entities desired operation, and securityCookies

Given model-specific parameters to identify a security entity, handle used for
matching up an SF-M must return a securityCookie

Given a securityCookie generated by this SF-M, incoming response to the SF-M must return
model-specific data identifying application making the corresponding security entity.

8.2.4. Provide mapping between group request.

The Message Processing and securityCookies

Given a group, the SF-M must return an array of securityCookies
identifying Control checks the entities which are members of verb in the specified group.

8.3. Standard Services of a Local-Processing Model

8.3.1. Process PDU to
determine that it is a request

Given a ScopedPDU, Group, QoS, message, and ScopedPDU-MMS, an LP-M must return
a scopedPDU processed if so, skips local
processing of the PDU.

\

The Message Processing and Control will generate the message according
to the protocol rules of process described in 8.1.2.

8.1.6. Forward Received Response Message to an Application

The Message Processing and Control will receive the LP-M

8.3.2. Generate SNMP message
according to the process described in 8.1.1.

The Message Processing and Control will determine which application is
awaiting a Trap

When an event occurs that requires response, using the generation of a trap, handle assigned to the LP-M
must transaction in
step 8.1.3

The Message Processing and Control will pass to the MPC a Destination Address, QoS, MMS, SecurityModel, a
Group, application the
 LoS, the securityCookie, the PDU-MMS, and a scopedPDU, according to the protocol rules of PDU.

An Application, using the LP-M.

\

\

9. Definitions

9.1. Definitions for securityCookie, can determine the Architectural Model for SNMPng

snmpNg-MIB DEFINITIONS ::=3D BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, snmpModules  FROM SNMPv2-SMI
    TEXTUAL-CONVENTION, TestAndIncr,
    RowStatus, AutonomousType, StorageType,
    TDomain, TAddress                          FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP            FROM SNMPv2-CONF;

snmpNgMIB MODULE-IDENTITY
    LAST-UPDATED "9703260000Z"     -- 26 Mar 1997, midnight
    ORGANIZATION "SNMPv3 Working Group"
    CONTACT-INFO "WG-email:   snmpv3@tis.com
                  Subscribe:  majordomo@tis.com
                              In message body:  subscribe snmpv3

                  Chair:      Russ Mundy
                              Trusted Information Systems
                  postal:     3060 Washington Rd
                              Glenwood MD 21738
                  email:      mundy@tis.com
                  phone:      301-854-6889

                  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
                 "
    DESCRIPTION  "The snmpNg engine MIB"
    ::=3D { snmpModules xx }

-- Administrative assignments

snmpNgMIBObjects      OBJECT IDENTIFIER ::=3D { snmpNgMIB 1 }

\

snmpNgMIBConformance  OBJECT IDENTIFIER ::=3D { snmpNgMIB 2 }

-- Textual Conventions used throughout
securityIdentity on whose behalf the SNMPng Framework

snmpNgGroupName ::=3D TEXTUAL-CONVENTION
    STATUS        current
    DESCRIPTION  "An octet string representing response should be processed.

8.1.7. Forward Received Notification Message to an Application

The Message Processing and Control will receive the name of a group
                  for use in accordance with SNMP message
according to the SNMPng Architectural
                  Framework.
                 "
    SYNTAX        OCTET STRING (SIZE(1..16))

snmpNgContextName ::=3D TEXTUAL-CONVENTION
    STATUS        current
    DESCRIPTION  "An SNMPng context name process described in 8.1.1.

The Message Processing and Control will determine to which unambiguously
                  identifies application
traps should be forwarded.
DBH: is this true? isn't this a set function of management information
                  directly accessible by an application support
subsystem to de-multiplex traps to the Local Processing Module
                  (implementation or LP-I) appropriate application? Isn't
this necessarily part of an SNMPng engine.
                 "
    SYNTAX       OCTET STRING (SIZE (0..32))

snmpNgQoS ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "A level SNMP, since the indication of security at which SNMPng messages can the appropriate
application may need to be
                 sent; in particular, one of:
                   noAuth - without authentication provided by the SNMP message (e.g. msgID)

The Message Processing and without privacy,
                   auth   - with authentication but without privacy,
                   priv   - with authentication Control subsystem will pass to the
application the LoS, the securityCookie, the PDU-MMS, and with privacy.
                "
    SYNTAX       INTEGER { noAuth(1), auth(2), priv(3) }

snmpNgEngineID ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "An SNMPng entity's administratively-unique identifier.

                 The value for this object may not the PDU.

An Application, using the securityCookie, can determine the
securityIdentity on whose behalf the notification should be all zeros or
                 all 'ff'H. processed.

8.1.8. Send a Notification

The initial value for this object may be configured
                 via Message Processing and Control subsystem accepts from an operator console entry or via
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 algorithmic
                 function. In Application

An application, using local information can determine the later case,
securityCookie to use to generate the message.

\

The application will pass to the Message Processing and Control
subsystem the securityCookie, the LoS, and the following
                 guidelines are recommended:

                  1) scopedPDU.

The first four octets are set Message Processing and Control will send the SNMP message
according to the binary
                     equivalent process described in 8.1.2.

8.2. Standard Services Required of Security Models

8.2.1. validate the agent's SNMP network management
                     private enterprise number as assigned by security-stamp in a received message

given a message, the
                     Internet Assigned Numbers Authority (IANA).
                     For example, if Acme Networks MMS, LoS, and the security parameters from that
message, verify the message has not been assigned
                     { enterprises 696 }, altered, and authenticate
the first four octets would identification of the securityIdentity for whom the message was
generated.

If encrypted, decrypt the message

Additional requirements may be assigned '000002b8'H.

\
                  2) The remaining eight octets are defined by the cookie whose
                     contents 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 determined via one or more
                     enterprise specific methods. Such methods must
                     be designed no so as 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 maximize
            the possibility
                     that rules of the value Local Processing model to be used.
         LoS - the level of this object will security required. The same level of
            security must also be unique in used during application of access
            control.
         MMS - the agent's administrative domain. For example, maximum size of a message able to be generated
            by this engine for the cookie may destination agent.
         PDU-MMS - the maximum size of a PDU to be included in a
            response message, given the IP address amount of
            reserved space in the agent,
                     or the MAC address of one of message for the interfaces,
                     with each address suitably padded with random
                     octets. If multiple methods are defined, then
                     it is recommended that anticipated
            security parameters.
         GroupName - the cookie GroupName to be further
                     divided into one octet that indicates applied for access control for
            the
                     method being used securityIdentity for whom the request was generated.

8.2.2. security-stamp a message

Given a PDU, LoS, MMS, and seven octets which are a function of securityCookie, the method.
                "
    SYNTAX       OCTET STRING (SIZE (12))

snmpNgSecurityModel ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "An identifier that uniquely identifies an SNMPng Security Model within the SNMPng Framework.
                "
    SYNTAX       INTEGER

-- SNMPng MIB objects implemented by model
must determine the SNMPng MPC ******************

snmpNgEngineID   OBJECT-TYPE
    SYNTAX       snmpNgEngineID
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The SNMPng entity's administratively-unique
                 SNMP-Engine identifier.
                "
    ::=3D { snmpNgMIBObjects 1 }

snmpNgEngineMms   OBJECT-TYPE
    SYNTAX       INTEGER
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The maximum length in octets of an SNMPng message
                 which this SNMPng entity will accept using any
                 transport mapping.
                "
    ::=3D { snmpNgMIBObjects 2 }

-- Conformance information

snmpNgMIBCompliances  OBJECT IDENTIFIER ::=3D { snmpNgMIBConformance 1 }
snmpNgMIBGroups       OBJECT IDENTIFIER ::=3D { snmpNgMIBConformance 2 }

\

-- Compliance statements

snmpNgMIBCompliance MODULE-COMPLIANCE
    STATUS current
    DESCRIPTION
          "The compliance statement security parameters for SNMPng entities which
           implement the SNMPng (MPC) remote configuration MIB.
          "

    MODULE  -- this module
        MANDATORY-GROUPS { snmpNgBasicGroup }

    ::=3D { snmpNgMIBCompliances 1 }

snmpNgBasicGroup OBJECT-GROUP
    OBJECTS { snmpNgEngineID,
              snmpNgEngineMms
            }
    STATUS  current
    DESCRIPTION
          "A collection of objects providing for remote configuration message, the contents
and format of an SNMPng entity which implements are defined by the SNMPng MPC-Model.
          "
    ::=3D { snmpNgMIBGroups 1 }

END

\

10. Agent Installation Parameters

During installation, an SNMPng entity acting in 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

\

Given model-specific parameters to identify a securityIdentity,
an agent role is
configured with several parameters. These include:

(1) Security model must return a security posture

    The choice of security posture determines securityCookie

Given a securityCookie generated by this Security model, the extent of Security
model must return model-specific data identifying the view
    configured for unauthenticated access. One corresponding
securityIdentity.

8.3. Standard Services of three possible
    choices is selected:

          minimum-secure,
          semi-secure, or
          very-secure.

(2) one or more transport service addresses

    These parameters may be specified explicitly, or they may be
    specified implicitly as 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 same set of network-layer addresses
    configured for other uses protocol rules defined by the device together with the well-
    known transport-layer "port" information for the appropriate
    transport domain 13. The agent listens on each of these
    transport service addresses for messages.
Local Processing model.

\

11.

9. Security Consideration

This document describes how the SNMPng uses a Security Model model and a
Local processing Model Processing model to achieve a level of security for network
management messages and controlled access to data.

The level of security actually provided is primarily determined by the specific Security Model
model implementation(s) and the specific Local Processing Model 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 model complies with the
      rules of the Security Model, model,
  3) the implementation of the Local Processing Model model complies
      with the rules of the Local Processing Model, model,
  4) the implementation of associated applications comply
      with the rules of this framework relative to applications,
  5) the Security Model 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 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 model protects against
      inadvertently revealing security secrets in its design of
      implementation-specific data structures,
  8) the implementation of the Local Processing Model 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.

\

12.

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., 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, "Introduction to
     Community-based SNMPv2", "Textual Conventions for Version 2 of the Simple
    Network Management Protocol (SNMPv2)", RFC 1901, 1903, January 1996.

[RFC1902]

[RFC1904] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
    and S., Waldbusser, "Structure of Management
     Information "Conformance Statements for Version 2 of the
    Simple Network Management Protocol (SNMPv2)", RFC 1905, 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)",

\
    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.

[SNMPng-ARCH] The SNMPng Working Group, Harrington, D., Wijnen, B.,
     "Architecture for the Next Generation Simple Network Management
     Protocol (SNMPng)", draft-ietf-snmpv3-next-gen-arch-00.txt,
     April 1997.

[SNMPng-LPM] The SNMPng Working Group, Wijnen, B., Harrington, D.,
     "Local Processing Model

[RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure
    for the Next Generation Simple Network
     Management Protocol (SNMPng)", draft-ietf-snmpng-lpm-00.txt,
     April 1997.

[SNMPng-USEC] To be written
              The SNMPng Working Group, Editors...Names,
     "The User-Based SNMPv2", RFC1909, February 1996

[RFC1910] Waters, G., Editor, "User-based Security Model for the Next Generation Simple
     Network Management Protocol (SNMPng)",
     draft-ietf-snmpng-usec-00.txt, April 1997. SNMPv2",
    RFC1910, February 1996

\

13.

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

14.

\

12. Acknowledgements

This document describes 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)

\

Table of Contents

0.  Change Log                                                         2
1. Introduction                                                        3                                                        4
1.1. A Note on Terminology                                             3                                             4
2. Overview                                                            4                                                            5
3. An Evolutionary Architecture - Design Goals                         5                         6
3.1. Encapsulation                                                     5                                                     6
3.2. Cohesion                                                          5                                                          6
3.3. Hierarchical Rules                                                5                                                6
3.4. Coupling                                                          6
4.0.                                                          7
4. Abstract Functionality                                            7                                              9
4.1. Message Processing and Control                                    7                                    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                                                          7                                                         10
4.3. Local Processing                                                  8                                                 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                                                      8
4.5. Definition of SNMPng acronyms and terms:                          8                                                     11
4.5 Coexistence                                                       11
5. Abstract Data Elements of the Framework                                           9
5.1. Groups                                                            9 Architecture                         13
5.1 engineID                                                          13
5.2. Quality of Service                                                9 SecurityIdentity                                                 13
5.3. Contexts                                                          9 Level of Security                                                13
5.4. Scoped-PDU                                                        9 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                                 10
5.6.                                14
5.12. Local Configuration Datastore                                    10                                   14
6. Textual Conventions for the SNMPng Architecture                    16
7. Model Design Requirements                                          11
6.1.                                          19
7.1. Security Model Design Requirements                               11
6.2.                               19
7.2. Local Processing Model Design Requirements                       12
6.3.                       20
7.3. Message Processing and Control Requirements                      13
6.4.                      21
7.4. Applications                                                     13
6.4.1. A Proxy                                                     21
7.4.1. Application                                            13
7. The SNMPng message format:                                         15
7.1. SNMP version                                                     16
7.2. msgID                                                            16
7.3. MMS                                                              16
7.4. securityModel                                                    16
7.5. QoS                                                              16
7.6. security parameters                                              17
7.7. scopedPDU                                                        17
7.7.1. contextID                                                      17
7.7.2. contextName                                                    17
7.7.3. data                                                           17 Responsibilities                                   21
8. The Frameworks Subsystems and their standard "services" interfaces            18 Transferring Data Between Subsystems                23
8.1. Standard Services of Message Processing and Control Models       18       23
8.1.1. Receive SNMP messages from the network                         18                         23
8.1.2. Send SNMP messages to the network                              18                              23
8.1.3. Coordinate the Local Processing of a Received Request Message  18  24
8.1.4. Forward Received Request Message to a Proxy an Application        19             24
8.1.5. Generate a Request Message for an Application                  19                  24
8.1.6. Forward Received Response Message to an Application            19            25
8.1.7. Forward Received Notification Message to an Application        20        25
8.1.8. Generate Send a Trap Message                                        20 Notification                                            25
8.1.9. Send a Response Message from a Proxy an Application               20                    25
8.2. Standard Services Required of Security Models                    20                    26
8.2.1. validate the security-stamp in a received message              20              26
8.2.2. security-stamp a message                                       21                                       26
8.2.3. Provide mappings between security entities and securityCookies 21
8.2.4. Provide mapping between group and securityCookies              21 26
8.3. Standard Services of a Local-Processing Model                    21                    27
8.3.1. Process a request                                              21
8.3.2. Generate a Trap                                                21
9. Definitions                                                        23
9.1. Definitions for the Architectural Model for SNMPng               23
10. Agent Installation Parameters                                              27
11.
9. Security Consideration                                             28
12.
10. References                                                        29
13.
11. Editor's Addresses                                                30
14.                                                31
12. Acknowledgements                                                  30                                                  32