path: root/doc/rfc/rfc6045.txt

Internet Engineering Task Force (IETF)                       K. Moriarty
Request for Comments: 6045                                           EMC
Category: Informational                                    November 2010
ISSN: 2070-1721


                 Real-time Inter-network Defense (RID)

Abstract

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

   RID has found use within the international research communities, but
   has not been widely adopted in other sectors.  This publication
   provides the specification to those communities that have adopted it,
   and communities currently considering solutions for real-time inter-
   network defense.  The specification may also accelerate development
   of solutions where different transports or message formats are
   required by leveraging the data elements and structures specified
   here.

















Moriarty                      Informational                     [Page 1]
^L
RFC 6045                           RID                     November 2010


Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6045.

Copyright Notice

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

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





















Moriarty                      Informational                     [Page 2]
^L
RFC 6045                           RID                     November 2010


Table of Contents

   1. Introduction ....................................................4
      1.1. Normative and Informative ..................................6
      1.2. Terminology ................................................6
      1.3. Attack Types and RID Messaging .............................6
   2. RID Integration with Network Provider Technologies ..............8
   3. Characteristics of Attacks ......................................9
      3.1. Integrating Trace Approaches ..............................11
      3.2. Superset of Packet Information for Traces .................11
   4. Communication between Network Providers ........................12
      4.1. Inter-Network Provider RID Messaging ......................14
      4.2. RID Network Topology ......................................16
      4.3. Message Formats ...........................................17
           4.3.1. RID Data Types .....................................17
                  4.3.1.1. Boolean ...................................17
           4.3.2. RID Messages and Transport .........................18
           4.3.3. IODEF-RID Schema ...................................19
                  4.3.3.1. RequestStatus Class .......................21
                  4.3.3.2. IncidentSource Class ......................23
                  4.3.3.3. RIDPolicy Class ...........................24
           4.3.4. RID Namespace ......................................29
      4.4. RID Messages ..............................................29
           4.4.1. TraceRequest .......................................29
           4.4.2. RequestAuthorization ...............................30
           4.4.3. Result .............................................31
           4.4.4. Investigation Request ..............................33
           4.4.5. Report .............................................35
           4.4.6. IncidentQuery ......................................36
      4.5. RID Communication Exchanges ...............................37
           4.5.1. Upstream Trace Communication Flow ..................39
                  4.5.1.1. RID TraceRequest Example ..................40
                  4.5.1.2. RequestAuthorization Message Example ......44
                  4.5.1.3. Result Message Example ....................44
           4.5.2. Investigation Request Communication Flow ...........47
                  4.5.2.1. Investigation Request Example .............48
                  4.5.2.2. RequestAuthorization Message Example ......50
           4.5.3. Report Communication ...............................51
                  4.5.3.1. Report Example ............................51
           4.5.4. IncidentQuery Communication Flow ...................54
                  4.5.4.1. IncidentQuery Example .....................54
   5. RID Schema Definition ..........................................55









Moriarty                      Informational                     [Page 3]
^L
RFC 6045                           RID                     November 2010


   6. Security Considerations ........................................60
      6.1. Message Transport .........................................62
      6.2. Message Delivery Protocol - Integrity and Authentication ..63
      6.3. Transport Communication ...................................63
      6.4. Authentication of RID Protocol ............................64
           6.4.1. Multi-Hop TraceRequest Authentication ..............65
      6.5. Consortiums and Public Key Infrastructures ................66
      6.6. Privacy Concerns and System Use Guidelines ................67
   7. IANA Considerations ............................................72
   8. Summary ........................................................72
   9. References .....................................................73
      9.1. Normative References ......................................73
      9.2. Informative References ....................................74
   Acknowledgements ..................................................75
   Sponsor Information ...............................................75

1.  Introduction

   Incident handling involves the detection, reporting, identification,
   and mitigation of an attack, whether it be a system compromise,
   socially engineered phishing attack, or a denial-of-service (DoS)
   attack.  When an attack is detected, the response may include simply
   filing a report, notification to the source of the attack, a request
   for mitigation, or the 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 victim system and the attacker or source system
   are available, the source is easy to identify.  The problem of
   tracing incidents becomes more difficult when the source is obscured
   or spoofed, logs are deleted, and the number of sources is
   overwhelming.  If the source of an attack is known or identified, it
   may be desirable to request actions be taken to stop or mitigate the
   effects of the attack.

   Current approaches to mitigating the effects of security incidents
   are aimed at identifying and filtering or rate-limiting packets from
   attackers who seek to hide the origin of their attack by source
   address spoofing from multiple locations.  Measures can be taken at
   network provider (NP) edge routers providing ingress, egress, and
   broadcast filtering as a recommended best practice in [RFC2827].

   Network providers have devised solutions, in-house or commercial, to
   trace attacks across their backbone infrastructure to either identify
   the source on their network or on the next upstream network in the
   path to the source.  Techniques such as collecting packets as traffic
   traverses the network have been implemented to provide the capability



Moriarty                      Informational                     [Page 4]
^L
RFC 6045                           RID                     November 2010


   to trace attack traffic after an incident has occurred.  Other
   methods use packet-marking techniques or flow-based traffic analysis
   to trace traffic across the network in real time.  The single-network
   trace mechanisms use similar information across the individual
   networks to trace traffic.  Problems may arise when an attempt is
   made to have a trace continued through the next upstream network
   since the trace mechanism and management may vary.

   In the case in which the traffic traverses multiple networks, there
   is currently no established communication mechanism for continuing
   the trace.  If the next upstream network has been identified, a phone
   call might be placed to contact the network administrators in an
   attempt to have them continue the trace.  A communication mechanism
   is needed to facilitate the transfer of information to continue
   traces accurately and efficiently to upstream networks.  The
   communication mechanism described in this paper, Real-time Inter-
   network Defense (RID), takes into consideration the information
   needed by various single-network trace implementations and the
   requirement for network providers to decide if a TraceRequest should
   be permitted to continue.  The data in RID messages is represented in
   an Extensible Markup Language (XML) [XML1.0] document using the
   Incident Object Description Exchange Format (IODEF) and RID.  By
   following this model, integration with other aspects of the network
   for incident handling is simplified.  Finally, 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 attack at hand.  RID is intended to 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.

   At this point, RID has found use within the international research
   communities, but has not been widely adopted in other sectors.  This
   publication provides the specification to those communities that have
   adopted it, and communities currently considering solutions for real-
   time inter-network defense.  The specification may also accelerate
   development of solutions where different transports or message
   formats are required by leveraging the data elements and structures
   specified here.

   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 security incidents.  RID
   messages are encapsulated for transport, which is defined in a



