rfc3014.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,460 行 · 第 1/4 页

Network Working Group                            Editor of this version:
Request for Comments: 3014                                  R. Kavasseri
Category: Standards Track                            Cisco Systems, Inc.
                                             Author of previous version:
                                                              B. Stewart
                                                           November 2000


                          Notification Log MIB

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects used for logging Simple
   Network Management Protocol (SNMP) Notifications.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.



















Kavasseri                   Standards Track                     [Page 1]

RFC 3014                  Notification Log MIB             November 2000


Table of Contents

   1 The SNMP Management Framework .................................  2
   2 Overview ......................................................  3
   2.1 Environment .................................................  3
   2.1.1 SNMP Engines and Contexts .................................  4
   2.1.2 Security ..................................................  4
   2.2 Structure ...................................................  5
   2.2.1 Configuration .............................................  5
   2.2.2 Statistics ................................................  6
   2.2.3 Log .......................................................  6
   2.3 Example .....................................................  6
   3 Definitions ...................................................  7
   4 Intellectual Property ......................................... 23
   5 References .................................................... 23
   6 Security Considerations ....................................... 25
   7 Author's Address .............................................. 25
   8 Full Copyright Statement ...................................... 26

1.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

      o  An overall architecture, described in RFC 2571 [RFC2571].

      o  Mechanisms for describing and naming objects and events for the
         purpose of management.  The first version of this Structure of
         Management Information (SMI) is called SMIv1 and described in
         STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
         1215 [RFC1215].  The second version, called SMIv2, is described
         in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
         STD 58, RFC 2580 [RFC2580].

      o  Message protocols for transferring management information.  The
         first version of the SNMP message protocol is called SNMPv1 and
         described in STD 15, RFC 1157 [RFC1157].  A second version of
         the SNMP message protocol, which is not an Internet standards
         track protocol, is called SNMPv2c and described in RFC 1901
         [RFC1901] and RFC 1906 [RFC1906].  The third version of the
         message protocol is called SNMPv3 and described in RFC 1906
         [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].

      o  Protocol operations for accessing management information.  The
         first set of protocol operations and associated PDU formats is
         described in STD 15, RFC 1157 [RFC1157].  A second set of
         protocol operations and associated PDU formats is described in
         RFC 1905 [RFC1905].



Kavasseri                   Standards Track                     [Page 2]

RFC 3014                  Notification Log MIB             November 2000


      o  A set of fundamental applications described in RFC 2573
         [RFC2573] and the view-based access control mechanism described
         in RFC 2575 [RFC2575].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 2570 [RFC2570].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations.  The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64).  Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process.  However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

2.  Overview

   Systems that support SNMP often need a mechanism for recording
   Notification information as a hedge against lost Notifications,
   whether those are Traps or Informs [RFC1905] that exceed
   retransmission limits.  This MIB therefore provides common
   infrastructure for other MIBs in the form of a local logging
   function.  It is intended primarily for senders of Notifications but
   could be used also by receivers.

   Given the Notification Log MIB, individual MIBs bear less
   responsibility to record the transient information associated with an
   event against the possibility that the Notification message is lost,
   and applications can poll the log to verify that they have not missed
   important Notifications.

2.1.  Environment

   The overall environmental concerns for the MIB are:

      o  SNMP Engines and Contexts

      o  Security







Kavasseri                   Standards Track                     [Page 3]

RFC 3014                  Notification Log MIB             November 2000


2.1.1.  SNMP Engines and Contexts

   There are two distinct information flows from multiple notification
   originators that one may log.  The first is the notifications that
   are received (from one or more SNMP engines) for logging as SNMP
   informs and traps.  The other comprises notifications delivered to an
   SNMP engine at the interface to the notification originator (using a
   notification mechanism other than SNMP informs or traps).  The latter
   information flow (using a notification mechanism other than SNMP
   informs or traps) is modeled here as the SNMP engine (which maintains
   the log) sending a notification to itself.  The remainder of this
   section discusses the handling of the former information flow -
   notifications (received in the form of SNMP informs or traps) from
   multiple SNMP engines.

   As described in the SNMP architecture [RFC2571], a given system may
   support multiple SNMP engines operating independently of one another,
   each with its own SNMP engine identification.  Furthermore, within
   the purview of a given engine there may be multiple named management
   contexts supporting overlapping or disjoint sets of MIB objects and
   Notifications.  Thus, understanding a particular Notification
   requires knowing the SNMP engine and management context from whence
   it came.

   To provide the necessary source information for a logged
   Notification, the MIB includes objects to record that Notification's
   source SNMP engine ID and management context name.

