Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6545

Real-time Inter-network Defense (RID)

Pages: 84
Proposed Standard
Errata
Obsoletes:  6045
Part 1 of 4 – Pages 1 to 15
None   None   Next

Top   ToC   RFC6545 - Page 1
Internet Engineering Task Force (IETF)                       K. Moriarty
Request for Comments: 6545                                           EMC
Obsoletes: 6045                                               April 2012
Category: Standards Track
ISSN: 2070-1721


                 Real-time Inter-network Defense (RID)

Abstract

Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident-handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident-handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC 6045. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6545.
Top   ToC   RFC6545 - Page 2
Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

1. Introduction ....................................................3 1.1. Changes from RFC 6045 ......................................5 1.2. Normative and Informative ..................................6 1.3. Terminology ................................................7 2. Characteristics of Incidents ....................................7 3. Communication between CSIRTs and Service Providers ..............8 3.1. Inter-Service-Provider RID Messaging ......................10 3.2. RID Communication Topology ................................12 4. Message Formats ................................................13 4.1. RID Data Types ............................................13 4.1.1. Boolean ............................................13 4.2. RID Message Types .........................................14 5. IODEF-RID Schema ...............................................15 5.1. RIDPolicy Class ...........................................17 5.1.1. ReportSchema .......................................23 5.2. RequestStatus .............................................26 5.3. IncidentSource ............................................28 5.4. RID Name Spaces ...........................................29 5.5. Encoding ..................................................29 5.6. Including IODEF or Other XML Documents ....................29 5.6.1. Including XML Documents in RID .....................30 6. RID Messages ...................................................31 6.1. Request ...................................................31 6.2. Acknowledgement ...........................................33 6.3. Result ....................................................34 6.4. Report ....................................................36 6.5. Query .....................................................38 7. RID Communication Exchanges ....................................39 7.1. Upstream Trace Communication Flow .........................40 7.1.1. RID TraceRequest Example ...........................43 7.1.2. Acknowledgement Message Example ....................47
Top   ToC   RFC6545 - Page 3
           7.1.3. Result Message Example .............................47
      7.2. Investigation Request Communication Flow ..................50
           7.2.1. Investigation Request Example ......................51
           7.2.2. Acknowledgement Message Example ....................53
      7.3. Report Communication Flow .................................54
           7.3.1. Report Example .....................................54
      7.4. Query Communication Flow ..................................56
           7.4.1. Query Example ......................................57
   8. RID Schema Definition ..........................................58
   9. Security Requirements ..........................................62
      9.1. XML Digital Signatures and Encryption .....................62
      9.2. Message Transport .........................................66
      9.3. Public Key Infrastructure .................................67
           9.3.1. Authentication .....................................68
           9.3.2. Multi-Hop Request Authentication ...................69
      9.4. Consortiums and Public Key Infrastructures ................70
      9.5. Privacy Concerns and System Use Guidelines ................71
      9.6. Sharing Profiles and Policies .............................76
   10. Security Considerations .......................................77
   11. Internationalization Issues ...................................77
   12. IANA Considerations ...........................................78
   13. Summary .......................................................80
   14. References ....................................................80
      14.1. Normative References .....................................80
      14.2. Informative References ...................................82
   Appendix A. Acknowledgements ......................................84

1. Introduction

