7.  RID Communication Exchanges

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

   The possible set of message exchanges include:

   o  Request: Asynchronous Request for assistance and/or action to be
      taken, MAY involve multiple systems and iterative Requests

         MsgType set to 'InvestigationRequest' or 'TraceRequest'

         Possible responses:

         +  Acknowledgement (OPTIONAL for InvestigationRequest)

         +  Result (REQUIRED unless Acknowledgement was set to 'no')

         +  Report (OPTIONAL; zero or more; Report can be sent
            unsolicited)

   o  Query: Synchronous request for information

         MsgType set to 'Query'

         Possible responses:

         +  Acknowledgement (OPTIONAL if yes; REQUIRED if no Report will
            be sent)

         +  Report (REQUIRED unless Acknowledgement was set to 'no')

   o  Report: Asynchronous information report; may be pushed to systems
      or may be a response to a Query

         MsgType set to 'Report'

         Possible responses:

         +  Acknowledgement (OPTIONAL)

   Processing considerations for the IODEF document and any IODEF
   included elements or attributes MUST follow the guidelines specified
   in [RFC5070], Section 4.  [RFC3023] and [RFC3470] specify
   requirements and best practices for the use of XML in IETF
   application protocols.  RID and IODEF documents MUST be well-formed
   (see [RFC3470], Section 4.1) and MUST be validated against the
   appropriate schema.  Internal or external DTD subsets are prohibited
   in RID; see [RFC3023], Section 3.

   Comments can be ignored by conform ant processors for RID or IODEF
   documents (see [RFC3470], Section 4.6) and are included below for
   informational purposes only.  The first example demonstrates the use
   of a detached digital signature.  Subsequent examples do not include
   the detached signature required for some message types.  The
   signature is applied after the message is created as demonstrated in
   the first example.

   Note: For each example listed below, [RFC5735] addresses were used.
   Assume that each IP address listed is actually a separate network
   range held by different SPs.  Addresses were used from /27 network
   ranges.

7.1.  Upstream Trace Communication Flow

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

   'TraceRequest' is represented in the diagram by "TraceRequest".
   SP-1, SP-2, and SP-3 represent service providers that are involved in
   the example trace communication flow.

    Attack Dest      SP-1            SP-2        SP-3        Attack Src

    1. Attack    |  Attack
       reported  |  detected

    2.              Initiate trace

    3.              Locate origin
                    through
                    upstream SP

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

    5.                              Trace
                                    Initiated

    6.              <---Acknowledgement--o

    7.                              Locate origin
                                    through
                                    upstream SP

    8.                              o---TraceRequest--->

    9.                                             Trace Initiated

    10.             <----------Acknowledgement----o
                                     <-Acknowledgement-o

    11.                                            Locate attack
                                                   source on network   X

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

    13.             o- - - - -Acknowledgement- - - - - >


                 Figure 8: TraceRequest Communication Flow

   Before a trace is initiated, the RID system should verify that an
   instance of the trace or a similar request is not active.  The traces
   may be resource intensive; therefore, providers need to be able to
   detect potential abuse of the system or unintentional resource

   drains.  Information such as the Source and Destination Information,
   associated packets, and the incident may be desirable to maintain for
   a period of time determined by administrators.

   The communication flow demonstrates that an Acknowledgement message
   is sent to both the downstream peer and the original requestor.  If a
   Request in a traceback is denied, the downstream peer has the option
   to take an action and respond with a Result message.  The originator
   of the request may follow up with the downstream peer of the SP
   involved using a Request with the MsgType set to
   'InvestigationRequest' to ensure that an action is taken if no
   response is received.  Nothing precludes the originator of the
   request from initiating a new Request with the MsgType set to
   'TraceRequest' thereby bypassing the SP that denied the request, if a
   trace is needed beyond that point.  Another option may be for the
   initiator to send an 'InvestigationRequest' to an SP upstream of the
   SP that denied the request.  This action assumes enough information
   was gathered to discern the true source of the attack traffic from
   the incident-handling information.

   The proper response to a TraceRequest is an Acknowledgement message.
   The Acknowledgement message lets the requestor know if the trace will
   continue through the next upstream network.  If there is a problem
   with the request, such as a failure to validate the digital signature
   or decrypt the request, an Acknowledgement message MUST be sent to
   the requestor and the downstream peer (if they are not one and the
   same) providing the reason why the message could not be processed.
   Assuming that the trace continued, additional TraceRequests with the
   response of an Acknowledgement message would occur, thereby passing
   the request upstream in the path to the source of the traffic related
   to the incident.  Once a source is found, a Result message is sent to
   the originator of the trace, as determined by the SP path information
   provided through the document instance of EventData, where contact is
   set to 'infrastructure'.  The SP path information is also used when
   sending the Acknowledgement messages to the first entry (the trace
   originator) and the last nested entry (the downstream peer).  The
   Result message is encrypted [XMLencrypt] for the originator providing
   information about the incident source and any actions taken.  If the
   originator fails to decrypt or authenticate the Result message, an
   Acknowledgement message is sent in response; otherwise, no return
   message is sent.  The final Acknowledgement to the Result message is
   depicted as optional in the diagram above.  If an Acknowledgement
   message is sent with the RequestStatus set to Denied, a downstream
   peer receiving this message may choose to take action to stop or
   mitigate the traffic at that point in the network, as close to the
   source as possible.  If the downstream peer chooses this option, it
   would send a Result message to the trace originator.

