MILE Working Group                                           K. Moriarty
Internet-Draft                                                       EMC
Updates: 6045 (if approved)                            November 17, 2011
Intended status: Standards Track
Expires: May 20, 2012


                 Real-time Inter-network Defense (RID)
                   draft-ietf-mile-rfc6045-bis-01.txt

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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 20, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the



Moriarty                  Expires May 20, 2012                  [Page 1]


Internet-Draft                 RFC6045-bis                 November 2011


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Normative and Informative  . . . . . . . . . . . . . . . .  6
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Characteristics of Incidents . . . . . . . . . . . . . . . . .  6
   3.  Communication between CSIRTs and Service Providers . . . . . .  8
     3.1.  Inter-network Provider RID Messaging . . . . . . . . . . . 10
     3.2.  RID Communication Topology . . . . . . . . . . . . . . . . 12
     3.3.  Message Formats  . . . . . . . . . . . . . . . . . . . . . 13
     3.4.  RID Data Types . . . . . . . . . . . . . . . . . . . . . . 13
       3.4.1.  Boolean  . . . . . . . . . . . . . . . . . . . . . . . 14
     3.5.  RID Message Types  . . . . . . . . . . . . . . . . . . . . 14
   4.  IODEF-RID Schema . . . . . . . . . . . . . . . . . . . . . . . 15
     4.1.  RIDPolicy Class  . . . . . . . . . . . . . . . . . . . . . 17
     4.2.  RequestStatus  . . . . . . . . . . . . . . . . . . . . . . 22
     4.3.  IncidentSource . . . . . . . . . . . . . . . . . . . . . . 23
     4.4.  RID Name Spaces  . . . . . . . . . . . . . . . . . . . . . 25
   5.  RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 25
     5.1.  TraceRequest . . . . . . . . . . . . . . . . . . . . . . . 25
     5.2.  RequestAuthorization . . . . . . . . . . . . . . . . . . . 26
     5.3.  Result . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     5.4.  Investigation Request  . . . . . . . . . . . . . . . . . . 29
     5.5.  Report . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     5.6.  IncidentQuery  . . . . . . . . . . . . . . . . . . . . . . 32
   6.  RID Communication Exchanges  . . . . . . . . . . . . . . . . . 34
     6.1.  Upstream Trace Communication Flow  . . . . . . . . . . . . 34
       6.1.1.  RID TraceRequest Example . . . . . . . . . . . . . . . 36
       6.1.2.  RequestAuthorization Message Example . . . . . . . . . 40
       6.1.3.  Result Message Example . . . . . . . . . . . . . . . . 40
     6.2.  Investigation Request Communication Flow . . . . . . . . . 43
       6.2.1.  Investigation Request Example  . . . . . . . . . . . . 44
       6.2.2.  RequestAuthorization Message Example . . . . . . . . . 46
     6.3.  Report Communication Flow  . . . . . . . . . . . . . . . . 46
       6.3.1.  Report Example . . . . . . . . . . . . . . . . . . . . 47



Moriarty                  Expires May 20, 2012                  [Page 2]


Internet-Draft                 RFC6045-bis                 November 2011


     6.4.  IncidentQuery Communication Flow . . . . . . . . . . . . . 49
       6.4.1.  IncidentQuery Example  . . . . . . . . . . . . . . . . 49
   7.  RID Schema Definition  . . . . . . . . . . . . . . . . . . . . 50
   8.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 54
     8.1.  XML Digital Signatures and Encryption  . . . . . . . . . . 54
     8.2.  Message Transport  . . . . . . . . . . . . . . . . . . . . 57
     8.3.  Message Delivery Protocol - Integrity and
           Authentication . . . . . . . . . . . . . . . . . . . . . . 58
     8.4.  Transport Communication  . . . . . . . . . . . . . . . . . 59
     8.5.  Authentication of RID Protocol . . . . . . . . . . . . . . 59
       8.5.1.  Multi-Hop TraceRequest Authentication  . . . . . . . . 60
     8.6.  Consortiums and Public Key Infrastructures . . . . . . . . 62
     8.7.  Privacy Concerns and System Use Guidelines . . . . . . . . 63
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 67
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 68
   11. Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 69
     12.2. Informative References . . . . . . . . . . . . . . . . . . 71
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 71































Moriarty                  Expires May 20, 2012                  [Page 3]


Internet-Draft                 RFC6045-bis                 November 2011


1.  Introduction

   This document moves Real-time Inter-network Defense (RID) [RFC6045]
   to Historic status as it provides minor updates.  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 a SP to resolve a
   configuration issue 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.

   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 a SP for resolution/mitigation,
   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 service providers 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



Moriarty                  Expires May 20, 2012                  [Page 4]


