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

Versions: 00 01 02 03 04 05 06 rfc2261                                  
               Architecture for the Next Generation
               Simple Network Management Protocol (SNMPng)

                            26 April 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-00.txt>




                          Status of this Memo

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

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

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



                             Abstract

This document describes an architecture for the Next-Generation of
the Simple Network Management Protocol (SNMPng).  The architecture
is designed to be modular to allow the evolution of the protocol
over time. The major portions of the architecture are 1) a message
processing and control framework, 2) a security framework, and
3) a local processing framework.






Harrington/Wijnen         Expires October 1977        [Page  1]
\
Draft              Architectural Model for SNMPng             April 1997


0.  Change Log

[version 1.8]
        1. changed filename to internet-drafts assigned name
[version 1.7]
        1. Truncate lines to 72 (more to be done)
        2. Prepare for pagination
        3. Added references section
        4. Let table of contents be generated
[version 1.6]
        1. added abstract
        2. davel's comments
        3. bert's comments
        4. reverted to QoS since it was less work.
        5. completed section 8
        6. Security Considerations, etc
        7. table of contents
[version 1.5]
        1. add goals/constraints from issues list
        2. add discussion of proxy as App
        3. move ngMIB to arch from LPM doc
        4. define LCD versus SCD
        5. copy Bert's 2.x that apply to framework
        6. modify Message definition to better match Bert's ASN.1
[version 1.4]
        1. modified intro
        2. added section on design principles/goals
        3. added section on message contents and service interfaces
        4. defined LP-F versus LP-M
        5. changed QoS to msgFlags
[version 1.3]
        1. modified title from Security and Framework Evolution to
           Next Generation
        2. expanded section 4 - architectural design goals
        3. replaced all acronyms with the new acronyms



















Harrington/Wijnen         Expires October 1977        [Page  2]
\
Draft              Architectural Model for SNMPng             April 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.

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

Operations of the protocol are carried out under an administrative
framework which defines minimum policies for mechanisms which provide
message-level security, access control for managed objects, and
interaction between the protocol engine and the applications which use
the services of the engine.

It is the purpose of this document to define a framework which can
evolve to realize effective SNMP network management in a variety of
configurations and environments. The framework has been designed to
meet the needs of implementors of both minimal agents and full-function
network enterprise management stations.


1.1. A Note on Terminology

For the purpose of exposition, the original Internet-standard Network
Management Framework, as described in RFCs 1155, 1157, and 1212, is
termed the SNMP version 1 framework (SNMPv1). A partially-updated
Internet-standard Network Management framework , as described
in RFCs 1902-1908, is termed the SNMP version 2 framework (SNMPv2).
The current framework, meant to complement the SNMPv2 framework,
is termed the SNMP next generation framework (SNMPng).

SNMPng provides a framework for the evolution of multiple
(sub-)frameworks.

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

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

A Implementation is an instantiation of a Framework, conforming to a
specific Model.




Harrington/Wijnen         Expires October 1977        [Page  3]
\
Draft              Architectural Model for SNMPng             April 1997


2. Overview

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

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

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





































Harrington/Wijnen         Expires October 1977        [Page  4]
\
Draft              Architectural Model for SNMPng             April 1997


3. An Evolutionary Architecture - Design Goals

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

3.1. Encapsulation

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

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

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

3.2. Cohesion

Similar functions can be grouped together and their differences
ignored, so they can be dealt with as a single entity. It is important
that the functions which are grouped together are actually similar.
For instance, authentication and encryption are both security functions
which act on the message. Access control, while similar in some ways,
is not similar in that it does not work on the message, it works on the
contents of the message. The similarity of the data used to perform
functions can be a good indicator of the similarity of the functions.

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

3.3. Hierarchical Rules

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





Harrington/Wijnen         Expires October 1977        [Page  5]
\
Draft              Architectural Model for SNMPng             April 1997


The SNMPng architecture uses the hierarchical approach by defining
frameworks, 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
between the parts of the system. The concept of plug-and-play hardware
components is based on that type of interface between the hardware
component and system into which it will be "plugged."

SNMPng has chosen this approach so individual portions of the system
can be upgraded over time, while keeping the overall system intact.
Cross-references between document describing the subsystems should be
limited to Framework or Model defined interfaces wherever possible.

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 October 1977        [Page  6]
\
Draft              Architectural Model for SNMPng             April 1997



