Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2573

SNMP Applications

Pages: 72
Obsoletes:  2273
Obsoleted by:  3413
Part 3 of 3 – Pages 61 to 72
First   Prev   None

ToP   noToC   RFC2573 - Page 61   prevText

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 each entry in 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 Unconfirmed-Class or a Confirmed-Class PDU is determined by the value of the snmpNotifyType object. If the value of this object is trap(1), the notification should contain an Unconfirmed-Class PDU.
ToP   noToC   RFC2573 - Page 62
   If the value of this object is inform(2), then the notification
   should contain a Confirmed-Class PDU, and the timeout time and number
   of retries for the notification are the value of
   snmpTargetAddrTimeout and snmpTargetAddrRetryCount.  Note that the
   exception to these rules is when the snmpTargetParamsMPModel object
   indicates an SNMP version which supports a different PDU version.  In
   this case, the notification may be sent using a different PDU type
   ([COEX] defines the PDU type in the case where the outgoing SNMP
   version is SNMPv1).

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) is specifically included, and none of the object instances to be included in the variable-bindings of the notification are 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.
ToP   noToC   RFC2573 - Page 63
   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.  For a notification name, if none match,
   then the notification name is considered excluded, and the
   notification should not be sent to this management target.  For an
   object instance, if none match, the object instance is considered
   included, and the notification may 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 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 Read- Class PDU. The snmpProxyType must be write(2) if the request is a Write-Class PDU. - The contextEngineID must equal the snmpProxyContextEngineID object.
ToP   noToC   RFC2573 - Page 64
     -  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 an Unconfirmed-Class PDU. The snmpProxyType must be inform(4) if the request is a Confirmed-Class PDU.
ToP   noToC   RFC2573 - Page 65
     -  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.
ToP   noToC   RFC2573 - Page 66

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: Harald Tveit Alvestrand (Maxware) Dave Battle (SNMP Research, Inc.) Alan Beard (Disney Worldwide Services) Paul Berrevoets (SWI Systemware/Halcyon Inc.) Martin Bjorklund (Ericsson) Uri Blumenthal (IBM T.J. Watson Research Center) Jeff Case (SNMP Research, Inc.) John Curran (BBN) Mike Daniele (Compaq Computer Corporation) T. Max Devlin (Eltrax Systems) John Flick (Hewlett Packard) Rob Frye (MCI) Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) David Harrington (Cabletron Systems Inc.) Lauren Heintz (BMC Software, Inc.) N.C. Hien (IBM T.J. Watson Research Center) Michael Kirkham (InterWorking Labs, Inc.) Dave Levi (SNMP Research, Inc.) Louis A Mamakos (UUNET Technologies Inc.) Joe Marzot (Nortel Networks) Paul Meyer (Secure Computing Corporation) Keith McCloghrie (Cisco Systems) Bob Moore (IBM) Russ Mundy (TIS Labs at Network Associates) Bob Natale (ACE*COMM Corporation) Mike O'Dell (UUNET Technologies Inc.) Dave Perkins (DeskTalk) Peter Polkinghorne (Brunel University) Randy Presuhn (BMC Software, Inc.) David Reeder (TIS Labs at Network Associates) David Reid (SNMP Research, Inc.) Aleksey Romanov (Quality Quorum) Shawn Routhier (Epilogue) Juergen Schoenwaelder (TU Braunschweig) Bob Stewart (Cisco Systems) Mike Thatcher (Independent Consultant) 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:
ToP   noToC   RFC2573 - Page 67
     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. Finally, the MIBs described in this document contain potentially sensitive information. A security administrator may wish to limit access to these MIBs.

11. References

[COEX] The SNMPv3 Working Group, Frye, R.,Levi, D., Wijnen, B., "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", Work in Progress.
ToP   noToC   RFC2573 - Page 68
   [RFC1157]   Case, J., Fedor, M., Schoffstall, M. and J. Davin,
               "Simple Network Management Protocol", STD 15, RFC 1157,
               May 1990.

   [RFC1213]   McCloghrie, K. and M. Rose, Editors, "Management
               Information Base for Network Management of TCP/IP-based
               internets: MIB-II", STD 17, RFC 1213, March 1991.

   [RFC2578]   McCloghrie, K., Perkins, D. and J. Schoenwaelder,
               "Structure of Management Information Version 2 (SMIv2)",
               STD 58, RFC 2578, April 1999.

   [RFC2579]   McCloghrie, K., Perkins, D. and J.  Schoenwaelder,
               "Textual Conventions for SMIv2", STD 58, RFC 2579, April
               1999.

   [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)", RFC1905, 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", RFC1905, January 1996.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC2119, March 1997.

   [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
               for Describing SNMP Management Frameworks", RFC 2571,
               April 1999.

   [RFC2572]   Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
               "Message Processing and Dispatching for the Simple
               Network Management Protocol (SNMP)", RFC 2572, April
               1999.

   [RFC2575]  Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model for the Simple Network Management
               Protocol (SNMP)", RFC 2575, April 1999.
ToP   noToC   RFC2573 - Page 69
   [RFC2573] Levi, D. B., Meyer, P. and B. Stewart, "SNMP Applications",
               RFC 2573, April 1999.

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 651 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 2686 EMail: bstewart@cisco.com
ToP   noToC   RFC2573 - Page 70

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 = 3m
ToP   noToC   RFC2573 - Page 71
          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
ToP   noToC   RFC2573 - Page 72

Appendix B. Full Copyright Statement

Copyright (C) The Internet Society (1999). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.