Internet-Draft                 RFC6045-bis                 November 2011


   provide a method to communicate the relevant information between
   computer security incident response teams (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 and privacy policy
   information set in the RID schema.  The RID schema acts as an XML
   envelope 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 [RFC6046-bis] [RFC6046-bis].  The authentication, integrity,
   and authorization features 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
   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.

   This specification updates [RFC6045].  Differences from [RFC6045] are
   summarized below:

   o  Edits reflected in this updated version of RFC6045 are primarily
      improvements to the informational descriptions.  The descriptions
      have been updated to clarify the use of IODEF and RID extend for
      all types of incidents and are not limited to network security
      incidents.  The language has been updated to reduce a focus on
      attacks and instead on 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





Moriarty                  Expires May 20, 2012                  [Page 5]


Internet-Draft                 RFC6045-bis                 November 2011


      *  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 remains the same with the exception updates for
      reported errata and an additional enumeration in the RIDPolicy
      class for 'LawEnforcement'.

   o  Guidance has 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.

   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 4 has
      been changed to match the order in the IODEF-RID schema.

1.1.  Normative and Informative

   The XML schema [XMLschema] and transport requirements contained in
   this document are normative; all other information provided is
   intended as informative.  More specifically, the following sections
   of this document are intended as informative: Sections 1 and 2; and
   the sub-sections of 3 including the introduction to 3, 3.1, and 3.2.
   The following sections of this document are normative: The sub-
   sections of 3 including 3.3, 3.4, and 3.5; Sections 5, 6, 7, and 8.

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

   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.  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.  Incident
   tracing can be used to identify the source(s) of an attack in order



Moriarty                  Expires May 20, 2012                  [Page 6]


Internet-Draft                 RFC6045-bis                 November 2011


   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 allows for actions
   to be taken when the source of the incident or a point closer to the
   source is known or has been identified.  The purpose of tracing an
   incident is to remedy the detected issue, halt, or mitigate the
   effects of the incident.  Methods to accomplish this 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
   along the path of a trace.

   Tracing 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
   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;

   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 NP or HTTP requests sent to an



Moriarty                  Expires May 20, 2012                  [Page 7]


Internet-Draft                 RFC6045-bis                 November 2011


      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

   Note: The Introduction, and Sub-sections 3.1 and 3.2, are
   informative, with the exception of references to IODEF/RID Transport
   RFC6046-bis [RFC6046-bis].  Sub-sections 3.3, 3.4, and 3.5 are
   normative.

   Expediting the communication between CSIRTs and service providers
   (SP) is essential when responding to a security-related incident,
   which may cross network access points (Internet backbones or cloud
   infrastructures) between service or network providers.  As a result
   of the urgency involved in this inter-service provider security
   incident communication, there must be an effective system in place to
   facilitate the interaction.  This communication policy or method
   should involve multiple means of communication to avoid a single
   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.




Moriarty                  Expires May 20, 2012                  [Page 8]


Internet-Draft                 RFC6045-bis                 November 2011


   A technical solution to trace traffic across a single service or
   network provider may include homegrown or commercial systems for
   which RID messaging must accommodate the input requirements.  The
   incident handling system used on the service or network provider's
   backbone by the CSIRT to coordinate the trace across the single
   network requires a method to accept and 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 integrate 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.  An
   example of a consortium might include the cloud service providers.

   Consortiums could consist of a group of service (network, cloud,
   etc.) providers, CSIRTs, or other federation 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 the IODEF/RID Transport [X.ridd] Recommendation.

   One goal of RID is to prevent the need to permit access to other
   networks' equipment through the use of 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 their network operations staff to authorize the continuance
   of a trace or other necessary response to a RID communication request
   through their network via a notification and alerting system.

   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



Moriarty                  Expires May 20, 2012                  [Page 9]


Internet-Draft                 RFC6045-bis                 November 2011


   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 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 FBI or other assisting
   government organization in the country of the investigation.

3.1.  Inter-network Provider RID Messaging

   RID provides a standard protocol and format is required to ensure
   inter-operability 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 3.5 are necessary to facilitate the
   handling of a security incident.  The message types include the
   Report, IncidentQuery, TraceRequest, RequestAuthorization, Result,
   and the Investigation request 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.
   An IncidentQuery message is used to request information on a
   particular incident.  A TraceRequest message is used when the source
   of the traffic may have been spoofed.  In that case, each network
   provider in the upstream path who receives a TraceRequest will issue
   a trace across the network to determine the upstream source of the



Moriarty                  Expires May 20, 2012                 [Page 10]


Internet-Draft                 RFC6045-bis                 November 2011


   traffic.  The RequestAuthorization and Result messages are used to
   communicate the status and result of a TraceRequest or Investigation
   request.  The Investigation request message only involves the systems
   accepting RID communication along the path to the source of the
   traffic and not the use of network trace systems.  The Investigation
   request 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 Investigation request.  A message sent
   between RID systems for a TraceRequest or an Investigation request 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 TraceRequest containing 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 of 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
   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



Moriarty                  Expires May 20, 2012                 [Page 11]


Internet-Draft                 RFC6045-bis                 November 2011


   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 an
   investigation or trace.  If the Confidence rating (provided in IODEF)
   is low, it may not be in the provider's best interest to continue the
   investigation or trace.  The Confidence ratings must adhere to the
   specifications for selecting the percentage used to avoid abuse of
   the system.  TraceRequests 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,
   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.




Moriarty                  Expires May 20, 2012                 [Page 12]


Internet-Draft                 RFC6045-bis                 November 2011


       _______                     _______                     _______
       |     |                     |     |                     |     |
     __| 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
   TraceRequest 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.

3.3.  Message Formats

   Section 3.5 describes the six RID message types, which leverage the
   IODEF model [RFC5070].  The messages are generated and received on
   designated systems for RID communication on the provider's network.
   The messages may originate from IODEF documents from intrusion
   detection servers, CSIRTs, analysts, etc.  A RID message uses the
   IODEF document with the RID extension, which is encapsulated for
   transport [RFC6046-bis].  Each RID message type, along with an
   example, is described in the following sections.  The IODEF-RID
   schema is introduced in Section 4 to support the RID message types in
   Section 3.5.  The term service provider (SP), used in the following
   sections should be interpreted as any type of service provider or
   CSIRT that may be involved in RID communications.

3.4.  RID Data Types

   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.





Moriarty                  Expires May 20, 2012                 [Page 13]


Internet-Draft                 RFC6045-bis                 November 2011


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

3.5.  RID Message Types

   The six RID message types are as follows:

   1.  TraceRequest.  This message is sent to the next provider in the
       upstream trace.  It is used to initiate a TraceRequest or to
       continue a TraceRequest to an upstream provider closer to the
       source address of the origin of the security incident.  The
       TraceRequest triggers a traceback on the network to locate the
       source of the attack traffic.

   2.  RequestAuthorization.  This message is sent to the initiating RID
       system from each of the upstream providers' RID systems to
       provide information on the request status in the current network.

   3.  Result.  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.  The Result message is
       also used to provide the notification of actions taken for an
       Investigation request.

   4.  Investigation.  This message type is used when the source of the
       traffic is believed not to be spoofed.  The purpose of the
       Investigation request message is to leverage the existing peer
       relationships in order to notify the network provider closest to
       the source of the valid traffic of a security-related incident
       for any necessary actions to be taken.

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

   6.  IncidentQuery.  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
   also be used by the transport protocol to facilitate the



Moriarty                  Expires May 20, 2012                 [Page 14]


Internet-Draft                 RFC6045-bis                 November 2011


   communication of security incident data to trace, investigate, query,
   or report information regarding security incidents.


4.  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 TraceRequest or Investigation
   request; the IncidentSource class is used to report whether or not a
   source was found and to identify the source host(s) or network(s);
   and the RIDPolicy class provides information on the agreed-upon
   policies and specifies the type of communication message being used.

   The RID schema acts as an envelope for the IODEF schema to facilitate
   RID communications.  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
   that includes the IODEF schema, the RID information acts as an
   envelope, and then the RIDPolicy class can be easily extracted for
   use by the transport protocol.

   The security requirements of sending incident information across the
   network include the use of encryption.  The RIDPolicy information is
   not required to be encrypted, so separating out this data from the
   IODEF extension removes the need for decrypting and parsing the
   entire IODEF and RID 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 policy information and guidelines are discussed in Section 8.7.
   The policy is defined between RID peers and within or between
   consortiums.  The RIDPolicy is meant to be a tool to facilitate the
   defined policies.  This MUST be used in accordance with policy set
   between clients, peers, consortiums, and/or regions.  Security,
   privacy, and confidentiality MUST be considered as specified in this
   document.

   The RID schema is defined as follows:








Moriarty                  Expires May 20, 2012                 [Page 15]


Internet-Draft                 RFC6045-bis                 November 2011


           +------------------+
           |        RID       |
           +------------------+
           | ANY              |
           |                  |<>---{0..1}----[ RIDPolicy      ]
           | ENUM restriction |
           | ENUM type        |<>---{0..1}----[ RequestStatus  ]
           | STRING meaning   |
           |                  |<>---{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
      RequestAuthorization messages to report back to the CSIRT or SP
      originating the RID trace will be continued by each RID system
      that received a TraceRequest in the path to the source of the
      traffic.

   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 [RFC6046-bis], 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 [RFC6046-bis].






Moriarty                  Expires May 20, 2012                 [Page 16]


Internet-Draft                 RFC6045-bis                 November 2011


4.1.  RIDPolicy Class

   The RIDPolicy class facilitates the delivery of RID messages and is
   also referenced for transport in the transport document [RFC6046-
   bis].

          +------------------------+
          | RIDPolicy              |
          +------------------------+
          |                        |
          | ENUM restriction       |<>-------------[ Node         ]
          | ENUM MsgType           |
          | ENUM MsgDestination    |<>---{0..1}----[ IncidentID   ]
          | ENUM ext-MsgType       |
          | ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ]
          |                        |
          |                        |<>---{1..*}----[ TrafficType  ]
          |                        |
          +------------------------+

                       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.
      The base definition of this class is reused from the IODEF
      specification [RFC5070], Section 3.16.

   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



Moriarty                  Expires May 20, 2012                 [Page 17]


Internet-Draft                 RFC6045-bis                 November 2011


      multiple selections from the attribute list in order to fit all
      possible policy considerations when crossing regions, consortiums,
      or networks.

   region

      One. ENUM.

      1.  ClientToSP.  An enterprise initiated the request to their
          service provider.

      2.  SPToClient.  An service provider passed a RID request or
          report to a client or an enterprise based on requested
          services or service level agreements.

      3.  IntraConsortium.  Incident information that should have no
          restrictions within the boundaries of a consortium with the
          agreed-upon use and abuse guidelines.

      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.

      5.  BetweenConsortiums.  Incident information that should have no
          restrictions between consortiums that have established agreed-
          upon use and abuse guidelines.

      6.  AcrossNationalBoundaries.  This selection must be set if the
          message type will cross national boundaries.  There could be
          instances of TraceRequest messages where that may not be known
          in advance, but should be known at the instance where
          boundaries are crossed during the investigation.  This must
          also be set if the security requirements of the request is
          based upon regulations of a specific nation that may not apply
          to all nations.  The stricter requirements should be upheld.
          This is different from the "BetweenConsortiums" setting since
          it may be possible to have multiple nations as members of the
          same consortium, and this option must be selected if the
          traffic is of a type that may have different restrictions in
          other nations.

      7.  LawEnforcement.  This option is used when incident information
          is exchanged with LawEnforcement, local government, or other
          authorities assisting with an investigation.  If the law
          enforcement agency resides within a different nation that the
          sending entity, the "AcrossNationalBoundaries" enumeration
          MUST also be set.



Moriarty                  Expires May 20, 2012                 [Page 18]


Internet-Draft                 RFC6045-bis                 November 2011


      8.  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 (provider) 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. ENUM.

      1.  Attack.  This option should only be selected if the traffic is
          related to a network-based 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 include determining what sources
          or destinations accessed certain materials available on the
          Internet, including, but not limited to, news, technology, or
          inappropriate content.

      4.  OfficialBusiness.  This option MUST be used if the incident
          information is requested by or affiliated with any government
          or other official business request.  This could be used during
          an investigation by government authorities or other government
          incident investigations to track suspected criminal or other
          activities.

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





Moriarty                  Expires May 20, 2012                 [Page 19]


Internet-Draft                 RFC6045-bis                 November 2011


      6.  ext-value.  An escape value used to extend this attribute.
          See IODEF [RFC5070], Section 5.1.

   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

         REQUIRED.  ENUM.  The type of RID message sent.  The six types
         of messages are described in Section 3.5 and can be noted as
         one of the six selections below.

      2.  TraceRequest.  This 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.

      3.  RequestAuthorization.  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.

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

      5.  Investigation.  This message type is used when the source of
          the traffic is believed to be valid.  The purpose of the
          Investigation request is to leverage the existing peer or
          consortium relationships in order to notify the network or
          service provider closest to the source of the valid traffic
          that some event occurred, which may be a security-related
          incident.

      6.  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, statistics and trending information,
          etc.

      7.  IncidentQuery.  This message is used to request information
          from a trusted RID system about an incident or incident type.



Moriarty                  Expires May 20, 2012                 [Page 20]


Internet-Draft                 RFC6045-bis                 November 2011


      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

         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 an Investigation request, the
         source of the incident.  In the case of an Investigation
         request, 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 address listed in the Node element of the
             RIDPolicy class is the next upstream RID system that will
             receive the RID message.

         2.  SourceOfIncident.  The address listed in the Node element
             of the RIDPolicy class is the incident source.  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 an
             Investigation request message is used.  This is not to be
             confused with the IncidentSource class, as the defined
             value here is from an initial trace or Investigation
             request, not the source used in a Result message.

         3.  ext-value.  An escape value used to extend this attribute.
             See IODEF [RFC5070], Section 5.1.

      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




Moriarty                  Expires May 20, 2012                 [Page 21]


Internet-Draft                 RFC6045-bis                 November 2011


4.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 5: 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

         REQUIRED.  ENUM.  The listed values are used to provide a
         response to the requesting CSIRT of the status of a
         TraceRequest in the current network.

         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 RequestAuthorization message must be passed back to the
             originator and a Result message used from the closest SP to
             the source to indicate actions taken in the IODEF History
             class.

         3.  Pending.  Awaiting approval; a timeout period has been
             reached, which resulted in this Pending status and



Moriarty                  Expires May 20, 2012                 [Page 22]


Internet-Draft                 RFC6045-bis                 November 2011


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

         2.  SystemResource.  A resource issue exists on the systems
             that would be involved in the request.

         3.  Authentication.  The enveloped digital signature [RFC3275]
             failed to validate.

         4.  AuthenticationOrigin.  The detached digital signature for
             the original requestor on the RecordItem entry failed to
             validate.

         5.  Encryption.  Unable to decrypt the request.

         6.  Other.  There were other reasons this request could not be
             processed.

         7.  ext-value.  An escape value used to extend this attribute.
             See IODEF [RFC5070], Section 5.1.

         AuthorizationStatus-ext

            OPTIONAL.  STRING.  A means by which to extend the
            AuthorizationStatus attribute.  See IODEF [RFC5070], Section
            5.1.

         Justification-ext

            OPTIONAL.  STRING.  A means by which to extend the
            Justification attribute.  See IODEF [RFC5070], Section 5.1.

4.3.  IncidentSource

   The IncidentSource class is an aggregate class in the RID class.









Moriarty                  Expires May 20, 2012                 [Page 23]


Internet-Draft                 RFC6045-bis                 November 2011


          +-------------------+
          | IncidentSource    |
          +-------------------+
          |                   |
          | ENUM restriction  |
          |                   |<>-------------[ SourceFound    ]
          |                   |
          |                   |<>---{0..*}----[ Node           ]
          |                   |
          +-------------------+

                    Figure 6: 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

         One. The Node class is used to identify a host or network
         device, in this case to identify the system communicating RID
         messages.

         The base definition of this class is reused from the IODEF
         specification [RFC5070], Section 3.16.

      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.








Moriarty                  Expires May 20, 2012                 [Page 24]


Internet-Draft                 RFC6045-bis                 November 2011


4.4.  RID Name Spaces

   The RID schema declares a namespace of "iodef-rid-1.1" and registers
   it per [XMLNames].  Each IODEF-RID document MUST use the
   "iodef-rid-1.1" namespace in the top-level element RID-Document.  It
   can be referenced as follows:

   <RID-Document version="1.10" lang="en-US"
      xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
      xsi:schemaLocation=http://www.iana.org/assignments/xml-registry/
      schema/iodef-rid-1.1.xsd">


5.  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 to ensure proper parsing of all RID 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 that used in the EventData class.

5.1.  TraceRequest

   Description: This message or document is sent to the network
   management station next in the upstream trace once the upstream
   source of the traffic has been identified.  The following information
   is required for TraceRequest messages and is provided through:

   RID Information:

      RIDPolicy

         RID message type, IncidentID, and destination policy
         information

   IODEF Information:

      Time Stamps (DetectTime, StartTime, EndTime, ReportTime).




Moriarty                  Expires May 20, 2012                 [Page 25]


Internet-Draft                 RFC6045-bis                 November 2011


      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 service/network provider (SP)
      path contact information.

   Standards for encryption and digital signatures [RFC3275], [XMLsig]:

      Digital signature from initiating CSIRT or provider system sending
      the RID message, passed to all systems in upstream trace using a
      detached XML digital signature on a RecordItem entry.

      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.

      XML encryption as required by policy, agreements, and data
      markers.

   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 had already passed
   through a single network.  The Incident Identifier must also be used
   to identify multiple TraceRequests from a single incident.  If a
   single TraceRequest results in divergent paths of TraceRequests, 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.

5.2.  RequestAuthorization

   Description: This message is sent to the initiating RID system from
   the next upstream provider's application or system designated for



Moriarty                  Expires May 20, 2012                 [Page 26]


Internet-Draft                 RFC6045-bis                 November 2011


   accepting RID communications to provide information on the request
   status in the current network.

   The following information is required for RequestAuthorization
   messages and is provided through:

   RID Information:

      RIDPolicy

         RID message type, IncidentID, and destination policy
         information

      RequestStatus class:

         Status of TraceRequest

   Standards for encryption and digital signatures [RFC3275], [XMLsig]:

      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
   accepting 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 taken 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 enables the sending peer the option to
   take action to stop or mitigate the traffic as close to the source as
   possible.

5.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 through the IncidentSource class.  The Result
   information MUST go back to the originating RID system that began the
   investigation or trace.  An provider may use any number of incident



Moriarty                  Expires May 20, 2012                 [Page 27]


Internet-Draft                 RFC6045-bis                 November 2011


   handling data sources to ascertain the true source of an attack.  All
   of the possible information sources may or may not be readily tied
   into the RID communications system.

   The following information is required for Result messages and will be
   provided through:

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

      IODEF Information:

         Time Stamps (DetectTime, StartTime, EndTime, ReportTime).

         Incident Identifier (Incident class, IncidentID).

            Trace number - used for multiple traces of a single
            incident; must be noted.

         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 an upstream TraceRequest in RID.

         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                  Expires May 20, 2012                 [Page 28]


Internet-Draft                 RFC6045-bis                 November 2011


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

         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 enough to block all Internet access until the
   host has taken the appropriate action to resolve any security issues
   or to rate-limit the ingress traffic as close to the source as
   possible.

   Security and privacy requirements discussed in Section 8 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 TraceRequest or
   Investigation 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 TraceRequest or Investigation
   request is made.

5.4.  Investigation Request

   Description: This message type is used when the source of the traffic
   is believed not to be spoofed.  The purpose of the Investigation
   request message is to leverage the existing bilateral peer
   relationships in order to notify the network provider closest to the
   source of the valid traffic that some event occurred, which may be a



Moriarty                  Expires May 20, 2012                 [Page 29]


Internet-Draft                 RFC6045-bis                 November 2011


   security-related incident.

   The following information is required for Investigation request
   messages and is provided through:

      RID Information:

         RID Policy

            RID message type, IncidentID, and destination policy
            information

      IODEF Information:

         Time Stamps (DetectTime, StartTime, EndTime, ReportTime).

         Incident Identifier (Incident class, IncidentID).

            Trace number - used for multiple traces of a single
            incident; must be noted.

         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 an upstream TraceRequest in RID.

         Expectation class should be used to request any specific
         actions to be taken close to the source.

         Path information of nested systems communicating via RID
         messages, 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]:

         Digital signature from initiating system sending the RID
         message, passed to all systems involved in the investigation
         using a detached XML digital signature on a RecordItem entry.




