4.1. Non-Secure Minimal Agent Configuration

This section presents an example configuration for a minimal, non-secure SNMPv2 agent that interacts with one or more SNMPv2 management stations. Table 2 presents information about SNMPv2 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 SNMPv2 agent implementation must provide for administrative configuration (and non-volatile storage) of the identities and transport addresses of two SNMPv2 parties: itself and a remote peer. Strictly speaking, other information about these two parties (including access policy information) need not be configurable.

        Identity          gracie                george
                          (agent)               (manager)
        Domain            snmpUDPDomain         snmpUDPDomain
        Address           1.2.3.4, 161          1.2.3.5, 2001
        Auth Prot         noAuth                noAuth
        Auth Priv Key     ""                    ""
        Auth Pub Key      ""                    ""
        Auth Clock        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    Context    Privileges
   gracie    george     local       35 (Get, GetNext & GetBulk)
   george    gracie     local      132 (Response & SNMPv2-Trap)

           Table 3: Access Information for Minimal Agent

Suppose that the managing party george wishes to interrogate management information about the SNMPv2 context named "local" held by the agent named gracie by issuing a SNMPv2 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 authenticated as to origin and integrity. Because, according to the manager's local database of party information, the privacy protocol for the party gracie is noPriv, the GetNext request message is not protected from disclosure. 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 local database of party information 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 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 database of party information 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 agent's local database of access policy information authorizes GetNext request communications by the party george to the agent party gracie with respect to the SNMPv2 context "local". The database of access policy information presented as Table 3 authorizes such communications (as well as Get and GetBulk operations).

When the received request is processed, a Response message is generated which references the SNMPv2 context "local" and identifies 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 database of party information as noAuth, the generated Response message is not authenticated as to origin or integrity. Because, according to the local database of party information, 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 of party information.

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 database of party information 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 manager's local database of access policy information authorizes Response communications from the party gracie to the manager party george which reference the SNMPv2 context "local". The database of access policy information presented as Table 3 authorizes such Response messages (as well as SNMPv2-Trap messages).