Moriarty                      Informational                     [Page 5]
^L
RFC 6045                           RID                     November 2010


   separate document [RFC6046].  The authentication, integrity, and
   authorization features each layer has to offer are used to achieve a
   necessary level of security.

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, 2, and 3;
   and the sub-sections of 4 including the introduction to 4, 4.1, and
   4.2.  The following sections of this document are normative: The
   sub-sections of 4 including 4.3, 4.4, and 4.5; Section 5; and
   Section 6.

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

1.3.  Attack Types and RID Messaging

   RID messaging is intended for use in coordinating incident handling
   to locate the source of an attack and stop or mitigate the effects of
   the attack.  The attack types include system or network compromises,
   denial-of-service attacks, or other malicious network traffic.  RID
   is essentially a messaging system coordinating attack detection,
   tracing mechanisms, and the incident handling responses to locate the
   source of traffic.  If a source address is spoofed, a more detailed
   trace of a packet (RID TraceRequest) would be required to locate the
   true source.  If the source address is valid, the incident handling
   may only involve the use of routing information to determine what
   network provider is closest to the source (RID Investigation request)
   and can assist with the remediation.  The type of RID message used to
   locate a source is determined by the validity of the source address.
   RID message types are discussed in Section 4.3.

   DoS [DoS] attacks are characterized by large amounts of traffic
   destined for particular Internet locations and can originate from a
   single or multiple sources.  An attack from multiple sources is known
   as a distributed denial-of-service (DDoS) attack.  Because DDoS
   attacks can originate from multiple sources, tracing such an attack
   can be extremely difficult or nearly impossible.  Many TraceRequests
   may be required to accomplish the task and may require the use of
   dedicated network resources to communicate incident handling
   information to prevent a DoS attack against the RID system and
   network used for tracing and remediation.  Provisions are suggested



Moriarty                      Informational                     [Page 6]
^L
RFC 6045                           RID                     November 2010


   to reduce the load and prevent the same trace from occurring twice on
   a single-network backbone discussed in Section 4 on communication
   between NPs.  The attacks can be launched from systems across the
   Internet unified in their efforts or by compromised systems enlisted
   as "zombies" that are controlled by servers, thereby providing
   anonymity to the controlling server of the attack.  This scenario may
   require multiple RID traces, one to locate the zombies and an
   additional one to locate the controlling server.  DDoS attacks do not
   necessarily spoof the source of an attack since there are a large
   number of source addresses, which make it difficult to trace anyway.
   DDoS attacks can also originate from a single system or a subset of
   systems that spoof the source address in packet headers in order to
   mask the identity of the attack source.  In this case, an iterative
   trace through the upstream networks in the path of the attack traffic
   may be required.

   RID traces may also be used to locate a system used in an attack to
   compromise another system.  Compromising a system can be accomplished
   through one of many attack vectors, using various techniques from a
   remote host or through local privilege escalation attempts.  The
   attack may exploit a system or application level vulnerability that
   may be the result of a design flaw or a configuration issue.  A
   compromised system, as described above, can be used to later attack
   other systems.  A single RID Investigation request may be used in
   this case since it is probable that the source address is valid.
   Identifying the sources of system compromises may be difficult since
   an attacker may access the compromised system from various sources.
   The attacker may also take measures to hide their tracks by deleting
   log files or by accessing the system through a series of compromised
   hosts.  Iterative RID traces may be required for each of the
   compromised systems used to obscure the source of the attack.  If the
   source address is valid, an Investigation request may be used in lieu
   of a full RID TraceRequest.

   Once an attack has been reported, CSIRTs may want to query other
   CSIRTs if they have detected an attack or simply report that one has
   taken place.  The Report message can be used to file a report without
   an action taken, and an IncidentQuery can be used to ask if an attack
   has been seen by another CSIRT.

   System compromises may result from other security incident types such
   as worms, Trojans, or viruses.  It is often the case that an incident
   goes unreported even if valid source address information is available
   because it is difficult to take any action to mitigate or stop the
   attack.  Incident handling is a difficult task for an NP and even at
   some client locations due to network size and resource limitations.





Moriarty                      Informational                     [Page 7]
^L
RFC 6045                           RID                     November 2010


2.  RID Integration with Network Provider Technologies

   For the purpose of this document, a network provider (NP) shall be
   defined as a backbone infrastructure manager of a network.  The
   network provider's Computer Security Incident Response Team shall be
   referred to as the CSIRT.  The backbone may be that of an
   organization providing network (Internet or private) access to
   commercial, personal, government, or educational institutions, or the
   backbone provider of the connected network.  The connected network
   provider is an extension meant to include Intranet and Extranet
   providers as well as instances such as a business or educational
   institute's private network.

   NPs typically manage and monitor their networks through a centralized
   network management system (NMS).  The acronym "NMS" will be used to
   generically represent management systems on a network used for the
   management of network resources.  An incident handling system (IHS)
   is used to communicate RID messages and may be integrated with an NMS
   as well as other components of the network.  The components of the
   network that may be integrated through the RID messaging system
   include attack or event detection, network tracing, and network
   devices to stop the effects of an attack.

   The detection of security incidents may rely on manual reporting,
   automated intrusion detection tools, and variations in traffic types
   or levels on a network.  Intrusion detection systems (IDSs) may be
   integrated into the IHS to create IODEF documents or RID messages to
   facilitate security incident handling.  Detection of a security
   incident is outside the scope of this paper; however, it should be
   possible to integrate detection methods with RID messaging.

   RID messaging in an IHS is intended to be flexible in order to
   accommodate various traceback systems currently in use as well as
   those that may evolve with technology.  RID is intended to
   communicate the necessary information needed by a trace mechanism to
   the next upstream NP in the path of a trace.  Therefore, a RID
   message must carry the superset of data required for all tracing
   systems.  If possible, the trace may need to inspect packets to
   determine a pattern, which could assist reverse path identification.
   This may be accomplished by inspecting packet header information such
   as the source and destination IP addresses, ports, and protocol flags
   to determine if there is a way to distinguish the packets being
   traced from other packets.  A description of the incident along with
   any available automated trace data should trigger an alert to the
   NP's CSIRT for further investigation.  The various technologies used
   to trace traffic across a network are described in Section 3.1.





