draft-ietf-mile-rfc6045-bis-04.txt   draft-ietf-mile-rfc6045-bis-05.txt 
MILE Working Group K. Moriarty MILE Working Group K. Moriarty
Internet-Draft EMC Internet-Draft EMC
Obsoletes: 6045 (if approved) December 15, 2011 Obsoletes: 6045 (if approved) January 1, 2012
Intended status: Standards Track Intended status: Standards Track
Expires: June 17, 2012 Expires: July 4, 2012
Real-time Inter-network Defense (RID) Real-time Inter-network Defense (RID)
draft-ietf-mile-rfc6045-bis-04.txt draft-ietf-mile-rfc6045-bis-05.txt
Abstract Abstract
Security incidents, such as system compromises, worms, viruses, Security incidents, such as system compromises, worms, viruses,
phishing incidents, and denial of service, typically result in the phishing incidents, and denial of service, typically result in the
loss of service, data, and resources both human and system. Service loss of service, data, and resources both human and system. Service
providers and Computer Security Incident Response Teams need to be providers and Computer Security Incident Response Teams need to be
equipped and ready to assist in communicating and tracing security equipped and ready to assist in communicating and tracing security
incidents with tools and procedures in place before the occurrence of incidents with tools and procedures in place before the occurrence of
an attack. Real-time Inter-network Defense (RID) outlines a an attack. Real-time Inter-network Defense (RID) outlines a
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 17, 2012. This Internet-Draft will expire on July 4, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Normative and Informative . . . . . . . . . . . . . . . . 6 1.1. Normative and Informative . . . . . . . . . . . . . . . . 6
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Characteristics of Incidents . . . . . . . . . . . . . . . . . 7 2. Characteristics of Incidents . . . . . . . . . . . . . . . . . 7
3. Communication between CSIRTs and Service Providers . . . . . . 8 3. Communication between CSIRTs and Service Providers . . . . . . 8
3.1. Inter-network Provider RID Messaging . . . . . . . . . . . 10 3.1. Inter-network Provider RID Messaging . . . . . . . . . . . 10
3.2. RID Communication Topology . . . . . . . . . . . . . . . . 12 3.2. RID Communication Topology . . . . . . . . . . . . . . . . 12
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. RID Data Types . . . . . . . . . . . . . . . . . . . . . . 13 4.1. RID Data Types . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. RID Message Types . . . . . . . . . . . . . . . . . . . . 14 4.2. RID Message Types . . . . . . . . . . . . . . . . . . . . 13
5. IODEF-RID Schema . . . . . . . . . . . . . . . . . . . . . . . 15 5. IODEF-RID Schema . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. RIDPolicy Class . . . . . . . . . . . . . . . . . . . . . 17 5.1. RIDPolicy Class . . . . . . . . . . . . . . . . . . . . . 17
5.2. RequestStatus . . . . . . . . . . . . . . . . . . . . . . 23 5.1.1. ReportSchema . . . . . . . . . . . . . . . . . . . . . 23
5.3. IncidentSource . . . . . . . . . . . . . . . . . . . . . . 25 5.2. RequestStatus . . . . . . . . . . . . . . . . . . . . . . 25
5.4. RID Name Spaces . . . . . . . . . . . . . . . . . . . . . 26 5.3. IncidentSource . . . . . . . . . . . . . . . . . . . . . . 27
6. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4. RID Name Spaces . . . . . . . . . . . . . . . . . . . . . 28
6.1. TraceRequest . . . . . . . . . . . . . . . . . . . . . . . 26 5.5. Including IODEF or other XML Documents . . . . . . . . . . 28
6.2. RequestAuthorization . . . . . . . . . . . . . . . . . . . 28 6. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. TraceRequest . . . . . . . . . . . . . . . . . . . . . . . 29
6.4. Investigation Request . . . . . . . . . . . . . . . . . . 31 6.2. RequestAuthorization . . . . . . . . . . . . . . . . . . . 31
6.5. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.6. IncidentQuery . . . . . . . . . . . . . . . . . . . . . . 34 6.4. Investigation Request . . . . . . . . . . . . . . . . . . 34
7. RID Communication Exchanges . . . . . . . . . . . . . . . . . 35 6.5. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1. Upstream Trace Communication Flow . . . . . . . . . . . . 35 6.6. IncidentQuery . . . . . . . . . . . . . . . . . . . . . . 37
7.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 37 7. RID Communication Exchanges . . . . . . . . . . . . . . . . . 38
7.1.2. RequestAuthorization Message Example . . . . . . . . . 41 7.1. Upstream Trace Communication Flow . . . . . . . . . . . . 38
7.1.3. Result Message Example . . . . . . . . . . . . . . . . 42 7.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 40
7.2. Investigation Request Communication Flow . . . . . . . . . 45 7.1.2. RequestAuthorization Message Example . . . . . . . . . 45
7.2.1. Investigation Request Example . . . . . . . . . . . . 46 7.1.3. Result Message Example . . . . . . . . . . . . . . . . 45
7.2.2. RequestAuthorization Message Example . . . . . . . . . 48 7.2. Investigation Request Communication Flow . . . . . . . . . 48
7.3. Report Communication Flow . . . . . . . . . . . . . . . . 48 7.2.1. Investigation Request Example . . . . . . . . . . . . 49
7.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 49 7.2.2. RequestAuthorization Message Example . . . . . . . . . 51
7.4. IncidentQuery Communication Flow . . . . . . . . . . . . . 51 7.3. Report Communication Flow . . . . . . . . . . . . . . . . 52
7.4.1. IncidentQuery Example . . . . . . . . . . . . . . . . 51 7.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 52
8. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 52 7.4. IncidentQuery Communication Flow . . . . . . . . . . . . . 54
9. Security Requirements . . . . . . . . . . . . . . . . . . . . 56 7.4.1. IncidentQuery Example . . . . . . . . . . . . . . . . 55
9.1. XML Digital Signatures and Encryption . . . . . . . . . . 56 8. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 56
9.2. Message Transport . . . . . . . . . . . . . . . . . . . . 59 9. Security Requirements . . . . . . . . . . . . . . . . . . . . 60
9.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 61 9.1. XML Digital Signatures and Encryption . . . . . . . . . . 60
9.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 61 9.2. Message Transport . . . . . . . . . . . . . . . . . . . . 64
9.3.2. Multi-Hop TraceRequest Authentication . . . . . . . . 62 9.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 65
9.4. Consortiums and Public Key Infrastructures . . . . . . . . 63 9.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 65
9.5. Privacy Concerns and System Use Guidelines . . . . . . . . 64 9.3.2. Multi-Hop TraceRequest Authentication . . . . . . . . 66
10. Security Considerations . . . . . . . . . . . . . . . . . . . 68 9.4. Consortiums and Public Key Infrastructures . . . . . . . . 67
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 9.5. Privacy Concerns and System Use Guidelines . . . . . . . . 68
12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 73
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73
13.1. Normative References . . . . . . . . . . . . . . . . . . . 70 12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.2. Informative References . . . . . . . . . . . . . . . . . . 72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 72 13.1. Normative References . . . . . . . . . . . . . . . . . . . 75
13.2. Informative References . . . . . . . . . . . . . . . . . . 76
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77
1. Introduction 1. Introduction
This document moves Real-time Inter-network Defense (RID) [RFC6045] This document moves Real-time Inter-network Defense (RID) [RFC6045]
to Historic status as it provides minor updates. Organizations to Historic status as it provides minor updates. Organizations
require help from other parties to identify incidents, mitigate require help from other parties to identify incidents, mitigate
malicious activity targeting their computing resources, and to gain malicious activity targeting their computing resources, and to gain
insight into potential threats through the sharing of information. insight into potential threats through the sharing of information.
This coordination might entail working with a service provider (SP) This coordination might entail working with a service provider (SP)
to filter attack traffic, working with a SP to resolve a to filter attack traffic, working with a SP to resolve a
skipping to change at page 6, line 14 skipping to change at page 6, line 14
* 2. RID Integration with Network Provider Technologies, * 2. RID Integration with Network Provider Technologies,
* 3.1. Integrating Trace Approaches, and * 3.1. Integrating Trace Approaches, and
* 3.2. Superset of Packet Information for Traces. * 3.2. Superset of Packet Information for Traces.
o An option for a star topology has been included in an o An option for a star topology has been included in an
informational section to meet current use case requirements of informational section to meet current use case requirements of
those who provide reports on incident information. those who provide reports on incident information.
o The schema version was incremented. The schema remains the same o The schema version was incremented. The schema has updates that
with the exception updates for reported errata and an additional include IODEF [RFC5070] enveloped in RID via the ReportSchema
enumeration in the RIDPolicy class for 'LawEnforcement'. class contained in the RIDPolicy class, updates for reported
Additional text has been provided to clarify definitions of errata, and an additional enumeration in the RIDPolicy class for
enumerated values for some attributes. 'LawEnforcement'. Additional text has been provided to clarify
definitions of enumerated values for some attributes.
o Guidance has improved to ensure consistent implementations and use o Guidance has improved to ensure consistent implementations and use
of XML encryption to provide confidentiality based on data of XML encryption to provide confidentiality based on data
markers, specifically the iodef:restriction attribute in the IODEF markers, specifically the iodef:restriction attribute in the IODEF
and IODEF-RID schemas. The attribute may also be present in IODEF and IODEF-RID schemas. The attribute may also be present in IODEF
extension schemas, where the guidance also applies. extension schemas, where the guidance also applies.
o All of the normative text from the Security Considerations Section o All of the normative text from the Security Considerations Section
has been moved to a new Section, Security Requirements. has been moved to a new Section, Security Requirements.
skipping to change at page 6, line 42 skipping to change at page 6, line 43
o Additional text has been provided to explain the content and o Additional text has been provided to explain the content and
interactions between entities in the examples. interactions between entities in the examples.
1.1. Normative and Informative 1.1. Normative and Informative
Section 1, 2, 3, and 12 provide helpful background information and Section 1, 2, 3, and 12 provide helpful background information and
considerations. RID systems participating in a consortium are considerations. RID systems participating in a consortium are
REQUIRED to fully implement sections 4, 5, 6, 7, 8, 9, 10, and 11 to REQUIRED to fully implement sections 4, 5, 6, 7, 8, 9, 10, and 11 to
prevent interoperability concerns. prevent interoperability concerns.
The XML schema [XMLschema] and transport requirements contained in
this document are normative; all other information provided is
intended as informative. More specifically, the following sections
of this document are intended as informative: Sections 2, 3, 10, and
13.2. The following sections of this document are normative:
Sections 1, 4, 5, 6, 7, 8, 10, 11, 12, and 13.1.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Characteristics of Incidents 2. Characteristics of Incidents
The goal of tracing a security incident may be to identify the source The goal of tracing a security incident may be to identify the source
or to find a point on the network as close to the origin of the or to find a point on the network as close to the origin of the
skipping to change at page 17, line 9 skipping to change at page 17, line 9
the transport protocol [RFC6046-bis], as that information should be the transport protocol [RFC6046-bis], as that information should be
as small as possible and may not be encrypted. The RequestStatus as small as possible and may not be encrypted. The RequestStatus
message MUST be able to stand alone without the need for an IODEF message MUST be able to stand alone without the need for an IODEF
document to facilitate the communication, limiting the data document to facilitate the communication, limiting the data
transported to the required elements per [RFC6046-bis]. transported to the required elements per [RFC6046-bis].
5.1. RIDPolicy Class 5.1. RIDPolicy Class
The RIDPolicy class facilitates the delivery of RID messages and is The RIDPolicy class facilitates the delivery of RID messages and is
also referenced for transport in the transport document [RFC6046- also referenced for transport in the transport document [RFC6046-
bis]. bis]. The RIDPolicy Class includes the ability to embed an IODEF or
other XML schema document in the ReportSchema element.
+------------------------+ +------------------------+
| RIDPolicy | | RIDPolicy |
+------------------------+ +------------------------+
| | | |
| ENUM restriction |<>-------------[ Node ] | ENUM restriction |<>-------------[ Node ]
| ENUM MsgType | | ENUM MsgType |
| ENUM MsgDestination |<>---{0..1}----[ IncidentID ] | ENUM MsgDestination |<>---{0..1}----[ IncidentID ]
| ENUM ext-MsgType | | ENUM ext-MsgType |
| ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ] | ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ]
| | | |
| |<>---{1..*}----[ TrafficType ] | |<>---{1..*}----[ TrafficType ]
| | | |
| |<>---{0..1}----[ ReportSchema ]
+------------------------+ +------------------------+
Figure 4: The RIDPolicy Class Figure 4: The RIDPolicy Class
The aggregate elements that constitute the RIDPolicy class are as The aggregate elements that constitute the RIDPolicy class are as
follows: follows:
Node Node
One. The Node class is used to identify a host or network device, One. The Node class is used to identify a host or network device,
skipping to change at page 21, line 10 skipping to change at page 21, line 16
traffic type MUST be provided so that policy decisions can be traffic type MUST be provided so that policy decisions can be
made to continue or stop the investigation. The information made to continue or stop the investigation. The information
should be provided in the IODEF message in the Expectation should be provided in the IODEF message in the Expectation
class or in the History class using a HistoryItem log. This class or in the History class using a HistoryItem log. This
may also be used for incident types other than information may also be used for incident types other than information
security related incidents. security related incidents.
6. ext-value. An escape value used to extend this attribute. 6. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1. See IODEF [RFC5070], Section 5.1.
ReportSchema
Zero or One. The ReportSchema class is used by the message
types that require the full IODEF schema to be included in the
RID envelope. Alternate schemas may be included if approved
for use with RID by IANA.
The RIDPolicy class has five attributes: The RIDPolicy class has five attributes:
restriction restriction
OPTIONAL. ENUM. This attribute indicates the disclosure OPTIONAL. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient to adhere. guidelines to which the sender expects the recipient to adhere.
This guideline provides no real security since it is the choice This guideline provides no real security since it is the choice
of the recipient of the document to honor it. This attribute of the recipient of the document to honor it. This attribute
follows the same guidelines as "restriction" used in IODEF. follows the same guidelines as "restriction" used in IODEF.
skipping to change at page 23, line 10 skipping to change at page 23, line 21
MsgType-ext MsgType-ext
OPTIONAL. STRING. A means by which to extend the MsgType OPTIONAL. STRING. A means by which to extend the MsgType
attribute. See IODEF [RFC5070], Section 5.1. attribute. See IODEF [RFC5070], Section 5.1.
MsgDestination-ext MsgDestination-ext
OPTIONAL. STRING. A means by which to extend the OPTIONAL. STRING. A means by which to extend the
MsgDestination attribute. See IODEF [RFC5070], Section 5.1 MsgDestination attribute. See IODEF [RFC5070], Section 5.1
5.1.1. ReportSchema
The ReportSchema class is an aggregate class in the RIDPolicy class.
The IODEF schema is the approved schema for inclusion in RID messages
via the ReportSchema class.
+-------------------------+
| ReportSchema |
+-------------------------+
| |
| ENUM Version |
| STRING ext-Version |<>---{1}-------[ XMLDocument ]
| ENUM XMLSchemaID |
| STRING ext-XMLSchemaID |<>---{0..1}----[ URL ]
| |
| |<>---{0..*}----[ DetachedSignature ]
| |
+-------------------------+
Figure 5: The ReportSchema Class
The elements that constitute the ReportSchema class are as follows:
XMLDocument
One. The XMLDocument is a complete XML document defined by the
iodef:ExtensionType class. This class follows the guidelines
in [RFC5070] Section 5 where the data type is set to "xml" and
meaning is set to "xml" to include an xml document.
URL
Zero or One. URL. A reference to the XML schema included. The
URL data type is defined in [RFC5070] Section 2.15 as "xs:
anyURI" in the schema. The schemaLocation for IODEF is already
included in the RID schema, so this is not necessary to include
a URL for IODEF documents.
DetachedSignature
Zero to many. The DetachedSignature includes a complete XML
document with the type specified by the iodef:ExtensionType
class. This class follows the guidelines in [RFC5070] Section
5 where the data type is set to "xml" and meaning is set to
"xml" to include an xml document. This element is used to
encapsulate the detached signature based on the iodef:
RecordItem class within the IODEF document to verify the
originator of the message. If other schemas are used instead
of IODEF, they MUST provide guidance on what class to use if a
detached signature is provided for this purpose.
The ReportSchema class has four attributes:
Version
OPTIONAL. One. The Version attribute is the version number of
the specified XML schema. 1.0 is the only permitted value as
the IODEF schema is currently 1.0. If a schema that is
approved by IANA or IODEF 1.0 is included, this attribute MUST
be set.
ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1.
ext-Version
OPTIONAL. One. The ext-Version attribute is the version number
of the included XML schema. This attribute is used if a schema
other than IODEF or an IANA approved schema that has been added
to the enumerated list for Version is included.
XMLSchemaID
OPTIONAL. One. The XMLSchemaID attribute is the identifier
(defined namespace) of the XML schema included. The
XMLSchemaID and Version specify the format of the XMLDocument
element. The only permitted value, unless additional schemas
are approved by IANA, is the namespace for IODEF [RFC5070],
"urn:ietf:params:xml:ns:iodef-1.0". This attribute MUST be set
if IODEF or an IANA approved schema is included.
ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1.
ext-XMLSchemaID
OPTIONAL. One. The ext-XMLSchemaID attribute is the identifier
(defined namespace) of the XML schema included. The ext-
XMLSchemaID and Version specify the format of the XMLDocument
element and are used if the included schema is not IODEF
version 1.0 or an IANA approved schema that has been added to
the enumerated list for XMLSchemaID.
5.2. RequestStatus 5.2. RequestStatus
The RequestStatus class is an aggregate class in the RID class. The RequestStatus class is an aggregate class in the RID class.
+--------------------------------+ +--------------------------------+
| RequestStatus | | RequestStatus |
+--------------------------------+ +--------------------------------+
| | | |
| ENUM restriction | | ENUM restriction |
| ENUM AuthorizationStatus | | ENUM AuthorizationStatus |
| ENUM Justification | | ENUM Justification |
| STRING ext-AuthorizationStatus | | STRING ext-AuthorizationStatus |
| STRING ext-Justification | | STRING ext-Justification |
| | | |
+--------------------------------+ +--------------------------------+
Figure 5: The RequestStatus Class Figure 6: The RequestStatus Class
The RequestStatus class has five attributes: The RequestStatus class has five attributes:
restriction restriction
OPTIONAL. ENUM. This attribute indicates the disclosure OPTIONAL. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient to adhere. guidelines to which the sender expects the recipient to adhere.
This guideline provides no real security since it is the choice This guideline provides no real security since it is the choice
of the recipient of the document to honor it. This attribute of the recipient of the document to honor it. This attribute
follows the same guidelines as "restriction" used in IODEF. follows the same guidelines as "restriction" used in IODEF.
skipping to change at page 25, line 20 skipping to change at page 27, line 25
| IncidentSource | | IncidentSource |
+-------------------+ +-------------------+
| | | |
| ENUM restriction | | ENUM restriction |
| |<>-------------[ SourceFound ] | |<>-------------[ SourceFound ]
| | | |
| |<>---{0..*}----[ Node ] | |<>---{0..*}----[ Node ]
| | | |
+-------------------+ +-------------------+
Figure 6: The IncidentSource Class Figure 7: The IncidentSource Class
The elements that constitute the IncidentSource class follow: The elements that constitute the IncidentSource class follow:
SourceFound SourceFound
One. BOOLEAN. The Source class indicates if a source was One. BOOLEAN. The Source class indicates if a source was
identified. If the source was identified, it is listed in the identified. If the source was identified, it is listed in the
Node element of this class. Node element of this class.
True. Source of incident was identified. True. Source of incident was identified.
skipping to change at page 25, line 46 skipping to change at page 28, line 4
One. The Node class is used to identify a host or network One. The Node class is used to identify a host or network
device, in this case to identify the system communicating RID device, in this case to identify the system communicating RID
messages. messages.
The base definition of this class is reused from the IODEF The base definition of this class is reused from the IODEF
specification [RFC5070], Section 3.16. specification [RFC5070], Section 3.16.
The IncidentSource class has one attribute: The IncidentSource class has one attribute:
restriction restriction
OPTIONAL. ENUM. This attribute indicates the disclosure OPTIONAL. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient to adhere. guidelines to which the sender expects the recipient to adhere.
This guideline provides no real security since it is the choice This guideline provides no real security since it is the choice
of the recipient of the document to honor it. This attribute of the recipient of the document to honor it. This attribute
follows the same guidelines as "restriction" used in IODEF. follows the same guidelines as "restriction" used in IODEF.
5.4. RID Name Spaces 5.4. RID Name Spaces
The RID schema declares a namespace of "iodef-rid-1.1" and registers The RID schema declares a namespace of "iodef-rid-1.2" and registers
it per [XMLNames]. Each IODEF-RID document MUST use the it per [XMLNames]. Each IODEF-RID document MUST use the
"iodef-rid-1.1" namespace in the top-level element RID-Document. It "iodef-rid-1.2" namespace in the top-level element RID-Document. It
can be referenced as follows: can be referenced as follows:
<RID-Document version="1.10" lang="en-US" <RID-Document version="1.10" lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2"
xsi:schemaLocation=http://www.iana.org/assignments/xml-registry/ xsi:schemaLocation=http://www.iana.org/assignments/xml-registry/
schema/iodef-rid-1.1.xsd"> schema/iodef-rid-1.2.xsd">
5.5. Including IODEF or other XML Documents
In order to support the changing activity of CSIRTS, the RID schema
can include an IODEF or other data model. The IODEF is also
extensible, enabling the schemas to evolve along with the needs of
CSIRTs. This section discusses how to include the IODEF XML document
or other XML documents to leverage the security and trust
relationships established throughout he use of RID. These techniques
are designed so that adding new data will not require a change to the
RID schema. This approach supports the exchange of private XML
documents relevant only to a closed consortium. XML documents can be
included through the ReportSchema class in the RIDPolicy class. The
XMLDocument attribute is set to XML to allow for the inclusion of
full IODEF or other XML documents. The following guidelines MUST be
followed:
1. The included schema MUST define a separate namespace, such as the
declared namespace for IODEF of
"urn:ietf:params:xml:ns:iodef-1.0".
2. When a parser encounters an included XML document it does not
understand, it MUST be ignored (and not processed), but the
remainder of the document MUST be processed. Parsers will be
able to identify the XML documents for which they have no
processing logic through the namespace declaration. Parsers that
encounter an unrecognized element in a namespace that they do
support SHOULD reject the document as a syntax error.
3. Implementations SHOULD NOT download schemas at runtime due to the
security implications, and included documents MUST NOT be
required to provide a resolvable location of their schema.
The examples included in Section 7 demonstrate how an IODEF document
is included. The included schema, of IODEF is represented in
ReportSchema as follows:
Version: "1.0"
XMLSchemaID: "urn:ietf:params:xml:ns:iodef-1.0"
ReferenceURL: "http://www.iana.org/assignments/xml-registry/
schema/iodef-1.0.xsd"
The ReferenceURL is optionally included for IODEF since it is already
in the RID schema and the schemaLocation is defined. See the IANA
Considerations section for extending the list of approved XML schemas
to be included in RID for secure XML document exchanges.
6. RID Messages 6. RID Messages
The IODEF model is followed as specified in [RFC5070] for each of the The IODEF model is followed as specified in [RFC5070] for each of the
RID message types. The RID schema is used in combination with IODEF RID message types. The RID schema is used in combination with IODEF
documents to facilitate RID communications. Each message type varies documents to facilitate RID communications. Each message type varies
slightly in format and purpose; hence, the requirements vary and are slightly in format and purpose; hence, the requirements vary and are
specified for each. All classes, elements, attributes, etc., that specified for each. All classes, elements, attributes, etc., that
are defined in the IODEF-Document are valid in the context of a RID are defined in the IODEF-Document are valid in the context of a RID
message; however, some listed as optional in IODEF are mandatory for message; however, some listed as optional in IODEF are mandatory for
skipping to change at page 36, line 39 skipping to change at page 39, line 39
9. Trace Initiated 9. Trace Initiated
10. <----------RequestAuthorization----o 10. <----------RequestAuthorization----o
<---RequestAuth---o <---RequestAuth---o
11. Locate attack 11. Locate attack
source on network X source on network X
12. <------------Result----------------o 12. <------------Result----------------o
Figure 7: TraceRequest Communication Flow Figure 8: TraceRequest Communication Flow
Before a trace is initiated, the RID system should verify if an Before a trace is initiated, the RID system should verify if an
instance of the trace or a similar request is not active. The traces instance of the trace or a similar request is not active. The traces
may be resource intensive; therefore, providers need to be able to may be resource intensive; therefore, providers need to be able to
detect potential abuse of the system or unintentional resource detect potential abuse of the system or unintentional resource
drains. Information such as the Source and Destination Information, drains. Information such as the Source and Destination Information,
associated packets, and the incident may be desirable to maintain for associated packets, and the incident may be desirable to maintain for
a period of time determined by administrators. a period of time determined by administrators.
The communication flow demonstrates that a RequestAuthorization The communication flow demonstrates that a RequestAuthorization
skipping to change at page 38, line 34 skipping to change at page 41, line 34
this example to enable any traces to be performed by SP-2 and SP-3 to this example to enable any traces to be performed by SP-2 and SP-3 to
perform traces to the attack source before taking the requested perform traces to the attack source before taking the requested
action to 'rate-limit' the traffic. The subnet of 192.0.2.0uses a 27 action to 'rate-limit' the traffic. The subnet of 192.0.2.0uses a 27
bit mask in the examples below. bit mask in the examples below.
In the following example, use of [XMLsig] to generate digital In the following example, use of [XMLsig] to generate digital
signatures follows the guidance of [XMLsig] 1.0. Version 1.1 of signatures follows the guidance of [XMLsig] 1.0. Version 1.1 of
[XMLsig] supports additional digest algorithms. SHA-1 SHOULD NOT be [XMLsig] supports additional digest algorithms. SHA-1 SHOULD NOT be
used, see [RFC6194] for further details. used, see [RFC6194] for further details.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="TraceRequest" <iodef-rid:RIDPolicy MsgType="TraceRequest"
MsgDestination="RIDSystem"> MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/> <iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address> <iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
</iodef:Node> </iodef:Node>
<iodef-rid:TrafficType type="Attack"/> <iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1 CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID> </iodef:IncidentID>
</iodef-rid:RIDPolicy> <!-- IODEF-Document included in RID -->
</iodef-rid:RID> <iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<!-- IODEF-Document accompanied by the above RID --> <IODEF-Document lang="en">
<iodef:IODEF-Document version="1.00" <iodef:Incident restriction="need-to-know" purpose="traceback">
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
<iodef:Incident restriction="need-to-know" purpose="traceback"> CERT-FOR-OUR-DOMAIN#207-1
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> </iodef:IncidentID>
CERT-FOR-OUR-DOMAIN#207-1 <iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
</iodef:IncidentID> <iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
<iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime> <iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
<iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime> <iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime> <iodef:Assessment>
<iodef:Description>Host involved in DoS attack</iodef:Description> <iodef:Impact severity="low" completion="failed" type="dos"/>
<iodef:Assessment> </iodef:Assessment>
<iodef:Impact severity="low" completion="failed" type="dos"/> <iodef:Contact role="creator" type="organization">
</iodef:Assessment> <iodef:ContactName>Constituency-contact for 192.0.2.35
<iodef:Contact role="creator" type="organization"> </iodef:ContactName>
<iodef:ContactName>Constituency-contact for 192.0.2.35 <iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
</iodef:ContactName> </iodef:Contact>
<iodef:Email>Constituency-contact@192.0.2.35</iodef:Email> <iodef:EventData>
</iodef:Contact> <iodef:Flow>
<iodef:EventData> <iodef:System category="source">
<iodef:Flow> <iodef:Node>
<iodef:System category="source"> <iodef:Address category="ipv4-addr">192.0.2.35
<iodef:Node> </iodef:Address>
<iodef:Address category="ipv4-addr">192.0.2.35 </iodef:Node>
</iodef:Address> <iodef:Service ip_protocol="6">
</iodef:Node> <iodef:Port>38765</iodef:Port>
<iodef:Service> </iodef:Service>
<iodef:port>38765</iodef:port> </iodef:System>
</iodef:Service> <iodef:System category="target">
</iodef:System> <iodef:Node>
<iodef:System category="target"> <iodef:Address category="ipv4-addr">192.0.2.67
<iodef:Node> </iodef:Address>
<iodef:Address category="ipv4-addr">192.0.2.67 </iodef:Node>
</iodef:Address> <iodef:Service ip_protocol="6">
</iodef:Node> <iodef:Port>80</iodef:Port>
<iodef:Service> </iodef:Service>
<iodef:port>80</iodef:port> </iodef:System>
</iodef:Service> </iodef:Flow>
</iodef:System> <iodef:Expectation severity="high" action="rate-limit-host">
</iodef:Flow>
<iodef:Expectation severity="high" action="rate-limit-host">
<iodef:Description>
Rate-limit traffic close to source
</iodef:Description>
</iodef:Expectation>
<iodef:Record>
<iodef:RecordData>
<iodef:Description> <iodef:Description>
The IPv4 packet included was used in the described attack Rate-limit traffic close to source
</iodef:Description> </iodef:Description>
<iodef:RecordItem dtype="ipv4-packet">450000522ad9 </iodef:Expectation>
0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem>
<iodef:DateTime>2001-09-14T08:19:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:Description>
Notification sent to next upstream SP closer to 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
<!-- Digital signature accompanied by above RID and IODEF -->
<Envelope xmlns="urn:envelope"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1">
<iodef:IODEF-Document>
<iodef:Incident>
<iodef:EventData>
<iodef:Record> <iodef:Record>
<iodef:RecordData> <iodef:RecordData>
<iodef:RecordItem type="ipv4-packet">450000522ad9 <iodef:Description>
0000ff06c41fc0a801020a010102976d0050103e020810d9 The IPv4 packet included was used in the described attack
4a1350021000ad6700005468616e6b20796f7520666f7220 </iodef:Description>
6361726566756c6c792072656164696e6720746869732052 <iodef:RecordItem dtype="ipv4-packet">450000522ad9
46432e0a 0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem> </iodef:RecordItem>
</iodef:RecordData> </iodef:RecordData>
</iodef:Record> </iodef:Record>
</iodef:EventData> </iodef:EventData>
<iodef:History>
<iodef:HistoryItem action="rate-limit-host">
<iodef:DateTime>2001-09-14T08:19:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:Description>
Notification sent to next upstream SP closer to 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident> </iodef:Incident>
</iodef:IODEF-Document> </IODEF-Document>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> </iodef-rid:XMLDocument>
<SignedInfo> <!-- End of IODEF-Document included in RID -->
<CanonicalizationMethod <!-- Start of detached XML signature included in RID -->
Algorithm="http://www.w3.org/TR/2001/ <iodef-rid:DetachedSignature dtype="xml" meaning="xml">
REC-xml-c14n-20010315#WithComments"/> <!-- Signature of IODEF only document, will replace when iodef-rid-1.2 is posted -->
<SignatureMethod <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> <ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<Reference URI=""> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
<Transforms> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
<Transform Algorithm= <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"
"http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
</Transforms> <ds:Reference URI="IODEF-TraceRequestEx11.xml" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<DigestMethod <ds:Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"
<DigestValue>KiI5+6SnFAs429VNwsoJjHPplmo=</DigestValue> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
</Reference> <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"
</SignedInfo> xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<SignatureValue> <ds:XPath xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
VvyXqCzjoW0m2NdxNeToXQcqcSM80W+JMW+Kn01cS3z3KQwCPeswzg== xmlns:xml="http://www.w3.org/XML/1998/namespace">
</SignatureValue> /IODEF-Document/Incident[1]/EventData[1]/Record[1]/RecordData[1]/RecordItem[1]</ds:XPath>
<KeyInfo> </ds:Transform>
<KeyValue> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
<DSAKeyValue> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
<P>/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j </ds:Transforms>
QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==</P> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
<Q>li7dzDacuo67Jg7mtqEm2TRuOMU=</Q> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
<G>Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5 <ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">2jmj7l5rSw0yVb/vlWAYkK/YBwk=
Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==</G> </ds:DigestValue>
<Y>VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs </ds:Reference>
HifTyYdnj+roGzy4o09YntYD8zneQ7lw==</Y> </ds:SignedInfo>
</DSAKeyValue> <ds:SignatureValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
</KeyValue> JIMoK088bZk5V79DgSYnVNhnX3keEghQvkNIMol+VUHSjHCbiTTsYAMfYTqnWQDQcSzJE3YxdL5l
</KeyInfo> 0xII/YtWcp0bb6ZJEKKwKocHSxRsJsoH/jXP23ENzyMsEMrVvOX8Z8Gi37u35YV5Epw0srqCg9ZR
</Signature> lB854q6W7Ehdd0dIyVccWyOSvUIMDFITe6NJ1z7bxr0w09uN/oja3lk1UW4U3/oD2Cb+aZFGtXnw
</Envelope> jeLCaOhOs/SFgseU2skVELYZ21OovmdSs+7E5eHglUacyPKbZmrqGmqISuCR1fXDQ5K4O8cR7n9r
7lowQPhsqntrWE2H81EI7mM7NedUVfpQdfZeKA==
</ds:SignatureValue>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509SubjectName xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
EMAILADDRESS=CSIRT@emc.com,CN=CSIRT,OU=EMC OCTO,O=EMC,L=HOpkinton,ST=MA,C=US
</ds:X509SubjectName>
<ds:X509Certificate xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
MIIDlzCCAn+gAwIBAgIJAM+Pp0vlgv4HMA0GCSqGSIb3DQEBDQUAMH0xCzAJBgNVBAYTAlVTMQsw
CQYDVQQIEwJNQTESMBAGA1UEBxMJSG9wa2ludG9uMQwwCgYDVQQKEwNFTUMxETAPBgNVBAsTCEVN
QyBPQ1RPMQ4wDAYDVQQDEwVDU0lSVDEcMBoGCSqGSIb3DQEJARYNQ1NJUlRAZW1jLmNvbTAeFw0x
MTEyMjkxOTQ4NDhaFw0yMTEyMjYxOTQ4NDhaMH0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNQTES
MBAGA1UEBxMJSE9wa2ludG9uMQwwCgYDVQQKEwNFTUMxETAPBgNVBAsTCEVNQyBPQ1RPMQ4wDAYD
VQQDEwVDU0lSVDEcMBoGCSqGSIb3DQEJARYNQ1NJUlRAZW1jLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMjaCqWlpZj4B6mUbBtEPhM9ThVPUgju+lXLIeL607ch2ffgAUwk7tie
UYgrVYhWJqepRUawjuSNT3myNMkqtXxLt2N0sp+2s1981QtTjABmg72NiKgl+Gouf8/RzWdVX1S9
BToYrZUitLaOPER5tBJpzqqbuzodOzZ1t4Ve1w9uLdm5Rnqi9a7jUFA9aii9KAjcoiT1l1gyHQyP
j8IYcqkM+sRTGSgRdGGu3107+UHdt/aCwV7eI7P6Km9q4BCgAMPiyJzwe+22JdMb37HPgjhS6Vn8
TxlMPJn7QION7gVX20aS3FLao9DOZQ/ZA4r/yOm6PO30RljKK+mrDmRf0fMCAwEAAaMaMBgwFgYD
VR0lAQH/BAwwCgYIKwYBBQUHAwMwDQYJKoZIhvcNAQENBQADggEBALqt+Cs0fvGOgSg/X8uZ3ohb
1ce79fFFImTF7MaC827xrgxpc3O8mx+7xu/i6jkarwY30HohGhH885pVfCBo4tUwmFXuPms5jZ4v
uuJktgfzaeo6Z6fV30bSFhkgbiGTMgva61oa/2HRYjo4a/CcALPpdJxtyMrKilbUxl908Xdem0VT
PO+Ydvm3v4AQlbFzxUrzeWp3g5N++3UuDlKiK0AGcEMe+J4foMBvzkypLvLRFclvZGuCc9Sn/gII
TI+Hi2kHGULGXhR63Jfu1WcnV7vs771EI1vLmiKzxeseMV7N1wVXuCavg1DJVwIfAp3oKqkKX7MI
eggvFmZ3RSQQRTA=
</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:RSAKeyValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:Modulus xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
yNoKpaWlmPgHqZRsG0Q+Ez1OFU9SCO76Vcsh4vrTtyHZ9+ABTCTu2J5RiCtViFYmp6lFRrCO5I1P
ebI0ySq1fEu3Y3Syn7azX3zVC1OMAGaDvY2IqCX4ai5/z9HNZ1VfVL0FOhitlSK0to48RHm0EmnO
qpu7Oh07NnW3hV7XD24t2blGeqL1ruNQUD1qKL0oCNyiJPWXWDIdDI+PwhhyqQz6xFMZKBF0Ya7f
XTv5Qd239oLBXt4js/oqb2rgEKAAw+LInPB77bYl0xvfsc+COFLpWfxPGUw8mftAg43uBVfbRpLc
Utqj0M5lD9kDiv/I6bo87fRGWMor6asOZF/R8w==
</ds:Modulus>
<ds:Exponent xmlns:ds="http://www.w3.org/2000/09/xmldsig#">AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</ds:Signature>
</iodef-rid:DetachedSignature>
<!-- End of detached XML signature included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
7.1.2. RequestAuthorization Message Example 7.1.2. RequestAuthorization Message Example
The example RequestAuthorization message is in response to the The example RequestAuthorization message is in response to the
TraceRequest message listed above. The SP that received the request TraceRequest message listed above. The SP that received the request
is responding to approve the trace continuance in their network. is responding to approve the trace continuance in their network.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="RequestAuthorization" <iodef-rid:RIDPolicy MsgType="RequestAuthorization"
MsgDestination="RIDSystem"> MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/> <iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address> <iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node> </iodef:Node>
<iodef-rid:TrafficType type="Attack"/> <iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1 CERT-FOR-OUR-DOMAIN#207-1
skipping to change at page 42, line 30 skipping to change at page 45, line 41
7.1.3. Result Message Example 7.1.3. Result Message Example
The example Result message is in response to the TraceRequest listed The example Result message is in response to the TraceRequest listed
above. This message type only comes after a RequestAuthorization above. This message type only comes after a RequestAuthorization
within the TraceRequest flow of messages. It may be a direct within the TraceRequest flow of messages. It may be a direct
response to an Investigation request. This message provides response to an Investigation request. This message provides
information about the source of the attack and the actions taken to information about the source of the attack and the actions taken to
mitigate the traffic. mitigate the traffic.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Result" <iodef-rid:RIDPolicy MsgType="Result"
MsgDestination="RIDSystem"> MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/> <iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address> <iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
<iodef-rid:IncidentSource>
<iodef-rid:SourceFound>true</iodef-rid:SourceFound>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.37</iodef:Address>
</iodef:Node>
</iodef-rid:IncidentSource>
</iodef-rid:RID>
<!-- IODEF-Document accompanied by the above RID --> </iodef:Node>
<iodef:IODEF-Document version="1.00" <iodef-rid:TrafficType type="Attack"/>
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
<iodef:Incident restriction="need-to-know" purpose="traceback"> CERT-FOR-OUR-DOMAIN#207-1
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> </iodef:IncidentID>
CERT-FOR-OUR-DOMAIN#207-1 <!-- IODEF-Document included in RID -->
</iodef:IncidentID> <iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<IODEF-Document lang="en">
<iodef:Incident restriction="need-to-know" purpose="traceback">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime> <iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime> <iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
<iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime> <iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
<iodef:Description>Host involved in DoS attack</iodef:Description> <iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:Assessment> <iodef:Assessment>
<iodef:Impact severity="low" completion="failed" type="dos"/> <iodef:Impact severity="low" completion="failed" type="dos"/>
</iodef:Assessment> </iodef:Assessment>
<iodef:Contact role="creator" type="organization"> <iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35 <iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName> </iodef:ContactName>
skipping to change at page 44, line 11 skipping to change at page 47, line 18
</iodef:Flow> </iodef:Flow>
</iodef:EventData> </iodef:EventData>
</iodef:EventData> </iodef:EventData>
<iodef:EventData> <iodef:EventData>
<iodef:Flow> <iodef:Flow>
<iodef:System category="source"> <iodef:System category="source">
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35 <iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address> </iodef:Address>
</iodef:Node> </iodef:Node>
<iodef:Service> <iodef:Service ip_protocol="6">
<iodef:port>38765</iodef:port> <iodef:Port>38765</iodef:Port>
</iodef:Service> </iodef:Service>
</iodef:System> </iodef:System>
<iodef:System category="target"> <iodef:System category="target">
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67 <iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address> </iodef:Address>
</iodef:Node> </iodef:Node>
<iodef:Service> <iodef:Service ip_protocol="6">
<iodef:port>80</iodef:port> <iodef:Port>80</iodef:Port>
</iodef:Service> </iodef:Service>
</iodef:System> </iodef:System>
</iodef:Flow> </iodef:Flow>
<iodef:Expectation severity="high" action="rate-limit-host"> <iodef:Expectation severity="high" action="rate-limit-host">
<iodef:Description> <iodef:Description>
Rate-limit traffic close to source Rate-limit traffic close to source
</iodef:Description> </iodef:Description>
</iodef:Expectation> </iodef:Expectation>
<iodef:Record> <iodef:Record>
<iodef:RecordData> <iodef:RecordData>
skipping to change at page 44, line 45 skipping to change at page 48, line 4
<iodef:RecordItem dtype="ipv4-packet">450000522ad9 <iodef:RecordItem dtype="ipv4-packet">450000522ad9
0000ff06c41fc0a801020a010102976d0050103e020810d9 0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220 4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052 6361726566756c6c792072656164696e6720746869732052
46432e0a 46432e0a
</iodef:RecordItem> </iodef:RecordItem>
</iodef:RecordData> </iodef:RecordData>
</iodef:Record> </iodef:Record>
</iodef:EventData> </iodef:EventData>
<iodef:History> <iodef:History>
<iodef:HistoryItem> <iodef:HistoryItem action="rate-limit-host">
<iodef:DateTime>2004-02-02T22:53:01+00:00</iodef:DateTime> <iodef:DateTime>2004-02-02T22:53:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#207-1 CSIRT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID> </iodef:IncidentID>
<iodef:Description> <iodef:Description>
Notification sent to next upstream SP closer to 192.0.2.35 Notification sent to next upstream SP closer to 192.0.2.35
</iodef:Description> </iodef:Description>
</iodef:HistoryItem> </iodef:HistoryItem>
<iodef:HistoryItem action="rate-limit-host"> <iodef:HistoryItem action="rate-limit-host">
<iodef:DateTime>2004-02-02T23:07:21+00:00</iodef:DateTime> <iodef:DateTime>2004-02-02T23:07:21+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-SP3"> <iodef:IncidentID name="CSIRT-FOR-SP3">
CSIRT-FOR-SP3#3291-1 CSIRT-FOR-SP3#3291-1
</iodef:IncidentID> </iodef:IncidentID>
<iodef:Description> <iodef:Description>
Host rate-limited for 24 hours Host rate-limited for 24 hours
</iodef:Description> </iodef:Description>
</iodef:HistoryItem> </iodef:HistoryItem>
</iodef:History> </iodef:History>
</iodef:Incident> </iodef:Incident>
</iodef:IODEF-Document> </IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
<iodef-rid:IncidentSource>
<iodef-rid:SourceFound>true</iodef-rid:SourceFound>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.37</iodef:Address>
</iodef:Node>
</iodef-rid:IncidentSource>
</iodef-rid:RID>
7.2. Investigation Request Communication Flow 7.2. Investigation Request Communication Flow
The diagram below outlines the RID Investigation request The diagram below outlines the RID Investigation request
communication flow between RID systems on different networks for a communication flow between RID systems on different networks for a
security incident with a known source address. The proper response security incident with a known source address. The proper response
to an Investigation request is a Result message. If there is a to an Investigation request is a Result message. If there is a
problem with the request, such as a failure to validate the digital problem with the request, such as a failure to validate the digital
signature or decrypt the request, a RequestAuthorization message is signature or decrypt the request, a RequestAuthorization message is
sent to the requestor. The RequestAuthorization message should sent to the requestor. The RequestAuthorization message should
skipping to change at page 45, line 48 skipping to change at page 49, line 22
3. o---Investigation----> 3. o---Investigation---->
4. Research 4. Research
incident and incident and
determine appropriate determine appropriate
actions to take actions to take
5. <-------Result-------o 5. <-------Result-------o
Figure 8: Investigation Communication Flow Figure 9: Investigation Communication Flow
7.2.1. Investigation Request Example 7.2.1. Investigation Request Example
The following example only includes the RID-specific details. The The following example only includes the RID-specific details. The
IODEF and security measures are similar to the TraceRequest IODEF and security measures are similar to the TraceRequest
information, with the exception that the source is known and the information, with the exception that the source is known and the
receiving RID system is known to be close to the source. The source receiving RID system is known to be close to the source. The source
known is indicated in the IODEF document, which allows for incident known is indicated in the IODEF document, which allows for incident
sources to be listed as spoofed, if appropriate. sources to be listed as spoofed, if appropriate.
This flow does not include a Result message as the request is denied This flow does not include a Result message as the request is denied
as shown in the RequestAuthorization response. as shown in the RequestAuthorization response.
SP-1 is represented by CERT-FOR-OUR-DOMAIN and 192.0.2.67. SP-2 is SP-1 is represented by CERT-FOR-OUR-DOMAIN and 192.0.2.67. SP-2 is
identified by 192,0.2.98. In this example SP-2 is the service identified by 192,0.2.98. In this example SP-2 is the service
provider for systems on the 192.0.2.32/27 subnet. The contact for provider for systems on the 192.0.2.32/27 subnet. The contact for
the host 192.0.2.35 is known at the start of the request as the host 192.0.2.35 is known at the start of the request as
'Constituency-contact@10.1.1.2'. 'Constituency-contact@10.1.1.2'.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Investigation" <iodef-rid:RIDPolicy MsgType="Investigation"
MsgDestination="SourceOfIncident"> MsgDestination="SourceOfIncident">
<iodef-rid:PolicyRegion region="PeerToPeer"/> <iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.98</iodef:Address> <iodef:Address category="ipv4-addr">192.0.2.98</iodef:Address>
</iodef:Node> </iodef:Node>
<iodef-rid:TrafficType type="Attack"/> <iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1 CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID> </iodef:IncidentID>
</iodef-rid:RIDPolicy> <!-- IODEF-Document included in RID -->
</iodef-rid:RID> <iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<!-- IODEF-Document accompanied by the above RID --> <IODEF-Document lang="en">
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="other"> <iodef:Incident restriction="need-to-know" purpose="other">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1 CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID> </iodef:IncidentID>
<iodef:DetectTime>2004-02-05T08:13:33+00:00</iodef:DetectTime> <iodef:DetectTime>2004-02-05T08:13:33+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-05T08:13:31+00:00</iodef:StartTime> <iodef:StartTime>2004-02-05T08:13:31+00:00</iodef:StartTime>
<iodef:EndTime>2004-02-05T08:13:33+00:00</iodef:EndTime> <iodef:EndTime>2004-02-05T08:13:33+00:00</iodef:EndTime>
<iodef:ReportTime>2004-02-05T08:13:35+00:00</iodef:ReportTime> <iodef:ReportTime>2004-02-05T08:13:35+00:00</iodef:ReportTime>
<iodef:Description>Host involved in DoS attack</iodef:Description> <iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:Assessment> <iodef:Assessment>
skipping to change at page 47, line 18 skipping to change at page 50, line 34
</iodef:ContactName> </iodef:ContactName>
<iodef:Email>Constituency-contact@10.1.1.2</iodef:Email> <iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
</iodef:Contact> </iodef:Contact>
<iodef:EventData> <iodef:EventData>
<iodef:Flow> <iodef:Flow>
<iodef:System category="source"> <iodef:System category="source">
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35 <iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address> </iodef:Address>
</iodef:Node> </iodef:Node>
<iodef:Service> <iodef:Service ip_protocol="6">
<iodef:port>41421</iodef:port> <iodef:Port>41421</iodef:Port>
</iodef:Service> </iodef:Service>
</iodef:System> </iodef:System>
<iodef:System category="target"> <iodef:System category="target">
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67 <iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address> </iodef:Address>
</iodef:Node> </iodef:Node>
<iodef:Service> <iodef:Service ip_protocol="6">
<iodef:port>80</iodef:port> <iodef:Port>80</iodef:Port>
</iodef:Service> </iodef:Service>
</iodef:System> </iodef:System>
</iodef:Flow> </iodef:Flow>
<iodef:Expectation severity="high" action="investigate"> <iodef:Expectation severity="high" action="investigate">
<iodef:Description> <iodef:Description>
Investigate whether source has been compromised Investigate whether source has been compromised
</iodef:Description> </iodef:Description>
</iodef:Expectation> </iodef:Expectation>
</iodef:EventData> </iodef:EventData>
<iodef:History> <iodef:History>
<iodef:HistoryItem> <iodef:HistoryItem action="block-host">
<iodef:DateTime>2004-02-05T08:19:01+00:00</iodef:DateTime> <iodef:DateTime>2004-02-05T08:19:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#208-1 CSIRT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID> </iodef:IncidentID>
<iodef:Description> <iodef:Description>
Investigation request sent to SP for 192.0.2.35 Investigation request sent to SP for 192.0.2.35
</iodef:Description> </iodef:Description>
</iodef:HistoryItem> </iodef:HistoryItem>
</iodef:History> </iodef:History>
</iodef:Incident> </iodef:Incident>
</iodef:IODEF-Document> </IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
7.2.2. RequestAuthorization Message Example 7.2.2. RequestAuthorization Message Example
The example RequestAuthorization message is in response to the The example RequestAuthorization message is in response to the
Investigation request listed above. The SP that received the request Investigation request listed above. The SP that received the request
was unable to validate the digital signature used to authenticate the was unable to validate the digital signature used to authenticate the
sending RID system. sending RID system.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="RequestAuthorization" <iodef-rid:RIDPolicy MsgType="RequestAuthorization"
MsgDestination="RIDSystem"> MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/> <iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address> <iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node> </iodef:Node>
<iodef-rid:TrafficType type="Attack"/> <iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1 CERT-FOR-OUR-DOMAIN#208-1
skipping to change at page 48, line 43 skipping to change at page 52, line 19
SP-1 SP-2 SP-1 SP-2
1. Generate incident information 1. Generate incident information
and prepare Report message and prepare Report message
2. o-------Report-------> 2. o-------Report------->
3. File report in database 3. File report in database
Figure 9: Report Communication Flow Figure 10: Report Communication Flow
The Report communication flow is used to provide information on The Report communication flow is used to provide information on
specific incidents detected on the network. Incident information may specific incidents detected on the network. Incident information may
be shared between CSIRTs or participating RID hosts using this be shared between CSIRTs or participating RID hosts using this
format. When a report is received, the RID system must verify that format. When a report is received, the RID system must verify that
the report has not already been filed. The incident number and the report has not already been filed. The incident number and
incident data, such as the hexadecimal packet and incident class incident data, such as the hexadecimal packet and incident class
information, can be used to compare with existing database entries. information, can be used to compare with existing database entries.
The Report message typically does not have a response. If there is a The Report message typically does not have a response. If there is a
problem with the Report message, such as a failure to validate the problem with the Report message, such as a failure to validate the
digital signature [RFC3275] or decrypt the request, a digital signature [RFC3275] or decrypt the request, a
RequestAuthorization message is sent to the requestor. The RequestAuthorization message is sent to the requestor. The
RequestAuthorization message should provide the reason why the RequestAuthorization message should provide the reason why the
message could not be processed. message could not be processed.
7.3.1. Report Example 7.3.1. Report Example
The following example only includes the RID-specific details. This The following example only includes the RID-specific details. This
skipping to change at page 49, line 23 skipping to change at page 52, line 46
The following example only includes the RID-specific details. This The following example only includes the RID-specific details. This
report is an unsolicited Report message that includes an IPv4 packet. report is an unsolicited Report message that includes an IPv4 packet.
The IODEF document and digital signature is similar to the The IODEF document and digital signature is similar to the
TraceRequest information. TraceRequest information.
This example is a message sent from SP-1, CERT-FOR-OUR-DOMAIN at This example is a message sent from SP-1, CERT-FOR-OUR-DOMAIN at
192.0.2.67, to SP-2 at 192.0.2.130 for informational purposes on an 192.0.2.67, to SP-2 at 192.0.2.130 for informational purposes on an
attack that took place. attack that took place.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Report" MsgDestination="RIDSystem"> <iodef-rid:RIDPolicy MsgType="Report" MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="PeerToPeer"/> <iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.130</iodef:Address> <iodef:Address category="ipv4-addr">192.0.2.130</iodef:Address>
</iodef:Node> </iodef:Node>
<iodef-rid:TrafficType type="Attack"/> <iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#209-1 CERT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID> </iodef:IncidentID>
</iodef-rid:RIDPolicy> <!-- IODEF-Document included in RID -->
</iodef-rid:RID> <iodef-rid:ReportSchema>
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<!-- IODEF-Document accompanied by the above RID --> <IODEF-Document lang="en">
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="reporting"> <iodef:Incident restriction="need-to-know" purpose="reporting">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#209-1 CERT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID> </iodef:IncidentID>
<iodef:DetectTime>2004-02-05T10:21:08+00:00</iodef:DetectTime> <iodef:DetectTime>2004-02-05T10:21:08+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-05T10:21:05+00:00</iodef:StartTime> <iodef:StartTime>2004-02-05T10:21:05+00:00</iodef:StartTime>
<iodef:EndTime>2004-02-05T10:35:00+00:00</iodef:EndTime> <iodef:EndTime>2004-02-05T10:35:00+00:00</iodef:EndTime>
<iodef:ReportTime>2004-02-05T10:27:38+00:00</iodef:ReportTime> <iodef:ReportTime>2004-02-05T10:27:38+00:00</iodef:ReportTime>
<iodef:Description>Host illicitly accessed admin account <iodef:Description>Host illicitly accessed admin account
</iodef:Description> </iodef:Description>
skipping to change at page 50, line 19 skipping to change at page 53, line 41
</iodef:ContactName> </iodef:ContactName>
<iodef:Email>Constituency-contact@10.1.1.2</iodef:Email> <iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
</iodef:Contact> </iodef:Contact>
<iodef:EventData> <iodef:EventData>
<iodef:Flow> <iodef:Flow>
<iodef:System category="source"> <iodef:System category="source">
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35 <iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address> </iodef:Address>
</iodef:Node> </iodef:Node>
<iodef:Service> <iodef:Service ip_protocol="6">
<iodef:port>32821</iodef:port> <iodef:Port>32821</iodef:Port>
</iodef:Service> </iodef:Service>
</iodef:System> </iodef:System>
<iodef:System category="target"> <iodef:System category="target">
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67 <iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address> </iodef:Address>
</iodef:Node> </iodef:Node>
<iodef:Service> <iodef:Service ip_protocol="6">
<iodef:port>22</iodef:port> <iodef:Port>22</iodef:Port>
</iodef:Service> </iodef:Service>
</iodef:System> </iodef:System>
</iodef:Flow> </iodef:Flow>
</iodef:EventData> </iodef:EventData>
<iodef:History> <iodef:History>
<iodef:HistoryItem> <iodef:HistoryItem action="rate-limit-host">
<iodef:DateTime>2004-02-05T10:28:00+00:00</iodef:DateTime> <iodef:DateTime>2004-02-05T10:28:00+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#209-1 CSIRT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID> </iodef:IncidentID>
<iodef:Description> <iodef:Description>
Incident report sent to SP for 192.0.2.35 Incident report sent to SP for 192.0.2.35
</iodef:Description> </iodef:Description>
</iodef:HistoryItem> </iodef:HistoryItem>
</iodef:History> </iodef:History>
</iodef:Incident> </iodef:Incident>
</iodef:IODEF-Document> </IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
7.4. IncidentQuery Communication Flow 7.4. IncidentQuery Communication Flow
The diagram below outlines the RID IncidentQuery communication flow The diagram below outlines the RID IncidentQuery communication flow
between RID systems on different networks. between RID systems on different networks.
SP-1 SP-2 SP-1 SP-2
1. Generate a request for 1. Generate a request for
information on a specific information on a specific
skipping to change at page 51, line 28 skipping to change at page 54, line 50
3. Verify policy information 3. Verify policy information
and determine if matches exist and determine if matches exist
for requested information for requested information
4. <-------Report------o 4. <-------Report------o
5. Associate report to request 5. Associate report to request
by incident number or type by incident number or type
and file report(s). and file report(s).
Figure 10: IncidentQuery Communication Flow Figure 11: IncidentQuery Communication Flow
The IncidentQuery message communication receives a response of a The IncidentQuery message communication receives a response of a
Report message. If the Report message is empty, the responding host Report message. If the Report message is empty, the responding host
did not have information available to share with the requestor. The did not have information available to share with the requestor. The
incident number and responding RID system, as well as the transport, incident number and responding RID system, as well as the transport,
assist in the association of the request and response since a report assist in the association of the request and response since a report
can be filed and is not always solicited. If there is a problem with can be filed and is not always solicited. If there is a problem with
the IncidentQuery message, such as a failure to validate the digital the IncidentQuery message, such as a failure to validate the digital
signature or decrypt the request, a RequestAuthorization message is signature or decrypt the request, a RequestAuthorization message is
sent to the requestor. The RequestAuthorization message should sent to the requestor. The RequestAuthorization message should
skipping to change at page 52, line 12 skipping to change at page 55, line 36
CSIRTs, the incident number and/or IP packet information can be CSIRTs, the incident number and/or IP packet information can be
provided and used for comparison on the receiving RID system to provided and used for comparison on the receiving RID system to
generate (a) Report message(s). generate (a) Report message(s).
This query is sent to 192.0.2.3, inquiring about the incident with This query is sent to 192.0.2.3, inquiring about the incident with
the identifier CERT-FOR-OUR-DOMAIN#210-1. The Report will be the identifier CERT-FOR-OUR-DOMAIN#210-1. The Report will be
provided to the requestor identified and verified through the provided to the requestor identified and verified through the
authentication and digital signature information provided in the RID authentication and digital signature information provided in the RID
message. An example Report is provided above. message. An example Report is provided above.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="IncidentQuery" <iodef-rid:RIDPolicy MsgType="IncidentQuery"
MsgDestination="RIDSystem"> MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="PeerToPeer"/> <iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address> <iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
</iodef:Node> </iodef:Node>
<iodef-rid:TrafficType type="Attack"/> <iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#210-1 CERT-FOR-OUR-DOMAIN#210-1
</iodef:IncidentID> </iodef:IncidentID>
</iodef-rid:RIDPolicy> </iodef-rid:RIDPolicy>
</iodef-rid:RID> </iodef-rid:RID>
8. RID Schema Definition 8. RID Schema Definition
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" <xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="urn:ietf:params:xml:ns:iodef-rid-1.1" targetNamespace="urn:ietf:params:xml:ns:iodef-rid-1.2"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0" <xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0" schemaLocation="http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd"/>
schemaLocation="http://www.iana.org/assignments/xml-registry/ <xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
schema/iodef-1.0.xsd"/>
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
<!-- **************************************************************** <!-- ****************************************************************
********************************************************************* *********************************************************************
*** Real-time Inter-network Defense - RID XML Schema *** *** Real-time Inter-network Defense - RID XML Schema ***
*** Namespace - iodef-rid, December 2011 *** *** Namespace - iodef-rid, December 2011 ***
*** The namespace is defined to support transport of IODEF *** *** The namespace is defined to support transport of IODEF ***
*** documents for exchanging incident information. *** *** documents for exchanging incident information. ***
********************************************************************* *********************************************************************
--> -->
<!--RID messages acts as an envelope for IODEF and RID documents <!--RID messages acts as an envelope for IODEF and RID documents
skipping to change at page 54, line 45 skipping to change at page 58, line 14
<!-- RIDPolicy information with setting information listed in RID <!-- RIDPolicy information with setting information listed in RID
documentation --> documentation -->
<xs:element name="RIDPolicy" type="iodef-rid:RIDPolicyType"/> <xs:element name="RIDPolicy" type="iodef-rid:RIDPolicyType"/>
<xs:complexType name="RIDPolicyType"> <xs:complexType name="RIDPolicyType">
<xs:sequence> <xs:sequence>
<xs:element ref="iodef-rid:PolicyRegion" maxOccurs="unbounded"/> <xs:element ref="iodef-rid:PolicyRegion" maxOccurs="unbounded"/>
<xs:element ref="iodef:Node"/> <xs:element ref="iodef:Node"/>
<xs:element ref="iodef-rid:TrafficType" maxOccurs="unbounded"/> <xs:element ref="iodef-rid:TrafficType" maxOccurs="unbounded"/>
<xs:element ref="iodef:IncidentID" minOccurs="0"/> <xs:element ref="iodef:IncidentID" minOccurs="0"/>
<xs:element ref="iodef-rid:ReportSchema" minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="MsgType" use="required"> <xs:attribute name="MsgType" use="required">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/> <xs:whiteSpace value="collapse"/>
<xs:enumeration value="TraceRequest"/> <xs:enumeration value="TraceRequest"/>
<xs:enumeration value="RequestAuthorization"/> <xs:enumeration value="RequestAuthorization"/>
<xs:enumeration value="Result"/> <xs:enumeration value="Result"/>
<xs:enumeration value="Investigation"/> <xs:enumeration value="Investigation"/>
<xs:enumeration value="Report"/> <xs:enumeration value="Report"/>
skipping to change at page 55, line 24 skipping to change at page 58, line 43
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/> <xs:whiteSpace value="collapse"/>
<xs:enumeration value="RIDSystem"/> <xs:enumeration value="RIDSystem"/>
<xs:enumeration value="SourceOfIncident"/> <xs:enumeration value="SourceOfIncident"/>
<xs:enumeration value="ext-value"/> <xs:enumeration value="ext-value"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
<xs:attribute name="ext-MsgDestination" type="xs:string" <xs:attribute name="ext-MsgDestination" type="xs:string"
use="optional"/> use="optional"/>
<xs:attribute name="restriction" type="iodef:restriction-type"/>
</xs:complexType> </xs:complexType>
<xs:element name="PolicyRegion"> <xs:element name="PolicyRegion">
<xs:complexType> <xs:complexType>
<xs:attribute name="region" use="required"> <xs:attribute name="region" use="required">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/> <xs:whiteSpace value="collapse"/>
<xs:enumeration value="ClientToSP"/> <xs:enumeration value="ClientToSP"/>
<xs:enumeration value="SPToClient"/> <xs:enumeration value="SPToClient"/>
<xs:enumeration value="IntraConsortium"/> <xs:enumeration value="IntraConsortium"/>
skipping to change at page 56, line 15 skipping to change at page 59, line 35
<xs:enumeration value="Network"/> <xs:enumeration value="Network"/>
<xs:enumeration value="Content"/> <xs:enumeration value="Content"/>
<xs:enumeration value="OfficialBusiness"/> <xs:enumeration value="OfficialBusiness"/>
<xs:enumeration value="Other"/> <xs:enumeration value="Other"/>
<xs:enumeration value="ext-value"/> <xs:enumeration value="ext-value"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
<xs:attribute name="ext-type" <xs:attribute name="ext-type"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
<xs:attribute name="restriction" type="iodef:restriction-type"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<!--Used to include an enveloped XML document in RID-->
<xs:element name="ReportSchema" type="iodef-rid:ReportSchemaType"/>
<xs:complexType name="ReportSchemaType">
<xs:sequence>
<xs:element ref="iodef-rid:XMLDocument" minOccurs="1"
maxOccurs="1"/>
<xs:element ref="iodef:URL" minOccurs="0"
maxOccurs="1"/>
<xs:element ref="iodef-rid:DetachedSignature" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Version" use="optional">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="1.0"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-Version"
type="xs:string" use="optional"/>
<xs:attribute name="XMLSchemaID" use="optional">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="urn:ietf:params:xml:ns:iodef-1.0"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-XMLSchemaID"
type="xs:string" use="optional"/>
</xs:complexType>
<xs:element name="XMLDocument"
type="iodef:ExtensionType"/>
<xs:element name="DetachedSignature"
type="iodef:ExtensionType"/>
</xs:schema> </xs:schema>
9. Security Requirements 9. Security Requirements
9.1. XML Digital Signatures and Encryption 9.1. XML Digital Signatures and Encryption
RID leverages existing security standards and data markings in RID leverages existing security standards and data markings in
RIDPolicy to achieve the required levels of security for the exchange RIDPolicy to achieve the required levels of security for the exchange
of incident information. The use of standards include TLS and the of incident information. The use of standards include TLS and the
XML security features of encryption [XMLencrypt] and digital XML security features of encryption [XMLencrypt] and digital
skipping to change at page 57, line 5 skipping to change at page 61, line 14
authentication to all upstream participants in the trace or those authentication to all upstream participants in the trace or those
involved in the investigation. All instances of RecordItem involved in the investigation. All instances of RecordItem
provided by the originator may be individually signed, and provided by the originator may be individually signed, and
additional RecordItem entries by upstream peers in the trace or additional RecordItem entries by upstream peers in the trace or
investigation may be signed by the peer adding the data, while investigation may be signed by the peer adding the data, while
maintaining the original RecordItem entry(s) and detached maintaining the original RecordItem entry(s) and detached
signature(s) from the original requestor. It is important to note signature(s) from the original requestor. It is important to note
that the data is signed at the RecordItem level. Since multiple that the data is signed at the RecordItem level. Since multiple
RecordItems may exist within an IODEF document and may originate RecordItems may exist within an IODEF document and may originate
from different sources, the signature is applied at the RecordItem from different sources, the signature is applied at the RecordItem
level to enable the use of an XML detached signature. This level to enable the use of an XML detached signature. Exclusive
signature MUST be passed to all recipients of the TraceRequest or canonicalization is REQUIRED as the XML document generated is then
Investigation request. included in the RID message within the DetachedSignature element
of the ReportSchema class. This signature MUST be passed to all
recipients of the TraceRequest or Investigation request.
o If an Investigation or TraceRequest does not include a RecordItem o If an Investigation or TraceRequest does not include a RecordItem
entry, a timestamp MUST be used to ensure there is data to be entry, a timestamp MUST be used to ensure there is data to be
signed for the multi-hop authentication use case. The DateTime signed for the multi-hop authentication use case. The DateTime
element of the IODEF:RecordItem class, [RFC5070] Section3.19.1, is element of the IODEF:RecordItem class, [RFC5070] Section3.19.1, is
used for this purpose. used for this purpose.
o For all message types, the full IODEF/RID document MUST be signed o For all message types, the full IODEF/RID document MUST be signed
using an enveloped signature by the sending peer to provide using an enveloped signature by the sending peer to provide
authentication and integrity to the receiving RID system. authentication and integrity to the receiving RID system.
skipping to change at page 69, line 40 skipping to change at page 74, line 4
understanding of the usage of RID security, policy, and privacy understanding of the usage of RID security, policy, and privacy
options discussed in this section. The formality, requirements, and options discussed in this section. The formality, requirements, and
complexity of the agreements for the certificate policy, practices, complexity of the agreements for the certificate policy, practices,
and the use of RID options SHOULD be decided by the entities or and the use of RID options SHOULD be decided by the entities or
consortiums creating those agreements. consortiums creating those agreements.
11. IANA Considerations 11. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
[XMLschema] conforming to a registry mechanism described in [XMLschema] conforming to a registry mechanism described in
[RFC3688]. [RFC3688].
Registration request for the iodef-rid namespace: Registration request for the iodef-rid namespace:
URI: urn:ietf:params:xml:ns:iodef-rid-1.1 URI: urn:ietf:params:xml:ns:iodef-rid-1.2
Registrant Contact: See the "Author's Address" section of this Registrant Contact: See the "Author's Address" section of this
document. document.
XML: None. Namespace URIs do not represent an XML specification. XML: None. Namespace URIs do not represent an XML specification.
Registration request for the iodef-rid XML schema: Registration request for the iodef-rid XML schema:
URI: urn:ietf:params:xml:schema:iodef-rid-1.1 URI: urn:ietf:params:xml:schema:iodef-rid-1.2
Registrant Contact: See the "Author's Address" section of this Registrant Contact: See the "Author's Address" section of this
document. document.
XML: See Section 8, "RID Schema Definition", of this document. XML: See Section 8, "RID Schema Definition", of this document.
Request for managing a namespace list:
Additional namespaces need to be registered to an IANA repository
to extend the enumerated list for the attributes in the
ReportSchema class. The initial list of the namespaces is limited
to one, defined in IODEF [RFC5070], which is included as an
accepted enumerated value for the appropriate attributes.
12. Summary 12. Summary
Security incidents have always been difficult to trace as a result of Security incidents have always been difficult to trace as a result of
the spoofed sources, resource limitations, and bandwidth utilization the spoofed sources, resource limitations, and bandwidth utilization
problems. Incident response is often slow even when the IP address problems. Incident response is often slow even when the IP address
is known to be valid because of the resources required to notify the is known to be valid because of the resources required to notify the
responsible party of the attack and then to stop or mitigate the responsible party of the attack and then to stop or mitigate the
attack traffic. Methods to identify and trace attacks near real time attack traffic. Methods to identify and trace attacks near real time
are essential to thwarting attack attempts. Network providers need are essential to thwarting attack attempts. Network providers need
policies and automated methods to combat the hacker's efforts. SPs policies and automated methods to combat the hacker's efforts. SPs
 End of changes. 70 change blocks. 
292 lines changed or deleted 512 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/