An Architecture for the Next Generation
                Simple Network Describing
                      Internet Management Protocol (SNMPng) Frameworks
                               D. Harrington
                           Cabletron Systems, Inc.
                              dbh@cabletron.com

                                B. Wijnen
                          IBM T.J. Watson Research
                             wijnen@vnet.ibm.com

                   <draft-ietf-snmpv3-next-gen-arch-01.txt>

                   <draft-ietf-snmpv3-next-gen-arch-02.txt>

                           Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

                              Abstract

This document describes an architecture for the Next-Generation of
the Simple Network describing Internet
Management Protocol (SNMPng). Frameworks. 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 messaging engine containing a message
processing and control subsystem, 2) subsystem and a security subsystem, and
3) plus a local
data processing subsystem. engine, called a context engine, which contains an
access control subsystem, a MIB access subsystem, and possibly
multiple orangelets which provide specific functional processing
of network management data.

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

Harrington/Wijnen         Expires December 1977        [Page  2]

0.  Change Log

[version 2.2]
 . fix PDU back to scopedPDU where appropriate
 . MIB definitions contained some terms that need defining (MMS, etc)
 look them up and add Issues

0.1.  Issues to "abstract data elements" be resolved
 . fixes suggested by Bob Moore:
 contextID identifies engine not agent Need the "readable" introduction supplement
 . fixed intro to allow manager-to-manager "conveyance" taxonomy:
	orangelets
 . For interfaces which pass both should the securityCookie scopedPDU be contained in the securityParameters
    SEQUENCE, so encryption can include the PDU and some of the
    security
 model, removed the securityModel, since it can be derived parameters?
 . Who counts SNMP messages? who counts snmpv3 messages?
 . reportPDUs created from an error status or OID returned by the
 securityCookie. appropriate
	subsystem/model?
 . eliminated requirement of group foward refreences need to <users> mapping, since movement be handled
 . some TCs were defined for interface parameters, but aren't part of traps a mIB.
	move to application eliminates the need for this mapping. Glossary?
 . eliminated "end-user"; substitutes security entity. Is AdminString appropriate for all strings, such as securityidentifier and
	context and group? These had different sizes and semantics.
 . removed discussion AdminString has size (1..255); what about default context of traps as part ""?
 . snmpEngineMaxMessageSize maximum size? 65507? what about non-UDP transports?
 . description of LPM, replaced with discussion max message size
 . definitioon/description of notifications sent/received by application. MD5/DES protocol OIDs.
 . separated architectural textual conventions from MPC-specific MIB
 (put TCs should the tree for registering protocols be in architecture doc, objects basicGroup?
 . should User-based be in basicgroup conformance?
 . how does MPC doc) match incoming requests with outgoing responses?
 . changed security entity to securityIdentity
[version 2.1] generateRequestMessage( globalData, scopedPDU, MIID, engineID )
	why do we need engineID? isn't that implicit?
 . changed Quality of Service (QoS) to Level of Security (LoS) I rearranged primitive parameters: transport/engine/contextEngine/PDU
 . changed QoS field to msgFlags (includes LoS plus reportFlag) state_refernce releases - are these consistently defined?
 . modified "Abstract Functionality" should the MPC release the state_reference when it receives a response?
 . expanded subsystem descriptions How is duplicate registration handled? error or ignore?

0.2.  Change Log

[version 3.1]
 . change securityIdentity to include introductory MIID
 . write text on
 SMI, textual conventions, conformance, protocol operations, SNMP MIB,
 coexistence, etc.
 . added reference citations as needed
 . replaced "interface" with "abstract data elements to transfer data" to avoid explain the dreaded "interface = API" assumption. differences between security-identities,
   model-dependent identifiers, and model-independent identifiers.
 . modified scopedPDU write text to permit a snmpv1 community-scoped PDU,
 including one which uses the community to control proxy
 i.e snmpv3 uses engineID/contextName for naming scope
 snmpv1 uses community alone for naming scope
 a snmpv1 MPC can "scope" the snmpv1 PDU by using the community as explain distinction within the LCD of the naming scope in security
   data, the interface between MPC access control data, and LPM or Apps
 . rewrote (and renamed) "Abstract Data Elements of the Architecture"
 . added a definition for an abstract "engineID oranglet data.
 . modified naming scope and scopedPDU to be more generic identify issues
 . removed the MIB definitions publish as <draft-ietf-snmpv3-next-gen-arch-02.txt>

[version 2.0] 3.0]
 . separated architecture from Message Processing and Control
 model add section on threats for SNMPv3 message security
 . changed filename to internet-drafts assigned name add section on threats for access control
 . changed contextID change application to contextEngineID orangelet
 . changed sub-frameworks remove references to subsystems F-Ts
 . changed Model change securityIdentity to model security-identity
 . changed scopedPDU change securityCookie to PDU securityIdentity
 . expanded acronyms the format of securityIdentity is defined by the model
 . removed reference citations add securityModel to arch, mpc, and usec drafts passed parameters as needed

Harrington/Wijnen         Expires November December 1977        [Page  2]
\  3]
 . eliminate group from passed parameters
 . remove unused IMPORTS
 . add glossary section with initial set of words to define
 . differentiate the messageEngine from the contextEngine
 . eliminate the term SNMPng
 . rewrote 1.1. A Note on Terminology
 . eliminated assumptions about SNMP processing always being
    message related
 . rewrote 4.x to reflect new thinking
 . rewrote 5.x to reflect new thinking
 . rewrote 6.x (the MIB) to reflect new thinking
 . added MIB objects at this level (previously only T-Cs)
 . rewrote 7.x
 . sent to v3edit list

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

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 requirements for mechanisms which provide
message-level security, standard services,
such as sending and receiving messages, countering security threats to
messages, controlling access control for to managed objects, and
interaction between the protocol engine and the applications which use
the services processing various
types of the engine. requests.

It is the purpose of this document to define an architecture which
can evolve to realize effective network management in a variety
of configurations and environments. The architecture has been
designed to meet the needs of implementors of both minimal agents agents, command
line driven managers, mid-level managers, and full-function network
enterprise management stations.

1.1. A Note on Terminology

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

SNMP version 2 (SNMPv2) is an updated design of portions of SNMPv1,
as described in RFCs 1902-1908.

SNMP next generation (SNMPng) is an

This architecture is designed to allow an orderly evolution of
portions of SNMP subsystems. This document describes the
SNMPng architecture. Frameworks.

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

A model "model" describes a specific design of a subsystem, defining
additional constraints and rules for conformance to the model.
A model is sufficiently detailed a design to make it possible to implement
the specification.

A Implementation "implementation" is an instantiation of a subsystem, conforming to a
specific model.

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

SNMP version 2 (SNMPv2) is an updated design of portions of SNMPv1,
as described in RFCs 1902-1908. SNMPv2 has an incomplete message
definition.

Harrington/Wijnen         Expires November December 1977        [Page  4]
\  5]

Community-based SNMP version 2 (SNMPv2c) is an experimental Framework
which supplements the incomplete message format of SNMPv2 with
portions of the message format of SNMPv1, as described in RFC1901.

SNMP version 3 (SNMPv3) Framework is a particular configuration of
implemented subsystems, consistent with the architecture described
in this document.

Other SNMP Frameworks, i.e. other configurations of implemented
subsystems, are expected to also be consistent with this architecture.

This document does not describe any framework, but describes an
architecture into which multiple frameworks may be fitted.

2. Overview

The architecture presented here emphasizes the use of modularity to
allow the evolution of portions of SNMP without requiring a redesign
of the general architecture of SNMP.

The processing of

SNMP messages is procedural - there are specific
steps which processing must be accomplished performed in specific order of processing.
These steps consistently ordered steps, which
fall into general categories of similar functionality. This document
will describe major abstractions of functionality required of an during
SNMP engine, processing, and the abstract interactions between these major
categories of functionality.

This document will describe how this architecture is meant to allow
modules of functionality corresponding to these abstract categories to
be designed to allow the evolution of the whole by modifying discrete
modules within the architecture.

Harrington/Wijnen         Expires November December 1977        [Page  5]
\  6]

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 this architecture, all data used for processing only within
a functional portion of the architecture should have its visibility
restricted to that portion if possible. The data should be accessed
only by that functionality defined with the data. No reference to the
data should be made from outside the functional portion of the
architecture, except through predefined public interfaces.

3.2. Cohesion

Similar functions can be grouped together and their differences
ignored, so they can be dealt with as a single entity. It is important
that the functions which are grouped together are actually similar.
Similarity of the data used to perform functions can be a good
indicator of the similarity of the functions.