2.1.2.  Security

   Security for Notifications is awkward since access control for the
   objects in the Notification can be checked only where the
   Notification is created.  Thus such checking is possible only for
   locally-generated Notifications, and even then only when security
   credentials are available.

   For the purpose of this discussion, "security credentials" means the
   input values for the abstract service interface function
   isAccessAllowed [RFC2571] and using those credentials means
   conceptually using that function to see that those credentials allow
   access to the MIB objects in question, operating as for a
   Notification Originator in [RFC2573].

   The Notification Log MIB has the notion of a "named log."  By using
   log names and view-based access control [RFC2575] a network
   administrator can provide different access for different users.  When
   an application creates a named log the security credentials of the
   creator stay associated with that log.



Kavasseri                   Standards Track                     [Page 4]

RFC 3014                  Notification Log MIB             November 2000


   A managed system with fewer resources MAY disallow the creation of
   named logs, providing only the default, null-named log.  Such a log
   has no implicit security credentials for Notification object access
   control and Notifications are put into it with no further checking.

   When putting locally-generated Notifications into a named log, the
   managed system MUST use the security credentials associated with that
   log and MUST apply the same access control rules as described for a
   Notification Originator in [RFC2573].

   The managed system SHOULD NOT apply access control when adding
   remotely-generated Notifications into either a named log or the
   default, null-named log.  In those cases the security of the
   information in the log SHOULD be left to the normal, overall access
   control for the log itself.

   The Notification Log MIB allows applications to set the maximum
   number of Notifications that can be logged, using
   nlmConfigGlobalEntryLimit.  Similarly, an application can set the
   maximum age using nlmConfigGlobalAgeOut, after which older
   Notifications MAY be timed out.  Please be aware that contention
   between multiple applications trying to set these objects to
   different values MAY affect the reliability and completeness of data
   seen by each application, i.e., it is possible that one application
   may change the value of either of these objects, resulting in some
   Notifications being deleted before the other applications have had a
   chance to see them.  This could be used to orchestrate a denial-of-
   service attack.  Methods for countering such an attack are for
   further study.

2.2.  Structure

   The MIB has the following sections:

      o  Configuration -- control over how much the log can hold and
         what Notifications are to be logged.

      o  Statistics -- indications of logging activity.

      o  Log -- the Notifications themselves.

2.2.1.  Configuration

   The configuration section contains objects to manage resource use by
   the MIB.

   This section also contains a table to specify what logs exist and how
   they operate.  Deciding which Notifications are to be logged depends



Kavasseri                   Standards Track                     [Page 5]

RFC 3014                  Notification Log MIB             November 2000


   on filters defined in the the snmpNotifyFilterTable in the standard
   SNMP Notification MIB [RFC2573] identified by the initial index
   (snmpNotifyFilterName) from that table.

2.2.2.  Statistics

   The statistics section contains counters for Notifications logged and
   discarded, supplying a means to understand the results of log
   capacity configuration and resource problems.

2.2.3.  Log

   The log contains the Notifications and the objects that came in their
   variable binding list, indexed by an integer that reflects when the
   entry was made.  An application that wants to collect all logged
   Notifications or to know if it may have missed any can keep track of
   the highest index it has retrieved and start from there on its next
   poll, checking sysUpTime for a discontinuity that would have reset
   the index and perhaps have lost entries.

   Variables are in a table indexed by Notification index and variable
   index within that Notification.  The values are kept as a
   "discriminated union," with one value object per variable.  Exactly
   which value object is instantiated depends on the SNMP data type of
   the variable, with a separate object of appropriate type for each
   distinct SNMP data type.

   An application can thus reconstruct the information from the
   Notification PDU from what is recorded in the log.

2.3.  Example

   Following is an example configuration of a named log for logging only
   linkUp and linkDown Notifications.

   In nlmConfigLogTable:

      nlmConfigLogFilterName.5."links"    = "link-status"
      nlmConfigLogEntryLimit.5."links"    = 0
      nlmConfigLogAdminStatus.5."links"   = enabled
      nlmConfigLogOperStatus.5."links"    = operational
      nlmConfigLogStorageType.5."links"   = nonVolatile
      nlmConfigLogEntryStatus.5."links"   = active

   Note that snmpTraps is:

      iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.5




Kavasseri                   Standards Track                     [Page 6]

RFC 3014                  Notification Log MIB             November 2000


   Or numerically:

      1.3.6.1.6.3.1.1.5

   And linkDown is snmpTraps.3 and linkUp is snmpTraps.4.

   So to allow the two Notifications in snmpNotifyFilterTable:

     snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.3 = ''H
     snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.3 = include
     snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.3
      = nonVolatile
     snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.3
      = active

     snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.4 = ''H
     snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.4 = include
     snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.4
      = nonVolatile
     snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.4
      = active

3.  Definitions