GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:std:std62

Table of Contents

[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:
  1. 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);
  1. at least one SNMP entity containing command generator and/or

notification receiver applications (traditionally called a

       manager) and,
  1. 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:
  1. minimal SNMP entities with command responder and/or

notification originator applications (traditionally called SNMP

       agents),
  1. SNMP entities with proxy forwarder applications (traditionally

called SNMP proxy agents),

  1. command line driven SNMP entities with command generator and/or

notification receiver applications (traditionally called SNMP

       command line managers),
  1. 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),
  1. 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:
  1. 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.
  1. Address the need for secure SET support, which is considered

the most important deficiency in SNMPv1 and SNMPv2c.

  1. Make it possible to move portions of the architecture forward

in the standards track, even if consensus has not been reached

       on all pieces.
  1. Define an architecture that allows for longevity of the SNMP

Frameworks that have been and will be defined.

  1. Keep SNMP as simple as possible.
  1. Make it relatively inexpensive to deploy a minimal conforming

implementation.

  1. Make it possible to upgrade portions of SNMP as new approaches

become available, without disrupting an entire SNMP framework.

  1. 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:
  1. 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.
  1. 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.
  1. 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.
  1. 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

  1. 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:
  1. in the transmission/receipt of messages, and
  1. 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:
  1. a new SNMP message format,
  1. Security for Messages,
  1. Access Control, and
  1. 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:
  1. sending and receiving SNMP messages to/from the network,
  1. determining the version of an SNMP message and interacting with

the corresponding Message Processing Model,

  1. providing an abstract interface to SNMP applications for

delivery of a PDU to an application.

  1. 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:
  1. command generators, which monitor and manipulate management

data,

  1. command responders, which provide access to management data,
  1. notification originators, which initiate asynchronous messages,
  1. notification receivers, which process asynchronous messages,
    and
  1. 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:
  1. without authentication and without privacy (noAuthNoPriv)
  1. with authentication but without privacy (authNoPriv)
  1. 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 }
  1. - 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:
  1. verifies that the message has not been altered,
  1. authenticates the identification of the principal for whom the

message was generated.

  1. 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:
  1. for requests and notifications: prepareOutgoingMessage, as

described in section 4.2.1.

  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:
  1. for requests and notifications: generateRequestMsg, as

described in section 4.4.1.

  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 }
  1. - 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}
  1. - 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:
  1. sent on behalf of the principal associated with the

securityName,

  1. was not redirected,
  1. was not modified in transit, and
  1. 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:
  1. msgID,
  2. contextEngineID,
  3. contextName,
  4. securityModel,
  5. securityName,
  6. securityLevel,
  7. securityStateReference,
  8. reportableFlag,
  9. transportDomain, and
  10. 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:
  1. If securityLevel specifies noAuthNoPriv, then authFlag and

privFlag are both set to zero.

  1. If securityLevel specifies authNoPriv, then authFlag is set

to one and privFlag is set to zero.

  1. If securityLevel specifies authPriv, then authFlag is set to

one and privFlag is set to one.

  1. If the PDU is from the Unconfirmed Class, then the

reportableFlag is set to zero.

  1. If the PDU is from the Confirmed Class then the

reportableFlag is set to one.

  1. 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:
  1. sendPduHandle
  2. msgID
  3. snmpEngineID
  4. securityModel
  5. securityName
  6. securityLevel
  7. contextEngineID
  8. 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:
  1. GetRequest-PDU,
  2. GetNextRequest-PDU,
  3. GetBulkRequest-PDU,
  4. SetRequest-PDU,
  5. InformRequest-PDU,
  6. SNMPv2-Trap-PDU,
  7. Response-PDU,
  8. 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:
  1. snmpEngineID
  2. securityModel
  3. securityName
  4. securityLevel
  5. contextEngineID
  6. 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:
  1. Applications which initiate SNMP Read-Class, and/or Write-Class

requests, called 'command generators.'

  1. Applications which respond to SNMP Read-Class, and/or Write-Class

requests, called 'command responders.'

  1. Applications which generate SNMP Notification-Class PDUs, called

'notification originators.'

  1. Applications which receive SNMP Notification-Class PDUs, called

'notification receivers.'

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

  1. 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;
  1. 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:
  1. Destination information, consisting of a transport domain and a

