RFC 6545
Real-time Inter-network Defense (RID)
5. IODEF-RID Schema
There are three classes included in the RID extension required to facilitate RID communications. The RequestStatus class is used to indicate the approval status of a Request message; the IncidentSource class is used to report whether or not a source was found and to identify the source host(s) or network(s); and the RIDPolicy class provides information on the agreed-upon policies and specifies the type of communication message being used. The RID schema defines communication-specific metadata to support the exchange of incident information in an IODEF document. The intent in maintaining a separate schema and not using the AdditionalData extension of IODEF is the flexibility of sending messages between RID hosts. Since RID is a separate schema and RID messages include both the RID and IODEF documents, the RID message acts as an envelope in that policy and security defined at the RID message layer are applied to both documents. One reason for maintaining separate schemas is for flexibility, where the RIDPolicy class can be easily extracted for use in the RID message and by the transport protocol. The security requirements of sending incident information between entities include the use of encryption. The RIDPolicy information is not required to be encrypted, so separating out this data from the IODEF XML document removes the need for decrypting and parsing the IODEF document to determine how it should be handled at each RID host. The purpose of the RIDPolicy class is to specify the message type for the receiving host, facilitate the policy needs of RID, and provide routing information in the form of an IP address of the destination RID system. The security requirements and policy guidelines are discussed in Section 9. The policy is defined between RID peers and within or between consortiums. RIDPolicy is meant to be a tool to facilitate the defined policies. This MUST be used in accordance with policy set between clients, peers, consortiums, and/or regions. Security, privacy, and confidentiality MUST be considered as specified in this document.
The RID schema is defined as follows: +------------------+ | RID | +------------------+ | | | ENUM lang |<>---{0..1}----[ RIDPolicy ] | | | |<>---{0..1}----[ RequestStatus ] | | | |<>---{0..1}----[ IncidentSource ] +------------------+ Figure 3: The RID Schema The aggregate classes that constitute the RID schema in the iodef-rid namespace are as follows: RIDPolicy Zero or One. The RIDPolicy class is used by all message types to facilitate policy agreements between peers, consortiums, or federations, as well as to properly route messages. RequestStatus Zero or One. The RequestStatus class is used only in Acknowledgement messages. The message reports back to the CSIRT or SP in the Acknowledgement message to provide status on a Request or if an error or problem occurs with the receipt or processing of a Report, Query, or Result message. IncidentSource Zero or One. The IncidentSource class is used in the Result message only. The IncidentSource provides the information on the identified source host or network of an attack trace or investigation. 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, RIDPolicy MAY be the only class in the RID definition when used by the transport protocol [RFC6546], as that information should be as small as possible and may not be encrypted. The RequestStatus message MUST be able to stand alone without the need for an IODEF document to facilitate the communication, limiting the data transported to the required elements per [RFC6546].
The RID class has one attribute:
lang
One. REQUIRED. ENUM. A valid language code per [RFC5646]
constrained by the definition of "xs:language" inherited from
[XML1.0].
5.1. RIDPolicy Class
The RIDPolicy class facilitates the delivery of RID messages and is
also referenced for transport in the transport document [RFC6546].
The RIDPolicy Class includes the ability to embed an IODEF document
or XML documents that conform to schemas other than IODEF in the
ReportSchema element.
+------------------------+
| RIDPolicy |
+------------------------+
| |
| ENUM restriction |<>-------------[ Node ]
| ENUM MsgType |
| ENUM MsgDestination |<>---{0..1}----[ IncidentID ]
| ENUM ext-MsgType |
| ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ]
| |
| |<>---{1..*}----[ TrafficType ]
| |
| |<>---{0..1}----[ ReportSchema ]
+------------------------+
Figure 4: The RIDPolicy Class
The aggregate elements that constitute the RIDPolicy class are as
follows:
Node
One. The Node class is used to identify a host or network device,
in this case to identify the system communicating RID messages,
and the usage is determined by the MsgDestination attribute. The
base definition of this class is reused from the IODEF
specification [RFC5070], Section 3.16. See Section 11 of this
document for Internationalization considerations.
IncidentID
Zero or one. Global reference pointing back to the IncidentID
defined in the IODEF data model. The IncidentID includes the name
of the CSIRT, an incident number, and an instance of that
incident. The instance number is appended with a dash separating
the values and is used in cases for which it may be desirable to
group incidents. Examples of incidents that may be grouped
include botnets, polymorphic attacks, DDoS attacks, multiple hops
of compromised systems found during an investigation, etc.
PolicyRegion
One or many. REQUIRED. The values for the attribute "region" are
used to determine what policy area may require consideration
before a trace can be approved. The PolicyRegion may include
multiple selections from the attribute list in order to fit all
possible policy considerations when crossing regions, consortiums,
or networks.
region
One or many. REQUIRED. ENUM. The attribute region is used to
identify the expected sharing range of the incident information.
The region may be within a region or defined by existing
relationships such as those of a consortium or a client to a
service provider.
1. ClientToSP. A client initiated the request to their service
provider (SP). A client may be an individual, enterprise, or
other type of entity (government, commercial, education,
etc.). An SP may be a network, telecommunications,
infrastructure, or other type of SP where a client-to-vendor
relationship has been established. The client-to-vendor
relationship will typically have established contracts or
agreements to define expectations and trust relationships.
2. SPToClient. An SP initiated a RID request or report to a
client. A client may be an individual, enterprise, or other
type of entity (government, commercial, education, etc.). An
SP may be a network, telecommunications, infrastructure, or
other type of SP where a client-to-vendor relationship has
been established. The client-to-vendor relationship will
typically have established contracts or agreements to define
expectations and trust relationships.
3. IntraConsortium. Incident information that should have no
restrictions within the boundaries of a consortium with the
agreed-upon use and abuse guidelines. A consortium is a well-
defined group with established members and trust relationships
specific to sharing within that group. A consortium would
typically define the types of data that can be shared in
advance, define the expectations on protecting that data, as
well as have established contractual agreements. Examples of
consortiums may include industry-focused sharing communities
(financial, government, research and education, etc.) or cross
industry sharing communities (for instance, organizations
within local proximity that form a sharing group).
4. PeerToPeer. Incident information that should have no
restrictions between two peers but may require further
evaluation before continuance beyond that point with the
agreed-upon use and abuse guidelines. PeerToPeer
communications may involve any two individuals or entities
that decide to share information directly with each other.
5. BetweenConsortiums. Incident information that should have no
restrictions between consortiums that have established agreed-
upon use and abuse guidelines. BetweenConsortiums is used
when two consortiums (as defined in IntraConsortium above)
share data. The types of data that can be shared
BetweenConsortiums should be identified in their agreements
and contracts along with expectations on how that data should
be handled and protected.
6. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1.
TrafficType
One or many. REQUIRED. The values for the attribute "type" are
meant to assist in determining if a trace is appropriate for the
SP receiving the request to continue the trace. Multiple values
may be selected for this element; however, where possible, it
should be restricted to one value that most accurately describes
the traffic type.
type
One or many. REQUIRED. ENUM. The attribute type is used to
identify the type of information included in the RID message or
the type of incident.
1. Attack. This option SHOULD only be selected if the traffic is
related to an information security incident or attack. The
type of attack MUST also be listed in more detail in the IODEF
Method and Impact classes for further clarification to assist
in determining if the trace can be continued ([RFC5070],
Sections 3.9 and 3.10.1).
2. Network. This option MUST only be selected when the trace is
related to network traffic or routing issues.
3. Content. This category MUST be used only in the case in which
the request is related to the content and regional
restrictions on accessing that type of content exist. This is
not malicious traffic but may be used for determining what
sources or destinations accessed certain materials available
on the Internet, including, but not limited to, news,
technology, or inappropriate content.
4. DataWithHandlingRequirements. This option is used when data
shared may have additional restrictions for handling,
protection, and processing based on the type of data and where
it resides. Regulatory or legal restrictions may be imposed
on specific types of data that could vary based on the
location, region or nation, of the data or where it
originated. The IODEF document, as well as any extensions,
included with the RID message should indicate the specific
restrictions to be considered. The use of this enumeration
flag is not legally binding.
5. AudienceRestriction. This option is used to indicate that the
message contains data that should be viewed by a restricted
audience. This setting should not be used for normal
incidents or reporting as it could slow response times. The
content may be a business-relevant notification or request.
This option MAY be used by a business partner to report or
request assistance if an incident has affected a supply chain.
This option may also be used if the content is relevant to
regulatory obligations, legal (eDiscovery), or other use cases
that require management attention.
6. Other. If this option is selected, a description of the
traffic type MUST be provided so that policy decisions can be
made to continue or stop the investigation. The information
should be provided in the IODEF message in the Expectation
class or in the History class using a HistoryItem log. This
may also be used for incident types other than information-
security-related incidents.
7. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1.
ReportSchema
Zero or One. The ReportSchema class is used by the message
types that require the full IODEF schema to be included in the
RID envelope. Alternate schemas may be included if approved by
the Designated Reviewer and registered by IANA for use with
RID.
The RIDPolicy class has five attributes:
restriction
OPTIONAL. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient to adhere.
This guideline provides no real security since it is the choice
of the recipient of the document to honor it. This attribute
follows the same guidelines as "restriction" used in IODEF.
MsgType
One. REQUIRED. ENUM. The type of RID message sent. The five
types of messages are described in Section 4.2 and can be noted
as one of the six selections below, where a Request is set to
either 'InvestigationRequest' or 'TraceRequest'.
1. TraceRequest. This Request message may be used to initiate
a TraceRequest or to continue a TraceRequest to an upstream
network closer to the source address of the origin of the
security incident.
2. Acknowledgement. This message is sent to the initiating
RID system from each of the upstream RID systems to provide
information on the request status in the current network.
3. Result. This message indicates that the source of the
attack was located, and the message is sent to the
initiating RID system through the RID systems in the path
of the trace.
4. InvestigationRequest. This Request message type is used
when the source of the traffic is believed to be valid.
The purpose of the InvestigationRequest is to leverage the
existing peer or consortium relationships in order to
notify the SP closest to the source of the valid traffic
that some event occurred, which may be a security-related
incident.
5. Report. This message is used to report a security incident
for which no action is requested in the IODEF Expectation
class. This may be used for the purpose of correlating
attack information by CSIRTs, gathering statistics and
trending information, etc.
6. Query. This message is used to request information from a
trusted RID system about an incident or incident type.
Additionally, there is an extension attribute to add new
enumerated values:
ext-value. An escape value used to extend this attribute. See
IODEF [RFC5070], Section 5.1.
MsgDestination
One. REQUIRED. ENUM. The destination required at this level
may either be the RID messaging system intended to receive the
request, or, in the case of a Request with MsgType set to
'InvestigationRequest', the source of the incident. In the
case of an InvestigationRequest, the RID system that can help
stop or mitigate the traffic may not be known, and the message
may have to traverse RID messaging systems by following the
routing path to the RID system closest to the source of the
attack traffic. The Node element lists either the RID system
or the IP address of the source, and the meaning of the value
in the Node element is determined by the MsgDestination
element.
1. RIDSystem. The IP address of the next upstream system
accepting RID communications is REQUIRED and is listed in
the Node element of the RIDPolicy class. If NodeName
element of the Node class is used, it contains a DNS domain
name. The originating RID system is required to check that
this domain name resolves to the IP address to which the
RID message is sent. This check may be performed in
advance of sending the message and the result saved for
future use with additional RID messages.
2. SourceOfIncident. The Address element of the Node element
contains the IP address of the incident source, and the
NodeName element of the Node class is not used. The IP
address is REQUIRED when this option is selected. The IP
address is used to determine the path of systems accepting
RID communications that will be used to find the closest
RID system to the source of an attack in which the IP
address used by the source is believed to be valid and a
Request message with MsgDestination set to
'InvestigationRequest' is used. This is not to be confused
with the IncidentSource class, as the defined value here is
from an initial Request ('InvestigationRequest' or
'TraceRequest'), not the source used in a Result message.
3. ext-value. An escape value used to extend this attribute.
All extensions shall specify the contents and meaning of
the Node element of RIDPolicy. See IODEF [RFC5070],
Section 5.1, on extensibility. If the NodeName element of
the Node class is used by an extension, NodeName may
contain an Internationalized Domain Name (IDN); see
Section 11 for applicable requirements. All extensions
SHOULD use an IP address in the Address element of the Node
class as the primary means of Node identification.
MsgType-ext
OPTIONAL. STRING. A means by which to extend the MsgType
attribute. See IODEF [RFC5070], Section 5.1.
MsgDestination-ext
OPTIONAL. STRING. A means by which to extend the
MsgDestination attribute. See IODEF [RFC5070], Section 5.1
5.1.1. ReportSchema
The ReportSchema class is an aggregate class in the RIDPolicy class.
The IODEF schema is the approved schema for inclusion in RID messages
via the ReportSchema class.
+-------------------------+ | ReportSchema | +-------------------------+ | | | ENUM Version | | STRING ext-Version |<>---{1}-------[ XMLDocument ] | ENUM XMLSchemaID | | STRING ext-XMLSchemaID |<>---{0..1}----[ URL ] | | | |<>---{0..*}----[ Signature ] | | +-------------------------+ Figure 5: The ReportSchema Class The elements that constitute the ReportSchema class are as follows: XMLDocument One. The XMLDocument is a complete XML document defined by the iodef:ExtensionType class. This class follows the guidelines in [RFC5070], Section 5, where the data type is set to 'xml' and meaning is set to 'xml' to include an XML document. URL Zero or One. URL. A reference to the XML schema of the XML document included. The URL data type is defined in [RFC5070], Section 2.15, as "xs:anyURI" in the schema. The schemaLocation for IODEF is already included in the RID schema, so this is not necessary to include a URL for IODEF documents. The list of registered schemas for inclusion will be maintained by IANA. Signature Zero to many. The Signature uses the iodef:ExtensionType class to enable this element to contain a detached or enveloped signature. This class follows the guidelines in [RFC5070] Section 5 where the data type is set to 'xml' and meaning is set to 'xml' to include an XML document. This element is used to encapsulate the detached signature based on the iodef: RecordItem class within the IODEF document to verify the originator of the message or to include the enveloped signature. If other schemas are used instead of IODEF, they MUST provide guidance on what class to use if a detached signature is provided for this purpose.
The ReportSchema class has four attributes:
Version
OPTIONAL. One. The Version attribute is the version number of
the specified XML schema. That schema must be an approved
version of IODEF or a schema registered with IANA for use with
RID. The IANA registry for managing schemas other than IODEF
is specified in Section 12.
ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1.
ext-Version
OPTIONAL. One. The ext-Version attribute is the version
number of the included XML schema. This attribute is used if a
schema other than IODEF or an IANA-registered schema that has
been added to the enumerated list for Version is included.
XMLSchemaID
OPTIONAL. One. The XMLSchemaID attribute is the identifier,
the defined namespace [XMLNames], of the XML schema of the XML
document included. The XMLSchemaID and Version specify the
format of the XMLDocument element. The only permitted values,
include the namespace for IODEF [RFC5070],
"urn:ietf:params:xml:ns:iodef-1.0", any future IETF-approved
versions of IODEF, and any namespace included in the IANA-
managed list of registered schemas for use with RID. The IANA
registry for managing schemas other than IODEF is specified in
Section 12.
ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1.
ext-XMLSchemaID
OPTIONAL. One. The ext-XMLSchemaID attribute is the
identifier (defined namespace) of the XML schema of the XML
document included. The ext-XMLSchemaID and ext-Version specify
the format of the XMLDocument element and are used if the
included schema is not IODEF version 1.0 or an IANA-registered
schema that has been added to the enumerated list for
XMLSchemaID.
5.2. RequestStatus
The RequestStatus class is an aggregate class in the RID class. +--------------------------------+ | RequestStatus | +--------------------------------+ | | | ENUM restriction | | ENUM AuthorizationStatus | | ENUM Justification | | STRING ext-AuthorizationStatus | | STRING ext-Justification | | | +--------------------------------+ Figure 6: The RequestStatus Class The RequestStatus class has five attributes: restriction OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF. AuthorizationStatus One. REQUIRED. ENUM. The listed values are used to provide a response to the requesting CSIRT of the status of a Request, Report, or Query. 1. Approved. The trace was approved and will begin in the current SP. 2. Denied. The trace was denied in the current SP. The next closest SP can use this message to filter traffic from the upstream SP using the example packet to help mitigate the effects of the attack as close to the source as possible. The Acknowledgement message must be passed back to the originator and a Result message must be used from the closest SP to the source in order to indicate actions taken in the IODEF History class.
3. Pending. Awaiting approval; a timeout period has been
reached, which resulted in this Pending status and
Acknowledgement message being generated.
4. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1.
Justification
OPTIONAL. ENUM. Provides a reason for a Denied or Pending
message.
1. SystemResource. A resource issue exists on the systems
that would be involved in the request.
2. Authentication. The enveloped digital signature
[RFC3275] failed to validate.
3. AuthenticationOrigin. The detached digital signature
for the original requestor on the RecordItem entry
failed to validate.
4. Encryption. The recipient was unable to decrypt the
request, report, or query.
5. UnrecognizedFormat. The format of the provided document
was unrecognized.
6. CannotProcess. The document could not be processed.
Reasons may include legal or policy decisions.
Resolution may require communication outside of this
protocol to resolve legal or policy issues. No further
messages SHOULD be sent until resolved.
7. Other. There were other reasons this request could not
be processed.
8. ext-value. An escape value used to extend this
attribute. See IODEF [RFC5070], Section 5.1.
AuthorizationStatus-ext
OPTIONAL. STRING. A means by which to extend the
AuthorizationStatus attribute. See IODEF [RFC5070], Section
5.1.
Justification-ext
OPTIONAL. STRING. A means by which to extend the
Justification attribute. See IODEF [RFC5070], Section 5.1.
5.3. IncidentSource
The IncidentSource class is an aggregate class in the RID class.
+-------------------+
| IncidentSource |
+-------------------+
| |
| ENUM restriction |
| |<>-------------[ SourceFound ]
| |
| |<>---{0..*}----[ Node ]
| |
+-------------------+
Figure 7: The IncidentSource Class
The elements that constitute the IncidentSource class follow:
SourceFound
One. BOOLEAN. The Source class indicates if a source was
identified. If the source was identified, it is listed in the
Node element of this class.
True. Source of incident was identified.
False. Source of incident was not identified.
Node
Zero or many. The Node class is used to identify a system
identified as part of an incident. If this element is used,
the Address element of the Node element MUST contain the IP
address of the system. If the NodeName element of the Node
class is used, it contains a DNS domain name that has been
checked to ensure that it resolved to that IP address when the
check was performed. See Section 11 of this document for
internationalization considerations for NodeName. The base
definition of this class from the IODEF ([RFC5070], Section
3.16) can be expanded to include other identifiers.
The IncidentSource class has one attribute:
restriction
OPTIONAL. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient to
adhere.This guideline provides no real security since it is the
choice of the recipient of the document to honor it. This
attribute follows the same guidelines as "restriction" used in
IODEF.
5.4. RID Name Spaces
The RID schema declares a namespace of
"urn:ietf:params:xml:ns:iodef-rid-2.0" and registers it per
[RFC3688]. Each IODEF-RID document MUST use the "iodef-rid-2.0"
namespace in the top-level element RID-Document. It can be
referenced as follows:
<RID-Document version="2.0" lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0.xsd">
5.5. Encoding
RID documents MUST begin with an XML declaration and MUST specify the
XML version used; also, the use of UTF-8 encoding is REQUIRED
([RFC3470], Section 4.4). RID conforms to all XML data encoding
conventions and constraints.
The XML declaration with no character encoding will read as follows:
<?xml version="1.0" encoding="UTF-8"?>
The following characters have special meaning in XML and MUST be
escaped with their entity reference equivalent: "&", "<", ">", "\""
(double quotation mark), and "'" (apostrophe). These entity
references are "&", "<", ">", """, and "'",
respectively.
5.6. Including IODEF or Other XML Documents
In order to support the changing activity of CSIRTS, the RID schema
can include an IODEF or other data model. The IODEF is also
extensible, enabling the schemas to evolve along with the needs of
CSIRTs. This section discusses how to include the IODEF XML document
or other XML documents to leverage the security and trust
relationships established through the use of RID. These techniques
are designed so that adding new data will not require a change to the
RID schema. This approach also supports the exchange of private XML
documents relevant only to a closed consortium. XML documents can be
included through the ReportSchema class in the RIDPolicy class. The
XMLDocument attribute is set to 'xml' to allow for the inclusion of
full IODEF or other XML documents. The following guidelines MUST be
followed:
1. The included schema MUST define a separate namespace, such as the
declared namespace for IODEF of
"urn:ietf:params:xml:ns:iodef-1.0".
2. When a parser encounters an included XML document it does not
understand, the included document MUST be ignored (and not
processed), but the remainder of the document MUST be processed.
Parsers will be able to identify the XML documents for which they
have no processing logic through the namespace declaration.
Parsers that encounter an unrecognized element in a namespace
that they do support SHOULD reject the document as a syntax
error.
3. Implementations SHOULD NOT download schemas at runtime due to the
security implications, and included documents MUST NOT be
required to provide a resolvable location of their schema.
The examples included in Section 7 demonstrate how an IODEF document
is included. The included schema of IODEF is represented in
ReportSchema as follows:
Version: "1.0"
XMLSchemaID: "urn:ietf:params:xml:ns:iodef-1.0"
URL: "http://www.iana.org/assignments/xml-registry/schema/
iodef-1.0.xsd"
The URL is optionally included for IODEF since it is already in the
RID schema, and the schemaLocation is defined.
5.6.1. Including XML Documents in RID
XML schemas may be registered for inclusion in a RID message. This
may include schemas other than IODEF or updated versions of IODEF.
The registered IANA information for additional schemas MUST include
the specification name, version, specification Uniform Resource
Identifier (URI), and namespace. The following provides an example
of the necessary information for additional schemas beyond IODEF.
Example Name (XXXX)
Schema Name: XXXX_1.1
Version: 1.1
Namespace: <registered namespace>
Specification URI: http://www.example.com/XXXX
The version attribute of the ReportSchema class is populated with the
approved versions of IODEF or any additional schemas registered by
IANA; see Section 12.
The XMLSchemaID of the ReportSchema class is populated with the
namespace of the included schema. The attribute enumeration values
include the namespace for IODEF and any schema registered by IANA;
see Section 12.
The URL element of the ReportSchema class is populated with the
Specification URI value of the included schema.
6. RID Messages
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
documents to facilitate RID communications. Each message type varies
slightly in format and purpose; hence, the requirements vary and are
specified for each. All classes, elements, attributes, etc., that
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
RID as listed for each message type. The IODEF model MUST be fully
implemented for RID messages that include IODEF payloads to ensure
proper parsing of those messages.
Note: The implementation of RID may automate the ability to fill in
the content required for each message type from packet input,
incident data, situational awareness information, or default values
such as those used in the EventData class.
6.1. Request
Description: This message type is used to request assistance in a
computer security investigation. The investigation request may be
directed to another party that can assist with forensics and continue
the investigation (the incident may have originated on the SP network
to which the Request was sent), or it may be directed to an SP to
trace the traffic from an unknown source. The Request message with
MsgType set to 'InvestigationRequest' may leverage the existing
bilateral peer relationships in order to notify the SP closest to the
source of the valid traffic that some event occurred, which may be a
security-related incident. A Request message with the MsgType set to
'TraceRequest' may be sent to an upstream peer to trace back through
the network to locate the source of malicious traffic. The following
information is REQUIRED for Request messages and is provided through
the following data structures:
RID Information:
RIDPolicy
RID message type, IncidentID, and destination policy
information
IODEF Information:
Timestamps (DetectTime, StartTime, EndTime, ReportTime).
Incident Identifier (Incident class, IncidentID).
Confidence rating of security incident (Impact and Confidence
class).
System class is used to list both the Source and Destination.
Expectation class should be used to request any specific actions
to be taken close to the source.
Path information of nested RID systems, beginning with the request
originator used in the trace using IODEF EventData with category
set to 'infrastructure'.
Event, Record, and RecordItem classes to include example packets
and other information related to the incident. Note: Event
information included here requires a second instance of EventData
in addition to that used to convey SP path contact information.
Standards for encryption and digital signatures [RFC3275] [XMLsig]
[XMLencrypt]:
Digital signature from initiating CSIRT or provider system sending
the RID message, passed to all systems receiving the Request using
a detached XML digital signature on a RecordItem entry, placed in
an instance of the Signature element.
Digital signature of sending CSIRT or SP for authenticity of the
RID message, from the CSIRT or provider creating this message
using an enveloped XML digital signature on the IODEF document,
placed in an instance of the Signature element.
XML encryption as required by policy, agreements, and data
markers.
Security requirements include the ability to encrypt [XMLencrypt] the
contents of the Request message using the public key of the
destination RID system. The incident number increases whether the
Request message has the MsgDestination set to 'InvestigationRequest'
or 'TraceRequest' in order to ensure uniqueness within the system.
The relaying peers also append their Autonomous System (AS) or RID
system information using the path information as the Request message
was relayed through SPs. This enables the response (Result message)
to utilize the same path and trust relationships for the return
message, indicating any actions taken. The request is recorded in
the state tables of both the initiating and destination SP RID
systems. The destination SP is responsible for any actions taken as
a result of the request in adherence to any service level agreements
or policies. The SP MUST confirm that the traffic actually
originated from the suspected system before taking any action and
confirm the reason for the request. The request may be sent directly
to a known RID system or routed by the source address of the attack
using the MsgDestination of RIDPolicy set to 'SourceOfIncident'.
Note: Any intermediate parties in a TraceRequest MUST be able to view
RIDPolicy information of responding message types in order to
properly direct RID messages.
A DDoS attack can have many sources, resulting in multiple traces to
locate the sources of the attack. It may be valid to continue
multiple traces for a single attack. The path information enables
the administrators to determine if the exact trace already passed
through a single network. The Incident Identifier must also be used
to identify multiple Requests from a single incident. If a single
Request results in divergent paths of Requests, a separate instance
number MUST be used under the same IncidentID. The IncidentID
instance number of IODEF can be used to correlate related incident
data that is part of a larger incident.
6.2. Acknowledgement
Description: The Acknowledgement is also used to provide a status to
any message type and to provide a Justification if the message could
not be processed for any reason. This message is sent to the
initiating RID system from the next upstream provider's application
or system designated for accepting RID communications to provide
information on the request status in the current SP.
The following information is REQUIRED for Acknowledgement messages
and is provided through the following data structures:
RID Information:
RIDPolicy
RID message type, IncidentID, and destination policy
information
RequestStatus class:
Status of Request
Standards for encryption and digital signatures [RFC3275], [XMLsig],
[XMLencrypt]:
Digital signature of responding CSIRT or provider for authenticity
of Trace Status Message, from the CSIRT or provider creating this
message using an enveloped XML digital signature.
XML encryption as required by policy, agreements, and data
markers.
A message is sent back to the initiating CSIRT or provider's system;
it accepts RID communications of the trace as status notification.
This message verifies that the next RID system in the path has
received the message from the previous system in the path. This
message also verifies that the trace is now continuing, has stopped,
or is pending in the next upstream CSIRT or provider's RID system.
The Pending status is automatically generated after a 2-minute
timeout without system-predefined or administrator action to approve
or disapprove the trace continuance. If a Request is denied, the
originator and sending peer (if they are not the same) MUST both
receive the message. This provides the sending peer with the option
to take action to stop or mitigate the traffic as close to the source
as possible.
6.3. Result
Description: This message indicates that the trace or investigation
has been completed and provides the result. The Result message
includes information on whether or not a source was found, and the
source information is provided through the IncidentSource class. The
Result information MUST go back to the originating RID system that
began the investigation or trace. A provider may use any number of
incident-handling data sources to ascertain the true source of an
attack. All of the possible information sources may or may not be
readily tied into the RID communications system.
The following information is REQUIRED for Result messages and will be
provided through the following data structures:
RID Information:
RIDPolicy
RID message type, IncidentID, and destination policy
information
Incident Source
The IncidentSource class of the RID schema is used to note
if a source was identified and provide the source
address(es) or other Node information.
IODEF Information:
Timestamps (DetectTime, StartTime, EndTime, ReportTime).
Incident Identifier (Incident class, IncidentID).
Trace number is used for multiple traces of a single
incident; it MUST be included if the response is specific to
an instance of an incident.
Confidence rating of security incident (Impact and Confidence
class).
System class is used to list both the Source and Destination
Information used in the attack and must note if the traffic is
spoofed, thus requiring in RID an upstream Request set to
'TraceRequest'.
History class "atype" attribute is used to note any actions
taken.
History class also notes any other background information
including notes about the Confidence level or rating of the
result information.
Path information of nested RID systems, beginning with the
request originator used in the trace using IODEF EventData with
category set to 'infrastructure'. The last SP listed is the SP
that located the source of the traffic (the provider sending
the Result message).
Event, Record, and RecordItem classes to include example
packets and other information related to the incident
(optional). Note: Event information included here requires a
second instance of EventData in addition to that used to convey
SP path contact information.
Standards for encryption and digital signatures [RFC3275],
[XMLsig], [XMLencrypt]:
Digital signature of source CSIRT or provider for authenticity
of Result message, from the CSIRT or provider creating this
message using an enveloped XML digital signature.
XML encryption as required by policy, agreements, and data
markers.
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
actual source information may or may not be included, depending on
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
a trace should be included. The SP may be able to automate the
adjustment of filters at their border router to block outbound access
for the machine(s) discovered as a part of the attack. The filters
may be comprehensive and block all Internet access until the host has
taken the appropriate action to resolve any security issues. The SP
may be limited in their options for filtering due to agreements or
other restrictions resulting in less comprehensive filters, such as
rate-limiting the ingress traffic as close to the source as possible.
Security and privacy requirements discussed in Section 9 MUST be
taken into account.
Note: The History class has been expanded in IODEF to accommodate all
of the possible actions taken as a result of a RID Request using the
"iodef:atype", or action type, attribute. The History class should
be used to note all actions taken close to the source of a trace or
incident using the most appropriate option for the type of action
along with a description. The "atype" attribute in the Expectation
class can also be used to request an appropriate action when a
Request is made.
6.4. Report
Description: This message or document is sent to a RID system to
provide a report of a security incident. This message does not
require any actions to be taken, except to file the report on the
receiving RID system or associated database.
The following information is REQUIRED for Report messages and will be
provided through the following data structures:
RID Information:
RIDPolicy RID message type, IncidentID, and destination policy
information
The following data is RECOMMENDED if available and can be provided
through the following data structures:
IODEF Information:
Timestamps (DetectTime, StartTime, EndTime, ReportTime).
Incident Identifier (Incident class, IncidentID).
Trace number is used for multiple traces of a single
incident; it MUST be included if the Report is specific to
an instance of an incident.
Confidence rating of security incident (Impact and Confidence
class).
System class is used to list both the Source and Destination
Information used in the attack.
Event, Record, and RecordItem classes are used to include
example packets and other information related to the incident
(optional).
Standards for encryption and digital signatures [RFC3275],
[XMLsig], [XMLencrypt]:
Digital signature from initiating RID system, passed to all
systems receiving the report using an enveloped XML digital
signature, placed in an instance of the Signature element.
XML encryption as required by policy, agreements, and data
markers.
Security requirements include the ability to encrypt [XMLencrypt] the
contents of the Report message using the public key of the
destination RID system. Senders of a Report message should note that
the information may be used to correlate security incident
information for the purpose of trending, pattern detection, etc., and
may be shared with other parties unless otherwise agreed upon with
the receiving RID system. Therefore, sending parties of a Report
message may obfuscate or remove destination addresses or other sensitive information before sending a Report message. A Report message may be sent either to file an incident report or to respond to a Query, and data sensitivity must be considered in both cases. The SP path information is not necessary for this message, as it will be communicated directly between two trusted RID systems.6.5. Query
Description: The Query message is used to request incident information from a trusted RID system. The request can include the incident number, if known, or detailed information about the incident. If the incident number is known, the Report message containing the incident information can easily be returned to the trusted requestor using automated methods. If an example packet or other unique information is included in the Query, the return report may be automated; otherwise, analyst intervention may be required. The following information is REQUIRED for a Query message and is provided through the following data structures: RID Information: RIDPolicy RID message type, IncidentID, and destination policy information IODEF Information (optional): Timestamps (DetectTime, StartTime, EndTime, ReportTime). Incident Identifier (Incident class, IncidentID). Trace number is used for multiple traces of a single incident; it MUST be included if the Query is an instance of an incident. Confidence rating of security incident (Impact and Confidence class). System class is used to list both the Source and Destination Information used in the attack. Event, Record, and RecordItem classes are used to include example packets and other information related to the incident (optional).
Standards for encryption and digital signatures [RFC3275],
[XMLsig], [XMLencrypt]:
Digital signature from the CSIRT or SP initiating the RID
message, passed to all systems receiving the Query using an
enveloped XML digital signature, placed in an instance of the
Signature element.
XML encryption as required by policy, agreements, and data
markers.
The proper response to the Query message is a Report message.
Multiple incidents may be returned for a single query if an incident
type is requested. In this case, the receiving system sends an IODEF
document containing multiple incidents or all instances of an
incident. The system sending the reply may preset a limit to the
number of documents returned in one report. The recommended limit is
5, to prevent the documents from becoming too large. Other transfer
methods may be better suited than RID for large transfers of data.
The Confidence rating may be used in the Query message to select only
incidents with an equal or higher Confidence rating than 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 incident.
Source and Destination Information may not be needed if the Query is
intended to gather data about a specific type of incident.
(page 39 continued on part 3)