For instance, example, authentication and encryption are both security functions
which act on the are applied to a message. Access control, while similar in some
ways, is not similar dissimilar in that it does is not work on the applied to a message, it works on the
contents of the message. is
applied to a (proposed) request for a management operation.
The similarity of the data used required to perform
functions can be a good indicator of authentication and encryption are
different than the similarity of data needed to perform access control, and the functions.
two sets of services can be described independently.

Similar functions, especially those that use the same data elements,
should be defined together. The security functions which operate at
the message level should be defined in a document together with the
definitions for those data elements that are used only by those
security functions. For example, a MIB with authentication keys is
used only by authentication functions; they should be defined together.

Harrington/Wijnen         Expires December 1977        [Page  7]

3.3. Hierarchical Rules

Functionality can be grouped into hierarchies where each element in the
hierarchy receives general characteristics from its direct superior,
and passes on those characteristics to each of its direct subordinates.

The SNMPng

This architecture uses the hierarchical approach by defining

Harrington/Wijnen         Expires November 1977        [Page  6]
\
subsystems, which specify the general rules of a portion of the system,
models which define the specific rules to be followed by an
implementation of the portion of the system, and implementations which
encode those rules into reality for a portion of the system.

It is expected that within portions of the system, hierarchical
relationships will be used to compartmentalize, or modularize, the
implementation of specific functionality. For example, it is expected
that within the security portion of the system, authentication and
privacy will probably be contained in separate modules, and that
multiple authentication and privacy mechanisms will be supported by
allowing supplemental modules that provide protocol-specific
authentication and privacy services.

3.4. Coupling

Coupling describes the amount of interdependence between parts of
a system. Loose coupling indicates that two sub-systems are relatively
independent of each other; tight coupling indicates a high degree of
mutual dependence.

To make it possible to evolve the architecture by replacing only part
of the system, or by supplementing existing portions with alternate
mechanisms for similar functionality, without obsoleting the complete
system, it is necessary to limit the coupling of the parts.

Encapsulation and cohesion help to reduce coupling by limiting the
visibility of those parts that are only needed within portions of a
system. Another mechanism is to constrain the nature of interactions
between various parts of the system.

This can be done by defining fixed, generic, flexible interfaces
for transferring data between the parts of the system. The concept of
plug-and-play hardware components is based on that type of interface
between the hardware component and system into which it will be
"plugged."

SNMPng

This approach has been chosen this approach so individual portions of the system
can be upgraded over time, while keeping the overall system intact.

To avoid specifying fixed interfaces, which would constrain a vendor's
choice of implementation strategies, SNMPng defines a set of abstract data elements to be
is used for (conceptually) transferring data between subsystems in
documents which describe subsystem or model interactions. Documents

Harrington/Wijnen         Expires December 1977        [Page  8]

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 November December 1977        [Page  8]
\  9]

4. Abstract Functionality

DBH: {ref: Get-Request, PDU, authentication, encryption, timeliness,
managed objects, proxy, }

The architecture described here is composed of contains four subsystems, each
capable of being defined as one or more different models which may
be replaced or supplemented as the growing needs of network management
require. The subsystems are a Message Processing and Control
subsystem, a Security subsystem, a Local Processing an Orangelet subsystem, and an Application
Support
Access Control subsystem.

The term "engine" refers subsystems are contained in two "engines".

A messageEngine deals with SNMP messages, and is responsible for
sending and receiving messages, including having authentication
and encryption services applied to a combination of Message Processing the messages, and
Control subsystem(s), Security subsystem(s), determining
to which Orangelet the message contents should be delivered.

A contextEngine deals with processing network management operations,
and  Local Processing
subsystem(s). Applications are external processes contains subsystems for Access Control, MIB access, and
Orangelets which use provide specific functional processing.
Depending on the engine
to send or receive SNMP messages, or otherwise network management service needed, an Orangelet
may use the services of the access control and MIB access subsystems, and may use
SNMP engine, messages to accomplish their tasks.

4.1. Message Processing and Control communicate with remote nodes. The Message Processing and Control subsystem network
management service may be requested via the payload of an SNMP engine
message, or may be requested via a local process.

4.1. The messageEngine

The messageEngine interacts with the network using SNMP messages,
and interacts with
applications using data elements defined by the Message Processing message processing subsystem and Control model, the security subsystem
and with orangelets using service interfaces defined within this
architecture.

4.1.1. Transport Mappings

SNMP messages are sent to, or received from, the constraints network using
transport addresses. It is the responsibility of the Architecture.

A Message Processing and Control model has the responsibility for
coordinating messageEngine
to listen at the sending and receiving of SNMP messages, appropriate local addresses, 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 send messages are sent to, or received from, the network using a
transport mechanism. It is
through the purpose of Transport Mapping documents
to define how appropriate addresses, consistent with mappings defined
by SNMP maps onto transport domains.

A Message Processing and Control model defines which Transport Mappings
documents are supported by the model. Mapping documents, such as RFC1906.

4.1.2. SNMP-Based Message Formats

SNMP messages sent to, or received from, the network use a format
defined by the a version-specific Message Processing and Control model.

4.1.3. Application-Based Message Formats

Messages being sent to, or received from, applications use formats
The messageEngine determines to which are version-specific model the
message should be given.

The version-specific model interacts with the security subsystem,

using a service interface defined by this architecture, to procure
security services to meet the Message Processing and Control Model.
Note that these are not SNMP messages, but are abstract data elements
used requirements of the version-specific
protocol.

4.1.3. The Interface to transfer data between Orangelets

A messageEngine, as a result of the Message Processing and Control
subsystem and receipt of an Application Support subsystem. SNMP message, may
initiate a transaction with an Orangelet, such as for an incoming
request, or an Orangelet may initiate a transaction with a
messageEngine, such as for an outgoing request. The messageEngine
determines to which orangelet a message should be given.

4.1.4.  Protocol Instrumentation

Harrington/Wijnen         Expires November 1977        [Page  9]
\

It is the purpose of

To monitor and manage an SNMP engine, a Management Information Base
for SNMP document
to define defines the collection of managed objects which describe instrument
the behavior of an SNMP
engine. protocol itself. The messageEngine has the responsibility
for maintaining the instrumentation that is described by the
SNMPv2 MIB module [RFC1907] plus the instrumentation which is
described by the IMFMIB module defined in this document.

A Message Processing and Control model defines which SNMP may require support for
MIB Module
documents are supported modules related to instrument instrumenting version-specific aspects
of the model. SNMP protocol.

4.2. Security

Some environments require secure protocol interactions. Security is
normally applied at two different stages - in the transmission/receipt
of messages, and in the processing of the contents of messages. For
purposes of this document, "security" refers to message-level security;
"access control" refers to the security applied to protocol operations.

Authentication, encryption, and timeliness checking are common
functions of message level security.

4.3. Local Processing

Local Processing deals with Orangelets

Orangelets coordinate the contents processing of messages, called management information
operations.

This document describes three common types of orangelets
and how they interact within the PDU,
providing architecture - 1) an orangelet
may process requests to perform an operation on managed objects,
2) an orangelet may initiate a transaction as the result of a
local event, and 3) an orangelet may act as an intermediary,
forwarding an operation to another network management entity.

Orangelets provide access to instrumentation MIB information, and applying coordinate
the application of access control
according the rules to management operations.

A discussion of the Local Processing model being used.

An overview of management information and processing operations is
provided here, but a Local Processing an Orangelet model defines which set of
documents are used to specifically define the structure of management
information, textual conventions, conformance requirements, and
operations supported by the model.

During local processing, it may be required to control access to
certain instrumentation for certain operations. The enforcement of
access rights requires the means to identify the access allowed for
the securityIdentity on whose behalf a request is generated. A Local
Processing model defines which set of documents are used to define
the mechanisms to realize access control within that model.

4.3.1. Orangelet.

4.4.1.  Structure of Management Information

Management information is viewed as a collection of managed objects,
residing in a virtual information store, termed the Management
Information Base (MIB).  Collections of related objects are defined
in MIB modules.

It is the purpose of a Structure of Management Information
document to establish the syntax for defining objects, modules, and
other elements of managed information.

A Local Processing

An Orangelet model defines which SMI documents are supported
by the model.

\

4.3.2.

4.4.2.  Textual Conventions

When designing a MIB module, it is often useful to define new types
similar to those defined in the SMI, but with more precise semantics,
or which have special semantics associated with them. These newly
defined types are termed textual conventions.

A Local Processing

An Orangelet model defines which Textual Conventions documents
are supported by the model.

4.3.3.

4.4.3.  Conformance Statements

It may be useful to define the acceptable lower-bounds of
implementation, along with the actual level of implementation
achieved.  It is the purpose of Conformance Statements to define
the notation used for these purposes.

