GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6545

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.

Moriarty Standards Track [Page 1] RFC 6545 RID April 2012

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

Moriarty Standards Track [Page 2] RFC 6545 RID April 2012

         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,

Moriarty Standards Track [Page 3] RFC 6545 RID April 2012

 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

Moriarty Standards Track [Page 4] RFC 6545 RID April 2012

 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

Moriarty Standards Track [Page 5] RFC 6545 RID April 2012

    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.

Moriarty Standards Track [Page 6] RFC 6545 RID April 2012

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;

Moriarty Standards Track [Page 7] RFC 6545 RID April 2012

 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

Moriarty Standards Track [Page 8] RFC 6545 RID April 2012

 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.

Moriarty Standards Track [Page 9] RFC 6545 RID April 2012

 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.

Moriarty Standards Track [Page 10] RFC 6545 RID April 2012

 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

Moriarty Standards Track [Page 11] RFC 6545 RID April 2012

 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,

Moriarty Standards Track [Page 12] RFC 6545 RID April 2012

 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.

Moriarty Standards Track [Page 13] RFC 6545 RID April 2012

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

Moriarty Standards Track [Page 14] RFC 6545 RID April 2012

 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.

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.

Moriarty Standards Track [Page 15] RFC 6545 RID April 2012

 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].

Moriarty Standards Track [Page 16] RFC 6545 RID April 2012

 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.

Moriarty Standards Track [Page 17] RFC 6545 RID April 2012

 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.

Moriarty Standards Track [Page 18] RFC 6545 RID April 2012

    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.

Moriarty Standards Track [Page 19] RFC 6545 RID April 2012

    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.

Moriarty Standards Track [Page 20] RFC 6545 RID April 2012

    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.

Moriarty Standards Track [Page 21] RFC 6545 RID April 2012

       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.

Moriarty Standards Track [Page 22] RFC 6545 RID April 2012

       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.

Moriarty Standards Track [Page 23] RFC 6545 RID April 2012

        +-------------------------+
        |      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.

Moriarty Standards Track [Page 24] RFC 6545 RID April 2012

    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.

Moriarty Standards Track [Page 25] RFC 6545 RID April 2012

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.

Moriarty Standards Track [Page 26] RFC 6545 RID April 2012

       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.

Moriarty Standards Track [Page 27] RFC 6545 RID April 2012

       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.

Moriarty Standards Track [Page 28] RFC 6545 RID April 2012

    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 "&amp;", "&lt;", "&gt;", "&quot;", and "&apos;",
 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

Moriarty Standards Track [Page 29] RFC 6545 RID April 2012

 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.

Moriarty Standards Track [Page 30] RFC 6545 RID April 2012

 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

Moriarty Standards Track [Page 31] RFC 6545 RID April 2012

 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.

Moriarty Standards Track [Page 32] RFC 6545 RID April 2012

    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:

Moriarty Standards Track [Page 33] RFC 6545 RID April 2012

 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.

Moriarty Standards Track [Page 34] RFC 6545 RID April 2012

 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).

Moriarty Standards Track [Page 35] RFC 6545 RID April 2012

       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.

Moriarty Standards Track [Page 36] RFC 6545 RID April 2012

 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

Moriarty Standards Track [Page 37] RFC 6545 RID April 2012

 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).

Moriarty Standards Track [Page 38] RFC 6545 RID April 2012

    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.

7. RID Communication Exchanges

 The following section outlines the communication flows for RID and
 also provides examples of messages.
 The possible set of message exchanges include:
 o  Request: Asynchronous Request for assistance and/or action to be
    taken, MAY involve multiple systems and iterative Requests
       MsgType set to 'InvestigationRequest' or 'TraceRequest'
       Possible responses:
       +  Acknowledgement (OPTIONAL for InvestigationRequest)
       +  Result (REQUIRED unless Acknowledgement was set to 'no')
       +  Report (OPTIONAL; zero or more; Report can be sent
          unsolicited)

Moriarty Standards Track [Page 39] RFC 6545 RID April 2012

 o  Query: Synchronous request for information
       MsgType set to 'Query'
       Possible responses:
       +  Acknowledgement (OPTIONAL if yes; REQUIRED if no Report will
          be sent)
       +  Report (REQUIRED unless Acknowledgement was set to 'no')
 o  Report: Asynchronous information report; may be pushed to systems
    or may be a response to a Query
       MsgType set to 'Report'
       Possible responses:
       +  Acknowledgement (OPTIONAL)
 Processing considerations for the IODEF document and any IODEF
 included elements or attributes MUST follow the guidelines specified
 in [RFC5070], Section 4.  [RFC3023] and [RFC3470] specify
 requirements and best practices for the use of XML in IETF
 application protocols.  RID and IODEF documents MUST be well-formed
 (see [RFC3470], Section 4.1) and MUST be validated against the
 appropriate schema.  Internal or external DTD subsets are prohibited
 in RID; see [RFC3023], Section 3.
 Comments can be ignored by conform ant processors for RID or IODEF
 documents (see [RFC3470], Section 4.6) and are included below for
 informational purposes only.  The first example demonstrates the use
 of a detached digital signature.  Subsequent examples do not include
 the detached signature required for some message types.  The
 signature is applied after the message is created as demonstrated in
 the first example.
 Note: For each example listed below, [RFC5735] addresses were used.
 Assume that each IP address listed is actually a separate network
 range held by different SPs.  Addresses were used from /27 network
 ranges.

7.1. Upstream Trace Communication Flow

 The diagram below outlines the RID Request communication flow for a
 TraceRequest between RID systems on different networks tracing an
 attack.  The Request message with MsgDestination set to

Moriarty Standards Track [Page 40] RFC 6545 RID April 2012

 'TraceRequest' is represented in the diagram by "TraceRequest".
 SP-1, SP-2, and SP-3 represent service providers that are involved in
 the example trace communication flow.
  Attack Dest      SP-1            SP-2        SP-3        Attack Src
  1. Attack    |  Attack
     reported  |  detected
  2.              Initiate trace
  3.              Locate origin
                  through
                  upstream SP
  4.              o---TraceRequest----->
  5.                              Trace
                                  Initiated
  6.              <---Acknowledgement--o
  7.                              Locate origin
                                  through
                                  upstream SP
  8.                              o---TraceRequest--->
  9.                                             Trace Initiated
  10.             <----------Acknowledgement----o
                                   <-Acknowledgement-o
  11.                                            Locate attack
                                                 source on network   X
  12.             <------------Result----------------o
  13.             o- - - - -Acknowledgement- - - - - >
               Figure 8: TraceRequest Communication Flow
 Before a trace is initiated, the RID system should verify that an
 instance of the trace or a similar request is not active.  The traces
 may be resource intensive; therefore, providers need to be able to
 detect potential abuse of the system or unintentional resource

Moriarty Standards Track [Page 41] RFC 6545 RID April 2012

 drains.  Information such as the Source and Destination Information,
 associated packets, and the incident may be desirable to maintain for
 a period of time determined by administrators.
 The communication flow demonstrates that an Acknowledgement message
 is sent to both the downstream peer and the original requestor.  If a
 Request in a traceback is denied, the downstream peer has the option
 to take an action and respond with a Result message.  The originator
 of the request may follow up with the downstream peer of the SP
 involved using a Request with the MsgType set to
 'InvestigationRequest' to ensure that an action is taken if no
 response is received.  Nothing precludes the originator of the
 request from initiating a new Request with the MsgType set to
 'TraceRequest' thereby bypassing the SP that denied the request, if a
 trace is needed beyond that point.  Another option may be for the
 initiator to send an 'InvestigationRequest' to an SP upstream of the
 SP that denied the request.  This action assumes enough information
 was gathered to discern the true source of the attack traffic from
 the incident-handling information.
 The proper response to a TraceRequest is an Acknowledgement message.
 The Acknowledgement message lets the requestor know if the trace will
 continue through the next upstream network.  If there is a problem
 with the request, such as a failure to validate the digital signature
 or decrypt the request, an Acknowledgement message MUST be sent to
 the requestor and the downstream peer (if they are not one and the
 same) providing the reason why the message could not be processed.
 Assuming that the trace continued, additional TraceRequests with the
 response of an Acknowledgement message would occur, thereby passing
 the request upstream in the path to the source of the traffic related
 to the incident.  Once a source is found, a Result message is sent to
 the originator of the trace, as determined by the SP path information
 provided through the document instance of EventData, where contact is
 set to 'infrastructure'.  The SP path information is also used when
 sending the Acknowledgement messages to the first entry (the trace
 originator) and the last nested entry (the downstream peer).  The
 Result message is encrypted [XMLencrypt] for the originator providing
 information about the incident source and any actions taken.  If the
 originator fails to decrypt or authenticate the Result message, an
 Acknowledgement message is sent in response; otherwise, no return
 message is sent.  The final Acknowledgement to the Result message is
 depicted as optional in the diagram above.  If an Acknowledgement
 message is sent with the RequestStatus set to Denied, a downstream
 peer receiving this message may choose to take action to stop or
 mitigate the traffic at that point in the network, as close to the
 source as possible.  If the downstream peer chooses this option, it
 would send a Result message to the trace originator.

Moriarty Standards Track [Page 42] RFC 6545 RID April 2012

7.1.1. RID TraceRequest Example

 The example listed is of a Request message with MsgDestination set to
 'TraceRequest' based on the incident report example from the IODEF
 document.  The RID classes were included as appropriate for a Request
 message of this type using the RIDPolicy class.  The example given is
 that of a CSIRT reporting a DoS attack in progress to the upstream
 SP.  The request asks the next SP to continue the trace and have the
 traffic mitigated closer to the source of the traffic.  The example
 Request message is the first 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 Src' is later identified in the
 Result message example as 192.0.2.37 and initially as tracing closer
 to 192.0.2.35.  SP-1 is identified in the Request as CSIRT-FOR-OUR-
 DOMAIN, and SP-2 is identified in the RID document for the Request as
 the 'RIDSystem' in 'MsgDestination' as 192.0.2.3 using the Node
 class.  SP-3 is later used in the Result message and the
 administrator is identified as 'Admin-contact@10.1.1.2' as they
 searched for 192.0.2.35; the administrator may be different than the
 constituency contact (an additional Request with MsgDestination set
 to 'TraceRequest' occurred between SP-2 to SP-3 that is not
 included).  SP-3 is the service provider for 192.0.2.32/27 and was
 able to take the action to rate-limit their traffic.  The SP-1, SP-2,
 and SP-3 information would be replaced with the appropriate (and
 valid) email and other contact information in real usages.  The Node
 class enables multiple methods to identify a system, such as a fully
 qualified domain name or the IP address to be provided for the SP.
 Any mapping of existing relationships from the SP Node information to
 the name, contact, digital signature verification information and
 other identifying or trust information is provided at the application
 layer to support end 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 perform traces to the attack source
 before taking the requested action to 'rate-limit' the traffic.  The
 subnet of 192.0.2.0 uses a 27-bit mask in the examples below.
 In the following example, use of [XMLsig] to generate digital
 signatures follows the guidance of [XMLsig] 1.0.  Version 1.1 of
 [XMLsig] supports additional digest algorithms.  Reference [RFC4051]
 for URIs intended for use with XML digital signatures, encryption,
 and canonicalization.  SHA-1 SHOULD NOT be used; see [RFC6194] for
 further details.
 Note: Due to the limit of 72 characters per line, some line breaks
 were added in the examples and schemas in this document.