4.0. Abstract Functionality

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

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

4.1. Message Processing and Control

An SNMP engine interacts with the network and with applications through
the Message Processing and Control Framework.

Messages being sent to, or received from, the network use a format
defined by the SNMP protocol. The possible contents, and their
format, are also defined by the SNMP protocol.

Messages being sent to, or received from, applications use formats
which may be protocol-defined or may be implementation-specific. The
possible contents, and their format, may be protocol-defined or
implementation-specific.

The processing of messages must be controlled to ensure that applicable
rules are followed during the processing. Some messages, such as an
SNMP Get-Request received from the network for objects managed by this
engine, can be processed directly by the engine; other messages must be
passed to external processes, such as a remote SNMP engine or an
application. Some messages require security; others don't. Some engines
support multiple versions of SNMP messages and/or PDU formats.

The engine must control the order and the combinations of options used
in processing and generating messages.

4.2. Security

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

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




Harrington/Wijnen         Expires October 1977        [Page  7]
\
Draft              Architectural Model for SNMPng             April 1997


4.3. Local Processing

Local Processing deals with the contents of messages. It interacts with
the underlying operating system to access the instrumentation which is
represented as managed objects in SNMP.

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

4.4. Applications

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

Applications are developed to achieve certain goals. They use the SNMP
engine to achieve their goals, but their purpose is outside the scope
of the SNMP protocol definitions.

For example, management stations execute applications which monitor
and control managed elements. A proxy application may forward a
message from one SNMP engine to another (an snmp proxy), or convert
a message from one SNMP format to another (also an snmp proxy), or
from SNMP to another protocol ( a foreign proxy). The purpose and
design of applications are beyond the scope of the SNMPng engine
architecture.

4.5. Definition of SNMPng acronyms and terms:

   MPC-F   - Message Processing and Control Framework
   MPC-M   - Message Processing and Control Model
   MPC-I   - Message Processing and Control Implementation

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

   LP-F    - Local Processing Framework
   LP-M    - Local Processing Model
   LP-I    - Local Processing Implementation

   LCD     - Local Configuration Datastore
   SCD     - Security Configuration Datastore









Harrington/Wijnen         Expires October 1977        [Page  8]
\
Draft              Architectural Model for SNMPng             April 1997


5. Elements of the Framework

This section contains definitions of terms used in the interfaces
between Frameworks

5.1. Groups

A Group identifies a set of zero or more security entities on whose
behalf SNMP messages are being processed.

5.2. Quality of Service

Messages may require different levels of security. The term used to
refer to the level of security required is "Quality of Service" or QoS.

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

Every message has an associated QoS; all processing (security, access
control, applications, message processing and control) is required
to abide the specified QoS.

5.3. Contexts

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

5.4. Scoped-PDU

A scoped-PDU contains a Naming-Scope that unambiguously
identifies an SNMP agent and the context, (locally) accessible
by that agent, to which the SNMP management information
in the SNMP-PDU refers.

A Naming-Scope contains a contextID that unambiguously identifies
the SNMP agent which has (local) access to the management
information referred to by the contextName and the SNMP-PDU.

A Naming-Scope contains a contextName which unambiguously identifies
an SNMP context accessible by the SNMP agent to which the SNMP-PDU
is directed or from which the SNMP-PDU is originated.

An implementation of a Message Processing and Control Model
must determine if the contextID in the scopedPDU of a received message
matches the snmpNgEngineID of the current engine. If so, the scopedPDU
should be processed by the Local Processing implementation.




Harrington/Wijnen         Expires October 1977        [Page  9]
\
Draft              Architectural Model for SNMPng             April 1997


5.5. Security Configuration Datastore

Each Security Model may need to retain its own set of information about
security entities, mechanisms, and policies. This set of information
is called the SNMPng entity's Security Configuration Datastore (SCD).
In order to allow an SNMPng entity's SCD to be remotely configured,
portions may need to be accessible as managed objects.

5.6. Local Configuration Datastore

Each Local Processing Model may need to retain its own set of
information about access control, naming scopes, and policies.
This set of information is called the SNMPng entity's Local
Processing Configuration Datastore (LCD).
In order to allow an SNMPng entity's LCD to be remotely configured,
portions may need to be accessible as managed objects.






