7.1.1.  RID TraceRequest Example

   The example listed is of a Request message with MsgDestination set to
   'TraceRequest' based on the incident report example from the IODEF
   document.  The RID classes were included as appropriate for a Request
   message of this type using the RIDPolicy class.  The example given is
   that of a CSIRT reporting a DoS attack in progress to the upstream
   SP.  The request asks the next SP to continue the trace and have the
   traffic mitigated closer to the source of the traffic.  The example
   Request message is the first step of a TraceRequest as depicted in
   the previous diagram, where 'Attack Dest' is represented by
   192.0.2.67 (and SP-1).  The 'Attack Src' is later identified in the
   Result message example as 192.0.2.37 and initially as tracing closer
   to 192.0.2.35.  SP-1 is identified in the Request as CSIRT-FOR-OUR-
   DOMAIN, and SP-2 is identified in the RID document for the Request as
   the 'RIDSystem' in 'MsgDestination' as 192.0.2.3 using the Node
   class.  SP-3 is later used in the Result message and the
   administrator is identified as 'Admin-contact@10.1.1.2' as they
   searched for 192.0.2.35; the administrator may be different than the
   constituency contact (an additional Request with MsgDestination set
   to 'TraceRequest' occurred between SP-2 to SP-3 that is not
   included).  SP-3 is the service provider for 192.0.2.32/27 and was
   able to take the action to rate-limit their traffic.  The SP-1, SP-2,
   and SP-3 information would be replaced with the appropriate (and
   valid) email and other contact information in real usages.  The Node
   class enables multiple methods to identify a system, such as a fully
   qualified domain name or the IP address to be provided for the SP.
   Any mapping of existing relationships from the SP Node information to
   the name, contact, digital signature verification information and
   other identifying or trust information is provided at the application
   layer to support end users of the incident management system.  A
   packet is provided in this example to enable any traces to be
   performed by SP-2 and SP-3 to perform traces to the attack source
   before taking the requested action to 'rate-limit' the traffic.  The
   subnet of 192.0.2.0 uses a 27-bit mask in the examples below.

   In the following example, use of [XMLsig] to generate digital
   signatures follows the guidance of [XMLsig] 1.0.  Version 1.1 of
   [XMLsig] supports additional digest algorithms.  Reference [RFC4051]
   for URIs intended for use with XML digital signatures, encryption,
   and canonicalization.  SHA-1 SHOULD NOT be used; see [RFC6194] for
   further details.

   Note: Due to the limit of 72 characters per line, some line breaks
   were added in the examples and schemas in this document.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<iodef-rid:RID lang="en-US"
 xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
 xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0">
 <iodef-rid:RIDPolicy MsgDestination="RIDSystem" MsgType="TraceRequest">
   <iodef-rid:PolicyRegion region="IntraConsortium"/>
     <iodef:Node>
      <iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
     </iodef:Node>
     <iodef-rid:TrafficType type="Attack"/>
     <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
            CERT-FOR-OUR-DOMAIN#207-1
     </iodef:IncidentID>
     <!-- IODEF-Document included in RID -->
     <iodef-rid:ReportSchema Version="1.0">
      <iodef-rid:XMLDocument dtype="xml" meaning="xml">
       <IODEF-Document lang="en">
        <iodef:Incident purpose="traceback" restriction="need-to-know">
          <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
                           CERT-FOR-OUR-DOMAIN#207-1
          </iodef:IncidentID>
          <iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
          <iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
          <iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
          <iodef:Description>
                           Host involved in DoS attack
          </iodef:Description>
          <iodef:Assessment>
            <iodef:Impact completion="failed" severity="low"
                          type="dos"/>
          </iodef:Assessment>
          <iodef:Contact role="creator" type="organization">
            <iodef:ContactName>Constituency-contact for 192.0.2.35
            </iodef:ContactName>
            <iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
          </iodef:Contact>
          <iodef:EventData>
            <iodef:Flow>
              <iodef:System category="source">
                <iodef:Node>
                  <iodef:Address category="ipv4-addr">192.0.2.35
                  </iodef:Address>
                </iodef:Node>
                <iodef:Service ip_protocol="6">
                  <iodef:Port>38765</iodef:Port>
                </iodef:Service>

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

       <iodef-rid:Signature dtype="xml" meaning="xml">
        <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
                   Id="dsig-123456">
        <SignedInfo>