Moriarty Standards Track [Page 43] RFC 6545 RID April 2012

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <iodef-rid:RID lang="en-US" xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0"> <iodef-rid:RIDPolicy MsgDestination="RIDSystem" MsgType="TraceRequest">

 <iodef-rid:PolicyRegion region="IntraConsortium"/>
   <iodef:Node>
    <iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
   </iodef:Node>
   <iodef-rid:TrafficType type="Attack"/>
   <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
          CERT-FOR-OUR-DOMAIN#207-1
   </iodef:IncidentID>
   <!-- IODEF-Document included in RID -->
   <iodef-rid:ReportSchema Version="1.0">
    <iodef-rid:XMLDocument dtype="xml" meaning="xml">
     <IODEF-Document lang="en">
      <iodef:Incident purpose="traceback" restriction="need-to-know">
        <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
                         CERT-FOR-OUR-DOMAIN#207-1
        </iodef:IncidentID>
        <iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
        <iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
        <iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
        <iodef:Description>
                         Host involved in DoS attack
        </iodef:Description>
        <iodef:Assessment>
          <iodef:Impact completion="failed" severity="low"
                        type="dos"/>
        </iodef:Assessment>
        <iodef:Contact role="creator" type="organization">
          <iodef:ContactName>Constituency-contact for 192.0.2.35
          </iodef:ContactName>
          <iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
        </iodef:Contact>
        <iodef:EventData>
          <iodef:Flow>
            <iodef:System category="source">
              <iodef:Node>
                <iodef:Address category="ipv4-addr">192.0.2.35
                </iodef:Address>
              </iodef:Node>
              <iodef:Service ip_protocol="6">
                <iodef:Port>38765</iodef:Port>
              </iodef:Service>

Moriarty Standards Track [Page 44] RFC 6545 RID April 2012

            </iodef:System>
            <iodef:System category="target">
              <iodef:Node>
                <iodef:Address category="ipv4-addr">192.0.2.67
                </iodef:Address>
              </iodef:Node>
              <iodef:Service ip_protocol="6">
                <iodef:Port>80</iodef:Port>
              </iodef:Service>
            </iodef:System>
          </iodef:Flow>
          <iodef:Expectation action="rate-limit-host" severity="high">
            <iodef:Description>
                   Rate-limit traffic close to source
          </iodef:Description>
        </iodef:Expectation>
        <iodef:Record>
          <iodef:RecordData>
            <iodef:Description>
             The IPv4 packet included was used in the described attack
            </iodef:Description>
            <iodef:RecordItem dtype="ipv4-packet">450000522ad9
              0000ff06c41fc0a801020a010102976d0050103e020810d9
              4a1350021000ad6700005468616e6b20796f7520666f7220
              6361726566756c6c792072656164696e6720746869732052
              46432e0a
            </iodef:RecordItem>
           </iodef:RecordData>
          </iodef:Record>
         </iodef:EventData>
         <iodef:History>
           <iodef:HistoryItem action="rate-limit-host">
             <iodef:DateTime>
                    2001-09-14T08:19:01+00:00
             </iodef:DateTime>
             <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
                    CSIRT-FOR-OUR-DOMAIN#207-1
             </iodef:IncidentID>
             <iodef:Description>
            Notification sent to next upstream SP closer to 192.0.2.35
             </iodef:Description>
            </iodef:HistoryItem>
           </iodef:History>
          </iodef:Incident>
         </IODEF-Document>
       </iodef-rid:XMLDocument>
     <!-- End of IODEF-Document included in RID -->
     <!-- Start of detached XML signature included in RID -->

Moriarty Standards Track [Page 45] RFC 6545 RID April 2012

     <iodef-rid:Signature dtype="xml" meaning="xml">
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
                 Id="dsig-123456">
      <SignedInfo>

<CanonicalizationMethod

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<SignatureMethod

Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
  <Reference URI="">
  <Transforms>
   <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
   <Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
   <XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2"
     xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
     xmlns:dsig-trans="http://www.w3.org/2002/06/xmldsig-filter2"
     Filter="intersect">
     //dsig:Signature[@Id = 'dsig-123456']/
     ancestor::iodef-rid:ReportSchema/
     iodef-rid:XMLDocument/IODEF-Document[1]/iodef:Incident[1]/
     iodef:EventData[1]/iodef:Record[1]/iodef:RecordData[1]/
     iodef:RecordItem[1]</XPath></Transform></Transforms>
  <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
  <DigestValue>
     NQuIhPjdZuZJnPi/hW62dwJT1dR+vqcZV8mpemCVN5g=
  </DigestValue>
 </Reference></SignedInfo>
 <SignatureValue>

lnq/ePQ4AVpxCR0ifCp9sMsW0r/AdT3C2GR/zaN1V+hZ/NApOygUjMzTCQnx+RvGPNkO/RVq BEIDgZQUEnQZn/uSbmr0tQ6xpBfaxF1DCosLgiZy+2jFzpXrwoN/jHNgtxR/9QLW9mZ+I7V6 LEEJ73Kut+d0naTGHlyi64ab2PqsVuRXQ4pXUKbhMkhzeTIqvFLK93KGfsIMd6Cb+n2u/ABy Lkc+gflJYUWVP4DxkQ4cyex6hM6RYTRUSr7jVD9K4d8KFP2g85i69YLtSu01W1Np0afpJ4a9 MK0E7ISMNRmC8wIklCAsSXiBRqyaEwaSy/clybI0vCTPqGOYh3/SZg==

 </SignatureValue>
 <KeyInfo>
  <KeyValue>
    <RSAKeyValue>
     <Modulus>

z8adrX9m0S8OxIxN+fui33wiz4ZYgb4xPbR9MS5pOp1A8kVpH5Ew3N6O3/dMs2a4diIxyGLV h0r86QXWH/W6T2IC2ny+hi+jWRwXrvgTY3ZAFgePvz2OdRhVN/cUbOto4Pa4I2mVZWW+/Q0F n7YpqPBDDxlGq/xyFPuYq/4y7Y+Ah+vHO2ZSaiQjbj8F38XrGhwlcbFVyK8AmxK3z0zWwX86 uMEqVCjW6s6j2KAWdbAjEpgZHlJY87i/DqnFgxfmdg3oru+YeiEPVRY8hyQpYbtgryveZOHT gnCHmS/53U9jSS0cyb/ADuj1upfyNoOiMMgQr7Olhc5pTvuWAl4Fnw==</Modulus>

     <Exponent>AQAB</Exponent>
    </RSAKeyValue>
    </KeyValue>
  </KeyInfo>
 </Signature>
</iodef-rid:Signature>

Moriarty Standards Track [Page 46] RFC 6545 RID April 2012

<!-- End of detached XML signature included in RID -->
    </iodef-rid:ReportSchema>
 </iodef-rid:RIDPolicy>

</iodef-rid:RID>

7.1.2. Acknowledgement Message Example

 The example Acknowledgement message is in response to the Request
 message listed above.  The SP that received the request is responding
 to approve the trace continuance in their network.
 <iodef-rid:RID lang="en"
                xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
                xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
   <iodef-rid:RIDPolicy MsgType="Acknowledgement"
                        MsgDestination="RIDSystem">
     <iodef-rid:PolicyRegion region="IntraConsortium"/>
     <iodef:Node>
       <iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
     </iodef:Node>
     <iodef-rid:TrafficType type="Attack"/>
     <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
       CERT-FOR-OUR-DOMAIN#207-1
     </iodef:IncidentID>
   </iodef-rid:RIDPolicy>
   <iodef-rid:RequestStatus AuthorizationStatus="Approved"/>
 </iodef-rid:RID>

7.1.3. Result Message Example

 The example Result message is in response to the Request listed
 above.  This message type only comes after an Acknowledgement within
 the Request flow of messages where a TraceRequest is in progress.  It
 may be a direct response to a Request with the MsgType set to
 'InvestigationRequest'.  This message provides information about the
 source of the attack and the actions taken to mitigate the traffic.
 The Result message is typically the last message in a Request flow;
 however, an Acknowledgement MAY follow if there are any issues
 receiving or processing the Result.

<iodef-rid:RID lang="en"

             xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
             xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Result"
                     MsgDestination="RIDSystem">
  <iodef-rid:PolicyRegion region="IntraConsortium"/>
  <iodef:Node>
    <iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>

Moriarty Standards Track [Page 47] RFC 6545 RID April 2012

  </iodef:Node>
  <iodef-rid:TrafficType type="Attack"/>
  <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
    CERT-FOR-OUR-DOMAIN#207-1
  </iodef:IncidentID>

<!– IODEF-Document included in RID –>

  <iodef-rid:ReportSchema Version="1.0">
   <iodef-rid:XMLDocument dtype="xml" meaning="xml">
    <iodef:IODEF-Document lang="en">
    <iodef:Incident restriction="need-to-know" purpose="traceback">
      <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
        CERT-FOR-OUR-DOMAIN#207-1
      </iodef:IncidentID>
    <iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
    <iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
    <iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
    <iodef:Description>Host involved in DoS attack</iodef:Description>
    <iodef:Assessment>
      <iodef:Impact severity="low" completion="failed"
                    type="dos"/>
    </iodef:Assessment>
    <iodef:Contact role="creator" type="organization">
      <iodef:ContactName>Constituency-contact for 192.0.2.35
      </iodef:ContactName>
      <iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
    </iodef:Contact>
    <iodef:EventData>
      <iodef:Contact role="admin" type="organization">
        <iodef:ContactName>Admin-contact for 192.0.2.35
        </iodef:ContactName>
        <iodef:Email>Admin-contact@10.1.1.2</iodef:Email>
      </iodef:Contact>
      <iodef:Flow>
        <iodef:System category="intermediate">
          <iodef:Node>
            <iodef:Address category="ipv4-addr">192.0.2.35
            </iodef:Address>
          </iodef:Node>
        </iodef:System>
      </iodef:Flow>
      <iodef:EventData>
        <iodef:Contact role="admin" type="organization">
          <iodef:ContactName>Admin-contact for 192.0.2.3
          </iodef:ContactName>
          <iodef:Email>Admin-contact@192.0.2.3</iodef:Email>
        </iodef:Contact>
        <iodef:Flow>
          <iodef:System category="intermediate">