Moriarty                      Informational                     [Page 8]
^L
RFC 6045                           RID                     November 2010


   Another area of integration is the ability to mitigate or stop attack
   traffic once a source has been located.  Any automated solution
   should consider the possible side effects to the network.  A change
   control process or a central point for configuration management might
   be used to ensure that the security of the network and necessary
   functionality are maintained and that equipment configuration changes
   are documented.  Automated solutions may depend upon the capabilities
   and current configuration management solutions on a particular
   network.  The solutions may be based on HTTP/TLS (Transport Layer
   Security) or an appropriate protocol defined in the transport
   specification.

3.  Characteristics of Attacks

   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.  A security incident may be defined as a 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 to halt or mitigate the
   undesired behavior.  The communication system, RID, described in this
   paper can be used to trace any type of security incident and allows
   for actions to be taken when the source of the attack or a point
   closer to the source is known or has been identified.  The purpose of
   tracing an attack would be to halt or mitigate the effects of the
   attack through methods such as filtering or rate-limiting the traffic
   close to the source or by using methods such as taking the host or
   network offline.  Care must also be taken to ensure that the system
   is not abused and to use proper analysis in determining if attack
   traffic is, in fact, attack traffic at each NP 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.  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 tracing attacks include
   the following:




Moriarty                      Informational                     [Page 9]
^L
RFC 6045                           RID                     November 2010


   o  the attack originates from multiple sources;

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

   If the source(s) of the attack cannot be determined from IP address
   information or tracing the increased bandwidth utilization, it may be
   possible to trace the traffic based on the type of packets seen by
   the client.  In the case of packets with spoofed source addresses, it
   is no longer a trivial task to identify the source of an attack.  In
   the case of an attack using valid source addresses, methods such as
   the traceroute utility can be used to fairly accurately identify the
   path of the traffic between the source and destination of an attack.
   If the true source has been identified, actions should be taken to
   halt or mitigate the effects of the attack by reporting the incident
   to the NP or the upstream NP closest to the source.  In the case of a
   spoofed source address, other methods can be used to trace back to
   the source of an attack.  The methods include packet filtering,
   packet hash comparisons, IP marking techniques, ICMP traceback, and
   packet flow analysis.  As in the case of attack detection, tracing
   traffic across a single network is a function that can be used with
   RID in order to provide the network with the ability to trace spoofed
   traffic to the source, while RID provides all the necessary
   information to accommodate the approach used on any single network to
   accomplish this task.  RID can also be used to report attack traffic
   close to the source where the IP address used was determined to be
   valid or simply to report that an incident occurred.







Moriarty                      Informational                    [Page 10]
^L
RFC 6045                           RID                     November 2010


3.1.  Integrating Trace Approaches

   There have been many separate research initiatives to solve the
   problem of tracing upstream packets to detect the true source of
   attack traffic.  Upstream packet tracing is currently confined to the
   borders of a network or an NP's network.  Traces require access to
   network equipment and resources, thus potentially limiting a trace to
   a specific network.  Once a trace reaches the boundaries of a
   network, the network manager or NP adjacent in the upstream trace
   must be contacted in order to continue the trace.  NPs have been
   working on individual solutions to accomplish upstream tracing within
   their own network environments.  The tracing mechanisms implemented
   thus far have included proprietary or custom solutions requiring
   specific information such as IP packet header data, hash values of
   the attack packets, or marked packets.  Hash values are used to
   compare a packet against a database of packets that have passed
   through the network as described in "Hash-Based IP Traceback"
   [HASH-IPtrace].  Other research solutions involve marking packets as
   explained in "ICMP Traceback Messages" [ICMPtrace], "Practical
   network support for IP traceback" [NTWK-IPtrace], the IP Flow
   Information eXport (IPFIX) protocol [RFC3917], and IP marking
   [IPtrace].  The single-network traceback solutions were considered in
   developing RID to determine the information needed to accomplish an
   inter-network trace where different solutions may be in place.

3.2.  Superset of Packet Information for Traces

   In order for network traffic to be traced across a network, an
   example packet from the attack must be sent along with the
   TraceRequest or Investigation request.  According to the research for
   hash-based IP traceback, all of the non-changing fields of an IP
   header along with 8 bytes of payload are required to provide enough
   information to uniquely trace the path of a packet.  The non-changing
   fields of the packet header and the 8 bytes of payload are the
   superset of data required by most single-network tracing systems
   used; limiting the shared data to the superset of the packet header
   and 8 bytes of payload prevents the need for sharing potentially
   sensitive information that may be contained in the data portion of a
   packet.

   The RecordItem class in the IODEF is used to store a hexadecimal
   formatted packet including all packet header information plus 8 bytes
   of payload, or the entire packet contents.  The above trace systems
   do not require a full packet, but it may be useful in some cases, so
   the option is given to allow a full packet to be included in the data
   model.





Moriarty                      Informational                    [Page 11]
^L
RFC 6045                           RID                     November 2010


   If a subset of a packet is used, the research presented in "Hash-
   Based IP Traceback" [HASH-IPtrace] provides guidelines to establish a
   minimum requirement for distinguishing packets.  The full packet and
   content SHOULD be provided, but the minimum requirement MUST be
   provided.  The research from [HASH-IPtrace] found that the first 28
   invariant bytes of a packet (masked IP header plus the first 8 bytes
   of the payload) are sufficient to differentiate almost all non-
   identical IPv4 packets.  RID requires the first 28 invariant bytes of
   an IPv4 packet in order to perform a trace.  RID requires the first
   48 invariant bytes for an IPv6 packet in order to distinguish the
   packet in a trace.  Reference [HASH-IPtrace] for additional details.

   The input mechanism for packets to be traced should be flexible to
   allow intrusion detection systems or packet sniffers to provide the
   information.  The system creating the RID message should also use the
   packet information to populate the Incident class information in
   order to avoid human error and also allow a system administrator to
   override the automatically populated information.

4.  Communication between Network Providers

   Note: The Introduction, and Sub-sections 4.1 and 4.2, are
   informative, with the exception of references to IODEF/RID Transport
   [RFC6046].  Sub-sections 4.3, 4.4, and 4.5 are normative.

   Expediting the communication between CSIRTs is essential when
   responding to a security-related incident, which may cross network
   access points (Internet backbones) between providers.  As a result of
   the urgency involved in this inter-NP security incident
   communication, there must be an effective system in place to
   facilitate the interaction.  This communication policy or system
   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.

   Each NP should dedicate a phone number to reach a member of their
   respective CSIRT.  The phone number could be dedicated to inter-NP
   incident communications and must be a hotline that provides a 24x7
   live response.  The phone line should reach someone who would have
   the authority, expertise, and the means to expedite the necessary
   action to investigate the incident.  This may be a difficult policy
   to establish at smaller NPs due to resource limitations, so another
   solution may be necessary.  An outside group may be able to serve
   this function if given the necessary access to the NP's network.  The
   outside resource should be able to mitigate or alleviate the
   financial limitations and any lack of experienced resource personnel.