<CanonicalizationMethod
  Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod
  Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
    <Reference URI="">
    <Transforms>
     <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
     <Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
     <XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2"
       xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
       xmlns:dsig-trans="http://www.w3.org/2002/06/xmldsig-filter2"
       Filter="intersect">
       //dsig:Signature[@Id = 'dsig-123456']/
       ancestor::iodef-rid:ReportSchema/
       iodef-rid:XMLDocument/IODEF-Document[1]/iodef:Incident[1]/
       iodef:EventData[1]/iodef:Record[1]/iodef:RecordData[1]/
       iodef:RecordItem[1]</XPath></Transform></Transforms>
    <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
    <DigestValue>
       NQuIhPjdZuZJnPi/hW62dwJT1dR+vqcZV8mpemCVN5g=
    </DigestValue>
   </Reference></SignedInfo>
   <SignatureValue>
lnq/ePQ4AVpxCR0ifCp9sMsW0r/AdT3C2GR/zaN1V+hZ/NApOygUjMzTCQnx+RvGPNkO/RVq
BEIDgZQUEnQZn/uSbmr0tQ6xpBfaxF1DCosLgiZy+2jFzpXrwoN/jHNgtxR/9QLW9mZ+I7V6
LEEJ73Kut+d0naTGHlyi64ab2PqsVuRXQ4pXUKbhMkhzeTIqvFLK93KGfsIMd6Cb+n2u/ABy
Lkc+gflJYUWVP4DxkQ4cyex6hM6RYTRUSr7jVD9K4d8KFP2g85i69YLtSu01W1Np0afpJ4a9
MK0E7ISMNRmC8wIklCAsSXiBRqyaEwaSy/clybI0vCTPqGOYh3/SZg==
   </SignatureValue>
   <KeyInfo>
    <KeyValue>
      <RSAKeyValue>
       <Modulus>
