Local Processing Model for version 3 of the Simple Network Management Protocol (SNMPv3)
draft-ietf-snmpv3-lpm-01

Versions: 00 01                                                         
                Local Processing Model for version 3 of the
                Simple Network Management Protocol (SNMPv3)

                             09 May 1997


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

                            Randy Presuhn
                          BMC Software, Inc.
                           rpresuhn@bmc.com

                            Keith McCloghrie
                          Cisco Systems, Inc.
                             kzm@cisco.com


                    <draft-ietf-snmpv3-lpm-01.txt>


                          Status of this Memo

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

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

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



                          Abstract

This document describes the Local Processing Model (LPM) for SNMP
version 3 for use in the SNMPng architecture [SNMPng-ARCH].  This
document defines the Elements of Procedure for accessing local
management information.  This document also includes a MIB for remotely
monitoring/managing the configuration parameters for this LPM.






Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page  1]

Draft          Local Processing Model (LPM) for SNMPv3          May 1997


0.  Issues
  - Does access control belong in LPM or in Security
  - How to do access control for Notifications
  - Interdependencies for contextTable, acTable, viewTable and
    subtreeFamilyTable
  - Should we expect specific PDU-types or can we assume MPC has
    done that checking.
  - Should we use UTF-8 for human readable names like
    contextName, viewName, groupName etc.
  - indexing of the viewTable by integer or viewName
  - do we need a contextTable or should we rely on entityMIB
  - acknowledgements needs expansion


0.1  Change Log

[version 2.0]
  - Modifications as agreed at Memphis
    - Introduction and Terminology shortened, add ptr to Architecture
    - Follow new terminology (I may have missed some)
    - Trap Destinations and Trap Generation is now outside LPM
  - fixes/changes as a result of mailing list comments
    - Do away with snmpV3LpAcPrivileges
    - Keep contextTable with juts one column
    - Fix spelling errors (well at least some... we'll run through a
      spell-checker later).

[version 1.x]
  - Initial versions before Memphis meeting

























Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page  2]

Draft          Local Processing Model (LPM) for SNMPv3          May 1997


1.  Introduction

The architecture for the Next-Generation of the Simple Network
Management Protocol (SNMPng) is composed of multiple subsystems,
  1) a message processing and control subsystem,
  2) a security subsystem,
  3) a local processing subsystem, and
  4) applications.

It is important to understand the SNMPng architecture and the
terminology of the architecture to understand where the model
described in this document fits into the architecture and interacts
with other models within the architecture.  The reader is expected to
have read and understood the description of the SNMPng architecture,
as defined in [SNMPng-ARCH].

The Local Processing subsystem of an SNMP engine interacts with the
Message Processing and Control subsystem using data elements defined
by the Message Processing and Control model, within the constraints
of the Architecture.

A Local Processing model has the responsibility for processing the
SNMP PDUs that operate on local instrumentation.  As such, the Local
Processing model applies access control and invokes method routines
to access management information and then prepares a response to the
received SNMP request.

It is the purpose of this document to define a specific model of the
Local Processing subsystem, designated the SNMP version 3 Local
Processing model.

1.2  Local Processing

Local Processing may occur in an SNMPv3 engine acting in an agent
role in response to SNMPv3 request messages from an SNMPv3
engine acting in a manager role.  These request messages include
these types of operations: GetRequest, GetNextRequest, GetBulkRequest,
and SetRequest operations.

Local Processing only occurs if the request is targeted at local
management information as determined by the contextEngineID in the
Naming-Scope of a scopedPDU. It is the Message Processing and
Control module that determines if the contextEngineID refers to the
current (local) SNMPv3 engine and if so, to direct the scopedPDU to
the Local Processing module.

Local Processing almost always results in the production
of a response, (sometimes including error or other exceptional
indicators), termed the Response-PDU.

Local Processing can also result in the production of an



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page  3]

Draft          Local Processing Model (LPM) for SNMPv3          May 1997


error report, termed the Report-PDU.

1.3  Local Configuration Datastore

To implement the model described in this document, each SNMPv3
engine needs to retain its own set of information about access
rights and policies, and the like.  This set of information is
called the SNMPv3 engine's Local Configuration Datastore (LCD)
because it is locally-stored information.

In order to allow an SNMPv3 engine's LCD to be remotely configured,
portions of the LCD need to be accessible as managed objects.
A MIB module, the SNMPv3 Local Processing Model Configuration MIB,
which defines these managed object types is included in this document.








































Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page  4]

Draft          Local Processing Model (LPM) for SNMPv3          May 1997


2.  Elements of the Model

This section contains definitions to realize the access control
applied by this Local Processing Model.

2.1  Groups

A groupName identifies a group (set) of zero or more security
entities on whose behalf SNMP management objects are being accessed.
It is the responsibility of the Message Processing and Control module
(MPC) to determine in an authoritative manner for which groupName an
incoming SNMP request is being processed.

This SNMPv3 Local Processing model requires the groupName to be passed
as input to the Local Processing module when a PDU is handed to it for
processing.

2.2  Level of Security (LoS)

The LoS identifies the Level of Security (in terms of message
security) used for transmitting the SNMP message.
It is the responsibility of the Message Processing and Control module
to determine in an authoritative manner the LoS that was used for an
incoming SNMP message. It is the responsibility of the Local Processing
module to take the LoS into consideration when applying access control.

This Local Processing Model recognizes three different LoS levels:

   - without authentication and without privacy

   - with authentication but without privacy

   - with authentication and with privacy

This Local Processing Model requires the LoS to be passed as input
to the Local Processing module when a message is handed to it for
local processing.

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

2.4  scopedPDU

