Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method for high-performance processing of SNMP get-next requests under the view-based access control model

IP.com Disclosure Number: IPCOM000007102D
Publication Date: 2002-Feb-26
Document File: 13 page(s) / 1M

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method for high-performance processing of SNMP get-next requests under the view-based access control model. Benefits include improved reliability and improved performance.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 32% of the total text.

Method for high-performance processing of SNMP get-next requests under the view-based access control model

Disclosed is a method for high-performance processing of SNMP get-next requests under the view-based access control model. Benefits include improved reliability and improved performance.

Background

              The conventional architecture for describing Internet Management Frameworks describes that an SNMP engine is comprised of the following (see Figure 1):

·        Dispatcher

·        Message Processing Subsystem

·        Security Subsystem

·        Access Control Subsystem

              Applications (Command Responder, Notification Originator, and Proxy Forwarder) make use of the services of these subsystems.

              The Access Control Subsystem of an SNMP engine has the responsibility for checking whether a specific type of access (read, write, notify) to a particular MIB object (instance) is allowed.

              The only defined access control model is the View-Based Access Control Model (VACM).

              VACM is comprised of five elements (see Figure 2):

·        Groups

·        Security level

·        Contexts

·        MIB views

·        Access policy

              Groups are defined as a set of <securityModel, securityName> tuples on whose behalf SNMP management objects can be accessed. A group defines the access rights afforded to all securityNames that belong to that group. The combination of a securityModel and a securityName maps to at most one group. A group is identified by a groupName.

              Security level includes the access rights for a group may differ depending on the security level of the message that contains the request. The security level identifies the level of security that is assumed when checking for access rights.

              Context, or MIB context, is a named subset of the object instances in the local MIB. Contexts provide a useful way of aggregating objects into collections with different access policies.

      MIB views provide access to a context and define a specific set of managed objects. VACM makes use of a powerful and flexible technique for defining MIB views, based on the concepts of view subtrees and view families.

              The MIB view is defined in terms of a collection, or family, of subtrees, with each subtree being included in or excluded from the view. The managed objects in a local database are organized into a hierarchy, or tree, based on the object identifiers of the objects.

              A subtree is simply a node in the MIB's naming hierarchy plus all of its subordinate elements. More formally, a subtree may be defined as the set of all objects and object instances that have a common ASN.1 OBJECT IDENTIFIER prefix to their names. The longest common prefix of all of the instances in the subtree is the object identifier of the parent node of that subtree.

              Each MIB view consists of a set of view subtrees. Each view subtree in the MIB view is specified as being included or excluded. That is, the MIB view either includes or excludes all object instances contained in that subtree. In addition, a view mask is defined in order to reduce the amount of configuration inf...