rfc8274.original		rfc8274.txt
	MILE Working Group P. Kampanakis		Internet Engineering Task Force (IETF) P. Kampanakis
	Internet-Draft Cisco Systems		Request for Comments: 8274 Cisco Systems
	Intended status: Informational M. Suzuki		Category: Informational M. Suzuki
	Expires: March 11, 2018 NICT		ISSN: 2070-1721 NICT
	September 7, 2017		November 2017
	Incident Object Description Exchange Format Usage Guidance		Incident Object Description Exchange Format Usage Guidance
	draft-ietf-mile-iodef-guidance-11
	Abstract		Abstract
	The Incident Object Description Exchange Format (IODEF) v2 (RFC7970)		The Incident Object Description Exchange Format (IODEF) v2 (RFC 7970)
	defines a data representation that provides a framework for sharing		defines a data representation that provides a framework for sharing
	information about computer security incidents commonly exchanged by		information about computer security incidents commonly exchanged by
	Computer Security Incident Response Teams (CSIRTs) . Since the IODEF		Computer Security Incident Response Teams (CSIRTs). Since the IODEF
	model includes a wealth of available options that can be used to		model includes a wealth of available options that can be used to
	describe a security incident or issue, it can be challenging for		describe a security incident or issue, it can be challenging for
	security practitioners to develop tools that leverage IODEF for		security practitioners to develop tools that leverage IODEF for
	incident sharing. This document provides guidelines for IODEF		incident sharing. This document provides guidelines for IODEF
	implementers. It addresses how common security indicators can be		implementers. It addresses how common security indicators can be
	represented in IODEF and use-cases of how IODEF is being used. This		represented in IODEF and provides use cases of how IODEF is being
	document aims to make IODEF's adoption by vendors easier and		used. This document aims to make IODEF's adoption by vendors easier
	encourage faster and wider adoption of the model by CSIRTs around the		and to encourage faster and wider adoption of the model by CSIRTs
	world.		around the world.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are a candidate for any level of Internet
			Standard; see Section 2 of RFC 7841.
	This Internet-Draft will expire on March 11, 2018.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8274.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 20		skipping to change at page 2, line 17
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Implementation and Use Strategy . . . . . . . . . . . . . . . 3		3. Implementation and Use Strategy . . . . . . . . . . . . . . . 3
	3.1. Minimal IODEF document . . . . . . . . . . . . . . . . . 3		3.1. Minimal IODEF Document . . . . . . . . . . . . . . . . . 3
	3.2. Information represented . . . . . . . . . . . . . . . . . 4		3.2. Information Represented . . . . . . . . . . . . . . . . . 4
	3.3. IODEF Classes . . . . . . . . . . . . . . . . . . . . . . 5		3.3. IODEF Classes . . . . . . . . . . . . . . . . . . . . . . 5
	4. IODEF usage considerations . . . . . . . . . . . . . . . . . 6		4. IODEF Usage Considerations . . . . . . . . . . . . . . . . . 6
	4.1. External References . . . . . . . . . . . . . . . . . . . 6		4.1. External References . . . . . . . . . . . . . . . . . . . 6
	4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 6		4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 6
	4.3. Indicator predicate logic . . . . . . . . . . . . . . . . 7		4.3. Indicator Predicate Logic . . . . . . . . . . . . . . . . 7
	4.4. Disclosure level . . . . . . . . . . . . . . . . . . . . 7		4.4. Disclosure Level . . . . . . . . . . . . . . . . . . . . 7
	5. IODEF Uses . . . . . . . . . . . . . . . . . . . . . . . . . 8		5. IODEF Uses . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Implementations . . . . . . . . . . . . . . . . . . . . . 8		5.1. Implementations . . . . . . . . . . . . . . . . . . . . . 8
	5.2. Inter-vendor and Service Provider Exercise . . . . . . . 8		5.2. Inter-vendor and Service Provider Exercise . . . . . . . 8
	5.3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 11		5.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Indicator predicate logic examples . . . . . . . . . 13		Appendix A. Indicator Predicate Logic Examples . . . . . . . . . 13
	Appendix B. Inter-vendor and Service Provider Exercise Examples 16		Appendix B. Inter-vendor and Service Provider Exercise Examples 16
	B.1. Malware Delivery URL . . . . . . . . . . . . . . . . . . 16		B.1. Malware Delivery URL . . . . . . . . . . . . . . . . . . 16
	B.2. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 17		B.2. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	B.3. Spear-Phishing . . . . . . . . . . . . . . . . . . . . . 20		B.3. Spear Phishing . . . . . . . . . . . . . . . . . . . . . 20
	B.4. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 24		B.4. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 24
	B.5. IoT Malware . . . . . . . . . . . . . . . . . . . . . . . 30		B.5. IoT Malware . . . . . . . . . . . . . . . . . . . . . . . 30
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	The Incident Object Description Exchange Format (IODEF) v2 [RFC7970]		The Incident Object Description Exchange Format (IODEF) v2 [RFC7970]
	defines a data representation that provides a framework for sharing		defines a data representation that provides a framework for sharing
	computer security incident information commonly exchanged by Computer		computer security incident information commonly exchanged by Computer
	Security Incident Response Teams (CSIRTs). The IODEF data model		Security Incident Response Teams (CSIRTs). The IODEF data model
	consists of multiple classes and data types that are defined in the		consists of multiple classes and data types that are defined in the
	IODEF XML schema.		IODEF XML schema.
	The IODEF schema was designed to describe all the possible fields		The IODEF schema was designed to describe all the possible fields
	needed in a security incident exchange. Thus, IODEF contains a		needed in a security incident exchange. Thus, IODEF contains a
	plethora of data constructs which could make it hard for IODEF		plethora of data constructs that could make it hard for IODEF
	implementers to decide which are important. Additionally, in the		implementers to decide which are important. Additionally, in the
	IODEF schema, there exist multiple fields and classes which do not		IODEF schema, there exist multiple fields and classes that do not
	necessarily need to be used in every possible data exchange.		necessarily need to be used in every possible data exchange.
	Moreover, some IODEF classes are useful only in rare circumstances.		Moreover, some IODEF classes are useful only in rare circumstances.
	This document tries to address these concerns. It also presents how		This document tries to address these concerns. It also presents how
	common security indicators can be represented in IODEF. It points		common security indicators can be represented in IODEF, it points out
	out the most important IODEF classes for an implementer and describes		the most important IODEF classes for an implementer and describes
	other ones that are not as important. Also, it presents some common		other ones that are not as important, and it presents some common
	pitfalls for IODEF implementers and how to address them. The end		pitfalls for IODEF implementers and how to address them. The end
	goal of this document is to make IODEF's use by vendors easier and		goal of this document is to make IODEF's use by vendors easier and to
	encourage wider adoption of the model by CSIRTs around the world.		encourage wider adoption of the model by CSIRTs around the world.
	Section 3 discusses the recommended classes and how an IODEF		Section 3 discusses the recommended classes and how an IODEF
	implementer should choose the classes to implement. Section 4		implementer should choose the classes to implement. Section 4
	presents common considerations a practitioner will come across and		presents common considerations a practitioner will come across and
	how to address them. Section 5 goes over some common uses of IODEF.		how to address them. Section 5 goes over some common uses of IODEF.
	2. Terminology		2. Terminology
	The terminology used in this document follows the one defined in		The terminology used in this document is defined in [RFC7970] and
	[RFC7970] and [RFC7203].		[RFC7203].
	3. Implementation and Use Strategy		3. Implementation and Use Strategy
	It is important for IODEF implementers to distinguish how the IODEF		It is important for IODEF implementers to distinguish how the IODEF
	classes will be used in incident information exchanges. It is also		classes will be used in incident information exchanges. It is also
	important to understand the most common IODEF classes that describe		important to understand the most common IODEF classes that describe
	common security incidents or indicators. This section describes the		common security incidents or indicators. This section describes the
	most important classes and factors an IODEF practitioner should take		most important classes and factors an IODEF practitioner should take
	into consideration before using IODEF or designing an implementation.		into consideration before using IODEF or designing an implementation.
	3.1. Minimal IODEF document		3.1. Minimal IODEF Document
	An IODEF document must include at least an Incident class, an		An IODEF document must include at least an Incident class, an
	xml:lang attribute that defines the supported language and the IODEF		xml:lang attribute that defines the supported language, and the IODEF
	version attribute. An Incident must contain a purpose attribute and		version attribute. An Incident must contain a purpose attribute and
	three mandatory-to-implement elements. These elements are Generation		three mandatory-to-implement elements. These elements are
	time class that describes the time of the incident, an IncidentID		GenerationTime class (which describes the time of the incident), an
	class and at least one Contact class. The structure of the minimal		IncidentID class, and at least one Contact class. The structure of
	IODEF-Document is shown in Figure 1.		the minimal IODEF-Document class is shown in Figure 1.
	+---------------+ +--------------+		+---------------+ +--------------+
	|IODEF-Document | | Incident |		|IODEF-Document | | Incident |
	+---------------+ +--------------+ +----------------+		+---------------+ +--------------+ +--------------+
	|STRING version |<>--{1..*}--| ENUM purpose |<>----------| IncidentID |		|STRING version |<>--{1..*}--| ENUM purpose |<>---------| IncidentID |
	|ENUM xml:lang | | | +----------------+		|ENUM xml:lang | | | +--------------+
	| | | | | STRING name |		| | | | | STRING name |
	+---------------+ | | +----------------+		+---------------+ | | +--------------+
	| |		| |
	| |<>----------[ GenerationTime ]		| |<>---------[GenerationTime]
	| |		| |
	| | +----------------+		| | +--------------+
	| |<>--{1..*}--[ Contact |		| |<>-{1..*}--[ Contact |
	+--------------+ +----------------+		+--------------+ +--------------+
	| ENUM role |		| ENUM role |
	| ENUM type |		| ENUM type |
	+----------------+		+--------------+
	Figure 1: Minimal IODEF-Document class		Figure 1: Minimal IODEF-Document Class
	The IncidentID class must contain at least a name attribute.		The IncidentID class must contain at least a name attribute.
	In turn, the Contact class requires the type and role attributes, but		In turn, the Contact class requires the type and role attributes, but
	no elements are required by the IODEF v2 specification.		no elements are required by the IODEF v2 specification.
	Nevertheless, at least one of the elements in the Contact class, such		Nevertheless, at least one of the elements in the Contact class, such
	as an Email class, should be implemented so that the IODEF document		as an Email class, should be implemented so that the IODEF document
	is useful.		is useful.
	Section 7.1 of [RFC7970] presents a minimal IODEF document with only		Section 7.1 of [RFC7970] presents a minimal IODEF document with only
	the mandatory classes and attributes. Implementers can also refer to		the mandatory classes and attributes. Implementers can also refer to
	Section 7 of [RFC7970] and Appendix B for example IODEF v2 documents.		Section 7 of [RFC7970] and Appendix B of this document for examples
			of documents that are IODEF v2.
	3.2. Information represented		3.2. Information Represented
	There is no need for a practitioner to use or implement IODEF classes		There is no need for a practitioner to use or implement IODEF classes
	and fields other than the minimal ones (Section 3.1) and the ones		and fields other than the minimal ones (see Section 3.1) and the ones
	necessary for her use-cases. The implementer should carefully look		necessary for use cases. The implementer should carefully look into
	into the schema and decide which classes to implement (or not).		the schema and decide which classes to implement (or not).
	For example, if we have Distributed Denial of Service (DDoS) as a		For example, if we have Distributed Denial of Service (DDoS) as a
	potential use-case, then the Flow class and its included information		potential use case, then the Flow class and its included information
	are the most important classes to use. The Flow class describes		are the most important classes to use. The Flow class describes
	information related to the attacker and victim hosts, which		information related to the attacker and victim hosts, which could
	information could help automated filtering or sink-hole operations.		help automated filtering or sinkhole operations.
	Another potential use-case is malware command and control (c2).		Another potential use case is malware command and control (C2).
	After modern malware infects a device, it usually proceeds to connect		After modern malware infects a device, it usually proceeds to connect
	to one or more c2 servers to receive instructions from its master and		to one or more C2 servers to receive instructions from its master and
	potentially exfiltrate information. To protect against such		potentially exfiltrate information. To protect against such
	activity, it is important to interrupt the c2 communication by		activity, it is important to interrupt the C2 communication by
	filtering the activity. IODEF can describe c2 activities using the		filtering the activity. IODEF can describe C2 activities using the
	Flow and the ServiceName classes.		Flow and the ServiceName classes.
	For use-cases where indicators need to be described, the		For use cases where indicators need to be described, the
	IndicatorData class will be implemented instead of the EventData		IndicatorData class will be implemented instead of the EventData
	class.		class.
	In summary, an implementer should identify her use-cases and find the		In summary, an implementer should identify the use cases and find the
	classes that are necessary to support in IODEF v2. Implementing and		classes that are necessary to support in IODEF v2. Implementing and
	parsing all IODEF classes can be cumbersome in some occasions and		parsing all IODEF classes can be cumbersome, in some occasions, and
	unnecessary. Other external schemata can also be used in IODEF to		unnecessary. Other external schemata can also be used in IODEF to
	describe incidents or indicators. External schemata should be parsed		describe incidents or indicators. External schemata should be parsed
	accordingly only if the implementer's IODEF use-cases require		accordingly only if the implementer's IODEF use cases require
	external schema information. But even when an IODEF implementation		external schema information. But even when an IODEF implementation
	cannot parse an external schema, the IODEF report can still be		cannot parse an external schema, the IODEF report can still be
	valuable to an incident response team. The information can also be		valuable to an incident response team. The information can also be
	useful when shared further with content consumers able to parse this		useful when shared further with content consumers that are able to
	information.		parse this information.
	IODEF supports multiple language translations of free-form, ML_STRING		IODEF supports multiple language translations of free-form, ML_STRING
	text in all classes [RFC7970]. That way, text in Description		text in all classes [RFC7970]. That way, text in Description
	elements can be translated to different languages by using a		elements can be translated to different languages by using a
	translation identifier in the class. Implementers should be able to		translation identifier in the class. Implementers should be able to
	parse iodef:MLStringType classes and extract only the information		parse iodef:MLStringType classes and extract only the information
	relevant to languages of interest.		relevant to languages of interest.
	3.3. IODEF Classes		3.3. IODEF Classes
	[RFC7970] contains classes that can describe attack Methods, Events,		[RFC7970] contains classes that can describe attack Methods, Events,
	Incidents, Indicators, how they were discovered and the Assessment of		Incidents, Indicators, how they were discovered, and the Assessment
	the repercussions for the victim. It is important for IODEF users to		of the repercussions for the victim. It is important for IODEF users
	know the distinction between these classes in order to decide which		to know the distinction between these classes in order to decide
	ones fulfill their use-cases.		which ones fulfill their use cases.
	An IndicatorData class depicts a threat indicator or observable that		An IndicatorData class depicts a threat indicator or an observable
	could be used to describe a threat that resulted in an attempted		that could be used to describe a threat that resulted in an attempted
	attack. For example, we could see an attack happening but it might		attack. An IndicatorData class depicts a threat indicator or
	have been prevented and not have resulted in an incident or security		observable that could be used to describe a threat that resulted in
	event. On the other hand, an EventData class usually describes a		an attempted attack. For example, we could see an attack happening,
	security event and can be considered as a report of something that		but it might have been prevented and not have resulted in an incident
	took place.		or security event. On the other hand, an EventData class usually
			describes a security event and can be considered a report of
			something that took place.
	Classes like Discovery, Assessment, Method, and RecoveryTime are used		Classes like Discovery, Assessment, Method, and RecoveryTime are used
	in conjunction with EventData as they related to the incident report		in conjunction with EventData as they relate to the incident report
	described in the EventData. The RelatedActivity class can reference		described in the EventData. The RelatedActivity class can reference
	an incident, an indicator or other related threat activity.		an incident, an indicator, or other related threat activity.
	While deciding what classes are important for the needed use-cases,		While deciding what classes are important for the needed use cases,
	IODEF users should carefully evaluate the necessary classes and how		IODEF users should carefully evaluate the necessary classes and how
	these are used in order to avoid unnecessary work. For example, if		these are used in order to avoid unnecessary work. For example, if
	we want to only describe indicators in IODEF, the implementation of		we want to only describe indicators in IODEF, the implementation of
	Method or Assessment might not be important.		Method or Assessment might not be important.
	4. IODEF usage considerations		4. IODEF Usage Considerations
	Implementers need to consider some common, standardized options for		Implementers need to consider some common, standardized options for
	their IODEF use strategy.		their IODEF use strategy.
	4.1. External References		4.1. External References
	The IODEF format includes the Reference class used for externally		The IODEF format includes the Reference class used for externally
	defined information such as a vulnerability, Intrusion Detection		defined information, such as a vulnerability, Intrusion Detection
	System (IDS) alert, malware sample, advisory, or attack technique.		System (IDS) alert, malware sample, advisory, or attack technique.
	To facilitate the exchange of information, the Reference class was		To facilitate the exchange of information, the Reference class was
	extended to the Enumeration Reference Format [RFC7495]. The		extended to the enumeration reference format [RFC7495]. The
	Enumeration Reference Format specifies a means to use external		enumeration reference format specifies a means to use external
	enumeration specifications (e.g. CVE) that could define an		enumeration specifications (e.g., Common Vulnerabilities and
	enumeration format, specific enumeration values, or both. As		Exposures (CVE)) that could define an enumeration format, specific
	external enumerations can vary greatly, implementers should only		enumeration values, or both. As external enumerations can vary
	support the ones expected to describe their specific use-cases.		greatly, implementers should only support the ones expected to
			describe their specific use cases.
	4.2. Extensions		4.2. Extensions
	The IODEF data model ([RFC7970]) is extensible. Many attributes with		The IODEF data model [RFC7970] is extensible. Many attributes with
	enumerated values can be extended using the "ext-*" prefix.		enumerated values can be extended using the "ext-*" prefix.
	Additional classes can also be defined by using the AdditionalData		Additional classes can also be defined by using the AdditionalData
	and RecordItem classes. An extension to the AdditionalData class for		and RecordItem classes. An extension to the AdditionalData class for
	reporting Phishing emails is defined in [RFC5901]. Information about		reporting phishing emails is defined in [RFC5901]. Information about
	extending IODEF class attributes and enumerated values can be found		extending IODEF class attributes and enumerated values can be found
	in Section 5 of [RFC7970].		in Section 5 of [RFC7970].
	Additionally, IODEF can import existing schemata by using an		Additionally, IODEF can import existing schemata by using an
	extension framework defined in [RFC7203]. The framework enables		extension framework defined in [RFC7203]. The framework enables
	IODEF users to embed XML data inside an IODEF document using external		IODEF users to embed XML data inside an IODEF document using external
	schemata or structures defined by external specifications. Examples		schemata or structures defined by external specifications. Examples
	include CVE, CVRF and OVAL. [RFC7203] enhances the IODEF		include CVE, Common Vulnerability Reporting Framework (CVRF), and
	capabilities without further extending the data model.		Open Vulnerability and Assessment Language (OVAL). [RFC7203]
			enhances the IODEF capabilities without further extending the data
			model.
	IODEF implementers should not use their own IODEF extensions unless		IODEF implementers should not use their own IODEF extensions unless
	data cannot be represented using existing standards or importing them		data cannot be represented using existing standards or importing them
	in an IODEF document using [RFC7203] is not a suitable option.		in an IODEF document as defined in [RFC7203] is not a suitable
			option.
	4.3. Indicator predicate logic		4.3. Indicator Predicate Logic
	An IODEF [RFC7970] document can describe incident reports and		An IODEF document [RFC7970] can describe incident reports and
	indicators. The Indicator class can include references to other		indicators. The Indicator class can include references to other
	indicators, observables and more classes that contain details about		indicators, observables, and more classes that contain details about
	the indicator. When describing security indicators, it is often		the indicator. When describing security indicators, it is often
	common to need to group them together in order to form a group of		common to need to group them together in order to form a group of
	indicators that constitute a security threat. For example, a botnet		indicators that constitute a security threat. For example, a botnet
	might have multiple command and control servers. For that reason,		might have multiple command and control servers. For that reason,
	IODEF v2 introduced the IndicatorExpression class that is used to add		IODEF v2 introduced the IndicatorExpression class, which is used to
	the indicator predicate logic when grouping more than one indicators		add the indicator predicate logic when grouping more than one
	or observables.		indicator or observable.
	Implementations must be able to parse and apply the Boolean logic		Implementations must be able to parse and apply the Boolean logic
	offered by an IndicatorExpression in order to evaluate the existence		offered by an IndicatorExpression in order to evaluate the existence
	of an indicator. As explained in Section 3.29.5 of [RFC7970] the		of an indicator. As explained in Section 3.29.5 of [RFC7970], the
	IndicatorExpression element operator defines the operator applied to		IndicatorExpression element operator defines the operator applied to
	all the child element of the IndicatorExpression. If no operator is		all the child elements of the IndicatorExpression. If no operator is
	defined "and" should be assumed. IndicatorExpressions can also be		defined, "and" should be assumed. IndicatorExpressions can also be
	nested together. Child IndicatorExpressions should be treated as		nested together. Child IndicatorExpressions should be treated as
	child elements of their parent and they should be evaluated first		child elements of their parent, and they should be evaluated first
	before evaluated with the operator of their parent.		before being evaluated with the operator of their parent.
	Users can refer to Appendix A for example uses of the		Users can refer to Appendix A for example uses of the
	IndicatorExpressions in an IODEF v2.		IndicatorExpressions in an IODEF v2.
	4.4. Disclosure level		4.4. Disclosure Level
	Access to information in IODEF documents should be tightly locked		Access to information in IODEF documents should be tightly locked
	since the content may be confidential. IODEF has a common attribute,		since the content may be confidential. IODEF has a common attribute,
	called "restriction", which indicates the disclosure guideline to		called "restriction", which indicates the disclosure guideline to
	which the sender expects the recipient to adhere to for the		which the sender expects the recipient to adhere to for the
	information represented in the class and its children. That way, the		information represented in the class and its children. That way, the
	sender can express the level of disclosure for each component of an		sender can express the level of disclosure for each component of an
	IODEF document. Appropriate external measures could be implemented		IODEF document. Appropriate external measures could be implemented
	based on the restriction level. One example is when Real-time Inter-		based on the restriction level. One example is when Real-time Inter-
	network Defense (RID) [RFC6545] is used to transfer the IODEF		network Defense (RID) [RFC6545] is used to transfer the IODEF
	documents, it can provide policy guidelines for handling IODEF		documents, it can provide policy guidelines for handling IODEF
	documents by using the RIDPolicy class.		documents by using the RIDPolicy class.
	The enforcement of the disclosure guidelines is out of scope for		The enforcement of the disclosure guidelines is out of scope for
	IODEF. The recipient of the IODEF document needs to follow the		IODEF. The recipient of the IODEF document needs to follow the
	guidelines, but these guidelines themselves do not provide any		guidelines, but these guidelines themselves do not provide any
	enforcement measures. For that purpose, implementers should consider		enforcement measures. For that purpose, implementers should consider
	appropriate privacy control measures, technical or operational for		appropriate privacy control measures, technical or operational, for
	their implementation.		their implementation.
	5. IODEF Uses		5. IODEF Uses
	IODEF is currently used by various organizations in order to		IODEF is currently used by various organizations in order to
	represent security incidents and share incident and threat		represent security incidents and share incident and threat
	information between security operations organizations.		information between security operations organizations.
	5.1. Implementations		5.1. Implementations
	In order to use IODEF, tools like IODEF parsers are necessary.		In order to use IODEF, tools like IODEF parsers are necessary.
	[RFC8134] describes a set of IODEF implementations and uses by		[RFC8134] describes a set of IODEF implementations and uses by
	various vendors and Computer Emergency Readiness Team (CERT)		various vendors and Computer Emergency Readiness Team (CERT)
	organizations. The document does not specify any specific mandatory		organizations. The document does not specify any particular
	to implement (MTI) IODEF classes but provides a list of real world		mandatory-to-implement (MTI) IODEF classes but provides a list of
	uses. Perl and Python modules (XML::IODEF, Iodef::Pb, iodeflib) are		real-world uses. Perl and Python modules (XML::IODEF, Iodef::Pb,
	some examples. Moreover, implementers are encouraged to refer to		iodeflib) are some examples. Moreover, implementers are encouraged
	Section 7 of [RFC8134] practical IODEF usage guidelines.		to refer to Section 7 of [RFC8134] for practical IODEF usage
	[implementations], on the other hand, includes various vendor		guidelines. [implementations], on the other hand, includes various
	incident reporting products that can consume and export in IODEF		vendor incident reporting products that can consume and export in
	format.		IODEF format.
	5.2. Inter-vendor and Service Provider Exercise		5.2. Inter-vendor and Service Provider Exercise
	As an interoperability exercise, in 2013 a limited number of vendors		As an interoperability exercise, a limited number of vendors
	organized and executed threat indicators exchanges in IODEF. The		organized and executed exchanges of threat indicators in IODEF in
	transport protocol used was RID. The threat information shared		2013. The transport protocol used was RID. The threat information
	included indicators from DDoS attacks; and Malware incidents and		shared included indicators from DDoS attacks as well as malware
	Spear-Phishing that targets specific individuals after harvesting		incidents and spear phishing that targets specific individuals after
	information about them. The results served as proof-of-concept (PoC)		harvesting information about them. The results served as proof-of-
	about how seemingly competing entities could use IODEF to exchange		concept (PoC) about how seemingly competing entities could use IODEF
	sanitized security information. As this was a PoC exercise only		to exchange sanitized security information. As this was a PoC
	example information (no real threats) were shared as part of the		exercise, only example information (no real threats) was shared as
	exchanges.		part of the exchanges.
	____________ ____________		____________ ____________
	| Vendor X | | Vendor Y |		| Vendor X | | Vendor Y |
	| RID Agent |_______-------------________| RID Agent |		| RID Agent |_______-------------________| RID Agent |
	|___________| | Internet | |___________|		|___________| | Internet | |___________|
	-------------		-------------
	---- RID Report message --->		---- RID Report message --->
	-- carrying IODEF example ->		-- carrying IODEF example ->
	--------- over TLS -------->		--------- over TLS -------->
	<----- RID Ack message -----		<----- RID Ack message -----
	<--- in case of failure ----		<--- in case of failure ----
	Figure 2: PoC peering topology		Figure 2: PoC Peering Topology
	Figure 2 shows how RID interactions took place during the PoC.		Figure 2 shows how RID interactions took place during the PoC.
	Participating organizations were running RID Agent software on-		Participating organizations were running RID Agent software on
	premises. The RID Agents formed peering relationships with other		premises. The RID Agents formed peering relationships with other
	participating organizations. When Entity X had a new incident to		participating organizations. When Entity X had a new incident to
	exchange it would package it in IODEF and send it to Entity Y over		exchange, it would package it in IODEF and send it to Entity Y over
	TLS in a RID Report message. In case there was an issue with the		Transport Layer Security (TLS) in a RID Report message. In case
	message, Entity Y would send an RID Acknowledgement message back to		there was an issue with the message, Entity Y would send a RID
	Entity X which included an application level message to describe the		Acknowledgement message back to Entity X, which included an
	issue. Interoperability between RID agents implementing [RFC6545]		application-level message to describe the issue. Interoperability
	and [RFC6546] was also confirmed.		between RID Agents implementing [RFC6545] and [RFC6546] was also
			confirmed.
	The first use-case included sharing of Malware Data Related to an		The first use case included sharing of malware data related to an
	Incident between CSIRTs. After Entity X detected an incident, she		Incident between CSIRTs. After Entity X detected an incident, Entity
	would put data about malware found during the incident in a backend		X would put data about malware found during the incident in a backend
	system. Entity X then decided to share the incident information with		system. Entity X then decided to share the incident information with
	Entity Y about the malware discovered. This could be a human		Entity Y about the malware discovered. This could be a human
	decision or part of an automated process.		decision or part of an automated process.
	Below are the steps followed for the malware information exchange		Below are the steps followed for the malware information exchange
	that was taking place:		that was taking place:
	(1) Entity X has a sharing agreement with Entity Y, and has already		(1) Entity X has a sharing agreement with Entity Y and has already
	been configured with the IP address of Entity Y's RID Agent.		been configured with the IP address of Entity Y's RID Agent.
	(2) Entity X's RID Agent connects to Entity Y's RID Agent, and		(2) Entity X's RID Agent connects to Entity Y's RID Agent, and
	mutual authentication occurs using PKI digital certificates.		mutual authentication occurs using PKI digital certificates.
	(3) Entity X pushes out a RID Report message which contains		(3) Entity X pushes out a RID Report message, which contains
	information about N pieces of discovered malware. IODEF is used		information about N pieces of discovered malware. IODEF is used
	in RID to describe the		in RID to describe the
	(a) Hash of malware files		(a) hash of malware files;
			(b) registry settings changed by the malware; and
	(b) Registry settings changed by the malware
	(c) C&C Information for the malware		(c) C&C information for the malware.
	(4) Entity Y receives RID Report message, sends RID Acknowledgement		(4) Entity Y receives a RID Report message and sends a RID
	message		Acknowledgement message.
	(5) Entity Y stores the data in a format that makes it possible for		(5) Entity Y stores the data in a format that makes it possible for
	the back end to know which source the data came from.		the backend to know which source the data came from.
	Another use-case was sharing a DDoS attack as explained in the		Another use case was sharing a DDoS attack as explained in the
	following scenario: Entity X, a Critical Infrastructure and Key		following scenario: Entity X, a Critical Infrastructure and Key
	Resource (CIKR) company detects that their internet connection is		Resource (CIKR) company, detects that their internet connection is
	saturated with an abnormal amount of traffic. Further investigation		saturated with an abnormal amount of traffic. Further investigation
	determines that this is an actual DDoS attack. Entity X's CSIT		determines that this is an actual DDoS attack. Entity X's CSIRT
	contacts their ISP, Entity Y, and shares information with them about		contacts their ISP, Entity Y, and shares information with them about
	the attack traffic characteristics. Entity X's ISP is being		the attack traffic characteristics. Entity X's ISP is being
	overwhelmed by the amount of traffic, so it shares attack signatures		overwhelmed by the amount of traffic, so it shares attack signatures
	and IP addresses of the most prolific hosts with its adjacent ISPs.		and IP addresses of the most prolific hosts with its adjacent ISPs.
	Below are the steps followed for a DDoS information exchange:		Below are the steps followed for a DDoS information exchange:
	(1) Entity X has a sharing agreement with Entity Y, and has already		(1) Entity X has a sharing agreement with Entity Y and has already
	been configured with the IP address of Entity Y's RID Agent.		been configured with the IP address of Entity Y's RID Agent.
	(2) Entity X's RID Agent connects to Entity Y's RID Agent, and		(2) Entity X's RID Agent connects to Entity Y's RID Agent, and
	mutual authentication occurs using PKI digital certificates.		mutual authentication occurs using PKI digital certificates.
	(3) Entity X pushes out a RID Report message which contains		(3) Entity X pushes out a RID Report message, which contains
	information about the DDoS attack. IODEF is used in RID to		information about the DDoS attack. IODEF is used in RID to
	describe the		describe the following:
	(a) Start and Detect dates and times		(a) Start and Detect dates and times;
	(b) IP Addresses of nodes sending DDoS Traffic		(b) IP addresses of nodes sending DDoS traffic;
	(c) Sharing and Use Restrictions		(c) sharing and use restrictions;
	(d) Traffic characteristics (protocols and ports)		(d) traffic characteristics (protocols and ports);
	(e) HTTP User-Agents used		(e) HTTP user agents used; and
	(f) IP Addresses of C&C for a botnet		(f) IP addresses of C&C for a botnet.
	(4) Entity Y receives RID Report message, sends RID Acknowledgement		(4) Entity Y receives a RID Report message and sends a RID
	message		Acknowledgement message.
	(5) Entity Y stores the data in a format that makes it possible for		(5) Entity Y stores the data in a format that makes it possible for
	the back end to know which source the data came from.		the backend to know which source the data came from.
	(6) Entity Y shares information with other ISP Entities it has an		(6) Entity Y shares information with other ISP entities it has an
	established relationship with.		established relationship with.
	One more use-case was sharing spear-phishing email information as		One more use case was sharing spear-phishing email information as
	explained in the following scenario: The board members of several		explained in the following scenario: the board members of several
	defense contractors receive a targeted email inviting them to attend		defense contractors receive a targeted email inviting them to attend
	a conference in San Francisco. The board members are asked to		a conference in San Francisco. The board members are asked to
	provide their personally identifiable information such as their home		provide their personally identifiable information such as their home
	address, phone number, corporate email, etc in an attached document		address, phone number, corporate email, etc., in an attached document
	which came with the email. The board members are also asked to click		that came with the email. The board members are also asked to click
	on a URL which would allow them to reach the sign up page for the		on a URL that would allow them to reach the sign-up page for the
	conference. One of the recipients believes the email to be a		conference. One of the recipients believes the email to be a
	phishing attempt and forwards the email to their corporate CSIRT for		phishing attempt and forwards the email to their corporate CSIRT for
	analysis. The CSIRT identifies the email as an attempted spear		analysis. The CSIRT identifies the email as an attempted spear-
	phishing incident and distributes the indicators to their sharing		phishing incident and distributes the indicators to their sharing
	partners.		partners.
	Below are the steps followed for a spear-phishing information		Below are the steps followed for a spear-phishing information
	exchange between CSIRTs that was part of this PoC.		exchange between CSIRTs that were part of this PoC.
	(1) Entity X has a sharing agreement with Entity Y, and has already		(1) Entity X has a sharing agreement with Entity Y and has already
	been configured with the IP address of Entity Y's RID Agent.		been configured with the IP address of Entity Y's RID Agent.
	(2) Entity X's RID Agent connects to Entity Y's RID Agent, and		(2) Entity X's RID Agent connects to Entity Y's RID Agent, and
	mutual authentication occurs using PKI digital certificates.		mutual authentication occurs using PKI digital certificates.
	(3) Entity X pushes out a RID Report message which contains		(3) Entity X pushes out a RID Report message that contains
	information about the spear-phishing email. IODEF is used in		information about the spear-phishing email. IODEF is used in
	RID to describe the		RID to describe the following:
	(a) Attachment details (file Name, hash, size, malware family		(a) attachment details (file Name, hash, size, malware family);
	(b) Target description (IP, domain, NSLookup)		(b) target description (IP, domain, NSLookup);
	(c) Email information (From, Subject, header information, date/		(c) email information (From, Subject, header information, date/
	time, digital signature)		time, digital signature); and
	(d) Confidence Score		(d) confidence score.
	(4) Entity Y receives RID Report message, sends RID Acknowledgement		(4) Entity Y receives a RID Report message and sends a RID
	message		Acknowledgement message.
	(5) Entity Y stores the data in a format that makes it possible for		(5) Entity Y stores the data in a format that makes it possible for
	the back end to know which source the data came from.		the backend to know which source the data came from.
	Appendix B includes some of the incident IODEF example information		Appendix B includes some of the incident IODEF example information
	that was exchanged by the organizations' RID Agents as part of this		that was exchanged by the organizations' RID Agents as part of this
	proof-of-concept.		PoC.
	5.3. Use-cases		5.3. Use Cases
	Other use-cases of IODEF, other than the ones described above, could		Other use cases of IODEF, aside from the ones described above, could
	be:		be as follows:
	(1) ISP notifying a national CERT or organization when it identifies		(1) ISP notifying a national CERT or organization when it identifies
	and acts upon an incident and CERTs notifying ISPs when they are		and acts upon an incident, and CERTs notifying ISPs when they
	aware of incidents.		are aware of incidents.
	(2) Suspected phishing emails could be shared amongst organizations		(2) Suspected phishing emails could be shared amongst organizations
	and national agencies. Automation could validate web content		and national agencies. Automation could validate web content
	that the suspicious emails are pointing to. Identified		that the suspicious emails are pointing to. Identified
	malicious content linked in a phishing email could then be		malicious content linked in a phishing email could then be
	shared using IODEF. Phishing campaigns could thus be subverted		shared using IODEF. Phishing campaigns could thus be subverted
	much faster by automating information sharing using IODEF.		much faster by automating information sharing using IODEF.
	(3) When finding a certificate that should be revoked, a third-party		(3) When finding a certificate that should be revoked, a third party
	would forward an automated IODEF message to the CA with the full		would forward an automated IODEF message to the Certification
	context of the certificate and the CA could act accordingly		Authority (CA) with the full context of the certificate, and the
	after checking its validity. Alternatively, in the event of a		CA could act accordingly after checking its validity.
	compromise of the private key of a certificate, a third-party		Alternatively, in the event of a compromise of the private key
	could alert the certificate owner about the compromise using		of a certificate, a third party could alert the certificate
	IODEF.		owner about the compromise using IODEF.
	6. IANA Considerations		6. IANA Considerations
	This memo does not require any IANA actions.		This memo does not require any IANA actions.
	7. Security Considerations		7. Security Considerations
	This document does not incur any new security issues, since it only		This document does not incur any new security issues, because it only
	talks about the usage of IODEFv2 defined RFC7970. Nevertheless,		talks about the usage of IODEFv2 defined in RFC 7970. Nevertheless,
	readers of this document should refer to the Security Considerations		readers of this document should refer to the Security Considerations
	section of [RFC7970].		section of [RFC7970].
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document		[RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document
	Class for Reporting Phishing", RFC 5901,		Class for Reporting Phishing", RFC 5901,
	DOI 10.17487/RFC5901, July 2010,		DOI 10.17487/RFC5901, July 2010,
	skipping to change at page 13, line 12		skipping to change at page 13, line 27
	(IODEF)", RFC 7495, DOI 10.17487/RFC7495, March 2015,		(IODEF)", RFC 7495, DOI 10.17487/RFC7495, March 2015,
	<https://www.rfc-editor.org/info/rfc7495>.		<https://www.rfc-editor.org/info/rfc7495>.
	[RFC7970] Danyliw, R., "The Incident Object Description Exchange		[RFC7970] Danyliw, R., "The Incident Object Description Exchange
	Format Version 2", RFC 7970, DOI 10.17487/RFC7970,		Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
	November 2016, <https://www.rfc-editor.org/info/rfc7970>.		November 2016, <https://www.rfc-editor.org/info/rfc7970>.
	8.2. Informative References		8.2. Informative References
	[implementations]		[implementations]
	"Implementations on IODEF",		"Implementations on Incident Object Description Exchange
	<http://siis.realmv6.org/implementations/>.		Format", <http://siis.realmv6.org/implementations/>.
	[RFC6546] Trammell, B., "Transport of Real-time Inter-network		[RFC6546] Trammell, B., "Transport of Real-time Inter-network
	Defense (RID) Messages over HTTP/TLS", RFC 6546,		Defense (RID) Messages over HTTP/TLS", RFC 6546,
	DOI 10.17487/RFC6546, April 2012,		DOI 10.17487/RFC6546, April 2012,
	<https://www.rfc-editor.org/info/rfc6546>.		<https://www.rfc-editor.org/info/rfc6546>.
	[RFC8134] Inacio, C. and D. Miyamoto, "Management Incident		[RFC8134] Inacio, C. and D. Miyamoto, "Management Incident
	Lightweight Exchange (MILE) Implementation Report",		Lightweight Exchange (MILE) Implementation Report",
	RFC 8134, DOI 10.17487/RFC8134, May 2017,		RFC 8134, DOI 10.17487/RFC8134, May 2017,
	<https://www.rfc-editor.org/info/rfc8134>.		<https://www.rfc-editor.org/info/rfc8134>.
	Appendix A. Indicator predicate logic examples		Appendix A. Indicator Predicate Logic Examples
	In the following example the EventData class evaluates as a Flow of		In the following example, the EventData class evaluates as a Flow of
	one System with source address being (192.0.2.104 OR 192.0.2.106) AND		one System with source address 192.0.2.104 OR 192.0.2.106 AND target
	target address 198.51.100.1.		address 198.51.100.1.
	<!-- ...XML code omitted... -->		<!-- ...XML code omitted... -->
	<IndicatorData>		<IndicatorData>
	<Indicator>		<Indicator>
	<IndicatorID name="csirt.example.com" version="1">		<IndicatorID name="csirt.example.com" version="1">
	G90823490		G90823490
	</IndicatorID>		</IndicatorID>
	<Description>C2 domains</Description>		<Description>C2 domains</Description>
	<IndicatorExpression operator="and">		<IndicatorExpression operator="and">
	<IndicatorExpression operator="or">		<IndicatorExpression operator="or">
	skipping to change at page 14, line 50		skipping to change at page 14, line 50
	</System>		</System>
	</Observable>		</Observable>
	</IndicatorExpression>		</IndicatorExpression>
	</Indicator>		</Indicator>
	</IndicatorData>		</IndicatorData>
	<!-- ...XML code omitted... -->		<!-- ...XML code omitted... -->
	Similarly, the FileData Class can be an observable in an		Similarly, the FileData Class can be an observable in an
	IndicatorExpression. The hash values of two files can be used to		IndicatorExpression. The hash values of two files can be used to
	match against an indicator using Boolean "or" logic. In the		match against an indicator using Boolean "or" logic. In the
	following example the indicator consists of either of the two files		following example, the indicator consists of either of the two files
	with two different hashes.		with two different hashes.
	<!-- ...XML code omitted... -->		<!-- ...XML code omitted... -->
	<IndicatorData>		<IndicatorData>
	<Indicator>		<Indicator>
	<IndicatorID name="csirt.example.com" version="1">		<IndicatorID name="csirt.example.com" version="1">
	A4399IWQ		A4399IWQ
	</IndicatorID>		</IndicatorID>
	<Description>File hash watchlist</Description>		<Description>File hash watchlist</Description>
	<IndicatorExpression operator="or">		<IndicatorExpression operator="or">
	skipping to change at page 16, line 7		skipping to change at page 16, line 7
	</File>		</File>
	</FileData>		</FileData>
	</Observable>		</Observable>
	</IndicatorExpression>		</IndicatorExpression>
	</Indicator>		</Indicator>
	</IndicatorData>		</IndicatorData>
	<!-- ...XML code omitted... -->		<!-- ...XML code omitted... -->
	Appendix B. Inter-vendor and Service Provider Exercise Examples		Appendix B. Inter-vendor and Service Provider Exercise Examples
	Below some of the incident IODEF example information that was		Below, some of the incident IODEF example information that was
	exchanged by the vendors as part of this proof-of-concept Inter-		exchanged by the vendors as part of this proof-of-concept, inter-
	vendor and Service Provider Exercise.		vendor and service provider exercise.
	B.1. Malware Delivery URL		B.1. Malware Delivery URL
	This example indicates malware and related URL for file delivery.		This example indicates malware and a related URL for file delivery.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<IODEF-Document version="2.00"		<IODEF-Document version="2.00"
	xmlns="urn:ietf:params:xml:ns:iodef-2.0"		xmlns="urn:ietf:params:xml:ns:iodef-2.0"
	xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"		xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<iodef:Incident purpose="reporting">		<iodef:Incident purpose="reporting">
	<iodef:IncidentID name="csirt.example.com">		<iodef:IncidentID name="csirt.example.com">
	189801		189801
	</iodef:IncidentID>		</iodef:IncidentID>
	<iodef:ReportTime>2012-12-05T12:20:00+00:00</iodef:ReportTime>		<iodef:ReportTime>2012-12-05T12:20:00+00:00</iodef:ReportTime>
	<iodef:GenerationTime>2012-12-05T12:20:00+00:00</iodef:GenerationTime>		<iodef:GenerationTime>2012-12-05T12:20:00+00:00
	<iodef:Description>Malware and related indicators</iodef:Description>		</iodef:GenerationTime>
	<iodef:Assessment occurrence="potential">		<iodef:Description>Malware and related indicators
	<iodef:SystemImpact severity="medium" type="breach-privacy">		</iodef:Description>
	<iodef:Description>Malware with C&amp;C		<iodef:Assessment occurrence="potential">
	</iodef:Description>		<iodef:SystemImpact severity="medium" type="breach-privacy">
	</iodef:SystemImpact>		<iodef:Description>Malware with C&amp;C
	</iodef:Assessment>		</iodef:Description>
	<iodef:Contact role="creator" type="organization">		</iodef:SystemImpact>
	<iodef:ContactName>example.com CSIRT		</iodef:Assessment>
	</iodef:ContactName>		<iodef:Contact role="creator" type="organization">
	<iodef:Email>		<iodef:ContactName>example.com CSIRT
	<iodef:EmailTo>contact@csirt.example.com		</iodef:ContactName>
	</iodef:EmailTo>		<iodef:Email>
	</iodef:Email>		<iodef:EmailTo>contact@csirt.example.com
	</iodef:Contact>		</iodef:EmailTo>
	<iodef:EventData>		</iodef:Email>
	<iodef:Flow>		</iodef:Contact>
	<iodef:System category="source">		<iodef:EventData>
	<iodef:Node>		<iodef:Flow>
	<iodef:Address category="ipv4-addr">192.0.2.200		<iodef:System category="source">
	</iodef:Address>		<iodef:Node>
	<iodef:Address category="site-uri">		<iodef:Address category="ipv4-addr">192.0.2.200
	/log-bin/lunch_install.php?aff_id=1&amp;lunch_id=1&amp;maddr=&amp;action=install		</iodef:Address>
	</iodef:Address>		<iodef:Address category="site-uri">
	</iodef:Node>		/log-bin/lunch_install.php?aff_id=1&amp;lunch_id=1&amp;
	<iodef:NodeRole category="www"/>		maddr=&amp;action=install
	</iodef:System>		</iodef:Address>
	</iodef:Flow>		</iodef:Node>
	</iodef:EventData>		<iodef:NodeRole category="www"/>
	</iodef:Incident>		</iodef:System>
	</IODEF-Document>		</iodef:Flow>
			</iodef:EventData>
			</iodef:Incident>
			</IODEF-Document>
	B.2. DDoS		B.2. DDoS
	The DDoS test exchanged information that described a DDoS including		The DDoS test exchanged information that described a DDoS, including
	protocols and ports, bad IP addresses and HTTP User-Agent fields.		protocols and ports, bad IP addresses, and HTTP user agent fields.
	The IODEF version used for the data representation was based on		The IODEF version used for the data representation was based on
	[RFC7970].		[RFC7970].
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<IODEF-Document version="2.00"		<IODEF-Document version="2.00"
	xmlns="urn:ietf:params:xml:ns:iodef-2.0"		xmlns="urn:ietf:params:xml:ns:iodef-2.0"
	xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"		xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<iodef:Incident purpose="reporting" restriction="default">		<iodef:Incident purpose="reporting" restriction="default">
	<iodef:IncidentID name="csirt.example.com">		<iodef:IncidentID name="csirt.example.com">
	189701		189701
	</iodef:IncidentID>		</iodef:IncidentID>
	<iodef:DetectTime>2013-02-05T01:15:45+00:00</iodef:DetectTime>		<iodef:DetectTime>2013-02-05T01:15:45+00:00</iodef:DetectTime>
	<iodef:StartTime>2013-02-05T00:34:45+00:00</iodef:StartTime>		<iodef:StartTime>2013-02-05T00:34:45+00:00</iodef:StartTime>
	<iodef:ReportTime>2013-02-05T01:34:45+00:00</iodef:ReportTime>		<iodef:ReportTime>2013-02-05T01:34:45+00:00</iodef:ReportTime>
	<iodef:GenerationTime>2013-02-05T01:15:45+00:00</iodef:GenerationTime>		<iodef:GenerationTime>2013-02-05T01:15:45+00:00
	<iodef:Description>DDoS Traffic Seen</iodef:Description>		</iodef:GenerationTime>
	<iodef:Assessment occurrence="actual">		<iodef:Description>DDoS Traffic Seen</iodef:Description>
	<iodef:SystemImpact severity="medium" type="availability-system">		<iodef:Assessment occurrence="actual">
	<iodef:Description>DDoS Traffic		<iodef:SystemImpact severity="medium" type="availability-system">
	</iodef:Description>		<iodef:Description>DDoS Traffic
	</iodef:SystemImpact>		</iodef:Description>
	<iodef:Confidence rating="high"/>		</iodef:SystemImpact>
	</iodef:Assessment>		<iodef:Confidence rating="high"/>
	<iodef:Contact role="creator" type="organization">		</iodef:Assessment>
	<iodef:ContactName>Dummy Test</iodef:ContactName>		<iodef:Contact role="creator" type="organization">
	<iodef:Email>		<iodef:ContactName>Dummy Test</iodef:ContactName>
	<iodef:EmailTo>contact@dummytest.com		<iodef:Email>
	</iodef:EmailTo>		<iodef:EmailTo>contact@dummytest.com
	</iodef:Email>		</iodef:EmailTo>
	</iodef:Contact>		</iodef:Email>
	<iodef:EventData>		</iodef:Contact>
	<iodef:Description>		<iodef:EventData>
	Dummy Test sharing with ISP1		<iodef:Description>
	</iodef:Description>		Dummy Test sharing with ISP1
	<iodef:Method>		</iodef:Description>
	<iodef:Reference>		<iodef:Method>
	<iodef:URL>		<iodef:Reference>
	http://blog.spiderlabs.com/2011/01/loic-ddos-		<iodef:URL>
	analysis-and-detection.html		http://blog.spiderlabs.com/2011/01/loic-ddos-
	</iodef:URL>		analysis-and-detection.html
	<iodef:URL>		</iodef:URL>
	http://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon		<iodef:URL>
	</iodef:URL>		http://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon
	<iodef:Description>
	Low Orbit Ion Cannon User Agent
	</iodef:Description>
	</iodef:Reference>
	</iodef:Method>		</iodef:URL>
	<iodef:Flow>		<iodef:Description>
	<iodef:System category="source" spoofed="no">		Low Orbit Ion Cannon User Agent
	<iodef:Node>		</iodef:Description>
	<iodef:Address category="ipv4-addr">		</iodef:Reference>
	192.0.2.104		</iodef:Method>
	</iodef:Address>		<iodef:Flow>
	</iodef:Node>		<iodef:System category="source" spoofed="no">
	<iodef:Service ip-protocol="6">		<iodef:Node>
	<iodef:Port>1337</iodef:Port>		<iodef:Address category="ipv4-addr">
	</iodef:Service>		192.0.2.104
	</iodef:System>		</iodef:Address>
	<iodef:System category="source" spoofed="no">		</iodef:Node>
	<iodef:Node>		<iodef:Service ip-protocol="6">
	<iodef:Address category="ipv4-addr">		<iodef:Port>1337</iodef:Port>
	192.0.2.106		</iodef:Service>
	</iodef:Address>		</iodef:System>
	</iodef:Node>		<iodef:System category="source" spoofed="no">
	<iodef:Service ip-protocol="6">		<iodef:Node>
	<iodef:Port>1337</iodef:Port>		<iodef:Address category="ipv4-addr">
	</iodef:Service>		192.0.2.106
	</iodef:System>		</iodef:Address>
	<iodef:System category="source" spoofed="yes">		</iodef:Node>
	<iodef:Node>		<iodef:Service ip-protocol="6">
	<iodef:Address category="ipv4-net">		<iodef:Port>1337</iodef:Port>
	198.51.100.0/24		</iodef:Service>
	</iodef:Address>		</iodef:System>
	</iodef:Node>		<iodef:System category="source" spoofed="yes">
	<iodef:Service ip-protocol="6">		<iodef:Node>
	<iodef:Port>1337</iodef:Port>		<iodef:Address category="ipv4-net">
	</iodef:Service>		198.51.100.0/24
	</iodef:System>		</iodef:Address>
	<iodef:System category="source" spoofed="yes">		</iodef:Node>
	<iodef:Node>		<iodef:Service ip-protocol="6">
	<iodef:Address category="ipv6-addr">		<iodef:Port>1337</iodef:Port>
	2001:db8:dead:beef::1		</iodef:Service>
	</iodef:Address>		</iodef:System>
	</iodef:Node>		<iodef:System category="source" spoofed="yes">
	<iodef:Service ip-protocol="6">		<iodef:Node>
	<iodef:Port>1337</iodef:Port>		<iodef:Address category="ipv6-addr">
	</iodef:Service>		2001:db8:dead:beef::1
	</iodef:System>		</iodef:Address>
	<iodef:System category="target">		</iodef:Node>
	<iodef:Node>		<iodef:Service ip-protocol="6">
	<iodef:Address category="ipv4-addr">		<iodef:Port>1337</iodef:Port>
	203.0.113.1		</iodef:Service>
	</iodef:Address>		</iodef:System>
	</iodef:Node>		<iodef:System category="target">
	<iodef:Service ip-protocol="6">		<iodef:Node>
	<iodef:Port>80</iodef:Port>		<iodef:Address category="ipv4-addr">
	</iodef:Service>		203.0.113.1
	</iodef:System>		</iodef:Address>
	<iodef:System category="sensor">		</iodef:Node>
	<iodef:Node>		<iodef:Service ip-protocol="6">
	</iodef:Node>		<iodef:Port>80</iodef:Port>
	<iodef:Description>		</iodef:Service>
	Information provided in Flow class instance is from		</iodef:System>
	Inspection of traffic from network tap		<iodef:System category="sensor">
	</iodef:Description>		<iodef:Node>
	</iodef:System>		</iodef:Node>
	</iodef:Flow>		<iodef:Description>
	<iodef:Expectation action="other"/>		Information provided in Flow class instance is from
	</iodef:EventData>		Inspection of traffic from network tap
	<iodef:IndicatorData>		</iodef:Description>
	<iodef:Indicator>		</iodef:System>
	<iodef:IndicatorID name="csirt.example.com" version="1">		</iodef:Flow>
	G83345941		<iodef:Expectation action="other"/>
	</iodef:IndicatorID>		</iodef:EventData>
	<iodef:Description>		<iodef:IndicatorData>
	User-Agent string		<iodef:Indicator>
	</iodef:Description>		<iodef:IndicatorID name="csirt.example.com" version="1">
	<iodef:Observable>		G83345941
	<iodef:BulkObservable type="http-user-agent">		</iodef:IndicatorID>
	<iodef:BulkObservableList>		<iodef:Description>
	user-agent="Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12">		User-Agent string
	</iodef:BulkObservableList>		</iodef:Description>
	</iodef:BulkObservable>		<iodef:Observable>
	</iodef:Observable>		<iodef:BulkObservable type="http-user-agent">
	</iodef:Indicator>		<iodef:BulkObservableList>
	</iodef:IndicatorData>		user-agent="Mozilla/5.0 (Macintosh; U;
	</iodef:Incident>		Intel Mac OS X 10.5; en-US; rv:1.9.2.12)
	</IODEF-Document>		Gecko/20101026 Firefox/3.6.12">
			</iodef:BulkObservableList>
			</iodef:BulkObservable>
			</iodef:Observable>
			</iodef:Indicator>
			</iodef:IndicatorData>
			</iodef:Incident>
			</IODEF-Document>
	B.3. Spear-Phishing		B.3. Spear Phishing
	The Spear-Phishing test exchanged information that described a Spear-		The spear-phishing test exchanged information that described a spear-
	Phishing email including DNS records and addresses about the sender,		phishing email, including DNS records and addresses about the sender,
	malicious attached file information and email data. The IODEF		malicious attached file information, and email data. The IODEF
	version used for the data representation was based on [RFC7970].		version used for the data representation was based on [RFC7970].
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<IODEF-Document version="2.00"		<IODEF-Document version="2.00"
	xmlns="urn:ietf:params:xml:ns:iodef-2.0"		xmlns="urn:ietf:params:xml:ns:iodef-2.0"
	xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"		xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#">		xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
			<iodef:Incident purpose="reporting">
	<iodef:Incident purpose="reporting">		<iodef:IncidentID name="csirt.example.com">
	<iodef:IncidentID name="csirt.example.com">		189601
	189601		</iodef:IncidentID>
	</iodef:IncidentID>		<iodef:DetectTime>2013-01-04T08:06:12+00:00</iodef:DetectTime>
	<iodef:DetectTime>2013-01-04T08:06:12+00:00</iodef:DetectTime>		<iodef:StartTime>2013-01-04T08:01:34+00:00</iodef:StartTime>
	<iodef:StartTime>2013-01-04T08:01:34+00:00</iodef:StartTime>		<iodef:EndTime>2013-01-04T08:31:27+00:00</iodef:EndTime>
	<iodef:EndTime>2013-01-04T08:31:27+00:00</iodef:EndTime>		<iodef:ReportTime>2013-01-04T09:15:45+00:00</iodef:ReportTime>
	<iodef:ReportTime>2013-01-04T09:15:45+00:00</iodef:ReportTime>		<iodef:GenerationTime>2013-01-04T09:15:45+00:00
	<iodef:GenerationTime>2013-01-04T09:15:45+00:00</iodef:GenerationTime>		</iodef:GenerationTime>
	<iodef:Description>
	Zeus Spear Phishing E-mail with Malware Attachment
	</iodef:Description>
	<iodef:Assessment occurrence="potential">
	<iodef:SystemImpact severity="medium" type="takeover-system">
	<iodef:Description>
	Malware with Command and Control Server and System Changes
	</iodef:Description>
	</iodef:SystemImpact>
	</iodef:Assessment>
	<iodef:Contact role="creator" type="organization">
	<iodef:ContactName>example.com CSIRT</iodef:ContactName>
	<iodef:Email>
	<iodef:EmailTo>contact@csirt.example.com</iodef:EmailTo>
	</iodef:Email>
	</iodef:Contact>
	<iodef:EventData>
	<iodef:Description>		<iodef:Description>
	Targeting Defense Contractors,		Zeus Spear Phishing E-mail with Malware Attachment
	specifically board members attending Dummy Con
	</iodef:Description>		</iodef:Description>
	<iodef:Method>		<iodef:Assessment occurrence="potential">
	<iodef:Reference observable-id="ref-1234">		<iodef:SystemImpact severity="medium" type="takeover-system">
	<iodef:Description>Zeus</iodef:Description>		<iodef:Description>
	</iodef:Reference>		Malware with Command and Control Server and System Changes
	</iodef:Method>		</iodef:Description>
	<iodef:Flow>		</iodef:SystemImpact>
	<iodef:System category="source">		</iodef:Assessment>
	<iodef:Node>		<iodef:Contact role="creator" type="organization">
	<iodef:Address category="site-uri">		<iodef:ContactName>example.com CSIRT</iodef:ContactName>
	http://www.zeusevil.example.com		<iodef:Email>
	</iodef:Address>		<iodef:EmailTo>contact@csirt.example.com</iodef:EmailTo>
	<iodef:Address category="ipv4-addr">		</iodef:Email>
	192.0.2.166		</iodef:Contact>
	</iodef:Address>		<iodef:EventData>
	<iodef:Address category="asn">		<iodef:Description>
	65535		Targeting Defense Contractors,
	</iodef:Address>		specifically board members attending Dummy Con
	<iodef:Address category="ext-value"		</iodef:Description>
	ext-category="as-name">		<iodef:Method>
	EXAMPLE-AS - University of Example"		<iodef:Reference observable-id="ref-1234">
	</iodef:Address>		<iodef:Description>Zeus</iodef:Description>
	<iodef:Address category="ext-value"		</iodef:Reference>
	ext-category="as-prefix">		</iodef:Method>
	192.0.2.0/24		<iodef:Flow>
	</iodef:Address>		<iodef:System category="source">
	</iodef:Node>		<iodef:Node>
	<iodef:NodeRole category="malware-distribution"/>		<iodef:Address category="site-uri">
	</iodef:System>		http://www.zeusevil.example.com
	</iodef:Flow>		</iodef:Address>
	<iodef:Flow>		<iodef:Address category="ipv4-addr">
	<iodef:System category="source">		192.0.2.166
	<iodef:Node>		</iodef:Address>
	<iodef:DomainData>		<iodef:Address category="asn">
	<Name>mail1.evildave.example.com</Name>		65535
	</iodef:DomainData>		</iodef:Address>
	<iodef:Address category="ipv4-addr">		<iodef:Address category="ext-value"
	198.51.100.6		ext-category="as-name">
	</iodef:Address>		EXAMPLE-AS - University of Example"
	<iodef:Address category="asn">		</iodef:Address>
	65534		<iodef:Address category="ext-value"
	</iodef:Address>		ext-category="as-prefix">
	<iodef:Address category="ext-value"		192.0.2.0/24
	ext-category="as-name">		</iodef:Address>
	EXAMPLE-AS - University of Example		</iodef:Node>
	</iodef:Address>		<iodef:NodeRole category="malware-distribution"/>
	<iodef:DomainData>		</iodef:System>
	<iodef:Name>evildave.example.com</iodef:Name>		</iodef:Flow>
	<iodef:DateDomainWasChecked>2013-01-04T09:10:24+00:00		<iodef:Flow>
	</iodef:DateDomainWasChecked>		<iodef:System category="source">
	<!-- <iodef:RelatedDNS RecordType="MX"> -->		<iodef:Node>
	<iodef:RelatedDNS dtype="string">		<iodef:DomainData>
	evildave.example.com MX prefernce = 10, mail exchanger		<Name>mail1.evildave.example.com</Name>
	= mail1.evildave.example.com		</iodef:DomainData>
	</iodef:RelatedDNS>		<iodef:Address category="ipv4-addr">
	<iodef:RelatedDNS dtype="string">		198.51.100.6
	mail1.evildave.example.com		</iodef:Address>
	internet address = 198.51.100.6		<iodef:Address category="asn">
	</iodef:RelatedDNS>		65534
	<iodef:RelatedDNS dtype="string">		</iodef:Address>
	zuesevil.example.com. IN TXT \"v=spf1 a mx -all\"		<iodef:Address category="ext-value"
	</iodef:RelatedDNS>		ext-category="as-name">
	</iodef:DomainData>		EXAMPLE-AS - University of Example
	</iodef:Node>		</iodef:Address>
	<iodef:NodeRole category="mail">		<iodef:DomainData>
	<iodef:Description>		<iodef:Name>evildave.example.com</iodef:Name>
	Sending phishing mails		<iodef:DateDomainWasChecked>2013-01-04T09:10:24+00:00
			</iodef:DateDomainWasChecked>
	</iodef:Description>		<!-- <iodef:RelatedDNS RecordType="MX"> -->
	</iodef:NodeRole>		<iodef:RelatedDNS dtype="string">
	<iodef:Service>		evildave.example.com MX prefernce = 10, mail exchanger
	<iodef:EmailData>		= mail1.evildave.example.com
	<iodef:EmailFrom>		</iodef:RelatedDNS>
	emaildave@evildave.example.com		<iodef:RelatedDNS dtype="string">
	</iodef:EmailFrom>		mail1.evildave.example.com
	<iodef:EmailSubject>		internet address = 198.51.100.6
	Join us at Dummy Con		</iodef:RelatedDNS>
	</iodef:EmailSubject>		<iodef:RelatedDNS dtype="string">
	<iodef:EmailX-Mailer>		zuesevil.example.com. IN TXT \"v=spf1 a mx -all\"
	StormRider 4.0		</iodef:RelatedDNS>
	</iodef:EmailX-Mailer>		</iodef:DomainData>
	</iodef:EmailData>		</iodef:Node>
	</iodef:Service>		<iodef:NodeRole category="mail">
	</iodef:System>		<iodef:Description>
	<iodef:System category="target">		Sending phishing mails
	<iodef:Node>		</iodef:Description>
	<iodef:Address category="ipv4-addr">		</iodef:NodeRole>
	203.0.113.2		<iodef:Service>
	</iodef:Address>		<iodef:EmailData>
	</iodef:Node>		<iodef:EmailFrom>
	</iodef:System>		emaildave@evildave.example.com
	</iodef:Flow>		</iodef:EmailFrom>
	<iodef:Expectation action="other"/>		<iodef:EmailSubject>
	<iodef:Record>		Join us at Dummy Con
	<iodef:RecordData>		</iodef:EmailSubject>
	<iodef:FileData observable-id="fd-1234">		<iodef:EmailX-Mailer>
	<iodef:File>		StormRider 4.0
	<iodef:FileName>		</iodef:EmailX-Mailer>
	Dummy Con Sign Up Sheet.txt		</iodef:EmailData>
	</iodef:FileName>		</iodef:Service>
	<iodef:FileSize>		</iodef:System>
	152		<iodef:System category="target">
	</iodef:FileSize>		<iodef:Node>
	<iodef:HashData scope="file-contents">		<iodef:Address category="ipv4-addr">
	<iodef:Hash>		203.0.113.2
	<ds:DigestMethod		</iodef:Address>
	Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>		</iodef:Node>
	<ds:DigestValue>		</iodef:System>
	141accec23e7e5157de60853cb1e01bc38042d		</iodef:Flow>
	08f9086040815300b7fe75c184		<iodef:Expectation action="other"/>
	</ds:DigestValue>		<iodef:Record>
	</iodef:Hash>		<iodef:RecordData>
	</iodef:HashData>		<iodef:FileData observable-id="fd-1234">
	</iodef:File>		<iodef:File>
	</iodef:FileData>		<iodef:FileName>
	</iodef:RecordData>		Dummy Con Sign Up Sheet.txt
	<iodef:RecordData>		</iodef:FileName>
	<iodef:CertificateData>		<iodef:FileSize>
	<iodef:Certificate>		152
	<ds:X509Data>		</iodef:FileSize>
	<ds:X509IssuerSerial>		<iodef:HashData scope="file-contents">
	<ds:X509IssuerName>FakeCA		<iodef:Hash>
	</ds:X509IssuerName>		<ds:DigestMethod
	<ds:X509SerialNumber>		Algorithm="http://www.w3.org/2001/04/
	57482937101		xmlenc#sha256"/>
	</ds:X509SerialNumber>		<ds:DigestValue>
	</ds:X509IssuerSerial>		141accec23e7e5157de60853cb1e01bc38042d
	<ds:X509SubjectName>EvilDaveExample		08f9086040815300b7fe75c184
	</ds:X509SubjectName>		</ds:DigestValue>
	</ds:X509Data>		</iodef:Hash>
	</iodef:Certificate>		</iodef:HashData>
	</iodef:CertificateData>		</iodef:File>
	</iodef:RecordData>		</iodef:FileData>
	</iodef:Record>		</iodef:RecordData>
	</iodef:EventData>		<iodef:RecordData>
	</iodef:Incident>		<iodef:CertificateData>
	</IODEF-Document>		<iodef:Certificate>
			<ds:X509Data>
			<ds:X509IssuerSerial>
			<ds:X509IssuerName>FakeCA
			</ds:X509IssuerName>
			<ds:X509SerialNumber>
			57482937101
			</ds:X509SerialNumber>
			</ds:X509IssuerSerial>
			<ds:X509SubjectName>EvilDaveExample
			</ds:X509SubjectName>
			</ds:X509Data>
			</iodef:Certificate>
			</iodef:CertificateData>
			</iodef:RecordData>
			</iodef:Record>
			</iodef:EventData>
			</iodef:Incident>
			</IODEF-Document>
	B.4. Malware		B.4. Malware
	In this test, malware information was exchanged using RID and IODEF.		In this test, malware information was exchanged using RID and IODEF.
	The information included file hashes, registry setting changes and		The information included file hashes, registry setting changes, and
	the C&C servers the malware uses.		the C&C servers the malware uses.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<IODEF-Document version="2.00"		<IODEF-Document version="2.00"
	xmlns="urn:ietf:params:xml:ns:iodef-2.0"		xmlns="urn:ietf:params:xml:ns:iodef-2.0"
	xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"		xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#">		xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
	<iodef:Incident purpose="reporting">		<iodef:Incident purpose="reporting">
	<iodef:IncidentID name="csirt.example.com">		<iodef:IncidentID name="csirt.example.com">
	189234		189234
	</iodef:IncidentID>		</iodef:IncidentID>
	<iodef:ReportTime>2013-03-07T16:14:56.757+05:30</iodef:ReportTime>		<iodef:ReportTime>2013-03-07T16:14:56.757+05:30</iodef:ReportTime>
	<iodef:GenerationTime>2013-03-07T16:14:56.757+05:30</iodef:GenerationTime>		<iodef:GenerationTime>2013-03-07T16:14:56.757+05:30
			</iodef:GenerationTime>
	<iodef:Description>		<iodef:Description>
	Malware and related indicators identified		Malware and related indicators identified
	</iodef:Description>		</iodef:Description>
	<iodef:Assessment occurrence="potential">		<iodef:Assessment occurrence="potential">
	<iodef:SystemImpact severity="medium" type="breach-proprietary">		<iodef:SystemImpact severity="medium" type="breach-proprietary">
	<iodef:Description>		<iodef:Description>
	Malware with Command and Control Server and System Changes		Malware with Command and Control Server and System Changes
	</iodef:Description>		</iodef:Description>
	</iodef:SystemImpact>		</iodef:SystemImpact>
	</iodef:Assessment>		</iodef:Assessment>
	<iodef:Contact role="creator" type="organization">		<iodef:Contact role="creator" type="organization">
	<iodef:ContactName>example.com CSIRT</iodef:ContactName>		<iodef:ContactName>example.com CSIRT</iodef:ContactName>
	<iodef:Email>		<iodef:Email>
	<iodef:EmailTo>contact@csirt.example.com</iodef:EmailTo>		<iodef:EmailTo>contact@csirt.example.com</iodef:EmailTo>
	</iodef:Email>		</iodef:Email>
	</iodef:Contact>		</iodef:Contact>
	<iodef:EventData>		<iodef:EventData>
	<iodef:Method>		<iodef:Method>
	skipping to change at page 25, line 26		skipping to change at page 25, line 34
	<iodef:URL>		<iodef:URL>
	http://www.threatexpert.example.com/report.aspx?		http://www.threatexpert.example.com/report.aspx?
	md5=e2710ceb088dacdcb03678db250742b7		md5=e2710ceb088dacdcb03678db250742b7
	</iodef:URL>		</iodef:URL>
	<iodef:Description>Zeus</iodef:Description>		<iodef:Description>Zeus</iodef:Description>
	</iodef:Reference>		</iodef:Reference>
	</iodef:Method>		</iodef:Method>
	<iodef:Flow>		<iodef:Flow>
	<iodef:System category="source">		<iodef:System category="source">
	<iodef:Node>		<iodef:Node>
	<iodef:Address category="ipv4-addr" observable-id="addr-c2-91011-001">		<iodef:Address category="ipv4-addr"
			observable-id="addr-c2-91011-001">
	203.0.113.200		203.0.113.200
	</iodef:Address>		</iodef:Address>
	<iodef:Address category="site-uri" observable-id="addr-c2-91011-002">		<iodef:Address category="site-uri"
			observable-id="addr-c2-91011-002">
	http://zeus.556677889900.example.com/log-bin/		http://zeus.556677889900.example.com/log-bin/
	lunch_install.php?aff_id=1&amp;amp;		lunch_install.php?aff_id=1&amp;amp;
	lunch_id=1&amp;amp;maddr=&amp;amp;		lunch_id=1&amp;amp;maddr=&amp;amp;
	action=install		action=install
	</iodef:Address>		</iodef:Address>
	</iodef:Node>		</iodef:Node>
	<iodef:NodeRole category="c2-server"/>		<iodef:NodeRole category="c2-server"/>
	</iodef:System>		</iodef:System>
	</iodef:Flow>		</iodef:Flow>
	<iodef:Record>		<iodef:Record>
	<iodef:RecordData>		<iodef:RecordData>
	<iodef:FileData observable-id="file-91011-001">		<iodef:FileData observable-id="file-91011-001">
	<iodef:File>		<iodef:File>
	<iodef:HashData scope="file-contents">		<iodef:HashData scope="file-contents">
	<iodef:Hash>		<iodef:Hash>
	<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha1"/>		<ds:DigestMethod Algorithm=
			"http://www.w3.org/2001/04/xmlenc#sha1"/>
	<ds:DigestValue>		<ds:DigestValue>
	MHg2NzUxQTI1MzQ4M0E2N0Q4NkUwRjg0NzYwRjYxRjEwQkJDQzJFREZG		MHg2NzUxQTI1MzQ4M0E2N0Q4NkUwRjg0NzYwRjYxRjEwQkJDQzJF
			REZG
	</ds:DigestValue>		</ds:DigestValue>
	</iodef:Hash>		</iodef:Hash>
	</iodef:HashData>		</iodef:HashData>
	</iodef:File>		</iodef:File>
	<iodef:File>		<iodef:File>
	<iodef:HashData scope="file-contents">		<iodef:HashData scope="file-contents">
	<iodef:Hash>		<iodef:Hash>
	<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#md5"/>		<ds:DigestMethod Algorithm=
			"http://www.w3.org/2001/04/xmlenc#md5"/>
	<ds:DigestValue>		<ds:DigestValue>
	MHgyRTg4ODA5ODBENjI0NDdFOTc5MEFGQTg5NTEzRjBBNA==		MHgyRTg4ODA5ODBENjI0NDdFOTc5MEFGQTg5NTEzRjBBNA==
	</ds:DigestValue>		</ds:DigestValue>
	</iodef:Hash>		</iodef:Hash>
	</iodef:HashData>		</iodef:HashData>
	</iodef:File>		</iodef:File>
	</iodef:FileData>		</iodef:FileData>
	<iodef:WindowsRegistryKeysModified observable-id="regkey-91011-001">		<iodef:WindowsRegistryKeysModified observable-id=
			"regkey-91011-001">
	<iodef:Key registryaction="add-value">		<iodef:Key registryaction="add-value">
	<iodef:KeyName>		<iodef:KeyName>
	HKLM\Software\Microsoft\Windows\		HKLM\Software\Microsoft\Windows\
	CurrentVersion\Run\tamg		CurrentVersion\Run\tamg
	</iodef:KeyName>		</iodef:KeyName>
	<iodef:Value>		<iodef:Value>
	?\?\?%System%\wins\mc.exe\?\??		?\?\?%System%\wins\mc.exe\?\??
	</iodef:Value>		</iodef:Value>
	</iodef:Key>		</iodef:Key>
	<iodef:Key registryaction="modify-value">		<iodef:Key registryaction="modify-value">
	skipping to change at page 26, line 49		skipping to change at page 27, line 16
	<iodef:URL>		<iodef:URL>
	http://www.threatexpert.example.com/report.aspx?		http://www.threatexpert.example.com/report.aspx?
	md5=c3c528c939f9b176c883ae0ce5df0001		md5=c3c528c939f9b176c883ae0ce5df0001
	</iodef:URL>		</iodef:URL>
	<iodef:Description>Cridex</iodef:Description>		<iodef:Description>Cridex</iodef:Description>
	</iodef:Reference>		</iodef:Reference>
	</iodef:Method>		</iodef:Method>
	<iodef:Flow>		<iodef:Flow>
	<iodef:System category="source">		<iodef:System category="source">
	<iodef:Node>		<iodef:Node>
	<iodef:Address category="ipv4-addr" observable-id="addr-c2-91011-003">		<iodef:Address category="ipv4-addr"
			observable-id="addr-c2-91011-003">
	203.0.113.100		203.0.113.100
	</iodef:Address>		</iodef:Address>
	</iodef:Node>		</iodef:Node>
	<iodef:NodeRole category="c2-server"/>		<iodef:NodeRole category="c2-server"/>
	<iodef:Service ip-protocol="6">		<iodef:Service ip-protocol="6">
	<iodef:Port>8080</iodef:Port>		<iodef:Port>8080</iodef:Port>
	</iodef:Service>		</iodef:Service>
	</iodef:System>		</iodef:System>
	</iodef:Flow>		</iodef:Flow>
	<iodef:Record>		<iodef:Record>
	<iodef:RecordData>		<iodef:RecordData>
	<iodef:FileData observable-id="file-91011-002">		<iodef:FileData observable-id="file-91011-002">
	skipping to change at page 27, line 18		skipping to change at page 27, line 33
	<iodef:Port>8080</iodef:Port>		<iodef:Port>8080</iodef:Port>
	</iodef:Service>		</iodef:Service>
	</iodef:System>		</iodef:System>
	</iodef:Flow>		</iodef:Flow>
	<iodef:Record>		<iodef:Record>
	<iodef:RecordData>		<iodef:RecordData>
	<iodef:FileData observable-id="file-91011-002">		<iodef:FileData observable-id="file-91011-002">
	<iodef:File>		<iodef:File>
	<iodef:HashData scope="file-contents">		<iodef:HashData scope="file-contents">
	<iodef:Hash>		<iodef:Hash>
	<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha1"/>		<ds:DigestMethod Algorithm=
			"http://www.w3.org/2001/04/xmlenc#sha1"/>
	<ds:DigestValue>		<ds:DigestValue>
	MHg3MjYzRkUwRDNBMDk1RDU5QzhFMEM4OTVBOUM1ODVFMzQzRTcxNDFD		MHg3MjYzRkUwRDNBMDk1RDU5QzhFMEM4OTVBOUM
			1ODVFMzQzRTcxNDFD
	</ds:DigestValue>		</ds:DigestValue>
	</iodef:Hash>		</iodef:Hash>
	</iodef:HashData>		</iodef:HashData>
	</iodef:File>		</iodef:File>
	</iodef:FileData>		</iodef:FileData>
	<iodef:FileData observable-id="file-91011-003">		<iodef:FileData observable-id="file-91011-003">
	<iodef:File>		<iodef:File>
	<iodef:HashData scope="file-contents">		<iodef:HashData scope="file-contents">
	<iodef:Hash>		<iodef:Hash>
	<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#md5"/>		<ds:DigestMethod Algorithm=
			"http://www.w3.org/2001/04/xmlenc#md5"/>
	<ds:DigestValue>		<ds:DigestValue>
	MHg0M0NEODUwRkNEQURFNDMzMEE1QkVBNkYxNkVFOTcxQw==		MHg0M0NEODUwRkNEQURFNDMzMEE1QkVBNkYxNkVFOTcxQw==
	</ds:DigestValue>		</ds:DigestValue>
	</iodef:Hash>		</iodef:Hash>
	</iodef:HashData>		</iodef:HashData>
	</iodef:File>		</iodef:File>
	</iodef:FileData>		</iodef:FileData>
	<iodef:WindowsRegistryKeysModified observable-id="regkey-91011-002">		<iodef:WindowsRegistryKeysModified observable-id=
			"regkey-91011-002">
	<iodef:Key registryaction="add-value">		<iodef:Key registryaction="add-value">
	<iodef:KeyName>		<iodef:KeyName>
	HKLM\Software\Microsoft\Windows\		HKLM\Software\Microsoft\Windows\
	CurrentVersion\Run\KB00121600.exe		CurrentVersion\Run\KB00121600.exe
	</iodef:KeyName>		</iodef:KeyName>
	<iodef:Value>		<iodef:Value>
	\?\?%AppData%\KB00121600.exe\?\?		\?\?%AppData%\KB00121600.exe\?\?
	</iodef:Value>		</iodef:Value>
	</iodef:Key>		</iodef:Key>
	</iodef:WindowsRegistryKeysModified>		</iodef:WindowsRegistryKeysModified>
	skipping to change at page 28, line 14		skipping to change at page 28, line 35
	<iodef:Indicator>		<iodef:Indicator>
	<iodef:IndicatorID name="csirt.example.com" version="1">		<iodef:IndicatorID name="csirt.example.com" version="1">
	ind-91011		ind-91011
	</iodef:IndicatorID>		</iodef:IndicatorID>
	<iodef:Description>		<iodef:Description>
	evil c2 server, file hash, and registry key		evil c2 server, file hash, and registry key
	</iodef:Description>		</iodef:Description>
	<iodef:IndicatorExpression operator="or">		<iodef:IndicatorExpression operator="or">
	<iodef:IndicatorExpression operator="or">		<iodef:IndicatorExpression operator="or">
	<iodef:Observable>		<iodef:Observable>
	<iodef:Address category="site-uri" observable-id="addr-qrst">		<iodef:Address category="site-uri"
			observable-id="addr-qrst">
	http://foo.example.com:12345/evil/cc.php		http://foo.example.com:12345/evil/cc.php
	</iodef:Address>		</iodef:Address>
	</iodef:Observable>		</iodef:Observable>
	<iodef:Observable>		<iodef:Observable>
	<iodef:Address category="ipv4-addr" observable-id="addr-stuv">		<iodef:Address category="ipv4-addr"
			observable-id="addr-stuv">
	192.0.2.1		192.0.2.1
	</iodef:Address>		</iodef:Address>
	</iodef:Observable>		</iodef:Observable>
	<iodef:Observable>		<iodef:Observable>
	<iodef:Address category="ipv4-addr" observable-id="addr-tuvw">		<iodef:Address category="ipv4-addr"
			observable-id="addr-tuvw">
	198.51.100.1		198.51.100.1
	</iodef:Address>		</iodef:Address>
	</iodef:Observable>		</iodef:Observable>
	<iodef:Observable>		<iodef:Observable>
	<iodef:Address category="ipv6-addr" observable-id="addr-uvwx">		<iodef:Address category="ipv6-addr"
			observable-id="addr-uvwx">
	2001:db8:dead:beef::1		2001:db8:dead:beef::1
	</iodef:Address>		</iodef:Address>
	</iodef:Observable>		</iodef:Observable>
	<iodef:ObservableReference uid-ref="addr-c2-91011-001"/>		<iodef:ObservableReference uid-ref="addr-c2-91011-001"/>
	<iodef:ObservableReference uid-ref="addr-c2-91011-002"/>		<iodef:ObservableReference uid-ref="addr-c2-91011-002"/>
	<iodef:ObservableReference uid-ref="addr-c2-91011-003"/>		<iodef:ObservableReference uid-ref="addr-c2-91011-003"/>
	</iodef:IndicatorExpression>		</iodef:IndicatorExpression>
	<iodef:IndicatorExpression operator="and">		<iodef:IndicatorExpression operator="and">
	<iodef:Observable>		<iodef:Observable>
	<iodef:FileData observable-id="file-91011-000">		<iodef:FileData observable-id="file-91011-000">
	<iodef:File>		<iodef:File>
	<iodef:HashData scope="file-contents">		<iodef:HashData scope="file-contents">
	<iodef:Hash>		<iodef:Hash>
	<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>		<ds:DigestMethod Algorithm=
			"http://www.w3.org/2001/04/xmlenc#sha256"/>
	<ds:DigestValue>		<ds:DigestValue>
	141accec23e7e5157de60853cb1e01bc38042d08f9086040815300b7fe75c184		141accec23e7e5157de60853cb1e01bc38042d08f
			9086040815300b7fe75c184
	</ds:DigestValue>		</ds:DigestValue>
	</iodef:Hash>		</iodef:Hash>
	</iodef:HashData>		</iodef:HashData>
	</iodef:File>		</iodef:File>
	</iodef:FileData>		</iodef:FileData>
	</iodef:Observable>		</iodef:Observable>
	<iodef:Observable>		<iodef:Observable>
	<iodef:WindowsRegistryKeysModified observable-id="regkey-91011-000">		<iodef:WindowsRegistryKeysModified observable-id=
			"regkey-91011-000">
	<iodef:Key registryaction="add-key"		<iodef:Key registryaction="add-key"
	observable-id="regkey-vwxy">		observable-id="regkey-vwxy">
	<iodef:KeyName>		<iodef:KeyName>
	HKLM\SYSTEM\CurrentControlSet\		HKLM\SYSTEM\CurrentControlSet\
	Services\.Net CLR		Services\.Net CLR
	</iodef:KeyName>		</iodef:KeyName>
	</iodef:Key>		</iodef:Key>
	<iodef:Key registryaction="add-key"		<iodef:Key registryaction="add-key"
	observable-id="regkey-wxyz">		observable-id="regkey-wxyz">
	<iodef:KeyName>		<iodef:KeyName>
	skipping to change at page 30, line 15		skipping to change at page 30, line 43
	</iodef:IndicatorExpression>		</iodef:IndicatorExpression>
	</iodef:IndicatorExpression>		</iodef:IndicatorExpression>
	</iodef:IndicatorExpression>		</iodef:IndicatorExpression>
	</iodef:Indicator>		</iodef:Indicator>
	</iodef:IndicatorData>		</iodef:IndicatorData>
	</iodef:Incident>		</iodef:Incident>
	</IODEF-Document>		</IODEF-Document>
	B.5. IoT Malware		B.5. IoT Malware
	The IoT Malware test exchanged information that described a bad IP		The Internet of Things (IoT) malware test exchanged information that
	address of IoT malware and its scanned ports. This example		described a bad IP address of IoT malware and its scanned ports.
	information is extracted from alert messages of a Darknet monitoring		This example information is extracted from alert messages of a
	system referred in [RFC8134]. The IODEF version used for the data		darknet monitoring system referred to in [RFC8134]. The IODEF
	representation was based on [RFC7970].		version used for the data representation was based on [RFC7970].
	<?xml version="1.0" encoding="UTF-8"?>
	<IODEF-Document version="2.00"
	xmlns="urn:ietf:params:xml:ns:iodef-2.0"
	xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<iodef:Incident purpose="reporting">
	<iodef:IncidentID name="csirt.example.com">
	189802
	</iodef:IncidentID>
	<iodef:ReportTime>2017-03-01T01:15:00+09:00</iodef:ReportTime>
	<iodef:GenerationTime>2017-03-01T01:15:00+09:00</iodef:GenerationTime>
	<iodef:Description>IoT Malware and related indicators</iodef:Description>
	<iodef:Assessment occurrence="potential">
	<iodef:SystemImpact severity="medium" type="takeover-system">
	<iodef:Description>IoT Malware is scanning other hosts
	</iodef:Description>
	</iodef:SystemImpact>
	</iodef:Assessment>
	<iodef:Contact role="creator" type="organization">
	<iodef:ContactName>example.com CSIRT
	</iodef:ContactName>
	<iodef:Email>
	<iodef:EmailTo>contact@csirt.example.com
	</iodef:EmailTo>
	</iodef:Email>
	</iodef:Contact>
	<iodef:EventData>
	<iodef:Discovery source="nidps">
	<iodef:Description>
	Detected by darknet monitoring
	</iodef:Description>
	</iodef:Discovery>		<?xml version="1.0" encoding="UTF-8"?>
	<iodef:Flow>		<IODEF-Document version="2.00"
	<iodef:System category="source">		xmlns="urn:ietf:params:xml:ns:iodef-2.0"
	<iodef:Node>		xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"
	<iodef:Address category="ipv4-addr">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	192.0.2.210		<iodef:Incident purpose="reporting">
	</iodef:Address>		<iodef:IncidentID name="csirt.example.com">
	</iodef:Node>		189802
	<iodef:NodeRole category="camera"/>		</iodef:IncidentID>
	<iodef:Service ip-protocol="6">		<iodef:ReportTime>2017-03-01T01:15:00+09:00</iodef:ReportTime>
	<iodef:Port>23</iodef:Port>		<iodef:GenerationTime>2017-03-01T01:15:00+09:00
	</iodef:Service>		</iodef:GenerationTime>
	<iodef:OperatingSystem>		<iodef:Description>IoT Malware and related indicators
	<iodef:Description>		</iodef:Description>
	Example Surveillance Camera OS 2.1.1		<iodef:Assessment occurrence="potential">
	</iodef:Description>		<iodef:SystemImpact severity="medium" type="takeover-system">
	</iodef:OperatingSystem>		<iodef:Description>IoT Malware is scanning other hosts
	</iodef:System>		</iodef:Description>
	</iodef:Flow>		</iodef:SystemImpact>
	<iodef:EventData>		</iodef:Assessment>
	<iodef:Flow>		<iodef:Contact role="creator" type="organization">
	<iodef:System category="target">		<iodef:ContactName>example.com CSIRT
	<iodef:Node>		</iodef:ContactName>
	<iodef:Address category="ipv4-addr">		<iodef:Email>
	198.51.100.1		<iodef:EmailTo>contact@csirt.example.com
	</iodef:Address>		</iodef:EmailTo>
	</iodef:Node>		</iodef:Email>
	<iodef:NodeRole category="honeypot"/>		</iodef:Contact>
	<iodef:Service ip-protocol="6">
	<iodef:Port>23</iodef:Port>
	</iodef:Service>
	</iodef:System>
	</iodef:Flow>
	</iodef:EventData>
	<iodef:EventData>		<iodef:EventData>
			<iodef:Discovery source="nidps">
			<iodef:Description>
			Detected by darknet monitoring
			</iodef:Description>
			</iodef:Discovery>
	<iodef:Flow>		<iodef:Flow>
	<iodef:System category="target">		<iodef:System category="source">
	<iodef:Node>		<iodef:Node>
	<iodef:Address category="ipv4-addr">		<iodef:Address category="ipv4-addr">
	198.51.100.94		192.0.2.210
	</iodef:Address>		</iodef:Address>
	</iodef:Node>		</iodef:Node>
	<iodef:NodeRole category="honeypot"/>		<iodef:NodeRole category="camera"/>
	<iodef:Service ip-protocol="6">		<iodef:Service ip-protocol="6">
	<iodef:Port>23</iodef:Port>		<iodef:Port>23</iodef:Port>
	</iodef:Service>		</iodef:Service>
			<iodef:OperatingSystem>
			<iodef:Description>
			Example Surveillance Camera OS 2.1.1
			</iodef:Description>
			</iodef:OperatingSystem>
	</iodef:System>		</iodef:System>
	</iodef:Flow>		</iodef:Flow>
			<iodef:EventData>
	</iodef:EventData>		<iodef:Flow>
	<iodef:EventData>		<iodef:System category="target">
	<iodef:Flow>		<iodef:Node>
	<iodef:System category="target">		<iodef:Address category="ipv4-addr">
	<iodef:Node>		198.51.100.1
	<iodef:Address category="ipv4-addr">		</iodef:Address>
	198.51.100.237		</iodef:Node>
	</iodef:Address>		<iodef:NodeRole category="honeypot"/>
	</iodef:Node>		<iodef:Service ip-protocol="6">
	<iodef:NodeRole category="honeypot"/>		<iodef:Port>23</iodef:Port>
	<iodef:Service ip-protocol="6">		</iodef:Service>
	<iodef:Port>2323</iodef:Port>		</iodef:System>
	</iodef:Service>		</iodef:Flow>
	</iodef:System>		</iodef:EventData>
	</iodef:Flow>		<iodef:EventData>
			<iodef:Flow>
			<iodef:System category="target">
			<iodef:Node>
			<iodef:Address category="ipv4-addr">
			198.51.100.94
			</iodef:Address>
			</iodef:Node>
			<iodef:NodeRole category="honeypot"/>
			<iodef:Service ip-protocol="6">
			<iodef:Port>23</iodef:Port>
			</iodef:Service>
			</iodef:System>
			</iodef:Flow>
			</iodef:EventData>
			<iodef:EventData>
			<iodef:Flow>
			<iodef:System category="target">
			<iodef:Node>
			<iodef:Address category="ipv4-addr">
			198.51.100.237
			</iodef:Address>
			</iodef:Node>
			<iodef:NodeRole category="honeypot"/>
			<iodef:Service ip-protocol="6">
			<iodef:Port>2323</iodef:Port>
			</iodef:Service>
			</iodef:System>
			</iodef:Flow>
			</iodef:EventData>
	</iodef:EventData>		</iodef:EventData>
	</iodef:EventData>		</iodef:Incident>
	</iodef:Incident>		</IODEF-Document>
	</IODEF-Document>
	Authors' Addresses		Authors' Addresses
	Panos Kampanakis		Panos Kampanakis
	Cisco Systems		Cisco Systems
	Email: pkampana@cisco.com		Email: pkampana@cisco.com
	Mio Suzuki		Mio Suzuki
	NICT		NICT
	4-2-1, Nukui-Kitamachi		4-2-1, Nukui-Kitamachi
	Koganei, Tokyo 184-8795		Koganei, Tokyo 184-8795
	JP		Japan
	Email: mio@nict.go.jp		Email: mio@nict.go.jp
End of changes. 153 change blocks.
	684 lines changed or deleted		712 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/