Harrington/Wijnen         Expires October 1977        [Page 10]


\
Draft              Architectural Model for SNMPng             April 1997


6. Model Design Requirements

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

SNMPv1 and SNMPv2c [RFC1901] are two administrative frameworks based
on communities to provide trivial authentication and access control.
SNMPng allows implementations to add support for features of SNMPv1
and SNMPv2c, and to coexist with SNMPv1 and SNMPv2c engines, but
this document does not provide guidelines for that coexistence.

6.1. Security Model Design Requirements

Received messages must be validated by a model of the Security
Framework before being processed by the Local Processing Framework.
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 Quality of Service to be
used during processing. All messages requiring privacy must also
require authentication.

A Security Model specifies rules by which authentication and privacy
are to be done. A model may define mechanisms to provide additional
security features, but is restricted to using the interface, defined in
this document, between the Message Processing and Control Framework and
the Security Framework.

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 QoS and the
security parameters passed in the message. Each Security Model, with
its associated protocol(s) defines how the sending/receiving entities
are identified, how secrets are configured, and how security entities
map to groups.

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

Security Models are replaceable within the SNMPng Framework. 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
entity within the model's SCD, and a securityCookie. A securityCookie



Harrington/Wijnen         Expires October 1977        [Page 11]


\
Draft              Architectural Model for SNMPng             April 1997


is an implementation-specific handle to identify the unique entity to
which it maps. If an implementation supports multiple Security Models,
the securityCookie must include a mechanism for determining which
Security Model SCD 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 security entity. 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 MIBs required for security processing,
including any MIBs required for the protocol(s) supported. The MIB
formats must be defined concurrently with the procedures which use
the MIB. The MIBs are subject to normal security and access control
rules.


The persistent data used for security should be SNMP-manageable, but
the Security Model defines whether an instantiation of the MIB is a
conformance requirement. The mapping between a securityCookie and the
unique security entity within the engine must be able to be determined
using SNMP, if the MIB is instantiated and access control policy
allows.

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

Within any Security Model, there should be no reference to any specific
Local Processing Model, or to data defined by a Local Processing Model.

6.2. Local Processing Model Design Requirements

A Local processing Model only processes scopedPDUs which contain a
contextID which matches the engineID of the current engine.

A Local Processing Model must determine whether the specified group is
allowed to perform the requested operation on the managed objects in
the PDU. For messages with a QoS specifying authentication, the group
used for access control must be the same group provided by the Message
Processing and Control Framework.

A Local Processing Model specifies the rules by which access control
and PDU processing are to be done. A model may define mechanisms to
provide additional processing features, but is restricted to using the
interface, defined in this document, between the Message Processing
and Control Framework and the Local Processing Framework.




Harrington/Wijnen         Expires October 1977        [Page 12]


\
Draft              Architectural Model for SNMPng             April 1997


The persistent data used for local processing should be manageable
using SNMP, but the Local Processing Model defines whether an
instantiation of the MIB is a conformance requirement.

Within any Local Processing Model, there should be no reference to
any specific Security Model, or any data defined by a Security Model.

6.3. Message Processing and Control Requirements

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

The MPC Model must determine whether a scopedPDU should be processed
by the current engine or by an application. If a received message
contains a scopedPDU with a contextID matching the engineID of the
current engine, then the scopedPDU should be passed to the Local
Processing Model implementation for processing.

If the MPC Model determines that the contextID does not match the
engineID of the current engine, then the message parts, as specified in
the interface section, are passed to a proxy application for
processing.

6.4. Applications

Applications are beyond the scope of this document, but earlier
attempts to define an SNMP Framework considered proxy as a possible
function of the protocol. SNMPng does not mandate support for proxy
in an SNMPng implementation.

6.4.1. A Proxy Application

The SNMPng Framework explicitly considers proxy to be an external
application. There are certain issues that must be clarified regarding
the relation and interface between proxy and the engine, however.

A proxy application has the responsibility to define any MIBs used
to forward message contents, and to determine the address and
identity to whom the message should be forwarded.

An engine supports at most one interface to proxy applications; if an
implementation wishes to support multiple proxy applications, the
determination of which type of proxy, and hence which proxy application
should handle it, should be handled by the single proxy application to
which the engine has an interface.

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