Organizations require help from other parties to identify incidents, mitigate malicious activity targeting their computing resources, and to gain insight into potential threats through the sharing of information. This coordination might entail working with a service provider (SP) to filter attack traffic, working with an SP to resolve a configuration issue that is unintentionally causing problems, contacting a remote site to take down a bot network, or sharing watch-lists of known malicious IP addresses in a consortium. The term "SP" is to be interpreted as any type of service provider or Computer Security Incident Response Team (CSIRT) that may be involved in RID communications. Incident handling involves the detection, reporting, identification, and mitigation of an incident, whether it be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), system compromise, socially engineered phishing attack, or a denial- of-service (DoS) attack, etc. When an incident is detected, the response may include simply filing a report, notification to the source of the incident, a request to an SP for resolution/mitigation,
Top   ToC   RFC6545 - Page 4
   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
   ability to trace the attack traffic iteratively upstream through the
   network for the possibility of any further actions to take place.  In
   cases when accurate records of an active session between the target
   or victim system and the source or attacking system are available,
   the source is easy to identify.

   Real-time inter-network defense (RID) outlines a proactive inter-
   network communication method to facilitate sharing incident-handling
   data while integrating existing detection, tracing, source
   identification, and mitigation mechanisms for a complete incident
   handling solution.  RID provides a secure method to communicate
   incident information, enabling the exchange of Incident Object
   Description and Exchange Format (IODEF) [RFC5070] Extensible Markup
   Language (XML) documents.  RID considers security, policy, and
   privacy issues related to the exchange of potentially sensitive
   information, enabling SPs or organizations the options to make
   appropriate decisions according to their policies.  RID includes
   provisions for confidentiality, integrity, and authentication.

   The data in RID messages is represented in an XML [XML1.0] document
   using the IODEF and RID.  By following this model, integration with
   other aspects for incident handling is simplified.  Methods are
   incorporated into the communication system to indicate what actions
   need to be taken closest to the source in order to halt or mitigate
   the effects of the incident or attack at hand.  RID is intended to
   provide a method to communicate the relevant information between
   CSIRTs while being compatible with a variety of existing and possible
   future detection-tracing and response approaches.  Incidents may be
   extended to include Information Technology (IT) incidents, where RID
   enables the communication between or within providers for non-
   security IT incidents.

   Security and privacy considerations are of high concern since
   potentially sensitive information may be passed through RID messages.
   RID messaging takes advantage of XML security, privacy, and policy
   information set in the RID schema.  The RID schema defines
   communication-specific metadata to support the communication of IODEF
   documents for exchanging or tracing information regarding incidents.
   RID messages are encapsulated for transport, which is defined in a
   separate document [RFC6546].  The authentication, integrity, and
   authorization features that RID and RID transport offer are used to
   achieve a necessary level of security.

   Coordinating with other CSIRTs is not strictly a technical problem.
   There are numerous procedural, trust, and legal considerations that
   might prevent an organization from sharing information.  RID provides
Top   ToC   RFC6545 - Page 5
   information and options that can be used by organizations who must
   then apply their own policies for sharing information.  Organizations
   must develop policies and procedures for the use of the RID protocol
   and IODEF.

1.1. Changes from RFC 6045

This document contains the following changes with respect to its predecessor [RFC6045]: o This document is Standards Track, while [RFC6045] was published as Informational. o This document obsoletes [RFC6045] and moves it to Historic status. o This document refers to the updated RID transport specification [RFC6546], where appropriate. o Edits reflected in this updated version of RID are primarily improvements to the informational descriptions. The descriptions have been updated to clarify that IODEF and RID can be used for all types of incidents and are not limited to network security incidents. The language has been updated to change the focus from attacks to incidents, where appropriate. The term "network provider" has been replaced with the more generic term of "service provider". Several introductory informational sections have been removed as they are not necessary for the implementation of the protocol. The sections include: * 1.3. Attack Types and RID Messaging, * 2. RID Integration with Network Provider Technologies, * 3.1. Integrating Trace Approaches, and * 3.2. Superset of Packet Information for Traces. o An option for a star topology has been included in an informational section to meet current use-case requirements of those who provide reports on incident information. o The schema version was incremented. The schema has changed to include IODEF [RFC5070] enveloped in RID in the RIDPolicy class using the new ReportSchema class, to include one verified erratum, to include additional enumerations in the Justification attribute, to remove the AcrossNationalBoundaries region enumeration, to add the DataWithHandlingRequirements enumeration in TrafficTypes, and to change the name of the RequestAuthorization MsgType to
Top   ToC   RFC6545 - Page 6
      Acknowledgement.  Additional text has been provided to clarify
      definitions of enumerated values for some attributes.  The
      RequestAuthorization name was replaced with Acknowledgement to
      more accurately represent the function of that message type.  Text
      was clarified to note the possible use of this message in response
      to Query and Report messages.  The attributes were fixed in the
      schema to add 'lang' at the RID class level for language support.

   o  The TraceRequest and Investigation messages have been collapsed
      into a single message with the requirement to set the MsgType
      according to the functionality required for automation.  The
      message descriptions were identical with the exception of the
      MsgType, which remains an exception depending on the desired
      function.  Since both of the enumerations for MsgType are each a
      Request, 'Investigation' is now 'InvestigationRequest'.  Content
      may vary within the IODEF document for the type of Request
      specified.

   o  The IncidentQuery message description name and MsgType enumeration
      value in the schema have been changed to the more generic name of
      'Query'.

   o  Guidance has been improved to ensure consistent implementations
      and use of XML encryption to provide confidentiality based on data
      markers, specifically the iodef:restriction attribute in the IODEF
      and IODEF-RID schemas.  The attribute may also be present in IODEF
      extension schemas, where the guidance also applies.  Additional
      guidance and restrictions have been added for XML requirements.

   o  All of the normative text from the Security Considerations section
      has been moved to a new section, Security Requirements.

   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.

   o  Additional text has been provided to explain the content and
      interactions between entities in the examples.

   o  Additional references have been provided to improve
      interoperability with stricter guidance on the use of XML digital
      signatures and encryption.