A scopedPDU 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.



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page  5]

Draft          Local Processing Model (LPM) for SNMPv3          May 1997



A Naming-Scope contains a contextEngineID 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.

It is the responsibility of the Message Processing and Control module
to determine in an authoritative manner if the contextEngineID refers
to the current (local) SNMPv3 engine and if so to direct the SNMP
message to the Local Processing module for local processing.

This Local Processing Model requires the scopedPDU to be passed as
input to the Local Processing module if a message is handed to it.

Editor's notes:
         We (Keith, Randy and Bert) believe it would be better
         to not use a scopedPDU as input/output to the LPM but
         instead use contextName plus PDU as input/output.
         After all, the contextEngineID is irrelevant in the
         LPM and is in fact only used/known in the MPC.
End Editor's notes.

2.5  Access Policy

The access policy of this Local Processing model determines the access
rights of groups (representing zero, one or more security entities
which have the same access rights).  For a particular context
(contextName) to which a group (groupName) has access using
a particular Level of Security (LoS), that group's access rights
are given by a list of authorized operations, and a read-view and a
write-view.  The read-view is the set of object instances authorized
for the group when reading objects.  Reading objects occurs
when processing a retrieval (Get, GetNext, GetBulk) operation
and when sending a notification (Trap).
The write-view is the set of object instances authorized for
the group when writing objects.  Writing objects occurs when
processing a Set operation.

2.6.  Error Reporting

Editor's notes:
         (additional) pieces of this should be specified
         in the MPC and Security Model. MPC does not do
         any details on error reporting yet, so here it is
End Editor's notes.

While processing a received communication, an SNMPv3 engine may
determine that the message is unacceptable.  In this case,



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page  6]

Draft          Local Processing Model (LPM) for SNMPv3          May 1997


the appropriate error counter is incremented and the received
message is discarded without further processing.

If an SNMPv3 engine is processing a received Get, GetNext,
GetBulk, Set or Inform PDU and determines that a message is
unacceptable and the reportableFlag indicates that a report
may be generated, then after incrementing the appropriate
counter, it is required to generate a message containing a
report PDU, with the same context as the received message,
and to send it to the transport address which originated
the received message.  For all report PDUs, generated by
the Local Processing module, the Level of Security (LoS)
for sending the report-PDU is unauthenticated.
-- Editor's note:
   There were some opinions in the SNMPv3 mailing list that the
   reports should be send with same LoS if at all possible.
   Originally the v2adv team had agreed that all report PDUs would
   travel unauthenticated (except for notInTimeWindow).
   The editors still think that this indeed is best.
-- End Editor's note

-- Editor's note:
   The following about the reportableFlag is already specified in
   MPC document, so maybe we do not need to repeat it here?
-- End editor's note
The reportableFlag should never be set for a message that
contains a Response, SNMPv2-Trap or Report operation.



























Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page  7]

Draft          Local Processing Model (LPM) for SNMPv3          May 1997


3.  Elements of Procedure

This section describes the procedures followed by the Local Processing
module that implements this Local Processing Model when processing or
generating a scopedPDU.  For clarity, some of the details of this
procedure are left out and are described in Section 3.1.1 and its
sub-sections.

3.1  Processing a Received scopedPDU

This section describes the procedure followed by the Local Processing
module whenever it receives a scopedPDU for local processing.

(1)  The PDU portion of the scopedPDU is processed.  If the
     serialized PDU value is not the serialization (according to
     the conventions of [RFC1906]) of a PDU value, then the
     snmpInASNParseErrs counter [RFC1907] is incremented,
     and the received scopedPDU is discarded without further
     processing. An error indication is returned to the calling
     module.

(2)  The SNMPv2 operation type is determined from the ASN.1 tag
     value associated with the PDUs component.

(3)  If the SNMPv2 operation type is either a Response, SNMPv2-Trap,
     Inform or Report operation, then the snmpV3UnauthorizedOperations
     counter is incremented. Then:
     - If the SNMPv2 operation type is an Inform operation, then an
       error report is generated.
     - The scopedPDU is discarded without further processing.
     - An error indication is returned to the calling module.

Editor's notes:
         the above PDU-types should not be passed to the LPM.
         So it seems that the MPC also must define some SNMP
         PDU processing for Report, Response, Trap, Inform.

         I first thought we could return a response with an
         authorizationError (in SNMP PDU)...
         On second thoughts, we cannot do that because we cannot
         return a response to a Response, Trap or Report.
         We can also not return a report to a Response, Trap or
         Report. So I think the above is the best we can do.
End Editor's notes.

(4)  The LCD is consulted for information about the SNMP context
     identified by the contextName.  If information about this SNMP
     context is absent from the LCD, then the
     snmpV3LpStatsUnknownContexts counter is incremented, a report
     PDU [RFC1905] is generated, and the received scopedPDU is
     discarded without further processing.



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page  8]

Draft          Local Processing Model (LPM) for SNMPv3          May 1997



Editor's notes:
         The above means we have a contextTable within LPM.
         We had some discussion on this on the mailing list and it
         seems most people feel it is useful to have a contextTable.
End Editor's notes.

(5)  The LCD is consulted for information about the SNMP group
     identified by the groupName.  If information about this SNMP
     group is absent from the LCD, then the snmpV3LpStatsUnknownGroups
     counter is incremented, a report PDU [RFC1905] is generated,
     and the received scopedPDU is discarded without further
     processing. Note that a group is considered to be known if
     the groupName is used as an index in the snmpV3LpAcTable and
     has at least one row with a status of "active".