Moriarty Standards Track [Page 48] RFC 6545 RID April 2012

            <iodef:Node>
              <iodef:Address category="ipv4-addr">192.0.2.3
              </iodef:Address>
            </iodef:Node>
          </iodef:System>
        </iodef:Flow>
      </iodef:EventData>
    </iodef:EventData>
    <iodef:EventData>
      <iodef:Flow>
        <iodef:System category="source">
          <iodef:Node>
            <iodef:Address category="ipv4-addr">192.0.2.35
            </iodef:Address>
          </iodef:Node>
          <iodef:Service ip_protocol="6">
            <iodef:Port>38765</iodef:Port>
          </iodef:Service>
        </iodef:System>
        <iodef:System category="target">
          <iodef:Node>
            <iodef:Address category="ipv4-addr">192.0.2.67
            </iodef:Address>
          </iodef:Node>
          <iodef:Service ip_protocol="6">
            <iodef:Port>80</iodef:Port>
          </iodef:Service>
        </iodef:System>
      </iodef:Flow>
      <iodef:Expectation severity="high" action="rate-limit-host">
        <iodef:Description>
          Rate-limit traffic close to source
        </iodef:Description>
      </iodef:Expectation>
      <iodef:Record>
        <iodef:RecordData>
          <iodef:Description>
            The IPv4 packet included was used in the described attack
          </iodef:Description>
          <iodef:RecordItem dtype="ipv4-packet">450000522ad9
          0000ff06c41fc0a801020a010102976d0050103e020810d9
          4a1350021000ad6700005468616e6b20796f7520666f7220
          6361726566756c6c792072656164696e6720746869732052
          46432e0a
          </iodef:RecordItem>
        </iodef:RecordData>
      </iodef:Record>
    </iodef:EventData>

Moriarty Standards Track [Page 49] RFC 6545 RID April 2012

    <iodef:History>
      <iodef:HistoryItem action="rate-limit-host">
        <iodef:DateTime>2004-02-02T22:53:01+00:00</iodef:DateTime>
        <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
          CSIRT-FOR-OUR-DOMAIN#207-1
        </iodef:IncidentID>
        <iodef:Description>
          Notification sent to next upstream SP closer to 192.0.2.35
        </iodef:Description>
      </iodef:HistoryItem>
      <iodef:HistoryItem action="rate-limit-host">
        <iodef:DateTime>2004-02-02T23:07:21+00:00</iodef:DateTime>
        <iodef:IncidentID name="CSIRT-FOR-SP3">
          CSIRT-FOR-SP3#3291-1
        </iodef:IncidentID>
        <iodef:Description>
          Host rate-limited for 24 hours
          </iodef:Description>
        </iodef:HistoryItem>
      </iodef:History>
    </iodef:Incident>
    </iodef:IODEF-Document>
   </iodef-rid:XMLDocument>

<!– End of IODEF-Document included in RID –>

 </iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
<iodef-rid:IncidentSource>
  <iodef-rid:SourceFound>true</iodef-rid:SourceFound>
  <iodef:Node>
    <iodef:Address category="ipv4-addr">192.0.2.37</iodef:Address>
  </iodef:Node>
</iodef-rid:IncidentSource>

</iodef-rid:RID>

7.2. Investigation Request Communication Flow

 The diagram below outlines a RID Request communication flow between
 RID systems on different networks for a security incident with a
 known source address.  Therefore, MsgDestination is set to
 'InvestigationRequest' for the Request message and is included in the
 diagram below as "Investigation".  The proper response to a Request
 with the MsgDestination set to 'InvestigationRequest' is a Result
 message.  If there is a problem with the Request, such as a failure
 to validate the digital signature or decrypt the Request, an
 Acknowledgement message is sent to the requestor.  The
 Acknowledgement message should provide the reason why the message
 could not be processed.

Moriarty Standards Track [Page 50] RFC 6545 RID April 2012

     Attack Dest      SP-1              SP-2        Attack Src
     1. Attack    |  Attack
        reported  |  detected
     2.              Determine source
                     of security incident
     3.              o---Investigation---->
     4.                              Research
                                     incident and
                                     determine appropriate
                                     actions to take
     5.              <-------Result-------o
          Figure 9: Investigation Request Communication Flow

7.2.1. Investigation Request Example

 The following example only includes the RID-specific details.  The
 IODEF and security measures are similar to the TraceRequest, with the
 exception that the source is known, the receiving RID system is known
 to be close to the source, and the MsgDestination is set to
 'InvestigationRequest'.  The source known is indicated in the IODEF
 document, which allows for incident sources to be listed as spoofed,
 if appropriate.
 This flow does not include a Result message because the request is
 denied as shown in the Acknowledgement response.
 SP-1 is represented by CERT-FOR-OUR-DOMAIN and 192.0.2.67.  SP-2 is
 identified by 192,0.2.98.  In this example, SP-2 is the service
 provider for systems on the 192.0.2.32/27 subnet.  The contact for
 the host 192.0.2.35 is known at the start of the request as
 'Constituency-contact@10.1.1.2'.
<iodef-rid:RID lang="en"
               xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
               xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
  <iodef-rid:RIDPolicy MsgType="InvestigationRequest"
                       MsgDestination="SourceOfIncident">
    <iodef-rid:PolicyRegion region="PeerToPeer"/>
    <iodef:Node>
      <iodef:Address category="ipv4-addr">192.0.2.98</iodef:Address>
    </iodef:Node>
    <iodef-rid:TrafficType type="Attack"/>

Moriarty Standards Track [Page 51] RFC 6545 RID April 2012

    <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
      CERT-FOR-OUR-DOMAIN#208-1
    </iodef:IncidentID>
<!-- IODEF-Document included in RID -->
    <iodef-rid:ReportSchema Version="1.0">
     <iodef-rid:XMLDocument dtype="xml" meaning="xml">
  <iodef:IODEF-Document lang="en">
  <iodef:Incident restriction="need-to-know" purpose="other">
    <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
      CERT-FOR-OUR-DOMAIN#208-1
    </iodef:IncidentID>
    <iodef:DetectTime>2004-02-05T08:13:33+00:00</iodef:DetectTime>
    <iodef:StartTime>2004-02-05T08:13:31+00:00</iodef:StartTime>
    <iodef:EndTime>2004-02-05T08:13:33+00:00</iodef:EndTime>
    <iodef:ReportTime>2004-02-05T08:13:35+00:00</iodef:ReportTime>
    <iodef:Description>Host involved in DoS attack</iodef:Description>
    <iodef:Assessment>
      <iodef:Impact severity="low" completion="failed" type="recon"/>
    </iodef:Assessment>
    <iodef:Contact role="creator" type="organization">
      <iodef:ContactName>Constituency-contact for 192.0.2.35
      </iodef:ContactName>
      <iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
    </iodef:Contact>
    <iodef:EventData>
      <iodef:Flow>
        <iodef:System category="source">
          <iodef:Node>
            <iodef:Address category="ipv4-addr">192.0.2.35
            </iodef:Address>
          </iodef:Node>
          <iodef:Service ip_protocol="6">
            <iodef:Port>41421</iodef:Port>
          </iodef:Service>
        </iodef:System>
        <iodef:System category="target">
          <iodef:Node>
            <iodef:Address category="ipv4-addr">192.0.2.67
            </iodef:Address>
          </iodef:Node>
          <iodef:Service ip_protocol="6">
            <iodef:Port>80</iodef:Port>
          </iodef:Service>
        </iodef:System>
      </iodef:Flow>
      <iodef:Expectation severity="high" action="investigate">
        <iodef:Description>
          Investigate whether source has been compromised

Moriarty Standards Track [Page 52] RFC 6545 RID April 2012

        </iodef:Description>
      </iodef:Expectation>
    </iodef:EventData>
    <iodef:History>
      <iodef:HistoryItem action="block-host">
        <iodef:DateTime>2004-02-05T08:19:01+00:00</iodef:DateTime>
        <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
          CSIRT-FOR-OUR-DOMAIN#208-1
        </iodef:IncidentID>
        <iodef:Description>
          Investigation request sent to SP for 192.0.2.35
        </iodef:Description>
      </iodef:HistoryItem>
    </iodef:History>
  </iodef:Incident>
  </iodef:IODEF-Document>
     </iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
    </iodef-rid:ReportSchema>
  </iodef-rid:RIDPolicy>
</iodef-rid:RID>

7.2.2. Acknowledgement Message Example

 The example Acknowledgement message is in response to the Request
 listed above.  The SP that received the request was unable to
 validate the digital signature used to authenticate the sending RID
 system.
 <iodef-rid:RID lang="en"
                xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
                xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
   <iodef-rid:RIDPolicy MsgType="Acknowledgement"
                        MsgDestination="RIDSystem">
     <iodef-rid:PolicyRegion region="IntraConsortium"/>
     <iodef:Node>
       <iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
     </iodef:Node>
     <iodef-rid:TrafficType type="Attack"/>
     <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
       CERT-FOR-OUR-DOMAIN#208-1
     </iodef:IncidentID>
   </iodef-rid:RIDPolicy>
   <iodef-rid:RequestStatus AuthorizationStatus="Denied"
                            Justification="Authentication"/>
 </iodef-rid:RID>

Moriarty Standards Track [Page 53] RFC 6545 RID April 2012

7.3. Report Communication Flow

 The diagram below outlines the RID Report communication flow between
 RID systems on different SPs.
         SP-1                           SP-2
      1. Generate incident information
         and prepare Report message
      2.              o-------Report------->
      3.                          File report in database
                 Figure 10: Report Communication Flow
 The Report communication flow is used to provide information on
 incidents.  Incident information may be shared between CSIRTs or
 other entities using this format.  When a report is received, the RID
 system must verify that the report has not already been filed.  The
 incident number and incident data, such as the hexadecimal packet and
 incident class information, can be used to compare with existing
 database entries.  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 digital signature [RFC3275] or decrypt the
 request, an Acknowledgement message is sent to the requestor.  The
 Acknowledgement message should provide the reason why the message
 could not be processed.

7.3.1. Report Example

 The following example only includes the RID-specific details.  This
 report is an unsolicited Report message that includes an IPv4 packet.
 The IODEF document and digital signature is similar to the Request
 example with MsgDestination set to 'TraceRequest'.
 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
 attack that took place.
 <iodef-rid:RID lang="en"
                xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
                xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
   <iodef-rid:RIDPolicy MsgType="Report" MsgDestination="RIDSystem">
     <iodef-rid:PolicyRegion region="PeerToPeer"/>
     <iodef:Node>
       <iodef:Address category="ipv4-addr">192.0.2.130</iodef:Address>
     </iodef:Node>

