Internet Draft G. Nunzi Document: draft-nunzi-check-mib-00.txt J. Quittek Expires: June 2004 M. Brunner T. Dietz NEC December 2003 Definitions of Managed Objects for the Health Check Operations Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). 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, that is targeted at increasing scalability of network monitoring via SNMP. In particular, the MIB module defined in this document describes a set of managed objects that allow to define a check procedure on a managed device. The result of the check is accumulated into a single managed object that can be read by a manager instead of reading all individual managed objects to be checked during the check procedure. Nunzi, Quittek, Brunner, Dietz [Page 1] Internet-Draft December 2003 Table of Contents 1 Introduction ................................................. 3 2 The Internet-Standard Management Framework ................... 3 3 Overview ..................................................... 3 3.1 Related MIB Modules ........................................ 4 3.1.1 Script MIB ............................................... 4 3.1.2 Expression MIB ........................................... 5 3.1.3 Event MIB ................................................ 5 4 Features ..................................................... 6 5 Structure of the MIB Module .................................. 8 5.1 checkCapabilities .......................................... 9 5.2 checkControl ............................................... 9 5.3 checkResultTable ........................................... 9 5.4 checkRuleTable ............................................. 10 5.5 checkFailureTable .......................................... 11 5.6 checkNotifications ......................................... 11 6 MIB Usage .................................................... 11 6.1 Usage Example .............................................. 12 7 Definitions .................................................. 13 8 Security Considerations ...................................... 33 9 Normative References ......................................... 34 10 Informative References ...................................... 35 11 Authors' Addresses .......................................... 35 12 IPR Notices ................................................. 36 13 Full Copyright Statement .................................... 36 Nunzi, Quittek, Brunner, Dietz [Page 2] Internet-Draft December 2003 1. Introduction 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 a set of managed objects that allow to define a health check procedure on a managed device. The result of the health check is accumulated into a single managed object that can be read by a manager instead of reading all managed objects to be checked during the health check procedure. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview Typically, checking healthiness of a managed node from a network management station requires reading a lot of individual managed objects at the node. The management applications checks if the values of these objects are within certain ranges; indicating safe states, or have reached values indicating failure or error states. Polling the values from the managed device to compare them with the ranges' boundaries causes load on the management station in the network and on the managed node. This limits the scalability of monitoring applications in terms of managed nodes and of managed objects to be checked per node. Configuring event notifications avoids the read operations; but can lead to flooding of notifications when a single failure triggers several events at the same time. In both approaches; the manager applications can experiment difficulties in monitoring a high number of managed objects per device in large networks. Nunzi, Quittek, Brunner, Dietz [Page 3] Internet-Draft December 2003 The basic idea of the CHECK MIB is to perform the comparison operations at the device and to aggregate the result into a single object. The manager can poll the single result object or, eventually, configure the device to send a notification if the result identifies a failure condition. This approach improves the scalability of monitoring applications; because the interactions with the controlled stations are reduced by a factor equal to number of objects aggregated by the result. The CHECK MIB aims to keep a high level of simplicity in the configuration of the checks as well as in the implementation of the module, while featuring, at the same time, capabilities which should fit for the most monitoring applications. 3.1. Related MIB Modules Existing MIBs define similar features to distribute monitoring operations to managed nodes; as outlined briefly in the following paragraphs. In general it can be stated that they focus on wider ranges of applications and offer richer capabilities than the CHECK MIB; but they don't achieve the same level of scalability, simplicity and efficiency. 3.1.1. Script MIB The Script MIB [RFC3165] allows a NMS to download arbitrary programs (scripts) to the managed node and read intermediate or final results from program execution. If supported by the Script MIB implementation, programs can access local managed objects of other MIB modules and perform even complex operations on them. Among these operations the checks described above are included. However, the Script MIB also creates a lot of overhead. It requires to code all comparisons into programs, to download them to the managed node and to control their execution. Changes in the check operations, for example, the modification of one of several thresholds requires to identify the corresponding line of the program, modify it, re-compile it (required in some cases), download the modified program to the managed node (required in some cases), stop the execution of the original program and start the modified one. Another matter of complexity is the implementation of the Script MIB. It is very powerful concerning the handling of programs, passing arguments to them, receiving intermediate results and controlling their execution. In addition, a runtime engine for the programs to be executed must be provided. This is achieved by a rather complex and costly implementation. The rich capabilities of the Script MIB imply several security Nunzi, Quittek, Brunner, Dietz [Page 4] Internet-Draft December 2003 issues. Since the programs to be executed can potentially execute arbitrary code, strict access control to the Script MIB is required. Summarizing the consideration of the Script MIB, it is more than powerful enough for increasing scalability of monitoring applications as described above. It offers a much richer and more general functionality. However, the prices for this is a costly implementation, rather complex handling of the MIB required by an NMS and a set of security issues to be considered. 3.1.2. Expression MIB The Expression MIB [RFC2982] allows to compute in the managed station simple expressions based on the values of the managed objects; the goal is to offer to the manager directly an elaboration of those values (for example the percentage line utilization per second elaborated with a mathematical expression from four objects of mib-2). Moreover the Expression MIB introduce two new features: the "wildcard" to include the computation of all instances of an object in a table within a single expression and the type of sampling to consider different samples of object value. The drawbacks of this flexibility are the complexity in defining the expressions (each value in the expression is treated as a variable and must be correctly defined in a table for variables) and the difficulty in implementing it (the manager must implement a parser for the expression, a checker for the consistency of the expression with variables); moreover the expression can be incorrectly defined and so the manager must check for errors before reading results, avoiding automated control; finally the wildcard creates a value for each instance of the object referred, without aggregating each partial result. Most of the monitoring operations performed by manager applications resolve to simple comparison between values and don't require the computational capabilities offered by the Expression MIB. However, those applications which need such capabilities can use the value objects of the Expression MIB as source for the comparison operations defined in the CHECK MIB. 3.1.3. Event MIB The Event MIB [RFC2981] allows an agent to monitor managed objects at a device and to report failures when certain conditions on their values are met. The manager can configure three types of condition to monitor the objects. If a condition is met, two different actions can be taken: either set a value of a object (to report failures to other MIBs) or send a notification. Each type of condition must be defined in a different table and is Nunzi, Quittek, Brunner, Dietz [Page 5] Internet-Draft December 2003 associated with a different notification. The Event MIB can control objects on the local managed station or on remote managed stations through the integration with the SNMPv3 Management Target and Notification MIBs [RFC2573]. The Event MIB contains also two features already defined in the Expression MIB: the wildcard to reference all the instances of an object and the different types of sampling of the object's value. There's a certain overlap in the definition of the monitor operations in the Event MIB (trough the "trigger" objects) and in the CHECK MIB. This overlap is needed to achieve the simplicity and scalability goals aimed by the CHECK MIB. The configuration of the triggers of the Event MIB is not simple due the need of accessing two different tables for each trigger; the implementation as well is complicated by the coexistence of three different types of triggers and the correspondent tables in the MIB tree. Scalability is not addressed, because each trigger monitors a managed object and cannot be aggregated with others. 4. Features The basic feature of the CHECK MIB is to perform a check procedure through a set of simple comparison operations between values of the monitored objects and control values. The manager station initially configures the check procedure on the device and later it polls a value representing the result of the check. Alternatively; the manager can configure the device to send a notification when the result identifies an error condition. In the CHECK MIB the comparison operation is called "rule". A rule defines a monitored object, a reference value and the relationship expected between the value of the monitored object and the reference value; a rule fails if the relationship is not respected. Rules are defined as entries in the checkRuleTable. A check is constituted by a set of rules and is defined in an object called "result". When a check defined in a result is performed; each rule included by that result is performed in sequence. At the end of the performance, the result object contains the result of the check; as explained afterwards. Results are defined as entries in the checkResultTable and the rules included by a result are referenced using the name of the result as first index in the checkRuleTable. Several results can be defined on a device, where each of them performs a different check. For example, one result can monitor general conditions of the device (like the internal temperature) and another one can monitor the operational status of a specific element (for example the link status of the interfaces installed). The Nunzi, Quittek, Brunner, Dietz [Page 6] Internet-Draft December 2003 figure below gives a snapshot of a general configuration and clarifies the aggregation of operations inducted by the CHECK MIB. rule1: obj1<30 --| rule2: obj2=2 |-- aggregated by --> result: checkGeneral rule3: obj9>=60 --| ruleA: obj1<30 --| . . . |-- aggregated by --> result: checkSpecific ruleZ: obj9>=60 --| When a check is performed and some rules included fail; then a "failure" object is created for each rule which failed; each failure object contains the OID of the monitored object defined in the rule; as depicted below: performance of checkGeneral --> rule1: failed? Yes --> failure: obj1 --> rule2: failed? Yes --> failure: obj2 --> rule3: failed? Yes --> failure: obj9 When the manager polling the result discovers a failure in the check, it can read the objects which didn't pass the last check. A rule defines also the integer value "severity" which measures the gravity of the rule for the result which includes it. If some rules fail, then the result is updated with the maximum of the severities of the failed rules. The purpose of the severity is to indicate the severity of the failures occurred in a check to the network manager. The scale of the severity is arbitrary chosen by the manager. Nevertheless this document implicitly uses for the examples a scale between 0 and 100, because it gives enough space to include enough levels of gravity of the checks of the managed stations. The CHECK MIB defines a notification object to report a failed check. The notification contains the severity of the result. The trigger of a notification is a threshold value for the severity of the result and thus a notification is sent only if the severity reaches or overcomes the threshold value. The management station can enable the threshold only for highly severe failures, so that a notification will not be sent for minor failures. It's worth to notice that even if the managed objects controlled in a check carry correlated information and all the rules in a result happen to fail for the same failure in the monitored device, only one notification will be sent (no "events storming" is triggered). A check can be performed automatically, that is on regular intervals, or manually, that is each time the severity of a result is retrieved by the manager. The CHECK MIB can be used to monitor all the object types defined in Nunzi, Quittek, Brunner, Dietz [Page 7] Internet-Draft December 2003 SMIv2 with the exception of the Opaque type. Integer values can be compared to control values (with relationships like <,<=,=,!=,>,>=). For counters it's possible to specify also a delta operation to monitor the increments at each check. IpAddress, OID, BITS and OCTET STRING values can be monitored only testing if they match the control value. The control value for all the object types is encoded into an OCTET STRING object, following the definitions given in the textual convention RuleValue. The objects to be monitored are identified by their OIDs. In the simple case a rule monitors a single instance object. Beside, it's possible to monitor with a single rule all the instances of a columnar object (that is an object defined inside a row of a table); in this case the OID of the columnar object itself must be indicated and the rule is applied to all the instances of the columnar object existing in the table. The instances are retrieved as the objects next in lexicographical order to the OID specified in the rule. A misconfigured OID (that is an OID which doesn't refer neither to an instance object nor a columnar object) may lead to retrieve wrong objects in the MIB tree and thus to compute wrong results in the performance of a check. Each result is identified by its name which is used as index in the checkResultTable. The name of the result should give a brief description of the purpose of the result to help readability of the table. Some recommendations are given in the definition of the CHECK MIB for the result's name; aiming at a common semantic between different management stations. Following these suggestions, an example for a result's name is "zeusInterfaces", which identifies a check configured by a management application called "zeus" to monitor the the interfaces of the device. A useful application of the CHECK MIB is the support for checks pre- configured in the device by the manufacturer. In this case the manager application might use the pre-configured checks, bypassing the configuration of all the rules. 5. Structure of the MIB Module This section presents the structure of the MIB module that is specified in Section 7. The module contains five groups of managed objects: - the capabilities group containing managed objects that indicate capabilities of the CHECK MIB implementation; - the control group containing managed objects that control the working status of the CHECK MIB; Nunzi, Quittek, Brunner, Dietz [Page 8] Internet-Draft December 2003 - the result group containing the checkResultTable that provides results of check operations; - the rule group containing the checkRuleTable that specifies check operations; - the failed checks group containing the checkFailureTable that indicated managed objects for which a check failed. Additionally, a notification is specified that can be used for notifying a NMS about failed checks. 5.1. checkCapabilities Information on middle-box capabilities is provided by the capabilities group of managed objects. The following objects are defined: o checkCapabMinCheckInterval This object indicates the minimum time between two performances of the same check that can be scheduled. o checkCapabMaxResults This object indicates the maximum number of entries in the checkResultTable. o checkCapabMaxRules This object indicates the maximum number of entries in the checkRuleTable. 5.2. checkControl The working status of the CHECK MIB can be controlled through two objects: o checkCtrlAdminStatus This object indicates the desiderated status of the CHECK MIB. o checkCtrlOperStatus This object indicates the actual status of the CHECK MIB. 5.3. checkResultTable This tables contains the results of the checks performed by the agent as well as some parameters to control how the checks are actually performed. The following objects are defined: o checkResultName This object indicates the name of the result. The name is used as index for the table and should give indicate the name of the Nunzi, Quittek, Brunner, Dietz [Page 9] Internet-Draft December 2003 manager configuring the check and a label identifying the check procedure. o checkResultSeverity This object indicates the result of the checks performed from the device. A value of 0 indicates that no failure have been detected while performing the check. A value greater than 0 indicates the maximum of the severities of the rules failed at the last performance. o checkResultSize This object indicates the number of failed rules at the last performance. o checkResultTime This object indicates the time of the last performance. o checkResultInterval If this object is set to 0, then the check is performed each time a manager retrieves the value of checkResultSeverity. A value greater than 0 specifies the interval between two checks automatically performed by the device. o checkResultSeverityThreshold This objects indicates if a notification should be sent if a check fails. A value of 0 means that no notification will be sent. A value different from 0 indicates that a notification should be sent if a check fails with severity greater or equal to that value. o checkResultRowStatus This objects permits the creation and deletion of rows. 5.4. checkRuleTable This table defines the comparison operations to be executed for the checks specified in the checkResultTable. The following objects are defined: o checkRuleName This object indicates the name of the rule and is used as index for the table coupled with the checkResultName of the check which includes the rule. o checkRuleOid This object indicates the OID of the object to be monitored. o checkRuleValue This object indicates the value the object must be compared to. Nunzi, Quittek, Brunner, Dietz [Page 10] Internet-Draft December 2003 o checkRuleOperation This object indicates the relationship expected between the value of the monitored object and checkRuleValue. o checkRuleSeverity This object indicates the severity for the rule defined by this entry. o checkRuleRowStatus This object permits the creation and deletion of rows. 5.5. checkFailureTable This table contains the failures registered while performing the checks. For each rule failed, an entry in this table. Each entry is indexed by the checkResultName and the checkRuleName of the rule failed and the checkFailureSeverity object. Two objects are defined in the table: o checkFailureSeverity This objects is indicates the severity with which the rule failed. o checkFailureOid This objects is indicates the OID of the object for which the rule failed. 5.6. checkNotifications The notification object checkResultFailed can be sent by the device when a check fails. The notification contains only the checkResultSeverity object. 6. MIB Usage This section explains how to configure check procedures and to implement monitor application with the CHECK MIB. When defining a new check, the manager should follow these steps: 1. Create a new row in checkResultTable through the object checkResultRowStatus, using the name of the check as index. 2. Set the values of checkResultSeverityThreshold and checkResultInterval. 3. Create a new row in checkRuleTable through the object checkRuleRowStatus giving the name of check and the name of the rule as indexes. 4. Configure the operation defined in the rule and its severity. 5. Activate the row of the rule by writing to checkRuleRowStatus. 6. Repeat step 3-5 for each rule to be included in the check. Nunzi, Quittek, Brunner, Dietz [Page 11] Internet-Draft December 2003 7. Activate the row of the result by writing to checkResultRowStatus. A change in the RowStatus of a result is propagated also to the RowStatus of all the rules included by that result. As consequences, deleting a row in the checkResultTable causes the deletion of all rows in the checkRuleTable and checkFailureTable with the same checkResultName (they are respectively the rules and the failures included by the check being deleted) and activating a results causes the activation of all the rules included. The values of the objects with read-create permissions can be modified only when the row they belong to is put in the status notInService. If the device is put under maintenance (for example monitored objects are being reset); it's possible to disable temporally the performance of the checks, changing the value of the checkCtrlAdminStatus object. 6.1. Usage Example This section presents an example that explains how a manager can use the CHECK MIB defined in this memo. The purpose of this example is to explain the steps that can be performed by a network management station (NMS) to configure check procedures and to retrieve their results. When monitoring the correct behavior of the interfaces installed on a device; the main task is to make sure that all the interfaces installed have their operational status as UP; besides, the number of corrupted packets can be a first indicator of some malfunctions in the device. Instead of polling continuously the managed objects from the router, the NMS can configure the CHECK MIB to follow these rules: 1. Control all the instances of ifOperStatus: if one interface is down, sends a notification. 2. Control all the instances of ifInError and ifOutError: if too corrupted packets traverse an interface, then raise the severity of the check result. For example 30 corrupted packets every 10 seconds should be marked as severity 40; 50 corrupted packets every 10 seconds as severity 70. If the check is configured to be performed every 10 seconds, then a new row in the checkResultTable must be created with the following set commands: checkResultRowStatus."mgrInterfaces" = create-and-wait(5) checkResultInterval."mgrInterfaces" = 10000 checkResultSeverityThreshold."mgrInterfaces" = 100 Then the rules must be defined for that check. For example the rule Nunzi, Quittek, Brunner, Dietz [Page 12] Internet-Draft December 2003 for the ifOperStatus is configured with the following set commands: checkRuleRowStatus."mgrInterfaces"."status" = create-and-wait(5) checkRuleOid."mgrInterfaces"."status" = ifOperStatus checkRuleSeverity."mgrInterfaces"."status" = 100 checkRuleValue."mgrInterfaces"."status" = 1 checkRuleOperation."mgrInterfaces"."status" = less(3) checkRuleRowStatus."mgrInterfaces"."status" = active(1) Commands for the ifInErrors and ifOutErrors are similar. As the last step, the check must be activated with the following command: checkResultRowStatus."mgrInterfaces" = active(1) The checkResultTable will look like: ----------------------------------------------------- |Name |Severity|Time|Interval|SeverityThreshold| ----------------------------------------------------- |mgr_router| 100|0:00| 1000| 100| ----------------------------------------------------- The checkRuleTable will look like: --------------------------------------------------- |Name | Oid|Value|Operation|Severity| --------------------------------------------------- |status |ifOperStatus| 1| less| 100| |inErrors30 |ifInErrors | 30| delta| 40| |outErrors30|ifOutErrors | 30| delta| 40| |inErrors50 |ifInErrors | 50| delta| 70| |outErrors50|ifOutErrors | 50| delta| 70| --------------------------------------------------- At this point if an interface switches its operational status to DOWN, only one notification will be sent containing the severity 100. On the other hand, if the NMS reports bad performance of end-services in the network (for example high level of packet-loss), than it can poll the severity of the result: a value of 40 or 70 might indicate the right cause of the bad performance reported. 7. Definitions CHECK-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Unsigned32, TimeTicks, zeroDotZero Nunzi, Quittek, Brunner, Dietz [Page 13] Internet-Draft December 2003 FROM SNMPv2-SMI -- RFC2578 StorageType, RowStatus, TimeInterval, TimeStamp, TEXTUAL-CONVENTION FROM SNMPv2-TC -- RFC2579 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC2580 SnmpAdminString FROM SNMP-FRAMEWORK-MIB; -- RFC3411 checkMIB MODULE-IDENTITY LAST-UPDATED "200312191313Z" -- December 19, 2003 ORGANIZATION "IETF Distributed Management man Working Group" CONTACT-INFO "Editor: Giorgio Nunzi NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69221 Heidelberg Germany Tel: +49 6221 90511-39 Email: nunzi@netlab.nec.de" DESCRIPTION "This MIB module defines a set of objects that allow to define a health check procedure on a managed node. The health check procedure is performed through a sequence of simple comparison operations on some managed objects against a control value. The result of the health check is accumulated into a single managed object that can be read by a manager to discover the status of the whole set of managed objects instead of retrieving all the single values controlled during the health check procedure. The main purpose of the CHECK-MIB is increasing scalability of network management applications by moving check operations from the management station to managed nodes. There are five groups of managed objects defined by this MIB module: - objects describing capabilities of the CHECK-MIB implementation; - objects controlling the operational status of the health check procedure; - objects defining the checks in the checkResultTable; - objects defining the operations for each of Nunzi, Quittek, Brunner, Dietz [Page 14] Internet-Draft December 2003 the configured checks in the checkRuleTable; - objects providing information about failed checks." REVISION "200312191313Z" -- December 19, 2003 DESCRIPTION "Initial version" ::= { mib-2 7777 } -- 7777 to be assigned by IANA. RuleValue ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x" STATUS current DESCRIPTION "The control value compared with the value of a monitored object. This value encodes all the object types defined by the SMIv2, except the Opaque, with the following rules: - INTEGER, Integer32, Unsigned32, TimeTicks, Counter32, Gauge32: the integer value is encoded with 4 octets in network-byte order; - Counter64: the integer value is encoded with 8 octets in network-byte order; - IpAddress: the address value is encoded with a 4 in network-byte order; - OBJECT IDENTIFIER: each sub-identifier is encoded with 4 octets in network-order and the whole OID is encoded as a sequence of sub-identifiers starting from the top-level; - BITS: all the named bits in the bitstring, commencing with the first bit and proceeding to the last bit, are placed in bits 8 (high order bit) to 1 (low order bit) of the first octet, followed by bits 8 to 1 of each subsequent octet in turn, followed by as many bits as are needed of the final subsequent octet, commencing with bit 8. Remaining bits, if any, of the final octet are set to zero on generation and ignored while performing a check; - OCTET STRING: the string is encoded as it is." SYNTAX OCTET STRING SeverityConfigured ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The severity value measures the gravity of a failure of a rule or a result. A low value indicates a minor failure, while a high value indicates a sever failure. The scale of the severity is arbitrary chosen by the manager application. This textual convention represents the value of a severity which is configured by the manager." SYNTAX Unsigned32 (0..4294967293) Nunzi, Quittek, Brunner, Dietz [Page 15] Internet-Draft December 2003 SeverityReturned ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The severity value measures the gravity of a failure of a rule or a result. A low value indicates a minor failure, while a high value indicates a sever failure. The scale of the severity is arbitrary chosen by the manager application. This textual convention represents the value of a severity which is set by the device after the performance of a rule. If the rule has been correctly performed, the value is equal to the severity configured for the rule. If the rule has not been performed because the monitored object couldn't be accessed, then this values is set to 4294967295. If the rule has not been performed due to a lack of resources, then this value is set to 4294967294." SYNTAX Unsigned32 -- -- main components of this MIB module -- checkObjects OBJECT IDENTIFIER ::= { checkMIB 1 } checkNotifications OBJECT IDENTIFIER ::= { checkMIB 2 } checkConformance OBJECT IDENTIFIER ::= { checkMIB 3 } -- -- Capabilities group -- -- The capabilities group contains a set of managed -- objects describing the capabilities of the CHECK-MIB -- implementation. -- checkCapabilities OBJECT IDENTIFIER ::= { checkObjects 1 } checkCapabMinCheckInterval OBJECT-TYPE SYNTAX TimeTicks UNITS "centi-seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum interval that can be scheduled between two performances of the same check defined in the checkResultTable using the object checkResultInterval. This value is the minimum value allowed for the object checkResultInterval of the checkResultTable." ::= { checkCapabilities 1 } Nunzi, Quittek, Brunner, Dietz [Page 16] Internet-Draft December 2003 checkCapabMaxResults OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of entries supported in the checkResultTable. A value of 0 indicates that there is no fixed limitation. Creating a new row in the checkResultTable with the object checkResultRowStatus after the maximum number of entries supported, leads to a resourceUnavailable error." ::= { checkCapabilities 2 } checkCapabMaxRules OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of entries supported in the checkRuleTable. A value of 0 indicates that there is no fixed limitation. Creating a new row in the checkRuleTable with the object checkRuleRowStatus after the maximum number of entries supported, leads to a resourceUnavailable error." ::= { checkCapabilities 3 } -- -- Control group -- -- The control group contains managed objects controlling -- the operational status of the check MIB implementation. -- checkControl OBJECT IDENTIFIER ::= { checkObjects 2 } checkCtrlAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- performing checks silent(2), -- no notifications sent down(3) -- all checks disabled } MAX-ACCESS read-write STATUS current DESCRIPTION "The desidered state of the checking engine of the Check MIB implementation. Setting this object to up(1) Nunzi, Quittek, Brunner, Dietz [Page 17] Internet-Draft December 2003 indicates a request for performing all checks as defined in the checkResultTable and the checkRuleTable performed. Setting this object to silent(2) indicates that all the checks defined in checkResultTable must be performed, but no notification must be sent by the Check MIB implementation. Setting this object to down(3) indicates a request for performing o more tests. When retrieved, the object returns the last value written to it, except after system boot when it returns the value up(1)." DEFVAL { up } ::= { checkControl 1 } checkCtrlOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- performing checks silent(2), -- no notifications sent down(3), -- all checks disabled flushing(4) -- finishing checks already started } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of the Check MIB implementation. The up(1) state indicates that all checks defined in the checkResultTable and the checkRuleTable are performed. The silent(2) state indicates that all checks are performed as defined in the checkResultTable and the checkRuleTable, but no notification is sent by the Check MIB implementation. The down(3) state indicates that no check is performed. The flushing(4) state indicates that the checkCtrlAdminStatus has been set to down(3) and the managed node is completing the performance of checks that were scheduled before checkCtrlAdminStatus was set to down(3). If the value of checkCtrlAdminStatus does not change again before these checks are completed, then the value of checkCtrlOperStatus will change to down(3) after the checks are completed. After a system re-initialization, the Check MIB implementation starts up with this object set to up(1)." ::= { checkControl 2 } -- -- Result group -- -- The Result group contains the objects to define the checks -- performed on the managed node. The checks are organized -- in the checkResultTable. Nunzi, Quittek, Brunner, Dietz [Page 18] Internet-Draft December 2003 -- checkResultTable OBJECT-TYPE SYNTAX SEQUENCE OF CheckResultEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the definitions of the checks to be performed by the Check MIB implementation. Each row defines one check and contains the parameters controlling the performance of the check as well as the result of the check. The operations performed by each check are defined as rules in the checkRuleTable." ::= { checkObjects 3 } checkResultEntry OBJECT-TYPE SYNTAX CheckResultEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry defining a check. Each entry is indexed by the string checkResultName, which represents the name of the check. An entry can be created with the object checkResultRowStatus only with the createAndWait operation. A check is never performed if its entry is in the notInService status. Objects in an entry marked as read-create can be modified only when the entry is in notInService status." INDEX { checkResultName } ::= { checkResultTable 1 } CheckResultEntry ::= SEQUENCE { checkResultName SnmpAdminString, checkResultSeverity SeverityReturned, checkResultSize Unsigned32, checkResultTime TimeStamp, checkResultInterval TimeInterval, checkResultSeverityThreshold SeverityConfigured, checkResultStorageType StorageType, checkResultRowStatus RowStatus } checkResultName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION Nunzi, Quittek, Brunner, Dietz [Page 19] Internet-Draft December 2003 "A name describing the check. Since the name serves as table index, it must be unique for each row in the table. The name of a check is chosen arbitrary by the manager creating the row in the checkResultTable, but some suggestions are given to offer a common semantic among different managers. The name should give a brief description of the check defined in the row. In particular it is recommended that the name indicates: - the name of the manager who defined the row. - a label describing the check." ::= { checkResultEntry 1 } checkResultSeverity OBJECT-TYPE SYNTAX SeverityReturned MAX-ACCESS read-only STATUS current DESCRIPTION "Each time the check defined by this entry (and the corresponding entries of the checkRuleTable) is performed, this object is set to to the maximum value of all checkRuleSeverity objects in corresponding entries of the checkRuleTable for which the check failed. If the check passes for all corresponding rules, then the value of object checkResultSeverity is 0. If the object checkResultInterval contains the value 0, then the check is performed when the value of checkResultSeverity is retrieved by a manager. If the object checkResultInterval contains a value greater than 0, then the check is performed automatically by the managed node and a read access by a manager just returns the value computed at the last scheduled check. Each time object checkResultSeverity is set, the value of object checkResultTime in the corresponding entry is set to the current time, and the value of object checkResultSize is set to the number of corresponding entries in the checkRuleTable for which the check failed. If no check has been performed so far, then the value of this object is 0." ::= { checkResultEntry 2 } checkResultSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION Nunzi, Quittek, Brunner, Dietz [Page 20] Internet-Draft December 2003 "The number of rules defined in corresponding entries of the checkFailureTable for which the check failed when it was performed last. If no check has been performed so far, then the value of this object is 0." ::= { checkResultEntry 3 } checkResultTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "A timestamp indicating the time when the last performance of the check defined in this row was completed. If no check has been performed so far, then the value of this object is 0. Note that 0 is a valid timestamp." ::= { checkResultEntry 4 } checkResultInterval OBJECT-TYPE SYNTAX TimeInterval UNITS "centi-seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The interval between two performances of the check defined in this row. When this object is set to a value greater than 0, then the check is performed regularly with the number of centi-seconds indicated by this object between two performances. When this object is successfully set to a value greater than 0, then the check is not performed immediately. The first check is performed after the number of centi-seconds specified by the new value of the object. If a performance is scheduled to start before the previous one has been completed, then the previous check will be completed and the scheduled check will be skipped. If the number of this object is 0, then the check is performed only on request when the value of the object checkResultSeverity is retrieved by a manager. A set operation on this object may lead to an inconsistentValue error in two cases: - if the vale passed is greater than 0 but less than the value of checkCapabMinCheckInterval; - if the value passed is greater than 0 and the Nunzi, Quittek, Brunner, Dietz [Page 21] Internet-Draft December 2003 check defined in this row includes rules with delta operations." DEFVAL { 0 } ::= { checkResultEntry 5 } checkResultSeverityThreshold OBJECT-TYPE SYNTAX SeverityConfigured MAX-ACCESS read-only STATUS current DESCRIPTION "This object serves for sending notifications in case of failures occurred in the check defined in this row. If the value of this object is set to 0, then no notification is sent to the manager even if some rule defined for the check fails. Otherwise, if the performance of a check leads to a value of the object checkResultSeverity that is equal to or greater than the value of the object checkResultSeverityThreshold, then a notification is sent. The notification is an instance of checkResultFailed." DEFVAL { 0 } ::= { checkResultEntry 6 } checkResultStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object indicates the storage type of this entry in the checkResultTable and of all corresponding entries in the checkRuleTable. The value of this object indicates whether the entries are stored in volatile memory and lost upon reboot or if they are backed up by non-volatile or permanent storage. If checkResultStorageType has the value permanent(4), then all objects whose MAX-ACCESS value is read-write can be modified, but the row cannot be deleted. All the objects in corresponding entries of the checkRuleTable whose MAX-ACCESS is read-create are instead read-only with the exception of the checkRuleRowStatus. Attempts to set this object to permanent(4) will always fail with an inconsistentValue error." DEFVAL { volatile } ::= { checkResultEntry 7 } checkResultRowStatus OBJECT-TYPE Nunzi, Quittek, Brunner, Dietz [Page 22] Internet-Draft December 2003 SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows to create and delete rows in the table. The value createAndGo(4) is not allowed and an wrongValue error is returned when attempting to set it. Objects of the same row can be modified only when checkResultRowStatus has the notInService(2) value and set operations on objects of a row in active(1) status result to inconsistentValue. A change of the value of the checkResultRowStatus object is propagated to the checkRuleRowStatus of all the related entries in the checkRuleTable (those indexed by the same checkResultName); if the change of the value of a checkRuleRowStatus object results in an inconsistentValue error, then this error is returned to the manager while setting the value of this checkResultRowStatus. An attempt to set the value of this object to active(1), causes the following actions: - all the related entries in the checkRuleTable become active; if an attempt to activate an entry results in an inconsistentValue error, then this error is returned to the manager and further action is taken; - all the objects of this row become read-only, with the exception of checkResultRowStatus; - if the value of checkResultInterval is greater than 0, then the timer to schedule the performances of the check starts immediately, but the first check will be performed only but after the time specified by checkResultInterval; for rules defining delta operations the values of managed objects to be checked are read immediately, so that delta operations can be computed at the first scheduled check. - if the value of checkResultInterval is equal to 0, then retrieving the value of checkResultSeverity forces the performance of the check. When a row is put in the notInService status, then the following actions are taken: - all the objects of the row marked as read-create can be modified; - all the related entries in the checkRuleTable become notInService; - all scheduled future checks are canceled. - retrieving the value of checkResultSeverity returns always the value computed at the last check. When a row is deleted, then if an alarm was configured, it is removed, and all the related entries in checkRuleTable Nunzi, Quittek, Brunner, Dietz [Page 23] Internet-Draft December 2003 are deleted (eventually freeing the resources allocated for delta operations defined by those rules). Creating a new row when the table reached the maximum number of entries defined in checkCapabMaxResults results in a resourceUnavailable error." ::= { checkResultEntry 8 } -- -- Check Rule group -- -- The Rule group contains the objects to define the operations -- performed for each check. The operations are organized -- in the checkRuleTable. -- checkRuleTable OBJECT-TYPE SYNTAX SEQUENCE OF CheckRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the definitions of the operations performed for checks defined in the checkResultTable. Each row defines an operation on the value of a managed object. The operation consists in a comparison of the value of the managed object with a control value specified in checkRuleValue. The relationship expected between the two values is indicated by checkRuleOperation. It is possible to reference in a single rule either a single instances object or all the instance of a columnar object of a table. For each operation, a severity is set which indicates the gravity of the failure of the comparison operation. The storage type of entries in this table is determined by the value of object checkResultStorageType in the corresponding entry of the checkResultTable." ::= { checkObjects 4 } checkRuleEntry OBJECT-TYPE SYNTAX CheckRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry defining a rule for a check defined in the checkResultTable. Each entry is indexed by: 1. the checkResultName of the check which includes the operation defined by the entry; 2. the string checkRuleName, which represents the Nunzi, Quittek, Brunner, Dietz [Page 24] Internet-Draft December 2003 name of the operation. An entry can be created with the object checkResultRowStatus only with the createAndWait operation. A rule is never considered in the performance of the check defined in the related checkResultEntry, if its entry is in the notInService status. Objects in an entry can be modified only when the entry is in notInService status." INDEX { checkResultName, checkRuleName } ::= { checkRuleTable 1 } CheckRuleEntry ::= SEQUENCE { checkRuleName SnmpAdminString, checkRuleOid OBJECT IDENTIFIER, checkRuleValue RuleValue, checkRuleOperation INTEGER, checkRuleSeverity SeverityConfigured, checkRuleRowStatus RowStatus } checkRuleName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A name describing the rule. Since the name serves as table index coupled with the value of checkResultName, it must be unique per each row in the table inside the scope of checkResultName. The name of a rule is chosen by the manager creating the row, but some suggestions are given to offer a common semantic between different managers. The name should give a brief description of the rule defined in the row. In particular it is recommended that the name indicates the name of the managed object controlled by the rule." ::= { checkRuleEntry 2 } checkRuleOid OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OID indicating the managed object to be checked. The OID must be: - the OID of an instance object: in this case the rule is applied to that object; - the OID of a columnar object (missing of the instance sub-identifier): in this case the rule is applied to all Nunzi, Quittek, Brunner, Dietz [Page 25] Internet-Draft December 2003 the instances of the columnar object. The validity of the OID is verified when the manager tries to activate the row, following these actions: - the agent should try to read the value of the object referenced by the OID (like a snmp get operation); if the value is read, the OID refers to a valid instance object and the type of the object should be registered inside the agent; - if the object is not available, then the agent should try to read the next object in the lexicographical order (like a snmp get next operation); if the OID returned is a child node of the checkRuleOid, then the latter is assumed to be a columnar object and the type of the object read is stored inside the agent; - if no object could be found or the OID returned is not a leaf of checkRuleOid, then an inconsistentValue error is return to the attempt of activating the row. When setting the OID of a columnar object, at least one instance object must exist at the moment of the activation of the row, so that the validity test of OID passes and the row is activated. If the OID references an instance object that is removed or become inaccessible after the row has been activated, then rule automatically fails with a severity equal to 4294967295. If the OID value references a columnar object and no instance exists after the first performance, then the rule doesn't fail." DEFVAL { zeroDotZero } ::= { checkRuleEntry 3 } checkRuleValue OBJECT-TYPE SYNTAX RuleValue MAX-ACCESS read-create STATUS current DESCRIPTION "The control value compared to the value of the managed object indicated by checkRuleOid. The control value encoded in this object must be consistent with the type of the object referenced by the checkRuleOid. The control value is considered inconsistent if: - the object type is INTEGER, Unsigned32, TimeTicks, Gauge32, Counter32, IpAddress and the size of the checkRuleValue is different from 4; - the object type is Counter64 and the size of the checkRuleValue is different from 8; - the object type is OBJECT IDENTIFIER and the size of the checkRuleValue is not a multiple of 4. Nunzi, Quittek, Brunner, Dietz [Page 26] Internet-Draft December 2003 The consistency between the control value and the object type is verified when the rule is activated; if the consistency test fails, the attempt to active the row results in an inconsistentValue error." DEFVAL { "" } ::= { checkRuleEntry 4 } checkRuleOperation OBJECT-TYPE SYNTAX INTEGER { noOperation(0), unequal(1), equal(2), less(3), lessOrEqual(4), greater(5), greaterOrEqual(6), delta(7) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object specifies the comparison operation to be performed between the value of the managed object indicated by checkRuleOid and the value indicated by checkRuleValue. Some operations cannot be applied to all the types of object. If the value of the checkRuleOperation is inconsistent with the type of the object indicated by checkRuleOid, then an attempt to activate the row results in an inconsistentValue error. The value 0 can be configured for all the object types and means that no operation is performed and the rule never fails. When the type of the object indicated by checkRuleOid is IpAddress, BITS, OBJECT IDENTIFIER then only the value equal(2) can be configured. For the IpAddress, the value of the object indicated by checkRuleOid is compared byte by byte with the value of checkRuleValue and the rule doesn't fail if all the bytes are matched. For the OBJECT IDENTIFIER, the rule doesn't fail if checkRuleValue encodes an OID of the same dimension of the value of the object indicated by checkRuleOid and the two OIDs are equal. For the BITS, the rule doesn't fail if the checkRuleValue encodes a bitstring long at least as the number of the named bits and all the named bits are matched with that bitstring. When the type of the object indicated by checkRuleOid is INTEGER, Integer32, Unsigned32, Counter32, Counter64, TimeTicks, Gauge32, all the values from 1 to 6 can be configured. These values define simple mathematical Nunzi, Quittek, Brunner, Dietz [Page 27] Internet-Draft December 2003 operations: the rule doesn't fail if the the value of the object indicated by checkRuleOid is, respectively, !=, =, <, <=, >, >= than the value of checkRuleValue. A value of of delta(7) can be configured only for Counter32, Counter64, Gauge32; moreover it is permitted only if the check including the rule is performed automatically and thus its value of checkResultInterval greater than 0, otherwise an inconsistentValue error is returned. For a delta operation, each time the rule is performed, the difference between the actual value of the managed object and its value at the last performance is considered and the rule doesn't fail if the difference is <= than the value of the checkRuleValue. If the actual value is less than the previous one, then the difference is augmented with the value 4294967295, like as the managed object reached its maximum value and it has been resetted. Each time the new value of the managed object must be stored by the device in an internal buffer. The buffer must be handled so that when a new managed object is controlled, a new entry is allocated for it. If no more entries are available, then the rule fails with severity 4294967294. If a managed object for which an entry was previously allocated, doesn't exist when a new execution of the delta operation is performed, its entry should be removed. When a new entry is allocated for a new managed object, its value is stored in the entry, but the operation is not computed and the rule doesn't fail; the delta operation is normally computed only from the second time." DEFVAL { noOperation } ::= { checkRuleEntry 5 } checkRuleSeverity OBJECT-TYPE SYNTAX SeverityConfigured MAX-ACCESS read-create STATUS current DESCRIPTION "The severity of a failure of the operation specified by the row for the whole check. A severity of 0 indicates that a failure of the operation is irrelevant." DEFVAL { 1 } ::= { checkRuleEntry 6 } checkRuleRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Nunzi, Quittek, Brunner, Dietz [Page 28] Internet-Draft December 2003 STATUS current DESCRIPTION "The control to create and delete rows. It is possible to create new rules only for a check which is already defined in the CHECK-MIB. Creating a new row indexed by a value of checkResultName which doesn't exist already in any row of the checkResultTable results in a inconsistentName error. The value createAndGo(4) is not allowed and an wrongValue error is returned when attempting to set it. Objects of the same row can be modified only when checkRuleRowStatus has the notInService(2) value and set operations on objects of a row in active(1) status result to inconsistentValue. A row in the notInService status is not considered in the performance of the check defined by the related entry in the checkResultTable (the one indexed by the same checkResultName). An attempt to set the value of this object to active(1), causes the following actions: - the validity of the value of checkRuleOid is verified; if it fails, then an inconsistentValue error is returned; - the consistency between the type of the object referenced by checkRuleOid and the value of checkRuleOperation is verified; if it fails, then an inconsistentValue error is returned; - the consistency between the type of the object referenced by checkRuleOid and the value of checkRuleValue is verified; if it fails, then an inconsistentValue error is returned; - if all the tests pass, the row is activated. An attempt to create a new row when the table has reached the maximum number of entries defined in checkCapabMaxRules results in a resourceUnavailable error. An attempt to create a new row in the table with the corresponding entry in the checkResultTable having the storage type permanent(4) results in an inconsistentValue error." ::= { checkRuleEntry 7 } -- -- Failure group -- -- The Failure group contains the object describing the failures -- of a check. The failures are organized in the checkFailureTable. -- Nunzi, Quittek, Brunner, Dietz [Page 29] Internet-Draft December 2003 checkFailureTable OBJECT-TYPE SYNTAX SEQUENCE OF CheckFailureEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists all the rules defined in the checkRuleTable, which failed at the last time the check including them has been performed. Entries only describe objects for which the last check failed. Failures in checks before the last one are not indicated." ::= { checkObjects 5 } checkFailureEntry OBJECT-TYPE SYNTAX CheckFailureEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry referencing a failed rule. Each entry is indexed by: 1. the checkResultName of the check including the rule failed; 2. the severity of the rule failed; 3. The checkRuleName of the rule failed. The manager, after having read a value of checkResultSeverity of a check different from 0, can directly read the rule failed with the maximum severity by retrieving the checkFailureOid with a get_next command without specifying the checkRuleName." INDEX { checkResultName, checkFailureSeverity, checkRuleName } ::= { checkFailureTable 1 } CheckFailureEntry ::= SEQUENCE { checkFailureSeverity SeverityReturned, checkFailureOid OBJECT IDENTIFIER } checkFailureSeverity OBJECT-TYPE SYNTAX SeverityReturned MAX-ACCESS not-accessible STATUS current DESCRIPTION "The severity with which the rule failed." ::= { checkFailureEntry 1} checkFailureOid OBJECT-TYPE SYNTAX OBJECT IDENTIFIER Nunzi, Quittek, Brunner, Dietz [Page 30] Internet-Draft December 2003 MAX-ACCESS read-only STATUS current DESCRIPTION "The OID of the managed object for which a rule failed. This value contains the value of checkRuleOid of the rule failed." ::= { checkFailureEntry 2 } -- -- Notifications. The definition of checkEvent makes notification -- registrations reversible (see STD 58, RFC 2578, Section 8.5). -- checkEvent OBJECT IDENTIFIER ::= { checkNotifications 0 } checkFailed NOTIFICATION-TYPE OBJECTS { checkResultSeverity } STATUS current DESCRIPTION "This notification can be generated to report that a check failed. The notification is generated each time, the value of checkSeverityThreshold is greater than 0 and the performance of a check results in a value of checkResultSeverity that is greater than or equal to the value of checkSeverityThreshold. The notification contains the checkResultSeverity of the check failed." ::= { checkEvent 1 } -- -- Conformance information -- checkCompliances OBJECT IDENTIFIER ::= { checkConformance 1 } checkGroups OBJECT IDENTIFIER ::= { checkConformance 2 } -- -- Compliance statements -- -- This is the CHECK-MIB compliance definition. -- checkCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the CHECK-MIB." Nunzi, Quittek, Brunner, Dietz [Page 31] Internet-Draft December 2003 MODULE -- this module MANDATORY-GROUPS { checkCapabilitiesGroup, checkControlGroup, checkResultGroup, checkRuleGroup, checkFailureGroup, checkNotificationsGroup } ::= { checkCompliances 1 } -- -- Groups statements -- -- This is the definition of the objects group of the CHECK-MIB. -- checkCapabilitiesGroup OBJECT-GROUP OBJECTS { checkCapabMinCheckInterval, checkCapabMaxResults, checkCapabMaxRules } STATUS current DESCRIPTION "A collection of objects providing information about the capabilities of the CHECK-MIB implementation." ::= { checkGroups 1 } checkControlGroup OBJECT-GROUP OBJECTS { checkCtrlAdminStatus, checkCtrlOperStatus } STATUS current DESCRIPTION "A collection of objects controlling the state of the CHECK-MIB." ::= { checkGroups 2 } checkResultGroup OBJECT-GROUP OBJECTS { checkResultSeverity, checkResultSize, checkResultTime, checkResultInterval, checkResultSeverityThreshold, checkResultStorageType, checkResultRowStatus } Nunzi, Quittek, Brunner, Dietz [Page 32] Internet-Draft December 2003 STATUS current DESCRIPTION "A collection of objects defining a check." ::= { checkGroups 3 } checkRuleGroup OBJECT-GROUP OBJECTS { checkRuleOid, checkRuleValue, checkRuleOperation, checkRuleSeverity, checkRuleRowStatus } STATUS current DESCRIPTION "A collection of objects defining the operations computed for each check." ::= { checkGroups 4 } checkFailureGroup OBJECT-GROUP OBJECTS { checkFailureOid } STATUS current DESCRIPTION "A collection of objects indicating managed objects for which a check operation failed." ::= { checkGroups 5 } checkNotificationsGroup OBJECT-GROUP OBJECTS { checkFailed } STATUS current DESCRIPTION "The notifications emitted by the CHECK-MIB." ::= { checkGroups 6 } END 8. Security Considerations This MIB allow the execution of check procedures on the devices. An improper manipulation of its objects can lead on one side to waste of device's resources or to spoofing of managed object otherwise not accessible and on the other hand to alter the normal monitor process of managers. There are a number of management objects defined in this MIB module Nunzi, Quittek, Brunner, Dietz [Page 33] Internet-Draft December 2003 with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: - The use of checkCtrlAdminStatus can turn off the check procedures configured on the device; thus disabling the whole monitor application using them; - The use of checkResultTable can alter or remove the configured checks; moreover it can allow the creation of new checks wasting resources on the controlled device; - The use of the checkRuleTable can alter or remove the configured rules; in particular it can be possible to set the OID of managed objects to spy their values through the check procedure; moreover the improper addition of new rules can result in waste of resources on the controlled device. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is REQUIRED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). For implementations of the CHECK MIB it is REQUIRED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. Normative References [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. Nunzi, Quittek, Brunner, Dietz [Page 34] Internet-Draft December 2003 [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. [RFC3413] Levi, D., Meyer, P. and B. Stewart "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002 10. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3165] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts", RFC 3165, August 2001. [RFC2982] Stewart, B., "Distributed Management Expression MIB", RFC 2982, October 2000. [RFC2981] Stewart, B., "Event MIB", RFC 2981, October 2000. 11. Authors' Addresses Giorgio Nunzi NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-39 Email: nunzi@netlab.nec.de Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@netlab.nec.de Nunzi, Quittek, Brunner, Dietz [Page 35] Internet-Draft December 2003 Marcus Brunner NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-29 Email: brunner@netlab.nec.de Thomas Dietz NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-28 Email: dietz@netlab.nec.de 12. IPR Notices 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. 13. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to Nunzi, Quittek, Brunner, Dietz [Page 36] Internet-Draft December 2003 others, and derivative works that comment on or otherwise explain it or assist in its implmentation 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. Nunzi, Quittek, Brunner, Dietz [Page 37]