Moriarty                  Expires May 20, 2012                 [Page 30]


Internet-Draft                 RFC6045-bis                 November 2011


         Digital signature of sending CSIRT or SP for authenticity of
         the RID message, from the CSIRT or provider sending this
         message using an enveloped XML digital signature on the IODEF
         document.

         XML encryption as required by policy, agreements, and data
         markers.

   Security requirements include the ability to encrypt [XMLencrypt] the
   contents of the Investigation request message using the public key of
   the destination RID system.  The incident number increases as if it
   were a TraceRequest message in order to ensure uniqueness within the
   system.  The relaying peers also append their Autonomous System (AS)
   or RID system information as the request message was relayed along
   the web of network providers so that the Result message could utilize
   the same path as the set of trust relationships for the return
   message, thus 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 internal 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 message destination of RIDPolicy, SourceOfIncident.  Note:
   All intermediate parties MUST be able to view RIDPolicy information
   in order to properly direct RID messages.

5.5.  Report

   Description: This message or document is sent to a RID system to
   provide a report of a security incident.  This message does not
   require any actions to be taken, except to file the report on the
   receiving RID system or associated database.

   The following information is required for Report messages and will be
   provided through:

      RID Information:

         RID Policy RID message type, IncidentID, and destination policy
         information

      The following data is recommended if available and can be provided
      through:

      IODEF Information:




