Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3413

Simple Network Management Protocol (SNMP) Applications

Pages: 74
Internet Standard: 62
Errata
STD 62 is also:  3411341234143415341634173418
Obsoletes:  2573
Part 4 of 4 – Pages 63 to 74
First   Prev   None

Top   ToC   RFC3413 - Page 63   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 all active entries in the snmpNotifyTable to find the management targets to be used for generating notifications. Each active entry in this table selects zero or more entries in the snmpTargetAddrTable. When a notification is generated, it is sent to all of the targets specified by the selected snmpTargetAddrTable entries (subject to the application of access control and notification filtering). 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 (this allows, for example, both traps and informs to be sent to the same target). 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   ToC   RFC3413 - Page 64
   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
   ([RFC2576] 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. To determine whether a particular notification name or object instance is excluded by the set of matching entries, compare the
Top   ToC   RFC3413 - Page 65
   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
   value of snmpNotifyFilterType, in the entry among those which match,
   and whose instance is lexicographically the largest, 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. - If the snmpProxyContextName object is supported, it must equal the contextName.
Top   ToC   RFC3413 - Page 66
   - The snmpProxyTargetParamsIn object identifies an entry in the
     snmpTargetParamsTable.  The messageProcessingModel, security model,
     securityName, and securityLevel 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. - The contextEngineID must equal the snmpProxyContextEngineID object. - If the snmpProxyContextName object is supported, it must equal the contextName.
Top   ToC   RFC3413 - Page 67
   - The snmpProxyTargetParamsIn object identifies an entry in the
     snmpTargetParamsTable.  The messageProcessingModel, security model,
     securityName, and securityLevel 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: Harald Tveit Alvestrand (Maxware) Dave Battle (SNMP Research, Inc.) Alan Beard (Disney Worldwide Services) Paul Berrevoets (SWI Systemware/Halcyon Inc.)
Top   ToC   RFC3413 - Page 68
      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 (Enterasys Networks)
      Lauren Heintz (BMC Software, Inc.)
      N.C. Hien (IBM T.J. Watson Research Center)
      Michael Kirkham (InterWorking Labs, Inc.)
      Dave Levi (Nortel Networks)
      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 (Lucent Technologies)

   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 (Enterasys Networks)
      Jeff Johnson (Cisco Systems)
      David Levi (Nortel Networks)
      John Linn (Openvision)
      Russ Mundy (Trusted Information Systems) chair
      Shawn Routhier (Epilogue)
      Glenn Waters (Nortel)
      Bert Wijnen (Lucent Technologies)
Top   ToC   RFC3413 - Page 69
   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 (Enterasys Networks)
      David Levi (Nortel Networks)
      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

11.1 Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
Top   ToC   RFC3413 - Page 70
   [RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Conformance Statements for
               SMIv2", STD 58, RFC 2580, April 1999.

   [RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An
               Architecture for describing Simple Network Management
               Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
               December 2002.

   [RFC3412]   Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
               "Message Processing and Dispatching for the Simple
               Network Management Protocol (SNMP)", STD 62, RFC 3412,
               December 2002.

   [RFC3415]   Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model (VACM) for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3415, December
               2002.

   [RFC3416]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
               Waldbusser, "Protocol Operations for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3416, December
               2002.

   [RFC3418]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
               Waldbusser, "Management Information Base (MIB) for the
               Simple Network Management Protocol (SNMP)", STD 62, RFC
               3418, December 2002.

11.2 Informative References

[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. [RFC2576] Frye, R.,Levi, D., Routhier, S. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", RFC 2576, February 1999.
Top   ToC   RFC3413 - Page 71

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, two rows in the snmpTargetTable, and two rows in the snmpNotifyTable. * 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.5.9/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)
Top   ToC   RFC3413 - Page 72
      * 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   ToC   RFC3413 - Page 73

Editors' Addresses

David B. Levi Nortel Networks 3505 Kesterwood Drive Knoxville, TN 37918 U.S.A. Phone: +1 865 686 0432 EMail: dlevi@nortelnetworks.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 Retired
Top   ToC   RFC3413 - Page 74
Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.