Moriarty Standards Track [Page 54] RFC 6545 RID April 2012

     <iodef-rid:TrafficType type="Attack"/>
     <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
       CERT-FOR-OUR-DOMAIN#209-1
     </iodef:IncidentID>
 <!-- IODEF-Document included in RID -->
     <iodef-rid:ReportSchema>
      <iodef-rid:XMLDocument dtype="xml" meaning="xml">
   <iodef:IODEF-Document lang="en">
   <iodef:Incident restriction="need-to-know" purpose="reporting">
     <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
       CERT-FOR-OUR-DOMAIN#209-1
     </iodef:IncidentID>
     <iodef:DetectTime>2004-02-05T10:21:08+00:00</iodef:DetectTime>
     <iodef:StartTime>2004-02-05T10:21:05+00:00</iodef:StartTime>
     <iodef:EndTime>2004-02-05T10:35:00+00:00</iodef:EndTime>
     <iodef:ReportTime>2004-02-05T10:27:38+00:00</iodef:ReportTime>
     <iodef:Description>Host illicitly accessed admin account
     </iodef:Description>
     <iodef:Assessment>
       <iodef:Impact severity="high" completion="succeeded"
                     type="admin"/>
       <iodef:Confidence rating="high"/>
     </iodef:Assessment>
     <iodef:Contact role="creator" type="organization">
       <iodef:ContactName>Constituency-contact for 192.0.2.35
       </iodef:ContactName>
       <iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
     </iodef:Contact>
     <iodef:EventData>
       <iodef:Flow>
         <iodef:System category="source">
           <iodef:Node>
             <iodef:Address category="ipv4-addr">192.0.2.35
             </iodef:Address>
           </iodef:Node>
           <iodef:Service ip_protocol="6">
             <iodef:Port>32821</iodef:Port>
           </iodef:Service>
         </iodef:System>
         <iodef:System category="target">
           <iodef:Node>
             <iodef:Address category="ipv4-addr">192.0.2.67
             </iodef:Address>
           </iodef:Node>
           <iodef:Service ip_protocol="6">
             <iodef:Port>22</iodef:Port>
           </iodef:Service>
         </iodef:System>

Moriarty Standards Track [Page 55] RFC 6545 RID April 2012

       </iodef:Flow>
     </iodef:EventData>
     <iodef:History>
       <iodef:HistoryItem action="rate-limit-host">
         <iodef:DateTime>2004-02-05T10:28:00+00:00</iodef:DateTime>
         <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
           CSIRT-FOR-OUR-DOMAIN#209-1
         </iodef:IncidentID>
         <iodef:Description>
           Incident report sent to SP for 192.0.2.35
         </iodef:Description>
       </iodef:HistoryItem>
     </iodef:History>
   </iodef:Incident>
   </iodef:IODEF-Document>
      </iodef-rid:XMLDocument>
 <!-- End of IODEF-Document included in RID -->
   </iodef-rid:ReportSchema>
   </iodef-rid:RIDPolicy>
 </iodef-rid:RID>

7.4. Query Communication Flow

 The diagram below outlines the RID Query communication flow between
 RID systems on different networks.
         SP-1                           SP-2
      1. Generate a request for
         information on a specific
         incident number or incident type
      2.              o-------Query------->
      3.                              Verify policy information
                                      and determine if matches exist
                                      for requested information
      4.              <-------Report------o
      5.  Associate report to request
          by incident number or type
          and file report(s).
                  Figure 11: Query Communication Flow
 The Query message communication receives a response of a Report
 message.  If the Report message is empty, the responding host did not

Moriarty Standards Track [Page 56] RFC 6545 RID April 2012

 have information available to share with the requestor.  The incident
 number and responding RID system, as well as the transport, 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 the
 Query message, such as a failure to validate the digital signature or
 decrypt the request, an Acknowledgement message is sent to the
 requestor.  The Acknowledgement message should provide the reason why
 the message could not be processed.

7.4.1. Query Example

 The Query request may be received in several formats as a result of
 the type of query being performed.  If the incident number is the
 only information provided, the IODEF document and IP packet data may
 not be needed to complete the request.  However, if a type of
 incident is requested, the incident number remains NULL, and the IP
 packet data will not be included in the IODEF RecordItem class; the
 other incident information is the main source for comparison.  In the
 case in which an incident number may not be the same between CSIRTs,
 the incident number and/or IP packet information can be provided and
 used for comparison on the receiving RID system to generate (a)
 Report message(s).
 This query is sent to 192.0.2.3, inquiring about the incident with
 the identifier CERT-FOR-OUR-DOMAIN#210-1.  The Report will be
 provided to the requestor identified and verified through the
 authentication and digital signature information provided in the RID
 message.  An example Report is provided above.
 <iodef-rid:RID lang="en"
                xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
                xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
   <iodef-rid:RIDPolicy MsgType="Query"
                        MsgDestination="RIDSystem">
     <iodef-rid:PolicyRegion region="PeerToPeer"/>
     <iodef:Node>
       <iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
     </iodef:Node>
     <iodef-rid:TrafficType type="Attack"/>
     <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
       CERT-FOR-OUR-DOMAIN#210-1
     </iodef:IncidentID>
   </iodef-rid:RIDPolicy>
 </iodef-rid:RID>

Moriarty Standards Track [Page 57] RFC 6545 RID April 2012

8. RID Schema Definition

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"

xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="urn:ietf:params:xml:ns:iodef-rid-2.0"
elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0" schemaLocation="http://www.iana.org/assignments/xml-registry/schema/ iodef-1.0.xsd"/> <xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/xmldsig-core/ xmldsig-core-schema.xsd"/>

<!– * * Real-time Inter-network Defense - RID XML Schema * * Namespace - iodef-rid, April 2012 * * The namespace is defined to support transport of IODEF * * documents for exchanging incident information. * * –> <!–RID messages act as an envelope for IODEF and RID documents

   to support the exchange of incident information-->

<!–

Real-Time Inter-network Defense - RID

Suggested definition for RID messaging

<xs:annotation>

 <xs:documentation>XML Schema wrapper for IODEF</xs:documentation>

</xs:annotation> <xs:element name="RID" type="iodef-rid:RIDType"/>

 <xs:complexType name="RIDType">
   <xs:sequence>
     <xs:element ref="iodef-rid:RIDPolicy" minOccurs="0"/>
     <xs:element ref="iodef-rid:RequestStatus" minOccurs="0"/>
     <xs:element ref="iodef-rid:IncidentSource" minOccurs="0"/>
   </xs:sequence>
   <xs:attribute name="lang"
                  type="xs:language" use="required"/>
 </xs:complexType>

<!–Used in Acknowledgement Message for RID–>

Moriarty Standards Track [Page 58] RFC 6545 RID April 2012

<xs:element name="RequestStatus" type="iodef-rid:RequestStatusType"/>

 <xs:complexType name="RequestStatusType">
    <xs:attribute name="AuthorizationStatus" use="required">
       <xs:simpleType>
         <xs:restriction base="xs:NMTOKEN">
         <xs:whiteSpace value="collapse"/>
           <xs:enumeration value="Approved"/>
           <xs:enumeration value="Denied"/>
           <xs:enumeration value="Pending"/>
           <xs:enumeration value="ext-value"/>
         </xs:restriction>
       </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="ext-AuthorizationStatus"
                  type="xs:string" use="optional"/>
    <xs:attribute name="Justification">
       <xs:simpleType>
         <xs:restriction base="xs:NMTOKEN">
         <xs:whiteSpace value="collapse"/>
           <xs:enumeration value="SystemResource"/>
           <xs:enumeration value="Authentication"/>
           <xs:enumeration value="AuthenticationOrigin"/>
           <xs:enumeration value="Encryption"/>
           <xs:enumeration value="UnrecognizedFormat"/>
           <xs:enumeration value="CannotProcess"/>
           <xs:enumeration value="Other"/>
           <xs:enumeration value="ext-value"/>
         </xs:restriction>
       </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="ext-Justification"
                  type="xs:string" use="optional"/>
   <xs:attribute name="restriction" type="iodef:restriction-type"/>
 </xs:complexType>

<!–Incident Source Information for Result Message–>

<xs:element name="IncidentSource" type="iodef-rid:IncidentSourceType"/>

 <xs:complexType name="IncidentSourceType">
   <xs:sequence>
     <xs:element ref="iodef-rid:SourceFound"/>
     <xs:element ref="iodef:Node" minOccurs="0"
         maxOccurs="unbounded"/>
   </xs:sequence>
   <xs:attribute name="restriction" type="iodef:restriction-type"/>
 </xs:complexType>
 <xs:element name="SourceFound" type="xs:boolean"/>

Moriarty Standards Track [Page 59] RFC 6545 RID April 2012

<!–

Real-Time Inter-network Defense Policy - RIDPolicy

====== Definition for RIDPolicy for messaging

<xs:annotation>

<xs:documentation>RID Policy used for transport of
    messages</xs:documentation>

</xs:annotation>

<!– RIDPolicy information with setting information listed in RID

    documentation -->

<xs:element name="RIDPolicy" type="iodef-rid:RIDPolicyType"/>

 <xs:complexType name="RIDPolicyType">
   <xs:sequence>
     <xs:element ref="iodef-rid:PolicyRegion" maxOccurs="unbounded"/>
     <xs:element ref="iodef:Node"/>
     <xs:element ref="iodef-rid:TrafficType" maxOccurs="unbounded"/>
     <xs:element ref="iodef:IncidentID" minOccurs="0"/>
     <xs:element ref="iodef-rid:ReportSchema" minOccurs="0"/>
   </xs:sequence>
  <xs:attribute name="MsgType" use="required">
   <xs:simpleType>
     <xs:restriction base="xs:NMTOKEN">
     <xs:whiteSpace value="collapse"/>
       <xs:enumeration value="TraceRequest"/>
       <xs:enumeration value="Acknowledgement"/>
       <xs:enumeration value="Result"/>
       <xs:enumeration value="InvestigationRequest"/>
       <xs:enumeration value="Report"/>
       <xs:enumeration value="Query"/>
       <xs:enumeration value="ext-value"/>
     </xs:restriction>
   </xs:simpleType>
  </xs:attribute>
 <xs:attribute name="ext-MsgType" type="xs:string" use="optional"/>
 <xs:attribute name="MsgDestination" use="required">
   <xs:simpleType>
     <xs:restriction base="xs:NMTOKEN">
     <xs:whiteSpace value="collapse"/>
       <xs:enumeration value="RIDSystem"/>
       <xs:enumeration value="SourceOfIncident"/>
       <xs:enumeration value="ext-value"/>
     </xs:restriction>
   </xs:simpleType>
  </xs:attribute>
 <xs:attribute name="ext-MsgDestination" type="xs:string"