Moriarty                  Expires May 20, 2012                 [Page 31]


Internet-Draft                 RFC6045-bis                 November 2011


         Time Stamps (DetectTime, StartTime, EndTime, ReportTime).

         Incident Identifier (Incident class, IncidentID).  Trace number
         - used for multiple traces of a single incident; must be noted.

         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 to include example
         packets and other information related to the incident
         (optional).

      Standards for encryption and digital signatures [RFC3275]:

         Digital signature from initiating RID system, passed to all
         systems receiving the report using an enveloped XML digital
         signature.

         XML encryption as required by policy, agreements, and data
         markers.

   Security requirements include the ability to encrypt [XMLencrypt] the
   contents of the Report message using the public key of the
   destination RID system.  Senders of a Report message should note that
   the information may be used to correlate security incident
   information for the purpose of trending, pattern detection, etc., and
   may be shared with other parties unless otherwise agreed upon with
   the receiving RID system.  Therefore, sending parties of a Report
   message may obfuscate or remove destination addresses or other
   sensitive information before sending a Report message.  A Report
   message may be sent either to file an incident report or in response
   to an IncidentQuery, 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.

5.6.  IncidentQuery

   Description: The IncidentQuery 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 IncidentQuery, the return
   report may be automated; otherwise, analyst intervention may be



Moriarty                  Expires May 20, 2012                 [Page 32]


Internet-Draft                 RFC6045-bis                 November 2011


   required.

   The following information must be used for an IncidentQuery message
   and is provided through:

      RID Information:

         RID Policy

            RID message type, IncidentID, and destination policy
            information

      IODEF Information (optional):

         Time Stamps (DetectTime, StartTime, EndTime, ReportTime).

         Incident Identifier (Incident class, IncidentID).

            Trace number - used for multiple traces of a single
            incident; must be noted.

         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 to include example
         packets and other information related to the incident
         (optional).

      Standards for encryption and digital signatures [RFC3275]:

         Digital signature from the CSIRT or SP initiating the RID
         message, passed to all systems receiving the IncidentQuery
         using an enveloped XML digital signature.

         XML encryption as required by policy, agreements, and data
         markers.

   The proper response to the IncidentQuery 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 pre-set 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 suited better than RID for large transfers of data.



Moriarty                  Expires May 20, 2012                 [Page 33]


Internet-Draft                 RFC6045-bis                 November 2011


   The Confidence rating may be used in the IncidentQuery 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 IncidentQuery is intended to gather data about a specific type of
   incident as well.


