draft-ietf-mile-rfc6045-bis-03.txt   draft-ietf-mile-rfc6045-bis-04.txt 
MILE Working Group K. Moriarty MILE Working Group K. Moriarty
Internet-Draft EMC Internet-Draft EMC
Obsoletes: 6045 (if approved) December 7, 2011 Obsoletes: 6045 (if approved) December 15, 2011
Intended status: Standards Track Intended status: Standards Track
Expires: June 9, 2012 Expires: June 17, 2012
Real-time Inter-network Defense (RID) Real-time Inter-network Defense (RID)
draft-ietf-mile-rfc6045-bis-03.txt draft-ietf-mile-rfc6045-bis-04.txt
Abstract Abstract
Security incidents, such as system compromises, worms, viruses, Security incidents, such as system compromises, worms, viruses,
phishing incidents, and denial of service, typically result in the phishing incidents, and denial of service, typically result in the
loss of service, data, and resources both human and system. Service loss of service, data, and resources both human and system. Service
providers and Computer Security Incident Response Teams need to be providers and Computer Security Incident Response Teams need to be
equipped and ready to assist in communicating and tracing security equipped and ready to assist in communicating and tracing security
incidents with tools and procedures in place before the occurrence of incidents with tools and procedures in place before the occurrence of
an attack. Real-time Inter-network Defense (RID) outlines a an attack. Real-time Inter-network Defense (RID) outlines a
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 9, 2012. This Internet-Draft will expire on June 17, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Normative and Informative . . . . . . . . . . . . . . . . 6 1.1. Normative and Informative . . . . . . . . . . . . . . . . 6
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. Characteristics of Incidents . . . . . . . . . . . . . . . . . 6 2. Characteristics of Incidents . . . . . . . . . . . . . . . . . 7
3. Communication between CSIRTs and Service Providers . . . . . . 8 3. Communication between CSIRTs and Service Providers . . . . . . 8
3.1. Inter-network Provider RID Messaging . . . . . . . . . . . 10 3.1. Inter-network Provider RID Messaging . . . . . . . . . . . 10
3.2. RID Communication Topology . . . . . . . . . . . . . . . . 12 3.2. RID Communication Topology . . . . . . . . . . . . . . . . 12
3.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 13 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. RID Data Types . . . . . . . . . . . . . . . . . . . . . . 14 4.1. RID Data Types . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 13
3.5. RID Message Types . . . . . . . . . . . . . . . . . . . . 14 4.2. RID Message Types . . . . . . . . . . . . . . . . . . . . 14
4. IODEF-RID Schema . . . . . . . . . . . . . . . . . . . . . . . 15 5. IODEF-RID Schema . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. RIDPolicy Class . . . . . . . . . . . . . . . . . . . . . 17 5.1. RIDPolicy Class . . . . . . . . . . . . . . . . . . . . . 17
4.2. RequestStatus . . . . . . . . . . . . . . . . . . . . . . 23 5.2. RequestStatus . . . . . . . . . . . . . . . . . . . . . . 23
4.3. IncidentSource . . . . . . . . . . . . . . . . . . . . . . 25 5.3. IncidentSource . . . . . . . . . . . . . . . . . . . . . . 25
4.4. RID Name Spaces . . . . . . . . . . . . . . . . . . . . . 26 5.4. RID Name Spaces . . . . . . . . . . . . . . . . . . . . . 26
5. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. TraceRequest . . . . . . . . . . . . . . . . . . . . . . . 26 6.1. TraceRequest . . . . . . . . . . . . . . . . . . . . . . . 26
5.2. RequestAuthorization . . . . . . . . . . . . . . . . . . . 28 6.2. RequestAuthorization . . . . . . . . . . . . . . . . . . . 28
5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4. Investigation Request . . . . . . . . . . . . . . . . . . 31 6.4. Investigation Request . . . . . . . . . . . . . . . . . . 31
5.5. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.5. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.6. IncidentQuery . . . . . . . . . . . . . . . . . . . . . . 33 6.6. IncidentQuery . . . . . . . . . . . . . . . . . . . . . . 34
6. RID Communication Exchanges . . . . . . . . . . . . . . . . . 35 7. RID Communication Exchanges . . . . . . . . . . . . . . . . . 35
6.1. Upstream Trace Communication Flow . . . . . . . . . . . . 35 7.1. Upstream Trace Communication Flow . . . . . . . . . . . . 35
6.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 37 7.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 37
6.1.2. RequestAuthorization Message Example . . . . . . . . . 41 7.1.2. RequestAuthorization Message Example . . . . . . . . . 41
6.1.3. Result Message Example . . . . . . . . . . . . . . . . 42 7.1.3. Result Message Example . . . . . . . . . . . . . . . . 42
6.2. Investigation Request Communication Flow . . . . . . . . . 45 7.2. Investigation Request Communication Flow . . . . . . . . . 45
6.2.1. Investigation Request Example . . . . . . . . . . . . 46 7.2.1. Investigation Request Example . . . . . . . . . . . . 46
6.2.2. RequestAuthorization Message Example . . . . . . . . . 48 7.2.2. RequestAuthorization Message Example . . . . . . . . . 48
6.3. Report Communication Flow . . . . . . . . . . . . . . . . 48 7.3. Report Communication Flow . . . . . . . . . . . . . . . . 48
6.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 49 7.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 49
6.4. IncidentQuery Communication Flow . . . . . . . . . . . . . 51 7.4. IncidentQuery Communication Flow . . . . . . . . . . . . . 51
6.4.1. IncidentQuery Example . . . . . . . . . . . . . . . . 51 7.4.1. IncidentQuery Example . . . . . . . . . . . . . . . . 51
7. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 52 8. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 52
8. Security Requirements . . . . . . . . . . . . . . . . . . . . 56 9. Security Requirements . . . . . . . . . . . . . . . . . . . . 56
8.1. XML Digital Signatures and Encryption . . . . . . . . . . 56 9.1. XML Digital Signatures and Encryption . . . . . . . . . . 56
8.2. Message Transport . . . . . . . . . . . . . . . . . . . . 59 9.2. Message Transport . . . . . . . . . . . . . . . . . . . . 59
8.3. Message Delivery Protocol - Integrity and 9.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 61
Authentication . . . . . . . . . . . . . . . . . . . . . . 60 9.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 61
8.4. Transport Communication . . . . . . . . . . . . . . . . . 61 9.3.2. Multi-Hop TraceRequest Authentication . . . . . . . . 62
8.5. Authentication of RID Protocol . . . . . . . . . . . . . . 62 9.4. Consortiums and Public Key Infrastructures . . . . . . . . 63
8.5.1. Multi-Hop TraceRequest Authentication . . . . . . . . 63 9.5. Privacy Concerns and System Use Guidelines . . . . . . . . 64
8.6. Consortiums and Public Key Infrastructures . . . . . . . . 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 68
8.7. Privacy Concerns and System Use Guidelines . . . . . . . . 65 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
9. Security Considerations . . . . . . . . . . . . . . . . . . . 69 12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 13.1. Normative References . . . . . . . . . . . . . . . . . . . 70
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71 13.2. Informative References . . . . . . . . . . . . . . . . . . 72
12.1. Normative References . . . . . . . . . . . . . . . . . . . 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 72
12.2. Informative References . . . . . . . . . . . . . . . . . . 73
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 73
1. Introduction 1. Introduction
This document moves Real-time Inter-network Defense (RID) [RFC6045] This document moves Real-time Inter-network Defense (RID) [RFC6045]
to Historic status as it provides minor updates. Organizations to Historic status as it provides minor updates. Organizations
require help from other parties to identify incidents, mitigate require help from other parties to identify incidents, mitigate
malicious activity targeting their computing resources, and to gain malicious activity targeting their computing resources, and to gain
insight into potential threats through the sharing of information. insight into potential threats through the sharing of information.
This coordination might entail working with a service provider (SP) This coordination might entail working with a service provider (SP)
to filter attack traffic, working with a SP to resolve a to filter attack traffic, working with a SP to resolve a
configuration issue unintentionally causing problems, contacting a configuration issue unintentionally causing problems, contacting a
remote site to take down a bot- network, or sharing watch-lists of remote site to take down a bot- network, or sharing watch-lists of
known malicious IP addresses in a consortium. known malicious IP addresses in a consortium. The term SP is to be
interpreted as any type of service provider or CSIRT that may be
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 a 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
skipping to change at page 5, line 31 skipping to change at page 5, line 33
achieve a necessary level of security. achieve a necessary level of security.
Coordinating with other CSIRTs is not strictly a technical problem. Coordinating with other CSIRTs is not strictly a technical problem.
There are numerous procedural, trust, and legal considerations that There are numerous procedural, trust, and legal considerations that
might prevent an organization from sharing information. RID provides might prevent an organization from sharing information. RID provides
information and options that can be used by organizations who must information and options that can be used by organizations who must
then apply their own policies for sharing information. Organizations then apply their own policies for sharing information. Organizations
must develop policies and procedures for the use of the RID protocol must develop policies and procedures for the use of the RID protocol
and IODEF. and IODEF.
This specification updates [RFC6045]. Differences from [RFC6045] are This specification obsoletes [RFC6045]. Differences from [RFC6045]
summarized below: are summarized below:
o Edits reflected in this updated version of RFC6045 are primarily o This document is on standards track while [RFC6045] was
informational, but now it is historic.
o Edits reflected in this updated version of RID are primarily
improvements to the informational descriptions. The descriptions improvements to the informational descriptions. The descriptions
have been updated to clarify the use of IODEF and RID extend for have been updated to clarify the use of IODEF and RID extend for
all types of incidents and are not limited to network security all types of incidents and are not limited to network security
incidents. The language has been updated to reduce a focus on incidents. The language has been updated to reduce a focus on
attacks and instead on incidents where appropriate. The term attacks and instead on incidents where appropriate. The term
network provider has been replaced with the more generic term of network provider has been replaced with the more generic term of
service provider. Several introductory informational sections service provider. Several introductory informational sections
have been removed as they are not necessary for the implementation have been removed as they are not necessary for the implementation
of the protocol. The sections include: of the protocol. The sections include:
skipping to change at page 5, line 46 skipping to change at page 6, line 4
have been updated to clarify the use of IODEF and RID extend for have been updated to clarify the use of IODEF and RID extend for
all types of incidents and are not limited to network security all types of incidents and are not limited to network security
incidents. The language has been updated to reduce a focus on incidents. The language has been updated to reduce a focus on
attacks and instead on incidents where appropriate. The term attacks and instead on incidents where appropriate. The term
network provider has been replaced with the more generic term of network provider has been replaced with the more generic term of
service provider. Several introductory informational sections service provider. Several introductory informational sections
have been removed as they are not necessary for the implementation have been removed as they are not necessary for the implementation
of the protocol. The sections include: of the protocol. The sections include:
* 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 remains the same with the exception updates for o The schema version was incremented. The schema remains the same
reported errata and an additional enumeration in the RIDPolicy with the exception updates for reported errata and an additional
class for 'LawEnforcement'. Additional text has been provided to enumeration in the RIDPolicy class for 'LawEnforcement'.
clarify definitions of enumerated values for some attributes. Additional text has been provided to clarify definitions of
enumerated values for some attributes.
o Guidance has improved to ensure consistent implementations and use o Guidance has improved to ensure consistent implementations and use
of XML encryption to provide confidentiality based on data of XML encryption to provide confidentiality based on data
markers, specifically the iodef:restriction attribute in the IODEF markers, specifically the iodef:restriction attribute in the IODEF
and IODEF-RID schemas. The attribute may also be present in IODEF and IODEF-RID schemas. The attribute may also be present in IODEF
extension schemas, where the guidance also applies. extension schemas, where the guidance also applies.
o All of the normative text from the Security Considerations Section o All of the normative text from the Security Considerations Section
has been moved to a new Section, Security Requirements. has been moved to a new Section, Security Requirements.
o The order in which the RID Schema is presented in Section 4 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.
1.1. Normative and Informative 1.1. Normative and Informative
Section 1, 2, 3, and 12 provide helpful background information and
considerations. RID systems participating in a consortium are
REQUIRED to fully implement sections 4, 5, 6, 7, 8, 9, 10, and 11 to
prevent interoperability concerns.
The XML schema [XMLschema] and transport requirements contained in The XML schema [XMLschema] and transport requirements contained in
this document are normative; all other information provided is this document are normative; all other information provided is
intended as informative. More specifically, the following sections intended as informative. More specifically, the following sections
of this document are intended as informative: Sections 1, 2, and 9; of this document are intended as informative: Sections 2, 3, 10, and
and the sub-sections of 3 including the introduction to 3, 3.1, and 13.2. The following sections of this document are normative:
3.2. The following sections of this document are normative: The sub- Sections 1, 4, 5, 6, 7, 8, 10, 11, 12, and 13.1.
sections of 3 including 3.3, 3.4, and 3.5; Sections 5, 6, 7, 8, 10,
and 11.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Characteristics of Incidents 2. Characteristics of Incidents
The goal of tracing a security incident may be to identify the source The goal of tracing a security incident may be to identify the source
skipping to change at page 8, line 8 skipping to change at page 8, line 19
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 NP 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
skipping to change at page 8, line 38 skipping to change at page 8, line 49
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
Note: The Introduction, and Sub-sections 3.1 and 3.2, are Expediting the communication between CSIRTs and SPs is essential when
informative, with the exception of references to IODEF/RID Transport responding to a security-related incident, which may cross network
RFC6046-bis [RFC6046-bis]. Sub-sections 3.3, 3.4, and 3.5 are access points between service or network providers. As a result of
normative. the urgency involved in this inter-service provider security incident
communication, there must be an effective system in place to
Expediting the communication between CSIRTs and service providers
(SP) is essential when responding to a security-related incident,
which may cross network access points (Internet backbones or cloud
infrastructures) between service or network providers. As a result
of the urgency involved in this inter-service provider security
incident communication, there must be an effective system in place to
facilitate the interaction. This communication policy or method facilitate the interaction. This communication policy or method
should involve multiple means of communication to avoid a single should involve multiple means of communication to avoid a single
point of failure. Email is one way to transfer information about the point of failure. Email is one way to transfer information about the
incident, packet traces, etc. However, email may not be received in incident, packet traces, etc. However, email may not be received in
a timely fashion or be acted upon with the same urgency as a phone a timely fashion or be acted upon with the same urgency as a phone
call or other communication mechanism like RID. call or other communication mechanism like RID.
A technical solution to trace traffic across a single service or A technical solution to trace traffic across a single service or
network provider may include homegrown or commercial systems for network provider may include homegrown or commercial systems for
which RID messaging must accommodate the input requirements. The which RID messaging must accommodate the input requirements. The
incident handling system used on the service or network provider's incident handling system used on the service or network provider's
backbone by the CSIRT to coordinate the trace across the single backbone by the CSIRT to coordinate the trace across the single
network requires a method to accept and process and relay RID network requires a method to accept, process, and relay RID messages
messages to the system, as well as to wait for responses from the to the system, as well as to wait for responses from the system to
system to continue the RID request process as appropriate. In this continue the RID request process as appropriate. In this scenario,
scenario, each service provider maintains its own system capable of each service provider maintains its own system capable of
communicating via RID and integrate 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. An a consortium that may be able to provide centralized resources.
example of a consortium might include the cloud service providers.
Consortiums could consist of a group of service (network, cloud, Consortiums could consist of a group of service providers, CSIRTs, or
etc.) providers, CSIRTs, or other federation that agrees to other federation that agrees to participate in the RID communication
participate in the RID communication protocol with an agreed-upon protocol with an agreed-upon policy and communication protocol
policy and communication protocol facilitating the secure transport facilitating the secure transport of IODEF/RID XML documents.
of IODEF/RID XML documents. Transport for RID messages is specified Transport for RID messages is specified in [RFC6046-bis].
in the IODEF/RID Transport [X.ridd] Recommendation.
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 through the use of a standard messaging mechanism networks' equipment. RID provides a standard messaging mechanism to
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
skipping to change at page 10, line 39 skipping to change at page 10, line 41
Procedures for incident handling need to be established and well Procedures for incident handling need to be established and well
known by anyone that may be involved in incident response. The known by anyone that may be involved in incident response. The
procedures should also contain contact information for internal procedures should also contain contact information for internal
escalation procedures, as well as for external assistance groups such escalation procedures, as well as for external assistance groups such
as a CSIRT, CERT Coordination Center (CERT/CC), Global Information as a CSIRT, CERT Coordination Center (CERT/CC), Global Information
Assurance Certification (GIAC), and the FBI or other assisting Assurance Certification (GIAC), and the FBI or other assisting
government organization in the country of the investigation. government organization in the country of the investigation.
3.1. Inter-network Provider RID Messaging 3.1. Inter-network Provider RID Messaging
RID provides a standard protocol and format that is required to RID provides a protocol and format that ensures interoperability
ensure inter-operability between vendors for the implementation of an between vendors for the implementation of an incident messaging
incident messaging mechanism. The messages should meet several mechanism. The messages should meet several requirements in order to
requirements in order to be meaningful as they traverse multiple be meaningful as they traverse multiple networks. RID provides the
networks. RID provides the framework necessary for communication framework necessary for communication between networks involved in
between networks involved in the incident handling, possible the incident handling, possible traceback, and mitigation of a
traceback, and mitigation of a security incident. Several message security incident. Several message types described in Section 4.2
types described in Section 3.5 are necessary to facilitate the are necessary to facilitate the handling of a security incident. The
handling of a security incident. The message types include the message types include the Report, IncidentQuery, TraceRequest,
Report, IncidentQuery, TraceRequest, RequestAuthorization, Result, RequestAuthorization, Result, and the Investigation request message.
and the Investigation request message.
The Report message is used when an incident is to be filed on a RID The Report message is used when an incident is to be filed on a RID
system or associated database, where no further action is required. system or associated database, where no further action is required.
An IncidentQuery message is used to request information on a An IncidentQuery message is used to request information on a
particular incident. A TraceRequest message is used when the source particular incident. A TraceRequest message is used when the source
of the traffic may have been spoofed. In that case, each network of the traffic may have been spoofed. In that case, each network
provider in the upstream path who receives a TraceRequest will issue provider in the upstream path who receives a TraceRequest will issue
a trace across the network to determine the upstream source of the a trace across the network to determine the upstream source of the
traffic. The RequestAuthorization and Result messages are used to traffic. The RequestAuthorization and Result messages are used to
communicate the status and result of a TraceRequest or Investigation communicate the status and result of a TraceRequest or Investigation
request. The Investigation request message only involves the systems request. The Investigation request message only involves the systems
accepting RID communication along the path to the source of the accepting RID communication along the path to the source of the
traffic and not the use of network trace systems. The Investigation traffic and not the use of network trace systems. The Investigation
skipping to change at page 13, line 35 skipping to change at page 13, line 37
result, many networks would have utilized unnecessary resources for a result, many networks would have utilized unnecessary resources for a
TraceRequest that may have also been unnecessary. TraceRequest 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.
3.3. Message Formats 4. Message Formats
Section 3.5 describes the six RID message types, which leverage the
IODEF model [RFC5070]. The messages are generated and received on
designated systems for RID communication on the provider's network.
The messages may originate from IODEF documents from intrusion
detection servers, CSIRTs, analysts, etc. A RID message uses both
the IODEF document and RID document, which is encapsulated for
transport [RFC6046-bis]. Each RID message type, along with an
example, is described in the following sections. The IODEF-RID
schema is introduced in Section 4 to support the RID message types in
Section 3.5. The term service provider (SP), used in the following
sections should be interpreted as any type of service provider or
CSIRT that may be involved in RID communications.
3.4. 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.
3.4.1. Boolean 4.1.1. Boolean
A boolean value is represented by the BOOLEAN data type. A boolean value is represented by the BOOLEAN data type.
The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
the schema. the schema.
3.5. RID Message Types 4.2. RID Message Types
The six RID message types are as follows: The six RID message types described below MUST be implemented. RID
messages uses both the IODEF [RFC5070] and RID document, which MUST
be encapsulated for transport as specified in [RFC6046-bis]. The
messages are generated and received on designated systems for RID
communications. Each RID message type, along with an example, is
described in the following sections. The IODEF-RID schema is
introduced in Section 5 to support the descried RID message types.
1. TraceRequest. This message is sent to the next provider in the 1. TraceRequest. This message is sent to the next provider in the
upstream trace. It is used to initiate a TraceRequest or to upstream trace. It is used to initiate a TraceRequest or to
continue a TraceRequest to an upstream provider closer to the continue a TraceRequest to an upstream provider closer to the
source address of the origin of the security incident. The source address of the origin of the security incident. The
TraceRequest triggers a traceback on the network to locate the TraceRequest triggers a traceback on the network to locate the
source of the attack traffic. source of the attack traffic.
2. RequestAuthorization. This message is sent to the initiating RID 2. RequestAuthorization. This message is sent to the initiating RID
system from each of the upstream providers' RID systems to system from each of the upstream providers' RID systems to
skipping to change at page 15, line 13 skipping to change at page 15, line 6
an incident or incident type from a trusted system communicating an incident or incident type from a trusted system communicating
via RID. The response is provided through the Report message. via RID. The response is provided through the Report message.
When an application receives a RID message, it must be able to When an application receives a RID message, it must be able to
determine the type of message and parse it accordingly. The message determine the type of message and parse it accordingly. The message
type is specified in the RIDPolicy class. The RIDPolicy class may type is specified in the RIDPolicy class. The RIDPolicy class may
also be used by the transport protocol to facilitate the also be used by the transport protocol to facilitate the
communication of security incident data to trace, investigate, query, communication of security incident data to trace, investigate, query,
or report information regarding security incidents. or report information regarding security incidents.
4. IODEF-RID Schema 5. IODEF-RID Schema
There are three classes included in the RID extension required to There are three classes included in the RID extension required to
facilitate RID communications. The RequestStatus class is used to facilitate RID communications. The RequestStatus class is used to
indicate the approval status of a TraceRequest or Investigation indicate the approval status of a TraceRequest or Investigation
request; the IncidentSource class is used to report whether or not a request; the IncidentSource class is used to report whether or not a
source was found and to identify the source host(s) or network(s); source was found and to identify the source host(s) or network(s);
and the RIDPolicy class provides information on the agreed-upon and the RIDPolicy class provides information on the agreed-upon
policies and specifies the type of communication message being used. policies and specifies the type of communication message being used.
The RID schema defines communication specific metadata to support the The RID schema defines communication specific metadata to support the
exchange of incident information in an IODEF document. The intent in exchange of incident information in an IODEF document. The intent in
maintaining a separate schema and not using the AdditionalData maintaining a separate schema and not using the AdditionalData
extension of IODEF is the flexibility of sending messages between RID extension of IODEF is the flexibility of sending messages between RID
hosts. Since RID is a separate schema and RID messages include both hosts. Since RID is a separate schema and RID messages include both
the RID and IODEF schemas, the RID message acts as an envelope in the RID and IODEF schemas, the RID message acts as an envelope in
that policy and security defined at the RID message layer are applied that policy and security defined at the RID message layer are applied
to both documents. One reason for maintaining separate schemas is to both documents. One reason for maintaining separate schemas is
for flexibility, where the RIDPolicy class can be easily extracted for flexibility, where the RIDPolicy class can be easily extracted
for use in the RID message and by the transport protocol. for use in the RID message and by the transport protocol.
The security requirements of sending incident information across the The security requirements of sending incident information between
network include the use of encryption. The RIDPolicy information is entities include the use of encryption. The RIDPolicy information is
not required to be encrypted, so separating out this data from the not required to be encrypted, so separating out this data from the
IODEF extension removes the need for decrypting and parsing the IODEF XML document removes the need for decrypting and parsing the
entire IODEF and RID document to determine how it should be handled IODEF document to determine how it should be handled at each RID
at each RID host. host.
The purpose of the RIDPolicy class is to specify the message type for The purpose of the RIDPolicy class is to specify the message type for
the receiving host, facilitate the policy needs of RID, and provide the receiving host, facilitate the policy needs of RID, and provide
routing information in the form of an IP address of the destination routing information in the form of an IP address of the destination
RID system. RID system.
The policy information and guidelines are discussed in Section 8.7. The policy information and guidelines are discussed in Section 9.7.
The policy is defined between RID peers and within or between The policy is defined between RID peers and within or between
consortiums. The RIDPolicy is meant to be a tool to facilitate the consortiums. The RIDPolicy is meant to be a tool to facilitate the
defined policies. This MUST be used in accordance with policy set defined policies. This MUST be used in accordance with policy set
between clients, peers, consortiums, and/or regions. Security, between clients, peers, consortiums, and/or regions. Security,
privacy, and confidentiality MUST be considered as specified in this privacy, and confidentiality MUST be considered as specified in this
document. document.
The RID schema is defined as follows: The RID schema is defined as follows:
+------------------+ +------------------+
skipping to change at page 17, line 7 skipping to change at page 17, line 5
Each of the three listed classes may be the only class included in Each of the three listed classes may be the only class included in
the RID class, hence the option for zero or one. In some cases, the RID class, hence the option for zero or one. In some cases,
RIDPolicy MAY be the only class in the RID definition when used by RIDPolicy MAY be the only class in the RID definition when used by
the transport protocol [RFC6046-bis], as that information should be the transport protocol [RFC6046-bis], as that information should be
as small as possible and may not be encrypted. The RequestStatus as small as possible and may not be encrypted. The RequestStatus
message MUST be able to stand alone without the need for an IODEF message MUST be able to stand alone without the need for an IODEF
document to facilitate the communication, limiting the data document to facilitate the communication, limiting the data
transported to the required elements per [RFC6046-bis]. transported to the required elements per [RFC6046-bis].
4.1. RIDPolicy Class 5.1. RIDPolicy Class
The RIDPolicy class facilitates the delivery of RID messages and is The RIDPolicy class facilitates the delivery of RID messages and is
also referenced for transport in the transport document [RFC6046- also referenced for transport in the transport document [RFC6046-
bis]. bis].
+------------------------+ +------------------------+
| RIDPolicy | | RIDPolicy |
+------------------------+ +------------------------+
| | | |
| ENUM restriction |<>-------------[ Node ] | ENUM restriction |<>-------------[ Node ]
skipping to change at page 18, line 4 skipping to change at page 17, line 49
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
of compromised systems found during an investigation, etc. of compromised systems found during an investigation, etc.
PolicyRegion PolicyRegion
One or many. REQUIRED. The values for the attribute "region" are
One or more. REQUIRED. The values for the attribute "region" are
used to determine what policy area may require consideration used to determine what policy area may require consideration
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
Required. ENUM. The attribute region is used to identify the REQUIRED. ENUM. The attribute region is used to identify the
expected sharing range of the incident information. The region expected sharing range of the incident information. The region
may be within a region or defined by existing relationships such may be within a region or defined by existing relationships such
as those of a consortium or client to service provider. as those of a consortium or client to service provider.
1. ClientToSP. A client initiated the request to their service 1. ClientToSP. A client initiated the request to their service
provider (SP). A client may be an individual, enterprise, or provider (SP). A client may be an individual, enterprise, or
other type of entity (government, commercial, education, other type of entity (government, commercial, education,
etc.). A service provider may be a network, etc.). A service provider may be a network,
telecommunications, cloud, infrastructure, or other type of telecommunications, infrastructure, or other type of service
service provider where a client to vendor relationship has provider where a client to vendor relationship has been
been established. The client to vendor relationship will established. The client to vendor relationship will typically
typically have established contracts or agreements to define have established contracts or agreements to define
expectations and trust relationships. expectations and trust relationships.
2. SPToClient. A service provider (SP) initiated a RID request 2. SPToClient. A service provider (SP) initiated a RID request
or report to a client. A client may be an individual, or report to a client. A client may be an individual,
enterprise, or other type of entity (government, commercial, enterprise, or other type of entity (government, commercial,
education, etc.). A service provider may be a network, education, etc.). A service provider may be a network,
telecommunications, cloud, infrastructure, or other type of telecommunications, infrastructure, or other type of service
service provider where a client to vendor relationship has provider where a client to vendor relationship has been
been established. The client to vendor relationship will established. The client to vendor relationship will typically
typically have established contracts or agreements to define have established contracts or agreements to define
expectations and trust relationships. expectations and trust relationships.
3. IntraConsortium. Incident information that should have no 3. IntraConsortium. Incident information that should have no
restrictions within the boundaries of a consortium with the restrictions within the boundaries of a consortium with the
agreed-upon use and abuse guidelines. A consortium is a well agreed-upon use and abuse guidelines. A consortium is a well
defined group with established members and trust relationships defined group with established members and trust relationships
specific to sharing within that group. A consortium would specific to sharing within that group. A consortium would
typically define the types of data that can be shared in typically define the types of data that can be shared in
advance, expectations on protecting that data, as well as advance, expectations on protecting that data, as well as
having established contractual agreements. Examples of having established contractual agreements. Examples of
skipping to change at page 20, line 26 skipping to change at page 20, line 23
Multiple values may be selected for this element; however, where Multiple values may be selected for this element; however, where
possible, it should be restricted to one value that most possible, it should be restricted to one value that most
accurately describes the traffic type. accurately describes the traffic type.
type type
REQUIRED. ENUM. The attribute type is used to identify the type REQUIRED. ENUM. The attribute type is used to identify the type
of information included in the RID message or the type of of information included in the RID message or the type of
incident. incident.
1. Attack. This option should only be selected if the traffic is 1. Attack. This option SHOULD only be selected if the traffic is
related to a information security incident or attack. The related to a information security incident or attack. The
type of attack MUST also be listed in more detail in the IODEF type of attack MUST also be listed in more detail in the IODEF
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
skipping to change at page 21, line 29 skipping to change at page 21, line 23
OPTIONAL. ENUM. This attribute indicates the disclosure OPTIONAL. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient to adhere. guidelines to which the sender expects the recipient to adhere.
This guideline provides no real security since it is the choice This guideline provides no real security since it is the choice
of the recipient of the document to honor it. This attribute of the recipient of the document to honor it. This attribute
follows the same guidelines as "restriction" used in IODEF. follows the same guidelines as "restriction" used in IODEF.
MsgType MsgType
REQUIRED. ENUM. The type of RID message sent. The six types REQUIRED. ENUM. The type of RID message sent. The six types
of messages are described in Section 3.5 and can be noted as of messages are described in Section 4.2 and can be noted as
one of the six selections below. one of the six selections below.
2. TraceRequest. This message may be used to initiate a 2. TraceRequest. This message may be used to initiate a
TraceRequest or to continue a TraceRequest to an upstream TraceRequest or to continue a TraceRequest to an upstream
network closer to the source address of the origin of the network closer to the source address of the origin of the
security incident. security incident.
3. RequestAuthorization. This message is sent to the initiating 3. RequestAuthorization. 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.
skipping to change at page 23, line 15 skipping to change at page 23, line 10
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
4.2. RequestStatus 5.2. RequestStatus
The RequestStatus class is an aggregate class in the RID class. The RequestStatus class is an aggregate class in the RID class.
+--------------------------------+ +--------------------------------+
| RequestStatus | | RequestStatus |
+--------------------------------+ +--------------------------------+
| | | |
| ENUM restriction | | ENUM restriction |
| ENUM AuthorizationStatus | | ENUM AuthorizationStatus |
| ENUM Justification | | ENUM Justification |
skipping to change at page 25, line 4 skipping to change at page 24, line 44
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.
AuthorizationStatus-ext AuthorizationStatus-ext
OPTIONAL. STRING. A means by which to extend the OPTIONAL. STRING. A means by which to extend the
AuthorizationStatus attribute. See IODEF [RFC5070], Section AuthorizationStatus attribute. See IODEF [RFC5070], Section
5.1. 5.1.
Justification-ext Justification-ext
OPTIONAL. STRING. A means by which to extend the OPTIONAL. STRING. A means by which to extend the
Justification attribute. See IODEF [RFC5070], Section 5.1. Justification attribute. See IODEF [RFC5070], Section 5.1.
4.3. IncidentSource 5.3. IncidentSource
The IncidentSource class is an aggregate class in the RID class. The IncidentSource class is an aggregate class in the RID class.
+-------------------+ +-------------------+
| IncidentSource | | IncidentSource |
+-------------------+ +-------------------+
| | | |
| ENUM restriction | | ENUM restriction |
| |<>-------------[ SourceFound ] | |<>-------------[ SourceFound ]
| | | |
skipping to change at page 26, line 7 skipping to change at page 26, line 5
The IncidentSource class has one attribute: The IncidentSource class has one attribute:
restriction restriction
OPTIONAL. ENUM. This attribute indicates the disclosure OPTIONAL. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient to adhere. guidelines to which the sender expects the recipient to adhere.
This guideline provides no real security since it is the choice This guideline provides no real security since it is the choice
of the recipient of the document to honor it. This attribute of the recipient of the document to honor it. This attribute
follows the same guidelines as "restriction" used in IODEF. follows the same guidelines as "restriction" used in IODEF.
4.4. RID Name Spaces 5.4. RID Name Spaces
The RID schema declares a namespace of "iodef-rid-1.1" and registers The RID schema declares a namespace of "iodef-rid-1.1" and registers
it per [XMLNames]. Each IODEF-RID document MUST use the it per [XMLNames]. Each IODEF-RID document MUST use the
"iodef-rid-1.1" namespace in the top-level element RID-Document. It "iodef-rid-1.1" namespace in the top-level element RID-Document. It
can be referenced as follows: can be referenced as follows:
<RID-Document version="1.10" lang="en-US" <RID-Document version="1.10" lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
xsi:schemaLocation=http://www.iana.org/assignments/xml-registry/ xsi:schemaLocation=http://www.iana.org/assignments/xml-registry/
schema/iodef-rid-1.1.xsd"> schema/iodef-rid-1.1.xsd">
5. RID Messages 6. RID Messages
The IODEF model is followed as specified in [RFC5070] for each of the The IODEF model is followed as specified in [RFC5070] for each of the
RID message types. The RID schema is used in combination with IODEF RID message types. The RID schema is used in combination with IODEF
documents to facilitate RID communications. Each message type varies documents to facilitate RID communications. Each message type varies
slightly in format and purpose; hence, the requirements vary and are slightly in format and purpose; hence, the requirements vary and are
specified for each. All classes, elements, attributes, etc., that specified for each. All classes, elements, attributes, etc., that
are defined in the IODEF-Document are valid in the context of a RID are defined in the IODEF-Document are valid in the context of a RID
message; however, some listed as optional in IODEF are mandatory for message; however, some listed as optional in IODEF are mandatory for
RID as listed for each message type. The IODEF model MUST be fully RID as listed for each message type. The IODEF model MUST be fully
implemented to ensure proper parsing of all RID messages. implemented to ensure proper parsing of all RID messages.
Note: The implementation of RID may automate the ability to fill in Note: The implementation of RID may automate the ability to fill in
the content required for each message type from packet input, the content required for each message type from packet input,
incident data, situational awareness information, or default values incident data, situational awareness information, or default values
such as that used in the EventData class. such as that used in the EventData class.
5.1. TraceRequest 6.1. TraceRequest
Description: This message or document is sent to the network Description: This message or document is sent to the network
management station next in the upstream trace once the upstream management station next in the upstream trace once the upstream
source of the traffic has been identified. The following information source of the traffic has been identified. The following information
is required for TraceRequest messages and is provided through: is REQUIRED for TraceRequest messages and is provided through:
RID Information: RID Information:
RIDPolicy RIDPolicy
RID message type, IncidentID, and destination policy RID message type, IncidentID, and destination policy
information information
IODEF Information: IODEF Information:
skipping to change at page 27, line 27 skipping to change at page 27, line 25
Path information of nested RID systems, beginning with the request Path information of nested RID systems, beginning with the request
originator used in the trace using IODEF EventData with category originator used in the trace using IODEF EventData with category
set to "infrastructure". set to "infrastructure".
Event, Record, and RecordItem classes to include example packets Event, Record, and RecordItem classes to include example packets
and other information related to the incident. Note: Event and other information related to the incident. Note: Event
information included here requires a second instance of EventData information included here requires a second instance of EventData
in addition to that used to convey service/network provider (SP) in addition to that used to convey service/network provider (SP)
path contact information. path contact information.
Standards for encryption and digital signatures [RFC3275], [XMLsig]: Standards for encryption and digital signatures [RFC3275], [XMLsig],
[XMLencrypt]:
Digital signature from initiating CSIRT or provider system sending Digital signature from initiating CSIRT or provider system sending
the RID message, passed to all systems in upstream trace using a the RID message, passed to all systems in upstream trace using a
detached XML digital signature on a RecordItem entry. detached XML digital signature on a RecordItem entry.
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.
XML encryption as required by policy, agreements, and data XML encryption as required by policy, agreements, and data
skipping to change at page 28, line 5 skipping to change at page 28, line 5
locate the sources of the attack. It may be valid to continue locate the sources of the attack. It may be valid to continue
multiple traces for a single attack. The path information enables multiple traces for a single attack. The path information enables
the administrators to determine if the exact trace had already passed the administrators to determine if the exact trace had already passed
through a single network. The Incident Identifier must also be used through a single network. The Incident Identifier must also be used
to identify multiple TraceRequests from a single incident. If a to identify multiple TraceRequests from a single incident. If a
single TraceRequest results in divergent paths of TraceRequests, a single TraceRequest results in divergent paths of TraceRequests, a
separate instance number MUST be used under the same IncidentID. The separate instance number MUST be used under the same IncidentID. The
IncidentID instance number of IODEF can be used to correlate related IncidentID instance number of IODEF can be used to correlate related
incident data that is part of a larger incident. incident data that is part of a larger incident.
5.2. RequestAuthorization 6.2. RequestAuthorization
Description: This message is sent to the initiating RID system from Description: This message is sent to the initiating RID system from
the next upstream provider's application or system designated for the next upstream provider's application or system designated for
accepting RID communications to provide information on the request accepting RID communications to provide information on the request
status in the current network. status in the current network.
The following information is required for RequestAuthorization The following information is REQUIRED for RequestAuthorization
messages and is provided through: messages and is provided through:
RID Information: RID Information:
RIDPolicy RIDPolicy
RID message type, IncidentID, and destination policy RID message type, IncidentID, and destination policy
information information
RequestStatus class: RequestStatus class:
Status of TraceRequest Status of TraceRequest
Standards for encryption and digital signatures [RFC3275], [XMLsig]: Standards for encryption and digital signatures [RFC3275], [XMLsig],
[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. accepting RID communications of the trace as status notification.
skipping to change at page 28, line 49 skipping to change at page 29, line 5
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 taken to
approve or disapprove the trace continuance. If a Request is denied, approve or disapprove the trace continuance. If a Request is denied,
the originator and sending peer (if they are not the same) MUST both the 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 enables the sending peer the option to
take action to stop or mitigate the traffic as close to the source as take action to stop or mitigate the traffic as close to the source as
possible. possible.
5.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 through the IncidentSource class. The Result source information through the IncidentSource class. The Result
information MUST go back to the originating RID system that began the information MUST go back to the originating RID system that began the
investigation or trace. An provider may use any number of incident investigation or trace. An provider may use any number of incident
handling data sources to ascertain the true source of an attack. All handling data sources to ascertain the true source of an attack. All
of the possible information sources may or may not be readily tied of the possible information sources may or may not be readily tied
into the RID communications system. 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:
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
skipping to change at page 29, line 35 skipping to change at page 29, line 40
if a source was identified and provide the source if a source was identified and provide the source
address(es). address(es).
IODEF Information: IODEF Information:
Time Stamps (DetectTime, StartTime, EndTime, ReportTime). Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
Incident Identifier (Incident class, IncidentID). Incident Identifier (Incident class, IncidentID).
Trace number - used for multiple traces of a single Trace number - used for multiple traces of a single
incident; must be noted. incident; MUST be included if the response 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 and must note if the traffic is Information used in the attack and must note if the traffic is
spoofed, thus requiring an upstream TraceRequest in RID. spoofed, thus requiring an upstream TraceRequest in RID.
History class "atype" attribute is used to note any actions History class "atype" attribute is used to note any actions
taken. taken.
skipping to change at page 30, line 17 skipping to change at page 30, line 21
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],
[XMLsig], [XMLencrypt]:
Digital signature of source CSIRT or provider for authenticity Digital signature of source CSIRT or provider for authenticity
of Result message, from the CSIRT or provider creating this of Result 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 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
skipping to change at page 30, line 39 skipping to change at page 30, line 44
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 enough to block all Internet access until the
host has taken the appropriate action to resolve any security issues host has taken the appropriate action to resolve any security issues
or to rate-limit the ingress traffic as close to the source as or to rate-limit the ingress traffic as close to the source as
possible. possible.
Security and privacy requirements discussed in Section 8 MUST be Security and privacy requirements discussed in Section 9 MUST be
taken into account. taken into account.
Note: The History class has been expanded in IODEF to accommodate all Note: The History class has been expanded in IODEF to accommodate all
of the possible actions taken as a result of a RID TraceRequest or of the possible actions taken as a result of a RID TraceRequest or
Investigation request using the "iodef:atype", or action type, Investigation request using the "iodef:atype", or action type,
attribute. The History class should be used to note all actions attribute. The History class should be used to note all actions
taken close to the source of a trace or incident using the most taken close to the source of a trace or incident using the most
appropriate option for the type of action along with a description. appropriate option for the type of action along with a description.
The "atype" attribute in the Expectation class can also be used to The "atype" attribute in the Expectation class can also be used to
request an appropriate action when a TraceRequest or Investigation request an appropriate action when a TraceRequest or Investigation
request is made. request is made.
5.4. Investigation Request 6.4. Investigation Request
Description: This message type is used when the source of the traffic Description: This message type is used when the source of the traffic
is believed not to be spoofed. The purpose of the Investigation is believed not to be spoofed. The purpose of the Investigation
request message is to leverage the existing bilateral peer request message is to leverage the existing bilateral peer
relationships in order to notify the network provider closest to the relationships in order to notify the network provider closest to the
source of the valid traffic that some event occurred, which may be a source of the valid traffic that some event occurred, which may be a
security-related incident. security-related incident.
The following information is required for Investigation request The following information is REQUIRED for Investigation request
messages and is provided through: messages and is provided through:
RID Information: RID Information:
RID Policy RID Policy
RID message type, IncidentID, and destination policy RID message type, IncidentID, and destination policy
information information
IODEF Information: IODEF Information:
Time Stamps (DetectTime, StartTime, EndTime, ReportTime). Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
Incident Identifier (Incident class, IncidentID). Incident Identifier (Incident class, IncidentID).
Trace number - used for multiple traces of a single Trace number - used for multiple traces of a single
incident; must be noted. incident; MUST be included if the InvestigationRequest is 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 TraceRequest in RID. spoofed, thus requiring an upstream TraceRequest in RID.
Expectation class should be used to request any specific Expectation class should be used to request any specific
actions to be taken close to the source. actions to be taken close to the source.
skipping to change at page 32, line 5 skipping to change at page 32, line 11
messages, beginning with the request originator used in the messages, beginning with the request originator used in the
trace using IODEF EventData with category set to trace using IODEF EventData with category set to
"infrastructure". "infrastructure".
Event, Record, and RecordItem classes to include example Event, Record, and RecordItem classes to include example
packets and other information related to the incident. Note: packets and other information related to the incident. Note:
Event information included here requires a second instance of Event information included here requires a second instance of
EventData in addition to that used to convey SP path contact EventData in addition to that used to convey SP path contact
information. information.
Standards for encryption and digital signatures [RFC3275]: Standards for encryption and digital signatures [RFC3275],
[XMLsig], [XMLencrypt]:
Digital signature from initiating system sending the RID Digital signature from initiating system sending the RID
message, passed to all systems involved in the investigation message, passed to all systems involved in the investigation
using a detached XML digital signature on a RecordItem entry. using a detached XML digital signature on a RecordItem entry.
Digital signature of sending CSIRT or SP for authenticity of Digital signature of sending CSIRT or SP for authenticity of
the RID message, from the CSIRT or provider sending this the RID message, from the CSIRT or provider sending this
message using an enveloped XML digital signature on the IODEF message using an enveloped XML digital signature on the IODEF
document. document.
skipping to change at page 32, line 39 skipping to change at page 32, line 46
systems. The destination SP is responsible for any actions taken as systems. The destination SP is responsible for any actions taken as
a result of the request in adherence to any service level agreements a result of the request in adherence to any service level agreements
or internal policies. The SP MUST confirm that the traffic actually or internal policies. The SP MUST confirm that the traffic actually
originated from the suspected system before taking any action and originated from the suspected system before taking any action and
confirm the reason for the request. The request may be sent directly confirm the reason for the request. The request may be sent directly
to a known RID system or routed by the source address of the attack to a known RID system or routed by the source address of the attack
using the message destination of RIDPolicy, SourceOfIncident. Note: using the message destination of RIDPolicy, SourceOfIncident. Note:
All intermediate parties MUST be able to view RIDPolicy information All intermediate parties MUST be able to view RIDPolicy information
in order to properly direct RID messages. in order to properly direct RID messages.
5.5. Report 6.5. Report
Description: This message or document is sent to a RID system to Description: This message or document is sent to a RID system to
provide a report of a security incident. This message does not provide a report of a security incident. This message does not
require any actions to be taken, except to file the report on the require any actions to be taken, except to file the report on the
receiving RID system or associated database. receiving RID system or associated database.
The following information is required for Report messages and will be The following information is REQUIRED for Report messages and will be
provided through: provided through:
RID Information: RID Information:
RID Policy RID message type, IncidentID, and destination policy RID Policy 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:
IODEF Information: IODEF Information:
Time Stamps (DetectTime, StartTime, EndTime, ReportTime). Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
Incident Identifier (Incident class, IncidentID). Trace number Incident Identifier (Incident class, IncidentID). Trace number
- used for multiple traces of a single incident; must be noted. - used for multiple traces of a single incident; 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 to include example
packets and other information related to the incident packets and other information related to the incident
(optional). (optional).
Standards for encryption and digital signatures [RFC3275]: Standards for encryption and digital signatures [RFC3275],
[XMLsig], [XMLencrypt]:
Digital signature from initiating RID system, passed to all Digital signature from initiating RID system, passed to all
systems receiving the report using an enveloped XML digital systems receiving the report using an enveloped XML digital
signature. signature.
XML encryption as required by policy, agreements, and data XML encryption as required by policy, agreements, and data
markers. markers.
Security requirements include the ability to encrypt [XMLencrypt] the Security requirements include the ability to encrypt [XMLencrypt] the
contents of the Report message using the public key of the contents of the Report message using the public key of the
skipping to change at page 33, line 48 skipping to change at page 34, line 10
information for the purpose of trending, pattern detection, etc., and information for the purpose of trending, pattern detection, etc., and
may be shared with other parties unless otherwise agreed upon with may be shared with other parties unless otherwise agreed upon with
the receiving RID system. Therefore, sending parties of a Report the receiving RID system. Therefore, sending parties of a Report
message may obfuscate or remove destination addresses or other message may obfuscate or remove destination addresses or other
sensitive information before sending a Report message. A Report sensitive information before sending a Report message. A Report
message may be sent either to file an incident report or in response message may be sent either to file an incident report or in response
to an IncidentQuery, and data sensitivity must be considered in both to an IncidentQuery, and data sensitivity must be considered in both
cases. The SP path information is not necessary for this message, as cases. The SP path information is not necessary for this message, as
it will be communicated directly between two trusted RID systems. it will be communicated directly between two trusted RID systems.
5.6. IncidentQuery 6.6. IncidentQuery
Description: The IncidentQuery message is used to request incident Description: The IncidentQuery message is used to request incident
information from a trusted RID system. The request can include the information from a trusted RID system. The request can include the
incident number, if known, or detailed information about the incident number, if known, or detailed information about the
incident. If the incident number is known, the Report message incident. If the incident number is known, the Report message
containing the incident information can easily be returned to the containing the incident information can easily be returned to the
trusted requestor using automated methods. If an example packet or trusted requestor using automated methods. If an example packet or
other unique information is included in the IncidentQuery, the return other unique information is included in the IncidentQuery, the return
report may be automated; otherwise, analyst intervention may be report may be automated; otherwise, analyst intervention may be
required. required.
The following information must be used for an IncidentQuery message The following information is REQUIRED for an IncidentQuery message
and is provided through: and is provided through:
RID Information: RID Information:
RID Policy RID Policy
RID message type, IncidentID, and destination policy RID message type, IncidentID, and destination policy
information information
IODEF Information (optional): IODEF Information (optional):
Time Stamps (DetectTime, StartTime, EndTime, ReportTime). Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
Incident Identifier (Incident class, IncidentID). Incident Identifier (Incident class, IncidentID).
Trace number - used for multiple traces of a single Trace number - used for multiple traces of a single
incident; must be noted. incident; MUST be included if the IncidentQuery is 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 to include example
packets and other information related to the incident packets and other information related to the incident
(optional). (optional).
Standards for encryption and digital signatures [RFC3275]: Standards for encryption and digital signatures [RFC3275],
[XMLsig], [XMLencrypt]:
Digital signature from the CSIRT or SP initiating the RID Digital signature from the CSIRT or SP initiating the RID
message, passed to all systems receiving the IncidentQuery message, passed to all systems receiving the IncidentQuery
using an enveloped XML digital signature. 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.
The proper response to the IncidentQuery message is a Report message. The proper response to the IncidentQuery 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
skipping to change at page 35, line 17 skipping to change at page 35, line 31
5, to prevent the documents from becoming too large. Other transfer 5, to prevent the documents from becoming too large. Other transfer
methods may be suited better than RID for large transfers of data. methods may be suited better than RID for large transfers of data.
The Confidence rating may be used in the IncidentQuery message to The Confidence rating may be used in the IncidentQuery message to
select only incidents with an equal or higher Confidence rating than select only incidents with an equal or higher Confidence rating than
what is specified. This may be used for cases when information is what is specified. This may be used for cases when information is
gathered on a type of incident but not on specifics about a single gathered on a type of incident but not on specifics about a single
incident. Source and Destination Information may not be needed if incident. Source and Destination Information may not be needed if
the IncidentQuery is intended to gather data about a specific type of the IncidentQuery is intended to gather data about a specific type of
incident as well. incident as well.
6. 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.
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.
6.1. Upstream Trace Communication Flow 7.1. Upstream Trace Communication Flow
The diagram below outlines the RID TraceRequest communication flow The diagram below outlines the RID TraceRequest communication flow
between RID systems on different networks tracing an attack. SP-1, between RID systems on different networks tracing an attack. SP-1,
SP-2, SP-3 represent service or network providers that are involved SP-2, SP-3 represent service or network providers that are involved
in the example trace communication flow. in the example trace communication flow.
Attack Dest SP-1 SP-2 SP-3 Attack Src Attack Dest SP-1 SP-2 SP-3 Attack Src
1. Attack | Attack 1. Attack | Attack
reported | detected reported | detected
skipping to change at page 37, line 42 skipping to change at page 37, line 42
information about the incident source and any actions taken. If the information about the incident source and any actions taken. If the
originator fails to decrypt or authenticate the Result message, a originator fails to decrypt or authenticate the Result message, a
RequestAuthorization message is sent in response; otherwise, no RequestAuthorization message is sent in response; otherwise, no
return message is sent. If a RequestAuthorization message is sent return message is sent. If a RequestAuthorization message is sent
with the RequestStatus set to Denied, a downstream peer receiving with the RequestStatus set to Denied, a downstream peer receiving
this message may choose to take action to stop or mitigate the this message may choose to take action to stop or mitigate the
traffic at that point in the network, as close to the source as traffic at that point in the network, as close to the source as
possible. If the downstream peer chooses this option, it would send possible. If the downstream peer chooses this option, it would send
a Result message to the trace originator. a Result message to the trace originator.
6.1.1. RID TraceRequest Example 7.1.1. RID TraceRequest Example
The example listed is of a TraceRequest based on the incident report The example listed is of a TraceRequest based on the incident report
example from the IODEF document. The RID extension classes were example from the IODEF document. The RID extension classes were
included as appropriate for a TraceRequest message using the included as appropriate for a TraceRequest message using the
RIDPolicy class. The example given is that of a CSIRT reporting a RIDPolicy class. The example given is that of a CSIRT reporting a
DoS attack in progress to the upstream SP. The request asks the next DoS attack in progress to the upstream SP. The request asks the next
SP to continue the trace and have the traffic mitigated closer to the SP to continue the trace and have the traffic mitigated closer to the
source of the traffic. The example TraceRequest message is the first source of the traffic. The example TraceRequest message is the first
step of a TraceRequest as depicted in the previous diagram, where step of a TraceRequest as depicted in the previous diagram, where
'Attack Dest' is represented by 192.0.2.67 (and SP-1). The "Attack 'Attack Dest' is represented by 192.0.2.67 (and SP-1). The "Attack
skipping to change at page 38, line 30 skipping to change at page 38, line 30
relationships from the SP Node information to the name, contact, relationships from the SP Node information to the name, contact,
digital signature verification information and other identifying or digital signature verification information and other identifying or
trust information is provided at the application layer to support end trust information is provided at the application layer to support end
users of the incident management system. A packet is provided in users of the incident management system. A packet is provided in
this example to enable any traces to be performed by SP-2 and SP-3 to this example to enable any traces to be performed by SP-2 and SP-3 to
perform traces to the attack source before taking the requested perform traces to the attack source before taking the requested
action to 'rate-limit' the traffic. The subnet of 192.0.2.0uses a 27 action to 'rate-limit' the traffic. The subnet of 192.0.2.0uses a 27
bit mask in the examples below. bit mask in the examples below.
In the following example, use of [XMLsig] to generate digital In the following example, use of [XMLsig] to generate digital
signatures used SHA-1 following the guidance of [XMLsig] 1.0. signatures follows the guidance of [XMLsig] 1.0. Version 1.1 of
Version 1.1 of [XMLsig] supports additional digest algorithms. [XMLsig] supports additional digest algorithms. SHA-1 SHOULD NOT be
used, see [RFC6194] for further details.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="TraceRequest" <iodef-rid:RIDPolicy MsgType="TraceRequest"
MsgDestination="RIDSystem"> MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/> <iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address> <iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
</iodef:Node> </iodef:Node>
<iodef-rid:TrafficType type="Attack"/> <iodef-rid:TrafficType type="Attack"/>
skipping to change at page 41, line 36 skipping to change at page 41, line 37
<G>Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5 <G>Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5
Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==</G> Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==</G>
<Y>VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs <Y>VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs
HifTyYdnj+roGzy4o09YntYD8zneQ7lw==</Y> HifTyYdnj+roGzy4o09YntYD8zneQ7lw==</Y>
</DSAKeyValue> </DSAKeyValue>
</KeyValue> </KeyValue>
</KeyInfo> </KeyInfo>
</Signature> </Signature>
</Envelope> </Envelope>
6.1.2. RequestAuthorization Message Example 7.1.2. RequestAuthorization Message Example
The example RequestAuthorization message is in response to the The example RequestAuthorization message is in response to the
TraceRequest message listed above. The SP that received the request TraceRequest message listed above. The SP that received the request
is responding to approve the trace continuance in their network. is responding to approve the trace continuance in their network.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="RequestAuthorization" <iodef-rid:RIDPolicy MsgType="RequestAuthorization"
MsgDestination="RIDSystem"> MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/> <iodef-rid:PolicyRegion region="IntraConsortium"/>
skipping to change at page 42, line 21 skipping to change at page 42, line 21
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address> <iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node> </iodef:Node>
<iodef-rid:TrafficType type="Attack"/> <iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1 CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID> </iodef:IncidentID>
</iodef-rid:RIDPolicy> </iodef-rid:RIDPolicy>
<iodef-rid:RequestStatus AuthorizationStatus="Approved"/> <iodef-rid:RequestStatus AuthorizationStatus="Approved"/>
</iodef-rid:RID> </iodef-rid:RID>
6.1.3. Result Message Example 7.1.3. Result Message Example
The example Result message is in response to the TraceRequest listed The example Result message is in response to the TraceRequest listed
above. This message type only comes after a RequestAuthorization above. This message type only comes after a RequestAuthorization
within the TraceRequest flow of messages. It may be a direct within the TraceRequest flow of messages. It may be a direct
response to an Investigation request. This message provides response to an Investigation request. This message provides
information about the source of the attack and the actions taken to information about the source of the attack and the actions taken to
mitigate the traffic. mitigate the traffic.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
skipping to change at page 45, line 20 skipping to change at page 45, line 20
CSIRT-FOR-SP3#3291-1 CSIRT-FOR-SP3#3291-1
</iodef:IncidentID> </iodef:IncidentID>
<iodef:Description> <iodef:Description>
Host rate-limited for 24 hours Host rate-limited for 24 hours
</iodef:Description> </iodef:Description>
</iodef:HistoryItem> </iodef:HistoryItem>
</iodef:History> </iodef:History>
</iodef:Incident> </iodef:Incident>
</iodef:IODEF-Document> </iodef:IODEF-Document>
6.2. Investigation Request Communication Flow 7.2. Investigation Request Communication Flow
The diagram below outlines the RID Investigation request The diagram below outlines the RID Investigation request
communication flow between RID systems on different networks for a communication flow between RID systems on different networks for a
security incident with a known source address. The proper response security incident with a known source address. The proper response
to an Investigation request is a Result message. If there is a to an Investigation request is a Result message. If there is a
problem with the request, such as a failure to validate the digital problem with the request, such as a failure to validate the digital
signature or decrypt the request, a RequestAuthorization message is signature or decrypt the request, a RequestAuthorization message is
sent to the requestor. The RequestAuthorization message should sent to the requestor. The RequestAuthorization message should
provide the reason why the message could not be processed. provide the reason why the message could not be processed.
skipping to change at page 46, line 5 skipping to change at page 46, line 5
4. Research 4. Research
incident and incident and
determine appropriate determine appropriate
actions to take actions to take
5. <-------Result-------o 5. <-------Result-------o
Figure 8: Investigation Communication Flow Figure 8: Investigation Communication Flow
6.2.1. Investigation Request Example 7.2.1. Investigation Request Example
The following example only includes the RID-specific details. The The following example only includes the RID-specific details. The
IODEF and security measures are similar to the TraceRequest IODEF and security measures are similar to the TraceRequest
information, with the exception that the source is known and the information, with the exception that the source is known and the
receiving RID system is known to be close to the source. The source receiving RID system is known to be close to the source. The source
known is indicated in the IODEF document, which allows for incident known is indicated in the IODEF document, which allows for incident
sources to be listed as spoofed, if appropriate. sources to be listed as spoofed, if appropriate.
This flow does not include a Result message as the request is denied This flow does not include a Result message as the request is denied
as shown in the RequestAuthorization response. as shown in the RequestAuthorization response.
skipping to change at page 48, line 5 skipping to change at page 48, line 5
CSIRT-FOR-OUR-DOMAIN#208-1 CSIRT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID> </iodef:IncidentID>
<iodef:Description> <iodef:Description>
Investigation request sent to SP for 192.0.2.35 Investigation request sent to SP for 192.0.2.35
</iodef:Description> </iodef:Description>
</iodef:HistoryItem> </iodef:HistoryItem>
</iodef:History> </iodef:History>
</iodef:Incident> </iodef:Incident>
</iodef:IODEF-Document> </iodef:IODEF-Document>
6.2.2. RequestAuthorization Message Example 7.2.2. RequestAuthorization Message Example
The example RequestAuthorization message is in response to the The example RequestAuthorization message is in response to the
Investigation request listed above. The SP that received the request Investigation request listed above. The SP that received the request
was unable to validate the digital signature used to authenticate the was unable to validate the digital signature used to authenticate the
sending RID system. sending RID system.
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="RequestAuthorization" <iodef-rid:RIDPolicy MsgType="RequestAuthorization"
MsgDestination="RIDSystem"> MsgDestination="RIDSystem">
skipping to change at page 48, line 29 skipping to change at page 48, line 29
</iodef:Node> </iodef:Node>
<iodef-rid:TrafficType type="Attack"/> <iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1 CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID> </iodef:IncidentID>
</iodef-rid:RIDPolicy> </iodef-rid:RIDPolicy>
<iodef-rid:RequestStatus AuthorizationStatus="Denied" <iodef-rid:RequestStatus AuthorizationStatus="Denied"
Justification="Authentication"/> Justification="Authentication"/>
</iodef-rid:RID> </iodef-rid:RID>
6.3. Report Communication Flow 7.3. Report Communication Flow
The diagram below outlines the RID Report communication flow between The diagram below outlines the RID Report communication flow between
RID systems on different networks. RID systems on different networks.
SP-1 SP-2 SP-1 SP-2
1. Generate incident information 1. Generate incident information
and prepare Report message and prepare Report message
2. o-------Report-------> 2. o-------Report------->
skipping to change at page 49, line 12 skipping to change at page 49, line 12
incident data, such as the hexadecimal packet and incident class incident data, such as the hexadecimal packet and incident class
information, can be used to compare with existing database entries. information, can be used to compare with existing database entries.
The Report message typically does not have a response. If there is a The Report message typically does not have a response. If there is a
problem with the Report message, such as a failure to validate the problem with the Report message, such as a failure to validate the
digital signature [RFC3275] or decrypt the request, a digital signature [RFC3275] or decrypt the request, a
RequestAuthorization message is sent to the requestor. The RequestAuthorization message is sent to the requestor. The
RequestAuthorization message should provide the reason why the RequestAuthorization message should provide the reason why the
message could not be processed. message could not be processed.
6.3.1. Report Example 7.3.1. Report Example
The following example only includes the RID-specific details. This The following example only includes the RID-specific details. This
report is an unsolicited Report message that includes an IPv4 packet. report is an unsolicited Report message that includes an IPv4 packet.
The IODEF document and digital signature is similar to the The IODEF document and digital signature is similar to the
TraceRequest information. TraceRequest information.
This example is a message sent from SP-1, CERT-FOR-OUR-DOMAIN at This example is a message sent from SP-1, CERT-FOR-OUR-DOMAIN at
192.0.2.67, to SP-2 at 192.0.2.130 for informational purposes on an 192.0.2.67, to SP-2 at 192.0.2.130 for informational purposes on an
attack that took place. attack that took place.
skipping to change at page 51, line 5 skipping to change at page 51, line 5
CSIRT-FOR-OUR-DOMAIN#209-1 CSIRT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID> </iodef:IncidentID>
<iodef:Description> <iodef:Description>
Incident report sent to SP for 192.0.2.35 Incident report sent to SP for 192.0.2.35
</iodef:Description> </iodef:Description>
</iodef:HistoryItem> </iodef:HistoryItem>
</iodef:History> </iodef:History>
</iodef:Incident> </iodef:Incident>
</iodef:IODEF-Document> </iodef:IODEF-Document>
6.4. IncidentQuery Communication Flow 7.4. IncidentQuery Communication Flow
The diagram below outlines the RID IncidentQuery communication flow The diagram below outlines the RID IncidentQuery communication flow
between RID systems on different networks. between RID systems on different networks.
SP-1 SP-2 SP-1 SP-2
1. Generate a request for 1. Generate a request for
information on a specific information on a specific
incident number or incident type incident number or incident type
skipping to change at page 51, line 41 skipping to change at page 51, line 41
Report message. If the Report message is empty, the responding host Report message. If the Report message is empty, the responding host
did not have information available to share with the requestor. The did not have information available to share with the requestor. The
incident number and responding RID system, as well as the transport, incident number and responding RID system, as well as the transport,
assist in the association of the request and response since a report assist in the association of the request and response since a report
can be filed and is not always solicited. If there is a problem with can be filed and is not always solicited. If there is a problem with
the IncidentQuery message, such as a failure to validate the digital the IncidentQuery message, such as a failure to validate the digital
signature or decrypt the request, a RequestAuthorization message is signature or decrypt the request, a RequestAuthorization message is
sent to the requestor. The RequestAuthorization message should sent to the requestor. The RequestAuthorization message should
provide the reason why the message could not be processed. provide the reason why the message could not be processed.
6.4.1. IncidentQuery Example 7.4.1. IncidentQuery Example
The IncidentQuery request may be received in several formats as a The IncidentQuery request may be received in several formats as a
result of the type of query being performed. If the incident number result of the type of query being performed. If the incident number
is the only information provided, the IODEF document and IP packet is the only information provided, the IODEF document and IP packet
data may not be needed to complete the request. However, if a type data may not be needed to complete the request. However, if a type
of incident is requested, the incident number remains NULL, and the of incident is requested, the incident number remains NULL, and the
IP packet data will not be included in the IODEF RecordItem class; IP packet data will not be included in the IODEF RecordItem class;
the other incident information is the main source for comparison. In the other incident information is the main source for comparison. In
the case in which an incident number may not be the same between the case in which an incident number may not be the same between
CSIRTs, the incident number and/or IP packet information can be CSIRTs, the incident number and/or IP packet information can be
skipping to change at page 52, line 27 skipping to change at page 52, line 27
<iodef:Node> <iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address> <iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
</iodef:Node> </iodef:Node>
<iodef-rid:TrafficType type="Attack"/> <iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#210-1 CERT-FOR-OUR-DOMAIN#210-1
</iodef:IncidentID> </iodef:IncidentID>
</iodef-rid:RIDPolicy> </iodef-rid:RIDPolicy>
</iodef-rid:RID> </iodef-rid:RID>
7. RID Schema Definition 8. RID Schema Definition
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1" <xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="urn:ietf:params:xml:ns:iodef-rid-1.1" targetNamespace="urn:ietf:params:xml:ns:iodef-rid-1.1"
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/ schemaLocation="http://www.iana.org/assignments/xml-registry/
skipping to change at page 56, line 20 skipping to change at page 56, line 20
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
<xs:attribute name="ext-type" <xs:attribute name="ext-type"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
<xs:attribute name="restriction" type="iodef:restriction-type"/> <xs:attribute name="restriction" type="iodef:restriction-type"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
8. Security Requirements 9. Security Requirements
8.1. XML Digital Signatures and Encryption 9.1. XML Digital Signatures and Encryption
RID leverages existing security standards and data markings in RID leverages existing security standards and data markings in
RIDPolicy to achieve the required levels of security for the exchange RIDPolicy to achieve the required levels of security for the exchange
of incident information. The use of standards include TLS and the of incident information. The use of standards include TLS and the
XML security features of encryption [XMLencrypt] and digital XML security features of encryption [XMLencrypt] and digital
signatures [RFC3275], [XMLsig]. The standards provide clear methods signatures [RFC3275], [XMLsig]. The standards provide clear methods
to ensure that messages are secure, authenticated, and authorized, to ensure that messages are secure, authenticated, and authorized,
and that the messages meet policy and privacy guidelines and maintain and that the messages meet policy and privacy guidelines and maintain
integrity. integrity.
skipping to change at page 57, line 10 skipping to change at page 57, line 10
maintaining the original RecordItem entry(s) and detached maintaining the original RecordItem entry(s) and detached
signature(s) from the original requestor. It is important to note signature(s) from the original requestor. It is important to note
that the data is signed at the RecordItem level. Since multiple that the data is signed at the RecordItem level. Since multiple
RecordItems may exist within an IODEF document and may originate RecordItems may exist within an IODEF document and may originate
from different sources, the signature is applied at the RecordItem from different sources, the signature is applied at the RecordItem
level to enable the use of an XML detached signature. This level to enable the use of an XML detached signature. This
signature MUST be passed to all recipients of the TraceRequest or signature MUST be passed to all recipients of the TraceRequest or
Investigation request. Investigation request.
o If an Investigation or TraceRequest does not include a RecordItem o If an Investigation or TraceRequest does not include a RecordItem
entry, an NTP timestamp may be used to ensure there is data to be entry, a timestamp MUST be used to ensure there is data to be
signed for the multi-hop authentication use case. signed for the multi-hop authentication use case. The DateTime
element of the IODEF:RecordItem class, [RFC5070] Section3.19.1, is
used for this purpose.
o For all message types, the full IODEF/RID document MUST be signed o For all message types, the full IODEF/RID document MUST be signed
using an enveloped signature by the sending peer to provide using an enveloped signature by the sending peer to provide
authentication and integrity to the receiving RID system. authentication and integrity to the receiving RID system.
o Optionally, nested enveloped signatures MAY be used when o Optionally, nested enveloped signatures MAY be used when
forwarding documents during an investigation. If this option is forwarding documents during an investigation. If this option is
used, the implementation MUST follow the guidance specified in the used, the implementation MUST follow the guidance specified in the
XML Digital Signature [XMLsig] specification for two or more XML Digital Signature [XMLsig] specification for two or more
enveloped signatures. enveloped signatures.
skipping to change at page 58, line 29 skipping to change at page 58, line 31
of the IODEF document or the complete IODEF document. Consortiums of the IODEF document or the complete IODEF document. Consortiums
and organizations should consider this guidance when creating and organizations should consider this guidance when creating
exchange policies. exchange policies.
o Expectations based on restriction setting: o Expectations based on restriction setting:
* If restriction is set to "private", the class or document MUST * If restriction is set to "private", the class or document MUST
be encrypted for the recipient using XML encryption and the be encrypted for the recipient using XML encryption and the
public key of the recipient. The use of PKI between entities public key of the recipient. The use of PKI between entities
SHOULD adhere to any applicable certificate policy and SHOULD adhere to any applicable certificate policy and
practices agreements for the use of RID. practices agreements for the use of RID. [RFC3647] specifies a
commonly used format for certificate policy and certification
practices statements.
* If restriction is set to "need-to-know", the class or document * If restriction is set to "need-to-know", the class or document
MUST be encrypted to ensure only those with need-to-know access MUST be encrypted to ensure only those with need-to-know access
can decrypt the data. The document can either be encrypted for can decrypt the data. The document can either be encrypted for
each individual for which access is intended or a single group each individual for which access is intended or a single group
key may be used. The method used SHOULD adhere to any key may be used. The method used SHOULD adhere to any
certificate policy and practices agreements between entities certificate policy and practices agreements between entities
for the use of RID. A group key in this instance refers to a for the use of RID. A group key in this instance refers to a
single key (symmetric) that is used to encrypt the block of single key (symmetric) that is used to encrypt the block of
data. The users with need-to-know access privileges may be data. The users with need-to-know access privileges may be
skipping to change at page 59, line 24 skipping to change at page 59, line 26
* 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 8.5 and 8.6 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. RID Policy is a
necessary tool for listing the requirements of messages to provide a necessary tool for listing the requirements of messages to provide a
method to categorize data elements for proper handling. Controls are method to categorize data elements for proper handling. Controls are
also provided for the sending entity to protect messages from third also provided for the sending entity to protect messages from third
parties through XML encryption. parties through XML encryption.
RID provides a method to exchange incident handling request and RID provides a method to exchange incident handling request and
Report messages to peer networks. Administrators have the ability to Report messages to peer networks. 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.
8.2. Message Transport 9.2. Message Transport
The transport specifications are fully defined in a separate document The transport specifications are fully defined in a separate document
[RFC6046-bis]. The specified transport protocols MUST use encryption [RFC6046-bis]. The specified transport protocols MUST use encryption
to provide an additional level of security and integrity, while to provide an additional level of security and integrity, while
supporting mutual authentication through bi-directional certificate supporting mutual authentication through bi-directional certificate
usage. Any subsequent transport method defined should take advantage usage. Any subsequent transport method defined should take advantage
of existing standards for ease of implementation and integration of of existing standards for ease of implementation and integration of
RID systems. Session encryption for the transport of RID messages is RID systems. Session encryption for the transport of RID messages is
enforced in the transport specification. The privacy and security enforced in the transport specification. The privacy and security
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 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 are discussed in Section 8.1 of this and considerations for RID messages are discussed in Section 9.1 of
document. this document.
XML security functions such as the digital signature [RFC3275] and
encryption [XMLencrypt] provide a standards-based method to encrypt
and digitally sign RID messages. RID messages specify system use and
privacy guidelines through the RIDPolicy class. A public key
infrastructure (PKI) provides the base for authentication and
authorization, encryption, and digital signatures to establish trust
relationships between members of a RID consortium or a peering
consortium.
XML security functions such as the digital signature [RFC3275] and
encryption [XMLencrypt] can be used within the contents of the
message for privacy and security in cases for which certain elements
must remain encrypted or signed as they traverse the path of a trace.
For example, the digital signature on a TraceRequest can be used to
verify the identity of the trace originator. The use of the XML
security features in RID messaging is in accordance with the
specifications for the IODEF model; however, the use requirements may
differ since RID also incorporates communication of security incident
information.
8.3. Message Delivery Protocol - Integrity and Authentication
The RID protocol must be able to guarantee delivery and meet the The RID protocol must be able to guarantee delivery and meet the
necessary security requirements of a state-of-the-art protocol. In necessary security requirements of a state-of-the-art protocol. In
order to guarantee delivery, TCP should be considered as the order to guarantee delivery, TCP should be considered as the
underlying protocol within the current network standard practices. underlying protocol within the current network standard practices.
Security requirements must include the integrity, authentication, Consortiums may vary their selected transport mechanisms and thus
privacy, and authorization of the messages sent between systems decide upon a mutual protocol to use for transport when communicating
communicating via RID. The communication between RID systems must be with peers in a neighboring consortium using RID. RID systems MUST
authenticated and encrypted to ensure the integrity of the messages implement and deploy HTTPS as defined in the transport document
and the RID systems involved in the trace. Another concern that [RFC6046-bis] and optionally support other protocols such as the
needs to be addressed is authentication for a request that traverses Blocks Extensible Exchange Protocol (BEEP) [RFC3080]. RID, the XML
multiple networks. In this scenario, systems in the path of the security functions, and transport protocols must properly integrate
multi-hop TraceRequest need to authorize a trace from not only their with a public key infrastructure (PKI) managed by the consortium or
neighbor network, but also from the initiating RID system as one managed by a trusted entity. For the Internet, a few of examples
discussed in Section 8.5. Several methods can be used to ensure of existing efforts that could be leveraged to provide the supporting
integrity and privacy of the communication. PKI include the Regional Internet Registry's (RIR's) PKI hierarchy,
vendor issued certificates, or approved issuers of Extended
The transport mechanism selected MUST follow the defined transport Validation (EV) Certificates. Security and privacy considerations
protocol [RFC6046-bis] when using RID messaging to ensure consistency related to consortiums are discussed in Sections 9.4 and 9.5.
among the peers. Consortiums may vary their selected transport
mechanisms and thus must decide upon a mutual protocol to use for
transport when communicating with peers in a neighboring consortium
using RID. RID systems MUST implement and deploy HTTPS as defined in
the transport document [RFC6046-bis] and optionally support other
protocols such as the Blocks Extensible Exchange Protocol (BEEP).
RID, the XML security functions, and transport protocols must
properly integrate with a public key infrastructure (PKI) managed by
the consortium or one managed by a trusted entity. For the Internet,
a few of examples of existing efforts that could be leveraged to
provide the supporting PKI include the American Registry for Internet
Numbers (ARIN) and the Regional Internet Registry's (RIR's) PKI
hierarchy, vendor issued certificates, or approved issuers of
Extended Validation (EV) Certificates. Security and privacy
considerations related to consortiums are discussed in Sections 8.5
and 8.6.
8.4. Transport Communication
Out-of-band communications dedicated to SP interaction for RID
messaging would provide additional security as well as guaranteed
bandwidth during a denial-of-service attack. For example, an out-of-
band channel may consist of logical paths defined over the existing
network. Out-of-band communications may not be practical or possible
between service providers, but provisions should be considered to
protect the incident management systems used for RID messaging.
Methods to protect the data transport may also be provided through
session encryption.
In order to address the integrity and authenticity of messages,
transport encryption MUST be used to secure the traffic sent between
RID systems. Systems with predefined relationships for RID include
those who peer within a consortium with agreed-upon appropriate use
regulations and for peering consortiums. Trust relationships may
also be defined through a bridged or hierarchical PKI in which both
peers belong.
Systems used to send authenticated RID messages between networks MUST Systems used to send authenticated RID messages between networks MUST
use a secured system and interface to connect to a border network's use a secured system and interface to connect to a border network's
RID systems. Each connection to a RID system MUST meet the security RID systems. Each connection to a RID system MUST meet the security
requirements agreed upon through the consortium regulations, peering, requirements agreed upon through the consortium regulations, peering,
or SLAs. The RID system MUST only listen for and send RID messages or SLAs. The RID system MUST only listen for and send RID messages
on the designated port, which also MUST be over an encrypted tunnel on the designated port, which also MUST be over an encrypted tunnel
meeting the minimum requirement of algorithms and key lengths meeting the minimum requirement of algorithms and key lengths
established by the consortium, peering, or SLA. The selected established by the consortium, peering, or SLA. The selected
cryptographic algorithms for symmetric encryption, digital cryptographic algorithms for symmetric encryption, digital
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.
8.5. Authentication of RID Protocol Out-of-band communications dedicated to SP interaction for RID
messaging would provide additional security as well as guaranteed
bandwidth during a denial-of-service attack. For example, an out-of-
band channel may consist of logical paths defined over the existing
network. Out-of-band communications may not be practical or possible
between service providers, but provisions should be considered to
protect the incident management systems used for RID messaging.
Methods to protect the data transport may also be provided through
session encryption.
In order to ensure the authenticity of the RID messages, a message 9.3. Public Key Infrastructure
authentication scheme is used to secure the protocol. XML security
functions utilized in RID require a trust center such as a PKI for
the distribution of credentials to provide the necessary level of
security for this protocol. Layered transport protocols also utilize
encryption and rely on a trust center. Public key certificate pairs
issued by a trusted Certification Authority (CA) MAY be used to
provide the necessary level of authentication and encryption for the
RID protocol. The CA used for RID messaging must be trusted by all
involved parties and may take advantage of similar efforts, such as
the Internet2 federated PKI or the ARIN/RIR effort to provide a PKI
to network providers. The PKI used for authentication also provides
the necessary certificates needed for encryption used for the RID
transport protocol [RFC6046-bis].
The use of pre-shared keys may be considered for authentication. If Systems with predefined relationships for RID include those who peer
this option is selected, the specifications set forth in "Pre-Shared within a consortium with agreed-upon appropriate use regulations and
Key Ciphersuites for Transport Layer Security (TLS)" [RFC4279] MUST for peering consortiums. Trust relationships may also be defined
be followed. through a bridged or hierarchical PKI in which both peers belong.
XML security functions utilized in RID require a trust center such as
a PKI for the distribution of credentials to provide the necessary
level of security for this protocol. Layered transport protocols
also utilize encryption and rely on a trust center. Public key
certificate pairs issued by a trusted Certification Authority (CA)
MAY be used to provide the necessary level of authentication and
encryption for the RID protocol. The CA used for RID messaging must
be trusted by all involved parties and may take advantage of similar
efforts, such as the Internet2 federated PKI or the ARIN/RIR effort
to provide a PKI to network providers. The PKI used for
authentication also provides the necessary certificates needed for
encryption used for the RID transport protocol [RFC6046-bis].
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. The IODEF specification MUST be followed for similar purposes. Full path validation verifies the chaining
digital signatures to provide the authentication and integrity relationship to a trusted root and also performs a certificate
aspects required for secure messaging between network providers. The revocation check. The use of digital signatures in RID XML messages
use of digital signatures in RID XML messages MUST follow the World MUST follow the World Wide Web Consortium (W3C) recommendations for
Wide Web Consortium (W3C) recommendations for signature syntax and signature syntax and processing when either the XML encryption
processing when either the XML encryption [XMLencrypt] or digital [XMLencrypt] or digital signature [XMLsig], [RFC3275] is used within
signature [XMLsig], [RFC3275] is used within a document. Transport a document.
specifications are detailed in a separate document [RFC6046-bis].
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.
8.5.1. Multi-Hop TraceRequest Authentication The use of pre-shared keys may be considered for authentication at
the transport layer. If this option is selected, the specifications
set forth in "Pre-Shared Key Ciphersuites for Transport Layer
Security (TLS)" [RFC4279] MUST be followed. Transport specifications
are detailed in a separate document [RFC6046-bis].
Bilateral trust relations between network providers ensure the 9.3.2. Multi-Hop TraceRequest Authentication
authenticity of requests for TraceRequests from immediate peers in
the web of networks formed to provide the traceback capability. A
network provider several hops into the path of the RID trace must
trust the information from its own trust relationships as well as the
previous trust relationships in the downstream path. The use of
multi-hop authentication in an Investigation request is used when an
Investigation is sent to multiple entities or SPs in an iterative
manner. For practical reasons, the SPs may want to prioritize
incident handling events based upon the immediate peer for a
TraceRequest, the originator of a request, and the listed Confidence
rating for the incident. In order to provide a higher assurance
level of the authenticity of the TraceRequest, the originating RID
system is included in the TraceRequest along with contact information
and the information of all RID systems in the path the trace has
taken. This information is provided through the IODEF EventData
class nesting the list of systems and contacts involved in a trace,
while setting the category attribute to "infrastructure".
A second measure MUST be taken to ensure the identity of the The use of multi-hop authentication in an Investigation request is
originating RID system. The originating RID system MUST include a used when an Investigation is sent to multiple entities or SPs in an
digital signature in the TraceRequest sent to all systems in the iterative manner. Multi-hop authentication is REQUIRED in
upstream path. The digital signature from the RID system is TraceRequests that involve multiple SPs. Bilateral trust
relationships MAY be used between peers, then Multi-hop
authentication MUST be used for cases where the originator of a
message is authenticated several hops into the message flow.
For practical reasons, the SPs may want to prioritize incident
handling events based upon the immediate peer for a TraceRequest, the
originator of a request, and the listed Confidence rating for the
incident. In order to provide a higher assurance level of the
authenticity of the TraceRequest, the originating RID system is
included in the TraceRequest along with contact information and the
information of all RID systems in the path the trace has taken. This
information is provided through the IODEF EventData class nesting the
list of systems and contacts involved in a trace, while setting the
category attribute to "infrastructure".
To provide multi-hop authentication, the originating RID system MUST
include a digital signature in the TraceRequest sent to all systems
in the upstream path. The digital signature from the RID system is
performed on the RecordItem class of the IODEF following the XML performed on the RecordItem class of the IODEF following the XML
digital signature specifications from W3C [XMLsig] using a detached digital signature specifications from W3C [XMLsig] using a detached
signature. The signature MUST be passed to all parties that receive signature. The signature MUST be passed to all parties that receive
a TraceRequest, and each party MUST be able to perform full path a TraceRequest, and each party MUST be able to perform full path
validation on the digital signature [RFC5280]. Full path validation validation on the digital signature [RFC5280]. In order to
verifies the chaining relationship to a trusted root and also accommodate that requirement, the RecordItem data MUST remain
performs a certificate revocation check. In order to accommodate unchanged as a request is passed along between providers and is the
that requirement, the RecordItem data MUST remain unchanged as a only element for which the signature is applied. If additional
request is passed along between providers and is the only element for RecordItems are included in the document at upstream peers, the
which the signature is applied. If additional RecordItems are initial RecordItem entry MUST still remain with the detached
included in the document at upstream peers, the initial RecordItem signature. The subsequent RecordItem elements may be signed by the
entry MUST still remain with the detached signature. The subsequent peer adding the incident information for the investigation. A second
RecordItem elements may be signed by the peer adding the incident benefit to this requirement is that the integrity of the filter used
information for the investigation. A second benefit to this is ensured as it is passed to subsequent SPs in the upstream trace of
requirement is that the integrity of the filter used is ensured as it the incident. The trusted PKI also provides the keys used to
is passed to subsequent SPs in the upstream trace of the incident. digitally sign the RecordItem class for TraceRequest or Investigation
The trusted PKI also provides the keys used to digitally sign the to meet the requirement of authenticating the original request. Any
RecordItem class for TraceRequest or Investigation to meet the host in the path of the trace should be able to verify the digital
requirement of authenticating the original request. Any host in the signature using the trusted PKI.
path of the trace should be able to verify the digital signature
using the trusted PKI.
In the case in which an enterprise network using RID sends a In the case in which an enterprise using RID sends a TraceRequest to
TraceRequest to its provider, the signature from the enterprise its provider, the signature from the enterprise MUST be included in
network MUST be included in the initial request. The SP may generate the initial request. The SP may generate a new request to send
a new request to send upstream to members of the SP consortium to upstream to members of the SP consortium to continue the
continue the investigation. If the original request is sent, the investigation. If the original request is sent, the originating SP,
originating SP, acting on behalf of the enterprise network under acting on behalf of the enterprise network under attack, MUST also
attack, MUST also digitally sign, with an enveloped signature, the digitally sign, with an enveloped signature, the full IODEF document
full IODEF document to assure the authenticity of the TraceRequest. to assure the authenticity of the TraceRequest. An SP that offers
An SP that offers RID as a service may be using its own PKI to secure RID as a service may be using its own PKI to secure RID
RID communications between its RID system and the attached enterprise communications between its RID system and the attached enterprise
networks. SPs participating in the trace MUST be able to determine networks. SPs participating in the trace MUST be able to determine
the authenticity of RID requests. the authenticity of RID requests.
8.6. Consortiums and Public Key Infrastructures 9.4. Consortiums and Public Key Infrastructures
Consortiums of SPs are an ideal way to establish a communication web Consortiums of SPs are an ideal way to establish a communication web
of trust for RID messaging. It should be noted that direct of trust for RID messaging. It should be noted that direct
relationships may be ideal for some communications, such as those relationships may be ideal for some communications, such as those
between a provider of incident information and a subscriber of the between a provider of incident information and a subscriber of the
incident reports. The consortium could provide centralized incident reports. The consortium could provide centralized
resources, such as a PKI, and established guidelines for use of the resources, such as a PKI, and established guidelines for use of the
RID protocol. The consortium may assist in establishing trust RID protocol. The consortium may assist in establishing trust
relationships between the participating SPs to achieve the necessary relationships between the participating SPs to achieve the necessary
level of cooperation and experience-sharing among the consortium level of cooperation and experience-sharing among the consortium
skipping to change at page 64, line 47 skipping to change at page 64, line 4
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 and policy to provide authentication, integrity, and o A PKI, certificate policy, and certification practices statement
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 that 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. The PKI may be a subordinate CA or in customer network) and the SP.
the CA hierarchy from the SP's consortium to establish the trust
relationships necessary as the request is made to other connected
networks.
8.7. Privacy Concerns and System Use Guidelines 9.5. Privacy Concerns and System Use Guidelines
Privacy issues raise many concerns when information-sharing is Privacy issues raise many concerns when information-sharing is
required to achieve the goal of stopping or mitigating the effects of required to achieve the goal of stopping or mitigating the effects of
a security incident. The RIDPolicy class is used to automate the a security incident. The RIDPolicy class is used to automate the
enforcement of the privacy concerns listed within this document. The enforcement of the privacy concerns listed within this document. The
privacy and system use concerns that MUST be addressed in the RID privacy and system use concerns that MUST be addressed in the RID
system and other integrated components include the following: system and other integrated components include the following:
Network Provider Concerns: Network Provider Concerns:
o Privacy of data monitored and/or stored on IDSs for attack o Privacy of data monitored and/or stored on Intrusion Detection
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.
Customer Attached Networks Participating in RID with SP: Customer Attached Networks Participating in RID with SP:
o Customer networks may include an enterprise, educational, o Customer networks may include an enterprise, educational,
government, or other attached networks to an SP participating in government, or other attached networks to an SP participating in
RID and MUST be made fully aware of the security and privacy RID and MUST be made fully aware of the security and privacy
considerations for using RID. considerations for using RID.
o Customers MUST know the security and privacy considerations in o Customers MUST be informed of the security and privacy
place by their SP and the consortium of which the SP is a member. considerations in place by their SP and the consortium of which
the SP is a member.
o Customers MUST understand that their data can and will be sent to o Customers MUST be informed that their data can and will be sent to
other SPs in order to complete a trace unless an agreement stating other SPs in order to complete a trace unless an agreement stating
otherwise is made in the service level agreements between the otherwise is made in the service level agreements between the
customer and SP. customer and SP.
Parties Involved in the Attack: Parties Involved in the Attack:
o Privacy of the identity of a host involved in an attack. o Privacy of the identity of a host involved in an attack.
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
skipping to change at page 66, line 51 skipping to change at page 66, line 4
"AcrossNationalBoundaries" MUST respect national boundary issues "AcrossNationalBoundaries" MUST respect national boundary issues
and limit requests to appropriate system use and not to achieve and limit requests to appropriate system use and not to achieve
their own agenda to limit or restrict traffic that is otherwise their own agenda to limit or restrict traffic that is otherwise
permitted within the country in which the peering consortium permitted within the country in which the peering consortium
resides. 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. Some policies may be facilitated through use of the RIDPolicy class. Some
privacy considerations are addressed through the RID guidelines for privacy considerations are addressed through the RID guidelines for
encryption and digital signatures as described in Section 8.1. encryption and digital signatures as described in Section 9.1.
RID is useful in determining the true source of an incident that RID is useful in determining the true source of an incident that
traverses multiple networks or to communicate security incidents and traverses multiple networks or to communicate security incidents and
automate the response. The information obtained from the automate the response. The information obtained from the
investigation may determine the identity of the source host or the investigation may determine the identity of the source host or the
network provider used by the source of the traffic. It should be network provider used by the source of the traffic. It should be
noted that the trace mechanism used across a single-network provider noted that the trace mechanism used across a single-network provider
may also raise privacy concerns for the clients of the network. may also raise privacy concerns for the clients of the network.
Methods that may raise concern include those that involve storing Methods that may raise concern include those that involve storing
packets for some length of time in order to trace packets after the packets for some length of time in order to trace packets after the
skipping to change at page 69, line 45 skipping to change at page 68, line 47
perform a bi-directional authentication when sending a RID message perform a bi-directional authentication when sending a RID message
and use the public encryption key of the upstream or downstream peer and use the public encryption key of the upstream or downstream peer
to send a message or document over the network. This means that the to send a message or document over the network. This means that the
document is decrypted and re-encrypted at each RID system via TLS document is decrypted and re-encrypted at each RID system via TLS
over the transport protocol [RFC6046-bis]. The RID messages may be over the transport protocol [RFC6046-bis]. The RID messages may be
decrypted at each RID system in order to properly process the request decrypted at each RID system in order to properly process the request
or relay the information. Today's processing power is more than or relay the information. Today's processing power is more than
sufficient to handle the minimal burden of encrypting and decrypting sufficient to handle the minimal burden of encrypting and decrypting
relatively small typical RID messages. relatively small typical RID messages.
9. Security Considerations 10. Security Considerations
RID has many security requirements and considerations built into the RID has many security requirements and considerations built into the
design of the protocol, several of which are described in the design of the protocol, several of which are described in the
Security Requirements section. For a complete view of security, Security Requirements section. For a complete view of security,
considerations include the availability, confidentiality, and considerations include the availability, confidentiality, and
integrity concerns for the transport, storage, and exchange of integrity concerns for the transport, storage, and exchange of
information. information.
Authenticated encrypted tunnels between systems accepting RID Protected tunnels between systems accepting RID communications are
communications are used to provide confidentiality, integrity, used to provide confidentiality, integrity, authenticity, and privacy
authenticity, and privacy for the data at the transport layer. for the data at the transport layer. Encryption and digital
Encryption and digital signatures are also used at the IODEF document signatures are also used at the IODEF document level through RID
level through RID options to provide confidentiality, integrity, options to provide confidentiality, integrity, authenticity, privacy
authenticity, privacy and traceability of the document contents. and traceability of the document contents at the application layer.
Trust relationships are based on consortiums and established trust Trust relationships are based on public key infrastructure (PKI).
relationships of public key infrastructure (PKI) cross-certifications Trust levels can be established in cross-certification processes
of consortiums. Trust levels can be established in cross- where entities compare PKI policies that include the specific
certification processes where entities compare PKI policies that management and handling of an entity's PKI and certificates issued
include the specific management and handling of an entity's PKI and under that policy. [RFC3647] defines an Internet X.509 Public Key
certificates issued under that policy. [RFC3647] defines an Internet Infrastructure Certificate Policy and Certification Practices
X.509 Public Key Infrastructure Certificate Policy and Certification Framework that may be used in the comparison of policies to establish
Practices Framework that may be used in the comparison of policies to trust levels and agreements between entities, an entity and a
establish trust levels and agreements between entities, an entity and consortium, and consortia. The agreements SHOULD consider key
a consortium, and consortia. The agreements SHOULD consider key
management practices including the ability to perform path validation management practices including the ability to perform path validation
on certificates [RFC5280], key distribution techniques [RFC2585], on certificates [RFC5280], key distribution techniques [RFC2585],
Certificate Authority and Registration Authority management Certificate Authority and Registration Authority management
practices. practices.
The agreements between entities SHOULD also include a common The agreements between entities SHOULD also include a common
understanding of the usage of RID security, policy, and privacy understanding of the usage of RID security, policy, and privacy
options discussed in this section. The formality, requirements, and options discussed in this section. The formality, requirements, and
complexity of the agreements for the certificate policy, practices, complexity of the agreements for the certificate policy, practices,
and the use of RID options SHOULD be decided by the entities or and the use of RID options SHOULD be decided by the entities or
consortiums creating those agreements. consortiums creating those agreements.
10. IANA Considerations 11. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
[XMLschema] conforming to a registry mechanism described in [XMLschema] conforming to a registry mechanism described in
[RFC3688]. [RFC3688].
Registration request for the iodef-rid namespace: Registration request for the iodef-rid namespace:
URI: urn:ietf:params:xml:ns:iodef-rid-1.1 URI: urn:ietf:params:xml:ns:iodef-rid-1.1
Registrant Contact: See the "Author's Address" section of this Registrant Contact: See the "Author's Address" section of this
skipping to change at page 71, line 10 skipping to change at page 70, line 12
XML: None. Namespace URIs do not represent an XML specification. XML: None. Namespace URIs do not represent an XML specification.
Registration request for the iodef-rid XML schema: Registration request for the iodef-rid XML schema:
URI: urn:ietf:params:xml:schema:iodef-rid-1.1 URI: urn:ietf:params:xml:schema:iodef-rid-1.1
Registrant Contact: See the "Author's Address" section of this Registrant Contact: See the "Author's Address" section of this
document. document.
XML: See Section 7, "RID Schema Definition", of this document. XML: See Section 8, "RID Schema Definition", of this document.
11. Summary 12. Summary
Security incidents have always been difficult to trace as a result of Security incidents have always been difficult to trace as a result of
the spoofed sources, resource limitations, and bandwidth utilization the spoofed sources, resource limitations, and bandwidth utilization
problems. Incident response is often slow even when the IP address problems. Incident response is often slow even when the IP address
is known to be valid because of the resources required to notify the is known to be valid because of the resources required to notify the
responsible party of the attack and then to stop or mitigate the responsible party of the attack and then to stop or mitigate the
attack traffic. Methods to identify and trace attacks near real time attack traffic. Methods to identify and trace attacks near real time
are essential to thwarting attack attempts. Network providers need are essential to thwarting attack attempts. Network providers need
policies and automated methods to combat the hacker's efforts. SPs policies and automated methods to combat the hacker's efforts. SPs
need automated monitoring and response capabilities to identify and need automated monitoring and response capabilities to identify and
skipping to change at page 71, line 40 skipping to change at page 70, line 42
of flexible IODEF XML-based documents passed between IHSs or RID of flexible IODEF XML-based documents passed between IHSs or RID
systems. A TraceRequest or Investigation request is communicated to systems. A TraceRequest or Investigation request is communicated to
an upstream SP and may result in an upstream trace or in an action to an upstream SP and may result in an upstream trace or in an action to
stop or mitigate the attack traffic. The messages are communicated stop or mitigate the attack traffic. The messages are communicated
among peers with security inherent to the RID messaging scheme among peers with security inherent to the RID messaging scheme
provided through existing standards such as XML encryption and provided through existing standards such as XML encryption and
digital signatures. Policy information is carried in the RID message digital signatures. Policy information is carried in the RID message
itself through the use of the RIDPolicy. RID provides the timely itself through the use of the RIDPolicy. RID provides the timely
communication among SPs, which is essential for incident handling. communication among SPs, which is essential for incident handling.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999. RFC 2585, May 1999.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, Language) XML-Signature Syntax and Processing", RFC 3275,
skipping to change at page 73, line 12 skipping to change at page 72, line 14
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures", W3C Recommendation Second "XML Schema Part 1: Structures", W3C Recommendation Second
Edition, October 2004, Edition, October 2004,
<http://www.w3.org/TR/xmlschema-1/>. <http://www.w3.org/TR/xmlschema-1/>.
[XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E. [XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E.
Simon, "XML-Signature Syntax and Processing", W3C Simon, "XML-Signature Syntax and Processing", W3C
Recommendation Second Edition, June 2008, Recommendation Second Edition, June 2008,
<http://www.w3.org/TR/xmldsig-core/>. <http://www.w3.org/TR/xmldsig-core/>.
12.2. Informative References 13.2. Informative References
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)", selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, March 1996. BCP 6, RFC 1930, March 1996.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
November 2003. November 2003.
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001.
[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
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, March 2011.
Acknowledgements Acknowledgements
Many thanks to colleagues and the Internet community for reviewing Many thanks to colleagues and the Internet community for reviewing
and commenting on the document as well as providing recommendations and commenting on the document as well as providing recommendations
to simplify and secure the protocol: Robert K. Cunningham, Ph.D, to simplify and secure the protocol: Robert K. Cunningham, Ph.D,
Cynthia D. McLain, Dr. William Streilein, Iljitsch van Beijnum, Steve Cynthia D. McLain, Dr. William Streilein, Iljitsch van Beijnum, Steve
Bellovin, Yuri Demchenko, Jean-Francois Morfin, Stephen Northcutt, Bellovin, Yuri Demchenko, Jean-Francois Morfin, Stephen Northcutt,
Jeffrey Schiller, Brian Trammell, Roman Danyliw, Tony Tauber, Sandra Jeffrey Schiller, Brian Trammell, Roman Danyliw, Tony Tauber, Sandra
G. Dykes, Ph.D., Katherine Goodier, Ph.D., Tony Rutkowski, Damir G. Dykes, Ph.D., Katherine Goodier, Ph.D., Tony Rutkowski, Damir
Rajnovic, David Black, and Paul Cichonski. Rajnovic, David Black, and Paul Cichonski.
 End of changes. 120 change blocks. 
383 lines changed or deleted 349 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/