1.2. Normative and Informative

Sections 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.
Top   ToC   RFC6545 - Page 7

1.3. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Characteristics of Incidents

An incident may be defined as a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), system compromise, a worm or Trojan infection, or a single- or multiple- source denial-of-service attack. The goal of tracing a security incident may be to identify the source or to find a point on the network as close to the origin of the incident as possible. Incident tracing can be used to identify the source(s) of an attack in order to halt or mitigate the undesired behavior or to correct an identified issue. RID messages can be communicated between entities to report or investigate any type of incident and allow for actions to be taken when the source of the incident or a point closer to the source is known or has been identified. Methods to accomplish mitigation may include remediation of a configuration issue, filtering or rate-limiting the traffic close to the source, or taking the host or network offline. Care must also be taken to ensure that the systems involved in the RID communications are not abused and to use proper analysis in determining if attack traffic is, in fact, attack traffic at each SP involved in the investigation. Investigating security incidents can be a difficult task since attackers go to great lengths to obscure their identity. In the case of a security incident, the true source might be identified through an existing established connection to the attacker's point of origin. However, the attacker may not connect to the compromised system for a long period of time after the initial compromise or may access the system through a series of compromised hosts spread across the network. Other methods of obscuring the source may include targeting the host with the same attack from multiple sources using both valid and spoofed source addresses. This tactic can be used to compromise a machine and leave the difficult task of locating the true origin for the administrators. Attackers use many techniques, which can vary between individuals or even organized groups of attackers. Through analysis, the techniques may be grouped into indicators of compromise to be shared via IODEF and RID, further assisting with the improvement of detection capabilities. Security incidents, including distributed denial-of-service (DDoS) attacks, can be difficult or nearly impossible to trace because of the nature of the attack. Some of the difficulties in investigating attacks include the following: o the incident or attack originates from multiple sources;
Top   ToC   RFC6545 - Page 8
   o  the incident may leverage social-engineering techniques or other
      methods to gain access to resources and intellectual property
      using what appears to be legitimate access methods such as
      outbound web sessions from user systems;

   o  the attack may include various types of traffic meant to consume
      server resources, such as a SYN flood attack without a significant
      increase in bandwidth utilization;

   o  the type of traffic could include valid destination services,
      which cannot be blocked since they are essential services to
      business, such as DNS servers at an SP or HTTP requests sent to an
      organization connected to the Internet;

   o  the attack may utilize varying types of packets including TCP,
      UDP, ICMP, or other IP protocols;

   o  the attack may be from "zombies" or large botnets, which then
      require additional searches to locate a controlling server as the
      true origin of the attack;

   o  the attack may use a very small number of packets from any
      particular source, thus making a trace after the fact nearly
      impossible;

   o  the indicators of a compromise may be difficult to detect.

   If the source(s) of an incident cannot be determined from IP address
   information, it may be possible to trace the traffic based on
   characteristics of the incident such as tracing the increased
   bandwidth utilization or the type of packets seen by the client.  In
   the case of packets with spoofed source addresses, it is not a
   trivial task to identify the source of an attack.

   IODEF, any extensions to IODEF, and RID can be used to detail an
   incident, characteristics of the incident (as it evolves), the
   incident history, and communications of the incident to facilitate
   the resolution and reporting of the incident.

