|_____________________________________________|
__________________________________________________
| alarmClearTable |
|--------------------------------------------------|
| alarmClear Index | alarm |
|--------------------------------------------------|
| | |
|__________________________________________________|
3. Some time later, the link goes back up. A linkUp Notification
is sent out and logged. As this Notification models
the clear alarm for this alarm, the alarm entry is remove
from the active alarm table. An entry is added to the
clear alarm table.
__________________________________________________
| alarmActiveTable |
|--------------------------------------------------|
| alarmActiveIndex | alarm |
|--------------------------------------------------|
|__________________________________________________|
_____________________________________________
| nlmLogTable |
|---------------------------------------------|
| nlmLogPointer | Notification |
|---------------------------------------------|
| 1 | linkDown |
| 2 | dsx3LineStatusChange |
| 3 | linkUp |
|_____________________________________________|
__________________________________________________
| alarmClearTable |
|--------------------------------------------------|
| alarmClear Index | alarm |
|--------------------------------------------------|
| 1 | linkDown - confirmed problem |
|__________________________________________________|
7. Security Considerations
There are a number of management objects defined in this MIB module
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.
The following objects are defined with a MAX-ACCESS clause of read-
write or read-create: alarmModelNotificationId,
alarmModelVarbindIndex, alarmModelVarbindValue,
alarmModelDescription, alarmModelSpecificPointer,
alarmModelVarbindSubtree, alarmModelResourcePrefix,
alarmModelRowStatus, alarmClearMaximum, ituAlarmEventType,
ituAlarmProbableCause, ituAlarmAdditionalText, and
ituAlarmGenericModel.
Note that setting the value of alarmClearMaximum too low may result
in security related alarms history being prematurely lost.
Changing values of alarmModelRowStatus as part of creating and
deleting rows in the alarmModelTable result in adding new alarm
models to the system or taking them out respectively. These
operations need to be carefully planned. Adding a new model should
be made in a consistent manner to avoid the system overflow with
alarms. Taking out a model should result in the deletion of all this
model’s related alarms in the system.
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 RECOMMENDED 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).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED 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.
Note that the alarm throttling mechanism associated with the
alarmActiveState and alarmActiveClear notifications only applies to a
given alarm. Defining multiple alarms from the same internal
stimulus may then still result in a flood of alarms into the network.
Although the use of community strings in SNMPv1 is not considered an
effective means of providing security, security administrators SHOULD
consider whether the fact that alarmActiveContextName can reveal
community string values would make this object sensitive in their
environment.
This MIB module can provide access to information that may also be
accessed through manipulation of the SNMP-NOTIFICATION-MIB and the
NOTIFICATION-LOG-MIB. This is expressed in part through the common
indexing structure of nlmLogName [RFC3014],
snmpNotifyFilterProfileName [RFC3413], and alarmListName.
Consequently, it is RECOMMENDED that security administrators take
care to configure a coherent VACM security policy. The objects
alarmActiveLogPointer, alarmActiveModelPointer,
alarmActiveSpecificPointer, and alarmClearModelPointer are object
identifiers that reference information to which a particular user
might not be given direct access. The structure of these object
identifiers does not permit the extraction of any sensitive
information. Two other objects, alarmClearResourceId, and
alarmActiveResourceId, are also syntactically object identifiers, but
their structure could provide a user with potentially useful
information to which he or she might not otherwise be granted access,
such as the existence of a particular resource.
For further discussion of security, see section 3.4.
8. Acknowledgements
This document is a product of the DISMAN Working Group.
9. References
9.1. Normative References
[M.3100] ITU Recommendation M.3100, "Generic Network Information
Model", 1995
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15, RFC
1157, May 1990.
[RFC1215] Rose, M., "A Convention for defining traps for use with
the SNMP", RFC 1215, March 1991.
[RFC2021] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC3291] Daniele, M., Haberman, B., Routhier, S. and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 3291, May 2002.
[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
3414, 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., Ed., "Version 2 of the Protocol Operations
for the Simple Network Management Protocol (SNMP)", STD
62, RFC 3416, December 2002.
[RFC3584] 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",
BCP 74, RFC 3584, August 2003.
[X.733] ITU Recommendation X.733, "Information Technology - Open
Systems Interconnection - System Management: Alarm
Reporting Function", 1992.
[X.736] ITU Recommendation X.736, "Information Technology - Open
Systems Interconnection - System Management: Security
Alarm Reporting Function", 1992.
9.2 Informative References
[RFC1657] Willis, S., Burruss, J. and J. Chu, Ed., "Definitions of
Managed Objects for the Fourth Version of the Border
Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July
1994.
[RFC2737] McCloghrie, K. and A. Bierman, "Entity MIB (version 2)",
RFC 2737, December 1999.
[RFC2819] Waldbusser, S. "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB using SMIv2", RFC 2863, June 2000.
[RFC2981] Kavasseri, R., Ed., "Event MIB", RFC 2981, October 2000.
[RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, November
2000.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for
the Simple Network Management Protocol (SNMP)", STD 62,
RFC 3418, December 2002.
[RFC3805] Bergman, R., Lewis, H. and I. McDonald, "Printer MIB v2",
RFC 3805, June 2004.
10. Authors’ Addresses
Sharon Chisholm
Nortel Networks
PO Box 3511, Station C
Ottawa, Ontario, K1Y 4H7
Canada
EMail: schishol@nortelnetworks.com
Dan Romascanu
Avaya
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
Israel
Phone: +972-3-645-8414
EMail: dromasca@avaya.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.