Moriarty                      Informational                    [Page 12]
^L
RFC 6045                           RID                     November 2010


   A technical solution to trace traffic across a single NP may include
   homegrown or commercial systems for which RID messaging must
   accommodate the input requirements.  The IHS used on the NP's
   backbone by the CSIRT to coordinate the trace across the single
   network requires a method to accept and process RID messages and
   relay TraceRequests 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 NP would maintain its own RID/IHS and
   integrate with a management station used for network monitoring and
   analysis.  An alternative for NPs lacking sufficient resources may be
   to have a neutral third party with access to the NP'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 the Internet as a whole or within a
   consortium that may be able to provide centralized resources.
   Consortiums would consist of a group of NPs and/or CSIRTs that agree
   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 [RFC6046] document.

   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 IHSs to communicate incident handling information to other
   networks 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
   NPs.  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 NPs to
   maintain full management of their network, and the third-party option
   could be available to smaller NPs who lack the necessary human
   resources to perform incident handling operations.  The first method
   enables the individual NPs 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 out-of-band logical solution
   for messaging may be permanent virtual circuits configured with a
   small amount of bandwidth dedicated to RID communications between
   NPs.

   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 between network peers
   who have agreed-upon use and abuse policies through the use of a
   consortium.  Consortiums might be linked through policy comparisons



Moriarty                      Informational                    [Page 13]
^L
RFC 6045                           RID                     November 2010


   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.  The maintenance of the individual links is
   the responsibility of the two network peers hosting the link.
   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 NP 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 network
   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.

4.1.  Inter-Network Provider RID Messaging

   In order to implement a messaging mechanism between RID communication
   systems or IHSs, a standard protocol and format is required to ensure
   inter-operability between vendors.  The messages would have to meet
   several requirements in order to be meaningful as they traverse
   multiple networks.  RID provides the framework necessary for
   communication between networks involved in the incident handling,
   possible traceback, and mitigation of a security incident.  Several
   message types described in Section 4.3 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 traffic.  The
   RequestAuthorization and Result messages are used to communicate the



Moriarty                      Informational                    [Page 14]
^L
RFC 6045                           RID                     November 2010


   status and result of a TraceRequest or Investigation request.  The
   Investigation request message would only involve the RID
   communication systems 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 would require
   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 for this system and one 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 Considerations section, along
   with other requirements that must be agreed upon by participating
   entities.



Moriarty                      Informational                    [Page 15]
^L
RFC 6045                           RID                     November 2010


   RID requests must be legitimate security-related incidents and not
   used for purposes such as sabotage or censorship.  An example of such
   abuse of the system would include 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 would enable a network
   manager to assess the available resources before continuing a trace.
   A trace initiated from a TraceRequest may cause adverse effects on a
   network.  If the Confidence rating is low, it may not be in the NP's
   best interest to continue the 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 network, set forth in
   policy guidelines established through peering or SLA.

4.2.  RID Network Topology

   The most basic topology for communicating RID systems would be a
   direct connection or a bilateral relationship as illustrated below.

         ___________                                  __________
         |         |                                  |        |
         |  RID    |__________-------------___________|  RID   |
         |_________|          | NP 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 would look 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.  An
   example is illustrated below.






Moriarty                      Informational                    [Page 16]
^L
RFC 6045                           RID                     November 2010


     _______                     _______                     _______
     |     |                     |     |                     |     |
   __| RID |____-------------____| RID |____-------------____| RID |__
     |_____|    | NP Border |    |_____|    | NP 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.

4.3.  Message Formats

   Section 4.3.2 describes the six RID message types, which are based on
   the IODEF model [RFC5070].  The messages are generated and received
   on RID communication systems on the NP's network.  The messages may
   originate from IODEF messages from intrusion detection servers,
   CSIRTs, analysts, etc.  A RID message uses the IODEF framework with
   the RID extension, which is encapsulated for transport [RFC6046].
   Each RID message type, along with an example, is described in the
   following sections.  The IODEF-RID schema is introduced in
   Section 4.3.3 to support the RID message types in Section 4.3.2.

4.3.1.  RID Data Types

   RID is derived from the IODEF data model and inherits all of the data
   types defined in the IODEF model.  One data type is added by RID:
   BOOLEAN.

4.3.1.1.  Boolean

   A boolean value is represented by the BOOLEAN data type.

   The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
   the schema.








Moriarty                      Informational                    [Page 17]
^L
RFC 6045                           RID                     November 2010


4.3.2.  RID Messages and Transport

   The six RID message types follow:

   1. TraceRequest.  This message is sent to the RID system next in the
      upstream trace.  It is 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.  The
      TraceRequest would trigger 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 NPs' RID systems to provide
      information on the request status in the current network.

   3. Result.  This message is sent to the initiating RID system 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, statistics and trending
      information, etc.

   6. IncidentQuery.  This message is used to request information about
      an incident or incident type from a trusted RID system.  The
      response is provided through the Report message.

   When a system 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 communication of
   security incident data to trace, investigate, query, or report
   information regarding security incidents.








Moriarty                      Informational                    [Page 18]
^L
RFC 6045                           RID                     November 2010


4.3.3.  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 6.6.
   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.
















Moriarty                      Informational                    [Page 19]
^L
RFC 6045                           RID                     November 2010


   The RID schema is defined as follows:

        +------------------+
        |        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 originating
      RID system if the 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], 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].





Moriarty                      Informational                    [Page 20]
^L
RFC 6045                           RID                     November 2010


4.3.3.1.  RequestStatus Class

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

      2. Denied.  The trace was denied in the current NP.  The next
         closest NP can use this message to filter traffic from the
         upstream NP 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 NP to the
         source to indicate actions taken in the IODEF History class.







Moriarty                      Informational                    [Page 21]
^L
RFC 6045                           RID                     November 2010


      3. Pending.  Awaiting approval; a timeout period has been reached,
         which resulted in this Pending status and 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.

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

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

      3. AuthenticationOrigin.  The detached digital signature for the
         original requestor on the IP packet failed to validate.

      4. Encryption.  Unable to decrypt the request.

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

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













Moriarty                      Informational                    [Page 22]
^L
RFC 6045                           RID                     November 2010


4.3.3.2.  IncidentSource Class

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

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

                    Figure 5.  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                      Informational                    [Page 23]
^L
RFC 6045                           RID                     November 2010


