[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 rfc2261                                  
                       An Architecture for Describing
                      Internet Management Frameworks

                             17 June 1997


                               D. Harrington
                           Cabletron Systems, Inc.
                              dbh@cabletron.com

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


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




                           Status of this Memo

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

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

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



                              Abstract

This document describes an architecture for describing Internet
Management Frameworks. The architecture is designed to be modular
to allow the evolution of the protocol over time. The major portions
of the architecture are a messaging engine containing a message
processing and control subsystem and a security subsystem, plus a
data processing engine, called a context engine, which contains an
access control subsystem, a MIB access subsystem, and possibly
multiple orangelets which provide specific functional processing
of network management data.



Harrington/Wijnen         Expires December 1977        [Page  1]

Draft   Architecture for Describing Internet Management Frameworks   March 1997
























































Harrington/Wijnen         Expires December 1977        [Page  2]

Draft   Architecture for Describing Internet Management Frameworks   March 1997


0. Issues

0.1.  Issues to be resolved
 . Need the "readable" introduction supplement
 . taxonomy:
        orangelets
 . should the scopedPDU be contained in the securityParameters
    SEQUENCE, so encryption can include the PDU and some of the
    security parameters?
 . Who counts SNMP messages? who counts snmpv3 messages?
 . reportPDUs created from an error status or OID returned by the appropriate
        subsystem/model?
 . foward refreences need to be handled
 . some TCs were defined for interface parameters, but aren't part of a mIB.
        move to Glossary?
 . Is AdminString appropriate for all strings, such as securityidentifier and
        context and group? These had different sizes and semantics.
 . AdminString has size (1..255); what about default context of ""?
 . snmpEngineMaxMessageSize maximum size? 65507? what about non-UDP transports?
 . description of max message size
 . definitioon/description of MD5/DES protocol OIDs.
 . should the tree for registering protocols be in basicGroup?
 . should User-based be in basicgroup conformance?
 . how does MPC match incoming requests with outgoing responses?
 . generateRequestMessage( globalData, scopedPDU, MIID, engineID )
        why do we need engineID? isn't that implicit?
 . I rearranged primitive parameters: transport/engine/contextEngine/PDU
 . state_refernce releases - are these consistently defined?
 . should the MPC release the state_reference when it receives a response?
 . How is duplicate registration handled? error or ignore?

0.2.  Change Log

[version 3.1]
 . change securityIdentity to MIID
 . write text to explain the differences between security-identities,
   model-dependent identifiers, and model-independent identifiers.
 . write text to explain distinction within the LCD of the security
   data, the access control data, and the oranglet data.
 . identify issues
 . publish as <draft-ietf-snmpv3-next-gen-arch-02.txt>

[version 3.0]
 . add section on threats for message security
 . add section on threats for access control
 . change application to orangelet
 . remove references to F-Ts
 . change securityIdentity to security-identity
 . change securityCookie to securityIdentity
 . the format of securityIdentity is defined by the model
 . add securityModel to passed parameters as needed



Harrington/Wijnen         Expires December 1977        [Page  3]

Draft   Architecture for Describing Internet Management Frameworks   March 1997


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








































Harrington/Wijnen         Expires December 1977        [Page  4]

Draft   Architecture for Describing Internet Management Frameworks   March 1997


1. Introduction

A management system contains: several (potentially many) nodes, each
with a processing entity, termed an agent, which has access to
management instrumentation; at least one management station; and, a
management protocol, used to convey management information between the
agents and management stations, or between management stations and
other management stations.

Management stations execute management applications which monitor and
control managed elements. Managed elements are devices such as hosts,
routers, terminal servers, etc., which are monitored and controlled via
access to their management information.

Operations of the protocol are carried out under an administrative
framework which defines minimum requirements for standard services,
such as sending and receiving messages, countering security threats to
messages, controlling access to managed objects, and processing various
types of requests.

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

1.1. A Note on Terminology

This architecture is designed to allow an orderly evolution of
portions of SNMP Frameworks.

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

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

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

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

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




Harrington/Wijnen         Expires December 1977        [Page  5]

Draft   Architecture for Describing Internet Management Frameworks   March 1997


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

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

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

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

2. Overview

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

SNMP processing must be performed in consistently ordered steps, which
fall into general categories of similar functionality. This document
will describe major abstractions of functionality required during
SNMP processing, and the abstract interactions between these major
categories of functionality.

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
























Harrington/Wijnen         Expires December 1977        [Page  6]

Draft   Architecture for Describing Internet Management Frameworks   March 1997


3. An Evolutionary Architecture - Design Goals

The goals of the architectural design are to use encapsulation,
cohesion, hierarchical rules, and loose coupling to reduce complexity
of design and make the evolution of portions of the architecture
possible.

3.1. Encapsulation

Encapsulation describes the practice of hiding the details that are
used internal to a process. Some data is required for a given
procedure, but isn't needed by any other part of the process.

In networking, the concept of a layered stack reflects this approach.
The transport layer contains data specific to its processing; the data
is not visible to the other layers. In programming this is reflected
in language elements such as "file static" variables in C, and
"private" in C++, etc.

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

3.2. Cohesion

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

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

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






Harrington/Wijnen         Expires December 1977        [Page  7]

Draft   Architecture for Describing Internet Management Frameworks   March 1997


3.3. Hierarchical Rules

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

This architecture uses the hierarchical approach by defining
subsystems, which specify the general rules of a portion of the system,
models which define the specific rules to be followed by an
implementation of the portion of the system, and implementations which
encode those rules into reality for a portion of the system.

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

3.4. Coupling

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

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

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

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

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

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



Harrington/Wijnen         Expires December 1977        [Page  8]

Draft   Architecture for Describing Internet Management Frameworks   March 1997


describing the interaction of subsystems or models should use only
the abstract data elements provided for transferring data but vendors
are not constrained to using the described data elements for
transferring data between portions of their implementation.

Loose coupling works well with the IETF standards process. If we
separate message-handling from security and from local processing,
then the separate portions of the system can move through the standards
process with less dependence on the status of the other portions of the
standard. Security models may be able to be re-opened for discussion
due to patents, new research, export laws, etc., as is clearly expected
by the WG, without needing to reopen the documents which detail the
message format or the local processing of PDUs. Thus, the standards
track status of related, but independent, documents is not affected.








































Harrington/Wijnen         Expires December 1977        [Page  9]

Draft   Architecture for Describing Internet Management Frameworks   March 1997


4. Abstract Functionality

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

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

The subsystems are contained in two "engines".

A messageEngine deals with SNMP messages, and is responsible for
sending and receiving messages, including having authentication
and encryption services applied to the messages, and determining
to which Orangelet the message contents should be delivered.

A contextEngine deals with processing network management operations,
and contains subsystems for Access Control, MIB access, and
Orangelets which provide specific functional processing.
Depending on the network management service needed, an Orangelet
may use the access control and MIB access subsystems, and may use
SNMP messages to communicate with remote nodes. The network
management service may be requested via the payload of an SNMP
message, or may be requested via a local process.

4.1. The messageEngine

The messageEngine interacts with the network using SNMP messages,
and with the message processing subsystem and the security subsystem
and with orangelets using service interfaces defined within this
architecture.

4.1.1. Transport Mappings

SNMP messages are sent to, or received from, the network using
transport addresses. It is the responsibility of the messageEngine
to listen at the appropriate local addresses, and to send messages
through the appropriate addresses, consistent with mappings defined
by SNMP Transport Mapping documents, such as RFC1906.

4.1.2. SNMP-Based Message Formats

SNMP messages sent to, or received from, the network use a format
defined by a version-specific Message Processing and Control model.
The messageEngine determines to which version-specific model the
message should be given.

The version-specific model interacts with the security subsystem,



Harrington/Wijnen         Expires December 1977        [Page 10]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


using a service interface defined by this architecture, to procure
security services to meet the requirements of the version-specific
protocol.

4.1.3. The Interface to Orangelets

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

4.1.4.  Protocol Instrumentation

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

A Message Processing and Control model may require support for
MIB modules related to instrumenting version-specific aspects
of the SNMP protocol.

4.2. Security

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

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

4.3. Orangelets

Orangelets coordinate the processing of management information
operations.

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

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




Harrington/Wijnen         Expires December 1977        [Page 11]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


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

4.4.1.  Structure of Management Information

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

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

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

4.4.2.  Textual Conventions

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

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

4.4.3.  Conformance Statements

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

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

4.4.4.  Protocol Operations

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

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






Harrington/Wijnen         Expires December 1977        [Page 12]


Draft   Architecture for Describing Internet Management Frameworks   March 1997



4.5. Access Control

During processing, it may be required to control access to certain
instrumentation for certain operations. The determination of
access rights requires the means to identify the access allowed for
the security-identity on whose behalf a request is generated.

An Access Control model provides an advisory service for an
Orangelet. The determination of whether to check access control
policy is the responsibility of the Orangelet model. The mechanism
by which access control is checked is defined by the Access Control
model.

4.6. Coexistence

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

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

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

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





















Harrington/Wijnen         Expires December 1977        [Page 13]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


5. Abstract Data Elements of the Architecture

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

5.1. engineID

Each SNMP engine, consisting of potentially many subsystems, must be
able to be uniquely identified. The mechanism by which this can be
done is defined in the IMFMIB module, described in this document,
since it is desirable that engine identification span all frameworks.

5.2. SecurityIdentity

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

5.3. Model Independent Identifier (MIID)

Each security model must also provide a mapping from the model
specific identification to an SnmpAdminString representation,
called the MIID, which, in combination with the securityModel,
can be used by all other subsystems within an engine to identify
a security identity, regardless of the security mechanisms used to
provide security services.

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

5.4. Level of Security

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

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

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






Harrington/Wijnen         Expires December 1977        [Page 14]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


5.5. Contexts

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

5.6. ContextName

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

5.7. ContextEngineID

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

5.8. Naming Scope

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

5.9. Scoped-PDU

A scopedPDU contains a Naming-Scope and a PDU.

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

The PDU format is defined by an Orangelet model, or a document
referenced by an Orangelet model, which processes the PDU contents.

5.10. PDU-MMS

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

5.11. Local Configuration Datastore

The subsystems and models in an SNMP engine may need to retain their
own, possibly multiple, sets of information to perform their
processing. To allow these sets of information to be remotely
configured, portions may need to be accessible as managed objects.

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




Harrington/Wijnen         Expires December 1977        [Page 15]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


5.11.1. Security Portion of the Local Configuration Datastore

Each Security model may need to retain its own set of information about
security entities, mechanisms, and policies.

5.11.2. Orangelet Portion of the Local Configuration Datastore

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

5.11.3. Access Control Portion of the Local Configuration Datastore

Each Access Control model may need to retain its own set of
information about access control policies, and the MIIDs
to which the policies apply.

5.12. Groups

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

































Harrington/Wijnen         Expires December 1977        [Page 16]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


6. Definition of Managed Objects for Internet Management Frameworks

IMF-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, snmpModules,
    Unsigned32, Integer32                         FROM SNMPv2-SMI
    TEXTUAL-CONVENTION                            FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP               FROM SNMPv2-CONF;

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

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

                  Co-editor   Dave Harrington
                              Cabletron Systems, Inc
                  postal:     Post Office Box 5005
                              MailStop: Durham
                              35 Industrial Way
                              Rochester NH 03867-5005
                  email:      dbh@cabletron.com
                  phone:      603-337-7357

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

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

-- Textual Conventions used in the Internet Management Architecture ***

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




Harrington/Wijnen         Expires December 1977        [Page 17]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


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

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

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

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

SnmpSecurityModel ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "An identifier that uniquely identifies a model of
                 security subsystem within the Internet
                 Management Architecture.
                "
    SYNTAX       INTEGER(0..2147483647)

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



Harrington/Wijnen         Expires December 1977        [Page 18]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


--               The security model defines what information must be
--               retained for use in sending the response.
--              "
--  SYNTAX      OCTET STRING

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

SnmpAdminString ::= TEXTUAL-CONVENTION
    STATUS        current
    DESCRIPTION  "An octet string containing an SNMP administrative
                  string.  Preferably this a a human readable string.
                  We're still thinking if this could use the UTF8
                  character set.
                 "
    SYNTAX        OCTET STRING (SIZE(1..255))

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



Harrington/Wijnen         Expires December 1977        [Page 19]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


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

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

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

-- the imfEngine group ***********************************************

imfEngine OBJECT IDENTIFIER ::= { imfMIBObjects 1 }

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

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

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

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



Harrington/Wijnen         Expires December 1977        [Page 20]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


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

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

imfAuthProtocols      OBJECT IDENTIFIER ::= { imfAdmin 1 }

imfNoAuthProtocol     OBJECT IDENTIFIER ::= { imfAuthProtocols 1 }

imfAuthMD5Protocol    OBJECT IDENTIFIER ::= { imfAuthProtocols 2 }




Harrington/Wijnen         Expires December 1977        [Page 21]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


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

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

imfPrivProtocols      OBJECT IDENTIFIER ::= { imfAdmin 2 }

imfNoPrivProtocol     OBJECT IDENTIFIER ::= { imfPrivProtocols 1 }

imfDESPrivProtocol    OBJECT IDENTIFIER ::= { imfPrivProtocols 2 }

-- conformance information

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

-- compliance statements

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

-- units of conformance

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

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



Harrington/Wijnen         Expires December 1977        [Page 22]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


--            as a minimum. No?

END



















































Harrington/Wijnen         Expires December 1977        [Page 23]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


7. Model Design Requirements

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

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

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

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

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

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

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

7.1. Security Model Design Requirements

7.1.1. Threats

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

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




Harrington/Wijnen         Expires December 1977        [Page 24]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


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

Masquerade
     The masquerade threat is the danger that management operations
     not authorized for some security-identity may be attempted by
     assuming the identity of another security-identity that has the
     appropriate authorizations.

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

Disclosure
     The disclosure threat is the danger of eavesdropping on the
     exchanges between SNMP engines. Protecting against this threat
     may be required as a matter of local policy.

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

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

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

7.1.2. Security Processing

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



Harrington/Wijnen         Expires December 1977        [Page 25]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


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

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

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

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

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

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

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

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

7.1.3. validate the security-stamp in a received message

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

If encrypted, decrypt the message

Additional requirements may be defined by the model, and additional



Harrington/Wijnen         Expires December 1977        [Page 26]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


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

return a MIID identifying the security-identity for whom
the message was generated and return the portions of the message
needed for further processing:
         a PDU - a PDU containing varbinds and a verb according to
            the rules of the Local Processing model to be used.
         LoS - the level of security required. The same level of
            security must also be used during application of access
            control.
         MMS - the maximum size of a message able to be generated
            by this engine for the destination agent.
         PDU-MMS - the maximum size of a PDU to be included in a
            response message, given the amount of
            reserved space in the message for the anticipated
            security parameters.

7.1.4. Security Identity

Different security models define identifiers which represent some
<thing> which somehow exists, and is capable of using SNMP.
The <thing> may be person, or a network-management platform, or
an aggregate of persons, or an aggregation of persons and devices,
or some other abstraction of entities that are recognized as
being able to use SNMP-defined services.

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

7.1.5. Model Dependent Identifier

Each Security model defines how security-identities are identified
within the model, i.e. how they are named. Model-dependent identifiers
must be unique within the model. The combination of engineID,
securityModel, and the correct model-dependent identifier can be
used to uniquely identify a security-identity.

For example, David Harrington may be represented on a particular
engine by multiple security models - as the user "davidh", the
community "david", and the foobar "david". It is legal to use
"david" in more than one model, since uniqueness is only guaranteed
within the model, but there cannot be two "david" communities.
The combination of the engineID, the <user> model, and the user
"davidh" uniquely identifies the security-entity David Harrington.

7.1.6. Model Independent Identifier

It is desirable to be able to refer to a security-entity using a human
readable identifier, such as for audit trail entries.
Therefore, each Security model is required to define a mapping between



Harrington/Wijnen         Expires December 1977        [Page 27]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


a model-dependent identifier and an identifier restricted to a human
readable character set. This identifier is called a MIID.

The type of a MIID is a human-readable OCTET STRING following the
conventions of the SnmpAdminString TEXTUAL-CONVENTION, defined below.

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

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

7.1.5. Security MIBs

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

The mapping between the model-dependent identifier and the MIID
must be able to be determined using SNMP, if the model-dependent
MIB is instantiated and access control policy allows.

7.1.6. Security State Cacheing

For each message received, the security subsystem caches the state information
such that a response message can be generated using the same security
state information, even if the security portion of the Local Configuration
Datastore is altered between the time of the incoming request and the
outgoing response.

The Orangelet subsystem has the responsibility for explicitly releasing
the cached data. To enable this, an abstract state_reference data element
is passed from the security subsystem to the message processing and control
subsystem, which passes it to the orangelet subsystem.

The cached security data must be implicitly released via the generation of a
response, or explicitly released by using the state_release() primitive:

state_release( state_reference )

7.2. MessageEngine and Message Processing and Control Model Requirements

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

Within any version-specific Message Processing and Control model, there may be
an explicit binding to a particular security model but there should be no
reference to any data defined by a specific security model. there should be



Harrington/Wijnen         Expires December 1977        [Page 28]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


no reference to any specific Orangelet model, or to any data defined by a
specific Orangelet model; there should be no reference to any specific Access
Control model, or to any data defined by a specific Access Control model.

The Message Processing and Control model must always (conceptually)
pass the complete PDU, i.e. it never forwards less than the complete
list of varbinds.

7.2.1. Receiving an SNMP Message from the Network

Upon receipt of a message from the network, the messageEngine will,
in an implementation-defined manner, establish a mechanism for coordinating
all processing regarding this received message, e.g. it may assign a "handle"
to the message.
DBH: It is no longer valid that the MPC coordinates all processing. But it
still needs to match requests and responses. how does an incoming request get
matched to the outgoing response?

A Message Processing and Control model will specify how to determine the values
of the global data (MMS, the securityModel, the LoS), and the security
parameters block. The Message Processing and Control will call the security
model to provide security processing for the message using the primitive:

processMsg( globalData, securityParameters, wholeMsg, wholeMsgLen )

The Security model, after completion of its processing, will return to
the Message Processing and Control model the extracted information, using
the returnProcess() primitive:

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

7.2.2. Send SNMP messages to the network

The Message Processing and Control model will pass a PDU, the
MIID, and all global data to be included in the message to
the Security model using the following primitives:

For requests and notifications:

generateRequestMessage( globalData, scopedPDU, MIID, engineID )

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

For response messages:

generateResponseMessage( globalData, scopedPDU, MIID, cachedSecurityData )

The Security model will construct the message, and return the completed
message to the messageEngine using the returngenerate() primitive:

returnGenerate( wholeMsg, wholeMsglen, statusCode )



Harrington/Wijnen         Expires December 1977        [Page 29]


Draft   Architecture for Describing Internet Management Frameworks   March 1997



The messageEngine will send the message to the desired address using the
appropriate transport.

7.2.3. Generate a Request or Notification Message for an Orangelet

The messageEngine will receive a request for the generation of an SNMP message
from an orangelet via the send_pdu primitive:

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

The messageEngine checks the verb in the PDU to determine if it is a message
which may receive a response, and if so, caches the msgID of the generated
message and the associated orangelet.

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

7.2.4. Forward Received Response Message to an Orangelet

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

The Message Processing and Control will determine which orangelet is
awaiting a response, using the msgID and the cached information from
step 7.2.3

The messageEngine matches the msgID of an incoming response to the cached
msgIDs of messages sent by this messageEngine, and forwards the response to the
associated Orangelet using the process_pdu() primitive:

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

7.2.5. Forward Received Request or Notification Message to an Orangelet

The messageEngine will receive the SNMP message according to the process
described in 7.2.1.

The messageEngine will look into the scopedPDU to determine the contextEngineID,
then determine which orangelet has registered to support that contextEngineID,
and forwards the request or notification to the registered Orangelet using the
process_pdu() primitive:

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






Harrington/Wijnen         Expires December 1977        [Page 30]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


7.2.6. Generate a Response Message for an Orangelet

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

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

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

7.3. Orangelet Model Design Requirements

Within an Orangelet model, there may be an explicit binding to a specific
SNMP message version, i.e. a specific Message Processing and Control model,
and to a specific Access Control model, but there should be no reference to
any data defined by a specific Message Processing and Control model or Access
Control model.

Within an Orangelet model, there should be no reference to any
specific Security model, or any data defined by a specific Security
model.

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

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

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

7.3.1. Orangelets that Initiate Messages

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

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

[DBH: I rearranged these parameters into groups of related data organized
roughly by order of locality - transport/engine/contextEngine/PDU.]

If it is desired that a message be sent to multiple targets, it is the
reponsibility of the orangelet to provide the iteration.

The messageEngine assumes necessary access control has been applied
to the PDU, and provides no access control services.




Harrington/Wijnen         Expires December 1977        [Page 31]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


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

7.3.2. Orangelets that Receive Responses

The messageEngine matches the msgID of an incoming response to the cached
msgIDs of messages sent by this messageEngine, and forwards the response to the
associated Orangelet using the process_pdu() primitive:

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

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

7.3.3. Orangelets that Receive Asynchronous Messages

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

An Orangelet that wishes to receive asynchronous messages registers
itself with the messageEngine using the registration primitive.
An Orangelet that wishes to stop receiving asynchronous messages
should un-register itself with the messageEngine.

register_contextEngineID ( contextEngineID )
unregister_contextEngineID ( contextEngineID )

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

[DBH: there is no provision for an error for this. Is the second
just ignored?]

All asynchronously received messages referencing a registered contextEngineID
will be sent to the orangelet which registered to support that contextEngineID.
This includes incoming requests, incoming notifications, and proxies.

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

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

7.3.4. Orangelets that Send Responses

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



Harrington/Wijnen         Expires December 1977        [Page 32]


Draft   Architecture for Describing Internet Management Frameworks   March 1997



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

The contextEngineID, contextName, LoS, MIID, and state_reference parameters
are from the initial process_pdu() primitive. The PDU and status_code are
the results of processing.

DBH: in the v2adv approach, a handle was passed so the messageEngine
could match the response to the incoming request. How is it done now?

7.4. Access Control Model Design Requirements

An Access Control model must determine whether the specified
MIID is allowed to perform the requested operation on
a specified managed object. The Access Control model specifies the
rules by which access control is determined.

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

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





























Harrington/Wijnen         Expires December 1977        [Page 33]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


8. Security Consideration

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

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

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

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


















Harrington/Wijnen         Expires December 1977        [Page 34]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


9. Glossary





















































Harrington/Wijnen         Expires December 1977        [Page 35]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


10. References

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

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

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

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

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

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

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

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

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

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

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



Harrington/Wijnen         Expires December 1977        [Page 36]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


    RFC 1907 January 1996.

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

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

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










































Harrington/Wijnen         Expires December 1977        [Page 37]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


11. Editor's Addresses

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

                   Co-editor   Dave Harrington
                               Cabletron Systems, Inc
                   postal:     Post Office Box 5005
                               MailStop: Durham
                               35 Industrial Way
                               Rochester NH 03867-5005
                   email:      dbh@cabletron.com
                   phone:      603-337-7357




































Harrington/Wijnen         Expires December 1977        [Page 38]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


12. Acknowledgements

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

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









































Harrington/Wijnen         Expires December 1977        [Page 39]


Draft   Architecture for Describing Internet Management Frameworks   March 1997


Table of Contents

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



Harrington/Wijnen         Expires December 1977        [Page 40]