home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2572.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  96.3 KB  |  2,468 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            J. Case
  8. Request for Comments: 2572                            SNMP Research Inc.
  9. Obsoletes: 2272                                            D. Harrington
  10. Category: Standards Track                        Cabletron Systems, Inc.
  11.                                                               R. Presuhn
  12.                                                       BMC Software, Inc.
  13.                                                                B. Wijnen
  14.                                                IBM T. J. Watson Research
  15.                                                               April 1999
  16.  
  17.  
  18.                Message Processing and Dispatching for the
  19.                Simple Network Management Protocol (SNMP)
  20.  
  21. Status of this Memo
  22.  
  23.    This document specifies an Internet standards track protocol for the
  24.    Internet community, and requests discussion and suggestions for
  25.    improvements.  Please refer to the current edition of the "Internet
  26.    Official Protocol Standards" (STD 1) for the standardization state
  27.    and status of this protocol.  Distribution of this memo is unlimited.
  28.  
  29. Copyright Notice
  30.  
  31.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  32.  
  33. Abstract
  34.  
  35.    This document describes the Message Processing and Dispatching for
  36.    SNMP messages within the SNMP architecture [RFC2571].  It defines the
  37.    procedures for dispatching potentially multiple versions of SNMP
  38.    messages to the proper SNMP Message Processing Models, and for
  39.    dispatching PDUs to SNMP applications.  This document also describes
  40.    one Message Processing Model - the SNMPv3 Message Processing Model.
  41.  
  42. Table of Contents
  43.  
  44.    1. Introduction ................................................    3
  45.    2. Overview ....................................................    3
  46.    2.1. The Dispatcher.  ..........................................    5
  47.    2.2. Message Processing Subsystem ..............................    5
  48.    3. Elements of Message Processing and Dispatching ..............    5
  49.    3.1. messageProcessingModel ....................................    6
  50.    3.2. pduVersion ................................................    6
  51.    3.3. pduType ...................................................    7
  52.    3.4. sendPduHandle .............................................    7
  53.    4. Dispatcher Elements of Procedure ............................    7
  54.    4.1. Sending an SNMP Message to the Network ....................    7
  55.  
  56.  
  57.  
  58. SNMPv3 Working Group        Standards Track                     [Page 1]
  59.  
  60. RFC 2572           Message Processing and Dispatching           April 1999
  61.  
  62.  
  63.    4.1.1. Sending a Request or Notification .......................    7
  64.    4.1.2. Sending a Response to the Network .......................    9
  65.    4.2. Receiving an SNMP Message from the Network ................   11
  66.    4.2.1. Message Dispatching of received SNMP Messages ...........   11
  67.    4.2.2. PDU Dispatching for Incoming Messages ...................   12
  68.    4.2.2.1. Incoming Requests and Notifications ...................   12
  69.    4.2.2.2. Incoming Responses ....................................   14
  70.    4.3. Application Registration for Handling PDU types ...........   15
  71.    4.4. Application Unregistration for Handling PDU Types .........   16
  72.    5. Definitions .................................................   16
  73.    5.1. Definitions for SNMP Message Processing and Dispatching ...   16
  74.    6. The SNMPv3 Message Format ...................................   20
  75.    6.1. msgVersion ................................................   21
  76.    6.2. msgID .....................................................   21
  77.    6.3. msgMaxSize ................................................   21
  78.    6.4. msgFlags ..................................................   22
  79.    6.5. msgSecurityModel ..........................................   24
  80.    6.6. msgSecurityParameters .....................................   24
  81.    6.7. scopedPduData .............................................   24
  82.    6.8. scopedPDU .................................................   25
  83.    6.8.1. contextEngineID .........................................   25
  84.    6.8.2. contextName .............................................   25
  85.    6.8.3. data ....................................................   25
  86.    7. Elements of Procedure for v3MP ..............................   25
  87.    7.1. Prepare an Outgoing SNMP Message ..........................   36
  88.    7.2. Prepare Data Elements from an Incoming SNMP Message .......   31
  89.    8. Intellectual Property .......................................   37
  90.    9. Acknowledgements ............................................   37
  91.    10. Security Considerations ....................................   39
  92.    11. References .................................................   40
  93.    12. Editors' Addresses .........................................   41
  94.    13. Changes From RFC 2272 ......................................   42
  95.    14. Full Copyright Statement ...................................   44
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. SNMPv3 Working Group        Standards Track                     [Page 2]
  115.  
  116. RFC 2572           Message Processing and Dispatching           April 1999
  117.  
  118.  
  119. 1.  Introduction
  120.  
  121.    The Architecture for describing Internet Management Frameworks
  122.    [RFC2571] describes that an SNMP engine is composed of:
  123.  
  124.         1) a Dispatcher
  125.         2) a Message Processing Subsystem,
  126.         3) a Security Subsystem, and
  127.         4) an Access Control Subsystem.
  128.  
  129.    Applications make use of the services of these subsystems.
  130.  
  131.    It is important to understand the SNMP architecture and its
  132.    terminology to understand where the Message Processing Subsystem and
  133.    Dispatcher described in this document fit into the architecture and
  134.    interact with other subsystems within the architecture.  The reader
  135.    is expected to have read and understood the description of the SNMP
  136.    architecture, defined in [RFC2571].
  137.  
  138.    The Dispatcher in the SNMP engine sends and receives SNMP messages.
  139.    It also dispatches SNMP PDUs to SNMP applications. When an SNMP
  140.    message needs to be prepared or when data needs to be extracted from
  141.    an SNMP message, the Dispatcher delegates these tasks to a message
  142.    version-specific Message Processing Model within the Message
  143.    Processing Subsystem.
  144.  
  145.    A Message Processing Model is responsible for processing a SNMP
  146.    version-specific message and for coordinating the interaction with
  147.    the Security Subsystem to ensure proper security is applied to the
  148.    SNMP message being handled.
  149.  
  150.    Interactions between the Dispatcher, the Message Processing
  151.    Subsystem, and applications are modeled using abstract data elements
  152.    and abstract service interface primitives defined by the SNMP
  153.    architecture.
  154.  
  155.    Similarly, interactions between the Message Processing Subsystem and
  156.    the Security Subsystem are modeled using abstract data elements and
  157.    abstract service interface primitives as defined by the SNMP
  158.    architecture.
  159.  
  160.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  161.    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  162.    document are to be interpreted as described in RFC 2119.
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. SNMPv3 Working Group        Standards Track                     [Page 3]
  171.  
  172. RFC 2572           Message Processing and Dispatching           April 1999
  173.  
  174.  
  175.  
  176. 2.  Overview
  177.  
  178.    The following illustration depicts the Message Processing in relation
  179.    to SNMP applications, the Security Subsystem and Transport Mappings.
  180.  
  181.    +-------------------------------------------------------------------+
  182.    | SNMP Entity                                                       |
  183.    |                                                                   |
  184.    | +---------------------------------------------------------------+ |
  185.    | | Applications                                                  | |
  186.    | | +-----------+  +--------------+                               | |
  187.    | | | Command   |  | Notification |                               | |
  188.    | | | Generator |  | Originator   | +-----------+ +--------------+| |
  189.    | | +-----------+  +--------------+ | Proxy     | | Other         | |
  190.    | | +-----------+  +--------------+ | Forwarder | |Application(s)|| |
  191.    | | | Command   |  | Notification | +-----------+ +--------------+| |
  192.    | | | Responder |  | Receiver     |                               | |
  193.    | | +-----------+  +--------------+                               | |
  194.    | +---------------------------------------------------------------+ |
  195.    |        ^                ^               ^           ^             |
  196.    |        |                |               |           |             |
  197.    |        v                v               v           v             |
  198.    |        +--------+-------+---------------+-----------+             |
  199.    |                 ^                                                 |
  200.    |                 |    +---------------------+  +-----------------+ |
  201.    |                 |    | Message Processing  |  | Security        | |
  202.    | Dispatcher      v    | Subsystem           |  | Subsystem       | |
  203.    | +------------------+ |     +------------+  |  |                 | |
  204.    | | PDU Dispatcher   | |  +->| v1MP     * |<--->| +-------------+ | |
  205.    | |                  | |  |  +------------+  |  | | Other       | | |
  206.    | |                  | |  |  +------------+  |  | | Security    | | |
  207.    | |                  | |  +->| v2cMP    * |<--->| | Model       | | |
  208.    | | Message          | |  |  +------------+  |  | +-------------+ | |
  209.    | | Dispatcher  <-------->+                  |  |                 | |
  210.    | |                  | |  |  +------------+  |  | +-------------+ | |
  211.    | |                  | |  +->| v3MP     * |<--->| | User-based  | | |
  212.    | | Transport        | |  |  +------------+  |  | | Security    | | |
  213.    | | Mapping          | |  |  +------------+  |  | | Model       | | |
  214.    | | (e.g RFC 1906)   | |  +->| otherMP  * |<--->| +-------------+ | |
  215.    | +------------------+ |     +------------+  |  |                 | |
  216.    |          ^           +---------------------+  +-----------------+ |
  217.    |          |                                                        |
  218.    +----------|--------------------------------------------------------+
  219.               v
  220.      +------------------+
  221.      |   Network        |
  222.      +------------------+
  223.  
  224.  
  225.  
  226. SNMPv3 Working Group        Standards Track                     [Page 4]
  227.  
  228. RFC 2572           Message Processing and Dispatching           April 1999
  229.  
  230.  
  231.  
  232. 2.1.  The Dispatcher.
  233.  
  234.    The Dispatcher is a key piece of an SNMP engine. There is only one in
  235.    an SNMP engine, and its job is to dispatch tasks to the multiple
  236.    version-specific Message Processing Models, and to dispatch PDUs to
  237.    various applications.
  238.  
  239.    For outgoing messages, an application provides a PDU to be sent, plus
  240.    the data needed to prepare and send the message, and the application
  241.    specifies which version-specific Message Processing Model will be
  242.    used to prepare the message with the desired security processing.
  243.    Once the message is prepared, the Dispatcher sends the message.
  244.  
  245.    For incoming messages, the Dispatcher determines the SNMP version of
  246.    the incoming message and passes the message to the version-specific
  247.    Message Processing Model to extract the components of the message and
  248.    to coordinate the processing of security services for the message.
  249.    After version-specific processing, the PDU Dispatcher determines
  250.    which application, if any, should receive the PDU for processing and
  251.    forwards it accordingly.
  252.  
  253.    The Dispatcher, while sending and receiving SNMP messages, collects
  254.    statistics about SNMP messages and the behavior of the SNMP engine in
  255.    managed objects to make them accessible to remote SNMP entities.
  256.    This document defines these managed objects, the MIB module which
  257.    contains them, and how these managed objects might be used to provide
  258.    useful management.
  259.  
  260. 2.2.  Message Processing Subsystem
  261.  
  262.    The SNMP Message Processing Subsystem is the part of an SNMP engine
  263.    which interacts with the Dispatcher to handle the version-specific
  264.    SNMP messages. It contains one or more Message Processing Models.
  265.  
  266.    This document describes one Message Processing Model, the SNMPv3
  267.    Message Processing Model, in Section 6. The SNMPv3 Message Processing
  268.    Model is defined in a separate section to show that multiple
  269.    (independent) Message Processing Models can exist at the same time
  270.    and that such Models can be described in different documents. The
  271.    SNMPv3 Message Processing Model can be replaced or supplemented with
  272.    other Message Processing Models in the future. Two Message Processing
  273.    Models which are expected to be developed in the future are the
  274.    SNMPv1 message format [RFC1157] and the SNMPv2c message format
  275.    [RFC1901].  Others may be developed as needed.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. SNMPv3 Working Group        Standards Track                     [Page 5]
  283.  
  284. RFC 2572           Message Processing and Dispatching           April 1999
  285.  
  286.  
  287.  
  288. 3.  Elements of Message Processing and Dispatching
  289.  
  290.    See [RFC2571] for the definitions of
  291.            contextEngineID
  292.            contextName
  293.            scopedPDU
  294.            maxSizeResponseScopedPDU
  295.            securityModel
  296.            securityName
  297.            securityLevel
  298.            messageProcessingModel
  299.  
  300.    For incoming messages, a version-specific message processing module
  301.    provides these values to the Dispatcher. For outgoing messages, an
  302.    application provides these values to the Dispatcher.
  303.  
  304.    For some version-specific processing, the values may be extracted
  305.    from received messages; for other versions, the values may be
  306.    determined by algorithm, or by an implementation-defined mechanism.
  307.    The mechanism by which the value is determined is irrelevant to the
  308.    Dispatcher.
  309.  
  310.    The following additional or expanded definitions are for use within
  311.    the Dispatcher.
  312.  
  313. 3.1.  messageProcessingModel
  314.  
  315.    The value of messageProcessingModel identifies a Message Processing
  316.    Model.  A Message Processing Model describes the version-specific
  317.    procedures for extracting data from messages, generating messages,
  318.    calling upon a securityModel to apply its security services to
  319.    messages, for converting data from a version-specific message format
  320.    into a generic format usable by the Dispatcher, and for converting
  321.    data from Dispatcher format into a version-specific message format.
  322.  
  323. 3.2.  pduVersion
  324.  
  325.    The value of pduVersion represents a specific version of protocol
  326.    operation and its associated PDU formats, such as SNMPv1 or SNMPv2
  327.    [RFC1905].  The values of pduVersion are specific to the version of
  328.    the PDU contained in a message, and the PDUs processed by
  329.    applications. The Dispatcher does not use the value of pduVersion
  330.    directly.
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. SNMPv3 Working Group        Standards Track                     [Page 6]
  339.  
  340. RFC 2572           Message Processing and Dispatching           April 1999
  341.  
  342.  
  343.    An application specifies the pduVersion when it requests the PDU
  344.    Dispatcher to send a PDU to another SNMP engine. The Dispatcher
  345.    passes the pduVersion to a Message Processing Model, so it knows how
  346.    to handle the PDU properly.
  347.  
  348.    For incoming messages, pduVersion is provided to the Dispatcher by a
  349.    version-specific Message Processing module. The PDU Dispatcher passes
  350.    the pduVersion to the application so it knows how to handle the PDU
  351.    properly.  For example, a command responder application needs to know
  352.    whether to use [RFC1905] elements of procedure and syntax instead of
  353.    those specified for SNMPv1.
  354.  
  355. 3.3.  pduType
  356.  
  357.    A value of pduType represents a specific type of protocol operation.
  358.    The values of pduType are specific to the version of the PDU
  359.    contained in a message.
  360.  
  361.    Applications register to support particular pduTypes for particular
  362.    contextEngineIDs.
  363.  
  364.    For incoming messages, pduType is provided to the Dispatcher by a
  365.    version-specific Message Processing module. It is subsequently used
  366.    to dispatch the PDU to the application which registered for the
  367.    pduType for the contextEngineID of the associated scopedPDU.
  368.  
  369. 3.4.  sendPduHandle
  370.  
  371.    This handle is generated for coordinating the processing of requests
  372.    and responses between the SNMP engine and an application. The handle
  373.    must be unique across all version-specific Message Processing Models,
  374.    and is of local significance only.
  375.  
  376. 4.  Dispatcher Elements of Procedure
  377.  
  378.    This section describes the procedures followed by the Dispatcher when
  379.    generating and processing SNMP messages.
  380.  
  381. 4.1.  Sending an SNMP Message to the Network
  382.  
  383.    This section describes the procedure followed by an SNMP engine
  384.    whenever it sends an SNMP message.
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. SNMPv3 Working Group        Standards Track                     [Page 7]
  395.  
  396. RFC 2572           Message Processing and Dispatching           April 1999
  397.  
  398.  
  399.  
  400. 4.1.1.  Sending a Request or Notification
  401.  
  402.    The following procedures are followed by the Dispatcher when an
  403.    application wants to send an SNMP PDU to another (remote)
  404.    application, i.e., to initiate a communication by originating a
  405.    message, such as one containing a request or a trap.
  406.  
  407.    1) The application requests this using the abstract service
  408.       primitive:
  409.  
  410.        statusInformation =              -- sendPduHandle if success
  411.                                         -- errorIndication if failure
  412.          sendPdu(
  413.          IN   transportDomain           -- transport domain to be used
  414.          IN   transportAddress          -- destination network address
  415.          IN   messageProcessingModel    -- typically, SNMP version
  416.          IN   securityModel             -- Security Model to use
  417.          IN   securityName              -- on behalf of this principal
  418.          IN   securityLevel             -- Level of Security requested
  419.          IN   contextEngineID           -- data from/at this entity
  420.          IN   contextName               -- data from/in this context
  421.          IN   pduVersion                -- the version of the PDU
  422.          IN   PDU                       -- SNMP Protocol Data Unit
  423.          IN   expectResponse            -- TRUE or FALSE
  424.               )
  425.  
  426.    2) If the messageProcessingModel value does not represent a Message
  427.       Processing Model known to the Dispatcher, then an errorIndication
  428.       (implementation-dependent) is returned to the calling application.
  429.       No further processing is performed.
  430.  
  431.    3) The Dispatcher generates a sendPduHandle to coordinate subsequent
  432.       processing.
  433.  
  434.    4) The Message Dispatcher sends the request to the version-specific
  435.       Message Processing module identified by messageProcessingModel
  436.       using the abstract service primitive:
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. SNMPv3 Working Group        Standards Track                     [Page 8]
  451.  
  452. RFC 2572           Message Processing and Dispatching           April 1999
  453.  
  454.  
  455.       statusInformation =              - success or error indication
  456.         prepareOutgoingMessage(
  457.         IN   transportDomain           -- as specified by application
  458.         IN   transportAddress          -- as specified by application
  459.         IN   messageProcessingModel    -- as specified by application
  460.         IN   securityModel             -- as specified by application
  461.         IN   securityName              -- as specified by application
  462.         IN   securityLevel             -- as specified by application
  463.         IN   contextEngineID           -- as specified by application
  464.         IN   contextName               -- as specified by application
  465.         IN   pduVersion                -- as specified by application
  466.         IN   PDU                       -- as specified by application
  467.         IN   expectResponse            -- as specified by application
  468.         IN   sendPduHandle             -- as determined in step 3.
  469.         OUT  destTransportDomain       -- destination transport domain
  470.         OUT  destTransportAddress      -- destination transport address
  471.         OUT  outgoingMessage           -- the message to send
  472.         OUT  outgoingMessageLength     -- the message length
  473.              )
  474.  
  475.    5) If the statusInformation indicates an error, the errorIndication
  476.       is returned to the calling application.  No further processing is
  477.       performed.
  478.  
  479.    6) If the statusInformation indicates success, the sendPduHandle is
  480.       returned to the application, and the outgoingMessage is sent via
  481.       the transport specified by the transportDomain to the address
  482.       specified by the transportAddress.
  483.  
  484.    Outgoing Message Processing is complete.
  485.  
  486.  
  487. 4.1.2.  Sending a Response to the Network
  488.  
  489.    The following procedure is followed when an application wants to
  490.    return a response back to the originator of an SNMP Request.
  491.  
  492.    1) An application can request this using the abstract service
  493.       primitive:
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. SNMPv3 Working Group        Standards Track                     [Page 9]
  507.  
  508. RFC 2572           Message Processing and Dispatching           April 1999
  509.  
  510.  
  511.       result =
  512.       returnResponsePdu(
  513.        IN   messageProcessingModel   -- typically, SNMP version
  514.        IN   securityModel            -- Security Model in use
  515.        IN   securityName             -- on behalf of this principal
  516.        IN   securityLevel            -- same as on incoming request
  517.        IN   contextEngineID          -- data from/at this SNMP entity
  518.        IN   contextName              -- data from/in this context
  519.        IN   pduVersion               -- the version of the PDU
  520.        IN   PDU                      -- SNMP Protocol Data Unit
  521.        IN   maxSizeResponseScopedPDU -- maximum size of Response PDU
  522.        IN   stateReference           -- reference to state information
  523.                                      -- as presented with the request
  524.        IN   statusInformation        -- success or errorIndication
  525.        )                             -- (error counter OID and value
  526.                                      -- when errorIndication)
  527.  
  528.    2) The Message Dispatcher sends the request to the appropriate
  529.       Message Processing Model indicated by the received value of
  530.       messageProcessingModel using the abstract service primitive:
  531.  
  532.       result =                        -- SUCCESS or errorIndication
  533.        prepareResponseMessage(
  534.        IN   messageProcessingModel   -- specified by application
  535.        IN   securityModel            -- specified by application
  536.        IN   securityName             -- specified by application
  537.        IN   securityLevel            -- specified by application
  538.        IN   contextEngineID          -- specified by application
  539.        IN   contextName              -- specified by application
  540.        IN   pduVersion               -- specified by application
  541.        IN   PDU                      -- specified by application
  542.        IN   maxSizeResponseScopedPDU -- specified by application
  543.        IN   stateReference           -- specified by application
  544.        IN   statusInformation        -- specified by application
  545.        OUT  destTransportDomain      -- destination transport domain
  546.        OUT  destTransportAddress     -- destination transport address
  547.        OUT  outgoingMessage          -- the message to send
  548.        OUT  outgoingMessageLength    -- the message length
  549.             )
  550.  
  551.    3) If the result is an errorIndication, the errorIndication is
  552.       returned to the calling application.  No further processing is
  553.       performed.
  554.  
  555.    4) If the result is success, the outgoingMessage is sent over the
  556.       transport specified by the transportDomain to the address
  557.       specified by the transportAddress.
  558.  
  559.  
  560.  
  561.  
  562. SNMPv3 Working Group        Standards Track                    [Page 10]
  563.  
  564. RFC 2572           Message Processing and Dispatching           April 1999
  565.  
  566.  
  567.    Message Processing is complete.
  568.  
  569. 4.2.  Receiving an SNMP Message from the Network
  570.  
  571.    This section describes the procedure followed by an SNMP engine
  572.    whenever it receives an SNMP message.
  573.  
  574.    Please note, that for the sake of clarity and to prevent the text
  575.    from being even longer and more complicated, some details were
  576.    omitted from the steps below.  In particular, The elements of
  577.    procedure do not always explicitly indicate when state information
  578.    needs to be released. The general rule is that if state information
  579.    is available when a message is to be "discarded without further
  580.    processing", then the state information must also be released at that
  581.    same time.
  582.  
  583. 4.2.1.  Message Dispatching of received SNMP Messages
  584.  
  585.    1) The snmpInPkts counter [RFC1907] is incremented.
  586.  
  587.    2) The version of the SNMP message is determined in an
  588.       implementation-dependent manner.  If the packet cannot be
  589.       sufficiently parsed to determine the version of the SNMP message,
  590.       then the snmpInASNParseErrs [RFC1907] counter is incremented, and
  591.       the message is discarded without further processing.  If the
  592.       version is not supported, then the snmpInBadVersions [RFC1907]
  593.       counter is incremented, and the message is discarded without
  594.       further processing.
  595.  
  596.    3) The origin transportDomain and origin transportAddress are
  597.       determined.
  598.  
  599.    4) The message is passed to the version-specific Message Processing
  600.       Model which returns the abstract data elements required by the
  601.       Dispatcher.  This is performed using the abstract service
  602.       primitive:
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. SNMPv3 Working Group        Standards Track                    [Page 11]
  619.  
  620. RFC 2572           Message Processing and Dispatching           April 1999
  621.  
  622.  
  623.       result =                        -- SUCCESS or errorIndication
  624.         prepareDataElements(
  625.         IN   transportDomain          -- origin as determined in step 3.
  626.         IN   transportAddress         -- origin as determined in step 3.
  627.         IN   wholeMsg                 -- as received from the network
  628.         IN   wholeMsgLength           -- as received from the network
  629.         OUT  messageProcessingModel   -- typically, SNMP version
  630.         OUT  securityModel            -- Security Model specified
  631.         OUT  securityName             -- on behalf of this principal
  632.         OUT  securityLevel            -- Level of Security specified
  633.         OUT  contextEngineID          -- data from/at this entity
  634.         OUT  contextName              -- data from/in this context
  635.         OUT  pduVersion               -- the version of the PDU
  636.         OUT  PDU                      -- SNMP Protocol Data Unit
  637.         OUT  pduType                  -- SNMP PDU type
  638.         OUT  sendPduHandle            -- handle for a matched request
  639.         OUT  maxSizeResponseScopedPDU -- maximum size of Response PDU
  640.         OUT  statusInformation        -- success or errorIndication
  641.                                       -- (error counter OID and value
  642.                                       -- when errorIndication)
  643.         OUT  stateReference           -- reference to state information
  644.                                       -- to be used for a possible
  645.              )                        -- Response
  646.  
  647.    5) If the result is a FAILURE errorIndication, the message is
  648.       discarded without further processing.
  649.  
  650.    6) At this point, the abstract data elements have been prepared and
  651.       processing continues as described in Section 4.2.2, PDU
  652.       Dispatching for Incoming Messages.
  653.  
  654. 4.2.2.  PDU Dispatching for Incoming Messages
  655.  
  656.    The elements of procedure for the dispatching of PDUs depends on the
  657.    value of sendPduHandle.  If the value of sendPduHandle is <none>,
  658.    then this is a request or notification and the procedures specified
  659.    in Section 4.2.2.1 apply.  If the value of snmpPduHandle is not
  660.    <none>, then this is a response and the procedures specified in
  661.    Section 4.2.2.2 apply.
  662.  
  663. 4.2.2.1.  Incoming Requests and Notifications
  664.  
  665.    The following procedures are followed for the dispatching of PDUs
  666.    when the value of sendPduHandle is <none>, indicating this is a
  667.    request or notification.
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. SNMPv3 Working Group        Standards Track                    [Page 12]
  675.  
  676. RFC 2572           Message Processing and Dispatching           April 1999
  677.  
  678.  
  679.    1) The combination of contextEngineID and pduType is used to
  680.       determine which application has registered for this request or
  681.       notification.
  682.  
  683.    2) If no application has registered for the combination, then
  684.  
  685.       a) The snmpUnknownPDUHandlers counter is incremented.
  686.  
  687.       b) A Response message is generated using the abstract service
  688.          primitive:
  689.  
  690.          result =                         -- SUCCESS or FAILURE
  691.          prepareResponseMessage(
  692.          IN   messageProcessingModel    -- as provided by MP module
  693.          IN   securityModel             -- as provided by MP module
  694.          IN   securityName              -- as provided by MP module
  695.          IN   securityLevel             -- as provided by MP module
  696.          IN   contextEngineID           -- as provided by MP module
  697.          IN   contextName               -- as provided by MP module
  698.          IN   pduVersion                -- as provided by MP module
  699.          IN   PDU                       -- as provided by MP module
  700.          IN   maxSizeResponseScopedPDU  -- as provided by MP module
  701.          IN   stateReference            -- as provided by MP module
  702.          IN   statusInformation         -- errorIndication plus
  703.                                         -- snmpUnknownPDUHandlers OID
  704.                                         -- value pair.
  705.          OUT  destTransportDomain       -- destination transportDomain
  706.          OUT  destTransportAddress      -- destination transportAddress
  707.          OUT  outgoingMessage           -- the message to send
  708.          OUT  outgoingMessageLength     -- its length
  709.          )
  710.  
  711.       c) If the result is SUCCESS, then the prepared message is sent to
  712.          the originator of the request as identified by the
  713.          transportDomain and transportAddress.
  714.  
  715.       d) The incoming message is discarded without further processing.
  716.          Message Processing for this message is complete.
  717.  
  718.    3) The PDU is dispatched to the application, using the abstract
  719.       service primitive:
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. SNMPv3 Working Group        Standards Track                    [Page 13]
  731.  
  732. RFC 2572           Message Processing and Dispatching           April 1999
  733.  
  734.  
  735.       processPdu(                     -- process Request/Notification
  736.         IN   messageProcessingModel   -- as provided by MP module
  737.         IN   securityModel            -- as provided by MP module
  738.         IN   securityName             -- as provided by MP module
  739.         IN   securityLevel            -- as provided by MP module
  740.         IN   contextEngineID          -- as provided by MP module
  741.         IN   contextName              -- as provided by MP module
  742.         IN   pduVersion               -- as provided by MP module
  743.         IN   PDU                      -- as provided by MP module
  744.         IN   maxSizeResponseScopedPDU -- as provided by MP module
  745.         IN   stateReference           -- as provided by MP module
  746.                                       -- needed when sending response
  747.              )
  748.  
  749.       Message processing for this message is complete.
  750.  
  751. 4.2.2.2.  Incoming Responses
  752.  
  753.    The following procedures are followed for the dispatching of PDUs
  754.    when the value of sendPduHandle is not <none>, indicating this is a
  755.    response.
  756.  
  757.       1) The value of sendPduHandle is used to determine, in an
  758.          implementation-defined manner, which application is waiting for
  759.          a response associated with this sendPduHandle.
  760.  
  761.       2) If no waiting application is found, the message is discarded
  762.          without further processing, and the stateReference is released.
  763.          The snmpUnknownPDUHandlers counter is incremented.  Message
  764.          Processing is complete for this message.
  765.  
  766.       3) Any cached information, including stateReference, about the
  767.          message is discarded.
  768.  
  769.       4) The response is dispatched to the application using the
  770.          abstract service primitive:
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. SNMPv3 Working Group        Standards Track                    [Page 14]
  787.  
  788. RFC 2572           Message Processing and Dispatching           April 1999
  789.  
  790.  
  791.          processResponsePdu(              -- process Response PDU
  792.            IN   messageProcessingModel    -- provided by the MP module
  793.            IN   securityModel             -- provided by the MP module
  794.            IN   securityName              -- provided by the MP module
  795.            IN   securityLevel             -- provided by the MP module
  796.            IN   contextEngineID           -- provided by the MP module
  797.            IN   contextName               -- provided by the MP module
  798.            IN   pduVersion                -- provided by the MP module
  799.            IN   PDU                       -- provided by the MP module
  800.            IN   statusInformation         -- provided by the MP module
  801.            IN   sendPduHandle             -- provided by the MP module
  802.                 )
  803.  
  804.          Message Processing is complete for this message.
  805.  
  806. 4.3.  Application Registration for Handling PDU types
  807.  
  808.    Applications that want to process certain PDUs must register with the
  809.    PDU Dispatcher. Applications specify the combination of
  810.    contextEngineID and pduType(s) for which they want to take
  811.    responsibility
  812.  
  813.    1) An application registers according to the abstract interface
  814.       primitive:
  815.  
  816.       statusInformation =           -- success or errorIndication
  817.         registerContextEngineID(
  818.         IN   contextEngineID        -- take responsibility for this one
  819.         IN   pduType                -- the pduType(s) to be registered
  820.              )
  821.  
  822.       Note: implementations may provide a means of requesting
  823.       registration for simultaneous multiple contextEngineID values,
  824.       e.g., all contextEngineID values, and may also provide means for
  825.       requesting simultaneous registration for multiple values of
  826.       pduType.
  827.  
  828.    2) The parameters may be checked for validity; if they are not, then
  829.       an errorIndication (invalidParameter) is returned to the
  830.       application.
  831.  
  832.    3) Each combination of contextEngineID and pduType can be registered
  833.       only once.  If another application has already registered for the
  834.       specified combination, then an errorIndication (alreadyRegistered)
  835.       is returned to the application.
  836.  
  837.    4) Otherwise, the registration is saved so that SNMP PDUs can be
  838.       dispatched to this application.
  839.  
  840.  
  841.  
  842. SNMPv3 Working Group        Standards Track                    [Page 15]
  843.  
  844. RFC 2572           Message Processing and Dispatching           April 1999
  845.  
  846.  
  847. 4.4.  Application Unregistration for Handling PDU Types
  848.  
  849.    Applications that no longer want to process certain PDUs must
  850.    unregister with the PDU Dispatcher.
  851.  
  852.    1) An application unregisters using the abstract service primitive:
  853.  
  854.       unregisterContextEngineID(
  855.        IN   contextEngineID        -- give up responsibility for this
  856.        IN   pduType                -- the pduType(s) to be unregistered
  857.              )
  858.       Note: implementations may provide means for requesting
  859.       unregistration for simultaneous multiple contextEngineID values,
  860.       e.g., all contextEngineID values, and may also provide means for
  861.       requesting simultaneous unregistration for multiple values of
  862.       pduType.
  863.  
  864.    2) If the contextEngineID and pduType combination has been
  865.       registered, then the registration is deleted.
  866.  
  867.       If no such registration exists, then the request is ignored.
  868.  
  869. 5.  Definitions
  870.  
  871. 5.1.  Definitions for SNMP Message Processing and Dispatching
  872.  
  873.    SNMP-MPD-MIB DEFINITIONS ::= BEGIN
  874.  
  875.    IMPORTS
  876.        MODULE-COMPLIANCE, OBJECT-GROUP         FROM SNMPv2-CONF
  877.        MODULE-IDENTITY, OBJECT-TYPE,
  878.        snmpModules, Counter32                  FROM SNMPv2-SMI;
  879.  
  880.    snmpMPDMIB MODULE-IDENTITY
  881.        LAST-UPDATED "9905041636Z"              -- 4 April 1999
  882.        ORGANIZATION "SNMPv3 Working Group"
  883.        CONTACT-INFO "WG-EMail:   snmpv3@lists.tislabs.com
  884.                      Subscribe:  majordomo@lists.tislabs.com
  885.                                  In message body:  subscribe snmpv3
  886.  
  887.                      Chair:      Russ Mundy
  888.                                  TIS Labs at Network Associates
  889.                      postal:     3060 Washington Road
  890.                                  Glenwood, MD 21738
  891.                                  USA
  892.                      EMail:      mundy@tislabs.com
  893.                      phone:      +1 301-854-6889
  894.  
  895.  
  896.  
  897.  
  898. SNMPv3 Working Group        Standards Track                    [Page 16]
  899.  
  900. RFC 2572           Message Processing and Dispatching           April 1999
  901.  
  902.  
  903.                      Co-editor:  Jeffrey Case
  904.                                  SNMP Research, Inc.
  905.                      postal:     3001 Kimberlin Heights Road
  906.                                  Knoxville, TN 37920-9716
  907.                                  USA
  908.                      EMail:      case@snmp.com
  909.                      phone:      +1 423-573-1434
  910.  
  911.                      Co-editor   Dave Harrington
  912.                                  Cabletron Systems, Inc.
  913.                      postal:     Post Office Box 5005
  914.                                  MailStop: Durham
  915.                                  35 Industrial Way
  916.                                  Rochester, NH 03867-5005
  917.                                  USA
  918.                      EMail:      dbh@ctron.com
  919.                      phone:      +1 603-337-7357
  920.  
  921.                      Co-editor:  Randy Presuhn
  922.                                  BMC Software, Inc.
  923.                      postal:     965 Stewart Drive
  924.                                  Sunnyvale, CA 94086
  925.                                  USA
  926.                      EMail:      randy_presuhn@bmc.com
  927.                      phone:      +1 408-616-3100
  928.  
  929.                      Co-editor:  Bert Wijnen
  930.                                  IBM T. J. Watson Research
  931.                      postal:     Schagen 33
  932.                                  3461 GL Linschoten
  933.                                  Netherlands
  934.                      EMail:      wijnen@vnet.ibm.com
  935.                      phone:      +31 348-432-794
  936.  
  937.                     "
  938.        DESCRIPTION  "The MIB for Message Processing and Dispatching"
  939.        REVISION     "9905041636Z"              -- 4 April 1999
  940.        DESCRIPTION  "Updated addresses, published as RFC 2572."
  941.        REVISION     "9709300000Z"              -- 30 September 1997
  942.        DESCRIPTION  "Original version, published as RFC 2272."
  943.        ::= { snmpModules 11 }
  944.  
  945.    -- Administrative assignments ***************************************
  946.  
  947.    snmpMPDAdmin           OBJECT IDENTIFIER ::= { snmpMPDMIB 1 }
  948.    snmpMPDMIBObjects      OBJECT IDENTIFIER ::= { snmpMPDMIB 2 }
  949.    snmpMPDMIBConformance  OBJECT IDENTIFIER ::= { snmpMPDMIB 3 }
  950.  
  951.  
  952.  
  953.  
  954. SNMPv3 Working Group        Standards Track                    [Page 17]
  955.  
  956. RFC 2572           Message Processing and Dispatching           April 1999
  957.  
  958.  
  959.    -- Statistics for SNMP Messages *************************************
  960.  
  961.    snmpMPDStats           OBJECT IDENTIFIER ::= { snmpMPDMIBObjects 1 }
  962.  
  963.    snmpUnknownSecurityModels OBJECT-TYPE
  964.        SYNTAX       Counter32
  965.        MAX-ACCESS   read-only
  966.        STATUS       current
  967.        DESCRIPTION "The total number of packets received by the SNMP
  968.                     engine which were dropped because they referenced a
  969.                     securityModel that was not known to or supported by
  970.                     the SNMP engine.
  971.                    "
  972.        ::= { snmpMPDStats 1 }
  973.  
  974.    snmpInvalidMsgs OBJECT-TYPE
  975.        SYNTAX       Counter32
  976.        MAX-ACCESS   read-only
  977.        STATUS       current
  978.        DESCRIPTION "The total number of packets received by the SNMP
  979.                     engine which were dropped because there were invalid
  980.                     or inconsistent components in the SNMP message.
  981.                    "
  982.        ::= { snmpMPDStats 2 }
  983.  
  984.    snmpUnknownPDUHandlers OBJECT-TYPE
  985.        SYNTAX       Counter32
  986.        MAX-ACCESS   read-only
  987.        STATUS       current
  988.        DESCRIPTION "The total number of packets received by the SNMP
  989.                     engine which were dropped because the PDU contained
  990.                     in the packet could not be passed to an application
  991.                     responsible for handling the pduType, e.g. no SNMP
  992.                     application had registered for the proper
  993.                     combination of the contextEngineID and the pduType.
  994.                    "
  995.        ::= { snmpMPDStats 3 }
  996.  
  997.    -- Conformance information ******************************************
  998.  
  999.    snmpMPDMIBCompliances OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 1}
  1000.    snmpMPDMIBGroups      OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 2}
  1001.  
  1002.    -- Compliance statements
  1003.  
  1004.    snmpMPDCompliance MODULE-COMPLIANCE
  1005.        STATUS       current
  1006.        DESCRIPTION "The compliance statement for SNMP entities which
  1007.  
  1008.  
  1009.  
  1010. SNMPv3 Working Group        Standards Track                    [Page 18]
  1011.  
  1012. RFC 2572           Message Processing and Dispatching           April 1999
  1013.  
  1014.  
  1015.                     implement the SNMP-MPD-MIB.
  1016.                    "
  1017.  
  1018.        MODULE    -- this module
  1019.            MANDATORY-GROUPS { snmpMPDGroup }
  1020.  
  1021.        ::= { snmpMPDMIBCompliances 1 }
  1022.  
  1023.    snmpMPDGroup OBJECT-GROUP
  1024.        OBJECTS {
  1025.                  snmpUnknownSecurityModels,
  1026.                  snmpInvalidMsgs,
  1027.                  snmpUnknownPDUHandlers
  1028.                }
  1029.        STATUS       current
  1030.        DESCRIPTION "A collection of objects providing for remote
  1031.                     monitoring of the SNMP Message Processing and
  1032.                     Dispatching process.
  1033.                    "
  1034.        ::= { snmpMPDMIBGroups 1 }
  1035.  
  1036.    END
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. SNMPv3 Working Group        Standards Track                    [Page 19]
  1067.  
  1068. RFC 2572           Message Processing and Dispatching           April 1999
  1069.  
  1070.  
  1071. 6.  The SNMPv3 Message Format
  1072.  
  1073.    This section defines the SNMPv3 message format and the corresponding
  1074.    SNMP version 3 Message Processing Model (v3MP).
  1075.    SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN
  1076.  
  1077.        SNMPv3Message ::= SEQUENCE {
  1078.            -- identify the layout of the SNMPv3Message
  1079.            -- this element is in same position as in SNMPv1
  1080.            -- and SNMPv2c, allowing recognition
  1081.            -- the value 3 is used for snmpv3
  1082.            msgVersion INTEGER ( 0 .. 2147483647 ),
  1083.            -- administrative parameters
  1084.            msgGlobalData HeaderData,
  1085.            -- security model-specific parameters
  1086.            -- format defined by Security Model
  1087.            msgSecurityParameters OCTET STRING,
  1088.            msgData  ScopedPduData
  1089.        }
  1090.  
  1091.        HeaderData ::= SEQUENCE {
  1092.            msgID      INTEGER (0..2147483647),
  1093.            msgMaxSize INTEGER (484..2147483647),
  1094.  
  1095.            msgFlags   OCTET STRING (SIZE(1)),
  1096.                       --  .... ...1   authFlag
  1097.                       --  .... ..1.   privFlag
  1098.                       --  .... .1..   reportableFlag
  1099.                       --              Please observe:
  1100.                       --  .... ..00   is OK, means noAuthNoPriv
  1101.                       --  .... ..01   is OK, means authNoPriv
  1102.                       --  .... ..10   reserved, must NOT be used.
  1103.                       --  .... ..11   is OK, means authPriv
  1104.  
  1105.            msgSecurityModel INTEGER (1..2147483647)
  1106.        }
  1107.  
  1108.        ScopedPduData ::= CHOICE {
  1109.            plaintext    ScopedPDU,
  1110.            encryptedPDU OCTET STRING  -- encrypted scopedPDU value
  1111.        }
  1112.  
  1113.        ScopedPDU ::= SEQUENCE {
  1114.            contextEngineID  OCTET STRING,
  1115.            contextName      OCTET STRING,
  1116.            data             ANY -- e.g., PDUs as defined in RFC 1905
  1117.        }
  1118.    END
  1119.  
  1120.  
  1121.  
  1122. SNMPv3 Working Group        Standards Track                    [Page 20]
  1123.  
  1124. RFC 2572           Message Processing and Dispatching           April 1999
  1125.  
  1126.  
  1127.  
  1128. 6.1.  msgVersion
  1129.  
  1130.    The msgVersion field is set to snmpv3(3) and identifies the message
  1131.    as an SNMP version 3 Message.
  1132.  
  1133. 6.2.  msgID
  1134.  
  1135.    The msgID is used between two SNMP entities to coordinate request
  1136.    messages and responses, and by the v3MP to coordinate the processing
  1137.    of the message by different subsystem models within the architecture.
  1138.  
  1139.    Values for msgID SHOULD be generated in a manner that avoids re-use
  1140.    of any outstanding values.  Doing so provides protection against some
  1141.    replay attacks.  One possible implementation strategy would be to use
  1142.    the low-order bits of snmpEngineBoots [RFC2571] as the high-order
  1143.    portion of the msgID value and a monotonically increasing integer for
  1144.    the low-order portion of msgID.
  1145.  
  1146.    Note that the request-id in a PDU may be used by SNMP applications to
  1147.    identify the PDU; the msgID is used by the engine to identify the
  1148.    message which carries a PDU. The engine needs to identify the message
  1149.    even if decryption of the PDU (and request-id) fails.  No assumption
  1150.    should be made that the value of the msgID and the value of the
  1151.    request-id are equivalent.
  1152.  
  1153.    The value of the msgID field for a response takes the value of the
  1154.    msgID field from the message to which it is a response.  By use of
  1155.    the msgID value, an engine can distinguish the (potentially multiple)
  1156.    outstanding requests, and thereby correlate incoming responses with
  1157.    outstanding requests.  In cases where an unreliable datagram service
  1158.    is used, the msgID also provides a simple means of identifying
  1159.    messages duplicated by the network.  If a request is retransmitted, a
  1160.    new msgID value SHOULD be used for each retransmission.
  1161.  
  1162. 6.3.  msgMaxSize
  1163.  
  1164.    The msgMaxSize field of the message conveys the maximum message size
  1165.    supported by the sender of the message, i.e., the maximum message
  1166.    size that the sender can accept when another SNMP engine sends an
  1167.    SNMP message (be it a response or any other message) to the sender of
  1168.    this message on the transport in use for this message.
  1169.  
  1170.    When an SNMP message is being generated, the msgMaxSize is provided
  1171.    by the SNMP engine which generates the message.  At the receiving
  1172.    SNMP engine, the msgMaxSize is used to determine the maximum message
  1173.    size the sender can accommodate.
  1174.  
  1175.  
  1176.  
  1177.  
  1178. SNMPv3 Working Group        Standards Track                    [Page 21]
  1179.  
  1180. RFC 2572           Message Processing and Dispatching           April 1999
  1181.  
  1182.  
  1183. 6.4.  msgFlags
  1184.  
  1185.    The msgFlags field of the message contains several bit fields which
  1186.    control processing of the message.
  1187.  
  1188.    The reportableFlag is a secondary aid in determining whether a Report
  1189.    PDU must be sent.  It is only used in cases where the PDU portion of
  1190.    a message cannot be decoded, due to, for example, an incorrect
  1191.    encryption key.  If the PDU can be decoded, the PDU type forms the
  1192.    basis for decisions on sending Report PDUs.
  1193.  
  1194.    When the reportableFlag is used, if its value is one, a Report PDU
  1195.    MUST be returned to the sender under those conditions which can cause
  1196.    the generation of Report PDUs.  Similarly, when the reportableFlag is
  1197.    used and its value is zero, then a Report PDU MUST NOT be sent.  The
  1198.    reportableFlag MUST always be zero when the message contains a PDU
  1199.    from the Unconfirmed Class, such as a Report PDU, a response-type PDU
  1200.    (such as a Response PDU), or an unacknowledged notification-type PDU
  1201.    (such as an SNMPv2-trap PDU).  The reportableFlag MUST always be one
  1202.    for a PDU from the Confirmed Class, include request-type PDUs (such
  1203.    as a Get PDU) and an acknowledged notification-type PDUs (such as an
  1204.    Inform PDU).
  1205.  
  1206.    If the reportableFlag is set to one for a message containing a PDU
  1207.    from the Unconfirmed Class, such as a Report PDU, a response-type PDU
  1208.    (such as a Response PDU), or an unacknowledged notification-type PDU
  1209.    (such as an SNMPv2-trap PDU), then the receiver of that message MUST
  1210.    process it as though the reportableFlag had been set to zero.
  1211.  
  1212.    If the reportableFlag is set to zero for a message containing a
  1213.    request-type PDU (such as a Get PDU) or an acknowledged
  1214.    notification-type PDU (such as an Inform PDU), then the receiver of
  1215.    that message must process it as though the reportableFlag had been
  1216.    set to one.
  1217.  
  1218.    Report PDUs are generated directly by the SNMPv3 Message Processing
  1219.    Model, and support engine-to-engine communications, but may be passed
  1220.    to applications for processing.
  1221.  
  1222.    An SNMP engine that receives a reportPDU may use it to determine what
  1223.    kind of problem was detected by the remote SNMP engine.  It can do so
  1224.    based on the error counter included as the first (and only) varBind
  1225.    of the reportPDU.  Based on the detected error, the SNMP engine may
  1226.    try to send a corrected SNMP message.  If that is not possible, it
  1227.    may pass an indication of the error to the application on whose
  1228.    behalf the failed SNMP request was issued.
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. SNMPv3 Working Group        Standards Track                    [Page 22]
  1235.  
  1236. RFC 2572           Message Processing and Dispatching           April 1999
  1237.  
  1238.  
  1239.    The authFlag and privFlag portions of the msgFlags field are set by
  1240.    the sender to indicate the securityLevel that was applied to the
  1241.    message before it was sent on the wire.  The receiver of the message
  1242.    MUST apply the same securityLevel when the message is received and
  1243.    the contents are being processed.
  1244.  
  1245.    There are three securityLevels, namely noAuthNoPriv, which is less
  1246.    than authNoPriv, which is in turn less than authPriv.  See the SNMP
  1247.    architecture document [RFC2571] for details about the securityLevel.
  1248.  
  1249.    a) authFlag
  1250.  
  1251.       If the authFlag is set to one, then the securityModel used by the
  1252.       SNMP engine which sent the message MUST identify the securityName
  1253.       on whose behalf the SNMP message was generated and MUST provide,
  1254.       in a securityModel-specific manner, sufficient data for the
  1255.       receiver of the message to be able to authenticate that
  1256.       identification.  In general, this authentication will allow the
  1257.       receiver to determine with reasonable certainty that the message
  1258.       was:
  1259.  
  1260.       -  sent on behalf of the principal associated with the
  1261.          securityName,
  1262.  
  1263.       -  was not redirected,
  1264.  
  1265.       -  was not modified in transit, and
  1266.  
  1267.       -  was not replayed.
  1268.  
  1269.       If the authFlag is zero, then the securityModel used by the SNMP
  1270.       engine which sent the message must identify the securityName on
  1271.       whose behalf the SNMP message was generated but it does not need
  1272.       to provide sufficient data for the receiver of the message to
  1273.       authenticate the identification, as there is no need to
  1274.       authenticate the message in this case.
  1275.  
  1276.    b) privFlag
  1277.  
  1278.       If the privFlag is set, then the securityModel used by the SNMP
  1279.       engine which sent the message MUST also protect the scopedPDU in
  1280.       an SNMP message from disclosure, i.e., it MUST encrypt/decrypt the
  1281.       scopedPDU. If the privFlag is zero, then the securityModel in use
  1282.       does not need to protect the data from disclosure.
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. SNMPv3 Working Group        Standards Track                    [Page 23]
  1291.  
  1292. RFC 2572           Message Processing and Dispatching           April 1999
  1293.  
  1294.  
  1295.       It is an explicit requirement of the SNMP architecture that if
  1296.       privacy is selected, then authentication is also required.  That
  1297.       means that if the privFlag is set, then the authFlag MUST also be
  1298.       set to one.
  1299.  
  1300.       The combination of the authFlag and the privFlag comprises a Level
  1301.       of Security as follows:
  1302.          authFlag zero, privFlag zero -> securityLevel is noAuthNoPriv
  1303.          authFlag zero, privFlag one  -> invalid combination, see below
  1304.          authFlag one,  privFlag zero -> securityLevel is authNoPriv
  1305.          authFlag one,  privFlag one  -> securityLevel is authPriv
  1306.  
  1307.    The elements of procedure (see below) describe the action to be taken
  1308.    when the invalid combination of authFlag equal to zero and privFlag
  1309.    equal to one is encountered.
  1310.  
  1311.    The remaining bits in msgFlags are reserved, and MUST be set to zero
  1312.    when sending a message and SHOULD be ignored when receiving a
  1313.    message.
  1314.  
  1315. 6.5.  msgSecurityModel
  1316.  
  1317.    The v3MP supports the concurrent existence of multiple Security
  1318.    Models to provide security services for SNMPv3 messages.  The
  1319.    msgSecurityModel field in an SNMPv3 Message identifies which Security
  1320.    Model was used by the sender to generate the message and therefore
  1321.    which securityModel must be used by the receiver to perform security
  1322.    processing for the message.  The mapping to the appropriate
  1323.    securityModel implementation within an SNMP engine is accomplished in
  1324.    an implementation-dependent manner.
  1325.  
  1326. 6.6.  msgSecurityParameters
  1327.  
  1328.    The msgSecurityParameters field of the SNMPv3 Message is used for
  1329.    communication between the Security Model modules in the sending and
  1330.    receiving SNMP engines. The data in the msgSecurityParameters field
  1331.    is used exclusively by the Security Model, and the contents and
  1332.    format of the data is defined by the Security Model.  This OCTET
  1333.    STRING is not interpreted by the v3MP, but is passed to the local
  1334.    implementation of the Security Model indicated by the
  1335.    msgSecurityModel field in the message.
  1336.  
  1337. 6.7.  scopedPduData
  1338.  
  1339.    The scopedPduData field represents either the plain text scopedPDU if
  1340.    the privFlag in the msgFlags is zero, or it represents an
  1341.    encryptedPDU (encoded as an OCTET STRING) which must be decrypted by
  1342.    the securityModel in use to produce a plaintext scopedPDU.
  1343.  
  1344.  
  1345.  
  1346. SNMPv3 Working Group        Standards Track                    [Page 24]
  1347.  
  1348. RFC 2572           Message Processing and Dispatching           April 1999
  1349.  
  1350.  
  1351. 6.8.  scopedPDU
  1352.  
  1353.    The scopedPDU contains information to identify an administratively
  1354.    unique context and a PDU. The object identifiers in the PDU refer to
  1355.    managed objects which are (expected to be) accessible within the
  1356.    specified context.
  1357.  
  1358. 6.8.1.  contextEngineID
  1359.  
  1360.    The contextEngineID in the SNMPv3 message, uniquely identifies,
  1361.    within an administrative domain, an SNMP entity that may realize an
  1362.    instance of a context with a particular contextName.
  1363.  
  1364.    For incoming messages, the contextEngineID is used in conjunction
  1365.    with pduType to determine to which application the scopedPDU will be
  1366.    sent for processing.
  1367.  
  1368.    For outgoing messages, the v3MP sets the contextEngineID to the value
  1369.    provided by the application in the request for a message to be sent.
  1370.  
  1371. 6.8.2.  contextName
  1372.  
  1373.    The contextName field in an SNMPv3 message, in conjunction with the
  1374.    contextEngineID field, identifies the particular context associated
  1375.    with the management information contained in the PDU portion of the
  1376.    message.  The contextName is unique within the SNMP entity specified
  1377.    by the contextEngineID, which may realize the managed objects
  1378.    referenced within the PDU.  An application which originates a message
  1379.    provides the value for the contextName field and this value may be
  1380.    used during processing by an application at the receiving SNMP
  1381.    Engine.
  1382.  
  1383. 6.8.3.  data
  1384.  
  1385.    The data field of the SNMPv3 Message contains the PDU.  Among other
  1386.    things, the PDU contains the PDU type that is used by the v3MP to
  1387.    determine the type of the incoming SNMP message.  The v3MP specifies
  1388.    that the PDU must be one of those specified in [RFC1905].
  1389.  
  1390. 7.  Elements of Procedure for v3MP
  1391.  
  1392.    This section describes the procedures followed by an SNMP engine when
  1393.    generating and processing SNMP messages according to the SNMPv3
  1394.    Message Processing Model.
  1395.  
  1396.    Please note, that for the sake of clarity and to prevent the text
  1397.    from being even longer and more complicated, some details were
  1398.    omitted from the steps below.
  1399.  
  1400.  
  1401.  
  1402. SNMPv3 Working Group        Standards Track                    [Page 25]
  1403.  
  1404. RFC 2572           Message Processing and Dispatching           April 1999
  1405.  
  1406.  
  1407.       a) Some steps specify that when some error conditions are
  1408.          encountered when processing a received message, a message
  1409.          containing a Report PDU is generated and the received message
  1410.          is discarded without further processing.  However, a Report-PDU
  1411.          must not be generated unless the PDU causing generation of the
  1412.          Report PDU can be determine to be a member of the Confirmed
  1413.          Class, or the reportableFlag is set to one and the PDU class
  1414.          cannot be determined.
  1415.  
  1416.       b) The elements of procedure do not always explicitly indicate
  1417.          when state information needs to be released. The general rule
  1418.          is that if state information is available when a message is to
  1419.          be "discarded without further processing", then the state
  1420.          information should also be released at that same time.
  1421.  
  1422. 7.1.  Prepare an Outgoing SNMP Message
  1423.  
  1424.    This section describes the procedure followed to prepare an SNMPv3
  1425.    message from the data elements passed by the Message Dispatcher.
  1426.  
  1427.    1) The Message Dispatcher may request that an SNMPv3 message
  1428.       containing a Read Class, Write Class, or Notification Class PDU be
  1429.       prepared for sending.
  1430.  
  1431.       a) It makes such a request according to the abstract service
  1432.          primitive:
  1433.  
  1434.          statusInformation =           -- success or errorIndication
  1435.            prepareOutgoingMessage(
  1436.            IN   transportDomain        -- requested transport domain
  1437.            IN   transportAddress       -- requested destination address
  1438.            IN   messageProcessingModel -- typically, SNMP version
  1439.            IN   securityModel          -- Security Model to use
  1440.            IN   securityName           -- on behalf of this principal
  1441.            IN   securityLevel          -- Level of Security requested
  1442.            IN   contextEngineID        -- data from/at this entity
  1443.            IN   contextName            -- data from/in this context
  1444.            IN   pduVersion             -- version of the PDU
  1445.            IN   PDU                    -- SNMP Protocol Data Unit
  1446.            IN   expectResponse         -- TRUE or FALSE *
  1447.            IN   sendPduHandle          -- the handle for matching
  1448.                                        -- incoming responses
  1449.            OUT  destTransportDomain    -- destination transport domain
  1450.            OUT  destTransportAddress   -- destination transport address
  1451.            OUT  outgoingMessage        -- the message to send
  1452.            OUT  outgoingMessageLength  -- the length of the message
  1453.            )
  1454.  
  1455.  
  1456.  
  1457.  
  1458. SNMPv3 Working Group        Standards Track                    [Page 26]
  1459.  
  1460. RFC 2572           Message Processing and Dispatching           April 1999
  1461.  
  1462.  
  1463.       *  The SNMPv3 Message Processing Model does not use the values of
  1464.          expectResponse or pduVersion.
  1465.  
  1466.       b) A unique msgID is generated.  The number used for msgID should
  1467.          not have been used recently, and must not be the same as was
  1468.          used for any outstanding request.
  1469.  
  1470.    2) The Message Dispatcher may request that an SNMPv3 message
  1471.       containing a Response Class or Internal Class PDU be prepared for
  1472.       sending.
  1473.  
  1474.       a) It makes such a request according to the abstract service
  1475.          primitive:
  1476.  
  1477.          result =                        -- SUCCESS or FAILURE
  1478.          prepareResponseMessage(
  1479.           IN   messageProcessingModel   -- typically, SNMP version
  1480.           IN   securityModel            -- same as on incoming request
  1481.           IN   securityName             -- same as on incoming request
  1482.           IN   securityLevel            -- same as on incoming request
  1483.           IN   contextEngineID          -- data from/at this SNMP entity
  1484.           IN   contextName              -- data from/in this context
  1485.           IN   pduVersion               -- version of the PDU
  1486.           IN   PDU                      -- SNMP Protocol Data Unit
  1487.           IN   maxSizeResponseScopedPDU -- maximum size sender can accept
  1488.           IN   stateReference           -- reference to state
  1489.                                         -- information presented with
  1490.                                         -- the request
  1491.           IN   statusInformation        -- success or errorIndication
  1492.                                         -- error counter OID and value
  1493.                                         -- when errorIndication
  1494.           OUT  destTransportDomain      -- destination transport domain
  1495.           OUT  destTransportAddress     -- destination transport address
  1496.           OUT  outgoingMessage          -- the message to send
  1497.           OUT  outgoingMessageLength    -- the length of the message
  1498.           )
  1499.  
  1500.       b) The cached information for the original request is retrieved
  1501.          via the stateReference, including
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. SNMPv3 Working Group        Standards Track                    [Page 27]
  1515.  
  1516. RFC 2572           Message Processing and Dispatching           April 1999
  1517.  
  1518.  
  1519.                   - msgID,
  1520.                   - contextEngineID,
  1521.                   - contextName,
  1522.                   - securityModel,
  1523.                   - securityName,
  1524.                   - securityLevel,
  1525.                   - securityStateReference,
  1526.                   - reportableFlag,
  1527.                   - transportDomain, and
  1528.                   - transportAddress.
  1529.  
  1530.          The SNMPv3 Message Processing Model does not allow cached data
  1531.          to be overridden, except by error indications as detailed in
  1532.          (3) below.
  1533.  
  1534.    3) If statusInformation contains values for an OID/value combination
  1535.       (potentially also containing a securityLevel value,
  1536.       contextEngineID value, or contextName value), then
  1537.  
  1538.       a) If reportableFlag is zero, then the original message is
  1539.          discarded, and no further processing is done. A result of
  1540.          FAILURE is returned. SNMPv3 Message Processing is complete.
  1541.  
  1542.       b) If a PDU is provided, it is the PDU from the original request.
  1543.          If possible, extract the request-id.
  1544.  
  1545.       c) A Report PDU is prepared:
  1546.  
  1547.          1) the varBindList is set to contain the OID and value from the
  1548.             statusInformation
  1549.  
  1550.          2) error-status is set to 0
  1551.  
  1552.          3) error-index is set to 0.
  1553.  
  1554.          4) request-id is set to the value extracted in step b)
  1555.             Otherwise, request-id is set to 0
  1556.  
  1557.       d) The errorIndication in statusInformation may be accompanied by
  1558.          a securityLevel value, a contextEngineID value, or a
  1559.          contextName value.
  1560.  
  1561.          1) If statusInformation contains a value for securityLevel,
  1562.             then securityLevel is set to that value, otherwise it is set
  1563.             to noAuthNoPriv.
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570. SNMPv3 Working Group        Standards Track                    [Page 28]
  1571.  
  1572. RFC 2572           Message Processing and Dispatching           April 1999
  1573.  
  1574.  
  1575.          2) If statusInformation contains a value for contextEngineID,
  1576.             then contextEngineID is set to that value, otherwise it is
  1577.             set to the value of this entity's snmpEngineID.
  1578.  
  1579.          3) If statusInformation contains a value for contextName, then
  1580.             contextName is set to that value, otherwise it is set to the
  1581.             default context of "" (zero-length string).
  1582.  
  1583.       e) PDU is set to refer to the new Report-PDU.  The old PDU is
  1584.          discarded.
  1585.  
  1586.       f) Processing continues with step 6) below.
  1587.  
  1588.    4) If contextEngineID is not yet determined, then the contextEngineID
  1589.       is determined, in an implementation-dependent manner, possibly
  1590.       using the transportDomain and transportAddress.
  1591.  
  1592.    5) If the contextName is not yet determined, the contextName is set
  1593.       to the default context.
  1594.  
  1595.    6) A scopedPDU is prepared from the contextEngineID, contextName, and
  1596.       PDU.
  1597.  
  1598.    7) msgGlobalData is constructed as follows
  1599.  
  1600.       a) The msgVersion field is set to snmpv3(3).
  1601.  
  1602.       b) msgID is set as determined in step 1 or 2 above.
  1603.  
  1604.       c) msgMaxSize is set to an implementation-dependent value.
  1605.  
  1606.       d) msgFlags are set as follows:
  1607.  
  1608.          -  If securityLevel specifies noAuthNoPriv, then authFlag and
  1609.             privFlag are both set to zero.
  1610.  
  1611.          -  If securityLevel specifies authNoPriv, then authFlag is set
  1612.             to one and privFlag is set to zero.
  1613.  
  1614.          -  If securityLevel specifies authPriv, then authFlag is set to
  1615.             one and privFlag is set to one.
  1616.  
  1617.          -  If the PDU is from the Unconfirmed Class, then the
  1618.             reportableFlag is set to zero.
  1619.  
  1620.          -  If the PDU is from the Confirmed Class then the
  1621.             reportableFlag is set to one.
  1622.  
  1623.  
  1624.  
  1625.  
  1626. SNMPv3 Working Group        Standards Track                    [Page 29]
  1627.  
  1628. RFC 2572           Message Processing and Dispatching           April 1999
  1629.  
  1630.  
  1631.          -  All other msgFlags bits are set to zero.
  1632.  
  1633.       e) msgSecurityModel is set to the value of securityModel
  1634.  
  1635.    8) If the PDU is from the Response Class or the Internal Class, then
  1636.  
  1637.       a) The specified Security Model is called to generate the message
  1638.          according to the primitive:
  1639.  
  1640.          statusInformation =
  1641.            generateResponseMsg(
  1642.            IN   messageProcessingModel -- SNMPv3 Message Processing
  1643.                                        -- Model
  1644.            IN   globalData             -- msgGlobalData from step 7
  1645.            IN   maxMessageSize         -- from msgMaxSize (step 7c)
  1646.            IN   securityModel          -- as determined in step 7e
  1647.            IN   securityEngineID       -- the value of snmpEngineID
  1648.            IN   securityName           -- on behalf of this principal
  1649.            IN   securityLevel          -- for the outgoing message
  1650.            IN   scopedPDU              -- as prepared in step 6)
  1651.            IN   securityStateReference -- as determined in step 2
  1652.            OUT  securityParameters     -- filled in by Security Module
  1653.            OUT  wholeMsg               -- complete generated message
  1654.            OUT  wholeMsgLength         -- length of generated message
  1655.            )
  1656.  
  1657.          If, upon return from the Security Model, the statusInformation
  1658.          includes an errorIndication, then any cached information about
  1659.          the outstanding request message is discarded, and an
  1660.          errorIndication is returned, so it can be returned to the
  1661.          calling application. SNMPv3 Message Processing is complete.
  1662.  
  1663.       b) A SUCCESS result is returned. SNMPv3 Message Processing is
  1664.          complete.
  1665.  
  1666.    9) If the PDU is from the Confirmed Class or the Notification Class,
  1667.       then
  1668.  
  1669.       a) If the PDU is from the Unconfirmed Class, then securityEngineID
  1670.          is set to the value of this entity's snmpEngineID.
  1671.  
  1672.          Otherwise, the snmpEngineID of the target entity is determined,
  1673.          in an implementation-dependent manner, possibly using
  1674.          transportDomain and transportAddress.  The value of
  1675.          securityEngineID is set to the value of the target entity's
  1676.          snmpEngineID.
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. SNMPv3 Working Group        Standards Track                    [Page 30]
  1683.  
  1684. RFC 2572           Message Processing and Dispatching           April 1999
  1685.  
  1686.  
  1687.  
  1688.       b) The specified Security Model is called to generate the message
  1689.          according to the primitive:
  1690.  
  1691.          statusInformation =
  1692.           generateRequestMsg(
  1693.           IN  messageProcessingModel -- SNMPv3 Message Processing Model
  1694.           IN  globalData             -- msgGlobalData, from step 7
  1695.           IN  maxMessageSize         -- from msgMaxSize in step 7 c)
  1696.           IN  securityModel          -- as provided by caller
  1697.           IN  securityEngineID       -- authoritative SNMP entity
  1698.                                      -- from step 9 a)
  1699.           IN  securityName           -- as provided by caller
  1700.           IN  securityLevel          -- as provided by caller
  1701.           IN  scopedPDU              -- as prepared in step 6
  1702.           OUT securityParameters     -- filled in by Security Module
  1703.           OUT wholeMsg               -- complete generated message
  1704.           OUT wholeMsgLength         -- length of the generated message
  1705.           )
  1706.  
  1707.          If, upon return from the Security Model, the statusInformation
  1708.          includes an errorIndication, then the message is discarded, and
  1709.          the errorIndication is returned, so it can be returned to the
  1710.          calling application, and no further processing is done.
  1711.          SNMPv3 Message Processing is complete.
  1712.  
  1713.       c) If the PDU is from the Confirmed Class, information about the
  1714.          outgoing message is cached, and a (implementation-specific)
  1715.          stateReference is created.  Information to be cached includes
  1716.          the values of:
  1717.  
  1718.                       - sendPduHandle
  1719.                       - msgID
  1720.                       - snmpEngineID
  1721.                       - securityModel
  1722.                       - securityName
  1723.                       - securityLevel
  1724.                       - contextEngineID
  1725.                       - contextName
  1726.  
  1727.       d) A SUCCESS result is returned.  SNMPv3 Message Processing is
  1728.          complete.
  1729.  
  1730. 7.2.  Prepare Data Elements from an Incoming SNMP Message
  1731.  
  1732.    This section describes the procedure followed to extract data from an
  1733.    SNMPv3 message, and to prepare the data elements required for further
  1734.    processing of the message by the Message Dispatcher.
  1735.  
  1736.  
  1737.  
  1738. SNMPv3 Working Group        Standards Track                    [Page 31]
  1739.  
  1740. RFC 2572           Message Processing and Dispatching           April 1999
  1741.  
  1742.  
  1743.    1)  The message is passed in from the Message Dispatcher according to
  1744.        the abstract service primitive:
  1745.  
  1746.        result =                         -- SUCCESS or errorIndication
  1747.          prepareDataElements(
  1748.          IN  transportDomain          -- origin transport domain
  1749.          IN  transportAddress         -- origin transport address
  1750.          IN  wholeMsg                 -- as received from the network
  1751.          IN  wholeMsgLength           -- as received from the network
  1752.          OUT messageProcessingModel   -- typically, SNMP version
  1753.          OUT securityModel            -- Security Model to use
  1754.          OUT securityName             -- on behalf of this principal
  1755.          OUT securityLevel            -- Level of Security requested
  1756.          OUT contextEngineID          -- data from/at this entity
  1757.          OUT contextName              -- data from/in this context
  1758.          OUT pduVersion               -- version of the PDU
  1759.          OUT PDU                      -- SNMP Protocol Data Unit
  1760.          OUT pduType                  -- SNMP PDU type
  1761.          OUT sendPduHandle            -- handle for matched request
  1762.          OUT maxSizeResponseScopedPDU -- maximum size sender can accept
  1763.          OUT statusInformation        -- success or errorIndication
  1764.                                       -- error counter OID and value
  1765.                                       -- when errorIndication
  1766.          OUT stateReference           -- reference to state information
  1767.                                       -- to be used for a possible
  1768.          )                            -- Response
  1769.  
  1770.    2)  If the received message is not the serialization (according to
  1771.        the conventions of [RFC1906]) of an SNMPv3Message value, then the
  1772.        snmpInASNParseErrs counter [RFC1907] is incremented, the message
  1773.        is discarded without further processing, and a FAILURE result is
  1774.        returned. SNMPv3 Message Processing is complete.
  1775.  
  1776.    3)  The values for msgVersion, msgID, msgMaxSize, msgFlags,
  1777.        msgSecurityModel, msgSecurityParameters, and msgData are
  1778.        extracted from the message.
  1779.  
  1780.    4)  If the value of the msgSecurityModel component does not match a
  1781.        supported securityModel, then the snmpUnknownSecurityModels
  1782.        counter is incremented, the message is discarded without further
  1783.        processing, and a FAILURE result is returned. SNMPv3 Message
  1784.        Processing is complete.
  1785.  
  1786.    5)  The securityLevel is determined from the authFlag and the
  1787.        privFlag bits of the msgFlags component as follows:
  1788.  
  1789.        a) If the authFlag is not set and the privFlag is not set, then
  1790.           securityLevel is set to noAuthNoPriv.
  1791.  
  1792.  
  1793.  
  1794. SNMPv3 Working Group        Standards Track                    [Page 32]
  1795.  
  1796. RFC 2572           Message Processing and Dispatching           April 1999
  1797.  
  1798.  
  1799.        b) If the authFlag is set and the privFlag is not set, then
  1800.           securityLevel is set to authNoPriv.
  1801.  
  1802.        c) If the authFlag is set and the privFlag is set, then
  1803.           securityLevel is set to authPriv.
  1804.  
  1805.        d) If the authFlag is not set and privFlag is set, then the
  1806.           snmpInvalidMsgs counter is incremented, the message is
  1807.           discarded without further processing, and a FAILURE result is
  1808.           returned. SNMPv3 Message Processing is complete.
  1809.  
  1810.        e) Any other bits in the msgFlags are ignored.
  1811.  
  1812.    6)  The security module implementing the Security Model as specified
  1813.        by the securityModel component is called for authentication and
  1814.        privacy services.  This is done according to the abstract service
  1815.        primitive:
  1816.  
  1817.        statusInformation =            -- errorIndication or success
  1818.                                       -- error counter OID and
  1819.                                       -- value if error
  1820.          processIncomingMsg(
  1821.          IN  messageProcessingModel   -- SNMPv3 Message Processing Model
  1822.          IN  maxMessageSize           -- of the sending SNMP entity
  1823.          IN  securityParameters       -- for the received message
  1824.          IN  securityModel            -- for the received message
  1825.          IN  securityLevel            -- Level of Security
  1826.          IN  wholeMsg                 -- as received on the wire
  1827.          IN  wholeMsgLength           -- length as received on the wire
  1828.          OUT securityEngineID         -- authoritative SNMP entity
  1829.          OUT securityName             -- identification of the principal
  1830.          OUT scopedPDU,               -- message (plaintext) payload
  1831.          OUT maxSizeResponseScopedPDU -- maximum size sender can accept
  1832.          OUT securityStateReference   -- reference to security state
  1833.          )                            -- information, needed for
  1834.                                       -- response
  1835.  
  1836.        If an errorIndication is returned by the security module, then
  1837.  
  1838.        a) If statusInformation contains values for an OID/value pair,
  1839.           then generation of a Report PDU is attempted (see step 3 in
  1840.           section 7.1).
  1841.  
  1842.           1) If the scopedPDU has been returned from processIncomingMsg
  1843.              then determine contextEngineID, contextName, and PDU.
  1844.  
  1845.           2) Information about the message is cached and a
  1846.              stateReference is created (implementation-specific).
  1847.  
  1848.  
  1849.  
  1850. SNMPv3 Working Group        Standards Track                    [Page 33]
  1851.  
  1852. RFC 2572           Message Processing and Dispatching           April 1999
  1853.  
  1854.  
  1855.              Information to be cached includes the values of:
  1856.  
  1857.                           msgVersion,
  1858.                           msgID,
  1859.                           securityLevel,
  1860.                           msgFlags,
  1861.                           msgMaxSize,
  1862.                           securityModel,
  1863.                           maxSizeResponseScopedPDU,
  1864.                           securityStateReference
  1865.  
  1866.           3) Request that a Report-PDU be prepared and sent, according
  1867.              to the abstract service primitive:
  1868.  
  1869.              result =                     -- SUCCESS or FAILURE
  1870.              returnResponsePdu(
  1871.              IN  messageProcessingModel   -- SNMPv3(3)
  1872.              IN  securityModel            -- same as on incoming request
  1873.              IN  securityName             -- from processIncomingMsg
  1874.              IN  securityLevel            -- same as on incoming request
  1875.              IN  contextEngineID          -- from step 6 a) 1)
  1876.              IN  contextName              -- from step 6 a) 1)
  1877.              IN  pduVersion               -- SNMPv2-PDU
  1878.              IN  PDU                      -- from step 6 a) 1)
  1879.              IN  maxSizeResponseScopedPDU -- from processIncomingMsg
  1880.              IN  stateReference           -- from step 6 a) 2)
  1881.              IN  statusInformation        -- from processIncomingMsg
  1882.              )
  1883.  
  1884.        b) The incoming message is discarded without further processing,
  1885.           and a FAILURE result is returned. SNMPv3 Message Processing is
  1886.           complete.
  1887.  
  1888.    7)  The scopedPDU is parsed to extract the contextEngineID, the
  1889.        contextName and the PDU.  If any parse error occurs, then the
  1890.        snmpInASNParseErrs counter [RFC1907] is incremented, the security
  1891.        state information is discarded, the message is discarded without
  1892.        further processing, and a FAILURE result is returned. SNMPv3
  1893.        Message Processing is complete.  Treating an unknown PDU type is
  1894.        treated as a parse error is an implementation option.
  1895.  
  1896.    8)  The pduVersion is determined in an implementation-dependent
  1897.        manner.  For SNMPv3, the pduVersion would be an SNMPv2-PDU.
  1898.  
  1899.    9)  The pduType is determined, in an implementation-dependent manner.
  1900.        For RFC 1905, the pduTypes include:
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906. SNMPv3 Working Group        Standards Track                    [Page 34]
  1907.  
  1908. RFC 2572           Message Processing and Dispatching           April 1999
  1909.  
  1910.  
  1911.                - GetRequest-PDU,
  1912.                - GetNextRequest-PDU,
  1913.                - GetBulkRequest-PDU,
  1914.                - SetRequest-PDU,
  1915.                - InformRequest-PDU,
  1916.                - SNMPv2-Trap-PDU,
  1917.                - Response-PDU,
  1918.                - Report-PDU.
  1919.  
  1920.    10) If the pduType is from the Response Class or the Internal Class,
  1921.        then
  1922.  
  1923.        a) The value of the msgID component is used to find the cached
  1924.           information for a corresponding outstanding Request message.
  1925.           If no such outstanding Request message is found, then the
  1926.           security state information is discarded, the message is
  1927.           discarded without further processing, and a FAILURE result is
  1928.           returned. SNMPv3 Message Processing is complete.
  1929.  
  1930.        b) sendPduHandle is retrieved from the cached information.
  1931.  
  1932.        Otherwise, sendPduHandle is set to <none>, an implementation
  1933.        defined value.
  1934.  
  1935.     11) If the pduType is from the Internal Class, then
  1936.  
  1937.         a) statusInformation is created using the contents of the
  1938.            Report-PDU, in an implementation-dependent manner. This
  1939.            statusInformation will be forwarded to the application
  1940.            associated with the sendPduHandle.
  1941.  
  1942.         b) The cached data for the outstanding message, referred to by
  1943.            stateReference, is retrieved.  If the securityModel or
  1944.            securityLevel values differ from the cached ones, it is
  1945.            important to recognize that Internal Class PDUs delivered at
  1946.            the security level of noAuthNoPriv open a window of
  1947.            opportunity for spoofing or replay attacks.  If the receiver
  1948.            of such messages is aware of these risks, the use of such
  1949.            unauthenticated messages is acceptable and may provide a
  1950.            useful function for discovering engine IDs or for detecting
  1951.            misconfiguration at remote nodes.
  1952.  
  1953.            When the securityModel or securityLevel values differ from
  1954.            the cached ones, an implementation may retain the cached
  1955.            information about the outstanding Request message, in
  1956.            anticipation of the possibility that the Internal Class PDU
  1957.  
  1958.  
  1959.  
  1960.  
  1961.  
  1962. SNMPv3 Working Group        Standards Track                    [Page 35]
  1963.  
  1964. RFC 2572           Message Processing and Dispatching           April 1999
  1965.  
  1966.  
  1967.            received might be illegitimate.  Otherwise, any cached
  1968.            information about the outstanding Request message message is
  1969.            discarded.
  1970.  
  1971.         c) The security state information for this incoming message is
  1972.            discarded.
  1973.  
  1974.         d) stateReference is set to <none>
  1975.  
  1976.         e) A SUCCESS result is returned. SNMPv3 Message Processing is
  1977.            complete.
  1978.  
  1979.     12) If the pduType is from the Response Class, then
  1980.  
  1981.         a) The cached data for the outstanding request, referred to by
  1982.            stateReference, is retrieved, including
  1983.  
  1984.                        - snmpEngineID
  1985.                        - securityModel
  1986.                        - securityName
  1987.                        - securityLevel
  1988.                        - contextEngineID
  1989.                        - contextName
  1990.  
  1991.         b) If the values extracted from the incoming message differ from
  1992.            the cached data, then any cached information about the
  1993.            outstanding Request message is discarded, the incoming
  1994.            message is discarded without further processing, and a
  1995.            FAILURE result is returned.  SNMPv3 Message Processing is
  1996.            complete.
  1997.  
  1998.            When the securityModel or securityLevel values differ from
  1999.            the cached ones, an implementation may retain the cached
  2000.            information about the outstanding Request message, in
  2001.            anticipation of the possibility that the Response Class PDU
  2002.            received might be illegitimate.
  2003.  
  2004.         c) Otherwise, any cached information about the outstanding
  2005.            Request message is discarded, and stateReference is set to
  2006.            <none>.
  2007.  
  2008.         d) A SUCCESS result is returned. SNMPv3 Message Processing is
  2009.            complete.
  2010.  
  2011.     13) If the pduType is from the Confirmed Class, then
  2012.  
  2013.         a) If the value of securityEngineID is not equal to the value of
  2014.            snmpEngineID, then the security state information is
  2015.  
  2016.  
  2017.  
  2018. SNMPv3 Working Group        Standards Track                    [Page 36]
  2019.  
  2020. RFC 2572           Message Processing and Dispatching           April 1999
  2021.  
  2022.  
  2023.            discarded, any cached information about this message is
  2024.            discarded, the incoming message is discarded without further
  2025.            processing, and a FAILURE result is returned.  SNMPv3 Message
  2026.            Processing is complete.
  2027.  
  2028.         b) Information about the message is cached and a stateReference
  2029.            is created (implementation-specific).  Information to be
  2030.            cached includes the values of:
  2031.  
  2032.                         msgVersion,
  2033.                         msgID,
  2034.                         securityLevel,
  2035.                         msgFlags,
  2036.                         msgMaxSize,
  2037.                         securityModel,
  2038.                         maxSizeResponseScopedPDU,
  2039.                         securityStateReference
  2040.  
  2041.         c) A SUCCESS result is returned. SNMPv3 Message Processing is
  2042.            complete.
  2043.  
  2044.     14) If the pduType is from the Unconfirmed Class, then A SUCCESS
  2045.         result is returned. SNMPv3 Message Processing is complete.
  2046.  
  2047. 8.  Intellectual Property
  2048.  
  2049.    The IETF takes no position regarding the validity or scope of any
  2050.    intellectual property or other rights that might be claimed to
  2051.    pertain to the implementation or use of the technology described in
  2052.    this document or the extent to which any license under such rights
  2053.    might or might not be available; neither does it represent that it
  2054.    has made any effort to identify any such rights.  Information on the
  2055.    IETF's procedures with respect to rights in standards-track and
  2056.    standards-related documentation can be found in BCP-11.  Copies of
  2057.    claims of rights made available for publication and any assurances of
  2058.    licenses to be made available, or the result of an attempt made to
  2059.    obtain a general license or permission for the use of such
  2060.    proprietary rights by implementors or users of this specification can
  2061.    be obtained from the IETF Secretariat.
  2062.  
  2063.    The IETF invites any interested party to bring to its attention any
  2064.    copyrights, patents or patent applications, or other proprietary
  2065.    rights which may cover technology that may be required to practice
  2066.    this standard.  Please address the information to the IETF Executive
  2067.    Director.
  2068.  
  2069.  
  2070.  
  2071.  
  2072.  
  2073.  
  2074. SNMPv3 Working Group        Standards Track                    [Page 37]
  2075.  
  2076. RFC 2572           Message Processing and Dispatching           April 1999
  2077.  
  2078.  
  2079.  
  2080. 9.  Acknowledgements
  2081.  
  2082.    This document is the result of the efforts of the SNMPv3 Working
  2083.    Group.  Some special thanks are in order to the following SNMPv3 WG
  2084.    members:
  2085.  
  2086.        Harald Tveit Alvestrand (Maxware)
  2087.        Dave Battle (SNMP Research, Inc.)
  2088.        Alan Beard (Disney Worldwide Services)
  2089.        Paul Berrevoets (SWI Systemware/Halcyon Inc.)
  2090.        Martin Bjorklund (Ericsson)
  2091.        Uri Blumenthal (IBM T. J. Watson Research Center)
  2092.        Jeff Case (SNMP Research, Inc.)
  2093.        John Curran (BBN)
  2094.        Mike Daniele (Compaq Computer Corporation)
  2095.        T. Max Devlin (Eltrax Systems)
  2096.        John Flick (Hewlett Packard)
  2097.        Rob Frye (MCI)
  2098.        Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.)
  2099.        David Harrington (Cabletron Systems Inc.)
  2100.        Lauren Heintz (BMC Software, Inc.)
  2101.        N.C. Hien (IBM T. J. Watson Research Center)
  2102.        Michael Kirkham (InterWorking Labs, Inc.)
  2103.        Dave Levi (SNMP Research, Inc.)
  2104.        Louis A Mamakos (UUNET Technologies Inc.)
  2105.        Joe Marzot (Nortel Networks)
  2106.        Paul Meyer (Secure Computing Corporation)
  2107.        Keith McCloghrie (Cisco Systems)
  2108.        Bob Moore (IBM)
  2109.        Russ Mundy (TIS Labs at Network Associates)
  2110.        Bob Natale (ACE*COMM Corporation)
  2111.        Mike O'Dell (UUNET Technologies Inc.)
  2112.        Dave Perkins (DeskTalk)
  2113.        Peter Polkinghorne (Brunel University)
  2114.        Randy Presuhn (BMC Software, Inc.)
  2115.        David Reeder (TIS Labs at Network Associates)
  2116.        David Reid (SNMP Research, Inc.)
  2117.        Aleksey Romanov (Quality Quorum)
  2118.        Shawn Routhier (Epilogue)
  2119.        Juergen Schoenwaelder (TU Braunschweig)
  2120.        Bob Stewart (Cisco Systems)
  2121.        Mike Thatcher (Independent Consultant)
  2122.        Bert Wijnen (IBM T. J. Watson Research Center)
  2123.  
  2124.    The document is based on recommendations of the IETF Security and
  2125.    Administrative Framework Evolution for SNMP Advisory Team.  Members
  2126.    of that Advisory Team were:
  2127.  
  2128.  
  2129.  
  2130. SNMPv3 Working Group        Standards Track                    [Page 38]
  2131.  
  2132. RFC 2572           Message Processing and Dispatching           April 1999
  2133.  
  2134.  
  2135.        David Harrington (Cabletron Systems Inc.)
  2136.        Jeff Johnson (Cisco Systems)
  2137.        David Levi (SNMP Research Inc.)
  2138.        John Linn (Openvision)
  2139.        Russ Mundy (Trusted Information Systems) chair
  2140.        Shawn Routhier (Epilogue)
  2141.        Glenn Waters (Nortel)
  2142.        Bert Wijnen (IBM T. J. Watson Research Center)
  2143.  
  2144.    As recommended by the Advisory Team and the SNMPv3 Working Group
  2145.    Charter, the design incorporates as much as practical from previous
  2146.    RFCs and drafts. As a result, special thanks are due to the authors
  2147.    of previous designs known as SNMPv2u and SNMPv2*:
  2148.  
  2149.        Jeff Case (SNMP Research, Inc.)
  2150.        David Harrington (Cabletron Systems Inc.)
  2151.        David Levi (SNMP Research, Inc.)
  2152.        Keith McCloghrie (Cisco Systems)
  2153.        Brian O'Keefe (Hewlett Packard)
  2154.        Marshall T. Rose (Dover Beach Consulting)
  2155.        Jon Saperia (BGS Systems Inc.)
  2156.        Steve Waldbusser (International Network Services)
  2157.        Glenn W. Waters (Bell-Northern Research Ltd.)
  2158.  
  2159. 10.  Security Considerations
  2160.  
  2161.    The Dispatcher coordinates the processing of messages to provide a
  2162.    level of security for management messages and to direct the SNMP PDUs
  2163.    to the proper SNMP application(s).
  2164.  
  2165.    A Message Processing Model, and in particular the V3MP defined in
  2166.    this document, interacts as part of the Message Processing with
  2167.    Security Models in the Security Subsystem via the abstract service
  2168.    interface primitives defined in [RFC2571] and elaborated above.
  2169.  
  2170.    The level of security actually provided is primarily determined by
  2171.    the specific Security Model implementation(s) and the specific SNMP
  2172.    application implementation(s) incorporated into this framework.
  2173.    Applications have access to data which is not secured. Applications
  2174.    should take reasonable steps to protect the data from disclosure, and
  2175.    when they send data across the network, they should obey the
  2176.    securityLevel and call upon the services of an Access Control Model
  2177.    as they apply access control.
  2178.  
  2179.    The values for the msgID element used in communication between SNMP
  2180.    entities must be chosen to avoid replay attacks.  The values do not
  2181.    need to be unpredictable; it is sufficient that they not repeat.
  2182.  
  2183.  
  2184.  
  2185.  
  2186. SNMPv3 Working Group        Standards Track                    [Page 39]
  2187.  
  2188. RFC 2572           Message Processing and Dispatching           April 1999
  2189.  
  2190.  
  2191.    When exchanges are carried out over an insecure network, there is an
  2192.    open opportunity for a third party to spoof or replay messages when
  2193.    any message of an exchange is given at the security level of
  2194.    noAuthNoPriv.  For most exchanges, all messages exist at the same
  2195.    security level.  In the case where the final message is an Internal
  2196.    Class PDU, this message may be delivered at a level of noAuthNoPriv
  2197.    or authNoPriv, independent of the security level of the preceding
  2198.    messages.  Internal Class PDUs delivered at the level of authNoPriv
  2199.    are not considered to pose a security hazard.  Internal Class PDUs
  2200.    delivered at the security level of noAuthNoPriv open a window of
  2201.    opportunity for spoofing or replay attacks.  If the receiver of such
  2202.    messages is aware of these risks, the use of such unauthenticated
  2203.    messages is acceptable and may provide a useful function for
  2204.    discovering engine IDs or for detecting misconfiguration at remote
  2205.    nodes.
  2206.  
  2207.    This document also contains a MIB definition module.  None of the
  2208.    objects defined is writable, and the information they represent is
  2209.    not deemed to be particularly sensitive.  However, if they are deemed
  2210.    sensitive in a particular environment, access to them should be
  2211.    restricted through the use of appropriately configured Security and
  2212.    Access Control models.
  2213.  
  2214. 11.  References
  2215.  
  2216.    [RFC1901]    The SNMPv2 Working Group, Case, J., McCloghrie, K.,
  2217.                 Rose, M.  and S. Waldbusser, "Introduction to
  2218.                 Community-based SNMPv2", RFC 1901, January 1996.
  2219.  
  2220.    [RFC2578]    McCloghrie, K., Perkins, D. and J. Schoenwaelder,
  2221.                 "Structure of Management Information Version 2 (SMIv2)",
  2222.                 STD 58, RFC 2578, April 1999.
  2223.  
  2224.    [RFC1905]    The SNMPv2 Working Group, Case, J., McCloghrie, K.,
  2225.                 Rose, M. and S. Waldbusser, "Protocol Operations for
  2226.                 Version 2 of the Simple Network Management Protocol
  2227.                 (SNMPv2)", RFC 1905, January 1996.
  2228.  
  2229.    [RFC1906]    The SNMPv2 Working Group, Case, J., McCloghrie, K.,
  2230.                 Rose, M. and S. Waldbusser, "Transport Mappings for
  2231.                 Version 2 of the Simple Network Management Protocol
  2232.                 (SNMPv2)", RFC 1906, January 1996.
  2233.  
  2234.    [RFC1907]    The SNMPv2 Working Group, Case, J., McCloghrie, K.,
  2235.                 Rose, M. and S. Waldbusser, "Management Information Base
  2236.                 for Version 2 of the Simple Network Management Protocol
  2237.                 (SNMPv2)", RFC 1907 January 1996.
  2238.  
  2239.  
  2240.  
  2241.  
  2242. SNMPv3 Working Group        Standards Track                    [Page 40]
  2243.  
  2244. RFC 2572           Message Processing and Dispatching           April 1999
  2245.  
  2246.  
  2247.    [RFC1908]    The SNMPv2 Working Group, Case, J., McCloghrie, K.,
  2248.                 Rose, M. and S. Waldbusser, "Coexistence between Version
  2249.                 1 and Version 2 of the Internet-standard Network
  2250.                 Management Framework", RFC 1908, January 1996.
  2251.  
  2252.    [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
  2253.                 Requirement Levels", BCP 14, RFC 2119, March 1997.
  2254.  
  2255.    [RFC2028]    Hovey, R. and S. Bradner, "The Organizations Involved in
  2256.                 the IETF Standards Process", BCP 11, RFC 2028, October
  2257.                 1996.
  2258.  
  2259.    [RFC2571]    Harrington, D., Presuhn, R. and B. Wijnen, "An
  2260.                 Architecture for describing SNMP Management Frameworks",
  2261.                 RFC 2571, April 1999.
  2262.  
  2263.    [RFC2574]    Blumenthal, U.  and B. Wijnen, "The User-Based Security
  2264.                 Model for Version 3 of the Simple Network Management
  2265.                 Protocol (SNMPv3)", RFC 2574, April 1999.
  2266.  
  2267.    [RFC2575]    Wijnen, B., Presuhn, R.  and K. McCloghrie, "View-based
  2268.                 Access Control Model for the Simple Network Management
  2269.                 Protocol (SNMP)", RFC 2575, April 1999.
  2270.  
  2271.    [RFC2573]    Levi, D., Meyer, P.  and B. Stewart, "SNMP
  2272.                 Applications", RFC 2573, April 1999.
  2273.  
  2274.    [RFC2570]    Case, J., Mundy, R., Partain, D. and B. Stewart,
  2275.                 "Introduction to Version 3 of the Internet-standard
  2276.                 Network Management Framework", RFC 2570, April 1999.
  2277.  
  2278. 12.  Editors' Addresses
  2279.  
  2280.    Jeffrey Case
  2281.    SNMP Research, Inc.
  2282.    3001 Kimberlin Heights Road
  2283.    Knoxville, TN 37920-9716
  2284.    USA
  2285.  
  2286.    Phone:     +1 423-573-1434
  2287.    EMail:     case@snmp.com
  2288.  
  2289.  
  2290.  
  2291.  
  2292.  
  2293.  
  2294.  
  2295.  
  2296.  
  2297.  
  2298. SNMPv3 Working Group        Standards Track                    [Page 41]
  2299.  
  2300. RFC 2572           Message Processing and Dispatching           April 1999
  2301.  
  2302.  
  2303.    Dave Harrington
  2304.    Cabletron Systems, Inc
  2305.    Post Office Box 5005
  2306.    Mail Stop: Durham
  2307.    35 Industrial Way
  2308.    Rochester, NH 03867-5005
  2309.    USA
  2310.  
  2311.    Phone:      +1 603-337-7357
  2312.    EMail:      dbh@ctron.com
  2313.  
  2314.  
  2315.    Randy Presuhn
  2316.    BMC Software, Inc.
  2317.    965 Stewart Drive
  2318.    Sunnyvale, CA 94086
  2319.    USA
  2320.  
  2321.    Phone:      +1 408-616-3100
  2322.    EMail:      randy_presuhn@bmc.com
  2323.  
  2324.  
  2325.    Bert Wijnen
  2326.    IBM T. J. Watson Research
  2327.    Schagen 33
  2328.    3461 GL Linschoten
  2329.    Netherlands
  2330.  
  2331.    Phone:      +31 348-432-794
  2332.    EMail:      wijnen@vnet.ibm.com
  2333.  
  2334.  
  2335. 13.  Changes From RFC 2272
  2336.  
  2337.    The following change log records major changes from the previous
  2338.    version of this document, RFC 2272.
  2339.  
  2340.       -  Updated contact information for editors.
  2341.  
  2342.       -  Made parameter identification in prepareResponseMessage()
  2343.          consistent, both internally and with architecture.
  2344.  
  2345.       -  Made references to processIncomingMsg() consistent, both
  2346.          internally and with architecture.
  2347.  
  2348.       -  Deleted superfluous expectResponse parameter from
  2349.          processIncomingMsg(), consistent with architecture.
  2350.  
  2351.  
  2352.  
  2353.  
  2354. SNMPv3 Working Group        Standards Track                    [Page 42]
  2355.  
  2356. RFC 2572           Message Processing and Dispatching           April 1999
  2357.  
  2358.  
  2359.       -  Fixed typos.
  2360.  
  2361.       -  Removed sending of a report PDU from step 4 on page 30 on RFC
  2362.          2272.
  2363.  
  2364.       -  Use "PDU Class" terminology instead of directly using RFC 1905
  2365.          PDU types, in order to potentially allow use of new PDU types
  2366.          in the future.
  2367.  
  2368.       -  Added intro document to references.
  2369.  
  2370.       -  Made various clarifications to the text.
  2371.  
  2372.       -  The handling of the reportableFlag has been made consistent.
  2373.  
  2374.       -  The acknowledgement list has been updated.
  2375.  
  2376.  
  2377.  
  2378.  
  2379.  
  2380.  
  2381.  
  2382.  
  2383.  
  2384.  
  2385.  
  2386.  
  2387.  
  2388.  
  2389.  
  2390.  
  2391.  
  2392.  
  2393.  
  2394.  
  2395.  
  2396.  
  2397.  
  2398.  
  2399.  
  2400.  
  2401.  
  2402.  
  2403.  
  2404.  
  2405.  
  2406.  
  2407.  
  2408.  
  2409.  
  2410. SNMPv3 Working Group        Standards Track                    [Page 43]
  2411.  
  2412. RFC 2572           Message Processing and Dispatching           April 1999
  2413.  
  2414.  
  2415. 14.  Full Copyright Statement
  2416.  
  2417.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  2418.  
  2419.    This document and translations of it may be copied and furnished to
  2420.    others, and derivative works that comment on or otherwise explain it
  2421.    or assist in its implementation may be prepared, copied, published
  2422.    and distributed, in whole or in part, without restriction of any
  2423.    kind, provided that the above copyright notice and this paragraph are
  2424.    included on all such copies and derivative works.  However, this
  2425.    document itself may not be modified in any way, such as by removing
  2426.    the copyright notice or references to the Internet Society or other
  2427.    Internet organizations, except as needed for the purpose of
  2428.    developing Internet standards in which case the procedures for
  2429.    copyrights defined in the Internet Standards process must be
  2430.    followed, or as required to translate it into languages other than
  2431.    English.
  2432.  
  2433.    The limited permissions granted above are perpetual and will not be
  2434.    revoked by the Internet Society or its successors or assigns.
  2435.  
  2436.    This document and the information contained herein is provided on an
  2437.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  2438.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  2439.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  2440.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  2441.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  2442.  
  2443. Acknowledgement
  2444.  
  2445.    Funding for the RFC Editor function is currently provided by the
  2446.    Internet Society.
  2447.  
  2448.  
  2449.  
  2450.  
  2451.  
  2452.  
  2453.  
  2454.  
  2455.  
  2456.  
  2457.  
  2458.  
  2459.  
  2460.  
  2461.  
  2462.  
  2463.  
  2464.  
  2465.  
  2466. SNMPv3 Working Group        Standards Track                    [Page 44]
  2467.  
  2468.