(6)  If the SNMPv2 operation type is either a Get, GetNext, GetBulk, or
     Set operation, then:

     a) the LCD is consulted for access rights authorized for
        communications using the indicated LoS, on behalf of the
        indicated group, and concerning management information in
        the indicated context for the particular SNMPv2 operation
        type. A Get, GetNext and GetBulk represent a read operation
        type (for which a read-view must exist) and a Set represents
        a write operation type (for which a write-view must exist).

     b) if the SNMPv2 operation type is not among the authorized
        access rights, then a response-PDU is prepared with the
        error-index set to zero and the error-status set to
        authorizationError [RFC1905]. The response-PDU is returned
        to the calling module.

     c) the management operation represented by the SNMPv2 operation
        type is performed by the receiving LPM with respect to the
        relevant MIB view within the SNMP context according to
        the procedures set forth in [RFC1905], where the relevant
        MIB view is determined according to the contextName,
        groupName and the LoS values and the SNMPv2 operation
        type requested.

     d) An SNMPv2 Response-PDU is produced and presented to the
        calling module for further processing.
        The LPM uses the scopedPDU-MMS to ensure that the
        produced Response-PDU does not exceed the maximum
        message size.

(7)  If the SNMPv2 operation type is anything that has not yet been
     processed, then it is an unknown PDU-type. The
     snmpV3UnauthorizedOperations counter is incremented and the
     received scopedPDU is discarded without further processing.



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page  9]

Draft          Local Processing Model (LPM) for SNMPv3          May 1997


     An error indication is returned to the calling module.

3.1.1.  Additional Details

   For the sake of clarity and to prevent the above procedure from being
   even longer, the following details were omitted from the above
   procedure.

3.1.1.1.  ASN.1 Parsing Errors

   For ASN.1 parsing errors, the snmpInASNParseErrs counter [RFC1907] is
   incremented and a report PDU is generated whenever such an ASN.1
   parsing error is discovered.  However, if the parsing error causes
   the information able to be extracted from the message to be
   insufficient for generating a report PDU, then the report PDU is not
   sent.

3.1.1.2.  Generation of a Report PDU

   Some steps specify that the received scopedPDU is discarded without
   further processing whenever a report PDU is generated.  However:

   -  If the operation type can reliably be determined and it is
      determined to be a Report, SNMPv2-Trap, or a Response then a
      report PDU is not generated.

   -  A report PDU is only generated when the reportableFlag is set
      to the value 1.

   A generated report PDU must always use the current values of
   snmpEngineID, engineBoots, and engineTime from the LCD.  In addition,
   a generated report PDU must contain the same msgID value as in the
   received message.

-- Editor's note:
            Sounds on the mailing list that we need to allow
            access control checking for Notifications that must be
            generated by the F-Ts. Once the decision is made we
            can add text here.
-- End Editor's note














Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 10]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


4.  Definitions

SNMPV3-LP-MIB DEFINITIONS ::= BEGIN

IMPORTS
    Counter32, Unsigned32,
    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,
    SnmpV3GroupName, SnmpV3ContextName,
    SnmpV3LoS, SnmpV3EngineID,
    SnmpV3SecurityModel                        FROM SNMPv3-MIB;


snmpV3LpMIB MODULE-IDENTITY
    LAST-UPDATED "9705090000Z"     -- 09 May 1997, midnight
    ORGANIZATION "SNMPv3 Working Group"
    CONTACT-INFO "WG-email:   snmpv3@tis.com
                  Subscribe:  majordomo@tis.com
                              In msg body:  subscribe snmpv3

                  Chair:      Russ Mundy
                              Trutsed 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 management information definitions for the
                  SNMPv3 Local Processing Model.
                 "



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 11]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


    ::= { snmpModules xx }

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

snmpV3LpMIBObjects      OBJECT IDENTIFIER ::= { snmpV3LpMIB 1 }
snmpV3LpMIBConformance  OBJECT IDENTIFIER ::= { snmpV3LpMIB 2 }

-- SNMPv3 Statistics for Local Processing ****************************

snmpV3LpStats OBJECT IDENTIFIER ::= { snmpV3LpMIBObjects 1 }

snmpV3LpStatsUnknownContexts OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The total number of packets received by the SNMPv3
                 engine which were dropped because they referenced a
                 context that was not known to the engine.
                "
    ::= { snmpV3LpStats 1 }

snmpV3LpStatsUnknownGroups OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The total number of packets received by the SNMPv3
                 engine which were dropped because the security identity
                 mapped onto a group that was not known to the engine
                 (the group has no access at all to the specified
                 context).
                "
    ::= { snmpV3LpStats 2 }

snmpV3LpStatsUnauthorizedOperations OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The total number of packets received by the SNMPv3
                 engine which were dropped because the PDU type
                 referred to an operation that is invalid or not
                 authorized.
                "
    ::= { snmpV3LpStats 3 }


-- Information about Local Contexts **********************************

-- Editor's notes:
--        We're still discussing if the contextTable is needed at all
--        (See Editor's notes in section 3.1 under item 4).
--        For now (May 9) it seems most people want it as a read-only



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 12]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


--        table with just one column.
--        Others still feel that the context info should be obtained
--        from the entityMIB and we should tell that WG to include
--        this info.
-- End Editor's notes.

snmpV3LpContextTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF SnmpV3LpContextEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The table of locally available contexts.

                 This table is read-only meaning that SNMP engines
                 in a manager role cannot configure contexts.

                 Instead the table is meant to provide input to SNMP
                 engines in a manager role such that they can
                 properly configure the snmpV3LpAcTable to control
                 access to all contexts in an SNMP engine operating
                 in an agent role.
                "
    ::= { snmpV3LpMIBObjects 2 }

