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