transport address. This is also termed a transport endpoint.

  1. 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:
  1. The transportDomain is that of the destination of the message.
  1. The transportAddress is that of the destination of the message.
  1. The messageProcessingModel indicates which Message Processing Model

the application wishes to use.

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

  1. The securityName is the security model independent name for the

principal on whose behalf the application wishes the message to be

   generated.
  1. The securityLevel is the security level that the application wishes

to use.

  1. 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.
  1. The contextName specifies the local context name for the management

information it is requesting.

  1. The pduVersion indicates the version of the PDU to be sent.
  1. The PDU is a value constructed by the command generator containing

the management operation that the command generator wishes to

   perform.
  1. 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:
  1. The messageProcessingModel is the value from the received response.
  1. The securityModel is the value from the received response.
  1. The securityName is the value from the received response.
  1. The securityLevel is the value from the received response.
  1. The contextEngineID is the value from the received response.
  1. The contextName is the value from the received response.
  1. The pduVersion indicates the version of the PDU in the received

response.

  1. The PDU is the value from the received response.
  1. The statusInformation indicates success or failure in receiving the

response.

  1. 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:
  1. The statusInformation indicates success or failure of the

registration attempt.

  1. The contextEngineID is equal to the snmpEngineID of the SNMP engine

with which the command responder is registering.

  1. 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:
  1. The contextEngineID is equal to the snmpEngineID of the SNMP engine

with which the command responder is cancelling the registration.

  1. 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:
  1. The messageProcessingModel indicates which Message Processing Model

received and processed the message.

  1. The securityModel is the value from the received message.
  1. The securityName is the value from the received message.
  1. The securityLevel is the value from the received message.
  1. The contextEngineID is the value from the received message.
  1. The contextName is the value from the received message.
  1. The pduVersion indicates the version of the PDU in the received

message.

  1. The PDU is the value from the received message.
  1. 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).
  1. 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:
  1. The securityModel is the value from the received message.
  1. The securityName is the value from the received message.
  1. The securityLevel is the value from the received message.
  1. The viewType indicates whether the PDU type is a Read-Class or

Write-Class operation.

  1. The contextName is the value from the received message.

Levi, et. al. Standards Track [Page 11] RFC 3413 SNMP Applications December 2002

  1. 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:
  1. 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.
  1. 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.
  1. 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.
  1. 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:
  1. The messageProcessingModel is the value from the processPdu

call.

  1. The securityModel is the value from the processPdu call.
  1. The securityName is the value from the processPdu call.
  1. The securityLevel is the value from the processPdu call.
  1. The contextEngineID is the value from the processPdu call.
  1. The contextName is the value from the processPdu call.
  1. The pduVersion indicates the version of the PDU to be returned.

If no result PDU was generated, the pduVersion is an undefined

       value.
  1. The PDU is the result generated in step (5) above. If no

result PDU was generated, the PDU is an undefined value.

  1. The maxSizeResponseScopedPDU is a local value indicating the

maximum size of a ScopedPDU that the application can accept.

  1. The stateReference is the value from the processPdu call.
  1. 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:
  1. The transportDomain is that of the management target.
  1. The transportAddress is that of the management target.
  1. The messageProcessingModel is that of the management target.
  1. The securityModel is that of the management target.
  1. The securityName is that of the management target.
  1. The securityLevel is that of the management target.
  1. The contextEngineID is the value originally determined for the

notification.

  1. The contextName is the value originally determined for the

notification.

  1. The pduVersion is the version of the PDU to be sent.
  1. The PDU is the value constructed in step (4) above.
  1. 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:
  1. Determine the targets to which the notification should be sent.
  1. Apply any required filtering to the list of targets.
  1. 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

  1. The contextEngineID is an undefined 'wildcard' value.

Notifications are delivered to a registered notification receiver

   regardless of the contextEngineID contained in the notification
   message.
  1. 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:
  1. The messageProcessingModel indicates which Message Processing Model

received and processed the message.

  1. The securityModel is the value from the received message.
  1. The securityName is the value from the received message.
  1. The securityLevel is the value from the received message.
  1. The contextEngineID is the value from the received message.
  1. The contextName is the value from the received message.
  1. The pduVersion indicates the version of the PDU in the received

message.

  1. The PDU is the value from the received message.
  1. 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).
  1. 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:
  1. The messageProcessingModel is the value from the processPdu