3. Communication between CSIRTs and Service Providers

Expediting the communication between CSIRTs and SPs is essential when responding to a security-related incident, which may cross network access points between service 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 should involve multiple means of communication to avoid a single
Top   ToC   RFC6545 - Page 9
   point of failure.  Email is one way to transfer information about the
   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
   call or other communication mechanism like RID.

   A technical solution to trace traffic across a single SP may include
   homegrown or commercial systems for which RID messaging must
   accommodate the input requirements.  The incident-handling system
   used on the SP's backbone by the CSIRT to coordinate the trace across
   the single network requires a method to accept, process, and relay
   RID messages to the system, as well as to wait for responses from the
   system to continue the RID request process as appropriate.  In this
   scenario, each service provider maintains its own system capable of
   communicating via RID and integrates with a management station used
   for monitoring and analysis.  An alternative for providers lacking
   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
   incident-handling functions.  This could be a function of a central
   organization operating as a CSIRT for countries as a whole or within
   a consortium that may be able to provide centralized resources.

   Consortiums could consist of a federation or a group of service
   providers or CSIRTs that agrees to participate in the RID
   communication protocol with an agreed-upon policy and communication
   protocol facilitating the secure transport of IODEF-RID XML
   documents.  Transport for RID messages is specified in [RFC6546].

   One goal of RID is to prevent the need to permit access to other
   networks' equipment.  RID provides a standard messaging mechanism to
   enable the communication of incident-handling information to other
   providers in a consortium or in neighboring networks.  The third
   party mentioned above may be used in this technical solution to
   assist in facilitating incident handling and possibly traceback
   through smaller providers.  The RID messaging mechanism may be a
   logical or physical out-of-band network to ensure that the
   communication is secure and unaffected by the state of the network
   under attack.  The two management methods would accommodate the needs
   of larger providers to maintain full management of their network, and
   the third-party option could be available to smaller providers who
   lack the necessary human resources to perform incident-handling
   operations.  The first method enables the individual providers to
   involve (via a notification and alerting system) their network
   operations staff to authorize the continuance of a trace or other
   necessary response to a RID communication request through their
   network.
Top   ToC   RFC6545 - Page 10
   The network used for the communication should consist of out-of-band
   or protected channels (direct communication links) or encrypted
   channels dedicated to the transport of RID messages.  The
   communication links would be direct connections (virtual or physical)
   between peers who have agreed-upon use and abuse policies through a
   consortium.  Consortiums might be linked through policy comparisons
   and additional agreements to form a larger web or iterative network
   of peers that correlates to the traffic paths available over the
   larger web of networks or is based on regions and logical groups.
   Contact information, IP addresses of RID systems, and other
   information must be coordinated between bilateral peers by a
   consortium and may use existing databases, such as the routing
   arbiter.  The security, configuration, and Confidence rating schemes
   of the RID messaging peers must be negotiated by peers and must meet
   certain overall requirements of the fully connected network
   (Internet, government, education, etc.) through the peering and/or a
   consortium-based agreement.

   RID messaging established with clients of an provider may be
   negotiated in a contract as part of a value-added service or through
   a service level agreement (SLA).  Further discussion is beyond the
   scope of this document and may be more appropriately handled in
   peering or service level agreements.

   Procedures for incident handling need to be established and well
   known by anyone that may be involved in incident response.  The
   procedures should also contain contact information for internal
   escalation procedures, as well as for external assistance groups such
   as a CSIRT, CERT Coordination Center (CERT/CC), Global Information
   Assurance Certification (GIAC), and the U.S. Federal Bureau of
   Investigations (FBI) or other assisting government organization in
   the country of the investigation.