A Local Processing

An Orangelet model defines which Conformance Statement documents
are supported by the model.

4.3.4.

4.4.4.  Protocol Operations

SNMP messages encapsulate a Protocol Data Unit (PDU). It is the
purpose of a Protocol Operations document to define the operations
of the protocol with respect to the processing of the PDUs.

A Local Processing

An Orangelet model defines which Protocol Operations documents
are supported by the model.

4.4. Applications

Applications are developed

4.5. Access Control

During processing, it may be required to control access to achieve certain goals. They use
instrumentation for certain operations. The determination of
access rights requires the SNMP
engine means to achieve their goals, and interact with the engine in a manner
consistent with identify the SNMP architecture, but access allowed for
the purpose security-identity on whose behalf a request is generated.

An Access Control model provides an advisory service for an
Orangelet. The determination of specific
applications whether to check access control
policy is outside the scope responsibility of the SNMP architecture.

Applications interact with the SNMP engine using application-support
messages whose format Orangelet model. The mechanism
by which access control is checked is defined by the Message Processing and Access Control
model in use.

4.5
model.

4.6. Coexistence

The purpose of an evolutionary architecture is to permit new models
to replace or supplement existing models. The interactions between
models could result in incompatibilities, security "holes", and
other undesirable effects.

The purpose of a Coexistence document is to detail recognized anomalies
and to describe required and recommended behaviors for resolving the
interactions between models within the architecture.

\

It would be very difficult to document all the possible interactions
between a model and all other previously existing models while in the
process of developing a new model.

Coexistence documents are therefore expected to be prepared separately
from model definition documents, to describe and resolve interaction
anomalies between a model definition and one or more other model
definitions.

\

5. Abstract Data Elements of the Architecture

This section contains definitions of abstract data elements used to
transfer data between subsystems.

5.1

5.1. engineID

Each SNMP engine, consisting of potentially many subsystems, must be
able to be uniquely identified. The mechanism by which this can be
done is defined in the Message Processing and Control model IMFMIB module, described in use.

DBH: this document,
since it is so the IP or MAC address can be used as the engineID
for old snmpv1 implementations which are being retrofitted into this
architecture for use with old snmpv1 management stations. A partial
alternative would be to define the engineID MIB as a separate module
that can be recognized and supported by snmpv1 engines as well as
newer engines desirable that fit this architecture. engine identification span all frameworks.

5.2. SecurityIdentity

A generic term for an uniquely-identifiable entity on whose behalf
a message can be generated. The term Each security subsystem may define a
model-specific mechanism for entity identification, such as a
community [RFC1157] or user [RFC1910] or party-pair [RFC1445].
This model-specific identifier is deliberately abstract not guaranteed to allow
the be represented
in a character set readable by humans.

5.3. Model Independent Identifier (MIID)

Each security subsystem model must also provide a mapping from the model
specific identification to define an SnmpAdminString representation,
called the format and nature MIID, which, in combination with the securityModel,
can be used by all other subsystems within an engine to identify
a security identity, regardless of the
identities it will use.

Sample securityIdentities include communities [RFC1157], parties
[RFC1445], security mechanisms used to
provide security services.

The combination of engineID and users [RFC1910].

5.3. securityModel and MIID provides a
globally-unique identifier for an entity on whose behalf a message
can be generated.

5.4. Level of Security

Messages may require different levels of security. The acronym LoS is
used to refer to the level of security.

SNMPng

This architecture recognizes three levels of security:
    - without authentication and without privacy (noAuth/noPriv)
    - with authentication but without privacy (auth/noPriv)
    - with authentication and with privacy (auth/Priv)

Every message has an associated LoS; all subsystems (security, access
control, applications, orangelets, message processing and control) are required
to abide the specified LoS.

5.4. Groups

A Group identifies a set of zero or more security entities on whose
behalf SNMP managed objects are being processed, subject to access
control policies common to all members of LoS while processing the group. message and its
contents.

5.5. Contexts

An SNMP context is a collection of management information

\
accessible by an SNMP engine. An item of management information
may exist in more than one context. An SNMP engine potentially
has access to many contexts.

5.6. ContextEngineID

A contextEngineID is a field in a message to uniquely identify the
engine that contains the context which realizes the managed objects
referenced in the PDUs.

5.7. ContextName

An octet string used ContextName

An octet string used to name a context. Each context must be uniquely
named within an engine.

5.7. ContextEngineID

A contextEngineID uniquely identifies an engine that may realize
an instance of a named context.

5.8. Naming Scope

The data necessary to combination of a contextEngineID and a contextName uniquely identify
identifies a context within an administrative domain domain, and is called
a naming scope.

The format of the naming scope data is defined by a Message Processing
and Control model.

5.9. Scoped-PDU

A scopedPDU contains a Naming-Scope and a PDU.

The Naming Scope unambiguously identifies, within the administrative
domain, the context to which the SNMP management information in
the PDU refers.

The PDU format is defined by the Local Processing model in use, an Orangelet model, or
by a document
referenced by an Orangelet model, which processes the Local processing model. PDU contents.

5.10. PDU-MMS

the maximum size of a scopedPDU to be included in a response message,
given the amount of reserved space in the message for the anticipated
security parameters.

5.11. Security Local Configuration Datastore

Each Security model

The subsystems and models in an SNMP engine may need to retain its own set of information about
security entities, mechanisms, and policies. The collection of these, their
own, possibly multiple, sets of information is referred to collectively as
the SNMPng engine's Security Configuration Datastore (SCD).
In order to perform their
processing. To allow an SNMPng engine's SCD these sets of information to be remotely
configured, portions may need to be accessible as managed objects.

5.12.

The collection of these possibly multiple sets of information is
referred to collectively as an engine's Local Configuration Datastore

\

Each
(LCD).

5.11.1. Security Portion of the Local Processing Configuration Datastore

Each Security model may need to retain its own set of information about access control, naming scopes,
security entities, mechanisms, and policies.
The collection

5.11.2. Orangelet Portion of these, possibly multiple, sets the Local Configuration Datastore

Each Orangelet model may need to retain its own set of information is
referred to collectively was
about contexts, naming scopes, and other configuration data.

5.11.3. Access Control Portion of the SNMPng engine's Local Processing Configuration Datastore (LCD). In order to allow an SNMPng engine's
LCD to be remotely configured, portions

Each Access Control model may need to be accessible
as managed objects.

\

6. Textual Conventions for retain its own set of
information about access control policies, and the SNMPng Architecture

snmpNg-TC DEFINITIONS ::= BEGIN

IMPORTS
    ObjectSyntax, TimeTicks
        FROM SNMPv2-SMI;
     TEXTUAL-CONVENTION
        FROM SNMPv2-TC;

snmpNg-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, MIIDs
to which the policies apply.

5.12. Groups

A Group identifies a set of zero or more MIIDs on whose
behalf SNMP managed objects are being processed, subject to access
control policies common to all members of the group.

6. Definition of Managed Objects for Internet Management Frameworks

IMF-MIB DEFINITIONS ::= BEGIN

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

snmpNgMIB

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

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

                  Co-editor:  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

                   Co-editor:  Bert Wijnen
                               IBM T.J. Watson Research
                   postal:     Schagen 33
                               3461 GL Linschoten
                               Netherlands
                   email:      wijnen@vnet.ibm.com
                   phone:      +31-348-412-498

                 "
    DESCRIPTION  "The snmpNg architecture Internet Management Architecture MIB"
    ::= { snmpModules xx 99 }

\

-- Textual Conventions used throughout in the SNMPng Framework

SnmpNgEngineID Internet Management Architecture ***

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

                 The value for this object may not be all zeros or
                 all 'ff'H.

                 The initial value for this object may be configured
                 via an operator console entry or via an algorithmic
                 function. In the later case, the following
                 guidelines are recommended:

                  1) The first four octets are set to the binary
                     equivalent of the agent's SNMP network management
                     private enterprise number as assigned by the
                     Internet Assigned Numbers Authority (IANA).
                     For example, if Acme Networks has been assigned
                     { enterprises 696 }, the first four octets would
                     be assigned '000002b8'H.

                  2) The remaining eight octets are the cookie whose
                     contents are determined via one or more
                     enterprise specific methods. Such methods must
                     be designed so as to maximize the possibility
                     that the value of this object will be unique in
                     the agent's administrative domain. For example,
                     the cookie may be the IP address of the agent,
                     or the MAC address of one of the interfaces,
                     with each address suitably padded with random
                     octets. If multiple methods are defined, then
                     it is recommended that the cookie be further
                     divided into one octet that indicates the
                     method being used and seven octets which are
                     a function of the method.
                "
    SYNTAX       OCTET STRING (SIZE (12))