call.

  1. The securityModel is the value from the processPdu call.
  1. The securityName is the value from the processPdu call.
  1. The securityLevel is the value from the processPdu call.
  1. The contextEngineID is the value from the processPdu call.
  1. The contextName is the value from the processPdu call.
  1. The pduVersion indicates the version of the PDU to be returned.
  1. The PDU is the result generated in step (2) above.
  1. The maxSizeResponseScopedPDU is a local value indicating the

maximum size of a ScopedPDU that the application can accept.

  1. The stateReference is the value from the processPdu call.
  1. 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

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

  1. The messageProcessingModel is the value from the processPdu

call.

  1. The securityModel is the value from the processPdu call.
  1. The securityName is the value from the processPdu call.
  1. The securityLevel is the value from the processPdu call.
  1. The contextEngineID is the value from the processPdu call.
  1. The contextName is the value from the processPdu call.
  1. The pduVersion is the value from the processPdu call.
  1. The PDU is an undefined value.
  1. The maxSizeResponseScopedPDU is a local value indicating the

maximum size of a ScopedPDU that the application can accept.

  1. The stateReference is the value from the processPdu call.
  1. 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:
  1. The transportDomain is that of the outgoing management target.
  1. The transportAddress is that of the outgoing management target.
  1. The messageProcessingModel is that of the outgoing management

target.

  1. The securityModel is that of the outgoing management target.

Levi, et. al. Standards Track [Page 22] RFC 3413 SNMP Applications December 2002

  1. The securityName is that of the outgoing management target.
  1. The securityLevel is that of the outgoing management target.
  1. The contextEngineID is the value from the processPdu call.
  1. The contextName is the value from the processPdu call.
  1. The pduVersion is the version of the PDU to be sent.
  1. The PDU is the value constructed in step (3) above.
  1. 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:
  1. The sendPduHandle returned from the call to sendPdu,
  1. The request-id from the received PDU.
  1. The contextEngineID,
  1. The contextName,
  1. The stateReference,
  1. The incoming management target information,
  1. The outgoing management information,
  1. 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:
  1. The messageProcessingModel indicates the Message Processing

Model by which the original incoming message was processed.

  1. The securityModel is that of the original incoming management

target extracted from the cache.

  1. The securityName is that of the original incoming management

target extracted from the cache.

  1. The securityLevel is that of the original incoming management

target extracted from the cache.

  1. The contextEngineID is the value extracted from the cache.
  1. The contextName is the value extracted from the cache.
  1. The pduVersion indicates the version of the PDU to be returned.
  1. The PDU is the (possibly translated) Response PDU.

Levi, et. al. Standards Track [Page 24] RFC 3413 SNMP Applications December 2002

  1. The maxSizeResponseScopedPDU is a local value indicating the

maximum size of a ScopedPDU that the application can accept.

  1. The stateReference is the value extracted from the cache.
  1. 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:
  1. The messageProcessingModel indicates the Message Processing

Model by which the original incoming message was processed.

  1. The securityModel is that of the original incoming management

target extracted from the cache.

  1. The securityName is that of the original incoming management

target extracted from the cache.

  1. The securityLevel is that of the original incoming management

target extracted from the cache.

  1. The contextEngineID is the value extracted from the cache.
  1. The contextName is the value extracted from the cache.
  1. The pduVersion indicates the version of the PDU to be returned.

Levi, et. al. Standards Track [Page 25] RFC 3413 SNMP Applications December 2002

  1. The PDU is unused.
  1. The maxSizeResponseScopedPDU is a local value indicating the

maximum size of a ScopedPDU that the application can accept.

  1. The stateReference is the value extracted from the cache.
  1. 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:
  1. The messageProcessingModel is the value from the processPdu

call.

  1. The securityModel is the value from the processPdu call.
  1. The securityName is the value from the processPdu call.
  1. The securityLevel is the value from the processPdu call.
  1. The contextEngineID is the value from the processPdu call.
  1. The contextName is the value from the processPdu call.

Levi, et. al. Standards Track [Page 26] RFC 3413 SNMP Applications December 2002

  1. The pduVersion is the value from the processPdu call.
  1. The PDU is an undefined and unused value.
  1. The maxSizeResponseScopedPDU is a local value indicating the

maximum size of a ScopedPDU that the application can accept.

  1. The stateReference is the value from the processPdu call.
  1. 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:
  1. The contextEngineID and contextName values from the original