snmpV3LpContextEntry OBJECT-TYPE
    SYNTAX       SnmpV3LpContextEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Information about a particular context."
    INDEX        { IMPLIED snmpV3LpContextName }
    ::= { snmpV3LpContextTable 1 }

SnmpV3LpContextEntry ::= SEQUENCE
    {
        snmpV3LpContextName        SnmpV3ContextName
    }

snmpV3LpContextName OBJECT-TYPE
    SYNTAX       SnmpV3ContextName
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "A textual name uniquely identifying a particular
                 context on a particular agent.
                "
    ::= { snmpV3LpContextEntry 1 }

-- Information about Access Rights ***********************************

snmpV3LpAcTable  OBJECT-TYPE
    SYNTAX       SEQUENCE OF SnmpV3LpAcEntry
    MAX-ACCESS   not-accessible
    STATUS       current



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 13]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


    DESCRIPTION "The table of group access rights configured in the
                 local configuration datastore (LCD).
                "
    ::= { snmpV3LpMIBObjects 3 }

snmpV3LpAcEntry  OBJECT-TYPE
    SYNTAX       SnmpV3LpAcEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An access right configured in the local configuration
                 datastore (LCD) authorizing access to a SNMPv3
                 context.
                "
    INDEX       { snmpV3LpAcContextName,
                  snmpV3LpAcGroupName,
                  snmpV3LpAcLoS
                }
    ::= { snmpV3LpAcTable 1 }

SnmpV3LpAcEntry ::= SEQUENCE
    {
        snmpV3LpAcContextName      SnmpV3ContextName,
        snmpV3LpAcGroupName        SnmpV3GroupName,
        snmpV3LpAcLoS              SnmpV3LoS,
        snmpV3LpAcReadViewIndex    INTEGER,
        snmpV3LpAcWriteViewIndex   INTEGER,
        snmpV3LpAcStorageType      StorageType,
        snmpV3LpAcStatus           RowStatus
    }

snmpV3LpAcContextName OBJECT-TYPE
    SYNTAX       ContextName
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The context name which identifies an SNMP context
                 to which this conceptual row grants access rights.
                "
    ::= { snmpV3LpAcEntry 1 }

snmpV3LpAcGroupName OBJECT-TYPE
    SYNTAX       GroupName
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The group name which identifies an SNMP group
                 to which this conceptual row grants access rights.
                "
    ::= { snmpV3LpAcEntry 1 }

snmpV3LpAcLoS    OBJECT-TYPE
    SYNTAX       SnmpV3LoS
    MAX-ACCESS   not-accessible



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 14]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


    STATUS       current
    DESCRIPTION "The minimum level of security required of messages
                 sent on behalf of an identity belonging to the group
                 in order to gain the access rights allowed by this
                 conceptual row.
                "
    ::= { snmpV3LpAcEntry 2 }

snmpV3LpAcReadViewIndex OBJECT-TYPE
    SYNTAX       INTEGER (0..2147483647)
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The value of an instance of this object identifies
                 the MIB view of the SNMP context to which this
                 conceptual row authorizes read access.
                 The identified MIB view is that for which
                 snmpV3LpViewIndex has the same value as the
                 instance of this object; if the value is zero or if
                 there is no active MIB view having this value of
                 snmpV3LpViewIndex, then no access is granted.

                 Otherwise, this object is ignored and can take any
                 value at the Local Processing Module's discretion,
                 e.g., zero.

                 Note that read access includes access via retrieval
                 requests as well as transmission of information
                 via notifications.
-- Editor's note:
            Notification stuff still under heavy discussion
-- End Editors note
                "
    DEFVAL      { 0 }
    ::= { snmpV3LpAcEntry 3 }


snmpV3LpAcWriteViewIndex OBJECT-TYPE
    SYNTAX       INTEGER (0..2147483647)
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The value of an instance of this object identifies
                 the MIB view of the SNMPv3 context to which this
                 conceptual row authorizes write access.
                 The identified MIB view is that for which
                 snmpV3LpViewIndex has the same value as the
                 instance of this object; if the value is zero or if
                 there is no active MIB view having this value of
                 snmpV3LpViewIndex, then no access is granted.

                 Otherwise, this object is ignored and can take any
                 value at the Local Processing Module's discretion,



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 15]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


                 e.g., zero.
                "
    DEFVAL      { 0 }
    ::= { snmpV3LpAcEntry 4 }

snmpV3LpAcStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The storage type for this conceptual row.
                 Conceptual rows having the value 'permanent'
                 need not allow write-access to any columnar
                 objects in the row.
                "
    DEFVAL      { nonVolatile }
    ::= { snmpV3LpAcEntry 5 }

snmpV3LpAcStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The status of this conceptual row.

                 For those columnar objects which permit write-access,
                 their value in an existing conceptual row can be
                 changed irrespective of the value of snmpV3LpAcStatus
                 for that row.

-- Editor's notes:
--          We have discussed the removal of the following. That means
--          stale entries can occur, and so the agent code will have
--          ro be able to deal with it. We're not in agreement yet.
--          So we need to discuss at Interim.
--
--               A conceptual row in this table is not qualified for
--               activation until the context and the group it
--               references are active.  Further, a conceptual row in
--               this table is immediately made notInService whenever
--               the status of the context or the group it references
--               is made notInService, and immediately destroyed
--               whenever the context or the group it references is
--               destroyed.
--
--          There is also a suggestion as follows (DaveL):
--               Why not just have a set of snmpV3LpViewStatus to
--               destroy(6) either:
--               - fail with an inconsistent value error if any
--                 corresponding entries exist in the
--                 snmpV3LpSubtreeFamilyTable, or
--               - result also in deletion of all corresponding entries
--                 in the snmpV3LpSubtreeFamilyTable.



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 16]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