SnmpNgMms   OBJECT-TYPE
    SYNTAX       INTEGER(0..65535)
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The maximum length in octets of an SNMP message
                 which this SNMPng engine will accept using any
                 transport mapping.
                "
    ::= { snmpV3MPCMIBObjects 2 }

SnmpNgSecurityModel

SnmpSecurityModel ::= TEXTUAL-CONVENTION

\
    STATUS       current
    DESCRIPTION "An identifier that uniquely identifies a model of
                 security subsystem within the SNMPng Framework. Internet
                 Management Architecture.
                "
    SYNTAX       INTEGER(0..2147483647)

SnmpNgSecurityIdentity

-- BW to DBH: why do we need the following TC? It is never used in a MIB
--            is it?
-- DBH to BW: I defined this only because it was used in an architectural
--		  interface, and felt that the architecture should define the
--		  limits of the syntax, and provide a common description.
--
-- SnmpSecurityStateReference ::= TEXTUAL-CONVENTION
--  STATUS       current
--  DESCRIPTION  "A octet string which contains data in a format
                  defined by "An implementation-defined reference to the retained
--               security information required to send a response.

--               The security model which identifies a
                  unique <thing> for which messages may defines what information must be generated.

                  For example, a securityIdentity for user-based
                  security contains a user; a securityIdentity
--               retained for
                  community-based security contains a community.
                  The format is not restricted to human-readable text. use in sending the response.
--              "
--  SYNTAX      OCTET STRING (SIZE (0..32))

SnmpNgLoS

SnmpLoS ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "A level of security at which SNMP messages can be
                 sent; in particular, one of:
                   noAuth - without authentication and without privacy,
                   auth   - with authentication but without privacy,
                   priv   - with authentication and with privacy.
                "
    SYNTAX       INTEGER { noAuth(1), auth(2), priv(3) }

SnmpNgGroupName

SnmpAdminString ::= TEXTUAL-CONVENTION
    STATUS        current
    DESCRIPTION  "An octet string which identifies a set of zero or
                  more security entities on whose behalf containing an SNMP managed
                  objects administrative
                  string.  Preferably this a a human readable string.
                  We're still thinking if this could use the UTF8
                  character set.
                 "
    SYNTAX        OCTET STRING (SIZE(1..255))

-- BW to DBH: I think these are no longer needed. They now use the
--            SnmpV3AdminString TC.
-- DBH to BW: so now all securityidentities, Gropups, and Contxets
--            can be up to 255 bytes long, and MUST always be at least
--            one byte in length? What is our new default context?
--
-- SnmpSecurityIdentity ::= TEXTUAL-CONVENTION
--  STATUS        current
--  DESCRIPTION  "A octet string which contains data in a format
--                defined by a security model which identifies a
--                unique identity for which messages may be generated.
--                The securityIdentity must be unique across all
--                securityModels supported by the engine.
--               "
--  SYNTAX       DisplayString (SIZE (0..32))
--
-- SnmpGroupName ::= TEXTUAL-CONVENTION
--  STATUS        current
--  DESCRIPTION  "An octet string which identifies a set of zero or
--                more security entities on whose behalf SNMP managed
--                objects are being processed, subject to access
--                control policies common to all members of the group.
--               "
--  SYNTAX        OCTET STRING (SIZE(1..16))

SnmpNgContextName
--
--SnmpContextName ::= TEXTUAL-CONVENTION
--  STATUS        current

--  DESCRIPTION  "A name which uniquely identifies a set of
--                management information realized by an SNMP engine.
--               "
--  SYNTAX       OCTET STRING (SIZE (0..32))

END

\

7. Model Design Requirements
--
--
-- The basic design elements come from SNMPv2u and SNMPv2*, as
described in RFCs 1909-1910, and from a set of internet drafts.
these are IMF Engine Group
--

-- Administrative assignments ****************************************

imfAdmin           OBJECT IDENTIFIER ::= { imfMIB 1 }
imfMIBObjects      OBJECT IDENTIFIER ::= { imfMIB 2 }
imfMIBConformance  OBJECT IDENTIFIER ::= { imfMIB 3 }

-- the two most popular de facto "administrative framework"
standards that include security and access control for SNMPv2.

SNMPv1 and SNMPv2c [RFC1901] are two administrative frameworks based
on communities to provide trivial authentication and access control.
SNMPng allows implementations to add support for features imfEngine group ***********************************************

imfEngine OBJECT IDENTIFIER ::= { imfMIBObjects 1 }

snmpEngineID     OBJECT-TYPE
    SYNTAX       SnmpEngineID
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "An SNMP engine's administratively-unique identifier.
                "
    ::= { imfEngine 1 }

snmpEngineBoots  OBJECT-TYPE
    SYNTAX       Unsigned32 -- (1..4294967295)
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of SNMPv1
and SNMPv2c, and times that the engine has re-initialized
                 itself since its initial configuration.
                "
    ::= { imfEngine 2 }

snmpEngineTime   OBJECT-TYPE
    SYNTAX       Integer32 (0..2147483647)
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of seconds since the engine last
                 incremented the snmpEngineBoots object.
                "
    ::= { imfEngine 3 }

snmpEngineMaxMessageSize OBJECT-TYPE
--  SYNTAX       Integer32 (484..2147483647)
-- From BW to DBH: why did you use that large range? The 65507 is the
--                 max that fits in a UDP datagram. I thought we
--                 reached consensus on that on the mailinglist.
-- DBH to BW:      did we? I thought there were arguments that we should

--                 not work with the limits of UDP, since other transports
--                 are now officially supported. If I write an engine that
--                 has a larger buffer, and use a transport that can handle
--                 the larger size, why artficially limit it? The type can
--                 handle the larger number; why impose unnecessary limits?
    SYNTAX       Integer32 (484..65507)
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The maximum length in octets of an SNMP message
                 which this SNMP engine can send or receive and
                 process, determined as the minimum of the maximum
                 message size values supported among all of the
                 transports available to and supported by the engine.
                "
-- From BW to DBH: How do you like this (picked it from RFC1910):
--                 I think it is only meant to state what it can
--                 receive!!!
-- DBH to BW:      I think the one above came from snmpv2*. I think the send
--                 was included to indictae
--                 to an enquiring manager how large a getBulk might be
--                 supported, so a manager didn't send one obviously too large,
--                 and to reflect that a message might be receivable, but not
--                 be able to be processed due to resource limitations (such
--                 as an ASN.1-decoded message being larger than the encoded
--			 message, or a secured message with a non-sent key that led
--                 to resource allocation problems...)
--  DESCRIPTION "The maximum length in octets of an SNMP message which
--               this agent will accept using any transport mapping.
--              "
    ::= { imfEngine 4 }

-- From BW to DBH: Was the following decided at the interim?
--                 We had those defined in USEC doc.... so if we
--                 do define these protocols here, then I can
--                 remove them from USEC doc.
-- DBH to BW:      Not sure if decided; If we want protocols defined
--			in a common place, the arch mib should provide the tree.
--                I don't object to MD5 and DES being defined in USEC, but
--                the arch doc does specify they are expected, so I think
--                it treasonable to define here, especially if we want to
--                make it mandatory for basic compliance.
--
-- The IMF IETF-Standard Authentication Protocols Group
--

imfAuthProtocols      OBJECT IDENTIFIER ::= { imfAdmin 1 }

imfNoAuthProtocol     OBJECT IDENTIFIER ::= { imfAuthProtocols 1 }

imfAuthMD5Protocol    OBJECT IDENTIFIER ::= { imfAuthProtocols 2 }

DBH to BW: should we have a description of this object to make it
meaningful? ditto for DES below.

--
-- The IMF IETF-Standard Privacy Protocols Group
--

imfPrivProtocols      OBJECT IDENTIFIER ::= { imfAdmin 2 }

imfNoPrivProtocol     OBJECT IDENTIFIER ::= { imfPrivProtocols 1 }

imfDESPrivProtocol    OBJECT IDENTIFIER ::= { imfPrivProtocols 2 }

-- conformance information

imfMIBCompliances
               OBJECT IDENTIFIER ::= { imfMIBConformance 1 }
imfMIBGroups
               OBJECT IDENTIFIER ::= { imfMIBConformance 2 }

-- compliance statements

imfMIBCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION "The compliance statement for SNMP engines which
                 implement the IMF MIB.
                "
    MODULE    -- this module
        MANDATORY-GROUPS {
                          imfEngineBasicGroup
                         }
    ::= { imfMIBCompliances 1 }

-- units of conformance