6.  RID Communication Exchanges

   The following section outlines the communication flows for RID and
   also provides examples of messages.

   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.

6.1.  Upstream Trace Communication Flow

   The diagram below outlines the RID TraceRequest communication flow
   between RID systems on different networks tracing an attack.  SP-1,
   SP-2, SP-3 represent service or network providers that are involved
   in the example trace communication flow.


























Moriarty                  Expires May 20, 2012                 [Page 34]


Internet-Draft                 RFC6045-bis                 November 2011


    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.              <-RequestAuthorization-o

    7.                              Locate origin
                                    through
                                    upstream SP

    8.                              o---TraceRequest--->

    9.                                             Trace Initiated

    10.             <----------RequestAuthorization----o
                                     <---RequestAuth---o

    11.                                            Locate attack
                                                   source on network   X

    12.             <------------Result----------------o

                 Figure 7: TraceRequest Communication Flow

   Before a trace is initiated, the RID system should verify if 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
   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 a RequestAuthorization
   message is sent to both the downstream peer and the original
   requestor.  If a TraceRequest is denied, the downstream peer has the
   option to take an action and respond with a Result message.  The



Moriarty                  Expires May 20, 2012                 [Page 35]


Internet-Draft                 RFC6045-bis                 November 2011


   originator of the request may follow up with the downstream peer of
   the SP involved using an Investigation request to ensure that an
   action is taken if no response is received.  Nothing precludes the
   originator of the request from initiating a new TraceRequest
   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
   Investigation request to an SP upstream of the SP that denied the
   request if 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 a RequestAuthorization
   message.  The RequestAuthorization 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, a RequestAuthorization
   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 a RequestAuthorization
   message would occur 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
   RequestAuthorization 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, a
   RequestAuthorization message is sent in response; otherwise, no
   return message is sent.  If a RequestAuthorization 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.

6.1.1.  RID TraceRequest Example

   The example listed is of a TraceRequest based on the incident report
   example from the IODEF document.  The RID extension classes were
   included as appropriate for a TraceRequest message 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.




Moriarty                  Expires May 20, 2012                 [Page 36]


Internet-Draft                 RFC6045-bis                 November 2011


   In the following example, use of [XMLsig] to generate digital
   signatures used SHA-1 following the guidance of [XMLsig] 1.0.
   Version 1.1 of [XMLsig] supports additional digest algorithms.

  <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
                 xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
    <iodef-rid:RIDPolicy MsgType="TraceRequest"
                         MsgDestination="RIDSystem">
      <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-rid:RIDPolicy>
  </iodef-rid:RID>


  <!-- IODEF-Document accompanied by the above RID -->

  <iodef:IODEF-Document version="1.00"
                        xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
    <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:Flow>
          <iodef:System category="source">
            <iodef:Node>
              <iodef:Address category="ipv4-addr">192.0.2.35
              </iodef:Address>
            </iodef:Node>
            <iodef:Service>



Moriarty                  Expires May 20, 2012                 [Page 37]


Internet-Draft                 RFC6045-bis                 November 2011


              <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>
              <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>
      <iodef:History>
        <iodef:HistoryItem>
          <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:IODEF-Document>

  <!-- Digital signature accompanied by above RID and IODEF -->




Moriarty                  Expires May 20, 2012                 [Page 38]


Internet-Draft                 RFC6045-bis                 November 2011


  <Envelope xmlns="urn:envelope"
            xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
            xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1">
    <iodef:IODEF-Document>
      <iodef:Incident>
        <iodef:EventData>
          <iodef:Record>
            <iodef:RecordData>
              <iodef:RecordItem type="ipv4-packet">450000522ad9
               0000ff06c41fc0a801020a010102976d0050103e020810d9
               4a1350021000ad6700005468616e6b20796f7520666f7220
               6361726566756c6c792072656164696e6720746869732052
               46432e0a
              </iodef:RecordItem>
            </iodef:RecordData>
          </iodef:Record>
        </iodef:EventData>
      </iodef:Incident>
    </iodef:IODEF-Document>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod
           Algorithm="http://www.w3.org/TR/2001/
            REC-xml-c14n-20010315#WithComments"/>
        <SignatureMethod
           Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
        <Reference URI="">
          <Transforms>
            <Transform Algorithm=
             "http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          </Transforms>
          <DigestMethod
             Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
          <DigestValue>KiI5+6SnFAs429VNwsoJjHPplmo=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>
        VvyXqCzjoW0m2NdxNeToXQcqcSM80W+JMW+Kn01cS3z3KQwCPeswzg==
      </SignatureValue>
      <KeyInfo>
        <KeyValue>
          <DSAKeyValue>
            <P>/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j
               QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==</P>
            <Q>li7dzDacuo67Jg7mtqEm2TRuOMU=</Q>
            <G>Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5
               Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==</G>
            <Y>VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs



Moriarty                  Expires May 20, 2012                 [Page 39]


Internet-Draft                 RFC6045-bis                 November 2011


               HifTyYdnj+roGzy4o09YntYD8zneQ7lw==</Y>
          </DSAKeyValue>
        </KeyValue>
      </KeyInfo>
    </Signature>
  </Envelope>


6.1.2.  RequestAuthorization Message Example

   The example RequestAuthorization message is in response to the
   TraceRequest message listed above.  The SP that received the request
   is responding to approve the trace continuance in their network.

   <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
                  xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
     <iodef-rid:RIDPolicy MsgType="RequestAuthorization"
                          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></section>

6.1.3.  Result Message Example

   The example Result message is in response to the TraceRequest listed
   above.  This message type only comes after a RequestAuthorization
   within the TraceRequest flow of messages.  It may be a direct
   response to an Investigation request.  This message provides
   information about the source of the attack and the actions taken to
   mitigate the traffic.

  <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
                 xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
    <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>
      </iodef:Node>
      <iodef-rid:TrafficType type="Attack"/>



Moriarty                  Expires May 20, 2012                 [Page 40]


Internet-Draft                 RFC6045-bis                 November 2011


      <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
        CERT-FOR-OUR-DOMAIN#207-1
      </iodef:IncidentID>
    </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>

  <!-- IODEF-Document accompanied by the above RID -->

  <iodef:IODEF-Document version="1.00"
                        xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
    <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">



Moriarty                  Expires May 20, 2012                 [Page 41]


Internet-Draft                 RFC6045-bis                 November 2011


            <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">
              <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>
              <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>
              <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



Moriarty                  Expires May 20, 2012                 [Page 42]


Internet-Draft                 RFC6045-bis                 November 2011


            6361726566756c6c792072656164696e6720746869732052
            46432e0a
            </iodef:RecordItem>
          </iodef:RecordData>
        </iodef:Record>
      </iodef:EventData>
      <iodef:History>
        <iodef:HistoryItem>
          <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>

6.2.  Investigation Request Communication Flow

   The diagram below outlines the RID Investigation request
   communication flow between RID systems on different networks for a
   security incident with a known source address.  The proper response
   to an Investigation request 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, a RequestAuthorization message is
   sent to the requestor.  The RequestAuthorization message should
   provide the reason why the message could not be processed.












Moriarty                  Expires May 20, 2012                 [Page 43]


Internet-Draft                 RFC6045-bis                 November 2011


        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 8: Investigation Communication Flow

