rfc1351.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,542 行 · 第 1/5 页

   This section describes the procedure followed by a SNMP protocol
   entity whenever a response to a management request is generated.

   The procedure for generating a response to a SNMP management request
   is identical to the procedure for transmitting a request (see Section
   3.13.1), except for the derivation of the transport domain and
   address information.  In this case, the response is transmitted using
   the transport domain and address from which the corresponding request
   originated -- even if that is different from the transport
   information recorded in the local database.

4.  Application of the Model

   This section describes how the administrative model set forth above
   is applied to realize effective network management in a variety of
   configurations and environments. Several types of administrative
   configurations are identified, and an example of each is presented.

4.1   Non-Secure Minimal Agent Configuration

   This section presents an example configuration for a minimal, non-
   secure SNMP agent that interacts with one or more SNMP management



Davin, Galvin, & McCloghrie                                    [Page 17]

RFC 1351               SNMP Administrative Model               July 1992


   stations. Table 2 presents information about SNMP parties that is
   known both to the minimal agent and to the manager, while Table 3
   presents similarly common information about the local access policy.

   As represented in Table 2, the example agent party operates at UDP
   port 161 at IP address 1.2.3.4 using the party identity gracie; the
   example manager operates at UDP port 2001 at IP address 1.2.3.5 using
   the identity george. At minimum, a non-secure SNMP agent
   implementation must provide for administrative configuration (and
   non-volatile storage) of the identities and transport addresses of
   two SNMP parties: itself and a remote peer. Strictly speaking, other
   information about these two parties (including access policy
   information) need not be configurable.

   Suppose that the managing party george wishes to interrogate the
   agent named gracie by issuing a SNMP GetNext request message. The
   manager consults its local database of party information. Because the
   authentication protocol for the party george is recorded as noAuth,
   the GetNext request message generated by the manager is not

    Identity          gracie                george
                      (agent)               (manager)
    Domain            rfc1351Domain         rfc1351Domain
    Address           1.2.3.4, 161          1.2.3.5, 2001
    Proxied Party     noProxy               noProxy
    Auth Prot         noAuth                noAuth
    Auth Priv Key     ""                    ""
    Auth Pub Key      ""                    ""
    Auth Clock        0                     0
    Auth Last Msg     0                     0
    Auth Lifetime     0                     0
    Priv Prot         noPriv                noPriv
    Priv Priv Key     ""                    ""
    Priv Pub Key      ""                    ""

         Table 2: Party Information for Minimal Agent



              Target    Subject   Privileges
              gracie    george    3
              george    gracie    20

        Table 3: Access Information for Minimal Agent

   authenticated as to origin and integrity. Because, according to the
   manager's database, the privacy protocol for the party gracie is
   noPriv, the GetNext request message is not protected from disclosure.



Davin, Galvin, & McCloghrie                                    [Page 18]

RFC 1351               SNMP Administrative Model               July 1992


   Rather, it is simply assembled, serialized, and transmitted to the
   transport address (IP address 1.2.3.4, UDP port 161) associated in
   the manager's database with the party gracie.

   When the GetNext request message is received at the agent, the
   identity of the party to which it is directed (gracie) is extracted
   from the message, and the receiving protocol entity consults its
   local database of party information. Because the privacy protocol for
   the party gracie is recorded as noPriv, the received message is
   assumed not to be protected from disclosure. Similarly, the identity
   of the originating party (george) is extracted, and the local party
   database is consulted. Because the authentication protocol for the
   party george is recorded as noAuth, the received message is
   immediately accepted as authentic.

   The received message is fully processed only if the access policy
   database local to the agent authorizes GetNext request communications
   by the party george with respect to the agent party gracie. The
   access policy database presented as Table 3 authorizes such
   communications (as well as Get operations).

   When the received request is processed, a GetResponse message is
   generated with gracie as the source party and george, the party from
   which the request originated, as the destination party. Because the
   authentication protocol for gracie is recorded in the local party
   database as noAuth, the generated GetResponse message is not
   authenticated as to origin or integrity. Because, according to the
   local database, the privacy protocol for the party george is noPriv,
   the response message is not protected from disclosure. The response
   message is transmitted to the transport address from which the
   corresponding request originated -- without regard for the transport
   address associated with george in the local database.

   When the generated response is received by the manager, the identity
   of the party to which it is directed (george) is extracted from the
   message, and the manager consults its local database of party
   information. Because the privacy protocol for the party george is
   recorded as noPriv, the received response is assumed not to be
   protected from disclosure. Similarly, the identity of the originating
   party (gracie) is extracted, and the local party database is
   consulted. Because the authentication protocol for the party gracie
   is recorded as noAuth, the received response is immediately accepted
   as authentic.

   The received message is fully processed only if the access policy
   database local to the manager authorizes GetResponse communications
   by the party gracie with respect to the manager party george. The
   access policy database presented as Table 3 authorizes such response



Davin, Galvin, & McCloghrie                                    [Page 19]

RFC 1351               SNMP Administrative Model               July 1992


   messages (as well as Trap messages).