imfEngineBasicGroup OBJECT-GROUP
    OBJECTS {
             snmpEngineID,
             snmpEngineMaxMessageSize,
             snmpEngineBoots,
             snmpEngineTime
            }
    STATUS       current
    DESCRIPTION "A collection of objects for identifying and
                 determining the configuration limits of an
                 SNMP agent.
                "
    ::= { imfMIBGroups 1 }

-- DBH to BW: should the tree for registering protocols be in basicGroup?
--            I thouhgt we had consensus that user-based security was required

--            as a minimum. No?

END

7. Model Design Requirements

The basic design elements come from SNMPv2u and SNMPv2*, as
described in RFCs 1909-1910, and from a set of internet drafts.
these are the two most popular de facto "administrative framework"
standards that include security and access control for SNMPv2.

SNMPv1 and SNMPv2c [RFC1901] are two administrative frameworks based
on communities to provide trivial authentication and access control.
SNMPv1 and SNMPv2c Frameworks can coexist with Frameworks designed
to fit into this architecture, and modified versions of SNMPv1 and
SNMPv2c engines, Frameworks could be fit into this architecture, but this
document does not provide guidelines for that coexistence.

Within any subsystem model, there should be no reference to any
specific
specific model of another subsystem, or to data defined by a specific
model of another subsystem.

Transfer of data between the subsystems is deliberately described as a fixed
set of abstract data elements and primitive functions which can be overloaded
to satisfy the needs of multiple model definitions.

Documents which define models to be used within this architecture are constrained
to using the abstract data elements for transferring data between subsystems,
possibly defining specific mechanisms for converting the abstract data into
model-usable formats. This constraint exists to allow subsystem and model
documents to be written recognizing common borders of the subsystem and model.
Vendors are not constrained to recognize these borders in their implementations.

The architecture defines certain standard services to be provided
between subsystems, and the architecture defines abstract data
elements to transfer the data necessary to perform the services.

Each model definition for a subsystem must support the standard service
interfaces, but whether, or how, or how well, it performs the service
is defined by the model definition.

7.1. Security Model Design Requirements

7.1.1. Threats

Several of the classical threats to network protocols are applicable
to the network management problem and therefore would be applicable
to any security model used in an Internet Management Framework. Other
threats are not applicable to the network management problem.  This
section discusses principal threats, secondary threats, and threats
which are of lesser importance.

The principal threats against which any security model used within
this architecture should provide protection are:

Modification of another subsystem, or Information
     The modification threat is the danger that some unauthorized
     entity may alter in-transit SNMP messages generated on behalf
     of an authorized security-identity in such a way as to data defined effect
     unauthorized management operations, including falsifying the
     value of an object.

Masquerade
     The masquerade threat is the danger that management operations
     not authorized for some security-identity may be attempted by a specific
model
     assuming the identity of another subsystem.

For security-identity that has the
     appropriate authorizations.

Message Stream Modification
     The SNMPv3 protocol is typically based upon a connectionless
     transport service which may operate over any subsystem model, subnetwork service.
     The re-ordering, delay or replay of messages can and does occur
     through the model definition natural operation of many such subnetwork services.
     The message stream modification threat is constrained the danger that messages
     may be maliciously re-ordered, delayed or replayed to using an extent
     which is greater than can occur through the abstract data elements, defined natural operation of a
     subnetwork service, in this document, for transferring
data between order to effect unauthorized management
     operations.

Disclosure
     The disclosure threat is the subsystem and any other subsystem. (Note that danger of eavesdropping on the
     exchanges between SNMP engines. Protecting against this threat
     may be required as a matter of local policy.

There are at least two threats against which a security model definition used
by a framework within this architecture need not protect.

Denial of Service
     A security model need not attempt to address the broad range of
     attacks by which service on behalf of authorized users is so constrained, but implementations denied.
     Indeed, such denial-of-service attacks are in many cases
     indistinguishable from the type of network failures with which any
     viable network management protocol must cope as a matter of
     course.

Traffic Analysis
     A security model need not so
constrained).

7.1. attempt to address traffic analysis
     attacks.  Many traffic patterns are predictable - agents may be
     managed on a regular basis by a relatively small number of
     management stations - and therefore there is no significant
     advantage afforded by protecting against traffic analysis.

7.1.2. Security Model Design Requirements Processing

Received messages must be validated by a model of the Security security
subsystem. Validation includes authentication and privacy processing

if needed, but it is explicitly allowed to send messages which do
not require authentication or privacy.

A received message will contain a specified Level of Security to be
used during processing. All messages requiring privacy must also
require authentication.

A Security security model specifies rules by which authentication and privacy
are to be done. A model may define mechanisms to provide additional
security features, but the model definition is constrained to using
(possibly a subset of) the abstract data elements defined in this
document for transferring data between subsystems.

Each Security model may allow multiple security mechanisms to be used
concurrently within an implementation of the model. Each Security model
defines how to determine which protocol to use, given the LoS and the
security parameters relevant to the message. Each Security model, with
its associated protocol(s) defines how the sending/receiving entities
are identified, and how secrets are configured, configured.

Authentication and how Privacy protocols supported by security entities
map to groups. models
are uniquely identified using Object Identifiers. IETF standard
protocol for authentication or privacy should have an identifier
defined within the ImfAuthenticationProtocols or ImfPrivacyProtocols
subtrees. Enterprise-specific protocol identifiers should be defined
within the enterprise subtree.

For privacy, the Security model defines what portion of the message
is encrypted.

\

The persistent data used for security should be SNMP-manageable, but
the Security model defines whether an instantiation of the MIB is a
conformance requirement.

Security models are replaceable within the SNMPng security subsystem. Multiple
Security model Implementations may exist concurrently within an engine.
The number of Security models defined by the SNMP community should
remain small to promote interoperability. It is required that an
implementation of the User-Based Security model be used in all
engines to ensure at least a minimal level of interoperability.

Each Security model must define a mapping to be used between a unique
securityIdentity within the model's SCD, and a securityCookie. A
securityCookie is an implementation-specific handle to identify the
securityIdentity to which it maps. If an implementation supports
multiple Security models, the securityCookie must include a mechanism
for determining which Security model SCD is referenced. The
securityCookie, in combination with the engineID of the engine which
instantiates the securityCookie, can be used as a globally-unique
identifier for a securityIdentity. The type of a securityCookie is an
OCTET STRING, but the format of the contents is
implementation-specific. It is important to note that since the
securityCookie may be accessible outside the engine, the
securityCookie must not disclose any sensitive data, such as by
including passwords in open text in the securityCookie.

Each Security model defines the MIB moduless required for security
processing, including any MIB modules required for the security
mechanism(s) supported. The MIB modules must be defined concurrently
with the procedures which use the MIB module. The MIB modules are
subject to normal security and access control rules.

The persistent data used for security should be SNMP-manageable, but
the Security model defines whether an instantiation ensure at least a minimal level of interoperability.

7.1.3. validate the MIB is security-stamp in a
conformance requirement. The mapping between received message

given a securityCookie and message, the
unique securityIdentity within MMS, LoS, and the engine must be able to be
determined using SNMP, if security parameters from that
message, verify the MIB is instantiated message has not been altered, and access control
policy allows.

Protocols should be uniquely identified using Object Identifiers.
Enterprise-specific protocols should be defined within authenticate
the enterprise
subtree. A protocolID MIB should be defined for IETF standard
protocols identification of the security-identity for authentication and privacy.

7.2. Local Processing Model Design Requirements

Within any Local Processing model, there should whom the message was
generated.

If encrypted, decrypt the message

Additional requirements may be no reference to
any specific Security model, or any specific Message Processing and
Control model, or any data defined by a specific Security or Message
Processing the model, and Control model.

A Local Processing additional

services provided by the model, but the model is constrained to use
only processes PDUs which the defined abstract data elements for transferring data between
subsystems. Implementations are destined no so constrained.

return a MIID identifying the security-identity for
processing by whom
the current engine, message was generated and return the portions of the message
needed for further processing:
         a PDU - a PDU containing varbinds and a verb according to
            the rules of the Local Processing model.

\

A Local Processing model to be used.
         LoS - the level of security required. The same level of
            security must determine whether also be used during application of access
            control.
         MMS - the specified group is
allowed maximum size of a message able to perform the requested operation on be generated
            by this engine for the managed objects in destination agent.
         PDU-MMS - the PDU, according maximum size of a PDU to be included in a
            response message, given the rules amount of
            reserved space in the Local Processing model being
used.

A Local Processing model specifies message for the rules by anticipated
            security parameters.

7.1.4. Security Identity