z8adrX9m0S8OxIxN+fui33wiz4ZYgb4xPbR9MS5pOp1A8kVpH5Ew3N6O3/dMs2a4diIxyGLV
h0r86QXWH/W6T2IC2ny+hi+jWRwXrvgTY3ZAFgePvz2OdRhVN/cUbOto4Pa4I2mVZWW+/Q0F
n7YpqPBDDxlGq/xyFPuYq/4y7Y+Ah+vHO2ZSaiQjbj8F38XrGhwlcbFVyK8AmxK3z0zWwX86
uMEqVCjW6s6j2KAWdbAjEpgZHlJY87i/DqnFgxfmdg3oru+YeiEPVRY8hyQpYbtgryveZOHT
gnCHmS/53U9jSS0cyb/ADuj1upfyNoOiMMgQr7Olhc5pTvuWAl4Fnw==</Modulus>
       <Exponent>AQAB</Exponent>
      </RSAKeyValue>
      </KeyValue>
    </KeyInfo>
   </Signature>
  </iodef-rid:Signature>

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

7.1.2.  Acknowledgement Message Example

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

   <iodef-rid:RID lang="en"
                  xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
                  xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
     <iodef-rid:RIDPolicy MsgType="Acknowledgement"
                          MsgDestination="RIDSystem">
       <iodef-rid:PolicyRegion region="IntraConsortium"/>
       <iodef:Node>
         <iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
       </iodef:Node>
       <iodef-rid:TrafficType type="Attack"/>
       <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
         CERT-FOR-OUR-DOMAIN#207-1
       </iodef:IncidentID>
     </iodef-rid:RIDPolicy>
     <iodef-rid:RequestStatus AuthorizationStatus="Approved"/>
   </iodef-rid:RID>

7.1.3.  Result Message Example

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

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

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

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

      <iodef:History>
        <iodef:HistoryItem action="rate-limit-host">
          <iodef:DateTime>2004-02-02T22:53:01+00:00</iodef:DateTime>
          <iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
            CSIRT-FOR-OUR-DOMAIN#207-1
          </iodef:IncidentID>
          <iodef:Description>
            Notification sent to next upstream SP closer to 192.0.2.35
          </iodef:Description>
        </iodef:HistoryItem>
        <iodef:HistoryItem action="rate-limit-host">
          <iodef:DateTime>2004-02-02T23:07:21+00:00</iodef:DateTime>
          <iodef:IncidentID name="CSIRT-FOR-SP3">
            CSIRT-FOR-SP3#3291-1
          </iodef:IncidentID>
          <iodef:Description>
            Host rate-limited for 24 hours
            </iodef:Description>
          </iodef:HistoryItem>
        </iodef:History>
      </iodef:Incident>
      </iodef:IODEF-Document>
     </iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
   </iodef-rid:ReportSchema>
  </iodef-rid:RIDPolicy>
  <iodef-rid:IncidentSource>
    <iodef-rid:SourceFound>true</iodef-rid:SourceFound>
    <iodef:Node>
      <iodef:Address category="ipv4-addr">192.0.2.37</iodef:Address>
    </iodef:Node>
  </iodef-rid:IncidentSource>
</iodef-rid:RID>

7.2.  Investigation Request Communication Flow

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

       Attack Dest      SP-1              SP-2        Attack Src

       1. Attack    |  Attack
          reported  |  detected

       2.              Determine source
                       of security incident

       3.              o---Investigation---->

       4.                              Research
                                       incident and
                                       determine appropriate
                                       actions to take

       5.              <-------Result-------o

            Figure 9: Investigation Request Communication Flow

7.2.1.  Investigation Request Example

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

   This flow does not include a Result message because the request is
   denied as shown in the Acknowledgement response.

   SP-1 is represented by CERT-FOR-OUR-DOMAIN and 192.0.2.67.  SP-2 is
   identified by 192,0.2.98.  In this example, SP-2 is the service
   provider for systems on the 192.0.2.32/27 subnet.  The contact for
   the host 192.0.2.35 is known at the start of the request as
   'Constituency-contact@10.1.1.2'.

  <iodef-rid:RID lang="en"
                 xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
                 xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
    <iodef-rid:RIDPolicy MsgType="InvestigationRequest"
                         MsgDestination="SourceOfIncident">
      <iodef-rid:PolicyRegion region="PeerToPeer"/>
      <iodef:Node>
        <iodef:Address category="ipv4-addr">192.0.2.98</iodef:Address>
      </iodef:Node>
      <iodef-rid:TrafficType type="Attack"/>

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

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