4.2   Secure Minimal Agent Configuration

   This section presents an example configuration for a secure, minimal
   SNMP agent that interacts with a single SNMP management station.
   Table 4 presents information about SNMP parties that is known both to
   the minimal agent and to the manager, while Table 5 presents
   similarly common information about the local access policy.

   The interaction of manager and agent in this configuration is very
   similar to that sketched above for the non-secure minimal agent --
   except that all protocol messages are authenticated as to origin and
   integrity and protected from disclosure. This example requires
   encryption in order to support distribution of secret keys via the
   SNMP itself. A more elaborate example comprising an additional pair
   of SNMP parties could support the exchange of non-secret information
   in authenticated messages without incurring the cost of encryption.

   An actual secure agent configuration may require SNMP parties for
   which the authentication and privacy protocols are noAuth and noPriv,
   respectively, in order to support clock synchronization (see [4]).
   For clarity, these additional parties are not represented in this
   example.

     Identity          ollie                stan
                       (agent)              (manager)
     Domain            rfc1351Domain        rfc1351Domain
     Address           1.2.3.4, 161         1.2.3.5, 2001
     Proxied Party     noProxy              noProxy
     Auth Prot         md5AuthProtocol      md5AuthProtocol
     Auth Priv Key     "0123456789ABCDEF"   "GHIJKL0123456789"
     Auth Pub Key      ""                   ""
     Auth Clock        0                    0
     Auth Last Msg     0                    0
     Auth Lifetime     500                  500
     Priv Prot         desPrivProtocol      desPrivProtocol
     Priv Priv Key     "MNOPQR0123456789"   "STUVWX0123456789"
     Priv Pub Key      ""                   ""

      Table 4: Party Information for Secure Minimal Agent


               Target   Subject   Privileges
               ollie    stan      3
               stan     ollie     20

      Table 5: Access Information for Secure Minimal Agent



Davin, Galvin, & McCloghrie                                    [Page 20]

RFC 1351               SNMP Administrative Model               July 1992


   As represented in Table 4, the example agent party operates at UDP
   port 161 at IP address 1.2.3.4 using the party identity ollie; the
   example manager operates at UDP port 2001 at IP address 1.2.3.5 using
   the identity stan. At minimum, a secure SNMP agent implementation
   must provide for administrative configuration (and non-volatile
   storage) of relevant information about two SNMP parties: itself and a
   remote peer. Both ollie and stan authenticate all messages that they
   generate by using the SNMP authentication protocol md5AuthProtocol
   and their distinct, private authentication keys. Although these
   private authentication key values ("0123456789ABCDEF" and
   "GHIJKL0123456789") are presented here for expository purposes,
   knowledge of private authentication keys is not normally afforded to
   human beings and is confined to those portions of the protocol
   implementation that require it.

   When using the md5AuthProtocol, the public authentication key for
   each SNMP party is never used in authentication and verification of
   SNMP exchanges. Also, because the md5AuthProtocol is symmetric in
   character, the private authentication key for each party must be
   known to another SNMP party with which authenticated communication is
   desired. In contrast, asymmetric (public key) authentication
   protocols would not depend upon sharing of a private key for their
   operation.

   All protocol messages originated by the party stan are encrypted on
   transmission using the desPrivProtocol privacy protocol and the
   private key "STUVWX0123456789"; they are decrypted upon reception
   according to the same protocol and key. Similarly, all messages
   originated by the party ollie are encrypted on transmission using the
   desPrivProtocol protocol and private privacy key "MNOPQR0123456789";
   they are correspondingly decrypted on reception. As with
   authentication keys, knowledge of private privacy keys is not
   normally afforded to human beings and is confined to those portions
   of the protocol implementation that require it.

4.3   Proxy Configuration

   This section presents examples of SNMP proxy configurations.  On one
   hand, foreign proxy configurations provide the capability to manage
   non-SNMP devices. On the other hand, native proxy configurations
   allow an administrator to shift the computational burden of rich
   management functionality away from network devices whose primary task
   is not management.  To the extent that SNMP proxy agents function as
   points of aggregation for management information, proxy
   configurations may also reduce the bandwidth requirements of large-
   scale management activities.

   The example configurations in this section are simplified for



Davin, Galvin, & McCloghrie                                    [Page 21]

RFC 1351               SNMP Administrative Model               July 1992


   clarity: actual configurations may require additional parties in
   order to support clock synchronization and distribution of secrets.

4.3.1   Foreign Proxy Configuration

   This section presents an example configuration by which a SNMP
   management station may manage network elements that do not themselves
   support the SNMP. This configuration centers on a SNMP proxy agent
   that realizes SNMP management operations by interacting with a non-
   SNMP device using a proprietary protocol.

   Table 6 presents information about SNMP parties that is recorded in
   the local database of the SNMP proxy agent.  Table 7 presents
   information about SNMP parties that is recorded in the local database
   of the SNMP management station. Table 8 presents information about
   the access policy specified by the local administration.

   As represented in Table 6, the proxy agent party operates at UDP port
   161 at IP address 1.2.3.5 using the party identity moe; the example
   manager operates at UDP port 2002 at IP address 1.2.3.4 using the
   identity larry. Both larry and moe authenticate all messages that
   they generate by using the protocol md5AuthProtocol and their
   distinct, private authentication keys. Although these private
   authentication key values ("0123456789ABCDEF" and

   Identity        larry               moe                 curly
                   (manager)           (proxy)             (proxied)
   Domain          rfc1351Domain       rfc1351Domain       acmeMgmtPrtcl
   Address         1.2.3.4, 2002       1.2.3.5, 161        0x98765432
   Proxied Party   noProxy             curly               noProxy
   Auth Prot       md5AuthProtocol     md5AuthProtocol     noAuth
   Auth Priv Key   "0123456789ABCDEF"  "GHIJKL0123456789"  ""
   Auth Pub Key    ""                  ""                  ""
   Auth Clock      0                   0                   0
   Auth Last Msg   0                   0                   0
   Auth Lifetime   500                 500                 0
   Priv Prot       noPriv              noPriv              noPriv
   Priv Priv Key   ""                  ""                  ""
   Priv Pub Key    ""                  ""                  ""

         Table 6: Party Information for Proxy Agent










Davin, Galvin, & McCloghrie                                    [Page 22]

RFC 1351               SNMP Administrative Model               July 1992