4.3.3.3.  RIDPolicy Class

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

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

                      Figure 6.  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 would
      be botnets, 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                      Informational                    [Page 24]
^L
RFC 6045                           RID                     November 2010


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

   region

      One.  ENUM.

      1. ClientToNP.  An enterprise network initiated the request.

      2. NPToClient.  An NP passed a RID request to a client or an
         enterprise attached network to the NP based on the service
         level agreements.

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

      4. PeerToPeer.  A trace 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.  A trace 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
         trace type is anything but a trace of attack traffic with
         malicious intent.  This must also be set if the traffic request
         is based upon regulations of a specific nation that would not
         apply to all nations.  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. ext-value.  An escape value used to extend this attribute.  See
         IODEF [RFC5070], Section 5.1.












Moriarty                      Informational                    [Page 25]
^L
RFC 6045                           RID                     November 2010


   TrafficType

      One or many.  REQUIRED.  The values for the attribute "type" are
      meant to assist in determining if a trace is appropriate for the
      NP 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 would most accurately
      describe 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 NP 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 traffic
         being traced is requested or is affiliated with any government
         or other official business request.  This would be used during
         an investigation by government authorities or other government
         traces 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 trace.  The information should be
         provided in the IODEF message in the Expectation class or in
         the History class using a HistoryItem log.

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






Moriarty                      Informational                    [Page 26]
^L
RFC 6045                           RID                     November 2010


   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 4.3.2 and can be noted as one of
      the six selections below.

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

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

      3. Result.  This message indicates that the source of the attack
         was located and the message is sent to the initiating RID
         system through the RID systems in the path of the trace.

      4. 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 NP closest to
         the source of the valid traffic that some event occurred, which
         may be a security-related incident.

      5. Report.  This message is used to report a security incident,
         for which no action is requested in the IODEF Expectation
         class.  This may be used for the purpose of correlating attack
         information by CSIRTs, statistics and trending information,
         etc.

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







Moriarty                      Informational                    [Page 27]
^L
RFC 6045                           RID                     November 2010


      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 RID systems 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                      Informational                    [Page 28]
^L
RFC 6045                           RID                     November 2010


4.3.4.  RID Namespace

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

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

4.4.  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 the RID system may obtain some of the
   information needed to fill in the content required for each message
   type automatically from packet input to the system or default
   information such as that used in the EventData class.

4.4.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                      Informational                    [Page 29]
^L
RFC 6045                           RID                     November 2010


         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 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 NP
            path contact information.

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

         Digital signature from initiating RID system, passed to all
         systems in upstream trace using XML digital signature.

   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 would
   enable 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.

4.4.2.  RequestAuthorization

   Description: This message is sent to the initiating RID system from
   the next upstream NP's RID system to provide information on the
   request status in the current network.





Moriarty                      Informational                    [Page 30]
^L
RFC 6045                           RID                     November 2010


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

      RID Information:

         RIDPolicy
            RID message type, IncidentID, and destination
            policy information

         Status of TraceRequest
            RequestStatus class in RID schema

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

         Digital signature of responding NP for authenticity of Trace
         Status Message, from the NP creating this message using XML
         digital signature.

   A message is sent back to the initiating RID system 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 RID system.  The
   Pending status would be 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.

4.4.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 NP may use any number of incident
   handling data sources to ascertain the true source of an attack.  All
   of the possible information sources may or may not be readily tied
   into the RID communications system.








Moriarty                      Informational                    [Page 31]
^L
RFC 6045                           RID                     November 2010


   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 NP listed
            is the NP that located the source of the traffic (the NP
            sending the Result message).

         Event, Record, and RecordItem classes to include example
            packets and other information related to the incident
            (optional).
            Note: Event information included here requires a second
            instance of EventData in addition to that used to convey NP
            path contact information.



Moriarty                      Informational                    [Page 32]
^L
RFC 6045                           RID                     November 2010


      Standards for encryption and digital signatures [RFC3275]:

         Digital signature of source NP for authenticity of Result
         Message, from the NP creating this message using XML digital
         signature.

   A message is sent back to the initiating RID system to notify the
   associated 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 NP to act upon the discovery of the source of a trace
   should be included.  The NP 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 considerations discussed in Section 6 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.

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



Moriarty                      Informational                    [Page 33]
^L
RFC 6045                           RID                     November 2010


      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 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 NP
            path contact information.

      Standards for encryption and digital signatures [RFC3275]:

         Digital signature from initiating RID system, passed to all
         systems in upstream trace using XML digital signature.

   Security considerations would 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
   would increase as if it were a TraceRequest message in order to
   ensure uniqueness within the system.  The relaying peers would 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 would also be recorded in the state
   tables of both the initiating and destination NP RID systems.  The
   destination NP is responsible for any actions taken as a result of
   the request in adherence to any service level agreements or internal
   policies.  The NP should confirm that the traffic actually originated
   from the suspected system before taking any action and confirm the



Moriarty                      Informational                    [Page 34]
^L
RFC 6045                           RID                     November 2010


   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.

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

         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 XML digital signature.




Moriarty                      Informational                    [Page 35]
^L
RFC 6045                           RID                     November 2010


   Security considerations would 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 NP path information is not necessary for this message, as
   it will be communicated directly between two trusted RID systems.

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



Moriarty                      Informational                    [Page 36]
^L
RFC 6045                           RID                     November 2010


         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 IncidentQuery using XML digital
         signature.  If a packet is not included, the signature may be
         based on the RIDPolicy class.

   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 would send 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.  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.

4.5.  RID Communication Exchanges

   The following section outlines the communication flows for RID and
   also provides examples of messages.  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 NP path information provided through the document instance of
   EventData, where contact is set to "infrastructure".  The NP 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



Moriarty                      Informational                    [Page 37]
^L
RFC 6045                           RID                     November 2010


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

   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 NPs.  Addresses were used from /27 network
   ranges.




































Moriarty                      Informational                    [Page 38]
^L
RFC 6045                           RID                     November 2010


4.5.1.  Upstream Trace Communication Flow

   The diagram below outlines the RID TraceRequest communication flow
   between RID systems on different networks tracing an attack.

   Attack Dest      NP-1            NP-2        NP-3        Attack Src

   1. Attack    |  Attack
      reported  |  detected

   2.              Initiate trace

   3.              Locate origin
                   through
                   upstream NP

   4.              o---TraceRequest----->

   5.                              Trace
                                   Initiated

   6.              <-RequestAuthorization-o

   7.                              Locate origin
                                   through
                                   upstream NP

   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.



