draft-ietf-mile-rfc6045-bis-11.txt   rfc6545.txt 
MILE Working Group K. Moriarty
Internet-Draft EMC Internet Engineering Task Force (IETF) K. Moriarty
Obsoletes: 6045 (if approved) January 31, 2012 Request for Comments: 6545 EMC
Intended status: Standards Track Obsoletes: 6045 April 2012
Expires: August 3, 2012 Category: Standards Track
ISSN: 2070-1721
Real-time Inter-network Defense (RID) Real-time Inter-network Defense (RID)
draft-ietf-mile-rfc6045-bis-11.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
proactive inter-network communication method to facilitate sharing proactive inter-network communication method to facilitate sharing
incident handling data while integrating existing detection, tracing, incident-handling data while integrating existing detection, tracing,
source identification, and mitigation mechanisms for a complete source identification, and mitigation mechanisms for a complete
incident handling solution. Combining these capabilities in a incident-handling solution. Combining these capabilities in a
communication system provides a way to achieve higher security levels communication system provides a way to achieve higher security levels
on networks. Policy guidelines for handling incidents are on networks. Policy guidelines for handling incidents are
recommended and can be agreed upon by a consortium using the security recommended and can be agreed upon by a consortium using the security
recommendations and considerations. This document obsoletes RFC6045. recommendations and considerations. This document obsoletes RFC
6045.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 3, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6545.
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 ....................................................3
1.1. Changes from RFC6045 . . . . . . . . . . . . . . . . . . . 5 1.1. Changes from RFC 6045 ......................................5
1.2. Normative and Informative . . . . . . . . . . . . . . . . 7 1.2. Normative and Informative ..................................6
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Terminology ................................................7
2. Characteristics of Incidents . . . . . . . . . . . . . . . . . 7 2. Characteristics of Incidents ....................................7
3. Communication between CSIRTs and Service Providers . . . . . . 9 3. Communication between CSIRTs and Service Providers ..............8
3.1. Inter-service Provider RID Messaging . . . . . . . . . . . 11 3.1. Inter-Service-Provider RID Messaging ......................10
3.2. RID Communication Topology . . . . . . . . . . . . . . . . 13 3.2. RID Communication Topology ................................12
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 14 4. Message Formats ................................................13
4.1. RID Data Types . . . . . . . . . . . . . . . . . . . . . . 14 4.1. RID Data Types ............................................13
4.1.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.1. Boolean ............................................13
4.2. RID Message Types . . . . . . . . . . . . . . . . . . . . 14 4.2. RID Message Types .........................................14
5. IODEF-RID Schema . . . . . . . . . . . . . . . . . . . . . . . 15 5. IODEF-RID Schema ...............................................15
5.1. RIDPolicy Class . . . . . . . . . . . . . . . . . . . . . 17 5.1. RIDPolicy Class ...........................................17
5.1.1. ReportSchema . . . . . . . . . . . . . . . . . . . . . 24 5.1.1. ReportSchema .......................................23
5.2. RequestStatus . . . . . . . . . . . . . . . . . . . . . . 26 5.2. RequestStatus .............................................26
5.3. IncidentSource . . . . . . . . . . . . . . . . . . . . . . 28 5.3. IncidentSource ............................................28
5.4. RID Name Spaces . . . . . . . . . . . . . . . . . . . . . 29 5.4. RID Name Spaces ...........................................29
5.5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.5. Encoding ..................................................29
5.6. Including IODEF or other XML Documents . . . . . . . . . . 30 5.6. Including IODEF or Other XML Documents ....................29
5.6.1. Including XML Documents in RID . . . . . . . . . . . . 31 5.6.1. Including XML Documents in RID .....................30
6. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. RID Messages ...................................................31
6.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.1. Request ...................................................31
6.2. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 34 6.2. Acknowledgement ...........................................33
6.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.3. Result ....................................................34
6.4. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.4. Report ....................................................36
6.5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.5. Query .....................................................38
7. RID Communication Exchanges . . . . . . . . . . . . . . . . . 39 7. RID Communication Exchanges ....................................39
7.1. Upstream Trace Communication Flow . . . . . . . . . . . . 41 7.1. Upstream Trace Communication Flow .........................40
7.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 43 7.1.1. RID TraceRequest Example ...........................43
7.1.2. Acknowledgement Message Example . . . . . . . . . . . 47 7.1.2. Acknowledgement Message Example ....................47
7.1.3. Result Message Example . . . . . . . . . . . . . . . . 48 7.1.3. Result Message Example .............................47
7.2. Investigation Request Communication Flow . . . . . . . . . 51 7.2. Investigation Request Communication Flow ..................50
7.2.1. Investigation Request Example . . . . . . . . . . . . 52 7.2.1. Investigation Request Example ......................51
7.2.2. Acknowledgement Message Example . . . . . . . . . . . 54 7.2.2. Acknowledgement Message Example ....................53
7.3. Report Communication Flow . . . . . . . . . . . . . . . . 55 7.3. Report Communication Flow .................................54
7.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 55 7.3.1. Report Example .....................................54
7.4. Query Communication Flow . . . . . . . . . . . . . . . . . 57 7.4. Query Communication Flow ..................................56
7.4.1. Query Example . . . . . . . . . . . . . . . . . . . . 58 7.4.1. Query Example ......................................57
8. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 59 8. RID Schema Definition ..........................................58
9. Security Requirements . . . . . . . . . . . . . . . . . . . . 63 9. Security Requirements ..........................................62
9.1. XML Digital Signatures and Encryption . . . . . . . . . . 63 9.1. XML Digital Signatures and Encryption .....................62
9.2. Message Transport . . . . . . . . . . . . . . . . . . . . 67 9.2. Message Transport .........................................66
9.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 68 9.3. Public Key Infrastructure .................................67
9.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 69 9.3.1. Authentication .....................................68
9.3.2. Multi-Hop Request Authentication . . . . . . . . . . . 70 9.3.2. Multi-Hop Request Authentication ...................69
9.4. Consortiums and Public Key Infrastructures . . . . . . . . 71 9.4. Consortiums and Public Key Infrastructures ................70
9.5. Privacy Concerns and System Use Guidelines . . . . . . . . 72 9.5. Privacy Concerns and System Use Guidelines ................71
9.6. Sharing Profiles and Policies . . . . . . . . . . . . . . 77 9.6. Sharing Profiles and Policies .............................76
10. Security Considerations . . . . . . . . . . . . . . . . . . . 77 10. Security Considerations .......................................77
11. Internationalization Issues . . . . . . . . . . . . . . . . . 78 11. Internationalization Issues ...................................77
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 12. IANA Considerations ...........................................78
13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 13. Summary .......................................................80
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81 14. References ....................................................80
14.1. Normative References . . . . . . . . . . . . . . . . . . . 81 14.1. Normative References .....................................80
14.2. Informative References . . . . . . . . . . . . . . . . . . 83 14.2. Informative References ...................................82
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 84 Appendix A. Acknowledgements ......................................84
1. Introduction 1. Introduction
Organizations require help from other parties to identify incidents, Organizations require help from other parties to identify incidents,
mitigate malicious activity targeting their computing resources, and mitigate malicious activity targeting their computing resources, and
to gain insight into potential threats through the sharing of to gain insight into potential threats through the sharing of
information. This coordination might entail working with a service information. This coordination might entail working with a service
provider (SP) to filter attack traffic, working with a SP to resolve provider (SP) to filter attack traffic, working with an SP to resolve
a configuration issue unintentionally causing problems, contacting a a configuration issue that is unintentionally causing problems,
remote site to take down a bot- network, or sharing watch-lists of contacting a remote site to take down a bot network, or sharing
known malicious IP addresses in a consortium. The term SP is to be watch-lists of known malicious IP addresses in a consortium. The
interpreted as any type of service provider or CSIRT that may be term "SP" is to be interpreted as any type of service provider or
involved in RID communications. Computer Security Incident Response Team (CSIRT) that may be 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
response may include simply filing a report, notification to the response may include simply filing a report, notification to the
source of the incident, a request to a SP for resolution/mitigation, source of the incident, a request to an SP for resolution/mitigation,
or a request to locate the source. One of the more difficult cases or a request to locate the source. One of the more difficult cases
is that in which the source of an attack is unknown, requiring the is that in which the source of an attack is unknown, requiring the
ability to trace the attack traffic iteratively upstream through the ability to trace the attack traffic iteratively upstream through the
network for the possibility of any further actions to take place. In network for the possibility of any further actions to take place. In
cases when accurate records of an active session between the target cases when accurate records of an active session between the target
or victim system and the source or attacking system are available, or victim system and the source or attacking system are available,
the source is easy to identify. the source is easy to identify.
Real-time inter-network defense (RID) outlines a proactive inter- Real-time inter-network defense (RID) outlines a proactive inter-
network communication method to facilitate sharing incident handling network communication method to facilitate sharing incident-handling
data while integrating existing detection, tracing, source data while integrating existing detection, tracing, source
identification, and mitigation mechanisms for a complete incident identification, and mitigation mechanisms for a complete incident
handling solution. RID provides a secure method to communicate handling solution. RID provides a secure method to communicate
incident information, enabling the exchange of incident object incident information, enabling the exchange of Incident Object
description and exchange format (IODEF) [RFC5070] extensible markup Description and Exchange Format (IODEF) [RFC5070] Extensible Markup
language (XML) documents. RID considers security, policy, and Language (XML) documents. RID considers security, policy, and
privacy issues related to the exchange of potentially sensitive privacy issues related to the exchange of potentially sensitive
information, enabling service providers or organizations the options information, enabling SPs or organizations the options to make
to make appropriate decisions according to their policies. RID appropriate decisions according to their policies. RID includes
includes provisions for confidentiality, integrity, and provisions for confidentiality, integrity, and authentication.
authentication.
The data in RID messages is represented in an XML [XML1.0] document The data in RID messages is represented in an XML [XML1.0] document
using the IODEF and RID. By following this model, integration with using the IODEF and RID. By following this model, integration with
other aspects for incident handling is simplified. Methods are other aspects for incident handling is simplified. Methods are
incorporated into the communication system to indicate what actions incorporated into the communication system to indicate what actions
need to be taken closest to the source in order to halt or mitigate need to be taken closest to the source in order to halt or mitigate
the effects of the incident or attack at hand. RID is intended to the effects of the incident or attack at hand. RID is intended to
provide a method to communicate the relevant information between provide a method to communicate the relevant information between
computer security incident response teams (CSIRTs) while being CSIRTs while being compatible with a variety of existing and possible
compatible with a variety of existing and possible future detection future detection-tracing and response approaches. Incidents may be
tracing and response approaches. Incidents may be extended to extended to include Information Technology (IT) incidents, where RID
include Information Technology (IT) incidents, where RID enables the enables the communication between or within providers for non-
communication between or within providers for non-security IT security IT incidents.
incidents.
Security and privacy considerations are of high concern since Security and privacy considerations are of high concern since
potentially sensitive information may be passed through RID messages. potentially sensitive information may be passed through RID messages.
RID messaging takes advantage of XML security, privacy, and policy RID messaging takes advantage of XML security, privacy, and policy
information set in the RID schema. The RID schema defines information set in the RID schema. The RID schema defines
communication specific metadata to support the communication of IODEF communication-specific metadata to support the communication of IODEF
documents for exchanging or tracing information regarding incidents. documents for exchanging or tracing information regarding incidents.
RID messages are encapsulated for transport, which is defined in a RID messages are encapsulated for transport, which is defined in a
separate document [RFC6046-bis]. The authentication, integrity, and separate document [RFC6546]. The authentication, integrity, and
authorization features RID and RID transport offer are used to authorization features that RID and RID transport offer are used to
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.
1.1. Changes from RFC6045 1.1. Changes from RFC 6045
This document contains the following changes with respect to its This document contains the following changes with respect to its
predecessor [RFC6045]: predecessor [RFC6045]:
o This document is on standards track while [RFC6045] was o This document is Standards Track, while [RFC6045] was published as
informational, but now it is historic. Informational.
o This document, when published, obsoletes [RFC6045] and moves it to o This document obsoletes [RFC6045] and moves it to Historic status.
Historic status.
o This document refers to the updated RID transport specification o This document refers to the updated RID transport specification
[RFC6046-bis], where appropriate. [RFC6546], 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 that IODEF and RID can be used 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 change the focus from
attacks and instead on incidents where appropriate. The term attacks to incidents, where appropriate. The term "network
network provider has been replaced with the more generic term of provider" has been replaced with the more generic term of "service
service provider. Several introductory informational sections provider". Several introductory informational sections have been
have been removed as they are not necessary for the implementation removed as they are not necessary for the implementation of the
of the protocol. The sections include: protocol. The sections include:
* 1.3. Attack Types and RID Messaging, * 1.3. Attack Types and RID Messaging,
* 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 changed to o The schema version was incremented. The schema has changed to
include IODEF [RFC5070] enveloped in RID in the RIDPolicy class include IODEF [RFC5070] enveloped in RID in the RIDPolicy class
using the new ReportSchema class, to include reported errata, to using the new ReportSchema class, to include one verified erratum,
include additional enumerations in the Justification attribute, to to include additional enumerations in the Justification attribute,
remove the AcrossNationalBoundaries region enumeration, to add the to remove the AcrossNationalBoundaries region enumeration, to add
DataWithHandlingRequirements enumeration in TrafficTypes, and to the DataWithHandlingRequirements enumeration in TrafficTypes, and
change the name of the RequestAuthorization MsgType to to change the name of the RequestAuthorization MsgType to
Acknowledgement. Additional text has been provided to clarify Acknowledgement. Additional text has been provided to clarify
definitions of enumerated values for some attributes. The definitions of enumerated values for some attributes. The
RequestAuthorization name was replaced with Acknowledgement to RequestAuthorization name was replaced with Acknowledgement to
more accurately represent the function of that message type. Text more accurately represent the function of that message type. Text
was clarified to note the possible use of this message in response was clarified to note the possible use of this message in response
to Query and Report messages. The attributes were fixed in the to Query and Report messages. The attributes were fixed in the
schema to add 'lang' at the RID class level for language support. schema to add 'lang' at the RID class level for language support.
o The TraceRequest and Investigation messages have been collapsed o The TraceRequest and Investigation messages have been collapsed
into a single message with the requirement to set the MsgType into a single message with the requirement to set the MsgType
according to the functionality required for automation. The according to the functionality required for automation. The
message descriptions were identical with with exception of the message descriptions were identical with the exception of the
MsgType, which remains an exception depending on the desired MsgType, which remains an exception depending on the desired
function. Since both of the enumerations for MsgType are each a function. Since both of the enumerations for MsgType are each a
Request, 'Investigation' is now 'InvestigationRequest'. Content Request, 'Investigation' is now 'InvestigationRequest'. Content
may vary within the IODEF document for the type of Request may vary within the IODEF document for the type of Request
specified. specified.
o The IncidentQuery message description name and MsgType enumeration o The IncidentQuery message description name and MsgType enumeration
value in the schema has been changed to the more generic name of value in the schema have been changed to the more generic name of
'Query'. 'Query'.
o Guidance has improved to ensure consistent implementations and use o Guidance has been improved to ensure consistent implementations
of XML encryption to provide confidentiality based on data and use 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. Additional extension schemas, where the guidance also applies. Additional
guidance and restrictions have been added for XML requirements. guidance and restrictions have been added for XML requirements.
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 o Additional references have been provided to improve
interoperability with stricter guidance on the use of XML digital interoperability with stricter guidance on the use of XML digital
signatures and encryption. signatures and encryption.
1.2. Normative and Informative 1.2. Normative and Informative
Section 1, 2, 3, and 12 provide helpful background information and Sections 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.3. Terminology 1.3. 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
An incident may be defined as a benign configuration issue, IT An incident may be defined as a benign configuration issue, IT
incident, an infraction to a service level agreement (SLA), system incident, an infraction to a service level agreement (SLA), system
compromise, a worm or Trojan infection, or a single- or multiple- compromise, a worm or Trojan infection, or a single- or multiple-
source denial-of-service attack. The goal of tracing a security source denial-of-service attack. The goal of tracing a security
incident may be to identify the source or to find a point on the incident may be to identify the source or to find a point on the
network as close to the origin of the incident as possible. 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 allow 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. Methods to accomplish source is known or has been identified. Methods to accomplish
mitigation may include remediation of a configuration issue, mitigation may include remediation of a configuration issue,
filtering or rate-limiting the traffic close to the source, or taking filtering or rate-limiting the traffic close to the source, or taking
the host or network offline. Care must also be taken to ensure that the host or network offline. Care must also be taken to ensure that
the systems involved in the RID communications are not abused and to the systems involved in the RID communications are not abused and to
use proper analysis in determining if attack traffic is, in fact, use proper analysis in determining if attack traffic is, in fact,
attack traffic at each SP involved in the investigation. attack traffic at each SP involved in the investigation.
Investigating security incidents can be a difficult task since Investigating security incidents can be a difficult task since
attackers go to great lengths to obscure their identity. In the case attackers go to great lengths to obscure their identity. In the case
of a security incident, the true source might be identified through of a security incident, the true source might be identified through
an 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
between individuals or even organized groups of attackers. Through vary between individuals or even organized groups of attackers.
analysis, the techniques may be grouped into indicators of compromise Through analysis, the techniques may be grouped into indicators of
to be shared via IODEF and RID, further assisting with the compromise to be shared via IODEF and RID, further assisting with the
improvement of detection capabilities. Security incidents, including improvement of detection capabilities. Security incidents, including
DDoS attacks, can be difficult or nearly impossible to trace because distributed denial-of-service (DDoS) attacks, can be difficult or
of the nature of the attack. Some of the difficulties in nearly impossible to trace because of the nature of the attack. Some
investigating attacks include the following: of the difficulties in investigating attacks include the following:
o the incident or attack originates from multiple sources; o the incident or attack originates from multiple sources;
o the incident may leverage social-engineering techniques or other
o the incident may leverage social engineering techniques or other
methods to gain access to resources and intellectual property methods to gain access to resources and intellectual property
using what appears to be legitimate access methods such as using what appears to be legitimate access methods such as
outbound web sessions from user systems; outbound web sessions from user systems;
o the attack may include various types of traffic meant to consume o the attack may include various types of traffic meant to consume
server resources, such as a SYN flood attack without a significant server resources, such as a SYN flood attack without a significant
increase in bandwidth utilization; increase in bandwidth utilization;
o the type of traffic could include valid destination services, o the type of traffic could include valid destination services,
which cannot be blocked since they are essential services to which cannot be blocked since they are essential services to
business, such as DNS servers at an SP or HTTP requests sent to an business, such as DNS servers at an SP or HTTP requests sent to an
organization connected to the Internet; organization connected to the Internet;
o the attack may utilize varying types of packets including TCP, o the attack may utilize varying types of packets including TCP,
UDP, ICMP, or other IP protocols; UDP, ICMP, or other IP protocols;
o the attack may be from "zombies" or large "botnets", which then o the attack may be from "zombies" or large botnets, which then
require additional searches to locate a controlling server as the require additional searches to locate a controlling server as the
true origin of the attack; true origin of the attack;
o the attack may use a very small number of packets from any o the attack may use a very small number of packets from any
particular source, thus making a trace after the fact nearly particular source, thus making a trace after the fact nearly
impossible; impossible;
o the indicators of a compromise may be difficult to detect. o the indicators of a compromise may be difficult to detect.
If the source(s) of an incident cannot be determined from IP address If the source(s) of an incident cannot be determined from IP address
information it may be possible to trace the traffic based on information, it may be possible to trace the traffic based on
characteristics of the incident such as tracing the increased characteristics of the incident such as tracing the increased
bandwidth utilization or the type of packets seen by the client. In bandwidth utilization or the type of packets seen by the client. In
the case of packets with spoofed source addresses, it is not a the case of packets with spoofed source addresses, it is not a
trivial task to identify the source of an attack. trivial task to identify the source of an attack.
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 providers. As a result of the urgency access points between service providers. As a result of 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 SP may include A technical solution to trace traffic across a single SP may include
homegrown or commercial systems for which RID messaging must homegrown or commercial systems for which RID messaging must
accommodate the input requirements. The incident handling system accommodate the input requirements. The incident-handling system
used on the SP's backbone by the CSIRT to coordinate the trace across used on the SP's backbone by the CSIRT to coordinate the trace across
the single network requires a method to accept, process, and relay the single network requires a method to accept, process, and relay
RID messages to the system, as well as to wait for responses from the RID messages to the system, as well as to wait for responses from the
system to continue the RID request process as appropriate. In this system to continue the RID request process as appropriate. In this
scenario, each service provider maintains its own system capable of scenario, 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 federation or a group of service
other federation that agrees to participate in the RID communication providers or CSIRTs that agrees to participate in the RID
protocol with an agreed-upon policy and communication protocol communication protocol with an agreed-upon policy and communication
facilitating the secure transport of IODEF/RID XML documents. protocol facilitating the secure transport of IODEF-RID XML
Transport for RID messages is specified in [RFC6046-bis]. documents. Transport for RID messages is specified in [RFC6546].
One goal of RID is to prevent the need to permit access to other One goal of RID is to prevent the need to permit access to other
networks' equipment. RID provides a standard messaging mechanism to networks' equipment. RID provides a standard messaging mechanism to
enable the communication of incident handling information to other enable the communication of incident-handling information to other
providers in a consortium or in neighboring networks. The third providers in a consortium or in neighboring networks. The third
party mentioned above may be used in this technical solution to party mentioned above may be used in this technical solution to
assist in facilitating incident handling and possibly traceback assist in facilitating incident handling and possibly traceback
through smaller providers. The RID messaging mechanism may be a through smaller providers. The RID messaging mechanism may be a
logical or physical out-of-band network to ensure that the logical or physical out-of-band network to ensure that the
communication is secure and unaffected by the state of the network communication is secure and unaffected by the state of the network
under attack. The two management methods would accommodate the needs under attack. The two management methods would accommodate the needs
of larger providers to maintain full management of their network, and of larger providers to maintain full management of their network, and
the third-party option could be available to smaller providers who the third-party option could be available to smaller providers who
lack the necessary human resources to perform incident handling lack the necessary human resources to perform incident-handling
operations. The first method enables the individual providers to operations. The first method enables the individual providers to
involve their network operations staff to authorize the continuance involve (via a notification and alerting system) their network
of a trace or other necessary response to a RID communication request operations staff to authorize the continuance of a trace or other
through their network via a notification and alerting system. necessary response to a RID communication request through their
network.
The network used for the communication should consist of out-of-band The network used for the communication should consist of out-of-band
or protected channels (direct communication links) or encrypted or protected channels (direct communication links) or encrypted
channels dedicated to the transport of RID messages. The channels dedicated to the transport of RID messages. The
communication links would be direct connections (virtual or physical) communication links would be direct connections (virtual or physical)
between peers who have agreed-upon use and abuse policies through a between peers who have agreed-upon use and abuse policies through a
consortium. Consortiums might be linked through policy comparisons consortium. Consortiums might be linked through policy comparisons
and additional agreements to form a larger web or iterative network and additional agreements to form a larger web or iterative network
of peers that correlates to the traffic paths available over the of peers that correlates to the traffic paths available over the
larger web of networks or based on regions and logical groups. larger web of networks or is based on regions and logical groups.
Contact information, IP addresses of RID systems, and other Contact information, IP addresses of RID systems, and other
information must be coordinated between bilateral peers by a information must be coordinated between bilateral peers by a
consortium and may use existing databases, such as the routing consortium and may use existing databases, such as the routing
arbiter. The security, configuration, and confidence rating schemes arbiter. The security, configuration, and Confidence rating schemes
of the RID messaging peers must be negotiated by peers and must meet of the RID messaging peers must be negotiated by peers and must meet
certain overall requirements of the fully connected network certain overall requirements of the fully connected network
(Internet, government, education, etc.) through the peering and/or a (Internet, government, education, etc.) through the peering and/or a
consortium-based agreement. consortium-based agreement.
RID messaging established with clients of an provider may be RID messaging established with clients of an provider may be
negotiated in a contract as part of a value-added service or through negotiated in a contract as part of a value-added service or through
a service level agreement (SLA). Further discussion is beyond the a service level agreement (SLA). Further discussion is beyond the
scope of this document and may be more appropriately handled in scope of this document and may be more appropriately handled in
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 U.S. Federal Bureau of Assurance Certification (GIAC), and the U.S. Federal Bureau of
Investigations (FBI) or other assisting government organization in Investigations (FBI) or other assisting government organization in
the country of the investigation. the country of the investigation.
3.1. Inter-service 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, Query, Request, Acknowledgement, message types include the Report, Query, Request, Acknowledgement,
skipping to change at page 11, line 29 skipping to change at page 11, line 4
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, Query, Request, Acknowledgement, message types include the Report, Query, Request, Acknowledgement,
and Result 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.
A Query message is used to request information on a particular A Query message is used to request information on a particular
incident. A Request message with options set for a TraceRequest is incident. A Request message with options set to 'TraceRequest' is
used when the source of the traffic may have been spoofed. In that used when the source of the traffic may have been spoofed. In that
case, each SP in the upstream path who receives this Request will case, each SP in the upstream path who receives this Request will
issue a trace across the network to determine the upstream source of issue a trace across the network to determine the upstream source of
the traffic. The Acknowledgement and Result messages are used to the traffic. The Acknowledgement and Result messages are used to
communicate the status and result of a Request. The Request message communicate the status and result of a Request. The Request message
with options set for an InvestigationRequest may be sent to any party with options set to 'InvestigationRequest' may be sent to any party
assisting in an incident investigation. The investigation Request assisting in an incident investigation. The InvestigationRequest
message leverages the bilateral relationships or a consortium's 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 Request message address in the case of an InvestigationRequest. A Request message
(TraceRequest or an InvestigationRequest) sent between RID systems to (set to 'TraceRequest' or 'InvestigationRequest') sent between RID
stop traffic at the source through a bordering network requires the systems to stop traffic at the source through a bordering network
information enumerated below: requires the 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 Request with the TraceRequest option set that contains receives a Request with MsgType set to 'TraceRequest' that
its own information in the path, the trace must cease and the RID contains its own information in the path, the trace must cease
system should generate an alert to inform the network operations and the RID system should generate an alert to inform the network
staff that a tracing loop exists. operations 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
skipping to change at page 12, line 45 skipping to change at page 12, line 19
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 a Request
investigation or trace Request. If the Confidence rating (provided message set to 'InvestigationRequest' or 'TraceRequest'. If the
in IODEF) is low, it may not be in the provider's best interest to Confidence rating (provided in IODEF) is low, it may not be in the
continue the investigation or trace Request. The Confidence ratings provider's best interest to continue the Request with options set to
'InvestigationRequest' or 'TraceRequest'. The Confidence ratings
must adhere to the specifications for selecting the percentage used must adhere to the specifications for selecting the percentage used
to avoid abuse of the system. Requests must be issued by authorized to avoid abuse of the system. Requests must be issued by authorized
individuals from the initiating CSIRT, set forth in policy guidelines individuals from the initiating CSIRT, set forth in policy guidelines
established 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.
skipping to change at page 14, line 6 skipping to change at page 13, line 31
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
Request 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
4.1. RID Data Types 4.1. RID Data Types
RID is derived from the IODEF data model and inherits all of the data RID is derived from the IODEF data model and inherits all of the data
types defined in the IODEF model. One data type is added by RID: types defined in the IODEF model. One data type is added by RID:
BOOLEAN. BOOLEAN.
skipping to change at page 14, line 31 skipping to change at page 14, line 9
The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
the schema. Note that there are two lexical representations for the schema. Note that there are two lexical representations for
boolean in [XMLschema]: '1' or 'true' for TRUE and '0' or 'false' or boolean in [XMLschema]: '1' or 'true' for TRUE and '0' or 'false' or
FALSE. FALSE.
4.2. RID Message Types 4.2. RID Message Types
The five 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 [RFC6546]. 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 described RID message types. introduced in Section 5 to support the described RID message types.
1. Request. This message type is used for an investigation or trace 1. Request. This message type is used when a request
Request is needed. The purpose of the investigation Request ('InvestigationRequest' or 'TraceRequest') is needed. The
message is to leverage the existing peer relationships in order purpose of the Request message (set to 'InvestigationRequest') is
to notify the SP closest to the source of the valid traffic of a to leverage the existing peer relationships in order to notify
security-related incident for any necessary actions to be taken. the SP closest to the source of the valid traffic of a security-
The Request for a trace request is used when the traffic has to related incident for any necessary actions to be taken. The
Request (set to 'TraceRequest') is used when the traffic has to
be traced iteratively through networks to find the source by be traced iteratively through networks to find the source by
setting the MsgType to 'TraceRequest'. The setting the MsgType to 'TraceRequest'. The
'InvestigationRequest' MsgType is used for all other Request 'InvestigationRequest' MsgType is used for all other Request
messages. messages.
2. Acknowledgement. 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 provider's RID systems to
provide information on the status of a Request. The provide information on the status of a Request. The
Acknowledgement is also used to provide a reason why a Request, Acknowledgement is also used to provide a reason why a Request,
Report, or Query was not accepted. Report, or Query was not accepted.
3. Result. The Result message is used to provide a final report and 3. Result. The Result message is used to provide a final report and
the notification of actions taken for a Request. This message is the notification of actions taken for a Request. This message is
sent to the initiating CSIRT through the network of RID systems sent to the initiating CSIRT through the network of RID systems
in the path of the trace as notification that the source of the in the path of the trace as notification that the source of the
attack was located. attack was located.
skipping to change at page 15, line 39 skipping to change at page 15, line 18
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 Request message; the IncidentSource indicate the approval status of a Request message; the IncidentSource
class is used to report whether or not a source was found and to class is used to report whether or not a source was found and to
identify the source host(s) or network(s); and the RIDPolicy class identify the source host(s) or network(s); and the RIDPolicy class
provides information on the agreed-upon policies and specifies the provides information on the agreed-upon 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 documents, 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.
skipping to change at page 16, line 43 skipping to change at page 16, line 25
| |<>---{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
Acknowledgement messages. The message reports back to the CSIRT Acknowledgement messages. The message reports back to the CSIRT
or SP in the Acknowledgement message to provide status on a or SP in the Acknowledgement message to provide status on a
Request or if an error or problem occurs with the receipt or Request or if an error or problem occurs with the receipt or
processing of a Report, Query, or Result message. 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 [RFC6546], as that information should be as
as small as possible and may not be encrypted. The RequestStatus 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 [RFC6546].
The RID class has one attribute: The RID class has one attribute:
lang lang
One. REQUIRED. ENUM. A valid language code per [RFC5646] One. REQUIRED. ENUM. A valid language code per [RFC5646]
constrained by the definition of "xs:language" inherited from constrained by the definition of "xs:language" inherited from
[XML1.0]. [XML1.0].
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 [RFC6546].
bis]. The RIDPolicy Class includes the ability to embed an IODEF or The RIDPolicy Class includes the ability to embed an IODEF document
other XML documents that conform to schemas other than IODEF in the or XML documents that conform to schemas other than IODEF in the
ReportSchema element. ReportSchema element.
+------------------------+ +------------------------+
| RIDPolicy | | RIDPolicy |
+------------------------+ +------------------------+
| | | |
| ENUM restriction |<>-------------[ Node ] | ENUM restriction |<>-------------[ Node ]
| ENUM MsgType | | ENUM MsgType |
| ENUM MsgDestination |<>---{0..1}----[ IncidentID ] | ENUM MsgDestination |<>---{0..1}----[ IncidentID ]
| ENUM ext-MsgType | | ENUM ext-MsgType |
skipping to change at page 18, line 27 skipping to change at page 17, line 43
| |<>---{0..1}----[ ReportSchema ] | |<>---{0..1}----[ ReportSchema ]
+------------------------+ +------------------------+
Figure 4: The RIDPolicy Class Figure 4: The RIDPolicy Class
The aggregate elements that constitute the RIDPolicy class are as The aggregate elements that constitute the RIDPolicy class are as
follows: follows:
Node Node
One. The Node class is used to identify a host or network device, One. The Node class is used to identify a host or network device,
in this case to identify the system communicating RID messages and in this case to identify the system communicating RID messages,
the usage is determined by the MsgDestination attribute. The base and the usage is determined by the MsgDestination attribute. The
definition of this class is reused from the IODEF specification base definition of this class is reused from the IODEF
[RFC5070], Section 3.16. See Section 11 of this document for specification [RFC5070], Section 3.16. See Section 11 of this
Internationalization considerations. document for Internationalization considerations.
IncidentID IncidentID
Zero or one. Global reference pointing back to the IncidentID Zero or one. Global reference pointing back to the IncidentID
defined in the IODEF data model. The IncidentID includes the name defined in the IODEF data model. The IncidentID includes the name
of the CSIRT, an incident number, and an instance of that of the CSIRT, an incident number, and an instance of that
incident. The instance number is appended with a dash separating incident. The instance number is appended with a dash separating
the values and is used in cases for which it may be desirable to the values and is used in cases for which it may be desirable to
group incidents. Examples of incidents that may be grouped group incidents. Examples of incidents that may be grouped
include botnets, polymorphic attacks, DDoS attacks, multiple hops include botnets, polymorphic attacks, DDoS attacks, multiple hops
skipping to change at page 19, line 10 skipping to change at page 18, line 30
before a trace can be approved. The PolicyRegion may include before a trace can be approved. The PolicyRegion may include
multiple selections from the attribute list in order to fit all multiple selections from the attribute list in order to fit all
possible policy considerations when crossing regions, consortiums, possible policy considerations when crossing regions, consortiums,
or networks. or networks.
region region
One or many. REQUIRED. ENUM. The attribute region is used to One or many. REQUIRED. ENUM. The attribute region is used to
identify the expected sharing range of the incident information. identify the expected sharing range of the incident information.
The region may be within a region or defined by existing The region may be within a region or defined by existing
relationships such as those of a consortium or client to service relationships such as those of a consortium or a client to a
provider. 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.). An SP may be a network, telecommunications, etc.). An SP may be a network, telecommunications,
infrastructure, or other type of SP where a client to vendor infrastructure, or other type of SP where a client-to-vendor
relationship has been established. The client to vendor relationship has been established. The client-to-vendor
relationship will typically have established contracts or relationship will typically have established contracts or
agreements to define expectations and trust relationships. agreements to define expectations and trust relationships.
2. SPToClient. A service provider (SP) initiated a RID request 2. SPToClient. An SP initiated a RID request or report to a
or report to a client. A client may be an individual, client. A client may be an individual, enterprise, or other
enterprise, or other type of entity (government, commercial, type of entity (government, commercial, education, etc.). An
education, etc.). An SP may be a network, telecommunications, SP may be a network, telecommunications, infrastructure, or
infrastructure, or other type of SP where a client to vendor other type of SP where a client-to-vendor relationship has
relationship has been established. The client to vendor been established. The client-to-vendor relationship will
relationship will typically have established contracts or typically 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, define the expectations on protecting that data, as
having established contractual agreements. Examples of well as have 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.
skipping to change at page 20, line 30 skipping to change at page 20, line 6
should be restricted to one value that most accurately describes should be restricted to one value that most accurately describes
the traffic type. the traffic type.
type type
One or many. REQUIRED. ENUM. The attribute type is used to One or many. REQUIRED. ENUM. The attribute type is used to
identify the type of information included in the RID message or identify the type of information included in the RID message or
the type of incident. the type of 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 an 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
Method and Impact classes for further clarification to assist Method and Impact classes for further clarification to assist
in determining if the trace can be continued ([RFC5070], in determining if the trace can be continued ([RFC5070],
Sections 3.9 and 3.10.1). Sections 3.9 and 3.10.1).
2. Network. This option MUST only be selected when the trace is 2. Network. This option MUST only be selected when the trace is
related to network traffic or routing issues. related to network traffic or routing issues.
3. Content. This category MUST be used only in the case in which 3. Content. This category MUST be used only in the case in which
the request is related to the content and regional the request is related to the content and regional
restrictions on accessing that type of content exist. This is restrictions on accessing that type of content exist. This is
not malicious traffic but may include determining what sources not malicious traffic but may be used for determining what
or destinations accessed certain materials available on the sources or destinations accessed certain materials available
Internet, including, but not limited to, news, technology, or on the Internet, including, but not limited to, news,
inappropriate content. technology, or inappropriate content.
4. DataWithHandlingRequirements. This option is used when data 4. DataWithHandlingRequirements. This option is used when data
shared may have additional restrictions for handling, shared may have additional restrictions for handling,
protection, and processing based on the type of data and where protection, and processing based on the type of data and where
it resides. Regulatory or legal restrictions may be imposed it resides. Regulatory or legal restrictions may be imposed
on specific types of data that could vary based on the on specific types of data that could vary based on the
location, region or nation, of the data or where it location, region or nation, of the data or where it
originated. The IODEF document included, as well as any originated. The IODEF document, as well as any extensions,
extensions, with the RID message should indicate the specific included with the RID message should indicate the specific
restrictions to be considered. The use of this enumeration restrictions to be considered. The use of this enumeration
flag is not legally binding. flag is not legally binding.
5. AudienceRestriction. This option is used to indicate the 5. AudienceRestriction. This option is used to indicate that the
message contains data that should be viewed by a restricted message contains data that should be viewed by a restricted
audience. This setting should not be used for normal audience. This setting should not be used for normal
incidents or reporting as it could slow response times. The incidents or reporting as it could slow response times. The
content may be a business relevant notification or request. content may be a business-relevant notification or request.
This option MAY be used by a business partner to report or This option MAY be used by a business partner to report or
request assistance if an incident has effected a supply chain. request assistance if an incident has affected a supply chain.
This option may also be used if the content is relevant to a This option may also be used if the content is relevant to
regulatory obligations, legal (eDiscovery), or other use cases regulatory obligations, legal (eDiscovery), or other use cases
that require management attention. that require management attention.
6. Other. If this option is selected, a description of the 6. Other. If this option is selected, a description of the
traffic type MUST be provided so that policy decisions can be traffic type MUST be provided so that policy decisions can be
made to continue or stop the investigation. The information made to continue or stop the investigation. The information
should be provided in the IODEF message in the Expectation should be provided in the IODEF message in the Expectation
class or in the History class using a HistoryItem log. This class or in the History class using a HistoryItem log. This
may also be used for incident types other than information may also be used for incident types other than information-
security related incidents. security-related incidents.
7. ext-value. An escape value used to extend this attribute. 7. 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 by RID envelope. Alternate schemas may be included if approved by
the Designated Reviewer and registered by IANA for use with the Designated Reviewer and registered by IANA for use with
RID. 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
One. REQUIRED. ENUM. The type of RID message sent. The five One. REQUIRED. ENUM. The type of RID message sent. The five
types of messages are described in Section 4.2 and can be noted types of messages are described in Section 4.2 and can be noted
as one of the six selections below, where a Request is set to as one of the six selections below, where a Request is set to
either an InvestigationRequest or TraceRequest. either 'InvestigationRequest' or 'TraceRequest'.
1. TraceRequest. This Request message may be used to initiate 1. TraceRequest. This Request message may be used to initiate
a TraceRequest or to continue a TraceRequest to an upstream a 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.
2. Acknowledgement. This message is sent to the initiating 2. Acknowledgement. This message is sent to the initiating
RID system from each of the upstream RID systems to provide RID 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.
3. Result. This message indicates that the source of the 3. Result. This message indicates that the source of the
attack was located and the message is sent to the attack was located, and the message is sent to the
initiating RID system through the RID systems in the path initiating RID system through the RID systems in the path
of the trace. of the trace.
4. InvestigationRequest. This Request message type is used 4. InvestigationRequest. This Request message type is used
when the source of the traffic is believed to be valid. when the source of the traffic is believed to be valid.
The purpose of the InvestigationRequest is to leverage the The purpose of the InvestigationRequest is to leverage the
existing peer or consortium relationships in order to existing peer or consortium relationships in order to
notify the SP closest to the source of the valid traffic notify the SP closest to the source of the valid traffic
that some event occurred, which may be a security-related that some event occurred, which may be a security-related
incident. incident.
5. Report. This message is used to report a security 5. Report. This message is used to report a security incident
incident, for which no action is requested in the IODEF for which no action is requested in the IODEF Expectation
Expectation class. This may be used for the purpose of class. This may be used for the purpose of correlating
correlating attack information by CSIRTs, statistics and attack information by CSIRTs, gathering statistics and
trending information, etc. trending information, etc.
6. Query. This message is used to request information from a 6. Query. This message is used to request information 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
One. REQUIRED. ENUM. The destination required at this level One. REQUIRED. ENUM. The destination required at this level
may either be the RID messaging system intended to receive the may either be the RID messaging system intended to receive the
request, or, in the case of a Request with MsgType set to request, or, in the case of a Request with MsgType set to
'InvestigationRequest', the source of the incident. In the 'InvestigationRequest', the source of the incident. In the
case of an InvestigationRequest, the RID system that can help case of an InvestigationRequest, the RID system that can help
stop or mitigate the traffic may not be known, and the message stop or mitigate the traffic may not be known, and the message
may have to traverse RID messaging systems by following the may have to traverse RID messaging systems by following the
routing path to the RID system closest to the source of the routing path to the RID system closest to the source of the
attack traffic. The Node element lists either the RID system attack traffic. The Node element lists either the RID system
or the IP address of the source, and the meaning of the value or the IP address of the source, and the meaning of the value
in the Node element is determined by the MsgDestination in the Node element is determined by the MsgDestination
skipping to change at page 23, line 33 skipping to change at page 23, line 13
future use with additional RID messages. future use with additional RID messages.
2. SourceOfIncident. The Address element of the Node element 2. SourceOfIncident. The Address element of the Node element
contains the IP address of the incident source, and the contains the IP address of the incident source, and the
NodeName element of the Node class is not used. The IP NodeName element of the Node class is not used. The IP
address is REQUIRED when this option is selected. The IP address is REQUIRED when this option is selected. 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 a address used by the source is believed to be valid and a
Request message with MsgDst set to InvestigationRequest is Request message with MsgDestination set to
used. This is not to be confused with the IncidentSource 'InvestigationRequest' is used. This is not to be confused
class, as the defined value here is from an initial trace with the IncidentSource class, as the defined value here is
or investigation Request, not the source used in a Result from an initial Request ('InvestigationRequest' or
message. 'TraceRequest'), 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.
All extensions shall specify the contents and meaning of All extensions shall specify the contents and meaning of
the Node element of RIDPolicy. See IODEF [RFC5070], the Node element of RIDPolicy. See IODEF [RFC5070],
Section 5.1 on extensibility. If the NodeName element of Section 5.1, on extensibility. If the NodeName element of
the Node class is used by an extension, NodeName may the Node class is used by an extension, NodeName may
contain an Internationalized Domain Name (IDN); see Section contain an Internationalized Domain Name (IDN); see
11 for applicable requirements. All extensions SHOULD use Section 11 for applicable requirements. All extensions
an IP address in the Address element of the Node class as SHOULD use an IP address in the Address element of the Node
the primary means of Node identification. class as the primary means of Node identification.
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
skipping to change at page 24, line 37 skipping to change at page 24, line 24
| |<>---{0..*}----[ Signature ] | |<>---{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'
meaning is set to "xml" to include an xml document. and meaning is set to 'xml' to include an XML document.
URL URL
Zero or One. URL. A reference to the XML schema of the XML Zero or One. URL. A reference to the XML schema of the XML
document included. The URL data type is defined in [RFC5070] document included. The URL data type is defined in [RFC5070],
Section 2.15 as "xs:anyURI" in the schema. The schemaLocation Section 2.15, as "xs:anyURI" in the schema. The schemaLocation
for IODEF is already included in the RID schema, so this is not for IODEF is already included in the RID schema, so this is not
necessary to include a URL for IODEF documents. The list of necessary to include a URL for IODEF documents. The list of
registered schemas for inclusion will be maintained by IANA. registered schemas for inclusion will be maintained by IANA.
Signature Signature
Zero to many. The Signature uses the iodef:ExtensionType class Zero to many. The Signature uses the iodef:ExtensionType class
to enable this element to contain a detached or enveloped to enable this element to contain a detached or enveloped
signature. This class follows the guidelines in [RFC5070] signature. This class follows the guidelines in [RFC5070]
Section 5 where the data type is set to "xml" and meaning is Section 5 where the data type is set to 'xml' and meaning is
set to "xml" to include an xml document. This element is used set to 'xml' to include an XML document. This element is used
to 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 or to include the enveloped originator of the message or to include the enveloped
signature. If other schemas are used instead of IODEF, they signature. If other schemas are used instead of IODEF, they
MUST provide guidance on what class to use if a detached MUST provide guidance on what class to use if a detached
signature is provided for this purpose. 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. That schema must be an approved the specified XML schema. That schema must be an approved
version of IODEF or a schema registered with IANA for use with version of IODEF or a schema registered with IANA for use with
RID. The IANA registry for managing schemas other than IODEF RID. The IANA registry for managing schemas other than IODEF
is specified in Section 11. is specified in Section 12.
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
of the included XML schema. This attribute is used if a schema number of the included XML schema. This attribute is used if a
other than IODEF or an IANA registered schema that has been schema other than IODEF or an IANA-registered schema that has
added to the enumerated list for Version is included. been 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,
the defined namespace[XMLNames], of the XML schema of the XML the defined namespace [XMLNames], of the XML schema of the XML
document included. The XMLSchemaID and Version specify the document included. The XMLSchemaID and Version specify the
format of the XMLDocument element. The only permitted values, format of the XMLDocument element. The only permitted values,
include the namespace for IODEF [RFC5070], include the namespace for IODEF [RFC5070],
"urn:ietf:params:xml:ns:iodef-1.0", any future IETF approved "urn:ietf:params:xml:ns:iodef-1.0", any future IETF-approved
versions of IODEF, and any namespace included in the IANA versions of IODEF, and any namespace included in the IANA-
managed list of registered schemas for use with RID. The IANA managed list of registered schemas for use with RID. The IANA
registry for managing schemas other than IODEF is specified in registry for managing schemas other than IODEF is specified in
Section 11. Section 12.
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
(defined namespace) of the XML schema of the XML document identifier (defined namespace) of the XML schema of the XML
included. The ext-XMLSchemaID and ext-Version specify the document included. The ext-XMLSchemaID and ext-Version specify
format of the XMLDocument element and are used if the included the format of the XMLDocument element and are used if the
schema is not IODEF version 1.0 or an IANA registered schema included schema is not IODEF version 1.0 or an IANA-registered
that has been added to the enumerated list for XMLSchemaID. schema that has been added to the enumerated list for
XMLSchemaID.
5.2. RequestStatus 5.2. RequestStatus
The RequestStatus class is an aggregate class in the RID class. The RequestStatus class is an aggregate class in the RID class.
+--------------------------------+ +--------------------------------+
| RequestStatus | | RequestStatus |
+--------------------------------+ +--------------------------------+
| | | |
| ENUM restriction | | ENUM restriction |
skipping to change at page 26, line 47 skipping to change at page 26, line 35
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.
AuthorizationStatus AuthorizationStatus
One. REQUIRED. ENUM. The listed values are used to provide a One. REQUIRED. ENUM. The listed values are used to provide a
response to the requesting CSIRT of the status of a Request, response to the requesting CSIRT of the status of a Request,
Report, or Query. 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 Acknowledgement 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 must be used from the
the source to indicate actions taken in the IODEF History closest SP to the source in order to indicate actions taken
class. in the IODEF History 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
Acknowledgement 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
skipping to change at page 27, line 36 skipping to change at page 27, line 27
1. SystemResource. A resource issue exists on the systems 1. SystemResource. A resource issue exists on the systems
that would be involved in the request. that would be involved in the request.
2. Authentication. The enveloped digital signature 2. Authentication. The enveloped digital signature
[RFC3275] failed to validate. [RFC3275] failed to validate.
3. AuthenticationOrigin. The detached digital signature 3. AuthenticationOrigin. The detached digital signature
for the original requestor on the RecordItem entry for the original requestor on the RecordItem entry
failed to validate. failed to validate.
4. Encryption. Unable to decrypt the request, report, or 4. Encryption. The recipient was unable to decrypt the
query. request, report, or query.
5. UnrecognizedFormat. The format of the provided document 5. UnrecognizedFormat. The format of the provided document
was unrecognized. was unrecognized.
6. CannotProcess. The document could not be processed. 6. CannotProcess. The document could not be processed.
Reasons may include legal or policy decisions. Reasons may include legal or policy decisions.
Resolution may require communication outside of this Resolution may require communication outside of this
protocol to resolve legal or policy issues. No further protocol to resolve legal or policy issues. No further
messages SHOULD be sent until resolved. messages SHOULD be sent until resolved.
skipping to change at page 28, line 37 skipping to change at page 28, line 31
| |<>---{0..*}----[ Node ] | |<>---{0..*}----[ Node ]
| | | |
+-------------------+ +-------------------+
Figure 7: The IncidentSource Class Figure 7: The IncidentSource Class
The elements that constitute the IncidentSource class follow: The elements that constitute the IncidentSource class follow:
SourceFound SourceFound
One. BOOLEAN. The Source class indicates if a source was One. BOOLEAN. The Source class indicates if a source was
identified. If the source was identified, it is listed in the identified. If the source was identified, it is listed in the
Node element of this class. Node element of this class.
True. Source of incident was identified. True. Source of incident was identified.
False. Source of incident was not identified. False. Source of incident was not identified.
Node Node
Zero or many. The Node class is used to identify a system Zero or many. The Node class is used to identify a system
identified as part of an incident. If this element is used, identified as part of an incident. If this element is used,
the Address element of the Node element MUST contain the IP the Address element of the Node element MUST contain the IP
address of the system. If the NodeName element of the Node address of the system. If the NodeName element of the Node
class is used, it contains a DNS domain name that has been class is used, it contains a DNS domain name that has been
checked to ensure that it resolved to that IP address when the checked to ensure that it resolved to that IP address when the
check was performed. See Section 11 of this document for check was performed. See Section 11 of this document for
internationalization considerations for NodeName. The base internationalization considerations for NodeName. The base
definition of this class from the IODEF [RFC5070] can be definition of this class from the IODEF ([RFC5070], Section
expanded to include other identifiers, Section 3.16. 3.16) can be expanded to include other identifiers.
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
This guideline provides no real security since it is the choice adhere.This guideline provides no real security since it is the
of the recipient of the document to honor it. This attribute choice of the recipient of the document to honor it. This
follows the same guidelines as "restriction" used in IODEF. attribute 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 The RID schema declares a namespace of
"urn:ietf:params:xml:ns:iodef-rid-2.0" and registers it per "urn:ietf:params:xml:ns:iodef-rid-2.0" and registers it per
[RFC3688]. Each IODEF-RID document MUST use the "iodef-rid-2.0" [RFC3688]. Each IODEF-RID document MUST use the "iodef-rid-2.0"
namespace in the top-level element RID-Document. It can be namespace in the top-level element RID-Document. It can be
referenced as follows: referenced as follows:
<RID-Document version="2.0" lang="en-US" <RID-Document version="2.0" lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0" xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0.xsd"> xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0.xsd">
5.5. Encoding 5.5. Encoding
RID documents MUST begin with an XML declaration, MUST specify the RID documents MUST begin with an XML declaration and MUST specify the
XML version used, and the use of UTF-8 encoding is REQUIRED [RFC3470] XML version used; also, the use of UTF-8 encoding is REQUIRED
Section 4.4. RID conforms to all XML data encoding conventions and ([RFC3470], Section 4.4). RID conforms to all XML data encoding
constraints. conventions and constraints.
The XML declaration with no character encoding will read as follows: The XML declaration with no character encoding will read as follows:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
The following characters have special meaning in XML and MUST be The following characters have special meaning in XML and MUST be
escaped with their entity reference equivalent: "&", "<", ">", "\"" escaped with their entity reference equivalent: "&", "<", ">", "\""
(double quotation mark), and "'" (apostrophe). These entity (double quotation mark), and "'" (apostrophe). These entity
references are "&amp;", "&lt;", "&gt;", "&quot;", and "&apos;" references are "&amp;", "&lt;", "&gt;", "&quot;", and "&apos;",
respectively. respectively.
5.6. Including IODEF or other XML Documents 5.6. 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 through the 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 also 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".
2. When a parser encounters an included XML document it does not 2. When a parser encounters an included XML document it does not
understand, it MUST be ignored (and not processed), but the understand, the included document MUST be ignored (and not
remainder of the document MUST be processed. Parsers will be processed), but the remainder of the document MUST be processed.
able to identify the XML documents for which they have no Parsers will be able to identify the XML documents for which they
processing logic through the namespace declaration. Parsers that have no processing logic through the namespace declaration.
encounter an unrecognized element in a namespace that they do Parsers that encounter an unrecognized element in a namespace
support SHOULD reject the document as a syntax error. that they do support SHOULD reject the document as a syntax
error.
3. Implementations SHOULD NOT download schemas at runtime due to the 3. Implementations SHOULD NOT download schemas at runtime due to the
security implications, and included documents MUST NOT be security implications, and included documents MUST NOT be
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"
URL: "http://www.iana.org/assignments/xml-registry/schema/ URL: "http://www.iana.org/assignments/xml-registry/schema/
iodef-1.0.xsd" iodef-1.0.xsd"
The URL is optionally included for IODEF since it is already in the The URL is optionally included for IODEF since it is already in the
RID schema and the schemaLocation is defined. RID schema, and the schemaLocation is defined.
5.6.1. Including XML Documents in RID 5.6.1. Including XML Documents in RID
The Common Vulnerability Reporting Format (CVRF) is an additional XML schemas may be registered for inclusion in a RID message. This
schema registered for inclusion in a RID message. The registered may include schemas other than IODEF or updated versions of IODEF.
IANA information for additional schemas MUST include the The registered IANA information for additional schemas MUST include
specification name, version, specification Uniform Resource the specification name, version, specification Uniform Resource
Identifier (URI), and namespace. The following provides an example Identifier (URI), and namespace. The following provides an example
of the necessary information for additional schemas beyond IODEF and of the necessary information for additional schemas beyond IODEF.
CVRF.
Common Vulnerability Reporting Format (CVRF) Example Name (XXXX)
Schema Name: CVRF_1.0 Schema Name: XXXX_1.1
Version: 1.0 Version: 1.1
Namespace: http://www.icasi.org/CVRF/schema/cvrf/1.0 Namespace: <registered namespace>
Specification URI: http://www.icasi.org/cvrf Specification URI: http://www.example.com/XXXX
The version attribute of the ReportSchema class is populated with the The version attribute of the ReportSchema class is populated with the
approved versions of IODEF, CVRF, and any additional schemas approved versions of IODEF or any additional schemas registered by
registered by IANA, see Section 11. IANA; see Section 12.
The XMLSchemaID of the ReportSchema class is populated with the The XMLSchemaID of the ReportSchema class is populated with the
namespace of the included schema. The attribute enumeration values namespace of the included schema. The attribute enumeration values
include the namespace for IODEF and CVRF and any schema registered by include the namespace for IODEF and any schema registered by IANA;
IANA, see Section 11. see Section 12.
The URL element of the ReportSchema class is populated with the The URL element of the ReportSchema class is populated with the
Specification URI value of the included schema. 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
skipping to change at page 32, line 8 skipping to change at page 31, line 45
proper parsing of those messages. proper parsing of those 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 those used in the EventData class. such as those used in the EventData class.
6.1. Request 6.1. Request
Description: This message type is used to request assistance in a Description: This message type is used to request assistance in a
computer security investigation. The investigation Request may be computer security investigation. The investigation request may be
directed to another party that can assist with forensics, continue directed to another party that can assist with forensics and continue
the investigation (incident may have originated on the SP network to the investigation (the incident may have originated on the SP network
which the Request was sent), or even to an SP to trace the traffic to which the Request was sent), or it may be directed to an SP to
from an unknown source. The Request message with MsgType set to trace the traffic from an unknown source. The Request message with
'InvestigationRequest' may leverage the existing bilateral peer MsgType set to 'InvestigationRequest' may leverage the existing
relationships in order to notify the SP closest to the source of the bilateral peer relationships in order to notify the SP closest to the
valid traffic that some event occurred, which may be a security- source of the valid traffic that some event occurred, which may be a
related incident. A Request message with the MsgType set to security-related incident. A Request message with the MsgType set to
'TraceRequest' may be sent to an upstream peer to trace back through 'TraceRequest' may be sent to an upstream peer to trace back through
the network to locate the source of malicious traffic. The following the network to locate the source of malicious traffic. The following
information is REQUIRED for Request messages and is provided through: information is REQUIRED for Request messages and is provided through
the following data structures:
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). Timestamps (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
class). class).
System class is used to list both the Source and Destination. System class is used to list both the Source and Destination.
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 SP path contact information. in addition to that used to convey SP 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 receiving the Request using the RID message, passed to all systems receiving the Request using
a detached XML digital signature on a RecordItem entry, placed in a detached XML digital signature on a RecordItem entry, placed in
an instance of the Signature element. 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. 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 Request message using the public key of the contents of the Request message using the public key of the
destination RID system. The incident number increases whether the destination RID system. The incident number increases whether the
Request message has the MsgDst set to 'InvestigationRequest' or Request message has the MsgDestination set to 'InvestigationRequest'
'TraceRequest' in order to ensure uniqueness within the system. The or 'TraceRequest' in order to ensure uniqueness within the system.
relaying peers also append their Autonomous System (AS) or RID system The relaying peers also append their Autonomous System (AS) or RID
information using the NPPath element as the Request message was system information using the path information as the Request message
relayed through SPs. This enables the response (Result message) to was relayed through SPs. This enables the response (Result message)
utilize the same path and trust relationships for the return message, to utilize the same path and trust relationships for the return
indicating any actions taken. The request is recorded in the state message, indicating any actions taken. The request is recorded in
tables of both the initiating and destination SP RID systems. The the state tables of both the initiating and destination SP RID
destination SP is responsible for any actions taken as a result of systems. The destination SP is responsible for any actions taken as
the request in adherence to any service level agreements or policies. a result of the request in adherence to any service level agreements
The SP MUST confirm that the traffic actually originated from the or policies. The SP MUST confirm that the traffic actually
suspected system before taking any action and confirm the reason for originated from the suspected system before taking any action and
the request. The request may be sent directly to a known RID system confirm the reason for the request. The request may be sent directly
or routed by the source address of the attack using the message to a known RID system or routed by the source address of the attack
destination of RIDPolicy, SourceOfIncident. Note: Any intermediate using the MsgDestination of RIDPolicy set to 'SourceOfIncident'.
parties in a TraceRequest MUST be able to view RIDPolicy information Note: Any intermediate parties in a TraceRequest MUST be able to view
of responding message types in order to properly direct RID messages. 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 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 Requests from a single incident. If a single to identify multiple Requests from a single incident. If a single
Request results in divergent paths of Requests, a separate instance Request results in divergent paths of Requests, a separate instance
number MUST be used under the same IncidentID. The IncidentID number MUST be used under the same IncidentID. The IncidentID
instance number of IODEF can be used to correlate related incident instance number of IODEF can be used to correlate related incident
data that is part of a larger incident. data that is part of a larger incident.
6.2. Acknowledgement 6.2. Acknowledgement
Description: The Acknowledgement is also used to provide a status to Description: The Acknowledgement is also used to provide a status to
any message type along with a Justification if the message could not any message type and to provide a Justification if the message could
be processed for any reason. This message is sent to the initiating not be processed for any reason. This message is sent to the
RID system from the next upstream provider's application or system initiating RID system from the next upstream provider's application
designated for accepting RID communications to provide information on or system designated for accepting RID communications to provide
the request status in the current SP. information on the request status in the current SP.
The following information is REQUIRED for Acknowledgement messages The following information is REQUIRED for Acknowledgement messages
and is provided through: and is provided through the following data structures:
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:
skipping to change at page 34, line 38 skipping to change at page 34, line 26
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.
A message is sent back to the initiating CSIRT or provider's system A message is sent back to the initiating CSIRT or provider's system;
accepting RID communications of the trace as status notification. it accepts RID communications of the trace as status notification.
This message verifies that the next RID system in the path has This message verifies that the next RID system in the path has
received the message from the previous system in the path. This received the message from the previous system in the path. This
message also verifies that the trace is now continuing, has stopped, message also verifies that the trace is now continuing, has stopped,
or is pending in the next upstream CSIRT or provider's RID system. or is pending in the next upstream CSIRT or provider's RID system.
The Pending status is automatically generated after a 2-minute The Pending status is automatically generated after a 2-minute
timeout without system-predefined or administrator action taken to timeout without system-predefined or administrator action to approve
approve or disapprove the trace continuance. If a Request is denied, or disapprove the trace continuance. If a Request is denied, the
the originator and sending peer (if they are not the same) MUST both originator and sending peer (if they are not the same) MUST both
receive the message. This enables the sending peer the option to receive the message. This provides the sending peer with the option
take action to stop or mitigate the traffic as close to the source as to take action to stop or mitigate the traffic as close to the source
possible. as possible.
6.3. Result 6.3. Result
Description: This message indicates that the trace or investigation Description: This message indicates that the trace or investigation
has been completed and provides the result. The Result message has been completed and provides the result. The Result message
includes information on whether or not a source was found and the includes information on whether or not a source was found, and the
source information is provided through the IncidentSource class. The source information is provided through the IncidentSource class. The
Result information MUST go back to the originating RID system that Result information MUST go back to the originating RID system that
began the investigation or trace. An provider may use any number of began the investigation or trace. A provider may use any number of
incident handling data sources to ascertain the true source of an incident-handling data sources to ascertain the true source of an
attack. All of the possible information sources may or may not be attack. All of the possible information sources may or may not be
readily tied into the RID communications system. readily tied into the RID communications system.
The following information is REQUIRED for Result messages and will be The following information is REQUIRED for Result messages and will be
provided through: provided through the following data structures:
RID Information: RID Information:
RIDPolicy RIDPolicy
RID message type, IncidentID, and destination policy RID message type, IncidentID, and destination policy
information information
Incident Source Incident Source
The IncidentSource class of the RID schema is used to note The IncidentSource class of the RID schema is used to note
if a source was identified and provide the source if a source was identified and provide the source
address(es) or other Node information. address(es) or other Node information.
IODEF Information: IODEF Information:
Time Stamps (DetectTime, StartTime, EndTime, ReportTime). Timestamps (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 is used for multiple traces of a single
incident; MUST be included if the response is specific to an incident; it MUST be included if the response is specific to
instance of an incident. an 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 Request set to spoofed, thus requiring in RID an upstream Request set to
'TraceRequest' in RID. 'TraceRequest'.
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
category set to "infrastructure". The last SP listed is the SP category set to 'infrastructure'. The last SP listed is the SP
that located the source of the traffic (the provider sending that located the source of the traffic (the provider sending
the Result message). the Result message).
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). Note: Event information included here requires a (optional). Note: Event information included here requires a
second instance of EventData in addition to that used to convey second instance of EventData in addition to that used to convey
SP path contact information. SP path contact information.
Standards for encryption and digital signatures [RFC3275], Standards for encryption and digital signatures [RFC3275],
skipping to change at page 36, line 39 skipping to change at page 36, line 29
markers. markers.
A message is sent back to the initiating CSIRT or provider's RID A message is sent back to the initiating CSIRT or provider's RID
system to notify the CSIRT that the source has been located. The system to notify the CSIRT that the source has been located. The
actual source information may or may not be included, depending on actual source information may or may not be included, depending on
the policy of the network in which the client or host is attached. the policy of the network in which the client or host is attached.
Any action taken by the SP to act upon the discovery of the source of Any action taken by the SP to act upon the discovery of the source of
a trace should be included. The SP may be able to automate the a trace should be included. The SP may be able to automate the
adjustment of filters at their border router to block outbound access adjustment of filters at their border router to block outbound access
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 and block all Internet access until the host has
host has taken the appropriate action to resolve any security issues taken the appropriate action to resolve any security issues. The SP
or to rate-limit the ingress traffic as close to the source as may be limited in their options for filtering due to agreements or
possible. other restrictions resulting in less comprehensive filters, such as
rate-limiting the ingress traffic as close to the source as 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 Request using the of the possible actions taken as a result of a RID Request using the
"iodef:atype", or action type, attribute. The History class should "iodef:atype", or action type, attribute. The History class should
be used to note all actions taken close to the source of a trace or be used to note all actions taken close to the source of a trace or
incident using the most appropriate option for the type of action incident using the most appropriate option for the type of action
along with a description. The "atype" attribute in the Expectation along with a description. The "atype" attribute in the Expectation
skipping to change at page 37, line 15 skipping to change at page 37, line 6
Request is made. Request is made.
6.4. 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 the following data structures:
RID Information: RID Information:
RID Policy RID message type, IncidentID, and destination policy RIDPolicy RID message type, IncidentID, and destination policy
information information
The following data is RECOMMENDED if available and can be provided The following data is RECOMMENDED if available and can be provided
through: through the following data structures:
IODEF Information: IODEF Information:
Time Stamps (DetectTime, StartTime, EndTime, ReportTime). Timestamps (DetectTime, StartTime, EndTime, ReportTime).
Incident Identifier (Incident class, IncidentID). Trace number Incident Identifier (Incident class, IncidentID).
- used for multiple traces of a single incident; MUST be
included if the Report is specific to an instance of an Trace number is used for multiple traces of a single
incident. incident; it MUST be included if the Report is specific to
an 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. Information used in the attack.
Event, Record, and RecordItem classes to include example Event, Record, and RecordItem classes are used to include
packets and other information related to the incident example 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, placed in an instance of the Signature element. 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
skipping to change at page 38, line 17 skipping to change at page 38, line 6
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 to respond
to a Query, and data sensitivity must be considered in both cases. to a Query, and data sensitivity must be considered in both cases.
The SP path information is not necessary for this message, as it will The SP path information is not necessary for this message, as it will
be communicated directly between two trusted RID systems. be communicated directly between two trusted RID systems.
6.5. Query 6.5. Query
Description: The Query 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 Query, the return report other unique information is included in the Query, the return report
may be automated; otherwise, analyst intervention may be required. may be automated; otherwise, analyst intervention may be required.
The following information is REQUIRED for a Query message and is The following information is REQUIRED for a Query message and is
provided through: provided through the following data structures:
RID Information: RID Information:
RID Policy RIDPolicy
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). Timestamps (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 is used for multiple traces of a single
incident; MUST be included if the Query is an instance of an incident; it MUST be included if the Query is an instance of
incident. 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. Information used in the attack.
Event, Record, and RecordItem classes to include example Event, Record, and RecordItem classes are used to include
packets and other information related to the incident example 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 Query using an message, passed to all systems receiving the Query using an
enveloped XML digital signature, placed in an instance of the enveloped XML digital signature, placed in an instance of the
Signature element. 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 Query 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 preset 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 better suited 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 Query message to select only The Confidence rating may be used in the Query message to select only
incidents with an equal or higher Confidence rating than what is incidents with an equal or higher Confidence rating than what is
specified. This may be used for cases when information is gathered specified. This may be used for cases when information is gathered
on a type of incident but not on specifics about a single incident. on a type of incident but not on specifics about a single incident.
Source and Destination Information may not be needed if the Query is Source and Destination Information may not be needed if the Query is
intended to gather data about a specific type of incident. intended to gather data about a specific type of incident.
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: The possible set of message exchanges include:
o Request: Asynchronous Request for assistance and/or action to be o Request: Asynchronous Request for assistance and/or action to be
taken, MAY involve multiple systems and iterative Requests taken, MAY involve multiple systems and iterative Requests
MsgType set to InvestigationRequest or TraceRequest
MsgType set to 'InvestigationRequest' or 'TraceRequest'
Possible responses: Possible responses:
+ Acknowledgement (OPTIONAL for InvestigationRequest) + Acknowledgement (OPTIONAL for InvestigationRequest)
+ Result (REQUIRED unless Acknowledgement was set to no) + Result (REQUIRED unless Acknowledgement was set to 'no')
+ Report (OPTIONAL, zero or more: Report can be sent + Report (OPTIONAL; zero or more; Report can be sent
unsolicited) unsolicited)
o Query: Synchronous request for information o Query: Synchronous request for information
MsgType set to Query MsgType set to 'Query'
Possible responses: Possible responses:
+ Acknowledgement (OPTIONAL if yes, required if no Report will + Acknowledgement (OPTIONAL if yes; REQUIRED if no Report will
be sent) be sent)
+ Report (REQUIRED unless Acknowledgement was set to no) + Report (REQUIRED unless Acknowledgement was set to 'no')
o Report: Asynchronous information report, may be pushed to systems o Report: Asynchronous information report; may be pushed to systems
or a response from a Query or may be a response to a Query
MsgType set to Report MsgType set to 'Report'
Possible responses: Possible responses:
+ Acknowledgement (OPTIONAL) + Acknowledgement (OPTIONAL)
Processing considerations for the IODEF document and any IODEF Processing considerations for the IODEF document and any IODEF
included elements or attributes MUST follow the guidelines specified included elements or attributes MUST follow the guidelines specified
in [RFC5070] Section 4. [RFC3023] and [RFC3470] specify requirements in [RFC5070], Section 4. [RFC3023] and [RFC3470] specify
and best practices for the use of XML in IETF application protocols. requirements and best practices for the use of XML in IETF
RID and IODEF documents MUST be well-formed [RFC3470], see Section application protocols. RID and IODEF documents MUST be well-formed
4.1, and MUST be validated against the appropriate schema. Internal (see [RFC3470], Section 4.1) and MUST be validated against the
or external DTD subsets are prohibited in RID, see [RFC3023] Section appropriate schema. Internal or external DTD subsets are prohibited
3. in RID; see [RFC3023], Section 3.
Comments can be ignored by conform ant processors for RID or IODEF Comments can be ignored by conform ant processors for RID or IODEF
documents [RFC3470], see Section 4.6, and are included below for documents (see [RFC3470], Section 4.6) and are included below for
informational purposes only. The first example demonstrates the use informational purposes only. The first example demonstrates the use
of a detached digital signature. Subsequent examples do not include of a detached digital signature. Subsequent examples do not include
the detached signature required for some message types. The the detached signature required for some message types. The
signature is applied after the message is created as demonstrated in signature is applied after the message is created as demonstrated in
the first example. the first example.
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 Request communication flow for a The diagram below outlines the RID Request communication flow for a
TraceRequest between RID systems on different networks tracing an TraceRequest between RID systems on different networks tracing an
attack. The Request message with MsgDst set to 'TraceRequest' is attack. The Request message with MsgDestination set to
represented in the diagram by TraceRequest. SP-1, SP-2, SP-3 'TraceRequest' is represented in the diagram by "TraceRequest".
represent service providers that are involved in the example trace SP-1, SP-2, and SP-3 represent service providers that are involved in
communication flow. 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
skipping to change at page 42, line 43 skipping to change at page 41, line 46
11. Locate attack 11. Locate attack
source on network X source on network X
12. <------------Result----------------o 12. <------------Result----------------o
13. o- - - - -Acknowledgement- - - - - > 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 that 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 an Acknowledgement message The communication flow demonstrates that an Acknowledgement message
is sent to both the downstream peer and the original requestor. If a is sent to both the downstream peer and the original requestor. If a
Request in a traceback is denied, the downstream peer has the option Request in a traceback is denied, the downstream peer has the option
to take an action and respond with a Result message. The originator to take an action and respond with a Result message. The originator
of the request may follow up with the downstream peer of the SP of the request may follow up with the downstream peer of the SP
involved using a Request with the MsgType set to involved using a Request with the MsgType set to
'InvestigationRequest' to ensure that an action is taken if no 'InvestigationRequest' to ensure that an action is taken if no
response is received. Nothing precludes the originator of the response is received. Nothing precludes the originator of the
request from initiating a new Request with the MsgType set to request from initiating a new Request with the MsgType set to
'TraceRequest' bypassing the SP that denied the request, if a trace 'TraceRequest' thereby bypassing the SP that denied the request, if a
is needed beyond that point. Another option may be for the initiator trace is needed beyond that point. Another option may be for the
to send an 'InvestigationRequest' to an SP upstream of the SP that initiator to send an 'InvestigationRequest' to an SP upstream of the
denied the request. This action assumes enough information was SP that denied the request. This action assumes enough information
gathered to discern the true source of the attack traffic from the was gathered to discern the true source of the attack traffic from
incident handling information. the incident-handling information.
The proper response to a TraceRequest is an Acknowledgement message. The proper response to a TraceRequest is an Acknowledgement message.
The Acknowledgement message lets the requestor know if the trace will The Acknowledgement message lets the requestor know if the trace will
continue through the next upstream network. If there is a problem continue through the next upstream network. If there is a problem
with the request, such as a failure to validate the digital signature with the request, such as a failure to validate the digital signature
or decrypt the request, an Acknowledgement message MUST be sent to or decrypt the request, an Acknowledgement message MUST be sent to
the requestor and the downstream peer (if they are not one and the the requestor and the downstream peer (if they are not one and the
same) providing the reason why the message could not be processed. same) providing the reason why the message could not be processed.
Assuming that the trace continued, additional TraceRequests with the Assuming that the trace continued, additional TraceRequests with the
response of an Acknowledgement message would occur passing the response of an Acknowledgement message would occur, thereby passing
request upstream in the path to the source of the traffic related to the request upstream in the path to the source of the traffic related
the incident. Once a source is found, a Result message is sent to to the incident. Once a source is found, a Result message is sent to
the originator of the trace, as determined by the SP path information the originator of the trace, as determined by the SP path information
provided through the document instance of EventData, where contact is provided through the document instance of EventData, where contact is
set to "infrastructure". The SP path information is also used when set to 'infrastructure'. The SP path information is also used when
sending the Acknowledgement messages to the first entry (the trace sending the Acknowledgement 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, an originator fails to decrypt or authenticate the Result message, an
Acknowledgement message is sent in response; otherwise, no return Acknowledgement message is sent in response; otherwise, no return
message is sent. The final Acknowledgement to the Result message is message is sent. The final Acknowledgement to the Result message is
depicted as optional in the diagram above. If an Acknowledgement depicted as optional in the diagram above. If an Acknowledgement
message is sent with the RequestStatus set to Denied, a downstream message is sent with the RequestStatus set to Denied, a downstream
peer receiving this message may choose to take action to stop or peer receiving this message may choose to take action to stop or
mitigate the traffic at that point in the network, as close to the mitigate the traffic at that point in the network, as close to the
source as possible. If the downstream peer chooses this option, it source as possible. If the downstream peer chooses this option, it
would send a Result message to the trace originator. 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 Request message with MsgDst set to The example listed is of a Request message with MsgDestination set to
'TraceRequest' based on the incident report example from the IODEF 'TraceRequest' based on the incident report example from the IODEF
document. The RID classes were included as appropriate for a Request document. The RID classes were included as appropriate for a Request
message of this type using the RIDPolicy class. The example given is message of this type using the RIDPolicy class. The example given is
that of a CSIRT reporting a DoS attack in progress to the upstream that of a CSIRT reporting a DoS attack in progress to the upstream
SP. The request asks the next SP to continue the trace and have the SP. The request asks the next SP to continue the trace and have the
traffic mitigated closer to the source of the traffic. The example traffic mitigated closer to the source of the traffic. The example
Request message is the first step of a TraceRequest as depicted in Request message is the first step of a TraceRequest as depicted in
the previous diagram, where 'Attack Dest' is represented by the previous diagram, where 'Attack Dest' is represented by
192.0.2.67 (and SP-1). The "Attack Src' is later identified in the 192.0.2.67 (and SP-1). The 'Attack Src' is later identified in the
Result message example as 192.0.2.37 and initially as tracing closer Result message example as 192.0.2.37 and initially as tracing closer
to 192.0.2.35. 'SP-1' is identified in the Request as CSIRT-FOR-OUR- to 192.0.2.35. SP-1 is identified in the Request as CSIRT-FOR-OUR-
DOMAIN, and 'SP-2' is identified in the RID document for the Request DOMAIN, and SP-2 is identified in the RID document for the Request as
as the 'RIDSystem' in 'MsgDestination' as 192.0.2.3 using the Node the 'RIDSystem' in 'MsgDestination' as 192.0.2.3 using the Node
class. SP-3 is later used in the Result message and the class. SP-3 is later used in the Result message and the
administrator is identified as 'Admin-contact@10.1.1.2' as they administrator is identified as 'Admin-contact@10.1.1.2' as they
searched for 192.0.2.35, the administrator may be different than the searched for 192.0.2.35; the administrator may be different than the
constituency contact (an additional Request with MsgDst set to constituency contact (an additional Request with MsgDestination set
'TraceRequest' occurred between SP-2 to SP-3 that is not included). to 'TraceRequest' occurred between SP-2 to SP-3 that is not
SP-3 is the service provider for 192.0.2.32/27 and was able to take included). SP-3 is the service provider for 192.0.2.32/27 and was
the action to rate-limit their traffic. The SP-1, SP-2, and SP-3 able to take the action to rate-limit their traffic. The SP-1, SP-2,
information would be replaced with the appropriate (and valid) email and SP-3 information would be replaced with the appropriate (and
and other contact information in real usages. The Node class enables valid) email and other contact information in real usages. The Node
multiple methods to identify a system, such as a fully qualified class enables multiple methods to identify a system, such as a fully
domain or the IP address to be provided for the SP. Any mapping of qualified domain name or the IP address to be provided for the SP.
existing relationships from the SP Node information to the name, Any mapping of existing relationships from the SP Node information to
contact, digital signature verification information and other the name, contact, digital signature verification information and
identifying or trust information is provided at the application layer other identifying or trust information is provided at the application
to support end users of the incident management system. A packet is layer to support end users of the incident management system. A
provided in this example to enable any traces to be performed by SP-2 packet is provided in this example to enable any traces to be
and SP-3 to perform traces to the attack source before taking the performed by SP-2 and SP-3 to perform traces to the attack source
requested action to 'rate-limit' the traffic. The subnet of before taking the requested action to 'rate-limit' the traffic. The
192.0.2.0uses a 27 bit mask in the examples below. subnet of 192.0.2.0 uses 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. Reference [RFC4051] [XMLsig] supports additional digest algorithms. Reference [RFC4051]
for URIs intended for use with XML digital signatures, encryption, for URIs intended for use with XML digital signatures, encryption,
and canonicalization. SHA-1 SHOULD NOT be used, see [RFC6194] for and canonicalization. SHA-1 SHOULD NOT be used; see [RFC6194] for
further details. further details.
Note: Due to the limit of 72 characters per line, some line breaks
were added in the examples and schemas in this document.
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<iodef-rid:RID lang="en-US" <iodef-rid:RID lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0" 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:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0"> xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0">
<iodef-rid:RIDPolicy MsgDestination="RIDSystem" MsgType="TraceRequest"> <iodef-rid:RIDPolicy MsgDestination="RIDSystem" MsgType="TraceRequest">
<iodef-rid:PolicyRegion region="IntraConsortium"/> <iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address> <iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
skipping to change at page 45, line 19 skipping to change at page 44, line 31
<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 purpose="traceback" restriction="need-to-know"> <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 completion="failed" severity="low" 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>
skipping to change at page 46, line 23 skipping to change at page 45, line 37
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:Signature dtype="xml" meaning="xml"> <iodef-rid:Signature dtype="xml" meaning="xml">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" Id="dsig-123456"> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
Id="dsig-123456">
<SignedInfo> <SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <CanonicalizationMethod
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI=""> <Reference URI="">
<Transforms> <Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"> <Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
<XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2" <XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:dsig-trans="http://www.w3.org/2002/06/xmldsig-filter2" xmlns:dsig-trans="http://www.w3.org/2002/06/xmldsig-filter2"
Filter="intersect"> Filter="intersect">
//dsig:Signature[@Id = 'dsig-123456']/ancestor::iodef-rid:ReportSchema/ //dsig:Signature[@Id = 'dsig-123456']/
ancestor::iodef-rid:ReportSchema/
iodef-rid:XMLDocument/IODEF-Document[1]/iodef:Incident[1]/ iodef-rid:XMLDocument/IODEF-Document[1]/iodef:Incident[1]/
iodef:EventData[1]/iodef:Record[1]/iodef:RecordData[1]/ iodef:EventData[1]/iodef:Record[1]/iodef:RecordData[1]/
iodef:RecordItem[1]</XPath></Transform></Transforms> iodef:RecordItem[1]</XPath></Transform></Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>NQuIhPjdZuZJnPi/hW62dwJT1dR+vqcZV8mpemCVN5g=</DigestValue> <DigestValue>
NQuIhPjdZuZJnPi/hW62dwJT1dR+vqcZV8mpemCVN5g=
</DigestValue>
</Reference></SignedInfo> </Reference></SignedInfo>
<SignatureValue> <SignatureValue>
lnq/ePQ4AVpxCR0ifCp9sMsW0r/AdT3C2GR/zaN1V+hZ/NApOygUjMzTCQnx+RvGPNkO/RVqBEID lnq/ePQ4AVpxCR0ifCp9sMsW0r/AdT3C2GR/zaN1V+hZ/NApOygUjMzTCQnx+RvGPNkO/RVq
gZQUEnQZn/uSbmr0tQ6xpBfaxF1DCosLgiZy+2jFzpXrwoN/jHNgtxR/9QLW9mZ+I7V6LEEJ73Ku BEIDgZQUEnQZn/uSbmr0tQ6xpBfaxF1DCosLgiZy+2jFzpXrwoN/jHNgtxR/9QLW9mZ+I7V6
t+d0naTGHlyi64ab2PqsVuRXQ4pXUKbhMkhzeTIqvFLK93KGfsIMd6Cb+n2u/AByLkc+gflJYUWV LEEJ73Kut+d0naTGHlyi64ab2PqsVuRXQ4pXUKbhMkhzeTIqvFLK93KGfsIMd6Cb+n2u/ABy
P4DxkQ4cyex6hM6RYTRUSr7jVD9K4d8KFP2g85i69YLtSu01W1Np0afpJ4a9MK0E7ISMNRmC8wIk Lkc+gflJYUWVP4DxkQ4cyex6hM6RYTRUSr7jVD9K4d8KFP2g85i69YLtSu01W1Np0afpJ4a9
lCAsSXiBRqyaEwaSy/clybI0vCTPqGOYh3/SZg==</SignatureValue> MK0E7ISMNRmC8wIklCAsSXiBRqyaEwaSy/clybI0vCTPqGOYh3/SZg==
</SignatureValue>
<KeyInfo> <KeyInfo>
<KeyValue> <KeyValue>
<RSAKeyValue> <RSAKeyValue>
<Modulus> <Modulus>
z8adrX9m0S8OxIxN+fui33wiz4ZYgb4xPbR9MS5pOp1A8kVpH5Ew3N6O3/dMs2a4diIxyGLVh0r8 z8adrX9m0S8OxIxN+fui33wiz4ZYgb4xPbR9MS5pOp1A8kVpH5Ew3N6O3/dMs2a4diIxyGLV
6QXWH/W6T2IC2ny+hi+jWRwXrvgTY3ZAFgePvz2OdRhVN/cUbOto4Pa4I2mVZWW+/Q0Fn7YpqPBD h0r86QXWH/W6T2IC2ny+hi+jWRwXrvgTY3ZAFgePvz2OdRhVN/cUbOto4Pa4I2mVZWW+/Q0F
DxlGq/xyFPuYq/4y7Y+Ah+vHO2ZSaiQjbj8F38XrGhwlcbFVyK8AmxK3z0zWwX86uMEqVCjW6s6j n7YpqPBDDxlGq/xyFPuYq/4y7Y+Ah+vHO2ZSaiQjbj8F38XrGhwlcbFVyK8AmxK3z0zWwX86
2KAWdbAjEpgZHlJY87i/DqnFgxfmdg3oru+YeiEPVRY8hyQpYbtgryveZOHTgnCHmS/53U9jSS0c uMEqVCjW6s6j2KAWdbAjEpgZHlJY87i/DqnFgxfmdg3oru+YeiEPVRY8hyQpYbtgryveZOHT
yb/ADuj1upfyNoOiMMgQr7Olhc5pTvuWAl4Fnw==</Modulus> gnCHmS/53U9jSS0cyb/ADuj1upfyNoOiMMgQr7Olhc5pTvuWAl4Fnw==</Modulus>
<Exponent>AQAB</Exponent> <Exponent>AQAB</Exponent>
</RSAKeyValue> </RSAKeyValue>
</KeyValue> </KeyValue>
</KeyInfo> </KeyInfo>
</Signature> </Signature>
</iodef-rid:Signature> </iodef-rid:Signature>
<!-- End of detached XML signature included in RID --> <!-- End of detached XML signature included in RID -->
</iodef-rid:ReportSchema> </iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy> </iodef-rid:RIDPolicy>
</iodef-rid:RID> </iodef-rid:RID>
skipping to change at page 48, line 30 skipping to change at page 47, line 40
</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 Request listed The example Result message is in response to the Request listed
above. This message type only comes after an Acknowledgement within above. This message type only comes after an Acknowledgement within
the Request flow of messages where a TraceRequest is in progress. It the Request flow of messages where a TraceRequest is in progress. It
may be a direct response to a Request with the MsgType set to may be a direct response to a Request with the MsgType set to
'InvestigationRequest'. This message provides information about the 'InvestigationRequest'. This message provides information about the
source of the attack and the actions taken to 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, The Result message is typically the last message in a Request flow;
however an Acknowledgement MAY follow if there are any issues however, an Acknowledgement MAY follow if there are any issues
receiving or processing the Result. receiving or processing the Result.
<iodef-rid:RID lang="en" <iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0" 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>
skipping to change at page 49, line 11 skipping to change at page 48, line 23
<iodef: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"/>
</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:Contact role="admin" type="organization"> <iodef:Contact role="admin" type="organization">
<iodef:ContactName>Admin-contact for 192.0.2.35 <iodef:ContactName>Admin-contact for 192.0.2.35
</iodef:ContactName> </iodef:ContactName>
skipping to change at page 51, line 30 skipping to change at page 50, line 42
<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 a RID Request communication flow between The diagram below outlines a RID Request communication flow between
RID systems on different networks for a security incident with a RID systems on different networks for a security incident with a
known source address. Therefore, MsgDst is set to known source address. Therefore, MsgDestination is set to
'InvestigationRequest' for the Request message and is included in the 'InvestigationRequest' for the Request message and is included in the
diagram below as an Investigation. The proper response to a Request diagram below as "Investigation". The proper response to a Request
with the MsgDst set to 'InvestigationRequest' is a Result message. with the MsgDestination set to 'InvestigationRequest' is a Result
If there is a problem with the Request, such as a failure to validate message. If there is a problem with the Request, such as a failure
the digital signature or decrypt the Request, an Acknowledgement to validate the digital signature or decrypt the Request, an
message is sent to the requestor. The Acknowledgement message should Acknowledgement message is sent to the requestor. The
provide the reason why the message could not be processed. Acknowledgement message should 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 Request 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, with the IODEF and security measures are similar to the TraceRequest, with the
exception that the source is known, the receiving RID system is known exception that the source is known, the receiving RID system is known
to be close to the source, and the MsgDst is set to to be close to the source, and the MsgDestination is set to
'InvestigationRequest'. The source known is indicated in the IODEF 'InvestigationRequest'. The source known is indicated in the IODEF
document, which allows for incident sources to be listed as spoofed, document, which allows for incident sources to be listed as spoofed,
if appropriate. if appropriate.
This flow does not include a Result message as the request is denied This flow does not include a Result message because the request is
as shown in the Acknowledgement response. denied 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 lang="en" <iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0" 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="InvestigationRequest" <iodef-rid:RIDPolicy MsgType="InvestigationRequest"
MsgDestination="SourceOfIncident"> MsgDestination="SourceOfIncident">
<iodef-rid:PolicyRegion region="PeerToPeer"/> <iodef-rid:PolicyRegion region="PeerToPeer"/>
skipping to change at page 55, line 39 skipping to change at page 54, line 39
failure to validate the digital signature [RFC3275] or decrypt the failure to validate the digital signature [RFC3275] or decrypt the
request, an Acknowledgement message is sent to the requestor. The request, an Acknowledgement message is sent to the requestor. The
Acknowledgement message should provide the reason why the message Acknowledgement message should provide the reason why the message
could not be processed. 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 Request The IODEF document and digital signature is similar to the Request
example with MsgDst set to 'TraceRequest'. example with MsgDestination 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 lang="en" <iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0" 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"/>
skipping to change at page 59, line 15 skipping to change at page 58, line 15
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-2.0" <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-2.0" 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" <xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation="http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd"/> schemaLocation="http://www.iana.org/assignments/xml-registry/schema/
iodef-1.0.xsd"/>
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#" <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/> 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, January 2012 *** *** Namespace - iodef-rid, April 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 act 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 ======
--> -->
<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"/>
skipping to change at page 62, line 50 skipping to change at page 62, line 4
<xs:attribute name="ext-type" <xs:attribute name="ext-type"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
</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-rid:URL" minOccurs="0"
maxOccurs="1"/> maxOccurs="1"/>
<xs:element ref="iodef-rid:Signature" 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>
<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:anyURI"> <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="URL" <xs:element name="URL"
skipping to change at page 63, line 44 skipping to change at page 62, line 47
<xs:element name="Signature" <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 includes 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, authorized, that to ensure that messages are secure, authenticated, and authorized;
the messages meet policy and privacy guidelines, and maintain meet policy and privacy guidelines; and maintain integrity. XML
integrity. XML Signature Best Practices [XMLSigBP] should be Signature Best Practices [XMLSigBP] should be referenced by
referenced by implementers for information on improving security to implementers for information on improving security to mitigate
mitigate attacks. 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 a Request MUST use a detached signature to sign o The originator of a Request MUST use a detached signature to sign
at least one of the original elements contained in the RecordItem at least one of the original elements contained in the RecordItem
class to provide authentication to all upstream participants in class to provide authentication to all upstream participants in
skipping to change at page 64, line 26 skipping to change at page 63, line 28
of RecordItem provided by the originator may be individually of RecordItem provided by the originator may be individually
signed, and additional RecordItem entries by upstream peers in the signed, and additional RecordItem entries by upstream peers in the
trace or investigation may be signed by the peer adding the data, trace or investigation may be signed by the peer adding the data,
while maintaining the original RecordItem entry(s) and detached while 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 [XMLCanon] is REQUIRED for the detached signature canonicalization [XMLCanon] is REQUIRED for the detached signature
and not the references as the XML document generated is then and not the references, as the XML document generated is then
included in the RID message within the Signature element of the included in the RID message within the Signature element of the
ReportSchema class. This signature MUST be passed to all ReportSchema class. This signature MUST be passed to all
recipients of the Request message. recipients of the Request message.
o If a Request does not include a RecordItem entry, a timestamp MUST o If a Request does not include a RecordItem entry, a timestamp MUST
be used to ensure there is data to be signed for the multi-hop be used to ensure there is data to be signed for the multi-hop
authentication use case. The DateTime element of the IODEF: authentication use case. The DateTime element of the iodef:
RecordItem class, [RFC5070] Section3.19.1, is used for this RecordData class ([RFC5070], Section 3.19.1) is 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. The authentication and integrity to the receiving RID system. The
signature is placed in an instance of the Signature element. signature is placed in an instance of the Signature element.
o XML Signature Best Practices [XMLSigBP] guidance SHOULD be o XML Signature Best Practices [XMLSigBP] guidance SHOULD be
followed to prevent or mitigate security risks. Examples include followed to prevent or mitigate security risks. Examples include
the recommendation to authenticate a signature prior to processing the recommendation to authenticate a signature prior to processing
(executing potentially dangerous operations) and limiting the use (executing potentially dangerous operations) and the
of URIs since they may enable cross-site scripting attacks or recommendation to limit the use of URIs since they may enable
access to local information. cross-site scripting attacks or access to local information.
o XML Path Language (XPath) 2.0 [XMLPath] MUST be followed to o XML Path Language (XPath) 2.0 [XMLPath] MUST be followed to
specify the portion of the XML document to be signed. XPath is specify the portion of the XML document to be signed. XPath is
used to specify a location within an XML document. Best practice used to specify a location within an XML document. Best practice
recommendations for using XPath [XMLSigBP] SHOULD be referenced to recommendations for using XPath [XMLSigBP] SHOULD be referenced to
reduce the risk of denial of service attacks. The use of XSLT reduce the risk of denial-of-service attacks. The use of XSLT
transforms MUST be restricted according to security guidance in transforms MUST be restricted according to security guidance in
[XMLSigBP]. [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 not only the message is
encrypted for transport. This behavior would be agreed upon encrypted for transport. This behavior would be agreed upon
between peers or a consortium, or determined on a per-message between peers or a consortium, or determined on a per-message
basis, depending on security requirements. It should be noted basis, depending on security requirements. It should be noted
that there are cases for transport where the RIDPolicy class needs that there are cases for transport where the RIDPolicy class needs
to be presented in clear text, as detailed in the transport to be presented in clear text, as detailed in the transport
document [RFC6046-bis]. document [RFC6546].
o A Request, or any other message type that may be relayed through o A Request, or any other message type that may be relayed through
RID systems before reaching the intended destination as a result RID systems before reaching the intended destination as a result
of trust relationships, MAY be encrypted specifically for the of trust relationships, MAY be encrypted specifically for the
intended recipient. This may be necessary if the RID network is intended recipient. This may be necessary if the RID network is
being used for message transfer, the intermediate parties do not being used for message transfer, the intermediate parties do not
need to have knowledge of the request contents, and a direct need to have knowledge of the request contents, and a direct
communication path does not exist. In that case, the RIDPolicy communication path does not exist. In that case, the RIDPolicy
class is used by intermediate parties and as such, RIDPolicy is class is used by intermediate parties and as such, RIDPolicy is
maintained in clear text. 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
intermediate parties used in the path of the incident intermediate parties used in the path of the incident
investigation that the incident handling has been completed. investigation that the incident handling has been completed.
o The iodef:restriction attribute sets expectations for the privacy o The iodef:restriction attribute sets expectations for the privacy
of an incident and is defined in section 3.2 of RFC5070. of an incident and is defined in Section 3.2 of RFC 5070.
Following the guidance for XML encryption in the Security Following the guidance for XML encryption in the Security
Requirements Section, the iodef:restriction attribute can be set Requirements section, the iodef:restriction attribute can be set
in any of the RID classes to define restrictions and encryption in any of the RID classes to define restrictions and encryption
requirements for the exchange of incident information. The requirements for the exchange of incident information. The
restriction options enable encryption capabilities for the restriction options enable encryption capabilities for the
complete exchange of an IODEF document (including any extensions), complete exchange of an IODEF document (including any extensions),
within specific classes of IODEF, or IODEF extensions where more within specific classes of IODEF, or IODEF extensions, where more
limited restrictions are desired. The restriction attribute is limited restrictions are desired. The restriction attribute is
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 how restriction is set:
* 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. See Section 9.3 for a discussion public key of the recipient. See Section 9.3 for a discussion
on public key infrastructure (PKI) and other security on public key infrastructure (PKI) and other security
requirements. requirements.
* 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 be encrypted
key may be used. The method used SHOULD adhere to any with a single group key. 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
given access to the shared key via a secure distribution given access to the shared key via a secure distribution
method, for example, providing access to the symmetric key method, for example, providing access to the symmetric key
encrypted with each of users public keys. encrypted with each of the user's public keys.
* If restriction is set to "public", the class or document MUST * If restriction is set to 'public', the class or document MUST
be sent in clear text. This setting can be critical if certain be sent in clear text. This setting can be critical if certain
sections of a document or an entire document are to be shared sections of a document or an entire document are to be shared
without restrictions. This provides flexibility within an without restrictions. This provides flexibility within an
incident to share out certain information freely where incident to share certain information freely where appropriate.
appropriate.
* If restriction is set to "default", The information can be * If restriction is set to 'default', the information can be
shared according to an information disclosure policy pre- shared according to an information disclosure policy pre-
arranged by the communicating parties. arranged by the communicating parties.
o Expectations based on placement of the restriction setting: o Expectations based on placement of the restriction setting:
* If restriction is set within one of the RID classes, the * If restriction is set within one of the RID classes, the
restriction applies to the entire IODEF document. restriction applies to the entire IODEF document.
* If restriction is set within individual IODEF classes, the * If restriction is set within individual IODEF classes, the
restriction applies to the specific IODEF class and the restriction applies to the specific IODEF class and the
children of that class. children of that class.
The formation of policies is a very important aspect of using a The formation of policies is a very important aspect of using a
messaging system like RID to exchange potentially sensitive messaging system like RID to exchange potentially sensitive
information. Many considerations should be involved for peering information. Many considerations should be involved for peering
parties, and some guidelines to protect the data, systems, and parties, and some guidelines to protect the data, systems, and
transport are covered in this section. Policies established should transport are covered in this section. Policies established should
provide guidelines for communication methods, security, and fall-back provide guidelines for communication methods, security, and fall-back
procedures. See sections 9.4 and 9.5 for additional information on procedures. See Sections 9.4 and 9.5 for additional information on
consortiums and PKI considerations. consortiums and PKI considerations.
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. RIDPolicy 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 requests and
Report messages between entities. 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 RID is used to transfer or exchange XML documents in an IODEF format
or using another IANA registered format. Implementations SHOULD NOT or using another IANA-registered format. Implementations SHOULD NOT
download schemas at runtime due to the security implications, and download schemas at runtime due to the security implications, and
included documents MUST NOT be required to provide a resolvable included documents MUST NOT be required to provide a resolvable
location of their schema. location of their schema.
9.2. Message Transport 9.2. Message Transport
A transport specification is defined in a separate document [RFC6046- A transport specification is defined in a separate document
bis]. The specified transport protocols MUST use encryption to [RFC6546]. The specified transport protocols MUST use encryption to
provide an additional level of security and integrity, while provide an additional level of security and integrity, while
supporting mutual authentication through bi-directional certificate supporting mutual authentication through bidirectional 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
considerations are addressed fully in RID to protect sensitive considerations are addressed fully in RID to protect sensitive
portions of documents and provide a method to authenticate the portions of documents and to provide a method to authenticate the
messages. Therefore, RID messages do not rely on the security messages. Therefore, RID messages do not rely on the security
provided by the transport layer alone. The encryption requirements provided by the transport layer alone. The encryption requirements
and considerations for RID messages are discussed in Section 9.1 of and considerations for RID messages are discussed in Section 9.1 of
this document. this document.
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 [RFC6546] and optionally MAY support other protocols such as the
Blocks Extensible Exchange Protocol (BEEP) [RFC3080]. Bindings would Blocks Extensible Exchange Protocol (BEEP) [RFC3080]. Bindings would
need to be defined to enable support for other transport protocols. need to be defined to enable support for other transport protocols.
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 listen for and send RID messages on
on the designated port, which also MUST be over an encrypted tunnel only 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
signatures, and hash functions MUST meet minimum security levels of signatures, and hash functions MUST meet minimum security levels of
the times. The encryption strength MUST adhere to import and export the times. The encryption strength MUST adhere to import and export
regulations of the involved countries for data exchange. regulations of the involved countries for data exchange.
Out-of-band communications dedicated to SP interaction for RID Out-of-band communications dedicated to SP interaction for RID
messaging would provide additional security as well as guaranteed messaging would provide additional security as well as guaranteed
bandwidth during a denial-of-service attack. For example, an out-of- bandwidth during a denial-of-service attack. For example, an out-of-
skipping to change at page 68, line 43 skipping to change at page 67, line 43
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 It is RECOMMENDED that RID, the XML security functions, and transport
protocols properly integrate with a PKI managed by the consortium, protocols properly integrate with a PKI managed by the consortium,
federate PKIs within a consortium, or use a PKI managed by a trusted federate PKIs within a consortium, or use a PKI managed by a trusted
third party. Entities MAY use shared keys as an alternate solution, third party. Entities MAY use shared keys as an alternate solution,
although this may limit the ability to validate certificates and although this may limit the ability to validate certificates and
could introduce risk. For the Internet, a few of examples of could introduce risk. For the Internet, a few examples of existing
existing efforts that could be leveraged to provide the supporting efforts that could be leveraged to provide the supporting PKI include
PKI include the Regional Internet Registry's (RIR's) PKI hierarchy, the Regional Internet Registry's (RIR's) PKI hierarchy, vendor issued
vendor issued certificates, or approved issuers of Extended certificates, or approved issuers of Extended Validation (EV)
Validation (EV) Certificates. Security and privacy considerations Certificates. Security and privacy considerations related to
related to consortiums are discussed in Sections 9.4 and 9.5. consortiums are discussed in Sections 9.4 and 9.5.
The use of PKI between entities or by a consortium SHOULD adhere to The use of PKI between entities or by a consortium SHOULD adhere to
any applicable certificate policy and practices agreements for the any applicable certificate policy and practices agreements for the
use of RID. [RFC3647] specifies a commonly used format for use of RID. [RFC3647] specifies a commonly used format for
certificate policy (CP) and certification practices statements (CPS). 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
directly or through a consortium with agreed-upon appropriate use directly or through a consortium with agreed-upon appropriate use
agreements. The agreements to trust other entities may be based on agreements. The agreements to trust other entities may be based on
assurance levels that could be determined by a comparison of the CP, assurance levels that could be determined by a comparison of the CP,
CPS, and/or RID operating procedures. The initial comparison of CPS, and/or RID operating procedures. The initial comparison of
policies and ability to audit controls provides a baseline assurance policies and the ability to audit controls provide a baseline
level for entities to form and maintain trust relationships. Trust assurance level for entities to form and maintain trust
relationships may also be defined through a bridged or hierarchical relationships. Trust relationships may also be defined through a
PKI in which both peers belong. If shared keys or keys issued from a bridged or hierarchical PKI in which both peers belong. If shared
common CA are used, the verification of controls to determine the keys or keys issued from a common CA are used, the verification of
assurance level to trust other entities may be limited to the RID controls to determine the assurance level to trust other entities may
policies and operating procedures. 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 service 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 [RFC6546].
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
specifications and path validation standards set forth in [RFC5280] specifications and path validation standards set forth in [RFC5280]
MUST be followed in order to interoperate with a PKI designed for MUST be followed in order to interoperate with a PKI designed for
similar purposes. Full path validation verifies the chaining similar purposes. Full path validation verifies the chaining
relationship to a trusted root and also performs a certificate relationship to a trusted root and also performs a certificate
revocation check. The use of digital signatures in RID XML messages revocation check. The use of digital signatures in RID XML messages
MUST follow the World Wide Web Consortium (W3C) recommendations for MUST follow the World Wide Web Consortium (W3C) recommendations for
signature syntax and processing when either the XML encryption signature syntax and processing when either the XML encryption
[XMLencrypt] or digital signature [XMLsig], [RFC3275] is used within [XMLencrypt] or digital signature [XMLsig] [RFC3275] is used within a
a document. document.
It might be helpful to define an extension to the authentication It might be helpful to define an extension to the authentication
scheme that uses attribute certificates [RFC5755] in such a way that scheme that uses attribute certificates [RFC5755] in such a way that
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 [RFC6546].
9.3.2. Multi-Hop Request Authentication 9.3.2. Multi-Hop Request Authentication
The use of multi-hop authentication in a Request is used when a The use of multi-hop authentication in a Request is used when a
Request is sent to multiple entities or SPs in an iterative manner. Request is sent to multiple entities or SPs in an iterative manner.
Multi-hop authentication is REQUIRED in Requests that involve Multi-hop authentication is REQUIRED in Requests that involve
multiple SPs where Requests are forwarded iteratively through peers. multiple SPs where Requests are forwarded iteratively through peers.
Bilateral trust relationships MAY be used between peers, then Multi- Bilateral trust relationships MAY be used between peers; multi-hop
hop authentication MUST be used for cases where the originator of a 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, SPs may want to prioritize incident handling For practical reasons, SPs may want to prioritize incident-handling
events based upon the immediate peer for a Request, the originator of events based upon the immediate peer for a Request, the originator of
a request, and the listed Confidence rating for the incident. In a request, and the listed Confidence rating for the incident. In
order to provide a higher assurance level of the authenticity of a order to provide a higher assurance level of the authenticity of a
Request, the originating RID system is included in the Request along Request, the originating RID system is included in the Request along
with contact information and the information of all RID systems in with contact information and the information of all RID systems in
the path the trace has taken. This information is provided through the path the trace has taken. This information is provided through
the IODEF EventData class nesting the list of systems and contacts the IODEF EventData class, which nests the list of systems and
involved in a trace, while setting the category attribute to contacts involved in a trace, while setting the 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 Request sent to all systems in the include a digital signature in the Request sent to all systems 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 Request, 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
skipping to change at page 72, line 4 skipping to change at page 71, line 9
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;
o Network and application layer protection for RID systems and
o Network- and application-layer protection for RID systems and
communications; communications;
o Proper use guidelines for RID systems, messages, and requests; and o Proper use guidelines for RID systems, messages, and requests; and
o A PKI, certificate policy, and certification practices statement o A PKI, certificate policy, and certification practices statement
to provide authentication, integrity, and privacy. to provide authentication, integrity, and privacy.
The functions described for a consortium's role parallel that of a The functions described for a consortium's role parallel those of a
PKI federation. The PKI federations that currently exist are PKI federation. The PKI federations that currently exist are
responsible for establishing security guidelines and PKI trust responsible for establishing security guidelines and PKI trust
models. The trust models are used to support applications to share models. The trust models are used to support applications to share
information using trusted methods and protocols. information using trusted methods and protocols.
A PKI can also provide the same level of security for communication A PKI can also provide the same level of security for communication
between an end entity (enterprise, educational, or government between an end entity (enterprise, educational, or government
customer network) and the SP. customer network) and the SP.
9.5. Privacy Concerns and System Use Guidelines 9.5. Privacy Concerns and System Use Guidelines
skipping to change at page 72, line 44 skipping to change at page 71, line 50
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 o Privacy of incident information stored on incident management
systems participating in RID communications. 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 enterprise, educational, government,
government, or other attached networks to an SP participating in or other networks attached to an SP participating in RID.
RID. Customers should review data handling policies to understand Customers should review data handling policies to understand how
how data will be protected by a service provider. This data will be protected by a service provider. This information
information will enable customers to decide what types of data at will enable customers to decide what types of data at what
what sensitivity level can be shared with service providers. This sensitivity level can be shared with service providers. This
information could be used at the application layer to establish information could be used at the application layer to establish
sharing profiles for entities and groups, see Section 9.6. sharing profiles for entities and groups; see Section 9.6.
o Customers should request information on the security and privacy o Customers should request information on 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. Customers should understand if their data the SP is a member. Customers should understand if their data
were to be forwarded, how might it be sanitized and how will it be were to be forwarded, how it might be sanitized and how it will be
protected. Customers should also understand if limitations can be protected. In advance of sharing data with their SP, customers
placed on how any data they share with their SP will be used in should also understand if limitations can be placed on how it will
advance of sharing that data. be used.
o Customers should be aware that their data can and will be sent to o Customers should be aware 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. Customers considering privacy options may limit customer and SP. Customers considering privacy options may limit
the use of this feature if they do not want the data forwarded. the use of this feature if they do not want the data forwarded.
Parties Involved in the Attack: Parties Involved in the Attack:
o Privacy of the identity of a host involved in an attack or any o Privacy of the identity of a host involved in an attack or any
indicators of compromise. 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 Request request should be considered. the path of an Request request should be considered.
Consortium Considerations: Consortium Considerations:
o System use restrictions for security incident handling within the o System use restrictions for security incident handling within the
local region's definitions of appropriate traffic. When local region's definitions of appropriate traffic. When
participating in a consortium, appropriate use guidelines should participating in a consortium, appropriate use guidelines should
skipping to change at page 74, line 8 skipping to change at page 73, line 12
government communication regulations that apply between those two government communication regulations that apply between those two
regions, such as encryption export and import restrictions. regions, such as encryption export and import restrictions.
o System use between consortiums SHOULD NOT request traffic traces o System use between consortiums SHOULD NOT request traffic traces
and actions beyond the scope intended and permitted by law or and actions beyond the scope intended and permitted by law or
inter-consortium agreements. inter-consortium agreements.
o System use between consortiums should consider national boundary o System use between consortiums should consider national boundary
issues and request limits in their appropriate system use issues and request limits in their appropriate system use
agreements. Appropriate use should include restrictions to agreements. Appropriate use should include restrictions to
prevent the use of the protocol to limit or restrict traffic that prevent the use of the protocol for limiting or restricting
is otherwise permitted within the country in which the peering traffic that is otherwise permitted within the country in which
consortium resides. the peering consortium resides.
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 and policies may be facilitated through use of the RIDPolicy class and
application layer options. Some privacy considerations are addressed application-layer options. Some privacy considerations are addressed
through the RID guidelines for encryption and digital signatures as through the RID guidelines for encryption and digital signatures as
described in Section 9.1. 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 SP investigation may determine the identity of the source host or the SP
used by the source of the traffic. It should be noted that the trace used by the source of the traffic. It should be noted that the trace
mechanism used across a single-SP may also raise privacy concerns for mechanism used across a single SP may also raise privacy concerns for
the clients of the network. Methods that may raise concern include the clients of the network. Methods that may raise concern include
those that involve storing packets for some length of time in order those that involve storing packets for some length of time in order
to trace packets after the fact. Monitoring networks for intrusions to trace packets after the fact. Monitoring networks for intrusions
and for tracing capabilities also raises concerns for potentially and for tracing capabilities also raises concerns for potentially
sensitive valid traffic that may be traversing the monitored network. sensitive valid traffic that may be traversing the monitored network.
IDSs and single-network tracing are outside of the scope of this IDSs and single-network tracing are outside of the scope of this
document, but the concern should be noted and addressed within the document, but the concern should be noted and addressed within the
use guidelines of the network. Some IDSs and single-network trace use guidelines of the network. Some IDSs and single-network trace
mechanisms attempt to properly address these issues. RID is designed mechanisms attempt to properly address these issues. RID is designed
to provide the information needed by any single-network trace to provide the information needed by any single-network trace
skipping to change at page 75, line 47 skipping to change at page 75, line 6
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 SP. In that situation, options must support sending through a single SP. In that situation, options must support sending
Result messages from a downstream peer of that SP. That option Result messages from a downstream peer of that SP. That option
provides an additional level of abstraction to hide the identity and provides an additional level of abstraction to hide the identity and
the SP of the identified source of the traffic. Legal action may the SP of the identified source of the traffic. Legal action may
override this technical decision after the trace has taken place, but override this technical decision after the trace has taken place, but
that is out of the technical scope of this document. that is out of the technical scope of this document.
Privacy concerns when using an Request message to request action Privacy concerns when using an Request message to request action
close to the source of valid attack traffic needs to be considered. close to the source of valid attack traffic need to be considered.
Although the intermediate SPs may relay the request if there is no Although the intermediate SPs may relay the request if there is no
direct trust relationship to the closest SP to the source, the direct trust relationship to the closest SP to the source, the
intermediate SPs do not require the ability to see the contents of intermediate SPs do not require the ability to see the contents of
the packet or the text description field(s) in the request. This the packet or the text description field(s) in the request. This
message type does not require any action by the intermediate RID message type does not require any action by the intermediate RID
systems, except to relay the packet to the next SP in the path. systems, except to relay the packet to the next SP in the path.
Therefore, the contents of the request may be encrypted for the Therefore, the contents of the request may be encrypted for the
destination system. The intermediate SPs only needs to know how to destination system. The intermediate SPs only need to know how to
direct the request to the manager of the ASN in which the source IP direct the request to the manager of the ASN in which the 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. Request messages and requested actions to mitigate or or nations. Request messages and requested actions to mitigate or
stop traffic must adhere to the appropriate use guidelines and yet stop traffic must adhere to the appropriate use guidelines and yet
prevent abuse of the system. First, the peering consortiums must prevent abuse of the system. First, the peering consortiums must
identify the types of traffic that can be traced between the borders identify the types of traffic that can be traced between the borders
of the participating SPs of each consortium. The traffic traced of the participating SPs of each consortium. The traffic traced
should be limited to security-incident-related traffic. Second, the should be limited to security-incident-related traffic. Second, the
traces permitted within one consortium if passed to a peering traces permitted within one consortium, if passed to a peering
consortium may infringe upon the peering consortium's freedom of consortium, may infringe upon the peering consortium's freedom-of-
information laws. An example would be a consortium in one country information laws. An example would be a consortium in one country
permitting a trace of traffic containing objectionable material, permitting a trace of traffic containing objectionable material,
outlawed within that country. The RID trace may be a valid use of outlawed within that country. The RID trace may be a valid use of
the system within the confines of that country's network border; the system within the confines of that country's network border;
however, it may not be permitted to continue across network however, it may not be permitted to continue across network
boundaries where such content is permitted under law. By continuing boundaries where such content is permitted under law. By continuing
the trace in another country's network, the trace and response could the trace in another country's network, the trace and response could
have the effect of improperly restricting access to data. A have the effect of improperly restricting access to data. A
continued trace into a second country may break the laws and continued trace into a second country may break the laws and
regulations of that nation. Any such traces MUST cease at the regulations of that nation. Any such traces MUST cease 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 and the local security they traverse the path of trusted servers and through the local
controls in place for the incident management systems. Each RID security controls in place for the incident management systems. Each
system MUST perform a bi-directional authentication when sending a RID system MUST perform a bidirectional authentication when sending a
RID message and use the public encryption key of the upstream or RID message and use the public encryption key of the upstream or
downstream peer to send a message or document over the network. This downstream peer to send a message or document over the network. This
means that the document is decrypted and re-encrypted at each RID means that the document is decrypted and re-encrypted at each RID
system via TLS over a transport protocol such as [RFC6046-bis]. The system via TLS over a transport protocol such as [RFC6546]. The RID
RID messages may be decrypted at each RID system in order to properly messages may be decrypted at each RID system in order to properly
process the request or relay the information. Today's processing process the request or relay the information. Today's processing
power is more than sufficient to handle the minimal burden of power is more than sufficient to handle the minimal burden of
encrypting and decrypting relatively small typical RID messages. encrypting and decrypting relatively small typical RID messages.
9.6. Sharing Profiles and Policies 9.6. Sharing Profiles and Policies
The application layer can be used to establish workflows and rulesets The application layer can be used to establish workflows and rulesets
specific to sharing profiles for entities or consortiums. The specific to sharing profiles for entities or consortiums. The
profiles can leverage sharing agreements to restrict data types or profiles can leverage sharing agreements to restrict data types or
classifications of data that are shared. The level of information or classifications of data that are shared. The level of information or
classification of data shared with any entity may be based on classification of data shared with any entity may be based on
protection levels offered by the receiving entity and periodic protection levels offered by the receiving entity and periodic
validation of those controls. The profile may also indicate how far validation of those controls. The profile may also indicate how far
information can be shared according to the entity and data type. The information can be shared according to the entity and data type. The
profile can also support if requests to share data from an entity profile may also indicate whether requests to share data from an
must go directly to that entity. entity must go directly to that entity.
In some cases, pre-defined sharing profiles will be possible. These In some cases, pre-defined sharing profiles will be possible. These
include any use case where an agreement is in place in advance of include any use case where an agreement is in place in advance of
sharing. Examples may be between clients and SPs, entities such as sharing. Examples may be between clients and SPs, entities such as
partners, or consortiums. There may be other cases when sharing partners, or consortiums. There may be other cases when sharing
profiles may not be established in advance, such as an organization profiles may not be established in advance, such as an organization
dealing with an incident who requires assistance from an entity that dealing with an incident who requires assistance from an entity that
have not worked with before. An organization may want to establish it has not worked with before. An organization may want to establish
sharing profiles specific to possible user groups to prepare for sharing profiles specific to possible user groups to prepare for
possible incident scenarios. The user groups could include business possible incident scenarios. The user groups could include business
partners, industry peers, service providers, experts not part of a partners, industry peers, service providers, experts not part of a
service provider, law enforcement, or regulatory repotting bodies. service provider, law enforcement, or regulatory reporting bodies.
Workflows to approve transactions may be specific to sharing profiles Workflows to approve transactions may be specific to sharing profiles
and data types. Application developers should include capabilities and data types. Application developers should include capabilities
to enable these decision points for users of the system. to enable these decision points for users of the system.
Any expectations between entities to preserve the weight and Any expectations between entities to preserve the weight and
admissibility of evidence should be handled at the policy and admissibility of evidence should be handled at the policy and
agreement level. A sharing profile may include notes or an indicator agreement level. A sharing profile may include notes or an indicator
for approvers in workflows to reflect if such agreements exist. for approvers in workflows to reflect if such agreements exist.
skipping to change at page 78, line 21 skipping to change at page 77, line 29
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 PKI and the comparison/validation of Trust relationships are based on PKI and the comparison/validation of
security controls for the incident management systems communicating security controls for the incident management systems communicating
via RID. Trust levels can be established in cross-certification via RID. Trust levels can be established in cross-certification
processes where entities compare PKI policies that include the processes where entities compare PKI policies that include the
specific management and handling of an entity's PKI and certificates specific management and handling of an entity's PKI and certificates
issued under that policy. [RFC3647] defines an Internet X.509 Public issued under that policy. [RFC3647] defines an Internet X.509 Public
Key Infrastructure Certificate Policy and Certification Practices 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 consortiums. 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], and
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 both the Security Requirements and Security options discussed in both the Security Requirements and Security
Considerations sections. The formality, requirements, and complexity Considerations sections. The formality, requirements, and complexity
of the agreements for the certificate policy, practices, supporting of the agreements for the certificate policy, practices, supporting
infrastructure, and the use of RID options SHOULD be decided by the infrastructure, and the use of RID options SHOULD be decided by the
entities or consortiums creating those agreements. entities or consortiums creating those agreements.
11. Internationalization Issues 11. Internationalization Issues
The Node class identifies a host or network device. This document The Node class identifies a host or network device. This document
re-uses the definition of Node from the IODEF specification reuses the definition of Node from the IODEF specification [RFC5070],
[RFC5070], Section 3.16. However, that document did not clearly Section 3.16. However, that document did not clearly specify whether
specify whether a NodeName could be an Internationalized Domain Name a NodeName could be an Internationalized Domain Name (IDN). RID
(IDN). RID systems MUST treat the NodeName class as a domain name systems MUST treat the NodeName class as a domain name slot
slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName [RFC5890]. RID systems SHOULD support IDNs in the NodeName class.
class; if they do so, the UTF-8 representation of the domain name If they do so, the UTF-8 representation of the domain name MUST be
MUST be used, i.e., all of the domain name's labels MUST be U-labels used, i.e., all of the domain name's labels MUST be U-labels
expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be
used. An application communicating via RID can convert between used. An application communicating via RID can convert between
A-labels and U-labels by using the Punycode encoding [RFC3492] for A-labels and U-labels by using the Punycode encoding [RFC3492] for
A-labels as described in the protocol specification for A-labels as described in the protocol specification for
Internationalized Domain Names in Applications [RFC5891]. Internationalized Domain Names in Applications [RFC5891].
12. IANA Considerations 12. 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
skipping to change at page 79, line 27 skipping to change at page 78, line 32
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-2.0 URI: urn:ietf:params:xml:schema:iodef-rid-2.0
Registrant Contact: IESG. Registrant Contact: IESG.
XML: See Section 8, "RID Schema Definition", of this document. XML: See Section 8, "RID Schema Definition", of this document.
Request for the specified registry to be created and managed by IANA: The following registry has been created and is now managed by IANA:
Name of the registry:"XML Schemas Exchanged via RID" Name of the registry: "XML Schemas Exchanged via RID"
Namespace details: A registry entry for an XML Schema Transferred Namespace details: A registry entry for an XML Schema Transferred
via RID consists of: via RID consists of:
Schema Name: A short string that represents the schema Schema Name: A short string that represents the schema
referenced. This value is for reference only in the table. referenced. This value is for reference only in the table.
The version of the schema MUST be included in this string to The version of the schema MUST be included in this string to
allow for multiple versions of the same specification to be in allow for multiple versions of the same specification to be in
the registry. the registry.
skipping to change at page 80, line 5 skipping to change at page 79, line 14
Namespace: The namespace of the referenced XML schema. This is Namespace: The namespace of the referenced XML schema. This is
represented in the RID ReportSchema class in the XMLSchemaID represented in the RID ReportSchema class in the XMLSchemaID
attribute as an enumerated value is represented by a URN or attribute as an enumerated value is represented by a URN or
URI. URI.
Specification URI: A URI [RFC3986] from which the registered Specification URI: A URI [RFC3986] from which the registered
specification can be obtained. The specification MUST be specification can be obtained. The specification MUST be
publicly available from this URI. publicly available from this URI.
Reference: The reference to the document that describes the
schema.
Information that must be provided to assign a new value: The above Information that must be provided to assign a new value: The above
list of information. list of information.
Fields to record in the registry: Schema Name/Version/Namespace/ Fields to record in the registry: Schema Name, Version, Namespace,
Specification URI Specification URI, Reference
Initial registry contents: See section 5.5.1. Initial registry contents: See Section 5.6.1.
Allocation Policy: Expert Review [RFC5226] and Specification Allocation Policy: Expert Review [RFC5226] and Specification
Required [RFC5226]. Required [RFC5226].
The Designated Expert is expected to consult with the mile (Managed The Designated Expert is expected to consult with the MILE (Managed
Incident Lightweight Exchange) working group or its successor if any Incident Lightweight Exchange) working group or its successor if any
such WG exists (e.g., via email to the working group's mailing list). such WG exists (e.g., via email to the working group's mailing list).
The Designated Expert is expected to retrieve the XML schema The Designated Expert is expected to retrieve the XML schema
specification from the provided URI in order to check the public specification from the provided URI in order to check the public
availability of the specification and verify the correctness of the availability of the specification and verify the correctness of the
URI. An important responsibility of the Designated Expert is to URI. An important responsibility of the Designated Expert is to
ensure that the XML schema is appropriate for use in RID. ensure that the XML schema is appropriate for use in RID.
Request for the specified registry to be created and managed by IANA: The following registry has been created and is now managed by IANA:
Name of the registry:"RID Enumeration List" Name of the registry: "RID Enumeration List"
The registry is intended to enable enumeration value additions to The registry is intended to enable enumeration value additions to
attributes in the iodef-rid XML schema. attributes in the iodef-rid XML schema.
Fields to record in the registry: Attribute Name/Attribute Value/ Fields to record in the registry: Attribute Name, Attribute Value,
Description Description, Reference
Initial registry content: none. Initial registry content: none.
Allocation Policy: Expert Review [RFC5226] Allocation Policy: Expert Review [RFC5226]
The Designated Expert is expected to consult with the mile (Managed The Designated Expert is expected to consult with the MILE (Managed
Incident Lightweight Exchange) working group or its successor if any Incident Lightweight Exchange) working group or its successor if any
such WG exists (e.g., via email to the working group's mailing list). such WG exists (e.g., via email to the working group's mailing list).
The Designated Expert is expected to review the request and validate The Designated Expert is expected to review the request and validate
the appropriateness of the enumeration for the attribute. If a draft the appropriateness of the enumeration for the attribute. If a
specification is associated with the request, it MUST be reviewed by specification is associated with the request, it MUST be reviewed by
the Designated Expert. the Designated Expert.
13. Summary 13. 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 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. SPs need policies and are essential to thwarting attack attempts. SPs need policies and
automated methods to combat the hacker's efforts. SPs need automated automated methods to combat the hacker's efforts. SPs need automated
monitoring and response capabilities to identify and trace attacks monitoring and response capabilities to identify and trace attacks
quickly without resource-intensive side effects. Integration with a quickly without resource-intensive side effects. Integration with a
centralized communication system to coordinate the detection, centralized communication system to coordinate the detection,
tracing, and identification of attack sources on a single network is tracing, and identification of attack sources on a single network is
essential. RID provides a way to integrate SP resources for each essential. RID provides a way to integrate SP resources for each
aspect of attack detection, tracing, and source identification and aspect of attack detection, tracing, and source identification and
extends the communication capabilities among SPs. The communication extends the communication capabilities among SPs. The communication
is accomplished through the use of flexible IODEF XML-based documents is accomplished through the use of flexible IODEF XML-based documents
passed between IHSs or RID systems. A Request is communicated to an passed between incident-handling systems or RID systems. A Request
upstream SP and may result in an upstream trace or in an action to is communicated to an upstream SP and may result in an upstream trace
stop or mitigate the attack traffic. The messages are communicated or in an action to stop or mitigate the attack traffic. The messages
among peers with security inherent to the RID messaging scheme are communicated among peers with security inherent to the RID
provided through existing standards such as XML encryption and messaging scheme provided through existing standards such as XML
digital signatures. Policy information is carried in the RID message encryption and digital signatures. Policy information is carried in
itself through the use of the RIDPolicy. RID provides the timely the RID message itself through the use of the RIDPolicy. RID
communication among SPs, which is essential for incident handling. provides the timely communication among SPs, which is essential for
incident handling.
14. References 14. References
14.1. Normative References 14.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.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible
Language) XML-Signature Syntax and Processing", RFC 3275, Markup Language) XML-Signature Syntax and Processing",
March 2002. RFC 3275, March 2002.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines
for Internationalized Domain Names in Applications for the Use of Extensible Markup Language (XML)
(IDNA)", RFC 3492, March 2003. within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for [RFC3492] Costello, A., "Punycode: A Bootstring encoding of
the Use of Extensible Markup Language (XML) Unicode for Internationalized Domain Names in
within IETF Protocols", BCP 70, RFC 3470, January 2003. Applications (IDNA)", RFC 3492, March 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81,
January 2004. RFC 3688, January 2004.
[RFC4051] Eastlake, D., "Additional XML Security Uniform Resource [RFC4051] Eastlake, D., "Additional XML Security Uniform Resource
Identifiers (URIs)", RFC 4051, April 2005. 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
for Transport Layer Security (TLS)", RFC 4279, Ciphersuites for Transport Layer Security (TLS)",
December 2005. RFC 4279, December 2005.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The
Object Description Exchange Format", RFC 5070, Incident Object Description Exchange Format", RFC 5070,
December 2007. December 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 5226, an IANA Considerations Section in RFCs", BCP 26,
May 2008. 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
(CRL) Profile", RFC 5280, May 2008. List (CRL) Profile", RFC 5280, May 2008.
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Attribute Certificate Profile for Authorization", Languages", BCP 47, RFC 5646, September 2009.
RFC 5755, January 2010.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet
Languages", BCP 47, RFC 5646, September 2009. Attribute Certificate Profile for Authorization",
RFC 5755, January 2010.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document
RFC 5890, August 2010. Framework", RFC 5890, August 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010. Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC6046-bis] [RFC6546] Trammell, B., "Transport of Real-time Inter-network
Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546,
Defense (RID) Messages", January 2012, <http:// April 2012.
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.,
F. Yergeau, "Extensible Markup Language (XML) 1.0", W3C and F. Yergeau, "Extensible Markup Language (XML) 1.0",
Recommendation XML 1.0, November 2008, W3C Recommendation XML 1.0, November 2008,
<http://www.w3.org/TR/xml/>. <http://www.w3.org/TR/xml/>.
[XMLCanon] [XMLCanon] Boyer, J., "Canonical XML 1.0", W3C Recommendation 1.0,
Boyer, J., "Canonical XML 1.0", W3C Recommendation 1.0, December 2001, <http://www.w3.org/TR/xml-c14n>.
December 2001, <http://www.w3.org/TR/xml-c14n>.
[XMLencrypt] [XMLPath] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M.,
Imaura, T., Dillaway, B., and E. Simon, "XML Encryption Kay, M., Robie, J., and J. Simeon, "XML Schema Part 1:
Syntax and Processing", W3C Recommendation , Structures", W3C Recommendation Second Edition,
December 2002, <http://www.w3.org/TR/xmlenc-core/>. December 2010, <http://www.w3.org/TR/xpath20/>.
[XMLPath] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., [XMLSigBP] Hirsch, F. and P. Datta, "XML-Signature Best
Kay, M., Robie, J., and J. Simeon, "XML Schema Part 1: Practices", W3C Recommendation, August 2011,
Structures", W3C Recommendation Second Edition, <http://www.w3.org/TR/xmldsig-bestpractices/>.
December 2010, <http://www.w3.org/TR/xpath20/>.
[XMLschema] [XMLencrypt] Imaura, T., Dillaway, B., and E. Simon, "XML Encryption
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, Syntax and Processing", W3C Recommendation,
"XML Schema Part 1: Structures", W3C Recommendation Second December 2002, <http://www.w3.org/TR/xmlenc-core/>.
Edition, October 2004,
<http://www.w3.org/TR/xmlschema-1/>.
[XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E. [XMLschema] Thompson, H., Beech, D., Maloney, M., and N.
Simon, "XML-Signature Syntax and Processing", W3C Mendelsohn, "XML Schema Part 1: Structures", W3C
Recommendation Second Edition, June 2008, Recommendation Second Edition, October 2004,
<http://www.w3.org/TR/xmldsig-core/>. <http://www.w3.org/TR/xmlschema-1/>.
[XMLSigBP] [XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E.
Hirsch, F. and P. Datta, "XML-Signature Best Practices", Simon, "XML-Signature Syntax and Processing", W3C
W3C Recommendation , August 2011, Recommendation Second Edition, June 2008,
<http://www.w3.org/TR/xmldsig-bestpractices/>. <http://www.w3.org/TR/xmldsig-core/>.
14.2. Informative References 14.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
BCP 6, RFC 1930, March 1996. (AS)", BCP 6, RFC 1930, March 1996.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol
Wu, "Internet X.509 Public Key Infrastructure Certificate Core", RFC 3080, March 2001.
Policy and Certification Practices Framework", RFC 3647,
November 2003.
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
RFC 3080, March 2001. Wu, "Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices
Framework", RFC 3647, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
Resource Identifier (URI): Generic Syntax", STD 66, "Uniform Resource Identifier (URI): Generic Syntax",
RFC 3986, January 2005. STD 66, RFC 3986, January 2005.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010. BCP 153, RFC 5735, January 2010.
[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,
Considerations for the SHA-0 and SHA-1 Message-Digest "Security Considerations for the SHA-0 and SHA-1
Algorithms", RFC 6194, March 2011. Message-Digest Algorithms", RFC 6194, March 2011.
[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/>.
Acknowledgements Appendix A. 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 improve, simplify, and secure the protocol: Steve Bellovin, David to improve, simplify, and secure the protocol: Steve Bellovin, David
Black, Harold Booth, Paul Cichonski, Robert K. Cunningham, Roman Black, Harold Booth, Paul Cichonski, Robert K. Cunningham, Roman
Danyliw, Yuri Demchenko, Sandra G. Dykes, Stephen Farrell, Katherine Danyliw, Yuri Demchenko, Sandra G. Dykes, Stephen Farrell, Katherine
Goodier, Cynthia D. McLain, Thomas Millar, Jean-Francois Morfin, Goodier, Cynthia D. McLain, Thomas Millar, Jean-Francois Morfin,
Stephen Northcutt, William Streilein, Damir Rajnovic, Tony Rutkowski, Stephen Northcutt, Damir Rajnovic, Tony Rutkowski, Peter Saint-Andre,
Peter Saint-Andre, Jeffrey Schiller, Robert Sparks, Richard Struse, Jeffrey Schiller, Robert Sparks, William Streilein, Richard Struse,
Tony Tauber, Brian Trammell, Sean Turner, Iljitsch van Beijnum, and Tony Tauber, Brian Trammell, Sean Turner, Iljitsch van Beijnum, and
David Waltermire. David Waltermire.
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: EMail: Kathleen.Moriarty@emc.com
Email: Kathleen.Moriarty@emc.com
 End of changes. 312 change blocks. 
738 lines changed or deleted 763 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/