6.2.1.  Investigation Request Example

   The following example only includes the RID-specific details.  The
   IODEF and security measures are similar to the TraceRequest
   information, with the exception that the source is known and the
   receiving RID system is known to be close to the source.  The source
   known is indicated in the IODEF document, which allows for incident
   sources to be listed as spoofed, if appropriate.

  <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
                 xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
    <iodef-rid:RIDPolicy MsgType="Investigation"
                         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"/>
      <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
        CERT-FOR-OUR-DOMAIN#208-1
      </iodef:IncidentID>
    </iodef-rid:RIDPolicy>
  </iodef-rid:RID>

  <!-- IODEF-Document accompanied by the above RID -->

  <iodef:IODEF-Document version="1.00"
                        xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">



Moriarty                  Expires May 20, 2012                 [Page 44]


Internet-Draft                 RFC6045-bis                 November 2011


    <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>
              <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>
              <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
          </iodef:Description>
        </iodef:Expectation>
      </iodef:EventData>
      <iodef:History>
        <iodef:HistoryItem>
          <iodef:DateTime>2004-02-05T08:19:01+00:00</iodef:DateTime>
          <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">



Moriarty                  Expires May 20, 2012                 [Page 45]


Internet-Draft                 RFC6045-bis                 November 2011


            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>

6.2.2.  RequestAuthorization Message Example

   The example RequestAuthorization message is in response to the
   Investigation 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 xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
                  xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
     <iodef-rid:RIDPolicy MsgType="RequestAuthorization"
                          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>

6.3.  Report Communication Flow

   The diagram below outlines the RID Report communication flow between
   RID systems on different networks.

           SP-1                           SP-2

        1. Generate incident information
           and prepare Report message

        2.              o-------Report------->

        3.                              File report in database




Moriarty                  Expires May 20, 2012                 [Page 46]


Internet-Draft                 RFC6045-bis                 November 2011


                    Figure 9: Report Communication Flow

   The Report communication flow is used to provide information on
   specific incidents detected on the network.  Incident information may
   be shared between CSIRTs or participating RID hosts 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, a
   RequestAuthorization message is sent to the requestor.  The
   RequestAuthorization message should provide the reason why the
   message could not be processed.

6.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
   TraceRequest information.

   <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
                  xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
     <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>
       <iodef-rid:TrafficType type="Attack"/>
       <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
         CERT-FOR-OUR-DOMAIN#209-1
       </iodef:IncidentID>
     </iodef-rid:RIDPolicy>
   </iodef-rid:RID>

   <!-- IODEF-Document accompanied by the above RID -->

   <iodef:IODEF-Document version="1.00"
                         xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
     <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>



Moriarty                  Expires May 20, 2012                 [Page 47]


Internet-Draft                 RFC6045-bis                 November 2011


       <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>
               <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>
               <iodef:port>22</iodef:port>
             </iodef:Service>
           </iodef:System>
         </iodef:Flow>
       </iodef:EventData>
       <iodef:History>
         <iodef:HistoryItem>
           <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>



Moriarty                  Expires May 20, 2012                 [Page 48]


Internet-Draft                 RFC6045-bis                 November 2011


6.4.  IncidentQuery Communication Flow

   The diagram below outlines the RID IncidentQuery 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---IncidentQuery--->

        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 10: IncidentQuery Communication Flow

   The IncidentQuery message communication receives a response of a
   Report message.  If the Report message is empty, the responding host
   did not 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 IncidentQuery message, such as a failure to validate the digital
   signature or decrypt the request, a RequestAuthorization message is
   sent to the requestor.  The RequestAuthorization message should
   provide the reason why the message could not be processed.

6.4.1.  IncidentQuery Example

   The IncidentQuery 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



Moriarty                  Expires May 20, 2012                 [Page 49]


Internet-Draft                 RFC6045-bis                 November 2011


   generate (a) Report message(s).

   <iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
                  xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
     <iodef-rid:RIDPolicy MsgType="IncidentQuery"
                          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>


7.  RID Schema Definition

 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.1"
  xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  targetNamespace="urn:ietf:params:xml:ns:iodef-rid-1.1"
  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-rid-1.1.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, August 2011                         ***
 ***    The namespace is defined to support transport of IODEF     ***
 ***     documents for exchanging incident information.            ***
 *********************************************************************
 -->
 <!--RID acts as an envelope for IODEF documents to support the exchange
     of messages-->
 <!--
 ====== Real-Time Inter-network Defense - RID ======
 ====  Suggested definition for RID messaging ======



Moriarty                  Expires May 20, 2012                 [Page 50]


Internet-Draft                 RFC6045-bis                 November 2011


  -->

 <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:complexType>

 <!--Used in RequestAuthorization Message for RID-->

 <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="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>



Moriarty                  Expires May 20, 2012                 [Page 51]


Internet-Draft                 RFC6045-bis                 November 2011


 <!--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"/>

 <!--
 ====== 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: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="RequestAuthorization"/>
         <xs:enumeration value="Result"/>
         <xs:enumeration value="Investigation"/>
         <xs:enumeration value="Report"/>
         <xs:enumeration value="IncidentQuery"/>
         <xs:enumeration value="ext-value"/>
       </xs:restriction>
     </xs:simpleType>
    </xs:attribute>



Moriarty                  Expires May 20, 2012                 [Page 52]


Internet-Draft                 RFC6045-bis                 November 2011


   <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"
                 use="optional"/>
    </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="AcrossNationalBoundaries"/>
          <xs:enumeration value="LawEnforcement"/>
          <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="OfficialBusiness"/>
          <xs:enumeration value="Other"/>
          <xs:enumeration value="ext-value"/>
        </xs:restriction>



Moriarty                  Expires May 20, 2012                 [Page 53]


Internet-Draft                 RFC6045-bis                 November 2011


       </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="ext-type"
                    type="xs:string" use="optional"/>
      <xs:attribute name="restriction" type="iodef:restriction-type"/>
     </xs:complexType>
   </xs:element>
 </xs:schema>


8.  Security Requirements

8.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 include 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,
   and that the messages meet policy and privacy guidelines and maintain
   integrity.

   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 the TraceRequest or Investigation 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.  This
      signature MUST be passed to all recipients of the TraceRequest or
      Investigation request.

   o  If an Investigation or TraceRequest does not include a RecordItem
      entry, an NTP timestamp may be used to ensure there is data to be



Moriarty                  Expires May 20, 2012                 [Page 54]


Internet-Draft                 RFC6045-bis                 November 2011


      signed for the multi-hop authentication use case.

   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.

   o  Optionally, nested enveloped signatures MAY be used when
      forwarding documents during an investigation.  If this option is
      used, the implementation MUST follow the guidance specified in the
      XML Digital Signature [XMLsig] specification for two or more
      enveloped signatures.

   XML Encryption

   o  The IODEF/RID document may be encrypted to provide an extra layer
      of security between peers so that the message is not only
      encrypted for the transport, but also while stored.  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 [RFC6046-bis].

   o  An Investigation request, or any other message type that may be
      relayed through RID systems other than the intended destination as
      a result of trust relationships, may be encrypted 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 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 RFC5070.
      Following the guidance for XML encryption in the Security
      Requirements Section, the iodef:restriction attribute can be set



Moriarty                  Expires May 20, 2012                 [Page 55]


Internet-Draft                 RFC6045-bis                 November 2011


      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
      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 restriction setting:

      *  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.  The use of PKI between entities
         SHOULD adhere to any applicable certificate policy and
         practices agreements for the use of RID.

      *  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 a single group
         key may be used.  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 users 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 out 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.