Moriarty                      Informational                    [Page 39]
^L
RFC 6045                           RID                     November 2010


   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
   originator of the request may follow up with the downstream peer of
   the NP 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 NP 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 NP upstream of the NP that denied the
   request if enough information was gathered to discern the true source
   of the attack traffic from the incident handling information.

4.5.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 NP.  The request asks the next
   NP to continue the trace and have the traffic mitigated closer to the
   source of the traffic.

   In the following example, use of [XMLsig] to generate digital
   signatures does not currently provide digest algorithm agility, as
   [XMLsig] only supports SHA-1.  A future version of [XMLsig] may
   support additional digest algorithms to support digest algorithm
   agility.

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







Moriarty                      Informational                    [Page 40]
^L
RFC 6045                           RID                     November 2010


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





Moriarty                      Informational                    [Page 41]
^L
RFC 6045                           RID                     November 2010


      <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 NP closer to 192.0.2.35
        </iodef:Description>
      </iodef:HistoryItem>
    </iodef:History>
  </iodef:Incident>
</iodef:IODEF-Document>
























Moriarty                      Informational                    [Page 42]
^L
RFC 6045                           RID                     November 2010


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

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










Moriarty                      Informational                    [Page 43]
^L
RFC 6045                           RID                     November 2010


    <KeyInfo>
      <KeyValue>
        <DSAKeyValue>
          <P>/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j
             QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==</P>
          <Q>li7dzDacuo67Jg7mtqEm2TRuOMU=</Q>
          <G>Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5
             Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==</G>
          <Y>VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs
             HifTyYdnj+roGzy4o09YntYD8zneQ7lw==</Y>
        </DSAKeyValue>
      </KeyValue>
    </KeyInfo>
  </Signature>
</Envelope>

4.5.1.2.  RequestAuthorization Message Example

   The example RequestAuthorization message is in response to the
   TraceRequest message listed above.  The NP 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.0"
               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>

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





Moriarty                      Informational                    [Page 44]
^L
RFC 6045                           RID                     November 2010


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




Moriarty                      Informational                    [Page 45]
^L
RFC 6045                           RID                     November 2010


      <iodef:Flow>
        <iodef:System category="intermediate">
          <iodef:Node>
            <iodef:Address category="ipv4-addr">192.0.2.35
            </iodef:Address>
          </iodef:Node>
        </iodef:System>
      </iodef:Flow>
      <iodef:EventData>
        <iodef:Contact role="admin" type="organization">
          <iodef:ContactName>Admin-contact for 192.0.2.3
          </iodef:ContactName>
          <iodef:Email>Admin-contact@192.0.2.3</iodef:Email>
        </iodef:Contact>
        <iodef:Flow>
          <iodef:System category="intermediate">
            <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>






Moriarty                      Informational                    [Page 46]
^L
RFC 6045                           RID                     November 2010


      <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>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 NP 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-NP3">
          CSIRT-FOR-NP3#3291-1
        </iodef:IncidentID>
        <iodef:Description>
          Host rate-limited for 24 hours
        </iodef:Description>
      </iodef:HistoryItem>
    </iodef:History>
  </iodef:Incident>
</iodef:IODEF-Document>

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



Moriarty                      Informational                    [Page 47]
^L
RFC 6045                           RID                     November 2010


   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.

     Attack Dest      NP-1              NP-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

4.5.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.0"
               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>




Moriarty                      Informational                    [Page 48]
^L
RFC 6045                           RID                     November 2010


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



Moriarty                      Informational                    [Page 49]
^L
RFC 6045                           RID                     November 2010


    <iodef:History>
      <iodef:HistoryItem>
        <iodef:DateTime>2004-02-05T08:19:01+00:00</iodef:DateTime>
        <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
          CSIRT-FOR-OUR-DOMAIN#208-1
        </iodef:IncidentID>
        <iodef:Description>
          Investigation request sent to NP for 192.0.2.35
        </iodef:Description>
      </iodef:HistoryItem>
    </iodef:History>
  </iodef:Incident>
</iodef:IODEF-Document>

4.5.2.2.  RequestAuthorization Message Example

   The example RequestAuthorization message is in response to the
   Investigation request listed above.  The NP 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.0"
               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>














Moriarty                      Informational                    [Page 50]
^L
RFC 6045                           RID                     November 2010


4.5.3.  Report Communication

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

        NP-1                           NP-2

     1. Generate incident information
        and prepare Report message

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

     3.                              File report in database

                   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.

4.5.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 would be similar to the
   TraceRequest information.















Moriarty                      Informational                    [Page 51]
^L
RFC 6045                           RID                     November 2010


<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
               xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
  <iodef-rid:RIDPolicy MsgType="Report" MsgDestination="RIDSystem">
    <iodef-rid:PolicyRegion region="PeerToPeer"/>
    <iodef:Node>
      <iodef:Address category="ipv4-addr">192.0.2.130</iodef:Address>
    </iodef:Node>
    <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>
    <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>






Moriarty                      Informational                    [Page 52]
^L
RFC 6045                           RID                     November 2010


          <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 NP for 192.0.2.35
        </iodef:Description>
      </iodef:HistoryItem>
    </iodef:History>
  </iodef:Incident>
</iodef:IODEF-Document>























Moriarty                      Informational                    [Page 53]
^L
RFC 6045                           RID                     November 2010


4.5.4.  IncidentQuery Communication Flow

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

        NP-1                           NP-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.

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








Moriarty                      Informational                    [Page 54]
^L
RFC 6045                           RID                     November 2010


   IP packet data will not be included in the IODEF RecordItem class;
   the other incident information is the main source for comparison.  In
   the case in which an incident number may not be the same between
   CSIRTs, the incident number and/or IP packet information can be
   provided and used for comparison on the receiving RID system to
   generate (a) Report message(s).

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

5.  RID Schema Definition

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
 xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
 targetNamespace="urn:ietf:params:xml:ns:iodef-rid-1.0"
 elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
 schemaLocation="http://www.iana.org/assignments/xml-registry/
 schema/iodef-rid-1.0.xsd"/>

<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
 schemaLocation=
 "http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>

<!-- ****************************************************************
*********************************************************************
***  Real-time Inter-network Defense - RID XML Schema             ***
***    Namespace - iodef-rid, August 2006                         ***
***    The namespace is defined to support transport of IODEF     ***
***     documents for exchanging incident information.            ***
*********************************************************************
-->




Moriarty                      Informational                    [Page 55]
^L
RFC 6045                           RID                     November 2010


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

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















Moriarty                      Informational                    [Page 56]
^L
RFC 6045                           RID                     November 2010


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

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











Moriarty                      Informational                    [Page 57]
^L
RFC 6045                           RID                     November 2010


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