Harrington/Wijnen         Expires October 1977        [Page 13]


\
Draft              Architectural Model for SNMPng             April 1997
























































Harrington/Wijnen         Expires October 1977        [Page 14]


\
Draft              Architectural Model for SNMPng             April 1997


7. The SNMPng message format:

DEFINITIONS ::=3D BEGIN

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

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

        securityModel
            snmpNgSecurityModel,

        -- security model-specific parameters
        securityParameters
            OCTET STRING, -- format defined by Security Model

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

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

    scopedPDU ::=3D
        SEQUENCE {
            contextID
                snmpNgEngineID,
            contextName
                snmpNgContextName,
            data
                ANY -- e.g. PDUs as defined in RFC1905
        }
END



Harrington/Wijnen         Expires October 1977        [Page 15]


\
Draft              Architectural Model for SNMPng             April 1997




7.1. SNMP version

The SNMP version identifies the version of the MPC framework in use.
For purposes of discouraging, but not preventing, the replacement of
the Local Processing Model, the SNMP version also implies the version
of the Local Processing Model.

7.2. msgID

The msgID is used by SNMP engines to coordinate the processing of the
message by different portions of the framework.

Note that the requestID used during local processing identifies the
request, not the message that carried the request, and therefore might
not be equal to the msgID.

7.3. MMS

The maximum message size supported by the sender of the message.

7.4. securityModel

Multiple security models may exist concurrently in the engine.
This model number identifies which security model should be used to
provide security processing for the message. The mapping to the
appropriate implementation within the agent is done in an
implementation-dependent manner.

The initial model of the SNMPng Security Framework is the User-Based
Security Model of the SNMPng Security Framework.

7.5. QoS

The QoS field contains flags to control the processing of the message.

If the reportableFlag is set, then reportPDUs are allowed to be
returned to the sender under those conditions which cause the
generation of reportPDUs. If the reportableFlag is zero, then a
reportPDU must not be sent. The reportableFlag should always be zero
when the message is a reportPDU, a responsePDU, or a trapPDU.

If the auth flag is set, then the security implementation is required
to identify the entity on whose behalf a request is generated and to
authenticate such identification. If the auth flag is zero,
authentication of the identification is not required.

If the priv flag is set, then the security implementation is required
to protect the data within an SNMP operation from disclosure, i.e. to
encrypt the data. If the priv flag is zero, then the security



Harrington/Wijnen         Expires October 1977        [Page 16]


\
Draft              Architectural Model for SNMPng             April 1997


implementation does not need to protect the data using encryption.
It is an explicit requirement of the SNMPng Framework that if privacy
is selected, then authentication of the identification is required,
i.e. priv flag can only be set if auth flag is also set.

7.6. security parameters

This octet string is not interpreted by the MPC-F. This data is used
exclusively by the security model, and the contents and format of the
data is defined by the security model.

7.7. scopedPDU

The scopedPDU contains a PDU and the scope in which it is to be
processed, as defined by the ID of the engine and the context within
which the management data is realized on that engine.

7.7.1. contextID

This is the engineID of the engine which realizes the managed objects
referenced in the PDUs.

7.7.2. contextName

This is the name of the context, on the contextID-specified engine,
which realizes the managed objects referenced within the PDUs.

7.7.3. data

The data contains the PDUs. The Local Processing Model defines the
content and format of the PDUs. The initial model of the SNMPng Local
Processing Framework supports SNMPv2 PDUs as defined in RFC1905.






















Harrington/Wijnen         Expires October 1977        [Page 17]


\
Draft              Architectural Model for SNMPng             April 1997


8. The Frameworks and their standard "services" interfaces

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

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

8.1. Standard Services of Message Processing and Control Models

8.1.1. Receive SNMP messages from the network

Upon receipt of an SNMPng message from the network, an MPC-M
will extract the MMS, and the QoS, and will determine where the
block of security parameters start in the message.

It 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 MPC-M will pass the MMS, the QoS, a pointer to the message, and a
pointer to the block of security parameters to the implementation
of the Security Model specified in the message header.

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

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 MPC-M will pass a scopedPDU, the securityCookie, and 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 MPC-M, will 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 MPC will receive the SNMP message according to the process
described in 8.1.1.