-- End Editor's notes
                "
    ::= { snmpV3LpAcEntry 6 }

-- Information about MIB views ***************************************
-- Support for views having instance-level granularity is optional

snmpV3LpViewTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF SnmpV3LpViewEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The table of locally defined MIB views.

                 When an SNMP engine in the manager role wants to
                 create a new MIB view, then it must first create
                 an entry in the snmpV3LpViewTable, using a
                 non-existing index-value for snmpV3LpViewIndex.
                 If the creation of such an entry is successfull,
                 the SNMP engine in the manager role can then start
                 creating entries in the snmpV3LpSubtreeFamiliyTable.

                 When deleting MIB views, it is strongly advised that
                 first the related snmpV3LpSubtreeFamilityEntries are
                 deleted from the snmpV3LpSubtreeFamiliyTable and that
                 only upon completion of that deletion process the
                 snmpV3LpViewEntry is deleted from the
                 snmpV3LpViewTable.

                 Furthermore, a manager should take great care to
                 delete all the "included" family entries before
                 deleting any of the "excluded" ones.

                 Following these procedures there should be no
                 collisions when multiple managers try to update
                 the MIB views at an SNMP engine in an agent role.

                 If managers do not follow these procedures then it is
                 agent-implementation dependent as to what the result
                 of possible collisions will be.
                "
    ::= { snmpV3LpMIBObjects 4 }

snmpV3LpViewEntry OBJECT-TYPE
    SYNTAX       SnmpV3LpViewEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Information on a particular local MIB view."
    INDEX       { snmpV3LpViewIndex }
    ::= { snmpV3LpViewTable 1 }

SnmpV3LpViewEntry ::= SEQUENCE



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 17]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


    {
        snmpV3LpViewIndex        INTEGER,
        snmpV3LpViewName         OCTET STRING,
        snmpV3LpViewStorageType  StorageType,
        snmpV3LpViewStatus       RowStatus
    }

-- Editor's note
            There were suggestions to use the viewName as the index
            instead of the viewIndex. But if we do that, then it seems
            to me that the search through the viewTable can be quite
            inefficient.
            Besides, the majority of the v2adv team agreed that we
            should use an integer for indexing the views.
-- End Editors note.

snmpV3LpViewIndex OBJECT-TYPE
    SYNTAX       INTEGER (1..2147483647)
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An arbitrary unique value for each MIB view.

-- Editor's notes:
--          I am not sure I understand why this should stay the
--          same. As long as the agent ensures that the mapping
--          between the acTable's use of viewIndex and the indices
--          in this viewTable are in sync, then it should be OK.
--          A manager who wants to add entries to the acTable better
--          checks the views before it actually changes the acTable.
--          So I plan to remove this text:

                 Once assigned, the value for each MIB view must
                 remain constant for as long as that view is defined,
                 even across re-initializations of the engine's
                 network management system.
-- End Editor's notes.

                 Thus, the value for a nonVolatile, permanent, or
                 readOnly (see snmpV3LpViewStorageType) MIB view must
                 either be stored as part of the system's non-volatile
                 configuration information, or be able to be
                 re-generated after each re-initialization.

                 The specific value is meaningful only within a given
                 SNMP engine, i.e., it is not meaningful to any
                 other SNMP engine except to uniquely identify the
                 view within the set of all views known to this
                 SNMP engine.
                "
    ::= { snmpV3LpViewEntry 1 }




Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 18]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