Moriarty                      Informational                    [Page 58]
^L
RFC 6045                           RID                     November 2010


  <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="ClientToNP"/>
         <xs:enumeration value="NPToClient"/>
         <xs:enumeration value="IntraConsortium"/>
         <xs:enumeration value="PeerToPeer"/>
         <xs:enumeration value="BetweenConsortiums"/>
         <xs:enumeration value="AcrossNationalBoundaries"/>
         <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" default="Attack">
    <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>
      </xs:simpleType>
     </xs:attribute>
     <xs:attribute name="ext-type"
                   type="xs:string" use="optional"/>
    </xs:complexType>
  </xs:element>
</xs:schema>











Moriarty                      Informational                    [Page 59]
^L
RFC 6045                           RID                     November 2010


6.  Security Considerations

   Communication between NPs' RID systems must be protected.  RID has
   many security considerations built into the design of the protocol,
   several of which are described in the following sub-sections.  For a
   complete view of security, considerations need to include the
   availability, confidentiality, and integrity concerns for the
   transport, storage, and exchange of information.

   When considering the transport of RID messages, an out-of-band
   network, either logical or physical, would prevent outside attacks
   against RID communication.  An out-of-band connection would be ideal,
   but not necessarily practical.  Authenticated encrypted tunnels
   between RID systems MUST be used to provide confidentiality,
   integrity, authenticity, and privacy for the data.  Trust
   relationships are based on consortiums and established trust
   relationships of public key infrastructure (PKI) cross-certifications
   of consortiums.  By using RIDPolicy information, TLS, and the XML
   security features of encryption [XMLencrypt] and digital signatures
   [RFC3275], [XMLsig], RID takes advantage of existing security
   standards.  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 IP
      packets included in the RecordItem class data to provide
      authentication to all upstream participants in the trace of the
      origin.  All IP packets provided by the originator may be signed,
      and additional packets added by upstream peers in the trace may be
      signed by the peer adding the data, while maintaining the IP
      packet and detached signature from the original requestor.  This
      signature MUST be passed to all recipients of the TraceRequest.

   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.








Moriarty                      Informational                    [Page 60]
^L
RFC 6045                           RID                     November 2010


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

   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, using 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.

   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.

   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.



Moriarty                      Informational                    [Page 61]
^L
RFC 6045                           RID                     November 2010


   RID provides a method to exchange incident handling request and
   Report messages to peer networks.  Network administrators, who have
   the ability to base the decision on the available resources and other
   factors of their network, 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.

6.1.  Message Transport

   The transport specifications are fully defined in a separate document
   [RFC6046].  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 at the beginning of
   Section 6 of this document.

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

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







Moriarty                      Informational                    [Page 62]
^L
RFC 6045                           RID                     November 2010


6.2.  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 considerations must include the integrity, authentication,
   privacy, and authorization of the messages sent between RID
   communication systems or IHSs.  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 6.4.  Several methods can be used to ensure
   integrity and privacy of the communication.

   The transport mechanism selected MUST follow the defined transport
   protocol [RFC6046] 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] and optionally support other
   protocols such as the Blocks Extensible Exchange Protocol (BEEP).
   RID, the XML security functions, and transport protocols must
   properly integrate with a public key infrastructure (PKI) managed by
   the consortium or one managed by a trusted entity.  For the Internet,
   an example of an existing effort that could be leveraged to provide
   the supporting PKI could be the American Registry for Internet
   Numbers (ARIN) and the Regional Internet Registry's (RIR's) PKI
   hierarchy.  Security and privacy considerations related to
   consortiums are discussed in Sections 6.5 and 6.6.

6.3.  Transport Communication

   Out-of-band communications dedicated to NP 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 possible between all
   network providers, but should be considered to protect the network
   management systems used for RID messaging.  Methods to protect the
   data transport may also be provided through session encryption.





Moriarty                      Informational                    [Page 63]
^L
RFC 6045                           RID                     November 2010


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

6.4.  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
   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 would also
   provide the necessary certificates needed for encryption used for the
   RID transport protocol [RFC6046].

   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



Moriarty                      Informational                    [Page 64]
^L
RFC 6045                           RID                     November 2010


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

   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.

6.4.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.  For practical
   reasons, the NPs may want to prioritize incident handling events
   based upon the immediate peer for a TraceRequest, the originator, 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.  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 IP packet in the RecordItem data MUST remain



Moriarty                      Informational                    [Page 65]
^L
RFC 6045                           RID                     November 2010


   unchanged as a request is passed along between providers and is the
   only element for which the signature is applied.  If additional
   packets are included in the document at upstream peers, the initial
   packet MUST still remain with the detached signature.  The subsequent
   packets 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
   NPs in the upstream trace of the packet.  The trusted PKI also
   provides the keys used to digitally sign the RecordItem class for
   TraceRequests 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 NP may generate
   a new request to send upstream to members of the NP consortium to
   continue the trace.  If the original request is sent, the originating
   NP, 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 NP 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.  NPs participating in the trace MUST be able to determine
   the authenticity of RID requests.

6.5.  Consortiums and Public Key Infrastructures

   Consortiums of NPs are an ideal way to establish a communication web
   of trust for RID messaging.  The consortium could provide centralized
   resources, such as a PKI, and established guidelines for use of the
   RID protocol.  The consortium would also assist in establishing trust
   relationships between the participating NPs 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 NPs 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 NPs
   of consortiums that would peer with NPs belonging to a separate
   consortium.  In other words, consortiums could peer with other
   consortiums to enable communication of RID messages between the





Moriarty                      Informational                    [Page 66]
^L
RFC 6045                           RID                     November 2010


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

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

   A PKI can also provide the same level of security for communication
   between an end entity (enterprise, educational, or government
   customer network) and the NP.  The PKI may be a subordinate CA or in
   the CA hierarchy from the NP's consortium to establish the trust
   relationships necessary as the request is made to other connected
   networks.

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






Moriarty                      Informational                    [Page 67]
^L
RFC 6045                           RID                     November 2010


   Customer Attached Networks Participating in RID with NP:

   o  Customer networks may include an enterprise, educational,
      government, or other attached networks to an NP 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 NP and the consortium of which the NP is a member.

   o  Customers MUST understand that their data can and will be sent to
      other NPs in order to complete a trace unless an agreement stating
      otherwise is made in the service level agreements between the
      customer and NP.

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

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



Moriarty                      Informational                    [Page 68]
^L
RFC 6045                           RID                     November 2010


   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, NPs, 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 at the beginning of
   Section 6.

   RID is useful in determining the true source of a packet that
   traverses multiple networks or to communicate security incidents and
   automate the response.  The information obtained from the trace 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 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-NP level and are out of
   scope for RID messaging.

   The identity of the true source of an attack packet 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 NP.  Alternatively, the
   action taken may be listed without the identity being revealed to the
   originating NP.  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 NP 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



Moriarty                      Informational                    [Page 69]
^L
RFC 6045                           RID                     November 2010


   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
   would become aware that the cyber attack occurred.  In a targeted
   attack, it may not be desirable that information about two nation
   states that are battling a cyber war would become general knowledge
   to all intermediate parties.  However, it is important to allow the
   traces to take place in order to halt the activity since the health
   of the networks in the path could also be at stake during the attack.
   This provides a second argument for allowing the Result message to
   only include an action taken and not the identity of the offending
   host.  In the case of an Investigation request, where the originating
   NP is aware of the NP 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 NP to ensure
   that no other NP in the path can read the contents.  The encryption
   would be 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 NP 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 request to request
   action close to the source of valid attack traffic needs to be
   considered.  Although the intermediate NPs may relay the request if



Moriarty                      Informational                    [Page 70]
^L
RFC 6045                           RID                     November 2010


   there is no direct trust relationship to the closest NP to the
   source, the intermediate NPs 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 NP
   in the path.  Therefore, the contents of the request may be encrypted
   for the destination system.  The intermediate NPs would only need to
   know how to direct the request to the manager of the ASN in which the
   source IP address belongs.

   Traces must be legitimate security-related incidents and not used for
   purposes such as sabotage or censorship.  An example of such abuse of
   the system would include 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 and requested actions to mitigate traffic
   must adhere to the appropriate use guidelines and yet prevent abuse
   of the system.  First, the peering consortiums MUST identify the
   types of traffic that can be traced between the borders of the
   participating NPs 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 NP, 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



Moriarty                      Informational                    [Page 71]
^L
RFC 6045                           RID                     November 2010


   document is decrypted and re-encrypted at each RID system via TLS
   over the transport protocol [RFC6046].  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.

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

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

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

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

8.  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.  NPs
   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 NP resources
   for each aspect of attack detection, tracing, and source



Moriarty                      Informational                    [Page 72]
^L
RFC 6045                           RID                     November 2010


   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 NP 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 NPs, which is essential for incident handling.

9.  References

9.1.  Normative References

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3275]      Eastlake 3rd, 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., Ed., and H. Tschofenig, Ed., "Pre-Shared
                  Key Ciphersuites for Transport Layer Security (TLS)",
                  RFC 4279, December 2005.

   [RFC5070]      Danyliw, R., Meijer, J., and Y. Demchenko, "The
                  Incident Object Description Exchange Format", RFC
                  5070, December 2007.

   [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]      Moriarty, K. and B. Trammell, "Transport of Real-Time
                  Inter-Network Defense (RID) Messages," RFC 6046,
                  November 2010.





Moriarty                      Informational                    [Page 73]
^L
RFC 6045                           RID                     November 2010


   [XML1.0]       "Extensible Markup Language (XML) 1.0 (Second
                  Edition)".  W3C Recommendation.  T. Bray, E. Maler, J.
                  Paoli, and C.M. Sperberg-McQueen.  October 2000.
                  http://www.w3.org/TR/2000/REC-xml-20001006.

   [XMLnames]     "Namespaces in XML 1.0 (Third Edition)".  W3C
                  Recommendation.  T. Bray, D. Hollander, A. Layman, R.
                  Tobin, H. Thompson.  December 2009.
                  http://www.w3.org/TR/REC-xml-names/.

   [XMLencrypt]   "XML Encryption Syntax and Processing".  W3C
                  Recommendation.  T. Imamura, B. Dillaway, and E.
                  Simon.  December 2002.
                  http://www.w3.org/TR/xmlenc-core/.

   [XMLschema]    "XML Schema".  E. Van der Vlist.  O'Reilly.  2002.

   [XMLsig]       "XML-Signature Syntax and Processing (Second
                  Edition)".  W3C Recommendation.  M. Bartel, J. Boyer,
                  B. Fox, B. LaMacchia, and E. Simon.  June 2008.
                  http://www.w3.org/TR/xmldsig-core/#sec-Design.

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

   [RFC2827]      Ferguson, P. and D. Senie, "Network Ingress Filtering:
                  Defeating Denial of Service Attacks which employ IP
                  Source Address Spoofing", BCP 38, RFC 2827, May 2000.

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

   [RFC3917]      Quittek, J., Zseby, T., Claise, B., and S. Zander,
                  "Requirements for IP Flow Information Export (IPFIX)",
                  RFC 3917, October 2004.

   [RFC5735]      Cotton, M. and L. Vegoda, "Special Use IPv4
                  Addresses", BCP 153, RFC 5735, January 2010.

   [IPtrace]      "Advanced and Authenticated Marking Schemes for IP
                  Traceback".  D. Song and A. Perrig.  IEEE INFOCOM
                  2001.




Moriarty                      Informational                    [Page 74]
^L
RFC 6045                           RID                     November 2010


   [HASH-IPtrace] "Hash-Based IP Traceback".  A. Snoeren, C. Partridge,
                  L. Sanchez, C. Jones, F. Tchakountio, S. Kent, and W.
                  Strayer.  SIGCOMM'01.  August 2001.

   [ICMPtrace]    Bellovin, S., Leech, M., and T. Taylor, "ICMP
                  Traceback Messages", Work in Progress, February 2003.

   [NTWK-IPtrace] "Practical network support for IP traceback".  S.
                  Savage, D. Wetherall, A. Karlin, and T. Anderson.
                  SIGCOMM'00.  August 2000.

   [DoS]          "Trends in Denial of Service Attack Technology".  K.
                  Houle, G. Weaver, N. Long, and R. Thomas.  CERT
                  Coordination Center.  October 2001.

Acknowledgements

   Many thanks to coworkers 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, and
   Sandra G. Dykes, Ph.D.

Sponsor Information

   This work was sponsored by the Air Force under Air Force Contract
   FA8721-05-C-0002, while working at MIT Lincoln Laboratory.

   "Opinions, interpretations, conclusions, and recommendations are
   those of the author and are not necessarily endorsed by the United
   States Government".

Author's Address

   Kathleen M. Moriarty
   RSA, The Security Division of EMC
   174 Middlesex Turnpike
   Bedford, MA  01730
   US

   EMail: Moriarty_Kathleen@EMC.com








Moriarty                      Informational                    [Page 75]
^L