Local Processing Model for the Next Generation
Simple Network Management Protocol (SNMPng)
26 March 1997
B. Wijnen
IBM T.J. Watson Research
wijnen@vnet.ibm.com
D. Harrington
Cabletron Systems, Inc.
dbh@cabletron.com
<draft-ietf-snmpv3-lpm-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Abstract
This document describes the Local Processing Model (LPM) for the
Next-Generation of the Simple Network Management Protocol (SNMPng).
It is part of the overall Architectural Model for the Next Generation
Simple Network Management Protocol (SNMPng).
This document includes a MIB for remotely monitoring/managing the
configuration paramters for this LPM.
Wijnen/Harrington Expires September 1977 [Page 1]
Draft Local Processing Model (LPM) for SNMPng March 1997
0. Change Log
[version 0.6]
- Add address info for WG chair.
- Add address for DaveH in MIB description
- submit as I-D
[version 0.5]
- Some more comments by BW.
- Some more cleanup
- Address comments from others (dbh, dl)
- complete missing sections
- I still have quite a few of editor's notes so that
people can discuss/evaluate the alternatives.
Or do we want/need to take a position right now?
- add abstract
- prepare for pagination
[version 0.4]
- Add initial config info as appendix A
- Some more cleanup
[version 0.3]
- Explain and extend usage of viewTable and subtreeFamilyTable
[version 0.2]
- merge in dbh comments
- add more personal bw comments
- add more terminology definitions
- add MIB
[version 0.1]
- initial version
Wijnen/Harrington Expires September 1977 [Page 2]
Draft Local Processing Model (LPM) for SNMPng March 1997
1. Introduction
A management system contains: several (potentially many) nodes, each
with a processing entity, termed an agent, which has access to
management instrumentation; at least one management station; and, a
management protocol, used to convey management information between the
agents and management stations.
Management stations execute management applications which monitor and
control managed elements. Managed elements are devices such as hosts,
routers, terminal servers, etc., which are monitored and controlled
via access to their management information.
Operations of the protocol are carried out under an administrative
framework which defines minimum policies for mechanisms which
provide message-level security, access control for managed objects,
and interaction between the protocol engine and the applications
which use the services of the engine.
The Architectural Model for SNMPng [SNMPng-ARCH] describes
a Local Processing Framework for SNMP messages that are
targetted for local processing to access management information or
for SNMP messages that originate from local processing of management
information.
It is the purpose of this document to define a Local Processing
Model (LP-M) for the Next Generation Simple Network Management
Protocol (LP-M for SNMPng).
1.1 Terminology
Definition of SNMPng acronyms and terms:
MPC-F - Message Processing and Control Framework
MPC-M - Message Processing and Control Model
MPC-I - Message Processing and Control Implementation
SF-F - Security Framework
SF-M - Security Framework Model
SF-I - Security Framework Implementation
LP-F - Local Processing Framework
LP-M - Local Processing Model
LP-I - Local Processing Implementation
LCD - Local Configuration Datastore
1.2 Local Processing
Local Processing may occur in an SNMPng entity acting in an agent
role in response to SNMPng request messages from an SNMPng
Wijnen/Harrington Expires September 1977 [Page 3]
Draft Local Processing Model (LPM) for SNMPng March 1997
entity acting in a manager role. These request messages include
several types of operations, including GetRequest, GetNextRequest,
GetBulkRequest, and SetRequest operations.
Local Processing only occurs if the request is targeted at local
management information as determined by the contextID in the
Naming-Scope in a Scoped-PDU. It is the MPC implementation (MPC-I)
that determines if the contextID refers to the current SNMPng
engine and if so, to direct the Scoped-PDU to the LP-I.
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
error report, termed the Report-PDU.
Local Processing is also responsible for generating notifications,
which will result in the production of one or more traps, termed
SNMPv2-TRAP-PDUs.
1.3 Local Configuration Datastore
To implement the model described in this document, each SNMPng
entity needs to retain its own set of information about access
rights and policies, trap destinations, and the like. This set
of information is called the SNMPng entity's Local Configuration
Datastore (LCD) because it is locally-stored information.
In order to allow an SNMPng entity's LCD to be remotely configured,
portions of the LCD need to be accessible as managed objects.
A MIB module, the SNMPng LP-M Configuration MIB, which defines
these managed object types is included in this document.
Wijnen/Harrington Expires September 1977 [Page 4]
Draft Local Processing Model (LPM) for SNMPng March 1997
2. Elements of the Model
This section contains definitions to realize the access control
applied by this LP-M.
2.1 SNMPng Group
A groupName identifies a group (set) of zero or more security
entities on whose behalf SNMP messages are being processed or
generated.
It is the responsibility of the MPC-I to determine in an
authorirative manner for which groupName an incoming SNMP
message is being processed.
It is the responsibility of the LP-I to determine the groupName
for which a notification (TRAP) is being generated.
This Model (LP-M) requires the groupName to be passed as input
to an implementation (LP-I) of this LP-M when a message is
handed to the LP-I for processing.
This Model (LP-M) requires the groupName to be passed as output
from an implementation (LP-I) when a message originates from
the LP-I.
2.2 SNMPng Quality of Service (Qos)
The Qos identifies the Quality of Service (in terms of message
security) used for transmitting the SNMP message.
It is the responsibility of the MPC-I to determine in an
authoritative manner the Qos that was used for an incoming
SNMP message.
It is the responsibility of the LP-I to determine the Qos
that must be used when transmitting a notification (TRAP).
This Model (LP-M) recognizes three different Qos levels:
- without authentication and without privacy
- with authentication but without privacy
- with authentication and with privacy
This Model (LP-M) requires the Qos to be passed as input
to an implementation (LP-I) of this LP-M when a message is
handed to the LP-I for processing.
This Model (LP-M) requires the Qos to be passed as output
from an implementation (LP-I) when a message originates from
the LP-I.
2.3 Contexts
Wijnen/Harrington Expires September 1977 [Page 5]
Draft Local Processing Model (LPM) for SNMPng March 1997
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 SNMPng Scoped-PDU
A scoped-PDU contains a Naming-Scope that unambiguously
identifies an SNMP agent and the context, (locally) accesible
by that agent, to which the SNMP management information
in the SNMP-PDU refers.
A Naming-Scope contains a contextID that unambiguously identifies
the SNMP agent which has (local) access to the management
information refered to by the contextName and the SNMP-PDU.
A Naming-Scope contains a contextName which unambiguously
identifies an SNMP context accessible by the SNMP agent to
which the SNMP-PDU is directed or from which the SNMP-PDU
is originated.
It is the responsibility of the MPC-I to determine in an
authoritative manner if the contextID refers to the current
SNMPng engine and if so to direct the SNMP message to the
LP-I for local processing.
It is the responsibility of the LP-I to determine the
contextName from which the management information in a
notification (TRAP) is retrieved.
This Model (LP-M) requires the Soped-PDU to be passed as input
to an implementation (LP-I) of this LP-M if a message is
handed to the LP-I for processing.
This Model (LP-M) requires that the contextName be passed
as input to an implementation (LP-I) of this LP-M if a trap
must be generated.
This Model (LP-M) requires the Soped-PDU to be passed as output
from an implementation (LP-I) if a message originates from
the LP-I.
Editor's notes:
I wonder if it would not be better to not use a
Scoped-PDU as input/output to the LP-M but instead
use contextName plus PDU as input/output. After all,
the contextID is irrelevant in the LP-M and is in
fact only used/known in the MPC.
End Editor's notes.
Wijnen/Harrington Expires September 1977 [Page 6]
Draft Local Processing Model (LPM) for SNMPng March 1997
2.5 Access Policy
The access policy of this LP-M 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 Qos, 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-M and SF-M
End Editor's notes.
While processing a received communication, an SNMPng entity may
determine that the message is unacceptable. In this case,
the appropriate error counter is incremented and the received
message is discarded without further processing.
If an SNMPng entity 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 LP-I, the Qos for sending the report-PDU is set to
noAUth (no authentiocation, no privacy).
The reportableFlag should never be set for a message that
contains a Response, SNMPv2-Trap or Report operation.
Wijnen/Harrington Expires September 1977 [Page 7]
Draft Local Processing Model (LPM) for SNMPng March 1997
3. Elements of Procedure
This section describes the procedures followed by an
implementation (LP-I) of this Model (LP-M) when processing or
generating a Scoped-PDU
3.1 Processing a Received Scoped-PDU
This section describes the procedure followed by an implementation
(LP-I) whenever it receives a scoped-PDU for local processing.
This procedure is independent of any of the other processing
within the SNMPng Architectural Model.
(1) The PDU portion of the Scoped-PDU 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 scoped-PDU is discarded without further
processing.
(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 Report, Response,
Trap, or Inform operation,
then the snmpNgLpmStatsUnauthorizedOperations counter is
incremented, and the received Scoped-PDU is discarded
without further processing.
Editor's notes:
the above PDU-types should not be passed to the LP-I.
So it seems that the MPC-M also must define some SNMP
PDU processing for Report, Response, Trap, Inform.
We used UnauthorizedOperations counter in v2u but v2*
used authorizationError (in SNMP PDU)... The v2u did that
because it was part of the access-control as opposed to
part of PDU processing. Now it seems part of PDU
processing again... so maybe using authorizationError
is OK again... that is if we get to this point.
If the MPC-I detects it, then it should be an
unauthorizedOperations-report I think.
End Editor's notes.
(4) The LCD is consulted for information about the SNMPng context
identified by the contextName. If information about this
SNMPng context is absent from the LCD, then the
snmpNgLpmStatsUnknownContexts counter is incremented, a report
PDU [RFC1905] is generated, and the received scoped-PDU is
discarded without further processing.
Wijnen/Harrington Expires September 1977 [Page 8]
Draft Local Processing Model (LPM) for SNMPng March 1997
Editor's notes:
The above means we have a contextTable within LPM,
but I am not sure we need one... since we just use a
contextName as an index into the snmpNgLpmAcTable.
We already decided to get rid of contextLocalEntity.
I have heard many stories that contectLocalTime is not
used and that the functionality could be achieved by
just defining few extra objects for those that need
something like a value to be used at restartTime.
If we do not use a contextTable, then we could check that
the context is used as index in the acTable and if not,
then we assume the context does not exist
An other alternative is to skip step (4) and (5) and
just return an authorizationError or a reportPDU for
snmpNgLpmUnAuthorizedOperations since we will not find
an entry in the snmpNgLpmAcTable.
Some feel that the contextTable must exist (that is in
readOnly mode) so that a manager can learn about the
contextNames that exist at an agent.
But the entityMIB also sort of defines logical entities
which basically map to contextNames. However, the current
entityMIB does not yet address SNMPng contexts. Maybe
we should sync up with them.
End Editor's notes.
(5) The LCD is consulted for information about the SNMPng group
identified by the groupName. If information about this
SNMPng group is absent from the LCD, then the
snmpNgLpmStatsUnknownGroups counter is incremented, a report
PDU [RFC1905] is generated, and the received Scoped-PDU is
discarded without further processing.
Editor's notes:
The above would assume that we just check if the group
is used as an index in the snmpNgLpmAcTable at all
An other alternative is to skip step (4) and (5) and
just return a authorizationError or a reportPDU for
snmpNgLpmUnAuthorizedOperations since we will not find
an entry in the snmpNgLpmAcTable.
End Editor's notes.
(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 Qos, on behalf of the
indicated group, and concerning management information in
Wijnen/Harrington Expires September 1977 [Page 9]
Draft Local Processing Model (LPM) for SNMPng March 1997
the indicated context for the particular SNMPv2 operation
type.
b) if the SNMPv2 operation type is not among the authorized
access rights, then the snmpNgLpmStatsUnauthorizedOperations
counter is incremented, a report PDU is generated, and
the received Scoped-PDU is discarded without further
processing.
c) the management operation represented by the SNMPv2 operation
type is performed by the receiving LP-I with respect to the
relevant MIB view within the SNMPng context according to
the procedures set forth in [RFC1905], where the relevant
MIB view is determined according to the contextName,
groupName and the Qos values and the SNMPv2 operation
type requested.
d) An SNMPv2 Response-PDU is produced and presented to the
the MPC-I for further processing.
The LP-I uses the scoped-PDU-MMS to ensure that the
produced Response-PDU does not exceed the maximum
message size.
3.2 Generating a Notification
This section describes the procedure followed by an implementation
(LP-I) whenever it must generate a Scoped-PDU for an SNMPv2-Trap.
This procedure is independent of any of the other processing
within the SNMPng Architectural Model.
(1) The LCD is consulted for the set of trap destinations.
(2) For each element in the set of trap destinations, the Qos,
group (snmpNgLpmTrapGroup), destination addres and security
model (snmpNgLpmSecModel) are extracted from the LCD and
used together with the contextName in the following steps:
a) the LCD is consulted for access rights authorized for
communications using the indicated Qos, on behalf of the
indicated group, and concerning management information in
the indicated context for the SNMPv2 trap operation.
b) if the SNMPv2 trap operation is not among the authorized
access rights, then no SNMPv2-TRAP PDU is produced and
processing continues with the next element.
c) the varBindList is checked against the relevant MIB view
where the relevant MIB view is determined according to the
contextName, groupName and the Qos values and the SNMPv2
trap operation.
Wijnen/Harrington Expires September 1977 [Page 10]
Draft Local Processing Model (LPM) for SNMPng March 1997
d) if any varBind is not in view, then no SNMPv2-TRAP PDU is
produced and processing continues with the next element.
e) an SNMPv2-TRAP PDU is produced and presented to the
MPC-I for further processing. The LP-I passes the
the Scoped-PDU, security model, the Qos, the groupName
and the destination address to the MPC-I.
Wijnen/Harrington Expires September 1977 [Page 11]
Draft Local Processing Model (LPM) for SNMPng March 1997
4. Definitions
SNMPng-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,
SnmpNgGroupName, SnmpNgContextName,
SnmpNgQos, SnmpNgEngineID,
SnmpNgSecurityModel FROM SNMPng-MIB;
snmpNgLpMIB MODULE-IDENTITY
LAST-UPDATED "9703260000Z" -- 26 Mar 1997, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@tis.com
Subscribe: majordomo@tis.com
In 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
SNMPng Local Processing Model.
"
Wijnen/Harrington Expires September 1977 [Page 12]
Draft Local Processing Model (LPM) for SNMPng March 1997
::= { snmpModules xx }
-- Administrative assigments *****************************************
snmpNgLpMIBObjects OBJECT IDENTIFIER ::= { snmpNgLpMIB 1 }
snmpNgLpMIBConformance OBJECT IDENTIFIER ::= { snmpNgLpMIB 2 }
-- Information about Local Contexts **********************************
-- Editor's notes:
-- We're still discussing if the contextTable is needed at all
-- See Edotor's notes in section 3.1 under item 4).
-- End Editor's notes.
snmpNgLpContextTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpNgLpContextEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of locally available contexts.
This table is read-only meaning that SNMPng entities
in a manager role cannot configure contexts.
Instead the table is meant to provide input to SNMPng
entities in a manager role sich that they can
properly configure the snmpNgLpAcTable to control
access to all contexts in an SNMPng entity operating
in an agent role.
"
::= { snmpNgLpMIBObjects 1 }
snmpNgLpContextEntry OBJECT-TYPE
SYNTAX SnmpNgLpContextEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Information about a particular context."
INDEX { IMPLIED snmpNgLpContextName }
::= { snmpNgLpContextTable 1 }
SnmpNgLpContextEntry ::= SEQUENCE
{
snmpNgLpContextName SnmpNgContextName,
snmpNgLpContextStatus RowStatus
}
snmpNgLpContextName OBJECT-TYPE
SYNTAX SnmpNgContextName
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A textual name uniquely identifying a particular
context on a particular agent.
Wijnen/Harrington Expires September 1977 [Page 13]
Draft Local Processing Model (LPM) for SNMPng March 1997
"
::= { snmpNgLpContextEntry 1 }
snmpNgLpContextStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The status of this conceptual row in the context
table.
"
::= { snmpNgLpContextEntry 2 }
-- Information about Access Rights ***********************************
snmpNgLpAcTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpNgLpAcEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of group access rights configured in the
local configuration datastore (LCD).
"
::= { snmpNgLpMIBObjects 2 }
snmpNgLpAcEntry OBJECT-TYPE
SYNTAX SnmpNgLpAcEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An access right configured in the local configuration
datastore (LCD) authorizing access to a SNMPng
context.
"
INDEX { snmpNgLpAcContextName,
snmpNgLpAcGroupName,
snmpNgLpAcQoS
}
::= { snmpNgLpAcTable 1 }
SnmpNgLpAcEntry ::= SEQUENCE
{
snmpNgLpAcContextName SnmpNgContextName,
snmpNgLpAcGroupName SnmpNgGroupName,
snmpNgLpAcPrivileges INTEGER,
snmpNgLpAcReadViewIndex INTEGER,
snmpNgLpAcWriteViewIndex INTEGER,
snmpNgLpAcStorageType StorageType,
snmpNgLpAcStatus RowStatus
}
snmpNgLpAcContextName OBJECT-TYPE
SYNTAX ContextName
Wijnen/Harrington Expires September 1977 [Page 14]
Draft Local Processing Model (LPM) for SNMPng March 1997
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The context name which identifies an SNMPng context
to which this conceptual row grants access rights.
"
::= { snmpNgLpAcEntry 1 }
snmpNgLpAcGroupName OBJECT-TYPE
SYNTAX GroupName
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The group name which identifies an SNMPng group
to which this conceptual row grants access rights.
"
::= { snmpNgLpAcEntry 1 }
snmpNgLpAcQoS OBJECT-TYPE
SYNTAX QoS
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The minimum level of security required of messages
sent on behalf of an entity belonging to the group
in order to gain the access rights allowed by this
conceptual row.
"
::= { snmpNgLpAcEntry 2 }
snmpNgLpAcPrivileges OBJECT-TYPE
SYNTAX BITS { get(0), getNext(1), getBulk(2),
set(3), inform(4), snmpv2Trap(5) }
-- Editor's notes:
-- I think we should remove inform... it is not handled in
-- the LP-M. Inform is application to application.
-- I also have no problem if we were to use SNMPv2*
-- values: nothing(1), readOnly(2), readWrite(3)
--
-- There is also the suggestion to do away with this column
-- all together because the Privileges can be detrmined
-- based on the readView or writeView being non-zero.
-- End Editor's notes.
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The access privileges authorized by this conceptual
row. Access privileges specify whether received
retrieval and modification requests are permitted
to be processed, and whether notifications are
permitted to be transmitted.
A type of request is authorized if and only if the
corresponding enumerated bit is set.
"
Wijnen/Harrington Expires September 1977 [Page 15]
Draft Local Processing Model (LPM) for SNMPng March 1997
DEFVAL { { get, getNext, getBulk } }
::= { snmpNgLpAcEntry 3 }
snmpNgLpAcReadViewIndex 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 SNMPng context to which this
conceptual row authorizes read access.
The identified MIB view is that for which
snmpNgLpViewIndex has the same value as the
instance of this object; if the value is zero or
there is no MIB view having this value of
snmpNgLpViewIndex, 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 (traps).
"
DEFVAL { 0 }
::= { snmpNgLpAcEntry 4 }
snmpNgLpAcWriteViewIndex 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 SNMPng context to which this
conceptual row authorizes write access.
The identified MIB view is that for which
snmpNgLpViewIndex has the same value as the
instance of this object; if the value is zero or
there is no MIB view having this value of
snmpNgLpViewIndex, 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.
"
DEFVAL { 0 }
::= { snmpNgLpAcEntry 5 }
snmpNgLpAcStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
Wijnen/Harrington Expires September 1977 [Page 16]
Draft Local Processing Model (LPM) for SNMPng March 1997
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 }
::= { snmpNgLpAcEntry 6 }
snmpNgLpAcStatus 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 snmpNgLpAcStatus
for that row.
-- Editor's notes:
-- I am planning to remove the following based on discussions
-- in Montreal between Shawn, JeffJohnson and ourselves
-- where they claimed we should just allow for stale entries.
--
-- 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 snmpNgLpViewStatus to
-- destroy(6) either:
-- - fail with an inconsistent value error if any
-- corresponding entries exist in the
-- snmpNgLpSubtreeFamilyTable, or
-- - result also in deletion of all corresponding entries
-- in the snmpNgLpSubtreeFamilyTable.
-- End Editor's notes
"
::= { snmpNgLpAcEntry 7 }
-- Information about MIB views ***************************************
-- Support for views having instance-level granularity is optional
snmpNgLpViewTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpNgLpViewEntry
Wijnen/Harrington Expires September 1977 [Page 17]
Draft Local Processing Model (LPM) for SNMPng March 1997
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of locally defined MIB views.
When an SNMPng entity in the manager role wants to
create a new MIB view, then it must first create
an entry in the snmpNgLpViewTable, using a
non-existing index-value for snmpNgLpViewIndex.
If the creation of such an entry is successfull,
the SNMPng entity in the manager role can then start
creating entries in the snmpNgLpSubtreeFamiliyTable.
When deleting MIB views, it is stronly advised that
first the related snmpNgLpSubtreeFamilityEntries are
deleted from the snmpNgLpSubtreeFamiliyTable and that
only upon completion of that deletion process the
snmpNgLpViewEntry is deleted from the
snmpNgLpViewTable.
Following these procedures there should be no
collisions when multiple managers try to update
the MIB views at an SNMPng entity in an agent role.
"
::= { snmpNgLpMIBObjects 3 }
snmpNgLpViewEntry OBJECT-TYPE
SYNTAX SnmpNgLpViewEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Information on a particular local MIB view."
INDEX { snmpNgLpViewIndex }
::= { snmpNgLpViewTable 1 }
SnmpNgLpViewEntry ::= SEQUENCE
{
snmpNgLpViewIndex INTEGER,
snmpNgLpViewName OCTET STRING,
snmpNgLpViewStorageType StorageType,
snmpNgLpViewStatus RowStatus
}
snmpNgLpViewIndex OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An arbitrary unique value for each MIB view.
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 entity's
network management system.
Wijnen/Harrington Expires September 1977 [Page 18]
Draft Local Processing Model (LPM) for SNMPng March 1997
-- 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.
-- End Editor's notes.
Thus, the value for a nonVolatile, permanent, or
readOnly (see snmpNgLpViewStorageType) 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
SNMPng entity, i.e., it is not meaningful to any
other SNMPng entity except to uniquely identify the
view within the set of all views known to this
SNMPng entity.
"
::= { snmpNgLpViewEntry 1 }
snmpNgLpViewName 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 { "" }
::= { snmpNgLpViewEntry 2 }
snmpNgLpViewStorageType 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 }
::= { snmpNgLpViewEntry 3 }
snmpNgLpViewStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row."
Wijnen/Harrington Expires September 1977 [Page 19]
Draft Local Processing Model (LPM) for SNMPng March 1997
::= { snmpNgLpViewEntry 4 }
-- Subtree families of MIB views *************************************
snmpNgLpSubtreeFamilyTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpNgLpSubtreeFamilyEntry
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,
or excluded from, the MIB view according to the
value of snmpNgLpSubtreeFamilyType in the entry
whose value of snmpNgLpSubtreeFamilySubtree has the
most sub-identifiers. If multiple entries match
and have the same number of sub-identifiers, then
the lexicographically greatest instance of
snmpNgLpSubtreeFamilyType 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 snmpNgLpSubtreeFamilySubtree for the entry,
and each sub-identifier in the value of
snmpNgLpSubtreeFamilySubtree matches its
corresponding sub-identifier in X.
Two sub-identifiers match either if the
corresponding bit of snmpNgLpSubtreeFamilyMask 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
snmpNgLpSubtreeFamilySubtree and
snmpNgLpSubtreeFamilyMask.
In the case where no 'wild card' is defined in
snmpNgLpSubtreeFamilyMask, the family of view
subtrees reduces to a single view subtree.
Wijnen/Harrington Expires September 1977 [Page 20]
Draft Local Processing Model (LPM) for SNMPng March 1997
When an SNMPng entity in the manager role wants to
create a new MIB view, then it must first create
an entry in the snmpNgLpViewTable, using a
non-existing index-value for snmpNgLpViewIndex.
If the creation of such an entry is successfull,
the SNMPng entity in the manager role can then start
creating entries in the snmpNgLpSubtreeFamiliyTable.
When deleting MIB views, it is stronly advised that
first the related snmpNgLpSubtreeFamilityEntries are
deleted from the snmpNgLpSubtreeFamiliyTable and that
only upon completion of that deletion process the
snmpNgLpViewEntry is deleted from the
snmpNgLpViewTable.
Following these procedures there should be no
collisions when multiple managers try to update
the MIB views at an SNMPng entity in an agent role.
"
::= { snmpNgLpMIBObjects 4 }
snmpNgLpSubtreeFamilyEntry OBJECT-TYPE
SYNTAX SnmpNgLpSubtreeFamilyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Information on a particular family of view subtrees
included in or excluded from a particular SNMPng
context's MIB view. The MIB view must exist
(i.e., be represented by a conceptual row in the
snmpNgLpViewTable) 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
snmpNgLpSubtreeFamilyTable.
The value of snmpNgLpViewIndex 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 { snmpNgLpViewIndex,
IMPLIED snmpNgLpSubtreeFamilySubtree
}
::= { snmpNgLpSubtreeFamilyTable 1 }
Wijnen/Harrington Expires September 1977 [Page 21]
Draft Local Processing Model (LPM) for SNMPng March 1997
SnmpNgLpSubtreeFamilyEntry ::= SEQUENCE
{
snmpNgLpSubtreeFamilySubtree OBJECT IDENTIFIER,
snmpNgLpSubtreeFamilyMask OCTET STRING,
snmpNgLpSubtreeFamilyType INTEGER,
snmpNgLpSubtreeFamilyStorageType StorageType,
snmpNgLpSubtreeFamilyStatus RowStatus
}
snmpNgLpSubtreeFamilySubtree OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The MIB subtree which when combined with the
corresponding instance of snmpNgLpSubtreeFamilyMask
defines a family of view subtrees.
"
::= { snmpNgLpSubtreeFamilyEntry 1 }
snmpNgLpSubtreeFamilyMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..16))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The bit mask which,
in combination with the corresponding instance of
snmpNgLpSubtreeFamilySubtree, defines a family of
view subtrees.
Each bit of this bit mask corresponds to a
sub-identifier of snmpNgLpSubtreeFamilySubtree,
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
snmpNgLpSubtreeFamilySubtree, either:
the i-th bit of snmpNgLpSubtreeFamilyMask is 0, or
Wijnen/Harrington Expires September 1977 [Page 22]
Draft Local Processing Model (LPM) for SNMPng March 1997
the i-th sub-identifier of X is equal to the
i-th sub-identifier of the value of
snmpNgLpSubtreeFamilySubtree.
If the value of this bit mask is M bits long
and there are more than M sub-identifiers in
the corresponding instance of
snmpNgLpSubtreeFamilySubtree, 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 snmpNgLpSubtreeFamilySubtree.
"
DEFVAL { ''H }
::= { snmpNgLpSubtreeFamilyEntry 2 }
snmpNgLpSubtreeFamilyType OBJECT-TYPE
SYNTAX INTEGER { included(1), excluded(2) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The indication of whether the corresponding instances
of snmpNgLpSubtreeFamilySubtree and
snmpNgLpSubtreeFamilyMask define a family of view
subtrees which is included in or excluded from the
MIB view.
"
DEFVAL { included }
::= { snmpNgLpSubtreeFamilyEntry 3 }
snmpNgLpSubtreeFamilyStorageType 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 }
::= { snmpNgLpSubtreeFamilyEntry 4 }
Wijnen/Harrington Expires September 1977 [Page 23]
Draft Local Processing Model (LPM) for SNMPng March 1997
snmpNgLpSubtreeFamilyStatus 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
snmpNgLpSubtreeFamilyStatus 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.
"
::= { snmpNgLpSubtreeFamilyEntry 4 }
-- Information about TRAP destinations *******************************
snmpNgLpTrapDestTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpNgLpTrapDestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The transport addresses to which notifications
(traps) are to be sent on behalf of specific
SNMPng groups.
"
::= { snmpNgLpMIBObjects 5 }
snmpNgLpTrapDestEntry OBJECT-TYPE
SYNTAX SnmpNgLpTrapDestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A transport address to which notifications (traps)
are to be sent on behalf of a specific SNMPng group
"
INDEX { snmpNgLpTrapDestTDomain,
IMPLIED snmpNgLpTrapDestTAddress
}
::= { snmpNgLpTrapDestTable 1 }
SnmpNgLpTrapDestEntry ::= SEQUENCE
{
snmpNgLpTrapDestTDomain TDomain,
snmpNgLpTrapDestTAddress TAddress,
snmpNgLpTrapDestQos SnmpNgQos,
Wijnen/Harrington Expires September 1977 [Page 24]
Draft Local Processing Model (LPM) for SNMPng March 1997
snmpNgLpTrapDestGroupName SnmpGroupName,
snmpNgLpTrapDestSecModel SnmpNgSecurityModel,
snmpNgLpTrapDestStorageType StorageType,
snmpNgLpTrapDestStatus RowStatus
}
snmpNgLpTrapDestTDomain OBJECT-TYPE
SYNTAX TDomain
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Indicates the kind of transport service for this
transport address.
"
DEFAULT { snmpUDPDomain }
::= { snmpNgLpTrapDestAddressEntry 1 }
snmpNgLpTrapDestTAddress OBJECT-TYPE
SYNTAX TAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The transport service address.
The address is formatted according to the
corresponding value of snmpNgLpTrapDestTDomain.
For example, for the transport domain corresponding
to the snmpUDPDomain, transportAddress is formatted
as a 4-octet IP Address concatenated with a 2-octet
UDP port number.
See [RFC1906] for more information on transport
domains and how their corresponding addresses are
formatted.
"
::= { snmpNgLpTrapDestEntry 2 }
snmpNgLpTrapDestQos OBJECT-TYPE
SYNTAX SnmpNgQos
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The Qos to use when sending a notification (trap)
to this destination.
"
DEFVAL { 2 } -- auth
::= { snmpNgLpTrapDestEntry 4 }
snmpNgLpTrapDestGroupName OBJECT-TYPE
SYNTAX SnmpNgGroupName
MAX-ACCESS read-create
STATUS current
Wijnen/Harrington Expires September 1977 [Page 25]
Draft Local Processing Model (LPM) for SNMPng March 1997
DESCRIPTION "The group name to use when applying access control
to the management information contained in the
notification (trap) to be sent.
"
::= { snmpNgLpTrapDestEntry 5 }
snmpNgLpTrapDestSecModel OBJECT-TYPE
SYNTAX SnmpNgSecurityModel
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The Security Model to use when applying security
measures to the SNMP message before sending it
to this destination.
"
::= { snmpNgLpTrapDestEntry 6 }
snmpNgLpTrapDestStorageType 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 }
::= { snmpNgLpTrapDestEntry 7 }
snmpNgLpTrapDestStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row."
::= { snmpNgLpTrapDestEntry 8 }
-- Conformance information *******************************************
snmpNgLpMIBCompliances
OBJECT IDENTIFIER ::= { snmpNgLpMIBConformance 1 }
snmpNgLpMIBGroups
OBJECT IDENTIFIER ::= { snmpNgLpMIBConformance 2 }
-- Compliance statements *********************************************
snmpNgLpMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPng entities which
implement the SNMPng LP-M remote configuration MIB.
"
MODULE -- this module
MANDATORY-GROUPS { snmpNgLpBasicGroup }
Wijnen/Harrington Expires September 1977 [Page 26]
Draft Local Processing Model (LPM) for SNMPng March 1997
OBJECT snmpNgLpViewStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpNgLpViewStatus
MIN-ACCESS read-only
DESCRIPTION "Create access to the snmpNgLpViewTable
is not required.
"
OBJECT snmpNgLpSubtreeFamilyMask
WRITE-SYNTAX OCTET STRING (SIZE (0))
MIN-ACCESS read-only
DESCRIPTION "Support for configuration via SNMPng of
subtree families defined using wild-cards
is not required.
"
OBJECT snmpNgLpSubtreeFamilyStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpNgLpSubtreeFamilyStatus
MIN-ACCESS read-only
DESCRIPTION "Create access to the snmpNgLpSubtreeFamilyTable
is not required.
"
::= { snmpNgLpMIBCompliances 1 }
-- Units of conformance **********************************************
snmpNgLpBasicGroup OBJECT-GROUP
OBJECTS { snmpNgLpContextStatus,
snmpNgLpAcPrivileges,
snmpNgLpAcReadViewIndex,
snmpNgLpAcWriteViewIndex,
snmpNgLpAcStorageType,
snmpNgLpAcStatus,
snmpNgLpViewStorageType,
snmpNgLpViewStatus,
snmpNgLpSubtreeFamilyMask,
snmpNgLpSubtreeFamilyType,
snmpNgLpSubtreeFamilyStorageType, -- length 32 !!
snmpNgLpSubtreeFamilyStatus,
snmpNgLpTrapDestQos,
snmpNgLpTrapDestGroupName,
snmpNgLpTrapDestSecModel,
snmpNgLpTrapDestStorageType,
snmpNgLpTrapDestStatus
}
Wijnen/Harrington Expires September 1977 [Page 27]
Draft Local Processing Model (LPM) for SNMPng March 1997
STATUS current
DESCRIPTION
"A collection of objects providing for remote
configuration of an SNMPng entity which implements
the SNMPng Local Processing Model (LP-M).
"
::= { snmpNgLpMIBGroups 1 }
END
Wijnen/Harrington Expires September 1977 [Page 28]
Draft Local Processing Model (LPM) for SNMPng March 1997
5. Security Considerations
5.1 Recommended Practices
This document is part of the SNMPng Architectural Model. The
Local Processing Model (LP-M) 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 Implenetation
(LP-I) 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 SNMPng Securty Framework Model
(SF-M).
- Qos used for the transmission of a SNMP message.
When the LP-I is called for processing a Scoped-PDU, it is assumed
that the Message Processing and Control Implementation (MPC-I)
has ensured the authentication and privacy aspects as specified
by the Quality of service (Qos) 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
snmpNgLpAcTable.
By mapping a security entity into a group, a SF-M for SNMPng can
add/delete entities to a group.
5.3 Conformance
Conformance rules are described in the Architectural Model for SNMPng.
Wijnen/Harrington Expires September 1977 [Page 29]
Draft Local Processing Model (LPM) for SNMPng March 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-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
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/Harrington Expires September 1977 [Page 30]
Draft Local Processing Model (LPM) for SNMPng March 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-snmpv3-arch-00.txt,
March 1997.
[SNMPng-LPM] The SNMPng Working Group, Wijnen, B., Harrington, D.,
"Local Processing Model for the Next Generation Simple Network
Management Protocol (SNMPng)", draft-ietf-snmpv3-lpm-00.txt,
March 1997.
[SNMPng-USEC] To be written
The SNMPng Working Group, Editors...Names,
"The User-Based Security Model for the Next Generation Simple
Network Managememt Protocol (SNMPng)",
draft-ietf-snmpv3-usec-00.txt, April 1997.
Wijnen/Harrington Expires September 1977 [Page 31]
Draft Local Processing Model (LPM) for SNMPng March 1997
APPENDIX A - Installation
Editor's notes:
portions of the following still need to be moved to
the appropriate documents. I am just listing them here
so that we have one place where we can see what is
needed.
End Editor's notes.
A.1. Agent Installation Parameters
During installation, an SNMPng entity acting in an agent role is
configured with several parameters. These include:
(1) a security posture (todo in SNMPng-MPC)
The choice of security posture determines the extent of the view
configured for unauthenticated access. One of three possible
choices is selected:
minimum-secure,
semi-secure, or
very-secure.
(2) one or more transport service addresses (todo in SNMPng-MPC)
These parameters may be specified explicitly, or they may be
specified implicitly as the same set of network-layer addresses
configured for other uses by the device together with the well-
known transport-layer "port" information for the appropriate
transport domain [RFC1906]. The agent listens on each of these
transport service addresses for messages.
(3) one or more secrets (todo in SNMPng-USEC)
These are the authentication/privacy secrets for the first user
to be configured.
One way to accomplish this is to have the installer enter a
"password" for each required secret. The password is then
algorithmically converted into the required secret by:
- forming a string of length 1,048,576 octets by repeating the
value of the password as often as necessary, truncating
accordingly, and using the resulting string as the input to
the MD5 algorithm. The resulting digest, termed "digest1",
is used in the next step.
- a second string of length 44 octets is formed by concatenating
digest1, the SNMPng engine's snmpNgEngineID value, and digest1.
This string is used as input to the MD5 algorithm.
Wijnen/Harrington Expires September 1977 [Page 32]
Draft Local Processing Model (LPM) for SNMPng March 1997
The resulting digest is the required secret (see Appendix A.2).
With these configured parameters, the SNMPng entity instantiates
the following snmpNgUsecUserEntry,
no privacy support privacy support
------------------ ---------------
snmpNgUsecEngineID localEngineID localEngineID
snmpNgUsecUserName "public" "public"
snmpNgUsecGroupName "public" "public"
snmpNgUsecAuthProto snmpMD5Protocol snmpMD5Protocol
snmpNgUsecPrivProto none snmpDESProtocol
snmpNgUserSecurityCookie "" ""
(4) The SNMPng LP-M the SNMPng entity in an agent role must
instantiate the following views and access rights. This
configuration information should be readOnly (persistent).
- One context with its <contextName> as the empty-string "".
This represents the default context.
- 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]
"snmpNgStats" [SNMPng-ARCH]
"snmpNgUsecStats" [SNMPng-USEC]
- For the "semi-secure" posture:
the <restricted> MIB view is the union of these subtrees:
"snmp" [RFC1907]
"snmpNgStats" [SNMPng-ARCH]
"snmpNgUsecStats" [SNMPng-USEC]
"system" [RFC1902]
- For the "minimum-secure" posture:
the <restricted> MIB view is the following subtree.
"internet" [RFC1902]
Wijnen/Harrington Expires September 1977 [Page 33]
Draft Local Processing Model (LPM) for SNMPng March 1997
- Access rights to allow:
- read-only access for Qos "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 Qos "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 Qos "auth" on behalf of security
entities that belong to the group "public" to the
<all> MIB view in the context with contextName "".
Wijnen/Harrington Expires September 1977 [Page 34]
Draft Local Processing Model (LPM) for SNMPng March 1997
A.2. Password to Key Algorithm
Editor's Notes:
The following goes into SNMPng-USEC doc.
End Editor's notes.
The following code fragment demonstrates the password to key
algorithm which can be used when mapping a password to an
authentication or privacy key. The calls to MD5 are as
documented in RFC1321 [RFC1321]
void password_to_key(
u_char *password, /* IN */
u_int passwordlen, /* IN */
u_char *agentID, /* IN - ptr to 12 octet long snmpEngineID */
u_char *key) /* OUT - caller's pointer to 16-byte buffer */
{
MD5_CTX MD;
u_char *cp, password_buf[64];
u_long password_index = 0;
u_long count = 0, i;
MD5Init (&MD); /* initialize MD5 */
/**********************************************/
/* Use while loop until we've done 1 Megabyte */
/**********************************************/
while (count < 1048576) {
cp = password_buf;
for (i = 0; i < 64; i++) {
/*************************************************/
/* Take the next byte of the password, wrapping */
/* to the beginning of the password as necessary.*/
/*************************************************/
*cp++ = password[password_index++ % passwordlen];
}
MDupdate (&MD, password_buf, 64);
count += 64;
}
MD5Final (key, &MD); /* tell MD5 we're done */
/*****************************************************/
/* Now localize the key with the agentID and pass */
/* through MD5 to produce final key */
/*****************************************************/
memcpy(password_buf, key, 16);
memcpy(password_buf+16, agentID, 12);
memcpy(password_buf+28, key, 16);
MD5Init(&MD);
MDupdate(&MD, password_buf, 44);
Wijnen/Harrington Expires September 1977 [Page 35]
Draft Local Processing Model (LPM) for SNMPng March 1997
MD5Final(key, &MD);
return;
}
Wijnen/Harrington Expires September 1977 [Page 36]
Draft Local Processing Model (LPM) for SNMPng March 1997
Table of Contents
0. Change Log 2
1. Introduction 3
1.1 Terminology 3
1.2 Local Processing 3
1.3 Local Configuration Datastore 4
2. Elements of the Model 5
2.1 SNMPng Group 5
2.2 SNMPng Quality of Service (Qos) 5
2.3 Contexts 5
2.4 SNMPng Scoped-PDU 6
2.5 Access Policy 7
2.6. Error Reporting 7
3. Elements of Procedure 8
3.1 Processing a Received Scoped-PDU 8
3.2 Generating a Notification 10
4. Definitions 12
5. Security Considerations 29
5.1 Recommended Practices 29
5.2 Defining Groups 29
5.3 Conformance 29
6. Editor's Addresses 30
7. Acknowledgements 30
8. References 31
A.1. Agent Installation Parameters 32
A.2. Password to Key Algorithm 35
Wijnen/Harrington Expires September 1977 [Page 37]