Moriarty Standards Track [Page 60] RFC 6545 RID April 2012

               use="optional"/>
 <xs:attribute name="restriction" type="iodef:restriction-type"/>
  </xs:complexType>
 <xs:element name="PolicyRegion">
   <xs:complexType>
    <xs:attribute name="region" use="required">
     <xs:simpleType>
      <xs:restriction base="xs:NMTOKEN">
      <xs:whiteSpace value="collapse"/>
        <xs:enumeration value="ClientToSP"/>
        <xs:enumeration value="SPToClient"/>
        <xs:enumeration value="IntraConsortium"/>
        <xs:enumeration value="PeerToPeer"/>
        <xs:enumeration value="BetweenConsortiums"/>
        <xs:enumeration value="ext-value"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="ext-region"
                  type="xs:string" use="optional"/>
   </xs:complexType>
 </xs:element>
 <xs:element name="TrafficType">
   <xs:complexType>
    <xs:attribute name="type" use="required">
     <xs:simpleType>
      <xs:restriction base="xs:NMTOKEN">
      <xs:whiteSpace value="collapse"/>
        <xs:enumeration value="Attack"/>
        <xs:enumeration value="Network"/>
        <xs:enumeration value="Content"/>
        <xs:enumeration value="DataWithHandlingRequirements"/>
        <xs:enumeration value="AudienceRestriction"/>
        <xs:enumeration value="Other"/>
        <xs:enumeration value="ext-value"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="ext-type"
                  type="xs:string" use="optional"/>
   </xs:complexType>
 </xs:element>

<!–Used to include an enveloped XML document in RID–> <xs:element name="ReportSchema" type="iodef-rid:ReportSchemaType"/>

 <xs:complexType name="ReportSchemaType">
   <xs:sequence>
     <xs:element ref="iodef-rid:XMLDocument" minOccurs="1"
                 maxOccurs="1"/>

Moriarty Standards Track [Page 61] RFC 6545 RID April 2012

     <xs:element ref="iodef-rid:URL" minOccurs="0"
                 maxOccurs="1"/>
     <xs:element ref="iodef-rid:Signature" minOccurs="0"
                 maxOccurs="unbounded"/>
   </xs:sequence>
    <xs:attribute name="Version" use="optional">
     <xs:simpleType>
      <xs:restriction base="xs:NMTOKEN">
      <xs:whiteSpace value="collapse"/>
        <xs:enumeration value="1.0"/>
             <xs:enumeration value="ext-value"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="ext-Version"
                  type="xs:string" use="optional"/>
    <xs:attribute name="XMLSchemaID" use="optional">
     <xs:simpleType>
      <xs:restriction base="xs:anyURI">
      <xs:whiteSpace value="collapse"/>
        <xs:enumeration value="urn:ietf:params:xml:ns:iodef-1.0"/>
             <xs:enumeration value="ext-value"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="ext-XMLSchemaID"
                  type="xs:string" use="optional"/>
   </xs:complexType>
 <xs:element name="XMLDocument"
             type="iodef:ExtensionType"/>
 <xs:element name="URL"
             type="xs:anyURI"/>
 <xs:element name="Signature"
             type="iodef:ExtensionType"/>

</xs:schema>

9. Security Requirements

9.1. XML Digital Signatures and Encryption

 RID leverages existing security standards and data markings in
 RIDPolicy to achieve the required levels of security for the exchange
 of incident information.  The use of standards includes TLS and the
 XML security features of encryption [XMLencrypt] and digital
 signatures [RFC3275] [XMLsig].  The standards provide clear methods
 to ensure that messages are secure, authenticated, and authorized;
 meet policy and privacy guidelines; and maintain integrity.  XML

Moriarty Standards Track [Page 62] RFC 6545 RID April 2012

 Signature Best Practices [XMLSigBP] should be referenced by
 implementers for information on improving security to mitigate
 attacks.
 As specified in the relevant sections of this document, the XML
 digital signature [RFC3275] and XML encryption [XMLencrypt] are used
 in the following cases:
 XML Digital Signature
 o  The originator of a Request MUST use a detached signature to sign
    at least one of the original elements contained in the RecordItem
    class to provide authentication to all upstream participants in
    the trace or those involved in the investigation.  All instances
    of RecordItem provided by the originator may be individually
    signed, and additional RecordItem entries by upstream peers in the
    trace or investigation may be signed by the peer adding the data,
    while maintaining the original RecordItem entry(s) and detached
    signature(s) from the original requestor.  It is important to note
    that the data is signed at the RecordItem level.  Since multiple
    RecordItems may exist within an IODEF document and may originate
    from different sources, the signature is applied at the RecordItem
    level to enable the use of an XML detached signature.  Exclusive
    canonicalization [XMLCanon] is REQUIRED for the detached signature
    and not the references, as the XML document generated is then
    included in the RID message within the Signature element of the
    ReportSchema class.  This signature MUST be passed to all
    recipients of the Request message.
 o  If a Request does not include a RecordItem entry, a timestamp MUST
    be used to ensure there is data to be signed for the multi-hop
    authentication use case.  The DateTime element of the iodef:
    RecordData class ([RFC5070], Section 3.19.1) is used for this
    purpose.
 o  For all message types, the full IODEF-RID document MUST be signed
    using an enveloped signature by the sending peer to provide
    authentication and integrity to the receiving RID system.  The
    signature is placed in an instance of the Signature element.
 o  XML Signature Best Practices [XMLSigBP] guidance SHOULD be
    followed to prevent or mitigate security risks.  Examples include
    the recommendation to authenticate a signature prior to processing
    (executing potentially dangerous operations) and the
    recommendation to limit the use of URIs since they may enable
    cross-site scripting attacks or access to local information.

Moriarty Standards Track [Page 63] RFC 6545 RID April 2012

 o  XML Path Language (XPath) 2.0 [XMLPath] MUST be followed to
    specify the portion of the XML document to be signed.  XPath is
    used to specify a location within an XML document.  Best practice
    recommendations for using XPath [XMLSigBP] SHOULD be referenced to
    reduce the risk of denial-of-service attacks.  The use of XSLT
    transforms MUST be restricted according to security guidance in
    [XMLSigBP].
 XML Encryption
 o  The IODEF-RID document MAY be encrypted to provide an extra layer
    of security between peers so that not only the message is
    encrypted for transport.  This behavior would be agreed upon
    between peers or a consortium, or determined on a per-message
    basis, depending on security requirements.  It should be noted
    that there are cases for transport where the RIDPolicy class needs
    to be presented in clear text, as detailed in the transport
    document [RFC6546].
 o  A Request, or any other message type that may be relayed through
    RID systems before reaching the intended destination as a result
    of trust relationships, MAY be encrypted specifically for the
    intended recipient.  This may be necessary if the RID network is
    being used for message transfer, the intermediate parties do not
    need to have knowledge of the request contents, and a direct
    communication path does not exist.  In that case, the RIDPolicy
    class is used by intermediate parties and as such, RIDPolicy is
    maintained in clear text.
 o  The action taken in the Result message may be encrypted using the
    key of the request originator.  In that case, the intermediate
    parties can view the RIDPolicy information and know the trace has
    been completed and do not need to see the action.  If the use of
    encryption were limited to sections of the message, the History
    class information would be encrypted.  Otherwise, it is
    RECOMMENDED to encrypt the entire IODEF-RID document and use an
    enveloped signature for the originator of the request.  The
    existence of the Result message for an incident would tell any
    intermediate parties used in the path of the incident
    investigation that the incident handling has been completed.
 o  The iodef:restriction attribute sets expectations for the privacy
    of an incident and is defined in Section 3.2 of RFC 5070.
    Following the guidance for XML encryption in the Security
    Requirements section, the iodef:restriction attribute can be set
    in any of the RID classes to define restrictions and encryption
    requirements for the exchange of incident information.  The
    restriction options enable encryption capabilities for the

Moriarty Standards Track [Page 64] RFC 6545 RID April 2012

    complete exchange of an IODEF document (including any extensions),
    within specific classes of IODEF, or IODEF extensions, where more
    limited restrictions are desired.  The restriction attribute is
    contained in each of the RID classes and MUST be used in
    accordance with confidentiality expectations for either sections
    of the IODEF document or the complete IODEF document.  Consortiums
    and organizations should consider this guidance when creating
    exchange policies.
 o  Expectations based on how restriction is set:
  • If restriction is set to 'private', the class or document MUST

be encrypted for the recipient using XML encryption and the

       public key of the recipient.  See Section 9.3 for a discussion
       on public key infrastructure (PKI) and other security
       requirements.
  • If restriction is set to 'need-to-know', the class or document

MUST be encrypted to ensure only those with need-to-know access

       can decrypt the data.  The document can either be encrypted for
       each individual for which access is intended or be encrypted
       with a single group key.  The method used SHOULD adhere to any
       certificate policy and practices agreements between entities
       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
       data.  The users with need-to-know access privileges may be
       given access to the shared key via a secure distribution
       method, for example, providing access to the symmetric key
       encrypted with each of the user's public keys.
  • If restriction is set to 'public', the class or document MUST

be sent in clear text. This setting can be critical if certain

       sections of a document or an entire document are to be shared
       without restrictions.  This provides flexibility within an
       incident to share certain information freely where appropriate.
  • If restriction is set to 'default', the information can be

shared according to an information disclosure policy pre-

       arranged by the communicating parties.
 o  Expectations based on placement of the restriction setting:
  • If restriction is set within one of the RID classes, the

restriction applies to the entire IODEF document.

  • If restriction is set within individual IODEF classes, the

restriction applies to the specific IODEF class and the

       children of that class.

Moriarty Standards Track [Page 65] RFC 6545 RID April 2012

 The formation of policies is a very important aspect of using a
 messaging system like RID to exchange potentially sensitive
 information.  Many considerations should be involved for peering
 parties, and some guidelines to protect the data, systems, and
 transport are covered in this section.  Policies established should
 provide guidelines for communication methods, security, and fall-back
 procedures.  See Sections 9.4 and 9.5 for additional information on
 consortiums and PKI considerations.
 The security considerations for the storage and exchange of
 information in RID messaging may include adherence to local,
 regional, or national regulations in addition to the obligations to
 protect client information during an investigation.  RIDPolicy is a
 necessary tool for listing the requirements of messages to provide a
 method to categorize data elements for proper handling.  Controls are
 also provided for the sending entity to protect messages from third
 parties through XML encryption.
 RID provides a method to exchange incident-handling requests and
 Report messages between entities.  Administrators have the ability to
 base decisions on the available resources and other factors of their
 network and maintain control of incident investigations within their
 own network.  Thus, RID provides the ability for participating
 networks to manage their own security controls, leveraging the
 information listed in RIDPolicy.
 RID is used to transfer or exchange XML documents in an IODEF format
 or using another IANA-registered format.  Implementations SHOULD NOT
 download schemas at runtime due to the security implications, and
 included documents MUST NOT be required to provide a resolvable
 location of their schema.