The Message Processing and Control implementation will compare the
contextID in the scopedPDU with its snmpNgEngineID. If they match, the
MPC will forward the scopedPDU to the Local Processing implementation.
The MPC will pass the scopedPDU, the Group, and the scopedPDU-MMS
provided by the Security Model implementation, plus the QoS, to the
Local Processing implementation.



Harrington/Wijnen         Expires October 1977        [Page 18]


\
Draft              Architectural Model for SNMPng             April 1997



It will accept a completed scopedPDU containing the responsePDU
from the LP-I, and generate a response message according to the
process described in 8.1.2.

8.1.4. Forward Received Request Message to a Proxy Application

The MPC will receive the SNMP message according to the process
described in 8.1.1.

The MPC will determine whether a scopedPDU in a received message
contains a contextID which differs from its snmpNgEngineID.
If it does differ, and if a proxy application is supported by this
engine, the MPC will assign an implementation-defined handle to the
message. The MPC will determine, from the message header, the SNMP
version, the securityModel, the MMS, and the QoS. It will pass to the
proxy application the handle, the SNMP version, securityModel, MMS,
QoS, plus the securityCookie provided by the Security Model
implementation.

8.1.5. Generate a Request Message for an Application

The MPC will receive a request for the generation of a request message
from an application. The application has the responsibility for
providing
the Destination Address, the SNMP version, the QoS desired, the MMS of
the current engine, the SecurityModel to use, the securityCookie to
use, a scopedPDU containing the desired operation, and a handle used
for matching up an incoming response to the application making the
request.

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

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

8.1.6. Forward Received Response Message to an Application

The MPC will receive the SNMP message according to the process
described in 8.1.1.

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

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

The Application, using the securityCookie, will determine the end-user
on whose behalf the response should be processed.




Harrington/Wijnen         Expires October 1977        [Page 19]


\
Draft              Architectural Model for SNMPng             April 1997


8.1.7. Forward Received Notification Message to an Application

The MPC will receive the SNMP message according to the process
described in 8.1.1.

The MPC will determine to which application traps should be forwarded.

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

The Application, using the securityCookie, will determine the end-user
on whose behalf the notification should be processed.

8.1.8. Generate a Trap Message

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

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

8.1.9. Send a Response Message from a Proxy Application

The MPC will send the SNMP message according to the process
described in 8.1.1.

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

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

The Application, using the securityCookie, will determine the end-user
on whose behalf the response should be processed.

8.2. Standard Services Required of Security Models

8.2.1. validate the security-stamp in a received message

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

If encrypted, decrypt the message

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




Harrington/Wijnen         Expires October 1977        [Page 20]


\
Draft              Architectural Model for SNMPng             April 1997


return a securityCookie identifying the entity for whom the message
was generated and return the portions of the message needed for
further processing:
        a scopedPDU - a PDU enclosed by a header which contains
                an snmpID and a contextName
        QoS - the quality of service specified for security
                validation. The same quality of service must also
                be used during application of access control.
        MMS - the maximum size of a message able to be generated
                by this engine for the destination agent.
        scopedPDU-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.
        acGroup - the acGroup to be applied for access control for
                the entity for whom the request was generated.

8.2.2. security-stamp a message

Given a scopedPDU, QoS, MMS, and a securityCookie, the Security Model
must determine the security parameters for the message, the contents
and format of which are defined by the model.

The Security Model will return a message including the appropriate
security parameters, encrypted if required.

8.2.3. Provide mappings between security entities and securityCookies

Given model-specific parameters to identify a security entity,
an SF-M must return a securityCookie

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

8.2.4. Provide mapping between group and securityCookies

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

8.3. Standard Services of a Local-Processing Model

8.3.1. Process a request

Given a ScopedPDU, Group, QoS, and ScopedPDU-MMS, an LP-M must return
a scopedPDU processed according to the protocol rules of the LP-M

8.3.2. Generate a Trap

When an event occurs that requires the generation of a trap, the LP-M
must pass to the MPC a Destination Address, QoS, MMS, SecurityModel, a
Group, and a scopedPDU, according to the protocol rules of the LP-M.



Harrington/Wijnen         Expires October 1977        [Page 21]


\
Draft              Architectural Model for SNMPng             April 1997
























































Harrington/Wijnen         Expires October 1977        [Page 22]


\
Draft              Architectural Model for SNMPng             April 1997