7.2.2.  Acknowledgement Message Example

   The example Acknowledgement message is in response to the Request
   listed above.  The SP that received the request was unable to
   validate the digital signature used to authenticate the sending RID
   system.

   <iodef-rid:RID lang="en"
                  xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
                  xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
     <iodef-rid:RIDPolicy MsgType="Acknowledgement"
                          MsgDestination="RIDSystem">
       <iodef-rid:PolicyRegion region="IntraConsortium"/>
       <iodef:Node>
         <iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
       </iodef:Node>
       <iodef-rid:TrafficType type="Attack"/>
       <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
         CERT-FOR-OUR-DOMAIN#208-1
       </iodef:IncidentID>
     </iodef-rid:RIDPolicy>
     <iodef-rid:RequestStatus AuthorizationStatus="Denied"
                              Justification="Authentication"/>
   </iodef-rid:RID>

7.3.  Report Communication Flow

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

           SP-1                           SP-2

        1. Generate incident information
           and prepare Report message

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

        3.                          File report in database

                   Figure 10: Report Communication Flow

   The Report communication flow is used to provide information on
   incidents.  Incident information may be shared between CSIRTs or
   other entities using this format.  When a report is received, the RID
   system must verify that the report has not already been filed.  The
   incident number and incident data, such as the hexadecimal packet and
   incident class information, can be used to compare with existing
   database entries.  The Report message typically does not have a
   response.  If there is a problem with the Report message, such as a
   failure to validate the digital signature [RFC3275] or decrypt the
   request, an Acknowledgement message is sent to the requestor.  The
   Acknowledgement message should provide the reason why the message
   could not be processed.

7.3.1.  Report Example

   The following example only includes the RID-specific details.  This
   report is an unsolicited Report message that includes an IPv4 packet.
   The IODEF document and digital signature is similar to the Request
   example with MsgDestination set to 'TraceRequest'.

   This example is a message sent from SP-1, CERT-FOR-OUR-DOMAIN at
   192.0.2.67, to SP-2 at 192.0.2.130 for informational purposes on an
   attack that took place.

   <iodef-rid:RID lang="en"
                  xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
                  xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
     <iodef-rid:RIDPolicy MsgType="Report" MsgDestination="RIDSystem">
       <iodef-rid:PolicyRegion region="PeerToPeer"/>
       <iodef:Node>
         <iodef:Address category="ipv4-addr">192.0.2.130</iodef:Address>
       </iodef:Node>

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

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

7.4.  Query Communication Flow

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

           SP-1                           SP-2

        1. Generate a request for
           information on a specific
           incident number or incident type

        2.              o-------Query------->

        3.                              Verify policy information
                                        and determine if matches exist
                                        for requested information

        4.              <-------Report------o

        5.  Associate report to request
            by incident number or type
            and file report(s).

                    Figure 11: Query Communication Flow

   The Query message communication receives a response of a Report
   message.  If the Report message is empty, the responding host did not

   have information available to share with the requestor.  The incident
   number and responding RID system, as well as the transport, assist in
   the association of the request and response since a report can be
   filed and is not always solicited.  If there is a problem with the
   Query message, such as a failure to validate the digital signature or
   decrypt the request, an Acknowledgement message is sent to the
   requestor.  The Acknowledgement message should provide the reason why
   the message could not be processed.