Different security models define identifiers which access control represent some
<thing> which somehow exists, and PDU processing are to be done. A model may define mechanisms to
provide additional processing features, but is constrained to capable of using the
abstract data elements defined in this document for transferring data
between subsystems. SNMP.
The persistent data used for local processing should <thing> may be manageable
using SNMP, but the Local Processing model defines whether person, or a network-management platform, or
an
instantiation aggregate of the MIB is a conformance requirement.

7.3. Message Processing and Control Requirements

Within any Message Processing and Control model, there should be no
reference to any specific Security model persons, or any specific Local
Processing model, an aggregation of persons and devices,
or some other abstraction of entities that are recognized as
being able to any data defined by use SNMP-defined services.

This document will refer to that abstraction as a specific security-identity.

7.1.5. Model Dependent Identifier

Each Security or
Local Processing model.

The Message Processing and Control model must always (conceptually)
pass defines how security-identities are identified
within the complete PDU, model, i.e. it never forwards less than how they are named. Model-dependent identifiers
must be unique within the complete
list of varbinds. model. The Message Processing combination of engineID,
securityModel, and Control model specifies how to determine
whether the PDU in correct model-dependent identifier can be
used to uniquely identify a received message should security-identity.

For example, David Harrington may be processed represented on a particular
engine by multiple security models - as the user "davidh", the
community "david", and the
current engine or by an application [FT].

A model may define mechanisms to provide additional processing
features, but foobar "david". It is constrained legal to using the abstract data elements
defined use
"david" in this document for transferring data between subsystems.

7.4. Applications

Applications are beyond more than one model, since uniqueness is only guaranteed
within the scope of this document, model, but there are
certain issues that must cannot be clarified regarding two "david" communities.
The combination of the relation and engineID, the abstract data elements used for transferring data between
applications <user> model, and the engine.

7.4.1. Application Responsibilities

An application has user
"davidh" uniquely identifies the responsibility security-entity David Harrington.

7.1.6. Model Independent Identifier

It is desirable to define any MIB modules used be able to provide application-specific services.

An engine supports one conceptual interface refer to applications, provided a security-entity using the abstract data elements a human
readable identifier, such as for transferring data audit trail entries.
Therefore, each Security model is required to define a mapping between the
engine

a model-dependent identifier and applications. It an identifier restricted to a human
readable character set. This identifier is implementation-specific how data passed
from the engine called a MIID.

The type of a MIID is routed to a human-readable OCTET STRING following the appropriate application.

\

No access control
conventions of the SnmpAdminString TEXTUAL-CONVENTION, defined below.

The combination of engineID and securityModel and MIID can be used as a
globally-unique identifier for a security-identity.

It is applied important to note that since the PDU MIID may be accessible outside
the engine, care must be taken to not disclose sensitive data, such
as by including passwords in open text in the engine MIID.

7.1.5. Security MIBs

Each Security model defines the MIB modules required for security
processing, including any MIB modules required for the security
mechanism(s) supported. The MIB modules must be defined concurrently
with the procedures which passes use the
PDU MIB module. The MIB modules are
subject to normal security and access control rules.

The mapping between the application. A PDU passed to an application model-dependent identifier and the MIID
must be a
complete PDU, i.e the engine never partially processes a PDU which
is able to be passed to an application.

\

8. Subsystems and Transferring Data Between Subsystems

Transfer of data between determined using SNMP, if the subsystems model-dependent
MIB is deliberately described
as instantiated and access control policy allows.

7.1.6. Security State Cacheing

For each message received, the security subsystem caches the state information
such that a fixed set of abstract data elements which response message can be overloaded to
satisfy generated using the needs same security
state information, even if the security portion of multiple model definitions.

Documents which define models to be used within this architecture are
constrained to using the abstract data elements for transferring data Local Configuration
Datastore is altered between subsystems, possibly defining specific mechanisms the time of the incoming request and the
outgoing response.

The Orangelet subsystem has the responsibility for
converting explicitly releasing
the cached data. To enable this, an abstract state_reference data into model-usable formats. This
constraint exists to allow element
is passed from the security subsystem and model documents to be
written recognizing common borders of the subsystem message processing and model.
Vendors are not constrained control
subsystem, which passes it to recognize these borders in their
implementations. the orangelet subsystem.

The architecture defines certain standard services to cached security data must be provided
between subsystems, and implicitly released via the architecture defines abstract data
elements to transfer generation of a
response, or explicitly released by using the data necessary state_release() primitive:

state_release( state_reference )

7.2. MessageEngine and Message Processing and Control Model Requirements

A messageEngine may contain multiple version-specific Message Processing and
Control models.

Within any version-specific Message Processing and Control model, there may be
an explicit binding to perform the services.

Each model definition for a subsystem must support the standard service
interfaces, particular security model but whether, there should be no
reference to any data defined by a specific security model. there should be

no reference to any specific Orangelet model, or how, to any data defined by a
specific Orangelet model; there should be no reference to any specific Access
Control model, or how well, it performs the service
is to any data defined by the model definition.

8.1. Standard Services of a specific Access Control model.

The Message Processing and Control Models

8.1.1. Receive model must always (conceptually)
pass the complete PDU, i.e. it never forwards less than the complete
list of varbinds.

7.2.1. Receiving an SNMP messages Message from the network Network

Upon receipt of an SNMPng a message from the network, a Message Processing
and Control model the messageEngine will,
in an implementation-defined manner, establish a mechanism for coordinating
all processing regarding this received message, e.g. it may assign a "handle"
to the message.

The Message Processing and Control model will specify how to determine
the values of the MMS, the securityModel, the LoS, and the security
parameters block.

The Message Processing and Control will (conceptually) pass the
extracted MMS, the LoS, the message, and the block of security
parameters to the appropriate Security model.

The Security model, after completion of its processing, will return to
the Message Processing and Control model the group, the securityCookie,
the PDU-MMS, and the PDU.

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

8.1.2. Send SNMP messages to the network

The Message Processing and Control model will pass a PDU,
DBH: It is no longer valid that the
securityCookie, and MPC coordinates all global data to be included in the message to

\

the Security model.

The Security model will construct the message, and return the completed
message to the Message Processing and Control model, which will send
the message to the desired address using the appropriate transport.

8.1.3. Coordinate the Local Processing of a Received Request Message

The Message Processing and Control will receive the SNMP message
according processing. But it
still needs to match requests and responses. how does an incoming request get
matched to the process described in 8.1.1.

The outgoing response?

A Message Processing and Control model will specify how to determine
whether the request should be processed by values
of the Local Processing model
or by an application [FT].

If global data (MMS, the request should be processed locally, securityModel, the LoS), and the security
parameters block. The Message Processing and Control model will (conceptually) pass the PDU, call the Group, the PDU-MMS,
and the LoS, security
model to provide security processing for the Local Processing model.

It will accept a completed PDU containing the responsePDU
from message using the Local Processing primitive:

processMsg( globalData, securityParameters, wholeMsg, wholeMsgLen )

The Security model, and generate a response message
according after completion of its processing, will return to
the process described in 8.1.2.

8.1.4. Forward Received Request Message to an Application

The Message Processing and Control will receive model the extracted information, using
the returnProcess() primitive:

returnProcess( scopedPDUmms, MIID, cachedSecurityData, scopedPDU, statusCode )

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

The Message Processing and Control model will specify how to determine
whether pass a PDU, the request should
MIID, and all global data to be processed by the Local Processing model
or by an application [FT].

If included in the request should be processed by an application [FT], message to
the Message
Processing and Control Security model will assign an implementation-defined
handle to using the message. The Message Processing following primitives:

For requests and Control notifications:

generateRequestMessage( globalData, scopedPDU, MIID, engineID )

DBH: why do we need engineID? isn't that implicit?

For response messages:

generateResponseMessage( globalData, scopedPDU, MIID, cachedSecurityData )

The Security model will
specify how to determine, construct the message, and will (conceptually) pass return the SNMP
version, completed
message to the LoS, messageEngine using the securityCookie, and returngenerate() primitive:

returnGenerate( wholeMsg, wholeMsglen, statusCode )

The messageEngine will send the assigned handle message to the
application [FT].

8.1.5. desired address using the
appropriate transport.

7.2.3. Generate a Request or Notification Message for an Application Orangelet

The Message Processing and Control messageEngine will receive a request for the
generation of an SNMP request message from an application. The
application has the responsibility for providing a Destination Address,
the SNMP version, the LoS desired, the securityCookie to use, a
scopedPDU containing the desired operation, and a handle used for
matching up an incoming response to the application making generation of an SNMP message
from an orangelet via the request. send_pdu primitive:

