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

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

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.

   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>

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

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

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

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

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

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

      <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

   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>

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

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

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.

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

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

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

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

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

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

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

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