9.2. Message Transport

 A transport specification is defined in a separate document
 [RFC6546].  The specified transport protocols MUST use encryption to
 provide an additional level of security and integrity, while
 supporting mutual authentication through bidirectional certificate
 usage.  Any subsequent transport method defined should take advantage
 of existing standards for ease of implementation and integration of
 RID systems.  Session encryption for the transport of RID messages is
 enforced in the transport specification.  The privacy and security
 considerations are addressed fully in RID to protect sensitive
 portions of documents and to provide a method to authenticate the
 messages.  Therefore, RID messages do not rely on the security
 provided by the transport layer alone.  The encryption requirements
 and considerations for RID messages are discussed in Section 9.1 of
 this document.

Moriarty Standards Track [Page 66] RFC 6545 RID April 2012

 Consortiums may vary their selected transport mechanisms and thus
 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
 [RFC6546] and optionally MAY support other protocols such as the
 Blocks Extensible Exchange Protocol (BEEP) [RFC3080].  Bindings would
 need to be defined to enable support for other transport protocols.
 Systems used to send authenticated RID messages between networks MUST
 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
 requirements agreed upon through the consortium regulations, peering,
 or SLAs.  The RID system MUST listen for and send RID messages on
 only the designated port, which also MUST be over an encrypted tunnel
 meeting the minimum requirement of algorithms and key lengths
 established by the consortium, peering, or SLA.  The selected
 cryptographic algorithms for symmetric encryption, digital
 signatures, and hash functions MUST meet minimum security levels of
 the times.  The encryption strength MUST adhere to import and export
 regulations of the involved countries for data exchange.
 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.

9.3. Public Key Infrastructure

 It is RECOMMENDED that RID, the XML security functions, and transport
 protocols properly integrate with a PKI managed by the consortium,
 federate PKIs within a consortium, or use a PKI managed by a trusted
 third party.  Entities MAY use shared keys as an alternate solution,
 although this may limit the ability to validate certificates and
 could introduce risk.  For the Internet, a few examples of existing
 efforts that could be leveraged to provide the supporting PKI include
 the Regional Internet Registry's (RIR's) PKI hierarchy, vendor issued
 certificates, or approved issuers of Extended Validation (EV)
 Certificates.  Security and privacy considerations related to
 consortiums are discussed in Sections 9.4 and 9.5.
 The use of PKI between entities or by a consortium SHOULD adhere to
 any applicable certificate policy and practices agreements for the
 use of RID.  [RFC3647] specifies a commonly used format for

Moriarty Standards Track [Page 67] RFC 6545 RID April 2012

 certificate policy (CP) and certification practices statements (CPS).
 Systems with predefined relationships for RID include those who peer
 directly or through a consortium with agreed-upon appropriate use
 agreements.  The agreements to trust other entities may be based on
 assurance levels that could be determined by a comparison of the CP,
 CPS, and/or RID operating procedures.  The initial comparison of
 policies and the ability to audit controls provide a baseline
 assurance level for entities to form and maintain trust
 relationships.  Trust relationships may also be defined through a
 bridged or hierarchical PKI in which both peers belong.  If shared
 keys or keys issued from a common CA are used, the verification of
 controls to determine the assurance level to trust other entities may
 be limited to the RID policies and operating procedures.
 XML security functions utilized in RID require a trust center such as
 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 service providers.  The PKI used for
 authentication also provides the necessary certificates needed for
 encryption used for the RID transport protocol [RFC6546].

9.3.1. Authentication

 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
 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
 version 3 specifications as well as the digital signature
 specifications and path validation standards set forth in [RFC5280]
 MUST be followed in order to interoperate with a PKI designed for
 similar purposes.  Full path validation verifies the chaining
 relationship to a trusted root and also performs a certificate
 revocation check.  The use of digital signatures in RID XML messages
 MUST follow the World Wide Web Consortium (W3C) recommendations for
 signature syntax and processing when either the XML encryption
 [XMLencrypt] or digital signature [XMLsig] [RFC3275] is used within a
 document.

Moriarty Standards Track [Page 68] RFC 6545 RID April 2012

 It might be helpful to define an extension to the authentication
 scheme that uses attribute certificates [RFC5755] in such a way that
 an application could automatically determine whether human
 intervention is needed to authorize a request; however, the
 specification of such an extension is out of scope for this document.
 The use of pre-shared keys may be considered for authentication at
 the 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 [RFC6546].

9.3.2. Multi-Hop Request Authentication

 The use of multi-hop authentication in a Request is used when a
 Request is sent to multiple entities or SPs in an iterative manner.
 Multi-hop authentication is REQUIRED in Requests that involve
 multiple SPs where Requests are forwarded iteratively through peers.
 Bilateral trust relationships MAY be used between peers; 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, SPs may want to prioritize incident-handling
 events based upon the immediate peer for a Request, 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 a
 Request, the originating RID system is included in the Request 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, which nests 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 Request 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
 digital signature specifications from W3C [XMLsig] using a detached
 signature.  The signature MUST be passed to all parties that receive
 a Request, and each party MUST be able to perform full path
 validation on the digital signature [RFC5280].  In order to
 accommodate that requirement, the RecordItem data MUST remain
 unchanged as a request is passed along between providers and is the
 only element for which the signature is applied.  If additional
 RecordItems are included in the document at upstream peers, the
 initial RecordItem entry MUST still remain with the detached
 signature.  The subsequent RecordItem elements may be signed by the
 peer adding the incident information for the investigation.  A second

Moriarty Standards Track [Page 69] RFC 6545 RID April 2012

 benefit to this requirement is that the integrity of the filter used
 is ensured as it is passed to subsequent SPs in the upstream trace of
 the incident.  The trusted PKI also provides the keys used to
 digitally sign the RecordItem class for a Request to meet the
 requirement of authenticating the original request.  Any host in the
 path of the trace should be able to verify the digital signature
 using the trusted PKI.
 In the case in which an enterprise using RID sends a Request to its
 provider, the signature from the enterprise MUST be included in the
 initial request.  The SP may generate a new request to send upstream
 to members of the SP consortium to continue the investigation.  If
 the original request is sent, the originating SP, acting on behalf of
 the enterprise network under attack, MUST also digitally sign, with
 an enveloped signature, the full IODEF document to assure the
 authenticity of the Request.  An SP that offers RID as a service may
 be using its own PKI to secure RID communications between its RID
 system and the attached enterprise networks.  SPs participating in
 the trace MUST be able to determine the authenticity of RID requests.

9.4. Consortiums and Public Key Infrastructures

 Consortiums are an ideal way to establish a communication web of
 trust for RID messaging.  It should be noted that direct
 relationships may be ideal for some communications, such as those
 between a provider of incident information and a subscriber of the
 incident reports.  The consortium could provide centralized
 resources, such as a PKI, and established guidelines and control
 requirements for use of RID.  The consortium may assist in
 establishing trust relationships between the participating SPs to
 achieve the necessary level of cooperation and experience-sharing
 among the consortium entities.  This may be established through PKI
 certificate policy [RFC3647] reviews to determine the appropriate
 trust levels between organizations or entities.  The consortium may
 also be used for other purposes to better facilitate communication
 among SPs in a common area (Internet, region, government, education,
 private networks, etc.).
 Using a PKI to distribute certificates used by RID systems provides
 an already established method to link trust relationships between
 consortiums that peer with SPs belonging to a separate consortium.
 In other words, consortiums could peer with other consortiums to
 enable communication of RID messages between the participating SPs.
 The PKI along with Memorandums of Agreement could be used to link
 border directories to share public key information in a bridge, a
 hierarchy, or a single cross-certification relationship.

Moriarty Standards Track [Page 70] RFC 6545 RID April 2012

 Consortiums also need to establish guidelines for each participating
 SP to adhere to.  The RECOMMENDED guidelines include:
 o  Physical and logical practices to protect RID systems;
 o  Network- and application-layer protection for RID systems and
    communications;
 o  Proper use guidelines for RID systems, messages, and requests; and
 o  A PKI, certificate policy, and certification practices statement
    to provide authentication, integrity, and privacy.
 The functions described for a consortium's role parallel those of a
 PKI federation.  The PKI federations that currently exist are
 responsible for establishing security guidelines and PKI trust
 models.  The trust models are used to support applications to share
 information using trusted methods and protocols.
 A PKI can also provide the same level of security for communication
 between an end entity (enterprise, educational, or government
 customer network) and the SP.

9.5. Privacy Concerns and System Use Guidelines

 Privacy issues raise many concerns when information-sharing is
 required to achieve the goal of stopping or mitigating the effects of
 a security incident.  The RIDPolicy class is used to automate the
 enforcement of the privacy concerns listed within this document.  The
 privacy and system use concerns for the system communicating RID
 messages and other integrated components include the following:
 Service Provider Concerns:
 o  Privacy of data monitored and/or stored on Intrusion Detection
    Systems (IDSs) for attack detection.
 o  Privacy of data monitored and stored on systems used to trace
    traffic across a single network.
 o  Privacy of incident information stored on incident management
    systems participating in RID communications.
 Customer Attached Networks Participating in RID with SP:
 o  Customer networks may include enterprise, educational, government,
    or other networks attached to an SP participating in RID.
    Customers should review data handling policies to understand how

Moriarty Standards Track [Page 71] RFC 6545 RID April 2012

    data will be protected by a service provider.  This information
    will enable customers to decide what types of data at what
    sensitivity level can be shared with service providers.  This
    information could be used at the application layer to establish
    sharing profiles for entities and groups; see Section 9.6.
 o  Customers should request information on the security and privacy
    considerations in place by their SP and the consortium of which
    the SP is a member.  Customers should understand if their data
    were to be forwarded, how it might be sanitized and how it will be
    protected.  In advance of sharing data with their SP, customers
    should also understand if limitations can be placed on how it will
    be used.
 o  Customers should be aware that their data can and will be sent to
    other SPs in order to complete a trace unless an agreement stating
    otherwise is made in the service level agreements between the
    customer and SP.  Customers considering privacy options may limit
    the use of this feature if they do not want the data forwarded.
 Parties Involved in the Attack:
 o  Privacy of the identity of a host involved in an attack or any
    indicators of compromise.
 o  Privacy of information such as the source and destination used for
    communication purposes over the monitored or RID-connected
    network(s).
 o  Protection of data from being viewed by intermediate parties in
    the path of an Request request should be considered.
 Consortium Considerations:
 o  System use restrictions for security incident handling within the
    local region's definitions of appropriate traffic.  When
    participating in a consortium, appropriate use guidelines should
    be agreed upon and entered into contracts.
 o  System use prohibiting the consortium's participating SPs from
    inappropriately tracing traffic to locate sources or mitigate
    traffic unlawfully within the jurisdiction or region.
 Inter-Consortium Considerations:
 o  System use between peering consortiums should consider any
    government communication regulations that apply between those two
    regions, such as encryption export and import restrictions.