9. Definitions

9.1. Definitions for the Architectural Model for SNMPng

snmpNg-MIB DEFINITIONS ::=3D BEGIN

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


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

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

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

                  Co-editor   Dave Harrington
                              Cabletron Systems, Inc
                  postal:     Post Office Box 5005
                              MailStop: Durham
                              35 Industrial Way
                              Rochester NH 03867-5005
                  email:      dbh@cabletron.com
                  phone:      603-337-7357
                 "
    DESCRIPTION  "The snmpNg engine MIB"
    ::=3D { snmpModules xx }

-- Administrative assignments

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



Harrington/Wijnen         Expires October 1977        [Page 23]


\
Draft              Architectural Model for SNMPng             April 1997


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

-- Textual Conventions used throughout the SNMPng Framework

snmpNgGroupName ::=3D TEXTUAL-CONVENTION
    STATUS        current
    DESCRIPTION  "An octet string representing the name of a group
                  for use in accordance with the SNMPng Architectural
                  Framework.
                 "
    SYNTAX        OCTET STRING (SIZE(1..16))

snmpNgContextName ::=3D TEXTUAL-CONVENTION
    STATUS        current
    DESCRIPTION  "An SNMPng context name which unambiguously
                  identifies a set of management information
                  directly accessible by the Local Processing Module
                  (implementation or LP-I) of an SNMPng engine.
                 "
    SYNTAX       OCTET STRING (SIZE (0..32))

snmpNgQoS ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "A level of security at which SNMPng 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) }


snmpNgEngineID ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "An SNMPng entity'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.



Harrington/Wijnen         Expires October 1977        [Page 24]


\
Draft              Architectural Model for SNMPng             April 1997



                  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))

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

-- SNMPng MIB objects implemented by the SNMPng MPC ******************

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

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


-- Conformance information

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



Harrington/Wijnen         Expires October 1977        [Page 25]


\
Draft              Architectural Model for SNMPng             April 1997




-- Compliance statements

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

    MODULE  -- this module
        MANDATORY-GROUPS { snmpNgBasicGroup }

    ::=3D { snmpNgMIBCompliances 1 }

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

END


























Harrington/Wijnen         Expires October 1977        [Page 26]


\
Draft              Architectural Model for SNMPng             April 1997


10. Agent Installation Parameters

During installation, an SNMPng entity acting in an agent role is
configured with several parameters. These include:

(1) a security posture

    The choice of security posture determines the extent of the view
    configured for unauthenticated access. One of three possible
    choices is selected:

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

(2) one or more transport service addresses

    These parameters may be specified explicitly, or they may be
    specified implicitly as the same set of network-layer addresses
    configured for other uses by the device together with the well-
    known transport-layer "port" information for the appropriate
    transport domain 13. The agent listens on each of these
    transport service addresses for messages.































Harrington/Wijnen         Expires October 1977        [Page 27]


\
Draft              Architectural Model for SNMPng             April 1997


11. Security Consideration

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

The level of security actually provided is primarily determined by
the specific Security Model implementation(s) and the specific Local
Processing Model implementation(s) incorporated into this framework.
Applications have access to data which is not secured. Applications
should take reasonable steps to protect the data from disclosure.

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

















Harrington/Wijnen         Expires October 1977        [Page 28]


\
Draft              Architectural Model for SNMPng             April 1997


12. References

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

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

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

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

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


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

[SNMPng-LPM] The SNMPng Working Group, Wijnen, B., Harrington, D.,
     "Local Processing Model for the Next Generation Simple Network
     Management Protocol (SNMPng)", draft-ietf-snmpng-lpm-00.txt,
     April 1997.

[SNMPng-USEC] To be written
              The SNMPng Working Group, Editors...Names,
     "The User-Based Security Model for the Next Generation Simple
     Network Management Protocol (SNMPng)",
     draft-ietf-snmpng-usec-00.txt, April 1997.







Harrington/Wijnen         Expires October 1977        [Page 29]


\
Draft              Architectural Model for SNMPng             April 1997


13. Editor's Addresses

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

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

14. Acknowledgements

This document describes 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 October 1977        [Page 30]


\
Draft              Architectural Model for SNMPng             April 1997


Table of Contents

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



Harrington/Wijnen         Expires October 1977        [Page 31]