send_pdu( transportDomain, transportAddress, snmpVersion,
    LoS, securityModel, MIID, contextEngineID,
    contextName, PDU,

The Message Processing and Control messageEngine checks the verb in the PDU to determine that if it is a request message, message
which may receive a response, and if so, skips local
processing caches the msgID of the PDU.

\

The Message Processing generated
message and Control the associated orangelet.

The messageEngine will generate the message according to the process described
in 8.1.2.

8.1.6. 7.2.2.

7.2.4. Forward Received Response Message to an Application Orangelet

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

The Message Processing and Control will determine which application orangelet is
awaiting a response, using the handle assigned to msgID and the transaction in cached information from
step 8.1.3 7.2.3

The Message Processing and Control will pass to the application the
 LoS, messageEngine matches the securityCookie, msgID of an incoming response to the PDU-MMS, cached
msgIDs of messages sent by this messageEngine, and forwards the PDU.

An Application, using the securityCookie, can determine response to the
securityIdentity on whose behalf
associated Orangelet using the response should be processed.

8.1.7. process_pdu() primitive:

process_pdu( contextEngineID, contextName, pdu, LoS, scopedPdu-MMS,
	securityModel, MIID, state-reference )

7.2.5. Forward Received Request or Notification Message to an Application Orangelet

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

The Message Processing and Control messageEngine will determine to which application
traps should be forwarded.
DBH: is this true? isn't this a function of an application support
subsystem to de-multiplex traps to the appropriate application? Isn't
this necessarily part of SNMP, since the indication of the appropriate
application may need to be provided by look into the SNMP message (e.g. msgID)

The Message Processing and Control subsystem will pass scopedPDU to the
application the LoS, the securityCookie, the PDU-MMS, and the PDU.

An Application, using the securityCookie, can determine the
securityIdentity on whose behalf the notification should be processed.

8.1.8. Send a Notification

The Message Processing and Control subsystem accepts from an
application a request to send a notification message. The application
provides the address to contextEngineID,
then determine which the notification should be sent, the
SecurityCookie orangelet has registered to use, the LoS, and a completed scopedPDU.

Notifications are not processed by a Local Processing model, support that contextEngineID,
and
therefore are not subject to access control of their contents.

8.1.9. Send a Response Message from an Application

An application, using local information can determine forwards the
securityCookie to use request or notification to generate the message.

\

The application will pass to registered Orangelet using the
process_pdu() primitive:

process_pdu( contextEngineID, contextName, pdu, LoS, scopedPdu-MMS,
	securityModel, MIID, state-reference )

7.2.6. Generate a Response Message Processing and Control
subsystem for an Orangelet

The messageEngine will receive a request for the securityCookie, generation of an SNMP response
message from an orangelet via the return_pdu primitive:

return_pdu( contextEngineID, contextName, LoS, and the scopedPDU. MIID, state_reference,
	PDU, PDU-MMS, status_code )

The Message Processing and Control messageEngine will send generate the SNMP message according to the process described
in 8.1.2.

8.2. Standard Services Required of Security Models

8.2.1. validate the security-stamp in 7.2.2.

7.3. Orangelet Model Design Requirements

Within an Orangelet model, there may be an explicit binding to a received specific
SNMP message

given version, i.e. a message, the MMS, LoS, specific Message Processing and the security parameters from that
message, verify the message has not been altered, Control model,
and authenticate
the identification of the securityIdentity for whom the message was
generated.

If encrypted, decrypt the message

Additional requirements may to a specific Access Control model, but there should be no reference to
any data defined by the model, a specific Message Processing and additional
services provided by the model, but the Control model is constrained or Access
Control model.

Within an Orangelet model, there should be no reference to use
only the defined abstract data elements for transferring any
specific Security model, or any data between
subsystems. Implementations are no so constrained.

return defined by a securityCookie identifying specific Security
model.

An Orangelet determines whether explicit or implicit access control
should be applied to the securityIdentity for whom operation, and, if access control is needed,
which Access Control model should be used.

An orangelet has the
message was generated responsibility to define any MIB modules used
to provide orangelet-specific services.

Orangelets interact with the messageEngine to initiate messages, receive
responses, receive asynchronous messages, and return send responses.

7.3.1. Orangelets that Initiate Messages

Orangelets may request that the portions messageEngine send messages containing SNMP
polling requests or notifications using the send_pdu() primitive:

send_pdu( transportDomain, transportAddress, snmpVersion,
    LoS, securityModel, MIID, contextEngineID,
    contextName, PDU,

[DBH: I rearranged these parameters into groups of the message needed for
further processing:
         a PDU related data organized
roughly by order of locality - transport/engine/contextEngine/PDU.]

If it is desired that a PDU containing varbinds and a verb according message be sent to multiple targets, it is the rules
reponsibility of the Local Processing model orangelet to be used.
         LoS - provide the level of security required. iteration.

The same level of
            security must also be used during application of messageEngine assumes necessary access
            control.
         MMS - control has been applied
to the maximum size of PDU, and provides no access control services.

The messageEngine looks at the verb, and for operations which will elicit a message able
response, the msgID and the associated orangelet are cached.

7.3.2. Orangelets that Receive Responses

The messageEngine matches the msgID of an incoming response to be generated the cached
msgIDs of messages sent by this engine for messageEngine, and forwards the destination agent.
         PDU-MMS - response to the maximum size of
associated Orangelet using the process_pdu() primitive:

process_pdu( contextEngineID, contextName, pdu, LoS, scopedPdu-MMS,
	securityModel, MIID, state-reference )

DBH: should the MPC release the state_reference when it receives a PDU response?
There isn't much reason to be included in force the orangelet to handle this if the MPC
already knows it is a response message, given i.e. the amount end of
            reserved space in a transaction.

7.3.3. Orangelets that Receive Asynchronous Messages

When a messageEngine receives a message that is not the response to a request
from this messageEngine, it must determine to which Orangelet the message for
should be given.

An Orangelet that wishes to receive asynchronous messages registers
itself with the anticipated
            security parameters.
         GroupName - messageEngine using the GroupName registration primitive.
An Orangelet that wishes to be applied for access control for stop receiving asynchronous messages
should un-register itself with the securityIdentity messageEngine.

register_contextEngineID ( contextEngineID )
unregister_contextEngineID ( contextEngineID )

Only one registration per contextEngineID is permitted at the same
time. Duplicate registrations are ignored.

[DBH: there is no provision for whom an error for this. Is the request was generated.

8.2.2. security-stamp second
just ignored?]

All asynchronously received messages referencing a message

Given registered contextEngineID
will be sent to the orangelet which registered to support that contextEngineID.
This includes incoming requests, incoming notifications, and proxies.

It forwards the PDU to the registered Orangelet, using the process_pdu()
primitive:

process_pdu( contextEngineID, contextName, PDU, PDU-MMS,
    LoS, securityModel, MIID, state_reference )

7.3.4. Orangelets that Send Responses

Request operations require responses. These operations include Get requests,
set requests, and inform requests. An Orangelet sends a response via the
return_pdu primitive:

return_pdu( contextEngineID, contextName, LoS, MIID, state_reference,
	PDU, PDU-MMS, status_code )

The contextEngineID, contextName, LoS, MMS, MIID, and a securityCookie, the Security model
must determine the security state_reference parameters for the message,
are from the contents initial process_pdu() primitive. The PDU and format of which status_code are defined by
the model.

The Security model will return results of processing.

DBH: in the v2adv approach, a message including handle was passed so the appropriate
security parameters, encrypted if required.

8.2.3. Provide mappings between security entities and securityCookies

\

Given model-specific parameters messageEngine
could match the response to identify a securityIdentity,
an Security model must return a securityCookie

Given a securityCookie generated by this Security model, the Security incoming request. How is it done now?

7.4. Access Control Model Design Requirements

An Access Control model must return model-specific data identifying determine whether the corresponding
securityIdentity.

8.3. Standard Services of a Local-Processing Model

8.3.1. Process a request

Given a PDU, Group, LoS, and PDU-MMS, specified
MIID is allowed to perform the requested operation on
a Local Processing specified managed object. The Access Control model must
return a PDU processed according to specifies the protocol
rules defined by which access control is determined.

A model may define mechanisms to provide additional processing
features, but is constrained to using the
Local Processing model.

\

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

The persistent data used for access control should be manageable
using SNMP, but the Access Control model defines whether an
instantiation of the MIB is a conformance requirement.

8. Security Consideration

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

The level of security provided is determined by the specific Security
model implementation(s) and the specific Local Processing model
implementation(s) incorporated into this framework.

Applications

Orangelets have access to data which is not secured. Applications Orangelets
should take reasonable steps to protect the data from disclosure.

It is the responsibility of the purchaser of an SNMPng engine a management framework
implementation to ensure that:
  1) an implementation of this framework is fully compliant with
      the rules laid down defined by this framework, architecture,
  2) the implementation of the Security model complies with the
      rules of the Security model,
  3) the implementation of the Local Processing model complies
      with the rules of the Local Processing model,
  4) the implementation of associated applications orangelets comply
      with the rules of this framework relative to applications, orangelets,
  5) the Security model of the implementation(s) incorporated into
      this
      the framework satisfy the security needs of the organization
      using the SNMPng engine, organization,
  6) the Local Processing model of the implementation(s) incorporated
      into this the framework satisfy the access control policies of the
      organization using the SNMPng engine,
      organization,
  7) the implementation of the Security model protects against
      inadvertently revealing security secrets in its design of
      implementation-specific data structures,
  8) the implementation of the Local Processing model protects against
      inadvertently revealing configuration secrets in its design of
      implementation-specific data structures,
  9) and the applications associated with this engine should take
      reasonable steps to protect of
      implementation-specific data structures,
  9) and implementation of the orangelets protect security and
      access control configuration secrets from disclosure.