Moriarty Standards Track [Page 72] RFC 6545 RID April 2012

 o  System use between consortiums SHOULD NOT request traffic traces
    and actions beyond the scope intended and permitted by law or
    inter-consortium agreements.
 o  System use between consortiums should consider national boundary
    issues and request limits in their appropriate system use
    agreements.  Appropriate use should include restrictions to
    prevent the use of the protocol for limiting or restricting
    traffic that is otherwise permitted within the country in which
    the peering consortium resides.
 The security and privacy considerations listed above are for the
 consortiums, SPs, and enterprises to agree upon.  The agreed-upon
 policies may be facilitated through use of the RIDPolicy class and
 application-layer options.  Some privacy considerations are addressed
 through the RID guidelines for encryption and digital signatures as
 described in Section 9.1.
 RID is useful in determining the true source of an incident that
 traverses multiple networks or to communicate security incidents and
 automate the response.  The information obtained from the
 investigation may determine the identity of the source host or the SP
 used by the source of the traffic.  It should be noted that the trace
 mechanism used across a single SP may also raise privacy concerns for
 the clients of the network.  Methods that may raise concern include
 those that involve storing packets for some length of time in order
 to trace packets after the fact.  Monitoring networks for intrusions
 and for tracing capabilities also raises concerns for potentially
 sensitive valid traffic that may be traversing the monitored network.
 IDSs and single-network tracing are outside of the scope of this
 document, but the concern should be noted and addressed within the
 use guidelines of the network.  Some IDSs and single-network trace
 mechanisms attempt to properly address these issues.  RID is designed
 to provide the information needed by any single-network trace
 mechanism.  The provider's choice of a single trace mechanism depends
 on resources, existing solutions, and local legislation.  Privacy
 concerns in regard to the single-network trace must be dealt with at
 the client-to-SP level and are out of scope for RID messaging.
 The identity of the true source of an attack being traced through RID
 could be sensitive.  The true identity listed in a Result message can
 be protected through the use of encryption [XMLencrypt] enveloping
 the IODEF document and RID Result information, using the public
 encryption key of the originating SP.  Alternatively, the action
 taken may be listed without the identity being revealed to the
 originating SP.  The ultimate goal of the RID communication system is
 to stop or mitigate attack traffic, not to ensure that the identity
 of the attack traffic is known to involved parties.  The SP that

Moriarty Standards Track [Page 73] RFC 6545 RID April 2012

 identifies the source should deal directly with the involved parties
 and proper authorities in order to determine the guidelines for the
 release of such information, if it is regarded as sensitive.  In some
 situations, systems used in attacks are compromised by an unknown
 source and, in turn, are used to attack other systems.  In that
 situation, the reputation of a business or organization may be at
 stake, and the action taken may be the only additional information
 reported in the Result message to the originating system.  If the
 security incident is a minor incident, such as a zombie system used
 in part of a large-scale DDoS attack, ensuring the system is taken
 off the network until it has been fixed may be sufficient.  The
 decision is left to the system users and consortiums to determine
 appropriate data to be shared given that the goal of the
 specification is to provide the appropriate technical options to
 remain compliant.  The textual descriptions should include details of
 the incident in order to protect the reputation of the unknowing
 attacker and prevent the need for additional investigation.  Local,
 state, or national laws may dictate the appropriate reporting action
 for specific security incidents.
 Privacy becomes an issue whenever sensitive data traverses a network.
 For example, if an attack occurred between a specific source and
 destination, then every SP in the path of the trace becomes aware
 that the cyber attack occurred.  In a targeted attack, it may not be
 desirable that information about two nation states that are battling
 a cyber war would become general knowledge to all intermediate
 parties.  However, it is important to allow the traces to take place
 in order to halt the activity since the health of the networks in the
 path could also be at stake during the attack.  This provides a
 second argument for allowing the Result message to only include an
 action taken and not the identity of the offending host.  In the case
 of a Request or Report, where the originating SP is aware of the SP
 that will receive the request for processing, the free-form text
 areas of the document could be encrypted [XMLencrypt] using the
 public key of the destination SP to ensure that no other SP in the
 path can read the contents.  The encryption is accomplished through
 the W3C [XMLencrypt] specification for encrypting an element.
 In some situations, all network traffic of a nation may be granted
 through a single SP.  In that situation, options must support sending
 Result messages from a downstream peer of that SP.  That option
 provides an additional level of abstraction to hide the identity and
 the SP of the identified source of the traffic.  Legal action may
 override this technical decision after the trace has taken place, but
 that is out of the technical scope of this document.

Moriarty Standards Track [Page 74] RFC 6545 RID April 2012

 Privacy concerns when using an Request message to request action
 close to the source of valid attack traffic need to be considered.
 Although the intermediate SPs may relay the request if there is no
 direct trust relationship to the closest SP to the source, the
 intermediate SPs do not require the ability to see the contents of
 the packet or the text description field(s) in the request.  This
 message type does not require any action by the intermediate RID
 systems, except to relay the packet to the next SP in the path.
 Therefore, the contents of the request may be encrypted for the
 destination system.  The intermediate SPs only need to know how to
 direct the request to the manager of the ASN in which the source IP
 address belongs.
 Traces must be legitimate security-related incidents and not used for
 purposes such as sabotage or censorship.  An example of such abuse of
 the system includes a request to block or 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.
 Intra-consortium RID communications raise additional issues,
 especially when the peering consortiums reside in different regions
 or nations.  Request messages and requested actions to mitigate or
 stop traffic must adhere to the appropriate use guidelines and yet
 prevent abuse of the system.  First, the peering consortiums must
 identify the types of traffic that can be traced between the borders
 of the participating SPs of each consortium.  The traffic traced
 should be limited to security-incident-related traffic.  Second, the
 traces permitted within one consortium, if passed to a peering
 consortium, may infringe upon the peering consortium's freedom-of-
 information laws.  An example would be a consortium in one country
 permitting a trace of traffic containing objectionable material,
 outlawed within that country.  The RID trace may be a valid use of
 the system within the confines of that country's network border;
 however, it may not be permitted to continue across network
 boundaries where such content is permitted under law.  By continuing
 the trace in another country's network, the trace and response could
 have the effect of improperly restricting access to data.  A
 continued trace into a second country may break the laws and
 regulations of that nation.  Any such traces MUST cease at the
 country's border.
 The privacy concerns listed in this section address issues among the
 trusted parties involved in a trace within an SP, a RID consortium,
 and peering RID consortiums.  Data used for RID communications must
 also be protected from parties that are not trusted.  This protection
 is provided through the authentication and encryption of documents as

Moriarty Standards Track [Page 75] RFC 6545 RID April 2012

 they traverse the path of trusted servers and through the local
 security controls in place for the incident management systems.  Each
 RID system MUST perform a bidirectional authentication when sending a
 RID message 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 document is decrypted and re-encrypted at each RID
 system via TLS over a transport protocol such as [RFC6546].  The RID
 messages may be decrypted at each RID system in order to properly
 process the request or relay the information.  Today's processing
 power is more than sufficient to handle the minimal burden of
 encrypting and decrypting relatively small typical RID messages.

9.6. Sharing Profiles and Policies

 The application layer can be used to establish workflows and rulesets
 specific to sharing profiles for entities or consortiums.  The
 profiles can leverage sharing agreements to restrict data types or
 classifications of data that are shared.  The level of information or
 classification of data shared with any entity may be based on
 protection levels offered by the receiving entity and periodic
 validation of those controls.  The profile may also indicate how far
 information can be shared according to the entity and data type.  The
 profile may also indicate whether requests to share data from an
 entity must go directly to that entity.
 In some cases, pre-defined sharing profiles will be possible.  These
 include any use case where an agreement is in place in advance of
 sharing.  Examples may be between clients and SPs, entities such as
 partners, or consortiums.  There may be other cases when sharing
 profiles may not be established in advance, such as an organization
 dealing with an incident who requires assistance from an entity that
 it has not worked with before.  An organization may want to establish
 sharing profiles specific to possible user groups to prepare for
 possible incident scenarios.  The user groups could include business
 partners, industry peers, service providers, experts not part of a
 service provider, law enforcement, or regulatory reporting bodies.
 Workflows to approve transactions may be specific to sharing profiles
 and data types.  Application developers should include capabilities
 to enable these decision points for users of the system.
 Any expectations between entities to preserve the weight and
 admissibility of evidence should be handled at the policy and
 agreement level.  A sharing profile may include notes or an indicator
 for approvers in workflows to reflect if such agreements exist.

Moriarty Standards Track [Page 76] RFC 6545 RID April 2012

10. Security Considerations

 RID has many security requirements and considerations built into the
 design of the protocol, several of which are described in the
 Security Requirements section.  For a complete view of security,
 considerations include the availability, confidentiality, and
 integrity concerns for the transport, storage, and exchange of
 information.
 Protected tunnels between systems accepting RID communications are
 used to provide confidentiality, integrity, authenticity, and privacy
 for the data at the transport layer.  Encryption and digital
 signatures are also used at the IODEF document level through RID
 options to provide confidentiality, integrity, authenticity, privacy
 and traceability of the document contents at the application layer.
 Trust relationships are based on PKI and the comparison/validation of
 security controls for the incident management systems communicating
 via RID.  Trust levels can be established in cross-certification
 processes where entities compare PKI policies that include the
 specific management and handling of an entity's PKI and certificates
 issued under that policy.  [RFC3647] defines an Internet X.509 Public
 Key Infrastructure Certificate Policy and Certification Practices
 Framework that may be used in the comparison of policies to establish
 trust levels and agreements between entities, an entity and a
 consortium, and consortiums.  The agreements SHOULD consider key
 management practices including the ability to perform path validation
 on certificates [RFC5280], key distribution techniques [RFC2585], and
 Certificate Authority and Registration Authority management
 practices.
 The agreements between entities SHOULD also include a common
 understanding of the usage of RID security, policy, and privacy
 options discussed in both the Security Requirements and Security
 Considerations sections.  The formality, requirements, and complexity
 of the agreements for the certificate policy, practices, supporting
 infrastructure, and the use of RID options SHOULD be decided by the
 entities or consortiums creating those agreements.

11. Internationalization Issues

 The Node class identifies a host or network device.  This document
 reuses the definition of Node from the IODEF specification [RFC5070],
 Section 3.16.  However, that document did not clearly specify whether
 a NodeName could be an Internationalized Domain Name (IDN).  RID
 systems MUST treat the NodeName class as a domain name slot
 [RFC5890].  RID systems SHOULD support IDNs in the NodeName class.
 If they do so, the UTF-8 representation of the domain name MUST be
 used, i.e., all of the domain name's labels MUST be U-labels