received notification are used.

  1. The outgoing management targets previously determined are used.
  1. No filtering mechanisms are applied.
  1. 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.
  1. 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.
  1. 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:
  1. 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,
  1. 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:
  1. The messageProcessingModel is the value from the processPdu

call.

  1. The securityModel is the value from the processPdu call.
  1. The securityName is the value from the processPdu call.
  1. The securityLevel is the value from the processPdu call.
  1. The contextEngineID is the value from the processPdu call.
  1. The contextName is the value from the processPdu call.
  1. The pduVersion indicates the version of the PDU constructed in

step (6) above.

  1. The PDU is the value constructed in step (6) above.
  1. The maxSizeResponseScopedPDU is a local value indicating the

maximum size of a ScopedPDU that the application can accept.

  1. The stateReference is the value from the processPdu call.
  1. 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:
  1. The use of the management target MIB and the notification MIB in

notification originator applications is described in section 5.

  1. The use of the notification MIB for filtering notifications in

notification originator applications is described in section 6.

  1. 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:
  1. An ASCII space character (0x20).
  1. An ASCII TAB character (0x09).
  1. An ASCII carriage return (CR) character (0x0D).
  1. 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
  1. a zero-length octet string representing an empty list, or
  1. a single tag value, in which case the value of the MIB object may

not contain a delimiter character, or

  1. 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:
  1. There cannot be a leading or trailing delimiter character.
  1. 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:
  1. An ASCII space character (0x20).
  1. An ASCII TAB character (0x09).
  1. An ASCII carriage return (CR) character (0x0D).
  1. 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:
  1. 'acme'
  1. 'router'
  1. '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:
  1. An ASCII space character (0x20).
  1. An ASCII TAB character (0x09).
  1. An ASCII carriage return (CR) character (0x0D).
  1. 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:
  1. There cannot be a leading or trailing delimiter

character.

  1. There cannot be multiple adjacent delimiter

characters.

          Some examples of valid tag lists are:
  1. – 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 }
  1. -
  2. -
  3. - Conformance information
  4. -
  5. -
 snmpNotifyCompliances OBJECT IDENTIFIER ::=
                                         { snmpNotifyConformance 1 }
 snmpNotifyGroups      OBJECT IDENTIFIER ::=
                                         { snmpNotifyConformance 2 }
  1. -
  2. -
  3. - Compliance statements
  4. -
  5. -
 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 }
  1. -

Levi, et. al. Standards Track [Page 58] RFC 3413 SNMP Applications December 2002

  1. -
  2. - The snmpProxyObjects group
  3. -
  4. -
 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 }
  1. -
  2. -
  3. - Conformance information
  4. -
  5. -
 snmpProxyCompliances OBJECT IDENTIFIER ::=
                                          { snmpProxyConformance 1 }
 snmpProxyGroups      OBJECT IDENTIFIER ::=
                                          { snmpProxyConformance 2 }
  1. -
  2. -
  3. - Compliance statements
  4. -
  5. -
 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:
  1. 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.
  1. The contextEngineID must equal the snmpProxyContextEngineID object.
  1. If the snmpProxyContextName object is supported, it must equal the

contextName.

Levi, et. al. Standards Track [Page 65] RFC 3413 SNMP Applications December 2002

  1. 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:
  1. 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.
  1. The contextEngineID must equal the snmpProxyContextEngineID object.
  1. If the snmpProxyContextName object is supported, it must equal the

contextName.

Levi, et. al. Standards Track [Page 66] RFC 3413 SNMP Applications December 2002

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

  1. 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.
  1. 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:
  1. 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.
  1. 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:
  1. 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.
  1. 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:
  1. 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.
  1. 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

  1. Data Confidentiality is the provision of the property that

information is not made available or disclosed to unauthorized

   individuals, entities, or processes.
  1. 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:
  1. The authentication module MUST provide for:
  1. Data Integrity,
  1. Data Origin Authentication,
  1. The timeliness module MUST provide for:
  1. Protection against message delay or replay (to an extent greater

than can occur through normal operation).

  1. The privacy module MUST provide for
  1. 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:
  1. the HMAC-MD5-96 authentication protocol.
  2. 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:
  1. 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

  1. snmpEngineBoots, which is a count of the number of times the SNMP