Moriarty                  Expires May 20, 2012                 [Page 56]


Internet-Draft                 RFC6045-bis                 November 2011


      *  If restriction is set within individual IODEF classes, the
         restriction applies to the specific IODEF class and the
         children of that class.

   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 8.5 and 8.6 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.  RID Policy 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 request and
   Report messages to peer networks.  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.

8.2.  Message Transport

   The transport specifications are fully defined in a separate document
   [RFC6046-bis].  The specified transport protocols MUST use encryption
   to provide an additional level of security and integrity, while
   supporting mutual authentication through bi-directional 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 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 are discussed in Section 8.1 of this
   document.

   XML security functions such as the digital signature [RFC3275] and



Moriarty                  Expires May 20, 2012                 [Page 57]


Internet-Draft                 RFC6045-bis                 November 2011


   encryption [XMLencrypt] provide a standards-based method to encrypt
   and digitally sign RID messages.  RID messages specify system use and
   privacy guidelines through the RIDPolicy class.  A public key
   infrastructure (PKI) provides the base for authentication and
   authorization, encryption, and digital signatures to establish trust
   relationships between members of a RID consortium or a peering
   consortium.

   XML security functions such as the digital signature [RFC3275] and
   encryption [XMLencrypt] can be used within the contents of the
   message for privacy and security in cases for which certain elements
   must remain encrypted or signed as they traverse the path of a trace.
   For example, the digital signature on a TraceRequest can be used to
   verify the identity of the trace originator.  The use of the XML
   security features in RID messaging is in accordance with the
   specifications for the IODEF model; however, the use requirements may
   differ since RID also incorporates communication of security incident
   information.

8.3.  Message Delivery Protocol - Integrity and Authentication

   The RID protocol must be able to guarantee delivery and meet the
   necessary security requirements of a state-of-the-art protocol.  In
   order to guarantee delivery, TCP should be considered as the
   underlying protocol within the current network standard practices.

   Security requirements must include the integrity, authentication,
   privacy, and authorization of the messages sent between systems
   communicating via RID.  The communication between RID systems must be
   authenticated and encrypted to ensure the integrity of the messages
   and the RID systems involved in the trace.  Another concern that
   needs to be addressed is authentication for a request that traverses
   multiple networks.  In this scenario, systems in the path of the
   multi-hop TraceRequest need to authorize a trace from not only their
   neighbor network, but also from the initiating RID system as
   discussed in Section 8.5.  Several methods can be used to ensure
   integrity and privacy of the communication.

   The transport mechanism selected MUST follow the defined transport
   protocol [RFC6046-bis] when using RID messaging to ensure consistency
   among the peers.  Consortiums may vary their selected transport
   mechanisms and thus must decide upon a mutual protocol to use for
   transport when communicating with peers in a neighboring consortium
   using RID.  RID systems MUST implement and deploy HTTPS as defined in
   the transport document [RFC6046-bis] and optionally support other
   protocols such as the Blocks Extensible Exchange Protocol (BEEP).
   RID, the XML security functions, and transport protocols must
   properly integrate with a public key infrastructure (PKI) managed by



Moriarty                  Expires May 20, 2012                 [Page 58]


Internet-Draft                 RFC6045-bis                 November 2011


   the consortium or one managed by a trusted entity.  For the Internet,
   a few of examples of existing efforts that could be leveraged to
   provide the supporting PKI include the American Registry for Internet
   Numbers (ARIN) and the Regional Internet Registry's (RIR's) PKI
   hierarchy, vendor issued certificates, or approved issuers of
   Extended Validation (EV) Certificates.  Security and privacy
   considerations related to consortiums are discussed in Sections 8.5
   and 8.6.

8.4.  Transport Communication

   Out-of-band communications dedicated to SP interaction for RID
   messaging would provide additional security as well as guaranteed
   bandwidth during a denial-of-service attack.  For example, an out-of-
   band channel may consist of logical paths defined over the existing
   network.  Out-of-band communications may not be practical or possible
   between service providers, but provisions should be considered to
   protect the incident management systems used for RID messaging.
   Methods to protect the data transport may also be provided through
   session encryption.

   In order to address the integrity and authenticity of messages,
   transport encryption MUST be used to secure the traffic sent between
   RID systems.  Systems with predefined relationships for RID include
   those who peer within a consortium with agreed-upon appropriate use
   regulations and for peering consortiums.  Trust relationships may
   also be defined through a bridged or hierarchical PKI in which both
   peers belong.

   Systems used to send authenticated RID messages between networks MUST
   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 only listen for and send RID messages
   on 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.

8.5.  Authentication of RID Protocol

   In order to ensure the authenticity of the RID messages, a message
   authentication scheme is used to secure the protocol.  XML security
   functions utilized in RID require a trust center such as a PKI for
   the distribution of credentials to provide the necessary level of



Moriarty                  Expires May 20, 2012                 [Page 59]


Internet-Draft                 RFC6045-bis                 November 2011


   security for this protocol.  Layered transport protocols also utilize
   encryption and rely on a trust center.  Public key certificate pairs
   issued by a trusted Certification Authority (CA) MAY be used to
   provide the necessary level of authentication and encryption for the
   RID protocol.  The CA used for RID messaging must be trusted by all
   involved parties and may take advantage of similar efforts, such as
   the Internet2 federated PKI or the ARIN/RIR effort to provide a PKI
   to network providers.  The PKI used for authentication also provides
   the necessary certificates needed for encryption used for the RID
   transport protocol [RFC6046-bis].

   The use of pre-shared keys may be considered for authentication.  If
   this option is selected, the specifications set forth in "Pre-Shared
   Key Ciphersuites for Transport Layer Security (TLS)" [RFC4279] MUST
   be followed.

   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.  The IODEF specification MUST be followed for
   digital signatures to provide the authentication and integrity
   aspects required for secure messaging between network providers.  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.  Transport
   specifications are detailed in a separate document [RFC6046-bis].

   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.

8.5.1.  Multi-Hop TraceRequest Authentication

   Bilateral trust relations between network providers ensure the
   authenticity of requests for TraceRequests from immediate peers in
   the web of networks formed to provide the traceback capability.  A
   network provider several hops into the path of the RID trace must
   trust the information from its own trust relationships as well as the
   previous trust relationships in the downstream path.  The use of
   multi-hop authentication in an Investigation request is used when an
   Investigation is sent to multiple entities or SPs in an iterative



Moriarty                  Expires May 20, 2012                 [Page 60]


Internet-Draft                 RFC6045-bis                 November 2011


   manner.  For practical reasons, the SPs may want to prioritize
   incident handling events based upon the immediate peer for a
   TraceRequest, the originator of a request, and the listed Confidence
   rating for the incident.  In order to provide a higher assurance
   level of the authenticity of the TraceRequest, the originating RID
   system is included in the TraceRequest along with contact information
   and the information of all RID systems in the path the trace has
   taken.  This information is provided through the IODEF EventData
   class nesting the list of systems and contacts involved in a trace,
   while setting the category attribute to "infrastructure".

   A second measure MUST be taken to ensure the identity of the
   originating RID system.  The originating RID system MUST include a
   digital signature in the TraceRequest sent to all systems in the
   upstream path.  The digital signature from the RID system is
   performed on the RecordItem class of the IODEF following the XML
   digital signature specifications from W3C [XMLsig] using a detached
   signature.  The signature MUST be passed to all parties that receive
   a TraceRequest, and each party MUST be able to perform full path
   validation on the digital signature [RFC5280].  Full path validation
   verifies the chaining relationship to a trusted root and also
   performs a certificate revocation check.  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 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 TraceRequest or Investigation 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 network using RID sends a
   TraceRequest to its provider, the signature from the enterprise
   network 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 TraceRequest.
   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