snmpV3LpViewName OBJECT-TYPE
    SYNTAX       OCTET STRING (SIZE(0..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "An arbitrary viewName that may help humans recognize
                 the various MIB views.
                "
    DEFVAL      { "" }
    ::= { snmpV3LpViewEntry 2 }


snmpV3LpViewStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The storage type for this conceptual row.
                 Conceptual rows having the value 'permanent' need
                 not allow write-access to any columnar objects in
                 the row.
                "
    DEFVAL      { nonVolatile }
    ::= { snmpV3LpViewEntry 3 }

snmpV3LpViewStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The status of this conceptual row."
    ::= { snmpV3LpViewEntry 4 }

-- Subtree families of MIB views *************************************

snmpV3LpSubtreeFamilyTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF SnmpV3LpSubtreeFamilyEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Locally held information about families of subtrees
                 within MIB views.

                 Each MIB view is defined by two collections of view
                 subtrees: the included view subtrees, and the
                 excluded view subtrees.
                 Every such subtree, both included and excluded,
                 is defined in this table.

                 To determine if a particular object instance is in
                 a particular MIB view, compare the object instance's
                 OBJECT IDENTIFIER with each of the MIB view's active
                 entries in this table.  If none match, then the
                 object instance is not in the MIB view.  If one or
                 more match, then the object instance is included in,



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 19]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


                 or excluded from, the MIB view according to the
                 value of snmpV3LpSubtreeFamilyType in the entry
                 whose value of snmpV3LpSubtreeFamilySubtree has the
                 most sub-identifiers.  If multiple entries match
                 and have the same number of sub-identifiers, then
                 the lexicographically greatest instance of
                 snmpV3LpSubtreeFamilyType determines the inclusion
                 or exclusion.

                 An object instance's OBJECT IDENTIFIER X matches an
                 active entry in this table when the number of
                 sub-identifiers in X is at least as many as in the
                 value of snmpV3LpSubtreeFamilySubtree for the entry,
                 and each sub-identifier in the value of
                 snmpV3LpSubtreeFamilySubtree matches its
                 corresponding sub-identifier in X.
                 Two sub-identifiers match either if the
                 corresponding bit of snmpV3LpSubtreeFamilyMask is
                 zero (the 'wild card' value), or if they are equal.

                 A 'family' of view subtrees is the set of subtrees
                 defined by a particular combination of values of
                 snmpV3LpSubtreeFamilySubtree and
                 snmpV3LpSubtreeFamilyMask.
                 In the case where no 'wild card' is defined in
                 snmpV3LpSubtreeFamilyMask, the family of view
                 subtrees reduces to a single view subtree.

                 When an SNMPv3 engine in the manager role wants to
                 create a new MIB view, then it should first create
                 an entry in the snmpV3LpViewTable, using a
                 non-existing index-value for snmpV3LpViewIndex.
                 If the creation of such an entry is successful,
                 the SNMPv3 engine in the manager role can then start
                 creating entries in the snmpV3LpSubtreeFamiliyTable.

                 When deleting MIB views, it is strongly advised that
                 first the related snmpV3LpSubtreeFamilityEntries are
                 deleted from the snmpV3LpSubtreeFamiliyTable and that
                 only upon completion of that deletion process the
                 snmpV3LpViewEntry is deleted from the
                 snmpV3LpViewTable.

                 Following these procedures there should be no
                 collisions when multiple managers try to update
                 the MIB views at an SNMPv3 engine in an agent role.
                "
    ::= { snmpV3LpMIBObjects 5 }

snmpV3LpSubtreeFamilyEntry OBJECT-TYPE
    SYNTAX       SnmpV3LpSubtreeFamilyEntry



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 20]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Information on a particular family of view subtrees
                 included in or excluded from a particular SNMPv3
                 context's MIB view.  The MIB view must exist
                 (i.e., be represented by a conceptual row in the
                 snmpV3LpViewTable) before any subtree families can
                 be defined for it.

                 Implementations must not restrict the number of
                 families of view subtrees for a given MIB view,
                 except as dictated by resource constraints on the
                 overall number of entries in the
                 snmpV3LpSubtreeFamilyTable.

                 The value of snmpV3LpViewIndex in this INDEX clause
                 of this table identifies the MIB view in which this
                 subtree family exists.

                 A MIB view for which there are no conceptual rows
                 in this table is the empty set of view subtrees.
                "
    INDEX       { snmpV3LpViewIndex,
                  IMPLIED snmpV3LpSubtreeFamilySubtree
                }
    ::= { snmpV3LpSubtreeFamilyTable 1 }

SnmpV3LpSubtreeFamilyEntry ::= SEQUENCE
    {
        snmpV3LpSubtreeFamilySubtree      OBJECT IDENTIFIER,
        snmpV3LpSubtreeFamilyMask         OCTET STRING,
        snmpV3LpSubtreeFamilyType         INTEGER,
        snmpV3LpSubtreeFamilyStorageType  StorageType,
        snmpV3LpSubtreeFamilyStatus       RowStatus
    }

snmpV3LpSubtreeFamilySubtree OBJECT-TYPE
    SYNTAX       OBJECT IDENTIFIER
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The MIB subtree which when combined with the
                 corresponding instance of snmpV3LpSubtreeFamilyMask
                 defines a family of view subtrees.
                "
    ::= { snmpV3LpSubtreeFamilyEntry 1 }

snmpV3LpSubtreeFamilyMask OBJECT-TYPE
    SYNTAX       OCTET STRING (SIZE (0..16))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The bit mask which,



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 21]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


                 in combination with the corresponding instance of
                 snmpV3LpSubtreeFamilySubtree, defines a family of
                 view subtrees.

                 Each bit of this bit mask corresponds to a
                 sub-identifier of snmpV3LpSubtreeFamilySubtree,
                 with the most significant bit of the i-th octet
                 of this octet string value (extended if necessary,
                 see below) corresponding to the (8*i - 7)-th
                 sub-identifier, and the least significant bit of
                 the i-th octet of this octet string corresponding
                 to the (8*i)-th sub-identifier, where i is in the
                 range 1 through 16.

                 Each bit of this bit mask specifies whether or not
                 the corresponding sub-identifiers must match when
                 determining if an OBJECT IDENTIFIER is in this
                 family of view subtrees; a '1' indicates that an
                 exact match must occur; a '0' indicates 'wild card',
                 i.e., any sub-identifier value matches.

                 Thus, the OBJECT IDENTIFIER X of an object instance
                 is contained in a family of view subtrees if, for
                 each sub-identifier of the value of
                 snmpV3LpSubtreeFamilySubtree, either:

                   the i-th bit of snmpV3LpSubtreeFamilyMask is 0, or

                   the i-th sub-identifier of X is equal to the
                   i-th sub-identifier of the value of
                   snmpV3LpSubtreeFamilySubtree.

                 If the value of this bit mask is M bits long
                 and there are more than M sub-identifiers in
                 the corresponding instance of
                 snmpV3LpSubtreeFamilySubtree, then the bit mask
                 is extended with 1's to be the required length.

                 Note that when the value of this object is the
                 zero-length string, this extension rule results in
                 a mask of all-1's being used (i.e., no 'wild card'),
                 and the family of view subtrees is the one view
                 subtree uniquely identified by the corresponding
                 instance of snmpV3LpSubtreeFamilySubtree.
                "
    DEFVAL      { ''H }
    ::= { snmpV3LpSubtreeFamilyEntry 2 }

snmpV3LpSubtreeFamilyType OBJECT-TYPE
    SYNTAX       INTEGER  { included(1), excluded(2) }
    MAX-ACCESS   read-create



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 22]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


    STATUS       current
    DESCRIPTION "The indication of whether the corresponding instances
                 of snmpV3LpSubtreeFamilySubtree and
                 snmpV3LpSubtreeFamilyMask define a family of view
                 subtrees which is included in or excluded from the
                 MIB view.
                "
    DEFVAL      { included }
    ::= { snmpV3LpSubtreeFamilyEntry 3 }

snmpV3LpSubtreeFamilyStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The storage type for this conceptual row.
                 Conceptual rows having the value 'permanent' need
                 not allow write-access to any columnar objects in
                 the row.

-- Editor's notes:
--         There is the suggestion from DaveL to let these rows
--         inherit the StorageType from the corresponding entries
--         in the viewTable as the default StorageType.
-- End Editor's notes:
                "
    DEFVAL      { nonVolatile }
    ::= { snmpV3LpSubtreeFamilyEntry 4 }

snmpV3LpSubtreeFamilyStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The status of this conceptual row.

                 For those columnar objects which permit write-access,
                 their value in an existing conceptual row can be
                 changed irrespective of the value of
                 snmpV3LpSubtreeFamilyStatus for that row.

                 A conceptual row in this table is not qualified for
                 activation until the MIB view it references is active.
                 Further, a conceptual row in this table is
                 immediately made notInService whenever the status of
                 the view it references is made notInService,
                 and immediately destroyed whenever the
                 view it references is destroyed.
                "
    ::= { snmpV3LpSubtreeFamilyEntry 4 }


-- Conformance information *******************************************



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 23]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997



snmpV3LpMIBCompliances
               OBJECT IDENTIFIER ::= { snmpV3LpMIBConformance 1 }
snmpV3LpMIBGroups
               OBJECT IDENTIFIER ::= { snmpV3LpMIBConformance 2 }

-- Compliance statements *********************************************

snmpV3LpMIBCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION "The compliance statement for SNMPv3 entities which
                 implement the SNMPv3 LPM remote configuration MIB.
                "
    MODULE -- this module
        MANDATORY-GROUPS { snmpV3LpBasicGroup }

        OBJECT        snmpV3LpViewStorageType
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        snmpV3LpViewStatus
        MIN-ACCESS    read-only
        DESCRIPTION  "Create access to the snmpV3LpViewTable
                      is not required.
                     "

        OBJECT        snmpV3LpSubtreeFamilyMask
        WRITE-SYNTAX  OCTET STRING (SIZE (0))
        MIN-ACCESS    read-only
        DESCRIPTION  "Support for configuration via SNMPv3 of
                      subtree families defined using wild-cards
                      is not required.
                     "

        OBJECT        snmpV3LpSubtreeFamilyStorageType
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        snmpV3LpSubtreeFamilyStatus
        MIN-ACCESS    read-only
        DESCRIPTION  "Create access to the snmpV3LpSubtreeFamilyTable
                      is not required.
                     "
    ::= { snmpV3LpMIBCompliances 1 }

-- Units of conformance **********************************************

snmpV3LpBasicGroup OBJECT-GROUP
    OBJECTS { snmpV3LpContextStatus,
              snmpV3LpAcReadViewIndex,
              snmpV3LpAcWriteViewIndex,



Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 24]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


              snmpV3LpAcStorageType,
              snmpV3LpAcStatus,
              snmpV3LpViewStorageType,
              snmpV3LpViewStatus,
              snmpV3LpSubtreeFamilyMask,
              snmpV3LpSubtreeFamilyType,
              snmpV3LpSubtreeFamilyStorageType,  -- length 32 !!
              snmpV3LpSubtreeFamilyStatus
            }
    STATUS       current
    DESCRIPTION "A collection of objects providing for remote
                 configuration of an SNMPv3 engine which implements
                 the SNMPv3 Local Processing Model (LPM).
                "
    ::= { snmpV3LpMIBGroups 1 }

END





































Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 25]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


5.  Security Considerations

5.1  Recommended Practices

This document is meant for use in the SNMPng architecture. The
Local Processing Model (LPM) described in this document controls
access rights to management information based on:

   - contextName, representing a set of management information at the
     managed system where the Local Processing module is running.
   - groupName, representing a group or set of zero, one or more
     security entities. These security entities are mapped into
     one or more groups in the SNMPv3 Security subsystem.
   - Level of Security (LoS) used for the transmission of an SNMP
     message.

When the Local Processing module (LPM) is called for processing a
scopedPDU, it is assumed that the Message Processing and Control
module (MPC) has ensured the authentication and privacy aspects as
specified by the Level of security (LoS) that is being passed.

5.2  Defining Groups

GroupNames are used to give access to a group of zero, one or more
security entities. Within the LPM, a groupName is considered to
exist if that groupName is used (as an index) in a row in the
snmpV3LpAcTable.
By mapping a security identity into a group, a Security subsystem can
add/delete entities to a group.

5.3  Conformance

Conformance rules are described in the SNMPng architecture document
[SNMPng-ARCH].




















Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 26]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


6.  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-432-794

   Co-editor:  Randy Presuhn
               BMC Software, Inc
   postal:     1190 Saratoga Avenue, Suite 130
               San Jose, CA  95129-3433
               USA
   email:      rpresuhn@bmc.com
   phone:      +1-408-556-0720

   Co-editor:  Keith McCloghrie
               Cisco Systems, Inc.
   postal:     170 West Tasman Drive
               San Jose, CA  95134-1706
               USA
   email:      kzm@cisco.com
   phone:      +1-408-526-5260


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














Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 27]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


8.  References