engine has re-booted/re-initialized since snmpEngineID was last

   configured; and,
  1. 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:
  1. The msgAuthoritativeEngineID specifies the snmpEngineID of the

authoritative SNMP engine involved in the exchange of the message.

  1. The msgAuthoritativeEngineBoots specifies the snmpEngineBoots value

at the authoritative SNMP engine involved in the exchange of the

   message.
  1. The msgAuthoritativeEngineTime specifies the snmpEngineTime value

at the authoritative SNMP engine involved in the exchange of the

   message.
  1. 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.
  1. 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.
  1. 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:
  1. the local value of snmpEngineBoots is 2147483647;
  1. the value of the msgAuthoritativeEngineBoots field differs

from the local value of snmpEngineBoots; or,

  1. 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:
  1. the extracted value of the msgAuthoritativeEngineBoots

field is greater than the local notion of the value of

             snmpEngineBoots; or,
  1. 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:
  1. the local notion of the value of snmpEngineBoots to the

value of the msgAuthoritativeEngineBoots field,

  1. the local notion of the value of snmpEngineTime to the

value of the msgAuthoritativeEngineTime field, and

  1. 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:
  1. the local notion of the value of snmpEngineBoots is

2147483647;

  1. the value of the msgAuthoritativeEngineBoots field is

less than the local notion of the value of

             snmpEngineBoots; or,
  1. 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).
  1. Data Encryption Algorithm, American National

Standards Institute. ANSI X3.92-1981,

                  (December, 1980).
  1. DES Modes of Operation, National Institute of

Standards and Technology. Federal Information

                  Processing Standard (FIPS) Publication 81,
                  (December, 1980).
  1. 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:
  1. 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:
  1. Updated references
  2. Updated contact info
  3. Clarifications
    1. to first constraint item 1) on page 6.
    2. to usmUserCloneFrom DESCRIPTION clause
    3. to securityName in section 2.1
  4. Fixed "command responder" into "command generator" in last para of

DESCRIPTION clause of usmUserTable.

 Changes made since RFC2274:
  1. Fixed msgUserName to allow size of zero and explain that this can

be used for snmpEngineID discovery.

  1. Clarified section 3.1 steps 4.b, 5, 6 and 8.b.
  2. Clarified section 3.2 paragraph 2.
  3. Clarified section 3.2 step 7.a last paragraph, step 7.b.1 second

bullet and step 7.b.2 third bullet.

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

  1. Clarified how and under which conditions the usmUserAuthProtocol

and usmUserPrivProtocol can be initialized and/or changed.

  1. 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:
  1. the OBJECT IDENTIFIER name of the managed object instance contains

at least as many sub-identifiers as does the family name, and

  1. 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] © "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 232-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 1)

1)
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:
  1. only those principals (users) having legitimate rights can
access or modify the values of any MIB objects supported by
       that entity;
  1. the occurrence of particular events on the entity will be
communicated appropriately;
  1. 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:
  1. Corrected spelling error in copyright statement;
  1. Updated copyright date;
  1. Updated with new editor's name and contact information;
  1. Added notice on intellectual property;
Presuhn, et al. Standards Track [Page 28] RFC 3416 Protocol Operations for SNMP December 2002
  1. Cosmetic fixes to layout and typography;
  1. Added table of contents;
  1. Title changed;
  1. Updated document headers and footers;
  1. Deleted the old clause 2.3, entitled "Access to Management
Information";
  1. 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;
  1. Replaced the word "exception" with the word "error" in the old
clause 4.1. This does not affect the protocol in any way;
  1. Deleted the first two paragraphs of the old clause 4.2;
  1. Clarified the maximum number of variable bindings that an
implementation must support in a PDU. This does not affect the
       protocol in any way;
  1. Replaced occurrences of "SNMPv2 application" with
"application";
  1. 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;
  1. Clarified the use of the SNMPv2-Trap-Pdu in the old clause
4.2.6. This does not affect the protocol in any way;
  1. 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;
  1. Updated references;
  1. Re-wrote introduction clause;
  1. Replaced manager/agent/SNMPv2 entity terminology with
terminology from RFC 2571. This does not affect the protocol
       in any way;
  1. 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
  1. Added notes calling attention to two different manifestations
of reaching the end of a table in the table walk examples;
  1. Added content to security considerations clause;
  1. Updated ASN.1 comment on use of Report-PDU. This does not