Moriarty                  Expires May 20, 2012                 [Page 61]


Internet-Draft                 RFC6045-bis                 November 2011


   the authenticity of RID requests.

8.6.  Consortiums and Public Key Infrastructures

   Consortiums of SPs 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 for use of the
   RID protocol.  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 SPs
   of 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.

   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 and policy to provide authentication, integrity, and
      privacy.

   The functions described for a consortium's role parallel that 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.




Moriarty                  Expires May 20, 2012                 [Page 62]


Internet-Draft                 RFC6045-bis                 November 2011


   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.  The PKI may be a subordinate CA or in
   the CA hierarchy from the SP's consortium to establish the trust
   relationships necessary as the request is made to other connected
   networks.

8.7.  Privacy Concerns and System Use Guidelines

   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 that MUST be addressed in the RID
   system and other integrated components include the following:

   Network Provider Concerns:

   o  Privacy of data monitored and/or stored on IDSs for attack
      detection.

   o  Privacy of data monitored and stored on systems used to trace
      traffic across a single network.

   Customer Attached Networks Participating in RID with SP:

   o  Customer networks may include an enterprise, educational,
      government, or other attached networks to an SP participating in
      RID and MUST be made fully aware of the security and privacy
      considerations for using RID.

   o  Customers MUST know the security and privacy considerations in
      place by their SP and the consortium of which the SP is a member.

   o  Customers MUST understand that their data can and will be sent to
      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.

   Parties Involved in the Attack:

   o  Privacy of the identity of a host involved in an attack.

   o  Privacy of information such as the source and destination used for
      communication purposes over the monitored or RID connected
      network(s).





Moriarty                  Expires May 20, 2012                 [Page 63]


Internet-Draft                 RFC6045-bis                 November 2011


   o  Protection of data from being viewed by intermediate parties in
      the path of an Investigation request MUST be considered.

   Consortium Considerations:

   o  System use restricted to security incident handling within the
      local region's definitions of appropriate traffic for the network
      monitored and linked via RID in a single consortium also abiding
      by the consortium's use guidelines.

   o  System use prohibiting the consortium's participating SPs from
      inappropriately tracing non-attack traffic to locate sources or
      mitigate traffic unlawfully within the jurisdiction or region.

   Inter-Consortium Considerations:

   o  System use between peering consortiums MUST also adhere to any
      government communication regulations that apply between those two
      regions, such as encryption export and import restrictions.  This
      may include consortiums that are categorized as
      "BetweenConsortiums" or "AcrossNationalBoundaries".

   o  System use between consortiums MUST NOT request traffic traces and
      actions beyond the scope intended and permitted by law or inter-
      consortium agreements.

   o  System use between consortiums classified as
      "AcrossNationalBoundaries" MUST respect national boundary issues
      and limit requests to appropriate system use and not to achieve
      their own agenda to limit or restrict 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.  Some
   privacy considerations are addressed through the RID guidelines for
   encryption and digital signatures as described in Section 8.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
   network provider used by the source of the traffic.  It should be
   noted that the trace mechanism used across a single-network provider
   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



Moriarty                  Expires May 20, 2012                 [Page 64]


Internet-Draft                 RFC6045-bis                 November 2011


   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
   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 network provider 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



Moriarty                  Expires May 20, 2012                 [Page 65]


Internet-Draft                 RFC6045-bis                 November 2011


   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 an Investigation request, 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 network provider.  In that situation, options must
   support sending Result messages from a downstream peer of that
   network provider.  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.

   Privacy concerns when using an Investigation message to request
   action close to the source of valid attack traffic needs 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 needs 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.  TraceRequests, Investigation requests, 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



Moriarty                  Expires May 20, 2012                 [Page 66]


Internet-Draft                 RFC6045-bis                 November 2011


   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
   they traverse the path of trusted servers.  Each RID system MUST
   perform a bi-directional 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 the transport protocol [RFC6046-bis].  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.  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.

   Authenticated encrypted 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.



Moriarty                  Expires May 20, 2012                 [Page 67]


Internet-Draft                 RFC6045-bis                 November 2011


   Trust relationships are based on consortiums and established trust
   relationships of public key infrastructure (PKI) cross-certifications
   of consortiums.  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 consortia.  The agreements SHOULD consider key
   management practices including the ability to perform path validation
   on certificates [RFC5280], key distribution techniques [RFC2585],
   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 this section.  The formality, requirements, and
   complexity of the agreements for the certificate policy, practices,
   and the use of RID options SHOULD be decided by the entities or
   consortiums creating those agreements.


10.  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-1.1

   Registrant Contact: See the "Author's Address" section of this
   document.

   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-1.1

   Registrant Contact: See the "Author's Address" section of this
   document.

   XML: See Section 7, "RID Schema Definition", of this document.





Moriarty                  Expires May 20, 2012                 [Page 68]


Internet-Draft                 RFC6045-bis                 November 2011


11.  Summary

   Security incidents have always been difficult to trace as a result of
   the 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.  Network providers 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
   network providers.  The communication is accomplished through the use
   of flexible IODEF XML-based documents passed between IHSs or RID
   systems.  A TraceRequest or Investigation 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.


12.  References

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

   [RFC3275]  Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
              Language) XML-Signature Syntax and Processing", RFC 3275,
              March 2002.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites



Moriarty                  Expires May 20, 2012                 [Page 69]


Internet-Draft                 RFC6045-bis                 November 2011


              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.

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

   [RFC5755]  Farrell, S., Housley, R., and S. Turner, "An Internet
              Attribute Certificate Profile for Authorization",
              RFC 5755, January 2010.

   [RFC6046-bis]
              Trammell, B., "Transport of Real-time Inter-network
              Defense (RID) Messages", September 2011, <http://
              tools.ietf.org/html/draft-trammell-mile-rfc6046-bis-01>.

   [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/>.

   [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/>.

   [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/>.




Moriarty                  Expires May 20, 2012                 [Page 70]


Internet-Draft                 RFC6045-bis                 November 2011


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

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

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

   Acknowledgements

   Many thanks to colleagues and the Internet community for reviewing
   and commenting on the document as well as providing recommendations
   to simplify and secure the protocol: Robert K. Cunningham, Ph.D,
   Cynthia D. McLain, Dr. William Streilein, Iljitsch van Beijnum, Steve
   Bellovin, Yuri Demchenko, Jean-Francois Morfin, Stephen Northcutt,
   Jeffrey Schiller, Brian Trammell, Roman Danyliw, Tony Tauber, Sandra
   G. Dykes, Ph.D., Katherine Goodier, Ph.D., Tony Rutkowski, Damir
   Rajnovic, and David Black.


Author's Address

   Kathleen M. Moriarty
   EMC Corporation
   176 South Street
   Hopkinton, MA
   United States

   Phone:
   Email: Kathleen.Moriarty@emc.com












Moriarty                  Expires May 20, 2012                 [Page 71]