draft-ietf-mile-rfc6045-bis-05.txt   draft-ietf-mile-rfc6045-bis-06.txt 
MILE Working Group K. Moriarty MILE Working Group K. Moriarty
Internet-Draft EMC Internet-Draft EMC
Obsoletes: 6045 (if approved) January 1, 2012 Obsoletes: 6045 (if approved) January 16, 2012
Intended status: Standards Track Intended status: Standards Track
Expires: July 4, 2012 Expires: July 19, 2012
Real-time Inter-network Defense (RID) Real-time Inter-network Defense (RID)
draft-ietf-mile-rfc6045-bis-05.txt draft-ietf-mile-rfc6045-bis-06.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 July 4, 2012. This Internet-Draft will expire on July 19, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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 . . . . . . . . . . . . . . . . 7
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . 9
3.1. Inter-network Provider RID Messaging . . . . . . . . . . . 10 3.1. Inter-service Provider RID Messaging . . . . . . . . . . . 11
3.2. RID Communication Topology . . . . . . . . . . . . . . . . 12 3.2. RID Communication Topology . . . . . . . . . . . . . . . . 12
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. RID Data Types . . . . . . . . . . . . . . . . . . . . . . 13 4.1. RID Data Types . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. RID Message Types . . . . . . . . . . . . . . . . . . . . 13 4.2. RID Message Types . . . . . . . . . . . . . . . . . . . . 14
5. IODEF-RID Schema . . . . . . . . . . . . . . . . . . . . . . . 14 5. IODEF-RID Schema . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. RIDPolicy Class . . . . . . . . . . . . . . . . . . . . . 17 5.1. RIDPolicy Class . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. ReportSchema . . . . . . . . . . . . . . . . . . . . . 23 5.1.1. ReportSchema . . . . . . . . . . . . . . . . . . . . . 23
5.2. RequestStatus . . . . . . . . . . . . . . . . . . . . . . 25 5.2. RequestStatus . . . . . . . . . . . . . . . . . . . . . . 26
5.3. IncidentSource . . . . . . . . . . . . . . . . . . . . . . 27 5.3. IncidentSource . . . . . . . . . . . . . . . . . . . . . . 28
5.4. RID Name Spaces . . . . . . . . . . . . . . . . . . . . . 28 5.4. RID Name Spaces . . . . . . . . . . . . . . . . . . . . . 29
5.5. Including IODEF or other XML Documents . . . . . . . . . . 28 5.5. Including IODEF or other XML Documents . . . . . . . . . . 29
6. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.5.1. Including XML Schema Documents in RID . . . . . . . . 30
6.1. TraceRequest . . . . . . . . . . . . . . . . . . . . . . . 29 6. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. RequestAuthorization . . . . . . . . . . . . . . . . . . . 31 6.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.2. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 33
6.4. Investigation Request . . . . . . . . . . . . . . . . . . 34 6.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.5. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.4. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.6. IncidentQuery . . . . . . . . . . . . . . . . . . . . . . 37 6.5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7. RID Communication Exchanges . . . . . . . . . . . . . . . . . 38 7. RID Communication Exchanges . . . . . . . . . . . . . . . . . 38
7.1. Upstream Trace Communication Flow . . . . . . . . . . . . 38 7.1. Upstream Trace Communication Flow . . . . . . . . . . . . 39
7.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 40 7.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 42
7.1.2. RequestAuthorization Message Example . . . . . . . . . 45 7.1.2. Acknowledgement Message Example . . . . . . . . . . . 45
7.1.3. Result Message Example . . . . . . . . . . . . . . . . 45 7.1.3. Result Message Example . . . . . . . . . . . . . . . . 46
7.2. Investigation Request Communication Flow . . . . . . . . . 48 7.2. Investigation Request Communication Flow . . . . . . . . . 49
7.2.1. Investigation Request Example . . . . . . . . . . . . 49 7.2.1. Investigation Request Example . . . . . . . . . . . . 50
7.2.2. RequestAuthorization Message Example . . . . . . . . . 51 7.2.2. Acknowledgement Message Example . . . . . . . . . . . 52
7.3. Report Communication Flow . . . . . . . . . . . . . . . . 52 7.3. Report Communication Flow . . . . . . . . . . . . . . . . 53
7.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 52 7.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 53
7.4. IncidentQuery Communication Flow . . . . . . . . . . . . . 54 7.4. Query Communication Flow . . . . . . . . . . . . . . . . . 55
7.4.1. IncidentQuery Example . . . . . . . . . . . . . . . . 55 7.4.1. Query Example . . . . . . . . . . . . . . . . . . . . 56
8. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 56 8. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 57
9. Security Requirements . . . . . . . . . . . . . . . . . . . . 60 9. Security Requirements . . . . . . . . . . . . . . . . . . . . 61
9.1. XML Digital Signatures and Encryption . . . . . . . . . . 60 9.1. XML Digital Signatures and Encryption . . . . . . . . . . 61
9.2. Message Transport . . . . . . . . . . . . . . . . . . . . 64 9.2. Message Transport . . . . . . . . . . . . . . . . . . . . 65
9.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 65 9.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 66
9.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 65 9.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 67
9.3.2. Multi-Hop TraceRequest Authentication . . . . . . . . 66 9.3.2. Multi-Hop Request Authentication . . . . . . . . . . . 68
9.4. Consortiums and Public Key Infrastructures . . . . . . . . 67 9.4. Consortiums and Public Key Infrastructures . . . . . . . . 69
9.5. Privacy Concerns and System Use Guidelines . . . . . . . . 68 9.5. Privacy Concerns and System Use Guidelines . . . . . . . . 70
10. Security Considerations . . . . . . . . . . . . . . . . . . . 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 75
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78
13.1. Normative References . . . . . . . . . . . . . . . . . . . 75 13.1. Normative References . . . . . . . . . . . . . . . . . . . 78
13.2. Informative References . . . . . . . . . . . . . . . . . . 76 13.2. Informative References . . . . . . . . . . . . . . . . . . 79
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 80
1. Introduction 1. Introduction
This document moves Real-time Inter-network Defense (RID) [RFC6045] Organizations require help from other parties to identify incidents,
to Historic status as it provides minor updates. Organizations mitigate malicious activity targeting their computing resources, and
require help from other parties to identify incidents, mitigate to gain insight into potential threats through the sharing of
malicious activity targeting their computing resources, and to gain information. This coordination might entail working with a service
insight into potential threats through the sharing of information. provider (SP) to filter attack traffic, working with a SP to resolve
This coordination might entail working with a service provider (SP) a configuration issue unintentionally causing problems, contacting a
to filter attack traffic, working with a SP to resolve a
configuration issue unintentionally causing problems, contacting a
remote site to take down a bot- network, or sharing watch-lists of remote site to take down a bot- network, or sharing watch-lists of
known malicious IP addresses in a consortium. The term SP is to be known malicious IP addresses in a consortium. The term SP is to be
interpreted as any type of service provider or CSIRT that may be interpreted as any type of service provider or CSIRT that may be
involved in RID communications. involved in RID communications.
Incident handling involves the detection, reporting, identification, Incident handling involves the detection, reporting, identification,
and mitigation of an incident, whether it be a benign configuration and mitigation of an incident, whether it be a benign configuration
issue, IT incident, an infraction to a service level agreement (SLA), issue, IT incident, an infraction to a service level agreement (SLA),
system compromise, socially engineered phishing attack, or a denial- system compromise, socially engineered phishing attack, or a denial-
of-service (DoS) attack, etc.. When an incident is detected, the of-service (DoS) attack, etc.. When an incident is detected, the
skipping to change at page 5, line 33 skipping to change at page 5, line 31
achieve a necessary level of security. achieve a necessary level of security.
Coordinating with other CSIRTs is not strictly a technical problem. Coordinating with other CSIRTs is not strictly a technical problem.
There are numerous procedural, trust, and legal considerations that There are numerous procedural, trust, and legal considerations that
might prevent an organization from sharing information. RID provides might prevent an organization from sharing information. RID provides
information and options that can be used by organizations who must information and options that can be used by organizations who must
then apply their own policies for sharing information. Organizations then apply their own policies for sharing information. Organizations
must develop policies and procedures for the use of the RID protocol must develop policies and procedures for the use of the RID protocol
and IODEF. and IODEF.
This specification obsoletes [RFC6045]. Differences from [RFC6045] This document contains the following changes with respect to its
are summarized below: predecessor [RFC6045]:
o This document is on standards track while [RFC6045] was o This document is on standards track while [RFC6045] was
informational, but now it is historic. informational, but now it is historic.
o This document, when published, obsoletes [RFC6045] and moves it to
Historic status.
o This document refers to the updated RID transport specification
[RFC6046-bis], where appropriate.
o Edits reflected in this updated version of RID are primarily o Edits reflected in this updated version of RID are primarily
improvements to the informational descriptions. The descriptions improvements to the informational descriptions. The descriptions
have been updated to clarify the use of IODEF and RID extend for have been updated to clarify the use of IODEF and RID extend for
all types of incidents and are not limited to network security all types of incidents and are not limited to network security
incidents. The language has been updated to reduce a focus on incidents. The language has been updated to reduce a focus on
attacks and instead on incidents where appropriate. The term attacks and instead on incidents where appropriate. The term
network provider has been replaced with the more generic term of network provider has been replaced with the more generic term of
service provider. Several introductory informational sections service provider. Several introductory informational sections
have been removed as they are not necessary for the implementation have been removed as they are not necessary for the implementation
of the protocol. The sections include: of the protocol. The sections include:
skipping to change at page 6, line 14 skipping to change at page 6, line 18
* 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 has updates that o The schema version was incremented. The schema has changed to
include IODEF [RFC5070] enveloped in RID via the ReportSchema include IODEF [RFC5070] enveloped in RID in the RIDPolicy class
class contained in the RIDPolicy class, updates for reported using the new ReportSchema class, to include reported errata, to
errata, and an additional enumeration in the RIDPolicy class for include an additional enumeration in the RIDPolicy class for
'LawEnforcement'. Additional text has been provided to clarify 'LawEnforcement', to include additional enumerations in the
definitions of enumerated values for some attributes. Justification attribute, and to change the name of the
RequestAuthorization MsgType to Acknowledgement. Additional text
has been provided to clarify definitions of enumerated values for
some attributes. The RequestAuthorization name was replaced with
Acknowledgement to more accurately represent the function of that
message type. Text was clarified to note the possible use of this
message in response to Query and Report messages. The attributes
were fixed in the schema to add 'lang' at the RID class level for
language support.
o The TraceRequest and Investigation messages have been collapsed
into a single message with the requirement to set the MsgType
according to the functionality required for automation. The
message descriptions were identical with with exception of the
MsgType, which remains an exception depending on the desired
function. Since both of the enumerations for MsgType are each a
Request, 'Investigation' is now 'InvestigationRequest'. Content
may vary within the IODEF document for the type of Request
specified.
o The IncidentQuery message description name and MsgType enumeration
value in the schema has been changed to the more generic name of
'Query'.
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.
o The order in which the RID Schema is presented in Section 5 has o The order in which the RID Schema is presented in Section 5 has
been changed to match the order in the IODEF-RID schema. been changed to match the order in the IODEF-RID schema.
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.
o Additional references have been provided to improve
interoperability with stricter guidance on the use of XML digital
signatures and encryption.
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.
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 An incident may be defined as a benign configuration issue, IT
or to find a point on the network as close to the origin of the incident, an infraction to a service level agreement (SLA), system
incident as possible. An incident may be defined as a benign compromise, a worm or Trojan infection, or a single- or multiple-
configuration issue, IT incident, an infraction to a service level source denial-of-service attack. The goal of tracing a security
agreement (SLA), system compromise, a worm or Trojan infection, or a incident may be to identify the source or to find a point on the
single- or multiple-source denial-of-service attack. Incident network as close to the origin of the incident as possible. Incident
tracing can be used to identify the source(s) of an attack in order tracing can be used to identify the source(s) of an attack in order
to halt or mitigate the undesired behavior or to correct an to halt or mitigate the undesired behavior or to correct an
identified issue. RID messages can be communicated between entities identified issue. RID messages can be communicated between entities
to report or investigate any type of incident and allows for actions to report or investigate any type of incident and allows for actions
to be taken when the source of the incident or a point closer to the to be taken when the source of the incident or a point closer to the
source is known or has been identified. The purpose of tracing an source is known or has been identified. Methods to accomplish
incident is to remedy the detected issue, halt, or mitigate the mitigation may include remediation of a configuration issue,
effects of the incident. Methods to accomplish this may include filtering or rate-limiting the traffic close to the source, or taking
remediation of a configuration issue, filtering or rate-limiting the the host or network offline. Care must also be taken to ensure that
traffic close to the source, or taking the host or network offline. the systems involved in the RID communications are not abused and to
Care must also be taken to ensure that the systems involved in the use proper analysis in determining if attack traffic is, in fact,
RID communications are not abused and to use proper analysis in attack traffic at each SP involved in the investigation.
determining if attack traffic is, in fact, attack traffic at each SP
along the path of a trace.
Tracing security incidents can be a difficult task since attackers go Investigating security incidents can be a difficult task since
to great lengths to obscure their identity. In the case of a attackers go to great lengths to obscure their identity. In the case
security incident, the true source might be identified through an of a security incident, the true source might be identified through
existing established connection to the attacker's point of origin. an existing established connection to the attacker's point of origin.
However, the attacker may not connect to the compromised system for a However, the attacker may not connect to the compromised system for a
long period of time after the initial compromise or may access the long period of time after the initial compromise or may access the
system through a series of compromised hosts spread across the system through a series of compromised hosts spread across the
network. Other methods of obscuring the source may include targeting network. Other methods of obscuring the source may include targeting
the host with the same attack from multiple sources using both valid the host with the same attack from multiple sources using both valid
and spoofed source addresses. This tactic can be used to compromise and spoofed source addresses. This tactic can be used to compromise
a machine and leave the difficult task of locating the true origin a machine and leave the difficult task of locating the true origin
for the administrators. Attackers use many techniques which can vary for the administrators. Attackers use many techniques which can vary
between individuals or even organized groups of attackers. Through between individuals or even organized groups of attackers. Through
analysis, the techniques may be grouped into indicators of compromise analysis, the techniques may be grouped into indicators of compromise
skipping to change at page 8, line 44 skipping to change at page 9, line 23
IODEF, any extensions to IODEF, and RID can be used to detail an IODEF, any extensions to IODEF, and RID can be used to detail an
incident, characteristics of the incident (as it evolves), the incident, characteristics of the incident (as it evolves), the
incident history, and communications of the incident to facilitate incident history, and communications of the incident to facilitate
the resolution and reporting of the incident. the resolution and reporting of the incident.
3. Communication between CSIRTs and Service Providers 3. Communication between CSIRTs and Service Providers
Expediting the communication between CSIRTs and SPs is essential when Expediting the communication between CSIRTs and SPs is essential when
responding to a security-related incident, which may cross network responding to a security-related incident, which may cross network
access points between service or network providers. As a result of access points between service providers. As a result of the urgency
the urgency involved in this inter-service provider security incident involved in this inter-service provider security incident
communication, there must be an effective system in place to communication, there must be an effective system in place to
facilitate the interaction. This communication policy or method facilitate the interaction. This communication policy or method
should involve multiple means of communication to avoid a single should involve multiple means of communication to avoid a single
point of failure. Email is one way to transfer information about the point of failure. Email is one way to transfer information about the
incident, packet traces, etc. However, email may not be received in incident, packet traces, etc. However, email may not be received in
a timely fashion or be acted upon with the same urgency as a phone a timely fashion or be acted upon with the same urgency as a phone
call or other communication mechanism like RID. call or other communication mechanism like RID.
A technical solution to trace traffic across a single service or A technical solution to trace traffic across a single SP may include
network provider may include homegrown or commercial systems for homegrown or commercial systems for which RID messaging must
which RID messaging must accommodate the input requirements. The accommodate the input requirements. The incident handling system
incident handling system used on the service or network provider's used on the SP's backbone by the CSIRT to coordinate the trace across
backbone by the CSIRT to coordinate the trace across the single the single network requires a method to accept, process, and relay
network requires a method to accept, process, and relay RID messages RID messages to the system, as well as to wait for responses from the
to the system, as well as to wait for responses from the system to system to continue the RID request process as appropriate. In this
continue the RID request process as appropriate. In this scenario, scenario, each service provider maintains its own system capable of
each service provider maintains its own system capable of
communicating via RID and integrates with a management station used communicating via RID and integrates with a management station used
for monitoring and analysis. An alternative for providers lacking for monitoring and analysis. An alternative for providers lacking
sufficient resources may be to have a neutral third party with access sufficient resources may be to have a neutral third party with access
to the provider's network resources who could be used to perform the to the provider's network resources who could be used to perform the
incident handling functions. This could be a function of a central incident handling functions. This could be a function of a central
organization operating as a CSIRT for countries as a whole or within organization operating as a CSIRT for countries as a whole or within
a consortium that may be able to provide centralized resources. a consortium that may be able to provide centralized resources.
Consortiums could consist of a group of service providers, CSIRTs, or Consortiums could consist of a group of service providers, CSIRTs, or
other federation that agrees to participate in the RID communication other federation that agrees to participate in the RID communication
skipping to change at page 10, line 32 skipping to change at page 11, line 9
peering or service level agreements. peering or service level agreements.
Procedures for incident handling need to be established and well Procedures for incident handling need to be established and well
known by anyone that may be involved in incident response. The known by anyone that may be involved in incident response. The
procedures should also contain contact information for internal procedures should also contain contact information for internal
escalation procedures, as well as for external assistance groups such escalation procedures, as well as for external assistance groups such
as a CSIRT, CERT Coordination Center (CERT/CC), Global Information as a CSIRT, CERT Coordination Center (CERT/CC), Global Information
Assurance Certification (GIAC), and the FBI or other assisting Assurance Certification (GIAC), and the FBI or other assisting
government organization in the country of the investigation. government organization in the country of the investigation.
3.1. Inter-network Provider RID Messaging 3.1. Inter-service Provider RID Messaging
RID provides a protocol and format that ensures interoperability RID provides a protocol and format that ensures interoperability
between vendors for the implementation of an incident messaging between vendors for the implementation of an incident messaging
mechanism. The messages should meet several requirements in order to mechanism. The messages should meet several requirements in order to
be meaningful as they traverse multiple networks. RID provides the be meaningful as they traverse multiple networks. RID provides the
framework necessary for communication between networks involved in framework necessary for communication between networks involved in
the incident handling, possible traceback, and mitigation of a the incident handling, possible traceback, and mitigation of a
security incident. Several message types described in Section 4.2 security incident. Several message types described in Section 4.2
are necessary to facilitate the handling of a security incident. The are necessary to facilitate the handling of a security incident. The
message types include the Report, IncidentQuery, TraceRequest, message types include the Report, Query, Request, Acknowledgement,
RequestAuthorization, Result, and the Investigation request message. and Result message.
The Report message is used when an incident is to be filed on a RID The Report message is used when an incident is to be filed on a RID
system or associated database, where no further action is required. system or associated database, where no further action is required.
An IncidentQuery message is used to request information on a A Query message is used to request information on a particular
particular incident. A TraceRequest message is used when the source incident. A Request message with options set for a TraceRequest is
of the traffic may have been spoofed. In that case, each network used when the source of the traffic may have been spoofed. In that
provider in the upstream path who receives a TraceRequest will issue case, each SP in the upstream path who receives this Request will
a trace across the network to determine the upstream source of the issue a trace across the network to determine the upstream source of
traffic. The RequestAuthorization and Result messages are used to the traffic. The Acknowledgement and Result messages are used to
communicate the status and result of a TraceRequest or Investigation communicate the status and result of a Request. The Request message
request. The Investigation request message only involves the systems with options set for an InvestigationRequest may be sent to any party
accepting RID communication along the path to the source of the assisting in an incident investigation. The investigation Request
traffic and not the use of network trace systems. The Investigation message leverages the bilateral relationships or a consortium's
request leverages the bilateral relationships or a consortium's
interconnections to mitigate or stop problematic traffic close to the interconnections to mitigate or stop problematic traffic close to the
source. Routes could determine the fastest path to a known source IP source. Routes could determine the fastest path to a known source IP
address in the case of an Investigation request. A message sent address in the case of an investigation Request. A Request message
between RID systems for a TraceRequest or an Investigation request to (TraceRequest or an InvestigationRequest) sent between RID systems to
stop traffic at the source through a bordering network requires the stop traffic at the source through a bordering network requires the
information enumerated below: information enumerated below:
1. Enough information to enable the network administrators to make a 1. Enough information to enable the network administrators to make a
decision about the importance of continuing the trace. decision about the importance of continuing the trace.
2. The incident or IP packet information needed to carry out the 2. The incident or IP packet information needed to carry out the
trace or investigation. trace or investigation.
3. Contact information of the origin of the RID communication. The 3. Contact information of the origin of the RID communication. The
contact information could be provided through the Autonomous contact information could be provided through the Autonomous
System Number (ASN) [RFC1930] or Network Information Center (NIC) System Number (ASN) [RFC1930] or Network Information Center (NIC)
handle information listed in the Registry for Internet Numbers or handle information listed in the Registry for Internet Numbers or
other Internet databases. other Internet databases.
4. Network path information to help prevent any routing loops 4. Network path information to help prevent any routing loops
through the network from perpetuating a trace. If a RID system through the network from perpetuating a trace. If a RID system
receives a TraceRequest containing its own information in the receives a Request with the TraceRequest option set that contains
path, the trace must cease and the RID system should generate an its own information in the path, the trace must cease and the RID
alert to inform the network operations staff that a tracing loop system should generate an alert to inform the network operations
exists. staff that a tracing loop exists.
5. A unique identifier for a single attack. This identifier should 5. A unique identifier for a single attack. This identifier should
be used to correlate traces to multiple sources in a DDoS attack. be used to correlate traces to multiple sources in a DDoS attack.
Use of the communication network and the RID protocol must be for Use of the communication network and the RID protocol must be for
pre-approved, authorized purposes only. It is the responsibility of pre-approved, authorized purposes only. It is the responsibility of
each participating party to adhere to guidelines set forth in both a each participating party to adhere to guidelines set forth in both a
global use policy established through the peering agreements for each global use policy established through the peering agreements for each
bilateral peer or agreed-upon consortium guidelines. The purpose of bilateral peer or agreed-upon consortium guidelines. The purpose of
such policies is to avoid abuse of the system; the policies shall be such policies is to avoid abuse of the system; the policies shall be
developed by a consortium of participating entities. The global developed by a consortium or participating entities. The global
policy may be dependent on the domain it operates under; for example, policy may be dependent on the domain it operates under; for example,
a government network or a commercial network such as the Internet a government network or a commercial network such as the Internet
would adhere to different guidelines to address the individual would adhere to different guidelines to address the individual
concerns. Privacy issues must be considered in public networks such concerns. Privacy issues must be considered in public networks such
as the Internet. Privacy issues are discussed in the Security as the Internet. Privacy issues are discussed in the Security
Requirements section, along with other requirements that must be Requirements section, along with other requirements that must be
agreed upon by participating entities. agreed upon by participating entities.
RID requests must be legitimate incidents and not used for purposes RID requests must be legitimate incidents and not used for purposes
such as sabotage or censorship. An example of such abuse of the such as sabotage or censorship. An example of such abuse of the
system includes a request to rate-limit legitimate traffic to prevent system includes a request to rate-limit legitimate traffic to prevent
information from being shared between users on the Internet information from being shared between users on the Internet
(restricting access to online versions of papers) or restricting (restricting access to online versions of papers) or restricting
access from a competitor's product in order to sabotage a business. access from a competitor's product in order to sabotage a business.
The RID system should be configurable to either require user input or The RID system should be configurable to either require user input or
automatically continue traces. This feature enables a network automatically continue traces. This feature enables a network
manager to assess the available resources before continuing an manager to assess the available resources before continuing an
investigation or trace. If the Confidence rating (provided in IODEF) investigation or trace Request. If the Confidence rating (provided
is low, it may not be in the provider's best interest to continue the in IODEF) is low, it may not be in the provider's best interest to
investigation or trace. The Confidence ratings must adhere to the continue the investigation or trace Request. The Confidence ratings
specifications for selecting the percentage used to avoid abuse of must adhere to the specifications for selecting the percentage used
the system. TraceRequests must be issued by authorized individuals to avoid abuse of the system. Requests must be issued by authorized
from the initiating CSIRT, set forth in policy guidelines established individuals from the initiating CSIRT, set forth in policy guidelines
through peering or a SLA. established through peering or a SLA.
3.2. RID Communication Topology 3.2. RID Communication Topology
The most basic topology for communicating RID systems is a direct The most basic topology for communicating RID systems is a direct
connection or a bilateral relationship as illustrated below. connection or a bilateral relationship as illustrated below.
___________ __________ ___________ __________
| | | | | | | |
| RID |__________-------------___________| RID | | RID |__________-------------___________| RID |
|_________| | SP Border | |________| |_________| | SP Border | |________|
skipping to change at page 13, line 22 skipping to change at page 13, line 45
Direct connection to network that is not an immediate network peer Direct connection to network that is not an immediate network peer
Figure 2: Mesh Peer Topology Figure 2: Mesh Peer Topology
By using a fully meshed model in a consortium, broadcasting RID By using a fully meshed model in a consortium, broadcasting RID
requests would be possible, but not advisable. By broadcasting a requests would be possible, but not advisable. By broadcasting a
request, RID peers that may not have carried the attack traffic on request, RID peers that may not have carried the attack traffic on
their network would be asked to perform a trace for the potential of their network would be asked to perform a trace for the potential of
decreasing the time in which the true source was identified. As a decreasing the time in which the true source was identified. As a
result, many networks would have utilized unnecessary resources for a result, many networks would have utilized unnecessary resources for a
TraceRequest that may have also been unnecessary. Request that may have also been unnecessary.
A star topology may be desirable in instances where a peer may be a A star topology may be desirable in instances where a peer may be a
provider of incident information. This requires trust relationships provider of incident information. This requires trust relationships
to be established between the provider of information and each of the to be established between the provider of information and each of the
consumers of that information. Examples may include country level consumers of that information. Examples may include country level
CSIRTs or service providers distributing incident information to CSIRTs or service providers distributing incident information to
organizations. organizations.
4. Message Formats 4. Message Formats
skipping to change at page 13, line 48 skipping to change at page 14, line 22
4.1.1. Boolean 4.1.1. Boolean
A boolean value is represented by the BOOLEAN data type. A boolean value is represented by the BOOLEAN data type.
The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
the schema. the schema.
4.2. RID Message Types 4.2. RID Message Types
The six RID message types described below MUST be implemented. RID The five RID message types described below MUST be implemented. RID
messages uses both the IODEF [RFC5070] and RID document, which MUST messages uses both the IODEF [RFC5070] and RID document, which MUST
be encapsulated for transport as specified in [RFC6046-bis]. The be encapsulated for transport as specified in [RFC6046-bis]. The
messages are generated and received on designated systems for RID messages are generated and received on designated systems for RID
communications. Each RID message type, along with an example, is communications. Each RID message type, along with an example, is
described in the following sections. The IODEF-RID schema is described in the following sections. The IODEF-RID schema is
introduced in Section 5 to support the descried RID message types. introduced in Section 5 to support the described RID message types.
1. TraceRequest. This message is sent to the next provider in the 1. Request. This message type is used for an investigation or trace
upstream trace. It is used to initiate a TraceRequest or to Request is needed. The purpose of the investigation Request
continue a TraceRequest to an upstream provider closer to the message is to leverage the existing peer relationships in order
source address of the origin of the security incident. The to notify the SP closest to the source of the valid traffic of a
TraceRequest triggers a traceback on the network to locate the security-related incident for any necessary actions to be taken.
source of the attack traffic. The Request for a trace request is used when the traffic has to
be traced iteratively through networks to find the source by
setting the MsgType to 'TraceRequest'. The
'InvestigationRequest' MsgType is used for all other Request
messages.
2. RequestAuthorization. This message is sent to the initiating RID 2. Acknowledgement. This message is sent to the initiating RID
system from each of the upstream providers' RID systems to system from each of the upstream providers' RID systems to
provide information on the request status in the current network. provide information on the status of a Request. The
Acknowledgement is also used to provide a reason why a Request,
3. Result. This message is sent to the initiating CSIRT through the Report, or Query was not accepted.
network of RID systems in the path of the trace as notification
that the source of the attack was located. The Result message is
also used to provide the notification of actions taken for an
Investigation request.
4. Investigation. This message type is used when the source of the 3. Result. The Result message is used to provide a final report and
traffic is believed not to be spoofed. The purpose of the the notification of actions taken for a Request. This message is
Investigation request message is to leverage the existing peer sent to the initiating CSIRT through the network of RID systems
relationships in order to notify the network provider closest to in the path of the trace as notification that the source of the
the source of the valid traffic of a security-related incident attack was located.
for any necessary actions to be taken.
5. Report. This message is used to report a security incident, for 4. Report. This message is used to report a security incident, for
which no action is requested. This may be used for the purpose which no action is requested. This may be used for the purpose
of correlating attack information by CSIRTs, sharing incident of correlating attack information by CSIRTs, sharing incident
information, statistics and trending information, etc. information, statistics and trending information, etc.
6. IncidentQuery. This message is used to request information about 5. Query. This message is used to request information about an
an incident or incident type from a trusted system communicating incident or incident type from a trusted system communicating via
via RID. The response is provided through the Report message. RID. The response is provided through the Report message.
When an application receives a RID message, it must be able to When an application receives a RID message, it must be able to
determine the type of message and parse it accordingly. The message determine the type of message and parse it accordingly. The message
type is specified in the RIDPolicy class. The RIDPolicy class may type is specified in the RIDPolicy class. The RIDPolicy class may
also be used by the transport protocol to facilitate the also be used by the transport protocol to facilitate the
communication of security incident data to trace, investigate, query, communication of security incident data to trace, investigate, query,
or report information regarding security incidents. or report information regarding security incidents.
5. IODEF-RID Schema 5. IODEF-RID Schema
There are three classes included in the RID extension required to There are three classes included in the RID extension required to
facilitate RID communications. The RequestStatus class is used to facilitate RID communications. The RequestStatus class is used to
indicate the approval status of a TraceRequest or Investigation indicate the approval status of a Request message; the IncidentSource
request; the IncidentSource class is used to report whether or not a class is used to report whether or not a source was found and to
source was found and to identify the source host(s) or network(s); identify the source host(s) or network(s); and the RIDPolicy class
and the RIDPolicy class provides information on the agreed-upon provides information on the agreed-upon policies and specifies the
policies and specifies the type of communication message being used. type of communication message being used.
The RID schema defines communication specific metadata to support the The RID schema defines communication specific metadata to support the
exchange of incident information in an IODEF document. The intent in exchange of incident information in an IODEF document. The intent in
maintaining a separate schema and not using the AdditionalData maintaining a separate schema and not using the AdditionalData
extension of IODEF is the flexibility of sending messages between RID extension of IODEF is the flexibility of sending messages between RID
hosts. Since RID is a separate schema and RID messages include both hosts. Since RID is a separate schema and RID messages include both
the RID and IODEF schemas, the RID message acts as an envelope in the RID and IODEF documents, the RID message acts as an envelope in
that policy and security defined at the RID message layer are applied that policy and security defined at the RID message layer are applied
to both documents. One reason for maintaining separate schemas is to both documents. One reason for maintaining separate schemas is
for flexibility, where the RIDPolicy class can be easily extracted for flexibility, where the RIDPolicy class can be easily extracted
for use in the RID message and by the transport protocol. for use in the RID message and by the transport protocol.
The security requirements of sending incident information between The security requirements of sending incident information between
entities include the use of encryption. The RIDPolicy information is entities include the use of encryption. The RIDPolicy information is
not required to be encrypted, so separating out this data from the not required to be encrypted, so separating out this data from the
IODEF XML document removes the need for decrypting and parsing the IODEF XML document removes the need for decrypting and parsing the
IODEF document to determine how it should be handled at each RID IODEF document to determine how it should be handled at each RID
host. host.
The purpose of the RIDPolicy class is to specify the message type for The purpose of the RIDPolicy class is to specify the message type for
the receiving host, facilitate the policy needs of RID, and provide the receiving host, facilitate the policy needs of RID, and provide
routing information in the form of an IP address of the destination routing information in the form of an IP address of the destination
RID system. RID system.
The policy information and guidelines are discussed in Section 9.7. The security requirements and policy guidelines are discussed in
The policy is defined between RID peers and within or between Section 9. The policy is defined between RID peers and within or
consortiums. The RIDPolicy is meant to be a tool to facilitate the between consortiums. RIDPolicy is meant to be a tool to facilitate
defined policies. This MUST be used in accordance with policy set the defined policies. This MUST be used in accordance with policy
between clients, peers, consortiums, and/or regions. Security, set between clients, peers, consortiums, and/or regions. Security,
privacy, and confidentiality MUST be considered as specified in this privacy, and confidentiality MUST be considered as specified in this
document. document.
The RID schema is defined as follows: The RID schema is defined as follows:
+------------------+ +------------------+
| RID | | RID |
+------------------+ +------------------+
| ANY | | |
| |<>---{0..1}----[ RIDPolicy ] | ENUM lang |<>---{0..1}----[ RIDPolicy ]
| ENUM restriction | | |
| ENUM type |<>---{0..1}----[ RequestStatus ] | |<>---{0..1}----[ RequestStatus ]
| STRING meaning | | |
| |<>---{0..1}----[ IncidentSource ] | |<>---{0..1}----[ IncidentSource ]
+------------------+ +------------------+
Figure 3: The RID Schema Figure 3: The RID Schema
The aggregate classes that constitute the RID schema in the iodef-rid The aggregate classes that constitute the RID schema in the iodef-rid
namespace are as follows: namespace are as follows:
RIDPolicy RIDPolicy
Zero or One. The RIDPolicy class is used by all message types to Zero or One. The RIDPolicy class is used by all message types to
facilitate policy agreements between peers, consortiums, or facilitate policy agreements between peers, consortiums, or
federations, as well as to properly route messages. federations, as well as to properly route messages.
RequestStatus RequestStatus
Zero or One. The RequestStatus class is used only in Zero or One. The RequestStatus class is used only in
RequestAuthorization messages to report back to the CSIRT or SP Acknowledgement messages. The message reports back to the CSIRT
originating the RID trace will be continued by each RID system or SP in the Acknowledgement message to provide status on a
that received a TraceRequest in the path to the source of the Request or if an error or problem occurs with the receipt or
traffic. processing of a Report, Query, or Result message.
IncidentSource IncidentSource
Zero or One. The IncidentSource class is used in the Result Zero or One. The IncidentSource class is used in the Result
message only. The IncidentSource provides the information on the message only. The IncidentSource provides the information on the
identified source host or network of an attack trace or identified source host or network of an attack trace or
investigation. investigation.
Each of the three listed classes may be the only class included in Each of the three listed classes may be the only class included in
the RID class, hence the option for zero or one. In some cases, the RID class, hence the option for zero or one. In some cases,
RIDPolicy MAY be the only class in the RID definition when used by RIDPolicy MAY be the only class in the RID definition when used by
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].
The RID class has one attribute:
lang
REQUIRED. ENUM. A valid language code per [RFC4646]
constrained by the definition of "xs:language". The
interpretation of this code is described in IODEF [RFC5070],
Section 6.
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]. The RIDPolicy Class includes the ability to embed an IODEF or bis]. The RIDPolicy Class includes the ability to embed an IODEF or
other XML schema document in the ReportSchema element. other XML schema document in the ReportSchema element.
+------------------------+ +------------------------+
| RIDPolicy | | RIDPolicy |
+------------------------+ +------------------------+
skipping to change at page 18, line 21 skipping to change at page 18, line 39
region region
REQUIRED. ENUM. The attribute region is used to identify the REQUIRED. ENUM. The attribute region is used to identify the
expected sharing range of the incident information. The region expected sharing range of the incident information. The region
may be within a region or defined by existing relationships such may be within a region or defined by existing relationships such
as those of a consortium or client to service provider. as those of a consortium or client to service provider.
1. ClientToSP. A client initiated the request to their service 1. ClientToSP. A client initiated the request to their service
provider (SP). A client may be an individual, enterprise, or provider (SP). A client may be an individual, enterprise, or
other type of entity (government, commercial, education, other type of entity (government, commercial, education,
etc.). A service provider may be a network, etc.). An SP may be a network, telecommunications,
telecommunications, infrastructure, or other type of service infrastructure, or other type of SP where a client to vendor
provider where a client to vendor relationship has been relationship has been established. The client to vendor
established. The client to vendor relationship will typically relationship will typically have established contracts or
have established contracts or agreements to define agreements to define expectations and trust relationships.
expectations and trust relationships.
2. SPToClient. A service provider (SP) initiated a RID request 2. SPToClient. A service provider (SP) initiated a RID request
or report to a client. A client may be an individual, or report to a client. A client may be an individual,
enterprise, or other type of entity (government, commercial, enterprise, or other type of entity (government, commercial,
education, etc.). A service provider may be a network, education, etc.). An SP may be a network, telecommunications,
telecommunications, infrastructure, or other type of service infrastructure, or other type of SP where a client to vendor
provider where a client to vendor relationship has been relationship has been established. The client to vendor
established. The client to vendor relationship will typically relationship will typically have established contracts or
have established contracts or agreements to define agreements to define expectations and trust relationships.
expectations and trust relationships.
3. IntraConsortium. Incident information that should have no 3. IntraConsortium. Incident information that should have no
restrictions within the boundaries of a consortium with the restrictions within the boundaries of a consortium with the
agreed-upon use and abuse guidelines. A consortium is a well agreed-upon use and abuse guidelines. A consortium is a well
defined group with established members and trust relationships defined group with established members and trust relationships
specific to sharing within that group. A consortium would specific to sharing within that group. A consortium would
typically define the types of data that can be shared in typically define the types of data that can be shared in
advance, expectations on protecting that data, as well as advance, expectations on protecting that data, as well as
having established contractual agreements. Examples of having established contractual agreements. Examples of
Consortiums may include industry focused sharing communities consortiums may include industry focused sharing communities
(Financial, government, research and education, etc.) or cross (financial, government, research and education, etc.) or cross
industry sharing communities (for instance, organizations industry sharing communities (for instance, organizations
within local proximity that form a sharing group). within local proximity that form a sharing group).
4. PeerToPeer. Incident information that should have no 4. PeerToPeer. Incident information that should have no
restrictions between two peers but may require further restrictions between two peers but may require further
evaluation before continuance beyond that point with the evaluation before continuance beyond that point with the
agreed-upon use and abuse guidelines. PeerToPeer agreed-upon use and abuse guidelines. PeerToPeer
communications may involve any two individuals or entities communications may involve any two individuals or entities
that decide to share information directly with each other. that decide to share information directly with each other.
5. BetweenConsortiums. Incident information that should have no 5. BetweenConsortiums. Incident information that should have no
restrictions between consortiums that have established agreed- restrictions between consortiums that have established agreed-
upon use and abuse guidelines. BetweenConsortiums is used upon use and abuse guidelines. BetweenConsortiums is used
when two Consortiums (as defined in IntraConsortium above) when two consortiums (as defined in IntraConsortium above)
share data. The types of data that can be shared share data. The types of data that can be shared
BetweenConsortiums should be identified in their agreements BetweenConsortiums should be identified in their agreements
and contracts along with expectations on how that data should and contracts along with expectations on how that data should
be handled and protected. be handled and protected.
6. AcrossNationalBoundaries. This selection must be set if the 6. AcrossNationalBoundaries. This selection must be set if the
message type will cross national boundaries. message type will cross national boundaries.
AcrossNationalBoundaries is used when data shared may have AcrossNationalBoundaries is used when data shared may have
additional restrictions for handling and protection based on additional restrictions for handling and protection based on
the type of data and where it resides. The IODEF document the type of data and where it resides. The IODEF document
included, as well as any extensions, with the RID message included, as well as any extensions, with the RID message
should indicate the specific restrictions to be considered. should indicate the specific restrictions to be considered.
The national boundary may be defined by existing regulations The national boundary may be defined by existing regulations
or other legal agreements specific to a defined region. The or other legal agreements specific to a defined region. The
use of this AcrossNationalBoundaries is not legally binding use of this AcrossNationalBoundaries is not legally binding
unless contracts and agreements for entities who share data unless contracts and agreements for entities who share data
have deemed it as such through additional definitions that may have deemed it as such through additional definitions that may
include associated handling and protection requirements. include associated handling and protection requirements.
There could be instances of TraceRequest messages where that There could be instances of Request messages (set to
may not be known in advance, but should be known at the TraceRequest) where that may not be known in advance, but
instance where boundaries are crossed during the should be known at the instance where boundaries are crossed
investigation. This must also be set if the security during the investigation. This must also be set if the
requirements of the request is based upon regulations of a security requirements of the request is based upon regulations
specific nation that may not apply to all nations. The of a specific nation that may not apply to all nations. The
stricter requirements should be upheld. This is different stricter requirements should be upheld. This is different
from the "BetweenConsortiums" setting since it may be possible from the "BetweenConsortiums" setting since it may be possible
to have multiple nations as members of the same consortium, to have multiple nations as members of the same consortium,
and this option must be selected if the traffic is of a type and this option must be selected if the traffic is of a type
that may have different restrictions in other nations. that may have different restrictions in other nations.
7. LawEnforcement. This option is used when incident information 7. LawEnforcement. This option is used when incident information
is exchanged with LawEnforcement, local government, or other is exchanged with LawEnforcement, local government, or other
authorities assisting with an investigation. The usage of authorities assisting with an investigation. The usage of
this value is interpreted by the sender, and that this value is interpreted by the sender, and that
skipping to change at page 20, line 15 skipping to change at page 20, line 30
a different nation that the sending entity, the a different nation that the sending entity, the
"AcrossNationalBoundaries" enumeration MUST also be set. "AcrossNationalBoundaries" enumeration MUST also be set.
8. ext-value. An escape value used to extend this attribute. 8. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1. See IODEF [RFC5070], Section 5.1.
TrafficType TrafficType
One or many. REQUIRED. The values for the attribute "type" are One or many. REQUIRED. The values for the attribute "type" are
meant to assist in determining if a trace is appropriate for the meant to assist in determining if a trace is appropriate for the
SP (provider) receiving the request to continue the trace. SP receiving the request to continue the trace. Multiple values
Multiple values may be selected for this element; however, where may be selected for this element; however, where possible, it
possible, it should be restricted to one value that most should be restricted to one value that most accurately describes
accurately describes the traffic type. the traffic type.
type type
REQUIRED. ENUM. The attribute type is used to identify the type REQUIRED. ENUM. The attribute type is used to identify the type
of information included in the RID message or the type of of information included in the RID message or the type of
incident. incident.
1. Attack. This option SHOULD only be selected if the traffic is 1. Attack. This option SHOULD only be selected if the traffic is
related to a information security incident or attack. The related to a information security incident or attack. The
type of attack MUST also be listed in more detail in the IODEF type of attack MUST also be listed in more detail in the IODEF
skipping to change at page 21, line 20 skipping to change at page 21, line 35
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 ReportSchema
Zero or One. The ReportSchema class is used by the message Zero or One. The ReportSchema class is used by the message
types that require the full IODEF schema to be included in the types that require the full IODEF schema to be included in the
RID envelope. Alternate schemas may be included if approved RID envelope. Alternate schemas may be included if approved by
for use with RID by IANA. the Designated Reviewer and registered by IANA for use with
RID.
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.
MsgType MsgType
REQUIRED. ENUM. The type of RID message sent. The six types REQUIRED. ENUM. The type of RID message sent. The five types
of messages are described in Section 4.2 and can be noted as of messages are described in Section 4.2 and can be noted as
one of the six selections below. one of the six selections below, where a Request is set to
either an InvestigationRequest or TraceRequest.
2. TraceRequest. This message may be used to initiate a 2. TraceRequest. This Request message may be used to initiate a
TraceRequest or to continue a TraceRequest to an upstream TraceRequest or to continue a TraceRequest to an upstream
network closer to the source address of the origin of the network closer to the source address of the origin of the
security incident. security incident.
3. RequestAuthorization. This message is sent to the initiating 3. Acknowledgement. This message is sent to the initiating RID
RID system from each of the upstream RID systems to provide system from each of the upstream RID systems to provide
information on the request status in the current network. information on the request status in the current network.
4. Result. This message indicates that the source of the attack 4. Result. This message indicates that the source of the attack
was located and the message is sent to the initiating RID was located and the message is sent to the initiating RID
system through the RID systems in the path of the trace. system through the RID systems in the path of the trace.
5. Investigation. This message type is used when the source of 5. InvestigationRequest. This Request message type is used when
the traffic is believed to be valid. The purpose of the the source of the traffic is believed to be valid. The
Investigation request is to leverage the existing peer or purpose of the InvestigationRequest is to leverage the
consortium relationships in order to notify the network or existing peer or consortium relationships in order to notify
service provider closest to the source of the valid traffic the SP closest to the source of the valid traffic that some
that some event occurred, which may be a security-related event occurred, which may be a security-related incident.
incident.
6. Report. This message is used to report a security incident, 6. Report. This message is used to report a security incident,
for which no action is requested in the IODEF Expectation for which no action is requested in the IODEF Expectation
class. This may be used for the purpose of correlating attack class. This may be used for the purpose of correlating attack
information by CSIRTs, statistics and trending information, information by CSIRTs, statistics and trending information,
etc. etc.
7. IncidentQuery. This message is used to request information 7. Query. This message is used to request information from a
from a trusted RID system about an incident or incident type. trusted RID system about an incident or incident type.
Additionally, there is an extension attribute to add new Additionally, there is an extension attribute to add new
enumerated values: enumerated values:
ext-value. An escape value used to extend this attribute. See ext-value. An escape value used to extend this attribute. See
IODEF [RFC5070], Section 5.1. IODEF [RFC5070], Section 5.1.
MsgDestination MsgDestination
REQUIRED. ENUM. The destination required at this level may REQUIRED. ENUM. The destination required at this level may
either be the RID messaging system intended to receive the either be the RID messaging system intended to receive the
request, or, in the case of an Investigation request, the request, or, in the case of a Request with MsgType set to
source of the incident. In the case of an Investigation 'InvestigationRequest', the source of the incident. In the
request, the RID system that can help stop or mitigate the case of an InvestigationRequest, the RID system that can help
traffic may not be known, and the message may have to traverse stop or mitigate the traffic may not be known, and the message
RID messaging systems by following the routing path to the RID may have to traverse RID messaging systems by following the
system closest to the source of the attack traffic. The Node routing path to the RID system closest to the source of the
element lists either the RID system or the IP address of the attack traffic. The Node element lists either the RID system
source, and the meaning of the value in the Node element is or the IP address of the source, and the meaning of the value
determined by the MsgDestination element. in the Node element is determined by the MsgDestination
element.
1. RIDSystem. The address listed in the Node element of the 1. RIDSystem. The address listed in the Node element of the
RIDPolicy class is the next upstream RID system that will RIDPolicy class is the next upstream RID system that will
receive the RID message. receive the RID message.
2. SourceOfIncident. The address listed in the Node element 2. SourceOfIncident. The address listed in the Node element
of the RIDPolicy class is the incident source. The IP of the RIDPolicy class is the incident source. The IP
address is used to determine the path of systems accepting address is used to determine the path of systems accepting
RID communications that will be used to find the closest RID communications that will be used to find the closest
RID system to the source of an attack in which the IP RID system to the source of an attack in which the IP
address used by the source is believed to be valid and an address used by the source is believed to be valid and a
Investigation request message is used. This is not to be Request message with MsgDst set to InvestigationRequest is
confused with the IncidentSource class, as the defined used. This is not to be confused with the IncidentSource
value here is from an initial trace or Investigation class, as the defined value here is from an initial trace
request, not the source used in a Result message. or investigation Request, not the source used in a Result
message.
3. ext-value. An escape value used to extend this attribute. 3. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1. See IODEF [RFC5070], Section 5.1.
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 5.1.1. ReportSchema
The ReportSchema class is an aggregate class in the RIDPolicy class. The ReportSchema class is an aggregate class in the RIDPolicy class.
The IODEF schema is the approved schema for inclusion in RID messages The IODEF schema is the approved schema for inclusion in RID messages
via the ReportSchema class. via the ReportSchema class.
+-------------------------+ +-------------------------+
| ReportSchema | | ReportSchema |
+-------------------------+ +-------------------------+
| | | |
| ENUM Version | | ENUM Version |
| STRING ext-Version |<>---{1}-------[ XMLDocument ] | STRING ext-Version |<>---{1}-------[ XMLDocumen ]
| ENUM XMLSchemaID | | ENUM XMLSchemaID |
| STRING ext-XMLSchemaID |<>---{0..1}----[ URL ] | STRING ext-XMLSchemaID |<>---{0..1}----[ URL ]
| | | |
| |<>---{0..*}----[ DetachedSignature ] | |<>---{0..*}----[ Signature ]
| | | |
+-------------------------+ +-------------------------+
Figure 5: The ReportSchema Class Figure 5: The ReportSchema Class
The elements that constitute the ReportSchema class are as follows: The elements that constitute the ReportSchema class are as follows:
XMLDocument XMLDocument
One. The XMLDocument is a complete XML document defined by the One. The XMLDocument is a complete XML document defined by the
iodef:ExtensionType class. This class follows the guidelines iodef:ExtensionType class. This class follows the guidelines
in [RFC5070] Section 5 where the data type is set to "xml" and in [RFC5070] Section 5 where the data type is set to "xml" and
meaning is set to "xml" to include an xml document. meaning is set to "xml" to include an xml document.
URL URL
Zero or One. URL. A reference to the XML schema included. The Zero or One. URL. A reference to the XML schema included. The
URL data type is defined in [RFC5070] Section 2.15 as "xs: URL data type is defined in [RFC5070] Section 2.15 as "xs:
anyURI" in the schema. The schemaLocation for IODEF is already anyURI" in the schema. The schemaLocation for IODEF is already
included in the RID schema, so this is not necessary to include included in the RID schema, so this is not necessary to include
a URL for IODEF documents. a URL for IODEF documents. The list of registered schemas for
inclusion will be maintained by IANA.
DetachedSignature Signature
Zero to many. The DetachedSignature includes a complete XML Zero to many. The Signature uses the iodef:ExtensionType class
document with the type specified by the iodef:ExtensionType to enable this element to contain a detached or enveloped
class. This class follows the guidelines in [RFC5070] Section signature. This class follows the guidelines in [RFC5070]
5 where the data type is set to "xml" and meaning is set to Section 5 where the data type is set to "xml" and meaning is
"xml" to include an xml document. This element is used to set to "xml" to include an xml document. This element is used
encapsulate the detached signature based on the iodef: to encapsulate the detached signature based on the iodef:
RecordItem class within the IODEF document to verify the RecordItem class within the IODEF document to verify the
originator of the message. If other schemas are used instead originator of the message or to include the enveloped
of IODEF, they MUST provide guidance on what class to use if a signature. If other schemas are used instead of IODEF, they
detached signature is provided for this purpose. MUST provide guidance on what class to use if a detached
signature is provided for this purpose.
The ReportSchema class has four attributes: The ReportSchema class has four attributes:
Version Version
OPTIONAL. One. The Version attribute is the version number of OPTIONAL. One. The Version attribute is the version number of
the specified XML schema. 1.0 is the only permitted value as the specified XML schema. That schema must be an approved
the IODEF schema is currently 1.0. If a schema that is version of IODEF or a schema registered with IANA for use with
approved by IANA or IODEF 1.0 is included, this attribute MUST RID. The IANA registry for managing schemas other than IODEF
be set. is specified in Section 11.
ext-value. An escape value used to extend this attribute. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1. See IODEF [RFC5070], Section 5.1.
ext-Version ext-Version
OPTIONAL. One. The ext-Version attribute is the version number OPTIONAL. One. The ext-Version attribute is the version number
of the included XML schema. This attribute is used if a schema of the included XML schema. This attribute is used if a schema
other than IODEF or an IANA approved schema that has been added other than IODEF or an IANA registered schema that has been
to the enumerated list for Version is included. added to the enumerated list for Version is included.
XMLSchemaID XMLSchemaID
OPTIONAL. One. The XMLSchemaID attribute is the identifier OPTIONAL. One. The XMLSchemaID attribute is the identifier
(defined namespace) of the XML schema included. The (defined namespace) of the XML schema included. The
XMLSchemaID and Version specify the format of the XMLDocument XMLSchemaID and Version specify the format of the XMLDocument
element. The only permitted value, unless additional schemas element. The only permitted values, include the namespace for
are approved by IANA, is the namespace for IODEF [RFC5070], IODEF [RFC5070], "urn:ietf:params:xml:ns:iodef-1.0", any future
"urn:ietf:params:xml:ns:iodef-1.0". This attribute MUST be set IETF approved versions of IODEF, and any namespace included in
if IODEF or an IANA approved schema is included. the IANA managed list of registered schemas for use with RID.
The IANA registry for managing schemas other than IODEF is
specified in Section 11.
ext-value. An escape value used to extend this attribute. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1. See IODEF [RFC5070], Section 5.1.
ext-XMLSchemaID ext-XMLSchemaID
OPTIONAL. One. The ext-XMLSchemaID attribute is the identifier OPTIONAL. One. The ext-XMLSchemaID attribute is the identifier
(defined namespace) of the XML schema included. The ext- (defined namespace) of the XML schema included. The ext-
XMLSchemaID and Version specify the format of the XMLDocument XMLSchemaID and ext-Version specify the format of the
element and are used if the included schema is not IODEF XMLDocument element and are used if the included schema is not
version 1.0 or an IANA approved schema that has been added to IODEF version 1.0 or an IANA registered schema that has been
the enumerated list for XMLSchemaID. 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 |
skipping to change at page 25, line 50 skipping to change at page 26, line 36
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.
AuthorizationStatus AuthorizationStatus
REQUIRED. ENUM. The listed values are used to provide a REQUIRED. ENUM. The listed values are used to provide a
response to the requesting CSIRT of the status of a response to the requesting CSIRT of the status of a Request,
TraceRequest in the current network. Report, or Query.
1. Approved. The trace was approved and will begin in the 1. Approved. The trace was approved and will begin in the
current SP. current SP.
2. Denied. The trace was denied in the current SP. The next 2. Denied. The trace was denied in the current SP. The next
closest SP can use this message to filter traffic from the closest SP can use this message to filter traffic from the
upstream SP using the example packet to help mitigate the upstream SP using the example packet to help mitigate the
effects of the attack as close to the source as possible. effects of the attack as close to the source as possible.
The RequestAuthorization message must be passed back to the The Acknowledgement message must be passed back to the
originator and a Result message used from the closest SP to originator and a Result message used from the closest SP to
the source to indicate actions taken in the IODEF History the source to indicate actions taken in the IODEF History
class. class.
3. Pending. Awaiting approval; a timeout period has been 3. Pending. Awaiting approval; a timeout period has been
reached, which resulted in this Pending status and reached, which resulted in this Pending status and
RequestAuthorization message being generated. Acknowledgement message being generated.
4. ext-value. An escape value used to extend this attribute. 4. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1. See IODEF [RFC5070], Section 5.1.
Justification Justification
OPTIONAL. ENUM. Provides a reason for a Denied or Pending OPTIONAL. ENUM. Provides a reason for a Denied or Pending
message. message.
2. SystemResource. A resource issue exists on the systems 2. SystemResource. A resource issue exists on the systems
that would be involved in the request. that would be involved in the request.
3. Authentication. The enveloped digital signature [RFC3275] 3. Authentication. The enveloped digital signature [RFC3275]
failed to validate. failed to validate.
4. AuthenticationOrigin. The detached digital signature for 4. AuthenticationOrigin. The detached digital signature for
the original requestor on the RecordItem entry failed to the original requestor on the RecordItem entry failed to
validate. validate.
5. Encryption. Unable to decrypt the request. 5. Encryption. Unable to decrypt the request, report, or
query.
6. Other. There were other reasons this request could not be 6. UnrecognizedFormat. The format of the provided document
was unrecognized.
7. CannotProcess. The document could not be processed.
Reasons may include legal or policy decisions.
8. Other. There were other reasons this request could not be
processed. processed.
7. ext-value. An escape value used to extend this attribute. 9. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1. See IODEF [RFC5070], Section 5.1.
AuthorizationStatus-ext AuthorizationStatus-ext
OPTIONAL. STRING. A means by which to extend the OPTIONAL. STRING. A means by which to extend the
AuthorizationStatus attribute. See IODEF [RFC5070], Section AuthorizationStatus attribute. See IODEF [RFC5070], Section
5.1. 5.1.
Justification-ext Justification-ext
skipping to change at page 27, line 43 skipping to change at page 28, line 38
Node element of this class. Node element of this class.
True. Source of incident was identified. True. Source of incident was identified.
False. Source of incident was not identified. False. Source of incident was not identified.
Node Node
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 specification [RFC5070], Section 3.16.
The base definition of this class is reused from the IODEF
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.2" and registers The RID schema declares a namespace of "iodef-rid-2.0" 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.2" namespace in the top-level element RID-Document. It "iodef-rid-2.0" 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="2.0" lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2" xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xsi:schemaLocation=http://www.iana.org/assignments/xml-registry/ xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
schema/iodef-rid-1.2.xsd"> xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0.xsd">
5.5. Including IODEF or other XML Documents 5.5. Including IODEF or other XML Documents
In order to support the changing activity of CSIRTS, the RID schema In order to support the changing activity of CSIRTS, the RID schema
can include an IODEF or other data model. The IODEF is also can include an IODEF or other data model. The IODEF is also
extensible, enabling the schemas to evolve along with the needs of extensible, enabling the schemas to evolve along with the needs of
CSIRTs. This section discusses how to include the IODEF XML document CSIRTs. This section discusses how to include the IODEF XML document
or other XML documents to leverage the security and trust or other XML documents to leverage the security and trust
relationships established throughout he use of RID. These techniques relationships established through the use of RID. These techniques
are designed so that adding new data will not require a change to the are designed so that adding new data will not require a change to the
RID schema. This approach supports the exchange of private XML RID schema. This approach also supports the exchange of private XML
documents relevant only to a closed consortium. XML documents can be documents relevant only to a closed consortium. XML documents can be
included through the ReportSchema class in the RIDPolicy class. The included through the ReportSchema class in the RIDPolicy class. The
XMLDocument attribute is set to XML to allow for the inclusion of XMLDocument attribute is set to XML to allow for the inclusion of
full IODEF or other XML documents. The following guidelines MUST be full IODEF or other XML documents. The following guidelines MUST be
followed: followed:
1. The included schema MUST define a separate namespace, such as the 1. The included schema MUST define a separate namespace, such as the
declared namespace for IODEF of declared namespace for IODEF of
"urn:ietf:params:xml:ns:iodef-1.0". "urn:ietf:params:xml:ns:iodef-1.0".
skipping to change at page 29, line 14 skipping to change at page 30, line 9
required to provide a resolvable location of their schema. required to provide a resolvable location of their schema.
The examples included in Section 7 demonstrate how an IODEF document The examples included in Section 7 demonstrate how an IODEF document
is included. The included schema, of IODEF is represented in is included. The included schema, of IODEF is represented in
ReportSchema as follows: ReportSchema as follows:
Version: "1.0" Version: "1.0"
XMLSchemaID: "urn:ietf:params:xml:ns:iodef-1.0" XMLSchemaID: "urn:ietf:params:xml:ns:iodef-1.0"
ReferenceURL: "http://www.iana.org/assignments/xml-registry/ URL: "http://www.iana.org/assignments/xml-registry/schema/
schema/iodef-1.0.xsd" iodef-1.0.xsd"
The ReferenceURL is optionally included for IODEF since it is already The URL is optionally included for IODEF since it is already in the
in the RID schema and the schemaLocation is defined. See the IANA RID schema and the schemaLocation is defined.
Considerations section for extending the list of approved XML schemas
to be included in RID for secure XML document exchanges. 5.5.1. Including XML Schema Documents in RID
The Common Vulnerability Reporting Format (CVRF) is an additional
schema registered for inclusion in a RID message. The registered
IANA information for additional schemas MUST include the
specification name, version, specification Uniform Resource
Identifier (URI), and namespace. The following provides an example
of the necessary information for additional schemas beyond IODEF and
CVRF.
Common Vulnerability Reporting Format (CVRF)
Schema Name: CVRF_1.0
Version: 1.0
Namespace: http://www.icasi.org/CVRF/schema/cvrf/1.0
Specification URI: http://www.icasi.org/cvrf
The version attribute of the ReportSchema class is populated with the
approved versions of IODEF, CVRF, and any additional schemas
registered by IANA, see Section 11.
The XMLSchemaID of the ReportSchema class is populated with the
namespace of the included schema. The attribute enumeration values
include the namespace for IODEF and CVRF and any schema registered by
IANA, see Section 11.
The URL element of the ReportSchema class is populated with the
Specification URI value of the included schema.
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
RID as listed for each message type. The IODEF model MUST be fully RID as listed for each message type. The IODEF model MUST be fully
implemented to ensure proper parsing of all RID messages. implemented to ensure proper parsing of all RID messages.
Note: The implementation of RID may automate the ability to fill in Note: The implementation of RID may automate the ability to fill in
the content required for each message type from packet input, the content required for each message type from packet input,
incident data, situational awareness information, or default values incident data, situational awareness information, or default values
such as that used in the EventData class. such as those used in the EventData class.
6.1. TraceRequest 6.1. Request
Description: This message or document is sent to the network Description: This message type is used to request assistance in a
management station next in the upstream trace once the upstream computer security investigation. The investigation Request may be
source of the traffic has been identified. The following information directed to another party that can assist with forensics, continue
is REQUIRED for TraceRequest messages and is provided through: the investigation (incident may have originated on the SP network to
which the Request was sent), or even to an SP to trace the traffic
from an unknown source. The Request message with MsgType set to
'InvestigationRequest' may leverage the existing bilateral peer
relationships in order to notify the SP closest to the source of the
valid traffic that some event occurred, which may be a security-
related incident. A Request message with the MsgType set to
'TraceRequest' may be sent to an upstream peer to trace back through
the network to locate the source of malicious traffic. The following
information is REQUIRED for Request messages and is provided through:
RID Information: RID Information:
RIDPolicy RIDPolicy
RID message type, IncidentID, and destination policy RID message type, IncidentID, and destination policy
information information
IODEF Information: IODEF Information:
Time Stamps (DetectTime, StartTime, EndTime, ReportTime). Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
Incident Identifier (Incident class, IncidentID). Incident Identifier (Incident class, IncidentID).
Confidence rating of security incident (Impact and Confidence Confidence rating of security incident (Impact and Confidence
skipping to change at page 30, line 28 skipping to change at page 32, line 9
Expectation class should be used to request any specific actions Expectation class should be used to request any specific actions
to be taken close to the source. to be taken close to the source.
Path information of nested RID systems, beginning with the request Path information of nested RID systems, beginning with the request
originator used in the trace using IODEF EventData with category originator used in the trace using IODEF EventData with category
set to "infrastructure". set to "infrastructure".
Event, Record, and RecordItem classes to include example packets Event, Record, and RecordItem classes to include example packets
and other information related to the incident. Note: Event and other information related to the incident. Note: Event
information included here requires a second instance of EventData information included here requires a second instance of EventData
in addition to that used to convey service/network provider (SP) in addition to that used to convey SP path contact information.
path contact information.
Standards for encryption and digital signatures [RFC3275], [XMLsig], Standards for encryption and digital signatures [RFC3275], [XMLsig],
[XMLencrypt]: [XMLencrypt]:
Digital signature from initiating CSIRT or provider system sending Digital signature from initiating CSIRT or provider system sending
the RID message, passed to all systems in upstream trace using a the RID message, passed to all systems receiving the Request using
detached XML digital signature on a RecordItem entry. a detached XML digital signature on a RecordItem entry, placed in
an instance of the Signature element.
Digital signature of sending CSIRT or SP for authenticity of the Digital signature of sending CSIRT or SP for authenticity of the
RID message, from the CSIRT or provider creating this message RID message, from the CSIRT or provider creating this message
using an enveloped XML digital signature on the IODEF document. using an enveloped XML digital signature on the IODEF document,
placed in an instance of the Signature element.
XML encryption as required by policy, agreements, and data XML encryption as required by policy, agreements, and data
markers. markers.
Security requirements include the ability to encrypt [XMLencrypt] the
contents of the Request message using the public key of the
destination RID system. The incident number increases whether the
Request message has the MsgDst set to 'InvestigationRequest' or
'TraceRequest' in order to ensure uniqueness within the system. The
relaying peers also append their Autonomous System (AS) or RID system
information using the NPPath element as the Request message was
relayed through SPs. This enables the response (Result message) to
utilize the same path and trust relationships for the return message,
indicating any actions taken. The request is recorded in the state
tables of both the initiating and destination SP RID systems. The
destination SP is responsible for any actions taken as a result of
the request in adherence to any service level agreements or policies.
The SP MUST confirm that the traffic actually originated from the
suspected system before taking any action and confirm the reason for
the request. The request may be sent directly to a known RID system
or routed by the source address of the attack using the message
destination of RIDPolicy, SourceOfIncident. Note: Any intermediate
parties in a TraceRequest MUST be able to view RIDPolicy information
of responding message types in order to properly direct RID messages.
A DDoS attack can have many sources, resulting in multiple traces to A DDoS attack can have many sources, resulting in multiple traces to
locate the sources of the attack. It may be valid to continue locate the sources of the attack. It may be valid to continue
multiple traces for a single attack. The path information enables multiple traces for a single attack. The path information enables
the administrators to determine if the exact trace had already passed the administrators to determine if the exact trace had already passed
through a single network. The Incident Identifier must also be used through a single network. The Incident Identifier must also be used
to identify multiple TraceRequests from a single incident. If a to identify multiple Requests from a single incident. If a single
single TraceRequest results in divergent paths of TraceRequests, a Request results in divergent paths of Requests, a separate instance
separate instance number MUST be used under the same IncidentID. The number MUST be used under the same IncidentID. The IncidentID
IncidentID instance number of IODEF can be used to correlate related instance number of IODEF can be used to correlate related incident
incident data that is part of a larger incident. data that is part of a larger incident.
6.2. RequestAuthorization 6.2. Acknowledgement
Description: This message is sent to the initiating RID system from Description: The Acknowledgement is also used to provide a status to
the next upstream provider's application or system designated for any message type along with a Justification if the message could not
accepting RID communications to provide information on the request be processed for any reason. This message is sent to the initiating
status in the current network. RID system from the next upstream provider's application or system
designated for accepting RID communications to provide information on
the request status in the current SP.
The following information is REQUIRED for RequestAuthorization The following information is REQUIRED for Acknowledgement messages
messages and is provided through: and is provided through:
RID Information: RID Information:
RIDPolicy RIDPolicy
RID message type, IncidentID, and destination policy RID message type, IncidentID, and destination policy
information information
RequestStatus class: RequestStatus class:
Status of TraceRequest Status of Request
Standards for encryption and digital signatures [RFC3275], [XMLsig], Standards for encryption and digital signatures [RFC3275], [XMLsig],
[XMLencrypt]: [XMLencrypt]:
Digital signature of responding CSIRT or provider for authenticity Digital signature of responding CSIRT or provider for authenticity
of Trace Status Message, from the CSIRT or provider creating this of Trace Status Message, from the CSIRT or provider creating this
message using an enveloped XML digital signature. message using an enveloped XML digital signature.
XML encryption as required by policy, agreements, and data XML encryption as required by policy, agreements, and data
markers. markers.
skipping to change at page 32, line 48 skipping to change at page 35, line 7
Trace number - used for multiple traces of a single Trace number - used for multiple traces of a single
incident; MUST be included if the response is specific to an incident; MUST be included if the response is specific to an
instance of an incident. instance of an incident.
Confidence rating of security incident (Impact and Confidence Confidence rating of security incident (Impact and Confidence
class). class).
System class is used to list both the Source and Destination System class is used to list both the Source and Destination
Information used in the attack and must note if the traffic is Information used in the attack and must note if the traffic is
spoofed, thus requiring an upstream TraceRequest in RID. spoofed, thus requiring an upstream Request set to
'TraceRequest' in RID.
History class "atype" attribute is used to note any actions History class "atype" attribute is used to note any actions
taken. taken.
History class also notes any other background information History class also notes any other background information
including notes about the confidence level or rating of the including notes about the confidence level or rating of the
result information. result information.
Path information of nested RID systems, beginning with the Path information of nested RID systems, beginning with the
request originator used in the trace using IODEF EventData with request originator used in the trace using IODEF EventData with
skipping to change at page 33, line 48 skipping to change at page 36, line 7
for the machine(s) discovered as a part of the attack. The filters for the machine(s) discovered as a part of the attack. The filters
may be comprehensive enough to block all Internet access until the may be comprehensive enough to block all Internet access until the
host has taken the appropriate action to resolve any security issues host has taken the appropriate action to resolve any security issues
or to rate-limit the ingress traffic as close to the source as or to rate-limit the ingress traffic as close to the source as
possible. possible.
Security and privacy requirements discussed in Section 9 MUST be Security and privacy requirements discussed in Section 9 MUST be
taken into account. taken into account.
Note: The History class has been expanded in IODEF to accommodate all Note: The History class has been expanded in IODEF to accommodate all
of the possible actions taken as a result of a RID TraceRequest or of the possible actions taken as a result of a RID Request using the
Investigation request using the "iodef:atype", or action type, "iodef:atype", or action type, attribute. The History class should
attribute. The History class should be used to note all actions be used to note all actions taken close to the source of a trace or
taken close to the source of a trace or incident using the most incident using the most appropriate option for the type of action
appropriate option for the type of action along with a description. along with a description. The "atype" attribute in the Expectation
class can also be used to request an appropriate action when a
The "atype" attribute in the Expectation class can also be used to Request is made.
request an appropriate action when a TraceRequest or Investigation
request is made.
6.4. Investigation Request
Description: This message type is used when the source of the traffic
is believed not to be spoofed. The purpose of the Investigation
request message is to leverage the existing bilateral peer
relationships in order to notify the network provider closest to the
source of the valid traffic that some event occurred, which may be a
security-related incident.
The following information is REQUIRED for Investigation request
messages and is provided through:
RID Information:
RID Policy
RID message type, IncidentID, and destination policy
information
IODEF Information:
Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
Incident Identifier (Incident class, IncidentID).
Trace number - used for multiple traces of a single
incident; MUST be included if the InvestigationRequest is an
instance of an incident.
Confidence rating of security incident (Impact and Confidence
class).
System class is used to list both the Source and Destination
Information used in the attack and must note if the traffic is
spoofed, thus requiring an upstream TraceRequest in RID.
Expectation class should be used to request any specific
actions to be taken close to the source.
Path information of nested systems communicating via RID
messages, beginning with the request originator used in the
trace using IODEF EventData with category set to
"infrastructure".
Event, Record, and RecordItem classes to include example
packets and other information related to the incident. Note:
Event information included here requires a second instance of
EventData in addition to that used to convey SP path contact
information.
Standards for encryption and digital signatures [RFC3275],
[XMLsig], [XMLencrypt]:
Digital signature from initiating system sending the RID
message, passed to all systems involved in the investigation
using a detached XML digital signature on a RecordItem entry.
Digital signature of sending CSIRT or SP for authenticity of
the RID message, from the CSIRT or provider sending this
message using an enveloped XML digital signature on the IODEF
document.
XML encryption as required by policy, agreements, and data
markers.
Security requirements include the ability to encrypt [XMLencrypt] the
contents of the Investigation request message using the public key of
the destination RID system. The incident number increases as if it
were a TraceRequest message in order to ensure uniqueness within the
system. The relaying peers also append their Autonomous System (AS)
or RID system information as the request message was relayed along
the web of network providers so that the Result message could utilize
the same path as the set of trust relationships for the return
message, thus indicating any actions taken. The request is recorded
in the state tables of both the initiating and destination SP RID
systems. The destination SP is responsible for any actions taken as
a result of the request in adherence to any service level agreements
or internal policies. The SP MUST confirm that the traffic actually
originated from the suspected system before taking any action and
confirm the reason for the request. The request may be sent directly
to a known RID system or routed by the source address of the attack
using the message destination of RIDPolicy, SourceOfIncident. Note:
All intermediate parties MUST be able to view RIDPolicy information
in order to properly direct RID messages.
6.5. Report 6.4. Report
Description: This message or document is sent to a RID system to Description: This message or document is sent to a RID system to
provide a report of a security incident. This message does not provide a report of a security incident. This message does not
require any actions to be taken, except to file the report on the require any actions to be taken, except to file the report on the
receiving RID system or associated database. receiving RID system or associated database.
The following information is REQUIRED for Report messages and will be The following information is REQUIRED for Report messages and will be
provided through: provided through:
RID Information: RID Information:
skipping to change at page 36, line 40 skipping to change at page 37, line 10
Event, Record, and RecordItem classes to include example Event, Record, and RecordItem classes to include example
packets and other information related to the incident packets and other information related to the incident
(optional). (optional).
Standards for encryption and digital signatures [RFC3275], Standards for encryption and digital signatures [RFC3275],
[XMLsig], [XMLencrypt]: [XMLsig], [XMLencrypt]:
Digital signature from initiating RID system, passed to all Digital signature from initiating RID system, passed to all
systems receiving the report using an enveloped XML digital systems receiving the report using an enveloped XML digital
signature. signature, placed in an instance of the Signature element.
XML encryption as required by policy, agreements, and data XML encryption as required by policy, agreements, and data
markers. markers.
Security requirements include the ability to encrypt [XMLencrypt] the Security requirements include the ability to encrypt [XMLencrypt] the
contents of the Report message using the public key of the contents of the Report message using the public key of the
destination RID system. Senders of a Report message should note that destination RID system. Senders of a Report message should note that
the information may be used to correlate security incident the information may be used to correlate security incident
information for the purpose of trending, pattern detection, etc., and information for the purpose of trending, pattern detection, etc., and
may be shared with other parties unless otherwise agreed upon with may be shared with other parties unless otherwise agreed upon with
the receiving RID system. Therefore, sending parties of a Report the receiving RID system. Therefore, sending parties of a Report
message may obfuscate or remove destination addresses or other message may obfuscate or remove destination addresses or other
sensitive information before sending a Report message. A Report sensitive information before sending a Report message. A Report
message may be sent either to file an incident report or in response message may be sent either to file an incident report or in response
to an IncidentQuery, and data sensitivity must be considered in both to a Query, and data sensitivity must be considered in both cases.
cases. The SP path information is not necessary for this message, as The SP path information is not necessary for this message, as it will
it will be communicated directly between two trusted RID systems. be communicated directly between two trusted RID systems.
6.6. IncidentQuery 6.5. Query
Description: The IncidentQuery message is used to request incident Description: The Query message is used to request incident
information from a trusted RID system. The request can include the information from a trusted RID system. The request can include the
incident number, if known, or detailed information about the incident number, if known, or detailed information about the
incident. If the incident number is known, the Report message incident. If the incident number is known, the Report message
containing the incident information can easily be returned to the containing the incident information can easily be returned to the
trusted requestor using automated methods. If an example packet or trusted requestor using automated methods. If an example packet or
other unique information is included in the IncidentQuery, the return other unique information is included in the Query, the return report
report may be automated; otherwise, analyst intervention may be may be automated; otherwise, analyst intervention may be required.
required.
The following information is REQUIRED for an IncidentQuery message The following information is REQUIRED for a Query message and is
and is provided through: provided through:
RID Information: RID Information:
RID Policy RID Policy
RID message type, IncidentID, and destination policy RID message type, IncidentID, and destination policy
information information
IODEF Information (optional): IODEF Information (optional):
Time Stamps (DetectTime, StartTime, EndTime, ReportTime). Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
Incident Identifier (Incident class, IncidentID). Incident Identifier (Incident class, IncidentID).
Trace number - used for multiple traces of a single Trace number - used for multiple traces of a single
incident; MUST be included if the IncidentQuery is an incident; MUST be included if the Query is an instance of an
instance of an incident. incident.
Confidence rating of security incident (Impact and Confidence Confidence rating of security incident (Impact and Confidence
class). class).
System class is used to list both the Source and Destination System class is used to list both the Source and Destination
Information used in the attack. Information used in the attack.
Event, Record, and RecordItem classes to include example Event, Record, and RecordItem classes to include example
packets and other information related to the incident packets and other information related to the incident
(optional). (optional).
Standards for encryption and digital signatures [RFC3275], Standards for encryption and digital signatures [RFC3275],
[XMLsig], [XMLencrypt]: [XMLsig], [XMLencrypt]:
Digital signature from the CSIRT or SP initiating the RID Digital signature from the CSIRT or SP initiating the RID
message, passed to all systems receiving the IncidentQuery message, passed to all systems receiving the Query using an
using an enveloped XML digital signature. enveloped XML digital signature, placed in an instance of the
Signature element.
XML encryption as required by policy, agreements, and data XML encryption as required by policy, agreements, and data
markers. markers.
The proper response to the IncidentQuery message is a Report message. The proper response to the Query message is a Report message.
Multiple incidents may be returned for a single query if an incident Multiple incidents may be returned for a single query if an incident
type is requested. In this case, the receiving system sends an IODEF type is requested. In this case, the receiving system sends an IODEF
document containing multiple incidents or all instances of an document containing multiple incidents or all instances of an
incident. The system sending the reply may pre-set a limit to the incident. The system sending the reply may pre-set a limit to the
number of documents returned in one report. The recommended limit is number of documents returned in one report. The recommended limit is
5, to prevent the documents from becoming too large. Other transfer 5, to prevent the documents from becoming too large. Other transfer
methods may be suited better than RID for large transfers of data. methods may be better suited than RID for large transfers of data.
The Confidence rating may be used in the IncidentQuery message to The Confidence rating may be used in the Query message to select only
select only incidents with an equal or higher Confidence rating than incidents with an equal or higher Confidence rating than what is
what is specified. This may be used for cases when information is specified. This may be used for cases when information is gathered
gathered on a type of incident but not on specifics about a single on a type of incident but not on specifics about a single incident.
incident. Source and Destination Information may not be needed if Source and Destination Information may not be needed if the Query is
the IncidentQuery is intended to gather data about a specific type of intended to gather data about a specific type of incident.
incident as well.
7. RID Communication Exchanges 7. RID Communication Exchanges
The following section outlines the communication flows for RID and The following section outlines the communication flows for RID and
also provides examples of messages. also provides examples of messages.
The possible set of message exchanges include:
o Request: Asynchronous Request for assistance and/or action to be
taken, MAY involve multiple systems and iterative Requests
MsgType set to InvestigationRequest or TraceRequest
Possible responses:
+ Acknowledgement (OPTIONAL for InvestigationRequest)
+ Result (REQUIRED unless Acknowledgement was set to no)
+ Report (OPTIONAL, zero or more: Report can be sent
unsolicited)
o Query: Synchronous request for information
MsgType set to Query
Possible responses:
+ Acknowledgement (OPTIONAL if yes, required if no Report will
be sent)
+ Report (REQUIRED unless Acknowledgement was set to no)
o Report: Asynchronous information report, may be pushed to systems
or a response from a Query
MsgType set to Report
Possible responses:
+ Acknowledgement (OPTIONAL)
Note: For each example listed below, [RFC5735] addresses were used. Note: For each example listed below, [RFC5735] addresses were used.
Assume that each IP address listed is actually a separate network Assume that each IP address listed is actually a separate network
range held by different SPs. Addresses were used from /27 network range held by different SPs. Addresses were used from /27 network
ranges. ranges.
7.1. Upstream Trace Communication Flow 7.1. Upstream Trace Communication Flow
The diagram below outlines the RID TraceRequest communication flow The diagram below outlines the RID Request communication flow for a
between RID systems on different networks tracing an attack. SP-1, TraceRequest between RID systems on different networks tracing an
SP-2, SP-3 represent service or network providers that are involved attack. The Request message with MsgDst set to 'TraceRequest' is
in the example trace communication flow. represented in the diagram by TraceRequest. SP-1, SP-2, SP-3
represent service providers that are involved in the example trace
communication flow.
Attack Dest SP-1 SP-2 SP-3 Attack Src Attack Dest SP-1 SP-2 SP-3 Attack Src
1. Attack | Attack 1. Attack | Attack
reported | detected reported | detected
2. Initiate trace 2. Initiate trace
3. Locate origin 3. Locate origin
through through
upstream SP upstream SP
4. o---TraceRequest-----> 4. o---TraceRequest----->
5. Trace 5. Trace
Initiated Initiated
6. <-RequestAuthorization-o 6. <---Acknowledgement--o
7. Locate origin 7. Locate origin
through through
upstream SP upstream SP
8. o---TraceRequest---> 8. o---TraceRequest--->
9. Trace Initiated 9. Trace Initiated
10. <----------RequestAuthorization----o 10. <----------Acknowledgement----o
<---RequestAuth---o <-Acknowledgement-o
11. Locate attack 11. Locate attack
source on network X source on network X
12. <------------Result----------------o 12. <------------Result----------------o
13. o- - - - -Acknowledgement- - - - - >
Figure 8: 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 an Acknowledgement message
message is sent to both the downstream peer and the original is sent to both the downstream peer and the original requestor. If a
requestor. If a TraceRequest is denied, the downstream peer has the Request in a traceback is denied, the downstream peer has the option
option to take an action and respond with a Result message. The to take an action and respond with a Result message. The originator
originator of the request may follow up with the downstream peer of of the request may follow up with the downstream peer of the SP
the SP involved using an Investigation request to ensure that an involved using a Request with the MsgType set to
action is taken if no response is received. Nothing precludes the 'InvestigationRequest' to ensure that an action is taken if no
originator of the request from initiating a new TraceRequest response is received. Nothing precludes the originator of the
bypassing the SP that denied the request, if a trace is needed beyond request from initiating a new Request with the MsgType set to
that point. Another option may be for the initiator to send an 'TraceRequest' bypassing the SP that denied the request, if a trace
Investigation request to an SP upstream of the SP that denied the is needed beyond that point. Another option may be for the initiator
request if enough information was gathered to discern the true source to send an 'InvestigationRequest' to an SP upstream of the SP that
of the attack traffic from the incident handling information. denied the request. This action assumes enough information was
gathered to discern the true source of the attack traffic from the
incident handling information.
The proper response to a TraceRequest is a RequestAuthorization The proper response to a TraceRequest is an Acknowledgement message.
message. The RequestAuthorization message lets the requestor know if The Acknowledgement message lets the requestor know if the trace will
the trace will continue through the next upstream network. If there continue through the next upstream network. If there is a problem
is a problem with the request, such as a failure to validate the with the request, such as a failure to validate the digital signature
digital signature or decrypt the request, a RequestAuthorization or decrypt the request, an Acknowledgement message MUST be sent to
message MUST be sent to the requestor and the downstream peer (if the requestor and the downstream peer (if they are not one and the
they are not one and the same) providing the reason why the message same) providing the reason why the message could not be processed.
could not be processed. Assuming that the trace continued, Assuming that the trace continued, additional TraceRequests with the
additional TraceRequests with the response of a RequestAuthorization response of an Acknowledgement message would occur passing the
message would occur passing the request upstream in the path to the request upstream in the path to the source of the traffic related to
source of the traffic related to the incident. Once a source is the incident. Once a source is found, a Result message is sent to
found, a Result message is sent to the originator of the trace, as the originator of the trace, as determined by the SP path information
determined by the SP path information provided through the document provided through the document instance of EventData, where contact is
instance of EventData, where contact is set to "infrastructure". The set to "infrastructure". The SP path information is also used when
SP path information is also used when sending the sending the Acknowledgement messages to the first entry (the trace
RequestAuthorization messages to the first entry (the trace
originator) and the last nested entry (the downstream peer). The originator) and the last nested entry (the downstream peer). The
Result message is encrypted [XMLencrypt] for the originator providing Result message is encrypted [XMLencrypt] for the originator providing
information about the incident source and any actions taken. If the information about the incident source and any actions taken. If the
originator fails to decrypt or authenticate the Result message, a originator fails to decrypt or authenticate the Result message, an
RequestAuthorization message is sent in response; otherwise, no Acknowledgement message is sent in response; otherwise, no return
return message is sent. If a RequestAuthorization message is sent message is sent. The final Acknowledgement to the Result message is
with the RequestStatus set to Denied, a downstream peer receiving depicted as optional in the diagram above. If an Acknowledgement
this message may choose to take action to stop or mitigate the message is sent with the RequestStatus set to Denied, a downstream
traffic at that point in the network, as close to the source as peer receiving this message may choose to take action to stop or
possible. If the downstream peer chooses this option, it would send mitigate the traffic at that point in the network, as close to the
a Result message to the trace originator. source as possible. If the downstream peer chooses this option, it
would send a Result message to the trace originator.
7.1.1. RID TraceRequest Example 7.1.1. RID TraceRequest Example
The example listed is of a TraceRequest based on the incident report The example listed is of a Request message with MsgDst set to
example from the IODEF document. The RID extension classes were 'TraceRequest' based on the incident report example from the IODEF
included as appropriate for a TraceRequest message using the document. The RID classes were included as appropriate for a Request
RIDPolicy class. The example given is that of a CSIRT reporting a message of this type using the RIDPolicy class. The example given is
DoS attack in progress to the upstream SP. The request asks the next that of a CSIRT reporting a DoS attack in progress to the upstream
SP to continue the trace and have the traffic mitigated closer to the SP. The request asks the next SP to continue the trace and have the
source of the traffic. The example TraceRequest message is the first traffic mitigated closer to the source of the traffic. The example
step of a TraceRequest as depicted in the previous diagram, where Request message is the first step of a TraceRequest as depicted in
'Attack Dest' is represented by 192.0.2.67 (and SP-1). The "Attack the previous diagram, where 'Attack Dest' is represented by
Src' is later identified in the Result message example as 192.0.2.37 192.0.2.67 (and SP-1). The "Attack Src' is later identified in the
and initially as tracing closer to 192.0.2.35. 'SP-1' is identified Result message example as 192.0.2.37 and initially as tracing closer
in the TraceRequest as CSIRT-FOR-OUR-DOMAIN, and 'SP-2' is identified to 192.0.2.35. 'SP-1' is identified in the Request as CSIRT-FOR-OUR-
in the RID document for the TraceRequest as the 'RIDSystem' in DOMAIN, and 'SP-2' is identified in the RID document for the Request
'MsgDestination' as 192.0.2.3 using the Node class. SP-3 is later as the 'RIDSystem' in 'MsgDestination' as 192.0.2.3 using the Node
used in the Result message and the administrator is identified as class. SP-3 is later used in the Result message and the
'Admin-contact@10.1.1.2' as they searched for 192.0.2.35, the administrator is identified as 'Admin-contact@10.1.1.2' as they
administrator may be different than the constituency contact (an searched for 192.0.2.35, the administrator may be different than the
additional TraceRequest occurred between SP-2 to SP-3 that is not constituency contact (an additional Request with MsgDst set to
included). SP-3 is the service provider for 192.0.2.32/27 and was 'TraceRequest' occurred between SP-2 to SP-3 that is not included).
able to take the action to rate-limit their traffic. The SP-1, SP-2, SP-3 is the service provider for 192.0.2.32/27 and was able to take
and SP-3 information would be replaced with the appropriate (and the action to rate-limit their traffic. The SP-1, SP-2, and SP-3
valid) email and other contact information in real usages. The Node information would be replaced with the appropriate (and valid) email
class allows for the use of a fully qualified domain or the IP and other contact information in real usages. The Node class allows
address to be provided for the SP. Any mapping of existing for the use of a fully qualified domain or the IP address to be
relationships from the SP Node information to the name, contact, provided for the SP. Any mapping of existing relationships from the
digital signature verification information and other identifying or SP Node information to the name, contact, digital signature
trust information is provided at the application layer to support end verification information and other identifying or trust information
users of the incident management system. A packet is provided in is provided at the application layer to support end users of the
this example to enable any traces to be performed by SP-2 and SP-3 to incident management system. A packet is provided in this example to
perform traces to the attack source before taking the requested enable any traces to be performed by SP-2 and SP-3 to perform traces
action to 'rate-limit' the traffic. The subnet of 192.0.2.0uses a 27 to the attack source before taking the requested action to 'rate-
bit mask in the examples below. limit' the traffic. The subnet of 192.0.2.0uses a 27 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. Reference [RFC4051]
used, see [RFC6194] for further details. for URIs intended for use with XML digital signatures, encryption,
and canonicalization. SHA-1 SHOULD NOT be used, see [RFC6194] for
further details.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2" <?xml version="1.0" encoding="UTF-8" standalone="no"?>
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> <iodef-rid:RID lang="en-US"
<iodef-rid:RIDPolicy MsgType="TraceRequest" xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
MsgDestination="RIDSystem"> xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
<iodef-rid:PolicyRegion region="IntraConsortium"/> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<iodef:Node> xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0">
<iodef-rid:RIDPolicy MsgDestination="RIDSystem" MsgType="TraceRequest">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<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-Document included in RID --> <!-- IODEF-Document included in RID -->
<iodef-rid:ReportSchema Version="1.0"> <iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml"> <iodef-rid:XMLDocument dtype="xml" meaning="xml">
<IODEF-Document lang="en"> <IODEF-Document lang="en">
<iodef:Incident restriction="need-to-know" purpose="traceback"> <iodef:Incident purpose="traceback" restriction="need-to-know">
<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: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 completion="failed" severity="low" 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>
<iodef:Email>Constituency-contact@192.0.2.35</iodef:Email> <iodef:Email>Constituency-contact@192.0.2.35</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 ip_protocol="6"> <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 ip_protocol="6"> <iodef:Service ip_protocol="6">
<iodef:Port>80</iodef:Port> <iodef:Port>80</iodef:Port>
</iodef:Service>
</iodef:System> </iodef:Service>
</iodef:Flow> </iodef:System>
<iodef:Expectation severity="high" action="rate-limit-host"> </iodef:Flow>
<iodef:Description> <iodef:Expectation action="rate-limit-host" severity="high">
Rate-limit traffic close to source <iodef:Description>
Rate-limit traffic close to source
</iodef:Description> </iodef:Description>
</iodef:Expectation> </iodef:Expectation>
<iodef:Record> <iodef:Record>
<iodef:RecordData> <iodef:RecordData>
<iodef:Description> <iodef:Description>
The IPv4 packet included was used in the described attack The IPv4 packet included was used in the described attack
</iodef:Description> </iodef:Description>
<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 action="rate-limit-host"> <iodef:HistoryItem action="rate-limit-host">
<iodef:DateTime>2001-09-14T08:19:01+00:00</iodef:DateTime> <iodef:DateTime>2001-09-14T08:19: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:History> </iodef:History>
</iodef:Incident> </iodef:Incident>
</IODEF-Document> </IODEF-Document>
</iodef-rid:XMLDocument> </iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID --> <!-- End of IODEF-Document included in RID -->
<!-- Start of detached XML signature included in RID --> <!-- Start of detached XML signature included in RID -->
<iodef-rid:DetachedSignature dtype="xml" meaning="xml"> <iodef-rid:Signature dtype="xml" meaning="xml">
<!-- Signature of IODEF only document, will replace when iodef-rid-1.2 is posted --> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#" Id="dsig-123456">
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo>
<ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> <Reference URI="">
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512" <Transforms>
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:Reference URI="IODEF-TraceRequestEx11.xml" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
<ds:Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2"
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> xmlns:dsig-trans="http://www.w3.org/2002/06/xmldsig-filter2"
<ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116" Filter="intersect">
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> //dsig:Signature[@Id = 'dsig-123456']/ancestor::iodef-rid:ReportSchema/
<ds:XPath xmlns:ds="http://www.w3.org/2000/09/xmldsig#" iodef-rid:XMLDocument/IODEF-Document[1]/iodef:Incident[1]/
xmlns:xml="http://www.w3.org/XML/1998/namespace"> iodef:EventData[1]/iodef:Record[1]/iodef:RecordData[1]/
/IODEF-Document/Incident[1]/EventData[1]/Record[1]/RecordData[1]/RecordItem[1]</ds:XPath> iodef:RecordItem[1]</XPath></Transform></Transforms>
</ds:Transform> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" <DigestValue>NQuIhPjdZuZJnPi/hW62dwJT1dR+vqcZV8mpemCVN5g=</DigestValue>
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> </Reference></SignedInfo>
</ds:Transforms> <SignatureValue>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" lnq/ePQ4AVpxCR0ifCp9sMsW0r/AdT3C2GR/zaN1V+hZ/NApOygUjMzTCQnx+RvGPNkO/RVqBEID
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/> gZQUEnQZn/uSbmr0tQ6xpBfaxF1DCosLgiZy+2jFzpXrwoN/jHNgtxR/9QLW9mZ+I7V6LEEJ73Ku
<ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">2jmj7l5rSw0yVb/vlWAYkK/YBwk= t+d0naTGHlyi64ab2PqsVuRXQ4pXUKbhMkhzeTIqvFLK93KGfsIMd6Cb+n2u/AByLkc+gflJYUWV
</ds:DigestValue> P4DxkQ4cyex6hM6RYTRUSr7jVD9K4d8KFP2g85i69YLtSu01W1Np0afpJ4a9MK0E7ISMNRmC8wIk
</ds:Reference> lCAsSXiBRqyaEwaSy/clybI0vCTPqGOYh3/SZg==</SignatureValue>
</ds:SignedInfo> <KeyInfo>
<ds:SignatureValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <KeyValue>
JIMoK088bZk5V79DgSYnVNhnX3keEghQvkNIMol+VUHSjHCbiTTsYAMfYTqnWQDQcSzJE3YxdL5l <RSAKeyValue>
0xII/YtWcp0bb6ZJEKKwKocHSxRsJsoH/jXP23ENzyMsEMrVvOX8Z8Gi37u35YV5Epw0srqCg9ZR <Modulus>
lB854q6W7Ehdd0dIyVccWyOSvUIMDFITe6NJ1z7bxr0w09uN/oja3lk1UW4U3/oD2Cb+aZFGtXnw z8adrX9m0S8OxIxN+fui33wiz4ZYgb4xPbR9MS5pOp1A8kVpH5Ew3N6O3/dMs2a4diIxyGLVh0r8
jeLCaOhOs/SFgseU2skVELYZ21OovmdSs+7E5eHglUacyPKbZmrqGmqISuCR1fXDQ5K4O8cR7n9r 6QXWH/W6T2IC2ny+hi+jWRwXrvgTY3ZAFgePvz2OdRhVN/cUbOto4Pa4I2mVZWW+/Q0Fn7YpqPBD
7lowQPhsqntrWE2H81EI7mM7NedUVfpQdfZeKA== DxlGq/xyFPuYq/4y7Y+Ah+vHO2ZSaiQjbj8F38XrGhwlcbFVyK8AmxK3z0zWwX86uMEqVCjW6s6j
</ds:SignatureValue> 2KAWdbAjEpgZHlJY87i/DqnFgxfmdg3oru+YeiEPVRY8hyQpYbtgryveZOHTgnCHmS/53U9jSS0c
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> yb/ADuj1upfyNoOiMMgQr7Olhc5pTvuWAl4Fnw==</Modulus>
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <Exponent>AQAB</Exponent>
<ds:X509SubjectName xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> </RSAKeyValue>
EMAILADDRESS=CSIRT@emc.com,CN=CSIRT,OU=EMC OCTO,O=EMC,L=HOpkinton,ST=MA,C=US </KeyValue>
</ds:X509SubjectName> </KeyInfo>
<ds:X509Certificate xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> </Signature>
MIIDlzCCAn+gAwIBAgIJAM+Pp0vlgv4HMA0GCSqGSIb3DQEBDQUAMH0xCzAJBgNVBAYTAlVTMQsw </iodef-rid:Signature>
CQYDVQQIEwJNQTESMBAGA1UEBxMJSG9wa2ludG9uMQwwCgYDVQQKEwNFTUMxETAPBgNVBAsTCEVN <!-- End of detached XML signature included in RID -->
QyBPQ1RPMQ4wDAYDVQQDEwVDU0lSVDEcMBoGCSqGSIb3DQEJARYNQ1NJUlRAZW1jLmNvbTAeFw0x </iodef-rid:ReportSchema>
MTEyMjkxOTQ4NDhaFw0yMTEyMjYxOTQ4NDhaMH0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNQTES </iodef-rid:RIDPolicy>
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> </iodef-rid:RID>
7.1.2. RequestAuthorization Message Example 7.1.2. Acknowledgement Message Example
The example RequestAuthorization message is in response to the The example Acknowledgement message is in response to the Request
TraceRequest message listed above. The SP that received the request message listed above. The SP that received the request is responding
is responding to approve the trace continuance in their network. to approve the trace continuance in their network.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2" <iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
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="Acknowledgement"
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
</iodef:IncidentID> </iodef:IncidentID>
</iodef-rid:RIDPolicy> </iodef-rid:RIDPolicy>
<iodef-rid:RequestStatus AuthorizationStatus="Approved"/> <iodef-rid:RequestStatus AuthorizationStatus="Approved"/>
</iodef-rid:RID> </iodef-rid:RID>
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 Request listed
above. This message type only comes after a RequestAuthorization above. This message type only comes after an Acknowledgement within
within the TraceRequest flow of messages. It may be a direct the Request flow of messages where a TraceRequest is in progress. It
response to an Investigation request. This message provides may be a direct response to a Request with the MsgType set to
information about the source of the attack and the actions taken to 'InvestigationRequest'. This message provides information about the
mitigate the traffic. source of the attack and the actions taken to mitigate the traffic.
The Result message is typically the last message in a Request flow,
however an Acknowledgement MAY follow if there are any issues
receiving or processing the Result.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2" <iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
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: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-Document included in RID --> <!-- IODEF-Document included in RID -->
<iodef-rid:ReportSchema Version="1.0"> <iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml"> <iodef-rid:XMLDocument dtype="xml" meaning="xml">
<IODEF-Document lang="en"> <iodef:IODEF-Document lang="en">
<iodef:Incident restriction="need-to-know" purpose="traceback"> <iodef:Incident restriction="need-to-know" purpose="traceback">
<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: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"/>
skipping to change at page 48, line 24 skipping to change at page 49, line 13
<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-Document> </iodef:IODEF-Document>
</iodef-rid:XMLDocument> </iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID --> <!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema> </iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy> </iodef-rid:RIDPolicy>
<iodef-rid:IncidentSource> <iodef-rid:IncidentSource>
<iodef-rid:SourceFound>true</iodef-rid:SourceFound> <iodef-rid:SourceFound>true</iodef-rid:SourceFound>
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.37</iodef:Address> <iodef:Address category="ipv4-addr">192.0.2.37</iodef:Address>
</iodef:Node> </iodef:Node>
</iodef-rid:IncidentSource> </iodef-rid:IncidentSource>
</iodef-rid:RID> </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 a RID Request communication flow between
communication flow between RID systems on different networks for a RID systems on different networks for a security incident with a
security incident with a known source address. The proper response known source address. Therefore, MsgDst is set to
to an Investigation request is a Result message. If there is a 'InvestigationRequest' for the Request message and is included in the
problem with the request, such as a failure to validate the digital diagram below as an Investigation. The proper response to a Request
signature or decrypt the request, a RequestAuthorization message is with the MsgDst set to 'InvestigationRequest' is a Result message.
sent to the requestor. The RequestAuthorization message should If there is a problem with the Request, such as a failure to validate
the digital signature or decrypt the Request, an Acknowledgement
message is sent to the requestor. The Acknowledgement message should
provide the reason why the message could not be processed. provide the reason why the message could not be processed.
Attack Dest SP-1 SP-2 Attack Src Attack Dest SP-1 SP-2 Attack Src
1. Attack | Attack 1. Attack | Attack
reported | detected reported | detected
2. Determine source 2. Determine source
of security incident of security incident
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 9: Investigation Communication Flow Figure 9: Investigation Request 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, with the
information, with the exception that the source is known and the exception that the source is known, the receiving RID system is known
receiving RID system is known to be close to the source. The source to be close to the source, and the MsgDst is set to
known is indicated in the IODEF document, which allows for incident 'InvestigationRequest'. The source known is indicated in the IODEF
sources to be listed as spoofed, if appropriate. document, which allows for incident 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 Acknowledgement 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.2" <iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
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="InvestigationRequest"
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-Document included in RID --> <!-- IODEF-Document included in RID -->
<iodef-rid:ReportSchema Version="1.0"> <iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml"> <iodef-rid:XMLDocument dtype="xml" meaning="xml">
<IODEF-Document lang="en"> <iodef:IODEF-Document lang="en">
<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 51, line 19 skipping to change at page 52, line 20
<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-Document> </iodef:IODEF-Document>
</iodef-rid:XMLDocument> </iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID --> <!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema> </iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy> </iodef-rid:RIDPolicy>
</iodef-rid:RID> </iodef-rid:RID>
7.2.2. RequestAuthorization Message Example 7.2.2. Acknowledgement Message Example
The example RequestAuthorization message is in response to the The example Acknowledgement message is in response to the Request
Investigation request listed above. The SP that received the request listed above. The SP that received the request was unable to
was unable to validate the digital signature used to authenticate the validate the digital signature used to authenticate the sending RID
sending RID system. system.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.2" <iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
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="Acknowledgement"
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
</iodef:IncidentID> </iodef:IncidentID>
</iodef-rid:RIDPolicy> </iodef-rid:RIDPolicy>
<iodef-rid:RequestStatus AuthorizationStatus="Denied" <iodef-rid:RequestStatus AuthorizationStatus="Denied"
Justification="Authentication"/> Justification="Authentication"/>
</iodef-rid:RID> </iodef-rid:RID>
7.3. Report Communication Flow 7.3. Report Communication Flow
The diagram below outlines the RID Report communication flow between The diagram below outlines the RID Report communication flow between
RID systems on different networks. RID systems on different SPs.
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 10: 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 incidents. Incident information may be shared between CSIRTs or
be shared between CSIRTs or participating RID hosts using this other entities using this format. When a report is received, the RID
format. When a report is received, the RID system must verify that system must verify that the report has not already been filed. The
the report has not already been filed. The incident number and incident number and incident data, such as the hexadecimal packet and
incident data, such as the hexadecimal packet and incident class incident class information, can be used to compare with existing
information, can be used to compare with existing database entries. database entries. The Report message typically does not have a
The Report message typically does not have a response. If there is a response. If there is a problem with the Report message, such as a
problem with the Report message, such as a failure to validate the failure to validate the digital signature [RFC3275] or decrypt the
digital signature [RFC3275] or decrypt the request, a request, an Acknowledgement message is sent to the requestor. The
RequestAuthorization message is sent to the requestor. The Acknowledgement message should provide the reason why the message
RequestAuthorization message should provide the reason why the 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
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 Request
TraceRequest information. example with MsgDst set to 'TraceRequest'.
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.2" <iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
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-Document included in RID --> <!-- IODEF-Document included in RID -->
<iodef-rid:ReportSchema> <iodef-rid:ReportSchema>
<iodef-rid:XMLDocument dtype="xml" meaning="xml"> <iodef-rid:XMLDocument dtype="xml" meaning="xml">
<IODEF-Document lang="en"> <iodef:IODEF-Document lang="en">
<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 54, line 20 skipping to change at page 55, line 20
<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-Document> </iodef:IODEF-Document>
</iodef-rid:XMLDocument> </iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID --> <!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema> </iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy> </iodef-rid:RIDPolicy>
</iodef-rid:RID> </iodef-rid:RID>
7.4. IncidentQuery Communication Flow 7.4. Query Communication Flow
The diagram below outlines the RID IncidentQuery communication flow The diagram below outlines the RID Query communication flow between
between RID systems on different networks. 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
incident number or incident type incident number or incident type
2. o---IncidentQuery---> 2. o-------Query------->
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 11: IncidentQuery Communication Flow Figure 11: Query Communication Flow
The IncidentQuery message communication receives a response of a The Query message communication receives a response of a Report
Report message. If the Report message is empty, the responding host message. If the Report message is empty, the responding host did not
did not have information available to share with the requestor. The have information available to share with the requestor. The incident
incident number and responding RID system, as well as the transport, number and responding RID system, as well as the transport, assist in
assist in the association of the request and response since a report the association of the request and response since a report can be
can be filed and is not always solicited. If there is a problem with filed and is not always solicited. If there is a problem with the
the IncidentQuery message, such as a failure to validate the digital Query message, such as a failure to validate the digital signature or
signature or decrypt the request, a RequestAuthorization message is decrypt the request, an Acknowledgement message is sent to the
sent to the requestor. The RequestAuthorization message should requestor. The Acknowledgement message should provide the reason why
provide the reason why the message could not be processed. the message could not be processed.
7.4.1. IncidentQuery Example 7.4.1. Query Example
The IncidentQuery request may be received in several formats as a The Query request may be received in several formats as a result of
result of the type of query being performed. If the incident number the type of query being performed. If the incident number is the
is the only information provided, the IODEF document and IP packet only information provided, the IODEF document and IP packet data may
data may not be needed to complete the request. However, if a type not be needed to complete the request. However, if a type of
of incident is requested, the incident number remains NULL, and the incident is requested, the incident number remains NULL, and the IP
IP packet data will not be included in the IODEF RecordItem class; packet data will not be included in the IODEF RecordItem class; the
the other incident information is the main source for comparison. In other incident information is the main source for comparison. In the
the case in which an incident number may not be the same between case in which an incident number may not be the same between CSIRTs,
CSIRTs, the incident number and/or IP packet information can be the incident number and/or IP packet information can be provided and
provided and used for comparison on the receiving RID system to used for comparison on the receiving RID system to generate (a)
generate (a) Report message(s). 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.2" <iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
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="Query"
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.2" <xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
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.2" targetNamespace="urn:ietf:params:xml:ns:iodef-rid-2.0"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0" schemaLocation="http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd"/> <xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0" schemaLocation="http://www.iana.org/assignments/xml-registry/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"/> <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, January 2012 ***
*** 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
to support the exchange of incident information--> to support the exchange of incident information-->
<!-- <!--
====== Real-Time Inter-network Defense - RID ====== ====== Real-Time Inter-network Defense - RID ======
==== Suggested definition for RID messaging ====== ==== Suggested definition for RID messaging ======
--> -->
skipping to change at page 56, line 42 skipping to change at page 57, line 42
<xs:annotation> <xs:annotation>
<xs:documentation>XML Schema wrapper for IODEF</xs:documentation> <xs:documentation>XML Schema wrapper for IODEF</xs:documentation>
</xs:annotation> </xs:annotation>
<xs:element name="RID" type="iodef-rid:RIDType"/> <xs:element name="RID" type="iodef-rid:RIDType"/>
<xs:complexType name="RIDType"> <xs:complexType name="RIDType">
<xs:sequence> <xs:sequence>
<xs:element ref="iodef-rid:RIDPolicy" minOccurs="0"/> <xs:element ref="iodef-rid:RIDPolicy" minOccurs="0"/>
<xs:element ref="iodef-rid:RequestStatus" minOccurs="0"/> <xs:element ref="iodef-rid:RequestStatus" minOccurs="0"/>
<xs:element ref="iodef-rid:IncidentSource" minOccurs="0"/> <xs:element ref="iodef-rid:IncidentSource" minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="lang"
type="xs:language" use="required"/>
</xs:complexType> </xs:complexType>
<!--Used in RequestAuthorization Message for RID--> <!--Used in Acknowledgement Message for RID-->
<xs:element name="RequestStatus" type="iodef-rid:RequestStatusType"/> <xs:element name="RequestStatus" type="iodef-rid:RequestStatusType"/>
<xs:complexType name="RequestStatusType"> <xs:complexType name="RequestStatusType">
<xs:attribute name="AuthorizationStatus" use="required"> <xs:attribute name="AuthorizationStatus" 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="Approved"/> <xs:enumeration value="Approved"/>
<xs:enumeration value="Denied"/> <xs:enumeration value="Denied"/>
<xs:enumeration value="Pending"/> <xs:enumeration value="Pending"/>
skipping to change at page 57, line 20 skipping to change at page 58, line 22
<xs:attribute name="ext-AuthorizationStatus" <xs:attribute name="ext-AuthorizationStatus"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
<xs:attribute name="Justification"> <xs:attribute name="Justification">
<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="SystemResource"/> <xs:enumeration value="SystemResource"/>
<xs:enumeration value="Authentication"/> <xs:enumeration value="Authentication"/>
<xs:enumeration value="AuthenticationOrigin"/> <xs:enumeration value="AuthenticationOrigin"/>
<xs:enumeration value="Encryption"/> <xs:enumeration value="Encryption"/>
<xs:enumeration value="UnrecognizedFormat"/>
<xs:enumeration value="CannotProcess"/>
<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-Justification" <xs:attribute name="ext-Justification"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
<xs:attribute name="restriction" type="iodef:restriction-type"/> <xs:attribute name="restriction" type="iodef:restriction-type"/>
</xs:complexType> </xs:complexType>
skipping to change at page 58, line 21 skipping to change at page 59, line 27
<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: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="Acknowledgement"/>
<xs:enumeration value="Result"/> <xs:enumeration value="Result"/>
<xs:enumeration value="Investigation"/> <xs:enumeration value="InvestigationRequest"/>
<xs:enumeration value="Report"/> <xs:enumeration value="Report"/>
<xs:enumeration value="IncidentQuery"/> <xs:enumeration value="Query"/>
<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-MsgType" type="xs:string" use="optional"/> <xs:attribute name="ext-MsgType" type="xs:string" use="optional"/>
<xs:attribute name="MsgDestination" use="required"> <xs:attribute name="MsgDestination" 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="RIDSystem"/> <xs:enumeration value="RIDSystem"/>
skipping to change at page 59, line 45 skipping to change at page 60, line 50
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<!--Used to include an enveloped XML document in RID--> <!--Used to include an enveloped XML document in RID-->
<xs:element name="ReportSchema" type="iodef-rid:ReportSchemaType"/> <xs:element name="ReportSchema" type="iodef-rid:ReportSchemaType"/>
<xs:complexType name="ReportSchemaType"> <xs:complexType name="ReportSchemaType">
<xs:sequence> <xs:sequence>
<xs:element ref="iodef-rid:XMLDocument" minOccurs="1" <xs:element ref="iodef-rid:XMLDocument" minOccurs="1"
maxOccurs="1"/> maxOccurs="1"/>
<xs:element ref="iodef:URL" minOccurs="0" <xs:element ref="iodef:URL" minOccurs="0"
maxOccurs="1"/> maxOccurs="1"/>
<xs:element ref="iodef-rid:DetachedSignature" minOccurs="0" <xs:element ref="iodef-rid:Signature" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Version" use="optional"> <xs:attribute name="Version" use="optional">
<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="1.0"/> <xs:enumeration value="1.0"/>
<xs:enumeration value="ext-value"/> <xs:enumeration value="ext-value"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
skipping to change at page 60, line 13 skipping to change at page 61, line 19
<xs:whiteSpace value="collapse"/> <xs:whiteSpace value="collapse"/>
<xs:enumeration value="1.0"/> <xs:enumeration value="1.0"/>
<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-Version" <xs:attribute name="ext-Version"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
<xs:attribute name="XMLSchemaID" use="optional"> <xs:attribute name="XMLSchemaID" use="optional">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:anyURI">
<xs:whiteSpace value="collapse"/> <xs:whiteSpace value="collapse"/>
<xs:enumeration value="urn:ietf:params:xml:ns:iodef-1.0"/> <xs:enumeration value="urn:ietf:params:xml:ns:iodef-1.0"/>
<xs:enumeration value="http://www.icasi.org/CVRF/schema/cvrf/1.0"/>
<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-XMLSchemaID" <xs:attribute name="ext-XMLSchemaID"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
</xs:complexType> </xs:complexType>
<xs:element name="XMLDocument" <xs:element name="XMLDocument"
type="iodef:ExtensionType"/> type="iodef:ExtensionType"/>
<xs:element name="DetachedSignature" <xs:element name="URL"
type="xs:anyURI"/>
<xs:element name="Signature"
type="iodef:ExtensionType"/> 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
signatures [RFC3275], [XMLsig]. The standards provide clear methods signatures [RFC3275], [XMLsig]. The standards provide clear methods
to ensure that messages are secure, authenticated, and authorized, to ensure that messages are secure, authenticated, authorized, that
and that the messages meet policy and privacy guidelines and maintain the messages meet policy and privacy guidelines, and maintain
integrity. integrity. XML Signature Best Practices [XMLSigBP] should be
referenced by implementers for information on improving security to
mitigate attacks.
As specified in the relevant sections of this document, the XML As specified in the relevant sections of this document, the XML
digital signature [RFC3275] and XML encryption [XMLencrypt] are used digital signature [RFC3275] and XML encryption [XMLencrypt] are used
in the following cases: in the following cases:
XML Digital Signature XML Digital Signature
o The originator of the TraceRequest or Investigation request MUST o The originator of a Request MUST use a detached signature to sign
use a detached signature to sign at least one of the original at least one of the original elements contained in the RecordItem
elements contained in the RecordItem class to provide class to provide authentication to all upstream participants in
authentication to all upstream participants in the trace or those the trace or those involved in the investigation. All instances
involved in the investigation. All instances of RecordItem of RecordItem provided by the originator may be individually
provided by the originator may be individually signed, and signed, and additional RecordItem entries by upstream peers in the
additional RecordItem entries by upstream peers in the trace or trace or investigation may be signed by the peer adding the data,
investigation may be signed by the peer adding the data, while 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. Exclusive level to enable the use of an XML detached signature. Exclusive
canonicalization is REQUIRED as the XML document generated is then canonicalization [RFC3741] is REQUIRED for the detached signature
included in the RID message within the DetachedSignature element and not the references as the XML document generated is then
of the ReportSchema class. This signature MUST be passed to all included in the RID message within the Signature element of the
recipients of the TraceRequest or Investigation request. ReportSchema class. This signature MUST be passed to all
recipients of the Request message.
o If an Investigation or TraceRequest does not include a RecordItem o If a Request does not include a RecordItem entry, a timestamp MUST
entry, a timestamp MUST be used to ensure there is data to be be used to ensure there is data to be signed for the multi-hop
signed for the multi-hop authentication use case. The DateTime authentication use case. The DateTime element of the IODEF:
element of the IODEF:RecordItem class, [RFC5070] Section3.19.1, is RecordItem class, [RFC5070] Section3.19.1, is used for this
used for this purpose. 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. The
signature is placed in an instance of the Signature element.
o Optionally, nested enveloped signatures MAY be used when o XML Signature Best Practices [XMLSigBP] guidance SHOULD be
forwarding documents during an investigation. If this option is followed to prevent or mitigate security risks. Examples include
used, the implementation MUST follow the guidance specified in the the recommendation to authenticate a signature prior to processing
XML Digital Signature [XMLsig] specification for two or more (executing potentially dangerous operations) and limiting the use
enveloped signatures. of URIs since they may enable cross-site scripting attacks or
access to local information.
o XML Path Language (XPath) 2.0 [XMLPath] MUST be followed to
specify the portion of the XML document to be signed. XPath is
used to specify a location within an XML document. Best practice
recommendations for using XPath [XMLSigBP] SHOULD be referenced to
reduce the risk of denial of service attacks. The use of XSLT
transforms MUST be restricted according to security guidance in
[XMLSigBP].
XML Encryption XML Encryption
o The IODEF/RID document may be encrypted to provide an extra layer o The IODEF/RID document may be encrypted to provide an extra layer
of security between peers so that the message is not only of security between peers so that the message is not only
encrypted for the transport, but also while stored. This behavior encrypted for transport. This behavior would be agreed upon
would be agreed upon between peers or a consortium, or determined between peers or a consortium, or determined on a per-message
on a per-message basis, depending on security requirements. It basis, depending on security requirements. It should be noted
should be noted that there are cases for transport where the that there are cases for transport where the RIDPolicy class needs
RIDPolicy class needs to be presented in clear text, as detailed to be presented in clear text, as detailed in the transport
in the transport document [RFC6046-bis]. document [RFC6046-bis].
o An Investigation request, or any other message type that may be o A Request, or any other message type that may be relayed through
relayed through RID systems other than the intended destination as RID systems other than the intended destination as a result of
a result of trust relationships, may be encrypted for the intended trust relationships, may be encrypted for the intended recipient.
recipient. This may be necessary if the RID network is being used This may be necessary if the RID network is being used for message
for message transfer, the intermediate parties do not need to have transfer, the intermediate parties do not need to have knowledge
knowledge of the request contents, and a direct communication path of the request contents, and a direct communication path does not
does not exist. In that case, the RIDPolicy class is used by exist. In that case, the RIDPolicy class is used by intermediate
intermediate parties and is maintained in clear text. parties and is maintained in clear text.
o The action taken in the Result message may be encrypted using the o The action taken in the Result message may be encrypted using the
key of the request originator. In that case, the intermediate key of the request originator. In that case, the intermediate
parties can view the RIDPolicy information and know the trace has parties can view the RIDPolicy information and know the trace has
been completed and do not need to see the action. If the use of been completed and do not need to see the action. If the use of
encryption were limited to sections of the message, the History encryption were limited to sections of the message, the History
class information would be encrypted. Otherwise, it is class information would be encrypted. Otherwise, it is
RECOMMENDED to encrypt the entire IODEF/RID document and use an RECOMMENDED to encrypt the entire IODEF/RID document and use an
enveloped signature, for the originator of the request. The enveloped signature, for the originator of the request. The
existence of the Result message for an incident would tell any existence of the Result message for an incident would tell any
skipping to change at page 62, line 40 skipping to change at page 64, line 11
contained in each of the RID classes and MUST be used in contained in each of the RID classes and MUST be used in
accordance with confidentiality expectations for either sections accordance with confidentiality expectations for either sections
of the IODEF document or the complete IODEF document. Consortiums of the IODEF document or the complete IODEF document. Consortiums
and organizations should consider this guidance when creating and organizations should consider this guidance when creating
exchange policies. exchange policies.
o Expectations based on restriction setting: o Expectations based on restriction setting:
* If restriction is set to "private", the class or document MUST * If restriction is set to "private", the class or document MUST
be encrypted for the recipient using XML encryption and the be encrypted for the recipient using XML encryption and the
public key of the recipient. The use of PKI between entities public key of the recipient. See Section 9 for a discussion on
SHOULD adhere to any applicable certificate policy and public key infrastructure (PKI) and other security
practices agreements for the use of RID. [RFC3647] specifies a requirements.
commonly used format for certificate policy and certification
practices statements.
* If restriction is set to "need-to-know", the class or document * If restriction is set to "need-to-know", the class or document
MUST be encrypted to ensure only those with need-to-know access MUST be encrypted to ensure only those with need-to-know access
can decrypt the data. The document can either be encrypted for can decrypt the data. The document can either be encrypted for
each individual for which access is intended or a single group each individual for which access is intended or a single group
key may be used. The method used SHOULD adhere to any key may be used. The method used SHOULD adhere to any
certificate policy and practices agreements between entities certificate policy and practices agreements between entities
for the use of RID. A group key in this instance refers to a for the use of RID. A group key in this instance refers to a
single key (symmetric) that is used to encrypt the block of single key (symmetric) that is used to encrypt the block of
data. The users with need-to-know access privileges may be data. The users with need-to-know access privileges may be
skipping to change at page 63, line 50 skipping to change at page 65, line 19
The security considerations for the storage and exchange of The security considerations for the storage and exchange of
information in RID messaging may include adherence to local, information in RID messaging may include adherence to local,
regional, or national regulations in addition to the obligations to regional, or national regulations in addition to the obligations to
protect client information during an investigation. RID Policy is a protect client information during an investigation. RID Policy is a
necessary tool for listing the requirements of messages to provide a necessary tool for listing the requirements of messages to provide a
method to categorize data elements for proper handling. Controls are method to categorize data elements for proper handling. Controls are
also provided for the sending entity to protect messages from third also provided for the sending entity to protect messages from third
parties through XML encryption. parties through XML encryption.
RID provides a method to exchange incident handling request and RID provides a method to exchange incident handling request and
Report messages to peer networks. Administrators have the ability to Report messages between entities. Administrators have the ability to
base decisions on the available resources and other factors of their base decisions on the available resources and other factors of their
network and maintain control of incident investigations within their network and maintain control of incident investigations within their
own network. Thus, RID provides the ability for participating own network. Thus, RID provides the ability for participating
networks to manage their own security controls, leveraging the networks to manage their own security controls, leveraging the
information listed in RIDPolicy. information listed in RIDPolicy.
RID is used to transfer or exchange XML documents in an IODEF format
or using another IANA registered format. 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.
9.2. Message Transport 9.2. Message Transport
The transport specifications are fully defined in a separate document The transport specifications are fully defined in a separate document
[RFC6046-bis]. The specified transport protocols MUST use encryption [RFC6046-bis]. The specified transport protocols MUST use encryption
to provide an additional level of security and integrity, while to provide an additional level of security and integrity, while
supporting mutual authentication through bi-directional certificate supporting mutual authentication through bi-directional certificate
usage. Any subsequent transport method defined should take advantage usage. Any subsequent transport method defined should take advantage
of existing standards for ease of implementation and integration of of existing standards for ease of implementation and integration of
RID systems. Session encryption for the transport of RID messages is RID systems. Session encryption for the transport of RID messages is
enforced in the transport specification. The privacy and security enforced in the transport specification. The privacy and security
skipping to change at page 64, line 36 skipping to change at page 66, line 11
The RID protocol must be able to guarantee delivery and meet the The RID protocol must be able to guarantee delivery and meet the
necessary security requirements of a state-of-the-art protocol. In necessary security requirements of a state-of-the-art protocol. In
order to guarantee delivery, TCP should be considered as the order to guarantee delivery, TCP should be considered as the
underlying protocol within the current network standard practices. underlying protocol within the current network standard practices.
Consortiums may vary their selected transport mechanisms and thus Consortiums may vary their selected transport mechanisms and thus
decide upon a mutual protocol to use for transport when communicating decide upon a mutual protocol to use for transport when communicating
with peers in a neighboring consortium using RID. RID systems MUST with peers in a neighboring consortium using RID. RID systems MUST
implement and deploy HTTPS as defined in the transport document implement and deploy HTTPS as defined in the transport document
[RFC6046-bis] and optionally support other protocols such as the [RFC6046-bis] and optionally support other protocols such as the
Blocks Extensible Exchange Protocol (BEEP) [RFC3080]. RID, the XML Blocks Extensible Exchange Protocol (BEEP) [RFC3080].
security functions, and transport protocols must properly integrate
with a public key infrastructure (PKI) managed by the consortium or
one managed by a trusted entity. For the Internet, a few of examples
of existing efforts that could be leveraged to provide the supporting
PKI include the Regional Internet Registry's (RIR's) PKI hierarchy,
vendor issued certificates, or approved issuers of Extended
Validation (EV) Certificates. Security and privacy considerations
related to consortiums are discussed in Sections 9.4 and 9.5.
Systems used to send authenticated RID messages between networks MUST Systems used to send authenticated RID messages between networks MUST
use a secured system and interface to connect to a border network's use a secured system and interface to connect to a border network's
RID systems. Each connection to a RID system MUST meet the security RID systems. Each connection to a RID system MUST meet the security
requirements agreed upon through the consortium regulations, peering, requirements agreed upon through the consortium regulations, peering,
or SLAs. The RID system MUST only listen for and send RID messages or SLAs. The RID system MUST only listen for and send RID messages
on the designated port, which also MUST be over an encrypted tunnel on the designated port, which also MUST be over an encrypted tunnel
meeting the minimum requirement of algorithms and key lengths meeting the minimum requirement of algorithms and key lengths
established by the consortium, peering, or SLA. The selected established by the consortium, peering, or SLA. The selected
cryptographic algorithms for symmetric encryption, digital cryptographic algorithms for symmetric encryption, digital
skipping to change at page 65, line 23 skipping to change at page 66, line 38
bandwidth during a denial-of-service attack. For example, an out-of- bandwidth during a denial-of-service attack. For example, an out-of-
band channel may consist of logical paths defined over the existing band channel may consist of logical paths defined over the existing
network. Out-of-band communications may not be practical or possible network. Out-of-band communications may not be practical or possible
between service providers, but provisions should be considered to between service providers, but provisions should be considered to
protect the incident management systems used for RID messaging. protect the incident management systems used for RID messaging.
Methods to protect the data transport may also be provided through Methods to protect the data transport may also be provided through
session encryption. session encryption.
9.3. Public Key Infrastructure 9.3. Public Key Infrastructure
It is RECOMMENDED that RID, the XML security functions, and transport
protocols properly integrate with a PKI managed by the consortium,
federate PKIs within a consortium, or use a PKI managed by a trusted
third party. Entities MAY use shared keys as an alternate solution,
although this may limit the ability to validate certificates and
could introduce risk. For the Internet, a few of examples of
existing efforts that could be leveraged to provide the supporting
PKI include the Regional Internet Registry's (RIR's) PKI hierarchy,
vendor issued certificates, or approved issuers of Extended
Validation (EV) Certificates. Security and privacy considerations
related to consortiums are discussed in Sections 9.4 and 9.5.
The use of PKI between entities or by a consortium SHOULD adhere to
any applicable certificate policy and practices agreements for the
use of RID. [RFC3647] specifies a commonly used format for
certificate policy (CP) and certification practices statements (CPS).
Systems with predefined relationships for RID include those who peer Systems with predefined relationships for RID include those who peer
within a consortium with agreed-upon appropriate use regulations and directly or through a consortium with agreed-upon appropriate use
for peering consortiums. Trust relationships may also be defined agreements. The agreements to trust other entities may be based on
through a bridged or hierarchical PKI in which both peers belong. assurance levels that could be determined by a comparison of the CP,
CPS, and/or RID operating procedures. The initial comparison of
policies and ability to audit controls provides a baseline assurance
level for entities to form and maintain trust relationships. Trust
relationships may also be defined through a bridged or hierarchical
PKI in which both peers belong. If shared keys or keys issued from a
common CA are used, the verification of controls to determine the
assurance level to trust other entities may be limited to the RID
policies and operating procedures.
XML security functions utilized in RID require a trust center such as XML security functions utilized in RID require a trust center such as
a PKI for the distribution of credentials to provide the necessary a PKI for the distribution of credentials to provide the necessary
level of security for this protocol. Layered transport protocols level of security for this protocol. Layered transport protocols
also utilize encryption and rely on a trust center. Public key also utilize encryption and rely on a trust center. Public key
certificate pairs issued by a trusted Certification Authority (CA) certificate pairs issued by a trusted Certification Authority (CA)
MAY be used to provide the necessary level of authentication and MAY be used to provide the necessary level of authentication and
encryption for the RID protocol. The CA used for RID messaging must encryption for the RID protocol. The CA used for RID messaging must
be trusted by all involved parties and may take advantage of similar be trusted by all involved parties and may take advantage of similar
efforts, such as the Internet2 federated PKI or the ARIN/RIR effort efforts, such as the Internet2 federated PKI or the ARIN/RIR effort
to provide a PKI to network providers. The PKI used for to provide a PKI to service providers. The PKI used for
authentication also provides the necessary certificates needed for authentication also provides the necessary certificates needed for
encryption used for the RID transport protocol [RFC6046-bis]. encryption used for the RID transport protocol [RFC6046-bis].
9.3.1. Authentication 9.3.1. Authentication
Hosts receiving a RID message MUST be able to verify that the sender Hosts receiving a RID message MUST be able to verify that the sender
of the request is valid and trusted. Using digital signatures on a of the request is valid and trusted. Using digital signatures on a
hash of the RID message with an X.509 version 3 certificate issued by hash of the RID message with an X.509 version 3 certificate issued by
a trusted party MUST be used to authenticate the request. The X.509 a trusted party MUST be used to authenticate the request. The X.509
version 3 specifications as well as the digital signature version 3 specifications as well as the digital signature
skipping to change at page 66, line 22 skipping to change at page 68, line 13
an application could automatically determine whether human an application could automatically determine whether human
intervention is needed to authorize a request; however, the intervention is needed to authorize a request; however, the
specification of such an extension is out of scope for this document. specification of such an extension is out of scope for this document.
The use of pre-shared keys may be considered for authentication at The use of pre-shared keys may be considered for authentication at
the transport layer. If this option is selected, the specifications the transport layer. If this option is selected, the specifications
set forth in "Pre-Shared Key Ciphersuites for Transport Layer set forth in "Pre-Shared Key Ciphersuites for Transport Layer
Security (TLS)" [RFC4279] MUST be followed. Transport specifications Security (TLS)" [RFC4279] MUST be followed. Transport specifications
are detailed in a separate document [RFC6046-bis]. are detailed in a separate document [RFC6046-bis].
9.3.2. Multi-Hop TraceRequest Authentication 9.3.2. Multi-Hop Request Authentication
The use of multi-hop authentication in an Investigation request is The use of multi-hop authentication in a Request is used when a
used when an Investigation is sent to multiple entities or SPs in an Request is sent to multiple entities or SPs in an iterative manner.
iterative manner. Multi-hop authentication is REQUIRED in Multi-hop authentication is REQUIRED in Requests that involve
TraceRequests that involve multiple SPs. Bilateral trust multiple SPs where Requests are forwarded iteratively through peers.
relationships MAY be used between peers, then Multi-hop Bilateral trust relationships MAY be used between peers, then Multi-
authentication MUST be used for cases where the originator of a hop authentication MUST be used for cases where the originator of a
message is authenticated several hops into the message flow. message is authenticated several hops into the message flow.
For practical reasons, the SPs may want to prioritize incident For practical reasons, SPs may want to prioritize incident handling
handling events based upon the immediate peer for a TraceRequest, the events based upon the immediate peer for a Request, the originator of
originator of a request, and the listed Confidence rating for the a request, and the listed Confidence rating for the incident. In
incident. In order to provide a higher assurance level of the order to provide a higher assurance level of the authenticity of a
authenticity of the TraceRequest, the originating RID system is Request, the originating RID system is included in the Request along
included in the TraceRequest along with contact information and the with contact information and the information of all RID systems in
information of all RID systems in the path the trace has taken. This the path the trace has taken. This information is provided through
information is provided through the IODEF EventData class nesting the the IODEF EventData class nesting the list of systems and contacts
list of systems and contacts involved in a trace, while setting the involved in a trace, while setting the category attribute to
category attribute to "infrastructure". "infrastructure".
To provide multi-hop authentication, the originating RID system MUST To provide multi-hop authentication, the originating RID system MUST
include a digital signature in the TraceRequest sent to all systems include a digital signature in the Request sent to all systems in the
in the upstream path. The digital signature from the RID system is upstream path. The digital signature from the RID system is
performed on the RecordItem class of the IODEF following the XML performed on the RecordItem class of the IODEF following the XML
digital signature specifications from W3C [XMLsig] using a detached digital signature specifications from W3C [XMLsig] using a detached
signature. The signature MUST be passed to all parties that receive signature. The signature MUST be passed to all parties that receive
a TraceRequest, and each party MUST be able to perform full path a Request, and each party MUST be able to perform full path
validation on the digital signature [RFC5280]. In order to validation on the digital signature [RFC5280]. In order to
accommodate that requirement, the RecordItem data MUST remain accommodate that requirement, the RecordItem data MUST remain
unchanged as a request is passed along between providers and is the unchanged as a request is passed along between providers and is the
only element for which the signature is applied. If additional only element for which the signature is applied. If additional
RecordItems are included in the document at upstream peers, the RecordItems are included in the document at upstream peers, the
initial RecordItem entry MUST still remain with the detached initial RecordItem entry MUST still remain with the detached
signature. The subsequent RecordItem elements may be signed by the signature. The subsequent RecordItem elements may be signed by the
peer adding the incident information for the investigation. A second peer adding the incident information for the investigation. A second
benefit to this requirement is that the integrity of the filter used benefit to this requirement is that the integrity of the filter used
is ensured as it is passed to subsequent SPs in the upstream trace of is ensured as it is passed to subsequent SPs in the upstream trace of
the incident. The trusted PKI also provides the keys used to the incident. The trusted PKI also provides the keys used to
digitally sign the RecordItem class for TraceRequest or Investigation digitally sign the RecordItem class for a Request to meet the
to meet the requirement of authenticating the original request. Any requirement of authenticating the original request. Any host in the
host in the path of the trace should be able to verify the digital path of the trace should be able to verify the digital signature
signature using the trusted PKI. using the trusted PKI.
In the case in which an enterprise using RID sends a TraceRequest to In the case in which an enterprise using RID sends a Request to its
its provider, the signature from the enterprise MUST be included in provider, the signature from the enterprise MUST be included in the
the initial request. The SP may generate a new request to send initial request. The SP may generate a new request to send upstream
upstream to members of the SP consortium to continue the to members of the SP consortium to continue the investigation. If
investigation. If the original request is sent, the originating SP, the original request is sent, the originating SP, acting on behalf of
acting on behalf of the enterprise network under attack, MUST also the enterprise network under attack, MUST also digitally sign, with
digitally sign, with an enveloped signature, the full IODEF document an enveloped signature, the full IODEF document to assure the
to assure the authenticity of the TraceRequest. An SP that offers authenticity of the Request. An SP that offers RID as a service may
RID as a service may be using its own PKI to secure RID be using its own PKI to secure RID communications between its RID
communications between its RID system and the attached enterprise system and the attached enterprise networks. SPs participating in
networks. SPs participating in the trace MUST be able to determine the trace MUST be able to determine the authenticity of RID requests.
the authenticity of RID requests.
9.4. Consortiums and Public Key Infrastructures 9.4. Consortiums and Public Key Infrastructures
Consortiums of SPs are an ideal way to establish a communication web Consortiums are an ideal way to establish a communication web of
of trust for RID messaging. It should be noted that direct trust for RID messaging. It should be noted that direct
relationships may be ideal for some communications, such as those relationships may be ideal for some communications, such as those
between a provider of incident information and a subscriber of the between a provider of incident information and a subscriber of the
incident reports. The consortium could provide centralized incident reports. The consortium could provide centralized
resources, such as a PKI, and established guidelines for use of the resources, such as a PKI, and established guidelines and control
RID protocol. The consortium may assist in establishing trust requirements for use of RID. The consortium may assist in
relationships between the participating SPs to achieve the necessary establishing trust relationships between the participating SPs to
level of cooperation and experience-sharing among the consortium achieve the necessary level of cooperation and experience-sharing
entities. This may be established through PKI certificate policy among the consortium entities. This may be established through PKI
[RFC3647] reviews to determine the appropriate trust levels between certificate policy [RFC3647] reviews to determine the appropriate
organizations or entities. The consortium may also be used for other trust levels between organizations or entities. The consortium may
purposes to better facilitate communication among SPs in a common also be used for other purposes to better facilitate communication
area (Internet, region, government, education, private networks, among SPs in a common area (Internet, region, government, education,
etc.). private networks, etc.).
Using a PKI to distribute certificates used by RID systems provides Using a PKI to distribute certificates used by RID systems provides
an already established method to link trust relationships between SPs an already established method to link trust relationships between
of consortiums that peer with SPs belonging to a separate consortium. consortiums that peer with SPs belonging to a separate consortium.
In other words, consortiums could peer with other consortiums to In other words, consortiums could peer with other consortiums to
enable communication of RID messages between the participating SPs. enable communication of RID messages between the participating SPs.
The PKI along with Memorandums of Agreement could be used to link The PKI along with Memorandums of Agreement could be used to link
border directories to share public key information in a bridge, a border directories to share public key information in a bridge, a
hierarchy, or a single cross-certification relationship. hierarchy, or a single cross-certification relationship.
Consortiums also need to establish guidelines for each participating Consortiums also need to establish guidelines for each participating
SP to adhere to. The RECOMMENDED guidelines include: SP to adhere to. The RECOMMENDED guidelines include:
o Physical and logical practices to protect RID systems; o Physical and logical practices to protect RID systems;
skipping to change at page 68, line 43 skipping to change at page 70, line 34
9.5. Privacy Concerns and System Use Guidelines 9.5. Privacy Concerns and System Use Guidelines
Privacy issues raise many concerns when information-sharing is Privacy issues raise many concerns when information-sharing is
required to achieve the goal of stopping or mitigating the effects of required to achieve the goal of stopping or mitigating the effects of
a security incident. The RIDPolicy class is used to automate the a security incident. The RIDPolicy class is used to automate the
enforcement of the privacy concerns listed within this document. The enforcement of the privacy concerns listed within this document. The
privacy and system use concerns that MUST be addressed in the RID privacy and system use concerns that MUST be addressed in the RID
system and other integrated components include the following: system and other integrated components include the following:
Network Provider Concerns: Service Provider Concerns:
o Privacy of data monitored and/or stored on Intrusion Detection o Privacy of data monitored and/or stored on Intrusion Detection
Systems (IDSs) for attack detection. Systems (IDSs) for attack detection.
o Privacy of data monitored and stored on systems used to trace o Privacy of data monitored and stored on systems used to trace
traffic across a single network. traffic across a single network.
o Privacy of incident information stored on incident management
systems participating in RID communications.
Customer Attached Networks Participating in RID with SP: Customer Attached Networks Participating in RID with SP:
o Customer networks may include an enterprise, educational, o Customer networks may include an enterprise, educational,
government, or other attached networks to an SP participating in government, or other attached networks to an SP participating in
RID and MUST be made fully aware of the security and privacy RID and MUST be made fully aware of the security and privacy
considerations for using RID. considerations for using RID.
o Customers MUST be informed of the security and privacy o Customers MUST be informed of the security and privacy
considerations in place by their SP and the consortium of which considerations in place by their SP and the consortium of which
the SP is a member. the SP is a member.
o Customers MUST be informed that their data can and will be sent to o Customers MUST be informed that their data can and will be sent to
other SPs in order to complete a trace unless an agreement stating other SPs in order to complete a trace unless an agreement stating
otherwise is made in the service level agreements between the otherwise is made in the service level agreements between the
customer and SP. customer and SP.
Parties Involved in the Attack: Parties Involved in the Attack:
o Privacy of the identity of a host involved in an attack. o Privacy of the identity of a host involved in an attack or any
indicators of compromise.
o Privacy of information such as the source and destination used for o Privacy of information such as the source and destination used for
communication purposes over the monitored or RID connected communication purposes over the monitored or RID connected
network(s). network(s).
o Protection of data from being viewed by intermediate parties in o Protection of data from being viewed by intermediate parties in
the path of an Investigation request MUST be considered. the path of an Request request MUST be considered.
Consortium Considerations: Consortium Considerations:
o System use restricted to security incident handling within the o System use restricted to security incident handling within the
local region's definitions of appropriate traffic for the network local region's definitions of appropriate traffic for the network
monitored and linked via RID in a single consortium also abiding monitored and linked via RID in a single consortium also abiding
by the consortium's use guidelines. by the consortium's use guidelines.
o System use prohibiting the consortium's participating SPs from o System use prohibiting the consortium's participating SPs from
inappropriately tracing non-attack traffic to locate sources or inappropriately tracing non-attack traffic to locate sources or
skipping to change at page 70, line 21 skipping to change at page 72, line 16
The security and privacy considerations listed above are for the The security and privacy considerations listed above are for the
consortiums, SPs, and enterprises to agree upon. The agreed-upon consortiums, SPs, and enterprises to agree upon. The agreed-upon
policies may be facilitated through use of the RIDPolicy class. Some policies may be facilitated through use of the RIDPolicy class. Some
privacy considerations are addressed through the RID guidelines for privacy considerations are addressed through the RID guidelines for
encryption and digital signatures as described in Section 9.1. encryption and digital signatures as described in Section 9.1.
RID is useful in determining the true source of an incident that RID is useful in determining the true source of an incident that
traverses multiple networks or to communicate security incidents and traverses multiple networks or to communicate security incidents and
automate the response. The information obtained from the automate the response. The information obtained from the
investigation may determine the identity of the source host or the investigation may determine the identity of the source host or the SP
network provider used by the source of the traffic. It should be used by the source of the traffic. It should be noted that the trace
noted that the trace mechanism used across a single-network provider mechanism used across a single-SP may also raise privacy concerns for
may also raise privacy concerns for the clients of the network. the clients of the network. Methods that may raise concern include
Methods that may raise concern include those that involve storing those that involve storing packets for some length of time in order
packets for some length of time in order to trace packets after the to trace packets after the fact. Monitoring networks for intrusions
fact. Monitoring networks for intrusions and for tracing and for tracing capabilities also raises concerns for potentially
capabilities also raises concerns for potentially sensitive valid sensitive valid traffic that may be traversing the monitored network.
traffic that may be traversing the monitored network. IDSs and IDSs and single-network tracing are outside of the scope of this
single-network tracing are outside of the scope of this document, but document, but the concern should be noted and addressed within the
the concern should be noted and addressed within the use guidelines use guidelines of the network. Some IDSs and single-network trace
of the network. Some IDSs and single-network trace mechanisms mechanisms attempt to properly address these issues. RID is designed
attempt to properly address these issues. RID is designed to provide to provide the information needed by any single-network trace
the information needed by any single-network trace mechanism. The mechanism. The provider's choice of a single trace mechanism depends
provider's choice of a single trace mechanism depends on resources, on resources, existing solutions, and local legislation. Privacy
existing solutions, and local legislation. Privacy concerns in concerns in regard to the single-network trace must be dealt with at
regard to the single-network trace must be dealt with at the client- the client-to-SP level and are out of scope for RID messaging.
to-SP level and are out of scope for RID messaging.
The identity of the true source of an attack being traced through RID The identity of the true source of an attack being traced through RID
could be sensitive. The true identity listed in a Result message can could be sensitive. The true identity listed in a Result message can
be protected through the use of encryption [XMLencrypt] enveloping be protected through the use of encryption [XMLencrypt] enveloping
the IODEF document and RID Result information, using the public the IODEF document and RID Result information, using the public
encryption key of the originating SP. Alternatively, the action encryption key of the originating SP. Alternatively, the action
taken may be listed without the identity being revealed to the taken may be listed without the identity being revealed to the
originating SP. The ultimate goal of the RID communication system is originating SP. The ultimate goal of the RID communication system is
to stop or mitigate attack traffic, not to ensure that the identity to stop or mitigate attack traffic, not to ensure that the identity
of the attack traffic is known to involved parties. The SP that of the attack traffic is known to involved parties. The SP that
skipping to change at page 71, line 22 skipping to change at page 73, line 17
appropriate data to be shared given that the goal of the appropriate data to be shared given that the goal of the
specification is to provide the appropriate technical options to specification is to provide the appropriate technical options to
remain compliant. The textual descriptions should include details of remain compliant. The textual descriptions should include details of
the incident in order to protect the reputation of the unknowing the incident in order to protect the reputation of the unknowing
attacker and prevent the need for additional investigation. Local, attacker and prevent the need for additional investigation. Local,
state, or national laws may dictate the appropriate reporting action state, or national laws may dictate the appropriate reporting action
for specific security incidents. for specific security incidents.
Privacy becomes an issue whenever sensitive data traverses a network. Privacy becomes an issue whenever sensitive data traverses a network.
For example, if an attack occurred between a specific source and For example, if an attack occurred between a specific source and
destination, then every network provider in the path of the trace destination, then every SP in the path of the trace becomes aware
becomes aware that the cyber attack occurred. In a targeted attack, that the cyber attack occurred. In a targeted attack, it may not be
it may not be desirable that information about two nation states that desirable that information about two nation states that are battling
are battling a cyber war would become general knowledge to all a cyber war would become general knowledge to all intermediate
intermediate parties. However, it is important to allow the traces parties. However, it is important to allow the traces to take place
to take place in order to halt the activity since the health of the in order to halt the activity since the health of the networks in the
networks in the path could also be at stake during the attack. This path could also be at stake during the attack. This provides a
provides a second argument for allowing the Result message to only second argument for allowing the Result message to only include an
include an action taken and not the identity of the offending host. action taken and not the identity of the offending host. In the case
In the case of an Investigation request, where the originating SP is of a Request or Report, where the originating SP is aware of the SP
aware of the SP that will receive the request for processing, the that will receive the request for processing, the free-form text
free-form text areas of the document could be encrypted [XMLencrypt] areas of the document could be encrypted [XMLencrypt] using the
using the public key of the destination SP to ensure that no other SP public key of the destination SP to ensure that no other SP in the
in the path can read the contents. The encryption is accomplished path can read the contents. The encryption is accomplished through
through the W3C [XMLencrypt] specification for encrypting an element. the W3C [XMLencrypt] specification for encrypting an element.
In some situations, all network traffic of a nation may be granted In some situations, all network traffic of a nation may be granted
through a single network provider. In that situation, options must through a single SP. In that situation, options must support sending
support sending Result messages from a downstream peer of that Result messages from a downstream peer of that SP. That option
network provider. That option provides an additional level of provides an additional level of abstraction to hide the identity and
abstraction to hide the identity and the SP of the identified source the SP of the identified source of the traffic. Legal action may
of the traffic. Legal action may override this technical decision override this technical decision after the trace has taken place, but
after the trace has taken place, but that is out of the technical that is out of the technical scope of this document.
scope of this document.
Privacy concerns when using an Investigation message to request Privacy concerns when using an Request message to request action
action close to the source of valid attack traffic needs to be close to the source of valid attack traffic needs to be considered.
considered. Although the intermediate SPs may relay the request if Although the intermediate SPs may relay the request if there is no
there is no direct trust relationship to the closest SP to the direct trust relationship to the closest SP to the source, the
source, the intermediate SPs do not require the ability to see the intermediate SPs do not require the ability to see the contents of
contents of the packet or the text description field(s) in the the packet or the text description field(s) in the request. This
request. This message type does not require any action by the message type does not require any action by the intermediate RID
intermediate RID systems, except to relay the packet to the next SP systems, except to relay the packet to the next SP in the path.
in the path. Therefore, the contents of the request may be encrypted Therefore, the contents of the request may be encrypted for the
for the destination system. The intermediate SPs only needs to know destination system. The intermediate SPs only needs to know how to
how to direct the request to the manager of the ASN in which the direct the request to the manager of the ASN in which the source IP
source IP address belongs. address belongs.
Traces must be legitimate security-related incidents and not used for Traces must be legitimate security-related incidents and not used for
purposes such as sabotage or censorship. An example of such abuse of purposes such as sabotage or censorship. An example of such abuse of
the system includes a request to block or rate-limit legitimate the system includes a request to block or rate-limit legitimate
traffic to prevent information from being shared between users on the traffic to prevent information from being shared between users on the
Internet (restricting access to online versions of papers) or Internet (restricting access to online versions of papers) or
restricting access from a competitor's product in order to sabotage a restricting access from a competitor's product in order to sabotage a
business. business.
Intra-consortium RID communications raise additional issues, Intra-consortium RID communications raise additional issues,
especially when the peering consortiums reside in different regions especially when the peering consortiums reside in different regions
or nations. TraceRequests, Investigation requests, and requested or nations. Request messages and requested actions to mitigate or
actions to mitigate or stop traffic must adhere to the appropriate stop traffic must adhere to the appropriate use guidelines and yet
use guidelines and yet prevent abuse of the system. First, the prevent abuse of the system. First, the peering consortiums MUST
peering consortiums MUST identify the types of traffic that can be identify the types of traffic that can be traced between the borders
traced between the borders of the participating SPs of each of the participating SPs of each consortium. The traffic traced
consortium. The traffic traced should be limited to security- should be limited to security-incident-related traffic. Second, the
incident-related traffic. Second, the traces permitted within one traces permitted within one consortium if passed to a peering
consortium if passed to a peering consortium may infringe upon the consortium may infringe upon the peering consortium's freedom of
peering consortium's freedom of information laws. An example would information laws. An example would be a consortium in one country
be a consortium in one country permitting a trace of traffic permitting a trace of traffic containing objectionable material,
containing objectionable material, outlawed within that country. The outlawed within that country. The RID trace may be a valid use of
RID trace may be a valid use of the system within the confines of the system within the confines of that country's network border;
that country's network border; however, it may not be permitted to however, it may not be permitted to continue across network
continue across network boundaries where such content is permitted boundaries where such content is permitted under law. By continuing
under law. By continuing the trace in another country's network, the the trace in another country's network, the trace and response could
trace and response could have the effect of improperly restricting have the effect of improperly restricting access to data. A
access to data. A continued trace into a second country may break continued trace into a second country may break the laws and
the laws and regulations of that nation. Any such traces MUST cease regulations of that nation. Any such traces MUST cease at the
at the country's border. country's border.
The privacy concerns listed in this section address issues among the The privacy concerns listed in this section address issues among the
trusted parties involved in a trace within an SP, a RID consortium, trusted parties involved in a trace within an SP, a RID consortium,
and peering RID consortiums. Data used for RID communications must and peering RID consortiums. Data used for RID communications must
also be protected from parties that are not trusted. This protection also be protected from parties that are not trusted. This protection
is provided through the authentication and encryption of documents as is provided through the authentication and encryption of documents as
they traverse the path of trusted servers. Each RID system MUST they traverse the path of trusted servers. Each RID system MUST
perform a bi-directional authentication when sending a RID message perform a bi-directional authentication when sending a RID message
and use the public encryption key of the upstream or downstream peer and use the public encryption key of the upstream or downstream peer
to send a message or document over the network. This means that the to send a message or document over the network. This means that the
skipping to change at page 73, line 25 skipping to change at page 75, line 20
considerations include the availability, confidentiality, and considerations include the availability, confidentiality, and
integrity concerns for the transport, storage, and exchange of integrity concerns for the transport, storage, and exchange of
information. information.
Protected tunnels between systems accepting RID communications are Protected tunnels between systems accepting RID communications are
used to provide confidentiality, integrity, authenticity, and privacy used to provide confidentiality, integrity, authenticity, and privacy
for the data at the transport layer. Encryption and digital for the data at the transport layer. Encryption and digital
signatures are also used at the IODEF document level through RID signatures are also used at the IODEF document level through RID
options to provide confidentiality, integrity, authenticity, privacy options to provide confidentiality, integrity, authenticity, privacy
and traceability of the document contents at the application layer. and traceability of the document contents at the application layer.
Trust relationships are based on public key infrastructure (PKI). Trust relationships are based on PKI and the comparison/validation of
Trust levels can be established in cross-certification processes security controls for the incident management systems communicating
where entities compare PKI policies that include the specific via RID. Trust levels can be established in cross-certification
management and handling of an entity's PKI and certificates issued processes where entities compare PKI policies that include the
under that policy. [RFC3647] defines an Internet X.509 Public Key specific management and handling of an entity's PKI and certificates
Infrastructure Certificate Policy and Certification Practices issued under that policy. [RFC3647] defines an Internet X.509 Public
Key Infrastructure Certificate Policy and Certification Practices
Framework that may be used in the comparison of policies to establish Framework that may be used in the comparison of policies to establish
trust levels and agreements between entities, an entity and a trust levels and agreements between entities, an entity and a
consortium, and consortia. The agreements SHOULD consider key consortium, and consortia. The agreements SHOULD consider key
management practices including the ability to perform path validation management practices including the ability to perform path validation
on certificates [RFC5280], key distribution techniques [RFC2585], on certificates [RFC5280], key distribution techniques [RFC2585],
Certificate Authority and Registration Authority management Certificate Authority and Registration Authority management
practices. practices.
The agreements between entities SHOULD also include a common The agreements between entities SHOULD also include a common
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 both the Security Requirements and Security
complexity of the agreements for the certificate policy, practices, Considerations sections. The formality, requirements, and complexity
and the use of RID options SHOULD be decided by the entities or of the agreements for the certificate policy, practices, supporting
consortiums creating those agreements. infrastructure, and the use of RID options SHOULD be decided by the
entities or 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.2 URI: urn:ietf:params:xml:ns:iodef-rid-2.0
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.2 URI: urn:ietf:params:xml:schema:iodef-rid-2.0
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: Request for the specified registry to be created and managed by IANA:
Additional namespaces need to be registered to an IANA repository Name of the registry:"XML Schemas Exchanged via RID"
to extend the enumerated list for the attributes in the
ReportSchema class. The initial list of the namespaces is limited Namespace details: A registry entry for an XML Schema Transferred
to one, defined in IODEF [RFC5070], which is included as an via RID consists of:
accepted enumerated value for the appropriate attributes.
Schema Name: A short string that represents the schema
referenced. This value is for reference only in the table.
The version of the schema MUST be included in this string to
allow for multiple versions of the same specification to be in
the registry.
Version: The version of the registered XML schema. The version
is a string that SHOULD be formatted as numbers separated by a
'.' (period) character.
Namespace: The namespace of the referenced XML schema. This is
represented in the RID ReportSchema class in the XMLSchemaID
attribute as an enumerated value is represented by a URN or
URI.
Specification URI: A URI [RFC3986] from which the registered
specification can be obtained. The specification MUST be
publicly available from this URI.
Information that must be provided to assign a new value: The above
list of information.
Fields to record in the registry: Schema Name/Namespace/SchemaID/
Specification URI
Initial registry contents: See section 5.5.1.
Allocation Policy: Expert Review [RFC5226] and Specification
Required [RFC5226].
The Designated Expert is expected to consult with the mile (Managed
Incident Lightweight Exchange) working group or its successor if any
such WG exists (e.g., via email to the working group's mailing list).
The Designated Expert is expected to retrieve the XML schema
specification from the provided URI in order to check the public
availability of the specification and verify the correctness of the
URI. An important responsibility of the Designated Expert is to
ensure that the XML schema is appropriate for use in RID.
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. SPs need policies and
policies and automated methods to combat the hacker's efforts. SPs automated methods to combat the hacker's efforts. SPs need automated
need automated monitoring and response capabilities to identify and monitoring and response capabilities to identify and trace attacks
trace attacks quickly without resource-intensive side effects. quickly without resource-intensive side effects. Integration with a
Integration with a centralized communication system to coordinate the centralized communication system to coordinate the detection,
detection, tracing, and identification of attack sources on a single tracing, and identification of attack sources on a single network is
network is essential. RID provides a way to integrate SP resources essential. RID provides a way to integrate SP resources for each
for each aspect of attack detection, tracing, and source aspect of attack detection, tracing, and source identification and
identification and extends the communication capabilities among extends the communication capabilities among SPs. The communication
network providers. The communication is accomplished through the use is accomplished through the use of flexible IODEF XML-based documents
of flexible IODEF XML-based documents passed between IHSs or RID passed between IHSs or RID systems. A Request is communicated to an
systems. A TraceRequest or Investigation request is communicated to upstream SP and may result in an upstream trace or in an action to
an upstream SP and may result in an upstream trace or in an action to
stop or mitigate the attack traffic. The messages are communicated stop or mitigate the attack traffic. The messages are communicated
among peers with security inherent to the RID messaging scheme among peers with security inherent to the RID messaging scheme
provided through existing standards such as XML encryption and provided through existing standards such as XML encryption and
digital signatures. Policy information is carried in the RID message digital signatures. Policy information is carried in the RID message
itself through the use of the RIDPolicy. RID provides the timely itself through the use of the RIDPolicy. RID provides the timely
communication among SPs, which is essential for incident handling. communication among SPs, which is essential for incident handling.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999. RFC 2585, May 1999.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
skipping to change at page 75, line 31 skipping to change at page 78, line 20
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999. RFC 2585, May 1999.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002. March 2002.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC3741] Boyer, J., Eastlake, D., and J. Reagle, "Exclusive XML
Canonicalization, Version 1.0", RFC 3741, March 2004.
[RFC4051] Eastlake, D., "Additional XML Security Uniform Resource
Identifiers (URIs)", RFC 4051, April 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, for Transport Layer Security (TLS)", RFC 4279,
December 2005. December 2005.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", RFC 4646, September 2006.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070, Object Description Exchange Format", RFC 5070,
December 2007. December 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet
Attribute Certificate Profile for Authorization", Attribute Certificate Profile for Authorization",
RFC 5755, January 2010. RFC 5755, January 2010.
[RFC6046-bis] [RFC6046-bis]
Trammell, B., "Transport of Real-time Inter-network Trammell, B., "Transport of Real-time Inter-network
Defense (RID) Messages", December 2011, <http:// Defense (RID) Messages", January 2012, <http://
tools.ietf.org/html/draft-ietf-mile-rfc6046-bis-02>. tools.ietf.org/html/draft-ietf-mile-rfc6046-bis-05>.
[XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and
F. Yergeau, "Extensible Markup Language (XML) 1.0", W3C F. Yergeau, "Extensible Markup Language (XML) 1.0", W3C
Recommendation XML 1.0, November 2008, Recommendation XML 1.0, November 2008,
<http://www.w3.org/TR/xml/>. <http://www.w3.org/TR/xml/>.
[XMLNames] [XMLNames]
Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C
Recommendation , December 2009, Recommendation , December 2009,
<http://www.w3.org/TR/xml-names/>. <http://www.w3.org/TR/xml-names/>.
[XMLencrypt] [XMLencrypt]
Imaura, T., Dillaway, B., and E. Simon, "XML Encryption Imaura, T., Dillaway, B., and E. Simon, "XML Encryption
Syntax and Processing", W3C Recommendation , Syntax and Processing", W3C Recommendation ,
December 2002, <http://www.w3.org/TR/xmlenc-core/>. December 2002, <http://www.w3.org/TR/xmlenc-core/>.
[XMLschema] [XMLPath] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M.,
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, Kay, M., Robie, J., and J. Simeon, "XML Schema Part 1:
"XML Schema Part 1: Structures", W3C Recommendation Second Structures", W3C Recommendation Second Edition,
Edition, October 2004, December 2010, <http://www.w3.org/TR/xpath20/>.
<http://www.w3.org/TR/xmlschema-1/>.
[XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E. [XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E.
Simon, "XML-Signature Syntax and Processing", W3C Simon, "XML-Signature Syntax and Processing", W3C
Recommendation Second Edition, June 2008, Recommendation Second Edition, June 2008,
<http://www.w3.org/TR/xmldsig-core/>. <http://www.w3.org/TR/xmldsig-core/>.
[XMLSigBP]
Hirsch, F. and P. Datta, "XML-Signature Best Practices",
W3C Recommendation , August 2011,
<http://www.w3.org/TR/xmldsig-bestpractices/>.
13.2. Informative References 13.2. Informative References
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)", selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, March 1996. BCP 6, RFC 1930, March 1996.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
November 2003. November 2003.
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001. RFC 3080, March 2001.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
BCP 153, RFC 5735, January 2010. Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)",
RFC 6045, November 2010. RFC 6045, November 2010.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, March 2011. Algorithms", RFC 6194, March 2011.
[CVRF] Schiffman, M., "The Common Vulnerability Reporting
Framework (CVRF)", The Industry Consortium for Advancement
of Security on the Internet (ICASI) v1.0, May 2011,
<http://www.icasi.org/cvrf>.
Acknowledgements Acknowledgements
Many thanks to colleagues and the Internet community for reviewing Many thanks to colleagues and the Internet community for reviewing
and commenting on the document as well as providing recommendations and commenting on the document as well as providing recommendations
to simplify and secure the protocol: Robert K. Cunningham, Ph.D, to simplify and secure the protocol: Robert K. Cunningham, Ph.D,
Cynthia D. McLain, Dr. William Streilein, Iljitsch van Beijnum, Steve Cynthia D. McLain, Dr. William Streilein, Iljitsch van Beijnum, Steve
Bellovin, Yuri Demchenko, Jean-Francois Morfin, Stephen Northcutt, Bellovin, Yuri Demchenko, Jean-Francois Morfin, Stephen Northcutt,
Jeffrey Schiller, Brian Trammell, Roman Danyliw, Tony Tauber, Sandra Jeffrey Schiller, Brian Trammell, Roman Danyliw, Tony Tauber, Sandra
G. Dykes, Ph.D., Katherine Goodier, Ph.D., Tony Rutkowski, Damir G. Dykes, Ph.D., Katherine Goodier, Ph.D., Tony Rutkowski, Damir
Rajnovic, David Black, and Paul Cichonski. Rajnovic, David Black, Paul Cichonski, David Waltermire, Richard
Struse, Thomas Millar, and Harold Booth.
Author's Address Author's Address
Kathleen M. Moriarty Kathleen M. Moriarty
EMC Corporation EMC Corporation
176 South Street 176 South Street
Hopkinton, MA Hopkinton, MA
United States United States
Phone: Phone:
 End of changes. 228 change blocks. 
996 lines changed or deleted 1141 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/