[Docs] [txt|pdf]



[Note that this file is a concatenation of more than one RFC.]



Network Working Group                                      D. Harrington
Request for Comments: 3411                            Enterasys Networks
STD: 62                                                       R. Presuhn
Obsoletes: 2571                                       BMC Software, Inc.
Category: Standards Track                                      B. Wijnen
                                                     Lucent Technologies
                                                           December 2002


                     An Architecture for Describing
    Simple Network Management Protocol (SNMP) Management Frameworks

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes an architecture for describing Simple Network
   Management Protocol (SNMP) Management Frameworks.  The architecture
   is designed to be modular to allow the evolution of the SNMP protocol
   standards over time.  The major portions of the architecture are an
   SNMP engine containing a Message Processing Subsystem, a Security
   Subsystem and an Access Control Subsystem, and possibly multiple SNMP
   applications which provide specific functional processing of
   management data.  This document obsoletes RFC 2571.

Table of Contents

   1. Introduction ................................................    4
   1.1. Overview ..................................................    4
   1.2. SNMP ......................................................    5
   1.3. Goals of this Architecture ................................    6
   1.4. Security Requirements of this Architecture ................    6
   1.5. Design Decisions ..........................................    8
   2. Documentation Overview ......................................   10
   2.1. Document Roadmap ..........................................   11
   2.2. Applicability Statement ...................................   11





Harrington, et al.          Standards Track                     [Page 1]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


   2.3. Coexistence and Transition ................................   11
   2.4. Transport Mappings ........................................   12
   2.5. Message Processing ........................................   12
   2.6. Security ..................................................   12
   2.7. Access Control ............................................   13
   2.8. Protocol Operations .......................................   13
   2.9. Applications ..............................................   14
   2.10. Structure of Management Information ......................   15
   2.11. Textual Conventions ......................................   15
   2.12. Conformance Statements ...................................   15
   2.13. Management Information Base Modules ......................   15
   2.13.1. SNMP Instrumentation MIBs ..............................   15
   2.14. SNMP Framework Documents .................................   15
   3. Elements of the Architecture ................................   16
   3.1. The Naming of Entities ....................................   17
   3.1.1. SNMP engine .............................................   18
   3.1.1.1. snmpEngineID ..........................................   18
   3.1.1.2. Dispatcher ............................................   18
   3.1.1.3. Message Processing Subsystem ..........................   19
   3.1.1.3.1. Message Processing Model ............................   19
   3.1.1.4. Security Subsystem ....................................   20
   3.1.1.4.1. Security Model ......................................   20
   3.1.1.4.2. Security Protocol ...................................   20
   3.1.2. Access Control Subsystem ................................   21
   3.1.2.1. Access Control Model ..................................   21
   3.1.3. Applications ............................................   21
   3.1.3.1. SNMP Manager ..........................................   22
   3.1.3.2. SNMP Agent ............................................   23
   3.2. The Naming of Identities ..................................   25
   3.2.1. Principal ...............................................   25
   3.2.2. securityName ............................................   25
   3.2.3. Model-dependent security ID .............................   26
   3.3. The Naming of Management Information ......................   26
   3.3.1. An SNMP Context .........................................   28
   3.3.2. contextEngineID .........................................   28
   3.3.3. contextName .............................................   29
   3.3.4. scopedPDU ...............................................   29
   3.4. Other Constructs ..........................................   29
   3.4.1. maxSizeResponseScopedPDU ................................   29
   3.4.2. Local Configuration Datastore ...........................   29
   3.4.3. securityLevel ...........................................   29
   4. Abstract Service Interfaces .................................   30
   4.1. Dispatcher Primitives .....................................   30
   4.1.1. Generate Outgoing Request or Notification ...............   31
   4.1.2. Process Incoming Request or Notification PDU ............   31
   4.1.3. Generate Outgoing Response ..............................   32
   4.1.4. Process Incoming Response PDU ...........................   32
   4.1.5. Registering Responsibility for Handling SNMP PDUs .......   32



Harrington, et al.          Standards Track                     [Page 2]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


   4.2. Message Processing Subsystem Primitives ...................   33
   4.2.1. Prepare Outgoing SNMP Request or Notification Message ...   33
   4.2.2. Prepare an Outgoing SNMP Response Message ...............   34
   4.2.3. Prepare Data Elements from an Incoming SNMP Message .....   35
   4.3. Access Control Subsystem Primitives .......................   35
   4.4. Security Subsystem Primitives .............................   36
   4.4.1. Generate a Request or Notification Message ..............   36
   4.4.2. Process Incoming Message ................................   36
   4.4.3. Generate a Response Message .............................   37
   4.5. Common Primitives .........................................   37
   4.5.1. Release State Reference Information .....................   37
   4.6. Scenario Diagrams .........................................   38
   4.6.1. Command Generator or Notification Originator ............   38
   4.6.2. Scenario Diagram for a Command Responder Application ....   39
   5. Managed Object Definitions for SNMP Management Frameworks ...   40
   6. IANA Considerations .........................................   51
   6.1. Security Models ...........................................   51
   6.2. Message Processing Models .................................   51
   6.3. SnmpEngineID Formats ......................................   52
   7. Intellectual Property .......................................   52
   8. Acknowledgements ............................................   52
   9. Security Considerations .....................................   54
   10. References .................................................   54
   10.1. Normative References .....................................   54
   10.2. Informative References ...................................   56
   A. Guidelines for Model Designers ..............................   57
   A.1. Security Model Design Requirements ........................   57
   A.1.1. Threats .................................................   57
   A.1.2. Security Processing .....................................   58
   A.1.3. Validate the security-stamp in a received message .......   59
   A.1.4. Security MIBs ...........................................   59
   A.1.5. Cached Security Data ....................................   59
   A.2. Message Processing Model Design Requirements ..............   60
   A.2.1. Receiving an SNMP Message from the Network ..............   60
   A.2.2. Sending an SNMP Message to the Network ..................   60
   A.3. Application Design Requirements ...........................   61
   A.3.1. Applications that Initiate Messages .....................   61
   A.3.2. Applications that Receive Responses .....................   62
   A.3.3. Applications that Receive Asynchronous Messages .........   62
   A.3.4. Applications that Send Responses ........................   62
   A.4. Access Control Model Design Requirements ..................   63
   Editors' Addresses .............................................   63
   Full Copyright Statement .......................................   64








Harrington, et al.          Standards Track                     [Page 3]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


1.  Introduction

1.1.  Overview

   This document defines a vocabulary for describing SNMP Management
   Frameworks, and an architecture for describing the major portions of
   SNMP Management Frameworks.

   This document does not provide a general introduction to SNMP.  Other
   documents and books can provide a much better introduction to SNMP.
   Nor does this document provide a history of SNMP.  That also can be
   found in books and other documents.

   Section 1 describes the purpose, goals, and design decisions of this
   architecture.

   Section 2 describes various types of documents which define (elements
   of) SNMP Frameworks, and how they fit into this architecture.  It
   also provides a minimal road map to the documents which have
   previously defined SNMP frameworks.

   Section 3 details the vocabulary of this architecture and its pieces.
   This section is important for understanding the remaining sections,
   and for understanding documents which are written to fit within this
   architecture.

   Section 4 describes the primitives used for the abstract service
   interfaces between the various subsystems, models and applications
   within this architecture.

   Section 5 defines a collection of managed objects used to instrument
   SNMP entities within this architecture.

   Sections 6, 7, 8, 9, 10 and 11 are administrative in nature.

   Appendix A contains guidelines for designers of Models which are
   expected to fit within this architecture.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].










Harrington, et al.          Standards Track                     [Page 4]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


1.2.  SNMP

   An SNMP management system contains:

      -  several (potentially many) nodes, each with an SNMP entity
         containing command responder and notification originator
         applications, which have access to management instrumentation
         (traditionally called agents);

      -  at least one SNMP entity containing command generator and/or
         notification receiver applications (traditionally called a
         manager) and,

      -  a management protocol, used to convey management information
         between the SNMP entities.

   SNMP entities executing command generator and notification receiver
   applications 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.

   It is the purpose of this document to define an architecture which
   can evolve to realize effective management in a variety of
   configurations and environments.  The architecture has been designed
   to meet the needs of implementations of:

      -  minimal SNMP entities with command responder and/or
         notification originator applications (traditionally called SNMP
         agents),

      -  SNMP entities with proxy forwarder applications (traditionally
         called SNMP proxy agents),

      -  command line driven SNMP entities with command generator and/or
         notification receiver applications (traditionally called SNMP
         command line managers),

      -  SNMP entities with  command generator and/or notification
         receiver, plus command responder and/or notification originator
         applications (traditionally called SNMP mid-level managers or
         dual-role entities),

      -  SNMP entities with command generator and/or notification
         receiver and possibly other types of applications for managing
         a potentially very large number of managed nodes (traditionally
         called (network) management stations).





Harrington, et al.          Standards Track                     [Page 5]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


1.3.  Goals of this Architecture

   This architecture was driven by the following goals:

      -  Use existing materials as much as possible.  It is heavily
         based on previous work, informally known as SNMPv2u and
         SNMPv2*, based in turn on SNMPv2p.

      -  Address the need for secure SET support, which is considered
         the most important deficiency in SNMPv1 and SNMPv2c.

      -  Make it possible to move portions of the architecture forward
         in the standards track, even if consensus has not been reached
         on all pieces.

      -  Define an architecture that allows for longevity of the SNMP
         Frameworks that have been and will be defined.

      -  Keep SNMP as simple as possible.

      -  Make it relatively inexpensive to deploy a minimal conforming
         implementation.

      -  Make it possible to upgrade portions of SNMP as new approaches
         become available, without disrupting an entire SNMP framework.

      -  Make it possible to support features required in large
         networks, but make the expense of supporting a feature directly
         related to the support of the feature.

1.4.  Security Requirements of this Architecture

   Several of the classical threats to network protocols are applicable
   to the management problem and therefore would be applicable to any
   Security Model used in an SNMP Management Framework.  Other threats
   are not applicable to the management problem.  This section discusses
   principal threats, secondary threats, and threats which are of lesser
   importance.

   The principal threats against which any Security Model used within
   this architecture SHOULD provide protection are:

      Modification of Information
         The modification threat is the danger that some unauthorized
         entity may alter in-transit SNMP messages generated on behalf
         of an authorized principal in such a way as to effect
         unauthorized management operations, including falsifying the
         value of an object.



Harrington, et al.          Standards Track                     [Page 6]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


      Masquerade
         The masquerade threat is the danger that management operations
         not authorized for some principal may be attempted by assuming
         the identity of another principal that has the appropriate
         authorizations.

   Secondary threats against which any Security Model used within this
   architecture SHOULD provide protection are:

      Message Stream Modification
         The SNMP protocol is typically based upon a connectionless
         transport service which may operate over any subnetwork
         service.  The re-ordering, delay or replay of messages can and
         does occur through the natural operation of many such
         subnetwork services.  The message stream modification threat is
         the danger that messages may be maliciously re-ordered, delayed
         or replayed to an extent which is greater than can occur
         through the natural operation of a subnetwork service, in order
         to effect unauthorized management operations.

      Disclosure
         The disclosure threat is the danger of eavesdropping on the
         exchanges between SNMP engines.  Protecting against this threat
         may be required as a matter of local policy.

   There are at least two threats against which a Security Model within
   this architecture need not protect, since they are deemed to be of
   lesser importance in this context:

      Denial of Service
         A Security Model need not attempt to address the broad range of
         attacks by which service on behalf of authorized users is
         denied.  Indeed, such denial-of-service attacks are in many
         cases indistinguishable from the type of network failures with
         which any viable management protocol must cope as a matter of
         course.

      Traffic Analysis
         A Security Model need not attempt to address traffic analysis
         attacks.  Many traffic patterns are predictable - entities may
         be managed on a regular basis by a relatively small number of
         management stations - and therefore there is no significant
         advantage afforded by protecting against traffic analysis.








Harrington, et al.          Standards Track                     [Page 7]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


1.5.  Design Decisions

   Various design decisions were made in support of the goals of the
   architecture and the security requirements:

      - Architecture
         An architecture should be defined which identifies the
         conceptual boundaries between the documents.  Subsystems should
         be defined which describe the abstract services provided by
         specific portions of an SNMP framework.  Abstract service
         interfaces, as described by service primitives, define the
         abstract boundaries between documents, and the abstract
         services that are provided by the conceptual subsystems of an
         SNMP framework.

      - Self-contained Documents
         Elements of procedure plus the MIB objects which are needed for
         processing for a specific portion of an SNMP framework should
         be defined in the same document, and as much as possible,
         should not be referenced in other documents.  This allows
         pieces to be designed and documented as independent and self-
         contained parts, which is consistent with the general SNMP MIB
         module approach.  As portions of SNMP change over time, the
         documents describing other portions of SNMP are not directly
         impacted.  This modularity allows, for example, Security
         Models, authentication and privacy mechanisms, and message
         formats to be upgraded and supplemented as the need arises.
         The self-contained documents can move along the standards track
         on different time-lines.

         This modularity of specification is not meant to be interpreted
         as imposing any specific requirements on implementation.

      - Threats
         The Security Models in the Security Subsystem SHOULD protect
         against the principal and secondary threats: modification of
         information, masquerade, message stream modification and
         disclosure.  They do not need to protect against denial of
         service and traffic analysis.

      - Remote Configuration
         The Security and Access Control Subsystems add a whole new set
         of SNMP configuration parameters.  The Security Subsystem also
         requires frequent changes of secrets at the various SNMP
         entities.  To make this deployable in a large operational
         environment, these SNMP parameters must be remotely
         configurable.




Harrington, et al.          Standards Track                     [Page 8]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


      - Controlled Complexity
         It is recognized that producers of simple managed devices want
         to keep the resources used by SNMP to a minimum.  At the same
         time, there is a need for more complex configurations which can
         spend more resources for SNMP and thus provide more
         functionality.  The design tries to keep the competing
         requirements of these two environments in balance and allows
         the more complex environments to logically extend the simple
         environment.










































Harrington, et al.          Standards Track                     [Page 9]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


2.  Documentation Overview

   The following figure shows the set of documents that fit within the
   SNMP Architecture.

   +------------------------- Document Set ----------------------------+
   |                                                                   |
   | +----------+              +-----------------+  +----------------+ |
   | | Document |              | Applicability   |  | Coexistence    | |
   | | Roadmap  |              | Statement       |  | & Transition   | |
   | +----------+              +-----------------+  +----------------+ |
   |                                                                   |
   | +---------------------------------------------------------------+ |
   | | Message Handling                                              | |
   | | +----------------+  +-----------------+  +-----------------+  | |
   | | | Transport      |  | Message         |  | Security        |  | |
   | | | Mappings       |  | Processing and  |  |                 |  | |
   | | |                |  | Dispatcher      |  |                 |  | |
   | | +----------------+  +-----------------+  +-----------------+  | |
   | +---------------------------------------------------------------+ |
   |                                                                   |
   | +---------------------------------------------------------------+ |
   | | PDU Handling                                                  | |
   | | +----------------+  +-----------------+  +-----------------+  | |
   | | | Protocol       |  | Applications    |  | Access          |  | |
   | | | Operations     |  |                 |  | Control         |  | |
   | | +----------------+  +-----------------+  +-----------------+  | |
   | +---------------------------------------------------------------+ |
   |                                                                   |
   | +---------------------------------------------------------------+ |
   | | Information Model                                             | |
   | | +--------------+   +--------------+    +---------------+      | |
   | | | Structure of |   | Textual      |    | Conformance   |      | |
   | | | Management   |   | Conventions  |    | Statements    |      | |
   | | | Information  |   |              |    |               |      | |
   | | +--------------+   +--------------+    +---------------+      | |
   | +---------------------------------------------------------------+ |
   |                                                                   |
   | +---------------------------------------------------------------+ |
   | | MIB Modules written in various formats, e.g.:                 | |
   | | +----------------+ +----------------+                         | |
   | | | SMIv1 (STD 18) | | SMIv2 (STD 58) |                         | |
   | | | format         | | format         |                         | |
   | | +----------------+ +----------------+                         | |
   | +---------------------------------------------------------------+ |
   |                                                                   |
   +-------------------------------------------------------------------+




Harrington, et al.          Standards Track                    [Page 10]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


   Each of these documents may be replaced or supplemented.  This
   Architecture document specifically describes how new documents fit
   into the set of documents in the area of Message and PDU handling.

2.1.  Document Roadmap

   One or more documents may be written to describe how sets of
   documents taken together form specific Frameworks.  The configuration
   of document sets might change over time, so the "road map" should be
   maintained in a document separate from the standards documents
   themselves.

   An example of such a roadmap is "Introduction and Applicability
   Statements for the Internet-Standard Management Framework" [RFC3410].

2.2.  Applicability Statement

   SNMP is used in networks that vary widely in size and complexity, by
   organizations that vary widely in their requirements of management.
   Some models will be designed to address specific problems of
   management, such as message security.

   One or more documents may be written to describe the environments to
   which certain versions of SNMP or models within SNMP would be
   appropriately applied, and those to which a given model might be
   inappropriately applied.

2.3.  Coexistence and Transition

   The purpose of an evolutionary architecture is to permit new models
   to replace or supplement existing models.  The interactions between
   models could result in incompatibilities, security "holes", and other
   undesirable effects.

   The purpose of Coexistence documents is to detail recognized
   anomalies and to describe required and recommended behaviors for
   resolving the interactions between models within the architecture.

   Coexistence documents may be prepared separately from model
   definition documents, to describe and resolve interaction anomalies
   between a model definition and one or more other model definitions.

   Additionally, recommendations for transitions between models may also
   be described, either in a coexistence document or in a separate
   document.






Harrington, et al.          Standards Track                    [Page 11]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


   One such coexistence document is [RFC2576], "Coexistence between
   Version 1, Version 2, and Version 3 of the Internet-Standard Network
   Management Framework".

2.4.  Transport Mappings

   SNMP messages are sent over various transports.  It is the purpose of
   Transport Mapping documents to define how the mapping between SNMP
   and the transport is done.

2.5.  Message Processing

   A Message Processing Model document defines a message format, which
   is typically identified by a version field in an SNMP message header.
   The document may also define a MIB module for use in message
   processing and for instrumentation of version-specific interactions.

   An SNMP engine includes one or more Message Processing Models, and
   thus may support sending and receiving multiple versions of SNMP
   messages.

2.6.  Security

   Some environments require secure protocol interactions.  Security is
   normally applied at two different stages:

      -  in the transmission/receipt of messages, and

      -  in the processing of the contents of messages.

   For purposes of this document, "security" refers to message-level
   security; "access control" refers to the security applied to protocol
   operations.

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

   A security document describes a Security Model, the threats against
   which the model protects, the goals of the Security Model, the
   protocols which it uses to meet those goals, and it may define a MIB
   module to describe the data used during processing, and to allow the
   remote configuration of message-level security parameters, such as
   keys.

   An SNMP engine may support multiple Security Models concurrently.






Harrington, et al.          Standards Track                    [Page 12]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


2.7.  Access Control

   During processing, it may be required to control access to managed
   objects for operations.

   An Access Control Model defines mechanisms to determine whether
   access to a managed object should be allowed.  An Access Control
   Model may define a MIB module used during processing and to allow the
   remote configuration of access control policies.

2.8.  Protocol Operations

   SNMP messages encapsulate an SNMP Protocol Data Unit (PDU).  SNMP
   PDUs define the operations performed by the receiving SNMP engine.
   It is the purpose of a Protocol Operations document to define the
   operations of the protocol with respect to the processing of the
   PDUs.  Every PDU belongs to one or more of the PDU classes defined
   below:

      1) Read Class:

         The Read Class contains protocol operations that retrieve
         management information.  For example, [RFC3416] defines the
         following protocol operations for the Read Class: GetRequest-
         PDU, GetNextRequest-PDU, and GetBulkRequest-PDU.

      2) Write Class:

         The Write Class contains protocol operations which attempt to
         modify management information.  For example, [RFC3416] defines
         the following protocol operation for the Write Class:
         SetRequest-PDU.

      3) Response Class:

         The Response Class contains protocol operations which are sent
         in response to a previous request.  For example, [RFC3416]
         defines the following for the Response Class: Response-PDU,
         Report-PDU.

      4) Notification Class:

         The Notification Class contains protocol operations which send
         a notification to a notification receiver application.  For
         example, [RFC3416] defines the following operations for the
         Notification Class: Trapv2-PDU, InformRequest-PDU.





Harrington, et al.          Standards Track                    [Page 13]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


      5) Internal Class:

         The Internal Class contains protocol operations which are
         exchanged internally between SNMP engines.  For example,
         [RFC3416] defines the following operation for the Internal
         Class: Report-PDU.

   The preceding five classifications are based on the functional
   properties of a PDU.  It is also useful to classify PDUs based on
   whether a response is expected:

      6) Confirmed Class:

         The Confirmed Class contains all protocol operations which
         cause the receiving SNMP engine to send back a response.  For
         example, [RFC3416] defines the following operations for the
         Confirmed Class: GetRequest-PDU, GetNextRequest-PDU,
         GetBulkRequest-PDU, SetRequest-PDU, and InformRequest-PDU.

      7) Unconfirmed Class:

         The Unconfirmed Class contains all protocol operations which
         are not acknowledged.  For example, [RFC3416] defines the
         following operations for the Unconfirmed Class: Report-PDU,
         Trapv2-PDU, and GetResponse-PDU.

   An application document defines which Protocol Operations are
   supported by the application.

2.9.  Applications

   An SNMP entity normally includes a number of applications.
   Applications use the services of an SNMP engine to accomplish
   specific tasks.  They coordinate the processing of management
   information operations, and may use SNMP messages to communicate with
   other SNMP entities.

   An applications document describes the purpose of an application, the
   services required of the associated SNMP engine, and the protocol
   operations and informational model that the application uses to
   perform management operations.

   An application document defines which set of documents are used to
   specifically define the structure of management information, textual
   conventions, conformance requirements, and operations supported by
   the application.





Harrington, et al.          Standards Track                    [Page 14]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


2.10.  Structure of Management Information

   Management information is viewed as a collection of managed objects,
   residing in a virtual information store, termed the Management
   Information Base (MIB).  Collections of related objects are defined
   in MIB modules.

   It is the purpose of a Structure of Management Information document
   to establish the notation for defining objects, modules, and other
   elements of managed information.

2.11.  Textual Conventions

   When designing a MIB module, it is often useful to define new types
   similar to those defined in the SMI, but with more precise semantics,
   or which have special semantics associated with them.  These newly
   defined types are termed textual conventions, and may be defined in
   separate documents, or within a MIB module.

2.12.  Conformance Statements

   It may be useful to define the acceptable lower-bounds of
   implementation, along with the actual level of implementation
   achieved.  It is the purpose of the Conformance Statements document
   to define the notation used for these purposes.

2.13.  Management Information Base Modules

   MIB documents describe collections of managed objects which
   instrument some aspect of a managed node.

2.13.1.  SNMP Instrumentation MIBs

   An SNMP MIB document may define a collection of managed objects which
   instrument the SNMP protocol itself.  In addition, MIB modules may be
   defined within the documents which describe portions of the SNMP
   architecture, such as the documents for Message processing Models,
   Security Models, etc. for the purpose of instrumenting those Models,
   and for the purpose of allowing their remote configuration.

2.14.  SNMP Framework Documents

   This architecture is designed to allow an orderly evolution of
   portions of SNMP Frameworks.

   Throughout the rest of this document, the term "subsystem" refers to
   an abstract and incomplete specification of a portion of a Framework,
   that is further refined by a model specification.



Harrington, et al.          Standards Track                    [Page 15]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


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

   An "implementation" is an instantiation of a subsystem, conforming to
   one or more specific models.

   SNMP version 1 (SNMPv1), is the original Internet-Standard Network
   Management Framework, as described in RFCs 1155, 1157, and 1212.

   SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the
   SNMPv1 Framework.  It is described in STD 58, RFCs 2578, 2579, 2580,
   and STD 62, RFCs 3416, 3417, and 3418.  SNMPv2 has no message
   definition.

   The Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP
   Framework which supplements the SNMPv2 Framework, as described in
   [RFC1901].  It adds the SNMPv2c message format, which is similar to
   the SNMPv1 message format.

   SNMP version 3 (SNMPv3), is an extensible SNMP Framework which
   supplements the SNMPv2 Framework, by supporting the following:

      -  a new SNMP message format,

      -  Security for Messages,

      -  Access Control, and

      -  Remote configuration of SNMP parameters.

   Other SNMP Frameworks, i.e., other configurations of implemented
   subsystems, are expected to also be consistent with this
   architecture.

3.  Elements of the Architecture

   This section describes the various elements of the architecture and
   how they are named.  There are three kinds of naming:

      1) the naming of entities,

      2) the naming of identities, and

      3) the naming of management information.





Harrington, et al.          Standards Track                    [Page 16]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


   This architecture also defines some names for other constructs that
   are used in the documentation.

3.1.  The Naming of Entities

   An SNMP entity is an implementation of this architecture.  Each such
   SNMP entity consists of an SNMP engine and one or more associated
   applications.

   The following figure shows details about an SNMP entity and the
   components within it.

   +-------------------------------------------------------------------+
   |  SNMP entity                                                      |
   |                                                                   |
   |  +-------------------------------------------------------------+  |
   |  |  SNMP engine (identified by snmpEngineID)                   |  |
   |  |                                                             |  |
   |  |  +------------+ +------------+ +-----------+ +-----------+  |  |
   |  |  |            | |            | |           | |           |  |  |
   |  |  | Dispatcher | | Message    | | Security  | | Access    |  |  |
   |  |  |            | | Processing | | Subsystem | | Control   |  |  |
   |  |  |            | | Subsystem  | |           | | Subsystem |  |  |
   |  |  |            | |            | |           | |           |  |  |
   |  |  +------------+ +------------+ +-----------+ +-----------+  |  |
   |  |                                                             |  |
   |  +-------------------------------------------------------------+  |
   |                                                                   |
   |  +-------------------------------------------------------------+  |
   |  |  Application(s)                                             |  |
   |  |                                                             |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |  | Command     |  | Notification |  | Proxy        |        |  |
   |  |  | Generator   |  | Receiver     |  | Forwarder    |        |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |                                                             |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |  | Command     |  | Notification |  | Other        |        |  |
   |  |  | Responder   |  | Originator   |  |              |        |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |                                                             |  |
   |  +-------------------------------------------------------------+  |
   |                                                                   |
   +-------------------------------------------------------------------+







Harrington, et al.          Standards Track                    [Page 17]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


3.1.1.  SNMP engine

   An SNMP engine provides services for sending and receiving messages,
   authenticating and encrypting messages, and controlling access to
   managed objects.  There is a one-to-one association between an SNMP
   engine and the SNMP entity which contains it.

   The engine contains:

      1) a Dispatcher,

      2) a Message Processing Subsystem,

      3) a Security Subsystem, and

      4) an Access Control Subsystem.

3.1.1.1.  snmpEngineID

   Within an administrative domain, an snmpEngineID is the unique and
   unambiguous identifier of an SNMP engine.  Since there is a one-to-
   one association between SNMP engines and SNMP entities, it also
   uniquely and unambiguously identifies the SNMP entity within that
   administrative domain.  Note that it is possible for SNMP entities in
   different administrative domains to have the same value for
   snmpEngineID.  Federation of administrative domains may necessitate
   assignment of new values.

3.1.1.2.  Dispatcher

   There is only one Dispatcher in an SNMP engine.  It allows for
   concurrent support of multiple versions of SNMP messages in the SNMP
   engine.  It does so by:

      -  sending and receiving SNMP messages to/from the network,

      -  determining the version of an SNMP message and interacting with
         the corresponding Message Processing Model,

      -  providing an abstract interface to SNMP applications for
         delivery of a PDU to an application.

      -  providing an abstract interface for SNMP applications that
         allows them to send a PDU to a remote SNMP entity.







Harrington, et al.          Standards Track                    [Page 18]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


3.1.1.3.  Message Processing Subsystem

   The Message Processing Subsystem is responsible for preparing
   messages for sending, and extracting data from received messages.

   The Message Processing Subsystem potentially contains multiple
   Message Processing Models as shown in the next figure.

   * One or more Message Processing Models may be present.

   +------------------------------------------------------------------+
   |                                                                  |
   |  Message Processing Subsystem                                    |
   |                                                                  |
   |  +------------+  +------------+  +------------+  +------------+  |
   |  |          * |  |          * |  |          * |  |          * |  |
   |  | SNMPv3     |  | SNMPv1     |  | SNMPv2c    |  | Other      |  |
   |  | Message    |  | Message    |  | Message    |  | Message    |  |
   |  | Processing |  | Processing |  | Processing |  | Processing |  |
   |  | Model      |  | Model      |  | Model      |  | Model      |  |
   |  |            |  |            |  |            |  |            |  |
   |  +------------+  +------------+  +------------+  +------------+  |
   |                                                                  |
   +------------------------------------------------------------------+

3.1.1.3.1.  Message Processing Model

   Each Message Processing Model defines the format of a particular
   version of an SNMP message and coordinates the preparation and
   extraction of each such version-specific message format.





















Harrington, et al.          Standards Track                    [Page 19]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


3.1.1.4.  Security Subsystem

   The Security Subsystem provides security services such as the
   authentication and privacy of messages and potentially contains
   multiple Security Models as shown in the following figure

   * One or more Security Models may be present.

   +------------------------------------------------------------------+
   |                                                                  |
   |  Security Subsystem                                              |
   |                                                                  |
   |  +----------------+  +-----------------+  +-------------------+  |
   |  |              * |  |               * |  |                 * |  |
   |  | User-Based     |  | Other           |  | Other             |  |
   |  | Security       |  | Security        |  | Security          |  |
   |  | Model          |  | Model           |  | Model             |  |
   |  |                |  |                 |  |                   |  |
   |  +----------------+  +-----------------+  +-------------------+  |
   |                                                                  |
   +------------------------------------------------------------------+

3.1.1.4.1.  Security Model

   A Security Model specifies the threats against which it protects, the
   goals of its services, and the security protocols used to provide
   security services such as authentication and privacy.

3.1.1.4.2.  Security Protocol

   A Security Protocol specifies the mechanisms, procedures, and MIB
   objects used to provide a security service such as authentication or
   privacy.


















Harrington, et al.          Standards Track                    [Page 20]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


3.1.2.  Access Control Subsystem

   The Access Control Subsystem provides authorization services by means
   of one or more (*) Access Control Models.

   +------------------------------------------------------------------+
   |                                                                  |
   |  Access Control Subsystem                                        |
   |                                                                  |
   |  +---------------+   +-----------------+   +------------------+  |
   |  |             * |   |               * |   |                * |  |
   |  | View-Based    |   | Other           |   | Other            |  |
   |  | Access        |   | Access          |   | Access           |  |
   |  | Control       |   | Control         |   | Control          |  |
   |  | Model         |   | Model           |   | Model            |  |
   |  |               |   |                 |   |                  |  |
   |  +---------------+   +-----------------+   +------------------+  |
   |                                                                  |
   +------------------------------------------------------------------+

3.1.2.1.  Access Control Model

   An Access Control Model defines a particular access decision function
   in order to support decisions regarding access rights.

3.1.3.  Applications

   There are several types of applications, including:

      -  command generators, which monitor and manipulate management
         data,

      -  command responders, which provide access to management data,

      -  notification originators, which initiate asynchronous messages,

      -  notification receivers, which process asynchronous messages,

      and

      -  proxy forwarders, which forward messages between entities.

   These applications make use of the services provided by the SNMP
   engine.







Harrington, et al.          Standards Track                    [Page 21]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


3.1.3.1.  SNMP Manager

   An SNMP entity containing one or more command generator and/or
   notification receiver applications (along with their associated SNMP
   engine) has traditionally been called an SNMP manager.

                       (traditional SNMP manager)
   +-------------------------------------------------------------------+
   | +--------------+  +--------------+  +--------------+  SNMP entity |
   | | NOTIFICATION |  | NOTIFICATION |  |   COMMAND    |              |
   | |  ORIGINATOR  |  |   RECEIVER   |  |  GENERATOR   |              |
   | | applications |  | applications |  | applications |              |
   | +--------------+  +--------------+  +--------------+              |
   |         ^                ^                 ^                      |
   |         |                |                 |                      |
   |         v                v                 v                      |
   |         +-------+--------+-----------------+                      |
   |                 ^                                                 |
   |                 |     +---------------------+  +----------------+ |
   |                 |     | Message Processing  |  | Security       | |
   | Dispatcher      v     | Subsystem           |  | Subsystem      | |
   | +-------------------+ |     +------------+  |  |                | |
   | | PDU Dispatcher    | |  +->| v1MP     * |<--->| +------------+ | |
   | |                   | |  |  +------------+  |  | | Other      | | |
   | |                   | |  |  +------------+  |  | | Security   | | |
   | |                   | |  +->| v2cMP    * |<--->| | Model      | | |
   | | Message           | |  |  +------------+  |  | +------------+ | |
   | | Dispatcher  <--------->+                  |  |                | |
   | |                   | |  |  +------------+  |  | +------------+ | |
   | |                   | |  +->| v3MP     * |<--->| | User-based | | |
   | | Transport         | |  |  +------------+  |  | | Security   | | |
   | | Mapping           | |  |  +------------+  |  | | Model      | | |
   | | (e.g., RFC 3417)  | |  +->| otherMP  * |<--->| +------------+ | |
   | +-------------------+ |     +------------+  |  |                | |
   |          ^            +---------------------+  +----------------+ |
   |          |                                                        |
   |          v                                                        |
   +-------------------------------------------------------------------+
   +-----+ +-----+       +-------+
   | UDP | | IPX | . . . | other |
   +-----+ +-----+       +-------+
      ^       ^              ^
      |       |              |      * One or more models may be present.
      v       v              v
   +------------------------------+
   |           Network            |
   +------------------------------+




Harrington, et al.          Standards Track                    [Page 22]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


3.1.3.2.  SNMP Agent

   An SNMP entity containing one or more command responder and/or
   notification originator applications (along with their associated
   SNMP engine) has traditionally been called an SNMP agent.














































Harrington, et al.          Standards Track                    [Page 23]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


   * One or more models may be present.

   +------------------------------+
   |           Network            |
   +------------------------------+
      ^       ^              ^
      |       |              |
      v       v              v
   +-----+ +-----+       +-------+
   | UDP | | IPX | . . . | other |
   +-----+ +-----+       +-------+              (traditional SNMP agent)
   +-------------------------------------------------------------------+
   |              ^                                                    |
   |              |        +---------------------+  +----------------+ |
   |              |        | Message Processing  |  | Security       | |
   | Dispatcher   v        | Subsystem           |  | Subsystem      | |
   | +-------------------+ |     +------------+  |  |                | |
   | | Transport         | |  +->| v1MP     * |<--->| +------------+ | |
   | | Mapping           | |  |  +------------+  |  | | Other      | | |
   | | (e.g., RFC 3417)  | |  |  +------------+  |  | | Security   | | |
   | |                   | |  +->| v2cMP    * |<--->| | Model      | | |
   | | Message           | |  |  +------------+  |  | +------------+ | |
   | | Dispatcher  <--------->|  +------------+  |  | +------------+ | |
   | |                   | |  +->| v3MP     * |<--->| | User-based | | |
   | |                   | |  |  +------------+  |  | | Security   | | |
   | | PDU Dispatcher    | |  |  +------------+  |  | | Model      | | |
   | +-------------------+ |  +->| otherMP  * |<--->| +------------+ | |
   |              ^        |     +------------+  |  |                | |
   |              |        +---------------------+  +----------------+ |
   |              v                                                    |
   |      +-------+-------------------------+---------------+          |
   |      ^                                 ^               ^          |
   |      |                                 |               |          |
   |      v                                 v               v          |
   | +-------------+   +---------+   +--------------+  +-------------+ |
   | |   COMMAND   |   | ACCESS  |   | NOTIFICATION |  |    PROXY    | |
   | |  RESPONDER  |<->| CONTROL |<->|  ORIGINATOR  |  |  FORWARDER  | |
   | | application |   |         |   | applications |  | application | |
   | +-------------+   +---------+   +--------------+  +-------------+ |
   |      ^                                 ^                          |
   |      |                                 |                          |
   |      v                                 v                          |
   | +----------------------------------------------+                  |
   | |             MIB instrumentation              |      SNMP entity |
   +-------------------------------------------------------------------+






Harrington, et al.          Standards Track                    [Page 24]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


3.2.  The Naming of Identities

                            principal
                                ^
                                |
                                |
   +----------------------------|-------------+
   | SNMP engine                v             |
   |                    +--------------+      |
   |                    |              |      |
   |  +-----------------| securityName |---+  |
   |  | Security Model  |              |   |  |
   |  |                 +--------------+   |  |
   |  |                         ^          |  |
   |  |                         |          |  |
   |  |                         v          |  |
   |  |  +------------------------------+  |  |
   |  |  |                              |  |  |
   |  |  | Model                        |  |  |
   |  |  | Dependent                    |  |  |
   |  |  | Security ID                  |  |  |
   |  |  |                              |  |  |
   |  |  +------------------------------+  |  |
   |  |                         ^          |  |
   |  |                         |          |  |
   |  +-------------------------|----------+  |
   |                            |             |
   |                            |             |
   +----------------------------|-------------+
                                |
                                v
                             network

3.2.1.  Principal

   A principal is the "who" on whose behalf services are provided or
   processing takes place.

   A principal can be, among other things, an individual acting in a
   particular role; a set of individuals, with each acting in a
   particular role; an application or a set of applications; and
   combinations thereof.

3.2.2.  securityName

   A securityName is a human readable string representing a principal.
   It has a model-independent format, and can be used outside a
   particular Security Model.



Harrington, et al.          Standards Track                    [Page 25]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


3.2.3.  Model-dependent security ID

   A model-dependent security ID is the model-specific representation of
   a securityName within a particular Security Model.

   Model-dependent security IDs may or may not be human readable, and
   have a model-dependent syntax.  Examples include community names, and
   user names.

   The transformation of model-dependent security IDs into securityNames
   and vice versa is the responsibility of the relevant Security Model.

3.3.  The Naming of Management Information

   Management information resides at an SNMP entity where a Command
   Responder Application has local access to potentially multiple
   contexts.  This application uses a contextEngineID equal to the
   snmpEngineID of its associated SNMP engine.

































Harrington, et al.          Standards Track                    [Page 26]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


   +-----------------------------------------------------------------+
   |  SNMP entity (identified by snmpEngineID, for example:          |
   |  '800002b804616263'H (enterpise 696, string "abc")              |
   |                                                                 |
   |  +------------------------------------------------------------+ |
   |  | SNMP engine (identified by snmpEngineID)                   | |
   |  |                                                            | |
   |  | +-------------+ +------------+ +-----------+ +-----------+ | |
   |  | |             | |            | |           | |           | | |
   |  | | Dispatcher  | | Message    | | Security  | | Access    | | |
   |  | |             | | Processing | | Subsystem | | Control   | | |
   |  | |             | | Subsystem  | |           | | Subsystem | | |
   |  | |             | |            | |           | |           | | |
   |  | +-------------+ +------------+ +-----------+ +-----------+ | |
   |  |                                                            | |
   |  +------------------------------------------------------------+ |
   |                                                                 |
   |  +------------------------------------------------------------+ |
   |  |  Command Responder Application                             | |
   |  |  (contextEngineID, example: '800002b804616263'H)           | |
   |  |                                                            | |
   |  |  example contextNames:                                     | |
   |  |                                                            | |
   |  |  "bridge1"          "bridge2"            "" (default)      | |
   |  |  ---------          ---------            ------------      | |
   |  |      |                  |                   |              | |
   |  +------|------------------|-------------------|--------------+ |
   |         |                  |                   |                |
   |  +------|------------------|-------------------|--------------+ |
   |  |  MIB | instrumentation  |                   |              | |
   |  |  +---v------------+ +---v------------+ +----v-----------+  | |
   |  |  | context        | | context        | | context        |  | |
   |  |  |                | |                | |                |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  | | bridge MIB | | | | bridge MIB | | | | some  MIB  | |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   |  |  |                | |                | | +------------+ |  | |
   |  |  |                | |                | | | other MIB  | |  | |
   |  |  |                | |                | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   +-----------------------------------------------------------------+









Harrington, et al.          Standards Track                    [Page 27]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


3.3.1.  An SNMP Context

   An SNMP context, or just "context" for short, is a collection of
   management information accessible by an SNMP entity.  An item of
   management information may exist in more than one context.  An SNMP
   entity potentially has access to many contexts.

   Typically, there are many instances of each managed object type
   within a management domain.  For simplicity, the method for
   identifying instances specified by the MIB module does not allow each
   instance to be distinguished amongst the set of all instances within
   a management domain; rather, it allows each instance to be identified
   only within some scope or "context", where there are multiple such
   contexts within the management domain.  Often, a context is a
   physical device, or perhaps, a logical device, although a context can
   also encompass multiple devices, or a subset of a single device, or
   even a subset of multiple devices, but a context is always defined as
   a subset of a single SNMP entity.  Thus, in order to identify an
   individual item of management information within the management
   domain, its contextName and contextEngineID must be identified in
   addition to its object type and its instance.

   For example, the managed object type ifDescr [RFC2863], is defined as
   the description of a network interface.  To identify the description
   of device-X's first network interface, four pieces of information are
   needed: the snmpEngineID of the SNMP entity which provides access to
   the management information at device-X, the contextName (device-X),
   the managed object type (ifDescr), and the instance ("1").

   Each context has (at least) one unique identification within the
   management domain.  The same item of management information can exist
   in multiple contexts.  An item of management information may have
   multiple unique identifications.  This occurs when an item of
   management information exists in multiple contexts, and this also
   occurs when a context has multiple unique identifications.

   The combination of a contextEngineID and a contextName unambiguously
   identifies a context within an administrative domain; note that there
   may be multiple unique combinations of contextEngineID and
   contextName that unambiguously identify the same context.

3.3.2.  contextEngineID

   Within an administrative domain, a contextEngineID uniquely
   identifies an SNMP entity that may realize an instance of a context
   with a particular contextName.





Harrington, et al.          Standards Track                    [Page 28]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


3.3.3.  contextName

   A contextName is used to name a context.  Each contextName MUST be
   unique within an SNMP entity.

3.3.4.  scopedPDU

   A scopedPDU is a block of data containing a contextEngineID, a
   contextName, and a PDU.

   The PDU is an SNMP Protocol Data Unit containing information named in
   the context which is unambiguously identified within an
   administrative domain by the combination of the contextEngineID and
   the contextName.  See, for example, RFC 3416 for more information
   about SNMP PDUs.

3.4.  Other Constructs

3.4.1.  maxSizeResponseScopedPDU

   The maxSizeResponseScopedPDU is the maximum size of a scopedPDU that
   a PDU's sender would be willing to accept.  Note that the size of a
   scopedPDU does not include the size of the SNMP message header.

3.4.2.  Local Configuration Datastore

   The subsystems, models, and applications within an SNMP entity may
   need to retain their own sets of configuration information.

   Portions of the configuration information may be accessible as
   managed objects.

   The collection of these sets of information is referred to as an
   entity's Local Configuration Datastore (LCD).

3.4.3.  securityLevel

   This architecture recognizes three levels of security:

      -  without authentication and without privacy (noAuthNoPriv)

      -  with authentication but without privacy (authNoPriv)

      -  with authentication and with privacy (authPriv)







Harrington, et al.          Standards Track                    [Page 29]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


   These three values are ordered such that noAuthNoPriv is less than
   authNoPriv and authNoPriv is less than authPriv.

   Every message has an associated securityLevel.  All Subsystems
   (Message Processing, Security, Access Control) and applications are
   REQUIRED to either supply a value of securityLevel or to abide by the
   supplied value of securityLevel while processing the message and its
   contents.

4.  Abstract Service Interfaces

   Abstract service interfaces have been defined to describe the
   conceptual interfaces between the various subsystems within an SNMP
   entity.  The abstract service interfaces are intended to help clarify
   the externally observable behavior of SNMP entities, and are not
   intended to constrain the structure or organization of
   implementations in any way.  Most specifically, they should not be
   interpreted as APIs or as requirements statements for APIs.

   These abstract service interfaces are defined by a set of primitives
   that define the services provided and the abstract data elements that
   are to be passed when the services are invoked.  This section lists
   the primitives that have been defined for the various subsystems.

4.1.  Dispatcher Primitives

   The Dispatcher typically provides services to the SNMP applications
   via its PDU Dispatcher.  This section describes the primitives
   provided by the PDU Dispatcher.






















Harrington, et al.          Standards Track                    [Page 30]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


4.1.1.  Generate Outgoing Request or Notification

   The PDU Dispatcher provides the following primitive for an
   application to send an SNMP Request or Notification to another SNMP
   entity:

   statusInformation =              -- sendPduHandle if success
                                    -- errorIndication if failure
     sendPdu(
     IN   transportDomain           -- transport domain to be used
     IN   transportAddress          -- transport address to be used
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel             -- Security Model to use
     IN   securityName              -- on behalf of this principal
     IN   securityLevel             -- Level of Security requested
     IN   contextEngineID           -- data from/at this entity
     IN   contextName               -- data from/in this context
     IN   pduVersion                -- the version of the PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   expectResponse            -- TRUE or FALSE
          )

4.1.2.  Process Incoming Request or Notification PDU

   The PDU Dispatcher provides the following primitive to pass an
   incoming SNMP PDU to an application:

   processPdu(                      -- process Request/Notification PDU
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel             -- Security Model in use
     IN   securityName              -- on behalf of this principal
     IN   securityLevel             -- Level of Security
     IN   contextEngineID           -- data from/at this SNMP entity
     IN   contextName               -- data from/in this context
     IN   pduVersion                -- the version of the PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   maxSizeResponseScopedPDU  -- maximum size of the Response PDU
     IN   stateReference            -- reference to state information
          )                         -- needed when sending a response












Harrington, et al.          Standards Track                    [Page 31]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


4.1.3.  Generate Outgoing Response

   The PDU Dispatcher provides the following primitive for an
   application to return an SNMP Response PDU to the PDU Dispatcher:

   result =                         -- SUCCESS or FAILURE
   returnResponsePdu(
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel             -- Security Model in use
     IN   securityName              -- on behalf of this principal
     IN   securityLevel             -- same as on incoming request
     IN   contextEngineID           -- data from/at this SNMP entity
     IN   contextName               -- data from/in this context
     IN   pduVersion                -- the version of the PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   maxSizeResponseScopedPDU  -- maximum size sender can accept
     IN   stateReference            -- reference to state information
                                    -- as presented with the request
     IN   statusInformation         -- success or errorIndication
          )                         -- error counter OID/value if error

4.1.4.  Process Incoming Response PDU

   The PDU Dispatcher provides the following primitive to pass an
   incoming SNMP Response PDU to an application:

   processResponsePdu(              -- process Response PDU
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel             -- Security Model in use
     IN   securityName              -- on behalf of this principal
     IN   securityLevel             -- Level of Security
     IN   contextEngineID           -- data from/at this SNMP entity
     IN   contextName               -- data from/in this context
     IN   pduVersion                -- the version of the PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   statusInformation         -- success or errorIndication
     IN   sendPduHandle             -- handle from sendPdu
          )

4.1.5.  Registering Responsibility for Handling SNMP PDUs

   Applications can register/unregister responsibility for a specific
   contextEngineID, for specific pduTypes, with the PDU Dispatcher
   according to the following primitives.  The list of particular
   pduTypes that an application can register for is determined by the
   Message Processing Model(s) supported by the SNMP entity that
   contains the PDU Dispatcher.




Harrington, et al.          Standards Track                    [Page 32]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


   statusInformation =            -- success or errorIndication
     registerContextEngineID(
     IN   contextEngineID         -- take responsibility for this one
     IN   pduType                 -- the pduType(s) to be registered
          )

   unregisterContextEngineID(
     IN   contextEngineID         -- give up responsibility for this one
     IN   pduType                 -- the pduType(s) to be unregistered
          )

   Note that realizations of the registerContextEngineID and
   unregisterContextEngineID abstract service interfaces may provide
   implementation-specific ways for applications to register/deregister
   responsibility for all possible values of the contextEngineID or
   pduType parameters.

4.2.  Message Processing Subsystem Primitives

   The Dispatcher interacts with a Message Processing Model to process a
   specific version of an SNMP Message.  This section describes the
   primitives provided by the Message Processing Subsystem.

4.2.1.  Prepare Outgoing SNMP Request or Notification Message

   The Message Processing Subsystem provides this service primitive for
   preparing an outgoing SNMP Request or Notification Message:

   statusInformation =              -- success or errorIndication
     prepareOutgoingMessage(
     IN   transportDomain           -- transport domain to be used
     IN   transportAddress          -- transport address to be used
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel             -- Security Model to use
     IN   securityName              -- on behalf of this principal
     IN   securityLevel             -- Level of Security requested
     IN   contextEngineID           -- data from/at this entity
     IN   contextName               -- data from/in this context
     IN   pduVersion                -- the version of the PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   expectResponse            -- TRUE or FALSE
     IN   sendPduHandle             -- the handle for matching
                                    -- incoming responses
     OUT  destTransportDomain       -- destination transport domain
     OUT  destTransportAddress      -- destination transport address
     OUT  outgoingMessage           -- the message to send
     OUT  outgoingMessageLength     -- its length
          )



Harrington, et al.          Standards Track                    [Page 33]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


4.2.2.  Prepare an Outgoing SNMP Response Message

   The Message Processing Subsystem provides this service primitive for
   preparing an outgoing SNMP Response Message:

   result =                         -- SUCCESS or FAILURE
     prepareResponseMessage(
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel             -- same as on incoming request
     IN   securityName              -- same as on incoming request
     IN   securityLevel             -- same as on incoming request
     IN   contextEngineID           -- data from/at this SNMP entity
     IN   contextName               -- data from/in this context
     IN   pduVersion                -- the version of the PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   maxSizeResponseScopedPDU  -- maximum size able to accept
     IN   stateReference            -- reference to state information
                                    -- as presented with the request
     IN   statusInformation         -- success or errorIndication
                                    -- error counter OID/value if error
     OUT  destTransportDomain       -- destination transport domain
     OUT  destTransportAddress      -- destination transport address
     OUT  outgoingMessage           -- the message to send
     OUT  outgoingMessageLength     -- its length
          )


























Harrington, et al.          Standards Track                    [Page 34]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


4.2.3.  Prepare Data Elements from an Incoming SNMP Message

   The Message Processing Subsystem provides this service primitive for
   preparing the abstract data elements from an incoming SNMP message:

   result =                         -- SUCCESS or errorIndication
     prepareDataElements(
     IN   transportDomain           -- origin transport domain
     IN   transportAddress          -- origin transport address
     IN   wholeMsg                  -- as received from the network
     IN   wholeMsgLength            -- as received from the network
     OUT  messageProcessingModel    -- typically, SNMP version
     OUT  securityModel             -- Security Model to use
     OUT  securityName              -- on behalf of this principal
     OUT  securityLevel             -- Level of Security requested
     OUT  contextEngineID           -- data from/at this entity
     OUT  contextName               -- data from/in this context
     OUT  pduVersion                -- the version of the PDU
     OUT  PDU                       -- SNMP Protocol Data Unit
     OUT  pduType                   -- SNMP PDU type
     OUT  sendPduHandle             -- handle for matched request
     OUT  maxSizeResponseScopedPDU  -- maximum size sender can accept
     OUT  statusInformation         -- success or errorIndication
                                    -- error counter OID/value if error
     OUT  stateReference            -- reference to state information
                                    -- to be used for possible Response
          )

4.3.  Access Control Subsystem Primitives

   Applications are the typical clients of the service(s) of the Access
   Control Subsystem.

   The following primitive is provided by the Access Control Subsystem
   to check if access is allowed:

   statusInformation =              -- success or errorIndication
     isAccessAllowed(
     IN   securityModel             -- Security Model in use
     IN   securityName              -- principal who wants to access
     IN   securityLevel             -- Level of Security
     IN   viewType                  -- read, write, or notify view
     IN   contextName               -- context containing variableName
     IN   variableName              -- OID for the managed object
          )






Harrington, et al.          Standards Track                    [Page 35]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


4.4.  Security Subsystem Primitives

   The Message Processing Subsystem is the typical client of the
   services of the Security Subsystem.

4.4.1.  Generate a Request or Notification Message

   The Security Subsystem provides the following primitive to generate a
   Request or Notification message:

   statusInformation =
     generateRequestMsg(
     IN   messageProcessingModel    -- typically, SNMP version
     IN   globalData                -- message header, admin data
     IN   maxMessageSize            -- of the sending SNMP entity
     IN   securityModel             -- for the outgoing message
     IN   securityEngineID          -- authoritative SNMP entity
     IN   securityName              -- on behalf of this principal
     IN   securityLevel             -- Level of Security requested
     IN   scopedPDU                 -- message (plaintext) payload
     OUT  securityParameters        -- filled in by Security Module
     OUT  wholeMsg                  -- complete generated message
     OUT  wholeMsgLength            -- length of the generated message
          )

4.4.2.  Process Incoming Message

   The Security Subsystem provides the following primitive to process an
   incoming message:

   statusInformation =              -- errorIndication or success
                                    -- error counter OID/value if error
     processIncomingMsg(
     IN   messageProcessingModel    -- typically, SNMP version
     IN   maxMessageSize            -- of the sending SNMP entity
     IN   securityParameters        -- for the received message
     IN   securityModel             -- for the received message
     IN   securityLevel             -- Level of Security
     IN   wholeMsg                  -- as received on the wire
     IN   wholeMsgLength            -- length as received on the wire
     OUT  securityEngineID          -- authoritative SNMP entity
     OUT  securityName              -- identification of the principal
     OUT  scopedPDU,                -- message (plaintext) payload
     OUT  maxSizeResponseScopedPDU  -- maximum size sender can handle
     OUT  securityStateReference    -- reference to security state
          )                         -- information, needed for response





Harrington, et al.          Standards Track                    [Page 36]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


4.4.3.  Generate a Response Message

   The Security Subsystem provides the following primitive to generate a
   Response message:

   statusInformation =
     generateResponseMsg(
     IN   messageProcessingModel    -- typically, SNMP version
     IN   globalData                -- message header, admin data
     IN   maxMessageSize            -- of the sending SNMP entity
     IN   securityModel             -- for the outgoing message
     IN   securityEngineID          -- authoritative SNMP entity
     IN   securityName              -- on behalf of this principal
     IN   securityLevel             -- for the outgoing message
     IN   scopedPDU                 -- message (plaintext) payload
     IN   securityStateReference    -- reference to security state
                                    -- information from original request
     OUT  securityParameters        -- filled in by Security Module
     OUT  wholeMsg                  -- complete generated message
     OUT  wholeMsgLength            -- length of the generated message
          )

4.5.  Common Primitives

   These primitive(s) are provided by multiple Subsystems.

4.5.1.  Release State Reference Information

   All Subsystems which pass stateReference information also provide a
   primitive to release the memory that holds the referenced state
   information:

   stateRelease(
     IN   stateReference       -- handle of reference to be released
          )
















Harrington, et al.          Standards Track                    [Page 37]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


4.6.  Scenario Diagrams

4.6.1.  Command Generator or Notification Originator

   This diagram shows how a Command Generator or Notification Originator
   application requests that a PDU be sent, and how the response is
   returned (asynchronously) to that application.

   Command           Dispatcher               Message           Security
   Generator            |                     Processing           Model
   |                    |                     Model                    |
   |      sendPdu       |                        |                     |
   |------------------->|                        |                     |
   |                    | prepareOutgoingMessage |                     |
   :                    |----------------------->|                     |
   :                    |                        | generateRequestMsg  |
   :                    |                        |-------------------->|
   :                    |                        |                     |
   :                    |                        |<--------------------|
   :                    |                        |                     |
   :                    |<-----------------------|                     |
   :                    |                        |                     |
   :                    |------------------+     |                     |
   :                    | Send SNMP        |     |                     |
   :                    | Request Message  |     |                     |
   :                    | to Network       |     |                     |
   :                    |                  v     |                     |
   :                    :                  :     :                     :
   :                    :                  :     :                     :
   :                    :                  :     :                     :
   :                    |                  |     |                     |
   :                    | Receive SNMP     |     |                     |
   :                    | Response Message |     |                     |
   :                    | from Network     |     |                     |
   :                    |<-----------------+     |                     |
   :                    |                        |                     |
   :                    |   prepareDataElements  |                     |
   :                    |----------------------->|                     |
   :                    |                        | processIncomingMsg  |
   :                    |                        |-------------------->|
   :                    |                        |                     |
   :                    |                        |<--------------------|
   :                    |                        |                     |
   :                    |<-----------------------|                     |
   | processResponsePdu |                        |                     |
   |<-------------------|                        |                     |
   |                    |                        |                     |




Harrington, et al.          Standards Track                    [Page 38]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


4.6.2.  Scenario Diagram for a Command Responder Application

   This diagram shows how a Command Responder or Notification Receiver
   application registers for handling a pduType, how a PDU is dispatched
   to the application after an SNMP message is received, and how the
   Response is (asynchronously) send back to the network.

   Command               Dispatcher            Message          Security
   Responder                 |                 Processing          Model
   |                         |                 Model                   |
   |                         |                    |                    |
   | registerContextEngineID |                    |                    |
   |------------------------>|                    |                    |
   |<------------------------|              |     |                    |
   |                         | Receive SNMP |     |                    |
   :                         | Message      |     |                    |
   :                         | from Network |     |                    |
   :                         |<-------------+     |                    |
   :                         |                    |                    |
   :                         |prepareDataElements |                    |
   :                         |------------------->|                    |
   :                         |                    | processIncomingMsg |
   :                         |                    |------------------->|
   :                         |                    |                    |
   :                         |                    |<-------------------|
   :                         |                    |                    |
   :                         |<-------------------|                    |
   |     processPdu          |                    |                    |
   |<------------------------|                    |                    |
   |                         |                    |                    |
   :                         :                    :                    :
   :                         :                    :                    :
   |    returnResponsePdu    |                    |                    |
   |------------------------>|                    |                    |
   :                         | prepareResponseMsg |                    |
   :                         |------------------->|                    |
   :                         |                    |generateResponseMsg |
   :                         |                    |------------------->|
   :                         |                    |                    |
   :                         |                    |<-------------------|
   :                         |                    |                    |
   :                         |<-------------------|                    |
   :                         |                    |                    |
   :                         |--------------+     |                    |
   :                         | Send SNMP    |     |                    |
   :                         | Message      |     |                    |
   :                         | to Network   |     |                    |
   :                         |              v     |                    |



Harrington, et al.          Standards Track                    [Page 39]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


5.  Managed Object Definitions for SNMP Management Frameworks

SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE,
    OBJECT-IDENTITY,
    snmpModules                           FROM SNMPv2-SMI
    TEXTUAL-CONVENTION                    FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF;

snmpFrameworkMIB MODULE-IDENTITY
    LAST-UPDATED "200210140000Z"
    ORGANIZATION "SNMPv3 Working Group"
    CONTACT-INFO "WG-EMail:   snmpv3@lists.tislabs.com
                  Subscribe:  snmpv3-request@lists.tislabs.com

                  Co-Chair:   Russ Mundy
                              Network Associates Laboratories
                  postal:     15204 Omega Drive, Suite 300
                              Rockville, MD 20850-4601
                              USA
                  EMail:      mundy@tislabs.com
                  phone:      +1 301-947-7107

                  Co-Chair &
                  Co-editor:  David Harrington
                              Enterasys Networks
                  postal:     35 Industrial Way
                              P. O. Box 5005
                              Rochester, New Hampshire 03866-5005
                              USA
                  EMail:      dbh@enterasys.com
                  phone:      +1 603-337-2614

                  Co-editor:  Randy Presuhn
                              BMC Software, Inc.
                  postal:     2141 North First Street
                              San Jose, California 95131
                              USA
                  EMail:      randy_presuhn@bmc.com
                  phone:      +1 408-546-1006

                  Co-editor:  Bert Wijnen
                              Lucent Technologies
                  postal:     Schagen 33
                              3461 GL Linschoten
                              Netherlands



Harrington, et al.          Standards Track                    [Page 40]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


                  EMail:      bwijnen@lucent.com
                  phone:      +31 348-680-485
                    "
       DESCRIPTION  "The SNMP Management Architecture MIB

                     Copyright (C) The Internet Society (2002). This
                     version of this MIB module is part of RFC 3411;
                     see the RFC itself for full legal notices.
                    "

       REVISION     "200210140000Z"         -- 14 October 2002
       DESCRIPTION  "Changes in this revision:
                     - Updated various administrative information.
                     - Corrected some typos.
                     - Corrected typo in description of SnmpEngineID
                       that led to range overlap for 127.
                     - Changed '255a' to '255t' in definition of
                       SnmpAdminString to align with current SMI.
                     - Reworded 'reserved' for value zero in
                       DESCRIPTION of SnmpSecurityModel.
                     - The algorithm for allocating security models
                       should give 256 per enterprise block, rather
                       than 255.
                     - The example engine ID of 'abcd' is not
                       legal. Replaced with '800002b804616263'H based
                       on example enterprise 696, string 'abc'.
                     - Added clarification that engineID should
                       persist across re-initializations.
                     This revision published as RFC 3411.
                    "
       REVISION     "199901190000Z"         -- 19 January 1999
       DESCRIPTION  "Updated editors' addresses, fixed typos.
                     Published as RFC 2571.
                    "
       REVISION     "199711200000Z"         -- 20 November 1997
       DESCRIPTION  "The initial version, published in RFC 2271.
                    "
       ::= { snmpModules 10 }

   -- Textual Conventions used in the SNMP Management Architecture ***

SnmpEngineID ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "An SNMP engine's administratively-unique identifier.
                 Objects of this type are for identification, not for
                 addressing, even though it is possible that an
                 address may have been used in the generation of
                 a specific value.



Harrington, et al.          Standards Track                    [Page 41]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


                 The value for this object may not be all zeros or
                 all 'ff'H or the empty (zero length) string.

                 The initial value for this object may be configured
                 via an operator console entry or via an algorithmic
                 function.  In the latter case, the following
                 example algorithm is recommended.

                 In cases where there are multiple engines on the
                 same system, the use of this algorithm is NOT
                 appropriate, as it would result in all of those
                 engines ending up with the same ID value.

                 1) The very first bit is used to indicate how the
                    rest of the data is composed.

                    0 - as defined by enterprise using former methods
                        that existed before SNMPv3. See item 2 below.

                    1 - as defined by this architecture, see item 3
                        below.

                    Note that this allows existing uses of the
                    engineID (also known as AgentID [RFC1910]) to
                    co-exist with any new uses.

                 2) The snmpEngineID has a length of 12 octets.

                    The first four octets are set to the binary
                    equivalent of the agent's SNMP management
                    private enterprise number as assigned by the
                    Internet Assigned Numbers Authority (IANA).
                    For example, if Acme Networks has been assigned
                    { enterprises 696 }, the first four octets would
                    be assigned '000002b8'H.

                    The remaining eight octets are determined via
                    one or more enterprise-specific methods. Such
                    methods must be designed so as to maximize the
                    possibility that the value of this object will
                    be unique in the agent's administrative domain.
                    For example, it may be the IP address of the SNMP
                    entity, or the MAC address of one of the
                    interfaces, with each address suitably padded
                    with random octets.  If multiple methods are
                    defined, then it is recommended that the first
                    octet indicate the method being used and the
                    remaining octets be a function of the method.



Harrington, et al.          Standards Track                    [Page 42]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


                 3) The length of the octet string varies.

                    The first four octets are set to the binary
                    equivalent of the agent's SNMP management
                    private enterprise number as assigned by the
                    Internet Assigned Numbers Authority (IANA).
                    For example, if Acme Networks has been assigned
                    { enterprises 696 }, the first four octets would
                    be assigned '000002b8'H.

                    The very first bit is set to 1. For example, the
                    above value for Acme Networks now changes to be
                    '800002b8'H.

                    The fifth octet indicates how the rest (6th and
                    following octets) are formatted. The values for
                    the fifth octet are:

                      0     - reserved, unused.

                      1     - IPv4 address (4 octets)
                              lowest non-special IP address

                      2     - IPv6 address (16 octets)
                              lowest non-special IP address

                      3     - MAC address (6 octets)
                              lowest IEEE MAC address, canonical
                              order

                      4     - Text, administratively assigned
                              Maximum remaining length 27

                      5     - Octets, administratively assigned
                              Maximum remaining length 27

                      6-127 - reserved, unused

                    128-255 - as defined by the enterprise
                              Maximum remaining length 27
                "
    SYNTAX       OCTET STRING (SIZE(5..32))









Harrington, et al.          Standards Track                    [Page 43]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


SnmpSecurityModel ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "An identifier that uniquely identifies a
                 Security Model of the Security Subsystem within
                 this SNMP Management Architecture.

                 The values for securityModel are allocated as
                 follows:

                 - The zero value does not identify any particular
                   security model.

                 - Values between 1 and 255, inclusive, are reserved
                   for standards-track Security Models and are
                   managed by the Internet Assigned Numbers Authority
                   (IANA).
                 - Values greater than 255 are allocated to
                   enterprise-specific Security Models.  An
                   enterprise-specific securityModel value is defined
                   to be:

                   enterpriseID * 256 + security model within
                   enterprise

                   For example, the fourth Security Model defined by
                   the enterprise whose enterpriseID is 1 would be
                   259.

                 This scheme for allocation of securityModel
                 values allows for a maximum of 255 standards-
                 based Security Models, and for a maximum of
                 256 Security Models per enterprise.

                 It is believed that the assignment of new
                 securityModel values will be rare in practice
                 because the larger the number of simultaneously
                 utilized Security Models, the larger the
                 chance that interoperability will suffer.
                 Consequently, it is believed that such a range
                 will be sufficient.  In the unlikely event that
                 the standards committee finds this number to be
                 insufficient over time, an enterprise number
                 can be allocated to obtain an additional 256
                 possible values.

                 Note that the most significant bit must be zero;
                 hence, there are 23 bits allocated for various
                 organizations to design and define non-standard



Harrington, et al.          Standards Track                    [Page 44]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


                 securityModels.  This limits the ability to
                 define new proprietary implementations of Security
                 Models to the first 8,388,608 enterprises.

                 It is worthwhile to note that, in its encoded
                 form, the securityModel value will normally
                 require only a single byte since, in practice,
                 the leftmost bits will be zero for most messages
                 and sign extension is suppressed by the encoding
                 rules.

                 As of this writing, there are several values
                 of securityModel defined for use with SNMP or
                 reserved for use with supporting MIB objects.
                 They are as follows:

                     0  reserved for 'any'
                     1  reserved for SNMPv1
                     2  reserved for SNMPv2c
                     3  User-Based Security Model (USM)
                "
    SYNTAX       INTEGER(0 .. 2147483647)


SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "An identifier that uniquely identifies a Message
                 Processing Model of the Message Processing
                 Subsystem within this SNMP Management Architecture.

                 The values for messageProcessingModel are
                 allocated as follows:

                 - Values between 0 and 255, inclusive, are
                   reserved for standards-track Message Processing
                   Models and are managed by the Internet Assigned
                   Numbers Authority (IANA).

                 - Values greater than 255 are allocated to
                   enterprise-specific Message Processing Models.
                   An enterprise messageProcessingModel value is
                   defined to be:

                   enterpriseID * 256 +
                        messageProcessingModel within enterprise

                   For example, the fourth Message Processing Model
                   defined by the enterprise whose enterpriseID



Harrington, et al.          Standards Track                    [Page 45]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


                   is 1 would be 259.

                 This scheme for allocating messageProcessingModel
                 values allows for a maximum of 255 standards-
                 based Message Processing Models, and for a
                 maximum of 256 Message Processing Models per
                 enterprise.

                 It is believed that the assignment of new
                 messageProcessingModel values will be rare
                 in practice because the larger the number of
                 simultaneously utilized Message Processing Models,
                 the larger the chance that interoperability
                 will suffer. It is believed that such a range
                 will be sufficient.  In the unlikely event that
                 the standards committee finds this number to be
                 insufficient over time, an enterprise number
                 can be allocated to obtain an additional 256
                 possible values.

                 Note that the most significant bit must be zero;
                 hence, there are 23 bits allocated for various
                 organizations to design and define non-standard
                 messageProcessingModels.  This limits the ability
                 to define new proprietary implementations of
                 Message Processing Models to the first 8,388,608
                 enterprises.

                 It is worthwhile to note that, in its encoded
                 form, the messageProcessingModel value will
                 normally require only a single byte since, in
                 practice, the leftmost bits will be zero for
                 most messages and sign extension is suppressed
                 by the encoding rules.

                 As of this writing, there are several values of
                 messageProcessingModel defined for use with SNMP.
                 They are as follows:

                     0  reserved for SNMPv1
                     1  reserved for SNMPv2c
                     2  reserved for SNMPv2u and SNMPv2*
                     3  reserved for SNMPv3
                "
    SYNTAX       INTEGER(0 .. 2147483647)






Harrington, et al.          Standards Track                    [Page 46]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


SnmpSecurityLevel ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "A Level of Security at which SNMP messages can be
                 sent or with which operations are being processed;
                 in particular, one of:

                   noAuthNoPriv - without authentication and
                                  without privacy,
                   authNoPriv   - with authentication but
                                  without privacy,
                   authPriv     - with authentication and
                                  with privacy.

                 These three values are ordered such that
                 noAuthNoPriv is less than authNoPriv and
                 authNoPriv is less than authPriv.
                "
    SYNTAX       INTEGER { noAuthNoPriv(1),
                           authNoPriv(2),
                           authPriv(3)
                         }

SnmpAdminString ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "255t"
    STATUS       current
    DESCRIPTION "An octet string containing administrative
                 information, preferably in human-readable form.

                 To facilitate internationalization, this
                 information is represented using the ISO/IEC
                 IS 10646-1 character set, encoded as an octet
                 string using the UTF-8 transformation format
                 described in [RFC2279].

                 Since additional code points are added by
                 amendments to the 10646 standard from time
                 to time, implementations must be prepared to
                 encounter any code point from 0x00000000 to
                 0x7fffffff.  Byte sequences that do not
                 correspond to the valid UTF-8 encoding of a
                 code point or are outside this range are
                 prohibited.

                 The use of control codes should be avoided.

                 When it is necessary to represent a newline,
                 the control code sequence CR LF should be used.




Harrington, et al.          Standards Track                    [Page 47]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


                 The use of leading or trailing white space should
                 be avoided.

                 For code points not directly supported by user
                 interface hardware or software, an alternative
                 means of entry and display, such as hexadecimal,
                 may be provided.

                 For information encoded in 7-bit US-ASCII,
                 the UTF-8 encoding is identical to the
                 US-ASCII encoding.

                 UTF-8 may require multiple bytes to represent a
                 single character / code point; thus the length
                 of this object in octets may be different from
                 the number of characters encoded.  Similarly,
                 size constraints refer to the number of encoded
                 octets, not the number of characters represented
                 by an encoding.

                 Note that when this TC is used for an object that
                 is used or envisioned to be used as an index, then
                 a SIZE restriction MUST be specified so that the
                 number of sub-identifiers for any object instance
                 does not exceed the limit of 128, as defined by
                 [RFC3416].

                 Note that the size of an SnmpAdminString object is
                 measured in octets, not characters.
                "
    SYNTAX       OCTET STRING (SIZE (0..255))


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

snmpFrameworkAdmin
    OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 }
snmpFrameworkMIBObjects
    OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 }
snmpFrameworkMIBConformance
    OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 }

-- the snmpEngine Group ********************************************

snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 }






Harrington, et al.          Standards Track                    [Page 48]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


snmpEngineID     OBJECT-TYPE
    SYNTAX       SnmpEngineID
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "An SNMP engine's administratively-unique identifier.

                 This information SHOULD be stored in non-volatile
                 storage so that it remains constant across
                 re-initializations of the SNMP engine.
                "
    ::= { snmpEngine 1 }

snmpEngineBoots  OBJECT-TYPE
    SYNTAX       INTEGER (1..2147483647)
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of times that the SNMP engine has
                 (re-)initialized itself since snmpEngineID
                 was last configured.
                "
    ::= { snmpEngine 2 }

snmpEngineTime   OBJECT-TYPE
    SYNTAX       INTEGER (0..2147483647)
    UNITS        "seconds"
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of seconds since the value of
                 the snmpEngineBoots object last changed.
                 When incrementing this object's value would
                 cause it to exceed its maximum,
                 snmpEngineBoots is incremented as if a
                 re-initialization had occurred, and this
                 object's value consequently reverts to zero.
                "
    ::= { snmpEngine 3 }

snmpEngineMaxMessageSize OBJECT-TYPE
    SYNTAX       INTEGER (484..2147483647)
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The maximum length in octets of an SNMP message
                 which this SNMP engine can send or receive and
                 process, determined as the minimum of the maximum
                 message size values supported among all of the
                 transports available to and supported by the engine.
                "
    ::= { snmpEngine 4 }



Harrington, et al.          Standards Track                    [Page 49]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


-- Registration Points for Authentication and Privacy Protocols **

snmpAuthProtocols OBJECT-IDENTITY
    STATUS        current
    DESCRIPTION  "Registration point for standards-track
                  authentication protocols used in SNMP Management
                  Frameworks.
                 "
    ::= { snmpFrameworkAdmin 1 }

snmpPrivProtocols OBJECT-IDENTITY
    STATUS        current
    DESCRIPTION  "Registration point for standards-track privacy
                  protocols used in SNMP Management Frameworks.
                 "
    ::= { snmpFrameworkAdmin 2 }

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

snmpFrameworkMIBCompliances
               OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1}
snmpFrameworkMIBGroups
               OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2}

-- compliance statements

snmpFrameworkMIBCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION "The compliance statement for SNMP engines which
                 implement the SNMP Management Framework MIB.
                "
    MODULE    -- this module
        MANDATORY-GROUPS { snmpEngineGroup }

    ::= { snmpFrameworkMIBCompliances 1 }

-- units of conformance

snmpEngineGroup OBJECT-GROUP
    OBJECTS {
              snmpEngineID,
              snmpEngineBoots,
              snmpEngineTime,
              snmpEngineMaxMessageSize
            }
    STATUS       current
    DESCRIPTION "A collection of objects for identifying and
                 determining the configuration and current timeliness



Harrington, et al.          Standards Track                    [Page 50]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


                 values of an SNMP engine.
                "
    ::= { snmpFrameworkMIBGroups 1 }

END

6.  IANA Considerations

   This document defines three number spaces administered by IANA, one
   for security models, another for message processing models, and a
   third for SnmpEngineID formats.

6.1.  Security Models

   The SnmpSecurityModel TEXTUAL-CONVENTION values managed by IANA are
   in the range from 0 to 255 inclusive, and are reserved for
   standards-track Security Models.  If this range should in the future
   prove insufficient, an enterprise number can be allocated to obtain
   an additional 256 possible values.

   As of this writing, there are several values of securityModel defined
   for use with SNMP or reserved for use with supporting MIB objects.
   They are as follows:

                           0  reserved for 'any'
                           1  reserved for SNMPv1
                           2  reserved for SNMPv2c
                           3  User-Based Security Model (USM)

6.2.  Message Processing Models

   The SnmpMessageProcessingModel TEXTUAL-CONVENTION values managed by
   IANA are in the range 0 to 255, inclusive.  Each value uniquely
   identifies a standards-track Message Processing Model of the Message
   Processing Subsystem within the SNMP Management Architecture.

   Should this range prove insufficient in the future, an enterprise
   number may be obtained for the standards committee to get an
   additional 256 possible values.

   As of this writing, there are several values of
   messageProcessingModel defined for use with SNMP.  They are as
   follows:

                           0  reserved for SNMPv1
                           1  reserved for SNMPv2c
                           2  reserved for SNMPv2u and SNMPv2*
                           3  reserved for SNMPv3



Harrington, et al.          Standards Track                    [Page 51]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


6.3.  SnmpEngineID Formats

   The SnmpEngineID TEXTUAL-CONVENTION's fifth octet contains a format
   identifier.  The values managed by IANA are in the range 6 to 127,
   inclusive.  Each value uniquely identifies a standards-track
   SnmpEngineID format.

7.  Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in RFC 2028.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

8.  Acknowledgements

   This document is the result of the efforts of the SNMPv3 Working
   Group.  Some special thanks are in order to the following SNMPv3 WG
   members:

      Harald Tveit Alvestrand (Maxware)
      Dave Battle (SNMP Research, Inc.)
      Alan Beard (Disney Worldwide Services)
      Paul Berrevoets (SWI Systemware/Halcyon Inc.)
      Martin Bjorklund (Ericsson)
      Uri Blumenthal (IBM T.J. Watson Research Center)
      Jeff Case (SNMP Research, Inc.)
      John Curran (BBN)
      Mike Daniele (Compaq Computer Corporation)
      T. Max Devlin (Eltrax Systems)
      John Flick (Hewlett Packard)
      Rob Frye (MCI)
      Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.)



Harrington, et al.          Standards Track                    [Page 52]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


      David Harrington (Cabletron Systems Inc.)
      Lauren Heintz (BMC Software, Inc.)
      N.C. Hien (IBM T.J. Watson Research Center)
      Michael Kirkham (InterWorking Labs, Inc.)
      Dave Levi (SNMP Research, Inc.)
      Louis A Mamakos (UUNET Technologies Inc.)
      Joe Marzot (Nortel Networks)
      Paul Meyer (Secure Computing Corporation)
      Keith McCloghrie (Cisco Systems)
      Bob Moore (IBM)
      Russ Mundy (TIS Labs at Network Associates)
      Bob Natale (ACE*COMM Corporation)
      Mike O'Dell (UUNET Technologies Inc.)
      Dave Perkins (DeskTalk)
      Peter Polkinghorne (Brunel University)
      Randy Presuhn (BMC Software, Inc.)
      David Reeder (TIS Labs at Network Associates)
      David Reid (SNMP Research, Inc.)
      Aleksey Romanov (Quality Quorum)
      Shawn Routhier (Epilogue)
      Juergen Schoenwaelder (TU Braunschweig)
      Bob Stewart (Cisco Systems)
      Mike Thatcher (Independent Consultant)
      Bert Wijnen (IBM T.J. Watson Research Center)

   The document is based on recommendations of the IETF Security and
   Administrative Framework Evolution for SNMP Advisory Team.  Members
   of that Advisory Team were:

      David Harrington (Cabletron Systems Inc.)
      Jeff Johnson (Cisco Systems)
      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 Center)

   As recommended by the Advisory Team and the SNMPv3 Working Group
   Charter, the design incorporates as much as practical from previous
   RFCs and drafts. As a result, special thanks are due to the authors
   of previous designs known as SNMPv2u and SNMPv2*:

      Jeff Case (SNMP Research, Inc.)
      David Harrington (Cabletron Systems Inc.)
      David Levi (SNMP Research, Inc.)
      Keith McCloghrie (Cisco Systems)
      Brian O'Keefe (Hewlett Packard)



Harrington, et al.          Standards Track                    [Page 53]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


      Marshall T. Rose (Dover Beach Consulting)
      Jon Saperia (BGS Systems Inc.)
      Steve Waldbusser (International Network Services)
      Glenn W. Waters (Bell-Northern Research Ltd.)

9.  Security Considerations

   This document describes how an implementation can include a Security
   Model to protect management messages and an Access Control Model to
   control access to management information.

   The level of security provided is determined by the specific Security
   Model implementation(s) and the specific Access Control Model
   implementation(s) used.

   Applications have access to data which is not secured.  Applications
   SHOULD take reasonable steps to protect the data from disclosure.

   It is the responsibility of the purchaser of an implementation to
   ensure that:

      1) an implementation complies with the rules defined by this
         architecture,

      2) the Security and Access Control Models utilized satisfy the
         security and access control needs of the organization,

      3) the implementations of the Models and Applications comply with
         the model and application specifications,

      4) and the implementation protects configuration secrets from
         inadvertent disclosure.

   This document also contains a MIB definition module.  None of the
   objects defined is writable, and the information they represent is
   not deemed to be particularly sensitive.  However, if they are deemed
   sensitive in a particular environment, access to them should be
   restricted through the use of appropriately configured Security and
   Access Control models.

10.  References

10.1.  Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.





Harrington, et al.          Standards Track                    [Page 54]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
               10646", RFC 2279, January 1998.

   [RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Structure of Management
               Information Version 2 (SMIv2)", STD 58, RFC 2578, April
               1999.

   [RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Textual Conventions for
               SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Conformance Statements for
               SMIv2", STD 58, RFC 2580, April 1999.

   [RFC3412]   Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
               "Message Processing and Dispatching for the Simple
               Network Management Protocol (SNMP)", STD 62, RFC 3412,
               December 2002.

   [RFC3413]   Levi, D., Meyer, P. and B. Stewart, "Simple Network
               Management Protocol (SNMP) Applications", STD 62, RFC
               3413, December 2002.

   [RFC3414]   Blumenthal, U. and B. Wijnen, "User-Based Security Model
               (USM) for Version 3 of the Simple Network Management
               Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.

   [RFC3415]   Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model (VACM) for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3415, December
               2002.

   [RFC3416]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
               Waldbusser, "Protocol Operations for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3416, December
               2002.

   [RFC3417]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
               Waldbusser, "Transport Mappings for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3417, December
               2002.

   [RFC3418]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
               Waldbusser, "Management Information Base (MIB) for the
               Simple Network Management Protocol (SNMP)", STD 62, RFC
               3418, December 2002.



Harrington, et al.          Standards Track                    [Page 55]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


10.2.  Informative References

   [RFC1155]   Rose, M. and K. McCloghrie, "Structure and Identification
               of Management Information for TCP/IP-based internets",
               STD 16, RFC 1155, May 1990.

   [RFC1157]   Case, J., Fedor, M., Schoffstall, M. and J. Davin, "The
               Simple Network Management Protocol", STD 15, RFC 1157,
               May 1990.

   [RFC1212]   Rose, M. and K. McCloghrie, "Concise MIB Definitions",
               STD 16, RFC 1212, March 1991.

   [RFC1901]   Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
               "Introduction to Community-based SNMPv2", RFC 1901,
               January 1996.

   [RFC1909]   McCloghrie, K., Editor, "An Administrative Infrastructure
               for SNMPv2", RFC 1909, February 1996.

   [RFC1910]   Waters, G., Editor, "User-based Security Model for
               SNMPv2", RFC 1910, February 1996.

   [RFC2028]   Hovey, R. and S. Bradner, "The Organizations Involved in
               the IETF Standards Process", BCP 11, RFC 2028, October
               1996.

   [RFC2576]   Frye, R., Levi, D., Routhier, S. and B. Wijnen,
               "Coexistence between Version 1, Version 2, and Version 3
               of the Internet-Standard Network Management Framework",
               RFC 2576, March 2000.

   [RFC2863]   McCloghrie, K. and F. Kastenholz, "The Interfaces Group
               MIB", RFC 2863, June 2000.

   [RFC3410]   Case, J., Mundy, R., Partain, D. and B. Stewart,
               "Introduction and Applicability Statements for Internet-
               Standard Management Framework", RFC 3410, December 2002.













Harrington, et al.          Standards Track                    [Page 56]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


Appendix A

A.  Guidelines for Model Designers

   This appendix describes guidelines for designers of models which are
   expected to fit into the architecture defined in this document.

   SNMPv1 and SNMPv2c are two SNMP frameworks which use communities to
   provide trivial authentication and access control.  SNMPv1 and
   SNMPv2c Frameworks can coexist with Frameworks designed according to
   this architecture, and modified versions of SNMPv1 and SNMPv2c
   Frameworks could be designed to meet the requirements of this
   architecture, but this document does not provide guidelines for that
   coexistence.

   Within any subsystem model, there should be no reference to any
   specific model of another subsystem, or to data defined by a specific
   model of another subsystem.

   Transfer of data between the subsystems is deliberately described as
   a fixed set of abstract data elements and primitive functions which
   can be overloaded to satisfy the needs of multiple model definitions.

   Documents which define models to be used within this architecture
   SHOULD use the standard primitives between subsystems, possibly
   defining specific mechanisms for converting the abstract data
   elements into model-usable formats.  This constraint exists to allow
   subsystem and model documents to be written recognizing common
   borders of the subsystem and model.  Vendors are not constrained to
   recognize these borders in their implementations.

   The architecture defines certain standard services to be provided
   between subsystems, and the architecture defines abstract service
   interfaces to request these services.

   Each model definition for a subsystem SHOULD support the standard
   service interfaces, but whether, or how, or how well, it performs the
   service is dependent on the model definition.

A.1.  Security Model Design Requirements

A.1.1.  Threats

   A document describing a Security Model MUST describe how the model
   protects against the threats described under "Security Requirements
   of this Architecture", section 1.4.





Harrington, et al.          Standards Track                    [Page 57]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


A.1.2.  Security Processing

   Received messages MUST be validated by a Model of the Security
   Subsystem.  Validation includes authentication and privacy processing
   if needed, but it is explicitly allowed to send messages which do not
   require authentication or privacy.

   A received message contains a specified securityLevel to be used
   during processing.  All messages requiring privacy MUST also require
   authentication.

   A Security Model specifies rules by which authentication and privacy
   are to be done.  A model may define mechanisms to provide additional
   security features, but the model definition is constrained to using
   (possibly a subset of) the abstract data elements defined in this
   document for transferring data between subsystems.

   Each Security Model may allow multiple security protocols to be used
   concurrently within an implementation of the model.  Each Security
   Model defines how to determine which protocol to use, given the
   securityLevel and the security parameters relevant to the message.
   Each Security Model, with its associated protocol(s) defines how the
   sending/receiving entities are identified, and how secrets are
   configured.

   Authentication and Privacy protocols supported by Security Models are
   uniquely identified using Object Identifiers.  IETF standard
   protocols for authentication or privacy should have an identifier
   defined within the snmpAuthProtocols or the snmpPrivProtocols
   subtrees.  Enterprise specific protocol identifiers should be defined
   within the enterprise subtree.

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

   The persistent data used for security should be SNMP-manageable, but
   the Security Model defines whether an instantiation of the MIB is a
   conformance requirement.

   Security Models are replaceable within the Security Subsystem.
   Multiple Security Model implementations may exist concurrently within
   an SNMP engine.  The number of Security Models defined by the SNMP
   community should remain small to promote interoperability.








Harrington, et al.          Standards Track                    [Page 58]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


A.1.3.  Validate the security-stamp in a received message

   A Message Processing Model requests that a Security Model:

      -  verifies that the message has not been altered,

      -  authenticates the identification of the principal for whom the
         message was generated.

      -  decrypts the message if it was encrypted.

   Additional requirements may be defined by the model, and additional
   services may be provided by the model, but the model is constrained
   to use the following primitives for transferring data between
   subsystems.  Implementations are not so constrained.

   A Message Processing Model uses the processIncomingMsg primitive as
   described in section 4.4.2.

A.1.4.  Security MIBs

   Each Security Model defines the MIB module(s) required for security
   processing, including any MIB module(s) required for the security
   protocol(s) supported.  The MIB module(s) SHOULD be defined
   concurrently with the procedures which use the MIB module(s).  The
   MIB module(s) are subject to normal access control rules.

   The mapping between the model-dependent security ID and the
   securityName MUST be able to be determined using SNMP, if the model-
   dependent MIB is instantiated and if access control policy allows
   access.

A.1.5.  Cached Security Data

   For each message received, the Security Model caches the state
   information such that a Response message can be generated using the
   same security information, even if the Local Configuration Datastore
   is altered between the time of the incoming request and the outgoing
   response.

   A Message Processing Model has the responsibility for explicitly
   releasing the cached data if such data is no longer needed.  To
   enable this, an abstract securityStateReference data element is
   passed from the Security Model to the Message Processing Model.

   The cached security data may be implicitly released via the
   generation of a response, or explicitly released by using the
   stateRelease primitive, as described in section 4.5.1.



Harrington, et al.          Standards Track                    [Page 59]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


A.2.  Message Processing Model Design Requirements

   An SNMP engine contains a Message Processing Subsystem which may
   contain multiple Message Processing Models.

   The Message Processing Model MUST always (conceptually) pass the
   complete PDU, i.e., it never forwards less than the complete list of
   varBinds.

A.2.1.  Receiving an SNMP Message from the Network

   Upon receipt of a message from the network, the Dispatcher in the
   SNMP engine determines the version of the SNMP message and interacts
   with the corresponding Message Processing Model to determine the
   abstract data elements.

   A Message Processing Model specifies the SNMP Message format it
   supports and describes how to determine the values of the abstract
   data elements (like msgID, msgMaxSize, msgFlags,
   msgSecurityParameters, securityModel, securityLevel etc).  A Message
   Processing Model interacts with a Security Model to provide security
   processing for the message using the processIncomingMsg primitive, as
   described in section 4.4.2.

A.2.2.  Sending an SNMP Message to the Network

   The Dispatcher in the SNMP engine interacts with a Message Processing
   Model to prepare an outgoing message.  For that it uses the following
   primitives:

      -  for requests and notifications: prepareOutgoingMessage, as
         described in section 4.2.1.

      -  for response messages: prepareResponseMessage, as described in
         section 4.2.2.

   A Message Processing Model, when preparing an Outgoing SNMP Message,
   interacts with a Security Model to secure the message.  For that it
   uses the following primitives:

      -  for requests and notifications: generateRequestMsg, as
         described in section 4.4.1.

      -  for response messages: generateResponseMsg as described in
         section 4.4.3.






Harrington, et al.          Standards Track                    [Page 60]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


   Once the SNMP message is prepared by a Message Processing Model, the
   Dispatcher sends the message to the desired address using the
   appropriate transport.

A.3.  Application Design Requirements

   Within an application, there may be an explicit binding to a specific
   SNMP message version, i.e., a specific Message Processing Model, and
   to a specific Access Control Model, but there should be no reference
   to any data defined by a specific Message Processing Model or Access
   Control Model.

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

   An application determines whether explicit or implicit access control
   should be applied to the operation, and, if access control is needed,
   which Access Control Model should be used.

   An application has the responsibility to define any MIB module(s)
   used to provide application-specific services.

   Applications interact with the SNMP engine to initiate messages,
   receive responses, receive asynchronous messages, and send responses.

A.3.1.  Applications that Initiate Messages

   Applications may request that the SNMP engine send messages
   containing SNMP commands or notifications using the sendPdu primitive
   as described in section 4.1.1.

   If it is desired that a message be sent to multiple targets, it is
   the responsibility of the application to provide the iteration.

   The SNMP engine assumes necessary access control has been applied to
   the PDU, and provides no access control services.

   The SNMP engine looks at the "expectResponse" parameter, and if a
   response is expected, then the appropriate information is cached such
   that a later response can be associated to this message, and can then
   be returned to the application.  A sendPduHandle is returned to the
   application so it can later correspond the response with this message
   as well.








Harrington, et al.          Standards Track                    [Page 61]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


A.3.2.  Applications that Receive Responses

   The SNMP engine matches the incoming response messages to outstanding
   messages sent by this SNMP engine, and forwards the response to the
   associated application using the processResponsePdu primitive, as
   described in section 4.1.4.

A.3.3.  Applications that Receive Asynchronous Messages

   When an SNMP engine receives a message that is not the response to a
   request from this SNMP engine, it must determine to which application
   the message should be given.

   An Application that wishes to receive asynchronous messages registers
   itself with the engine using the primitive registerContextEngineID as
   described in section 4.1.5.

   An Application that wishes to stop receiving asynchronous messages
   should unregister itself with the SNMP engine using the primitive
   unregisterContextEngineID as described in section 4.1.5.

   Only one registration per combination of PDU type and contextEngineID
   is permitted at the same time.  Duplicate registrations are ignored.
   An errorIndication will be returned to the application that attempts
   to duplicate a registration.

   All asynchronously received messages containing a registered
   combination of PDU type and contextEngineID are sent to the
   application which registered to support that combination.

   The engine forwards the PDU to the registered application, using the
   processPdu primitive, as described in section 4.1.2.

A.3.4.  Applications that Send Responses

   Request operations require responses.  An application sends a
   response via the returnResponsePdu primitive, as described in section
   4.1.3.

   The contextEngineID, contextName, securityModel, securityName,
   securityLevel, and stateReference parameters are from the initial
   processPdu primitive.  The PDU and statusInformation are the results
   of processing.








Harrington, et al.          Standards Track                    [Page 62]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


A.4.  Access Control Model Design Requirements

   An Access Control Model determines whether the specified securityName
   is allowed to perform the requested operation on a specified managed
   object.  The Access Control Model specifies the rules by which access
   control is determined.

   The persistent data used for access control should be manageable
   using SNMP, but the Access Control Model defines whether an
   instantiation of the MIB is a conformance requirement.

   The Access Control Model must provide the primitive isAccessAllowed.

Editors' Addresses

   Bert Wijnen
   Lucent Technologies
   Schagen 33
   3461 GL Linschoten
   Netherlands

   Phone: +31 348-680-485
   EMail: bwijnen@lucent.com


   David Harrington
   Enterasys Networks
   Post Office Box 5005
   35 Industrial Way
   Rochester, New Hampshire 03866-5005
   USA

   Phone: +1 603-337-2614
   EMail: dbh@enterasys.com


   Randy Presuhn
   BMC Software, Inc.
   2141 North First Street
   San Jose, California 95131
   USA

   Phone: +1 408-546-1006
   Fax: +1 408-965-0359
   EMail: randy_presuhn@bmc.com






Harrington, et al.          Standards Track                    [Page 63]


RFC 3411      Architecture for SNMP Management Frameworks  December 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Harrington, et al.          Standards Track                    [Page 64]

=========================================================================






Network Working Group                                            J. Case
Request for Comments: 3412                           SNMP Research, Inc.
STD: 62                                                    D. Harrington
Obsoletes: 2572                                       Enterasys Networks
Category: Standards Track                                     R. Presuhn
                                                      BMC Software, Inc.
                                                               B. Wijnen
                                                     Lucent Technologies
                                                           December 2002


               Message Processing and Dispatching for the
               Simple Network Management Protocol (SNMP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes the Message Processing and Dispatching for
   Simple Network Management Protocol (SNMP) messages within the SNMP
   architecture.  It defines the procedures for dispatching potentially
   multiple versions of SNMP messages to the proper SNMP Message
   Processing Models, and for dispatching PDUs to SNMP applications.
   This document also describes one Message Processing Model - the
   SNMPv3 Message Processing Model.  This document obsoletes RFC 2572.
















Case, et al.                Standards Track                     [Page 1]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


Table of Contents

   1. Introduction ................................................    3
   2. Overview ....................................................    4
   2.1. The Dispatcher ............................................    5
   2.2. Message Processing Subsystem ..............................    5
   3. Elements of Message Processing and Dispatching ..............    6
   3.1. messageProcessingModel ....................................    6
   3.2. pduVersion ................................................    6
   3.3. pduType ...................................................    7
   3.4. sendPduHandle .............................................    7
   4. Dispatcher Elements of Procedure ............................    7
   4.1. Sending an SNMP Message to the Network ....................    7
   4.1.1. Sending a Request or Notification .......................    8
   4.1.2. Sending a Response to the Network .......................    9
   4.2. Receiving an SNMP Message from the Network ................   11
   4.2.1. Message Dispatching of received SNMP Messages ...........   11
   4.2.2. PDU Dispatching for Incoming Messages ...................   12
   4.2.2.1. Incoming Requests and Notifications ...................   13
   4.2.2.2. Incoming Responses ....................................   14
   4.3. Application Registration for Handling PDU types ...........   15
   4.4. Application Unregistration for Handling PDU Types .........   16
   5. Definitions .................................................   16
   5.1. Definitions for SNMP Message Processing and Dispatching ...   16
   6. The SNMPv3 Message Format ...................................   19
   6.1. msgVersion ................................................   20
   6.2. msgID .....................................................   20
   6.3. msgMaxSize ................................................   21
   6.4. msgFlags ..................................................   21
   6.5. msgSecurityModel ..........................................   24
   6.6. msgSecurityParameters .....................................   24
   6.7. scopedPduData .............................................   24
   6.8. scopedPDU .................................................   24
   6.8.1. contextEngineID .........................................   24
   6.8.2. contextName .............................................   25
   6.8.3. data ....................................................   25
   7. Elements of Procedure for v3MP ..............................   25
   7.1. Prepare an Outgoing SNMP Message ..........................   26
   7.2. Prepare Data Elements from an Incoming SNMP Message .......   32
   8. Intellectual Property .......................................   37
   9. Acknowledgements ............................................   38
   10. Security Considerations ....................................   39
   11. References .................................................   40
   11.1. Normative References .....................................   40
   11.2. Informative References ...................................   41
   12. Editors' Addresses .........................................   42
   13. Full Copyright Statement ...................................   43




Case, et al.                Standards Track                     [Page 2]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


1.  Introduction

   The Architecture for describing Internet Management Frameworks
   [RFC3411] describes that an SNMP engine is composed of:

      1) a Dispatcher
      2) a Message Processing Subsystem,
      3) a Security Subsystem, and
      4) an Access Control Subsystem.

   Applications make use of the services of these subsystems.

   It is important to understand the SNMP architecture and its
   terminology to understand where the Message Processing Subsystem and
   Dispatcher described in this document fit into the architecture and
   interact with other subsystems within the architecture.  The reader
   is expected to have read and understood the description of the SNMP
   architecture, defined in [RFC3411].

   The Dispatcher in the SNMP engine sends and receives SNMP messages.
   It also dispatches SNMP PDUs to SNMP applications.  When an SNMP
   message needs to be prepared or when data needs to be extracted from
   an SNMP message, the Dispatcher delegates these tasks to a message
   version-specific Message Processing Model within the Message
   Processing Subsystem.

   A Message Processing Model is responsible for processing an SNMP
   version-specific message and for coordinating the interaction with
   the Security Subsystem to ensure proper security is applied to the
   SNMP message being handled.

   Interactions between the Dispatcher, the Message Processing
   Subsystem, and applications are modeled using abstract data elements
   and abstract service interface primitives defined by the SNMP
   architecture.

   Similarly, interactions between the Message Processing Subsystem and
   the Security Subsystem are modeled using abstract data elements and
   abstract service interface primitives as defined by the SNMP
   architecture.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119.







Case, et al.                Standards Track                     [Page 3]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


2.  Overview

   The following illustration depicts the Message Processing in relation
   to SNMP applications, the Security Subsystem and Transport Mappings.

   +-------------------------------------------------------------------+
   | SNMP Entity                                                       |
   |                                                                   |
   | +---------------------------------------------------------------+ |
   | | Applications                                                  | |
   | | +-----------+  +--------------+                               | |
   | | | Command   |  | Notification |                               | |
   | | | Generator |  | Originator   | +-----------+ +--------------+| |
   | | +-----------+  +--------------+ | Proxy     | | Other        || |
   | | +-----------+  +--------------+ | Forwarder | |Application(s)|| |
   | | | Command   |  | Notification | +-----------+ +--------------+| |
   | | | Responder |  | Receiver     |                               | |
   | | +-----------+  +--------------+                               | |
   | +---------------------------------------------------------------+ |
   |        ^                ^               ^           ^             |
   |        |                |               |           |             |
   |        v                v               v           v             |
   |        +--------+-------+---------------+-----------+             |
   |                 ^                                                 |
   |                 |    +---------------------+  +-----------------+ |
   |                 |    | Message Processing  |  | Security        | |
   | Dispatcher      v    | Subsystem           |  | Subsystem       | |
   | +------------------+ |     +------------+  |  |                 | |
   | | PDU Dispatcher   | |  +->| v1MP     * |<--->| +-------------+ | |
   | |                  | |  |  +------------+  |  | | Other       | | |
   | |                  | |  |  +------------+  |  | | Security    | | |
   | |                  | |  +->| v2cMP    * |<--->| | Model       | | |
   | | Message          | |  |  +------------+  |  | +-------------+ | |
   | | Dispatcher  <-------->+                  |  |                 | |
   | |                  | |  |  +------------+  |  | +-------------+ | |
   | |                  | |  +->| v3MP     * |<--->| | User-based  | | |
   | | Transport        | |  |  +------------+  |  | | Security    | | |
   | | Mapping          | |  |  +------------+  |  | | Model       | | |
   | | (e.g., RFC 3417) | |  +->| otherMP  * |<--->| +-------------+ | |
   | +------------------+ |     +------------+  |  |                 | |
   |          ^           +---------------------+  +-----------------+ |
   |          |                                                        |
   +----------|--------------------------------------------------------+
              v
     +------------------+
     |   Network        |           * One or more models may be present.
     +------------------+




Case, et al.                Standards Track                     [Page 4]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


2.1.  The Dispatcher

   The Dispatcher is a key piece of an SNMP engine.  There is only one
   in an SNMP engine, and its job is to dispatch tasks to the multiple
   version-specific Message Processing Models, and to dispatch PDUs to
   various applications.

   For outgoing messages, an application provides a PDU to be sent, plus
   the data needed to prepare and send the message, and the application
   specifies which version-specific Message Processing Model will be
   used to prepare the message with the desired security processing.
   Once the message is prepared, the Dispatcher sends the message.

   For incoming messages, the Dispatcher determines the SNMP version of
   the incoming message and passes the message to the version-specific
   Message Processing Model to extract the components of the message and
   to coordinate the processing of security services for the message.
   After version-specific processing, the PDU Dispatcher determines
   which application, if any, should receive the PDU for processing and
   forwards it accordingly.

   The Dispatcher, while sending and receiving SNMP messages, collects
   statistics about SNMP messages and the behavior of the SNMP engine in
   managed objects to make them accessible to remote SNMP entities.
   This document defines these managed objects, the MIB module which
   contains them, and how these managed objects might be used to provide
   useful management.

2.2.  Message Processing Subsystem

   The SNMP Message Processing Subsystem is the part of an SNMP engine
   which interacts with the Dispatcher to handle the version-specific
   SNMP messages.  It contains one or more Message Processing Models.

   This document describes one Message Processing Model, the SNMPv3
   Message Processing Model, in Section 6.  The SNMPv3 Message
   Processing Model is defined in a separate section to show that
   multiple (independent) Message Processing Models can exist at the
   same time and that such Models can be described in different
   documents.  The SNMPv3 Message Processing Model can be replaced or
   supplemented with other Message Processing Models in the future.  Two
   Message Processing Models which are expected to be developed in the
   future are the SNMPv1 message format [RFC1157] and the SNMPv2c
   message format [RFC1901].  Others may be developed as needed.







Case, et al.                Standards Track                     [Page 5]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


3.  Elements of Message Processing and Dispatching

   See [RFC3411] for the definitions of:

      contextEngineID
      contextName
      scopedPDU
      maxSizeResponseScopedPDU
      securityModel
      securityName
      securityLevel
      messageProcessingModel

   For incoming messages, a version-specific message processing module
   provides these values to the Dispatcher.  For outgoing messages, an
   application provides these values to the Dispatcher.

   For some version-specific processing, the values may be extracted
   from received messages; for other versions, the values may be
   determined by algorithm, or by an implementation-defined mechanism.
   The mechanism by which the value is determined is irrelevant to the
   Dispatcher.

   The following additional or expanded definitions are for use within
   the Dispatcher.

3.1.  messageProcessingModel

   The value of messageProcessingModel identifies a Message Processing
   Model.  A Message Processing Model describes the version-specific
   procedures for extracting data from messages, generating messages,
   calling upon a securityModel to apply its security services to
   messages, for converting data from a version-specific message format
   into a generic format usable by the Dispatcher, and for converting
   data from Dispatcher format into a version-specific message format.

3.2.  pduVersion

   The value of pduVersion represents a specific version of protocol
   operation and its associated PDU formats, such as SNMPv1 or SNMPv2
   [RFC3416].  The values of pduVersion are specific to the version of
   the PDU contained in a message, and the PDUs processed by
   applications.  The Dispatcher does not use the value of pduVersion
   directly.







Case, et al.                Standards Track                     [Page 6]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   An application specifies the pduVersion when it requests the PDU
   Dispatcher to send a PDU to another SNMP engine.  The Dispatcher
   passes the pduVersion to a Message Processing Model, so it knows how
   to handle the PDU properly.

   For incoming messages, the pduVersion is provided to the Dispatcher
   by a version-specific Message Processing module.  The PDU Dispatcher
   passes the pduVersion to the application so it knows how to handle
   the PDU properly.  For example, a command responder application needs
   to know whether to use [RFC3416] elements of procedure and syntax
   instead of those specified for SNMPv1.

3.3.  pduType

   A value of the pduType represents a specific type of protocol
   operation.  The values of the pduType are specific to the version of
   the PDU contained in a message.

   Applications register to support particular pduTypes for particular
   contextEngineIDs.

   For incoming messages, pduType is provided to the Dispatcher by a
   version-specific Message Processing module.  It is subsequently used
   to dispatch the PDU to the application which registered for the
   pduType for the contextEngineID of the associated scopedPDU.

3.4.  sendPduHandle

   This handle is generated for coordinating the processing of requests
   and responses between the SNMP engine and an application.  The handle
   must be unique across all version-specific Message Processing Models,
   and is of local significance only.

4.  Dispatcher Elements of Procedure

   This section describes the procedures followed by the Dispatcher when
   generating and processing SNMP messages.

4.1.  Sending an SNMP Message to the Network

   This section describes the procedure followed by an SNMP engine
   whenever it sends an SNMP message.









Case, et al.                Standards Track                     [Page 7]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


4.1.1.  Sending a Request or Notification

   The following procedures are followed by the Dispatcher when an
   application wants to send an SNMP PDU to another (remote)
   application, i.e., to initiate a communication by originating a
   message, such as one containing a request or a notification.

   1) The application requests this using the abstract service
      primitive:

      statusInformation =              -- sendPduHandle if success
                                       -- errorIndication if failure
        sendPdu(
        IN   transportDomain           -- transport domain to be used
        IN   transportAddress          -- destination network address
        IN   messageProcessingModel    -- typically, SNMP version
        IN   securityModel             -- Security Model to use
        IN   securityName              -- on behalf of this principal
        IN   securityLevel             -- Level of Security requested
        IN   contextEngineID           -- data from/at this entity
        IN   contextName               -- data from/in this context
        IN   pduVersion                -- the version of the PDU
        IN   PDU                       -- SNMP Protocol Data Unit
        IN   expectResponse            -- TRUE or FALSE
             )

   2) If the messageProcessingModel value does not represent a Message
      Processing Model known to the Dispatcher, then an errorIndication
      (implementation-dependent) is returned to the calling application.
      No further processing is performed.

   3) The Dispatcher generates a sendPduHandle to coordinate subsequent
      processing.


















Case, et al.                Standards Track                     [Page 8]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   4) The Message Dispatcher sends the request to the version-specific
      Message Processing module identified by messageProcessingModel
      using the abstract service primitive:

      statusInformation =              -- success or error indication
        prepareOutgoingMessage(
        IN   transportDomain           -- as specified by application
        IN   transportAddress          -- as specified by application
        IN   messageProcessingModel    -- as specified by application
        IN   securityModel             -- as specified by application
        IN   securityName              -- as specified by application
        IN   securityLevel             -- as specified by application
        IN   contextEngineID           -- as specified by application
        IN   contextName               -- as specified by application
        IN   pduVersion                -- as specified by application
        IN   PDU                       -- as specified by application
        IN   expectResponse            -- as specified by application
        IN   sendPduHandle             -- as determined in step 3.
        OUT  destTransportDomain       -- destination transport domain
        OUT  destTransportAddress      -- destination transport address
        OUT  outgoingMessage           -- the message to send
        OUT  outgoingMessageLength     -- the message length
             )

   5) If the statusInformation indicates an error, the errorIndication
      is returned to the calling application.  No further processing is
      performed.

   6) If the statusInformation indicates success, the sendPduHandle is
      returned to the application, and the outgoingMessage is sent.  The
      transport used to send the outgoingMessage is returned via
      destTransportDomain, and the address to which it was sent is
      returned via destTransportAddress.

   Outgoing Message Processing is complete.

4.1.2.  Sending a Response to the Network

   The following procedure is followed when an application wants to
   return a response back to the originator of an SNMP Request.











Case, et al.                Standards Track                     [Page 9]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   1) An application can request this using the abstract service
      primitive:

      result =
      returnResponsePdu(
       IN   messageProcessingModel   -- typically, SNMP version
       IN   securityModel            -- Security Model in use
       IN   securityName             -- on behalf of this principal
       IN   securityLevel            -- same as on incoming request
       IN   contextEngineID          -- data from/at this SNMP entity
       IN   contextName              -- data from/in this context
       IN   pduVersion               -- the version of the PDU
       IN   PDU                      -- SNMP Protocol Data Unit
       IN   maxSizeResponseScopedPDU -- maximum size of Response PDU
       IN   stateReference           -- reference to state information
                                     -- as presented with the request
       IN   statusInformation        -- success or errorIndication
       )                             -- (error counter OID and value
                                     -- when errorIndication)

   2) The Message Dispatcher sends the request to the appropriate
      Message Processing Model indicated by the received value of
      messageProcessingModel using the abstract service primitive:

      result =                       -- SUCCESS or errorIndication
       prepareResponseMessage(
       IN   messageProcessingModel   -- specified by application
       IN   securityModel            -- specified by application
       IN   securityName             -- specified by application
       IN   securityLevel            -- specified by application
       IN   contextEngineID          -- specified by application
       IN   contextName              -- specified by application
       IN   pduVersion               -- specified by application
       IN   PDU                      -- specified by application
       IN   maxSizeResponseScopedPDU -- specified by application
       IN   stateReference           -- specified by application
       IN   statusInformation        -- specified by application
       OUT  destTransportDomain      -- destination transport domain
       OUT  destTransportAddress     -- destination transport address
       OUT  outgoingMessage          -- the message to send
       OUT  outgoingMessageLength    -- the message length
            )

   3) If the result is an errorIndication, the errorIndication is
      returned to the calling application.  No further processing is
      performed.





Case, et al.                Standards Track                    [Page 10]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   4) If the result is success, the outgoingMessage is sent.  The
      transport used to send the outgoingMessage is returned via
      destTransportDomain, and the address to which it was sent is
      returned via destTransportAddress.

   Message Processing is complete.

4.2.  Receiving an SNMP Message from the Network

   This section describes the procedure followed by an SNMP engine
   whenever it receives an SNMP message.

   Please note, that for the sake of clarity and to prevent the text
   from being even longer and more complicated, some details were
   omitted from the steps below.  In particular, the elements of
   procedure do not always explicitly indicate when state information
   needs to be released.  The general rule is that if state information
   is available when a message is to be "discarded without further
   processing", then the state information must also be released at that
   same time.

4.2.1.  Message Dispatching of received SNMP Messages

   1) The snmpInPkts counter [RFC3418] is incremented.

   2) The version of the SNMP message is determined in an
      implementation-dependent manner.  If the packet cannot be
      sufficiently parsed to determine the version of the SNMP message,
      then the snmpInASNParseErrs [RFC3418] counter is incremented, and
      the message is discarded without further processing.  If the
      version is not supported, then the snmpInBadVersions [RFC3418]
      counter is incremented, and the message is discarded without
      further processing.

   3) The origin transportDomain and origin transportAddress are
      determined.















Case, et al.                Standards Track                    [Page 11]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   4) The message is passed to the version-specific Message Processing
      Model which returns the abstract data elements required by the
      Dispatcher.  This is performed using the abstract service
      primitive:

      result =                        -- SUCCESS or errorIndication
        prepareDataElements(
        IN   transportDomain          -- origin as determined in step 3.
        IN   transportAddress         -- origin as determined in step 3.
        IN   wholeMsg                 -- as received from the network
        IN   wholeMsgLength           -- as received from the network
        OUT  messageProcessingModel   -- typically, SNMP version
        OUT  securityModel            -- Security Model specified
        OUT  securityName             -- on behalf of this principal
        OUT  securityLevel            -- Level of Security specified
        OUT  contextEngineID          -- data from/at this entity
        OUT  contextName              -- data from/in this context
        OUT  pduVersion               -- the version of the PDU
        OUT  PDU                      -- SNMP Protocol Data Unit
        OUT  pduType                  -- SNMP PDU type
        OUT  sendPduHandle            -- handle for a matched request
        OUT  maxSizeResponseScopedPDU -- maximum size of Response PDU
        OUT  statusInformation        -- success or errorIndication
                                      -- (error counter OID and value
                                      -- when errorIndication)
        OUT  stateReference           -- reference to state information
                                      -- to be used for a possible
             )                        -- Response

   5) If the result is a FAILURE errorIndication, the message is
      discarded without further processing.

   6) At this point, the abstract data elements have been prepared and
      processing continues as described in Section 4.2.2, PDU
      Dispatching for Incoming Messages.

4.2.2.  PDU Dispatching for Incoming Messages

   The elements of procedure for the dispatching of PDUs depends on the
   value of sendPduHandle.  If the value of sendPduHandle is <none>,
   then this is a request or notification and the procedures specified
   in Section 4.2.2.1 apply.  If the value of snmpPduHandle is not
   <none>, then this is a response and the procedures specified in
   Section 4.2.2.2 apply.







Case, et al.                Standards Track                    [Page 12]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


4.2.2.1.  Incoming Requests and Notifications

   The following procedures are followed for the dispatching of PDUs
   when the value of sendPduHandle is <none>, indicating this is a
   request or notification.

   1) The combination of contextEngineID and pduType is used to
      determine which application has registered for this request or
      notification.

   2) If no application has registered for the combination, then:

      a) The snmpUnknownPDUHandlers counter is incremented.

      b) A Response message is generated using the abstract service
         primitive:

         result =                       -- SUCCESS or FAILURE
         prepareResponseMessage(
         IN   messageProcessingModel    -- as provided by MP module
         IN   securityModel             -- as provided by MP module
         IN   securityName              -- as provided by MP module
         IN   securityLevel             -- as provided by MP module
         IN   contextEngineID           -- as provided by MP module
         IN   contextName               -- as provided by MP module
         IN   pduVersion                -- as provided by MP module
         IN   PDU                       -- as provided by MP module
         IN   maxSizeResponseScopedPDU  -- as provided by MP module
         IN   stateReference            -- as provided by MP module
         IN   statusInformation         -- errorIndication plus
                                        -- snmpUnknownPDUHandlers OID
                                        -- value pair.
         OUT  destTransportDomain       -- destination transportDomain
         OUT  destTransportAddress      -- destination transportAddress
         OUT  outgoingMessage           -- the message to send
         OUT  outgoingMessageLength     -- its length
         )

      c) If the result is SUCCESS, then the prepared message is sent to
         the originator of the request as identified by the
         transportDomain and transportAddress.  The transport used to
         send the outgoingMessage is returned via destTransportDomain,
         and the address to which it was sent is returned via
         destTransportAddress.

      d) The incoming message is discarded without further processing.
         Message Processing for this message is complete.




Case, et al.                Standards Track                    [Page 13]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   3) The PDU is dispatched to the application, using the abstract
      service primitive:

      processPdu(                     -- process Request/Notification
        IN   messageProcessingModel   -- as provided by MP module
        IN   securityModel            -- as provided by MP module
        IN   securityName             -- as provided by MP module
        IN   securityLevel            -- as provided by MP module
        IN   contextEngineID          -- as provided by MP module
        IN   contextName              -- as provided by MP module
        IN   pduVersion               -- as provided by MP module
        IN   PDU                      -- as provided by MP module
        IN   maxSizeResponseScopedPDU -- as provided by MP module
        IN   stateReference           -- as provided by MP module
                                      -- needed when sending response
             )

      Message processing for this message is complete.

4.2.2.2.  Incoming Responses

   The following procedures are followed for the dispatching of PDUs
   when the value of sendPduHandle is not <none>, indicating this is a
   response.

   1) The value of sendPduHandle is used to determine, in an
      implementation-defined manner, which application is waiting for a
      response associated with this sendPduHandle.

   2) If no waiting application is found, the message is discarded
      without further processing, and the stateReference is released.
      The snmpUnknownPDUHandlers counter is incremented.  Message
      Processing is complete for this message.

   3) Any cached information, including stateReference, about the
      message is discarded.















Case, et al.                Standards Track                    [Page 14]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   4) The response is dispatched to the application using the abstract
      service primitive:

      processResponsePdu(              -- process Response PDU
        IN   messageProcessingModel    -- provided by the MP module
        IN   securityModel             -- provided by the MP module
        IN   securityName              -- provided by the MP module
        IN   securityLevel             -- provided by the MP module
        IN   contextEngineID           -- provided by the MP module
        IN   contextName               -- provided by the MP module
        IN   pduVersion                -- provided by the MP module
        IN   PDU                       -- provided by the MP module
        IN   statusInformation         -- provided by the MP module
        IN   sendPduHandle             -- provided by the MP module
             )

      Message Processing is complete for this message.

4.3.  Application Registration for Handling PDU types

   Applications that want to process certain PDUs must register with the
   PDU Dispatcher.  Applications specify the combination of
   contextEngineID and pduType(s) for which they want to take
   responsibility.

   1) An application registers according to the abstract interface
      primitive:

      statusInformation =           -- success or errorIndication
        registerContextEngineID(
        IN   contextEngineID        -- take responsibility for this one
        IN   pduType                -- the pduType(s) to be registered
             )

      Note: Implementations may provide a means of requesting
      registration for simultaneous multiple contextEngineID values,
      e.g., all contextEngineID values, and may also provide a means for
      requesting simultaneous registration for multiple values of the
      pduType.

   2) The parameters may be checked for validity; if they are not, then
      an errorIndication (invalidParameter) is returned to the
      application.

   3) Each combination of contextEngineID and pduType can be registered
      only once.  If another application has already registered for the
      specified combination, then an errorIndication (alreadyRegistered)
      is returned to the application.



Case, et al.                Standards Track                    [Page 15]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   4) Otherwise, the registration is saved so that SNMP PDUs can be
      dispatched to this application.

4.4.  Application Unregistration for Handling PDU Types

   Applications that no longer want to process certain PDUs must
   unregister with the PDU Dispatcher.

   1) An application unregisters using the abstract service primitive:

      unregisterContextEngineID(
       IN   contextEngineID        -- give up responsibility for this
       IN   pduType                -- the pduType(s) to be unregistered
            )

      Note: Implementations may provide a means for requesting the
      unregistration for simultaneous multiple contextEngineID values,
      e.g., all contextEngineID values, and may also provide a means for
      requesting simultaneous unregistration for multiple values of
      pduType.

   2) If the contextEngineID and pduType combination has been
      registered, then the registration is deleted.

      If no such registration exists, then the request is ignored.

5.  Definitions

5.1.  Definitions for SNMP Message Processing and Dispatching

   SNMP-MPD-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-COMPLIANCE, OBJECT-GROUP         FROM SNMPv2-CONF
       MODULE-IDENTITY, OBJECT-TYPE,
       snmpModules, Counter32                  FROM SNMPv2-SMI;

   snmpMPDMIB MODULE-IDENTITY
       LAST-UPDATED "200210140000Z"
       ORGANIZATION "SNMPv3 Working Group"
       CONTACT-INFO "WG-EMail:   snmpv3@lists.tislabs.com
                     Subscribe:  snmpv3-request@lists.tislabs.com

                     Co-Chair:   Russ Mundy
                                 Network Associates Laboratories
                     postal:     15204 Omega Drive, Suite 300
                                 Rockville, MD 20850-4601
                                 USA



Case, et al.                Standards Track                    [Page 16]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


                     EMail:      mundy@tislabs.com
                     phone:      +1 301-947-7107

                     Co-Chair &
                     Co-editor:  David Harrington
                                 Enterasys Networks
                     postal:     35 Industrial Way
                                 P. O. Box 5005
                                 Rochester NH 03866-5005
                                 USA
                     EMail:      dbh@enterasys.com
                     phone:      +1 603-337-2614

                     Co-editor:  Jeffrey Case
                                 SNMP Research, Inc.
                     postal:     3001 Kimberlin Heights Road
                                 Knoxville, TN 37920-9716
                                 USA
                     EMail:      case@snmp.com
                     phone:      +1 423-573-1434

                     Co-editor:  Randy Presuhn
                                 BMC Software, Inc.
                     postal:     2141 North First Street
                                 San Jose, CA 95131
                                 USA
                     EMail:      randy_presuhn@bmc.com
                     phone:      +1 408-546-1006

                     Co-editor:  Bert Wijnen
                                 Lucent Technologies
                     postal:     Schagen 33
                                 3461 GL Linschoten
                                 Netherlands
                     EMail:      bwijnen@lucent.com
                     phone:      +31 348-680-485
                    "
       DESCRIPTION  "The MIB for Message Processing and Dispatching

                     Copyright (C) The Internet Society (2002). This
                     version of this MIB module is part of RFC 3412;
                     see the RFC itself for full legal notices.
                    "
       REVISION     "200210140000Z"            -- 14 October 2002
       DESCRIPTION  "Updated addresses, published as RFC 3412."
       REVISION     "199905041636Z"            -- 4 May 1999
       DESCRIPTION  "Updated addresses, published as RFC 2572."




Case, et al.                Standards Track                    [Page 17]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


       REVISION     "199709300000Z"            -- 30 September 1997
       DESCRIPTION  "Original version, published as RFC 2272."
       ::= { snmpModules 11 }

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

   snmpMPDAdmin           OBJECT IDENTIFIER ::= { snmpMPDMIB 1 }
   snmpMPDMIBObjects      OBJECT IDENTIFIER ::= { snmpMPDMIB 2 }
   snmpMPDMIBConformance  OBJECT IDENTIFIER ::= { snmpMPDMIB 3 }

   -- Statistics for SNMP Messages *************************************

   snmpMPDStats           OBJECT IDENTIFIER ::= { snmpMPDMIBObjects 1 }

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

   snmpInvalidMsgs OBJECT-TYPE
       SYNTAX       Counter32
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The total number of packets received by the SNMP
                    engine which were dropped because there were invalid
                    or inconsistent components in the SNMP message.
                   "
       ::= { snmpMPDStats 2 }

   snmpUnknownPDUHandlers OBJECT-TYPE
       SYNTAX       Counter32
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The total number of packets received by the SNMP
                    engine which were dropped because the PDU contained
                    in the packet could not be passed to an application
                    responsible for handling the pduType, e.g. no SNMP
                    application had registered for the proper
                    combination of the contextEngineID and the pduType.
                   "
       ::= { snmpMPDStats 3 }




Case, et al.                Standards Track                    [Page 18]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


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

   snmpMPDMIBCompliances OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 1}
   snmpMPDMIBGroups      OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 2}

   -- Compliance statements

   snmpMPDCompliance MODULE-COMPLIANCE
       STATUS       current
       DESCRIPTION "The compliance statement for SNMP entities which
                    implement the SNMP-MPD-MIB.
                   "
       MODULE    -- this module
           MANDATORY-GROUPS { snmpMPDGroup }
       ::= { snmpMPDMIBCompliances 1 }

   snmpMPDGroup OBJECT-GROUP
       OBJECTS {
                 snmpUnknownSecurityModels,
                 snmpInvalidMsgs,
                 snmpUnknownPDUHandlers
               }
       STATUS       current
       DESCRIPTION "A collection of objects providing for remote
                    monitoring of the SNMP Message Processing and
                    Dispatching process.
                   "
       ::= { snmpMPDMIBGroups 1 }

   END

6.  The SNMPv3 Message Format

   This section defines the SNMPv3 message format and the corresponding
   SNMP version 3 Message Processing Model (v3MP).

   SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN

       SNMPv3Message ::= SEQUENCE {
           -- identify the layout of the SNMPv3Message
           -- this element is in same position as in SNMPv1
           -- and SNMPv2c, allowing recognition
           -- the value 3 is used for snmpv3
           msgVersion INTEGER ( 0 .. 2147483647 ),
           -- administrative parameters
           msgGlobalData HeaderData,
           -- security model-specific parameters
           -- format defined by Security Model



Case, et al.                Standards Track                    [Page 19]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


           msgSecurityParameters OCTET STRING,
           msgData  ScopedPduData
       }

       HeaderData ::= SEQUENCE {
           msgID      INTEGER (0..2147483647),
           msgMaxSize INTEGER (484..2147483647),

           msgFlags   OCTET STRING (SIZE(1)),
                      --  .... ...1   authFlag
                      --  .... ..1.   privFlag
                      --  .... .1..   reportableFlag
                      --              Please observe:
                      --  .... ..00   is OK, means noAuthNoPriv
                      --  .... ..01   is OK, means authNoPriv
                      --  .... ..10   reserved, MUST NOT be used.
                      --  .... ..11   is OK, means authPriv

           msgSecurityModel INTEGER (1..2147483647)
       }

       ScopedPduData ::= CHOICE {
           plaintext    ScopedPDU,
           encryptedPDU OCTET STRING  -- encrypted scopedPDU value
       }

       ScopedPDU ::= SEQUENCE {
           contextEngineID  OCTET STRING,
           contextName      OCTET STRING,
           data             ANY -- e.g., PDUs as defined in [RFC3416]
       }
   END

6.1.  msgVersion

   The msgVersion field is set to snmpv3(3) and identifies the message
   as an SNMP version 3 Message.

6.2.  msgID

   The msgID is used between two SNMP entities to coordinate request
   messages and responses, and by the v3MP to coordinate the processing
   of the message by different subsystem models within the architecture.

   Values for msgID SHOULD be generated in a manner that avoids re-use
   of any outstanding values.  Doing so provides protection against some
   replay attacks.  One possible implementation strategy would be to use
   the low-order bits of snmpEngineBoots [RFC3411] as the high-order



Case, et al.                Standards Track                    [Page 20]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   portion of the msgID value and a monotonically increasing integer for
   the low-order portion of msgID.

   Note that the request-id in a PDU may be used by SNMP applications to
   identify the PDU; the msgID is used by the engine to identify the
   message which carries a PDU.  The engine needs to identify the
   message even if decryption of the PDU (and request-id) fails.  No
   assumption should be made that the value of the msgID and the value
   of the request-id are equivalent.

   The value of the msgID field for a response takes the value of the
   msgID field from the message to which it is a response.  By use of
   the msgID value, an engine can distinguish the (potentially multiple)
   outstanding requests, and thereby correlate incoming responses with
   outstanding requests.  In cases where an unreliable datagram service
   is used, the msgID also provides a simple means of identifying
   messages duplicated by the network.  If a request is retransmitted, a
   new msgID value SHOULD be used for each retransmission.

6.3.  msgMaxSize

   The msgMaxSize field of the message conveys the maximum message size
   supported by the sender of the message, i.e., the maximum message
   size that the sender can accept when another SNMP engine sends an
   SNMP message (be it a response or any other message) to the sender of
   this message on the transport in use for this message.

   When an SNMP message is being generated, the msgMaxSize is provided
   by the SNMP engine which generates the message.  At the receiving
   SNMP engine, the msgMaxSize is used to determine the maximum message
   size the sender can accommodate.

6.4.  msgFlags

   The msgFlags field of the message contains several bit fields which
   control processing of the message.

   The reportableFlag is a secondary aid in determining whether a Report
   PDU MUST be sent.  It is only used in cases where the PDU portion of
   a message cannot be decoded, due to, for example, an incorrect
   encryption key.  If the PDU can be decoded, the PDU type forms the
   basis for decisions on sending Report PDUs.

   When the reportableFlag is used, if its value is one, a Report PDU
   MUST be returned to the sender under those conditions which can cause
   the generation of Report PDUs.  Similarly, when the reportableFlag is
   used and its value is zero, then a Report PDU MUST NOT be sent.  The
   reportableFlag MUST always be zero when the message contains a PDU



Case, et al.                Standards Track                    [Page 21]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   from the Unconfirmed Class, such as a Report PDU, a response-type PDU
   (such as a Response PDU), or an unacknowledged notification-type PDU
   (such as an SNMPv2-trap PDU).  The reportableFlag MUST always be one
   for a PDU from the Confirmed Class, including request-type PDUs (such
   as a Get PDU) and acknowledged notification-type PDUs (such as an
   Inform PDU).

   If the reportableFlag is set to one for a message containing a PDU
   from the Unconfirmed Class, such as a Report PDU, a response-type PDU
   (such as a Response PDU), or an unacknowledged notification-type PDU
   (such as an SNMPv2-trap PDU), then the receiver of that message MUST
   process it as though the reportableFlag had been set to zero.

   If the reportableFlag is set to zero for a message containing a
   request-type PDU (such as a Get PDU) or an acknowledged
   notification-type PDU (such as an Inform PDU), then the receiver of
   that message MUST process it as though the reportableFlag had been
   set to one.

   Report PDUs are generated directly by the SNMPv3 Message Processing
   Model, and support engine-to-engine communications, but may be passed
   to applications for processing.

   An SNMP engine that receives a reportPDU may use it to determine what
   kind of problem was detected by the remote SNMP engine.  It can do so
   based on the error counter included as the first (and only) varBind
   of the reportPDU.  Based on the detected error, the SNMP engine may
   try to send a corrected SNMP message.  If that is not possible, it
   may pass an indication of the error to the application on whose
   behalf the failed SNMP request was issued.

   The authFlag and privFlag portions of the msgFlags field are set by
   the sender to indicate the securityLevel that was applied to the
   message before it was sent on the wire.  The receiver of the message
   MUST apply the same securityLevel when the message is received and
   the contents are being processed.

   There are three securityLevels, namely noAuthNoPriv, which is less
   than authNoPriv, which is in turn less than authPriv.  See the SNMP
   architecture document [RFC3411] for details about the securityLevel.

   a) authFlag

      If the authFlag is set to one, then the securityModel used by the
      SNMP engine which sent the message MUST identify the securityName
      on whose behalf the SNMP message was generated and MUST provide,
      in a securityModel-specific manner, sufficient data for the
      receiver of the message to be able to authenticate that



Case, et al.                Standards Track                    [Page 22]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


      identification.  In general, this authentication will allow the
      receiver to determine with reasonable certainty that the message
      was:

      -  sent on behalf of the principal associated with the
         securityName,

      -  was not redirected,

      -  was not modified in transit, and

      -  was not replayed.

      If the authFlag is zero, then the securityModel used by the SNMP
      engine which sent the message MUST identify the securityName on
      whose behalf the SNMP message was generated but it does not need
      to provide sufficient data for the receiver of the message to
      authenticate the identification, as there is no need to
      authenticate the message in this case.

   b) privFlag

      If the privFlag is set, then the securityModel used by the SNMP
      engine which sent the message MUST also protect the scopedPDU in
      an SNMP message from disclosure, i.e., it MUST encrypt/decrypt the
      scopedPDU.  If the privFlag is zero, then the securityModel in use
      does not need to protect the data from disclosure.

      It is an explicit requirement of the SNMP architecture that if
      privacy is selected, then authentication is also required.  That
      means that if the privFlag is set, then the authFlag MUST also be
      set to one.

      The combination of the authFlag and the privFlag comprises a Level
      of Security as follows:

         authFlag zero, privFlag zero -> securityLevel is noAuthNoPriv
         authFlag zero, privFlag one  -> invalid combination, see below
         authFlag one,  privFlag zero -> securityLevel is authNoPriv
         authFlag one,  privFlag one  -> securityLevel is authPriv

   The elements of procedure (see below) describe the action to be taken
   when the invalid combination of authFlag equal to zero and privFlag
   equal to one is encountered.

   The remaining bits in msgFlags are reserved, and MUST be set to zero
   when sending a message and SHOULD be ignored when receiving a
   message.



Case, et al.                Standards Track                    [Page 23]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


6.5.  msgSecurityModel

   The v3MP supports the concurrent existence of multiple Security
   Models to provide security services for SNMPv3 messages.  The
   msgSecurityModel field in an SNMPv3 Message identifies which Security
   Model was used by the sender to generate the message and therefore
   which securityModel MUST be used by the receiver to perform security
   processing for the message.  The mapping to the appropriate
   securityModel implementation within an SNMP engine is accomplished in
   an implementation-dependent manner.

6.6.  msgSecurityParameters

   The msgSecurityParameters field of the SNMPv3 Message is used for
   communication between the Security Model modules in the sending and
   receiving SNMP engines.  The data in the msgSecurityParameters field
   is used exclusively by the Security Model, and the contents and
   format of the data is defined by the Security Model.  This OCTET
   STRING is not interpreted by the v3MP, but is passed to the local
   implementation of the Security Model indicated by the
   msgSecurityModel field in the message.

6.7.  scopedPduData

   The scopedPduData field represents either the plain text scopedPDU if
   the privFlag in the msgFlags is zero, or it represents an
   encryptedPDU (encoded as an OCTET STRING) which MUST be decrypted by
   the securityModel in use to produce a plaintext scopedPDU.

6.8.  scopedPDU

   The scopedPDU contains information to identify an administratively
   unique context and a PDU.  The object identifiers in the PDU refer to
   managed objects which are (expected to be) accessible within the
   specified context.

6.8.1.  contextEngineID

   The contextEngineID in the SNMPv3 message uniquely identifies, within
   an administrative domain, an SNMP entity that may realize an instance
   of a context with a particular contextName.

   For incoming messages, the contextEngineID is used in conjunction
   with the pduType to determine to which application the scopedPDU will
   be sent for processing.

   For outgoing messages, the v3MP sets the contextEngineID to the value
   provided by the application in the request for a message to be sent.



Case, et al.                Standards Track                    [Page 24]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


6.8.2.  contextName

   The contextName field in an SNMPv3 message, in conjunction with the
   contextEngineID field, identifies the particular context associated
   with the management information contained in the PDU portion of the
   message.  The contextName is unique within the SNMP entity specified
   by the contextEngineID, which may realize the managed objects
   referenced within the PDU.  An application which originates a message
   provides the value for the contextName field and this value may be
   used during processing by an application at the receiving SNMP
   Engine.

6.8.3.  data

   The data field of the SNMPv3 Message contains the PDU.  Among other
   things, the PDU contains the PDU type that is used by the v3MP to
   determine the type of the incoming SNMP message.  The v3MP specifies
   that the PDU MUST be one of those specified in [RFC3416].

7.  Elements of Procedure for v3MP

   This section describes the procedures followed by an SNMP engine when
   generating and processing SNMP messages according to the SNMPv3
   Message Processing Model.

   Please note, that for the sake of clarity and to prevent the text
   from being even longer and more complicated, some details were
   omitted from the steps below.

      a) Some steps specify that when some error conditions are
         encountered when processing a received message, a message
         containing a Report PDU is generated and the received message
         is discarded without further processing.  However, a Report-PDU
         MUST NOT be generated unless the PDU causing generation of the
         Report PDU can be determined to be a member of the Confirmed
         Class, or the reportableFlag is set to one and the PDU class
         cannot be determined.

      b) The elements of procedure do not always explicitly indicate
         when state information needs to be released.  The general rule
         is that if state information is available when a message is to
         be "discarded without further processing", then the state
         information should also be released at that same time.








Case, et al.                Standards Track                    [Page 25]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


7.1.  Prepare an Outgoing SNMP Message

   This section describes the procedure followed to prepare an SNMPv3
   message from the data elements passed by the Message Dispatcher.

   1) The Message Dispatcher may request that an SNMPv3 message
      containing a Read Class, Write Class, or Notification Class PDU be
      prepared for sending.

      a) It makes such a request according to the abstract service
         primitive:

         statusInformation =           -- success or errorIndication
           prepareOutgoingMessage(
           IN   transportDomain        -- requested transport domain
           IN   transportAddress       -- requested destination address
           IN   messageProcessingModel -- typically, SNMP version
           IN   securityModel          -- Security Model to use
           IN   securityName           -- on behalf of this principal
           IN   securityLevel          -- Level of Security requested
           IN   contextEngineID        -- data from/at this entity
           IN   contextName            -- data from/in this context
           IN   pduVersion             -- version of the PDU *
           IN   PDU                    -- SNMP Protocol Data Unit
           IN   expectResponse         -- TRUE or FALSE *
           IN   sendPduHandle          -- the handle for matching
                                       -- incoming responses
           OUT  destTransportDomain    -- destination transport domain
           OUT  destTransportAddress   -- destination transport address
           OUT  outgoingMessage        -- the message to send
           OUT  outgoingMessageLength  -- the length of the message
           )

      *  The SNMPv3 Message Processing Model does not use the values of
         expectResponse or pduVersion.

      b) A unique msgID is generated.  The number used for msgID should
         not have been used recently, and MUST NOT be the same as was
         used for any outstanding request.

   2) The Message Dispatcher may request that an SNMPv3 message
      containing a Response Class or Internal Class PDU be prepared for
      sending.








Case, et al.                Standards Track                    [Page 26]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


      a) It makes such a request according to the abstract service
         primitive:

         result =                       -- SUCCESS or FAILURE
         prepareResponseMessage(
          IN   messageProcessingModel   -- typically, SNMP version
          IN   securityModel            -- same as on incoming request
          IN   securityName             -- same as on incoming request
          IN   securityLevel            -- same as on incoming request
          IN   contextEngineID          -- data from/at this SNMP entity
          IN   contextName              -- data from/in this context
          IN   pduVersion               -- version of the PDU
          IN   PDU                      -- SNMP Protocol Data Unit
          IN   maxSizeResponseScopedPDU -- maximum size sender can
                                        -- accept
          IN   stateReference           -- reference to state
                                        -- information presented with
                                        -- the request
          IN   statusInformation        -- success or errorIndication
                                        -- error counter OID and value
                                        -- when errorIndication
          OUT  destTransportDomain      -- destination transport domain
          OUT  destTransportAddress     -- destination transport address
          OUT  outgoingMessage          -- the message to send
          OUT  outgoingMessageLength    -- the length of the message
          )

      b) The cached information for the original request is retrieved
         via the stateReference, including:

               - msgID,
               - contextEngineID,
               - contextName,
               - securityModel,
               - securityName,
               - securityLevel,
               - securityStateReference,
               - reportableFlag,
               - transportDomain, and
               - transportAddress.

         The SNMPv3 Message Processing Model does not allow cached data
         to be overridden, except by error indications as detailed in
         (3) below.







Case, et al.                Standards Track                    [Page 27]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   3) If statusInformation contains values for an OID/value combination
      (potentially also containing a securityLevel value,
      contextEngineID value, or contextName value), then:

      a) If a PDU is provided, it is the PDU from the original request.
         If possible, extract the request-id and pduType.

      b) If the pduType is determined to not be a member of the
         Confirmed Class, or if the reportableFlag is zero and the
         pduType cannot be determined, then the original message is
         discarded, and no further processing is done.  A result of
         FAILURE is returned.  SNMPv3 Message Processing is complete.

      c) A Report PDU is prepared:

         1) the varBindList is set to contain the OID and value from the
            statusInformation.

         2) error-status is set to 0.

         3) error-index is set to 0.

         4) request-id is set to the value extracted in step b).
            Otherwise, request-id is set to 0.

      d) The errorIndication in statusInformation may be accompanied by
         a securityLevel value, a contextEngineID value, or a
         contextName value.

         1) If statusInformation contains a value for securityLevel,
            then securityLevel is set to that value, otherwise it is set
            to noAuthNoPriv.

         2) If statusInformation contains a value for contextEngineID,
            then contextEngineID is set to that value, otherwise it is
            set to the value of this entity's snmpEngineID.

         3) If statusInformation contains a value for contextName, then
            contextName is set to that value, otherwise it is set to the
            default context of "" (zero-length string).

      e) PDU is set to refer to the new Report-PDU.  The old PDU is
         discarded.

      f) Processing continues with step 6) below.






Case, et al.                Standards Track                    [Page 28]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   4) If the contextEngineID is not yet determined, then the
      contextEngineID is determined, in an implementation-dependent
      manner, possibly using the transportDomain and transportAddress.

   5) If the contextName is not yet determined, the contextName is set
      to the default context.

   6) A scopedPDU is prepared from the contextEngineID, contextName, and
      PDU.

   7) msgGlobalData is constructed as follows:

      a) The msgVersion field is set to snmpv3(3).

      b) msgID is set as determined in step 1 or 2 above.

      c) msgMaxSize is set to an implementation-dependent value.

      d) msgFlags are set as follows:

         -  If securityLevel specifies noAuthNoPriv, then authFlag and
            privFlag are both set to zero.

         -  If securityLevel specifies authNoPriv, then authFlag is set
            to one and privFlag is set to zero.

         -  If securityLevel specifies authPriv, then authFlag is set to
            one and privFlag is set to one.

         -  If the PDU is from the Unconfirmed Class, then the
            reportableFlag is set to zero.

         -  If the PDU is from the Confirmed Class then the
            reportableFlag is set to one.

         -  All other msgFlags bits are set to zero.

      e) msgSecurityModel is set to the value of securityModel.













Case, et al.                Standards Track                    [Page 29]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   8) If the PDU is from the Response Class or the Internal Class, then:

      a) The specified Security Model is called to generate the message
         according to the primitive:

         statusInformation =
           generateResponseMsg(
           IN   messageProcessingModel -- SNMPv3 Message Processing
                                       -- Model
           IN   globalData             -- msgGlobalData from step 7
           IN   maxMessageSize         -- from msgMaxSize (step 7c)
           IN   securityModel          -- as determined in step 7e
           IN   securityEngineID       -- the value of snmpEngineID
           IN   securityName           -- on behalf of this principal
           IN   securityLevel          -- for the outgoing message
           IN   scopedPDU              -- as prepared in step 6)
           IN   securityStateReference -- as determined in step 2
           OUT  securityParameters     -- filled in by Security Module
           OUT  wholeMsg               -- complete generated message
           OUT  wholeMsgLength         -- length of generated message
           )

         If, upon return from the Security Model, the statusInformation
         includes an errorIndication, then any cached information about
         the outstanding request message is discarded, and an
         errorIndication is returned, so it can be returned to the
         calling application.  SNMPv3 Message Processing is complete.

      b) A SUCCESS result is returned.  SNMPv3 Message Processing is
         complete.

   9) If the PDU is from the Confirmed Class or the Notification Class,
      then:

      a) If the PDU is from the Unconfirmed Class, then securityEngineID
         is set to the value of this entity's snmpEngineID.

         Otherwise, the snmpEngineID of the target entity is determined,
         in an implementation-dependent manner, possibly using
         transportDomain and transportAddress.  The value of the
         securityEngineID is set to the value of the target entity's
         snmpEngineID.









Case, et al.                Standards Track                    [Page 30]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


      b) The specified Security Model is called to generate the message
         according to the primitive:

         statusInformation =
          generateRequestMsg(
          IN  messageProcessingModel -- SNMPv3 Message Processing Model
          IN  globalData             -- msgGlobalData, from step 7
          IN  maxMessageSize         -- from msgMaxSize in step 7 c)
          IN  securityModel          -- as provided by caller
          IN  securityEngineID       -- authoritative SNMP entity
                                     -- from step 9 a)
          IN  securityName           -- as provided by caller
          IN  securityLevel          -- as provided by caller
          IN  scopedPDU              -- as prepared in step 6
          OUT securityParameters     -- filled in by Security Module
          OUT wholeMsg               -- complete generated message
          OUT wholeMsgLength         -- length of the generated message
          )

         If, upon return from the Security Model, the statusInformation
         includes an errorIndication, then the message is discarded, and
         the errorIndication is returned, so it can be returned to the
         calling application, and no further processing is done.  SNMPv3
         Message Processing is complete.

      c) If the PDU is from the Confirmed Class, information about the
         outgoing message is cached, and an implementation-specific
         stateReference is created.  Information to be cached includes
         the values of:

               - sendPduHandle
               - msgID
               - snmpEngineID
               - securityModel
               - securityName
               - securityLevel
               - contextEngineID
               - contextName

      d) A SUCCESS result is returned.  SNMPv3 Message Processing is
         complete.










Case, et al.                Standards Track                    [Page 31]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


7.2.  Prepare Data Elements from an Incoming SNMP Message

   This section describes the procedure followed to extract data from an
   SNMPv3 message, and to prepare the data elements required for further
   processing of the message by the Message Dispatcher.

   1)  The message is passed in from the Message Dispatcher according to
       the abstract service primitive:

       result =                       -- SUCCESS or errorIndication
         prepareDataElements(
         IN  transportDomain          -- origin transport domain
         IN  transportAddress         -- origin transport address
         IN  wholeMsg                 -- as received from the network
         IN  wholeMsgLength           -- as received from the network
         OUT messageProcessingModel   -- typically, SNMP version
         OUT securityModel            -- Security Model to use
         OUT securityName             -- on behalf of this principal
         OUT securityLevel            -- Level of Security requested
         OUT contextEngineID          -- data from/at this entity
         OUT contextName              -- data from/in this context
         OUT pduVersion               -- version of the PDU
         OUT PDU                      -- SNMP Protocol Data Unit
         OUT pduType                  -- SNMP PDU type
         OUT sendPduHandle            -- handle for matched request
         OUT maxSizeResponseScopedPDU -- maximum size sender can accept
         OUT statusInformation        -- success or errorIndication
                                      -- error counter OID and value
                                      -- when errorIndication
         OUT stateReference           -- reference to state information
                                      -- to be used for a possible
         )                            -- Response

   2)  If the received message is not the serialization (according to
       the conventions of [RFC3417]) of an SNMPv3Message value, then the
       snmpInASNParseErrs counter [RFC3418] is incremented, the message
       is discarded without further processing, and a FAILURE result is
       returned.  SNMPv3 Message Processing is complete.

   3)  The values for msgVersion, msgID, msgMaxSize, msgFlags,
       msgSecurityModel, msgSecurityParameters, and msgData are
       extracted from the message.

   4)  If the value of the msgSecurityModel component does not match a
       supported securityModel, then the snmpUnknownSecurityModels
       counter is incremented, the message is discarded without further
       processing, and a FAILURE result is returned.  SNMPv3 Message
       Processing is complete.



Case, et al.                Standards Track                    [Page 32]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   5)  The securityLevel is determined from the authFlag and the
       privFlag bits of the msgFlags component as follows:

       a) If the authFlag is not set and the privFlag is not set, then
          securityLevel is set to noAuthNoPriv.

       b) If the authFlag is set and the privFlag is not set, then
          securityLevel is set to authNoPriv.

       c) If the authFlag is set and the privFlag is set, then
          securityLevel is set to authPriv.

       d) If the authFlag is not set and privFlag is set, then the
          snmpInvalidMsgs counter is incremented, the message is
          discarded without further processing, and a FAILURE result is
          returned.  SNMPv3 Message Processing is complete.

       e) Any other bits in the msgFlags are ignored.

   6)  The security module implementing the Security Model as specified
       by the securityModel component is called for authentication and
       privacy services.  This is done according to the abstract service
       primitive:

       statusInformation =            -- errorIndication or success
                                      -- error counter OID and
                                      -- value if error
         processIncomingMsg(
         IN  messageProcessingModel   -- SNMPv3 Message Processing Model
         IN  maxMessageSize           -- of the sending SNMP entity
         IN  securityParameters       -- for the received message
         IN  securityModel            -- for the received message
         IN  securityLevel            -- Level of Security
         IN  wholeMsg                 -- as received on the wire
         IN  wholeMsgLength           -- length as received on the wire
         OUT securityEngineID         -- authoritative SNMP entity
         OUT securityName             -- identification of the principal
         OUT scopedPDU,               -- message (plaintext) payload
         OUT maxSizeResponseScopedPDU -- maximum size sender can accept
         OUT securityStateReference   -- reference to security state
         )                            -- information, needed for
                                      -- response

       If an errorIndication is returned by the security module, then:

       a) If statusInformation contains values for an OID/value pair,
          then generation of a Report PDU is attempted (see step 3 in
          section 7.1).



Case, et al.                Standards Track                    [Page 33]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


          1) If the scopedPDU has been returned from processIncomingMsg,
             then determine contextEngineID, contextName, and PDU.

          2) Information about the message is cached and a
             stateReference is created (implementation-specific).
             Information to be cached includes the values of:

                          msgVersion,
                          msgID,
                          securityLevel,
                          msgFlags,
                          msgMaxSize,
                          securityModel,
                          maxSizeResponseScopedPDU,
                          securityStateReference

          3) Request that a Report-PDU be prepared and sent, according
             to the abstract service primitive:

             result =                     -- SUCCESS or FAILURE
             returnResponsePdu(
             IN  messageProcessingModel   -- SNMPv3(3)
             IN  securityModel            -- same as on incoming request
             IN  securityName             -- from processIncomingMsg
             IN  securityLevel            -- same as on incoming request
             IN  contextEngineID          -- from step 6 a) 1)
             IN  contextName              -- from step 6 a) 1)
             IN  pduVersion               -- SNMPv2-PDU
             IN  PDU                      -- from step 6 a) 1)
             IN  maxSizeResponseScopedPDU -- from processIncomingMsg
             IN  stateReference           -- from step 6 a) 2)
             IN  statusInformation        -- from processIncomingMsg
             )

       b) The incoming message is discarded without further processing,
          and a FAILURE result is returned.  SNMPv3 Message Processing
          is complete.

   7)  The scopedPDU is parsed to extract the contextEngineID, the
       contextName and the PDU.  If any parse error occurs, then the
       snmpInASNParseErrs counter [RFC3418] is incremented, the security
       state information is discarded, the message is discarded without
       further processing, and a FAILURE result is returned.  SNMPv3
       Message Processing is complete.  Treating an unknown PDU type is
       treated as a parse error is an implementation option.






Case, et al.                Standards Track                    [Page 34]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   8)  The pduVersion is determined in an implementation-dependent
       manner.  For SNMPv3, the pduVersion would be an SNMPv2-PDU.

   9)  The pduType is determined, in an implementation-dependent manner.
       For [RFC3416], the pduTypes include:

               - GetRequest-PDU,
               - GetNextRequest-PDU,
               - GetBulkRequest-PDU,
               - SetRequest-PDU,
               - InformRequest-PDU,
               - SNMPv2-Trap-PDU,
               - Response-PDU,
               - Report-PDU.

   10) If the pduType is from the Response Class or the Internal Class,
       then:

       a) The value of the msgID component is used to find the cached
          information for a corresponding outstanding Request message.
          If no such outstanding Request message is found, then the
          security state information is discarded, the message is
          discarded without further processing, and a FAILURE result is
          returned.  SNMPv3 Message Processing is complete.

       b) sendPduHandle is retrieved from the cached information.

       Otherwise, sendPduHandle is set to <none>, an implementation
       defined value.

   11) If the pduType is from the Internal Class, then:

       a) statusInformation is created using the contents of the
          Report-PDU, in an implementation-dependent manner.  This
          statusInformation will be forwarded to the application
          associated with the sendPduHandle.

       b) The cached data for the outstanding message, referred to by
          stateReference, is retrieved.  If the securityModel or
          securityLevel values differ from the cached ones, it is
          important to recognize that Internal Class PDUs delivered at
          the security level of noAuthNoPriv open a window of
          opportunity for spoofing or replay attacks.  If the receiver
          of such messages is aware of these risks, the use of such
          unauthenticated messages is acceptable and may provide a
          useful function for discovering engine IDs or for detecting
          misconfiguration at remote nodes.




Case, et al.                Standards Track                    [Page 35]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


          When the securityModel or securityLevel values differ from the
          cached ones, an implementation may retain the cached
          information about the outstanding Request message, in
          anticipation of the possibility that the Internal Class PDU
          received might be illegitimate.  Otherwise, any cached
          information about the outstanding Request message is
          discarded.

       c) The security state information for this incoming message is
          discarded.

       d) stateReference is set to <none>.

       e) A SUCCESS result is returned.  SNMPv3 Message Processing is
          complete.

   12) If the pduType is from the Response Class, then:

       a) The cached data for the outstanding request, referred to by
          stateReference, is retrieved, including:

               - snmpEngineID
               - securityModel
               - securityName
               - securityLevel
               - contextEngineID
               - contextName

       b) If the values extracted from the incoming message differ from
          the cached data, then any cached information about the
          outstanding Request message is discarded, the incoming message
          is discarded without further processing, and a FAILURE result
          is returned.  SNMPv3 Message Processing is complete.

          When the securityModel or securityLevel values differ from the
          cached ones, an implementation may retain the cached
          information about the outstanding Request message, in
          anticipation of the possibility that the Response Class PDU
          received might be illegitimate.

       c) Otherwise, any cached information about the outstanding
          Request message is discarded, and the stateReference is set to
          <none>.

       d) A SUCCESS result is returned.  SNMPv3 Message Processing is
          complete.

   13) If the pduType is from the Confirmed Class, then:



Case, et al.                Standards Track                    [Page 36]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


       a) If the value of securityEngineID is not equal to the value of
          snmpEngineID, then the security state information is
          discarded, any cached information about this message is
          discarded, the incoming message is discarded without further
          processing, and a FAILURE result is returned.  SNMPv3 Message
          Processing is complete.

       b) Information about the message is cached and a stateReference
          is created (implementation-specific).  Information to be
          cached includes the values of:

                msgVersion,
                msgID,
                securityLevel,
                msgFlags,
                msgMaxSize,
                securityModel,
                maxSizeResponseScopedPDU,
                securityStateReference

       c) A SUCCESS result is returned.  SNMPv3 Message Processing is
          complete.

   14) If the pduType is from the Unconfirmed Class, then a SUCCESS
       result is returned.  SNMPv3 Message Processing is complete.

8.  Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.




Case, et al.                Standards Track                    [Page 37]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


9.  Acknowledgements

   This document is the result of the efforts of the SNMPv3 Working
   Group.  Some special thanks are in order to the following SNMPv3 WG
   members:

      Harald Tveit Alvestrand (Maxware)
      Dave Battle (SNMP Research, Inc.)
      Alan Beard (Disney Worldwide Services)
      Paul Berrevoets (SWI Systemware/Halcyon Inc.)
      Martin Bjorklund (Ericsson)
      Uri Blumenthal (IBM T. J. Watson Research Center)
      Jeff Case (SNMP Research, Inc.)
      John Curran (BBN)
      Mike Daniele (Compaq Computer Corporation)
      T. Max Devlin (Eltrax Systems)
      John Flick (Hewlett Packard)
      Rob Frye (MCI)
      Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.)
      David Harrington (Cabletron Systems Inc.)
      Lauren Heintz (BMC Software, Inc.)
      N.C. Hien (IBM T. J. Watson Research Center)
      Michael Kirkham (InterWorking Labs, Inc.)
      Dave Levi (SNMP Research, Inc.)
      Louis A Mamakos (UUNET Technologies Inc.)
      Joe Marzot (Nortel Networks)
      Paul Meyer (Secure Computing Corporation)
      Keith McCloghrie (Cisco Systems)
      Bob Moore (IBM)
      Russ Mundy (TIS Labs at Network Associates)
      Bob Natale (ACE*COMM Corporation)
      Mike O'Dell (UUNET Technologies Inc.)
      Dave Perkins (DeskTalk)
      Peter Polkinghorne (Brunel University)
      Randy Presuhn (BMC Software, Inc.)
      David Reeder (TIS Labs at Network Associates)
      David Reid (SNMP Research, Inc.)
      Aleksey Romanov (Quality Quorum)
      Shawn Routhier (Epilogue)
      Juergen Schoenwaelder (TU Braunschweig)
      Bob Stewart (Cisco Systems)
      Mike Thatcher (Independent Consultant)
      Bert Wijnen (IBM T. J. Watson Research Center)








Case, et al.                Standards Track                    [Page 38]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   The document is based on recommendations of the IETF Security and
   Administrative Framework Evolution for SNMP Advisory Team.  Members
   of that Advisory Team were:

      David Harrington (Cabletron Systems Inc.)
      Jeff Johnson (Cisco Systems)
      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 Center)

   As recommended by the Advisory Team and the SNMPv3 Working Group
   Charter, the design incorporates as much as practical from previous
   RFCs and drafts.  As a result, special thanks are due to the authors
   of previous designs known as SNMPv2u and SNMPv2*:

      Jeff Case (SNMP Research, Inc.)
      David Harrington (Cabletron Systems Inc.)
      David Levi (SNMP Research, Inc.)
      Keith McCloghrie (Cisco Systems)
      Brian O'Keefe (Hewlett Packard)
      Marshall T. Rose (Dover Beach Consulting)
      Jon Saperia (BGS Systems Inc.)
      Steve Waldbusser (International Network Services)
      Glenn W. Waters (Bell-Northern Research Ltd.)

10.  Security Considerations

   The Dispatcher coordinates the processing of messages to provide a
   level of security for management messages and to direct the SNMP PDUs
   to the proper SNMP application(s).

   A Message Processing Model, and in particular the v3MP defined in
   this document, interacts as part of the Message Processing with
   Security Models in the Security Subsystem via the abstract service
   interface primitives defined in [RFC3411] and elaborated above.

   The level of security actually provided is primarily determined by
   the specific Security Model implementation(s) and the specific SNMP
   application implementation(s) incorporated into this framework.
   Applications have access to data which is not secured.  Applications
   should take reasonable steps to protect the data from disclosure, and
   when they send data across the network, they should obey the
   securityLevel and call upon the services of an Access Control Model
   as they apply access control.




Case, et al.                Standards Track                    [Page 39]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   The values for the msgID element used in communication between SNMP
   entities MUST be chosen to avoid replay attacks.  The values do not
   need to be unpredictable; it is sufficient that they not repeat.

   When exchanges are carried out over an insecure network, there is an
   open opportunity for a third party to spoof or replay messages when
   any message of an exchange is given at the security level of
   noAuthNoPriv.  For most exchanges, all messages exist at the same
   security level.  In the case where the final message is an Internal
   Class PDU, this message may be delivered at a level of noAuthNoPriv
   or authNoPriv, independent of the security level of the preceding
   messages.  Internal Class PDUs delivered at the level of authNoPriv
   are not considered to pose a security hazard.  Internal Class PDUs
   delivered at the security level of noAuthNoPriv open a window of
   opportunity for spoofing or replay attacks.  If the receiver of such
   messages is aware of these risks, the use of such unauthenticated
   messages is acceptable and may provide a useful function for
   discovering engine IDs or for detecting misconfiguration at remote
   nodes.

   This document also contains a MIB definition module.  None of the
   objects defined is writable, and the information they represent is
   not deemed to be particularly sensitive.  However, if they are deemed
   sensitive in a particular environment, access to them should be
   restricted through the use of appropriately configured Security and
   Access Control models.

11.  References

11.1.  Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Structure of Management
               Information Version 2 (SMIv2)", STD 58, RFC 2578, April
               1999.

   [RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Conformance Statements for
               SMIv2", STD 58, RFC 2580, April 1999.

   [RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An
               Architecture for Describing Simple Network Management
               Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
               December 2002.




Case, et al.                Standards Track                    [Page 40]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


   [RFC3413]   Levi, D., Meyer, P. and B. Stewart, "Simple Network
               Management Protocol (SNMP) Applications", STD 62, RFC
               3413, December 2002.

   [RFC3414]   Blumenthal, U. and B. Wijnen, "The User-Based Security
               Model (USM) for Version 3 of the Simple Network
               Management Protocol (SNMPv3)", STD 62, RFC 3414, December
               2002.

   [RFC3415]   Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model (VACM) for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3415, December
               2002.

   [RFC3416]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
               Waldbusser, "Version 2 of the Protocol Operations for the
               Simple Network Management Protocol (SNMP)", STD 62, RFC
               3416, December 2002.

   [RFC3417]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
               Waldbusser, "Transport Mappings for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3417, December
               2002.

   [RFC3418]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
               Waldbusser, "Management Information Base (MIB) for the
               Simple Network Management Protocol (SNMP)", STD 62, RFC
               3418, December 2002.

11.2.  Informative References

   [RFC1901]   Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
               "Introduction to Community-based SNMPv2", RFC 1901,
               January 1996.

   [RFC2028]   Hovey, R. and S. Bradner, "The Organizations Involved in
               the IETF Standards Process", BCP 11, RFC 2028, October
               1996.

   [RFC2576]   Frye, R., Levi, D., Routhier, S. and B. Wijnen,
               "Coexistence between Version 1, Version 2, and Version 3
               of the Internet-Standard Network Management Framework",
               RFC 2576, March 2000.

   [RFC3410]   Case, J., Mundy, R., Partain, D. and B. Stewart,
               "Introduction and Applicability Statements for Internet-
               Standard Management Framework", RFC 3410, December 2002.




Case, et al.                Standards Track                    [Page 41]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


12.  Editors' Addresses

   Jeffrey Case
   SNMP Research, Inc.
   3001 Kimberlin Heights Road
   Knoxville, TN 37920-9716
   USA

   Phone: +1 423-573-1434
   EMail: case@snmp.com


   David Harrington
   Enterasys Networks
   35 Industrial Way
   Post Office Box 5005
   Rochester, NH 03866-5005
   USA

   Phone: +1 603-337-2614
   EMail: dbh@enterasys.com


   Randy Presuhn
   BMC Software, Inc.
   2141 North First Street
   San Jose, CA 95131
   USA

   Phone: +1 408-546-1006
   EMail: randy_presuhn@bmc.com


   Bert Wijnen
   Lucent Technologies
   Schagen 33
   3461 GL Linschoten
   Netherlands

   Phone: +31 348-680-485
   EMail: bwijnen@lucent.com










Case, et al.                Standards Track                    [Page 42]


RFC 3412      Message Processing and Dispatching for SNMP  December 2002


13.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Case, et al.                Standards Track                    [Page 43]

========================================================================






Network Working Group                                            D. Levi
Request for Comments: 3413                               Nortel Networks
STD: 62                                                         P. Meyer
Obsoletes: 2573                             Secure Computing Corporation
Category: Standards Track                                     B. Stewart
                                                                 Retired
                                                           December 2002


         Simple Network Management Protocol (SNMP) Applications

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes five types of Simple Network Management
   Protocol (SNMP) applications which make use of an SNMP engine as
   described in STD 62, RFC 3411.  The types of application described
   are Command Generators, Command Responders, Notification Originators,
   Notification Receivers, and Proxy Forwarders.

   This document also defines Management Information Base (MIB) modules
   for specifying targets of management operations, for notification
   filtering, and for proxy forwarding.  This document obsoletes RFC
   2573.

Table of Contents

   1       Overview ...............................................    2
   1.1     Command Generator Applications .........................    3
   1.2     Command Responder Applications .........................    3
   1.3     Notification Originator Applications ...................    3
   1.4     Notification Receiver Applications .....................    3
   1.5     Proxy Forwarder Applications ...........................    4
   2       Management Targets .....................................    5
   3       Elements Of Procedure ..................................    6
   3.1     Command Generator Applications .........................    6
   3.2     Command Responder Applications .........................    9
   3.3     Notification Originator Applications ...................   14
   3.4     Notification Receiver Applications .....................   17
   3.5     Proxy Forwarder Applications ...........................   19
   3.5.1   Request Forwarding .....................................   21



Levi, et. al.               Standards Track                     [Page 1]


RFC 3413                   SNMP Applications               December 2002


   3.5.1.1 Processing an Incoming Request .........................   21
   3.5.1.2 Processing an Incoming Response ........................   24
   3.5.1.3 Processing an Incoming Internal-Class PDU ..............   25
   3.5.2   Notification Forwarding ................................   26
   4       The Structure of the MIB Modules .......................   29
   4.1     The Management Target MIB Module .......................   29
   4.1.1   Tag Lists .....................,........................   29
   4.1.2   Definitions ..................,.........................   30
   4.2     The Notification MIB Module ............................   44
   4.2.1   Definitions ............................................   44
   4.3     The Proxy MIB Module ...................................   56
   4.3.1   Definitions ............................................   57
   5       Identification of Management Targets in
           Notification Originators ...............................   63
   6       Notification Filtering .................................   64
   7       Management Target Translation in
           Proxy Forwarder Applications ...........................   65
   7.1     Management Target Translation for
           Request Forwarding .....................................   65
   7.2     Management Target Translation for
           Notification Forwarding ................................   66
   8       Intellectual Property ..................................   67
   9       Acknowledgments ........................................   67
   10      Security Considerations ................................   69
   11      References .............................................   69
   A.      Trap Configuration Example .............................   71
           Editors' Addresses .....................................   73
           Full Copyright Statement ...............................   74

1. Overview

   This document describes five types of SNMP applications:

   - Applications which initiate SNMP Read-Class, and/or Write-Class
     requests, called 'command generators.'

   - Applications which respond to SNMP Read-Class, and/or Write-Class
     requests, called 'command responders.'

   - Applications which generate SNMP Notification-Class PDUs, called
     'notification originators.'

   - Applications which receive SNMP Notification-Class PDUs, called
     'notification receivers.'

   - Applications which forward SNMP messages, called 'proxy
     forwarders.'




Levi, et. al.               Standards Track                     [Page 2]


RFC 3413                   SNMP Applications               December 2002


   Note that there are no restrictions on which types of applications
   may be associated with a particular SNMP engine.  For example, a
   single SNMP engine may, in fact, be associated with both command
   generator and command responder applications.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.1. Command Generator Applications

   A command generator application initiates SNMP Read-Class and/or
   Write-Class requests, and processes responses to requests which it
   generated.

1.2. Command Responder Applications

   A command responder application receives SNMP Read-Class and/or
   Write-Class requests destined for the local system as indicated by
   the fact that the contextEngineID in the received request is equal to
   that of the local engine through which the request was received.  The
   command responder application will perform the appropriate protocol
   operation, using access control, and will generate a response message
   to be sent to the request's originator.

1.3. Notification Originator Applications

   A notification originator application conceptually monitors a system
   for particular events or conditions, and generates Notification-Class
   messages based on these events or conditions.  A notification
   originator must have a mechanism for determining where to send
   messages, and what SNMP version and security parameters to use when
   sending messages.  A mechanism and MIB module for this purpose is
   provided in this document.  Note that Notification-Class PDUs
   generated by a notification originator may be either Confirmed-Class
   or Unconfirmed-Class PDU types.

1.4. Notification Receiver Applications

   A notification receiver application listens for notification
   messages, and generates response messages when a message containing a
   Confirmed-Class PDU is received.









Levi, et. al.               Standards Track                     [Page 3]


RFC 3413                   SNMP Applications               December 2002


1.5. Proxy Forwarder Applications

   A proxy forwarder application forwards SNMP messages.  Note that
   implementation of a proxy forwarder application is optional.  The
   sections describing proxy (3.5, 4.3, and 7) may be skipped for
   implementations that do not include a proxy forwarder application.

   The term "proxy" has historically been used very loosely, with
   multiple different meanings.  These different meanings include (among
   others):

   (1) the forwarding of SNMP requests to other SNMP entities without
       regard for what managed object types are being accessed; for
       example, in order to forward an SNMP request from one transport
       domain to another, or to translate SNMP requests of one version
       into SNMP requests of another version;

   (2) the translation of SNMP requests into operations of some non-SNMP
       management protocol; and

   (3) support for aggregated managed objects where the value of one
       managed object instance depends upon the values of multiple other
       (remote) items of management information.

   Each of these scenarios can be advantageous; for example, support for
   aggregation of management information can significantly reduce the
   bandwidth requirements of large-scale management activities.

   However, using a single term to cover multiple different scenarios
   causes confusion.

   To avoid such confusion, this document uses the term "proxy" with a
   much more tightly defined meaning.  The term "proxy" is used in this
   document to refer to a proxy forwarder application which forwards
   either SNMP messages without regard for what managed objects are
   contained within those messages.  This definition is most closely
   related to the first definition above.  Note, however, that in the
   SNMP architecture [RFC3411], a proxy forwarder is actually an
   application, and need not be associated with what is traditionally
   thought of as an SNMP agent.

   Specifically, the distinction between a traditional SNMP agent and a
   proxy forwarder application is simple:








Levi, et. al.               Standards Track                     [Page 4]


RFC 3413                   SNMP Applications               December 2002


   - a proxy forwarder application forwards SNMP messages to other SNMP
     engines according to the context, and irrespective of the specific
     managed object types being accessed, and forwards the response to
     such previously forwarded messages back to the SNMP engine from
     which the original message was received;

   - in contrast, the command responder application that is part of what
     is traditionally thought of as an SNMP agent, and which processes
     SNMP requests according to the (names of the) individual managed
     object types and instances being accessed, is NOT a proxy forwarder
     application from the perspective of this document.

   Thus, when a proxy forwarder application forwards a request or
   notification for a particular contextEngineID / contextName pair, not
   only is the information on how to forward the request specifically
   associated with that context, but the proxy forwarder application has
   no need of a detailed definition of a MIB view (since the proxy
   forwarder application forwards the request irrespective of the
   managed object types).

   In contrast, a command responder application must have the detailed
   definition of the MIB view, and even if it needs to issue requests to
   other entities, via SNMP or otherwise, that need is dependent on the
   individual managed object instances being accessed (i.e., not only on
   the context).

   Note that it is a design goal of a proxy forwarder application to act
   as an intermediary between the endpoints of a transaction.  In
   particular, when forwarding Confirmed Notification-Class messages,
   the associated response is forwarded when it is received from the
   target to which the Notification-Class message was forwarded, rather
   than generating a response immediately when the Notification-Class
   message is received.

2. Management Targets

   Some types of applications (notification generators and proxy
   forwarders in particular) require a mechanism for determining where
   and how to send generated messages.  This document provides a
   mechanism and MIB module for this purpose.  The set of information
   that describes where and how to send a message is called a
   'Management Target', and consists of two kinds of information:

   - Destination information, consisting of a transport domain and a
     transport address.  This is also termed a transport endpoint.

   - SNMP parameters, consisting of message processing model, security
     model, security level, and security name information.



Levi, et. al.               Standards Track                     [Page 5]


RFC 3413                   SNMP Applications               December 2002


   The SNMP-TARGET-MIB module described later in this document contains
   one table for each of these types of information.  There can be a
   many-to-many relationship in the MIB between these two types of
   information.  That is, there may be multiple transport endpoints
   associated with a particular set of SNMP parameters, or a particular
   transport endpoint may be associated with several sets of SNMP
   parameters.

3. Elements Of Procedure

   The following sections describe the procedures followed by each type
   of application when generating messages for transmission or when
   processing received messages.  Applications communicate with the
   Dispatcher using the abstract service interfaces defined in
   [RFC3411].

3.1. Command Generator Applications

   A command generator initiates an SNMP request by calling the
   Dispatcher using the following abstract service interface:

      statusInformation =              -- sendPduHandle if success
                                       -- errorIndication if failure
        sendPdu(
        IN   transportDomain           -- transport domain to be used
        IN   transportAddress          -- destination network address
        IN   messageProcessingModel    -- typically, SNMP version
        IN   securityModel             -- Security Model to use
        IN   securityName              -- on behalf of this principal
        IN   securityLevel             -- Level of Security requested
        IN   contextEngineID           -- data from/at this entity
        IN   contextName               -- data from/in this context
        IN   pduVersion                -- the version of the PDU
        IN   PDU                       -- SNMP Protocol Data Unit
        IN   expectResponse            -- TRUE or FALSE
             )

   Where:

   - The transportDomain is that of the destination of the message.

   - The transportAddress is that of the destination of the message.

   - The messageProcessingModel indicates which Message Processing Model
     the application wishes to use.

   - The securityModel is the security model that the application wishes
     to use.



Levi, et. al.               Standards Track                     [Page 6]


RFC 3413                   SNMP Applications               December 2002


   - The securityName is the security model independent name for the
     principal on whose behalf the application wishes the message to be
     generated.

   - The securityLevel is the security level that the application wishes
     to use.

   - The contextEngineID specifies the location of the management
     information it is requesting.  Note that unless the request is
     being sent to a proxy, this value will usually be equal to the
     snmpEngineID value of the engine to which the request is being
     sent.

   - The contextName specifies the local context name for the management
     information it is requesting.

   - The pduVersion indicates the version of the PDU to be sent.

   - The PDU is a value constructed by the command generator containing
     the management operation that the command generator wishes to
     perform.

   - The expectResponse argument indicates that a response is expected.

   The result of the sendPdu interface indicates whether the PDU was
   successfully sent.  If it was successfully sent, the returned value
   will be a sendPduHandle.  The command generator should store the
   sendPduHandle so that it can correlate a response to the original
   request.

   The Dispatcher is responsible for delivering the response to a
   particular request to the correct command generator application.  The
   abstract service interface used is:

      processResponsePdu(              -- process Response PDU
        IN   messageProcessingModel    -- typically, SNMP version
        IN   securityModel             -- Security Model in use
        IN   securityName              -- on behalf of this principal
        IN   securityLevel             -- Level of Security
        IN   contextEngineID           -- data from/at this SNMP entity
        IN   contextName               -- data from/in this context
        IN   pduVersion                -- the version of the PDU
        IN   PDU                       -- SNMP Protocol Data Unit
        IN   statusInformation         -- success or errorIndication
        IN   sendPduHandle             -- handle from sendPdu
             )





Levi, et. al.               Standards Track                     [Page 7]


RFC 3413                   SNMP Applications               December 2002


   Where:

   - The messageProcessingModel is the value from the received response.

   - The securityModel is the value from the received response.

   - The securityName is the value from the received response.

   - The securityLevel is the value from the received response.

   - The contextEngineID is the value from the received response.

   - The contextName is the value from the received response.

   - The pduVersion indicates the version of the PDU in the received
     response.

   - The PDU is the value from the received response.

   - The statusInformation indicates success or failure in receiving the
     response.

   - The sendPduHandle is the value returned by the sendPdu call which
     generated the original request to which this is a response.

   The procedure when a command generator receives a message is as
   follows:

   (1) If the received values of messageProcessingModel, securityModel,
       securityName, contextEngineID, contextName, and pduVersion are
       not all equal to the values used in the original request, the
       response is discarded.

   (2) The operation type, request-id, error-status, error-index, and
       variable-bindings are extracted from the PDU and saved.  If the
       request-id is not equal to the value used in the original
       request, the response is discarded.

   (3) At this point, it is up to the application to take an appropriate
       action.  The specific action is implementation dependent.  If the
       statusInformation indicates that the request failed, an
       appropriate action might be to attempt to transmit the request
       again, or to notify the person operating the application that a
       failure occurred.







Levi, et. al.               Standards Track                     [Page 8]


RFC 3413                   SNMP Applications               December 2002


3.2. Command Responder Applications

   Before a command responder application can process messages, it must
   first associate itself with an SNMP engine.  The abstract service
   interface used for this purpose is:

      statusInformation =       -- success or errorIndication
       registerContextEngineID(
       IN   contextEngineID     -- take responsibility for this one
       IN   pduType             -- the pduType(s) to be registered
            )

   Where:

   - The statusInformation indicates success or failure of the
     registration attempt.

   - The contextEngineID is equal to the snmpEngineID of the SNMP engine
     with which the command responder is registering.

   - The pduType indicates a Read-Class and/or Write-Class PDU.

   Note that if another command responder application is already
   registered with an SNMP engine, any further attempts to register with
   the same contextEngineID and pduType will be denied.  This implies
   that separate command responder applications could register
   separately for the various pdu types.  However, in practice this is
   undesirable, and only a single command responder application should
   be registered with an SNMP engine at any given time.

   A command responder application can disassociate with an SNMP engine
   using the following abstract service interface:

      unregisterContextEngineID(
        IN   contextEngineID     -- give up responsibility for this one
        IN   pduType             -- the pduType(s) to be unregistered
             )

   Where:

   - The contextEngineID is equal to the snmpEngineID of the SNMP engine
     with which the command responder is cancelling the registration.

   - The pduType indicates a Read-Class and/or Write-Class PDU.







Levi, et. al.               Standards Track                     [Page 9]


RFC 3413                   SNMP Applications               December 2002


   Once the command responder has registered with the SNMP engine, it
   waits to receive SNMP messages.  The abstract service interface used
   for receiving messages is:

   processPdu(                     -- process Request/Notification PDU
     IN   messageProcessingModel   -- typically, SNMP version
     IN   securityModel            -- Security Model in use
     IN   securityName             -- on behalf of this principal
     IN   securityLevel            -- Level of Security
     IN   contextEngineID          -- data from/at this SNMP entity
     IN   contextName              -- data from/in this context
     IN   pduVersion               -- the version of the PDU
     IN   PDU                      -- SNMP Protocol Data Unit
     IN   maxSizeResponseScopedPDU -- maximum size of the Response PDU
     IN   stateReference           -- reference to state information
          )                        -- needed when sending a response

   Where:

   - The messageProcessingModel indicates which Message Processing Model
     received and processed the message.

   - The securityModel is the value from the received message.

   - The securityName is the value from the received message.

   - The securityLevel is the value from the received message.

   - The contextEngineID is the value from the received message.

   - The contextName is the value from the received message.

   - The pduVersion indicates the version of the PDU in the received
     message.

   - The PDU is the value from the received message.

   - The maxSizeResponseScopedPDU is the maximum allowable size of a
     ScopedPDU containing a Response PDU (based on the maximum message
     size that the originator of the message can accept).

   - The stateReference is a value which references cached information
     about each received request message.  This value must be returned
     to the Dispatcher in order to generate a response.







Levi, et. al.               Standards Track                    [Page 10]


RFC 3413                   SNMP Applications               December 2002


   The procedure when a message is received is as follows:

   (1) The operation type is determined from the ASN.1 tag value
       associated with the PDU parameter.  The operation type should
       always be one of the types previously registered by the
       application.

   (2) The request-id is extracted from the PDU and saved.

   (3) Any PDU type specific parameters are extracted from the PDU and
       saved (for example, if the PDU type is an SNMPv2 GetBulk PDU, the
       non-repeaters and max-repetitions values are extracted).

   (4) The variable-bindings are extracted from the PDU and saved.

   (5) The management operation represented by the PDU type is performed
       with respect to the relevant MIB view within the context named by
       the contextName (for an SNMPv2 PDU type, the operation is
       performed according to the procedures set forth in [RFC1905]).
       The relevant MIB view is determined by the securityLevel,
       securityModel, contextName, securityName, and the class of the
       PDU type.  To determine whether a particular object instance is
       within the relevant MIB view, the following abstract service
       interface is called:

          statusInformation =      -- success or errorIndication
            isAccessAllowed(
            IN   securityModel     -- Security Model in use
            IN   securityName      -- principal who wants to access
            IN   securityLevel     -- Level of Security
            IN   viewType          -- read, write, or notify view
            IN   contextName       -- context containing variableName
            IN   variableName      -- OID for the managed object
                 )

       Where:

       - The securityModel is the value from the received message.

       - The securityName is the value from the received message.

       - The securityLevel is the value from the received message.

       - The viewType indicates whether the PDU type is a Read-Class or
         Write-Class operation.

       - The contextName is the value from the received message.




Levi, et. al.               Standards Track                    [Page 11]


RFC 3413                   SNMP Applications               December 2002


       - The variableName is the object instance of the variable for
         which access rights are to be checked.

       Normally, the result of the management operation will be a new
       PDU value, and processing will continue in step (6) below.
       However, at any time during the processing of the management
       operation:

       - If the isAccessAllowed ASI returns a noSuchView, noAccessEntry,
         or noGroupName error, processing of the management operation is
         halted, a PDU value is constructed using the values from the
         originally received PDU, but replacing the error-status with an
         authorizationError code, and error-index value of 0, and
         control is passed to step (6) below.

       - If the isAccessAllowed ASI returns an otherError, processing of
         the management operation is halted, a different PDU value is
         constructed using the values from the originally received PDU,
         but replacing the error-status with a genError code and the
         error-index with the index of the failed variable binding, and
         control is passed to step (6) below.

       - If the isAccessAllowed ASI returns a noSuchContext error,
         processing of the management operation is halted, no result PDU
         is generated, the snmpUnknownContexts counter is incremented,
         and control is passed to step (6) below for generation of a
         report message.

       - If the context named by the contextName parameter is
         unavailable, processing of the management operation is halted,
         no result PDU is generated, the snmpUnavailableContexts counter
         is incremented, and control is passed to step (6) below for
         generation of a report message.

   (6) The Dispatcher is called to generate a response or report
       message.  The abstract service interface is:















Levi, et. al.               Standards Track                    [Page 12]


RFC 3413                   SNMP Applications               December 2002


returnResponsePdu(
  IN   messageProcessingModel   -- typically, SNMP version
  IN   securityModel            -- Security Model in use
  IN   securityName             -- on behalf of this principal
  IN   securityLevel            -- same as on incoming request
  IN   contextEngineID          -- data from/at this SNMP entity
  IN   contextName              -- data from/in this context
  IN   pduVersion               -- the version of the PDU
  IN   PDU                      -- SNMP Protocol Data Unit
  IN   maxSizeResponseScopedPDU -- maximum size of the Response PDU
  IN   stateReference           -- reference to state information
                                -- as presented with the request
  IN   statusInformation        -- success or errorIndication
       )                        -- error counter OID/value if error

   Where:

       - The messageProcessingModel is the value from the processPdu
         call.

       - The securityModel is the value from the processPdu call.

       - The securityName is the value from the processPdu call.

       - The securityLevel is the value from the processPdu call.

       - The contextEngineID is the value from the processPdu call.

       - The contextName is the value from the processPdu call.

       - The pduVersion indicates the version of the PDU to be returned.
         If no result PDU was generated, the pduVersion is an undefined
         value.

       - The PDU is the result generated in step (5) above.  If no
         result PDU was generated, the PDU is an undefined value.

       - The maxSizeResponseScopedPDU is a local value indicating the
         maximum size of a ScopedPDU that the application can accept.

       - The stateReference is the value from the processPdu call.

       - The statusInformation either contains an indication that no
         error occurred and that a response should be generated, or
         contains an indication that an error occurred along with the
         OID and counter value of the appropriate error counter object.





Levi, et. al.               Standards Track                    [Page 13]


RFC 3413                   SNMP Applications               December 2002


   Note that a command responder application should always call the
   returnResponsePdu abstract service interface, even in the event of an
   error such as a resource allocation error.  In the event of such an
   error, the PDU value passed to returnResponsePdu should contain
   appropriate values for errorStatus and errorIndex.

   Note that the text above describes situations where the
   snmpUnknownContexts counter is incremented, and where the
   snmpUnavailableContexts counter is incremented.  The difference
   between these is that the snmpUnknownContexts counter is incremented
   when a request is received for a context which is unknown to the SNMP
   entity.  The snmpUnavailableContexts counter is incremented when a
   request is received for a context which is known to the SNMP entity,
   but is currently unavailable.  Determining when a context is
   unavailable is implementation specific, and some implementations may
   never encounter this situation, and so may never increment the
   snmpUnavailableContexts counter.

3.3. Notification Originator Applications

   A notification originator application generates SNMP messages
   containing Notification-Class PDUs (for example, SNMPv2-Trap PDUs or
   Inform PDUs).  There is no requirement as to what specific types of
   Notification-Class PDUs a particular implementation must be capable
   of generating.

   Notification originator applications require a mechanism for
   identifying the management targets to which notifications should be
   sent.  The particular mechanism used is implementation dependent.
   However, if an implementation makes the configuration of management
   targets SNMP manageable, it MUST use the SNMP-TARGET-MIB module
   described in this document.

   When a notification originator wishes to generate a notification, it
   must first determine in which context the information to be conveyed
   in the notification exists, i.e., it must determine the
   contextEngineID and contextName.  It must then determine the set of
   management targets to which the notification should be sent.  The
   application must also determine, for each management target, what
   specific PDU type the notification message should contain, and if it
   is to contain a Confirmed-Class PDU, the number of retries and
   retransmission algorithm.









Levi, et. al.               Standards Track                    [Page 14]


RFC 3413                   SNMP Applications               December 2002


   The mechanism by which a notification originator determines this
   information is implementation dependent.  Once the application has
   determined this information, the following procedure is performed for
   each management target:

   (1) Any appropriate filtering mechanisms are applied to determine
       whether the notification should be sent to the management target.
       If such filtering mechanisms determine that the notification
       should not be sent, processing continues with the next management
       target.  Otherwise,

   (2) The appropriate set of variable-bindings is retrieved from local
       MIB instrumentation within the relevant MIB view.  The relevant
       MIB view is determined by the securityLevel, securityModel,
       contextName, and securityName of the management target.  To
       determine whether a particular object instance is within the
       relevant MIB view, the isAccessAllowed abstract service interface
       is used, in the same manner as described in the preceding
       section, except that the viewType indicates a Notification-Class
       operation.  If the statusInformation returned by isAccessAllowed
       does not indicate accessAllowed, the notification is not sent to
       the management target.

   (3) The NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (this
       is the value of the element of the variable bindings whose name
       is snmpTrapOID.0, i.e., the second variable binding) is checked
       using the isAccessAllowed abstract service interface, using the
       same parameters used in the preceding step.  If the
       statusInformation returned by isAccessAllowed does not indicate
       accessAllowed, the notification is not sent to the management
       target.

   (4) A PDU is constructed using a locally unique request-id value, a
       PDU type as determined by the implementation, an error-status and
       error-index value of 0, and the variable-bindings supplied
       previously in step (2).

   (5) If the notification contains an Unconfirmed-Class PDU, the
       Dispatcher is called using the following abstract service
       interface:











Levi, et. al.               Standards Track                    [Page 15]


RFC 3413                   SNMP Applications               December 2002


       statusInformation =              -- sendPduHandle if success
                                        -- errorIndication if failure
         sendPdu(
         IN   transportDomain           -- transport domain to be used
         IN   transportAddress          -- destination network address
         IN   messageProcessingModel    -- typically, SNMP version
         IN   securityModel             -- Security Model to use
         IN   securityName              -- on behalf of this principal
         IN   securityLevel             -- Level of Security requested
         IN   contextEngineID           -- data from/at this entity
         IN   contextName               -- data from/in this context
         IN   pduVersion                -- the version of the PDU
         IN   PDU                       -- SNMP Protocol Data Unit
         IN   expectResponse            -- TRUE or FALSE
              )

       Where:

       - The transportDomain is that of the management target.

       - The transportAddress is that of the management target.

       - The messageProcessingModel is that of the management target.

       - The securityModel is that of the management target.

       - The securityName is that of the management target.

       - The securityLevel is that of the management target.

       - The contextEngineID is the value originally determined for the
         notification.

       - The contextName is the value originally determined for the
         notification.

       - The pduVersion is the version of the PDU to be sent.

       - The PDU is the value constructed in step (4) above.

       - The expectResponse argument indicates that no response is
         expected.

       Otherwise,







Levi, et. al.               Standards Track                    [Page 16]


RFC 3413                   SNMP Applications               December 2002


   (6) If the notification contains a Confirmed-Class PDU, then:

       a) The Dispatcher is called using the sendPdu abstract service
          interface as described in step (5) above, except that the
          expectResponse argument indicates that a response is expected.

       b) The application caches information about the management
          target.

       c) If a response is received within an appropriate time interval
          from the transport endpoint of the management target, the
          notification is considered acknowledged and the cached
          information is deleted.  Otherwise,

       d) If a response is not received within an appropriate time
          period, or if a report indication is received, information
          about the management target is retrieved from the cache, and
          steps a) through d) are repeated.  The number of times these
          steps are repeated is equal to the previously determined retry
          count.  If this retry count is exceeded, the acknowledgement
          of the notification is considered to have failed, and
          processing of the notification for this management target is
          halted.  Note that some report indications might be considered
          a failure.  Such report indications should be interpreted to
          mean that the acknowledgement of the notification has failed,
          and that steps a) through d) need not be repeated.

   Responses to Confirmed-Class PDU notifications will be received via
   the processResponsePdu abstract service interface.

   To summarize, the steps that a notification originator follows when
   determining where to send a notification are:

   - Determine the targets to which the notification should be sent.

   - Apply any required filtering to the list of targets.

   - Determine which targets are authorized to receive the notification.

3.4. Notification Receiver Applications

   Notification receiver applications receive SNMP Notification messages
   from the Dispatcher.  Before any messages can be received, the
   notification receiver must register with the Dispatcher using the
   registerContextEngineID abstract service interface.  The parameters
   used are:





Levi, et. al.               Standards Track                    [Page 17]


RFC 3413                   SNMP Applications               December 2002


   - The contextEngineID is an undefined 'wildcard' value.
     Notifications are delivered to a registered notification receiver
     regardless of the contextEngineID contained in the notification
     message.

   - The pduType indicates the type of notifications that the
     application wishes to receive (for example, SNMPv2-Trap PDUs or
     Inform PDUs).

   Once the notification receiver has registered with the Dispatcher,
   messages are received using the processPdu abstract service
   interface.  Parameters are:

   - The messageProcessingModel indicates which Message Processing Model
     received and processed the message.

   - The securityModel is the value from the received message.

   - The securityName is the value from the received message.

   - The securityLevel is the value from the received message.

   - The contextEngineID is the value from the received message.

   - The contextName is the value from the received message.

   - The pduVersion indicates the version of the PDU in the received
     message.

   - The PDU is the value from the received message.

   - The maxSizeResponseScopedPDU is the maximum allowable size of a
     ScopedPDU containing a Response PDU (based on the maximum message
     size that the originator of the message can accept).

   - If the message contains an Unconfirmed-Class PDU, the
     stateReference is undefined and unused.  Otherwise, the
     stateReference is a value which references cached information about
     the notification.  This value must be returned to the Dispatcher in
     order to generate a response.

   When an Unconfirmed-Class PDU is delivered to a notification receiver
   application, it first extracts the SNMP operation type, request-id,
   error-status, error-index, and variable-bindings from the PDU.  After
   this, processing depends on the particular implementation.






Levi, et. al.               Standards Track                    [Page 18]


RFC 3413                   SNMP Applications               December 2002


   When a Confirmed-Class PDU is received, the notification receiver
   application follows the following procedure:

   (1) The PDU type, request-id, error-status, error-index, and
       variable-bindings are extracted from the PDU.

   (2) A Response-Class PDU is constructed using the extracted
       request-id and variable-bindings, and with error-status and
       error-index both set to 0.

   (3) The Dispatcher is called to generate a response message using the
       returnResponsePdu abstract service interface.  Parameters are:

       - The messageProcessingModel is the value from the processPdu
         call.

       - The securityModel is the value from the processPdu call.

       - The securityName is the value from the processPdu call.

       - The securityLevel is the value from the processPdu call.

       - The contextEngineID is the value from the processPdu call.

       - The contextName is the value from the processPdu call.

       - The pduVersion indicates the version of the PDU to be returned.

       - The PDU is the result generated in step (2) above.

       - The maxSizeResponseScopedPDU is a local value indicating the
         maximum size of a ScopedPDU that the application can accept.

       - The stateReference is the value from the processPdu call.

       - The statusInformation indicates that no error occurred and that
         a response should be generated.

   (4) After this, processing depends on the particular implementation.

3.5. Proxy Forwarder Applications

   A proxy forwarder application deals with forwarding SNMP messages.
   There are four basic types of messages which a proxy forwarder
   application may need to forward.  These are grouped according to the
   class of PDU type contained in a message.  The four basic types of
   messages are:




Levi, et. al.               Standards Track                    [Page 19]


RFC 3413                   SNMP Applications               December 2002


   - Those containing Read-Class or Write-Class PDU types (for example,
     Get, GetNext, GetBulk, and Set PDU types).  These deal with
     requesting or modifying information located within a particular
     context.

   - Those containing Notification-Class PDU types (for example,
     SNMPv2-Trap and Inform PDU types).  These deal with notifications
     concerning information located within a particular context.

   - Those containing a Response-Class PDU type.  Forwarding of
     Response-Class PDUs always occurs as a result of receiving a
     response to a previously forwarded message.

   - Those containing Internal-Class PDU types (for example, a Report
     PDU).  Forwarding of Internal-Class PDU types always occurs as a
     result of receiving an Internal-Class PDU in response to a
     previously forwarded message.

   For the first type, the proxy forwarder's role is to deliver a
   request for management information to an SNMP engine which is
   "closer" or "downstream in the path" to the SNMP engine which has
   access to that information, and to deliver the response containing
   the information back to the SNMP engine from which the request was
   received.  The context information in a request is used to determine
   which SNMP engine has access to the requested information, and this
   is used to determine where and how to forward the request.

   For the second type, the proxy forwarder's role is to determine which
   SNMP engines should receive notifications about management
   information from a particular location.  The context information in a
   notification message determines the location to which the information
   contained in the notification applies.  This is used to determine
   which SNMP engines should receive notification about this
   information.

   For the third type, the proxy forwarder's role is to determine which
   previously forwarded request or notification (if any) the response
   matches, and to forward the response back to the initiator of the
   request or notification.

   For the fourth type, the proxy forwarder's role is to determine which
   previously forwarded request or notification (if any) the Internal-
   Class PDU matches, and to forward the Internal-Class PDU back to the
   initiator of the request or notification.







Levi, et. al.               Standards Track                    [Page 20]


RFC 3413                   SNMP Applications               December 2002


   When forwarding messages, a proxy forwarder application must perform
   a translation of incoming management target information into outgoing
   management target information.  How this translation is performed is
   implementation specific.  In many cases, this will be driven by a
   preconfigured translation table.  If a proxy forwarder application
   makes the contents of this table SNMP manageable, it MUST use the
   SNMP-PROXY-MIB module defined in this document.

3.5.1. Request Forwarding

   There are two phases for request forwarding.  First, the incoming
   request needs to be passed through the proxy application.  Then, the
   resulting response needs to be passed back.  These phases are
   described in the following two sections.

3.5.1.1. Processing an Incoming Request

   A proxy forwarder application that wishes to forward request messages
   must first register with the Dispatcher using the
   registerContextEngineID abstract service interface.  The proxy
   forwarder must register each contextEngineID for which it wishes to
   forward messages, as well as for each pduType.  Note that as the
   configuration of a proxy forwarder is changed, the particular
   contextEngineID values for which it is forwarding may change.  The
   proxy forwarder should call the registerContextEngineID and
   unregisterContextEngineID abstract service interfaces as needed to
   reflect its current configuration.

   A proxy forwarder application should never attempt to register a
   value of contextEngineID which is equal to the snmpEngineID of the
   SNMP engine to which the proxy forwarder is associated.

   Once the proxy forwarder has registered for the appropriate
   contextEngineID values, it can start processing messages.  The
   following procedure is used:

   (1) A message is received using the processPdu abstract service
       interface.  The incoming management target information received
       from the processPdu interface is translated into outgoing
       management target information.  Note that this translation may
       vary for different values of contextEngineID and/or contextName.
       The translation should result in a single management target.

   (2) If appropriate outgoing management target information cannot be
       found, the proxy forwarder increments the snmpProxyDrops counter
       [RFC1907], and then calls the Dispatcher using the
       returnResponsePdu abstract service interface.  Parameters are:




Levi, et. al.               Standards Track                    [Page 21]


RFC 3413                   SNMP Applications               December 2002


       - The messageProcessingModel is the value from the processPdu
         call.

       - The securityModel is the value from the processPdu call.

       - The securityName is the value from the processPdu call.

       - The securityLevel is the value from the processPdu call.

       - The contextEngineID is the value from the processPdu call.

       - The contextName is the value from the processPdu call.

       - The pduVersion is the value from the processPdu call.

       - The PDU is an undefined value.

       - The maxSizeResponseScopedPDU is a local value indicating the
         maximum size of a ScopedPDU that the application can accept.

       - The stateReference is the value from the processPdu call.

       - The statusInformation indicates that an error occurred and
         includes the OID and value of the snmpProxyDrops object.

       Processing of the message stops at this point.  Otherwise,

   (3) A new PDU is constructed.  A unique value of request-id should be
       used in the new PDU (this value will enable a subsequent response
       message to be correlated with this request).  The remainder of
       the new PDU is identical to the received PDU, unless the incoming
       SNMP version and the outgoing SNMP version support different PDU
       versions, in which case the proxy forwarder may need to perform a
       translation on the PDU.  (A method for performing such a
       translation is described in [RFC2576].)

   (4) The proxy forwarder calls the Dispatcher to generate the
       forwarded message, using the sendPdu abstract service interface.
       The parameters are:

       - The transportDomain is that of the outgoing management target.

       - The transportAddress is that of the outgoing management target.

       - The messageProcessingModel is that of the outgoing management
         target.

       - The securityModel is that of the outgoing management target.



Levi, et. al.               Standards Track                    [Page 22]


RFC 3413                   SNMP Applications               December 2002


       - The securityName is that of the outgoing management target.

       - The securityLevel is that of the outgoing management target.

       - The contextEngineID is the value from the processPdu call.

       - The contextName is the value from the processPdu call.

       - The pduVersion is the version of the PDU to be sent.

       - The PDU is the value constructed in step (3) above.

       - The expectResponse argument indicates that a response is
         expected.  If the sendPdu call is unsuccessful, the proxy
         forwarder performs the steps described in (2) above.
         Otherwise:

   (5) The proxy forwarder caches the following information in order to
       match an incoming response to the forwarded request:

       - The sendPduHandle returned from the call to sendPdu,

       - The request-id from the received PDU.

       - The contextEngineID,

       - The contextName,

       - The stateReference,

       - The incoming management target information,

       - The outgoing management information,

       - Any other information needed to match an incoming response to
         the forwarded request.

       If this information cannot be cached (possibly due to a lack of
       resources), the proxy forwarder performs the steps described in
       (2) above.  Otherwise:

   (6) Processing of the request stops until a response to the forwarded
       request is received, or until an appropriate time interval has
       expired.  If this time interval expires before a response has
       been received, the cached information about this request is
       removed.





Levi, et. al.               Standards Track                    [Page 23]


RFC 3413                   SNMP Applications               December 2002


3.5.1.2. Processing an Incoming Response

       A proxy forwarder follows the following procedure when an
       incoming response is received:

   (1) The incoming response is received using the processResponsePdu
       interface.  The proxy forwarder uses the received parameters to
       locate an entry in its cache of pending forwarded requests.  This
       is done by matching the received parameters with the cached
       values of sendPduHandle, contextEngineID, contextName, outgoing
       management target information, and the request-id contained in
       the received PDU (the proxy forwarder must extract the request-id
       for this purpose).  If an appropriate cache entry cannot be
       found, processing of the response is halted.  Otherwise:

   (2) The cache information is extracted, and removed from the cache.

   (3) A new Response-Class PDU is constructed, using the request-id
       value from the original forwarded request (as extracted from the
       cache).  All other values are identical to those in the received
       Response-Class PDU, unless the incoming SNMP version and the
       outgoing SNMP version support different PDU versions, in which
       case the proxy forwarder may need to perform a translation on the
       PDU.  (A method for performing such a translation is described in
       [RFC2576].)

   (4) The proxy forwarder calls the Dispatcher using the
       returnResponsePdu abstract service interface.  Parameters are:

       - The messageProcessingModel indicates the Message Processing
         Model by which the original incoming message was processed.

       - The securityModel is that of the original incoming management
         target extracted from the cache.

       - The securityName is that of the original incoming management
         target extracted from the cache.

       - The securityLevel is that of the original incoming management
         target extracted from the cache.

       - The contextEngineID is the value extracted from the cache.

       - The contextName is the value extracted from the cache.

       - The pduVersion indicates the version of the PDU to be returned.

       - The PDU is the (possibly translated) Response PDU.



Levi, et. al.               Standards Track                    [Page 24]


RFC 3413                   SNMP Applications               December 2002


       - The maxSizeResponseScopedPDU is a local value indicating the
         maximum size of a ScopedPDU that the application can accept.

       - The stateReference is the value extracted from the cache.

       - The statusInformation indicates that no error occurred and that
         a Response PDU message should be generated.

3.5.1.3. Processing an Incoming Internal-Class PDU

   A proxy forwarder follows the following procedure when an incoming
   Internal-Class PDU is received:

   (1) The incoming Internal-Class PDU is received using the
       processResponsePdu interface.  The proxy forwarder uses the
       received parameters to locate an entry in its cache of pending
       forwarded requests.  This is done by matching the received
       parameters with the cached values of sendPduHandle.  If an
       appropriate cache entry cannot be found, processing of the
       Internal-Class PDU is halted.  Otherwise:

   (2) The cache information is extracted, and removed from the cache.

   (3) If the original incoming management target information indicates
       an SNMP version which does not support Report PDUs, processing of
       the Internal-Class PDU is halted.

   (4) The proxy forwarder calls the Dispatcher using the
       returnResponsePdu abstract service interface.  Parameters are:

       - The messageProcessingModel indicates the Message Processing
         Model by which the original incoming message was processed.

       - The securityModel is that of the original incoming management
         target extracted from the cache.

       - The securityName is that of the original incoming management
         target extracted from the cache.

       - The securityLevel is that of the original incoming management
         target extracted from the cache.

       - The contextEngineID is the value extracted from the cache.

       - The contextName is the value extracted from the cache.

       - The pduVersion indicates the version of the PDU to be returned.




Levi, et. al.               Standards Track                    [Page 25]


RFC 3413                   SNMP Applications               December 2002


       - The PDU is unused.

       - The maxSizeResponseScopedPDU is a local value indicating the
         maximum size of a ScopedPDU that the application can accept.

       - The stateReference is the value extracted from the cache.

       - The statusInformation contains values specific to the
         Internal-Class PDU type (for example, for a Report PDU, the
         statusInformation contains the contextEngineID, contextName,
         counter OID, and counter value received in the incoming Report
         PDU).

3.5.2. Notification Forwarding

   A proxy forwarder receives notifications in the same manner as a
   notification receiver application, using the processPdu abstract
   service interface.  The following procedure is used when a
   notification is received:

   (1) The incoming management target information received from the
       processPdu interface is translated into outgoing management
       target information.  Note that this translation may vary for
       different values of contextEngineID and/or contextName.  The
       translation may result in multiple management targets.

   (2) If appropriate outgoing management target information cannot be
       found and the notification was an Unconfirmed-Class PDU,
       processing of the notification is halted.  If appropriate
       outgoing management target information cannot be found and the
       notification was a Confirmed-Class PDU, the proxy forwarder
       increments the snmpProxyDrops object, and calls the Dispatcher
       using the returnResponsePdu abstract service interface.  The
       parameters are:

       - The messageProcessingModel is the value from the processPdu
         call.

       - The securityModel is the value from the processPdu call.

       - The securityName is the value from the processPdu call.

       - The securityLevel is the value from the processPdu call.

       - The contextEngineID is the value from the processPdu call.

       - The contextName is the value from the processPdu call.




Levi, et. al.               Standards Track                    [Page 26]


RFC 3413                   SNMP Applications               December 2002


       - The pduVersion is the value from the processPdu call.

       - The PDU is an undefined and unused value.

       - The maxSizeResponseScopedPDU is a local value indicating the
         maximum size of a ScopedPDU that the application can accept.

       - The stateReference is the value from the processPdu call.

       - The statusInformation indicates that an error occurred and that
         a Report message should be generated.

         Processing of the message stops at this point.  Otherwise,

   (3) The proxy forwarder generates a notification using the procedures
       described in the preceding section on Notification Originators,
       with the following exceptions:

       - The contextEngineID and contextName values from the original
         received notification are used.

       - The outgoing management targets previously determined are used.

       - No filtering mechanisms are applied.

       - The variable-bindings from the original received notification
         are used, rather than retrieving variable-bindings from local
         MIB instrumentation.  In particular, no access-control is
         applied to these variable-bindings, nor to the value of the
         variable-binding containing snmpTrapOID.0.

       - If the original notification contains a Confirmed-Class PDU,
         then any outgoing management targets for which the outgoing
         SNMP version does not support any PDU types that are both
         Notification-Class and Confirmed-Class PDUs will not be used
         when generating the forwarded notifications.

       - If, for any of the outgoing management targets, the incoming
         SNMP version and the outgoing SNMP version support different
         PDU versions, the proxy forwarder may need to perform a
         translation on the PDU.  (A method for performing such a
         translation is described in [RFC2576].)

   (4) If the original received notification contains an
       Unconfirmed-Class PDU, processing of the notification is now
       completed.  Otherwise, the original received notification must
       contain Confirmed-Class PDU, and processing continues.




Levi, et. al.               Standards Track                    [Page 27]


RFC 3413                   SNMP Applications               December 2002


   (5) If the forwarded notifications included any Confirmed-Class PDUs,
       processing continues when the procedures described in the section
       for Notification Originators determine that either:

       - None of the generated notifications containing Confirmed-Class
         PDUs have been successfully acknowledged within the longest of
         the time intervals, in which case processing of the original
         notification is halted, or,

       - At least one of the generated notifications containing
         Confirmed-Class PDUs is successfully acknowledged, in which
         case a response to the original received notification
         containing an Confirmed-Class PDU is generated as described in
         the following steps.

   (6) A Response-Class PDU is constructed, using the values of
       request-id and variable-bindings from the original received
       Notification-Class PDU, and error-status and error-index values
       of 0.

   (7) The Dispatcher is called using the returnResponsePdu abstract
       service interface.  Parameters are:

       - The messageProcessingModel is the value from the processPdu
         call.

       - The securityModel is the value from the processPdu call.

       - The securityName is the value from the processPdu call.

       - The securityLevel is the value from the processPdu call.

       - The contextEngineID is the value from the processPdu call.

       - The contextName is the value from the processPdu call.

       - The pduVersion indicates the version of the PDU constructed in
         step (6) above.

       - The PDU is the value constructed in step (6) above.

       - The maxSizeResponseScopedPDU is a local value indicating the
         maximum size of a ScopedPDU that the application can accept.

       - The stateReference is the value from the processPdu call.

       - The statusInformation indicates that no error occurred and that
         a Response-Class PDU message should be generated.



Levi, et. al.               Standards Track                    [Page 28]


RFC 3413                   SNMP Applications               December 2002


4. The Structure of the MIB Modules

   There are three separate MIB modules described in this document, the
   management target MIB, the notification MIB, and the proxy MIB.  The
   following sections describe the structure of these three MIB modules.

   The use of these MIBs by particular types of applications is
   described later in this document:

   - The use of the management target MIB and the notification MIB in
     notification originator applications is described in section 5.

   - The use of the notification MIB for filtering notifications in
     notification originator applications is described in section 6.

   - The use of the management target MIB and the proxy MIB in proxy
     forwarding applications is described in section 7.

4.1. The Management Target MIB Module

   The SNMP-TARGET-MIB module contains objects for defining management
   targets.  It consists of two tables and conformance/compliance
   statements.

   The first table, the snmpTargetAddrTable, contains information about
   transport domains and addresses.  It also contains an object,
   snmpTargetAddrTagList, which provides a mechanism for grouping
   entries.

   The second table, the snmpTargetParamsTable, contains information
   about SNMP version and security information to be used when sending
   messages to particular transport domains and addresses.

   The Management Target MIB is intended to provide a general-purpose
   mechanism for specifying transport address, and for specifying
   parameters of SNMP messages generated by an SNMP entity.  It is used
   within this document for generation of notifications and for proxy
   forwarding.  However, it may be used for other purposes.  If another
   document makes use of this MIB, that document is responsible for
   specifying how it is used.  For example, [RFC2576] uses this MIB for
   source address validation of SNMPv1 messages.

4.1.1. Tag Lists

   The snmpTargetAddrTagList object is used for grouping entries in the
   snmpTargetAddrTable.  The value of this object contains a list of tag
   values which are used to select target addresses to be used for a
   particular operation.



Levi, et. al.               Standards Track                    [Page 29]


RFC 3413                   SNMP Applications               December 2002


   A tag value, which may also be used in MIB objects other than
   snmpTargetAddrTagList, is an arbitrary string of octets, but may not
   contain a delimiter character.  Delimiter characters are defined to
   be one of the following characters:

   - An ASCII space character (0x20).

   - An ASCII TAB character (0x09).

   - An ASCII carriage return (CR) character (0x0D).

   - An ASCII line feed (LF) character (0x0A).

   In addition, a tag value within a tag list may not have a zero
   length.  Generally, a particular MIB object may contain either

   - a zero-length octet string representing an empty list, or

   - a single tag value, in which case the value of the MIB object may
     not contain a delimiter character, or

   - a list of tag values, separated by single delimiter characters.

     For a list of tag values, these constraints imply certain
     restrictions on the value of a MIB object:

   - There cannot be a leading or trailing delimiter character.

   - There cannot be multiple adjacent delimiter characters.

4.1.2. Definitions

   SNMP-TARGET-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY,
       OBJECT-TYPE,
       snmpModules,
       Counter32,
       Integer32
           FROM SNMPv2-SMI

       TEXTUAL-CONVENTION,
       TDomain,
       TAddress,
       TimeInterval,
       RowStatus,
       StorageType,



Levi, et. al.               Standards Track                    [Page 30]


RFC 3413                   SNMP Applications               December 2002


       TestAndIncr
           FROM SNMPv2-TC

       SnmpSecurityModel,
       SnmpMessageProcessingModel,
       SnmpSecurityLevel,
       SnmpAdminString
           FROM SNMP-FRAMEWORK-MIB

       MODULE-COMPLIANCE,
       OBJECT-GROUP
           FROM SNMPv2-CONF;

   snmpTargetMIB MODULE-IDENTITY
       LAST-UPDATED "200210140000Z"
       ORGANIZATION "IETF SNMPv3 Working Group"
       CONTACT-INFO
           "WG-email:   snmpv3@lists.tislabs.com
            Subscribe:  majordomo@lists.tislabs.com
                        In message body:  subscribe snmpv3

            Co-Chair:   Russ Mundy
                        Network Associates Laboratories
            Postal:     15204 Omega Drive, Suite 300
                        Rockville, MD 20850-4601
                        USA
            EMail:      mundy@tislabs.com
            Phone:      +1 301-947-7107

            Co-Chair:   David Harrington
                        Enterasys Networks
            Postal:     35 Industrial Way
                        P. O. Box 5004
                        Rochester, New Hampshire 03866-5005
                        USA
            EMail:      dbh@enterasys.com
            Phone:      +1 603-337-2614

            Co-editor:  David B. Levi
                        Nortel Networks
            Postal:     3505 Kesterwood Drive
                        Knoxville, Tennessee 37918
            EMail:      dlevi@nortelnetworks.com
            Phone:      +1 865 686 0432

            Co-editor:  Paul Meyer
                        Secure Computing Corporation
            Postal:     2675 Long Lake Road



Levi, et. al.               Standards Track                    [Page 31]


RFC 3413                   SNMP Applications               December 2002


                        Roseville, Minnesota 55113
            EMail:      paul_meyer@securecomputing.com
            Phone:      +1 651 628 1592

            Co-editor:  Bob Stewart
                        Retired"
       DESCRIPTION
           "This MIB module defines MIB objects which provide
            mechanisms to remotely configure the parameters used
            by an SNMP entity for the generation of SNMP messages.

            Copyright (C) The Internet Society (2002). This
            version of this MIB module is part of RFC 3413;
            see the RFC itself for full legal notices.
           "
       REVISION    "200210140000Z"             -- 14 October 2002
       DESCRIPTION "Fixed DISPLAY-HINTS for UTF-8 strings, fixed hex
                    value of LF characters, clarified meaning of zero
                    length tag values, improved tag list examples.
                    Published as RFC 3413."
       REVISION    "199808040000Z"             -- 4 August 1998
       DESCRIPTION "Clarifications, published as
                    RFC 2573."
       REVISION    "199707140000Z"             -- 14 July 1997
       DESCRIPTION "The initial revision, published as RFC2273."
       ::= { snmpModules 12 }

   snmpTargetObjects       OBJECT IDENTIFIER ::= { snmpTargetMIB 1 }
   snmpTargetConformance   OBJECT IDENTIFIER ::= { snmpTargetMIB 3 }

   SnmpTagValue ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "255t"
       STATUS       current
       DESCRIPTION
           "An octet string containing a tag value.
            Tag values are preferably in human-readable form.

            To facilitate internationalization, this information
            is represented using the ISO/IEC IS 10646-1 character
            set, encoded as an octet string using the UTF-8
            character encoding scheme described in RFC 2279.

            Since additional code points are added by amendments
            to the 10646 standard from time to time,
            implementations must be prepared to encounter any code
            point from 0x00000000 to 0x7fffffff.

            The use of control codes should be avoided, and certain



Levi, et. al.               Standards Track                    [Page 32]


RFC 3413                   SNMP Applications               December 2002


            control codes are not allowed as described below.

            For code points not directly supported by user
            interface hardware or software, an alternative means
            of entry and display, such as hexadecimal, may be
            provided.

            For information encoded in 7-bit US-ASCII, the UTF-8
            representation is identical to the US-ASCII encoding.

            Note that when this TC is used for an object that
            is used or envisioned to be used as an index, then a
            SIZE restriction must be specified so that the number
            of sub-identifiers for any object instance does not
            exceed the limit of 128, as defined by [RFC1905].

            An object of this type contains a single tag value
            which is used to select a set of entries in a table.

            A tag value is an arbitrary string of octets, but
            may not contain a delimiter character.  Delimiter
            characters are defined to be one of the following:

                -  An ASCII space character (0x20).

                -  An ASCII TAB character (0x09).

                -  An ASCII carriage return (CR) character (0x0D).

                -  An ASCII line feed (LF) character (0x0A).

            Delimiter characters are used to separate tag values
            in a tag list.  An object of this type may only
            contain a single tag value, and so delimiter
            characters are not allowed in a value of this type.

            Note that a tag value of 0 length means that no tag is
            defined.  In other words, a tag value of 0 length would
            never match anything in a tag list, and would never
            select any table entries.

            Some examples of valid tag values are:

                - 'acme'

                - 'router'

                - 'host'



Levi, et. al.               Standards Track                    [Page 33]


RFC 3413                   SNMP Applications               December 2002


            The use of a tag value to select table entries is
            application and MIB specific."
       SYNTAX       OCTET STRING (SIZE (0..255))

   SnmpTagList ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "255t"
       STATUS       current
       DESCRIPTION
           "An octet string containing a list of tag values.
            Tag values are preferably in human-readable form.

            To facilitate internationalization, this information
            is represented using the ISO/IEC IS 10646-1 character
            set, encoded as an octet string using the UTF-8
            character encoding scheme described in RFC 2279.

            Since additional code points are added by amendments
            to the 10646 standard from time to time,
            implementations must be prepared to encounter any code
            point from 0x00000000 to 0x7fffffff.

            The use of control codes should be avoided, except as
            described below.

            For code points not directly supported by user
            interface hardware or software, an alternative means
            of entry and display, such as hexadecimal, may be
            provided.

            For information encoded in 7-bit US-ASCII, the UTF-8
            representation is identical to the US-ASCII encoding.

            An object of this type contains a list of tag values
            which are used to select a set of entries in a table.

            A tag value is an arbitrary string of octets, but
            may not contain a delimiter character.  Delimiter
            characters are defined to be one of the following:

                -  An ASCII space character (0x20).

                -  An ASCII TAB character (0x09).

                -  An ASCII carriage return (CR) character (0x0D).

                -  An ASCII line feed (LF) character (0x0A).

            Delimiter characters are used to separate tag values



Levi, et. al.               Standards Track                    [Page 34]


RFC 3413                   SNMP Applications               December 2002


            in a tag list.  Only a single delimiter character may
            occur between two tag values.  A tag value may not
            have a zero length.  These constraints imply certain
            restrictions on the contents of this object:

                - There cannot be a leading or trailing delimiter
                  character.

                - There cannot be multiple adjacent delimiter
                  characters.

            Some examples of valid tag lists are:

                - ''                        -- an empty list

                - 'acme'                    -- list of one tag

                - 'host router bridge'      -- list of several tags

            Note that although a tag value may not have a length of
            zero, an empty string is still valid.  This indicates
            an empty list (i.e. there are no tag values in the list).

            The use of the tag list to select table entries is
            application and MIB specific.  Typically, an application
            will provide one or more tag values, and any entry
            which contains some combination of these tag values
            will be selected."
       SYNTAX       OCTET STRING (SIZE (0..255))

   --
   --
   -- The snmpTargetObjects group
   --
   --

   snmpTargetSpinLock OBJECT-TYPE
       SYNTAX      TestAndIncr
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "This object is used to facilitate modification of table
            entries in the SNMP-TARGET-MIB module by multiple
            managers.  In particular, it is useful when modifying
            the value of the snmpTargetAddrTagList object.

            The procedure for modifying the snmpTargetAddrTagList
            object is as follows:



Levi, et. al.               Standards Track                    [Page 35]


RFC 3413                   SNMP Applications               December 2002


                1.  Retrieve the value of snmpTargetSpinLock and
                    of snmpTargetAddrTagList.

                2.  Generate a new value for snmpTargetAddrTagList.

                3.  Set the value of snmpTargetSpinLock to the
                    retrieved value, and the value of
                    snmpTargetAddrTagList to the new value.  If
                    the set fails for the snmpTargetSpinLock
                    object, go back to step 1."
       ::= { snmpTargetObjects 1 }

   snmpTargetAddrTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SnmpTargetAddrEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table of transport addresses to be used in the generation
            of SNMP messages."
       ::= { snmpTargetObjects 2 }

   snmpTargetAddrEntry OBJECT-TYPE
       SYNTAX      SnmpTargetAddrEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A transport address to be used in the generation
            of SNMP operations.

            Entries in the snmpTargetAddrTable are created and
            deleted using the snmpTargetAddrRowStatus object."
       INDEX { IMPLIED snmpTargetAddrName }
       ::= { snmpTargetAddrTable 1 }

   SnmpTargetAddrEntry ::= SEQUENCE {
       snmpTargetAddrName         SnmpAdminString,
       snmpTargetAddrTDomain      TDomain,
       snmpTargetAddrTAddress     TAddress,
       snmpTargetAddrTimeout      TimeInterval,
       snmpTargetAddrRetryCount   Integer32,
       snmpTargetAddrTagList      SnmpTagList,
       snmpTargetAddrParams       SnmpAdminString,
       snmpTargetAddrStorageType  StorageType,
       snmpTargetAddrRowStatus    RowStatus
   }

   snmpTargetAddrName OBJECT-TYPE
       SYNTAX      SnmpAdminString (SIZE(1..32))



Levi, et. al.               Standards Track                    [Page 36]


RFC 3413                   SNMP Applications               December 2002


       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The locally arbitrary, but unique identifier associated
            with this snmpTargetAddrEntry."
       ::= { snmpTargetAddrEntry 1 }

   snmpTargetAddrTDomain OBJECT-TYPE
       SYNTAX      TDomain
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object indicates the transport type of the address
            contained in the snmpTargetAddrTAddress object."
       ::= { snmpTargetAddrEntry 2 }

   snmpTargetAddrTAddress OBJECT-TYPE
       SYNTAX      TAddress
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object contains a transport address.  The format of
            this address depends on the value of the
            snmpTargetAddrTDomain object."
       ::= { snmpTargetAddrEntry 3 }

   snmpTargetAddrTimeout OBJECT-TYPE
       SYNTAX      TimeInterval
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object should reflect the expected maximum round
            trip time for communicating with the transport address
            defined by this row.  When a message is sent to this
            address, and a response (if one is expected) is not
            received within this time period, an implementation
            may assume that the response will not be delivered.

            Note that the time interval that an application waits
            for a response may actually be derived from the value
            of this object.  The method for deriving the actual time
            interval is implementation dependent.  One such method
            is to derive the expected round trip time based on a
            particular retransmission algorithm and on the number
            of timeouts which have occurred.  The type of message may
            also be considered when deriving expected round trip
            times for retransmissions.  For example, if a message is
            being sent with a securityLevel that indicates both



Levi, et. al.               Standards Track                    [Page 37]


RFC 3413                   SNMP Applications               December 2002


            authentication and privacy, the derived value may be
            increased to compensate for extra processing time spent
            during authentication and encryption processing."
       DEFVAL { 1500 }
       ::= { snmpTargetAddrEntry 4 }

   snmpTargetAddrRetryCount OBJECT-TYPE
       SYNTAX      Integer32 (0..255)
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object specifies a default number of retries to be
            attempted when a response is not received for a generated
            message.  An application may provide its own retry count,
            in which case the value of this object is ignored."
       DEFVAL { 3 }
       ::= { snmpTargetAddrEntry 5 }

   snmpTargetAddrTagList OBJECT-TYPE
       SYNTAX      SnmpTagList
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object contains a list of tag values which are
            used to select target addresses for a particular
            operation."
       DEFVAL { "" }
       ::= { snmpTargetAddrEntry 6 }

   snmpTargetAddrParams OBJECT-TYPE
       SYNTAX      SnmpAdminString (SIZE(1..32))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The value of this object identifies an entry in the
            snmpTargetParamsTable.  The identified entry
            contains SNMP parameters to be used when generating
            messages to be sent to this transport address."
       ::= { snmpTargetAddrEntry 7 }

   snmpTargetAddrStorageType 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."



Levi, et. al.               Standards Track                    [Page 38]


RFC 3413                   SNMP Applications               December 2002


       DEFVAL { nonVolatile }
       ::= { snmpTargetAddrEntry 8 }

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

            To create a row in this table, a manager must
            set this object to either createAndGo(4) or
            createAndWait(5).

            Until instances of all corresponding columns are
            appropriately configured, the value of the
            corresponding instance of the snmpTargetAddrRowStatus
            column is 'notReady'.

            In particular, a newly created row cannot be made
            active until the corresponding instances of
            snmpTargetAddrTDomain, snmpTargetAddrTAddress, and
            snmpTargetAddrParams have all been set.

            The following objects may not be modified while the
            value of this object is active(1):
                - snmpTargetAddrTDomain
                - snmpTargetAddrTAddress
            An attempt to set these objects while the value of
            snmpTargetAddrRowStatus is active(1) will result in
            an inconsistentValue error."
       ::= { snmpTargetAddrEntry 9 }

   snmpTargetParamsTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SnmpTargetParamsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table of SNMP target information to be used
            in the generation of SNMP messages."
       ::= { snmpTargetObjects 3 }

   snmpTargetParamsEntry OBJECT-TYPE
       SYNTAX      SnmpTargetParamsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A set of SNMP target information.



Levi, et. al.               Standards Track                    [Page 39]


RFC 3413                   SNMP Applications               December 2002


            Entries in the snmpTargetParamsTable are created and
            deleted using the snmpTargetParamsRowStatus object."
       INDEX { IMPLIED snmpTargetParamsName }
       ::= { snmpTargetParamsTable 1 }

   SnmpTargetParamsEntry ::= SEQUENCE {
       snmpTargetParamsName           SnmpAdminString,
       snmpTargetParamsMPModel        SnmpMessageProcessingModel,
       snmpTargetParamsSecurityModel  SnmpSecurityModel,
       snmpTargetParamsSecurityName   SnmpAdminString,
       snmpTargetParamsSecurityLevel  SnmpSecurityLevel,
       snmpTargetParamsStorageType    StorageType,
       snmpTargetParamsRowStatus      RowStatus
   }

   snmpTargetParamsName OBJECT-TYPE
       SYNTAX      SnmpAdminString (SIZE(1..32))
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The locally arbitrary, but unique identifier associated
            with this snmpTargetParamsEntry."
       ::= { snmpTargetParamsEntry 1 }

   snmpTargetParamsMPModel OBJECT-TYPE
       SYNTAX      SnmpMessageProcessingModel
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The Message Processing Model to be used when generating
            SNMP messages using this entry."
       ::= { snmpTargetParamsEntry 2 }

   snmpTargetParamsSecurityModel OBJECT-TYPE
       SYNTAX      SnmpSecurityModel (1..2147483647)
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The Security Model to be used when generating SNMP
             messages using this entry.  An implementation may
             choose to return an inconsistentValue error if an
             attempt is made to set this variable to a value
             for a security model which the implementation does
             not support."
       ::= { snmpTargetParamsEntry 3 }

   snmpTargetParamsSecurityName OBJECT-TYPE
       SYNTAX      SnmpAdminString



Levi, et. al.               Standards Track                    [Page 40]


RFC 3413                   SNMP Applications               December 2002


       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The securityName which identifies the Principal on
            whose behalf SNMP messages will be generated using
            this entry."
       ::= { snmpTargetParamsEntry 4 }

   snmpTargetParamsSecurityLevel OBJECT-TYPE
       SYNTAX      SnmpSecurityLevel
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The Level of Security to be used when generating
            SNMP messages using this entry."
       ::= { snmpTargetParamsEntry 5 }

   snmpTargetParamsStorageType 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 }
       ::= { snmpTargetParamsEntry 6 }

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

            To create a row in this table, a manager must
            set this object to either createAndGo(4) or
            createAndWait(5).

            Until instances of all corresponding columns are
            appropriately configured, the value of the
            corresponding instance of the snmpTargetParamsRowStatus
            column is 'notReady'.

            In particular, a newly created row cannot be made
            active until the corresponding
            snmpTargetParamsMPModel,
            snmpTargetParamsSecurityModel,



Levi, et. al.               Standards Track                    [Page 41]


RFC 3413                   SNMP Applications               December 2002


            snmpTargetParamsSecurityName,
            and snmpTargetParamsSecurityLevel have all been set.

            The following objects may not be modified while the
            value of this object is active(1):
                - snmpTargetParamsMPModel
                - snmpTargetParamsSecurityModel
                - snmpTargetParamsSecurityName
                - snmpTargetParamsSecurityLevel
            An attempt to set these objects while the value of
            snmpTargetParamsRowStatus is active(1) will result in
            an inconsistentValue error."
       ::= { snmpTargetParamsEntry 7 }

   snmpUnavailableContexts OBJECT-TYPE
       SYNTAX       Counter32
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION
           "The total number of packets received by the SNMP
            engine which were dropped because the context
            contained in the message was unavailable."
       ::= { snmpTargetObjects 4 }

   snmpUnknownContexts OBJECT-TYPE
       SYNTAX       Counter32
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION
           "The total number of packets received by the SNMP
            engine which were dropped because the context
            contained in the message was unknown."
       ::= { snmpTargetObjects 5 }

   --
   --
   -- Conformance information
   --
   --

   snmpTargetCompliances OBJECT IDENTIFIER ::=
                                           { snmpTargetConformance 1 }
   snmpTargetGroups      OBJECT IDENTIFIER ::=
                                           { snmpTargetConformance 2 }

   --
   --
   -- Compliance statements



Levi, et. al.               Standards Track                    [Page 42]


RFC 3413                   SNMP Applications               December 2002


   --
   --

   snmpTargetCommandResponderCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for SNMP entities which include
            a command responder application."
       MODULE -- This Module
           MANDATORY-GROUPS { snmpTargetCommandResponderGroup }
       ::= { snmpTargetCompliances 1 }

   snmpTargetBasicGroup OBJECT-GROUP
       OBJECTS {
           snmpTargetSpinLock,
           snmpTargetAddrTDomain,
           snmpTargetAddrTAddress,
           snmpTargetAddrTagList,
           snmpTargetAddrParams,
           snmpTargetAddrStorageType,
           snmpTargetAddrRowStatus,
           snmpTargetParamsMPModel,
           snmpTargetParamsSecurityModel,
           snmpTargetParamsSecurityName,
           snmpTargetParamsSecurityLevel,
           snmpTargetParamsStorageType,
           snmpTargetParamsRowStatus
       }
       STATUS      current
       DESCRIPTION
           "A collection of objects providing basic remote
            configuration of management targets."
       ::= { snmpTargetGroups 1 }

   snmpTargetResponseGroup OBJECT-GROUP
       OBJECTS {
           snmpTargetAddrTimeout,
           snmpTargetAddrRetryCount
       }
       STATUS      current
       DESCRIPTION
           "A collection of objects providing remote configuration
            of management targets for applications which generate
            SNMP messages for which a response message would be
            expected."
       ::= { snmpTargetGroups 2 }

   snmpTargetCommandResponderGroup OBJECT-GROUP



Levi, et. al.               Standards Track                    [Page 43]


RFC 3413                   SNMP Applications               December 2002


       OBJECTS {
           snmpUnavailableContexts,
           snmpUnknownContexts
       }
       STATUS      current
       DESCRIPTION
           "A collection of objects required for command responder
            applications, used for counting error conditions."
       ::= { snmpTargetGroups 3 }

   END

4.2. The Notification MIB Module

   The SNMP-NOTIFICATION-MIB module contains objects for the remote
   configuration of the parameters used by an SNMP entity for the
   generation of notifications.  It consists of three tables and
   conformance/compliance statements.  The first table, the
   snmpNotifyTable, contains entries which select which entries in the
   snmpTargetAddrTable should be used for generating notifications, and
   the type of notifications to be generated.

   The second table, the snmpNotifyFilterProfileTable, sparsely augments
   the snmpTargetParamsTable with an object which is used to associate a
   set of filters with a particular management target.

   The third table, the snmpNotifyFilterTable, defines filters which are
   used to limit the number of notifications which are generated using
   particular management targets.

4.2.1. Definitions

   SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY,
       OBJECT-TYPE,
       snmpModules
           FROM SNMPv2-SMI

       RowStatus,
       StorageType
           FROM SNMPv2-TC

       SnmpAdminString
           FROM SNMP-FRAMEWORK-MIB

       SnmpTagValue,



Levi, et. al.               Standards Track                    [Page 44]


RFC 3413                   SNMP Applications               December 2002


       snmpTargetParamsName
           FROM SNMP-TARGET-MIB

       MODULE-COMPLIANCE,
       OBJECT-GROUP
           FROM SNMPv2-CONF;

   snmpNotificationMIB MODULE-IDENTITY
       LAST-UPDATED "200210140000Z"
       ORGANIZATION "IETF SNMPv3 Working Group"
       CONTACT-INFO
           "WG-email:   snmpv3@lists.tislabs.com
            Subscribe:  majordomo@lists.tislabs.com
                        In message body:  subscribe snmpv3

            Co-Chair:   Russ Mundy
                        Network Associates Laboratories
            Postal:     15204 Omega Drive, Suite 300
                        Rockville, MD 20850-4601
                        USA
            EMail:      mundy@tislabs.com
            Phone:      +1 301-947-7107

            Co-Chair:   David Harrington
                        Enterasys Networks
            Postal:     35 Industrial Way
                        P. O. Box 5004
                        Rochester, New Hampshire 03866-5005
                        USA
            EMail:      dbh@enterasys.com
            Phone:      +1 603-337-2614

            Co-editor:  David B. Levi
                        Nortel Networks
            Postal:     3505 Kesterwood Drive
                        Knoxville, Tennessee 37918
            EMail:      dlevi@nortelnetworks.com
            Phone:      +1 865 686 0432

            Co-editor:  Paul Meyer
                        Secure Computing Corporation
            Postal:     2675 Long Lake Road
                        Roseville, Minnesota 55113
            EMail:      paul_meyer@securecomputing.com
            Phone:      +1 651 628 1592

            Co-editor:  Bob Stewart
                        Retired"



Levi, et. al.               Standards Track                    [Page 45]


RFC 3413                   SNMP Applications               December 2002


       DESCRIPTION
           "This MIB module defines MIB objects which provide
            mechanisms to remotely configure the parameters
            used by an SNMP entity for the generation of
            notifications.

            Copyright (C) The Internet Society (2002). This
            version of this MIB module is part of RFC 3413;
            see the RFC itself for full legal notices.
           "
       REVISION    "200210140000Z"             -- 14 October 2002
       DESCRIPTION "Clarifications, published as
                    RFC 3413."
       REVISION    "199808040000Z"             -- 4 August 1998
       DESCRIPTION "Clarifications, published as
                    RFC 2573."
       REVISION    "199707140000Z"             -- 14 July 1997
       DESCRIPTION "The initial revision, published as RFC2273."
       ::= { snmpModules 13 }

   snmpNotifyObjects       OBJECT IDENTIFIER ::=
                                             { snmpNotificationMIB 1 }
   snmpNotifyConformance   OBJECT IDENTIFIER ::=
                                             { snmpNotificationMIB 3 }

   --
   --
   -- The snmpNotifyObjects group
   --
   --

   snmpNotifyTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SnmpNotifyEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table is used to select management targets which should
            receive notifications, as well as the type of notification
            which should be sent to each selected management target."
       ::= { snmpNotifyObjects 1 }

   snmpNotifyEntry OBJECT-TYPE
       SYNTAX      SnmpNotifyEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An entry in this table selects a set of management targets
            which should receive notifications, as well as the type of



Levi, et. al.               Standards Track                    [Page 46]


RFC 3413                   SNMP Applications               December 2002


            notification which should be sent to each selected
            management target.

            Entries in the snmpNotifyTable are created and
            deleted using the snmpNotifyRowStatus object."
       INDEX { IMPLIED snmpNotifyName }
       ::= { snmpNotifyTable 1 }

   SnmpNotifyEntry ::= SEQUENCE {
       snmpNotifyName         SnmpAdminString,
       snmpNotifyTag          SnmpTagValue,
       snmpNotifyType         INTEGER,
       snmpNotifyStorageType  StorageType,
       snmpNotifyRowStatus    RowStatus
   }

   snmpNotifyName OBJECT-TYPE
       SYNTAX      SnmpAdminString (SIZE(1..32))
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The locally arbitrary, but unique identifier associated
            with this snmpNotifyEntry."
       ::= { snmpNotifyEntry 1 }

   snmpNotifyTag OBJECT-TYPE
       SYNTAX      SnmpTagValue
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object contains a single tag value which is used
            to select entries in the snmpTargetAddrTable.  Any entry
            in the snmpTargetAddrTable which contains a tag value
            which is equal to the value of an instance of this
            object is selected.  If this object contains a value
            of zero length, no entries are selected."
       DEFVAL { "" }
       ::= { snmpNotifyEntry 2 }

   snmpNotifyType OBJECT-TYPE
       SYNTAX      INTEGER {
                       trap(1),
                       inform(2)
                   }
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object determines the type of notification to



Levi, et. al.               Standards Track                    [Page 47]


RFC 3413                   SNMP Applications               December 2002


            be generated for entries in the snmpTargetAddrTable
            selected by the corresponding instance of
            snmpNotifyTag.  This value is only used when
            generating notifications, and is ignored when
            using the snmpTargetAddrTable for other purposes.

            If the value of this object is trap(1), then any
            messages generated for selected rows will contain
            Unconfirmed-Class PDUs.

            If the value of this object is inform(2), then any
            messages generated for selected rows will contain
            Confirmed-Class PDUs.

            Note that if an SNMP entity only supports
            generation of Unconfirmed-Class PDUs (and not
            Confirmed-Class PDUs), then this object may be
            read-only."
       DEFVAL { trap }
       ::= { snmpNotifyEntry 3 }

   snmpNotifyStorageType 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 }
       ::= { snmpNotifyEntry 4 }

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

            To create a row in this table, a manager must
            set this object to either createAndGo(4) or
            createAndWait(5)."
       ::= { snmpNotifyEntry 5 }

   snmpNotifyFilterProfileTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SnmpNotifyFilterProfileEntry
       MAX-ACCESS  not-accessible
       STATUS      current



Levi, et. al.               Standards Track                    [Page 48]


RFC 3413                   SNMP Applications               December 2002


       DESCRIPTION
           "This table is used to associate a notification filter
            profile with a particular set of target parameters."
       ::= { snmpNotifyObjects 2 }

   snmpNotifyFilterProfileEntry OBJECT-TYPE
       SYNTAX      SnmpNotifyFilterProfileEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An entry in this table indicates the name of the filter
            profile to be used when generating notifications using
            the corresponding entry in the snmpTargetParamsTable.

            Entries in the snmpNotifyFilterProfileTable are created
            and deleted using the snmpNotifyFilterProfileRowStatus
            object."
       INDEX { IMPLIED snmpTargetParamsName }
       ::= { snmpNotifyFilterProfileTable 1 }

   SnmpNotifyFilterProfileEntry ::= SEQUENCE {
       snmpNotifyFilterProfileName         SnmpAdminString,
       snmpNotifyFilterProfileStorType     StorageType,
       snmpNotifyFilterProfileRowStatus    RowStatus
   }

   snmpNotifyFilterProfileName OBJECT-TYPE
       SYNTAX      SnmpAdminString (SIZE(1..32))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The name of the filter profile to be used when generating
            notifications using the corresponding entry in the
            snmpTargetAddrTable."
       ::= { snmpNotifyFilterProfileEntry 1 }

   snmpNotifyFilterProfileStorType 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 }
       ::= { snmpNotifyFilterProfileEntry 2 }

   snmpNotifyFilterProfileRowStatus OBJECT-TYPE



Levi, et. al.               Standards Track                    [Page 49]


RFC 3413                   SNMP Applications               December 2002


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

            To create a row in this table, a manager must
            set this object to either createAndGo(4) or
            createAndWait(5).

            Until instances of all corresponding columns are
            appropriately configured, the value of the
            corresponding instance of the
            snmpNotifyFilterProfileRowStatus column is 'notReady'.

            In particular, a newly created row cannot be made
            active until the corresponding instance of
            snmpNotifyFilterProfileName has been set."
       ::= { snmpNotifyFilterProfileEntry 3 }

   snmpNotifyFilterTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SnmpNotifyFilterEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The table of filter profiles.  Filter profiles are used
            to determine whether particular management targets should
            receive particular notifications.

            When a notification is generated, it must be compared
            with the filters associated with each management target
            which is configured to receive notifications, in order to
            determine whether it may be sent to each such management
            target.

            A more complete discussion of notification filtering
            can be found in section 6. of [SNMP-APPL]."
       ::= { snmpNotifyObjects 3 }

   snmpNotifyFilterEntry OBJECT-TYPE
       SYNTAX      SnmpNotifyFilterEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An element of a filter profile.

            Entries in the snmpNotifyFilterTable are created and
            deleted using the snmpNotifyFilterRowStatus object."



Levi, et. al.               Standards Track                    [Page 50]


RFC 3413                   SNMP Applications               December 2002


       INDEX {         snmpNotifyFilterProfileName,
               IMPLIED snmpNotifyFilterSubtree }
       ::= { snmpNotifyFilterTable 1 }

   SnmpNotifyFilterEntry ::= SEQUENCE {
       snmpNotifyFilterSubtree           OBJECT IDENTIFIER,
       snmpNotifyFilterMask              OCTET STRING,
       snmpNotifyFilterType              INTEGER,
       snmpNotifyFilterStorageType       StorageType,
       snmpNotifyFilterRowStatus         RowStatus
   }

   snmpNotifyFilterSubtree OBJECT-TYPE
       SYNTAX      OBJECT IDENTIFIER
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The MIB subtree which, when combined with the corresponding
            instance of snmpNotifyFilterMask, defines a family of
            subtrees which are included in or excluded from the
            filter profile."
       ::= { snmpNotifyFilterEntry 1 }

   snmpNotifyFilterMask 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 snmpNotifyFilterSubtree, defines a family of
            subtrees which are included in or excluded from the
            filter profile.

            Each bit of this bit mask corresponds to a
            sub-identifier of snmpNotifyFilterSubtree, 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 matches this
            family of filter subtrees; a '1' indicates that an
            exact match must occur; a '0' indicates 'wild card',
            i.e., any sub-identifier value matches.



Levi, et. al.               Standards Track                    [Page 51]


RFC 3413                   SNMP Applications               December 2002


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

              the i-th bit of snmpNotifyFilterMask is 0, or

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

            If the value of this bit mask is M bits long and
            there are more than M sub-identifiers in the
            corresponding instance of snmpNotifyFilterSubtree,
            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 filter subtrees is the one
            subtree uniquely identified by the corresponding
            instance of snmpNotifyFilterSubtree."
       DEFVAL { ''H }
       ::= { snmpNotifyFilterEntry 2 }

   snmpNotifyFilterType OBJECT-TYPE
       SYNTAX      INTEGER {
                       included(1),
                       excluded(2)
                   }
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object indicates whether the family of filter subtrees
            defined by this entry are included in or excluded from a
            filter.  A more detailed discussion of the use of this
            object can be found in section 6. of [SNMP-APPL]."
       DEFVAL { included }
       ::= { snmpNotifyFilterEntry 3 }

   snmpNotifyFilterStorageType 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



Levi, et. al.               Standards Track                    [Page 52]


RFC 3413                   SNMP Applications               December 2002


            allow write-access to any columnar objects in the row."
       DEFVAL { nonVolatile }
       ::= { snmpNotifyFilterEntry 4 }

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

            To create a row in this table, a manager must
            set this object to either createAndGo(4) or
            createAndWait(5)."
       ::= { snmpNotifyFilterEntry 5 }

   --
   --
   -- Conformance information
   --
   --

   snmpNotifyCompliances OBJECT IDENTIFIER ::=
                                           { snmpNotifyConformance 1 }
   snmpNotifyGroups      OBJECT IDENTIFIER ::=
                                           { snmpNotifyConformance 2 }

   --
   --
   -- Compliance statements
   --
   --

   snmpNotifyBasicCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for minimal SNMP entities which
            implement only SNMP Unconfirmed-Class notifications and
            read-create operations on only the snmpTargetAddrTable."
       MODULE SNMP-TARGET-MIB
           MANDATORY-GROUPS { snmpTargetBasicGroup }

           OBJECT snmpTargetParamsMPModel
           MIN-ACCESS    read-only
           DESCRIPTION
               "Create/delete/modify access is not required."

           OBJECT snmpTargetParamsSecurityModel



Levi, et. al.               Standards Track                    [Page 53]


RFC 3413                   SNMP Applications               December 2002


           MIN-ACCESS    read-only
           DESCRIPTION
               "Create/delete/modify access is not required."

           OBJECT snmpTargetParamsSecurityName
           MIN-ACCESS    read-only
           DESCRIPTION
               "Create/delete/modify access is not required."

           OBJECT snmpTargetParamsSecurityLevel
           MIN-ACCESS    read-only
           DESCRIPTION
               "Create/delete/modify access is not required."

           OBJECT snmpTargetParamsStorageType
           SYNTAX INTEGER {
               readOnly(5)
           }
           MIN-ACCESS    read-only
           DESCRIPTION
               "Create/delete/modify access is not required.
                Support of the values other(1), volatile(2),
                nonVolatile(3), and permanent(4) is not required."

           OBJECT snmpTargetParamsRowStatus
           SYNTAX INTEGER {
               active(1)
           }
           MIN-ACCESS    read-only
           DESCRIPTION
               "Create/delete/modify access to the
                snmpTargetParamsTable is not required.
                Support of the values notInService(2), notReady(3),
                createAndGo(4), createAndWait(5), and destroy(6) is
                not required."

       MODULE -- This Module
           MANDATORY-GROUPS { snmpNotifyGroup }

           OBJECT snmpNotifyTag
           MIN-ACCESS    read-only
           DESCRIPTION
               "Create/delete/modify access is not required."

           OBJECT snmpNotifyType
           SYNTAX INTEGER {
               trap(1)
           }



Levi, et. al.               Standards Track                    [Page 54]


RFC 3413                   SNMP Applications               December 2002


           MIN-ACCESS    read-only
           DESCRIPTION
               "Create/delete/modify access is not required.
                Support of the value notify(2) is not required."

           OBJECT snmpNotifyStorageType
           SYNTAX INTEGER {
               readOnly(5)
           }
           MIN-ACCESS    read-only
           DESCRIPTION
               "Create/delete/modify access is not required.
                Support of the values other(1), volatile(2),
                nonVolatile(3), and permanent(4) is not required."

           OBJECT snmpNotifyRowStatus
           SYNTAX INTEGER {
               active(1)
           }
           MIN-ACCESS    read-only
           DESCRIPTION
               "Create/delete/modify access to the
                snmpNotifyTable is not required.
                Support of the values notInService(2), notReady(3),
                createAndGo(4), createAndWait(5), and destroy(6) is
                not required."

       ::= { snmpNotifyCompliances 1 }

   snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for SNMP entities which implement
            SNMP Unconfirmed-Class notifications with filtering, and
            read-create operations on all related tables."
       MODULE SNMP-TARGET-MIB
           MANDATORY-GROUPS { snmpTargetBasicGroup }
       MODULE -- This Module
           MANDATORY-GROUPS { snmpNotifyGroup,
                              snmpNotifyFilterGroup }
       ::= { snmpNotifyCompliances 2 }

   snmpNotifyFullCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for SNMP entities which either
            implement only SNMP Confirmed-Class notifications, or both
            SNMP Unconfirmed-Class and Confirmed-Class notifications,



Levi, et. al.               Standards Track                    [Page 55]


RFC 3413                   SNMP Applications               December 2002


            plus filtering and read-create operations on all related
            tables."
       MODULE SNMP-TARGET-MIB
           MANDATORY-GROUPS { snmpTargetBasicGroup,
                              snmpTargetResponseGroup }
       MODULE -- This Module
           MANDATORY-GROUPS { snmpNotifyGroup,
                              snmpNotifyFilterGroup }
       ::= { snmpNotifyCompliances 3 }

   snmpNotifyGroup OBJECT-GROUP
       OBJECTS {
           snmpNotifyTag,
           snmpNotifyType,
           snmpNotifyStorageType,
           snmpNotifyRowStatus
       }
       STATUS      current
       DESCRIPTION
           "A collection of objects for selecting which management
            targets are used for generating notifications, and the
            type of notification to be generated for each selected
            management target."
       ::= { snmpNotifyGroups 1 }

   snmpNotifyFilterGroup OBJECT-GROUP
       OBJECTS {
           snmpNotifyFilterProfileName,
           snmpNotifyFilterProfileStorType,
           snmpNotifyFilterProfileRowStatus,
           snmpNotifyFilterMask,
           snmpNotifyFilterType,
           snmpNotifyFilterStorageType,
           snmpNotifyFilterRowStatus
       }
       STATUS      current
       DESCRIPTION
           "A collection of objects providing remote configuration
            of notification filters."
       ::= { snmpNotifyGroups 2 }

   END









Levi, et. al.               Standards Track                    [Page 56]


RFC 3413                   SNMP Applications               December 2002


4.3. The Proxy MIB Module

   The SNMP-PROXY-MIB module, which defines MIB objects that provide
   mechanisms to remotely configure the parameters used by an SNMP
   entity for proxy forwarding operations, contains a single table.
   This table, snmpProxyTable, is used to define translations between
   management targets for use when forwarding messages.

4.3.1. Definitions

   SNMP-PROXY-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY,
       OBJECT-TYPE,
       snmpModules
           FROM SNMPv2-SMI

       RowStatus,
       StorageType
           FROM SNMPv2-TC

       SnmpEngineID,
       SnmpAdminString
           FROM SNMP-FRAMEWORK-MIB

       SnmpTagValue
           FROM SNMP-TARGET-MIB

       MODULE-COMPLIANCE,
       OBJECT-GROUP
           FROM SNMPv2-CONF;

   snmpProxyMIB MODULE-IDENTITY
       LAST-UPDATED "200210140000Z"
       ORGANIZATION "IETF SNMPv3 Working Group"
       CONTACT-INFO
           "WG-email:   snmpv3@lists.tislabs.com
            Subscribe:  majordomo@lists.tislabs.com
                        In message body:  subscribe snmpv3

            Co-Chair:   Russ Mundy
                        Network Associates Laboratories
            Postal:     15204 Omega Drive, Suite 300
                        Rockville, MD 20850-4601
                        USA
            EMail:      mundy@tislabs.com
            Phone:      +1 301-947-7107



Levi, et. al.               Standards Track                    [Page 57]


RFC 3413                   SNMP Applications               December 2002


            Co-Chair:   David Harrington
                        Enterasys Networks
            Postal:     35 Industrial Way
                        P. O. Box 5004
                        Rochester, New Hampshire 03866-5005
                        USA
            EMail:      dbh@enterasys.com
            Phone:      +1 603-337-2614

            Co-editor:  David B. Levi
                        Nortel Networks
            Postal:     3505 Kesterwood Drive
                        Knoxville, Tennessee 37918
            EMail:      dlevi@nortelnetworks.com
            Phone:      +1 865 686 0432

            Co-editor:  Paul Meyer
                        Secure Computing Corporation
            Postal:     2675 Long Lake Road
                        Roseville, Minnesota 55113
            EMail:      paul_meyer@securecomputing.com
            Phone:      +1 651 628 1592

            Co-editor:  Bob Stewart
                        Retired"
       DESCRIPTION
           "This MIB module defines MIB objects which provide
            mechanisms to remotely configure the parameters
            used by a proxy forwarding application.

            Copyright (C) The Internet Society (2002). This
            version of this MIB module is part of RFC 3413;
            see the RFC itself for full legal notices.
           "
       REVISION    "200210140000Z"             -- 14 October 2002
       DESCRIPTION "Clarifications, published as
                    RFC 3413."
       REVISION    "199808040000Z"             -- 4 August 1998
       DESCRIPTION "Clarifications, published as
                    RFC 2573."
       REVISION    "199707140000Z"             -- 14 July 1997
       DESCRIPTION "The initial revision, published as RFC2273."
       ::= { snmpModules 14 }

   snmpProxyObjects        OBJECT IDENTIFIER ::= { snmpProxyMIB 1 }
   snmpProxyConformance    OBJECT IDENTIFIER ::= { snmpProxyMIB 3 }

   --



Levi, et. al.               Standards Track                    [Page 58]


RFC 3413                   SNMP Applications               December 2002


   --
   -- The snmpProxyObjects group
   --
   --

   snmpProxyTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SnmpProxyEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The table of translation parameters used by proxy forwarder
            applications for forwarding SNMP messages."
       ::= { snmpProxyObjects 2 }

   snmpProxyEntry OBJECT-TYPE
       SYNTAX      SnmpProxyEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A set of translation parameters used by a proxy forwarder
            application for forwarding SNMP messages.

            Entries in the snmpProxyTable are created and deleted
            using the snmpProxyRowStatus object."
       INDEX { IMPLIED snmpProxyName }
       ::= { snmpProxyTable 1 }

   SnmpProxyEntry ::= SEQUENCE {
       snmpProxyName               SnmpAdminString,
       snmpProxyType               INTEGER,
       snmpProxyContextEngineID    SnmpEngineID,
       snmpProxyContextName        SnmpAdminString,
       snmpProxyTargetParamsIn     SnmpAdminString,
       snmpProxySingleTargetOut    SnmpAdminString,
       snmpProxyMultipleTargetOut  SnmpTagValue,
       snmpProxyStorageType        StorageType,
       snmpProxyRowStatus          RowStatus
   }

   snmpProxyName OBJECT-TYPE
       SYNTAX      SnmpAdminString (SIZE(1..32))
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The locally arbitrary, but unique identifier associated
            with this snmpProxyEntry."
       ::= { snmpProxyEntry 1 }




Levi, et. al.               Standards Track                    [Page 59]


RFC 3413                   SNMP Applications               December 2002


   snmpProxyType OBJECT-TYPE
       SYNTAX      INTEGER {
                       read(1),
                       write(2),
                       trap(3),
                       inform(4)
                   }
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The type of message that may be forwarded using
            the translation parameters defined by this entry."
       ::= { snmpProxyEntry 2 }

   snmpProxyContextEngineID OBJECT-TYPE
       SYNTAX      SnmpEngineID
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The contextEngineID contained in messages that
            may be forwarded using the translation parameters
            defined by this entry."
       ::= { snmpProxyEntry 3 }

   snmpProxyContextName OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The contextName contained in messages that may be
            forwarded using the translation parameters defined
            by this entry.

            This object is optional, and if not supported, the
            contextName contained in a message is ignored when
            selecting an entry in the snmpProxyTable."
       ::= { snmpProxyEntry 4 }

   snmpProxyTargetParamsIn OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object selects an entry in the snmpTargetParamsTable.
            The selected entry is used to determine which row of the
            snmpProxyTable to use for forwarding received messages."
       ::= { snmpProxyEntry 5 }




Levi, et. al.               Standards Track                    [Page 60]


RFC 3413                   SNMP Applications               December 2002


   snmpProxySingleTargetOut OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object selects a management target defined in the
            snmpTargetAddrTable (in the SNMP-TARGET-MIB).  The
            selected target is defined by an entry in the
            snmpTargetAddrTable whose index value (snmpTargetAddrName)
            is equal to this object.

            This object is only used when selection of a single
            target is required (i.e. when forwarding an incoming
            read or write request)."
       ::= { snmpProxyEntry 6 }

   snmpProxyMultipleTargetOut OBJECT-TYPE
       SYNTAX      SnmpTagValue
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object selects a set of management targets defined
            in the snmpTargetAddrTable (in the SNMP-TARGET-MIB).

            This object is only used when selection of multiple
            targets is required (i.e. when forwarding an incoming
            notification)."
       ::= { snmpProxyEntry 7 }

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

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

            To create a row in this table, a manager must



Levi, et. al.               Standards Track                    [Page 61]


RFC 3413                   SNMP Applications               December 2002


            set this object to either createAndGo(4) or
            createAndWait(5).

            The following objects may not be modified while the
            value of this object is active(1):
                - snmpProxyType
                - snmpProxyContextEngineID
                - snmpProxyContextName
                - snmpProxyTargetParamsIn
                - snmpProxySingleTargetOut
                - snmpProxyMultipleTargetOut"
       ::= { snmpProxyEntry 9 }

   --
   --
   -- Conformance information
   --
   --

   snmpProxyCompliances OBJECT IDENTIFIER ::=
                                            { snmpProxyConformance 1 }
   snmpProxyGroups      OBJECT IDENTIFIER ::=
                                            { snmpProxyConformance 2 }

   --
   --
   -- Compliance statements
   --
   --

   snmpProxyCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for SNMP entities which include
            a proxy forwarding application."
       MODULE SNMP-TARGET-MIB
           MANDATORY-GROUPS { snmpTargetBasicGroup,
                              snmpTargetResponseGroup }
       MODULE -- This Module
           MANDATORY-GROUPS { snmpProxyGroup }
       ::= { snmpProxyCompliances 1 }

   snmpProxyGroup OBJECT-GROUP
       OBJECTS {
           snmpProxyType,
           snmpProxyContextEngineID,
           snmpProxyContextName,
           snmpProxyTargetParamsIn,



Levi, et. al.               Standards Track                    [Page 62]


RFC 3413                   SNMP Applications               December 2002


           snmpProxySingleTargetOut,
           snmpProxyMultipleTargetOut,
           snmpProxyStorageType,
           snmpProxyRowStatus
       }
       STATUS      current
       DESCRIPTION
           "A collection of objects providing remote configuration of
            management target translation parameters for use by
            proxy forwarder applications."
       ::= { snmpProxyGroups 3 }

   END

5. Identification of Management Targets in Notification Originators

   This section describes the mechanisms used by a notification
   originator application when using the MIB module described in this
   document to determine the set of management targets to be used when
   generating a notification.

   A notification originator uses all active entries in the
   snmpNotifyTable to find the management targets to be used for
   generating notifications.  Each active entry in this table selects
   zero or more entries in the snmpTargetAddrTable.  When a notification
   is generated, it is sent to all of the targets specified by the
   selected snmpTargetAddrTable entries (subject to the application of
   access control and notification filtering).

   Any entry in the snmpTargetAddrTable whose snmpTargetAddrTagList
   object contains a tag value which is equal to a value of
   snmpNotifyTag is selected by the snmpNotifyEntry which contains that
   instance of snmpNotifyTag.  Note that a particular
   snmpTargetAddrEntry may be selected by multiple entries in the
   snmpNotifyTable, resulting in multiple notifications being generated
   using that snmpTargetAddrEntry (this allows, for example, both traps
   and informs to be sent to the same target).

   Each snmpTargetAddrEntry contains a pointer to the
   snmpTargetParamsTable (snmpTargetAddrParams).  This pointer selects a
   set of SNMP parameters to be used for generating notifications.  If
   the selected entry in the snmpTargetParamsTable does not exist, the
   management target is not used to generate notifications.

   The decision as to whether a notification should contain an
   Unconfirmed-Class or a Confirmed-Class PDU is determined by the value
   of the snmpNotifyType object.  If the value of this object is
   trap(1), the notification should contain an Unconfirmed-Class PDU.



Levi, et. al.               Standards Track                    [Page 63]


RFC 3413                   SNMP Applications               December 2002


   If the value of this object is inform(2), then the notification
   should contain a Confirmed-Class PDU, and the timeout time and number
   of retries for the notification are the value of
   snmpTargetAddrTimeout and snmpTargetAddrRetryCount.  Note that the
   exception to these rules is when the snmpTargetParamsMPModel object
   indicates an SNMP version which supports a different PDU version.  In
   this case, the notification may be sent using a different PDU type
   ([RFC2576] defines the PDU type in the case where the outgoing SNMP
   version is SNMPv1).

6. Notification Filtering

   This section describes the mechanisms used by a notification
   originator application when using the MIB module described in this
   document to filter generation of notifications.

   A notification originator uses the snmpNotifyFilterTable to filter
   notifications.  A notification filter profile may be associated with
   a particular entry in the snmpTargetParamsTable.  The associated
   filter profile is identified by an entry in the
   snmpNotifyFilterProfileTable whose index is equal to the index of the
   entry in the snmpTargetParamsTable.  If no such entry exists in the
   snmpNotifyFilterProfileTable, no filtering is performed for that
   management target.

   If such an entry does exist, the value of snmpNotifyFilterProfileName
   of the entry is compared with the corresponding portion of the index
   of all active entries in the snmpNotifyFilterTable.  All such entries
   for which this comparison results in an exact match are used for
   filtering a notification generated using the associated
   snmpTargetParamsEntry.  If no such entries exist, no filtering is
   performed, and a notification may be sent to the management target.

   Otherwise, if matching entries do exist, a notification may be sent
   if the NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (this
   is the value of the element of the variable bindings whose name is
   snmpTrapOID.0, i.e., the second variable binding) is specifically
   included, and none of the object instances to be included in the
   variable-bindings of the notification are specifically excluded by
   the matching entries.

   Each set of snmpNotifyFilterTable entries is divided into two
   collections of filter subtrees:  the included filter subtrees, and
   the excluded filter subtrees.  The snmpNotifyFilterType object
   defines the collection to which each matching entry belongs.

   To determine whether a particular notification name or object
   instance is excluded by the set of matching entries, compare the



Levi, et. al.               Standards Track                    [Page 64]


RFC 3413                   SNMP Applications               December 2002


   notification name's or object instance's OBJECT IDENTIFIER with each
   of the matching entries.  For a notification name, if none match,
   then the notification name is considered excluded, and the
   notification should not be sent to this management target.  For an
   object instance, if none match, the object instance is considered
   included, and the notification may be sent to this management target.
   If one or more match, then the notification name or object instance
   is included or excluded, according to the value of
   snmpNotifyFilterType in the entry whose value of
   snmpNotifyFilterSubtree has the most sub-identifiers.  If multiple
   entries match and have the same number of sub-identifiers, then the
   value of snmpNotifyFilterType, in the entry among those which match,
   and whose instance is lexicographically the largest, determines the
   inclusion or exclusion.

   A notification name or object instance's OBJECT IDENTIFIER X matches
   an entry in the snmpNotifyFilterTable when the number of sub-
   identifiers in X is at least as many as in the value of
   snmpNotifyFilterSubtree for the entry, and each sub-identifier in the
   value of snmpNotifyFilterSubtree matches its corresponding sub-
   identifier in X.  Two sub-identifiers match either if the
   corresponding bit of snmpNotifyFilterMask is zero (the 'wild card'
   value), or if the two sub-identifiers are equal.

7. Management Target Translation in Proxy Forwarder Applications

   This section describes the mechanisms used by a proxy forwarder
   application when using the MIB module described in this document to
   translate incoming management target information into outgoing
   management target information for the purpose of forwarding messages.
   There are actually two mechanisms a proxy forwarder may use, one for
   forwarding request messages, and one for forwarding notification
   messages.

7.1. Management Target Translation for Request Forwarding

   When forwarding request messages, the proxy forwarder will select a
   single entry in the snmpProxyTable.  To select this entry, it will
   perform the following comparisons:

   - The snmpProxyType must be read(1) if the request is a Read-Class
     PDU.  The snmpProxyType must be write(2) if the request is a
     Write-Class PDU.

   - The contextEngineID must equal the snmpProxyContextEngineID object.

   - If the snmpProxyContextName object is supported, it must equal the
     contextName.



Levi, et. al.               Standards Track                    [Page 65]


RFC 3413                   SNMP Applications               December 2002


   - The snmpProxyTargetParamsIn object identifies an entry in the
     snmpTargetParamsTable.  The messageProcessingModel, security model,
     securityName, and securityLevel must match the values of
     snmpTargetParamsMPModel, snmpTargetParamsSecurityModel,
     snmpTargetParamsSecurityName, and snmpTargetParamsSecurityLevel of
     the identified entry in the snmpTargetParamsTable.

   There may be multiple entries in the snmpProxyTable for which these
   comparisons succeed.  The entry whose snmpProxyName has the
   lexicographically smallest value and for which the comparisons
   succeed will be selected by the proxy forwarder.

   The outgoing management target information is identified by the value
   of the snmpProxySingleTargetOut object of the selected entry.  This
   object identifies an entry in the snmpTargetAddrTable.  The
   identified entry in the snmpTargetAddrTable also contains a reference
   to the snmpTargetParamsTable (snmpTargetAddrParams).  If either the
   identified entry in the snmpTargetAddrTable does not exist, or the
   identified entry in the snmpTargetParamsTable does not exist, then
   this snmpProxyEntry does not identify valid forwarding information,
   and the proxy forwarder should attempt to identify another row.

   If there is no entry in the snmpProxyTable for which all of the
   conditions above may be met, then there is no appropriate forwarding
   information, and the proxy forwarder should take appropriate actions.

   Otherwise, The snmpTargetAddrTDomain, snmpTargetAddrTAddress,
   snmpTargetAddrTimeout, and snmpTargetRetryCount of the identified
   snmpTargetAddrEntry, and the snmpTargetParamsMPModel,
   snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, and
   snmpTargetParamsSecurityLevel of the identified snmpTargetParamsEntry
   are used as the destination management target.

7.2. Management Target Translation for Notification Forwarding

   When forwarding notification messages, the proxy forwarder will
   select multiple entries in the snmpProxyTable.  To select these
   entries, it will perform the following comparisons:

   - The snmpProxyType must be trap(3) if the notification is an
     Unconfirmed-Class PDU.  The snmpProxyType must be inform(4) if the
     request is a Confirmed-Class PDU.

   - The contextEngineID must equal the snmpProxyContextEngineID object.

   - If the snmpProxyContextName object is supported, it must equal the
     contextName.




Levi, et. al.               Standards Track                    [Page 66]


RFC 3413                   SNMP Applications               December 2002


   - The snmpProxyTargetParamsIn object identifies an entry in the
     snmpTargetParamsTable.  The messageProcessingModel, security model,
     securityName, and securityLevel must match the values of
     snmpTargetParamsMPModel, snmpTargetParamsSecurityModel,
     snmpTargetParamsSecurityName, and snmpTargetParamsSecurityLevel of
     the identified entry in the snmpTargetParamsTable.

   All entries for which these conditions are met are selected.  The
   snmpProxyMultipleTargetOut object of each such entry is used to
   select a set of entries in the snmpTargetAddrTable.  Any
   snmpTargetAddrEntry whose snmpTargetAddrTagList object contains a tag
   value equal to the value of snmpProxyMultipleTargetOut, and whose
   snmpTargetAddrParams object references an existing entry in the
   snmpTargetParamsTable, is selected as a destination for the forwarded
   notification.

8. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

9. Acknowledgments

   This document is the result of the efforts of the SNMPv3 Working
   Group.  Some special thanks are in order to the following SNMPv3 WG
   members:

      Harald Tveit Alvestrand (Maxware)
      Dave Battle (SNMP Research, Inc.)
      Alan Beard (Disney Worldwide Services)
      Paul Berrevoets (SWI Systemware/Halcyon Inc.)



Levi, et. al.               Standards Track                    [Page 67]


RFC 3413                   SNMP Applications               December 2002


      Martin Bjorklund (Ericsson)
      Uri Blumenthal (IBM T.J. Watson Research Center)
      Jeff Case (SNMP Research, Inc.)
      John Curran (BBN)
      Mike Daniele (Compaq Computer Corporation)
      T. Max Devlin (Eltrax Systems)
      John Flick (Hewlett Packard)
      Rob Frye (MCI)
      Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.)
      David Harrington (Enterasys Networks)
      Lauren Heintz (BMC Software, Inc.)
      N.C. Hien (IBM T.J. Watson Research Center)
      Michael Kirkham (InterWorking Labs, Inc.)
      Dave Levi (Nortel Networks)
      Louis A Mamakos (UUNET Technologies Inc.)
      Joe Marzot (Nortel Networks)
      Paul Meyer (Secure Computing Corporation)
      Keith McCloghrie (Cisco Systems)
      Bob Moore (IBM)
      Russ Mundy (TIS Labs at Network Associates)
      Bob Natale (ACE*COMM Corporation)
      Mike O'Dell (UUNET Technologies Inc.)
      Dave Perkins (DeskTalk)
      Peter Polkinghorne (Brunel University)
      Randy Presuhn (BMC Software, Inc.)
      David Reeder (TIS Labs at Network Associates)
      David Reid (SNMP Research, Inc.)
      Aleksey Romanov (Quality Quorum)
      Shawn Routhier (Epilogue)
      Juergen Schoenwaelder (TU Braunschweig)
      Bob Stewart (Cisco Systems)
      Mike Thatcher (Independent Consultant)
      Bert Wijnen (Lucent Technologies)

   The document is based on recommendations of the IETF Security and
   Administrative Framework Evolution for SNMP Advisory Team. Members of
   that Advisory Team were:

      David Harrington (Enterasys Networks)
      Jeff Johnson (Cisco Systems)
      David Levi (Nortel Networks)
      John Linn (Openvision)
      Russ Mundy (Trusted Information Systems) chair
      Shawn Routhier (Epilogue)
      Glenn Waters (Nortel)
      Bert Wijnen (Lucent Technologies)





Levi, et. al.               Standards Track                    [Page 68]


RFC 3413                   SNMP Applications               December 2002


   As recommended by the Advisory Team and the SNMPv3 Working Group
   Charter, the design incorporates as much as practical from previous
   RFCs and drafts.  As a result, special thanks are due to the authors
   of previous designs known as SNMPv2u and SNMPv2*:

      Jeff Case (SNMP Research, Inc.)
      David Harrington (Enterasys Networks)
      David Levi (Nortel Networks)
      Keith McCloghrie (Cisco Systems)
      Brian O'Keefe (Hewlett Packard)
      Marshall T. Rose (Dover Beach Consulting)
      Jon Saperia (BGS Systems Inc.)
      Steve Waldbusser (International Network Services)
      Glenn W. Waters (Bell-Northern Research Ltd.)

10. Security Considerations

   The SNMP applications described in this document typically have
   direct access to MIB instrumentation.  Thus, it is very important
   that these applications be strict in their application of access
   control as described in this document.

   In addition, there may be some types of notification generator
   applications which, rather than accessing MIB instrumentation using
   access control, will obtain MIB information through other means (such
   as from a command line).  The implementors and users of such
   applications must be responsible for not divulging MIB information
   that normally would be inaccessible due to access control.

   Finally, the MIBs described in this document contain potentially
   sensitive information.  A security administrator may wish to limit
   access to these MIBs.

11. References

11.1 Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Structure of Management
               Information Version 2 (SMIv2)", STD 58, RFC 2578, April
               1999.

   [RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Textual Conventions for
               SMIv2", STD 58, RFC 2579, April 1999.



Levi, et. al.               Standards Track                    [Page 69]


RFC 3413                   SNMP Applications               December 2002


   [RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Conformance Statements for
               SMIv2", STD 58, RFC 2580, April 1999.

   [RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An
               Architecture for describing Simple Network Management
               Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
               December 2002.

   [RFC3412]   Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
               "Message Processing and Dispatching for the Simple
               Network Management Protocol (SNMP)", STD 62, RFC 3412,
               December 2002.

   [RFC3415]   Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model (VACM) for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3415, December
               2002.

   [RFC3416]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
               Waldbusser, "Protocol Operations for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3416, December
               2002.

   [RFC3418]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
               Waldbusser, "Management Information Base (MIB) for the
               Simple Network Management Protocol (SNMP)", STD 62, RFC
               3418, December 2002.

11.2 Informative References

   [RFC1157]   Case, J., Fedor, M., Schoffstall, M. and J. Davin,
               "Simple Network Management Protocol", STD 15, RFC 1157,
               May 1990.

   [RFC1213]   McCloghrie, K. and M. Rose, Editors, "Management
               Information Base for Network Management of TCP/IP-based
               internets:  MIB-II", STD 17, RFC 1213, March 1991.

   [RFC2576]   Frye, R.,Levi, D., Routhier, S. and B. Wijnen,
               "Coexistence between Version 1, Version 2, and Version 3
               of the Internet-standard Network Management Framework",
               RFC 2576, February 1999.








Levi, et. al.               Standards Track                    [Page 70]


RFC 3413                   SNMP Applications               December 2002


Appendix A - Trap Configuration Example

   This section describes an example configuration for a Notification
   Generator application which implements the snmpNotifyBasicCompliance
   level.  The example configuration specifies that the Notification
   Generator should send notifications to 3 separate managers, using
   authentication and no privacy for the first 2 managers, and using
   both authentication and privacy for the third manager.

   The configuration consists of three rows in the snmpTargetAddrTable,
   two rows in the snmpTargetTable, and two rows in the snmpNotifyTable.

      * snmpTargetAddrName        = "addr1"
        snmpTargetAddrTDomain     = snmpUDPDomain
        snmpTargetAddrTAddress    = 128.1.2.3/162
        snmpTargetAddrTagList     = "group1"
        snmpTargetAddrParams      = "AuthNoPriv-joe"
        snmpTargetAddrStorageType = readOnly(5)
        snmpTargetAddrRowStatus   = active(1)

      * snmpTargetAddrName        = "addr2"
        snmpTargetAddrTDomain     = snmpUDPDomain
        snmpTargetAddrTAddress    = 128.2.4.6/162
        snmpTargetAddrTagList     = "group1"
        snmpTargetAddrParams      = "AuthNoPriv-joe"
        snmpTargetAddrStorageType = readOnly(5)
        snmpTargetAddrRowStatus   = active(1)

      * snmpTargetAddrName        = "addr3"
        snmpTargetAddrTDomain     = snmpUDPDomain
        snmpTargetAddrTAddress    = 128.1.5.9/162
        snmpTargetAddrTagList     = "group2"
        snmpTargetAddrParams      = "AuthPriv-bob"
        snmpTargetAddrStorageType = readOnly(5)
        snmpTargetAddrRowStatus   = active(1)

      * snmpTargetParamsName                   = "AuthNoPriv-joe"
        snmpTargetParamsMPModel                = 3
        snmpTargetParamsSecurityModel          = 3 (USM)
        snmpTargetParamsSecurityName           = "joe"
        snmpTargetParamsSecurityLevel          = authNoPriv(2)
        snmpTargetParamsStorageType            = readOnly(5)
        snmpTargetParamsRowStatus              = active(1)








Levi, et. al.               Standards Track                    [Page 71]


RFC 3413                   SNMP Applications               December 2002


      * snmpTargetParamsName                   = "AuthPriv-bob"
        snmpTargetParamsMPModel                = 3
        snmpTargetParamsSecurityModel          = 3 (USM)
        snmpTargetParamsSecurityName           = "bob"
        snmpTargetParamsSecurityLevel          = authPriv(3)
        snmpTargetParamsStorageType            = readOnly(5)
        snmpTargetParamsRowStatus              = active(1)

      * snmpNotifyName         = "group1"
        snmpNotifyTag          = "group1"
        snmpNotifyType         = trap(1)
        snmpNotifyStorageType  = readOnly(5)
        snmpNotifyRowStatus    = active(1)

      * snmpNotifyName         = "group2"
        snmpNotifyTag          = "group2"
        snmpNotifyType         = trap(1)
        snmpNotifyStorageType  = readOnly(5)
        snmpNotifyRowStatus    = active(1)

   These entries define two groups of management targets.  The first
   group contains two management targets:

                                first target      second target
                                ------------      -------------
      messageProcessingModel   SNMPv3            SNMPv3
               securityModel   3 (USM)           3 (USM)
                securityName   "joe"             "joe"
               securityLevel   authNoPriv(2)     authNoPriv(2)
             transportDomain   snmpUDPDomain     snmpUDPDomain
            transportAddress   128.1.2.3/162     128.2.4.6/162

   And the second group contains a single management target:

      messageProcessingModel   SNMPv3
               securityLevel   authPriv(3)
               securityModel   3 (USM)
                securityName   "bob"
             transportDomain   snmpUDPDomain
            transportAddress   128.1.5.9/162











Levi, et. al.               Standards Track                    [Page 72]


RFC 3413                   SNMP Applications               December 2002


Editors' Addresses

   David B. Levi
   Nortel Networks
   3505 Kesterwood Drive
   Knoxville, TN 37918
   U.S.A.

   Phone: +1 865 686 0432
   EMail: dlevi@nortelnetworks.com


   Paul Meyer
   Secure Computing Corporation
   2675 Long Lake Road
   Roseville, MN 55113
   U.S.A.

   Phone: +1 651 628 1592
   EMail: paul_meyer@securecomputing.com


   Bob Stewart
   Retired



























Levi, et. al.               Standards Track                    [Page 73]


RFC 3413                   SNMP Applications               December 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Levi, et. al.               Standards Track                    [Page 74]

========================================================================






Network Working Group                                      U. Blumenthal
Request for Comments: 3414                                     B. Wijnen
STD: 62                                              Lucent Technologies
Obsoletes: 2574                                            December 2002
Category: Standards Track


          User-based Security Model (USM) for version 3 of the
              Simple Network Management Protocol (SNMPv3)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes the User-based Security Model (USM) for
   Simple Network Management Protocol (SNMP) version 3 for use in the
   SNMP architecture.  It defines the Elements of Procedure for
   providing SNMP message level security.  This document also includes a
   Management Information Base (MIB) for remotely monitoring/managing
   the configuration parameters for this Security Model.  This document
   obsoletes RFC 2574.

Table of Contents

   1.        Introduction..........................................  4
   1.1.      Threats...............................................  4
   1.2.      Goals and Constraints.................................  6
   1.3.      Security Services.....................................  6
   1.4.      Module Organization...................................  7
   1.4.1.    Timeliness Module.....................................  8
   1.4.2.    Authentication Protocol...............................  8
   1.4.3.    Privacy Protocol......................................  8
   1.5.      Protection against Message Replay, Delay
             and Redirection.......................................  9
   1.5.1.    Authoritative SNMP engine.............................  9
   1.5.2.    Mechanisms............................................  9
   1.6.      Abstract Service Interfaces........................... 11




Blumenthal & Wijnen         Standards Track                     [Page 1]


RFC 3414                     USM for SNMPv3                December 2002


   1.6.1.    User-based Security Model Primitives
             for Authentication.................................... 11
   1.6.2.    User-based Security Model Primitives
             for Privacy........................................... 12
   2.        Elements of the Model................................. 12
   2.1.      User-based Security Model Users....................... 12
   2.2.      Replay Protection..................................... 13
   2.2.1.    msgAuthoritativeEngineID.............................. 14
   2.2.2.    msgAuthoritativeEngineBoots and
             msgAuthoritativeEngineTime............................ 14
   2.2.3.    Time Window........................................... 15
   2.3.      Time Synchronization.................................. 15
   2.4.      SNMP Messages Using this Security Model............... 16
   2.5.      Services provided by the User-based Security Model.... 17
   2.5.1.    Services for Generating an Outgoing SNMP Message...... 17
   2.5.2.    Services for Processing an Incoming SNMP Message...... 20
   2.6.      Key Localization Algorithm............................ 22
   3.        Elements of Procedure................................. 22
   3.1.      Generating an Outgoing SNMP Message................... 22
   3.2.      Processing an Incoming SNMP Message................... 26
   4.        Discovery............................................. 31
   5.        Definitions........................................... 32
   6.        HMAC-MD5-96 Authentication Protocol................... 51
   6.1.      Mechanisms............................................ 51
   6.1.1.    Digest Authentication Mechanism....................... 51
   6.2.      Elements of the Digest Authentication Protocol........ 52
   6.2.1.    Users................................................. 52
   6.2.2.    msgAuthoritativeEngineID.............................. 53
   6.2.3.    SNMP Messages Using this Authentication Protocol...... 53
   6.2.4.    Services provided by the HMAC-MD5-96
             Authentication Module................................. 53
   6.2.4.1.  Services for Generating an Outgoing SNMP Message...... 53
   6.2.4.2.  Services for Processing an Incoming SNMP Message...... 54
   6.3.      Elements of Procedure................................. 55
   6.3.1.    Processing an Outgoing Message........................ 55
   6.3.2.    Processing an Incoming Message........................ 56
   7.        HMAC-SHA-96 Authentication Protocol................... 57
   7.1.      Mechanisms............................................ 57
   7.1.1.    Digest Authentication Mechanism....................... 57
   7.2.      Elements of the HMAC-SHA-96 Authentication Protocol... 58
   7.2.1.    Users................................................. 58
   7.2.2.    msgAuthoritativeEngineID.............................. 58
   7.2.3.    SNMP Messages Using this Authentication Protocol...... 59
   7.2.4.    Services provided by the HMAC-SHA-96
             Authentication Module................................. 59
   7.2.4.1.  Services for Generating an Outgoing SNMP Message...... 59
   7.2.4.2.  Services for Processing an Incoming SNMP Message...... 60
   7.3.      Elements of Procedure................................. 61



Blumenthal & Wijnen         Standards Track                     [Page 2]


RFC 3414                     USM for SNMPv3                December 2002


   7.3.1.    Processing an Outgoing Message........................ 61
   7.3.2.    Processing an Incoming Message........................ 61
   8.        CBC-DES Symmetric Encryption Protocol................. 63
   8.1.      Mechanisms............................................ 63
   8.1.1.    Symmetric Encryption Protocol......................... 63
   8.1.1.1.  DES key and Initialization Vector..................... 64
   8.1.1.2.  Data Encryption....................................... 65
   8.1.1.3.  Data Decryption....................................... 65
   8.2.      Elements of the DES Privacy Protocol.................. 65
   8.2.1.    Users................................................. 65
   8.2.2.    msgAuthoritativeEngineID.............................. 66
   8.2.3.    SNMP Messages Using this Privacy Protocol............. 66
   8.2.4.    Services provided by the DES Privacy Module........... 66
   8.2.4.1.  Services for Encrypting Outgoing Data................. 66
   8.2.4.2.  Services for Decrypting Incoming Data................. 67
   8.3.      Elements of Procedure................................. 68
   8.3.1.    Processing an Outgoing Message........................ 68
   8.3.2.    Processing an Incoming Message........................ 69
   9.        Intellectual Property................................. 69
   10.       Acknowledgements...................................... 70
   11.       Security Considerations............................... 71
   11.1.     Recommended Practices................................. 71
   11.2.     Defining Users........................................ 73
   11.3.     Conformance........................................... 74
   11.4.     Use of Reports........................................ 75
   11.5.     Access to the SNMP-USER-BASED-SM-MIB.................. 75
   12.       References............................................ 75
   A.1.      SNMP engine Installation Parameters................... 78
   A.2.      Password to Key Algorithm............................. 80
   A.2.1.    Password to Key Sample Code for MD5................... 81
   A.2.2.    Password to Key Sample Code for SHA................... 82
   A.3.      Password to Key Sample Results........................ 83
   A.3.1.    Password to Key Sample Results using MD5.............. 83
   A.3.2.    Password to Key Sample Results using SHA.............. 83
   A.4.      Sample encoding of msgSecurityParameters.............. 83
   A.5.      Sample keyChange Results.............................. 84
   A.5.1.    Sample keyChange Results using MD5.................... 84
   A.5.2.    Sample keyChange Results using SHA.................... 85
   B.        Change Log............................................ 86
             Editors' Addresses.................................... 87
             Full Copyright Statement.............................. 88










Blumenthal & Wijnen         Standards Track                     [Page 3]


RFC 3414                     USM for SNMPv3                December 2002


1. Introduction

   The Architecture for describing Internet Management Frameworks
   [RFC3411] describes that an SNMP engine is composed of:

   1) a Dispatcher,
   2) a Message Processing Subsystem,
   3) a Security Subsystem, and
   4) an Access Control Subsystem.

   Applications make use of the services of these subsystems.

   It is important to understand the SNMP architecture and the
   terminology of the architecture to understand where the Security
   Model described in this document fits into the architecture and
   interacts with other subsystems within the architecture.  The reader
   is expected to have read and understood the description of the SNMP
   architecture, as defined in [RFC3411].

   This memo describes the User-based Security Model as it is used
   within the SNMP Architecture.  The main idea is that we use the
   traditional concept of a user (identified by a userName) with which
   to associate security information.

   This memo describes the use of HMAC-MD5-96 and HMAC-SHA-96 as the
   authentication protocols and the use of CBC-DES as the privacy
   protocol.  The User-based Security Model however allows for other
   such protocols to be used instead of or concurrent with these
   protocols.  Therefore, the description of HMAC-MD5-96, HMAC-SHA-96
   and CBC-DES are in separate sections to reflect their self-contained
   nature and to indicate that they can be replaced or supplemented in
   the future.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.1. Threats

   Several of the classical threats to network protocols are applicable
   to the network management problem and therefore would be applicable
   to any SNMP Security Model.  Other threats are not applicable to the
   network management problem.  This section discusses principal
   threats, secondary threats, and threats which are of lesser
   importance.

   The principal threats against which this SNMP Security Model should
   provide protection are:



Blumenthal & Wijnen         Standards Track                     [Page 4]


RFC 3414                     USM for SNMPv3                December 2002


   - Modification of Information The modification threat is the danger
     that some unauthorized entity may alter in-transit SNMP messages
     generated on behalf of an authorized principal in such a way as to
     effect unauthorized management operations, including falsifying the
     value of an object.

   - Masquerade The masquerade threat is the danger that management
     operations not authorized for some user may be attempted by
     assuming the identity of another user that has the appropriate
     authorizations.

   Two secondary threats are also identified.  The Security Model
   defined in this memo provides limited protection against:

   - Disclosure The disclosure threat is the danger of eavesdropping on
     the exchanges between managed agents and a management station.
     Protecting against this threat may be required as a matter of local
     policy.

   - Message Stream Modification The SNMP protocol is typically based
     upon a connection-less transport service which may operate over any
     sub-network service.  The re-ordering, delay or replay of messages
     can and does occur through the natural operation of many such sub-
     network services.  The message stream modification threat is the
     danger that messages may be maliciously re-ordered, delayed or
     replayed to an extent which is greater than can occur through the
     natural operation of a sub-network service, in order to effect
     unauthorized management operations.

   There are at least two threats that an SNMP Security Model need not
   protect against.  The security protocols defined in this memo do not
   provide protection against:

   - Denial of Service This SNMP Security Model does not attempt to
     address the broad range of attacks by which service on behalf of
     authorized users is denied.  Indeed, such denial-of-service attacks
     are in many cases indistinguishable from the type of network
     failures with which any viable network management protocol must
     cope as a matter of course.

   - Traffic Analysis This SNMP Security Model does not attempt to
     address traffic analysis attacks.  Indeed, many traffic patterns
     are predictable - devices may be managed on a regular basis by a
     relatively small number of management applications - and therefore
     there is no significant advantage afforded by protecting against
     traffic analysis.





Blumenthal & Wijnen         Standards Track                     [Page 5]


RFC 3414                     USM for SNMPv3                December 2002


1.2. Goals and Constraints

   Based on the foregoing account of threats in the SNMP network
   management environment, the goals of this SNMP Security Model are as
   follows.

   1) Provide for verification that each received SNMP message has not
      been modified during its transmission through the network.

   2) Provide for verification of the identity of the user on whose
      behalf a received SNMP message claims to have been generated.

   3) Provide for detection of received SNMP messages, which request or
      contain management information, whose time of generation was not
      recent.

   4) Provide, when necessary, that the contents of each received SNMP
      message are protected from disclosure.

   In addition to the principal goal of supporting secure network
   management, the design of this SNMP Security Model is also influenced
   by the following constraints:

   1) When the requirements of effective management in times of network
      stress are inconsistent with those of security, the design of USM
      has given preference to the former.

   2) Neither the security protocol nor its underlying security
      mechanisms should depend upon the ready availability of other
      network services (e.g., Network Time Protocol (NTP) or key
      management protocols).

   3) A security mechanism should entail no changes to the basic SNMP
      network management philosophy.

1.3. Security Services

   The security services necessary to support the goals of this SNMP
   Security Model are as follows:

   - Data Integrity is the provision of the property that data has not
     been altered or destroyed in an unauthorized manner, nor have data
     sequences been altered to an extent greater than can occur non-
     maliciously.

   - Data Origin Authentication is the provision of the property that
     the claimed identity of the user on whose behalf received data was
     originated is corroborated.



Blumenthal & Wijnen         Standards Track                     [Page 6]


RFC 3414                     USM for SNMPv3                December 2002


   - Data Confidentiality is the provision of the property that
     information is not made available or disclosed to unauthorized
     individuals, entities, or processes.

   - Message timeliness and limited replay protection is the provision
     of the property that a message whose generation time is outside of
     a specified time window is not accepted.  Note that message
     reordering is not dealt with and can occur in normal conditions
     too.

   For the protocols specified in this memo, it is not possible to
   assure the specific originator of a received SNMP message; rather, it
   is the user on whose behalf the message was originated that is
   authenticated.

   For these protocols, it not possible to obtain data integrity without
   data origin authentication, nor is it possible to obtain data origin
   authentication without data integrity.  Further, there is no
   provision for data confidentiality without both data integrity and
   data origin authentication.

   The security protocols used in this memo are considered acceptably
   secure at the time of writing.  However, the procedures allow for new
   authentication and privacy methods to be specified at a future time
   if the need arises.

1.4. Module Organization

   The security protocols defined in this memo are split in three
   different modules and each has its specific responsibilities such
   that together they realize the goals and security services described
   above:

   - The authentication module MUST provide for:

     - Data Integrity,

     - Data Origin Authentication,

   - The timeliness module MUST provide for:

     - Protection against message delay or replay (to an extent greater
       than can occur through normal operation).

   - The privacy module MUST provide for

     - Protection against disclosure of the message payload.




Blumenthal & Wijnen         Standards Track                     [Page 7]


RFC 3414                     USM for SNMPv3                December 2002


   The timeliness module is fixed for the User-based Security Model
   while there is provision for multiple authentication and/or privacy
   modules, each of which implements a specific authentication or
   privacy protocol respectively.

1.4.1. Timeliness Module

   Section 3 (Elements of Procedure) uses the timeliness values in an
   SNMP message to do timeliness checking.  The timeliness check is only
   performed if authentication is applied to the message.  Since the
   complete message is checked for integrity, we can assume that the
   timeliness values in a message that passes the authentication module
   are trustworthy.

1.4.2. Authentication Protocol

   Section 6 describes the HMAC-MD5-96 authentication protocol which is
   the first authentication protocol that MUST be supported with the
   User-based Security Model.  Section 7 describes the HMAC-SHA-96
   authentication protocol which is another authentication protocol that
   SHOULD be supported with the User-based Security Model.  In the
   future additional or replacement authentication protocols may be
   defined as new needs arise.

   The User-based Security Model prescribes that, if authentication is
   used, then the complete message is checked for integrity in the
   authentication module.

   For a message to be authenticated, it needs to pass authentication
   check by the authentication module and the timeliness check which is
   a fixed part of this User-based Security model.

1.4.3. Privacy Protocol

   Section 8 describes the CBC-DES Symmetric Encryption Protocol which
   is the first privacy protocol to be used with the User-based Security
   Model.  In the future additional or replacement privacy protocols may
   be defined as new needs arise.

   The User-based Security Model prescribes that the scopedPDU is
   protected from disclosure when a message is sent with privacy.

   The User-based Security Model also prescribes that a message needs to
   be authenticated if privacy is in use.







Blumenthal & Wijnen         Standards Track                     [Page 8]


RFC 3414                     USM for SNMPv3                December 2002


1.5. Protection against Message Replay, Delay and Redirection

1.5.1. Authoritative SNMP Engine

   In order to protect against message replay, delay and redirection,
   one of the SNMP engines involved in each communication is designated
   to be the authoritative SNMP engine.  When an SNMP message contains a
   payload which expects a response (those messages that contain a
   Confirmed Class PDU [RFC3411]), then the receiver of such messages is
   authoritative.  When an SNMP message contains a payload which does
   not expect a response (those messages that contain an Unconfirmed
   Class PDU [RFC3411]), then the sender of such a message is
   authoritative.

1.5.2. Mechanisms

   The following mechanisms are used:

   1) To protect against the threat of message delay or replay (to an
      extent greater than can occur through normal operation), a set of
      timeliness indicators (for the authoritative SNMP engine) are
      included in each message generated.  An SNMP engine evaluates the
      timeliness indicators to determine if a received message is
      recent.  An SNMP engine may evaluate the timeliness indicators to
      ensure that a received message is at least as recent as the last
      message it received from the same source.  A non-authoritative
      SNMP engine uses received authentic messages to advance its notion
      of the timeliness indicators at the remote authoritative source.

      An SNMP engine MUST also use a mechanism to match incoming
      Responses to outstanding Requests and it MUST drop any Responses
      that do not match an outstanding request.  For example, a msgID
      can be inserted in every message to cater for this functionality.

      These mechanisms provide for the detection of authenticated
      messages whose time of generation was not recent.

      This protection against the threat of message delay or replay does
      not imply nor provide any protection against unauthorized deletion
      or suppression of messages.  Also, an SNMP engine may not be able
      to detect message reordering if all the messages involved are sent
      within the Time Window interval.  Other mechanisms defined
      independently of the security protocol can also be used to detect
      the re-ordering replay, deletion, or suppression of messages
      containing Set operations (e.g., the MIB variable snmpSetSerialNo
      [RFC3418]).





Blumenthal & Wijnen         Standards Track                     [Page 9]


RFC 3414                     USM for SNMPv3                December 2002


   2) Verification that a message sent to/from one authoritative SNMP
      engine cannot be replayed to/as-if-from another authoritative SNMP
      engine.

      Included in each message is an identifier unique to the
      authoritative SNMP engine associated with the sender or intended
      recipient of the message.

      A message containing an Unconfirmed Class PDU sent by an
      authoritative SNMP engine to one non-authoritative SNMP engine can
      potentially be replayed to another non-authoritative SNMP engine.
      The latter non-authoritative SNMP engine might (if it knows about
      the same userName with the same secrets at the authoritative SNMP
      engine) as a result update its notion of timeliness indicators of
      the authoritative SNMP engine, but that is not considered a
      threat.  In this case, A Report or Response message will be
      discarded by the Message Processing Model, because there should
      not be an outstanding Request message.  A Trap will possibly be
      accepted.  Again, that is not considered a threat, because the
      communication was authenticated and timely.  It is as if the
      authoritative SNMP engine was configured to start sending Traps to
      the second SNMP engine, which theoretically can happen without the
      knowledge of the second SNMP engine anyway.  Anyway, the second
      SNMP engine may not expect to receive this Trap, but is allowed to
      see the management information contained in it.

   3) Detection of messages which were not recently generated.

      A set of time indicators are included in the message, indicating
      the time of generation.  Messages without recent time indicators
      are not considered authentic.  In addition, an SNMP engine MUST
      drop any Responses that do not match an outstanding request.  This
      however is the responsibility of the Message Processing Model.

   This memo allows the same user to be defined on multiple SNMP
   engines.  Each SNMP engine maintains a value, snmpEngineID, which
   uniquely identifies the SNMP engine.  This value is included in each
   message sent to/from the SNMP engine that is authoritative (see
   section 1.5.1).  On receipt of a message, an authoritative SNMP
   engine checks the value to ensure that it is the intended recipient,
   and a non-authoritative SNMP engine uses the value to ensure that the
   message is processed using the correct state information.

   Each SNMP engine maintains two values, snmpEngineBoots and
   snmpEngineTime, which taken together provide an indication of time at
   that SNMP engine.  Both of these values are included in an
   authenticated message sent to/received from that SNMP engine.  On
   receipt, the values are checked to ensure that the indicated



Blumenthal & Wijnen         Standards Track                    [Page 10]


RFC 3414                     USM for SNMPv3                December 2002


   timeliness value is within a Time Window of the current time.  The
   Time Window represents an administrative upper bound on acceptable
   delivery delay for protocol messages.

   For an SNMP engine to generate a message which an authoritative SNMP
   engine will accept as authentic, and to verify that a message
   received from that authoritative SNMP engine is authentic, such an
   SNMP engine must first achieve timeliness synchronization with the
   authoritative SNMP engine.  See section 2.3.

1.6. Abstract Service Interfaces

   Abstract service interfaces have been defined to describe the
   conceptual interfaces between the various subsystems within an SNMP
   entity.  Similarly a set of abstract service interfaces have been
   defined within the User-based Security Model (USM) to describe the
   conceptual interfaces between the generic USM services and the
   self-contained authentication and privacy services.

   These abstract service interfaces are defined by a set of primitives
   that define the services provided and the abstract data elements that
   must be passed when the services are invoked.  This section lists the
   primitives that have been defined for the User-based Security Model.

1.6.1. User-based Security Model Primitives for Authentication

   The User-based Security Model provides the following internal
   primitives to pass data back and forth between the Security Model
   itself and the authentication service:

   statusInformation =
     authenticateOutgoingMsg(
     IN   authKey                   -- secret key for authentication
     IN   wholeMsg                  -- unauthenticated complete message
     OUT  authenticatedWholeMsg     -- complete authenticated message
          )

   statusInformation =
     authenticateIncomingMsg(
     IN   authKey                   -- secret key for authentication
     IN   authParameters            -- as received on the wire
     IN   wholeMsg                  -- as received on the wire
     OUT  authenticatedWholeMsg     -- complete authenticated message
          )







Blumenthal & Wijnen         Standards Track                    [Page 11]


RFC 3414                     USM for SNMPv3                December 2002


1.6.2. User-based Security Model Primitives for Privacy

   The User-based Security Model provides the following internal
   primitives to pass data back and forth between the Security Model
   itself and the privacy service:

   statusInformation =
     encryptData(
     IN    encryptKey               -- secret key for encryption
     IN    dataToEncrypt            -- data to encrypt (scopedPDU)
     OUT   encryptedData            -- encrypted data (encryptedPDU)
     OUT   privParameters           -- filled in by service provider
           )

   statusInformation =
     decryptData(
     IN    decryptKey               -- secret key for decrypting
     IN    privParameters           -- as received on the wire
     IN    encryptedData            -- encrypted data (encryptedPDU)
     OUT   decryptedData            -- decrypted data (scopedPDU)
           )

2. Elements of the Model

   This section contains definitions required to realize the security
   model defined by this memo.

2.1. User-based Security Model Users

   Management operations using this Security Model make use of a defined
   set of user identities.  For any user on whose behalf management
   operations are authorized at a particular SNMP engine, that SNMP
   engine must have knowledge of that user.  An SNMP engine that wishes
   to communicate with another SNMP engine must also have knowledge of a
   user known to that engine, including knowledge of the applicable
   attributes of that user.

   A user and its attributes are defined as follows:

   userName
      A string representing the name of the user.

   securityName
      A human-readable string representing the user in a format that is
      Security Model independent.  There is a one-to-one relationship
      between userName and securityName.





Blumenthal & Wijnen         Standards Track                    [Page 12]


RFC 3414                     USM for SNMPv3                December 2002


   authProtocol
      An indication of whether messages sent on behalf of this user can
      be authenticated, and if so, the type of authentication protocol
      which is used.  Two such protocols are defined in this memo:

      - the HMAC-MD5-96 authentication protocol.
      - the HMAC-SHA-96 authentication protocol.

   authKey
      If messages sent on behalf of this user can be authenticated, the
      (private) authentication key for use with the authentication
      protocol.  Note that a user's authentication key will normally be
      different at different authoritative SNMP engines.  The authKey is
      not accessible via SNMP.  The length requirements of the authKey
      are defined by the authProtocol in use.

   authKeyChange and authOwnKeyChange
      The only way to remotely update the authentication key.  Does that
      in a secure manner, so that the update can be completed without
      the need to employ privacy protection.

   privProtocol
      An indication of whether messages sent on behalf of this user can
      be protected from disclosure, and if so, the type of privacy
      protocol which is used.  One such protocol is defined in this
      memo:  the CBC-DES Symmetric Encryption Protocol.

   privKey
      If messages sent on behalf of this user can be en/decrypted, the
      (private) privacy key for use with the privacy protocol.  Note
      that a user's privacy key will normally be different at different
      authoritative SNMP engines.  The privKey is not accessible via
      SNMP.  The length requirements of the privKey are defined by the
      privProtocol in use.

   privKeyChange and privOwnKeyChange
      The only way to remotely update the encryption key.  Does that in
      a secure manner, so that the update can be completed without the
      need to employ privacy protection.

2.2. Replay Protection

   Each SNMP engine maintains three objects:

   - snmpEngineID, which (at least within an administrative domain)
     uniquely and unambiguously identifies an SNMP engine.





Blumenthal & Wijnen         Standards Track                    [Page 13]


RFC 3414                     USM for SNMPv3                December 2002


   - snmpEngineBoots, which is a count of the number of times the SNMP
     engine has re-booted/re-initialized since snmpEngineID was last
     configured; and,

   - snmpEngineTime, which is the number of seconds since the
     snmpEngineBoots counter was last incremented.

   Each SNMP engine is always authoritative with respect to these
   objects in its own SNMP entity.  It is the responsibility of a non-
   authoritative SNMP engine to synchronize with the authoritative SNMP
   engine, as appropriate.

   An authoritative SNMP engine is required to maintain the values of
   its snmpEngineID and snmpEngineBoots in non-volatile storage.

2.2.1. msgAuthoritativeEngineID

   The msgAuthoritativeEngineID value contained in an authenticated
   message is used to defeat attacks in which messages from one SNMP
   engine to another SNMP engine are replayed to a different SNMP
   engine.  It represents the snmpEngineID at the authoritative SNMP
   engine involved in the exchange of the message.

   When an authoritative SNMP engine is first installed, it sets its
   local value of snmpEngineID according to a enterprise-specific
   algorithm (see the definition of the Textual Convention for
   SnmpEngineID in the SNMP Architecture document [RFC3411]).

2.2.2. msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime

   The msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime values
   contained in an authenticated message are used to defeat attacks in
   which messages are replayed when they are no longer valid.  They
   represent the snmpEngineBoots and snmpEngineTime values at the
   authoritative SNMP engine involved in the exchange of the message.

   Through use of snmpEngineBoots and snmpEngineTime, there is no
   requirement for an SNMP engine to have a non-volatile clock which
   ticks (i.e., increases with the passage of time) even when the
   SNMP engine is powered off.  Rather, each time an SNMP engine
   re-boots, it retrieves, increments, and then stores snmpEngineBoots
   in non-volatile storage, and resets snmpEngineTime to zero.

   When an SNMP engine is first installed, it sets its local values of
   snmpEngineBoots and snmpEngineTime to zero.  If snmpEngineTime ever
   reaches its maximum value (2147483647), then snmpEngineBoots is
   incremented as if the SNMP engine has re-booted and snmpEngineTime is
   reset to zero and starts incrementing again.



Blumenthal & Wijnen         Standards Track                    [Page 14]


RFC 3414                     USM for SNMPv3                December 2002


   Each time an authoritative SNMP engine re-boots, any SNMP engines
   holding that authoritative SNMP engine's values of snmpEngineBoots
   and snmpEngineTime need to re-synchronize prior to sending correctly
   authenticated messages to that authoritative SNMP engine (see Section
   2.3 for (re-)synchronization procedures).  Note, however, that the
   procedures do provide for a notification to be accepted as authentic
   by a receiving SNMP engine, when sent by an authoritative SNMP engine
   which has re-booted since the receiving SNMP engine last (re-
   )synchronized.


   If an authoritative SNMP engine is ever unable to determine its
   latest snmpEngineBoots value, then it must set its snmpEngineBoots
   value to 2147483647.

   Whenever the local value of snmpEngineBoots has the value 2147483647
   it latches at that value and an authenticated message always causes
   an notInTimeWindow authentication failure.

   In order to reset an SNMP engine whose snmpEngineBoots value has
   reached the value 2147483647, manual intervention is required.  The
   engine must be physically visited and re-configured, either with a
   new snmpEngineID value, or with new secret values for the
   authentication and privacy protocols of all users known to that SNMP
   engine.  Note that even if an SNMP engine re-boots once a second that
   it would still take approximately 68 years before the max value of
   2147483647 would be reached.

2.2.3. Time Window

   The Time Window is a value that specifies the window of time in which
   a message generated on behalf of any user is valid.  This memo
   specifies that the same value of the Time Window, 150 seconds, is
   used for all users.

2.3. Time Synchronization

   Time synchronization, required by a non-authoritative SNMP engine
   in order to proceed with authentic communications, has occurred
   when the non-authoritative SNMP engine has obtained a local notion
   of the authoritative SNMP engine's values of snmpEngineBoots and
   snmpEngineTime from the authoritative SNMP engine.  These values
   must be (and remain) within the authoritative SNMP engine's Time
   Window.  So the local notion of the authoritative SNMP engine's
   values must be kept loosely synchronized with the values stored
   at the authoritative SNMP engine.  In addition to keeping a local
   copy of snmpEngineBoots and snmpEngineTime from the authoritative
   SNMP engine, a non-authoritative SNMP engine must also keep one



Blumenthal & Wijnen         Standards Track                    [Page 15]


RFC 3414                     USM for SNMPv3                December 2002


   local variable, latestReceivedEngineTime.  This value records the
   highest value of snmpEngineTime that was received by the
   non-authoritative SNMP engine from the authoritative SNMP engine
   and is used to eliminate the possibility of replaying messages
   that would prevent the non-authoritative SNMP engine's notion of
   the snmpEngineTime from advancing.

   A non-authoritative SNMP engine must keep local notions of these
   values (snmpEngineBoots, snmpEngineTime and latestReceivedEngineTime)
   for each authoritative SNMP engine with which it wishes to
   communicate.  Since each authoritative SNMP engine is uniquely and
   unambiguously identified by its value of snmpEngineID, the
   non-authoritative SNMP engine may use this value as a key in order to
   cache its local notions of these values.

   Time synchronization occurs as part of the procedures of receiving an
   SNMP message (Section 3.2, step 7b).  As such, no explicit time
   synchronization procedure is required by a non-authoritative SNMP
   engine.  Note, that whenever the local value of snmpEngineID is
   changed (e.g., through discovery) or when secure communications are
   first established with an authoritative SNMP engine, the local values
   of snmpEngineBoots and latestReceivedEngineTime should be set to
   zero.  This will cause the time synchronization to occur when the
   next authentic message is received.

2.4. SNMP Messages Using this Security Model

   The syntax of an SNMP message using this Security Model adheres to
   the message format defined in the version-specific Message Processing
   Model document (for example [RFC3412]).

   The field msgSecurityParameters in SNMPv3 messages has a data type of
   OCTET STRING.  Its value is the BER serialization of the following
   ASN.1 sequence:

   USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN

      UsmSecurityParameters ::=
          SEQUENCE {
           -- global User-based security parameters
              msgAuthoritativeEngineID     OCTET STRING,
              msgAuthoritativeEngineBoots  INTEGER (0..2147483647),
              msgAuthoritativeEngineTime   INTEGER (0..2147483647),
              msgUserName                  OCTET STRING (SIZE(0..32)),
           -- authentication protocol specific parameters
              msgAuthenticationParameters  OCTET STRING,
           -- privacy protocol specific parameters
              msgPrivacyParameters         OCTET STRING



Blumenthal & Wijnen         Standards Track                    [Page 16]


RFC 3414                     USM for SNMPv3                December 2002


          }
   END

   The fields of this sequence are:

   - The msgAuthoritativeEngineID specifies the snmpEngineID of the
     authoritative SNMP engine involved in the exchange of the message.

   - The msgAuthoritativeEngineBoots specifies the snmpEngineBoots value
     at the authoritative SNMP engine involved in the exchange of the
     message.

   - The msgAuthoritativeEngineTime specifies the snmpEngineTime value
     at the authoritative SNMP engine involved in the exchange of the
     message.

   - The msgUserName specifies the user (principal) on whose behalf the
     message is being exchanged.  Note that a zero-length userName will
     not match any user, but it can be used for snmpEngineID discovery.

   - The msgAuthenticationParameters are defined by the authentication
     protocol in use for the message, as defined by the
     usmUserAuthProtocol column in the user's entry in the usmUserTable.

   - The msgPrivacyParameters are defined by the privacy protocol in use
     for the message, as defined by the usmUserPrivProtocol column in
     the user's entry in the usmUserTable).

   See appendix A.4 for an example of the BER encoding of field
   msgSecurityParameters.

2.5. Services provided by the User-based Security Model

   This section describes the services provided by the User-based
   Security Model with their inputs and outputs.

   The services are described as primitives of an abstract service
   interface and the inputs and outputs are described as abstract data
   elements as they are passed in these abstract service primitives.

2.5.1. Services for Generating an Outgoing SNMP Message

   When the Message Processing (MP) Subsystem invokes the User-based
   Security module to secure an outgoing SNMP message, it must use the
   appropriate service as provided by the Security module.  These two
   services are provided:





Blumenthal & Wijnen         Standards Track                    [Page 17]


RFC 3414                     USM for SNMPv3                December 2002


   1) A service to generate a Request message.  The abstract service
      primitive is:

      statusInformation =            -- success or errorIndication
        generateRequestMsg(
        IN   messageProcessingModel  -- typically, SNMP version
        IN   globalData              -- message header, admin data
        IN   maxMessageSize          -- of the sending SNMP entity
        IN   securityModel           -- for the outgoing message
        IN   securityEngineID        -- authoritative SNMP entity
        IN   securityName            -- on behalf of this principal
        IN   securityLevel           -- Level of Security requested
        IN   scopedPDU               -- message (plaintext) payload
        OUT  securityParameters      -- filled in by Security Module
        OUT  wholeMsg                -- complete generated message
        OUT  wholeMsgLength          -- length of generated message
             )

   2) A service to generate a Response message.  The abstract service
      primitive is:

      statusInformation =            -- success or errorIndication
        generateResponseMsg(
        IN   messageProcessingModel  -- typically, SNMP version
        IN   globalData              -- message header, admin data
        IN   maxMessageSize          -- of the sending SNMP entity
        IN   securityModel           -- for the outgoing message
        IN   securityEngineID        -- authoritative SNMP entity
        IN   securityName            -- on behalf of this principal
        IN   securityLevel           -- Level of Security requested
        IN   scopedPDU               -- message (plaintext) payload
        IN   securityStateReference  -- reference to security state
                                     -- information from original
                                     -- request
        OUT  securityParameters      -- filled in by Security Module
        OUT  wholeMsg                -- complete generated message
        OUT  wholeMsgLength          -- length of generated message
             )

   The abstract data elements passed as parameters in the abstract
   service primitives are as follows:

   statusInformation
      An indication of whether the encoding and securing of the message
      was successful.  If not it is an indication of the problem.






Blumenthal & Wijnen         Standards Track                    [Page 18]


RFC 3414                     USM for SNMPv3                December 2002


   messageProcessingModel
      The SNMP version number for the message to be generated.  This
      data is not used by the User-based Security module.

   globalData
      The message header (i.e., its administrative information).  This
      data is not used by the User-based Security module.

   maxMessageSize
      The maximum message size as included in the message.  This data is
      not used by the User-based Security module.

   securityParameters
      These are the security parameters.  They will be filled in by the
      User-based Security module.

   securityModel
      The securityModel in use.  Should be User-based Security Model.
      This data is not used by the User-based Security module.

   securityName
      Together with the snmpEngineID it identifies a row in the
      usmUserTablethat is to be used for securing the message.  The
      securityName has a format that is independent of the Security
      Model.  In case of a response this parameter is ignored and the
      value from the cache is used.

   securityLevel
      The Level of Security from which the User-based Security module
      determines if the message needs to be protected from disclosure
      and if the message needs to be authenticated.

   securityEngineID
      The snmpEngineID of the authoritative SNMP engine to which a
      dateRequest message is to be sent.  In case of a response it is
      implied to be the processing SNMP engine's snmpEngineID and so if
      it is specified, then it is ignored.

   scopedPDU
      The message payload.  The data is opaque as far as the User-based
      Security Model is concerned.

   securityStateReference
      A handle/reference to cachedSecurityData to be used when securing
      an outgoing Response message.  This is the exact same
      handle/reference as it was generated by the User-based Security
      module when processing the incoming Request message to which this
      is the Response message.



Blumenthal & Wijnen         Standards Track                    [Page 19]


RFC 3414                     USM for SNMPv3                December 2002


   wholeMsg
      The fully encoded and secured message ready for sending on the
      wire.

   wholeMsgLength
      The length of the encoded and secured message (wholeMsg).

   Upon completion of the process, the User-based Security module
   returns statusInformation.  If the process was successful, the
   completed message with privacy and authentication applied if such was
   requested by the specified securityLevel is returned.  If the process
   was not successful, then an errorIndication is returned.

2.5.2. Services for Processing an Incoming SNMP Message

   When the Message Processing (MP) Subsystem invokes the User-based
   Security module to verify proper security of an incoming message, it
   must use the service provided for an incoming message.  The abstract
   service primitive is:

   statusInformation =             -- errorIndication or success
                                   -- error counter OID/value if error
     processIncomingMsg(
     IN   messageProcessingModel   -- typically, SNMP version
     IN   maxMessageSize           -- of the sending SNMP entity
     IN   securityParameters       -- for the received message
     IN   securityModel            -- for the received message
     IN   securityLevel            -- Level of Security
     IN   wholeMsg                 -- as received on the wire
     IN   wholeMsgLength           -- length as received on the wire
     OUT  securityEngineID         -- authoritative SNMP entity
     OUT  securityName             -- identification of the principal
     OUT  scopedPDU,               -- message (plaintext) payload
     OUT  maxSizeResponseScopedPDU -- maximum size of the Response PDU
     OUT  securityStateReference   -- reference to security state
          )                        -- information, needed for response

   The abstract data elements passed as parameters in the abstract
   service primitives are as follows:

   statusInformation
      An indication of whether the process was successful or not.  If
      not, then the statusInformation includes the OID and the value of
      the error counter that was incremented.

   messageProcessingModel
      The SNMP version number as received in the message.  This data is
      not used by the User-based Security module.



Blumenthal & Wijnen         Standards Track                    [Page 20]


RFC 3414                     USM for SNMPv3                December 2002


   maxMessageSize
      The maximum message size as included in the message.  The User-bas
      User-based Security module uses this value to calculate the
      maxSizeResponseScopedPDU.

   securityParameters
      These are the security parameters as received in the message.

   securityModel
      The securityModel in use.  Should be the User-based Security
      Model.  This data is not used by the User-based Security module.

   securityLevel
      The Level of Security from which the User-based Security module
      determines if the message needs to be protected from disclosure
      and if the message needs to be authenticated.

   wholeMsg
      The whole message as it was received.

   wholeMsgLength
      The length of the message as it was received (wholeMsg).

   securityEngineID
      The snmpEngineID that was extracted from the field
      msgAuthoritativeEngineID and that was used to lookup the secrets
      in the usmUserTable.

   securityName
      The security name representing the user on whose behalf the
      message was received.  The securityName has a format that is
      independent of the Security Model.

   scopedPDU
      The message payload.  The data is opaque as far as the User-based
      Security Model is concerned.

   maxSizeResponseScopedPDU
      The maximum size of a scopedPDU to be included in a possible
      Response message.  The User-based Security module calculates this
      size based on the msgMaxSize (as received in the message) and the
      space required for the message header (including the
      securityParameters) for such a Response message.

   securityStateReference
      A handle/reference to cachedSecurityData to be used when securing
      an outgoing Response message.  When the Message Processing
      Subsystem calls the User-based Security module to generate a



Blumenthal & Wijnen         Standards Track                    [Page 21]


RFC 3414                     USM for SNMPv3                December 2002


      response to this incoming message it must pass this
      handle/reference.

   Upon completion of the process, the User-based Security module
   returns statusInformation and, if the process was successful, the
   additional data elements for further processing of the message.  If
   the process was not successful, then an errorIndication, possibly
   with a OID and value pair of an error counter that was incremented.

2.6. Key Localization Algorithm.

   A localized key is a secret key shared between a user U and one
   authoritative SNMP engine E.  Even though a user may have only one
   password and therefore one key for the whole network, the actual
   secrets shared between the user and each authoritative SNMP engine
   will be different.  This is achieved by key localization [Localized-
   key].

   First, if a user uses a password, then the user's password is
   converted into a key Ku using one of the two algorithms described in
   Appendices A.2.1 and A.2.2.

   To convert key Ku into a localized key Kul of user U at the
   authoritative SNMP engine E, one appends the snmpEngineID of the
   authoritative SNMP engine to the key Ku and then appends the key Ku
   to the result, thus enveloping the snmpEngineID within the two copies
   of user's key Ku.  Then one runs a secure hash function (which one
   depends on the authentication protocol defined for this user U at
   authoritative SNMP engine E; this document defines two authentication
   protocols with their associated algorithms based on MD5 and SHA).
   The output of the hash-function is the localized key Kul for user U
   at the authoritative SNMP engine E.

3. Elements of Procedure

   This section describes the security related procedures followed by an
   SNMP engine when processing SNMP messages according to the User-based
   Security Model.

3.1. Generating an Outgoing SNMP Message

   This section describes the procedure followed by an SNMP engine
   whenever it generates a message containing a management operation
   (like a request, a response, a notification, or a report) on behalf
   of a user, with a particular securityLevel.






Blumenthal & Wijnen         Standards Track                    [Page 22]


RFC 3414                     USM for SNMPv3                December 2002


   1) a) If any securityStateReference is passed (Response or Report
         message), then information concerning the user is extracted
         from the cachedSecurityData.  The cachedSecurityData can now be
         discarded.  The securityEngineID is set to the local
         snmpEngineID.  The securityLevel is set to the value specified
         by the calling module.

         Otherwise,

      b) based on the securityName, information concerning the user at
         the destination snmpEngineID, specified by the
         securityEngineID, is extracted from the Local Configuration
         Datastore (LCD, usmUserTable).  If information about the user
         is absent from the LCD, then an error indication
         (unknownSecurityName) is returned to the calling module.

   2) If the securityLevel specifies that the message is to be protected
      from disclosure, but the user does not support both an
      authentication and a privacy protocol then the message cannot be
      sent.  An error indication (unsupportedSecurityLevel) is returned
      to the calling module.

   3) If the securityLevel specifies that the message is to be
      authenticated, but the user does not support an authentication
      protocol, then the message cannot be sent.  An error indication
      (unsupportedSecurityLevel) is returned to the calling module.

   4) a) If the securityLevel specifies that the message is to be
         protected from disclosure, then the octet sequence representing
         the serialized scopedPDU is encrypted according to the user's
         privacy protocol.  To do so a call is made to the privacy
         module that implements the user's privacy protocol according to
         the abstract primitive:

         statusInformation =       -- success or failure
           encryptData(
           IN    encryptKey        -- user's localized privKey
           IN    dataToEncrypt     -- serialized scopedPDU
           OUT   encryptedData     -- serialized encryptedPDU
           OUT   privParameters    -- serialized privacy parameters
                 )

         statusInformation
           indicates if the encryption process was successful or not.

         encryptKey
           the user's localized private privKey is the secret key that
           can be used by the encryption algorithm.



Blumenthal & Wijnen         Standards Track                    [Page 23]


RFC 3414                     USM for SNMPv3                December 2002


         dataToEncrypt
           the serialized scopedPDU is the data to be encrypted.

         encryptedData
           the encryptedPDU represents the encrypted scopedPDU, encoded
           as an OCTET STRING.

         privParameters
           the privacy parameters, encoded as an OCTET STRING.

         If the privacy module returns failure, then the message cannot
         be sent and an error indication (encryptionError) is returned
         to the calling module.

         If the privacy module returns success, then the returned
         privParameters are put into the msgPrivacyParameters field of
         the securityParameters and the encryptedPDU serves as the
         payload of the message being prepared.

         Otherwise,

      b) If the securityLevel specifies that the message is not to be be
         protected from disclosure, then a zero-length OCTET STRING is
         encoded into the msgPrivacyParameters field of the
         securityParameters and the plaintext scopedPDU serves as the
         payload of the message being prepared.

   5) The securityEngineID is encoded as an OCTET STRING into the
      msgAuthoritativeEngineID field of the securityParameters.  Note
      that an empty (zero length) securityEngineID is OK for a Request
      message, because that will cause the remote (authoritative) SNMP
      engine to return a Report PDU with the proper securityEngineID
      included in the msgAuthoritativeEngineID in the securityParameters
      of that returned Report PDU.

   6) a) If the securityLevel specifies that the message is to be
         authenticated, then the current values of snmpEngineBoots and
         snmpEngineTime corresponding to the securityEngineID from the
         LCD are used.

         Otherwise,

      b) If this is a Response or Report message, then the current value
         of snmpEngineBoots and snmpEngineTime corresponding to the
         local snmpEngineID from the LCD are used.






Blumenthal & Wijnen         Standards Track                    [Page 24]


RFC 3414                     USM for SNMPv3                December 2002


         Otherwise,

      c) If this is a Request message, then a zero value is used for
         both snmpEngineBoots and snmpEngineTime.  This zero value gets
         used if snmpEngineID is empty.

         The values are encoded as INTEGER respectively into the
         msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime
         fields of the securityParameters.

   7) The userName is encoded as an OCTET STRING into the msgUserName
      field of the securityParameters.

   8) a) If the securityLevel specifies that the message is to be
         authenticated, the message is authenticated according to the
         user's authentication protocol.  To do so a call is made to the
         authentication module that implements the user's authentication
         protocol according to the abstract service primitive:

         statusInformation =
           authenticateOutgoingMsg(
           IN  authKey               -- the user's localized authKey
           IN  wholeMsg              -- unauthenticated message
           OUT authenticatedWholeMsg -- authenticated complete message
               )

         statusInformation
           indicates if authentication was successful or not.

         authKey
           the user's localized private authKey is the secret key that
           can be used by the authentication algorithm.

         wholeMsg
           the complete serialized message to be authenticated.

         authenticatedWholeMsg
           the same as the input given to the authenticateOutgoingMsg
           service, but with msgAuthenticationParameters properly
           filled in.

         If the authentication module returns failure, then the message
         cannot be sent and an error indication (authenticationFailure)
         is returned to the calling module.







Blumenthal & Wijnen         Standards Track                    [Page 25]


RFC 3414                     USM for SNMPv3                December 2002


         If the authentication module returns success, then the
         msgAuthenticationParameters field is put into the
         securityParameters and the authenticatedWholeMsg represents the
         serialization of the authenticated message being prepared.

         Otherwise,

      b) If the securityLevel specifies that the message is not to be
         authenticated then a zero-length OCTET STRING is encoded into
         the msgAuthenticationParameters field of the
         securityParameters.  The wholeMsg is now serialized and then
         represents the unauthenticated message being prepared.

   9) The completed message with its length is returned to the calling
      module with the statusInformation set to success.

3.2. Processing an Incoming SNMP Message

   This section describes the procedure followed by an SNMP engine
   whenever it receives a message containing a management operation on
   behalf of a user, with a particular securityLevel.

   To simplify the elements of procedure, the release of state
   information is not always explicitly specified.  As a general rule,
   if state information is available when a message gets discarded, the
   state information should also be released.  Also, an error indication
   can return an OID and value for an incremented counter and optionally
   a value for securityLevel, and values for contextEngineID or
   contextName for the counter.  In addition, the securityStateReference
   data is returned if any such information is available at the point
   where the error is detected.

   1)  If the received securityParameters is not the serialization
       (according to the conventions of [RFC3417]) of an OCTET STRING
       formatted according to the UsmSecurityParameters defined in
       section 2.4, then the snmpInASNParseErrs counter [RFC3418] is
       incremented, and an error indication (parseError) is returned to
       the calling module.  Note that we return without the OID and
       value of the incremented counter, because in this case there is
       not enough information to generate a Report PDU.

   2)  The values of the security parameter fields are extracted from
       the securityParameters.  The securityEngineID to be returned to
       the caller is the value of the msgAuthoritativeEngineID field.
       The cachedSecurityData is prepared and a securityStateReference
       is prepared to reference this data.  Values to be cached are:

          msgUserName



Blumenthal & Wijnen         Standards Track                    [Page 26]


RFC 3414                     USM for SNMPv3                December 2002


   3)  If the value of the msgAuthoritativeEngineID field in the
       securityParameters is unknown then:

       a) a non-authoritative SNMP engine that performs discovery may
          optionally create a new entry in its Local Configuration
          Datastore (LCD) and continue processing;

          or

       b) the usmStatsUnknownEngineIDs counter is incremented, and an
          error indication (unknownEngineID) together with the OID and
          value of the incremented counter is returned to the calling
          module.

       Note in the event that a zero-length, or other illegally sized
       msgAuthoritativeEngineID is received, b) should be chosen to
       facilitate engineID discovery.  Otherwise the choice between a)
       and b) is an implementation issue.

   4)  Information about the value of the msgUserName and
       msgAuthoritativeEngineID fields is extracted from the Local
       Configuration Datastore (LCD, usmUserTable).  If no information
       is available for the user, then the usmStatsUnknownUserNames
       counter is incremented and an error indication
       (unknownSecurityName) together with the OID and value of the
       incremented counter is returned to the calling module.

   5)  If the information about the user indicates that it does not
       support the securityLevel requested by the caller, then the
       usmStatsUnsupportedSecLevels counter is incremented and an error
       indication (unsupportedSecurityLevel) together with the OID and
       value of the incremented counter is returned to the calling
       module.

   6)  If the securityLevel specifies that the message is to be
       authenticated, then the message is authenticated according to the
       user's authentication protocol.  To do so a call is made to the
       authentication module that implements the user's authentication
       protocol according to the abstract service primitive:

       statusInformation =          -- success or failure
         authenticateIncomingMsg(
         IN   authKey               -- the user's localized authKey
         IN   authParameters        -- as received on the wire
         IN   wholeMsg              -- as received on the wire
         OUT  authenticatedWholeMsg -- checked for authentication
              )




Blumenthal & Wijnen         Standards Track                    [Page 27]


RFC 3414                     USM for SNMPv3                December 2002


       statusInformation
         indicates if authentication was successful or not.

       authKey
         the user's localized private authKey is the secret key that
         can be used by the authentication algorithm.

       wholeMsg
         the complete serialized message to be authenticated.

       authenticatedWholeMsg
         the same as the input given to the authenticateIncomingMsg
         service, but after authentication has been checked.

       If the authentication module returns failure, then the message
       cannot be trusted, so the usmStatsWrongDigests counter is
       incremented and an error indication (authenticationFailure)
       together with the OID and value of the incremented counter is
       returned to the calling module.

       If the authentication module returns success, then the message is
       authentic and can be trusted so processing continues.

   7)  If the securityLevel indicates an authenticated message, then the
       local values of snmpEngineBoots, snmpEngineTime and
       latestReceivedEngineTime corresponding to the value of the
       msgAuthoritativeEngineID field are extracted from the Local
       Configuration Datastore.

       a) If the extracted value of msgAuthoritativeEngineID is the same
          as the value of snmpEngineID of the processing SNMP engine
          (meaning this is the authoritative SNMP engine), then if any
          of the following conditions is true, then the message is
          considered to be outside of the Time Window:

          - the local value of snmpEngineBoots is 2147483647;

          - the value of the msgAuthoritativeEngineBoots field differs
            from the local value of snmpEngineBoots; or,

          - the value of the msgAuthoritativeEngineTime field differs
            from the local notion of snmpEngineTime by more than +/- 150
            seconds.

          If the message is considered to be outside of the Time Window
          then the usmStatsNotInTimeWindows counter is incremented and
          an error indication (notInTimeWindow) together with the OID,
          the value of the incremented counter, and an indication that



Blumenthal & Wijnen         Standards Track                    [Page 28]


RFC 3414                     USM for SNMPv3                December 2002


          the error must be reported with a securityLevel of authNoPriv,
          is returned to the calling module

       b) If the extracted value of msgAuthoritativeEngineID is not the
          same as the value snmpEngineID of the processing SNMP engine
          (meaning this is not the authoritative SNMP engine), then:

          1) if at least one of the following conditions is true:

             - the extracted value of the msgAuthoritativeEngineBoots
               field is greater than the local notion of the value of
               snmpEngineBoots; or,

             - the extracted value of the msgAuthoritativeEngineBoots
               field is equal to the local notion of the value of
               snmpEngineBoots, and the extracted value of
               msgAuthoritativeEngineTime field is greater than the
               value of latestReceivedEngineTime,

             then the LCD entry corresponding to the extracted value of
             the msgAuthoritativeEngineID field is updated, by setting:

             - the local notion of the value of snmpEngineBoots to the
               value of the msgAuthoritativeEngineBoots field,

             - the local notion of the value of snmpEngineTime to the
               value of the msgAuthoritativeEngineTime field, and

             - the latestReceivedEngineTime to the value of the value of
               the msgAuthoritativeEngineTime field.

          2) if any of the following conditions is true, then the
             message is considered to be outside of the Time Window:

             - the local notion of the value of snmpEngineBoots is
               2147483647;

             - the value of the msgAuthoritativeEngineBoots field is
               less than the local notion of the value of
               snmpEngineBoots; or,

             - the value of the msgAuthoritativeEngineBoots field is
               equal to the local notion of the value of snmpEngineBoots
               and the value of the msgAuthoritativeEngineTime field is
               more than 150 seconds less than the local notion of the
               value of snmpEngineTime.





Blumenthal & Wijnen         Standards Track                    [Page 29]


RFC 3414                     USM for SNMPv3                December 2002


             If the message is considered to be outside of the Time
             Window then an error indication (notInTimeWindow) is
             returned to the calling module.

             Note that this means that a too old (possibly replayed)
             message has been detected and is deemed unauthentic.

             Note that this procedure allows for the value of
             msgAuthoritativeEngineBoots in the message to be greater
             than the local notion of the value of snmpEngineBoots to
             allow for received messages to be accepted as authentic
             when received from an authoritative SNMP engine that has
             re-booted since the receiving SNMP engine last
             (re-)synchronized.

   8)  a) If the securityLevel indicates that the message was protected
          from disclosure, then the OCTET STRING representing the
          encryptedPDU is decrypted according to the user's privacy
          protocol to obtain an unencrypted serialized scopedPDU value.
          To do so a call is made to the privacy module that implements
          the user's privacy protocol according to the abstract
          primitive:

          statusInformation =       -- success or failure
            decryptData(
            IN    decryptKey        -- the user's localized privKey
            IN    privParameters    -- as received on the wire
            IN    encryptedData     -- encryptedPDU as received
            OUT   decryptedData     -- serialized decrypted scopedPDU
                  )

          statusInformation
             indicates if the decryption process was successful or not.

          decryptKey
             the user's localized private privKey is the secret key that
             can be used by the decryption algorithm.

          privParameters
             the msgPrivacyParameters, encoded as an OCTET STRING.

          encryptedData
             the encryptedPDU represents the encrypted scopedPDU,
             encoded as an OCTET STRING.

          decryptedData
             the serialized scopedPDU if decryption is successful.




Blumenthal & Wijnen         Standards Track                    [Page 30]


RFC 3414                     USM for SNMPv3                December 2002


          If the privacy module returns failure, then the message can
          not be processed, so the usmStatsDecryptionErrors counter is
          incremented and an error indication (decryptionError) together
          with the OID and value of the incremented counter is returned
          to the calling module.

          If the privacy module returns success, then the decrypted
          scopedPDU is the message payload to be returned to the calling
          module.

          Otherwise,

       b) The scopedPDU component is assumed to be in plain text and is
          the message payload to be returned to the calling module.

   9)  The maxSizeResponseScopedPDU is calculated.  This is the maximum
       size allowed for a scopedPDU for a possible Response message.
       Provision is made for a message header that allows the same
       securityLevel as the received Request.

   10) The securityName for the user is retrieved from the usmUserTable.

   11) The security data is cached as cachedSecurityData, so that a
       possible response to this message can and will use the same
       authentication and privacy secrets.  Information to be
       saved/cached is as follows:

          msgUserName,
          usmUserAuthProtocol, usmUserAuthKey
          usmUserPrivProtocol, usmUserPrivKey

   12) The statusInformation is set to success and a return is made to
       the calling module passing back the OUT parameters as specified
       in the processIncomingMsg primitive.

4. Discovery

   The User-based Security Model requires that a discovery process
   obtains sufficient information about other SNMP engines in order to
   communicate with them.  Discovery requires an non-authoritative SNMP
   engine to learn the authoritative SNMP engine's snmpEngineID value
   before communication may proceed.  This may be accomplished by
   generating a Request message with a securityLevel of noAuthNoPriv, a
   msgUserName of zero-length, a msgAuthoritativeEngineID value of zero
   length, and the varBindList left empty.  The response to this message
   will be a Report message containing the snmpEngineID of the
   authoritative SNMP engine as the value of the
   msgAuthoritativeEngineID field within the msgSecurityParameters



Blumenthal & Wijnen         Standards Track                    [Page 31]


RFC 3414                     USM for SNMPv3                December 2002


   field.  It contains a Report PDU with the usmStatsUnknownEngineIDs
   counter in the varBindList.

   If authenticated communication is required, then the discovery
   process should also establish time synchronization with the
   authoritative SNMP engine.  This may be accomplished by sending an
   authenticated Request message with the value of
   msgAuthoritativeEngineID set to the newly learned snmpEngineID and
   with the values of msgAuthoritativeEngineBoots and
   msgAuthoritativeEngineTime set to zero.  For an authenticated Request
   message, a valid userName must be used in the msgUserName field.  The
   response to this authenticated message will be a Report message
   containing the up to date values of the authoritative SNMP engine's
   snmpEngineBoots and snmpEngineTime as the value of the
   msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime fields
   respectively.  It also contains the usmStatsNotInTimeWindows counter
   in the varBindList of the Report PDU.  The time synchronization then
   happens automatically as part of the procedures in section 3.2 step
   7b.  See also section 2.3.

5. Definitions

SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE,
    OBJECT-IDENTITY,
    snmpModules, Counter32                FROM SNMPv2-SMI
    TEXTUAL-CONVENTION, TestAndIncr,
    RowStatus, RowPointer,
    StorageType, AutonomousType           FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF
    SnmpAdminString, SnmpEngineID,
    snmpAuthProtocols, snmpPrivProtocols  FROM SNMP-FRAMEWORK-MIB;

snmpUsmMIB MODULE-IDENTITY
    LAST-UPDATED "200210160000Z"            -- 16 Oct 2002, midnight
    ORGANIZATION "SNMPv3 Working Group"
    CONTACT-INFO "WG-email:   snmpv3@lists.tislabs.com
                  Subscribe:  majordomo@lists.tislabs.com
                              In msg body:  subscribe snmpv3

                  Chair:      Russ Mundy
                              Network Associates Laboratories
                  postal:     15204 Omega Drive, Suite 300
                              Rockville, MD 20850-4601
                              USA
                  email:      mundy@tislabs.com



Blumenthal & Wijnen         Standards Track                    [Page 32]


RFC 3414                     USM for SNMPv3                December 2002


                  phone:      +1 301-947-7107

                  Co-Chair:   David Harrington
                              Enterasys Networks
                  Postal:     35 Industrial Way
                              P. O. Box 5004
                              Rochester, New Hampshire 03866-5005
                              USA
                  EMail:      dbh@enterasys.com
                  Phone:      +1 603-337-2614

                  Co-editor   Uri Blumenthal
                              Lucent Technologies
                  postal:     67 Whippany Rd.
                              Whippany, NJ 07981
                              USA
                  email:      uri@lucent.com
                  phone:      +1-973-386-2163

                  Co-editor:  Bert Wijnen
                              Lucent Technologies
                  postal:     Schagen 33
                              3461 GL Linschoten
                              Netherlands
                  email:      bwijnen@lucent.com
                  phone:      +31-348-480-685
                 "
    DESCRIPTION  "The management information definitions for the
                  SNMP User-based Security Model.

                  Copyright (C) The Internet Society (2002). This
                  version of this MIB module is part of RFC 3414;
                  see the RFC itself for full legal notices.
                 "
--  Revision history

    REVISION     "200210160000Z"          -- 16 Oct 2002, midnight
    DESCRIPTION  "Changes in this revision:
                  - Updated references and contact info.
                  - Clarification to usmUserCloneFrom DESCRIPTION
                    clause
                  - Fixed 'command responder' into 'command generator'
                    in last para of DESCRIPTION clause of
                    usmUserTable.
                  This revision published as RFC3414.
                 "
    REVISION     "199901200000Z"          -- 20 Jan 1999, midnight
    DESCRIPTION  "Clarifications, published as RFC2574"



Blumenthal & Wijnen         Standards Track                    [Page 33]


RFC 3414                     USM for SNMPv3                December 2002


    REVISION     "199711200000Z"          -- 20 Nov 1997, midnight
    DESCRIPTION  "Initial version, published as RFC2274"

    ::= { snmpModules 15 }

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

usmMIBObjects     OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }

-- Identification of Authentication and Privacy Protocols ************

usmNoAuthProtocol OBJECT-IDENTITY
    STATUS        current
    DESCRIPTION  "No Authentication Protocol."
    ::= { snmpAuthProtocols 1 }

usmHMACMD5AuthProtocol OBJECT-IDENTITY
    STATUS        current
    DESCRIPTION  "The HMAC-MD5-96 Digest Authentication Protocol."
    REFERENCE    "- H. Krawczyk, M. Bellare, R. Canetti HMAC:
                    Keyed-Hashing for Message Authentication,
                    RFC2104, Feb 1997.
                  - Rivest, R., Message Digest Algorithm MD5, RFC1321.
                 "
    ::= { snmpAuthProtocols 2 }

usmHMACSHAAuthProtocol OBJECT-IDENTITY
    STATUS        current
    DESCRIPTION  "The HMAC-SHA-96 Digest Authentication Protocol."
    REFERENCE    "- H. Krawczyk, M. Bellare, R. Canetti, HMAC:
                    Keyed-Hashing for Message Authentication,
                    RFC2104, Feb 1997.
                  - Secure Hash Algorithm. NIST FIPS 180-1.
                 "
    ::= { snmpAuthProtocols 3 }

usmNoPrivProtocol OBJECT-IDENTITY
    STATUS        current
    DESCRIPTION  "No Privacy Protocol."
    ::= { snmpPrivProtocols 1 }

usmDESPrivProtocol OBJECT-IDENTITY
    STATUS        current
    DESCRIPTION  "The CBC-DES Symmetric Encryption Protocol."
    REFERENCE    "- Data Encryption Standard, National Institute of
                    Standards and Technology.  Federal Information
                    Processing Standard (FIPS) Publication 46-1.



Blumenthal & Wijnen         Standards Track                    [Page 34]


RFC 3414                     USM for SNMPv3                December 2002


                    Supersedes FIPS Publication 46,
                    (January, 1977; reaffirmed January, 1988).

                  - Data Encryption Algorithm, American National
                    Standards Institute.  ANSI X3.92-1981,
                    (December, 1980).

                  - DES Modes of Operation, National Institute of
                    Standards and Technology.  Federal Information
                    Processing Standard (FIPS) Publication 81,
                    (December, 1980).

                  - Data Encryption Algorithm - Modes of Operation,
                    American National Standards Institute.
                    ANSI X3.106-1983, (May 1983).
                 "
    ::= { snmpPrivProtocols 2 }

-- Textual Conventions ***********************************************

KeyChange ::=     TEXTUAL-CONVENTION
   STATUS         current
   DESCRIPTION
         "Every definition of an object with this syntax must identify
          a protocol P, a secret key K, and a hash algorithm H
          that produces output of L octets.

          The object's value is a manager-generated, partially-random
          value which, when modified, causes the value of the secret
          key K, to be modified via a one-way function.

          The value of an instance of this object is the concatenation
          of two components: first a 'random' component and then a
          'delta' component.

          The lengths of the random and delta components
          are given by the corresponding value of the protocol P;
          if P requires K to be a fixed length, the length of both the
          random and delta components is that fixed length; if P
          allows the length of K to be variable up to a particular
          maximum length, the length of the random component is that
          maximum length and the length of the delta component is any
          length less than or equal to that maximum length.
          For example, usmHMACMD5AuthProtocol requires K to be a fixed
          length of 16 octets and L - of 16 octets.
          usmHMACSHAAuthProtocol requires K to be a fixed length of
          20 octets and L - of 20 octets. Other protocols may define
          other sizes, as deemed appropriate.



Blumenthal & Wijnen         Standards Track                    [Page 35]


RFC 3414                     USM for SNMPv3                December 2002


          When a requester wants to change the old key K to a new
          key keyNew on a remote entity, the 'random' component is
          obtained from either a true random generator, or from a
          pseudorandom generator, and the 'delta' component is
          computed as follows:

           - a temporary variable is initialized to the existing value
             of K;
           - if the length of the keyNew is greater than L octets,
             then:
              - the random component is appended to the value of the
                temporary variable, and the result is input to the
                the hash algorithm H to produce a digest value, and
                the temporary variable is set to this digest value;
              - the value of the temporary variable is XOR-ed with
                the first (next) L-octets (16 octets in case of MD5)
                of the keyNew to produce the first (next) L-octets
                (16 octets in case of MD5) of the 'delta' component.
              - the above two steps are repeated until the unused
                portion of the keyNew component is L octets or less,
           - the random component is appended to the value of the
             temporary variable, and the result is input to the
             hash algorithm H to produce a digest value;
           - this digest value, truncated if necessary to be the same
             length as the unused portion of the keyNew, is XOR-ed
             with the unused portion of the keyNew to produce the
             (final portion of the) 'delta' component.

           For example, using MD5 as the hash algorithm H:

              iterations = (lenOfDelta - 1)/16; /* integer division */
              temp = keyOld;
              for (i = 0; i < iterations; i++) {
                  temp = MD5 (temp || random);
                  delta[i*16 .. (i*16)+15] =
                         temp XOR keyNew[i*16 .. (i*16)+15];
              }
              temp = MD5 (temp || random);
              delta[i*16 .. lenOfDelta-1] =
                     temp XOR keyNew[i*16 .. lenOfDelta-1];

          The 'random' and 'delta' components are then concatenated as
          described above, and the resulting octet string is sent to
          the recipient as the new value of an instance of this object.

          At the receiver side, when an instance of this object is set
          to a new value, then a new value of K is computed as follows:




Blumenthal & Wijnen         Standards Track                    [Page 36]


RFC 3414                     USM for SNMPv3                December 2002


           - a temporary variable is initialized to the existing value
             of K;
           - if the length of the delta component is greater than L
             octets, then:
              - the random component is appended to the value of the
                temporary variable, and the result is input to the
                hash algorithm H to produce a digest value, and the
                temporary variable is set to this digest value;
              - the value of the temporary variable is XOR-ed with
                the first (next) L-octets (16 octets in case of MD5)
                of the delta component to produce the first (next)
                L-octets (16 octets in case of MD5) of the new value
                of K.
              - the above two steps are repeated until the unused
                portion of the delta component is L octets or less,
           - the random component is appended to the value of the
             temporary variable, and the result is input to the
             hash algorithm H to produce a digest value;
           - this digest value, truncated if necessary to be the same
             length as the unused portion of the delta component, is
             XOR-ed with the unused portion of the delta component to
             produce the (final portion of the) new value of K.

           For example, using MD5 as the hash algorithm H:

              iterations = (lenOfDelta - 1)/16; /* integer division */
              temp = keyOld;
              for (i = 0; i < iterations; i++) {
                  temp = MD5 (temp || random);
                  keyNew[i*16 .. (i*16)+15] =
                         temp XOR delta[i*16 .. (i*16)+15];
              }
              temp = MD5 (temp || random);
              keyNew[i*16 .. lenOfDelta-1] =
                     temp XOR delta[i*16 .. lenOfDelta-1];

          The value of an object with this syntax, whenever it is
          retrieved by the management protocol, is always the zero
          length string.

          Note that the keyOld and keyNew are the localized keys.

          Note that it is probably wise that when an SNMP entity sends
          a SetRequest to change a key, that it keeps a copy of the old
          key until it has confirmed that the key change actually
          succeeded.
         "
    SYNTAX       OCTET STRING



Blumenthal & Wijnen         Standards Track                    [Page 37]


RFC 3414                     USM for SNMPv3                December 2002


-- Statistics for the User-based Security Model **********************


usmStats         OBJECT IDENTIFIER ::= { usmMIBObjects 1 }


usmStatsUnsupportedSecLevels OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The total number of packets received by the SNMP
                 engine which were dropped because they requested a
                 securityLevel that was unknown to the SNMP engine
                 or otherwise unavailable.
                "
    ::= { usmStats 1 }

usmStatsNotInTimeWindows OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The total number of packets received by the SNMP
                 engine which were dropped because they appeared
                 outside of the authoritative SNMP engine's window.
                "
    ::= { usmStats 2 }

usmStatsUnknownUserNames OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The total number of packets received by the SNMP
                 engine which were dropped because they referenced a
                 user that was not known to the SNMP engine.
                "
    ::= { usmStats 3 }

usmStatsUnknownEngineIDs OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The total number of packets received by the SNMP
                 engine which were dropped because they referenced an
                 snmpEngineID that was not known to the SNMP engine.
                "
    ::= { usmStats 4 }

usmStatsWrongDigests OBJECT-TYPE



Blumenthal & Wijnen         Standards Track                    [Page 38]


RFC 3414                     USM for SNMPv3                December 2002


    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The total number of packets received by the SNMP
                 engine which were dropped because they didn't
                 contain the expected digest value.
                "
    ::= { usmStats 5 }

usmStatsDecryptionErrors OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The total number of packets received by the SNMP
                 engine which were dropped because they could not be
                 decrypted.
                "
    ::= { usmStats 6 }

-- The usmUser Group ************************************************

usmUser          OBJECT IDENTIFIER ::= { usmMIBObjects 2 }

usmUserSpinLock  OBJECT-TYPE
    SYNTAX       TestAndIncr
    MAX-ACCESS   read-write
    STATUS       current
    DESCRIPTION "An advisory lock used to allow several cooperating
                 Command Generator Applications to coordinate their
                 use of facilities to alter secrets in the
                 usmUserTable.
                "
    ::= { usmUser 1 }

-- The table of valid users for the User-based Security Model ********

usmUserTable     OBJECT-TYPE
    SYNTAX       SEQUENCE OF UsmUserEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The table of users configured in the SNMP engine's
                 Local Configuration Datastore (LCD).

                 To create a new user (i.e., to instantiate a new
                 conceptual row in this table), it is recommended to
                 follow this procedure:

                   1)  GET(usmUserSpinLock.0) and save in sValue.



Blumenthal & Wijnen         Standards Track                    [Page 39]


RFC 3414                     USM for SNMPv3                December 2002


                   2)  SET(usmUserSpinLock.0=sValue,
                           usmUserCloneFrom=templateUser,
                           usmUserStatus=createAndWait)
                       You should use a template user to clone from
                       which has the proper auth/priv protocol defined.

                 If the new user is to use privacy:

                   3)  generate the keyChange value based on the secret
                       privKey of the clone-from user and the secret key
                       to be used for the new user. Let us call this
                       pkcValue.
                   4)  GET(usmUserSpinLock.0) and save in sValue.
                   5)  SET(usmUserSpinLock.0=sValue,
                           usmUserPrivKeyChange=pkcValue
                           usmUserPublic=randomValue1)
                   6)  GET(usmUserPulic) and check it has randomValue1.
                       If not, repeat steps 4-6.

                 If the new user will never use privacy:

                   7)  SET(usmUserPrivProtocol=usmNoPrivProtocol)

                 If the new user is to use authentication:

                   8)  generate the keyChange value based on the secret
                       authKey of the clone-from user and the secret key
                       to be used for the new user. Let us call this
                       akcValue.
                   9)  GET(usmUserSpinLock.0) and save in sValue.
                   10) SET(usmUserSpinLock.0=sValue,
                           usmUserAuthKeyChange=akcValue
                           usmUserPublic=randomValue2)
                   11) GET(usmUserPulic) and check it has randomValue2.
                       If not, repeat steps 9-11.

                 If the new user will never use authentication:

                   12) SET(usmUserAuthProtocol=usmNoAuthProtocol)

                 Finally, activate the new user:

                   13) SET(usmUserStatus=active)

                 The new user should now be available and ready to be
                 used for SNMPv3 communication. Note however that access
                 to MIB data must be provided via configuration of the
                 SNMP-VIEW-BASED-ACM-MIB.



Blumenthal & Wijnen         Standards Track                    [Page 40]


RFC 3414                     USM for SNMPv3                December 2002


                 The use of usmUserSpinlock is to avoid conflicts with
                 another SNMP command generator application which may
                 also be acting on the usmUserTable.
                "
    ::= { usmUser 2 }

usmUserEntry     OBJECT-TYPE
    SYNTAX       UsmUserEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "A user configured in the SNMP engine's Local
                 Configuration Datastore (LCD) for the User-based
                 Security Model.
                "
    INDEX       { usmUserEngineID,
                  usmUserName
                }
    ::= { usmUserTable 1 }

UsmUserEntry ::= SEQUENCE
    {
        usmUserEngineID         SnmpEngineID,
        usmUserName             SnmpAdminString,
        usmUserSecurityName     SnmpAdminString,
        usmUserCloneFrom        RowPointer,
        usmUserAuthProtocol     AutonomousType,
        usmUserAuthKeyChange    KeyChange,
        usmUserOwnAuthKeyChange KeyChange,
        usmUserPrivProtocol     AutonomousType,
        usmUserPrivKeyChange    KeyChange,
        usmUserOwnPrivKeyChange KeyChange,
        usmUserPublic           OCTET STRING,
        usmUserStorageType      StorageType,
        usmUserStatus           RowStatus
    }

usmUserEngineID  OBJECT-TYPE
    SYNTAX       SnmpEngineID
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An SNMP engine's administratively-unique identifier.

                 In a simple agent, this value is always that agent's
                 own snmpEngineID value.

                 The value can also take the value of the snmpEngineID
                 of a remote SNMP engine with which this user can
                 communicate.



Blumenthal & Wijnen         Standards Track                    [Page 41]


RFC 3414                     USM for SNMPv3                December 2002


                "
    ::= { usmUserEntry 1 }

usmUserName      OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "A human readable string representing the name of
                 the user.

                 This is the (User-based Security) Model dependent
                 security ID.
                "
    ::= { usmUserEntry 2 }

usmUserSecurityName OBJECT-TYPE
    SYNTAX       SnmpAdminString
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "A human readable string representing the user in
                 Security Model independent format.

                 The default transformation of the User-based Security
                 Model dependent security ID to the securityName and
                 vice versa is the identity function so that the
                 securityName is the same as the userName.
                "
    ::= { usmUserEntry 3 }

usmUserCloneFrom OBJECT-TYPE
    SYNTAX       RowPointer
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "A pointer to another conceptual row in this
                 usmUserTable.  The user in this other conceptual
                 row is called the clone-from user.

                 When a new user is created (i.e., a new conceptual
                 row is instantiated in this table), the privacy and
                 authentication parameters of the new user must be
                 cloned from its clone-from user. These parameters are:
                   - authentication protocol (usmUserAuthProtocol)
                   - privacy protocol (usmUserPrivProtocol)
                 They will be copied regardless of what the current
                 value is.

                 Cloning also causes the initial values of the secret
                 authentication key (authKey) and the secret encryption



Blumenthal & Wijnen         Standards Track                    [Page 42]


RFC 3414                     USM for SNMPv3                December 2002


                 key (privKey) of the new user to be set to the same
                 values as the corresponding secrets of the clone-from
                 user to allow the KeyChange process to occur as
                 required during user creation.

                 The first time an instance of this object is set by
                 a management operation (either at or after its
                 instantiation), the cloning process is invoked.
                 Subsequent writes are successful but invoke no
                 action to be taken by the receiver.
                 The cloning process fails with an 'inconsistentName'
                 error if the conceptual row representing the
                 clone-from user does not exist or is not in an active
                 state when the cloning process is invoked.

                 When this object is read, the ZeroDotZero OID
                 is returned.
                "
    ::= { usmUserEntry 4 }

usmUserAuthProtocol OBJECT-TYPE
    SYNTAX       AutonomousType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "An indication of whether messages sent on behalf of
                 this user to/from the SNMP engine identified by
                 usmUserEngineID, can be authenticated, and if so,
                 the type of authentication protocol which is used.

                 An instance of this object is created concurrently
                 with the creation of any other object instance for
                 the same user (i.e., as part of the processing of
                 the set operation which creates the first object
                 instance in the same conceptual row).

                 If an initial set operation (i.e. at row creation time)
                 tries to set a value for an unknown or unsupported
                 protocol, then a 'wrongValue' error must be returned.

                 The value will be overwritten/set when a set operation
                 is performed on the corresponding instance of
                 usmUserCloneFrom.

                 Once instantiated, the value of such an instance of
                 this object can only be changed via a set operation to
                 the value of the usmNoAuthProtocol.

                 If a set operation tries to change the value of an



Blumenthal & Wijnen         Standards Track                    [Page 43]


RFC 3414                     USM for SNMPv3                December 2002


                 existing instance of this object to any value other
                 than usmNoAuthProtocol, then an 'inconsistentValue'
                 error must be returned.

                 If a set operation tries to set the value to the
                 usmNoAuthProtocol while the usmUserPrivProtocol value
                 in the same row is not equal to usmNoPrivProtocol,
                 then an 'inconsistentValue' error must be returned.
                 That means that an SNMP command generator application
                 must first ensure that the usmUserPrivProtocol is set
                 to the usmNoPrivProtocol value before it can set
                 the usmUserAuthProtocol value to usmNoAuthProtocol.
                "
    DEFVAL      { usmNoAuthProtocol }
    ::= { usmUserEntry 5 }

usmUserAuthKeyChange OBJECT-TYPE
    SYNTAX       KeyChange   -- typically (SIZE (0 | 32)) for HMACMD5
                             -- typically (SIZE (0 | 40)) for HMACSHA
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "An object, which when modified, causes the secret
                 authentication key used for messages sent on behalf
                 of this user to/from the SNMP engine identified by
                 usmUserEngineID, to be modified via a one-way
                 function.

                 The associated protocol is the usmUserAuthProtocol.
                 The associated secret key is the user's secret
                 authentication key (authKey). The associated hash
                 algorithm is the algorithm used by the user's
                 usmUserAuthProtocol.

                 When creating a new user, it is an 'inconsistentName'
                 error for a set operation to refer to this object
                 unless it is previously or concurrently initialized
                 through a set operation on the corresponding instance
                 of usmUserCloneFrom.

                 When the value of the corresponding usmUserAuthProtocol
                 is usmNoAuthProtocol, then a set is successful, but
                 effectively is a no-op.

                 When this object is read, the zero-length (empty)
                 string is returned.

                 The recommended way to do a key change is as follows:




Blumenthal & Wijnen         Standards Track                    [Page 44]


RFC 3414                     USM for SNMPv3                December 2002


                   1) GET(usmUserSpinLock.0) and save in sValue.
                   2) generate the keyChange value based on the old
                      (existing) secret key and the new secret key,
                      let us call this kcValue.

                 If you do the key change on behalf of another user:

                   3) SET(usmUserSpinLock.0=sValue,
                          usmUserAuthKeyChange=kcValue
                          usmUserPublic=randomValue)

                 If you do the key change for yourself:

                   4) SET(usmUserSpinLock.0=sValue,
                          usmUserOwnAuthKeyChange=kcValue
                          usmUserPublic=randomValue)

                 If you get a response with error-status of noError,
                 then the SET succeeded and the new key is active.
                 If you do not get a response, then you can issue a
                 GET(usmUserPublic) and check if the value is equal
                 to the randomValue you did send in the SET. If so, then
                 the key change succeeded and the new key is active
                 (probably the response got lost). If not, then the SET
                 request probably never reached the target and so you
                 can start over with the procedure above.
                "
    DEFVAL      { ''H }    -- the empty string
    ::= { usmUserEntry 6 }

usmUserOwnAuthKeyChange OBJECT-TYPE
    SYNTAX       KeyChange   -- typically (SIZE (0 | 32)) for HMACMD5
                             -- typically (SIZE (0 | 40)) for HMACSHA
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "Behaves exactly as usmUserAuthKeyChange, with one
                 notable difference: in order for the set operation
                 to succeed, the usmUserName of the operation
                 requester must match the usmUserName that
                 indexes the row which is targeted by this
                 operation.
                 In addition, the USM security model must be
                 used for this operation.

                 The idea here is that access to this column can be
                 public, since it will only allow a user to change
                 his own secret authentication key (authKey).
                 Note that this can only be done once the row is active.



Blumenthal & Wijnen         Standards Track                    [Page 45]


RFC 3414                     USM for SNMPv3                December 2002


                 When a set is received and the usmUserName of the
                 requester is not the same as the umsUserName that
                 indexes the row which is targeted by this operation,
                 then a 'noAccess' error must be returned.

                 When a set is received and the security model in use
                 is not USM, then a 'noAccess' error must be returned.
                "
    DEFVAL      { ''H }    -- the empty string
    ::= { usmUserEntry 7 }

usmUserPrivProtocol OBJECT-TYPE
    SYNTAX       AutonomousType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "An indication of whether messages sent on behalf of
                 this user to/from the SNMP engine identified by
                 usmUserEngineID, can be protected from disclosure,
                 and if so, the type of privacy protocol which is used.

                 An instance of this object is created concurrently
                 with the creation of any other object instance for
                 the same user (i.e., as part of the processing of
                 the set operation which creates the first object
                 instance in the same conceptual row).

                 If an initial set operation (i.e. at row creation time)
                 tries to set a value for an unknown or unsupported
                 protocol, then a 'wrongValue' error must be returned.

                 The value will be overwritten/set when a set operation
                 is performed on the corresponding instance of
                 usmUserCloneFrom.

                 Once instantiated, the value of such an instance of
                 this object can only be changed via a set operation to
                 the value of the usmNoPrivProtocol.

                 If a set operation tries to change the value of an
                 existing instance of this object to any value other
                 than usmNoPrivProtocol, then an 'inconsistentValue'
                 error must be returned.

                 Note that if any privacy protocol is used, then you
                 must also use an authentication protocol. In other
                 words, if usmUserPrivProtocol is set to anything else
                 than usmNoPrivProtocol, then the corresponding instance
                 of usmUserAuthProtocol cannot have a value of



Blumenthal & Wijnen         Standards Track                    [Page 46]


RFC 3414                     USM for SNMPv3                December 2002


                 usmNoAuthProtocol. If it does, then an
                 'inconsistentValue' error must be returned.
                "
    DEFVAL      { usmNoPrivProtocol }
    ::= { usmUserEntry 8 }

usmUserPrivKeyChange OBJECT-TYPE
    SYNTAX       KeyChange  -- typically (SIZE (0 | 32)) for DES
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "An object, which when modified, causes the secret
                 encryption key used for messages sent on behalf
                 of this user to/from the SNMP engine identified by
                 usmUserEngineID, to be modified via a one-way
                 function.

                 The associated protocol is the usmUserPrivProtocol.
                 The associated secret key is the user's secret
                 privacy key (privKey). The associated hash
                 algorithm is the algorithm used by the user's
                 usmUserAuthProtocol.

                 When creating a new user, it is an 'inconsistentName'
                 error for a set operation to refer to this object
                 unless it is previously or concurrently initialized
                 through a set operation on the corresponding instance
                 of usmUserCloneFrom.

                 When the value of the corresponding usmUserPrivProtocol
                 is usmNoPrivProtocol, then a set is successful, but
                 effectively is a no-op.

                 When this object is read, the zero-length (empty)
                 string is returned.
                 See the description clause of usmUserAuthKeyChange for
                 a recommended procedure to do a key change.
                "
    DEFVAL      { ''H }    -- the empty string
    ::= { usmUserEntry 9 }

usmUserOwnPrivKeyChange OBJECT-TYPE
    SYNTAX       KeyChange  -- typically (SIZE (0 | 32)) for DES
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "Behaves exactly as usmUserPrivKeyChange, with one
                 notable difference: in order for the Set operation
                 to succeed, the usmUserName of the operation
                 requester must match the usmUserName that indexes



Blumenthal & Wijnen         Standards Track                    [Page 47]


RFC 3414                     USM for SNMPv3                December 2002


                 the row which is targeted by this operation.
                 In addition, the USM security model must be
                 used for this operation.

                 The idea here is that access to this column can be
                 public, since it will only allow a user to change
                 his own secret privacy key (privKey).
                 Note that this can only be done once the row is active.

                 When a set is received and the usmUserName of the
                 requester is not the same as the umsUserName that
                 indexes the row which is targeted by this operation,
                 then a 'noAccess' error must be returned.

                 When a set is received and the security model in use
                 is not USM, then a 'noAccess' error must be returned.
                "
    DEFVAL      { ''H }    -- the empty string
    ::= { usmUserEntry 10 }

usmUserPublic    OBJECT-TYPE
    SYNTAX       OCTET STRING (SIZE(0..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "A publicly-readable value which can be written as part
                 of the procedure for changing a user's secret
                 authentication and/or privacy key, and later read to
                 determine whether the change of the secret was
                 effected.
                "
    DEFVAL      { ''H }  -- the empty string
    ::= { usmUserEntry 11 }

usmUserStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The storage type for this conceptual row.

                 Conceptual rows having the value 'permanent' must
                 allow write-access at a minimum to:

                 - usmUserAuthKeyChange, usmUserOwnAuthKeyChange
                   and usmUserPublic for a user who employs
                   authentication, and
                 - usmUserPrivKeyChange, usmUserOwnPrivKeyChange
                   and usmUserPublic for a user who employs
                   privacy.



Blumenthal & Wijnen         Standards Track                    [Page 48]


RFC 3414                     USM for SNMPv3                December 2002


                 Note that any user who employs authentication or
                 privacy must allow its secret(s) to be updated and
                 thus cannot be 'readOnly'.

                 If an initial set operation tries to set the value to
                 'readOnly' for a user who employs authentication or
                 privacy, then an 'inconsistentValue' error must be
                 returned.  Note that if the value has been previously
                 set (implicit or explicit) to any value, then the rules
                 as defined in the StorageType Textual Convention apply.

                 It is an implementation issue to decide if a SET for
                 a readOnly or permanent row is accepted at all. In some
                 contexts this may make sense, in others it may not. If
                 a SET for a readOnly or permanent row is not accepted
                 at all, then a 'wrongValue' error must be returned.
                "
    DEFVAL      { nonVolatile }
    ::= { usmUserEntry 12 }

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

                 Until instances of all corresponding columns are
                 appropriately configured, the value of the
                 corresponding instance of the usmUserStatus column
                 is 'notReady'.

                 In particular, a newly created row for a user who
                 employs authentication, cannot be made active until the
                 corresponding usmUserCloneFrom and usmUserAuthKeyChange
                 have been set.

                 Further, a newly created row for a user who also
                 employs privacy, cannot be made active until the
                 usmUserPrivKeyChange has been set.

                 The RowStatus TC [RFC2579] requires that this
                 DESCRIPTION clause states under which circumstances
                 other objects in this row can be modified:

                 The value of this object has no effect on whether
                 other objects in this conceptual row can be modified,
                 except for usmUserOwnAuthKeyChange and
                 usmUserOwnPrivKeyChange. For these 2 objects, the



Blumenthal & Wijnen         Standards Track                    [Page 49]


RFC 3414                     USM for SNMPv3                December 2002


                 value of usmUserStatus MUST be active.
                "
    ::= { usmUserEntry 13 }

-- Conformance Information *******************************************

usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 }
usmMIBGroups      OBJECT IDENTIFIER ::= { usmMIBConformance 2 }

-- Compliance statements

usmMIBCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION "The compliance statement for SNMP engines which
                 implement the SNMP-USER-BASED-SM-MIB.
                "

    MODULE       -- this module
        MANDATORY-GROUPS { usmMIBBasicGroup }

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

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

    ::= { usmMIBCompliances 1 }

-- Units of compliance
usmMIBBasicGroup OBJECT-GROUP
    OBJECTS     {
                  usmStatsUnsupportedSecLevels,
                  usmStatsNotInTimeWindows,
                  usmStatsUnknownUserNames,
                  usmStatsUnknownEngineIDs,
                  usmStatsWrongDigests,
                  usmStatsDecryptionErrors,
                  usmUserSpinLock,
                  usmUserSecurityName,
                  usmUserCloneFrom,
                  usmUserAuthProtocol,
                  usmUserAuthKeyChange,
                  usmUserOwnAuthKeyChange,
                  usmUserPrivProtocol,
                  usmUserPrivKeyChange,
                  usmUserOwnPrivKeyChange,



Blumenthal & Wijnen         Standards Track                    [Page 50]


RFC 3414                     USM for SNMPv3                December 2002


                  usmUserPublic,
                  usmUserStorageType,
                  usmUserStatus
                }
    STATUS       current
    DESCRIPTION "A collection of objects providing for configuration
                 of an SNMP engine which implements the SNMP
                 User-based Security Model.
                "
    ::= { usmMIBGroups 1 }

END

6. HMAC-MD5-96 Authentication Protocol

   This section describes the HMAC-MD5-96 authentication protocol.  This
   authentication protocol is the first defined for the User-based
   Security Model.  It uses MD5 hash-function which is described in
   [RFC1321], in HMAC mode described in [RFC2104], truncating the output
   to 96 bits.

   This protocol is identified by usmHMACMD5AuthProtocol.

   Over time, other authentication protocols may be defined either as a
   replacement of this protocol or in addition to this protocol.

6.1. Mechanisms

   - In support of data integrity, a message digest algorithm is
     required.  A digest is calculated over an appropriate portion of an
     SNMP message and included as part of the message sent to the
     recipient.

   - In support of data origin authentication and data integrity, a
     secret value is prepended to SNMP message prior to computing the
     digest; the calculated digest is partially inserted into the SNMP
     message prior to transmission, and the prepended value is not
     transmitted.  The secret value is shared by all SNMP engines
     authorized to originate messages on behalf of the appropriate user.

6.1.1. Digest Authentication Mechanism

   The Digest Authentication Mechanism defined in this memo provides
   for:

   - verification of the integrity of a received message, i.e., the
     message received is the message sent.




Blumenthal & Wijnen         Standards Track                    [Page 51]


RFC 3414                     USM for SNMPv3                December 2002


     The integrity of the message is protected by computing a digest
     over an appropriate portion of the message.  The digest is computed
     by the originator of the message, transmitted with the message, and
     verified by the recipient of the message.

   - verification of the user on whose behalf the message was generated.

     A secret value known only to SNMP engines authorized to generate
     messages on behalf of a user is used in HMAC mode (see [RFC2104]).
     It also recommends the hash-function output used as Message
     Authentication Code, to be truncated.

   This protocol uses the MD5 [RFC1321] message digest algorithm.  A
   128-bit MD5 digest is calculated in a special (HMAC) way over the
   designated portion of an SNMP message and the first 96 bits of this
   digest is included as part of the message sent to the recipient.  The
   size of the digest carried in a message is 12 octets.  The size of
   the private authentication key (the secret) is 16 octets.  For the
   details see section 6.3.

6.2. Elements of the Digest Authentication Protocol

   This section contains definitions required to realize the
   authentication module defined in this section of this memo.

6.2.1. Users

   Authentication using this authentication protocol makes use of a
   defined set of userNames.  For any user on whose behalf a message
   must be authenticated at a particular SNMP engine, that SNMP engine
   must have knowledge of that user.  An SNMP engine that wishes to
   communicate with another SNMP engine must also have knowledge of a
   user known to that engine, including knowledge of the applicable
   attributes of that user.

   A user and its attributes are defined as follows:

   <userName>
     A string representing the name of the user.
   <authKey>
     A user's secret key to be used when calculating a digest.
     It MUST be 16 octets long for MD5.









Blumenthal & Wijnen         Standards Track                    [Page 52]


RFC 3414                     USM for SNMPv3                December 2002


6.2.2. msgAuthoritativeEngineID

   The msgAuthoritativeEngineID value contained in an authenticated
   message specifies the authoritative SNMP engine for that particular
   message (see the definition of SnmpEngineID in the SNMP Architecture
   document [RFC3411]).

   The user's (private) authentication key is normally different at each
   authoritative SNMP engine and so the snmpEngineID is used to select
   the proper key for the authentication process.

6.2.3. SNMP Messages Using this Authentication Protocol

   Messages using this authentication protocol carry a
   msgAuthenticationParameters field as part of the
   msgSecurityParameters.  For this protocol, the
   msgAuthenticationParameters field is the serialized OCTET STRING
   representing the first 12 octets of the HMAC-MD5-96 output done over
   the wholeMsg.

   The digest is calculated over the wholeMsg so if a message is
   authenticated, that also means that all the fields in the message are
   intact and have not been tampered with.

6.2.4. Services provided by the HMAC-MD5-96 Authentication Module

   This section describes the inputs and outputs that the HMAC-MD5-96
   Authentication module expects and produces when the User-based
   Security module calls the HMAC-MD5-96 Authentication module for
   services.

6.2.4.1. Services for Generating an Outgoing SNMP Message

   The HMAC-MD5-96 authentication protocol assumes that the selection of
   the authKey is done by the caller and that the caller passes the
   secret key to be used.

   Upon completion the authentication module returns statusInformation
   and, if the message digest was correctly calculated, the wholeMsg
   with the digest inserted at the proper place.  The abstract service
   primitive is:

   statusInformation =              -- success or failure
     authenticateOutgoingMsg(
     IN   authKey                   -- secret key for authentication
     IN   wholeMsg                  -- unauthenticated complete message
     OUT  authenticatedWholeMsg     -- complete authenticated message
          )



Blumenthal & Wijnen         Standards Track                    [Page 53]


RFC 3414                     USM for SNMPv3                December 2002


   The abstract data elements are:

   statusInformation
     An indication of whether the authentication process was successful.
     If not it is an indication of the problem.

   authKey
     The secret key to be used by the authentication algorithm.  The
     length of this key MUST be 16 octets.

   wholeMsg
     The message to be authenticated.

   authenticatedWholeMsg
     The authenticated message (including inserted digest) on output.

   Note, that authParameters field is filled by the authentication
   module and this module and this field should be already present in
   the wholeMsg before the Message Authentication Code (MAC) is
   generated.

6.2.4.2. Services for Processing an Incoming SNMP Message

   The HMAC-MD5-96 authentication protocol assumes that the selection of
   the authKey is done by the caller and that the caller passes the
   secret key to be used.

   Upon completion the authentication module returns statusInformation
   and, if the message digest was correctly calculated, the wholeMsg as
   it was processed.  The abstract service primitive is:

   statusInformation =              -- success or failure
     authenticateIncomingMsg(
     IN   authKey                   -- secret key for authentication
     IN   authParameters            -- as received on the wire
     IN   wholeMsg                  -- as received on the wire
     OUT  authenticatedWholeMsg     -- complete authenticated message
          )

   The abstract data elements are:

   statusInformation
     An indication of whether the authentication process was successful.
     If not it is an indication of the problem.

   authKey
     The secret key to be used by the authentication algorithm.  The
     length of this key MUST be 16 octets.



Blumenthal & Wijnen         Standards Track                    [Page 54]


RFC 3414                     USM for SNMPv3                December 2002


   authParameters
     The authParameters from the incoming message.

   wholeMsg
     The message to be authenticated on input and the authenticated
     message on output.

   authenticatedWholeMsg
     The whole message after the authentication check is complete.

6.3. Elements of Procedure

   This section describes the procedures for the HMAC-MD5-96
   authentication protocol.

6.3.1. Processing an Outgoing Message

   This section describes the procedure followed by an SNMP engine
   whenever it must authenticate an outgoing message using the
   usmHMACMD5AuthProtocol.

   1) The msgAuthenticationParameters field is set to the serialization,
      according to the rules in [RFC3417], of an OCTET STRING containing
      12 zero octets.

   2) From the secret authKey, two keys K1 and K2 are derived:

      a) extend the authKey to 64 octets by appending 48 zero octets;
         save it as extendedAuthKey

      b) obtain IPAD by replicating the octet 0x36 64 times;

      c) obtain K1 by XORing extendedAuthKey with IPAD;

      d) obtain OPAD by replicating the octet 0x5C 64 times;

      e) obtain K2 by XORing extendedAuthKey with OPAD.

   3) Prepend K1 to the wholeMsg and calculate MD5 digest over it
      according to [RFC1321].

   4) Prepend K2 to the result of the step 4 and calculate MD5 digest
      over it according to [RFC1321].  Take the first 12 octets of the
      final digest - this is Message Authentication Code (MAC).

   5) Replace the msgAuthenticationParameters field with MAC obtained in
      the step 4.




Blumenthal & Wijnen         Standards Track                    [Page 55]


RFC 3414                     USM for SNMPv3                December 2002


   6) The authenticatedWholeMsg is then returned to the caller together
      with statusInformation indicating success.

6.3.2. Processing an Incoming Message

   This section describes the procedure followed by an SNMP engine
   whenever it must authenticate an incoming message using the
   usmHMACMD5AuthProtocol.

   1) If the digest received in the msgAuthenticationParameters field is
      not 12 octets long, then an failure and an errorIndication
      (authenticationError) is returned to the calling module.

   2) The MAC received in the msgAuthenticationParameters field is
      saved.

   3) The digest in the msgAuthenticationParameters field is replaced by
      the 12 zero octets.

   4) From the secret authKey, two keys K1 and K2 are derived:

      a) extend the authKey to 64 octets by appending 48 zero octets;
         save it as extendedAuthKey

      b) obtain IPAD by replicating the octet 0x36 64 times;

      c) obtain K1 by XORing extendedAuthKey with IPAD;

      d) obtain OPAD by replicating the octet 0x5C 64 times;

      e) obtain K2 by XORing extendedAuthKey with OPAD.

   5) The MAC is calculated over the wholeMsg:

      a) prepend K1 to the wholeMsg and calculate the MD5 digest over
      it;

      b) prepend K2 to the result of step 5.a and calculate the MD5
      digest over it;

      c) first 12 octets of the result of step 5.b is the MAC.

      The msgAuthenticationParameters field is replaced with the MAC
      value that was saved in step 2.







Blumenthal & Wijnen         Standards Track                    [Page 56]


RFC 3414                     USM for SNMPv3                December 2002


   6) Then the newly calculated MAC is compared with the MAC saved in
      step 2.  If they do not match, then an failure and an
      errorIndication (authenticationFailure) is returned to the calling
      module.

   7) The authenticatedWholeMsg and statusInformation indicating success
      are then returned to the caller.

7. HMAC-SHA-96 Authentication Protocol

   This section describes the HMAC-SHA-96 authentication protocol.  This
   protocol uses the SHA hash-function which is described in [SHA-NIST],
   in HMAC mode described in [RFC2104], truncating the output to 96
   bits.

   This protocol is identified by usmHMACSHAAuthProtocol.

   Over time, other authentication protocols may be defined either as a
   replacement of this protocol or in addition to this protocol.

7.1. Mechanisms

   - In support of data integrity, a message digest algorithm is
     required.  A digest is calculated over an appropriate portion of an
     SNMP message and included as part of the message sent to the
     recipient.

   - In support of data origin authentication and data integrity, a
     secret value is prepended to the SNMP message prior to computing
     the digest; the calculated digest is then partially inserted into
     the message prior to transmission.  The prepended secret is not
     transmitted.  The secret value is shared by all SNMP engines
     authorized to originate messages on behalf of the appropriate user.

7.1.1. Digest Authentication Mechanism

   The Digest Authentication Mechanism defined in this memo provides
   for:

   - verification of the integrity of a received message, i.e., the
     message received is the message sent.

     The integrity of the message is protected by computing a digest
     over an appropriate portion of the message.  The digest is computed
     by the originator of the message, transmitted with the message, and
     verified by the recipient of the message.





Blumenthal & Wijnen         Standards Track                    [Page 57]


RFC 3414                     USM for SNMPv3                December 2002


   - verification of the user on whose behalf the message was generated.

     A secret value known only to SNMP engines authorized to generate
     messages on behalf of a user is used in HMAC mode (see [RFC2104]).
     It also recommends the hash-function output used as Message
     Authentication Code, to be truncated.

   This mechanism uses the SHA [SHA-NIST] message digest algorithm.  A
   160-bit SHA digest is calculated in a special (HMAC) way over the
   designated portion of an SNMP message and the first 96 bits of this
   digest is included as part of the message sent to the recipient.  The
   size of the digest carried in a message is 12 octets.  The size of
   the private authentication key (the secret) is 20 octets.  For the
   details see section 7.3.

7.2. Elements of the HMAC-SHA-96 Authentication Protocol

   This section contains definitions required to realize the
   authentication module defined in this section of this memo.

7.2.1. Users

   Authentication using this authentication protocol makes use of a
   defined set of userNames.  For any user on whose behalf a message
   must be authenticated at a particular SNMP engine, that SNMP engine
   must have knowledge of that user.  An SNMP engine that wishes to
   communicate with another SNMP engine must also have knowledge of a
   user known to that engine, including knowledge of the applicable
   attributes of that user.

   A user and its attributes are defined as follows:

   <userName>
     A string representing the name of the user.
   <authKey>
     A user's secret key to be used when calculating a digest.
     It MUST be 20 octets long for SHA.

7.2.2. msgAuthoritativeEngineID

   The msgAuthoritativeEngineID value contained in an authenticated
   message specifies the authoritative SNMP engine for that particular
   message (see the definition of SnmpEngineID in the SNMP Architecture
   document [RFC3411]).

   The user's (private) authentication key is normally different at each
   authoritative SNMP engine and so the snmpEngineID is used to select
   the proper key for the authentication process.



Blumenthal & Wijnen         Standards Track                    [Page 58]


RFC 3414                     USM for SNMPv3                December 2002


7.2.3. SNMP Messages Using this Authentication Protocol

   Messages using this authentication protocol carry a
   msgAuthenticationParameters field as part of the
   msgSecurityParameters.  For this protocol, the
   msgAuthenticationParameters field is the serialized OCTET STRING
   representing the first 12 octets of HMAC-SHA-96 output done over the
   wholeMsg.

   The digest is calculated over the wholeMsg so if a message is
   authenticated, that also means that all the fields in the message are
   intact and have not been tampered with.

7.2.4. Services Provided by the HMAC-SHA-96 Authentication Module

   This section describes the inputs and outputs that the HMAC-SHA-96
   Authentication module expects and produces when the User-based
   Security module calls the HMAC-SHA-96 Authentication module for
   services.

7.2.4.1. Services for Generating an Outgoing SNMP Message

   HMAC-SHA-96 authentication protocol assumes that the selection of the
   authKey is done by the caller and that the caller passes the secret
   key to be used.

   Upon completion the authentication module returns statusInformation
   and, if the message digest was correctly calculated, the wholeMsg
   with the digest inserted at the proper place.  The abstract service
   primitive is:

   statusInformation =              -- success or failure
     authenticateOutgoingMsg(
     IN   authKey                   -- secret key for authentication
     IN   wholeMsg                  -- unauthenticated complete message
     OUT  authenticatedWholeMsg     -- complete authenticated message
          )

   The abstract data elements are:

   statusInformation
     An indication of whether the authentication process was successful.
     If not it is an indication of the problem.

   authKey
     The secret key to be used by the authentication algorithm.  The
     length of this key MUST be 20 octets.




Blumenthal & Wijnen         Standards Track                    [Page 59]


RFC 3414                     USM for SNMPv3                December 2002


   wholeMsg
     The message to be authenticated.

   authenticatedWholeMsg
     The authenticated message (including inserted digest) on output.

   Note, that authParameters field is filled by the authentication
   module and this field should be already present in the wholeMsg
   before the Message Authentication Code (MAC) is generated.

7.2.4.2. Services for Processing an Incoming SNMP Message

   HMAC-SHA-96 authentication protocol assumes that the selection of the
   authKey is done by the caller and that the caller passes the secret
   key to be used.

   Upon completion the authentication module returns statusInformation
   and, if the message digest was correctly calculated, the wholeMsg as
   it was processed.  The abstract service primitive is:

   statusInformation =              -- success or failure
     authenticateIncomingMsg(
     IN   authKey                   -- secret key for authentication
     IN   authParameters            -- as received on the wire
     IN   wholeMsg                  -- as received on the wire
     OUT  authenticatedWholeMsg     -- complete authenticated message
          )

   The abstract data elements are:

   statusInformation
     An indication of whether the authentication process was successful.
     If not it is an indication of the problem.

   authKey
     The secret key to be used by the authentication algorithm.  The
     length of this key MUST be 20 octets.

   authParameters
     The authParameters from the incoming message.

   wholeMsg
     The message to be authenticated on input and the authenticated
     message on output.

   authenticatedWholeMsg
     The whole message after the authentication check is complete.




Blumenthal & Wijnen         Standards Track                    [Page 60]


RFC 3414                     USM for SNMPv3                December 2002


7.3. Elements of Procedure

   This section describes the procedures for the HMAC-SHA-96
   authentication protocol.

7.3.1. Processing an Outgoing Message

   This section describes the procedure followed by an SNMP engine
   whenever it must authenticate an outgoing message using the
   usmHMACSHAAuthProtocol.

   1) The msgAuthenticationParameters field is set to the serialization,
      according to the rules in [RFC3417], of an OCTET STRING containing
      12 zero octets.

   2) From the secret authKey, two keys K1 and K2 are derived:

      a) extend the authKey to 64 octets by appending 44 zero octets;
         save it as extendedAuthKey

      b) obtain IPAD by replicating the octet 0x36 64 times;

      c) obtain K1 by XORing extendedAuthKey with IPAD;

      d) obtain OPAD by replicating the octet 0x5C 64 times;

      e) obtain K2 by XORing extendedAuthKey with OPAD.

   3) Prepend K1 to the wholeMsg and calculate the SHA digest over it
      according to [SHA-NIST].

   4) Prepend K2 to the result of the step 4 and calculate SHA digest
      over it according to [SHA-NIST].  Take the first 12 octets of the
      final digest - this is Message Authentication Code (MAC).

   5) Replace the msgAuthenticationParameters field with MAC obtained in
      the step 5.

   6) The authenticatedWholeMsg is then returned to the caller together
      with statusInformation indicating success.

7.3.2. Processing an Incoming Message

   This section describes the procedure followed by an SNMP engine
   whenever it must authenticate an incoming message using the
   usmHMACSHAAuthProtocol.





Blumenthal & Wijnen         Standards Track                    [Page 61]


RFC 3414                     USM for SNMPv3                December 2002


   1) If the digest received in the msgAuthenticationParameters field is
      not 12 octets long, then an failure and an errorIndication
      (authenticationError) is returned to the calling module.

   2) The MAC received in the msgAuthenticationParameters field is
      saved.

   3) The digest in the msgAuthenticationParameters field is replaced by
      the 12 zero octets.

   4) From the secret authKey, two keys K1 and K2 are derived:

      a) extend the authKey to 64 octets by appending 44 zero octets;
         save it as extendedAuthKey

      b) obtain IPAD by replicating the octet 0x36 64 times;

      c) obtain K1 by XORing extendedAuthKey with IPAD;

      d) obtain OPAD by replicating the octet 0x5C 64 times;

      e) obtain K2 by XORing extendedAuthKey with OPAD.

   5)  The MAC is calculated over the wholeMsg:

      a) prepend K1 to the wholeMsg and calculate the SHA digest over
         it;

      b) prepend K2 to the result of step 5.a and calculate the SHA
         digest over it;

      c) first 12 octets of the result of step 5.b is the MAC.

      The msgAuthenticationParameters field is replaced with the MAC
      value that was saved in step 2.

   6) The the newly calculated MAC is compared with the MAC saved in
      step 2.  If they do not match, then a failure and an
      errorIndication (authenticationFailure) are returned to the
      calling module.

   7) The authenticatedWholeMsg and statusInformation indicating success
      are then returned to the caller.








Blumenthal & Wijnen         Standards Track                    [Page 62]


RFC 3414                     USM for SNMPv3                December 2002


8. CBC-DES Symmetric Encryption Protocol

   This section describes the CBC-DES Symmetric Encryption Protocol.
   This protocol is the first privacy protocol defined for the
   User-based Security Model.

   This protocol is identified by usmDESPrivProtocol.

   Over time, other privacy protocols may be defined either as a
   replacement of this protocol or in addition to this protocol.

8.1. Mechanisms

   - In support of data confidentiality, an encryption algorithm is
     required.  An appropriate portion of the message is encrypted prior
     to being transmitted.  The User-based Security Model specifies that
     the scopedPDU is the portion of the message that needs to be
     encrypted.

   - A secret value in combination with a timeliness value is used to
     create the en/decryption key and the initialization vector.  The
     secret value is shared by all SNMP engines authorized to originate
     messages on behalf of the appropriate user.

8.1.1. Symmetric Encryption Protocol

   The Symmetric Encryption Protocol defined in this memo provides
   support for data confidentiality.  The designated portion of an SNMP
   message is encrypted and included as part of the message sent to the
   recipient.

   Two organizations have published specifications defining the DES:
   the National Institute of Standards and Technology (NIST) [DES-NIST]
   and the American National Standards Institute [DES-ANSI].  There is a
   companion Modes of Operation specification for each definition
   ([DESO-NIST] and [DESO-ANSI], respectively).

   The NIST has published three additional documents that implementors
   may find useful.

   - There is a document with guidelines for implementing and using the
     DES, including functional specifications for the DES and its modes
     of operation [DESG-NIST].

   - There is a specification of a validation test suite for the DES
     [DEST-NIST].  The suite is designed to test all aspects of the DES
     and is useful for pinpointing specific problems.




Blumenthal & Wijnen         Standards Track                    [Page 63]


RFC 3414                     USM for SNMPv3                December 2002


   - There is a specification of a maintenance test for the DES [DESM-
     NIST].  The test utilizes a minimal amount of data and processing
     to test all components of the DES.  It provides a simple yes-or-no
     indication of correct operation and is useful to run as part of an
     initialization step, e.g., when a computer re-boots.

8.1.1.1. DES key and Initialization Vector

   The first 8 octets of the 16-octet secret (private privacy key) are
   used as a DES key.  Since DES uses only 56 bits, the Least
   Significant Bit in each octet is disregarded.

   The Initialization Vector for encryption is obtained using the
   following procedure.

   The last 8 octets of the 16-octet secret (private privacy key) are
   used as pre-IV.

   In order to ensure that the IV for two different packets encrypted by
   the same key, are not the same (i.e., the IV does not repeat) we need
   to "salt" the pre-IV with something unique per packet.  An 8-octet
   string is used as the "salt".  The concatenation of the generating
   SNMP engine's 32-bit snmpEngineBoots and a local 32-bit integer, that
   the encryption engine maintains, is input to the "salt".  The 32-bit
   integer is initialized to an arbitrary value at boot time.

   The 32-bit snmpEngineBoots is converted to the first 4 octets (Most
   Significant Byte first) of our "salt".  The 32-bit integer is then
   converted to the last 4 octet (Most Significant Byte first) of our
   "salt".  The resulting "salt" is then XOR-ed with the pre-IV to
   obtain the IV.  The 8-octet "salt" is then put into the
   privParameters field encoded as an OCTET STRING.  The "salt" integer
   is then modified.  We recommend that it be incremented by one and
   wrap when it reaches the maximum value.

   How exactly the value of the "salt" (and thus of the IV) varies, is
   an implementation issue, as long as the measures are taken to avoid
   producing a duplicate IV.

   The "salt" must be placed in the privParameters field to enable the
   receiving entity to compute the correct IV and to decrypt the
   message.









Blumenthal & Wijnen         Standards Track                    [Page 64]


RFC 3414                     USM for SNMPv3                December 2002


8.1.1.2. Data Encryption

   The data to be encrypted is treated as sequence of octets.  Its
   length should be an integral multiple of 8 - and if it is not, the
   data is padded at the end as necessary.  The actual pad value is
   irrelevant.

   The data is encrypted in Cipher Block Chaining mode.

   The plaintext is divided into 64-bit blocks.

   The plaintext for each block is XOR-ed with the ciphertext of the
   previous block, the result is encrypted and the output of the
   encryption is the ciphertext for the block.  This procedure is
   repeated until there are no more plaintext blocks.

   For the very first block, the Initialization Vector is used instead
   of the ciphertext of the previous block.

8.1.1.3. Data Decryption

   Before decryption, the encrypted data length is verified.  If the
   length of the OCTET STRING to be decrypted is not an integral
   multiple of 8 octets, the decryption process is halted and an
   appropriate exception noted.  When decrypting, the padding is
   ignored.

   The first ciphertext block is decrypted, the decryption output is
   XOR-ed with the Initialization Vector, and the result is the first
   plaintext block.

   For each subsequent block, the ciphertext block is decrypted, the
   decryption output is XOR-ed with the previous ciphertext block and
   the result is the plaintext block.

8.2. Elements of the DES Privacy Protocol

   This section contains definitions required to realize the privacy
   module defined by this memo.

8.2.1. Users

   Data en/decryption using this Symmetric Encryption Protocol makes use
   of a defined set of userNames.  For any user on whose behalf a
   message must be en/decrypted at a particular SNMP engine, that SNMP
   engine must have knowledge of that user.  An SNMP engine that wishes





Blumenthal & Wijnen         Standards Track                    [Page 65]


RFC 3414                     USM for SNMPv3                December 2002


   to communicate with another SNMP engine must also have knowledge of a
   user known to that SNMP engine, including knowledge of the applicable
   attributes of that user.

   A user and its attributes are defined as follows:

   <userName>
     An octet string representing the name of the user.

   <privKey>
     A user's secret key to be used as input for the DES key and IV.
     The length of this key MUST be 16 octets.

8.2.2. msgAuthoritativeEngineID

   The msgAuthoritativeEngineID value contained in an authenticated
   message specifies the authoritative SNMP engine for that particular
   message (see the definition of SnmpEngineID in the SNMP Architecture
   document [RFC3411]).

   The user's (private) privacy key is normally different at each
   authoritative SNMP engine and so the snmpEngineID is used to select
   the proper key for the en/decryption process.

8.2.3. SNMP Messages Using this Privacy Protocol

   Messages using this privacy protocol carry a msgPrivacyParameters
   field as part of the msgSecurityParameters.  For this protocol, the
   msgPrivacyParameters field is the serialized OCTET STRING
   representing the "salt" that was used to create the IV.

8.2.4. Services Provided by the DES Privacy Module

   This section describes the inputs and outputs that the DES Privacy
   module expects and produces when the User-based Security module
   invokes the DES Privacy module for services.

8.2.4.1. Services for Encrypting Outgoing Data

   This DES privacy protocol assumes that the selection of the privKey
   is done by the caller and that the caller passes the secret key to be
   used.

   Upon completion the privacy module returns statusInformation and, if
   the encryption process was successful, the encryptedPDU and the
   msgPrivacyParameters encoded as an OCTET STRING.  The abstract
   service primitive is:




Blumenthal & Wijnen         Standards Track                    [Page 66]


RFC 3414                     USM for SNMPv3                December 2002


   statusInformation =              -- success of failure
     encryptData(
     IN    encryptKey               -- secret key for encryption
     IN    dataToEncrypt            -- data to encrypt (scopedPDU)
     OUT   encryptedData            -- encrypted data (encryptedPDU)
     OUT   privParameters           -- filled in by service provider
           )

   The abstract data elements are:

   statusInformation
     An indication of the success or failure of the encryption process.
     In case of failure, it is an indication of the error.

   encryptKey
     The secret key to be used by the encryption algorithm.  The length
     of this key MUST be 16 octets.

   dataToEncrypt
     The data that must be encrypted.

   encryptedData
     The encrypted data upon successful completion.

   privParameters
     The privParameters encoded as an OCTET STRING.

8.2.4.2. Services for Decrypting Incoming Data

   This DES privacy protocol assumes that the selection of the privKey
   is done by the caller and that the caller passes the secret key to be
   used.

   Upon completion the privacy module returns statusInformation and, if
   the decryption process was successful, the scopedPDU in plain text.
   The abstract service primitive is:

   statusInformation =
     decryptData(
     IN    decryptKey               -- secret key for decryption
     IN    privParameters           -- as received on the wire
     IN    encryptedData            -- encrypted data (encryptedPDU)
     OUT   decryptedData            -- decrypted data (scopedPDU)
           )







Blumenthal & Wijnen         Standards Track                    [Page 67]


RFC 3414                     USM for SNMPv3                December 2002


   The abstract data elements are:

   statusInformation
     An indication whether the data was successfully decrypted and if
     not an indication of the error.

   decryptKey
     The secret key to be used by the decryption algorithm.  The length
     of this key MUST be 16 octets.

   privParameters
     The "salt" to be used to calculate the IV.

   encryptedData
     The data to be decrypted.

   decryptedData
     The decrypted data.

8.3. Elements of Procedure.

   This section describes the procedures for the DES privacy protocol.

8.3.1. Processing an Outgoing Message

   This section describes the procedure followed by an SNMP engine
   whenever it must encrypt part of an outgoing message using the
   usmDESPrivProtocol.

   1) The secret cryptKey is used to construct the DES encryption key,
      the "salt" and the DES pre-IV (from which the IV is computed as
      described in section 8.1.1.1).

   2) The privParameters field is set to the serialization according to
      the rules in [RFC3417] of an OCTET STRING representing the "salt"
      string.

   3) The scopedPDU is encrypted (as described in section 8.1.1.2)
      and the encrypted data is serialized according to the rules in
      [RFC3417] as an OCTET STRING.

   4) The serialized OCTET STRING representing the encrypted scopedPDU
      together with the privParameters and statusInformation indicating
      success is returned to the calling module.







Blumenthal & Wijnen         Standards Track                    [Page 68]


RFC 3414                     USM for SNMPv3                December 2002


8.3.2. Processing an Incoming Message

   This section describes the procedure followed by an SNMP engine
   whenever it must decrypt part of an incoming message using the
   usmDESPrivProtocol.

   1) If the privParameters field is not an 8-octet OCTET STRING, then
      an error indication (decryptionError) is returned to the calling
      module.

   2) The "salt" is extracted from the privParameters field.

   3) The secret cryptKey and the "salt" are then used to construct the
      DES decryption key and pre-IV (from which the IV is computed as
      described in section 8.1.1.1).

   4) The encryptedPDU is then decrypted (as described in section
      8.1.1.3).

   5) If the encryptedPDU cannot be decrypted, then an error indication
      (decryptionError) is returned to the calling module.

   6) The decrypted scopedPDU and statusInformation indicating success
      are returned to the calling module.

9. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.





Blumenthal & Wijnen         Standards Track                    [Page 69]


RFC 3414                     USM for SNMPv3                December 2002


10. Acknowledgements

   This document is the result of the efforts of the SNMPv3 Working
   Group.  Some special thanks are in order to the following SNMPv3 WG
   members:

      Harald Tveit Alvestrand (Maxware)
      Dave Battle (SNMP Research, Inc.)
      Alan Beard (Disney Worldwide Services)
      Paul Berrevoets (SWI Systemware/Halcyon Inc.)
      Martin Bjorklund (Ericsson)
      Uri Blumenthal (IBM T.J. Watson Research Center)
      Jeff Case (SNMP Research, Inc.)
      John Curran (BBN)
      Mike Daniele (Compaq Computer Corporation))
      T. Max Devlin (Eltrax Systems)
      John Flick (Hewlett Packard)
      Rob Frye (MCI)
      Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.)
      David Harrington (Cabletron Systems Inc.)
      Lauren Heintz (BMC Software, Inc.)
      N.C. Hien (IBM T.J. Watson Research Center)
      Michael Kirkham (InterWorking Labs, Inc.)
      Dave Levi (SNMP Research, Inc.)
      Louis A Mamakos (UUNET Technologies Inc.)
      Joe Marzot (Nortel Networks)
      Paul Meyer (Secure Computing Corporation)
      Keith McCloghrie (Cisco Systems)
      Bob Moore (IBM)
      Russ Mundy (TIS Labs at Network Associates)
      Bob Natale (ACE*COMM Corporation)
      Mike O'Dell (UUNET Technologies Inc.)
      Dave Perkins (DeskTalk)
      Peter Polkinghorne (Brunel University)
      Randy Presuhn (BMC Software, Inc.)
      David Reeder (TIS Labs at Network Associates)
      David Reid (SNMP Research, Inc.)
      Aleksey Romanov (Quality Quorum)
      Shawn Routhier (Epilogue)
      Juergen Schoenwaelder (TU Braunschweig)
      Bob Stewart (Cisco Systems)
      Mike Thatcher (Independent Consultant)
      Bert Wijnen (IBM T.J. Watson Research Center)








Blumenthal & Wijnen         Standards Track                    [Page 70]


RFC 3414                     USM for SNMPv3                December 2002


   The document is based on recommendations of the IETF Security and
   Administrative Framework Evolution for SNMP Advisory Team.  Members
   of that Advisory Team were:

      David Harrington (Cabletron Systems Inc.)
      Jeff Johnson (Cisco Systems)
      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 Center)

   As recommended by the Advisory Team and the SNMPv3 Working Group
   Charter, the design incorporates as much as practical from previous
   RFCs and drafts.  As a result, special thanks are due to the authors
   of previous designs known as SNMPv2u and SNMPv2*:

      Jeff Case (SNMP Research, Inc.)
      David Harrington (Cabletron Systems Inc.)
      David Levi (SNMP Research, Inc.)
      Keith McCloghrie (Cisco Systems)
      Brian O'Keefe (Hewlett Packard)
      Marshall T. Rose (Dover Beach Consulting)
      Jon Saperia (BGS Systems Inc.)
      Steve Waldbusser (International Network Services)
      Glenn W. Waters (Bell-Northern Research Ltd.)

11. Security Considerations

11.1. Recommended Practices

   This section describes practices that contribute to the secure,
   effective operation of the mechanisms defined in this memo.

   - An SNMP engine must discard SNMP Response messages that do not
     correspond to any currently outstanding Request message.  It is the
     responsibility of the Message Processing module to take care of
     this.  For example it can use a msgID for that.

     An SNMP Command Generator Application must discard any Response
     Class PDU for which there is no currently outstanding Confirmed
     Class PDU; for example for SNMPv2 [RFC3416] PDUs, the request-id
     component in the PDU can be used to correlate Responses to
     outstanding Requests.






Blumenthal & Wijnen         Standards Track                    [Page 71]


RFC 3414                     USM for SNMPv3                December 2002


     Although it would be typical for an SNMP engine and an SNMP Command
     Generator Application to do this as a matter of course, when using
     these security protocols it is significant due to the possibility
     of message duplication (malicious or otherwise).

   - If an SNMP engine uses a msgID for correlating Response messages to
     outstanding Request messages, then it MUST use different msgIDs in
     all such Request messages that it sends out during a Time Window
     (150 seconds) period.

     A Command Generator or Notification Originator Application MUST use
     different request-ids in all Request PDUs that it sends out during
     a TimeWindow (150 seconds) period.

     This must be done to protect against the possibility of message
     duplication (malicious or otherwise).

     For example, starting operations with a msgID and/or request-id
     value of zero is not a good idea.  Initializing them with an
     unpredictable number (so they do not start out the same after each
     reboot) and then incrementing by one would be acceptable.

   - An SNMP engine should perform time synchronization using
     authenticated messages in order to protect against the possibility
     of message duplication (malicious or otherwise).

   - When sending state altering messages to a managed authoritative
     SNMP engine, a Command Generator Application should delay sending
     successive messages to that managed SNMP engine until a positive
     acknowledgement is received for the previous message or until the
     previous message expires.

     No message ordering is imposed by the SNMP.  Messages may be
     received in any order relative to their time of generation and each
     will be processed in the ordered received.  Note that when an
     authenticated message is sent to a managed SNMP engine, it will be
     valid for a period of time of approximately 150 seconds under
     normal circumstances, and is subject to replay during this period.
     Indeed, an SNMP engine and SNMP Command Generator Applications must
     cope with the loss and re-ordering of messages resulting from
     anomalies in the network as a matter of course.

     However, a managed object, snmpSetSerialNo [RFC3418], is
     specifically defined for use with SNMP Set operations in order to
     provide a mechanism to ensure that the processing of SNMP messages
     occurs in a specific order.





Blumenthal & Wijnen         Standards Track                    [Page 72]


RFC 3414                     USM for SNMPv3                December 2002


   - The frequency with which the secrets of a User-based Security Model
     user should be changed is indirectly related to the frequency of
     their use.

     Protecting the secrets from disclosure is critical to the overall
     security of the protocols.  Frequent use of a secret provides a
     continued source of data that may be useful to a cryptanalyst in
     exploiting known or perceived weaknesses in an algorithm.  Frequent
     changes to the secret avoid this vulnerability.

     Changing a secret after each use is generally regarded as the most
     secure practice, but a significant amount of overhead may be
     associated with that approach.

     Note, too, in a local environment the threat of disclosure may be
     less significant, and as such the changing of secrets may be less
     frequent.  However, when public data networks are used as the
     communication paths, more caution is prudent.

11.2  Defining Users

   The mechanisms defined in this document employ the notion of users on
   whose behalf messages are sent.  How "users" are defined is subject
   to the security policy of the network administration.  For example,
   users could be individuals (e.g., "joe" or "jane"), or a particular
   role (e.g., "operator" or "administrator"), or a combination (e.g.,
   "joe-operator", "jane-operator" or "joe-admin").  Furthermore, a user
   may be a logical entity, such as an SNMP Application or a set of SNMP
   Applications, acting on behalf of an individual or role, or set of
   individuals, or set of roles, including combinations.

   Appendix A describes an algorithm for mapping a user "password" to a
   16/20 octet value for use as either a user's authentication key or
   privacy key (or both).  Note however, that using the same password
   (and therefore the same key) for both authentication and privacy is
   very poor security practice and should be strongly discouraged.
   Passwords are often generated, remembered, and input by a human.
   Human-generated passwords may be less than the 16/20 octets required
   by the authentication and privacy protocols, and brute force attacks
   can be quite easy on a relatively short ASCII character set.
   Therefore, the algorithm is Appendix A performs a transformation on
   the password.  If the Appendix A algorithm is used, SNMP
   implementations (and SNMP configuration applications) must ensure
   that passwords are at least 8 characters in length.  Please note that
   longer passwords with repetitive strings may result in exactly the
   same key.  For example, a password 'bertbert' will result in exactly
   the same key as password 'bertbertbert'.




Blumenthal & Wijnen         Standards Track                    [Page 73]


RFC 3414                     USM for SNMPv3                December 2002


   Because the Appendix A algorithm uses such passwords (nearly)
   directly, it is very important that they not be easily guessed.  It
   is suggested that they be composed of mixed-case alphanumeric and
   punctuation characters that don't form words or phrases that might be
   found in a dictionary.   Longer passwords improve the security of the
   system.  Users may wish to input multiword phrases to make their
   password string longer while ensuring that it is memorable.

   Since it is infeasible for human users to maintain different
   passwords for every SNMP engine, but security requirements strongly
   discourage having the same key for more than one SNMP engine, the
   User-based Security Model employs a compromise proposed in
   [Localized-key].  It derives the user keys for the SNMP engines from
   user's password in such a way that it is practically impossible to
   either determine the user's password, or user's key for another SNMP
   engine from any combination of user's keys on SNMP engines.

   Note however, that if user's password is disclosed, then key
   localization will not help and network security may be compromised in
   this case.  Therefore a user's password or non-localized key MUST NOT
   be stored on a managed device/node.  Instead the localized key SHALL
   be stored (if at all), so that, in case a device does get
   compromised, no other managed or managing devices get compromised.

11.3. Conformance

   To be termed a "Secure SNMP implementation" based on the User-based
   Security Model, an SNMP implementation MUST:

   - implement one or more Authentication Protocol(s).  The HMAC-MD5-96
     and HMAC-SHA-96 Authentication Protocols defined in this memo are
     examples of such protocols.

   - to the maximum extent possible, prohibit access to the secret(s) of
     each user about which it maintains information in a Local
     Configuration Datastore (LCD) under all circumstances except as
     required to generate and/or validate SNMP messages with respect to
     that user.

   - implement the key-localization mechanism.

   - implement the SNMP-USER-BASED-SM-MIB.

   In addition, an authoritative SNMP engine SHOULD provide initial
   configuration in accordance with Appendix A.1.

   Implementation of a Privacy Protocol (the DES Symmetric Encryption
   Protocol defined in this memo is one such protocol) is optional.



Blumenthal & Wijnen         Standards Track                    [Page 74]


RFC 3414                     USM for SNMPv3                December 2002


11.4. Use of Reports

   The use of unsecure reports (i.e., sending them with a securityLevel
   of noAuthNoPriv) potentially exposes a non-authoritative SNMP engine
   to some form of attacks.  Some people consider these denial of
   service attacks, others don't.  An installation should evaluate the
   risk involved before deploying unsecure Report PDUs.

11.5  Access to the SNMP-USER-BASED-SM-MIB

   The objects in this MIB may be considered sensitive in many
   environments.  Specifically the objects in the usmUserTable contain
   information about users and their authentication and privacy
   protocols.  It is important to closely control (both read and write)
   access to these MIB objects by using appropriately configured Access
   Control models (for example the View-based Access Control Model as
   specified in [RFC3415]).

12. References

12.1 Normative References

   [RFC1321]       Rivest, R., "Message Digest Algorithm MD5", RFC 1321,
                   April 1992.

   [RFC2104]       Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
                   Keyed-Hashing  for Message Authentication", RFC 2104,
                   February 1997.

   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]       McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                   J., Rose, M. and S. Waldbusser, "Structure of
                   Management Information Version 2 (SMIv2)", STD 58,
                   RFC 2578, April 1999.

   [RFC2579]       McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                   J., Rose, M. and S. Waldbusser, "Textual Conventions
                   for SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]       McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                   J., Rose, M. and S. Waldbusser, "Conformance
                   Statements for SMIv2", STD 58, RFC 2580, April 1999.







Blumenthal & Wijnen         Standards Track                    [Page 75]


RFC 3414                     USM for SNMPv3                December 2002


   [RFC3411]       Harrington, D., Presuhn, R. and B. Wijnen, "An
                   Architecture for Describing Simple Network Management
                   Protocol (SNMP) Management Frameworks", STD 62, RFC
                   3411, December 2002.

   [RFC3412]       Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
                   "Message Processing and Dispatching for the Simple
                   Network Management Protocol (SNMP)", STD 62, RFC
                   3412, December 2002.

   [RFC3415]       Wijnen, B., Presuhn, R. and K. McCloghrie, "View-
                   based Access Control Model (VACM) for the Simple
                   Network Management Protocol (SNMP)", STD 62, RFC
                   3415, December 2002.

   [RFC3416]       Presuhn, R., Case, J., McCloghrie, K., Rose, M. and
                   S. Waldbusser, "Version 2 of the Protocol Operations
                   for the Simple Network Management Protocol (SNMP)",
                   STD 62, RFC 3416, December 2002.

   [RFC3417]       Presuhn, R., Case, J., McCloghrie, K., Rose, M. and
                   S.  Waldbusser, "Transport Mappings for the Simple
                   Network Management Protocol (SNMP)", STD 62, RFC
                   3417, December 2002.

   [RFC3418]       Presuhn, R., Case, J., McCloghrie, K., Rose, M. and
                   S. Waldbusser, "Management Information Base (MIB) for
                   the Simple Network Management Protocol (SNMP)", STD
                   62, RFC 3418, December 2002.

   [DES-NIST]      Data Encryption Standard, National Institute of
                   Standards and Technology.  Federal Information
                   Processing Standard (FIPS) Publication 46-1.
                   Supersedes FIPS Publication 46, (January, 1977;
                   reaffirmed January, 1988).

   [DESO-NIST]     DES Modes of Operation, National Institute of
                   Standards and Technology.  Federal Information
                   Processing Standard (FIPS) Publication 81, (December,
                   1980).

   [SHA-NIST]      Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995)
                   http://csrc.nist.gov/fips/fip180-1.txt (ASCII)
                   http://csrc.nist.gov/fips/fip180-1.ps  (Postscript)







Blumenthal & Wijnen         Standards Track                    [Page 76]


RFC 3414                     USM for SNMPv3                December 2002


12.1 Informative References

   [Localized-Key] U. Blumenthal, N. C. Hien, B. Wijnen "Key Derivation
                   for Network Management Applications" IEEE Network
                   Magazine, April/May issue, 1997.

   [DES-ANSI]      Data Encryption Algorithm, American National
                   Standards Institute.  ANSI X3.92-1981, (December,
                   1980).

   [DESO-ANSI]     Data Encryption Algorithm - Modes of Operation,
                   American National Standards Institute.  ANSI X3.106-
                   1983, (May 1983).

   [DESG-NIST]     Guidelines for Implementing and Using the NBS Data
                   Encryption Standard, National Institute of Standards
                   and Technology.  Federal Information Processing
                   Standard (FIPS) Publication 74, (April, 1981).

   [DEST-NIST]     Validating the Correctness of Hardware
                   Implementations of the NBS Data Encryption Standard,
                   National Institute of Standards and Technology.
                   Special Publication 500-20.

   [DESM-NIST]     Maintenance Testing for the Data Encryption Standard,
                   National Institute of Standards and Technology.
                   Special Publication 500-61, (August, 1980).

   [RFC3174]       Eastlake, D. 3rd and P. Jones, "US Secure Hash
                   Algorithm 1 (SHA1)", RFC 3174, September 2001.





















Blumenthal & Wijnen         Standards Track                    [Page 77]


RFC 3414                     USM for SNMPv3                December 2002


APPENDIX A - Installation

A.1. SNMP engine Installation Parameters

   During installation, an authoritative SNMP engine SHOULD (in the
   meaning as defined in [RFC2119]) be configured with several initial
   parameters.  These include:

   1) A Security Posture

      The choice of security posture determines if initial configuration
      is implemented and if so how.  One of three possible choices is
      selected:

         minimum-secure,
         semi-secure,
         very-secure (i.e., no-initial-configuration)

      In the case of a very-secure posture, there is no initial
      configuration, and so the following steps are irrelevant.

   2) One or More Secrets

      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 [RFC1321].  The resulting digest, termed
        "digest1", is used in the next step.

      - a second string is formed by concatenating digest1, the SNMP
        engine's snmpEngineID value, and digest1.  This string is used
        as input to the MD5 algorithm [RFC1321].

        The resulting digest is the required secret (see Appendix A.2).










Blumenthal & Wijnen         Standards Track                    [Page 78]


RFC 3414                     USM for SNMPv3                December 2002


      With these configured parameters, the SNMP engine instantiates the
      following usmUserEntry in the usmUserTable:

                           no privacy support     privacy support
                           ------------------     ---------------
   usmUserEngineID         localEngineID          localEngineID
   usmUserName             "initial"              "initial"
   usmUserSecurityName     "initial"              "initial"
   usmUserCloneFrom        ZeroDotZero            ZeroDotZero
   usmUserAuthProtocol     usmHMACMD5AuthProtocol usmHMACMD5AuthProtocol
   usmUserAuthKeyChange    ""                     ""
   usmUserOwnAuthKeyChange ""                     ""
   usmUserPrivProtocol     none                   usmDESPrivProtocol
   usmUserPrivKeyChange    ""                     ""
   usmUserOwnPrivKeyChange ""                     ""
   usmUserPublic           ""                     ""
   usmUserStorageType      anyValidStorageType    anyValidStorageType
   usmUserStatus           active                 active

      It is recommended to also instantiate a set of template
      usmUserEntries which can be used as clone-from users for newly
      created usmUserEntries.  These are the two suggested entries:

                           no privacy support     privacy support
                           ------------------     ---------------
   usmUserEngineID         localEngineID          localEngineID
   usmUserName             "templateMD5"          "templateMD5"
   usmUserSecurityName     "templateMD5"          "templateMD5"
   usmUserCloneFrom        ZeroDotZero            ZeroDotZero
   usmUserAuthProtocol     usmHMACMD5AuthProtocol usmHMACMD5AuthProtocol
   usmUserAuthKeyChange    ""                     ""
   usmUserOwnAuthKeyChange ""                     ""
   usmUserPrivProtocol     none                   usmDESPrivProtocol
   usmUserPrivKeyChange    ""                     ""
   usmUserOwnPrivKeyChange ""                     ""
   usmUserPublic           ""                     ""
   usmUserStorageType      permanent              permanent
   usmUserStatus           active                 active













Blumenthal & Wijnen         Standards Track                    [Page 79]


RFC 3414                     USM for SNMPv3                December 2002


                           no privacy support     privacy support
                           ------------------     ---------------
   usmUserEngineID         localEngineID          localEngineID
   usmUserName             "templateSHA"          "templateSHA"
   usmUserSecurityName     "templateSHA"          "templateSHA"
   usmUserCloneFrom        ZeroDotZero            ZeroDotZero
   usmUserAuthProtocol     usmHMACSHAAuthProtocol usmHMACSHAAuthProtocol
   usmUserAuthKeyChange    ""                     ""
   usmUserOwnAuthKeyChange ""                     ""
   usmUserPrivProtocol     none                   usmDESPrivProtocol
   usmUserPrivKeyChange    ""                     ""
   usmUserOwnPrivKeyChange ""                     ""
   usmUserPublic           ""                     ""
   usmUserStorageType      permanent              permanent
   usmUserStatus           active                 active

A.2. Password to Key Algorithm

   A sample code fragment (section A.2.1) demonstrates the password to
   key algorithm which can be used when mapping a password to an
   authentication or privacy key using MD5.  The reference source code
   of MD5 is available in [RFC1321].

   Another sample code fragment (section A.2.2) demonstrates the
   password to key algorithm which can be used when mapping a password
   to an authentication or privacy key using SHA (documented in SHA-
   NIST).

   An example of the results of a correct implementation is provided
   (section A.3) which an implementor can use to check if his
   implementation produces the same result.




















Blumenthal & Wijnen         Standards Track                    [Page 80]


RFC 3414                     USM for SNMPv3                December 2002


A.2.1. Password to Key Sample Code for MD5

   void password_to_key_md5(
      u_char *password,    /* IN */
      u_int   passwordlen, /* IN */
      u_char *engineID,    /* IN  - pointer to snmpEngineID  */
      u_int   engineLength,/* IN  - length of snmpEngineID */
      u_char *key)         /* OUT - pointer to caller 16-octet 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 octet of the password, wrapping */
             /* to the beginning of the password as necessary.*/
             /*************************************************/
             *cp++ = password[password_index++ % passwordlen];
         }
         MD5Update (&MD, password_buf, 64);
         count += 64;
      }
      MD5Final (key, &MD);          /* tell MD5 we're done */

      /*****************************************************/
      /* Now localize the key with the engineID and pass   */
      /* through MD5 to produce final key                  */
      /* May want to ensure that engineLength <= 32,       */
      /* otherwise need to use a buffer larger than 64     */
      /*****************************************************/
      memcpy(password_buf, key, 16);
      memcpy(password_buf+16, engineID, engineLength);
      memcpy(password_buf+16+engineLength, key, 16);

      MD5Init(&MD);
      MD5Update(&MD, password_buf, 32+engineLength);
      MD5Final(key, &MD);
      return;
   }



Blumenthal & Wijnen         Standards Track                    [Page 81]


RFC 3414                     USM for SNMPv3                December 2002


A.2.2. Password to Key Sample Code for SHA

   void password_to_key_sha(
      u_char *password,    /* IN */
      u_int   passwordlen, /* IN */
      u_char *engineID,    /* IN  - pointer to snmpEngineID  */
      u_int   engineLength,/* IN  - length of snmpEngineID */
      u_char *key)         /* OUT - pointer to caller 20-octet buffer */
   {
      SHA_CTX     SH;
      u_char     *cp, password_buf[72];
      u_long      password_index = 0;
      u_long      count = 0, i;

      SHAInit (&SH);   /* initialize SHA */

      /**********************************************/
      /* Use while loop until we've done 1 Megabyte */
      /**********************************************/
      while (count < 1048576) {
         cp = password_buf;
         for (i = 0; i < 64; i++) {
             /*************************************************/
             /* Take the next octet of the password, wrapping */
             /* to the beginning of the password as necessary.*/
             /*************************************************/
             *cp++ = password[password_index++ % passwordlen];
         }
         SHAUpdate (&SH, password_buf, 64);
         count += 64;
      }
      SHAFinal (key, &SH);          /* tell SHA we're done */

      /*****************************************************/
      /* Now localize the key with the engineID and pass   */
      /* through SHA to produce final key                  */
      /* May want to ensure that engineLength <= 32,       */
      /* otherwise need to use a buffer larger than 72     */
      /*****************************************************/
      memcpy(password_buf, key, 20);
      memcpy(password_buf+20, engineID, engineLength);
      memcpy(password_buf+20+engineLength, key, 20);

      SHAInit(&SH);
      SHAUpdate(&SH, password_buf, 40+engineLength);
      SHAFinal(key, &SH);
      return;
   }



Blumenthal & Wijnen         Standards Track                    [Page 82]


RFC 3414                     USM for SNMPv3                December 2002


A.3. Password to Key Sample Results

A.3.1. Password to Key Sample Results using MD5

   The following shows a sample output of the password to key algorithm
   for a 16-octet key using MD5.

   With a password of "maplesyrup" the output of the password to key
   algorithm before the key is localized with the SNMP engine's
   snmpEngineID is:

      '9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H

   After the intermediate key (shown above) is localized with the
   snmpEngineID value of:

      '00 00 00 00 00 00 00 00 00 00 00 02'H

   the final output of the password to key algorithm is:

      '52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'H

A.3.2. Password to Key Sample Results using SHA

   The following shows a sample output of the password to key algorithm
   for a 20-octet key using SHA.

   With a password of "maplesyrup" the output of the password to key
   algorithm before the key is localized with the SNMP engine's
   snmpEngineID is:

      '9f b5 cc 03 81 49 7b 37 93 52 89 39 ff 78 8d 5d 79 14 52 11'H

   After the intermediate key (shown above) is localized with the
   snmpEngineID value of:

      '00 00 00 00 00 00 00 00 00 00 00 02'H

   the final output of the password to key algorithm is:

      '66 95 fe bc 92 88 e3 62 82 23 5f c7 15 1f 12 84 97 b3 8f 3f'H

A.4. Sample Encoding of msgSecurityParameters

   The msgSecurityParameters in an SNMP message are represented as an
   OCTET STRING.  This OCTET STRING should be considered opaque outside
   a specific Security Model.




Blumenthal & Wijnen         Standards Track                    [Page 83]


RFC 3414                     USM for SNMPv3                December 2002


   The User-based Security Model defines the contents of the OCTET
   STRING as a SEQUENCE (see section 2.4).

   Given these two properties, the following is an example of they
   msgSecurityParameters for the User-based Security Model, encoded as
   an OCTET STRING:

      04 <length>
      30 <length>
      04 <length> <msgAuthoritativeEngineID>
      02 <length> <msgAuthoritativeEngineBoots>
      02 <length> <msgAuthoritativeEngineTime>
      04 <length> <msgUserName>
      04 0c       <HMAC-MD5-96-digest>
      04 08       <salt>

   Here is the example once more, but now with real values (except for
   the digest in msgAuthenticationParameters and the salt in
   msgPrivacyParameters, which depend on variable data that we have not
   defined here):

      Hex Data                         Description
      --------------  -----------------------------------------------
      04 39           OCTET STRING,                  length 57
      30 37           SEQUENCE,                      length 55
      04 0c 80000002  msgAuthoritativeEngineID:      IBM
            01                                       IPv4 address
            09840301                                 9.132.3.1
      02 01 01        msgAuthoritativeEngineBoots:   1
      02 02 0101      msgAuthoritativeEngineTime:    257
      04 04 62657274  msgUserName:                   bert
      04 0c 01234567  msgAuthenticationParameters:   sample value
            89abcdef
            fedcba98
      04 08 01234567  msgPrivacyParameters:          sample value
            89abcdef

A.5. Sample keyChange Results

A.5.1. Sample keyChange Results using MD5

   Let us assume that a user has a current password of "maplesyrup" as
   in section A.3.1. and let us also assume the snmpEngineID of 12
   octets:

      '00 00 00 00 00 00 00 00 00 00 00 02'H





Blumenthal & Wijnen         Standards Track                    [Page 84]


RFC 3414                     USM for SNMPv3                December 2002


   If we now want to change the password to "newsyrup", then we first
   calculate the key for the new password.  It is as follows:

      '01 ad d2 73 10 7c 4e 59 6b 4b 00 f8 2b 1d 42 a7'H

   If we localize it for the above snmpEngineID, then the localized new
   key becomes:

      '87 02 1d 7b d9 d1 01 ba 05 ea 6e 3b f9 d9 bd 4a'H

   If we then use a (not so good, but easy to test) random value of:

      '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H

   Then the value we must send for keyChange is:

      '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       88 05 61 51 41 67 6c c9 19 61 74 e7 42 a3 25 51'H

   If this were for the privacy key, then it would be exactly the same.

A.5.2. Sample keyChange Results using SHA

   Let us assume that a user has a current password of "maplesyrup" as
   in section A.3.2. and let us also assume the snmpEngineID of 12
   octets:

      '00 00 00 00 00 00 00 00 00 00 00 02'H

   If we now want to change the password to "newsyrup", then we first
   calculate the key for the new password.  It is as follows:

      '3a 51 a6 d7 36 aa 34 7b 83 dc 4a 87 e3 e5 5e e4 d6 98 ac 71'H

   If we localize it for the above snmpEngineID, then the localized new
   key becomes:

      '78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63 91 f1 cd 25'H

   If we then use a (not so good, but easy to test) random value of:

      '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H

   Then the value we must send for keyChange is:

      '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       9c 10 17 f4 fd 48 3d 2d e8 d5 fa db f8 43 92 cb 06 45 70 51'




Blumenthal & Wijnen         Standards Track                    [Page 85]


RFC 3414                     USM for SNMPv3                December 2002


   For the key used for privacy, the new nonlocalized key would be:

      '3a 51 a6 d7 36 aa 34 7b 83 dc 4a 87 e3 e5 5e e4 d6 98 ac 71'H

   For the key used for privacy, the new localized key would be (note
   that they localized key gets truncated to 16 octets for DES):

      '78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63'H

   If we then use a (not so good, but easy to test) random value of:

      '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H

   Then the value we must send for keyChange for the privacy key is:

      '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      '7e f8 d8 a4 c9 cd b2 6b 47 59 1c d8 52 ff 88 b5'H

B. Change Log

   Changes made since RFC2574:

   - Updated references
   - Updated contact info
   - Clarifications
     - to first constraint item 1) on page 6.
     - to usmUserCloneFrom DESCRIPTION clause
     - to securityName in section 2.1
   - Fixed "command responder" into "command generator" in last para of
     DESCRIPTION clause of usmUserTable.

   Changes made since RFC2274:

   - Fixed msgUserName to allow size of zero and explain that this can
     be used for snmpEngineID discovery.
   - Clarified section 3.1 steps 4.b, 5, 6 and 8.b.
   - Clarified section 3.2 paragraph 2.
   - Clarified section 3.2 step 7.a last paragraph, step 7.b.1 second
     bullet and step 7.b.2 third bullet.
   - Clarified section 4 to indicate that discovery can use a userName
     of zero length in unAuthenticated messages, whereas a valid
     userName must be used in authenticated messages.
   - Added REVISION clauses to MODULE-IDENTITY
   - Clarified KeyChange TC by adding a note that localized keys must be
     used when calculating a KeyChange value.
   - Added clarifying text to the DESCRIPTION clause of usmUserTable.
     Added text describes a recommended procedure for adding a new user.
   - Clarified the use of usmUserCloneFrom object.



Blumenthal & Wijnen         Standards Track                    [Page 86]


RFC 3414                     USM for SNMPv3                December 2002


   - Clarified how and under which conditions the usmUserAuthProtocol
     and usmUserPrivProtocol can be initialized and/or changed.
   - Added comment on typical sizes for usmUserAuthKeyChange and
     usmUserPrivKeyChange.  Also for usmUserOwnAuthKeyChange and
     usmUserOwnPrivKeyChange.
   - Added clarifications to the DESCRIPTION clauses of
     usmUserAuthKeyChange, usmUserOwnAuthKeychange, usmUserPrivKeyChange
     and usmUserOwnPrivKeychange.
   - Added clarification to DESCRIPTION clause of usmUserStorageType.
   - Added clarification to DESCRIPTION clause of usmUserStatus.
   - Clarified IV generation procedure in section 8.1.1.1 and in
     addition clarified section 8.3.1 step 1 and section 8.3.2. step 3.
   - Clarified section 11.2 and added a warning that different size
     passwords with repetitive strings may result in same key.
   - Added template users to appendix A for cloning process.
   - Fixed C-code examples in Appendix A.
   - Fixed examples of generated keys in Appendix A.
   - Added examples of KeyChange values to Appendix A.
   - Used PDU Classes instead of RFC1905 PDU types.
   - Added text in the security section about Reports and Access Control
     to the MIB.
   - Removed a incorrect note at the end of section 3.2 step 7.
   - Added a note in section 3.2 step 3.
   - Corrected various spelling errors and typos.
   - Corrected procedure for 3.2 step 2.a)
   - various clarifications.
   - Fixed references to new/revised documents
   - Change to no longer cache data that is not used

Editors' Addresses

   Uri Blumenthal
   Lucent Technologies
   67 Whippany Rd.
   Whippany, NJ 07981
   USA

   Phone: +1-973-386-2163
   EMail: uri@lucent.com

   Bert Wijnen
   Lucent Technologies
   Schagen 33
   3461 GL Linschoten
   Netherlands

   Phone: +31-348-480-685
   EMail: bwijnen@lucent.com



Blumenthal & Wijnen         Standards Track                    [Page 87]


RFC 3414                     USM for SNMPv3                December 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Blumenthal & Wijnen         Standards Track                    [Page 88]

========================================================================






Network Working Group                                          B. Wijnen
Request for Comments: 3415                           Lucent Technologies
STD: 62                                                       R. Presuhn
Obsoletes: 2575                                       BMC Software, Inc.
Category: Standards Track                                  K. McCloghrie
                                                     Cisco Systems, Inc.
                                                           December 2002


             View-based Access Control Model (VACM) for the
               Simple Network Management Protocol (SNMP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes the View-based Access Control Model (VACM)
   for use in the Simple Network Management Protocol (SNMP)
   architecture.  It defines the Elements of Procedure for controlling
   access to management information.  This document also includes a
   Management Information Base (MIB) for remotely managing the
   configuration parameters for the View-based Access Control Model.
   This document obsoletes RFC 2575.


















Wijnen, et al.              Standards Track                     [Page 1]


RFC 3415                   VACM for the SNMP               December 2002


Table of Contents

   1.  Introduction .................................................  2
   1.2.  Access Control .............................................  3
   1.3.  Local Configuration Datastore ..............................  3
   2.  Elements of the Model ........................................  4
   2.1.  Groups .....................................................  4
   2.2.  securityLevel ..............................................  4
   2.3.  Contexts ...................................................  4
   2.4.  MIB Views and View Families ................................  5
   2.4.1.  View Subtree .............................................  5
   2.4.2.  ViewTreeFamily ...........................................  6
   2.5.  Access Policy ..............................................  6
   3.  Elements of Procedure ........................................  7
   3.1.  Overview  of isAccessAllowed Process .......................  8
   3.2.  Processing the isAccessAllowed Service Request .............  9
   4.  Definitions .................................................. 11
   5.  Intellectual Property ........................................ 28
   6.  Acknowledgements ............................................. 28
   7.  Security Considerations ...................................... 30
   7.1.  Recommended Practices ...................................... 30
   7.2.  Defining Groups ............................................ 30
   7.3.  Conformance ................................................ 31
   7.4.  Access to the SNMP-VIEW-BASED-ACM-MIB ...................... 31
   8.  References ................................................... 31
   A.  Installation ................................................. 33
   B.  Change Log ................................................... 36
   Editors' Addresses ............................................... 38
   Full Copyright Statement ......................................... 39

1.  Introduction

   The Architecture for describing Internet Management Frameworks
   [RFC3411] describes that an SNMP engine is composed of:

      1) a Dispatcher
      2) a Message Processing Subsystem,
      3) a Security Subsystem, and
      4) an Access Control Subsystem.

   Applications make use of the services of these subsystems.

   It is important to understand the SNMP architecture and its
   terminology to understand where the View-based Access Control Model
   described in this document fits into the architecture and interacts
   with other subsystems within the architecture.  The reader is
   expected to have read and understood the description and terminology
   of the SNMP architecture, as defined in [RFC3411].



Wijnen, et al.              Standards Track                     [Page 2]


RFC 3415                   VACM for the SNMP               December 2002


   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 object (instance) is allowed.

   It is the purpose of this document to define a specific model of the
   Access Control Subsystem, designated the View-based Access Control
   Model.  Note that this is not necessarily the only Access Control
   Model.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119.

1.2.  Access Control

   Access Control occurs (either implicitly or explicitly) in an SNMP
   entity when processing SNMP retrieval or modification request
   messages from an SNMP entity.  For example a Command Responder
   application applies Access Control when processing requests that it
   received from a Command Generator application.  These requests
   contain Read Class and Write Class PDUs as defined in [RFC3411].

   Access Control also occurs in an SNMP entity when an SNMP
   notification message is generated (by a Notification Originator
   application).  These notification messages contain Notification Class
   PDUs as defined in [RFC3411].

   The View-based Access Control Model defines a set of services that an
   application (such as a Command Responder or a Notification Originator
   application) can use for checking access rights.  It is the
   responsibility of the application to make the proper service calls
   for access checking.

1.3.  Local Configuration Datastore

   To implement the model described in this document, an SNMP entity
   needs to retain information about access rights and policies.  This
   information is part of the SNMP engine's Local Configuration
   Datastore (LCD).  See [RFC3411] for the definition of LCD.

   In order to allow an SNMP entity's LCD to be remotely configured,
   portions of the LCD need to be accessible as managed objects.  A MIB
   module, the View-based Access Control Model Configuration MIB, which
   defines these managed object types is included in this document.







Wijnen, et al.              Standards Track                     [Page 3]


RFC 3415                   VACM for the SNMP               December 2002


2.  Elements of the Model

   This section contains definitions to realize the access control
   service provided by the View-based Access Control Model.

2.1.  Groups

   A group is a set of zero or more <securityModel, securityName> tuples
   on whose behalf SNMP management objects can be accessed.  A group
   defines the access rights afforded to all securityNames which 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.

   The Access Control module assumes that the securityName has already
   been authenticated as needed and provides no further authentication
   of its own.

   The View-based Access Control Model uses the securityModel and the
   securityName as inputs to the Access Control module when called to
   check for access rights.  It determines the groupName as a function
   of securityModel and securityName.

2.2.  securityLevel

   Different access rights for members of a group can be defined for
   different levels of security, i.e., noAuthNoPriv, authNoPriv, and
   authPriv.  The securityLevel identifies the level of security that
   will be assumed when checking for access rights.  See the SNMP
   Architecture document [RFC3411] for a definition of securityLevel.

   The View-based Access Control Model requires that the securityLevel
   is passed as input to the Access Control module when called to check
   for access rights.

2.3.  Contexts

   An SNMP context is a collection of management information accessible
   by an SNMP entity.  An item of management information may exist in
   more than one context.  An SNMP entity potentially has access to many
   contexts.  Details about the naming of management information can be
   found in the SNMP Architecture document [RFC3411].

   The View-based Access Control Model defines a vacmContextTable that
   lists the locally available contexts by contextName.







Wijnen, et al.              Standards Track                     [Page 4]


RFC 3415                   VACM for the SNMP               December 2002


2.4.  MIB Views and View Families

   For security reasons, it is often valuable to be able to restrict the
   access rights of some groups to only a subset of the management
   information in the management domain.  To provide this capability,
   access to a context is via a "MIB view" which details a specific set
   of managed object types (and optionally, the specific instances of
   object types) within that context.  For example, for a given context,
   there will typically always be one MIB view which provides access to
   all management information in that context, and often there will be
   other MIB views each of which contains some subset of the
   information.  So, the access allowed for a group can be restricted in
   the desired manner by specifying its rights in terms of the
   particular (subset) MIB view it can access within each appropriate
   context.

   Since managed object types (and their instances) are identified via
   the tree-like naming structure of ISO's OBJECT IDENTIFIERs [ISO-
   ASN.1, RFC2578],  it is convenient to define a MIB view as the
   combination of a set of "view subtrees", where each view subtree is a
   subtree within the managed object naming tree.  Thus, a simple MIB
   view (e.g., all managed objects within the Internet Network
   Management Framework) can be defined as a single view subtree, while
   more complicated MIB views (e.g., all information relevant to a
   particular network interface) can be represented by the union of
   multiple view subtrees.

   While any set of managed objects can be described by the union of
   some number of view subtrees, situations can arise that would require
   a very large number of view subtrees.  This could happen, for
   example, when specifying all columns in one conceptual row of a MIB
   table because they would appear in separate subtrees, one per column,
   each with a very similar format.  Because the formats are similar,
   the required set of subtrees can easily be aggregated into one
   structure.  This structure is named a family of view subtrees after
   the set of subtrees that it conceptually represents.  A family of
   view subtrees can either be included or excluded from a MIB view.

2.4.1.  View Subtree

   A view subtree is the set of all MIB object instances which have a
   common ASN.1 OBJECT IDENTIFIER prefix to their names.  A view subtree
   is identified by the OBJECT IDENTIFIER value which is the longest
   OBJECT IDENTIFIER prefix common to all (potential) MIB object
   instances in that subtree.






Wijnen, et al.              Standards Track                     [Page 5]


RFC 3415                   VACM for the SNMP               December 2002


2.4.2.  ViewTreeFamily

   A family of view subtrees is a pairing of an OBJECT IDENTIFIER value
   (called the family name) together with a bit string value (called the
   family mask).  The family mask indicates which sub-identifiers of the
   associated family name are significant to the family's definition.

   For each possible managed object instance, that instance belongs to a
   particular ViewTreeFamily if both of the following conditions are
   true:

   -  the OBJECT IDENTIFIER name of the managed object instance contains
      at least as many sub-identifiers as does the family name, and

   -  each sub-identifier in the OBJECT IDENTIFIER name of the managed
      object instance matches the corresponding sub-identifier of the
      family name whenever the corresponding bit of the associated
      family mask is non-zero.

   When the configured value of the family mask is all ones, the view
   subtree family is identical to the single view subtree identified by
   the family name.

   When the configured value of the family mask is shorter than required
   to perform the above test, its value is implicitly extended with
   ones.  Consequently, a view subtree family having a family mask of
   zero length always corresponds to a single view subtree.

2.5.  Access Policy

   The View-based Access Control Model determines the access rights of a
   group, representing zero or more securityNames which have the same
   access rights.  For a particular context, identified by contextName,
   to which a group, identified by groupName, has access using a
   particular securityModel and securityLevel, that group's access
   rights are given by a read-view, a write-view and a notify-view.

   The read-view represents the set of object instances authorized for
   the group when reading objects.  Reading objects occurs when
   processing a retrieval operation (when handling Read Class PDUs).

   The write-view represents the set of object instances authorized for
   the group when writing objects.  Writing objects occurs when
   processing a write operation (when handling Write Class PDUs).

   The notify-view represents the set of object instances authorized for
   the group when sending objects in a notification, such as when
   sending a notification (when sending Notification Class PDUs).



Wijnen, et al.              Standards Track                     [Page 6]


RFC 3415                   VACM for the SNMP               December 2002


3.  Elements of Procedure

   This section describes the procedures followed by an Access Control
   module that implements the View-based Access Control Model when
   checking access rights as requested by an application (for example a
   Command Responder or a Notification Originator application).  The
   abstract service primitive is:

      statusInformation =          -- success or errorIndication
          isAccessAllowed(
              securityModel        -- Security Model in use
              securityName         -- principal who wants access
              securityLevel        -- Level of Security
              viewType             -- read, write, or notify view
              contextName          -- context containing variableName
              variableName         -- OID for the managed object
              )

   The abstract data elements are:

      statusInformation - one of the following:
         accessAllowed  - a MIB view was found and access is granted.
         notInView      - a MIB view was found but access is denied.
                          The variableName is not in the configured
                          MIB view for the specified viewType (e.g., in
                          the relevant entry in the vacmAccessTable).
         noSuchView     - no MIB view found because no view has been
                          configured for specified viewType (e.g., in
                          the relevant entry in the vacmAccessTable).
         noSuchContext  - no MIB view found because of no entry in the
                          vacmContextTable for specified contextName.
         noGroupName    - no MIB view found because no entry has been
                          configured in the vacmSecurityToGroupTable
                          for the specified combination of
                          securityModel and securityName.
         noAccessEntry  - no MIB view found because no entry has been
                          configured in the vacmAccessTable for the
                          specified combination of contextName,
                          groupName (from vacmSecurityToGroupTable),
                          securityModel and securityLevel.
         otherError     - failure, an undefined error occurred.
      securityModel - Security Model under which access is requested.
      securityName  - the principal on whose behalf access is requested.
      securityLevel - Level of Security under which access is requested.
      viewType      - view to be checked (read, write or notify).
      contextName   - context in which access is requested.
      variableName  - object instance to which access is requested.




Wijnen, et al.              Standards Track                     [Page 7]


RFC 3415                   VACM for the SNMP               December 2002


3.1.  Overview  of isAccessAllowed Process

   The following picture shows how the decision for access control is
   made by the View-based Access Control Model.

  +--------------------------------------------------------------------+
  |                                                                    |
  |      +-> securityModel -+                                          |
  |      |   (a)            |                                          |
  | who -+                  +-> groupName ----+                        |
  | (1)  |                  |   (x)           |                        |
  |      +-> securityName --+                 |                        |
  |          (b)                              |                        |
  |                                           |                        |
  | where -> contextName ---------------------+                        |
  | (2)      (e)                              |                        |
  |                                           |                        |
  |                                           |                        |
  |      +-> securityModel -------------------+                        |
  |      |   (a)                              |                        |
  | how -+                                    +-> viewName -+          |
  | (3)  |                                    |   (y)       |          |
  |      +-> securityLevel -------------------+             |          |
  |          (c)                              |             +-> yes/no |
  |                                           |             | decision |
  | why ---> viewType (read/write/notify) ----+             | (z)      |
  | (4)      (d)                                            |          |
  |                                                         |          |
  | what --> object-type ------+                            |          |
  | (5)      (m)               |                            |          |
  |                            +-> variableName (OID) ------+          |
  |                            |   (f)                                 |
  | which -> object-instance --+                                       |
  | (6)      (n)                                                       |
  |                                                                    |
  +--------------------------------------------------------------------+















Wijnen, et al.              Standards Track                     [Page 8]


RFC 3415                   VACM for the SNMP               December 2002


   How the decision for isAccessAllowed is made.

   1) Inputs to the isAccessAllowed service are:

      (a)       securityModel    -- Security Model in use
      (b)       securityName     -- principal who wants to access
      (c)       securityLevel    -- Level of Security
      (d)       viewType         -- read, write, or notify view
      (e)       contextName      -- context containing variableName
      (f)       variableName     -- OID for the managed object
                                 -- this is made up of:
                                    - object-type (m)
                                    - object-instance (n)

   2) The partial "who" (1), represented by the securityModel (a) and
      the securityName (b), are used as the indices (a,b) into the
      vacmSecurityToGroupTable to find a single entry that produces a
      group, represented by groupName (x).

   3) The "where" (2), represented by the contextName (e), the "who",
      represented by the groupName (x) from the previous step, and the
      "how" (3), represented by securityModel (a) and securityLevel (c),
      are used as indices (e,x,a,c) into the vacmAccessTable to find a
      single entry that contains three MIB views.

   4) The "why" (4), represented by the viewType (d), is used to select
      the proper MIB view, represented by a viewName (y), from the
      vacmAccessEntry selected in the previous step.  This viewName (y)
      is an index into the vacmViewTreeFamilyTable and selects the set
      of entries that define the variableNames which are included in or
      excluded from the MIB view identified by the viewName (y).

   5) The "what" (5) type of management data and "which" (6) particular
      instance, represented by the variableName (f), is then checked to
      be in the MIB view or not, e.g., the yes/no decision (z).

3.2.  Processing the isAccessAllowed Service Request

   This section describes the procedure followed by an Access Control
   module that implements the View-based Access Control Model whenever
   it receives an isAccessAllowed request.

   1) The vacmContextTable is consulted for information about the SNMP
      context identified by the contextName.  If information about this
      SNMP context is absent from the table, then an errorIndication
      (noSuchContext) is returned to the calling module.





Wijnen, et al.              Standards Track                     [Page 9]


RFC 3415                   VACM for the SNMP               December 2002


   2) The vacmSecurityToGroupTable is consulted for mapping the
      securityModel and securityName to a groupName.  If the information
      about this combination is absent from the table, then an
      errorIndication (noGroupName) is returned to the calling module.

   3) The vacmAccessTable is consulted for information about the
      groupName, contextName, securityModel and securityLevel.  If
      information about this combination is absent from the table, then
      an errorIndication (noAccessEntry) is returned to the calling
      module.

   4) a) If the viewType is "read", then the read view is used for
         checking access rights.

      b) If the viewType is "write", then the write view is used for
         checking access rights.

      c) If the viewType is "notify", then the notify view is used for
         checking access rights.

      If the view to be used is the empty view (zero length viewName)
      then an errorIndication (noSuchView) is returned to the calling
      module.

   5) a) If there is no view configured for the specified viewType, then
         an errorIndication (noSuchView) is returned to the calling
         module.

      b) If the specified variableName (object instance) is not in the
         MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable in
         section 4), then an errorIndication (notInView) is returned to
         the calling module.

         Otherwise,

      c) The specified variableName is in the MIB view.  A
         statusInformation of success (accessAllowed) is returned to the
         calling module.













Wijnen, et al.              Standards Track                    [Page 10]


RFC 3415                   VACM for the SNMP               December 2002


4.  Definitions

SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF
    MODULE-IDENTITY, OBJECT-TYPE,
    snmpModules                           FROM SNMPv2-SMI
    TestAndIncr,
    RowStatus, StorageType                FROM SNMPv2-TC
    SnmpAdminString,
    SnmpSecurityLevel,
    SnmpSecurityModel                     FROM SNMP-FRAMEWORK-MIB;

snmpVacmMIB       MODULE-IDENTITY
    LAST-UPDATED "200210160000Z"          -- 16 Oct 2002, midnight
    ORGANIZATION "SNMPv3 Working Group"
    CONTACT-INFO "WG-email:   snmpv3@lists.tislabs.com
                  Subscribe:  majordomo@lists.tislabs.com
                              In message body:  subscribe snmpv3

                  Co-Chair:   Russ Mundy
                              Network Associates Laboratories
                  postal:     15204 Omega Drive, Suite 300
                              Rockville, MD 20850-4601
                              USA
                  email:      mundy@tislabs.com
                  phone:      +1 301-947-7107

                  Co-Chair:   David Harrington
                              Enterasys Networks
                  Postal:     35 Industrial Way
                              P. O. Box 5004
                              Rochester, New Hampshire 03866-5005
                              USA
                  EMail:      dbh@enterasys.com
                  Phone:      +1 603-337-2614

                  Co-editor:  Bert Wijnen
                              Lucent Technologies
                  postal:     Schagen 33
                              3461 GL Linschoten
                              Netherlands
                  email:      bwijnen@lucent.com
                  phone:      +31-348-480-685

                  Co-editor:  Randy Presuhn
                              BMC Software, Inc.



Wijnen, et al.              Standards Track                    [Page 11]


RFC 3415                   VACM for the SNMP               December 2002


                  postal:     2141 North First Street
                              San Jose, CA 95131
                              USA
                  email:      randy_presuhn@bmc.com
                  phone:      +1 408-546-1006

                  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
                 "
    DESCRIPTION  "The management information definitions for the
                  View-based Access Control Model for SNMP.

                  Copyright (C) The Internet Society (2002). This
                  version of this MIB module is part of RFC 3415;
                  see the RFC itself for full legal notices.
                 "
--  Revision history

    REVISION     "200210160000Z"          -- 16 Oct 2002, midnight
    DESCRIPTION  "Clarifications, published as RFC3415"

    REVISION     "199901200000Z"          -- 20 Jan 1999, midnight
    DESCRIPTION  "Clarifications, published as RFC2575"

    REVISION     "199711200000Z"          -- 20 Nov 1997, midnight
    DESCRIPTION  "Initial version, published as RFC2275"

    ::= { snmpModules 16 }

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

vacmMIBObjects      OBJECT IDENTIFIER ::= { snmpVacmMIB 1 }
vacmMIBConformance  OBJECT IDENTIFIER ::= { snmpVacmMIB 2 }

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

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

                 This table provides information to SNMP Command



Wijnen, et al.              Standards Track                    [Page 12]


RFC 3415                   VACM for the SNMP               December 2002


                 Generator applications so that they can properly
                 configure the vacmAccessTable to control access to
                 all contexts at the SNMP entity.

                 This table may change dynamically if the SNMP entity
                 allows that contexts are added/deleted dynamically
                 (for instance when its configuration changes).  Such
                 changes would happen only if the management
                 instrumentation at that SNMP entity recognizes more
                 (or fewer) contexts.

                 The presence of entries in this table and of entries
                 in the vacmAccessTable are independent.  That is, a
                 context identified by an entry in this table is not
                 necessarily referenced by any entries in the
                 vacmAccessTable; and the context(s) referenced by an
                 entry in the vacmAccessTable does not necessarily
                 currently exist and thus need not be identified by an
                 entry in this table.

                 This table must be made accessible via the default
                 context so that Command Responder applications have
                 a standard way of retrieving the information.

                 This table is read-only.  It cannot be configured via
                 SNMP.
                "
    ::= { vacmMIBObjects 1 }

vacmContextEntry OBJECT-TYPE
    SYNTAX       VacmContextEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Information about a particular context."
    INDEX       {
                  vacmContextName
                }
    ::= { vacmContextTable 1 }

VacmContextEntry ::= SEQUENCE
    {
        vacmContextName SnmpAdminString
    }

vacmContextName  OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-only
    STATUS       current



Wijnen, et al.              Standards Track                    [Page 13]


RFC 3415                   VACM for the SNMP               December 2002


    DESCRIPTION "A human readable name identifying a particular
                 context at a particular SNMP entity.

                 The empty contextName (zero length) represents the
                 default context.
                "
    ::= { vacmContextEntry 1 }

-- Information about Groups ******************************************

vacmSecurityToGroupTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF VacmSecurityToGroupEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "This table maps a combination of securityModel and
                 securityName into a groupName which is used to define
                 an access control policy for a group of principals.
                "
    ::= { vacmMIBObjects 2 }

vacmSecurityToGroupEntry OBJECT-TYPE
    SYNTAX       VacmSecurityToGroupEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An entry in this table maps the combination of a
                 securityModel and securityName into a groupName.
                "
    INDEX       {
                  vacmSecurityModel,
                  vacmSecurityName
                }
    ::= { vacmSecurityToGroupTable 1 }

VacmSecurityToGroupEntry ::= SEQUENCE
    {
        vacmSecurityModel               SnmpSecurityModel,
        vacmSecurityName                SnmpAdminString,
        vacmGroupName                   SnmpAdminString,
        vacmSecurityToGroupStorageType  StorageType,
        vacmSecurityToGroupStatus       RowStatus
    }

vacmSecurityModel OBJECT-TYPE
    SYNTAX       SnmpSecurityModel(1..2147483647)
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The Security Model, by which the vacmSecurityName
                 referenced by this entry is provided.



Wijnen, et al.              Standards Track                    [Page 14]


RFC 3415                   VACM for the SNMP               December 2002


                 Note, this object may not take the 'any' (0) value.
                "
    ::= { vacmSecurityToGroupEntry 1 }

vacmSecurityName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The securityName for the principal, represented in a
                 Security Model independent format, which is mapped by
                 this entry to a groupName.
                "
    ::= { vacmSecurityToGroupEntry 2 }

vacmGroupName    OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The name of the group to which this entry (e.g., the
                 combination of securityModel and securityName)
                 belongs.

                 This groupName is used as index into the
                 vacmAccessTable to select an access control policy.
                 However, a value in this table does not imply that an
                 instance with the value exists in table vacmAccesTable.
                "
    ::= { vacmSecurityToGroupEntry 3 }

vacmSecurityToGroupStorageType 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 }
    ::= { vacmSecurityToGroupEntry 4 }

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

                 Until instances of all corresponding columns are
                 appropriately configured, the value of the



Wijnen, et al.              Standards Track                    [Page 15]


RFC 3415                   VACM for the SNMP               December 2002


                 corresponding instance of the vacmSecurityToGroupStatus
                 column is 'notReady'.

                 In particular, a newly created row cannot be made
                 active until a value has been set for vacmGroupName.

                 The  RowStatus TC [RFC2579] requires that this
                 DESCRIPTION clause states under which circumstances
                 other objects in this row can be modified:

                 The value of this object has no effect on whether
                 other objects in this conceptual row can be modified.
                "
    ::= { vacmSecurityToGroupEntry 5 }

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

vacmAccessTable  OBJECT-TYPE
    SYNTAX       SEQUENCE OF VacmAccessEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The table of access rights for groups.

                 Each entry is indexed by a groupName, a contextPrefix,
                 a securityModel and a securityLevel.  To determine
                 whether access is allowed, one entry from this table
                 needs to be selected and the proper viewName from that
                 entry must be used for access control checking.

                 To select the proper entry, follow these steps:

                 1) the set of possible matches is formed by the
                    intersection of the following sets of entries:

                      the set of entries with identical vacmGroupName
                      the union of these two sets:
                       - the set with identical vacmAccessContextPrefix
                       - the set of entries with vacmAccessContextMatch
                         value of 'prefix' and matching
                         vacmAccessContextPrefix
                      intersected with the union of these two sets:
                       - the set of entries with identical
                         vacmSecurityModel
                       - the set of entries with vacmSecurityModel
                         value of 'any'
                      intersected with the set of entries with
                      vacmAccessSecurityLevel value less than or equal
                      to the requested securityLevel



Wijnen, et al.              Standards Track                    [Page 16]


RFC 3415                   VACM for the SNMP               December 2002


                 2) if this set has only one member, we're done
                    otherwise, it comes down to deciding how to weight
                    the preferences between ContextPrefixes,
                    SecurityModels, and SecurityLevels as follows:
                    a) if the subset of entries with securityModel
                       matching the securityModel in the message is
                       not empty, then discard the rest.
                    b) if the subset of entries with
                       vacmAccessContextPrefix matching the contextName
                       in the message is not empty,
                       then discard the rest
                    c) discard all entries with ContextPrefixes shorter
                       than the longest one remaining in the set
                    d) select the entry with the highest securityLevel

                 Please note that for securityLevel noAuthNoPriv, all
                 groups are really equivalent since the assumption that
                 the securityName has been authenticated does not hold.
                "
    ::= { vacmMIBObjects 4 }

vacmAccessEntry  OBJECT-TYPE
    SYNTAX       VacmAccessEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An access right configured in the Local Configuration
                 Datastore (LCD) authorizing access to an SNMP context.

                 Entries in this table can use an instance value for
                 object vacmGroupName even if no entry in table
                 vacmAccessSecurityToGroupTable has a corresponding
                 value for object vacmGroupName.
                "
    INDEX       { vacmGroupName,
                  vacmAccessContextPrefix,
                  vacmAccessSecurityModel,
                  vacmAccessSecurityLevel
                }
    ::= { vacmAccessTable 1 }

VacmAccessEntry ::= SEQUENCE
    {
        vacmAccessContextPrefix    SnmpAdminString,
        vacmAccessSecurityModel    SnmpSecurityModel,
        vacmAccessSecurityLevel    SnmpSecurityLevel,
        vacmAccessContextMatch     INTEGER,
        vacmAccessReadViewName     SnmpAdminString,
        vacmAccessWriteViewName    SnmpAdminString,



Wijnen, et al.              Standards Track                    [Page 17]


RFC 3415                   VACM for the SNMP               December 2002


        vacmAccessNotifyViewName   SnmpAdminString,
        vacmAccessStorageType      StorageType,
        vacmAccessStatus           RowStatus
    }

vacmAccessContextPrefix OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "In order to gain the access rights allowed by this
                 conceptual row, a contextName must match exactly
                 (if the value of vacmAccessContextMatch is 'exact')
                 or partially (if the value of vacmAccessContextMatch
                 is 'prefix') to the value of the instance of this
                 object.
                "
    ::= { vacmAccessEntry 1 }

vacmAccessSecurityModel OBJECT-TYPE
    SYNTAX       SnmpSecurityModel
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "In order to gain the access rights allowed by this
                 conceptual row, this securityModel must be in use.
                "
    ::= { vacmAccessEntry 2 }

vacmAccessSecurityLevel OBJECT-TYPE
    SYNTAX       SnmpSecurityLevel
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The minimum level of security required in order to
                 gain the access rights allowed by this conceptual
                 row.  A securityLevel of noAuthNoPriv is less than
                 authNoPriv which in turn is less than authPriv.

                 If multiple entries are equally indexed except for
                 this vacmAccessSecurityLevel index, then the entry
                 which has the highest value for
                 vacmAccessSecurityLevel is selected.
                "
    ::= { vacmAccessEntry 3 }

vacmAccessContextMatch OBJECT-TYPE
    SYNTAX       INTEGER
                { exact (1), -- exact match of prefix and contextName
                  prefix (2) -- Only match to the prefix
                }



Wijnen, et al.              Standards Track                    [Page 18]


RFC 3415                   VACM for the SNMP               December 2002


    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "If the value of this object is exact(1), then all
                 rows where the contextName exactly matches
                 vacmAccessContextPrefix are selected.

                 If the value of this object is prefix(2), then all
                 rows where the contextName whose starting octets
                 exactly match vacmAccessContextPrefix are selected.
                 This allows for a simple form of wildcarding.
                "
    DEFVAL      { exact }
    ::= { vacmAccessEntry 4 }

vacmAccessReadViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    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 one for which the
                 vacmViewTreeFamilyViewName has the same value as the
                 instance of this object; if the value is the empty
                 string or if there is no active MIB view having this
                 value of vacmViewTreeFamilyViewName, then no access
                 is granted.
                "
    DEFVAL      { ''H }   -- the empty string
    ::= { vacmAccessEntry 5 }

vacmAccessWriteViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    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 write access.

                 The identified MIB view is that one for which the
                 vacmViewTreeFamilyViewName has the same value as the
                 instance of this object; if the value is the empty
                 string or if there is no active MIB view having this
                 value of vacmViewTreeFamilyViewName, then no access
                 is granted.
                "
    DEFVAL      { ''H }   -- the empty string



Wijnen, et al.              Standards Track                    [Page 19]


RFC 3415                   VACM for the SNMP               December 2002


    ::= { vacmAccessEntry 6 }

vacmAccessNotifyViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    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 access for notifications.

                 The identified MIB view is that one for which the
                 vacmViewTreeFamilyViewName has the same value as the
                 instance of this object; if the value is the empty
                 string or if there is no active MIB view having this
                 value of vacmViewTreeFamilyViewName, then no access
                 is granted.
                "
    DEFVAL      { ''H }   -- the empty string
    ::= { vacmAccessEntry 7 }

vacmAccessStorageType 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 }
    ::= { vacmAccessEntry 8 }

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

                 The  RowStatus TC [RFC2579] requires that this
                 DESCRIPTION clause states under which circumstances
                 other objects in this row can be modified:

                 The value of this object has no effect on whether
                 other objects in this conceptual row can be modified.
                "
    ::= { vacmAccessEntry 9 }

-- Information about MIB views ***************************************



Wijnen, et al.              Standards Track                    [Page 20]


RFC 3415                   VACM for the SNMP               December 2002


-- Support for instance-level granularity is optional.
--
-- In some implementations, instance-level access control
-- granularity may come at a high performance cost.  Managers
-- should avoid requesting such configurations unnecessarily.

vacmMIBViews     OBJECT IDENTIFIER ::= { vacmMIBObjects 5 }

vacmViewSpinLock OBJECT-TYPE
    SYNTAX       TestAndIncr
    MAX-ACCESS   read-write
    STATUS       current
    DESCRIPTION "An advisory lock used to allow cooperating SNMP
                 Command Generator applications to coordinate their
                 use of the Set operation in creating or modifying
                 views.

                 When creating a new view or altering an existing
                 view, it is important to understand the potential
                 interactions with other uses of the view.  The
                 vacmViewSpinLock should be retrieved.  The name of
                 the view to be created should be determined to be
                 unique by the SNMP Command Generator application by
                 consulting the vacmViewTreeFamilyTable.  Finally,
                 the named view may be created (Set), including the
                 advisory lock.
                 If another SNMP Command Generator application has
                 altered the views in the meantime, then the spin
                 lock's value will have changed, and so this creation
                 will fail because it will specify the wrong value for
                 the spin lock.

                 Since this is an advisory lock, the use of this lock
                 is not enforced.
                "
    ::= { vacmMIBViews 1 }

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

                 Each MIB view is defined by two sets of view subtrees:
                   - the included view subtrees, and
                   - the excluded view subtrees.
                 Every such view subtree, both the included and the



Wijnen, et al.              Standards Track                    [Page 21]


RFC 3415                   VACM for the SNMP               December 2002


                 excluded ones, 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 vacmViewTreeFamilyType in the entry whose
                 value of vacmViewTreeFamilySubtree has the most
                 sub-identifiers.  If multiple entries match and have
                 the same number of sub-identifiers (when wildcarding
                 is specified with the value of vacmViewTreeFamilyMask),
                 then the lexicographically greatest instance of
                 vacmViewTreeFamilyType 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 vacmViewTreeFamilySubtree for the entry,
                 and each sub-identifier in the value of
                 vacmViewTreeFamilySubtree matches its corresponding
                 sub-identifier in X.  Two sub-identifiers match
                 either if the corresponding bit of the value of
                 vacmViewTreeFamilyMask for the entry is zero (the
                 'wild card' value), or if they are equal.

                 A 'family' of subtrees is the set of subtrees defined
                 by a particular combination of values of
                 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask.

                 In the case where no 'wild card' is defined in the
                 vacmViewTreeFamilyMask, the family of subtrees reduces
                 to a single subtree.

                 When creating or changing MIB views, an SNMP Command
                 Generator application should utilize the
                 vacmViewSpinLock to try to avoid collisions.  See
                 DESCRIPTION clause of vacmViewSpinLock.

                 When creating MIB views, it is strongly advised that
                 first the 'excluded' vacmViewTreeFamilyEntries are
                 created and then the 'included' entries.

                 When deleting MIB views, it is strongly advised that
                 first the 'included' vacmViewTreeFamilyEntries are



Wijnen, et al.              Standards Track                    [Page 22]


RFC 3415                   VACM for the SNMP               December 2002


                 deleted and then the 'excluded' entries.

                 If a create for an entry for instance-level access
                 control is received and the implementation does not
                 support instance-level granularity, then an
                 inconsistentName error must be returned.
                "
    ::= { vacmMIBViews 2 }

vacmViewTreeFamilyEntry OBJECT-TYPE
    SYNTAX       VacmViewTreeFamilyEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Information on a particular family of view subtrees
                 included in or excluded from a particular SNMP
                 context's MIB view.

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

                 If no conceptual rows exist in this table for a given
                 MIB view (viewName), that view may be thought of as
                 consisting of the empty set of view subtrees.
                "
    INDEX       { vacmViewTreeFamilyViewName,
                  vacmViewTreeFamilySubtree
                }
    ::= { vacmViewTreeFamilyTable 1 }

VacmViewTreeFamilyEntry ::= SEQUENCE
    {
        vacmViewTreeFamilyViewName     SnmpAdminString,
        vacmViewTreeFamilySubtree      OBJECT IDENTIFIER,
        vacmViewTreeFamilyMask         OCTET STRING,
        vacmViewTreeFamilyType         INTEGER,
        vacmViewTreeFamilyStorageType  StorageType,
        vacmViewTreeFamilyStatus       RowStatus
    }

vacmViewTreeFamilyViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The human readable name for a family of view subtrees.
                "



Wijnen, et al.              Standards Track                    [Page 23]


RFC 3415                   VACM for the SNMP               December 2002


    ::= { vacmViewTreeFamilyEntry 1 }

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

vacmViewTreeFamilyMask 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 vacmViewTreeFamilySubtree,
                 defines a family of view subtrees.

                 Each bit of this bit mask corresponds to a
                 sub-identifier of vacmViewTreeFamilySubtree, 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
                 vacmViewTreeFamilySubtree, either:

                   the i-th bit of vacmViewTreeFamilyMask is 0, or

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

                 If the value of this bit mask is M bits long and



Wijnen, et al.              Standards Track                    [Page 24]


RFC 3415                   VACM for the SNMP               December 2002


                 there are more than M sub-identifiers in the
                 corresponding instance of vacmViewTreeFamilySubtree,
                 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 vacmViewTreeFamilySubtree.

                 Note that masks of length greater than zero length
                 do not need to be supported.  In this case this
                 object is made read-only.
                "
    DEFVAL      { ''H }
    ::= { vacmViewTreeFamilyEntry 3 }

vacmViewTreeFamilyType OBJECT-TYPE
    SYNTAX       INTEGER  { included(1), excluded(2) }
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "Indicates whether the corresponding instances of
                 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask
                 define a family of view subtrees which is included in
                 or excluded from the MIB view.
                "
    DEFVAL      { included }
    ::= { vacmViewTreeFamilyEntry 4 }

vacmViewTreeFamilyStorageType 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 }
    ::= { vacmViewTreeFamilyEntry 5 }

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



Wijnen, et al.              Standards Track                    [Page 25]


RFC 3415                   VACM for the SNMP               December 2002


                 The  RowStatus TC [RFC2579] requires that this
                 DESCRIPTION clause states under which circumstances
                 other objects in this row can be modified:

                 The value of this object has no effect on whether
                 other objects in this conceptual row can be modified.
                "
    ::= { vacmViewTreeFamilyEntry 6 }

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

vacmMIBCompliances  OBJECT IDENTIFIER ::= { vacmMIBConformance 1 }
vacmMIBGroups       OBJECT IDENTIFIER ::= { vacmMIBConformance 2 }

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

vacmMIBCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION "The compliance statement for SNMP engines which
                 implement the SNMP View-based Access Control Model
                 configuration MIB.
                "
    MODULE -- this module
        MANDATORY-GROUPS { vacmBasicGroup }

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

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

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

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

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

        OBJECT        vacmAccessStatus
        MIN-ACCESS    read-only
        DESCRIPTION  "Create/delete/modify access to the



Wijnen, et al.              Standards Track                    [Page 26]


RFC 3415                   VACM for the SNMP               December 2002


                      vacmAccessTable is not required.
                     "

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

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

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

        OBJECT        vacmViewTreeFamilyStatus
        MIN-ACCESS    read-only
        DESCRIPTION  "Create/delete/modify access to the
                      vacmViewTreeFamilyTable is not required.
                     "
    ::= { vacmMIBCompliances 1 }

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

vacmBasicGroup OBJECT-GROUP
    OBJECTS {
              vacmContextName,
              vacmGroupName,
              vacmSecurityToGroupStorageType,
              vacmSecurityToGroupStatus,
              vacmAccessContextMatch,
              vacmAccessReadViewName,
              vacmAccessWriteViewName,
              vacmAccessNotifyViewName,
              vacmAccessStorageType,
              vacmAccessStatus,
              vacmViewSpinLock,
              vacmViewTreeFamilyMask,
              vacmViewTreeFamilyType,
              vacmViewTreeFamilyStorageType,
              vacmViewTreeFamilyStatus
            }
    STATUS       current
    DESCRIPTION "A collection of objects providing for remote
                 configuration of an SNMP engine which implements



Wijnen, et al.              Standards Track                    [Page 27]


RFC 3415                   VACM for the SNMP               December 2002


                 the SNMP View-based Access Control Model.
                "
    ::= { vacmMIBGroups 1 }

END

5.  Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

6.  Acknowledgements

   This document is the result of the efforts of the SNMPv3 Working
   Group.  Some special thanks are in order to the following SNMPv3 WG
   members:

      Harald Tveit Alvestrand (Maxware)
      Dave Battle (SNMP Research, Inc.)
      Alan Beard (Disney Worldwide Services)
      Paul Berrevoets (SWI Systemware/Halcyon Inc.)
      Martin Bjorklund (Ericsson)
      Uri Blumenthal (IBM T.J. Watson Research Center)
      Jeff Case (SNMP Research, Inc.)
      John Curran (BBN)
      Mike Daniele (Compaq Computer Corporation)
      T. Max Devlin (Eltrax Systems)
      John Flick (Hewlett Packard)
      Rob Frye (MCI)
      Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.)
      David Harrington (Cabletron Systems Inc.)



Wijnen, et al.              Standards Track                    [Page 28]


RFC 3415                   VACM for the SNMP               December 2002


      Lauren Heintz (BMC Software, Inc.)
      N.C. Hien (IBM T.J. Watson Research Center)
      Michael Kirkham (InterWorking Labs, Inc.)
      Dave Levi (SNMP Research, Inc.)
      Louis A Mamakos (UUNET Technologies Inc.)
      Joe Marzot (Nortel Networks)
      Paul Meyer (Secure Computing Corporation)
      Keith McCloghrie (Cisco Systems)
      Bob Moore (IBM)
      Russ Mundy (TIS Labs at Network Associates)
      Bob Natale (ACE*COMM Corporation)
      Mike O'Dell (UUNET Technologies Inc.)
      Dave Perkins (DeskTalk)
      Peter Polkinghorne (Brunel University)
      Randy Presuhn (BMC Software, Inc.)
      David Reeder (TIS Labs at Network Associates)
      David Reid (SNMP Research, Inc.)
      Aleksey Romanov (Quality Quorum)
      Shawn Routhier (Epilogue)
      Juergen Schoenwaelder (TU Braunschweig)
      Bob Stewart (Cisco Systems)
      Mike Thatcher (Independent Consultant)
      Bert Wijnen (IBM T.J. Watson Research Center)

   The document is based on recommendations of the IETF Security and
   Administrative Framework Evolution for SNMP Advisory Team.  Members
   of that Advisory Team were:

      David Harrington (Cabletron Systems Inc.)
      Jeff Johnson (Cisco Systems)
      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 Center)

   As recommended by the Advisory Team and the SNMPv3 Working Group
   Charter, the design incorporates as much as practical from previous
   RFCs and drafts.  As a result, special thanks are due to the authors
   of previous designs known as SNMPv2u and SNMPv2*:

      Jeff Case (SNMP Research, Inc.)
      David Harrington (Cabletron Systems Inc.)
      David Levi (SNMP Research, Inc.)
      Keith McCloghrie (Cisco Systems)
      Brian O'Keefe (Hewlett Packard)
      Marshall T. Rose (Dover Beach Consulting)



Wijnen, et al.              Standards Track                    [Page 29]


RFC 3415                   VACM for the SNMP               December 2002


      Jon Saperia (BGS Systems Inc.)
      Steve Waldbusser (International Network Services)
      Glenn W. Waters (Bell-Northern Research Ltd.)

7.  Security Considerations

7.1.  Recommended Practices

   This document is meant for use in the SNMP architecture.  The View-
   based Access Control Model described in this document checks access
   rights to management information based on:

   -  contextName, representing a set of management information at the
      managed system where the Access Control module is running.

   -  groupName, representing a set of zero or more securityNames.  The
      combination of a securityModel and a securityName is mapped into a
      group in the View-based Access Control Model.

   -  securityModel under which access is requested.

   -  securityLevel under which access is requested.

   -  operation performed on the management information.

   -  MIB views for read, write or notify access.

   When the User-based Access Control module is called for checking
   access rights, it is assumed that the calling module has ensured the
   authentication and privacy aspects as specified by the securityLevel
   that is being passed.

   When creating entries in or deleting entries from the
   vacmViewTreeFamilyTable it is important to do such in the sequence as
   recommended in the DESCRIPTION clause of the vacmViewTreeFamilyTable
   definition.  Otherwise unwanted access may be granted while changing
   the entries in the table.

7.2.  Defining Groups

   The groupNames are used to give access to a group of zero or more
   securityNames.  Within the View-Based Access Control Model, a
   groupName is considered to exist if that groupName is listed in the
   vacmSecurityToGroupTable.

   By mapping the combination of a securityModel and securityName into a
   groupName, an SNMP Command Generator application can add/delete
   securityNames to/from a group, if proper access is allowed.



Wijnen, et al.              Standards Track                    [Page 30]


RFC 3415                   VACM for the SNMP               December 2002


   Further it is important to realize that the grouping of
   <securityModel, securityName> tuples in the vacmSecurityToGroupTable
   does not take securityLevel into account.  It is therefore important
   that the security administrator uses the securityLevel index in the
   vacmAccessTable to separate noAuthNoPriv from authPriv and/or
   authNoPriv access.

7.3.  Conformance

   For an implementation of the View-based Access Control Model to be
   conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB according
   to the vacmMIBCompliance.  It also SHOULD implement the initial
   configuration, described in appendix A.

7.4.  Access to the SNMP-VIEW-BASED-ACM-MIB

   The objects in this MIB control the access to all MIB data that is
   accessible via the SNMP engine and they may be considered sensitive
   in many environments.  It is important to closely control (both read
   and write) access to these to these MIB objects by using
   appropriately configured Access Control models (for example the
   View-based Access Control Model as specified in this document).

8.  References

8.1. Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Structure of Management
               Information Version 2 (SMIv2)", STD 58, RFC 2578, April
               1999.

   [RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Textual Conventions for
               SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Conformance Statements for
               SMIv2", STD 58, RFC 2580, April 1999.

   [RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An
               Architecture for describing Simple Network Management
               Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
               December 2002.




Wijnen, et al.              Standards Track                    [Page 31]


RFC 3415                   VACM for the SNMP               December 2002


   [SNMP3412]  Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
               "Message Processing and Dispatching for the Simple
               Network Management Protocol (SNMP)", STD 62, RFC 3412,
               December 2002.

   [RFC3414]   Blumenthal, U. and B. Wijnen, "User-based Security Model
               (USM) for version 3 of the Simple Network Management
               Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.

8.2. Informative References

   [ISO-ASN.1] Information processing systems - Open Systems
               Interconnection - Specification of Abstract Syntax
               Notation One (ASN.1), International Organization for
               Standardization.  International Standard 8824, (December,
               1987).



































Wijnen, et al.              Standards Track                    [Page 32]


RFC 3415                   VACM for the SNMP               December 2002


Appendix A - Installation

A.1.  Installation Parameters

   During installation, an authoritative SNMP engine which supports this
   View-based Access Control Model SHOULD be configured with several
   initial parameters.  These include for the View-based Access Control
   Model:

   1) A security configuration

      The choice of security configuration determines if initial
      configuration is implemented and if so how.  One of three possible
      choices is selected:

         -  initial-minimum-security-configuration
         -  initial-semi-security-configuration
         -  initial-no-access-configuration

      In the case of a initial-no-access-configuration, there is no
      initial configuration, and so the following steps are irrelevant.

   2) A default context

      One entry in the vacmContextTable with a contextName of "" (the
      empty string), representing the default context.  Note that this
      table gets created automatically if a default context exists.

         vacmContextName                  ""

   3) An initial group

      One entry in the vacmSecurityToGroupTable to allow access to group
      "initial".

         vacmSecurityModel                3 (USM)
         vacmSecurityName                 "initial"
         vacmGroupName                    "initial"
         vacmSecurityToGroupStorageType   anyValidStorageType
         vacmSecurityToGroupStatus        active











Wijnen, et al.              Standards Track                    [Page 33]


RFC 3415                   VACM for the SNMP               December 2002


   4) Initial access rights

      Three entries in the vacmAccessTable as follows:

      -  read-notify access for securityModel USM, securityLevel
         "noAuthNoPriv" on behalf of securityNames that belong to the
         group "initial" to the <restricted> MIB view in the default
         context with contextName "".

      -  read-write-notify access for securityModel USM, securityLevel
         "authNoPriv" on behalf of securityNames that belong to the
         group "initial" to the <internet> MIB view in the default
         context with contextName "".

      -  if privacy is supported, read-write-notify access for
         securityModel USM, securityLevel "authPriv" on behalf of
         securityNames that belong to the group "initial" to the
         <internet> MIB view in the default context with contextName "".

      That translates into the following entries in the vacmAccessTable.

      -  One entry to be used for unauthenticated access (noAuthNoPriv):

         vacmGroupName                    "initial"
         vacmAccessContextPrefix          ""
         vacmAccessSecurityModel          3 (USM)
         vacmAccessSecurityLevel          noAuthNoPriv
         vacmAccessContextMatch           exact
         vacmAccessReadViewName           "restricted"
         vacmAccessWriteViewName          ""
         vacmAccessNotifyViewName         "restricted"
         vacmAccessStorageType            anyValidStorageType
         vacmAccessStatus                 active

      -  One entry to be used for authenticated access (authNoPriv) with
         optional privacy (authPriv):

         vacmGroupName                    "initial"
         vacmAccessContextPrefix          ""
         vacmAccessSecurityModel          3 (USM)
         vacmAccessSecurityLevel          authNoPriv
         vacmAccessContextMatch           exact
         vacmAccessReadViewName           "internet"
         vacmAccessWriteViewName          "internet"
         vacmAccessNotifyViewName         "internet"
         vacmAccessStorageType            anyValidStorageType
         vacmAccessStatus                 active




Wijnen, et al.              Standards Track                    [Page 34]


RFC 3415                   VACM for the SNMP               December 2002


   5) Two MIB views, of which the second one depends on the security
      configuration.

      -  One view, the <internet> view, for authenticated access:

         -  the <internet> MIB view is the following subtree:
               "internet"  (subtree 1.3.6.1)

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

      -  For the initial-no-access-configuration there is no default
         initial configuration, so no MIB views are pre-scribed.

      -  For the initial-semi-secure-configuration:

            the <restricted> MIB view is the union of these subtrees:
            (a) "system"       (subtree 1.3.6.1.2.1.1)      [RFC3918]
            (b) "snmp"         (subtree 1.3.6.1.2.1.11)     [RFC3918]
            (c) "snmpEngine"   (subtree 1.3.6.1.6.3.10.2.1) [RFC3411]
            (d) "snmpMPDStats" (subtree 1.3.6.1.6.3.11.2.1) [RFC3412]
            (e) "usmStats"     (subtree 1.3.6.1.6.3.15.1.1) [RFC3414]

      -  For the initial-minimum-secure-configuration:

            the <restricted> MIB view is the following subtree.
                "internet"  (subtree 1.3.6.1)

   This translates into the following "internet" entry in the
   vacmViewTreeFamilyTable:

                                 minimum-secure      semi-secure
                                 ----------------    ---------------
   vacmViewTreeFamilyViewName    "internet"          "internet"
   vacmViewTreeFamilySubtree     1.3.6.1             1.3.6.1
   vacmViewTreeFamilyMask        ""                  ""
   vacmViewTreeFamilyType        1 (included)        1 (included)
   vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
   vacmViewTreeFamilyStatus      active              active











Wijnen, et al.              Standards Track                    [Page 35]


RFC 3415                   VACM for the SNMP               December 2002


   In addition it translates into the following "restricted" entries in
   the vacmViewTreeFamilyTable:

                                 minimum-secure      semi-secure
                                 ----------------    ---------------
   vacmViewTreeFamilyViewName    "restricted"        "restricted"
   vacmViewTreeFamilySubtree     1.3.6.1             1.3.6.1.2.1.1
   vacmViewTreeFamilyMask        ""                  ""
   vacmViewTreeFamilyType        1 (included)        1 (included)
   vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
   vacmViewTreeFamilyStatus      active              active

   vacmViewTreeFamilyViewName                        "restricted"
   vacmViewTreeFamilySubtree                         1.3.6.1.2.1.11
   vacmViewTreeFamilyMask                            ""
   vacmViewTreeFamilyType                            1 (included)
   vacmViewTreeFamilyStorageType                     anyValidStorageType
   vacmViewTreeFamilyStatus                          active

   vacmViewTreeFamilyViewName                        "restricted"
   vacmViewTreeFamilySubtree                         1.3.6.1.6.3.10.2.1
   vacmViewTreeFamilyMask                            ""
   vacmViewTreeFamilyType                            1 (included)
   vacmViewTreeFamilyStorageType                     anyValidStorageType
   vacmViewTreeFamilyStatus                          active

   vacmViewTreeFamilyViewName                        "restricted"
   vacmViewTreeFamilySubtree                         1.3.6.1.6.3.11.2.1
   vacmViewTreeFamilyMask                            ""
   vacmViewTreeFamilyType                            1 (included)
   vacmViewTreeFamilyStorageType                     anyValidStorageType
   vacmViewTreeFamilyStatus                          active

   vacmViewTreeFamilyViewName                        "restricted"
   vacmViewTreeFamilySubtree                         1.3.6.1.6.3.15.1.1
   vacmViewTreeFamilyMask                            ""
   vacmViewTreeFamilyType                            1 (included)
   vacmViewTreeFamilyStorageType                     anyValidStorageType
   vacmViewTreeFamilyStatus                          active

B.  Change Log

   Changes made since RFC 2575:

      -  Removed reference from abstract as per RFC-Editor guidelines
      -  Updated references





Wijnen, et al.              Standards Track                    [Page 36]


RFC 3415                   VACM for the SNMP               December 2002


   Changes made since RFC 2275:

      -  Added text to vacmSecurityToGroupStatus DESCRIPTION clause to
         clarify under which conditions an entry in the
         vacmSecurityToGroupTable can be made active.
      -  Added REVISION clauses to MODULE-IDENTITY
      -  Clarified text in vacmAccessTable DESCRIPTION clause.
      -  Added a DEFVAL clause to vacmAccessContextMatch object.
      -  Added missing columns in Appendix A and re-arranged for
         clarity.
      -  Fixed oids in appendix A.
      -  Use the PDU Class terminology instead of RFC1905 PDU types.
      -  Added section 7.4 about access control to the MIB.
      -  Fixed references to new/revised documents
      -  Fix Editor contact information.
      -  fixed spelling errors
      -  removed one vacmAccesEntry from sample in appendix A.
      -  made some more clarifications.
      -  updated acknowledgement section.
































Wijnen, et al.              Standards Track                    [Page 37]


RFC 3415                   VACM for the SNMP               December 2002


Editors' Addresses

   Bert Wijnen
   Lucent Technologies
   Schagen 33
   3461 GL Linschoten
   Netherlands

   Phone: +31-348-480-685
   EMail: bwijnen@lucent.com


   Randy Presuhn
   BMC Software, Inc.
   2141 North First Street
   San Jose, CA 95131
   USA

   Phone: +1 408-546-1006
   EMail: randy_presuhn@bmc.com


   Keith McCloghrie
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134-1706
   USA

   Phone: +1-408-526-5260
   EMail: kzm@cisco.com





















Wijnen, et al.              Standards Track                    [Page 38]


RFC 3415                   VACM for the SNMP               December 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Wijnen, et al.              Standards Track                    [Page 39]

========================================================================






Network Working Group                            Editor of this version:
Request for Comments: 3416                                    R. Presuhn
STD: 62                                               BMC Software, Inc.
Obsoletes: 1905                             Authors of previous version:
Category: Standards Track                                        J. Case
                                                     SNMP Research, Inc.
                                                           K. McCloghrie
                                                     Cisco Systems, Inc.
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                           S. Waldbusser
                                          International Network Services
                                                           December 2002


                Version 2 of the Protocol Operations for
             the Simple Network Management Protocol (SNMP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document defines version 2 of the protocol operations for the
   Simple Network Management Protocol (SNMP).  It defines the syntax and
   elements of procedure for sending, receiving, and processing SNMP
   PDUs.  This document obsoletes RFC 1905.















Presuhn, et al.             Standards Track                     [Page 1]


RFC 3416              Protocol Operations for SNMP         December 2002


Table of Contents

   1. Introduction ................................................    3
   2. Overview ....................................................    4
   2.1. Management Information ....................................    4
   2.2. Retransmission of Requests ................................    4
   2.3. Message Sizes .............................................    4
   2.4. Transport Mappings ........................................    5
   2.5. SMIv2 Data Type Mappings ..................................    6
   3. Definitions .................................................    6
   4. Protocol Specification ......................................    9
   4.1. Common Constructs .........................................    9
   4.2. PDU Processing ............................................   10
   4.2.1. The GetRequest-PDU ......................................   10
   4.2.2. The GetNextRequest-PDU ..................................   11
   4.2.2.1. Example of Table Traversal ............................   12
   4.2.3. The GetBulkRequest-PDU ..................................   14
   4.2.3.1. Another Example of Table Traversal ....................   17
   4.2.4. The Response-PDU ........................................   18
   4.2.5. The SetRequest-PDU ......................................   19
   4.2.6. The SNMPv2-Trap-PDU .....................................   22
   4.2.7. The InformRequest-PDU ...................................   23
   5. Notice on Intellectual Property .............................   24
   6. Acknowledgments .............................................   24
   7. Security Considerations .....................................   26
   8. References ..................................................   26
   8.1. Normative References ......................................   26
   8.2. Informative References ....................................   27
   9. Changes from RFC 1905 .......................................   28
   10. Editor's Address ...........................................   30
   11. Full Copyright Statement ...................................   31




















Presuhn, et al.             Standards Track                     [Page 2]


RFC 3416              Protocol Operations for SNMP         December 2002


1.  Introduction

   The SNMP Management Framework at the time of this writing consists of
   five major components:

      -  An overall architecture, described in STD 62, RFC 3411
         [RFC3411].

      -  Mechanisms for describing and naming objects and events for the
         purpose of management.  The first version of this Structure of
         Management Information (SMI) is called SMIv1 and described in
         STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
         1215 [RFC1215].  The second version, called SMIv2, is described
         in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
         STD 58, RFC 2580 [RFC2580].

      -  Message protocols for transferring management information.  The
         first version of the SNMP message protocol is called SNMPv1 and
         described in STD 15, RFC 1157 [RFC1157].  A second version of
         the SNMP message protocol, which is not an Internet standards
         track protocol, is called SNMPv2c and described in RFC 1901
         [RFC1901] and STD 62, RFC 3417 [RFC3417].  The third version of
         the message protocol is called SNMPv3 and described in STD 62,
         RFC 3417 [RFC3417], RFC 3412 [RFC3412] and RFC 3414 [RFC3414].

      -  Protocol operations for accessing management information.  The
         first set of protocol operations and associated PDU formats is
         described in STD 15, RFC 1157 [RFC1157].  A second set of
         protocol operations and associated PDU formats is described in
         this document.

      -  A set of fundamental applications described in STD 62, RFC 3413
         [RFC3413] and the view-based access control mechanism described
         in STD 62, RFC 3415 [RFC3415].

   A more detailed introduction to the SNMP Management Framework at the
   time of this writing can be found in RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This document, Version 2 of the Protocol Operations for the Simple
   Network Management Protocol, defines the operations of the protocol
   with respect to the sending and receiving of PDUs to be carried by
   the message protocol.





Presuhn, et al.             Standards Track                     [Page 3]


RFC 3416              Protocol Operations for SNMP         December 2002


2.  Overview

   SNMP entities supporting command generator or notification receiver
   applications (traditionally called "managers") communicate with SNMP
   entities supporting command responder or notification originator
   applications (traditionally called "agents").  The purpose of this
   protocol is the transport of management information and operations.

2.1.  Management Information

   The term "variable" refers to an instance of a non-aggregate object
   type defined according to the conventions set forth in the SMI
   [RFC2578] or the textual conventions based on the SMI [RFC2579].  The
   term "variable binding" normally refers to the pairing of the name of
   a variable and its associated value.  However, if certain kinds of
   exceptional conditions occur during processing of a retrieval
   request, a variable binding will pair a name and an indication of
   that exception.

   A variable-binding list is a simple list of variable bindings.

   The name of a variable is an OBJECT IDENTIFIER which is the
   concatenation of the OBJECT IDENTIFIER of the corresponding object-
   type together with an OBJECT IDENTIFIER fragment identifying the
   instance.  The OBJECT IDENTIFIER of the corresponding object-type is
   called the OBJECT IDENTIFIER prefix of the variable.

2.2.  Retransmission of Requests

   For all types of request in this protocol, the receiver is required
   under normal circumstances, to generate and transmit a response to
   the originator of the request.  Whether or not a request should be
   retransmitted if no corresponding response is received in an
   appropriate time interval, is at the discretion of the application
   originating the request.  This will normally depend on the urgency of
   the request.  However, such an application needs to act responsibly
   in respect to the frequency and duration of re-transmissions.  See
   BCP 41 [RFC2914] for discussion of relevant congestion control
   principles.

2.3.  Message Sizes

   The maximum size of an SNMP message is limited to the minimum of:

   (1)   the maximum message size which the destination SNMP entity can
         accept; and,





Presuhn, et al.             Standards Track                     [Page 4]


RFC 3416              Protocol Operations for SNMP         December 2002


   (2)   the maximum message size which the source SNMP entity can
         generate.

   The former may be known on a per-recipient basis; and in the absence
   of such knowledge, is indicated by transport domain used when sending
   the message.  The latter is imposed by implementation-specific local
   constraints.

   Each transport mapping for the SNMP indicates the minimum message
   size which a SNMP implementation must be able to produce or consume.
   Although implementations are encouraged to support larger values
   whenever possible, a conformant implementation must never generate
   messages larger than allowed by the receiving SNMP entity.

   One of the aims of the GetBulkRequest-PDU, specified in this
   protocol, is to minimize the number of protocol exchanges required to
   retrieve a large amount of management information.  As such, this PDU
   type allows an SNMP entity supporting command generator applications
   to request that the response be as large as possible given the
   constraints on message sizes.  These constraints include the limits
   on the size of messages which the SNMP entity supporting command
   responder applications can generate, and the SNMP entity supporting
   command generator applications can receive.

   However, it is possible that such maximum sized messages may be
   larger than the Path MTU of the path across the network traversed by
   the messages.  In this situation, such messages are subject to
   fragmentation.  Fragmentation is generally considered to be harmful
   [FRAG], since among other problems, it leads to a decrease in the
   reliability of the transfer of the messages.  Thus, an SNMP entity
   which sends a GetBulkRequest-PDU must take care to set its parameters
   accordingly, so as to reduce the risk of fragmentation.  In
   particular, under conditions of network stress, only small values
   should be used for max-repetitions.

2.4.  Transport Mappings

   It is important to note that the exchange of SNMP messages requires
   only an unreliable datagram service, with every message being
   entirely and independently contained in a single transport datagram.
   Specific transport mappings and encoding rules are specified
   elsewhere [RFC3417].  However, the preferred mapping is the use of
   the User Datagram Protocol [RFC768].








Presuhn, et al.             Standards Track                     [Page 5]


RFC 3416              Protocol Operations for SNMP         December 2002


2.5.  SMIv2 Data Type Mappings

   The SMIv2 [RFC2578] defines 11 base types (INTEGER, OCTET STRING,
   OBJECT IDENTIFIER, Integer32, IpAddress, Counter32, Gauge32,
   Unsigned32, TimeTicks, Opaque, Counter64) and the BITS construct.
   The SMIv2 base types are mapped to the corresponding selection type
   in the SimpleSyntax and ApplicationSyntax choices of the ASN.1 SNMP
   protocol definition.  Note that the INTEGER and Integer32 SMIv2 base
   types are mapped to the integer-value selection type of the
   SimpleSyntax choice.  Similarly, the Gauge32 and Unsigned32 SMIv2
   base types are mapped to the unsigned-integer-value selection type of
   the ApplicationSyntax choice.

   The SMIv2 BITS construct is mapped to the string-value selection type
   of the SimpleSyntax choice.  A BITS value is encoded as an OCTET
   STRING, in which all the named bits in (the definition of) the
   bitstring, commencing with the first bit and proceeding to the last
   bit, are placed in bits 8 (high order bit) to 1 (low order bit) of
   the first octet, followed by bits 8 to 1 of each subsequent octet in
   turn, followed by as many bits as are needed of the final subsequent
   octet, commencing with bit 8.  Remaining bits, if any, of the final
   octet are set to zero on generation and ignored on receipt.

3.  Definitions

   The PDU syntax is defined using ASN.1 notation [ASN1].

   SNMPv2-PDU DEFINITIONS ::= BEGIN

   ObjectName ::= OBJECT IDENTIFIER

   ObjectSyntax ::= CHOICE {
         simple           SimpleSyntax,
         application-wide ApplicationSyntax }

   SimpleSyntax ::= CHOICE {
         integer-value   INTEGER (-2147483648..2147483647),
         string-value    OCTET STRING (SIZE (0..65535)),
         objectID-value  OBJECT IDENTIFIER }

   ApplicationSyntax ::= CHOICE {
         ipAddress-value        IpAddress,
         counter-value          Counter32,
         timeticks-value        TimeTicks,
         arbitrary-value        Opaque,
         big-counter-value      Counter64,
         unsigned-integer-value Unsigned32 }




Presuhn, et al.             Standards Track                     [Page 6]


RFC 3416              Protocol Operations for SNMP         December 2002


   IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4))

   Counter32 ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295)

   Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295)

   Gauge32 ::= Unsigned32

   TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295)

   Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING

   Counter64 ::= [APPLICATION 6]
                 IMPLICIT INTEGER (0..18446744073709551615)

   -- protocol data units

   PDUs ::= CHOICE {
        get-request      GetRequest-PDU,
        get-next-request GetNextRequest-PDU,
        get-bulk-request GetBulkRequest-PDU,
        response         Response-PDU,
        set-request      SetRequest-PDU,
        inform-request   InformRequest-PDU,
        snmpV2-trap      SNMPv2-Trap-PDU,
        report           Report-PDU }

   -- PDUs

   GetRequest-PDU ::= [0] IMPLICIT PDU

   GetNextRequest-PDU ::= [1] IMPLICIT PDU

   Response-PDU ::= [2] IMPLICIT PDU

   SetRequest-PDU ::= [3] IMPLICIT PDU

   -- [4] is obsolete

   GetBulkRequest-PDU ::= [5] IMPLICIT BulkPDU

   InformRequest-PDU ::= [6] IMPLICIT PDU

   SNMPv2-Trap-PDU ::= [7] IMPLICIT PDU

   --   Usage and precise semantics of Report-PDU are not defined
   --   in this document.  Any SNMP administrative framework making
   --   use of this PDU must define its usage and semantics.



Presuhn, et al.             Standards Track                     [Page 7]


RFC 3416              Protocol Operations for SNMP         December 2002


   Report-PDU ::= [8] IMPLICIT PDU

   max-bindings INTEGER ::= 2147483647

   PDU ::= SEQUENCE {
           request-id INTEGER (-214783648..214783647),

           error-status                -- sometimes ignored
               INTEGER {
                   noError(0),
                   tooBig(1),
                   noSuchName(2),      -- for proxy compatibility
                   badValue(3),        -- for proxy compatibility
                   readOnly(4),        -- for proxy compatibility
                   genErr(5),
                   noAccess(6),
                   wrongType(7),
                   wrongLength(8),
                   wrongEncoding(9),
                   wrongValue(10),
                   noCreation(11),
                   inconsistentValue(12),
                   resourceUnavailable(13),
                   commitFailed(14),
                   undoFailed(15),
                   authorizationError(16),
                   notWritable(17),
                   inconsistentName(18)
               },

           error-index                 -- sometimes ignored
               INTEGER (0..max-bindings),

           variable-bindings           -- values are sometimes ignored
               VarBindList
       }

   BulkPDU ::=                         -- must be identical in
       SEQUENCE {                      -- structure to PDU
           request-id      INTEGER (-214783648..214783647),
           non-repeaters   INTEGER (0..max-bindings),
           max-repetitions INTEGER (0..max-bindings),

           variable-bindings           -- values are ignored
               VarBindList
       }

   -- variable binding



Presuhn, et al.             Standards Track                     [Page 8]


RFC 3416              Protocol Operations for SNMP         December 2002


   VarBind ::= SEQUENCE {
           name ObjectName,

           CHOICE {
               value          ObjectSyntax,
               unSpecified    NULL,    -- in retrieval requests

                                       -- exceptions in responses
               noSuchObject   [0] IMPLICIT NULL,
               noSuchInstance [1] IMPLICIT NULL,
               endOfMibView   [2] IMPLICIT NULL
           }
       }

   -- variable-binding list

   VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind

   END

4.  Protocol Specification

4.1.  Common Constructs

   The value of the request-id field in a Response-PDU takes the value
   of the request-id field in the request PDU to which it is a response.
   By use of the request-id value, an application can distinguish the
   (potentially multiple) outstanding requests, and thereby correlate
   incoming responses with outstanding requests.  In cases where an
   unreliable datagram service is used, the request-id also provides a
   simple means of identifying messages duplicated by the network.  Use
   of the same request-id on a retransmission of a request allows the
   response to either the original transmission or the retransmission to
   satisfy the request.  However, in order to calculate the round trip
   time for transmission and processing of a request-response
   transaction, the application needs to use a different request-id
   value on a retransmitted request.  The latter strategy is recommended
   for use in the majority of situations.

   A non-zero value of the error-status field in a Response-PDU is used
   to indicate that an error occurred to prevent the processing of the
   request.  In these cases, a non-zero value of the Response-PDU's
   error-index field provides additional information by identifying
   which variable binding in the list caused the error.  A variable
   binding is identified by its index value.  The first variable binding
   in a variable-binding list is index one, the second is index two,
   etc.




Presuhn, et al.             Standards Track                     [Page 9]


RFC 3416              Protocol Operations for SNMP         December 2002


   SNMP limits OBJECT IDENTIFIER values to a maximum of 128 sub-
   identifiers, where each sub-identifier has a maximum value of
   2**32-1.

4.2.  PDU Processing

   In the elements of procedure below, any field of a PDU which is not
   referenced by the relevant procedure is ignored by the receiving SNMP
   entity.  However, all components of a PDU, including those whose
   values are ignored by the receiving SNMP entity, must have valid
   ASN.1 syntax and encoding.  For example, some PDUs (e.g., the
   GetRequest-PDU) are concerned only with the name of a variable and
   not its value.  In this case, the value portion of the variable
   binding is ignored by the receiving SNMP entity.  The unSpecified
   value is defined for use as the value portion of such bindings.

   On generating a management communication, the message "wrapper" to
   encapsulate the PDU is generated according to the "Elements of
   Procedure" of the administrative framework in use.  The definition of
   "max-bindings" imposes an upper bound on the number of variable
   bindings.  In practice, the size of a message is also limited by
   constraints on the maximum message size.  A compliant implementation
   must support as many variable bindings in a PDU or BulkPDU as fit
   into the overall maximum message size limit of the SNMP engine, but
   no more than 2147483647 variable bindings.

   On receiving a management communication, the "Elements of Procedure"
   of the administrative framework in use is followed, and if those
   procedures indicate that the operation contained within the message
   is to be performed locally, then those procedures also indicate the
   MIB view which is visible to the operation.

4.2.1.  The GetRequest-PDU

   A GetRequest-PDU is generated and transmitted at the request of an
   application.

   Upon receipt of a GetRequest-PDU, the receiving SNMP entity processes
   each variable binding in the variable-binding list to produce a
   Response-PDU.  All fields of the Response-PDU have the same values as
   the corresponding fields of the received request except as indicated
   below.  Each variable binding is processed as follows:

   (1)   If the variable binding's name exactly matches the name of a
         variable accessible by this request, then the variable
         binding's value field is set to the value of the named
         variable.




Presuhn, et al.             Standards Track                    [Page 10]


RFC 3416              Protocol Operations for SNMP         December 2002


   (2)   Otherwise, if the variable binding's name does not have an
         OBJECT IDENTIFIER prefix which exactly matches the OBJECT
         IDENTIFIER prefix of any (potential) variable accessible by
         this request, then its value field is set to "noSuchObject".

   (3)   Otherwise, the variable binding's value field is set to
         "noSuchInstance".

   If the processing of any variable binding fails for a reason other
   than listed above, then the Response-PDU is re-formatted with the
   same values in its request-id and variable-bindings fields as the
   received GetRequest-PDU, with the value of its error-status field set
   to "genErr", and the value of its error-index field is set to the
   index of the failed variable binding.

   Otherwise, the value of the Response-PDU's error-status field is set
   to "noError", and the value of its error-index field is zero.

   The generated Response-PDU is then encapsulated into a message.  If
   the size of the resultant message is less than or equal to both a
   local constraint and the maximum message size of the originator, it
   is transmitted to the originator of the GetRequest-PDU.

   Otherwise, an alternate Response-PDU is generated.  This alternate
   Response-PDU is formatted with the same value in its request-id field
   as the received GetRequest-PDU, with the value of its error-status
   field set to "tooBig", the value of its error-index field set to
   zero, and an empty variable-bindings field.  This alternate
   Response-PDU is then encapsulated into a message.  If the size of the
   resultant message is less than or equal to both a local constraint
   and the maximum message size of the originator, it is transmitted to
   the originator of the GetRequest-PDU.  Otherwise, the snmpSilentDrops
   [RFC3418] counter is incremented and the resultant message is
   discarded.

4.2.2.  The GetNextRequest-PDU

   A GetNextRequest-PDU is generated and transmitted at the request of
   an application.

   Upon receipt of a GetNextRequest-PDU, the receiving SNMP entity
   processes each variable binding in the variable-binding list to
   produce a Response-PDU.  All fields of the Response-PDU have the same
   values as the corresponding fields of the received request except as
   indicated below.  Each variable binding is processed as follows:

      (1)   The variable is located which is in the lexicographically
            ordered list of the names of all variables which are



Presuhn, et al.             Standards Track                    [Page 11]


RFC 3416              Protocol Operations for SNMP         December 2002


            accessible by this request and whose name is the first
            lexicographic successor of the variable binding's name in
            the incoming GetNextRequest-PDU.  The corresponding variable
            binding's name and value fields in the Response-PDU are set
            to the name and value of the located variable.

      (2)   If the requested variable binding's name does not
            lexicographically precede the name of any variable
            accessible by this request, i.e., there is no lexicographic
            successor, then the corresponding variable binding produced
            in the Response-PDU has its value field set to
            "endOfMibView", and its name field set to the variable
            binding's name in the request.

   If the processing of any variable binding fails for a reason other
   than listed above, then the Response-PDU is re-formatted with the
   same values in its request-id and variable-bindings fields as the
   received GetNextRequest-PDU, with the value of its error-status field
   set to "genErr", and the value of its error-index field is set to the
   index of the failed variable binding.

   Otherwise, the value of the Response-PDU's error-status field is set
   to "noError", and the value of its error-index field is zero.

   The generated Response-PDU is then encapsulated into a message.  If
   the size of the resultant message is less than or equal to both a
   local constraint and the maximum message size of the originator, it
   is transmitted to the originator of the GetNextRequest-PDU.

   Otherwise, an alternate Response-PDU is generated.  This alternate
   Response-PDU is formatted with the same values in its request-id
   field as the received GetNextRequest-PDU, with the value of its
   error-status field set to "tooBig", the value of its error-index
   field set to zero, and an empty variable-bindings field.  This
   alternate Response-PDU is then encapsulated into a message.  If the
   size of the resultant message is less than or equal to both a local
   constraint and the maximum message size of the originator, it is
   transmitted to the originator of the GetNextRequest-PDU.  Otherwise,
   the snmpSilentDrops [RFC3418] counter is incremented and the
   resultant message is discarded.

4.2.2.1.  Example of Table Traversal

   An important use of the GetNextRequest-PDU is the traversal of
   conceptual tables of information within a MIB.  The semantics of this
   type of request, together with the method of identifying individual
   instances of objects in the MIB, provides access to related objects
   in the MIB as if they enjoyed a tabular organization.



Presuhn, et al.             Standards Track                    [Page 12]


RFC 3416              Protocol Operations for SNMP         December 2002


   In the protocol exchange sketched below, an application retrieves the
   media-dependent physical address and the address-mapping type for
   each entry in the IP net-to-media Address Translation Table [RFC1213]
   of a particular network element.  It also retrieves the value of
   sysUpTime [RFC3418], at which the mappings existed.  Suppose that the
   command responder's IP net-to-media table has three entries:

   Interface-Number  Network-Address  Physical-Address  Type

      1            10.0.0.51     00:00:10:01:23:45  static
      1             9.2.3.4      00:00:10:54:32:10  dynamic
      2            10.0.0.15     00:00:10:98:76:54  dynamic

   The SNMP entity supporting a command generator application begins by
   sending a GetNextRequest-PDU containing the indicated OBJECT
   IDENTIFIER values as the requested variable names:

    GetNextRequest ( sysUpTime,
                   ipNetToMediaPhysAddress,
                   ipNetToMediaType )

   The SNMP entity supporting a command responder application responds
   with a Response-PDU:

    Response (( sysUpTime.0 =  "123456" ),
               ( ipNetToMediaPhysAddress.1.9.2.3.4 = "000010543210" ),
            ( ipNetToMediaType.1.9.2.3.4 =  "dynamic" ))

   The SNMP entity supporting the command generator application
   continues with:

    GetNextRequest ( sysUpTime,
                   ipNetToMediaPhysAddress.1.9.2.3.4,
                   ipNetToMediaType.1.9.2.3.4 )

   The SNMP entity supporting the command responder application responds
   with:

    Response (( sysUpTime.0 =  "123461" ),
               ( ipNetToMediaPhysAddress.1.10.0.0.51 = "000010012345" ),
            ( ipNetToMediaType.1.10.0.0.51 =  "static" ))

   The SNMP entity supporting the command generator application
   continues with:

    GetNextRequest ( sysUpTime,
                   ipNetToMediaPhysAddress.1.10.0.0.51,
                   ipNetToMediaType.1.10.0.0.51 )



Presuhn, et al.             Standards Track                    [Page 13]


RFC 3416              Protocol Operations for SNMP         December 2002


   The SNMP entity supporting the command responder application responds
   with:

    Response (( sysUpTime.0 =  "123466" ),
               ( ipNetToMediaPhysAddress.2.10.0.0.15 = "000010987654" ),
            ( ipNetToMediaType.2.10.0.0.15 =  "dynamic" ))

   The SNMP entity supporting the command generator application
   continues with:

    GetNextRequest ( sysUpTime,
                   ipNetToMediaPhysAddress.2.10.0.0.15,
                   ipNetToMediaType.2.10.0.0.15 )

   As there are no further entries in the table, the SNMP entity
   supporting the command responder application responds with the
   variables that are next in the lexicographical ordering of the
   accessible object names, for example:

    Response (( sysUpTime.0 =  "123471" ),
               ( ipNetToMediaNetAddress.1.9.2.3.4 = "9.2.3.4" ),
            ( ipRoutingDiscards.0 =  "2" ))

   Note how, having reached the end of the column for
   ipNetToMediaPhysAddress, the second variable binding from the command
   responder application has now "wrapped" to the first row in the next
   column.  Furthermore, note how, having reached the end of the
   ipNetToMediaTable for the third variable binding, the command
   responder application has responded with the next available object,
   which is outside that table.  This response signals the end of the
   table to the command generator application.

4.2.3.  The GetBulkRequest-PDU

   A GetBulkRequest-PDU is generated and transmitted at the request of
   an application.  The purpose of the GetBulkRequest-PDU is to request
   the transfer of a potentially large amount of data, including, but
   not limited to, the efficient and rapid retrieval of large tables.

   Upon receipt of a GetBulkRequest-PDU, the receiving SNMP entity
   processes each variable binding in the variable-binding list to
   produce a Response-PDU with its request-id field having the same
   value as in the request.

   For the GetBulkRequest-PDU type, the successful processing of each
   variable binding in the request generates zero or more variable
   bindings in the Response-PDU.  That is, the one-to-one mapping
   between the variable bindings of the GetRequest-PDU, GetNextRequest-



Presuhn, et al.             Standards Track                    [Page 14]


RFC 3416              Protocol Operations for SNMP         December 2002


   PDU, and SetRequest-PDU types and the resultant Response-PDUs does
   not apply for the mapping between the variable bindings of a
   GetBulkRequest-PDU and the resultant Response-PDU.

   The values of the non-repeaters and max-repetitions fields in the
   request specify the processing requested.  One variable binding in
   the Response-PDU is requested for the first N variable bindings in
   the request and M variable bindings are requested for each of the R
   remaining variable bindings in the request.  Consequently, the total
   number of requested variable bindings communicated by the request is
   given by N + (M * R), where N is the minimum of:  a) the value of the
   non-repeaters field in the request, and b) the number of variable
   bindings in the request; M is the value of the max-repetitions field
   in the request; and R is the maximum of:  a) number of variable
   bindings in the request - N, and b)  zero.

   The receiving SNMP entity produces a Response-PDU with up to the
   total number of requested variable bindings communicated by the
   request.  The request-id shall have the same value as the received
   GetBulkRequest-PDU.

   If N is greater than zero, the first through the (N)-th variable
   bindings of the Response-PDU are each produced as follows:

   (1)   The variable is located which is in the lexicographically
         ordered list of the names of all variables which are accessible
         by this request and whose name is the first lexicographic
         successor of the variable binding's name in the incoming
         GetBulkRequest-PDU.  The corresponding variable binding's name
         and value fields in the Response-PDU are set to the name and
         value of the located variable.

   (2)   If the requested variable binding's name does not
         lexicographically precede the name of any variable accessible
         by this request, i.e., there is no lexicographic successor,
         then the corresponding variable binding produced in the
         Response-PDU has its value field set to "endOfMibView", and its
         name field set to the variable binding's name in the request.

   If M and R are non-zero, the (N + 1)-th and subsequent variable
   bindings of the Response-PDU are each produced in a similar manner.
   For each iteration i, such that i is greater than zero and less than
   or equal to M, and for each repeated variable, r, such that r is
   greater than zero and less than or equal to R, the (N + ( (i-1) * R )
   + r)-th variable binding of the Response-PDU is produced as follows:






Presuhn, et al.             Standards Track                    [Page 15]


RFC 3416              Protocol Operations for SNMP         December 2002


   (1)   The variable which is in the lexicographically ordered list of
         the names of all variables which are accessible by this request
         and whose name is the (i)-th lexicographic successor of the (N
         + r)-th variable binding's name in the incoming
         GetBulkRequest-PDU is located and the variable binding's name
         and value fields are set to the name and value of the located
         variable.

   (2)   If there is no (i)-th lexicographic successor, then the
         corresponding variable binding produced in the Response-PDU has
         its value field set to "endOfMibView", and its name field set
         to either the last lexicographic successor, or if there are no
         lexicographic successors, to the (N + r)-th variable binding's
         name in the request.

   While the maximum number of variable bindings in the Response-PDU is
   bounded by N + (M * R), the response may be generated with a lesser
   number of variable bindings (possibly zero) for either of three
   reasons.

   (1)   If the size of the message encapsulating the Response-PDU
         containing the requested number of variable bindings would be
         greater than either a local constraint or the maximum message
         size of the originator, then the response is generated with a
         lesser number of variable bindings.  This lesser number is the
         ordered set of variable bindings with some of the variable
         bindings at the end of the set removed, such that the size of
         the message encapsulating the Response-PDU is approximately
         equal to but no greater than either a local constraint or the
         maximum message size of the originator.  Note that the number
         of variable bindings removed has no relationship to the values
         of N, M, or R.

   (2)   The response may also be generated with a lesser number of
         variable bindings if for some value of iteration i, such that i
         is greater than zero and less than or equal to M, that all of
         the generated variable bindings have the value field set to
         "endOfMibView".  In this case, the variable bindings may be
         truncated after the (N + (i * R))-th variable binding.

   (3)   In the event that the processing of a request with many
         repetitions requires a significantly greater amount of
         processing time than a normal request, then a command responder
         application may terminate the request with less than the full
         number of repetitions, providing at least one repetition is
         completed.





Presuhn, et al.             Standards Track                    [Page 16]


RFC 3416              Protocol Operations for SNMP         December 2002


   If the processing of any variable binding fails for a reason other
   than listed above, then the Response-PDU is re-formatted with the
   same values in its request-id and variable-bindings fields as the
   received GetBulkRequest-PDU, with the value of its error-status field
   set to "genErr", and the value of its error-index field is set to the
   index of the variable binding in the original request which
   corresponds to the failed variable binding.

   Otherwise, the value of the Response-PDU's error-status field is set
   to "noError", and the value of its error-index field to zero.

   The generated Response-PDU (possibly with an empty variable-bindings
   field) is then encapsulated into a message.  If the size of the
   resultant message is less than or equal to both a local constraint
   and the maximum message size of the originator, it is transmitted to
   the originator of the GetBulkRequest-PDU.  Otherwise, the
   snmpSilentDrops [RFC3418] counter is incremented and the resultant
   message is discarded.

4.2.3.1.  Another Example of Table Traversal

   This example demonstrates how the GetBulkRequest-PDU can be used as
   an alternative to the GetNextRequest-PDU.  The same traversal of the
   IP net-to-media table as shown in Section 4.2.2.1 is achieved with
   fewer exchanges.

   The SNMP entity supporting the command generator application begins
   by sending a GetBulkRequest-PDU with the modest max-repetitions value
   of 2, and containing the indicated OBJECT IDENTIFIER values as the
   requested variable names:

    GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
                  ( sysUpTime,
                    ipNetToMediaPhysAddress,
                    ipNetToMediaType )

   The SNMP entity supporting the command responder application responds
   with a Response-PDU:

    Response (( sysUpTime.0 =  "123456" ),
               ( ipNetToMediaPhysAddress.1.9.2.3.4 = "000010543210" ),
            ( ipNetToMediaType.1.9.2.3.4 =  "dynamic" ),
               ( ipNetToMediaPhysAddress.1.10.0.0.51 = "000010012345" ),
            ( ipNetToMediaType.1.10.0.0.51 =  "static" ))







Presuhn, et al.             Standards Track                    [Page 17]


RFC 3416              Protocol Operations for SNMP         December 2002


   The SNMP entity supporting the command generator application
   continues with:

     GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
                     ( sysUpTime,
                       ipNetToMediaPhysAddress.1.10.0.0.51,
                       ipNetToMediaType.1.10.0.0.51 )

   The SNMP entity supporting the command responder application responds
   with:

    Response (( sysUpTime.0 =  "123466" ),
               ( ipNetToMediaPhysAddress.2.10.0.0.15 = "000010987654" ),
               ( ipNetToMediaType.2.10.0.0.15 = "dynamic" ),
               ( ipNetToMediaNetAddress.1.9.2.3.4 = "9.2.3.4" ),
            ( ipRoutingDiscards.0 =  "2" ))

   Note how, as in the first example, the variable bindings in the
   response indicate that the end of the table has been reached.  The
   fourth variable binding does so by returning information from the
   next available column; the fifth variable binding does so by
   returning information from the first available object
   lexicographically following the table.  This response signals the end
   of the table to the command generator application.

4.2.4.  The Response-PDU

   The Response-PDU is generated by an SNMP entity only upon receipt of
   a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU,
   SetRequest-PDU, or InformRequest-PDU, as described elsewhere in this
   document.

   If the error-status field of the Response-PDU is non-zero, the value
   fields of the variable bindings in the variable binding list are
   ignored.

   If both the error-status field and the error-index field of the
   Response-PDU are non-zero, then the value of the error-index field is
   the index of the variable binding (in the variable-binding list of
   the corresponding request) for which the request failed.  The first
   variable binding in a request's variable-binding list is index one,
   the second is index two, etc.

   A compliant SNMP entity supporting a command generator application
   must be able to properly receive and handle a Response-PDU with an
   error-status field equal to "noSuchName", "badValue", or "readOnly".
   (See sections 1.3 and 4.3 of [RFC2576].)




Presuhn, et al.             Standards Track                    [Page 18]


RFC 3416              Protocol Operations for SNMP         December 2002


   Upon receipt of a Response-PDU, the receiving SNMP entity presents
   its contents to the application which generated the request with the
   same request-id value.  For more details, see [RFC3412].

4.2.5.  The SetRequest-PDU

   A SetRequest-PDU is generated and transmitted at the request of an
   application.

   Upon receipt of a SetRequest-PDU, the receiving SNMP entity
   determines the size of a message encapsulating a Response-PDU having
   the same values in its request-id and variable-bindings fields as the
   received SetRequest-PDU, and the largest possible sizes of the
   error-status and error-index fields.  If the determined message size
   is greater than either a local constraint or the maximum message size
   of the originator, then an alternate Response-PDU is generated,
   transmitted to the originator of the SetRequest-PDU, and processing
   of the SetRequest-PDU terminates immediately thereafter.  This
   alternate Response-PDU is formatted with the same values in its
   request-id field as the received SetRequest-PDU, with the value of
   its error-status field set to "tooBig", the value of its error-index
   field set to zero, and an empty variable-bindings field.  This
   alternate Response-PDU is then encapsulated into a message.  If the
   size of the resultant message is less than or equal to both a local
   constraint and the maximum message size of the originator, it is
   transmitted to the originator of the SetRequest-PDU.  Otherwise, the
   snmpSilentDrops [RFC3418] counter is incremented and the resultant
   message is discarded.  Regardless, processing of the SetRequest-PDU
   terminates.

   Otherwise, the receiving SNMP entity processes each variable binding
   in the variable-binding list to produce a Response-PDU.  All fields
   of the Response-PDU have the same values as the corresponding fields
   of the received request except as indicated below.

   The variable bindings are conceptually processed as a two phase
   operation.  In the first phase, each variable binding is validated;
   if all validations are successful, then each variable is altered in
   the second phase.  Of course, implementors are at liberty to
   implement either the first, or second, or both, of these conceptual
   phases as multiple implementation phases.  Indeed, such multiple
   implementation phases may be necessary in some cases to ensure
   consistency.








Presuhn, et al.             Standards Track                    [Page 19]


RFC 3416              Protocol Operations for SNMP         December 2002


   The following validations are performed in the first phase on each
   variable binding until they are all successful, or until one fails:

   (1)   If the variable binding's name specifies an existing or non-
         existent variable to which this request is/would be denied
         access because it is/would not be in the appropriate MIB view,
         then the value of the Response-PDU's error-status field is set
         to "noAccess", and the value of its error-index field is set to
         the index of the failed variable binding.

   (2)   Otherwise, if there are no variables which share the same
         OBJECT IDENTIFIER prefix as the variable binding's name, and
         which are able to be created or modified no matter what new
         value is specified, then the value of the Response-PDU's
         error-status field is set to "notWritable", and the value of
         its error-index field is set to the index of the failed
         variable binding.

   (3)   Otherwise, if the variable binding's value field specifies,
         according to the ASN.1 language, a type which is inconsistent
         with that required for all variables which share the same
         OBJECT IDENTIFIER prefix as the variable binding's name, then
         the value of the Response-PDU's error-status field is set to
         "wrongType", and the value of its error-index field is set to
         the index of the failed variable binding.

   (4)   Otherwise, if the variable binding's value field specifies,
         according to the ASN.1 language, a length which is inconsistent
         with that required for all variables which share the same
         OBJECT IDENTIFIER prefix as the variable binding's name, then
         the value of the Response-PDU's error-status field is set to
         "wrongLength", and the value of its error-index field is set to
         the index of the failed variable binding.

   (5)   Otherwise, if the variable binding's value field contains an
         ASN.1 encoding which is inconsistent with that field's ASN.1
         tag, then the value of the Response-PDU's error-status field is
         set to "wrongEncoding", and the value of its error-index field
         is set to the index of the failed variable binding.  (Note that
         not all implementation strategies will generate this error.)

   (6)   Otherwise, if the variable binding's value field specifies a
         value which could under no circumstances be assigned to the
         variable, then the value of the Response-PDU's error-status
         field is set to "wrongValue", and the value of its error-index
         field is set to the index of the failed variable binding.





Presuhn, et al.             Standards Track                    [Page 20]


RFC 3416              Protocol Operations for SNMP         December 2002


   (7)   Otherwise, if the variable binding's name specifies a variable
         which does not exist and could not ever be created (even though
         some variables sharing the same OBJECT IDENTIFIER prefix might
         under some circumstances be able to be created), then the value
         of the Response-PDU's error-status field is set to
         "noCreation", and the value of its error-index field is set to
         the index of the failed variable binding.

   (8)   Otherwise, if the variable binding's name specifies a variable
         which does not exist but can not be created under the present
         circumstances (even though it could be created under other
         circumstances), then the value of the Response-PDU's error-
         status field is set to "inconsistentName", and the value of its
         error-index field is set to the index of the failed variable
         binding.

   (9)   Otherwise, if the variable binding's name specifies a variable
         which exists but can not be modified no matter what new value
         is specified, then the value of the Response-PDU's error-status
         field is set to "notWritable", and the value of its error-index
         field is set to the index of the failed variable binding.

   (10)  Otherwise, if the variable binding's value field specifies a
         value that could under other circumstances be held by the
         variable, but is presently inconsistent or otherwise unable to
         be assigned to the variable, then the value of the Response-
         PDU's error-status field is set to "inconsistentValue", and the
         value of its error-index field is set to the index of the
         failed variable binding.

   (11)  When, during the above steps, the assignment of the value
         specified by the variable binding's value field to the
         specified variable requires the allocation of a resource which
         is presently unavailable, then the value of the Response-PDU's
         error-status field is set to "resourceUnavailable", and the
         value of its error-index field is set to the index of the
         failed variable binding.

   (12)  If the processing of the variable binding fails for a reason
         other than listed above, then the value of the Response-PDU's
         error-status field is set to "genErr", and the value of its
         error-index field is set to the index of the failed variable
         binding.

   (13)  Otherwise, the validation of the variable binding succeeds.






Presuhn, et al.             Standards Track                    [Page 21]


RFC 3416              Protocol Operations for SNMP         December 2002


   At the end of the first phase, if the validation of all variable
   bindings succeeded, then the value of the Response-PDU's error-status
   field is set to "noError" and the value of its error-index field is
   zero, and processing continues as follows.

   For each variable binding in the request, the named variable is
   created if necessary, and the specified value is assigned to it.
   Each of these variable assignments occurs as if simultaneously with
   respect to all other assignments specified in the same request.
   However, if the same variable is named more than once in a single
   request, with different associated values, then the actual assignment
   made to that variable is implementation-specific.

   If any of these assignments fail (even after all the previous
   validations), then all other assignments are undone, and the
   Response-PDU is modified to have the value of its error-status field
   set to "commitFailed", and the value of its error-index field set to
   the index of the failed variable binding.

   If and only if it is not possible to undo all the assignments, then
   the Response-PDU is modified to have the value of its error-status
   field set to "undoFailed", and the value of its error-index field is
   set to zero.  Note that implementations are strongly encouraged to
   take all possible measures to avoid use of either "commitFailed" or
   "undoFailed" - these two error-status codes are not to be taken as
   license to take the easy way out in an implementation.

   Finally, the generated Response-PDU is encapsulated into a message,
   and transmitted to the originator of the SetRequest-PDU.

4.2.6.  The SNMPv2-Trap-PDU

   An SNMPv2-Trap-PDU is generated and transmitted by an SNMP entity on
   behalf of a notification originator application.  The SNMPv2-Trap-PDU
   is often used to notify a notification receiver application at a
   logically remote SNMP entity that an event has occurred or that a
   condition is present.  There is no confirmation associated with this
   notification delivery mechanism.

   The destination(s) to which an SNMPv2-Trap-PDU is sent is determined
   in an implementation-dependent fashion by the SNMP entity.  The first
   two variable bindings in the variable binding list of an SNMPv2-
   Trap-PDU are sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418]
   respectively.  If the OBJECTS clause is present in the invocation of
   the corresponding NOTIFICATION-TYPE macro, then each corresponding
   variable, as instantiated by this notification, is copied, in order,





Presuhn, et al.             Standards Track                    [Page 22]


RFC 3416              Protocol Operations for SNMP         December 2002


   to the variable-bindings field.  If any additional variables are
   being included (at the option of the generating SNMP entity), then
   each is copied to the variable-bindings field.

4.2.7.  The InformRequest-PDU

   An InformRequest-PDU is generated and transmitted by an SNMP entity
   on behalf of a notification originator application.  The
   InformRequest-PDU is often used to notify a notification receiver
   application that an event has occurred or that a condition is
   present.  This is a confirmed notification delivery mechanism,
   although there is, of course, no guarantee of delivery.

   The destination(s) to which an InformRequest-PDU is sent is specified
   by the notification originator application.  The first two variable
   bindings in the variable binding list of an InformRequest-PDU are
   sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418] respectively.  If
   the OBJECTS clause is present in the invocation of the corresponding
   NOTIFICATION-TYPE macro, then each corresponding variable, as
   instantiated by this notification, is copied, in order, to the
   variable-bindings field.  If any additional variables are being
   included (at the option of the generating SNMP entity), then each is
   copied to the variable-bindings field.

   Upon receipt of an InformRequest-PDU, the receiving SNMP entity
   determines the size of a message encapsulating a Response-PDU with
   the same values in its request-id, error-status, error-index and
   variable-bindings fields as the received InformRequest-PDU.  If the
   determined message size is greater than either a local constraint or
   the maximum message size of the originator, then an alternate
   Response-PDU is generated, transmitted to the originator of the
   InformRequest-PDU, and processing of the InformRequest-PDU terminates
   immediately thereafter.  This alternate Response-PDU is formatted
   with the same values in its request-id field as the received
   InformRequest-PDU, with the value of its error-status field set to
   "tooBig", the value of its error-index field set to zero, and an
   empty variable-bindings field.  This alternate Response-PDU is then
   encapsulated into a message.  If the size of the resultant message is
   less than or equal to both a local constraint and the maximum message
   size of the originator, it is transmitted to the originator of the
   InformRequest-PDU.  Otherwise, the snmpSilentDrops [RFC3418] counter
   is incremented and the resultant message is discarded.  Regardless,
   processing of the InformRequest-PDU terminates.

   Otherwise, the receiving SNMP entity:

   (1)   presents its contents to the appropriate application;




Presuhn, et al.             Standards Track                    [Page 23]


RFC 3416              Protocol Operations for SNMP         December 2002


   (2)   generates a Response-PDU with the same values in its request-id
         and variable-bindings fields as the received InformRequest-PDU,
         with the value of its error-status field set to "noError" and
         the value of its error-index field set to zero; and

   (3)   transmits the generated Response-PDU to the originator of the
         InformRequest-PDU.

5.  Notice on Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

6.  Acknowledgments

   This document is the product of the SNMPv3 Working Group.  Some
   special thanks are in order to the following Working Group members:

      Randy Bush
      Jeffrey D. Case
      Mike Daniele
      Rob Frye
      Lauren Heintz
      Keith McCloghrie
      Russ Mundy
      David T. Perkins
      Randy Presuhn
      Aleksey Romanov
      Juergen Schoenwaelder
      Bert Wijnen




Presuhn, et al.             Standards Track                    [Page 24]


RFC 3416              Protocol Operations for SNMP         December 2002


   This version of the document, edited by Randy Presuhn, was initially
   based on the work of a design team whose members were:

      Jeffrey D. Case
      Keith McCloghrie
      David T. Perkins
      Randy Presuhn
      Juergen Schoenwaelder

   The previous versions of this document, edited by Keith McCloghrie,
   was the result of significant work by four major contributors:

      Jeffrey D. Case
      Keith McCloghrie
      Marshall T. Rose
      Steven Waldbusser

   Additionally, the contributions of the SNMPv2 Working Group to the
   previous versions are also acknowledged.  In particular, a special
   thanks is extended for the contributions of:

      Alexander I. Alten
      Dave Arneson
      Uri Blumenthal
      Doug Book
      Kim Curran
      Jim Galvin
      Maria Greene
      Iain Hanson
      Dave Harrington
      Nguyen Hien
      Jeff Johnson
      Michael Kornegay
      Deirdre Kostick
      David Levi
      Daniel Mahoney
      Bob Natale
      Brian O'Keefe
      Andrew Pearson
      Dave Perkins
      Randy Presuhn
      Aleksey Romanov
      Shawn Routhier
      Jon Saperia
      Juergen Schoenwaelder
      Bob Stewart





Presuhn, et al.             Standards Track                    [Page 25]


RFC 3416              Protocol Operations for SNMP         December 2002


      Kaj Tesink
      Glenn Waters
      Bert Wijnen

7.  Security Considerations

   The protocol defined in this document by itself does not provide a
   secure environment.  Even if the network itself is secure (for
   example by using IPSec), there is no control as to who on the secure
   network is allowed access to management information.

   It is recommended that the implementors consider the security
   features as provided by the SNMPv3 framework.  Specifically, the use
   of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the
   View-based Access Control Model STD 62, RFC 3415 [RFC3415] is
   recommended.

   It is then a customer/user responsibility to ensure that the SNMP
   entity is properly configured so that:

      -  only those principals (users) having legitimate rights can
         access or modify the values of any MIB objects supported by
         that entity;

      -  the occurrence of particular events on the entity will be
         communicated appropriately;

      -  the entity responds appropriately and with due credence to
         events and information that have been communicated to it.

8.  References

8.1.  Normative References

   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
               August 1980.

   [RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Structure of Management
               Information Version 2 (SMIv2)", STD 58, RFC 2578, April
               1999.

   [RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Textual Conventions for
               SMIv2", STD 58, RFC 2579, April 1999.






Presuhn, et al.             Standards Track                    [Page 26]


RFC 3416              Protocol Operations for SNMP         December 2002


   [RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Conformance Statements for
               SMIv2", STD 58, RFC 2580, April 1999.

   [RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An
               Architecture for Describing Simple Network Management
               Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
               December 2002.

   [RFC3412]   Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
               "Message Processing and Dispatching for the Simple
               Network Management Protocol (SNMP)", STD 62, RFC 3412,
               December 2002.

   [RFC3413]   Levi, D., Meyer, P. and B. Stewart, "Simple Network
               Management Protocol (SNMP) Applications", STD 62, RFC
               3413, December 2002.

   [RFC3414]   Blumenthal, U. and B. Wijnen, "The User-Based Security
               Model (USM) for Version 3 of the Simple Network
               Management Protocol (SNMPv3)", STD 62, RFC 3414, December
               2002.

   [RFC3415]   Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model (VACM) for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3415, December
               2002.

   [RFC3417]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
               Waldbusser, "Transport Mappings for the Simple Network
               Management Protocol", STD 62, RFC 3417, December 2002.

   [RFC3418]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
               Waldbusser, "Management Information Base (MIB) for the
               Simple Network Management Protocol (SNMP)", STD 62, RFC
               3418, December 2002.

   [ASN1]      Information processing systems - Open Systems
               Interconnection - Specification of Abstract Syntax
               Notation One (ASN.1), International Organization for
               Standardization.  International Standard 8824, December
               1987.

8.2.  Informative References

   [FRAG]      Kent, C. and J. Mogul, "Fragmentation Considered
               Harmful," Proceedings, ACM SIGCOMM '87, Stowe, VT, August
               1987.



Presuhn, et al.             Standards Track                    [Page 27]


RFC 3416              Protocol Operations for SNMP         December 2002


   [RFC1155]   Rose, M. and K. McCloghrie, "Structure and Identification
               of Management Information for TCP/IP-based Internets",
               STD 16, RFC 1155, May 1990.

   [RFC1157]   Case, J., Fedor, M., Schoffstall, M. and J. Davin,
               "Simple Network Management Protocol", STD 15, RFC 1157,
               May 1990.

   [RFC1212]   Rose, M. and K. McCloghrie, "Concise MIB Definitions",
               STD 16, RFC 1212, March 1991.

   [RFC1213]   McCloghrie, K. and M. Rose, Editors, "Management
               Information Base for Network Management of TCP/IP-based
               internets: MIB-II", STD 17, RFC 1213, March 1991.

   [RFC1215]   Rose, M., "A Convention for Defining Traps for use with
               the SNMP", RFC 1215, March 1991.

   [RFC1901]   Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
               "Introduction to Community-based SNMPv2", RFC 1901,
               January 1996.

   [RFC2576]   Frye, R., Levi, D., Routhier, S. and B. Wijnen,
               "Coexistence between Version 1, Version 2, and Version 3
               of the Internet-Standard Network Management Framework",
               RFC 2576, March 2000.

   [RFC2863]   McCloghrie, K. and F. Kastenholz, "The Interfaces Group
               MIB", RFC 2863, June 2000.

   [RFC2914]   Floyd, S., "Congestion Control Principles", BCP 41, RFC
               2914, September 2000.

   [RFC3410]   Case, J., Mundy, R., Partain, D. and B. Stewart,
               "Introduction and Applicability Statements for Internet-
               Standard Management Framework", RFC 3410, December 2002.

9.  Changes from RFC 1905

   These are the changes from RFC 1905:

      -  Corrected spelling error in copyright statement;

      -  Updated copyright date;

      -  Updated with new editor's name and contact information;

      -  Added notice on intellectual property;



Presuhn, et al.             Standards Track                    [Page 28]


RFC 3416              Protocol Operations for SNMP         December 2002


      -  Cosmetic fixes to layout and typography;

      -  Added table of contents;

      -  Title changed;

      -  Updated document headers and footers;

      -  Deleted the old clause 2.3, entitled "Access to Management
         Information";

      -  Changed the way in which request-id was defined, though with
         the same ultimate syntax and semantics, to avoid coupling with
         SMI.  This does not affect the protocol in any way;

      -  Replaced the word "exception" with the word "error" in the old
         clause 4.1.  This does not affect the protocol in any way;

      -  Deleted the first two paragraphs of the old clause 4.2;

      -  Clarified the maximum number of variable bindings that an
         implementation must support in a PDU.  This does not affect the
         protocol in any way;

      -  Replaced occurrences of "SNMPv2 application" with
         "application";

      -  Deleted three sentences in old clause 4.2.3 describing the
         handling of an impossible situation.  This does not affect the
         protocol in any way;

      -  Clarified the use of the SNMPv2-Trap-Pdu in the old clause
         4.2.6.  This does not affect the protocol in any way;

      -  Aligned description of the use of the InformRequest-Pdu in old
         clause 4.2.7 with the architecture.  This does not affect the
         protocol in any way;

      -  Updated references;

      -  Re-wrote introduction clause;

      -  Replaced manager/agent/SNMPv2 entity terminology with
         terminology from RFC 2571.  This does not affect the protocol
         in any way;

      -  Eliminated IMPORTS from the SMI, replaced with equivalent in-
         line ASN.1.  This does not affect the protocol in any way;



Presuhn, et al.             Standards Track                    [Page 29]


RFC 3416              Protocol Operations for SNMP         December 2002


      -  Added notes calling attention to two different manifestations
         of reaching the end of a table in the table walk examples;

      -  Added content to security considerations clause;

      -  Updated ASN.1 comment on use of Report-PDU.  This does not
         affect the protocol in any way;

      -  Updated acknowledgments section;

      -  Included information on handling of BITS;

      -  Deleted spurious comma in ASN.1 definition of PDUs;

      -  Added abstract;

      -  Made handling of additional variable bindings in informs
         consistent with that for traps.  This was a correction of an
         editorial oversight, and reflects implementation practice;

      -  Added reference to RFC 2914.

10.  Editor's Address

   Randy Presuhn
   BMC Software, Inc.
   2141 North First Street
   San Jose, CA  95131
   USA

   Phone: +1 408 546 1006
   EMail: randy_presuhn@bmc.com



















Presuhn, et al.             Standards Track                    [Page 30]


RFC 3416              Protocol Operations for SNMP         December 2002


11.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Presuhn, et al.             Standards Track                    [Page 31]

=========================================================================






Network Working Group                            Editor of this version:
Request for Comments: 3417                                    R. Presuhn
STD: 62                                               BMC Software, Inc.
Obsoletes: 1906                             Authors of previous version:
Category: Standards Track                                        J. Case
                                                     SNMP Research, Inc.
                                                           K. McCloghrie
                                                     Cisco Systems, Inc.
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                           S. Waldbusser
                                          International Network Services
                                                           December 2002


                         Transport Mappings for
             the Simple Network Management Protocol (SNMP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document defines the transport of Simple Network Management
   Protocol (SNMP) messages over various protocols.  This document
   obsoletes RFC 1906.
















Presuhn, et al.             Standards Track                     [Page 1]


RFC 3417              Transport Mappings for SNMP          December 2002


Table of Contents

   1. Introduction ................................................    2
   2. Definitions .................................................    3
   3. SNMP over UDP over IPv4 .....................................    7
   3.1. Serialization .............................................    7
   3.2. Well-known Values .........................................    7
   4. SNMP over OSI ...............................................    7
   4.1. Serialization .............................................    7
   4.2. Well-known Values .........................................    8
   5. SNMP over DDP ...............................................    8
   5.1. Serialization .............................................    8
   5.2. Well-known Values .........................................    8
   5.3. Discussion of AppleTalk Addressing ........................    9
   5.3.1. How to Acquire NBP names ................................    9
   5.3.2. When to Turn NBP names into DDP addresses ...............   10
   5.3.3. How to Turn NBP names into DDP addresses ................   10
   5.3.4. What if NBP is broken ...................................   10
   6. SNMP over IPX ...............................................   11
   6.1. Serialization .............................................   11
   6.2. Well-known Values .........................................   11
   7. Proxy to SNMPv1 .............................................   12
   8. Serialization using the Basic Encoding Rules ................   12
   8.1. Usage Example .............................................   13
   9. Notice on Intellectual Property .............................   14
   10. Acknowledgments ............................................   14
   11. IANA Considerations ........................................   15
   12. Security Considerations ....................................   16
   13. References .................................................   16
   13.1. Normative References .....................................   16
   13.2. Informative References ...................................   17
   14. Changes from RFC 1906 ......................................   18
   15. Editor's Address ...........................................   18
   16. Full Copyright Statement ...................................   19

1.  Introduction

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB





Presuhn, et al.             Standards Track                     [Page 2]


RFC 3417              Transport Mappings for SNMP          December 2002


   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

   This document, Transport Mappings for the Simple Network Management
   Protocol, defines how the management protocol [RFC3416] may be
   carried over a variety of protocol suites.  It is the purpose of this
   document to define how the SNMP maps onto an initial set of transport
   domains.  At the time of this writing, work was in progress to define
   an IPv6 mapping, described in [RFC3419].  Other mappings may be
   defined in the future.

   Although several mappings are defined, the mapping onto UDP over IPv4
   is the preferred mapping for systems supporting IPv4.  Systems
   implementing IPv4 MUST implement the mapping onto UDP over IPv4.  To
   maximize interoperability, systems supporting other mappings SHOULD
   also provide for access via the UDP over IPv4 mapping.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

2.  Definitions

   SNMPv2-TM DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-IDENTITY,
       snmpModules, snmpDomains, snmpProxys
           FROM SNMPv2-SMI
       TEXTUAL-CONVENTION
           FROM SNMPv2-TC;

   snmpv2tm MODULE-IDENTITY
       LAST-UPDATED "200210160000Z"
       ORGANIZATION "IETF SNMPv3 Working Group"
       CONTACT-INFO
               "WG-EMail:   snmpv3@lists.tislabs.com
                Subscribe:  snmpv3-request@lists.tislabs.com

                Co-Chair:   Russ Mundy
                            Network Associates Laboratories
                postal:     15204 Omega Drive, Suite 300
                            Rockville, MD 20850-4601
                            USA
                EMail:      mundy@tislabs.com
                phone:      +1 301 947-7107



Presuhn, et al.             Standards Track                     [Page 3]


RFC 3417              Transport Mappings for SNMP          December 2002


                Co-Chair:   David Harrington
                            Enterasys Networks
                postal:     35 Industrial Way
                            P. O. Box 5005
                            Rochester, NH 03866-5005
                            USA
                EMail:      dbh@enterasys.com
                phone:      +1 603 337-2614

                Editor:     Randy Presuhn
                            BMC Software, Inc.
                postal:     2141 North First Street
                            San Jose, CA 95131
                            USA
                EMail:      randy_presuhn@bmc.com
                phone:      +1 408 546-1006"
       DESCRIPTION
               "The MIB module for SNMP transport mappings.

                Copyright (C) The Internet Society (2002). This
                version of this MIB module is part of RFC 3417;
                see the RFC itself for full legal notices.
               "
       REVISION     "200210160000Z"
       DESCRIPTION
               "Clarifications, published as RFC 3417."
       REVISION    "199601010000Z"
       DESCRIPTION
               "Clarifications, published as RFC 1906."
       REVISION    "199304010000Z"
       DESCRIPTION
               "The initial version, published as RFC 1449."
       ::= { snmpModules 19 }

   -- SNMP over UDP over IPv4

   snmpUDPDomain  OBJECT-IDENTITY
       STATUS     current
       DESCRIPTION
               "The SNMP over UDP over IPv4 transport domain.
               The corresponding transport address is of type
               SnmpUDPAddress."
       ::= { snmpDomains 1 }








Presuhn, et al.             Standards Track                     [Page 4]


RFC 3417              Transport Mappings for SNMP          December 2002


   SnmpUDPAddress ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "1d.1d.1d.1d/2d"
       STATUS       current
       DESCRIPTION
               "Represents a UDP over IPv4 address:

                  octets   contents        encoding
                   1-4     IP-address      network-byte order
                   5-6     UDP-port        network-byte order
               "
       SYNTAX       OCTET STRING (SIZE (6))

   -- SNMP over OSI

   snmpCLNSDomain OBJECT-IDENTITY
       STATUS     current
       DESCRIPTION
               "The SNMP over CLNS transport domain.
               The corresponding transport address is of type
               SnmpOSIAddress."
       ::= { snmpDomains 2 }

   snmpCONSDomain OBJECT-IDENTITY
       STATUS     current
       DESCRIPTION
               "The SNMP over CONS transport domain.
               The corresponding transport address is of type
               SnmpOSIAddress."
       ::= { snmpDomains 3 }

   SnmpOSIAddress ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "*1x:/1x:"
       STATUS       current
       DESCRIPTION
               "Represents an OSI transport-address:

             octets   contents           encoding
                1     length of NSAP     'n' as an unsigned-integer
                                            (either 0 or from 3 to 20)
             2..(n+1) NSAP                concrete binary representation
             (n+2)..m TSEL                string of (up to 64) octets
               "
       SYNTAX       OCTET STRING (SIZE (1 | 4..85))








Presuhn, et al.             Standards Track                     [Page 5]


RFC 3417              Transport Mappings for SNMP          December 2002


   -- SNMP over DDP

   snmpDDPDomain  OBJECT-IDENTITY
       STATUS     current
       DESCRIPTION
               "The SNMP over DDP transport domain.  The corresponding
               transport address is of type SnmpNBPAddress."
       ::= { snmpDomains 4 }

   SnmpNBPAddress ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
               "Represents an NBP name:

            octets        contents          encoding
               1          length of object  'n' as an unsigned integer
             2..(n+1)     object            string of (up to 32) octets
              n+2         length of type    'p' as an unsigned integer
         (n+3)..(n+2+p)   type              string of (up to 32) octets
             n+3+p        length of zone    'q' as an unsigned integer
       (n+4+p)..(n+3+p+q) zone              string of (up to 32) octets

               For comparison purposes, strings are
               case-insensitive. All strings may contain any octet
               other than 255 (hex ff)."
       SYNTAX       OCTET STRING (SIZE (3..99))

   -- SNMP over IPX

   snmpIPXDomain  OBJECT-IDENTITY
       STATUS     current
       DESCRIPTION
               "The SNMP over IPX transport domain.  The corresponding
               transport address is of type SnmpIPXAddress."
       ::= { snmpDomains 5 }

   SnmpIPXAddress ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
       STATUS       current
       DESCRIPTION
               "Represents an IPX address:

                  octets   contents            encoding
                   1-4     network-number      network-byte order
                   5-10    physical-address    network-byte order
                  11-12    socket-number       network-byte order
               "
       SYNTAX       OCTET STRING (SIZE (12))



Presuhn, et al.             Standards Track                     [Page 6]


RFC 3417              Transport Mappings for SNMP          December 2002


   -- for proxy to SNMPv1 (RFC 1157)

   rfc1157Proxy   OBJECT IDENTIFIER ::= { snmpProxys 1 }

   rfc1157Domain  OBJECT-IDENTITY
       STATUS     deprecated
       DESCRIPTION
               "The transport domain for SNMPv1 over UDP over IPv4.
               The corresponding transport address is of type
               SnmpUDPAddress."
       ::= { rfc1157Proxy 1 }

   --  ::= { rfc1157Proxy 2 }            this OID is obsolete

   END

3.  SNMP over UDP over IPv4

   This is the preferred transport mapping.

3.1.  Serialization

   Each instance of a message is serialized (i.e., encoded according to
   the convention of [BER]) onto a single UDP [RFC768] over IPv4
   [RFC791] datagram, using the algorithm specified in Section 8.

3.2.  Well-known Values

   It is suggested that administrators configure their SNMP entities
   supporting command responder applications to listen on UDP port 161.
   Further, it is suggested that SNMP entities supporting notification
   receiver applications be configured to listen on UDP port 162.

   When an SNMP entity uses this transport mapping, it must be capable
   of accepting messages up to and including 484 octets in size.  It is
   recommended that implementations be capable of accepting messages of
   up to 1472 octets in size.  Implementation of larger values is
   encouraged whenever possible.

4.  SNMP over OSI

   This is an optional transport mapping.

4.1.  Serialization

   Each instance of a message is serialized onto a single TSDU [IS8072]
   [IS8072A] for the OSI Connectionless-mode Transport Service (CLTS),
   using the algorithm specified in Section 8.



Presuhn, et al.             Standards Track                     [Page 7]


RFC 3417              Transport Mappings for SNMP          December 2002


4.2.  Well-known Values

   It is suggested that administrators configure their SNMP entities
   supporting command responder applications to listen on transport
   selector "snmp-l" (which consists of six ASCII characters), when
   using a CL-mode network service to realize the CLTS.  Further, it is
   suggested that SNMP entities supporting notification receiver
   applications be configured to listen on transport selector "snmpt-l"
   (which consists of seven ASCII characters, six letters and a hyphen)
   when using a CL-mode network service to realize the CLTS.  Similarly,
   when using a CO-mode network service to realize the CLTS, the
   suggested transport selectors are "snmp-o" and "snmpt-o", for command
   responders and notification receivers, respectively.

   When an SNMP entity uses this transport mapping, it must be capable
   of accepting messages that are at least 484 octets in size.
   Implementation of larger values is encouraged whenever possible.

5.  SNMP over DDP

   This is an optional transport mapping.

5.1.  Serialization

   Each instance of a message is serialized onto a single DDP datagram
   [APPLETALK], using the algorithm specified in Section 8.

5.2.  Well-known Values

   SNMP messages are sent using DDP protocol type 8.  SNMP entities
   supporting command responder applications listen on DDP socket number
   8, while SNMP entities supporting notification receiver applications
   listen on DDP socket number 9.

   Administrators must configure their SNMP entities supporting command
   responder applications to use NBP type "SNMP Agent" (which consists
   of ten ASCII characters) while those supporting notification receiver
   applications must be configured to use NBP type "SNMP Trap Handler"
   (which consists of seventeen ASCII characters).

   The NBP name for SNMP entities supporting command responders and
   notification receivers should be stable - NBP names should not change
   any more often than the IP address of a typical TCP/IP node.  It is
   suggested that the NBP name be stored in some form of stable storage.

   When an SNMP entity uses this transport mapping, it must be capable
   of accepting messages that are at least 484 octets in size.
   Implementation of larger values is encouraged whenever possible.



Presuhn, et al.             Standards Track                     [Page 8]


RFC 3417              Transport Mappings for SNMP          December 2002


5.3.  Discussion of AppleTalk Addressing

   The AppleTalk protocol suite has certain features not manifest in the
   TCP/IP suite.  AppleTalk's naming strategy and the dynamic nature of
   address assignment can cause problems for SNMP entities that wish to
   manage AppleTalk networks.  TCP/IP nodes have an associated IP
   address which distinguishes each from the other.  In contrast,
   AppleTalk nodes generally have no such characteristic.  The network-
   level address, while often relatively stable, can change at every
   reboot (or more frequently).

   Thus, when SNMP is mapped over DDP, nodes are identified by a "name",
   rather than by an "address".  Hence, all AppleTalk nodes that
   implement this mapping are required to respond to NBP lookups and
   confirms (e.g., implement the NBP protocol stub), which guarantees
   that a mapping from NBP name to DDP address will be possible.

   In determining the SNMP identity to register for an SNMP entity, it
   is suggested that the SNMP identity be a name which is associated
   with other network services offered by the machine.

   NBP lookups, which are used to map NBP names into DDP addresses, can
   cause large amounts of network traffic as well as consume CPU
   resources.  It is also the case that the ability to perform an NBP
   lookup is sensitive to certain network disruptions (such as zone
   table inconsistencies) which would not prevent direct AppleTalk
   communications between two SNMP entities.

   Thus, it is recommended that NBP lookups be used infrequently,
   primarily to create a cache of name-to-address mappings.  These
   cached mappings should then be used for any further SNMP traffic.  It
   is recommended that SNMP entities supporting command generator
   applications should maintain this cache between reboots.  This
   caching can help minimize network traffic, reduce CPU load on the
   network, and allow for (some amount of) network trouble shooting when
   the basic name-to-address translation mechanism is broken.

5.3.1.  How to Acquire NBP names

   An SNMP entity supporting command generator applications may have a
   pre-configured list of names of "known" SNMP entities supporting
   command responder applications.  Similarly, an SNMP entity supporting
   command generator or notification receiver applications might
   interact with an operator.  Finally, an SNMP entity supporting
   command generator or notification receiver applications might
   communicate with all SNMP entities supporting command responder or
   notification originator applications in a set of zones or networks.




Presuhn, et al.             Standards Track                     [Page 9]


RFC 3417              Transport Mappings for SNMP          December 2002


5.3.2.  When to Turn NBP names into DDP addresses

   When an SNMP entity uses a cache entry to address an SNMP packet, it
   should attempt to confirm the validity mapping, if the mapping hasn't
   been confirmed within the last T1 seconds.  This cache entry
   lifetime, T1, has a minimum, default value of 60 seconds, and should
   be configurable.

   An SNMP entity supporting a command generator application may decide
   to prime its cache of names prior to actually communicating with
   another SNMP entity.  In general, it is expected that such an entity
   may want to keep certain mappings "more current" than other mappings,
   e.g., those nodes which represent the network infrastructure (e.g.,
   routers) may be deemed "more important".

   Note that an SNMP entity supporting command generator applications
   should not prime its entire cache upon initialization - rather, it
   should attempt resolutions over an extended period of time (perhaps
   in some pre-determined or configured priority order).  Each of these
   resolutions might, in fact, be a wildcard lookup in a given zone.

   An SNMP entity supporting command responder applications must never
   prime its cache.  When generating a response, such an entity does not
   need to confirm a cache entry.  An SNMP entity supporting
   notification originator applications should do NBP lookups (or
   confirms) only when it needs to send an SNMP trap or inform.

5.3.3.  How to Turn NBP names into DDP addresses

   If the only piece of information available is the NBP name, then an
   NBP lookup should be performed to turn that name into a DDP address.
   However, if there is a piece of stale information, it can be used as
   a hint to perform an NBP confirm (which sends a unicast to the
   network address which is presumed to be the target of the name
   lookup) to see if the stale information is, in fact, still valid.

   An NBP name to DDP address mapping can also be confirmed implicitly
   using only SNMP transactions.  For example, an SNMP entity supporting
   command generator applications issuing a retrieval operation could
   also retrieve the relevant objects from the NBP group [RFC1742] for
   the SNMP entity supporting the command responder application.  This
   information can then be correlated with the source DDP address of the
   response.

5.3.4.  What if NBP is broken

   Under some circumstances, there may be connectivity between two SNMP
   entities, but the NBP mapping machinery may be broken, e.g.,



Presuhn, et al.             Standards Track                    [Page 10]


RFC 3417              Transport Mappings for SNMP          December 2002


   o  the NBP FwdReq (forward NBP lookup onto local attached network)
      mechanism might be broken at a router on the other entity's
      network; or,

   o  the NBP BrRq (NBP broadcast request) mechanism might be broken at
      a router on the entity's own network; or,

   o  NBP might be broken on the other entity's node.

   An SNMP entity supporting command generator applications which is
   dedicated to AppleTalk management might choose to alleviate some of
   these failures by directly implementing the router portion of NBP.
   For example, such an entity might already know all the zones on the
   AppleTalk internet and the networks on which each zone appears.
   Given an NBP lookup which fails, the entity could send an NBP FwdReq
   to the network in which the SNMP entity supporting the command
   responder or notification originator application was last located.
   If that failed, the station could then send an NBP LkUp (NBP lookup
   packet) as a directed (DDP) multicast to each network number on that
   network.  Of the above (single) failures, this combined approach will
   solve the case where either the local router's BrRq-to-FwdReq
   mechanism is broken or the remote router's FwdReq-to-LkUp mechanism
   is broken.

6.  SNMP over IPX

   This is an optional transport mapping.

6.1.  Serialization

   Each instance of a message is serialized onto a single IPX datagram
   [NOVELL], using the algorithm specified in Section 8.

6.2.  Well-known Values

   SNMP messages are sent using IPX packet type 4 (i.e., Packet Exchange
   Protocol).

   It is suggested that administrators configure their SNMP entities
   supporting command responder applications to listen on IPX socket
   36879 (900f hexadecimal).  Further, it is suggested that those
   supporting notification receiver applications be configured to listen
   on IPX socket 36880 (9010 hexadecimal).

   When an SNMP entity uses this transport mapping, it must be capable
   of accepting messages that are at least 546 octets in size.
   Implementation of larger values is encouraged whenever possible.




Presuhn, et al.             Standards Track                    [Page 11]


RFC 3417              Transport Mappings for SNMP          December 2002


7.  Proxy to SNMPv1

   Historically, in order to support proxy to SNMPv1, as defined in
   [RFC2576], it was deemed useful to define a transport domain,
   rfc1157Domain, which indicates the transport mapping for SNMP
   messages as defined in [RFC1157].

8.  Serialization using the Basic Encoding Rules

   When the Basic Encoding Rules [BER] are used for serialization:

   (1)   When encoding the length field, only the definite form is used;
         use of the indefinite form encoding is prohibited.  Note that
         when using the definite-long form, it is permissible to use
         more than the minimum number of length octets necessary to
         encode the length field.

   (2)   When encoding the value field, the primitive form shall be used
         for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT
         IDENTIFIER (either IMPLICIT or explicit).  The constructed form
         of encoding shall be used only for structured types, i.e., a
         SEQUENCE or an IMPLICIT SEQUENCE.

   (3)   When encoding an object whose syntax is described using the
         BITS construct, the value is encoded as an OCTET STRING, in
         which all the named bits in (the definition of) the bitstring,
         commencing with the first bit and proceeding to the last bit,
         are placed in bits 8 (high order bit) to 1 (low order bit) of
         the first octet, followed by bits 8 to 1 of each subsequent
         octet in turn, followed by as many bits as are needed of the
         final subsequent octet, commencing with bit 8.  Remaining bits,
         if any, of the final octet are set to zero on generation and
         ignored on receipt.

   These restrictions apply to all aspects of ASN.1 encoding, including
   the message wrappers, protocol data units, and the data objects they
   contain.














Presuhn, et al.             Standards Track                    [Page 12]


RFC 3417              Transport Mappings for SNMP          December 2002


8.1.  Usage Example

   As an example of applying the Basic Encoding Rules, suppose one
   wanted to encode an instance of the GetBulkRequest-PDU [RFC3416]:

     [5] IMPLICIT SEQUENCE {
             request-id      1414684022,
             non-repeaters   1,
             max-repetitions 2,
             variable-bindings {
                 { name sysUpTime,
                   value { unSpecified NULL } },
                 { name ipNetToMediaPhysAddress,
                   value { unSpecified NULL } },
                 { name ipNetToMediaType,
                   value { unSpecified NULL } }
             }
         }

   Applying the BER, this may be encoded (in hexadecimal) as:

   [5] IMPLICIT SEQUENCE          a5 82 00 39
       INTEGER                    02 04 54 52 5d 76
       INTEGER                    02 01 01
       INTEGER                    02 01 02
       SEQUENCE (OF)              30 2b
           SEQUENCE               30 0b
               OBJECT IDENTIFIER  06 07 2b 06 01 02 01 01 03
               NULL               05 00
           SEQUENCE               30 0d
               OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 02
               NULL               05 00
           SEQUENCE               30 0d
               OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 04
               NULL               05 00

   Note that the initial SEQUENCE in this example was not encoded using
   the minimum number of length octets.  (The first octet of the length,
   82, indicates that the length of the content is encoded in the next
   two octets.)











Presuhn, et al.             Standards Track                    [Page 13]


RFC 3417              Transport Mappings for SNMP          December 2002


9.  Notice on Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

10.  Acknowledgments

   This document is the product of the SNMPv3 Working Group.  Some
   special thanks are in order to the following Working Group members:

      Randy Bush
      Jeffrey D. Case
      Mike Daniele
      Rob Frye
      Lauren Heintz
      Keith McCloghrie
      Russ Mundy
      David T. Perkins
      Randy Presuhn
      Aleksey Romanov
      Juergen Schoenwaelder
      Bert Wijnen

   This version of the document, edited by Randy Presuhn, was initially
   based on the work of a design team whose members were:

      Jeffrey D. Case
      Keith McCloghrie
      David T. Perkins
      Randy Presuhn
      Juergen Schoenwaelder



Presuhn, et al.             Standards Track                    [Page 14]


RFC 3417              Transport Mappings for SNMP          December 2002


   The previous versions of this document, edited by Keith McCloghrie,
   was the result of significant work by four major contributors:

      Jeffrey D. Case
      Keith McCloghrie
      Marshall T. Rose
      Steven Waldbusser

   Additionally, the contributions of the SNMPv2 Working Group to the
   previous versions are also acknowledged.  In particular, a special
   thanks is extended for the contributions of:

      Alexander I. Alten
      Dave Arneson
      Uri Blumenthal
      Doug Book
      Kim Curran
      Jim Galvin
      Maria Greene
      Iain Hanson
      Dave Harrington
      Nguyen Hien
      Jeff Johnson
      Michael Kornegay
      Deirdre Kostick
      David Levi
      Daniel Mahoney
      Bob Natale
      Brian O'Keefe
      Andrew Pearson
      Dave Perkins
      Randy Presuhn
      Aleksey Romanov
      Shawn Routhier
      Jon Saperia
      Juergen Schoenwaelder
      Bob Stewart
      Kaj Tesink
      Glenn Waters
      Bert Wijnen

11.  IANA Considerations

   The SNMPv2-TM MIB module requires the allocation of a single object
   identifier for its MODULE-IDENTITY.  IANA has allocated this object
   identifier in the snmpModules subtree, defined in the SNMPv2-SMI MIB
   module.




Presuhn, et al.             Standards Track                    [Page 15]


RFC 3417              Transport Mappings for SNMP          December 2002


12.  Security Considerations

   SNMPv1 by itself is not a secure environment.  Even if the network
   itself is secure (for example by using IPSec), even then, there is no
   control as to who on the secure network is allowed to access and
   GET/SET (read/change) the objects accessible through a command
   responder application.

   It is recommended that the implementors consider the security
   features as provided by the SNMPv3 framework.  Specifically, the use
   of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the
   View-based Access Control Model STD 62, RFC 3415 [RFC3415] is
   recommended.

   It is then a customer/user responsibility to ensure that the SNMP
   entity giving access to a MIB is properly configured to give access
   to the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change) them.

13.  References

13.1.  Normative References

   [BER]       Information processing systems - Open Systems
               Interconnection - Specification of Basic Encoding Rules
               for Abstract Syntax Notation One (ASN.1), International
               Organization for Standardization.  International Standard
               8825, December 1987.

   [IS8072]    Information processing systems - Open Systems
               Interconnection - Transport Service Definition,
               International Organization for Standardization.
               International Standard 8072, June 1986.

   [IS8072A]   Information processing systems - Open Systems
               Interconnection - Transport Service Definition - Addendum
               1: Connectionless-mode Transmission, International
               Organization for Standardization.  International Standard
               8072/AD 1, December 1986.

   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
               August 1980.

   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
               September 1981.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.



Presuhn, et al.             Standards Track                    [Page 16]


RFC 3417              Transport Mappings for SNMP          December 2002


   [RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Structure of Management
               Information Version 2 (SMIv2)", STD 58, RFC 2578, April
               1999.

   [RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Textual Conventions for
               SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Conformance Statements for
               SMIv2", STD 58, RFC 2580, April 1999.

   [RFC3414]   Blumenthal, U. and B. Wijnen, "The User-Based Security
               Model (USM) for Version 3 of the Simple Network
               Management Protocol (SNMPv3)", STD 62, RFC 3414, December
               2002.

   [RFC3415]   Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model (VACM) for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3415, December
               2002.

   [RFC3416]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
               Waldbusser, "Version 2 of the Protocol Operations for the
               Simple Network Management Protocol (SNMP)", STD 62, RFC
               3416, December 2002.

13.2.  Informative References

   [APPLETALK] Sidhu, G., Andrews, R. and A. Oppenheimer, Inside
               AppleTalk (second edition).  Addison-Wesley, 1990.

   [NOVELL]    Network System Technical Interface Overview.  Novell,
               Inc., June 1989.

   [RFC1157]   Case, J., Fedor, M., Schoffstall, M. and J. Davin,
               "Simple Network Management Protocol", STD 15, RFC 1157,
               May 1990.

   [RFC1742]   Waldbusser, S. and K. Frisa, "AppleTalk Management
               Information Base II", RFC 1742, January 1995.

   [RFC2576]   Frye, R., Levi, D., Routhier, S. and B. Wijnen,
               "Coexistence between Version 1, Version 2, and Version 3
               of the Internet-Standard Network Management Framework",
               RFC 2576, March 2000.




Presuhn, et al.             Standards Track                    [Page 17]


RFC 3417              Transport Mappings for SNMP          December 2002


   [RFC3410]   Case, J., Mundy, R., Partain, D. and B. Stewart,
               "Introduction and Applicability Statements for Internet-
               Standard Management Framework", RFC 3410, December 2002.

   [RFC3419]   Daniele, M. and J. Schoenwaelder, "Textual Conventions
               for Transport Addresses", RFC 3419, November 2002.

14.  Changes from RFC 1906

   This document differs from RFC 1906 only in editorial improvements.
   The protocol is unchanged.

15.  Editor's Address

   Randy Presuhn
   BMC Software, Inc.
   2141 North First Street
   San Jose, CA 95131
   USA

   Phone: +1 408 546-1006
   EMail: randy_presuhn@bmc.com





























Presuhn, et al.             Standards Track                    [Page 18]


RFC 3417              Transport Mappings for SNMP          December 2002


16.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Presuhn, et al.             Standards Track                    [Page 19]

========================================================================






Network Working Group                            Editor of this version:
Request for Comments: 3418                                    R. Presuhn
STD: 62                                               BMC Software, Inc.
Obsoletes: 1907                             Authors of previous version:
Category: Standards Track                                        J. Case
                                                     SNMP Research, Inc.
                                                           K. McCloghrie
                                                     Cisco Systems, Inc.
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                           S. Waldbusser
                                          International Network Services
                                                           December 2002


               Management Information Base (MIB) for the
               Simple Network Management Protocol (SNMP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document defines managed objects which describe the behavior of
   a Simple Network Management Protocol (SNMP) entity.  This document
   obsoletes RFC 1907, Management Information Base for Version 2 of the
   Simple Network Management Protocol (SNMPv2).















Presuhn, et al.             Standards Track                     [Page 1]


RFC 3418                      MIB for SNMP                 December 2002


Table of Contents

   1. The Internet-Standard Management Framework ..................    2
   2. Definitions .................................................    2
   3. Notice on Intellectual Property .............................   20
   4. Acknowledgments .............................................   21
   5. Security Considerations .....................................   22
   6. References ..................................................   23
   6.1. Normative References ......................................   23
   6.2. Informative References ....................................   24
   7. Changes from RFC 1907 .......................................   24
   8. Editor's Address ............................................   25
   9. Full Copyright Statement ....................................   26

1.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).

   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

   It is the purpose of this document to define managed objects which
   describe the behavior of an SNMP entity, as defined in the SNMP
   architecture STD 62, [RFC3411].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

2.  Definitions

   SNMPv2-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
       TimeTicks, Counter32, snmpModules, mib-2
           FROM SNMPv2-SMI
       DisplayString, TestAndIncr, TimeStamp



Presuhn, et al.             Standards Track                     [Page 2]


RFC 3418                      MIB for SNMP                 December 2002


           FROM SNMPv2-TC
       MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
           FROM SNMPv2-CONF;

   snmpMIB MODULE-IDENTITY
       LAST-UPDATED "200210160000Z"
       ORGANIZATION "IETF SNMPv3 Working Group"
       CONTACT-INFO
               "WG-EMail:   snmpv3@lists.tislabs.com
                Subscribe:  snmpv3-request@lists.tislabs.com

                Co-Chair:   Russ Mundy
                            Network Associates Laboratories
                postal:     15204 Omega Drive, Suite 300
                            Rockville, MD 20850-4601
                            USA
                EMail:      mundy@tislabs.com
                phone:      +1 301 947-7107

                Co-Chair:   David Harrington
                            Enterasys Networks
                postal:     35 Industrial Way
                            P. O. Box 5005
                            Rochester, NH 03866-5005
                            USA
                EMail:      dbh@enterasys.com
                phone:      +1 603 337-2614

                Editor:     Randy Presuhn
                            BMC Software, Inc.
                postal:     2141 North First Street
                            San Jose, CA 95131
                            USA
                EMail:      randy_presuhn@bmc.com
                phone:      +1 408 546-1006"
       DESCRIPTION
               "The MIB module for SNMP entities.

                Copyright (C) The Internet Society (2002). This
                version of this MIB module is part of RFC 3418;
                see the RFC itself for full legal notices.
               "
       REVISION      "200210160000Z"
       DESCRIPTION
               "This revision of this MIB module was published as
                RFC 3418."
       REVISION      "199511090000Z"
       DESCRIPTION



Presuhn, et al.             Standards Track                     [Page 3]


RFC 3418                      MIB for SNMP                 December 2002


               "This revision of this MIB module was published as
                RFC 1907."
       REVISION      "199304010000Z"
       DESCRIPTION
               "The initial revision of this MIB module was published
               as RFC 1450."
       ::= { snmpModules 1 }

   snmpMIBObjects OBJECT IDENTIFIER ::= { snmpMIB 1 }

   --  ::= { snmpMIBObjects 1 }        this OID is obsolete
   --  ::= { snmpMIBObjects 2 }        this OID is obsolete
   --  ::= { snmpMIBObjects 3 }        this OID is obsolete

   -- the System group
   --
   -- a collection of objects common to all managed systems.

   system   OBJECT IDENTIFIER ::= { mib-2 1 }

   sysDescr OBJECT-TYPE
       SYNTAX      DisplayString (SIZE (0..255))
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A textual description of the entity.  This value should
               include the full name and version identification of
               the system's hardware type, software operating-system,
               and networking software."
       ::= { system 1 }

   sysObjectID OBJECT-TYPE
       SYNTAX      OBJECT IDENTIFIER
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The vendor's authoritative identification of the
               network management subsystem contained in the entity.
               This value is allocated within the SMI enterprises
               subtree (1.3.6.1.4.1) and provides an easy and
               unambiguous means for determining `what kind of box' is
               being managed.  For example, if vendor `Flintstones,
               Inc.' was assigned the subtree 1.3.6.1.4.1.424242,
               it could assign the identifier 1.3.6.1.4.1.424242.1.1
               to its `Fred Router'."
       ::= { system 2 }

   sysUpTime OBJECT-TYPE



Presuhn, et al.             Standards Track                     [Page 4]


RFC 3418                      MIB for SNMP                 December 2002


       SYNTAX      TimeTicks
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The time (in hundredths of a second) since the
               network management portion of the system was last
               re-initialized."
       ::= { system 3 }

   sysContact OBJECT-TYPE
       SYNTAX      DisplayString (SIZE (0..255))
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
               "The textual identification of the contact person for
               this managed node, together with information on how
               to contact this person.  If no contact information is
               known, the value is the zero-length string."
       ::= { system 4 }

   sysName OBJECT-TYPE
       SYNTAX      DisplayString (SIZE (0..255))
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
               "An administratively-assigned name for this managed
               node.  By convention, this is the node's fully-qualified
               domain name.  If the name is unknown, the value is
               the zero-length string."
       ::= { system 5 }

   sysLocation OBJECT-TYPE
       SYNTAX      DisplayString (SIZE (0..255))
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
               "The physical location of this node (e.g., 'telephone
               closet, 3rd floor').  If the location is unknown, the
               value is the zero-length string."
       ::= { system 6 }

   sysServices OBJECT-TYPE
       SYNTAX      INTEGER (0..127)
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A value which indicates the set of services that this
               entity may potentially offer.  The value is a sum.



Presuhn, et al.             Standards Track                     [Page 5]


RFC 3418                      MIB for SNMP                 December 2002


               This sum initially takes the value zero. Then, for
               each layer, L, in the range 1 through 7, that this node
               performs transactions for, 2 raised to (L - 1) is added
               to the sum.  For example, a node which performs only
               routing functions would have a value of 4 (2^(3-1)).
               In contrast, a node which is a host offering application
               services would have a value of 72 (2^(4-1) + 2^(7-1)).
               Note that in the context of the Internet suite of
               protocols, values should be calculated accordingly:

                    layer      functionality
                      1        physical (e.g., repeaters)
                      2        datalink/subnetwork (e.g., bridges)
                      3        internet (e.g., supports the IP)
                      4        end-to-end  (e.g., supports the TCP)
                      7        applications (e.g., supports the SMTP)

               For systems including OSI protocols, layers 5 and 6
               may also be counted."
       ::= { system 7 }

   -- object resource information
   --
   -- a collection of objects which describe the SNMP entity's
   -- (statically and dynamically configurable) support of
   -- various MIB modules.

   sysORLastChange OBJECT-TYPE
       SYNTAX     TimeStamp
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
               "The value of sysUpTime at the time of the most recent
               change in state or value of any instance of sysORID."
       ::= { system 8 }

   sysORTable OBJECT-TYPE
       SYNTAX     SEQUENCE OF SysOREntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
               "The (conceptual) table listing the capabilities of
               the local SNMP application acting as a command
               responder with respect to various MIB modules.
               SNMP entities having dynamically-configurable support
               of MIB modules will have a dynamically-varying number
               of conceptual rows."
       ::= { system 9 }



Presuhn, et al.             Standards Track                     [Page 6]


RFC 3418                      MIB for SNMP                 December 2002


   sysOREntry OBJECT-TYPE
       SYNTAX     SysOREntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
               "An entry (conceptual row) in the sysORTable."
       INDEX      { sysORIndex }
       ::= { sysORTable 1 }

   SysOREntry ::= SEQUENCE {
       sysORIndex     INTEGER,
       sysORID        OBJECT IDENTIFIER,
       sysORDescr     DisplayString,
       sysORUpTime    TimeStamp
   }

   sysORIndex OBJECT-TYPE
       SYNTAX     INTEGER (1..2147483647)
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
               "The auxiliary variable used for identifying instances
               of the columnar objects in the sysORTable."
       ::= { sysOREntry 1 }

   sysORID OBJECT-TYPE
       SYNTAX     OBJECT IDENTIFIER
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
               "An authoritative identification of a capabilities
               statement with respect to various MIB modules supported
               by the local SNMP application acting as a command
               responder."
       ::= { sysOREntry 2 }

   sysORDescr OBJECT-TYPE
       SYNTAX     DisplayString
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
               "A textual description of the capabilities identified
               by the corresponding instance of sysORID."
       ::= { sysOREntry 3 }

   sysORUpTime OBJECT-TYPE
       SYNTAX     TimeStamp
       MAX-ACCESS read-only



Presuhn, et al.             Standards Track                     [Page 7]


RFC 3418                      MIB for SNMP                 December 2002


       STATUS     current
       DESCRIPTION
               "The value of sysUpTime at the time this conceptual
               row was last instantiated."
       ::= { sysOREntry 4 }


   -- the SNMP group
   --
   -- a collection of objects providing basic instrumentation and
   -- control of an SNMP entity.

   snmp     OBJECT IDENTIFIER ::= { mib-2 11 }

   snmpInPkts OBJECT-TYPE
       SYNTAX     Counter32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
               "The total number of messages delivered to the SNMP
               entity from the transport service."
       ::= { snmp 1 }

   snmpInBadVersions OBJECT-TYPE
       SYNTAX     Counter32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
               "The total number of SNMP messages which were delivered
               to the SNMP entity and were for an unsupported SNMP
               version."
       ::= { snmp 3 }

   snmpInBadCommunityNames OBJECT-TYPE
       SYNTAX     Counter32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "The total number of community-based SNMP messages (for
              example,  SNMPv1) delivered to the SNMP entity which
              used an SNMP community name not known to said entity.
              Also, implementations which authenticate community-based
              SNMP messages using check(s) in addition to matching
              the community name (for example, by also checking
              whether the message originated from a transport address
              allowed to use a specified community name) MAY include
              in this value the number of messages which failed the
              additional check(s).  It is strongly RECOMMENDED that



Presuhn, et al.             Standards Track                     [Page 8]


RFC 3418                      MIB for SNMP                 December 2002


              the documentation for any security model which is used
              to authenticate community-based SNMP messages specify
              the precise conditions that contribute to this value."
       ::= { snmp 4 }

   snmpInBadCommunityUses OBJECT-TYPE
       SYNTAX     Counter32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "The total number of community-based SNMP messages (for
              example, SNMPv1) delivered to the SNMP entity which
              represented an SNMP operation that was not allowed for
              the SNMP community named in the message.  The precise
              conditions under which this counter is incremented
              (if at all) depend on how the SNMP entity implements
              its access control mechanism and how its applications
              interact with that access control mechanism.  It is
              strongly RECOMMENDED that the documentation for any
              access control mechanism which is used to control access
              to and visibility of MIB instrumentation specify the
              precise conditions that contribute to this value."
       ::= { snmp 5 }

   snmpInASNParseErrs OBJECT-TYPE
       SYNTAX     Counter32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
               "The total number of ASN.1 or BER errors encountered by
               the SNMP entity when decoding received SNMP messages."
       ::= { snmp 6 }

   snmpEnableAuthenTraps OBJECT-TYPE
       SYNTAX      INTEGER { enabled(1), disabled(2) }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
               "Indicates whether the SNMP entity is permitted to
               generate authenticationFailure traps.  The value of this
               object overrides any configuration information; as such,
               it provides a means whereby all authenticationFailure
               traps may be disabled.

               Note that it is strongly recommended that this object
               be stored in non-volatile memory so that it remains
               constant across re-initializations of the network
               management system."



Presuhn, et al.             Standards Track                     [Page 9]


RFC 3418                      MIB for SNMP                 December 2002


       ::= { snmp 30 }

   snmpSilentDrops OBJECT-TYPE
       SYNTAX     Counter32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "The total number of Confirmed Class PDUs (such as
              GetRequest-PDUs, GetNextRequest-PDUs,
              GetBulkRequest-PDUs, SetRequest-PDUs, and
              InformRequest-PDUs) delivered to the SNMP entity which
              were silently dropped because the size of a reply
              containing an alternate Response Class PDU (such as a
              Response-PDU) with an empty variable-bindings field
              was greater than either a local constraint or the
              maximum message size associated with the originator of
              the request."
       ::= { snmp 31 }

   snmpProxyDrops OBJECT-TYPE
       SYNTAX     Counter32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
               "The total number of Confirmed Class PDUs
               (such as GetRequest-PDUs, GetNextRequest-PDUs,
               GetBulkRequest-PDUs, SetRequest-PDUs, and
               InformRequest-PDUs) delivered to the SNMP entity which
               were silently dropped because the transmission of
               the (possibly translated) message to a proxy target
               failed in a manner (other than a time-out) such that
               no Response Class PDU (such as a Response-PDU) could
               be returned."
       ::= { snmp 32 }

   -- information for notifications
   --
   -- a collection of objects which allow the SNMP entity, when
   -- supporting a notification originator application,
   -- to be configured to generate SNMPv2-Trap-PDUs.

   snmpTrap       OBJECT IDENTIFIER ::= { snmpMIBObjects 4 }

   snmpTrapOID OBJECT-TYPE
       SYNTAX     OBJECT IDENTIFIER
       MAX-ACCESS accessible-for-notify
       STATUS     current
       DESCRIPTION



Presuhn, et al.             Standards Track                    [Page 10]


RFC 3418                      MIB for SNMP                 December 2002


               "The authoritative identification of the notification
               currently being sent.  This variable occurs as
               the second varbind in every SNMPv2-Trap-PDU and
               InformRequest-PDU."
       ::= { snmpTrap 1 }

   --  ::= { snmpTrap 2 }   this OID is obsolete

   snmpTrapEnterprise OBJECT-TYPE
       SYNTAX     OBJECT IDENTIFIER
       MAX-ACCESS accessible-for-notify
       STATUS     current
       DESCRIPTION
               "The authoritative identification of the enterprise
               associated with the trap currently being sent.  When an
               SNMP proxy agent is mapping an RFC1157 Trap-PDU
               into a SNMPv2-Trap-PDU, this variable occurs as the
               last varbind."
       ::= { snmpTrap 3 }

   --  ::= { snmpTrap 4 }   this OID is obsolete


   -- well-known traps

   snmpTraps      OBJECT IDENTIFIER ::= { snmpMIBObjects 5 }

   coldStart NOTIFICATION-TYPE
       STATUS  current
       DESCRIPTION
               "A coldStart trap signifies that the SNMP entity,
               supporting a notification originator application, is
               reinitializing itself and that its configuration may
               have been altered."
       ::= { snmpTraps 1 }

   warmStart NOTIFICATION-TYPE
       STATUS  current
       DESCRIPTION
               "A warmStart trap signifies that the SNMP entity,
               supporting a notification originator application,
               is reinitializing itself such that its configuration
               is unaltered."
       ::= { snmpTraps 2 }

   -- Note the linkDown NOTIFICATION-TYPE ::= { snmpTraps 3 }
   -- and the linkUp NOTIFICATION-TYPE ::= { snmpTraps 4 }
   -- are defined in RFC 2863 [RFC2863]



Presuhn, et al.             Standards Track                    [Page 11]


RFC 3418                      MIB for SNMP                 December 2002


   authenticationFailure NOTIFICATION-TYPE
       STATUS  current
       DESCRIPTION
               "An authenticationFailure trap signifies that the SNMP
                entity has received a protocol message that is not
                properly authenticated.  While all implementations
                of SNMP entities MAY be capable of generating this
                trap, the snmpEnableAuthenTraps object indicates
                whether this trap will be generated."
       ::= { snmpTraps 5 }

   -- Note the egpNeighborLoss notification is defined
   -- as { snmpTraps 6 } in RFC 1213

   -- the set group
   --
   -- a collection of objects which allow several cooperating
   -- command generator applications to coordinate their use of the
   -- set operation.

   snmpSet        OBJECT IDENTIFIER ::= { snmpMIBObjects 6 }

   snmpSetSerialNo OBJECT-TYPE
       SYNTAX     TestAndIncr
       MAX-ACCESS read-write
       STATUS     current
       DESCRIPTION
               "An advisory lock used to allow several cooperating
               command generator applications to coordinate their
               use of the SNMP set operation.

               This object is used for coarse-grain coordination.
               To achieve fine-grain coordination, one or more similar
               objects might be defined within each MIB group, as
               appropriate."
       ::= { snmpSet 1 }

   -- conformance information

   snmpMIBConformance
                  OBJECT IDENTIFIER ::= { snmpMIB 2 }

   snmpMIBCompliances
                  OBJECT IDENTIFIER ::= { snmpMIBConformance 1 }
   snmpMIBGroups  OBJECT IDENTIFIER ::= { snmpMIBConformance 2 }

   -- compliance statements




Presuhn, et al.             Standards Track                    [Page 12]


RFC 3418                      MIB for SNMP                 December 2002


   --    ::= { snmpMIBCompliances 1 }      this OID is obsolete
   snmpBasicCompliance MODULE-COMPLIANCE
       STATUS  deprecated
       DESCRIPTION
               "The compliance statement for SNMPv2 entities which
               implement the SNMPv2 MIB.

               This compliance statement is replaced by
               snmpBasicComplianceRev2."
       MODULE  -- this module
           MANDATORY-GROUPS { snmpGroup, snmpSetGroup, systemGroup,
                              snmpBasicNotificationsGroup }

           GROUP   snmpCommunityGroup
           DESCRIPTION
               "This group is mandatory for SNMPv2 entities which
               support community-based authentication."

       ::= { snmpMIBCompliances 2 }

   snmpBasicComplianceRev2 MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
               "The compliance statement for SNMP entities which
               implement this MIB module."
       MODULE  -- this module
           MANDATORY-GROUPS { snmpGroup, snmpSetGroup, systemGroup,
                              snmpBasicNotificationsGroup }

           GROUP   snmpCommunityGroup
           DESCRIPTION
               "This group is mandatory for SNMP entities which
               support community-based authentication."

           GROUP   snmpWarmStartNotificationGroup
           DESCRIPTION
               "This group is mandatory for an SNMP entity which
               supports command responder applications, and is
               able to reinitialize itself such that its
               configuration is unaltered."

       ::= { snmpMIBCompliances 3 }

   -- units of conformance

   --  ::= { snmpMIBGroups 1 }           this OID is obsolete
   --  ::= { snmpMIBGroups 2 }           this OID is obsolete
   --  ::= { snmpMIBGroups 3 }           this OID is obsolete



Presuhn, et al.             Standards Track                    [Page 13]


RFC 3418                      MIB for SNMP                 December 2002


   --  ::= { snmpMIBGroups 4 }           this OID is obsolete

   snmpGroup OBJECT-GROUP
       OBJECTS { snmpInPkts,
                 snmpInBadVersions,
                 snmpInASNParseErrs,
                 snmpSilentDrops,
                 snmpProxyDrops,
                 snmpEnableAuthenTraps }
       STATUS  current
       DESCRIPTION
               "A collection of objects providing basic instrumentation
               and control of an SNMP entity."
       ::= { snmpMIBGroups 8 }

   snmpCommunityGroup OBJECT-GROUP
       OBJECTS { snmpInBadCommunityNames,
                 snmpInBadCommunityUses }
       STATUS  current
       DESCRIPTION
               "A collection of objects providing basic instrumentation
               of a SNMP entity which supports community-based
               authentication."
       ::= { snmpMIBGroups 9 }

   snmpSetGroup OBJECT-GROUP
       OBJECTS { snmpSetSerialNo }
       STATUS  current
       DESCRIPTION
               "A collection of objects which allow several cooperating
               command generator applications to coordinate their
               use of the set operation."
       ::= { snmpMIBGroups 5 }

   systemGroup OBJECT-GROUP
       OBJECTS { sysDescr, sysObjectID, sysUpTime,
                 sysContact, sysName, sysLocation,
                 sysServices,
                 sysORLastChange, sysORID,
                 sysORUpTime, sysORDescr }
       STATUS  current
       DESCRIPTION
               "The system group defines objects which are common to all
               managed systems."
       ::= { snmpMIBGroups 6 }

   snmpBasicNotificationsGroup NOTIFICATION-GROUP
       NOTIFICATIONS { coldStart, authenticationFailure }



Presuhn, et al.             Standards Track                    [Page 14]


RFC 3418                      MIB for SNMP                 December 2002


       STATUS        current
       DESCRIPTION
          "The basic notifications implemented by an SNMP entity
           supporting command responder applications."
       ::= { snmpMIBGroups 7 }

   snmpWarmStartNotificationGroup NOTIFICATION-GROUP
      NOTIFICATIONS { warmStart }
      STATUS        current
      DESCRIPTION
        "An additional notification for an SNMP entity supporting
        command responder applications, if it is able to reinitialize
        itself such that its configuration is unaltered."
     ::= { snmpMIBGroups 11 }

   snmpNotificationGroup OBJECT-GROUP
       OBJECTS { snmpTrapOID, snmpTrapEnterprise }
       STATUS  current
       DESCRIPTION
               "These objects are required for entities
               which support notification originator applications."
       ::= { snmpMIBGroups 12 }

   -- definitions in RFC 1213 made obsolete by the inclusion of a
   -- subset of the snmp group in this MIB

   snmpOutPkts OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP Messages which were
               passed from the SNMP protocol entity to the
               transport service."
       ::= { snmp 2 }

   -- { snmp 7 } is not used

   snmpInTooBigs OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP PDUs which were
               delivered to the SNMP protocol entity and for
               which the value of the error-status field was
               `tooBig'."
       ::= { snmp 8 }



Presuhn, et al.             Standards Track                    [Page 15]


RFC 3418                      MIB for SNMP                 December 2002


   snmpInNoSuchNames OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP PDUs which were
               delivered to the SNMP protocol entity and for
               which the value of the error-status field was
               `noSuchName'."
       ::= { snmp 9 }

   snmpInBadValues OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP PDUs which were
               delivered to the SNMP protocol entity and for
               which the value of the error-status field was
               `badValue'."
       ::= { snmp 10 }

   snmpInReadOnlys OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number valid SNMP PDUs which were delivered
               to the SNMP protocol entity and for which the value
               of the error-status field was `readOnly'.  It should
               be noted that it is a protocol error to generate an
               SNMP PDU which contains the value `readOnly' in the
               error-status field, as such this object is provided
               as a means of detecting incorrect implementations of
               the SNMP."
       ::= { snmp 11 }

   snmpInGenErrs OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP PDUs which were delivered
               to the SNMP protocol entity and for which the value
               of the error-status field was `genErr'."
       ::= { snmp 12 }

   snmpInTotalReqVars OBJECT-TYPE



Presuhn, et al.             Standards Track                    [Page 16]


RFC 3418                      MIB for SNMP                 December 2002


       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of MIB objects which have been
               retrieved successfully by the SNMP protocol entity
               as the result of receiving valid SNMP Get-Request
               and Get-Next PDUs."
       ::= { snmp 13 }

   snmpInTotalSetVars OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of MIB objects which have been
               altered successfully by the SNMP protocol entity as
               the result of receiving valid SNMP Set-Request PDUs."
       ::= { snmp 14 }

   snmpInGetRequests OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP Get-Request PDUs which
               have been accepted and processed by the SNMP
               protocol entity."
       ::= { snmp 15 }

   snmpInGetNexts OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP Get-Next PDUs which have been
               accepted and processed by the SNMP protocol entity."
       ::= { snmp 16 }

   snmpInSetRequests OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP Set-Request PDUs which
               have been accepted and processed by the SNMP protocol
               entity."
       ::= { snmp 17 }



Presuhn, et al.             Standards Track                    [Page 17]


RFC 3418                      MIB for SNMP                 December 2002


   snmpInGetResponses OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP Get-Response PDUs which
               have been accepted and processed by the SNMP protocol
               entity."
       ::= { snmp 18 }

   snmpInTraps OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP Trap PDUs which have been
               accepted and processed by the SNMP protocol entity."
       ::= { snmp 19 }

   snmpOutTooBigs OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP PDUs which were generated
               by the SNMP protocol entity and for which the value
               of the error-status field was `tooBig.'"
       ::= { snmp 20 }

   snmpOutNoSuchNames OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP PDUs which were generated
               by the SNMP protocol entity and for which the value
               of the error-status was `noSuchName'."
       ::= { snmp 21 }

   snmpOutBadValues OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP PDUs which were generated
               by the SNMP protocol entity and for which the value
               of the error-status field was `badValue'."
       ::= { snmp 22 }



Presuhn, et al.             Standards Track                    [Page 18]


RFC 3418                      MIB for SNMP                 December 2002


   -- { snmp 23 } is not used

   snmpOutGenErrs OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP PDUs which were generated
               by the SNMP protocol entity and for which the value
               of the error-status field was `genErr'."
       ::= { snmp 24 }

   snmpOutGetRequests OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP Get-Request PDUs which
               have been generated by the SNMP protocol entity."
       ::= { snmp 25 }

   snmpOutGetNexts OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP Get-Next PDUs which have
               been generated by the SNMP protocol entity."
       ::= { snmp 26 }

   snmpOutSetRequests OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP Set-Request PDUs which
               have been generated by the SNMP protocol entity."
       ::= { snmp 27 }

   snmpOutGetResponses OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP Get-Response PDUs which
               have been generated by the SNMP protocol entity."
       ::= { snmp 28 }




Presuhn, et al.             Standards Track                    [Page 19]


RFC 3418                      MIB for SNMP                 December 2002


   snmpOutTraps OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      obsolete
       DESCRIPTION
               "The total number of SNMP Trap PDUs which have
               been generated by the SNMP protocol entity."
       ::= { snmp 29 }

   snmpObsoleteGroup OBJECT-GROUP
       OBJECTS { snmpOutPkts, snmpInTooBigs, snmpInNoSuchNames,
                 snmpInBadValues, snmpInReadOnlys, snmpInGenErrs,
                 snmpInTotalReqVars, snmpInTotalSetVars,
                 snmpInGetRequests, snmpInGetNexts, snmpInSetRequests,
                 snmpInGetResponses, snmpInTraps, snmpOutTooBigs,
                 snmpOutNoSuchNames, snmpOutBadValues,
                 snmpOutGenErrs, snmpOutGetRequests, snmpOutGetNexts,
                 snmpOutSetRequests, snmpOutGetResponses, snmpOutTraps
                 }
       STATUS  obsolete
       DESCRIPTION
               "A collection of objects from RFC 1213 made obsolete
               by this MIB module."
       ::= { snmpMIBGroups 10 }

   END

3.  Notice on Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.



Presuhn, et al.             Standards Track                    [Page 20]


RFC 3418                      MIB for SNMP                 December 2002


4.  Acknowledgments

   This document is the product of the SNMPv3 Working Group.  Some
   special thanks are in order to the following Working Group members:

      Randy Bush
      Jeffrey D. Case
      Mike Daniele
      Rob Frye
      Lauren Heintz
      Keith McCloghrie
      Russ Mundy
      David T. Perkins
      Randy Presuhn
      Aleksey Romanov
      Juergen Schoenwaelder
      Bert Wijnen

   This version of the document, edited by Randy Presuhn, was initially
   based on the work of a design team whose members were:

      Jeffrey D. Case
      Keith McCloghrie
      David T. Perkins
      Randy Presuhn
      Juergen Schoenwaelder

   The  previous versions of this document, edited by Keith McCloghrie,
   was the result of significant work by four major contributors:

      Jeffrey D. Case
      Keith McCloghrie
      Marshall T. Rose
      Steven Waldbusser

















Presuhn, et al.             Standards Track                    [Page 21]


RFC 3418                      MIB for SNMP                 December 2002


   Additionally, the contributions of the SNMPv2 Working Group to the
   previous versions are also acknowledged.  In particular, a special
   thanks is extended for the contributions of:

      Alexander I. Alten
      Dave Arneson
      Uri Blumenthal
      Doug Book
      Kim Curran
      Jim Galvin
      Maria Greene
      Iain Hanson
      Dave Harrington
      Nguyen Hien
      Jeff Johnson
      Michael Kornegay
      Deirdre Kostick
      David Levi
      Daniel Mahoney
      Bob Natale
      Brian O'Keefe
      Andrew Pearson
      Dave Perkins
      Randy Presuhn
      Aleksey Romanov
      Shawn Routhier
      Jon Saperia
      Juergen Schoenwaelder
      Bob Stewart
      Kaj Tesink
      Glenn Waters
      Bert Wijnen

5.  Security Considerations

   There are a number of management objects defined in this MIB that
   have a MAX-ACCESS clause of read-write.  Such objects may be
   considered sensitive or vulnerable in some network environments.  The
   support for SET operations in a non-secure environment without proper
   protection can have a negative effect on network operations.

   SNMPv1 by itself is not a secure environment.  Even if the network
   itself is secure (for example by using IPSec), even then, there is no
   control as to who on the secure network is allowed to access and
   GET/SET (read/change) the objects in this MIB.






Presuhn, et al.             Standards Track                    [Page 22]


RFC 3418                      MIB for SNMP                 December 2002


   It is recommended that the implementors consider the security
   features as provided by the SNMPv3 framework.  Specifically, the use
   of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the
   View-based Access Control Model STD 62, RFC 3415 [RFC3415] is
   recommended.

   It is then a customer/user responsibility to ensure that the SNMP
   entity giving access to an instance of this MIB is properly
   configured to give access to the objects only to those principals
   (users) that have legitimate rights to indeed GET or SET (change)
   them.

6.  References

6.1.  Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Structure of Management
               Information Version 2 (SMIv2)", STD 58, RFC 2578, April
               1999.

   [RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Textual Conventions for
               SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Conformance Statements for
               SMIv2", STD 58, RFC 2580, April 1999.

   [RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An
               Architecture for describing Simple Network Management
               Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
               December 2002.

   [RFC3414]   Blumenthal, U. and B. Wijnen, "The User-Based Security
               Model (USM) for Version 3 of the Simple Network
               Management Protocol (SNMPv3)", STD 62, RFC 3414, December
               2002.

   [RFC3415]   Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model (VACM) for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3415, December
               2002.





Presuhn, et al.             Standards Track                    [Page 23]


RFC 3418                      MIB for SNMP                 December 2002


6.1.  Informative References

   [RFC1157]   Case, J., Fedor, M., Schoffstall, M. and J. Davin,
               "Simple Network Management Protocol", STD 15, RFC 1157,
               May 1990.

   [RFC1213]   McCloghrie, K. and M. Rose, "Management Information Base
               for Network Management of TCP/IP-based internets: MIB-
               II", STD 16, RFC 1213, March 1991.

   [RFC2863]   McCloghrie, K. and F. Kastenholz, "The Interfaces Group
               MIB", RFC 2863, June 2000.

   [RFC3410]   Case, J., Mundy, R., Partain, D. and B. Stewart,
               "Introduction and Applicability Statements for Internet-
               Standard Management Framework", RFC 3410, December 2002.

7.  Changes from RFC 1907

   These are the changes from RFC 1907:

      -  Corrected typo in copyright statement;

      -  Updated copyright date;

      -  Updated with new editor's name and contact information;

      -  Cosmetic fixes to layout and typography;

      -  Changed title;

      -  Replace introduction with current MIB boilerplate;

      -  Updated references;

      -  Fixed typo in sysORUpTime;

      -  Re-worded description of snmpSilentDrops;

      -  Updated reference to RFC 1573 to 2863;

      -  Added IPR boilerplate as required by RFC 2026;

      -  Weakened authenticationFailure description from MUST to MAY,
         clarified that it pertains to all SNMP entities;






Presuhn, et al.             Standards Track                    [Page 24]


RFC 3418                      MIB for SNMP                 December 2002


      -  Clarified descriptions of snmpInBadCommunityNames and
         snmpInBadCommunityUses;

      -  Updated module-identity and contact information;

      -  Updated the acknowledgments section;

      -  Replaced references to "manager role", "agent role" and "SNMPv2
         entity" with appropriate terms from RFC 2571;

      -  Updated document headers and footers;

      -  Added security considerations, based on current recommendations
         for MIB modules;

      -  Added NOTIFICATION-GROUP and OBJECT-GROUP constructs for
         NOTIFICATION-TYPEs and OBJECT-TYPEs that were left unreferenced
         in RFC 1907;

      -  Fixed typos in sysServices DESCRIPTION;

      -  Changed description of snmpProxyDrops to use terms from
         architecture;

      -  Changed value used in example for sysObjectID;

      -  Added an abstract;

      -  Deprecated the snmpBasicCompliance MODULE-COMPLIANCE, and added
         the snmpBasicComplianceRev2 MODULE-COMPLIANCE to take its
         place;

      -  Updated working group mailing list address;

      -  Added co-chair's address.

8.  Editor's Address

   Randy Presuhn
   BMC Software, Inc.
   2141 North First Street
   San Jose, CA  95131
   USA

   Phone: +1 408 546 1006
   EMail: randy_presuhn@bmc.com





Presuhn, et al.             Standards Track                    [Page 25]


RFC 3418                      MIB for SNMP                 December 2002


9.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Presuhn, et al.             Standards Track                    [Page 26]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/