3.1. Inter-Service-Provider RID Messaging

RID provides a protocol and format that ensures interoperability between vendors for the implementation of an incident messaging mechanism. The messages should meet several requirements in order to be meaningful as they traverse multiple networks. RID provides the framework necessary for communication between networks involved in the incident handling, possible traceback, and mitigation of a security incident. Several message types described in Section 4.2 are necessary to facilitate the handling of a security incident. The message types include the Report, Query, Request, Acknowledgement, and Result message. 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.
Top   ToC   RFC6545 - Page 11
   A Query message is used to request information on a particular
   incident.  A Request message with options set to 'TraceRequest' is
   used when the source of the traffic may have been spoofed.  In that
   case, each SP in the upstream path who receives this Request will
   issue a trace across the network to determine the upstream source of
   the traffic.  The Acknowledgement and Result messages are used to
   communicate the status and result of a Request.  The Request message
   with options set to 'InvestigationRequest' may be sent to any party
   assisting in an incident investigation.  The InvestigationRequest
   leverages the bilateral relationships or a consortium's
   interconnections to mitigate or stop problematic traffic close to the
   source.  Routes could determine the fastest path to a known source IP
   address in the case of an InvestigationRequest.  A Request message
   (set to 'TraceRequest' or 'InvestigationRequest') sent between RID
   systems to stop traffic at the source through a bordering network
   requires the information enumerated below:

   1.  Enough information to enable the network administrators to make a
       decision about the importance of continuing the trace.

   2.  The incident or IP packet information needed to carry out the
       trace or investigation.

   3.  Contact information of the origin of the RID communication.  The
       contact information could be provided through the Autonomous
       System Number (ASN) [RFC1930] or Network Information Center (NIC)
       handle information listed in the Registry for Internet Numbers or
       other Internet databases.

   4.  Network path information to help prevent any routing loops
       through the network from perpetuating a trace.  If a RID system
       receives a Request with MsgType set to 'TraceRequest' that
       contains its own information in the path, the trace must cease
       and the RID system should generate an alert to inform the network
       operations staff that a tracing loop exists.

   5.  A unique identifier for a single attack.  This identifier should
       be used to correlate traces to multiple sources in a DDoS attack.

   Use of the communication network and the RID protocol must be for
   pre-approved, authorized purposes only.  It is the responsibility of
   each participating party to adhere to guidelines set forth in both a
   global use policy established through the peering agreements for each
   bilateral peer or agreed-upon consortium guidelines.  The purpose of
   such policies is to avoid abuse of the system; the policies shall be
   developed by a consortium or participating entities.  The global
   policy may be dependent on the domain it operates under; for example,
   a government network or a commercial network such as the Internet
Top   ToC   RFC6545 - Page 12
   would adhere to different guidelines to address the individual
   concerns.  Privacy issues must be considered in public networks such
   as the Internet.  Privacy issues are discussed in the Security
   Requirements section, along with other requirements that must be
   agreed upon by participating entities.

   RID requests must be legitimate incidents and not used for purposes
   such as sabotage or censorship.  An example of such abuse of the
   system includes a request to rate-limit legitimate traffic to prevent
   information from being shared between users on the Internet
   (restricting access to online versions of papers) or restricting
   access from a competitor's product in order to sabotage a business.

   The RID system should be configurable to either require user input or
   automatically continue traces.  This feature enables a network
   manager to assess the available resources before continuing a Request
   message set to 'InvestigationRequest' or 'TraceRequest'.  If the
   Confidence rating (provided in IODEF) is low, it may not be in the
   provider's best interest to continue the Request with options set to
   'InvestigationRequest' or 'TraceRequest'.  The Confidence ratings
   must adhere to the specifications for selecting the percentage used
   to avoid abuse of the system.  Requests must be issued by authorized
   individuals from the initiating CSIRT, set forth in policy guidelines
   established through peering or a SLA.

