< draft-ietf-idwg-requirements-09.txt		draft-ietf-idwg-requirements-10.txt >
	Intrusion Detection Working Group M. Wood		Intrusion Detection Working Group M. Wood
	Internet-Draft Internet Security Systems, Inc		Internet-Draft Internet Security Systems, Inc
	Expires: March 25, 2003 M. Erlinger		Expires: April 22, 2003 M. Erlinger
	Harvey Mudd College		Harvey Mudd College
	September 24, 2002		October 22, 2002
	Intrusion Detection Message Exchange Requirements		Intrusion Detection Message Exchange Requirements
	draft-ietf-idwg-requirements-09		draft-ietf-idwg-requirements-10
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 25, 2003.		This Internet-Draft will expire on April 22, 2003.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2002). All Rights Reserved.
	Abstract		Abstract
	The purpose of the Intrusion Detection Exchange Format Working Group		The purpose of the Intrusion Detection Exchange Format Working Group
	(IDWG) is to define data formats and exchange procedures for sharing		(IDWG) is to define data formats and exchange procedures for sharing
	information of interest to intrusion detection and response systems,		information of interest to intrusion detection and response systems,
	skipping to change at page 4, line 13 ¶		skipping to change at page 4, line 13 ¶
	6.16 Time Granularity and Accuracy . . . . . . . . . . . . . . 25		6.16 Time Granularity and Accuracy . . . . . . . . . . . . . . 25
	6.16.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 25		6.16.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 25
	6.17 Message Extensions . . . . . . . . . . . . . . . . . . . . 25		6.17 Message Extensions . . . . . . . . . . . . . . . . . . . . 25
	6.17.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 25		6.17.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 25
	6.18 Message Semantics . . . . . . . . . . . . . . . . . . . . 25		6.18 Message Semantics . . . . . . . . . . . . . . . . . . . . 25
	6.18.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 25		6.18.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 25
	6.18.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 26		6.18.2 Scenario: . . . . . . . . . . . . . . . . . . . . . . . . 26
	6.19 Message Extensibility . . . . . . . . . . . . . . . . . . 26		6.19 Message Extensibility . . . . . . . . . . . . . . . . . . 26
	6.19.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 26		6.19.1 Rationale: . . . . . . . . . . . . . . . . . . . . . . . . 26
	7. Security Considerations . . . . . . . . . . . . . . . . . 27		7. Security Considerations . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . 27		Informative References . . . . . . . . . . . . . . . . . . 28
	A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . 28
	Full Copyright Statement . . . . . . . . . . . . . . . . . 29		A. History of Significant Changes . . . . . . . . . . . . . . 29
			A.1 Significant Changes Since requirements-09 . . . . . . . . 29
			B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 30
			Full Copyright Statement . . . . . . . . . . . . . . . . . 31
	1. Conventions Used in This Document		1. Conventions Used in This Document
	This is not an IETF standards track document and thus the keywords		This is not an IETF standards track document [1] and thus the
	MUST, MUST NOT, SHOULD, and MAY are NOT as in RFC 2119, but rather:		keywords MUST, MUST NOT, SHOULD, and MAY are NOT as in RFC 2119, [2]
			but rather:
	o MUST: This word, or the terms "REQUIRED" or "SHALL", means that		o MUST: This word, or the terms "REQUIRED" or "SHALL", means that
	the described behavior or characteristic is an absolute		the described behavior or characteristic is an absolute
	requirement for a proposed IDWG specification.		requirement for a proposed IDWG specification.
	o MUST NOT: This phrase, or the phrase "SHALL NOT", means that the		o MUST NOT: This phrase, or the phrase "SHALL NOT", means that the
	described behavior or characteristic is an absolute prohibition of		described behavior or characteristic is an absolute prohibition of
	a proposed IDWG specification.		a proposed IDWG specification.
	o SHOULD: This word, or the adjective "RECOMMENDED", means that		o SHOULD: This word, or the adjective "RECOMMENDED", means that
	skipping to change at page 6, line 11 ¶		skipping to change at page 6, line 11 ¶
	specification. One proposed specification may choose to include		specification. One proposed specification may choose to include
	the described behavior or characteristic while another proposed		the described behavior or characteristic while another proposed
	specification may omit the same behavior or characteristic.		specification may omit the same behavior or characteristic.
	2. Introduction		2. Introduction
	This document defines requirements for the Intrusion Detection		This document defines requirements for the Intrusion Detection
	Message Exchange Format (IDMEF), which is the intended work product		Message Exchange Format (IDMEF), which is the intended work product
	of the Intrusion Detection Exchange Format Working Group (IDWG).		of the Intrusion Detection Exchange Format Working Group (IDWG).
	IDMEF is planned to be a standard format which automated Intrusion		IDMEF is planned to be a standard format which automated Intrusion
	Detection Systems (IDS) can use for reporting what they have deemed		Detection Systems (IDS) [4] can use for reporting what they have
	to be suspicious or of interest. This document also specifies		deemed to be suspicious or of interest. This document also specifies
	requirements for a communication protocol for communicating IDMEF.		requirements for a communication protocol for communicating IDMEF.
	As chartered IDWG, has the responsibility to first evaluate existing		As chartered IDWG, has the responsibility to first evaluate existing
	communication protocols before choosing to specify a new one. Thus		communication protocols before choosing to specify a new one. Thus
	the requirements in this document can be used to evaluate existing		the requirements in this document can be used to evaluate existing
	communication protocols. If IDWG determines that a new communication		communication protocols. If IDWG determines that a new communication
	protocol is necessary, the requirements in this document can be used		protocol is necessary, the requirements in this document can be used
	to evaluate proposed solutions.		to evaluate proposed solutions.
	2.1 Rationale for IDMEF		2.1 Rationale for IDMEF
	skipping to change at page 14, line 33 ¶		skipping to change at page 14, line 33 ¶
	MUST be formatted such that they can be presented to an operator in a		MUST be formatted such that they can be presented to an operator in a
	local language and adhering to local presentation customs.		local language and adhering to local presentation customs.
	4.1.2 Scenario:		4.1.2 Scenario:
	An IDMEF specification might include numeric event identifiers. An		An IDMEF specification might include numeric event identifiers. An
	IDMEF implementation might translate these numeric event identifiers		IDMEF implementation might translate these numeric event identifiers
	into local language descriptions. In cases where the messages		into local language descriptions. In cases where the messages
	contain strings, the information might be represented using the ISO/		contain strings, the information might be represented using the ISO/
	IEC IS 10646-1 character set and encoded using the UTF-8		IEC IS 10646-1 character set and encoded using the UTF-8
	transformation format to facilitate internationalization.		transformation format to facilitate internationalization [3].
	4.2 Message Filtering and Aggregation		4.2 Message Filtering and Aggregation
	The format of IDMEF messages MUST support filtering and/or		The format of IDMEF messages MUST support filtering and/or
	aggregation of data by the manager.		aggregation of data by the manager.
	4.2.1 Rationale:		4.2.1 Rationale:
	Since it is anticipated that some managers might want to perform		Since it is anticipated that some managers might want to perform
	filtering and/or data aggregation functions on IDMEF messages, the		filtering and/or data aggregation functions on IDMEF messages, the
	skipping to change at page 25, line 32 ¶		skipping to change at page 25, line 32 ¶
	used to timestamp the events have a specified accuracy.		used to timestamp the events have a specified accuracy.
	6.17 Message Extensions		6.17 Message Extensions
	The IDMEF message MUST support an extension mechanism used by		The IDMEF message MUST support an extension mechanism used by
	implementors to define implementation-specific data. The use of this		implementors to define implementation-specific data. The use of this
	mechanism by the implementor is OPTIONAL. This data contains		mechanism by the implementor is OPTIONAL. This data contains
	implementation-specific information determined by each implementor.		implementation-specific information determined by each implementor.
	The implementor MUST indicate how to interpret these extensions,		The implementor MUST indicate how to interpret these extensions,
	although there are no specific requirements placed on how		although there are no specific requirements placed on how
	implementors describe their implementation-specific extensions.		implementors describe their implementation-specific extensions. The
			lack or presence of such message extensions for implementation-
			specific data MUST NOT break interoperation.
	6.17.1 Rationale:		6.17.1 Rationale:
	Implementors might wish to supply extra data such as the version		Implementors might wish to supply extra data such as the version
	number of their product or other data that they believe provides		number of their product or other data that they believe provides
	value added due to the specific nature of their product.		value added due to the specific nature of their product.
	Implementors may publish a document or web site describing their		Implementors may publish a document or web site describing their
	extensions; they might also use an in-band extension mechanism that		extensions; they might also use an in-band extension mechanism that
	is self-describing.		is self-describing. Such extensions are not a license to break the
			interoperation of IDMEF messages.
	6.18 Message Semantics		6.18 Message Semantics
	The semantics of the IDMEF message MUST be well defined.		The semantics of the IDMEF message MUST be well defined.
	6.18.1 Rationale:		6.18.1 Rationale:
	Good semantics are key to understanding what the message is trying to		Good semantics are key to understanding what the message is trying to
	convey so there are no errors. Operators will decide what action to		convey so there are no errors. Operators will decide what action to
	take based on these messages, so it is important that they can		take based on these messages, so it is important that they can
	skipping to change at page 26, line 17 ¶		skipping to change at page 26, line 20 ¶
	Without this requirement, the operator receives an IDMEF message and		Without this requirement, the operator receives an IDMEF message and
	interprets it one way. The implementor who constructed the message		interprets it one way. The implementor who constructed the message
	intended it to have a different meaning from the operator's		intended it to have a different meaning from the operator's
	interpretation. The resulting corrective action is, therefore,		interpretation. The resulting corrective action is, therefore,
	incorrect.		incorrect.
	6.19 Message Extensibility		6.19 Message Extensibility
	The IDMEF itself MUST be extensible. As new ID technologies emerge		The IDMEF itself MUST be extensible. As new ID technologies emerge
	and as new information about events becomes available, the IDMEF		and as new information about events becomes available, the IDMEF
	message format MUST be able to include this new information.		message format MUST be able to include this new information. Such
			message extensibility must occur in such a manner that
			interoperability is NOT impacted.
	6.19.1 Rationale:		6.19.1 Rationale:
	As intrusion detection technology continues to evolve, it is likely		As intrusion detection technology continues to evolve, it is likely
	that additional information relating to detected events will become		that additional information relating to detected events will become
	available. The IDMEF message format MUST be able to be extended by a		available. The IDMEF message format MUST be able to be extended by a
	specific implementation to encompass this new information.		specific implementation to encompass this new information. Such
			extensions are not a license to break the interoperation of IDMEF
			messages.
	7. Security Considerations		7. Security Considerations
	This document does not treat security matters, except that Section 5		This document does not treat security matters, except that Section 5
	specifies security requirements for the protocols to be developed.		specifies security requirements for the protocols to be developed.
			Informative References
			[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
			9, RFC 2026, October 1996.
			[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
			Levels", BCP 14, RFC 2119, March 1997.
			[3] Alvestrand, H., "IETF Policy on Character Sets and Languages",
			BCP 18, RFC 2277, January 1998.
			[4] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
	Authors' Addresses		Authors' Addresses
	Mark Wood		Mark Wood
	Internet Security Systems, Inc		Internet Security Systems, Inc
	6303 Barfield Road		6303 Barfield Road
	Atlanta, GA 30328		Atlanta, GA 30328
	US		US
	EMail: mark1@iss.net		EMail: mark1@iss.net
	Michael A. Erlinger		Michael A. Erlinger
	Harvey Mudd College		Harvey Mudd College
	Computer Science Dept		Computer Science Dept
	301 East 12th Street		301 East 12th Street
	Claremont, CA 91711		Claremont, CA 91711
	US		US
	EMail: mike@cs.hmc.edu		EMail: mike@cs.hmc.edu
	URI: http://www.cs.hmc.edu/		URI: http://www.cs.hmc.edu/
	Appendix A. Acknowledgements		Appendix A. History of Significant Changes
			The RFC Editor should remove this section and its corresponding TOC
			references prior to publication.
			A.1 Significant Changes Since requirements-09
			Change section 6.17, Message Extensions, to indicate that such
			extensions CANNOT affect interoperability
			Change section 6.19, Message Extensions, to indicate that such
			extensions CANNOT affect interoperability
			Add a Reference Section and some related anchors
			Appendix B. Acknowledgements
	The following individuals contributed substantially to this document		The following individuals contributed substantially to this document
	and should be recognized for their efforts. This document would not		and should be recognized for their efforts. This document would not
	exist without their help:		exist without their help:
	Mark Crosbie, Hewlett-Packard		Mark Crosbie, Hewlett-Packard
	David Curry, IBM Emergency Response Services		David Curry, IBM Emergency Response Services
	David Donahoo, Air Force Information Warfare Center		David Donahoo, Air Force Information Warfare Center
End of changes. 14 change blocks.
	17 lines changed or deleted		56 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/