As per Relevance of the word component, we have this rfc below:
Network Working Group J.
Request for Comments: 1351 MIT Laboratory for Computer
J.
Trusted Information Systems, Inc
K.
Hughes LAN Systems, Inc
July 1992
SNMP Administrative
Status of this
This document specifies an IAB standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" for the standardization state and
of this protocol. Distribution of this memo is unlimited
Table of
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
3. Elements of the Model . . . . . . . . . . . . . . . . . . . 2
3.1 SNMP Party . . . . . . . . . . . . . . . . . . . . . . . . 2
3.2 SNMP Protocol Entity . . . . . . . . . . . . . . . . . . . 6
3.3 SNMP Management Station . . . . . . . . . . . . . . . . . . 6
3.4 SNMP Agent . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5 View Subtree . . . . . . . . . . . . . . . . . . . . . . . 7
3.6 MIB View . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7 SNMP Management Communication . . . . . . . . . . . . . . . 8
3.8 SNMP Authenticated Management Communication . . . . . . . . 9
3.9 SNMP Private Management Communication . . . . . . . . . . 9
3.10 SNMP Management Communication Class . . . . . . . . . . . . 10
3.11 SNMP Access Control Policy . . . . . . . . . . . . . . . . 11
3.12 SNMP Proxy Party . . . . . . . . . . . . . . . . . . . . . 12
3.13 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 13
3.13.1 Generating a Request . . . . . . . . . . . . . . . . . . 13
3.13.2 Processing a Received Communication . . . . . . . . . . . 15
3.13.3 Generating a Response . . . . . . . . . . . . . . . . . . 17
4. Application of the Model . . . . . . . . . . . . . . . . . 17
4.1 Non-Secure Minimal Agent Configuration . . . . . . . . . . 17
4.2 Secure Minimal Agent Configuration . . . . . . . . . . . . 20
4.3 Proxy Configuration . . . . . . . . . . . . . . . . . . . 21
4.3.1 Foreign Proxy Configuration . . . . . . . . . . . . . . . 22
4.3.2 Native Proxy Configuration . . . . . . . . . . . . . . . 25
4.4 Public Key Configuration . . . . . . . . . . . . . . . . . 27
4.5 MIB View Configurations . . . . . . . . . . . . . . . . . . 29
Davin, Galvin, & McCloghrie [Page 1]
RFC 1351 SNMP Administrative Model July 1992
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . 33
7. References . . . . . . . . . . . . . . . . . . . . . . . .
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 34
1.
This memo presents an elaboration of the SNMP administrative
set forth in [1]. This model provides a unified conceptual basis
administering SNMP protocol entities to
o authentication and integrity
o privacy
o access control,
o the cooperation of multiple protocol entities
Please send comments to the SNMP Security Developers mailing
(snmp-sec-dev@tis.com).
2.
This memo presents an elaboration of the SNMP administrative
set forth in [1]. It describes how the elaborated
model is applied to realize effective network management in a
of configurations and environments
The model described here entails the use of distinct identities
peers that exchange SNMP messages. Thus, it represents a
from the community-based administrative model set forth in [1].
unambiguously identifying the source and intended recipient of
SNMP message, this new strategy improves upon the
community scheme both by supporting a more convenient access
model and allowing for effective use of asymmetric (public key
security protocols in the future
3. Elements of the
3.1 SNMP
A SNMP party is a conceptual, virtual execution context
operation is restricted (for security or other purposes) to
administratively defined subset of all possible operations of
particular SNMP protocol entity (see Section 3.2). Whenever a
protocol entity processes a SNMP message, it does so by acting as
SNMP party and is thereby restricted to the set of operations
Davin, Galvin, & McCloghrie [Page 2]
RFC 1351 SNMP Administrative Model July 1992
for that party. The set of possible operations specified for a
party may be overlapping or disjoint with respect to the sets
other SNMP parties; it may also be a proper or improper subset of
possible operations of the SNMP protocol entity
Architecturally, each SNMP party
o a single, unique party identity
o a single authentication protocol and
parameters by which all protocol messages originated
the party are authenticated as to origin and integrity
o a single privacy protocol and associated parameters
which all protocol messages received by the party
protected from disclosure
o a single MIB view (see Section 3.6) to which
management operations performed by the party
applied,
o a logical network location at which the party executes
characterized by a transport protocol domain
transport addressing information
Conceptually, each SNMP party may be represented by an ASN.1
with the following syntax
SnmpParty ::= SEQUENCE {
OBJECT IDENTIFIER
OBJECT IDENTIFIER
OCTET STRING
OBJECT IDENTIFIER
INTEGER
OBJECT IDENTIFIER
INTEGER
INTEGER
INTEGER
Davin, Galvin, & McCloghrie [Page 3]
RFC 1351 SNMP Administrative Model July 1992
OCTET STRING
OCTET STRING
INTEGER
OBJECT IDENTIFIER
OCTET STRING
OCTET
}
For each SnmpParty value that represents a SNMP party, the
statements are true
o Its partyIdentity component is the party identity
o Its partyTDomain component is called the
domain and indicates the kind of transport service
which the party receives network management traffic
An example of a transport domain
rfc1351Domain (SNMP over UDP, using
parties).
o Its partyTAddr component is called the
addressing information and represents a
service address by which the party receives
management traffic
o Its partyProxyFor component is called the
party and represents the identity of a second
party or other management entity with
interaction may be necessary to satisfy
management requests. In this context, the
noProxy signifies that the party responds to
management requests by entirely local mechanisms
o Its partyMaxMessageSize component is called
maximum message size and represents the length
octets of the largest SNMP message this party
prepared to accept
o Its partyAuthProtocol component is called
authentication protocol and identifies a protocol and
mechanism by which all messages generated by the
Davin, Galvin, & McCloghrie [Page 4]
RFC 1351 SNMP Administrative Model July 1992
are authenticated as to integrity and origin. In
context, the value noAuth signifies that
generated by the party are not authenticated as
integrity and origin
o Its partyAuthClock component is called
authentication clock and represents a notion of
current time that is specific to the party.
significance of this component is specific to
authentication protocol
o Its partyAuthLastMsg component is called
last-timestamp and represents a notion of
associated with the most recent, authentic
message generated by the party. The significance of
component is specific to the authentication protocol
o Its partyAuthNonce component is called the
and represents a monotonically increasing
associated with the most recent, authentic
message generated by the party. The significance of
component is specific to the authentication protocol
o Its partyAuthPrivate component is called the
authentication key and represents any secret
needed to support the authentication protocol.
significance of this component is specific to
authentication protocol
o Its partyAuthPublic component is called the
authentication key and represents any public value
may be needed to support the authentication protocol
The significance of this component is specific to
authentication protocol
o Its partyAuthLifetime component is called
lifetime and represents an administrative upper
on acceptable delivery delay for protocol
generated by the party. The significance of
component is specific to the authentication protocol
o Its partyPrivProtocol component is called the
protocol and identifies a protocol and a mechanism
which all protocol messages received by the party
protected from disclosure. In this context, the
noPriv signifies that messages received by the party
not protected from disclosure
Davin, Galvin, & McCloghrie [Page 5]
RFC 1351 SNMP Administrative Model July 1992
o Its partyPrivPrivate component is called the
privacy key and represents any secret value needed
support the privacy protocol. The significance of
component is specific to the privacy protocol
o Its partyPrivPublic component is called the
privacy key and represents any public value that may
needed to support the privacy protocol. The
of this component is specific to the privacy protocol
If, for all SNMP parties realized by a SNMP protocol entity,
authentication protocol is noAuth and the privacy protocol is noPriv
then that protocol entity is called non-secure
3.2 SNMP Protocol
A SNMP protocol entity is an actual process which performs
management operations by generating and/or responding to
protocol messages in the manner specified in [1]. When a
entity is acting as a particular SNMP party (see Section 3.1),
operation of that entity must be restricted to the subset of
possible operations that is administratively defined for that party
By definition, the operation of a SNMP protocol entity requires
concurrency between processing of any single protocol message (by
particular SNMP party) and processing of any other protocol
(by a potentially different SNMP party). Accordingly,
of a SNMP protocol entity to support more than one party need not
multi-threaded. However, there may be situations where
may choose to use multi-threading
Architecturally, every SNMP entity maintains a local database
represents all SNMP parties known to it -- those whose operation
realized locally, those whose operation is realized by
interactions with remote parties or devices, and those
operation is realized by remote entities. In addition, every
protocol entity maintains a local database that represents an
control policy (see Section 3.11) that defines the access
accorded to known SNMP parties
3.3 SNMP Management
A SNMP management station is the operational role assumed by a
party when it initiates SNMP management operations by the
of appropriate SNMP protocol messages or when it receives
processes trap notifications
Sometimes, the term SNMP management station is applied to
Davin, Galvin, & McCloghrie [Page 6]
RFC 1351 SNMP Administrative Model July 1992
implementations of the SNMP (in graphics workstations, for example
that focus upon this operational role. Such partial
may provide for convenient, local invocation of management services
but they may provide little or no support for performing
management operations on behalf of remote protocol users
3.4 SNMP
A SNMP agent is the operational role assumed by a SNMP party when
performs SNMP management operations in response to received
protocol messages such as those generated by a SNMP
station (see Section 3.3).
Sometimes, the term SNMP agent is applied to partial
of the SNMP (in embedded systems, for example) that focus upon
operational role. Such partial implementations provide
realization of SNMP management operations on behalf of remote
of management services, but they may provide little or no support
local invocation of such services
3.5 View
A view subtree is the set of all MIB object instances which have
common ASN.1 OBJECT IDENTIFIER prefix to their names. A view
is identified by the OBJECT IDENTIFIER value which is the
OBJECT IDENTIFIER prefix common to all (potential) MIB
instances in that subtree
3.6 MIB
A MIB view is a subset of the set of all instances of all
types defined according to the Internet-standard SMI [2] (i.e.,
the universal set of all instances of all MIB objects), subject
the following constraints
o Each element of a MIB view is uniquely named by
ASN.1 OBJECT IDENTIFIER value. As such
identically named instances of a particular object
(e.g., in different agents) must be contained
different MIB views. That is, a particular
instance name resolves within a particular MIB view
at most one object instance
o Every MIB view is defined as a collection of
subtrees
Davin, Galvin, & McCloghrie [Page 7]
RFC 1351 SNMP Administrative Model July 1992
3.7 SNMP Management
A SNMP management communication is a communication from one
SNMP party to a second specified SNMP party about
information that is represented in the MIB view of the
party. In particular, a SNMP management communication may
o a query by the originating party about information
the MIB view of the addressed party (e.g.,
and getNextRequest),
o an indicative assertion to the addressed party
information in the MIB view of the originating
(e.g., getResponse or trapNotification),
o an imperative assertion by the originating party
information in the MIB view of the addressed
(e.g., setRequest).
A management communication is represented by an ASN.1 value with
SnmpMgmtCom ::= [1] IMPLICIT SEQUENCE {
OBJECT IDENTIFIER
OBJECT IDENTIFIER
}
For each SnmpMgmtCom value that represents a SNMP
communication, the following statements are true
o Its dstParty component is called the destination
identifies the SNMP party to which the
is directed
o Its srcParty component is called the source
identifies the SNMP party from which
communication is originated
o Its pdu component has the form and
attributed to it in [1].
Davin, Galvin, & McCloghrie [Page 8]
RFC 1351 SNMP Administrative Model July 1992
3.8 SNMP Authenticated Management
A SNMP authenticated management communication is a SNMP
communication (see Section 3.7) for which the originating SNMP
is (possibly) reliably identified and for which the integrity of
transmission of the communication is (possibly) protected.
authenticated management communication is represented by an ASN.1
value with the
SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE {
ANY, - defined by authentication
}
For each SnmpAuthMsg value that represents a SNMP
management communication, the following statements are true
o Its authInfo component is called the
information and represents information required
support of the authentication protocol used by
SNMP party originating the message. The
significance of the authentication information is
to the authentication protocol in use; it has no effect
the application semantics of the communication
than its use by the authentication protocol
determining whether the communication is authentic
not
o Its authData component is called the
data and represents a SNMP
communication
3.9 SNMP Private Management
A SNMP private management communication is a SNMP
management communication (see Section 3.8) that is (possibly
protected from disclosure. A private management communication
represented by an ASN.1 value with the
Davin, Galvin, & McCloghrie [Page 9]
RFC 1351 SNMP Administrative Model July 1992
SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE {
OBJECT IDENTIFIER
[1] IMPLICIT OCTET
}
For each SnmpPrivMsg value that represents a SNMP private
communication, the following statements are true
o Its privDst component is called the privacy
and identifies the SNMP party to which
communication is directed
o Its privData component is called the privacy data
represents the (possibly encrypted)
(according to the conventions of [3] and [1]) of a
authenticated management communication (
Section 3.8).
3.10 SNMP Management Communication
A SNMP management communication class corresponds to a specific
PDU type defined in [1]. A management communication class
represented by an ASN.1 INTEGER value according to the type of
identifying PDU (see Table 1).
Get 1
GetNext 2
GetResponse 4
Set 8
Trap 16
Table 1: Management Communication
The value by which a communication class is represented is
as 2 raised to the value of the ASN.1 context-specific tag for
appropriate SNMP PDU
A set of management communication classes is represented by the ASN.1
INTEGER value that is the sum of the representations of
communication classes in that set. The null set is represented by
value zero
Davin, Galvin, & McCloghrie [Page 10]
RFC 1351 SNMP Administrative Model July 1992
3.11 SNMP Access Control
A SNMP access control policy is a specification of a local
policy in terms of the network management communication classes
are authorized between pairs of SNMP parties. Architecturally, such
specification comprises three parts
o the targets of SNMP access control - the SNMP
that may perform management operations as
by management communications received from
parties
o the subjects of SNMP access control - the SNMP
that may request, by sending
communications to other parties, that
operations be performed,
o the policy that specifies the classes of
management communications that a particular target
authorized to accept from a particular subject
Access to individual MIB object instances is determined
since by definition each (target) SNMP party performs operations
exactly one MIB view. Thus, defining the permitted access of
(reliably) identified subject party to a particular target
effectively defines the access permitted by that subject to
target's MIB view and, accordingly, to particular MIB
instances
Conceptually, a SNMP access policy is represented by a collection
ASN.1 values with the following syntax
AclEntry ::= SEQUENCE {
OBJECT IDENTIFIER
OBJECT IDENTIFIER
}
For each such value that represents one part of a SNMP access policy
the following statements are true
Davin, Galvin, & McCloghrie [Page 11]
RFC 1351 SNMP Administrative Model July 1992
o Its aclTarget component is called the target
identifies the SNMP party to which the partial
permits access
o Its aclSubject component is called the subject
identifies the SNMP party to which the partial
grants privileges
o Its aclPrivileges component is called the privileges
represents a set of SNMP management
classes that are authorized to be processed by
specified target party when received from the
subject party
3.12 SNMP Proxy
A SNMP proxy party is a SNMP party that performs
operations by communicating with another, logically remote party
When communication between a logically remote party and a SNMP
party is via the SNMP (over any transport protocol), then the
party is called a SNMP native proxy party. Deployment of SNMP
proxy parties is a means whereby the processing or bandwidth costs
management may be amortized or shifted -- thereby facilitating
construction of large management systems
When communication between a logically remote party and a SNMP
party is not via the SNMP, then the proxy party is called a
foreign proxy party. Deployment of foreign proxy parties is a
whereby otherwise unmanageable devices or portions of an internet
be managed via the SNMP
The transparency principle that defines the behavior of a SNMP
in general applies in particular to a SNMP proxy party
The manner in which one SNMP party
SNMP protocol messages received from
SNMP party is entirely transparent to the latter
The transparency principle derives directly from the historical
philosophy of divorcing architecture from implementation. To
dichotomy are attributable many of the most valuable benefits in
the information and distribution models of the management framework
and it is the architectural cornerstone upon which large
systems may be built. Consistent with this philosophy, although
implementation of SNMP proxy agents in certain environments
resemble that of a transport-layer bridge, this
implementation strategy (or any other!) does not merit
Davin, Galvin, & McCloghrie [Page 12]
RFC 1351 SNMP Administrative Model July 1992
recognition either in the SNMP management architecture or in
mechanisms for proxy administration
Implicit in the transparency principle is the requirement that
semantics of SNMP management operations are preserved between any
SNMP peers. In particular, the "as if simultaneous" semantics of
Set operation are extremely difficult to guarantee if its
extends to management information resident at multiple
locations. For this reason, proxy configurations that admit
operations that apply to information at multiple locations
discouraged, although such operations are not explicitly precluded
the architecture in those rare cases where they might be supported
a conformant way
Also implicit in the transparency principle is the requirement that
throughout its interaction with a proxy agent, a management
is supplied with no information about the nature or progress of
proxy mechanisms by which its requests are realized. That is,
should seem to the management station -- except for any
in underlying transport address -- as if it were interacting via
directly with the proxied device. Thus, a timeout in
communication between a proxy agent and its proxied device should
represented as a timeout in the communication between the
station and the proxy agent. Similarly, an error response from
proxied device should -- as much as possible -- be represented by
corresponding error response in the interaction between the
agent and management station
3.13
This section describes the procedures followed by a SNMP
entity in processing SNMP messages. These procedures are
of the particular authentication and privacy protocols that may be
use
3.13.1 Generating a
This section describes the procedure followed by a SNMP
entity whenever either a management request or a trap notification
to be transmitted by a SNMP party
1. An ASN.1 SnmpMgmtCom value is constructed
which the srcParty component identifies the
party, for which the dstParty component identifies
receiving party, and for which the other
represents the desired management operation
Davin, Galvin, & McCloghrie [Page 13]
RFC 1351 SNMP Administrative Model July 1992
2. The local database is consulted to determine
authentication protocol and other relevant
for the originating SNMP party
3. An ASN.1 SnmpAuthMsg value is constructed
the following properties
o Its authInfo component is constructed
to the authentication protocol specified for
originating party
In particular, if the authentication protocol for
originating SNMP party is identified as noAuth
then this component corresponds to the
STRING value of zero length
o Its authData component is the
SnmpMgmtCom value
4. The local database is consulted to determine the
protocol and other relevant information for the
SNMP party
5. An ASN.1 SnmpPrivMsg value is constructed with
following properties
o Its privDst component identifies the
SNMP party
o Its privData component is the (
encrypted) serialization of the
value according to the conventions of [3] and [1].
In particular, if the privacy protocol for
receiving SNMP party is identified as noPriv,
the privData component is unencrypted
Otherwise, the privData component is
according to the privacy protocol
6. The constructed SnmpPrivMsg value is
according to the conventions of [3] and [1].
7. The serialized SnmpPrivMsg value is
using the transport address and transport domain
the receiving SNMP party
Davin, Galvin, & McCloghrie [Page 14]
RFC 1351 SNMP Administrative Model July 1992
3.13.2 Processing a Received
This section describes the procedure followed by a SNMP
entity whenever a management communication is received
1. If the received message is not the serialization (
to the conventions of [3] and [1]) of an ASN.1
SnmpPrivMsg value, then that message is
without further processing
2. The local database is consulted for information
the receiving SNMP party identified by the
component of the SnmpPrivMsg value
3. If information about the receiving SNMP party is
from the local database, or specifies a transport
and address which indicates that the receiving party'
operation is not realized by the local SNMP
entity, then the received message is discarded
further processing
4. An ASN.1 OCTET STRING value is
(possibly by decryption, according to the
protocol in use) from the privData component of
SnmpPrivMsg value
In particular, if the privacy protocol recorded for
party is noPriv, then the OCTET STRING
corresponds exactly to the privData component of
SnmpPrivMsg value
5. If the OCTET STRING value is not the
(according to the conventions of [3] and [1]) of an ASN.1
SnmpAuthMsg value, then the received message
discarded without further processing
6. If the dstParty component of the
component of the obtained SnmpAuthMsg value
not the same as the privDst component of
SnmpPrivMsg value, then the received message
discarded without further processing
7. The local database is consulted for information
the originating SNMP party identified by the
component of the authData component of
SnmpAuthMsg value
Davin, Galvin, & McCloghrie [Page 15]
RFC 1351 SNMP Administrative Model July 1992
8. If information about the originating SNMP party
absent from the local database, then the
message is discarded without further processing
9. The obtained SnmpAuthMsg value is
according to the authentication protocol and
relevant information associated with the
SNMP party in the local database
In particular, if the authentication protocol is
as noAuth, then the SnmpAuthMsg value is
evaluated as authentic
10. If the SnmpAuthMsg value is evaluated
unauthentic, then the received message is
without further processing, and an authentication
is noted
11. The ASN.1 SnmpMgmtCom value is extracted
the authData component of the
value
12. The local database is consulted for access
permitted by the local access policy to the
SNMP party with respect to the receiving SNMP party
13. The management communication class is
from the ASN.1 tag value associated with
SnmpMgmtCom value
14. If the management communication class of the
message is either 16 or 4 (i.e., Trap or GetResponse)
this class is not among the access privileges, then
received message is discarded without further processing
15. If the management communication class of the
message is not among the access privileges, then
received message is discarded without further
after generation and transmission of a response message
This response message is directed to the
SNMP party on behalf of the receiving SNMP party.
var-bind-list and request-id components are
to those of the received request. Its error-
component is zero and its error-status component
readOnly
16. If the proxied party associated with the receiving
party in the local database is identified as noProxy
Davin, Galvin, & McCloghrie [Page 16]
RFC 1351 SNMP Administrative Model July 1992
then the management operation represented by
SnmpMgmtCom value is performed by the
SNMP protocol entity with respect to the MIB
identified with the receiving SNMP party according
the procedures set forth in [1].
17. If the proxied party associated with the receiving
party in the local database is not identified as noProxy
then the management operation represented by
SnmpMgmtCom value is performed
appropriate cooperation between the receiving
party and the identified proxied party
In particular, if the transport domain associated
the identified proxied party in the local database
rfc1351Domain, then the operation requested
the received message is performed by the generation of
corresponding request to the proxied party on behalf
the receiving party. If the received message requires
response from the local SNMP protocol entity, then
response is subsequently generated from the response (
any) received from the proxied party corresponding
the newly generated request
3.13.3 Generating a
This section describes the procedure followed by a SNMP
entity whenever a response to a management request is generated
The procedure for generating a response to a SNMP management
is identical to the procedure for transmitting a request (see
3.13.1), except for the derivation of the transport domain
address information. In this case, the response is transmitted
the transport domain and address from which the corresponding
originated -- even if that is different from the
information recorded in the local database
4. Application of the
This section describes how the administrative model set forth
is applied to realize effective network management in a variety
configurations and environments. Several types of
configurations are identified, and an example of each is presented
4.1 Non-Secure Minimal Agent
This section presents an example configuration for a minimal, non
secure SNMP agent that interacts with one or more SNMP
Davin, Galvin, & McCloghrie [Page 17]
RFC 1351 SNMP Administrative Model July 1992
stations. Table 2 presents information about SNMP parties that
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
port 161 at IP address 1.2.3.4 using the party identity gracie;
example manager operates at UDP port 2001 at IP address 1.2.3.5
the identity george. At minimum, a non-secure SNMP
implementation must provide for administrative configuration (
non-volatile storage) of the identities and transport addresses
two SNMP parties: itself and a remote peer. Strictly speaking,
information about these two parties (including access
information) need not be configurable
Suppose that the managing party george wishes to interrogate
agent named gracie by issuing a SNMP GetNext request message.
manager consults its local database of party information. Because
authentication protocol for the party george is recorded as noAuth
the GetNext request message generated by the manager is
Identity gracie
(agent) (manager
Domain rfc1351Domain rfc1351
Address 1.2.3.4, 161 1.2.3.5, 2001
Proxied Party noProxy
Auth Prot noAuth
Auth Priv Key "" ""
Auth Pub Key "" ""
Auth Clock 0 0
Auth Last Msg 0 0
Auth Lifetime 0 0
Priv Prot noPriv
Priv Priv Key "" ""
Priv Pub Key "" ""
Table 2: Party Information for Minimal
Target Subject
gracie george 3
george gracie 20
Table 3: Access Information for Minimal
authenticated as to origin and integrity. Because, according to
manager's database, the privacy protocol for the party gracie
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
transport address (IP address 1.2.3.4, UDP port 161) associated
the manager's database with the party gracie
When the GetNext request message is received at the agent,
identity of the party to which it is directed (gracie) is
from the message, and the receiving protocol entity consults
local database of party information. Because the privacy protocol
the party gracie is recorded as noPriv, the received message
assumed not to be protected from disclosure. Similarly, the
of the originating party (george) is extracted, and the local
database is consulted. Because the authentication protocol for
party george is recorded as noAuth, the received message
immediately accepted as authentic
The received message is fully processed only if the access
database local to the agent authorizes GetNext request
by the party george with respect to the agent party gracie.
access policy database presented as Table 3 authorizes
communications (as well as Get operations).
When the received request is processed, a GetResponse message
generated with gracie as the source party and george, the party
which the request originated, as the destination party. Because
authentication protocol for gracie is recorded in the local
database as noAuth, the generated GetResponse message is
authenticated as to origin or integrity. Because, according to
local database, the privacy protocol for the party george is noPriv
the response message is not protected from disclosure. The
message is transmitted to the transport address from which
corresponding request originated -- without regard for the
address associated with george in the local database
When the generated response is received by the manager, the
of the party to which it is directed (george) is extracted from
message, and the manager consults its local database of
information. Because the privacy protocol for the party george
recorded as noPriv, the received response is assumed not to
protected from disclosure. Similarly, the identity of the
party (gracie) is extracted, and the local party database
consulted. Because the authentication protocol for the party
is recorded as noAuth, the received response is immediately
as authentic
The received message is fully processed only if the access
database local to the manager authorizes GetResponse
by the party gracie with respect to the manager party george.
access policy database presented as Table 3 authorizes such
Davin, Galvin, & McCloghrie [Page 19]
RFC 1351 SNMP Administrative Model July 1992
messages (as well as Trap messages).
4.2 Secure Minimal Agent
This section presents an example configuration for a secure,
SNMP agent that interacts with a single SNMP management station
Table 4 presents information about SNMP parties that is known both
the minimal agent and to the manager, while Table 5
similarly common information about the local access policy
The interaction of manager and agent in this configuration is
similar to that sketched above for the non-secure minimal agent --
except that all protocol messages are authenticated as to origin
integrity and protected from disclosure. This example
encryption in order to support distribution of secret keys via
SNMP itself. A more elaborate example comprising an additional
of SNMP parties could support the exchange of non-secret
in authenticated messages without incurring the cost of encryption
An actual secure agent configuration may require SNMP parties
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
example
Identity ollie
(agent) (manager
Domain rfc1351Domain rfc1351
Address 1.2.3.4, 161 1.2.3.5, 2001
Proxied Party noProxy
Auth Prot md5AuthProtocol md5
Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789"
Auth Pub Key "" ""
Auth Clock 0 0
Auth Last Msg 0 0
Auth Lifetime 500 500
Priv Prot desPrivProtocol
Priv Priv Key "MNOPQR0123456789" "STUVWX0123456789"
Priv Pub Key "" ""
Table 4: Party Information for Secure Minimal
Target Subject
ollie stan 3
stan ollie 20
Table 5: Access Information for Secure Minimal
Davin, Galvin, & McCloghrie [Page 20]
RFC 1351 SNMP Administrative Model July 1992
As represented in Table 4, the example agent party operates at
port 161 at IP address 1.2.3.4 using the party identity ollie;
example manager operates at UDP port 2001 at IP address 1.2.3.5
the identity stan. At minimum, a secure SNMP agent
must provide for administrative configuration (and non-
storage) of relevant information about two SNMP parties: itself and
remote peer. Both ollie and stan authenticate all messages that
generate by using the SNMP authentication protocol md5
and their distinct, private authentication keys. Although
private authentication key values ("0123456789ABCDEF"
"GHIJKL0123456789") are presented here for expository purposes
knowledge of private authentication keys is not normally afforded
human beings and is confined to those portions of the
implementation that require it
When using the md5AuthProtocol, the public authentication key
each SNMP party is never used in authentication and verification
SNMP exchanges. Also, because the md5AuthProtocol is symmetric
character, the private authentication key for each party must
known to another SNMP party with which authenticated communication
desired. In contrast, asymmetric (public key)
protocols would not depend upon sharing of a private key for
operation
All protocol messages originated by the party stan are encrypted
transmission using the desPrivProtocol privacy protocol and
private key "STUVWX0123456789"; they are decrypted upon
according to the same protocol and key. Similarly, all
originated by the party ollie are encrypted on transmission using
desPrivProtocol protocol and private privacy key "MNOPQR0123456789";
they are correspondingly decrypted on reception. As
authentication keys, knowledge of private privacy keys is
normally afforded to human beings and is confined to those
of the protocol implementation that require it
4.3 Proxy
This section presents examples of SNMP proxy configurations. On
hand, foreign proxy configurations provide the capability to
non-SNMP devices. On the other hand, native proxy
allow an administrator to shift the computational burden of
management functionality away from network devices whose primary
is not management. To the extent that SNMP proxy agents function
points of aggregation for management information,
configurations may also reduce the bandwidth requirements of large
scale management activities
The example configurations in this section are simplified
Davin, Galvin, & McCloghrie [Page 21]
RFC 1351 SNMP Administrative Model July 1992
clarity: actual configurations may require additional parties
order to support clock synchronization and distribution of secrets
4.3.1 Foreign Proxy
This section presents an example configuration by which a
management station may manage network elements that do not
support the SNMP. This configuration centers on a SNMP proxy
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
the local database of the SNMP proxy agent. Table 7
information about SNMP parties that is recorded in the local
of the SNMP management station. Table 8 presents information
the access policy specified by the local administration
As represented in Table 6, the proxy agent party operates at UDP
161 at IP address 1.2.3.5 using the party identity moe; the
manager operates at UDP port 2002 at IP address 1.2.3.4 using
identity larry. Both larry and moe authenticate all messages
they generate by using the protocol md5AuthProtocol and
distinct, private authentication keys. Although these
authentication key values ("0123456789ABCDEF"
Identity larry moe
(manager) (proxy) (proxied
Domain rfc1351Domain rfc1351Domain
Address 1.2.3.4, 2002 1.2.3.5, 161 0x98765432
Proxied Party noProxy curly
Auth Prot md5AuthProtocol md5AuthProtocol
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
Priv Priv Key "" "" ""
Priv Pub Key "" "" ""
Table 6: Party Information for Proxy
Davin, Galvin, & McCloghrie [Page 22]
RFC 1351 SNMP Administrative Model July 1992
Identity larry
(manager) (proxy
Domain rfc1351Domain rfc1351
Address 1.2.3.4, 2002 1.2.3.5, 161
Proxied Party noProxy
Auth Prot md5AuthProtocol md5
Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789"
Auth Pub Key "" ""
Auth Clock 0 0
Auth Last Msg 0 0
Auth Lifetime 500 500
Priv Prot noPriv
Priv Priv Key "" ""
Priv Pub Key "" ""
Table 7: Party Information for Management
Target Subject
moe larry 3
larry moe 20
Table 8: Access Information for Foreign
"GHIJKL0123456789") are presented here for expository purposes
knowledge of private keys is not normally afforded to human
and is confined to those portions of the protocol implementation
require it
Although all SNMP agents that use cryptographic keys in
communication with other protocol entities will almost
engage in private SNMP exchanges to distribute those keys, in
to simplify this example, neither the management station nor
proxy agent sends or receives private SNMP communications. Thus,
privacy protocol for each of them is recorded as noPriv
The party curly does not send or receive SNMP protocol messages
rather, all communication with that party proceeds via a
proprietary protocol identified by the value acmeMgmtPrtcl.
the party curly does not participate in the SNMP, many of
attributes recorded for that party in a local database are ignored
In order to interrogate the proprietary device associated with
party curly, the management station larry constructs a SNMP
request and transmits it to the party moe operating (see Table 7)
UDP port 161, and IP address 1.2.3.5. This request is
using the private authentication key "0123456789ABCDEF."
Davin, Galvin, & McCloghrie [Page 23]
RFC 1351 SNMP Administrative Model July 1992
When that request is received by the party moe, the originator of
message is verified as being the party larry by using local
(see Table 6) of the private authentication key "0123456789ABCDEF."
Because party larry is authorized to issue GetNext requests
respect to party moe by the relevant access control policy (Table 8),
the request is accepted. Because the local database records
proxied party for party moe as curly, the request is satisfied by
translation into appropriate operations of the acmeMgmtPrtcl
at party curly. These new operations are transmitted to the
curly at the address 0x98765432 in the acmeMgmtPrtcl domain
When and if the proprietary protocol exchange between the proxy
and the proprietary device concludes, a SNMP GetResponse
operation is constructed by the SNMP party moe to relay the
to party larry. This response communication is authenticated as
origin and integrity using the authentication
md5AuthProtocol and private authentication key "GHIJKL0123456789"
specified for transmissions from party moe. It is then transmitted
the SNMP party larry operating at the management station at
address 1.2.3.4 and UDP port 2002 (the source address for
corresponding request).
When this response is received by the party larry, the originator
the message is verified as being the party moe by using
knowledge (see Table 7) of the private authentication
"GHIJKL0123456789." Because party moe is authorized to
GetResponse communications with respect to party larry by
relevant access control policy (Table 8), the response is accepted
and the interrogation of the proprietary device is complete
It is especially useful to observe that the database of SNMP
recorded at the proxy agent (Table 6) need be neither static
configured exclusively by the management station. For instance
suppose that, in this example, the acmeMgmtPrtcl was a proprietary
MAC-layer mechanism for managing stations attached to a local
network. In such an environment, the SNMP party moe would reside at
SNMP proxy agent attached to such a LAN and could, by
in the LAN protocols, detect the attachment and disconnection
various stations on the LAN. In this scenario, the SNMP proxy
could easily adjust its local database of SNMP parties to
indirect management of the LAN stations by the SNMP
station. For each new LAN station detected, the SNMP proxy
would add to its database both an entry analogous to that for
curly (representing the new LAN station itself) and an
analogous to that for party moe (representing a proxy for that
station in the SNMP domain).
By using the SNMP to interrogate the database of parties held
Davin, Galvin, & McCloghrie [Page 24]
RFC 1351 SNMP Administrative Model July 1992
by the SNMP proxy agent, a SNMP management station can discover
interact with new stations as they are attached to the LAN
4.3.2 Native Proxy
This section presents an example configuration that supports
native proxy operations -- indirect interaction between a SNMP
and a management station that is mediated by a second SNMP (proxy
agent
This example configuration is similar to that presented in
discussion of SNMP foreign proxy above. In this example, however,
party associated with the identity curly receives messages via
SNMP, and, accordingly interacts with the SNMP proxy agent moe
authenticated SNMP communications
Table 9 presents information about SNMP parties that is recorded
the local database of the SNMP proxy agent. Table 7
information about SNMP parties that is recorded in the local
of the SNMP management station. Table 10 presents information
the access policy specified by the local administration
As represented in Table 9, the proxy party operates at UDP port 161
at IP address 1.2.3.5 using the party identity moe
Identity larry moe
(manager) (proxy) (proxied
Domain rfc1351Domain rfc1351Domain rfc1351
Address 1.2.3.4, 2002 1.2.3.5, 161 1.2.3.6, 16
Proxied Party noProxy curly
Auth Prot md5AuthProtocol md5AuthProtocol md5
Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789" "MNOPQR0123456789"
Auth Pub Key "" "" ""
Auth Clock 0 0 0
Auth Last Msg 0 0 0
Auth Lifetime 500 500 500
Priv Prot noPriv noPriv
Priv Priv Key "" "" ""
Priv Pub Key "" "" ""
Table 9: Party Information for Proxy
Davin, Galvin, & McCloghrie [Page 25]
RFC 1351 SNMP Administrative Model July 1992
Target Subject
moe larry 3
larry moe 20
curly moe 3
moe curly 20
Table 10: Access Information for Native
the example manager operates at UDP port 2002 at IP address 1.2.3.4
using the identity larry; the proxied party operates at UDP port 161
at IP address 1.2.3.6 using the party identity curly.
generated by all three SNMP parties are authenticated as to
and integrity by using the authentication protocol md5
and distinct, private authentication keys. Although these private
values ("0123456789ABCDEF," "GHIJKL0123456789,"
"MNOPQR0123456789") are presented here for expository purposes
knowledge of private keys is not normally afforded to human
and is confined to those portions of the protocol implementation
require it
In order to interrogate the proxied device associated with the
curly, the management station larry constructs a SNMP GetNext
and transmits it to the party moe operating (see Table 7) at UDP
161 and IP address 1.2.3.5. This request is authenticated using
private authentication key "0123456789ABCDEF."
When that request is received by the party moe, the originator of
message is verified as being the party larry by using local
(see Table 9) of the private authentication key "0123456789ABCDEF."
Because party larry is authorized to issue GetNext (and Get)
with respect to party moe by the relevant access control
(Table 10), the request is accepted. Because the local
records the proxied party for party moe as curly, the request
satisfied by its translation into a corresponding SNMP
request directed from party moe to party curly. This
communication is authenticated using the private authentication
"GHIJKL0123456789" and transmitted to party curly at the IP
1.2.3.6.
When this new request is received by the party curly, the
of the message is verified as being the party moe by using
knowledge (see Table 9) of the private authentication
"GHIJKL0123456789." Because party moe is authorized to issue
(and Get) requests with respect to party curly by the relevant
control policy (Table 10), the request is accepted. Because the
database records the proxied party for party curly as noProxy,
GetNext request is satisfied by local mechanisms. A SNMP
message representing the results of the query is then generated
Davin, Galvin, & McCloghrie [Page 26]
RFC 1351 SNMP Administrative Model July 1992
party curly. This response communication is authenticated as
origin and integrity using the private authentication
"MNOPQR0123456789" and transmitted to party moe at IP address 1.2.3.5
(the source address for the corresponding request).
When this response is received by party moe, the originator of
message is verified as being the party curly by using local
(see Table 9) of the private authentication key "MNOPQR0123456789."
Because party curly is authorized to issue GetResponse
with respect to party moe by the relevant access control
(Table 10), the response is not rejected. Instead, it is
into a response to the original GetNext request from party larry
This response is authenticated as to origin and integrity using
private authentication key "GHIJKL0123456789" and is transmitted
the party larry at IP address 1.2.3.4 (the source address for
original request).
When th