3.2. RID Communication Topology

The most basic topology for communicating RID systems is a direct connection or a bilateral relationship as illustrated below. ___________ __________ | | | | | RID |__________-------------___________| RID | |_________| | SP Border | |________| ------------- Figure 1: Direct Peer Topology Within the consortium model, several topologies might be agreed upon and used. One would leverage bilateral network peering relationships of the members of the consortium. The peers for RID would match that of routing peers, and the logical network borders would be used. This approach may be necessary for an iterative trace where the source is unknown. The model looks like the above diagram; however, there may be an extensive number of interconnections of bilateral relationships formed. Also within a consortium model, it may be useful to establish an integrated mesh of networks to pass RID messages. This may be beneficial when the source address is known,
Top   ToC   RFC6545 - Page 13
   and an interconnection may provide a faster route to reach the
   closest upstream peer to the source of the attack traffic if direct
   communication between SPs is not possible.  An example is illustrated
   below.

       _______                     _______                     _______
       |     |                     |     |                     |     |
     __| RID |____-------------____| RID |____-------------____| RID |__
       |_____|    | SP Border |    |_____|    | SP Border |    |_____|
          |       -------------               -------------       |
          |_______________________________________________________|

      Direct connection to network that is not an immediate network peer

                       Figure 2: Mesh Peer Topology

   By using a fully meshed model in a consortium, broadcasting RID
   requests would be possible, but not advisable.  By broadcasting a
   request, RID peers that may not have carried the attack traffic on
   their network would be asked to perform a trace for the potential of
   decreasing the time in which the true source was identified.  As a
   result, many networks would have utilized unnecessary resources for a
   Request that may have also been unnecessary.

   A star topology may be desirable in instances where a peer may be a
   provider of incident information.  This requires trust relationships
   to be established between the provider of information and each of the
   consumers of that information.  Examples may include country-level
   CSIRTs or service providers distributing incident information to
   organizations.

4. Message Formats

4.1. RID Data Types

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: BOOLEAN.

4.1.1. Boolean

A boolean value is represented by the BOOLEAN data type. The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in the schema. Note that there are two lexical representations for boolean in [XMLschema]: '1' or 'true' for TRUE and '0' or 'false' or FALSE.
Top   ToC   RFC6545 - Page 14

4.2. RID Message Types

The five 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 [RFC6546]. 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 described RID message types. 1. Request. This message type is used when a request ('InvestigationRequest' or 'TraceRequest') is needed. The purpose of the Request message (set to 'InvestigationRequest') is to leverage the existing peer relationships in order to notify the SP closest to the source of the valid traffic of a security- related incident for any necessary actions to be taken. The Request (set to 'TraceRequest') is used when the traffic has to be traced iteratively through networks to find the source by setting the MsgType to 'TraceRequest'. The 'InvestigationRequest' MsgType is used for all other Request messages. 2. Acknowledgement. This message is sent to the initiating RID system from each of the upstream provider's RID systems to provide information on the status of a Request. The Acknowledgement is also used to provide a reason why a Request, Report, or Query was not accepted. 3. Result. The Result message is used to provide a final report and the notification of actions taken for a Request. This message is sent to the initiating CSIRT through the network of RID systems in the path of the trace as notification that the source of the attack was located. 4. Report. This message is used to report a security incident, for which no action is requested. This may be used for the purpose of correlating attack information by CSIRTs, sharing incident information, statistics and trending information, etc. 5. Query. This message is used to request information about an incident or incident type from a trusted system communicating via RID. The response is provided through the Report message. When an application receives a RID message, it must be able to determine the type of message and parse it accordingly. The message type is specified in the RIDPolicy class. The RIDPolicy class may
Top   ToC   RFC6545 - Page 15
   also be used by the transport protocol to facilitate the
   communication of security incident data to trace, investigate, query,
   or report information regarding security incidents.



(page 15 continued on part 2)

Next Section