snmpProxyGroup OBJECT-GROUP
OBJECTS {
snmpProxyType,
snmpProxyContextEngineID,
snmpProxyContextName,
snmpProxyTargetParamsIn,
snmpProxySingleTargetOut,
snmpProxyMultipleTargetOut,
snmpProxyStorageType,
snmpProxyRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing remote configuration of
management target translation parameters for use by
proxy forwarder applications."
::= { snmpProxyGroups 3 }
END
5. Identification of Management Targets in Notification Originators
This section describes the mechanisms used by a notification
originator application when using the MIB module described in this
document to determine the set of management targets to be used when
generating a notification.
A notification originator uses the snmpNotifyTable to find the
management targets to be used for generating notifications. Each
active entry in this table identifies zero or more entries in the
snmpTargetAddrTable. Any entry in the snmpTargetAddrTable whose
snmpTargetAddrTagList object contains a tag value which is equal to a
value of snmpNotifyTag is selected by the snmpNotifyEntry which
contains that instance of snmpNotifyTag. Note that a particular
snmpTargetAddrEntry may be selected by multiple entries in the
snmpNotifyTable, resulting in multiple notifications being generated
using that snmpTargetAddrEntry.
Each snmpTargetAddrEntry contains a pointer to the
snmpTargetParamsTable (snmpTargetAddrParams). This pointer selects a
set of SNMP parameters to be used for generating notifications. If
the selected entry in the snmpTargetParamsTable does not exist, the
management target is not used to generate notifications.
The decision as to whether a notification should contain an SNMPv2-
Trap or Inform PDU is determined by the value of the snmpNotifyType
object. If the value of this object is trap(1), the notification
should contain an SNMPv2-Trap PDU. If the value of this object is
inform(2), then the notification should contain an Inform PDU, and
the timeout time and number of retries for the Inform are the value
of snmpTargetAddrTimeout and snmpTargetAddrRetryCount. Note that the
exception to these rules is when the snmpTargetParamsMPModel object
indicates SNMPv1. In this case, the notification is sent as a Trap
if the value of snmpNotifyTargetType is either trap(1) or inform(2).
6. Notification Filtering
This section describes the mechanisms used by a notification
originator application when using the MIB module described in this
document to filter generation of notifications.
A notification originator uses the snmpNotifyFilterTable to filter
notifications. A notification filter profile may be associated with
a particular entry in the snmpTargetParamsTable. The associated
filter profile is identified by an entry in the
snmpNotifyFilterProfileTable whose index is equal to the index of the
entry in the snmpTargetParamsTable. If no such entry exists in the
snmpNotifyFilterProfileTable, no filtering is performed for that
management target.
If such an entry does exist, the value of snmpNotifyFilterProfileName
of the entry is compared with the corresponding portion of the index
of all active entries in the snmpNotifyFilterTable. All such entries
for which this comparison results in an exact match are used for
filtering a notification generated using the associated
snmpTargetParamsEntry. If no such entries exist, no filtering is
performed, and a notification may be sent to the management target.
Otherwise, if matching entries do exist, a notification may be sent
if the NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (this
is the value of the element of the variable bindings whose name is
snmpTrapOID.0, i.e., the second variable binding), and all of the
object instances to be included in the variable-bindings of the
notification, are not specifically excluded by the matching entries.
Each set of snmpNotifyFilterTable entries is divided into two
collections of filter subtrees: the included filter subtrees, and
the excluded filter subtrees. The snmpNotifyFilterType object
defines the collection to which each matching entry belongs.
To determine whether a particular notification name or object
instance is excluded by the set of matching entries, compare the
notification name's or object instance's OBJECT IDENTIFIER with each
of the matching entries. If none match, then the notification name
or object instance is considered excluded, and the notification
should not be sent to this management target. If one or more match,
then the notification name or object instance is included or
excluded, according to the value of snmpNotifyFilterType in the entry
whose value of snmpNotifyFilterSubtree has the most sub-identifiers.
If multiple entries match and have the same number of sub-
identifiers, then the lexicographically greatest instance of
snmpNotifyFilterType among those which match determines the inclusion
or exclusion.
A notification name's or object instance's OBJECT IDENTIFIER X
matches an entry in the snmpNotifyFilterTable when the number of
sub-identifiers in X is at least as many as in the value of
snmpNotifyFilterSubtree for the entry, and each sub-identifier in the
value of snmpNotifyFilterSubtree matches its corresponding sub-
identifier in X. Two sub-identifiers match either if the
corresponding bit of snmpNotifyFilterMask is zero (the 'wild card'
value), or if the two sub-identifiers are equal.
7. Management Target Translation in Proxy Forwarder Applications
This section describes the mechanisms used by a proxy forwarder
application when using the MIB module described in this document to
translate incoming management target information into outgoing
management target information for the purpose of forwarding messages.
There are actually two mechanisms a proxy forwarder may use, one for
forwarding request messages, and one for forwarding notification
messages.
7.1. Management Target Translation for Request Forwarding
When forwarding request messages, the proxy forwarder will select a
single entry in the snmpProxyTable. To select this entry, it will
perform the following comparisons:
- The snmpProxyType must be read(1) if the request is a Get,
GetNext, or GetBulk request. The snmpProxyType must be
write(2) if the request is a Set request.
- The contextEngineId must equal the snmpProxyContextEngineID
object.
- If the snmpProxyContextName object is supported, it must equal
the contextName.
- The snmpProxyTargetParamsIn object identifies an entry in the
snmpTargetParamsTable. The messageProcessingModel,
securityLevel, security model, and securityName must match the
values of snmpTargetParamsMPModel,
snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName,
and snmpTargetParamsSecurityLevel of the identified entry in
the snmpTargetParamsTable.
There may be multiple entries in the snmpProxyTable for which these
comparisons succeed. The entry whose snmpProxyName has the
lexicographically smallest value and for which the comparisons
succeed will be selected by the proxy forwarder.
The outgoing management target information is identified by the value
of the snmpProxySingleTargetOut object of the selected entry. This
object identifies an entry in the snmpTargetAddrTable. The
identified entry in the snmpTargetAddrTable also contains a reference
to the snmpTargetParamsTable (snmpTargetAddrParams). If either the
identified entry in the snmpTargetAddrTable does not exist, or the
identified entry in the snmpTargetParamsTable does not exist, then
this snmpProxyEntry does not identify valid forwarding information,
and the proxy forwarder should attempt to identify another row.
If there is no entry in the snmpProxyTable for which all of the
conditions above may be met, then there is no appropriate forwarding
information, and the proxy forwarder should take appropriate actions.
Otherwise, The snmpTargetAddrTDomain, snmpTargetAddrTAddress,
snmpTargetAddrTimeout, and snmpTargetRetryCount of the identified
snmpTargetAddrEntry, and the snmpTargetParamsMPModel,
snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, and
snmpTargetParamsSecurityLevel of the identified snmpTargetParamsEntry
are used as the destination management target.
7.2. Management Target Translation for Notification Forwarding
When forwarding notification messages, the proxy forwarder will
select multiple entries in the snmpProxyTable. To select these
entries, it will perform the following comparisons:
- The snmpProxyType must be trap(3) if the notification is a
Trap. The snmpProxyType must be inform(4) if the request is
an Inform.
- The contextEngineId must equal the snmpProxyContextEngineID
object.
- If the snmpProxyContextName object is supported, it must equal
the contextName.
- The snmpProxyTargetParamsIn object identifies an entry in the
snmpTargetParamsTable. The messageProcessingModel,
securityLevel, security model, and securityName must match the
values of snmpTargetParamsMPModel,
snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName,
and snmpTargetParamsSecurityLevel of the identified entry in
the snmpTargetParamsTable.
All entries for which these conditions are met are selected. The
snmpProxyMultipleTargetOut object of each such entry is used to
select a set of entries in the snmpTargetAddrTable. Any
snmpTargetAddrEntry whose snmpTargetAddrTagList object contains a tag
value equal to the value of snmpProxyMultipleTargetOut, and whose
snmpTargetAddrParams object references an existing entry in the
snmpTargetParamsTable, is selected as a destination for the forwarded
notification.
8. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
9. Acknowledgments
This document is the result of the efforts of the SNMPv3 Working
Group. Some special thanks are in order to the following SNMPv3 WG
members:
Dave Battle (SNMP Research, Inc.)
Uri Blumenthal (IBM T.J. Watson Research Center)
Jeff Case (SNMP Research, Inc.)
John Curran (BBN)
T. Max Devlin (Hi-TECH Connections)
John Flick (Hewlett Packard)
David Harrington (Cabletron Systems Inc.)
N.C. Hien (IBM T.J. Watson Research Center)
Dave Levi (SNMP Research, Inc.)
Louis A Mamakos (UUNET Technologies Inc.)
Paul Meyer (Secure Computing Corporation)
Keith McCloghrie (Cisco Systems)
Russ Mundy (Trusted Information Systems, Inc.)
Bob Natale (ACE*COMM Corporation)
Mike O'Dell (UUNET Technologies Inc.)
Dave Perkins (DeskTalk)
Peter Polkinghorne (Brunel University)
Randy Presuhn (BMC Software, Inc.)
David Reid (SNMP Research, Inc.)
Shawn Routhier (Epilogue)
Juergen Schoenwaelder (TU Braunschweig)
Bob Stewart (Cisco Systems)
Bert Wijnen (IBM T.J. Watson Research Center)
The document is based on recommendations of the IETF Security and
Administrative Framework Evolution for SNMP Advisory Team. Members of
that Advisory Team were:
David Harrington (Cabletron Systems Inc.)
Jeff Johnson (Cisco Systems)
David Levi (SNMP Research Inc.)
John Linn (Openvision)
Russ Mundy (Trusted Information Systems) chair
Shawn Routhier (Epilogue)
Glenn Waters (Nortel)
Bert Wijnen (IBM T. J. Watson Research Center)
As recommended by the Advisory Team and the SNMPv3 Working Group
Charter, the design incorporates as much as practical from previous
RFCs and drafts. As a result, special thanks are due to the authors
of previous designs known as SNMPv2u and SNMPv2*:
Jeff Case (SNMP Research, Inc.)
David Harrington (Cabletron Systems Inc.)
David Levi (SNMP Research, Inc.)
Keith McCloghrie (Cisco Systems)
Brian O'Keefe (Hewlett Packard)
Marshall T. Rose (Dover Beach Consulting)
Jon Saperia (BGS Systems Inc.)
Steve Waldbusser (International Network Services)
Glenn W. Waters (Bell-Northern Research Ltd.)
10. Security Considerations
The SNMP applications described in this document typically have
direct access to MIB instrumentation. Thus, it is very important
that these applications be strict in their application of access
control as described in this document.
In addition, there may be some types of notification generator
applications which, rather than accessing MIB instrumentation using
access control, will obtain MIB information through other means (such
as from a command line). The implementors and users of such
applications must be responsible for not divulging MIB information
that normally would be inaccessible due to access control.
11. References
[RFC1157]
Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network
Management Protocol", RFC1157, May 1990.
[RFC1213]
McCloghrie, K. and M. Rose, Editors, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II", STD 17,
RFC1213, March 1991.
[RFC1902]
Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of
Management Information for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC1902, January 1996.
[RFC1903]
Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual
Conventions for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC1903, January 1996.
[RFC1905]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1905, January 1996.
[RFC1907]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC1907, January
1996.
[RFC1908]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework", RFC1908, January
1996.
[RFC2271]
Harrington, D., and B. Wijnen, "An Architecture for Describing SNMP
Management Frameworks", RFC2271, January 1998.
[RFC2272]
Case, J., Harrington, D., and B. Wijnen, "Message Processing and
Dispatching for the Simple Network Management Protocol (SNMP)", RFC
2272, January 1998.
[RFC2275]
Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model for the Simple Network Management Protocol (SNMP)",
RFC2275, January 1998.
12. Editors' Addresses
David B. Levi
SNMP Research, Inc.
3001 Kimberlin Heights Road
Knoxville, TN 37920-9716
U.S.A.
Phone: +1 423 573 1434
EMail: levi@snmp.com
Paul Meyer
Secure Computing Corporation
2675 Long Lake Road
Roseville, MN 55113
U.S.A.
Phone: +1 612 628 1592
EMail: paul_meyer@securecomputing.com
Bob Stewart
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
U.S.A.
Phone: +1 603 654 6923
EMail: bstewart@cisco.com
APPENDIX A - Trap Configuration Example
This section describes an example configuration for a Notification
Generator application which implements the snmpNotifyBasicCompliance
level. The example configuration specifies that the Notification
Generator should send notifications to 3 separate managers, using
authentication and no privacy for the first 2 managers, and using
both authentication and privacy for the third manager.
The configuration consists of three rows in the snmpTargetAddrTable,
and two rows in the snmpTargetTable.
snmpTargetAddrName SnmpAdminString,
snmpTargetAddrTDomain TDomain,
snmpTargetAddrTAddress TAddress,
snmpTargetAddrTimeout TimeInterval,
snmpTargetAddrRetryCount Integer32,
snmpTargetAddrTagList SnmpAdminString,
snmpTargetAddrParams SnmpAdminString,
snmpTargetAddrStorageType StorageType,
snmpTargetAddrRowStatus RowStatus
* snmpTargetAddrName = "addr1"
snmpTargetAddrTDomain = snmpUDPDomain
snmpTargetAddrTAddress = 128.1.2.3:162
snmpTargetAddrTagList = "group1"
snmpTargetAddrParams = "AuthNoPriv joe"
snmpTargetAddrStorageType = readOnly(5)
snmpTargetAddrRowStatus = active(1)
* snmpTargetAddrName = "addr2"
snmpTargetAddrTDomain = snmpUDPDomain
snmpTargetAddrTAddress = 128.2.4.6:162
snmpTargetAddrTagList = "group1"
snmpTargetAddrParams = "AuthNoPriv-joe"
snmpTargetAddrStorageType = readOnly(5)
snmpTargetAddrRowStatus = active(1)
* snmpTargetAddrName = "addr3"
snmpTargetAddrTDomain = snmpUDPDomain
snmpTargetAddrTAddress = 128.1.2.3:162
snmpTargetAddrTagList = "group2"
snmpTargetAddrParams = "AuthPriv-bob"
snmpTargetAddrStorageType = readOnly(5)
snmpTargetAddrRowStatus = active(1)
* snmpTargetParamsName = "AuthNoPriv-joe"
snmpTargetParamsMPModel = 3
snmpTargetParamsSecurityModel = 3 (USM)
snmpTargetParamsSecurityName = "joe"
snmpTargetParamsSecurityLevel = authNoPriv(2)
snmpTargetParamsStorageType = readOnly(5)
snmpTargetParamsRowStatus = active(1)
* snmpTargetParamsName = "AuthPriv-bob"
snmpTargetParamsMPModel = 3
snmpTargetParamsSecurityModel = 3 (USM)
snmpTargetParamsSecurityName = "bob"
snmpTargetParamsSecurityLevel = authPriv(3)
snmpTargetParamsStorageType = readOnly(5)
snmpTargetParamsRowStatus = active(1)
* snmpNotifyName = "group1"
snmpNotifyTag = "group1"
snmpNotifyType = trap(1)
snmpNotifyStorageType = readOnly(5)
snmpNotifyRowStatus = active(1)
* snmpNotifyName = "group2"
snmpNotifyTag = "group2"
snmpNotifyType = trap(1)
snmpNotifyStorageType = readOnly(5)
snmpNotifyRowStatus = active(1)
These entries define two groups of management targets. The first
group contains two management targets:
first target second target
------------ -------------
messageProcessingModel SNMPv3 SNMPv3
securityModel 3 (USM) 3 (USM)
securityName "joe" "joe"
securityLevel authNoPriv(2) authNoPriv(2)
transportDomain snmpUDPDomain snmpUDPDomain
transportAddress 128.1.2.3:162 128.2.4.6:162
And the second group contains a single management target:
messageProcessingModel SNMPv3
securityLevel authPriv(3)
securityModel 3 (USM)
securityName "bob"
transportDomain snmpUDPDomain
transportAddress 128.1.5.9:162
B. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.