7.4.1.  Query Example

   The Query request may be received in several formats as a result of
   the type of query being performed.  If the incident number is the
   only information provided, the IODEF document and IP packet data may
   not be needed to complete the request.  However, if a type of
   incident is requested, the incident number remains NULL, and the IP
   packet data will not be included in the IODEF RecordItem class; the
   other incident information is the main source for comparison.  In the
   case in which an incident number may not be the same between CSIRTs,
   the incident number and/or IP packet information can be provided and
   used for comparison on the receiving RID system to generate (a)
   Report message(s).

   This query is sent to 192.0.2.3, inquiring about the incident with
   the identifier CERT-FOR-OUR-DOMAIN#210-1.  The Report will be
   provided to the requestor identified and verified through the
   authentication and digital signature information provided in the RID
   message.  An example Report is provided above.

   <iodef-rid:RID lang="en"
                  xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
                  xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
     <iodef-rid:RIDPolicy MsgType="Query"
                          MsgDestination="RIDSystem">
       <iodef-rid:PolicyRegion region="PeerToPeer"/>
       <iodef:Node>
         <iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
       </iodef:Node>
       <iodef-rid:TrafficType type="Attack"/>
       <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
         CERT-FOR-OUR-DOMAIN#210-1
       </iodef:IncidentID>
     </iodef-rid:RIDPolicy>
   </iodef-rid:RID>

8.  RID Schema Definition

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

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

  -->

 <xs:annotation>
   <xs:documentation>XML Schema wrapper for IODEF</xs:documentation>
 </xs:annotation>
 <xs:element name="RID" type="iodef-rid:RIDType"/>
   <xs:complexType name="RIDType">
     <xs:sequence>
       <xs:element ref="iodef-rid:RIDPolicy" minOccurs="0"/>
       <xs:element ref="iodef-rid:RequestStatus" minOccurs="0"/>
       <xs:element ref="iodef-rid:IncidentSource" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="lang"
                    type="xs:language" use="required"/>
   </xs:complexType>

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

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

 <!--Incident Source Information for Result Message-->

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

 <!--
 ====== Real-Time Inter-network Defense Policy - RIDPolicy ======
 ======  Definition for RIDPolicy for messaging
  -->

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

 <!-- RIDPolicy information with setting information listed in RID
      documentation -->

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

                 use="optional"/>
   <xs:attribute name="restriction" type="iodef:restriction-type"/>
    </xs:complexType>
   <xs:element name="PolicyRegion">
     <xs:complexType>
      <xs:attribute name="region" use="required">
       <xs:simpleType>
        <xs:restriction base="xs:NMTOKEN">
        <xs:whiteSpace value="collapse"/>
          <xs:enumeration value="ClientToSP"/>
          <xs:enumeration value="SPToClient"/>
          <xs:enumeration value="IntraConsortium"/>
          <xs:enumeration value="PeerToPeer"/>
          <xs:enumeration value="BetweenConsortiums"/>
          <xs:enumeration value="ext-value"/>
        </xs:restriction>
       </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="ext-region"
                    type="xs:string" use="optional"/>
     </xs:complexType>
   </xs:element>
   <xs:element name="TrafficType">
     <xs:complexType>
      <xs:attribute name="type" use="required">
       <xs:simpleType>
        <xs:restriction base="xs:NMTOKEN">
        <xs:whiteSpace value="collapse"/>
          <xs:enumeration value="Attack"/>
          <xs:enumeration value="Network"/>
          <xs:enumeration value="Content"/>
          <xs:enumeration value="DataWithHandlingRequirements"/>
          <xs:enumeration value="AudienceRestriction"/>
          <xs:enumeration value="Other"/>
          <xs:enumeration value="ext-value"/>
        </xs:restriction>
       </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="ext-type"
                    type="xs:string" use="optional"/>
     </xs:complexType>
   </xs:element>
 <!--Used to include an enveloped XML document in RID-->
 <xs:element name="ReportSchema" type="iodef-rid:ReportSchemaType"/>
   <xs:complexType name="ReportSchemaType">
     <xs:sequence>
       <xs:element ref="iodef-rid:XMLDocument" minOccurs="1"
                   maxOccurs="1"/>

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