affect the protocol in any way;
  1. Updated acknowledgments section;
  1. Included information on handling of BITS;
  1. Deleted spurious comma in ASN.1 definition of PDUs;
  1. Added abstract;
  1. 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;
  1. 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 }
  1. - 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))
  1. - 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
  1. - 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))
  1. - 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
  1. - 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 }
  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 }
  1. - ::= { snmpMIBObjects 1 } this OID is obsolete
  2. - ::= { snmpMIBObjects 2 } this OID is obsolete
  3. - ::= { snmpMIBObjects 3 } this OID is obsolete
  1. - the System group
  2. -
  3. - 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 }
  1. - object resource information
  2. -
  3. - a collection of objects which describe the SNMP entity's
  4. - (statically and dynamically configurable) support of
  5. - 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 }
  1. - the SNMP group
  2. -
  3. - a collection of objects providing basic instrumentation and
  4. - 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 }
  1. - information for notifications
  2. -
  3. - a collection of objects which allow the SNMP entity, when
  4. - supporting a notification originator application,
  5. - 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 }
  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 }
  1. - ::= { snmpTrap 4 } this OID is obsolete
  1. - 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 }
  1. - Note the linkDown NOTIFICATION-TYPE ::= { snmpTraps 3 }
  2. - and the linkUp NOTIFICATION-TYPE ::= { snmpTraps 4 }
  3. - 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 }
  1. - Note the egpNeighborLoss notification is defined
  2. - as { snmpTraps 6 } in RFC 1213
  1. - the set group
  2. -
  3. - a collection of objects which allow several cooperating
  4. - command generator applications to coordinate their use of the
  5. - 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 }
  1. - conformance information
 snmpMIBConformance
                OBJECT IDENTIFIER ::= { snmpMIB 2 }
 snmpMIBCompliances
                OBJECT IDENTIFIER ::= { snmpMIBConformance 1 }
 snmpMIBGroups  OBJECT IDENTIFIER ::= { snmpMIBConformance 2 }
  1. - compliance statements
Presuhn, et al. Standards Track [Page 12] RFC 3418 MIB for SNMP December 2002
  1. - ::= { 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 }
  1. - units of conformance
  1. - ::= { snmpMIBGroups 1 } this OID is obsolete
  2. - ::= { snmpMIBGroups 2 } this OID is obsolete
  3. - ::= { snmpMIBGroups 3 } this OID is obsolete
Presuhn, et al. Standards Track [Page 13] RFC 3418 MIB for SNMP December 2002
  1. - ::= { 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 }
  1. - definitions in RFC 1213 made obsolete by the inclusion of a
  2. - 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 }
  1. - { 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
  1. - { 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:
  1. Corrected typo in copyright statement;
  1. Updated copyright date;
  1. Updated with new editor's name and contact information;
  1. Cosmetic fixes to layout and typography;
  1. Changed title;
  1. Replace introduction with current MIB boilerplate;
  1. Updated references;
  1. Fixed typo in sysORUpTime;
  1. Re-worded description of snmpSilentDrops;
  1. Updated reference to RFC 1573 to 2863;
  1. Added IPR boilerplate as required by RFC 2026;
  1. 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
  1. Clarified descriptions of snmpInBadCommunityNames and
snmpInBadCommunityUses;
  1. Updated module-identity and contact information;
  1. Updated the acknowledgments section;
  1. Replaced references to "manager role", "agent role" and "SNMPv2
entity" with appropriate terms from RFC 2571;
  1. Updated document headers and footers;
  1. Added security considerations, based on current recommendations
for MIB modules;
  1. Added NOTIFICATION-GROUP and OBJECT-GROUP constructs for
NOTIFICATION-TYPEs and OBJECT-TYPEs that were left unreferenced
       in RFC 1907;
  1. Fixed typos in sysServices DESCRIPTION;
  1. Changed description of snmpProxyDrops to use terms from
architecture;
  1. Changed value used in example for sysObjectID;
  1. Added an abstract;
  1. Deprecated the snmpBasicCompliance MODULE-COMPLIANCE, and added
the snmpBasicComplianceRev2 MODULE-COMPLIANCE to take its
       place;
  1. Updated working group mailing list address;
  1. 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]
/data/webs/external/dokuwiki/data/pages/rfc/std/std62.txt · Last modified: 2006/11/28 00:38 (external edit)