Moriarty Standards Track [Page 77] RFC 6545 RID April 2012

 expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be
 used.  An application communicating via RID can convert between
 A-labels and U-labels by using the Punycode encoding [RFC3492] for
 A-labels as described in the protocol specification for
 Internationalized Domain Names in Applications [RFC5891].

12. IANA Considerations

 This document uses URNs to describe XML namespaces and XML schemas
 [XMLschema] conforming to a registry mechanism described in
 [RFC3688].
 Registration request for the iodef-rid namespace:
    URI: urn:ietf:params:xml:ns:iodef-rid-2.0
    Registrant Contact: IESG.
    XML: None.  Namespace URIs do not represent an XML specification.
 Registration request for the iodef-rid XML schema:
    URI: urn:ietf:params:xml:schema:iodef-rid-2.0
    Registrant Contact: IESG.
    XML: See Section 8, "RID Schema Definition", of this document.
 The following registry has been created and is now managed by IANA:
    Name of the registry: "XML Schemas Exchanged via RID"
    Namespace details: A registry entry for an XML Schema Transferred
    via RID consists of:
       Schema Name: A short string that represents the schema
       referenced.  This value is for reference only in the table.
       The version of the schema MUST be included in this string to
       allow for multiple versions of the same specification to be in
       the registry.
       Version: The version of the registered XML schema.  The version
       is a string that SHOULD be formatted as numbers separated by a
       '.' (period) character.

Moriarty Standards Track [Page 78] RFC 6545 RID April 2012

       Namespace: The namespace of the referenced XML schema.  This is
       represented in the RID ReportSchema class in the XMLSchemaID
       attribute as an enumerated value is represented by a URN or
       URI.
       Specification URI: A URI [RFC3986] from which the registered
       specification can be obtained.  The specification MUST be
       publicly available from this URI.
       Reference: The reference to the document that describes the
       schema.
    Information that must be provided to assign a new value: The above
    list of information.
    Fields to record in the registry: Schema Name, Version, Namespace,
    Specification URI, Reference
    Initial registry contents: See Section 5.6.1.
    Allocation Policy: Expert Review [RFC5226] and Specification
    Required [RFC5226].
 The Designated Expert is expected to consult with the MILE (Managed
 Incident Lightweight Exchange) working group or its successor if any
 such WG exists (e.g., via email to the working group's mailing list).
 The Designated Expert is expected to retrieve the XML schema
 specification from the provided URI in order to check the public
 availability of the specification and verify the correctness of the
 URI.  An important responsibility of the Designated Expert is to
 ensure that the XML schema is appropriate for use in RID.
 The following registry has been created and is now managed by IANA:
    Name of the registry: "RID Enumeration List"
    The registry is intended to enable enumeration value additions to
    attributes in the iodef-rid XML schema.
    Fields to record in the registry: Attribute Name, Attribute Value,
    Description, Reference
    Initial registry content: none.
    Allocation Policy: Expert Review [RFC5226]

Moriarty Standards Track [Page 79] RFC 6545 RID April 2012

 The Designated Expert is expected to consult with the MILE (Managed
 Incident Lightweight Exchange) working group or its successor if any
 such WG exists (e.g., via email to the working group's mailing list).
 The Designated Expert is expected to review the request and validate
 the appropriateness of the enumeration for the attribute.  If a
 specification is associated with the request, it MUST be reviewed by
 the Designated Expert.

13. Summary

 Security incidents have always been difficult to trace as a result of
 spoofed sources, resource limitations, and bandwidth utilization
 problems.  Incident response is often slow even when the IP address
 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
 attack traffic.  Methods to identify and trace attacks near real time
 are essential to thwarting attack attempts.  SPs need policies and
 automated methods to combat the hacker's efforts.  SPs need automated
 monitoring and response capabilities to identify and trace attacks
 quickly without resource-intensive side effects.  Integration with a
 centralized communication system to coordinate the detection,
 tracing, and identification of attack sources on a single network is
 essential.  RID provides a way to integrate SP resources for each
 aspect of attack detection, tracing, and source identification and
 extends the communication capabilities among SPs.  The communication
 is accomplished through the use of flexible IODEF XML-based documents
 passed between incident-handling systems or RID systems.  A Request
 is communicated 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 among peers with security inherent to the RID
 messaging scheme provided through existing standards such as XML
 encryption and digital signatures.  Policy information is carried in
 the RID message itself through the use of the RIDPolicy.  RID
 provides the timely communication among SPs, which is essential for
 incident handling.

14. References

14.1. Normative References

 [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2585]     Housley, R. and P. Hoffman, "Internet X.509 Public Key
               Infrastructure Operational Protocols: FTP and HTTP",
               RFC 2585, May 1999.

Moriarty Standards Track [Page 80] RFC 6545 RID April 2012

 [RFC3023]     Murata, M., St. Laurent, S., and D. Kohn, "XML Media
               Types", RFC 3023, January 2001.
 [RFC3275]     Eastlake, D., Reagle, J., and D. Solo, "(Extensible
               Markup Language) XML-Signature Syntax and Processing",
               RFC 3275, March 2002.
 [RFC3470]     Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines
               for the Use of Extensible Markup Language (XML)
               within IETF Protocols", BCP 70, RFC 3470, January 2003.
 [RFC3492]     Costello, A., "Punycode: A Bootstring encoding of
               Unicode for Internationalized Domain Names in
               Applications (IDNA)", RFC 3492, March 2003.
 [RFC3688]     Mealling, M., "The IETF XML Registry", BCP 81,
               RFC 3688, January 2004.
 [RFC4051]     Eastlake, D., "Additional XML Security Uniform Resource
               Identifiers (URIs)", RFC 4051, April 2005.
 [RFC4279]     Eronen, P. and H. Tschofenig, "Pre-Shared Key
               Ciphersuites for Transport Layer Security (TLS)",
               RFC 4279, December 2005.
 [RFC5070]     Danyliw, R., Meijer, J., and Y. Demchenko, "The
               Incident Object Description Exchange Format", RFC 5070,
               December 2007.
 [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
               an IANA Considerations Section in RFCs", BCP 26,
               RFC 5226, May 2008.
 [RFC5280]     Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
               Housley, R., and W. Polk, "Internet X.509 Public Key
               Infrastructure Certificate and Certificate Revocation
               List (CRL) Profile", RFC 5280, May 2008.
 [RFC5646]     Phillips, A. and M. Davis, "Tags for Identifying
               Languages", BCP 47, RFC 5646, September 2009.
 [RFC5755]     Farrell, S., Housley, R., and S. Turner, "An Internet
               Attribute Certificate Profile for Authorization",
               RFC 5755, January 2010.
 [RFC5890]     Klensin, J., "Internationalized Domain Names for
               Applications (IDNA): Definitions and Document
               Framework", RFC 5890, August 2010.

Moriarty Standards Track [Page 81] RFC 6545 RID April 2012

 [RFC5891]     Klensin, J., "Internationalized Domain Names in
               Applications (IDNA): Protocol", RFC 5891, August 2010.
 [RFC6546]     Trammell, B., "Transport of Real-time Inter-network
               Defense (RID) Messages over HTTP/TLS", RFC 6546,
               April 2012.
 [XML1.0]      Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C.,
               and F. Yergeau, "Extensible Markup Language (XML) 1.0",
               W3C Recommendation XML 1.0, November 2008,
               <http://www.w3.org/TR/xml/>.
 [XMLCanon]    Boyer, J., "Canonical XML 1.0", W3C Recommendation 1.0,
               December 2001, <http://www.w3.org/TR/xml-c14n>.
 [XMLPath]     Berglund, A., Boag, S., Chamberlin, D., Fernandez, M.,
               Kay, M., Robie, J., and J. Simeon, "XML Schema Part 1:
               Structures", W3C Recommendation Second Edition,
               December 2010, <http://www.w3.org/TR/xpath20/>.
 [XMLSigBP]    Hirsch, F. and P. Datta, "XML-Signature Best
               Practices", W3C Recommendation, August 2011,
               <http://www.w3.org/TR/xmldsig-bestpractices/>.
 [XMLencrypt]  Imaura, T., Dillaway, B., and E. Simon, "XML Encryption
               Syntax and Processing", W3C Recommendation,
               December 2002, <http://www.w3.org/TR/xmlenc-core/>.
 [XMLschema]   Thompson, H., Beech, D., Maloney, M., and N.
               Mendelsohn, "XML Schema Part 1: Structures", W3C
               Recommendation Second Edition, October 2004,
               <http://www.w3.org/TR/xmlschema-1/>.
 [XMLsig]      Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E.
               Simon, "XML-Signature Syntax and Processing", W3C
               Recommendation Second Edition, June 2008,
               <http://www.w3.org/TR/xmldsig-core/>.

14.2. Informative References

 [RFC1930]     Hawkinson, J. and T. Bates, "Guidelines for creation,
               selection, and registration of an Autonomous System
               (AS)", BCP 6, RFC 1930, March 1996.
 [RFC3080]     Rose, M., "The Blocks Extensible Exchange Protocol
               Core", RFC 3080, March 2001.

Moriarty Standards Track [Page 82] RFC 6545 RID April 2012

 [RFC3647]     Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
               Wu, "Internet X.509 Public Key Infrastructure
               Certificate Policy and Certification Practices
               Framework", RFC 3647, November 2003.
 [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
               "Uniform Resource Identifier (URI): Generic Syntax",
               STD 66, RFC 3986, January 2005.
 [RFC5735]     Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
               BCP 153, RFC 5735, January 2010.
 [RFC6045]     Moriarty, K., "Real-time Inter-network Defense (RID)",
               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.
 [XMLNames]    Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
               Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C
               Recommendation , December 2009,
               <http://www.w3.org/TR/xml-names/>.

Moriarty Standards Track [Page 83] RFC 6545 RID April 2012

Appendix A. Acknowledgements

 Many thanks to colleagues and the Internet community for reviewing
 and commenting on the document as well as providing recommendations
 to improve, simplify, and secure the protocol: Steve Bellovin, David
 Black, Harold Booth, Paul Cichonski, Robert K. Cunningham, Roman
 Danyliw, Yuri Demchenko, Sandra G. Dykes, Stephen Farrell, Katherine
 Goodier, Cynthia D. McLain, Thomas Millar, Jean-Francois Morfin,
 Stephen Northcutt, Damir Rajnovic, Tony Rutkowski, Peter Saint-Andre,
 Jeffrey Schiller, Robert Sparks, William Streilein, Richard Struse,
 Tony Tauber, Brian Trammell, Sean Turner, Iljitsch van Beijnum, and
 David Waltermire.

Author's Address

 Kathleen M. Moriarty
 EMC Corporation
 176 South Street
 Hopkinton, MA
 United States
 EMail: Kathleen.Moriarty@emc.com

Moriarty Standards Track [Page 84]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6545.txt · Last modified: 2012/04/20 22:34 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki