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]