\

9. Glossary

10. References

[RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of
    Management Information for TCP/IP-based internets", STD 16, RFC
    1155, May 1990.

[RFC1157] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
    Network Management Protocol", RFC 1157, University of Tennessee
    at Knoxville, Performance Systems International, Performance
    International, and the MIT Laboratory for Computer
    Science, May 1990.

[RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions",
    STD 16, RFC 1212, March 1991.

[RFC1445] Galvin, J., and McCloghrie, K., "Administrative Model for
    version 2 of the Simple Network Management Protocol (SNMPv2)",
    RFC 1445, Trusted Information Systems, Hughes LAN Systems,
    April 1993.

[RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
    Rose, M., and S., Waldbusser, "Introduction to
    Community-based SNMPv2", RFC 1901, January 1996.

[RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
    Rose, M., and S., Waldbusser, "Structure of Management
    Information for Version  2 of the Simple Network Management
    Protocol (SNMPv2)", RFC 1905, January 1996.

[RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
    and S. Waldbusser, "Textual Conventions for Version 2 of the Simple
    Network Management Protocol (SNMPv2)", RFC 1903, January 1996.

[RFC1904] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
    and S., Waldbusser, "Conformance Statements for Version 2 of the
    Simple Network Management Protocol (SNMPv2)", RFC 1904,
    January 1996.

[RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
    Rose, M., and S., Waldbusser, "Protocol Operations for
    Version 2 of the Simple Network Management Protocol (SNMPv2)",
    RFC 1905, January 1996.

[RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
    Rose, M., and S. Waldbusser, "Transport Mappings for
    Version 2 of the Simple Network Management Protocol (SNMPv2)",
    RFC 1906, January 1996.

[RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
    Rose, M., and S. Waldbusser, "Management Information Base for
    Version 2 of the Simple Network Management Protocol (SNMPv2)",

\
    RFC 1907 January 1996.

[RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
    Rose, M., and S. Waldbusser, "Coexistence between Version 1
    and Version 2 of the Internet-standard Network Management
    Framework", RFC 1908, January 1996.

[RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure
    for SNMPv2", RFC1909, February 1996

[RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2",
    RFC1910, February 1996

\

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

\

12. Acknowledgements

This document builds on the work of the SNMP Security and
Administrative Framework Evolution team, comprised of

     David Harrington (Cabletron Systems Inc.)
     Jeff Johnson (Cisco)
     David Levi (SNMP Research Inc.)
     John Linn (Openvision)
     Russ Mundy (Trusted Information Systems) chair
     Shawn Routhier (Epilogue)
     Glenn Waters (Nortel)
     Bert Wijnen (IBM T.J. Watson Research)

\

Table of Contents

0. Issues                                                              3
0.1.  Issues to be resolved                                            3
0.2.  Change Log                                                         2                                                       3
1. Introduction                                                        4                                                        5
1.1. A Note on Terminology                                             4                                             5
2. Overview                                                            5                                                            6
3. An Evolutionary Architecture - Design Goals                         6                         7
3.1. Encapsulation                                                     6                                                     7
3.2. Cohesion                                                          6                                                          7
3.3. Hierarchical Rules                                                6                                                8
3.4. Coupling                                                          7                                                          8
4. Abstract Functionality                                              9                                             10
4.1. Message Processing and Control                                    9 The messageEngine                                                10
4.1.1. Transport Mappings                                              9                                             10
4.1.2. SNMP-Based Message Formats                                      9                                     10
4.1.3. Application-Based Message Formats                               9 The Interface to Orangelets                                    11
4.1.4.  Protocol Instrumentation                                       9                                      11
4.2. Security                                                         10                                                         11
4.3. Local Processing                                                 10
4.3.1. Orangelets                                                       11
4.4.1.  Structure of Management Information                           10
4.3.2.                           12
4.4.2.  Textual Conventions                                           11
4.3.3.                                           12
4.4.3.  Conformance Statements                                        11
4.3.4.                                        12
4.4.4.  Protocol Operations                                           11
4.4. Applications                                                     11
4.5                                           12
4.5. Access Control                                                   13
4.6. Coexistence                                                       11                                                      13
5. Abstract Data Elements of the Architecture                         13
5.1                         14
5.1. engineID                                                          13                                                         14
5.2. SecurityIdentity                                                 13                                                 14
5.3. Model Independent Identifier (MIID)                              14
5.4. Level of Security                                                13
5.4. Groups                                                           13                                                14
5.5. Contexts                                                         13                                                         15
5.6. ContextEngineID                                                  14
5.7. ContextName                                                      14                                                      15
5.7. ContextEngineID                                                  15
5.8. Naming Scope                                                     14                                                     15
5.9. Scoped-PDU                                                       14                                                       15
5.10. PDU-MMS                                                         14                                                         15
5.11. Local Configuration Datastore                                   15
5.11.1. Security Portion of the Local Configuration Datastore                                14
5.12.         16
5.11.2. Orangelet Portion of the Local Configuration Datastore                                   14
6. Textual Conventions for        16
5.11.3. Access Control Portion of the SNMPng Architecture Local Configuration Datastore   16
5.12. Groups                                                          16
6. Definition of Managed Objects for Internet Management Frameworks   17
7. Model Design Requirements                                          19                                          24
7.1. Security Model Design Requirements                               19
7.2. Local                               24
7.1.1. Threats                                                        24
7.1.2. Security Processing                                            25
7.1.3. validate the security-stamp in a received message              26
7.1.4. Security Identity                                              27
7.1.5. Model Design Requirements                       20
7.3. Message Processing and Control Requirements                      21
7.4. Applications                                                     21
7.4.1. Application Responsibilities                                   21
8. Subsystems Dependent Identifier                                     27
7.1.6. Model Independent Identifier                                   27
7.1.5. Security MIBs                                                  28
7.1.6. Security State Cacheing                                        28
7.2. MessageEngine and Transferring Data Between Subsystems                23
8.1. Standard Services of Message Processing and Control Models       23
8.1.1. Receive Model Requirements 28
7.2.1. Receiving an SNMP messages Message from the network                         23
8.1.2. Network                     29
7.2.2. Send SNMP messages to the network                              23
8.1.3. Coordinate the Local Processing of a Received Request Message  24
8.1.4. Forward Received Request Message to an Application             24
8.1.5.                              29
7.2.3. Generate a Request or Notification Message for an Application                  24
8.1.6. Orangelet    30
7.2.4. Forward Received Response Message to an Application            25
8.1.7. Orangelet              30
7.2.5. Forward Received Request or Notification Message to an Application        25
8.1.8. Send a Notification                                            25
8.1.9. Send Orangelet 30
7.2.6. Generate a Response Message from for an Application                    25
8.2. Standard Services Required of Security Models                    26
8.2.1. validate the security-stamp in a received message              26
8.2.2. security-stamp a message                                       26
8.2.3. Provide mappings between security entities and securityCookies 26
8.3. Standard Services of a Local-Processing Orangelet                   31
7.3. Orangelet Model                    27
8.3.1. Process a request                                              27
9. Design Requirements                              31
7.3.1. Orangelets that Initiate Messages                              31
7.3.2. Orangelets that Receive Responses                              32
7.3.3. Orangelets that Receive Asynchronous Messages                  32
7.3.4. Orangelets that Send Responses                                 32
7.4. Access Control Model Design Requirements                         33
8. Security Consideration                                             28                                             34
9. Glossary                                                           35
10. References                                                        29                                                        36
11. Editor's Addresses                                                31                                                38
12. Acknowledgements                                                  32                                                  39