[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.,
     "Architectural Model for the Next Generation Simple Network
     Managememt Protocol (SNMPng)", draft-ietf-snmpng-arch-00.txt,
     March 1997.

[SNMPv3-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,
     March 1997.

[SNMPv3-MPC] The SNMPv3 Working Group, Wijnen, B., Harrington, D.,
     "Message Processing and Control Model for version 3 of the Simple
     Network Management Protocol (SNMPv3)",
     draft-ietf-snmpv3-mpc-00.txt,
     March 1997.

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






Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 28]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


APPENDIX A - Installation

A.1.   Agent Installation Parameters

During installation, an SNMPv3 engine acting in an authoritative role
is configured with several parameters.  These include for the Local
Processing module:

(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) A default context

    One entry in the snmpV3LpContextTable as with a contextName of
    "" (the empty string, representing the default context.

(3) Three entries in the snmpV3LpAcTable as follows:

    - One entry to be used for unauthenticated access:

                                no privacy support  privacy support
                                ------------------  ---------------
      snmpV3LpAcContextName     ""                  ""
      snmpV3LpAcGroupName       "public"            "public"
      snmpV3LpAcLoS             noAuth/noPriv       noAuth/noPriv
      snmpV3LpAcReadViewIndex   1                   1
      snmpV3LpAcWriteViewIndex  0                   0
      snmpV3LpStorageType       permanent           permanent
      snmpV3LpStatus            active              active

    - One entry to be used for authenticated access but without
      privacy:
                                no privacy support  privacy support
                                ------------------  ---------------
      snmpV3LpAcContextName     ""                  ""
      snmpV3LpAcGroupName       "public"            "public"
      snmpV3LpAcLoS             Auth/noPriv         Auth/noPriv
      snmpV3LpAcReadViewIndex   2                   2
      snmpV3LpAcWriteViewIndex  2                   2
      snmpV3LpStorageType       permanent           permanent
      snmpV3LpStatus            active              active

    - One entry to be used for authenticated access with privacy:




Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 29]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


                                no privacy support  privacy support
                                ------------------  ---------------
      snmpV3LpAcContextName                         ""
      snmpV3LpAcGroupName                           "public"
      snmpV3LpAcLoS                                 Auth/Priv
      snmpV3LpAcReadViewIndex                       2
      snmpV3LpAcWriteViewIndex                      2
      snmpV3LpStorageType                           permanent
      snmpV3LpStatus                                active

(4) Two views depending on the security posture.

    -  One view (the <all> view) for authenticated access:

       -  the <all> MIB view is the following subtree:
              "internet"        [RFC1902]

    -  A second view (the <restricted> view) for unauthenticated
       access.  This view is configured according to the selected
       security posture:

       -  For the "very-secure" posture:

          the <restricted> MIB view is the union of these subtrees:
              "snmp"            [RFC1907]
              "snmpEngine"      [SNMPv3-USEC]
              "usecStats"       [SNMPv3-USEC]
              "authMD5Stats"    [SNMPv3-USEC]
              "privDESStats"    [SNMPv3-USEC]
              "snmpV3Stats"     [SNMPv3-MPC]
              "snmpV3LpStats"   [SNMPv3-LPM]

       -  For the "semi-secure" posture:

          the <restricted> MIB view is the union of these subtrees:
              "snmp"            [RFC1907]
              "snmpEngine"      [SNMPv3-USEC]
              "usecStats"       [SNMPv3-USEC]
              "authMD5Stats"    [SNMPv3-USEC]
              "privDESStats"    [SNMPv3-USEC]
              "snmpV3Stats"     [SNMPv3-MPC]
              "snmpV3LpStats"   [SNMPv3-LPM]
              "system"          [RFC1907]

       -  For the "minimum-secure" posture:

          the <restricted> MIB view is the following subtree.
              "internet"        [RFC1902]

    -  Access rights to allow:




Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 30]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


       - read-only access for LoS "noAuth" on behalf of security
         entities that belong to the group "public" to the
         <restricted> MIB view in the context with contextName "".

       - read-write access for LoS "auth" on behalf of security
         entities that belong to the group "public" to the
         <all> MIB view in the context with contextName "".

       - if privacy is supported,
         read-write access for LoS "auth" on behalf of security
         entities that belong to the group "public" to the
         <all> MIB view in the context with contextName "".

-- Editor's note:
            If we find it useful (I do) then I will also work out
            the entries in the viewTable and viewSubtreeFamilyTable
            so that we have the above views defined.
-- End Editor's note




































Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 31]


Draft          Local Processing Model (LPM) for SNMPv3          May 1997


Table of Contents

0.  Issues                                                             2
0.1  Change Log                                                        2
1.  Introduction                                                       3
1.2  Local Processing                                                  3
1.3  Local Configuration Datastore                                     4
2.  Elements of the Model                                              5
2.1  Groups                                                            5
2.2  Level of Security (LoS)                                           5
2.3  Contexts                                                          5
2.4  scopedPDU                                                         5
2.5  Access Policy                                                     6
2.6.  Error Reporting                                                  6
3.  Elements of Procedure                                              8
3.1  Processing a Received scopedPDU                                   8
3.1.1.  Additional Details                                            10
3.1.1.1.  ASN.1 Parsing Errors                                        10
3.1.1.2.  Generation of a Report PDU                                  10
4.  Definitions                                                       11
5.  Security Considerations                                           26
5.1  Recommended Practices                                            26
5.2  Defining Groups                                                  26
5.3  Conformance                                                      26
6.  Editor's Addresses                                                27
7.  Acknowledgements                                                  27
8.  References                                                        28
A.1.   Agent Installation Parameters                                  29




























Wijnen/Presuhn/McCloghrie      Expires November 1997           [Page 32]