Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6545

Real-time Inter-network Defense (RID)

Pages: 84
Proposed Standard
Errata
Obsoletes:  6045
Part 2 of 4 – Pages 15 to 39
First   Prev   Next

Top   ToC   RFC6545 - Page 15   prevText

5. IODEF-RID Schema

There are three classes included in the RID extension required to facilitate RID communications. The RequestStatus class is used to indicate the approval status of a Request message; the IncidentSource class is used to report whether or not a source was found and to identify the source host(s) or network(s); and the RIDPolicy class provides information on the agreed-upon policies and specifies the type of communication message being used. The RID schema defines communication-specific metadata to support the exchange of incident information in an IODEF document. The intent in maintaining a separate schema and not using the AdditionalData extension of IODEF is the flexibility of sending messages between RID hosts. Since RID is a separate schema and RID messages include both the RID and IODEF documents, the RID message acts as an envelope in that policy and security defined at the RID message layer are applied to both documents. One reason for maintaining separate schemas is for flexibility, where the RIDPolicy class can be easily extracted for use in the RID message and by the transport protocol. The security requirements of sending incident information between entities include the use of encryption. The RIDPolicy information is not required to be encrypted, so separating out this data from the IODEF XML document removes the need for decrypting and parsing the IODEF document to determine how it should be handled at each RID host. The purpose of the RIDPolicy class is to specify the message type for the receiving host, facilitate the policy needs of RID, and provide routing information in the form of an IP address of the destination RID system. The security requirements and policy guidelines are discussed in Section 9. The policy is defined between RID peers and within or between consortiums. RIDPolicy is meant to be a tool to facilitate the defined policies. This MUST be used in accordance with policy set between clients, peers, consortiums, and/or regions. Security, privacy, and confidentiality MUST be considered as specified in this document.
Top   ToC   RFC6545 - Page 16
   The RID schema is defined as follows:

           +------------------+
           |        RID       |
           +------------------+
           |                  |
           | ENUM lang        |<>---{0..1}----[ RIDPolicy      ]
           |                  |
           |                  |<>---{0..1}----[ RequestStatus  ]
           |                  |
           |                  |<>---{0..1}----[ IncidentSource ]
           +------------------+

                         Figure 3: The RID Schema

   The aggregate classes that constitute the RID schema in the iodef-rid
   namespace are as follows:

   RIDPolicy

      Zero or One.  The RIDPolicy class is used by all message types to
      facilitate policy agreements between peers, consortiums, or
      federations, as well as to properly route messages.

   RequestStatus

      Zero or One.  The RequestStatus class is used only in
      Acknowledgement messages.  The message reports back to the CSIRT
      or SP in the Acknowledgement message to provide status on a
      Request or if an error or problem occurs with the receipt or
      processing of a Report, Query, or Result message.

   IncidentSource

      Zero or One.  The IncidentSource class is used in the Result
      message only.  The IncidentSource provides the information on the
      identified source host or network of an attack trace or
      investigation.

   Each of the three listed classes may be the only class included in
   the RID class, hence the option for zero or one.  In some cases,
   RIDPolicy MAY be the only class in the RID definition when used by
   the transport protocol [RFC6546], as that information should be as
   small as possible and may not be encrypted.  The RequestStatus
   message MUST be able to stand alone without the need for an IODEF
   document to facilitate the communication, limiting the data
   transported to the required elements per [RFC6546].
Top   ToC   RFC6545 - Page 17
   The RID class has one attribute:

      lang

         One.  REQUIRED.  ENUM.  A valid language code per [RFC5646]
         constrained by the definition of "xs:language" inherited from
         [XML1.0].

5.1. RIDPolicy Class

The RIDPolicy class facilitates the delivery of RID messages and is also referenced for transport in the transport document [RFC6546]. The RIDPolicy Class includes the ability to embed an IODEF document or XML documents that conform to schemas other than IODEF in the ReportSchema element. +------------------------+ | RIDPolicy | +------------------------+ | | | ENUM restriction |<>-------------[ Node ] | ENUM MsgType | | ENUM MsgDestination |<>---{0..1}----[ IncidentID ] | ENUM ext-MsgType | | ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ] | | | |<>---{1..*}----[ TrafficType ] | | | |<>---{0..1}----[ ReportSchema ] +------------------------+ Figure 4: The RIDPolicy Class The aggregate elements that constitute the RIDPolicy class are as follows: Node One. The Node class is used to identify a host or network device, in this case to identify the system communicating RID messages, and the usage is determined by the MsgDestination attribute. The base definition of this class is reused from the IODEF specification [RFC5070], Section 3.16. See Section 11 of this document for Internationalization considerations.
Top   ToC   RFC6545 - Page 18
   IncidentID

      Zero or one.  Global reference pointing back to the IncidentID
      defined in the IODEF data model.  The IncidentID includes the name
      of the CSIRT, an incident number, and an instance of that
      incident.  The instance number is appended with a dash separating
      the values and is used in cases for which it may be desirable to
      group incidents.  Examples of incidents that may be grouped
      include botnets, polymorphic attacks, DDoS attacks, multiple hops
      of compromised systems found during an investigation, etc.

   PolicyRegion

      One or many.  REQUIRED.  The values for the attribute "region" are
      used to determine what policy area may require consideration
      before a trace can be approved.  The PolicyRegion may include
      multiple selections from the attribute list in order to fit all
      possible policy considerations when crossing regions, consortiums,
      or networks.

   region

      One or many.  REQUIRED.  ENUM.  The attribute region is used to
      identify the expected sharing range of the incident information.
      The region may be within a region or defined by existing
      relationships such as those of a consortium or a client to a
      service provider.

      1.  ClientToSP.  A client initiated the request to their service
          provider (SP).  A client may be an individual, enterprise, or
          other type of entity (government, commercial, education,
          etc.).  An SP may be a network, telecommunications,
          infrastructure, or other type of SP where a client-to-vendor
          relationship has been established.  The client-to-vendor
          relationship will typically have established contracts or
          agreements to define expectations and trust relationships.

      2.  SPToClient.  An SP initiated a RID request or report to a
          client.  A client may be an individual, enterprise, or other
          type of entity (government, commercial, education, etc.).  An
          SP may be a network, telecommunications, infrastructure, or
          other type of SP where a client-to-vendor relationship has
          been established.  The client-to-vendor relationship will
          typically have established contracts or agreements to define
          expectations and trust relationships.
Top   ToC   RFC6545 - Page 19
      3.  IntraConsortium.  Incident information that should have no
          restrictions within the boundaries of a consortium with the
          agreed-upon use and abuse guidelines.  A consortium is a well-
          defined group with established members and trust relationships
          specific to sharing within that group.  A consortium would
          typically define the types of data that can be shared in
          advance, define the expectations on protecting that data, as
          well as have established contractual agreements.  Examples of
          consortiums may include industry-focused sharing communities
          (financial, government, research and education, etc.) or cross
          industry sharing communities (for instance, organizations
          within local proximity that form a sharing group).

      4.  PeerToPeer.  Incident information that should have no
          restrictions between two peers but may require further
          evaluation before continuance beyond that point with the
          agreed-upon use and abuse guidelines.  PeerToPeer
          communications may involve any two individuals or entities
          that decide to share information directly with each other.

      5.  BetweenConsortiums.  Incident information that should have no
          restrictions between consortiums that have established agreed-
          upon use and abuse guidelines.  BetweenConsortiums is used
          when two consortiums (as defined in IntraConsortium above)
          share data.  The types of data that can be shared
          BetweenConsortiums should be identified in their agreements
          and contracts along with expectations on how that data should
          be handled and protected.

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

   TrafficType

      One or many.  REQUIRED.  The values for the attribute "type" are
      meant to assist in determining if a trace is appropriate for the
      SP receiving the request to continue the trace.  Multiple values
      may be selected for this element; however, where possible, it
      should be restricted to one value that most accurately describes
      the traffic type.

   type

      One or many.  REQUIRED.  ENUM.  The attribute type is used to
      identify the type of information included in the RID message or
      the type of incident.
Top   ToC   RFC6545 - Page 20
      1.  Attack.  This option SHOULD only be selected if the traffic is
          related to an information security incident or attack.  The
          type of attack MUST also be listed in more detail in the IODEF
          Method and Impact classes for further clarification to assist
          in determining if the trace can be continued ([RFC5070],
          Sections 3.9 and 3.10.1).

      2.  Network.  This option MUST only be selected when the trace is
          related to network traffic or routing issues.

      3.  Content.  This category MUST be used only in the case in which
          the request is related to the content and regional
          restrictions on accessing that type of content exist.  This is
          not malicious traffic but may be used for determining what
          sources or destinations accessed certain materials available
          on the Internet, including, but not limited to, news,
          technology, or inappropriate content.

      4.  DataWithHandlingRequirements.  This option is used when data
          shared may have additional restrictions for handling,
          protection, and processing based on the type of data and where
          it resides.  Regulatory or legal restrictions may be imposed
          on specific types of data that could vary based on the
          location, region or nation, of the data or where it
          originated.  The IODEF document, as well as any extensions,
          included with the RID message should indicate the specific
          restrictions to be considered.  The use of this enumeration
          flag is not legally binding.

      5.  AudienceRestriction.  This option is used to indicate that the
          message contains data that should be viewed by a restricted
          audience.  This setting should not be used for normal
          incidents or reporting as it could slow response times.  The
          content may be a business-relevant notification or request.
          This option MAY be used by a business partner to report or
          request assistance if an incident has affected a supply chain.
          This option may also be used if the content is relevant to
          regulatory obligations, legal (eDiscovery), or other use cases
          that require management attention.

      6.  Other.  If this option is selected, a description of the
          traffic type MUST be provided so that policy decisions can be
          made to continue or stop the investigation.  The information
          should be provided in the IODEF message in the Expectation
          class or in the History class using a HistoryItem log.  This
          may also be used for incident types other than information-
          security-related incidents.
Top   ToC   RFC6545 - Page 21
      7.  ext-value.  An escape value used to extend this attribute.
          See IODEF [RFC5070], Section 5.1.

      ReportSchema

         Zero or One.  The ReportSchema class is used by the message
         types that require the full IODEF schema to be included in the
         RID envelope.  Alternate schemas may be included if approved by
         the Designated Reviewer and registered by IANA for use with
         RID.

   The RIDPolicy class has five attributes:

      restriction

         OPTIONAL.  ENUM.  This attribute indicates the disclosure
         guidelines to which the sender expects the recipient to adhere.
         This guideline provides no real security since it is the choice
         of the recipient of the document to honor it.  This attribute
         follows the same guidelines as "restriction" used in IODEF.

      MsgType

         One.  REQUIRED.  ENUM.  The type of RID message sent.  The five
         types of messages are described in Section 4.2 and can be noted
         as one of the six selections below, where a Request is set to
         either 'InvestigationRequest' or 'TraceRequest'.

         1.  TraceRequest.  This Request message may be used to initiate
             a TraceRequest or to continue a TraceRequest to an upstream
             network closer to the source address of the origin of the
             security incident.

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

         3.  Result.  This message indicates that the source of the
             attack was located, and the message is sent to the
             initiating RID system through the RID systems in the path
             of the trace.
Top   ToC   RFC6545 - Page 22
         4.  InvestigationRequest.  This Request message type is used
             when the source of the traffic is believed to be valid.
             The purpose of the InvestigationRequest is to leverage the
             existing peer or consortium relationships in order to
             notify the SP closest to the source of the valid traffic
             that some event occurred, which may be a security-related
             incident.

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

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

      Additionally, there is an extension attribute to add new
      enumerated values:

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

      MsgDestination

         One.  REQUIRED.  ENUM.  The destination required at this level
         may either be the RID messaging system intended to receive the
         request, or, in the case of a Request with MsgType set to
         'InvestigationRequest', the source of the incident.  In the
         case of an InvestigationRequest, the RID system that can help
         stop or mitigate the traffic may not be known, and the message
         may have to traverse RID messaging systems by following the
         routing path to the RID system closest to the source of the
         attack traffic.  The Node element lists either the RID system
         or the IP address of the source, and the meaning of the value
         in the Node element is determined by the MsgDestination
         element.

         1.  RIDSystem.  The IP address of the next upstream system
             accepting RID communications is REQUIRED and is listed in
             the Node element of the RIDPolicy class.  If NodeName
             element of the Node class is used, it contains a DNS domain
             name.  The originating RID system is required to check that
             this domain name resolves to the IP address to which the
             RID message is sent.  This check may be performed in
             advance of sending the message and the result saved for
             future use with additional RID messages.
Top   ToC   RFC6545 - Page 23
         2.  SourceOfIncident.  The Address element of the Node element
             contains the IP address of the incident source, and the
             NodeName element of the Node class is not used.  The IP
             address is REQUIRED when this option is selected.  The IP
             address is used to determine the path of systems accepting
             RID communications that will be used to find the closest
             RID system to the source of an attack in which the IP
             address used by the source is believed to be valid and a
             Request message with MsgDestination set to
             'InvestigationRequest' is used.  This is not to be confused
             with the IncidentSource class, as the defined value here is
             from an initial Request ('InvestigationRequest' or
             'TraceRequest'), not the source used in a Result message.

         3.  ext-value.  An escape value used to extend this attribute.
             All extensions shall specify the contents and meaning of
             the Node element of RIDPolicy.  See IODEF [RFC5070],
             Section 5.1, on extensibility.  If the NodeName element of
             the Node class is used by an extension, NodeName may
             contain an Internationalized Domain Name (IDN); see
             Section 11 for applicable requirements.  All extensions
             SHOULD use an IP address in the Address element of the Node
             class as the primary means of Node identification.

      MsgType-ext

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

      MsgDestination-ext

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

5.1.1. ReportSchema

The ReportSchema class is an aggregate class in the RIDPolicy class. The IODEF schema is the approved schema for inclusion in RID messages via the ReportSchema class.
Top   ToC   RFC6545 - Page 24
          +-------------------------+
          |      ReportSchema       |
          +-------------------------+
          |                         |
          |  ENUM Version           |
          |  STRING ext-Version     |<>---{1}-------[ XMLDocument   ]
          |  ENUM XMLSchemaID       |
          |  STRING ext-XMLSchemaID |<>---{0..1}----[ URL           ]
          |                         |
          |                         |<>---{0..*}----[ Signature     ]
          |                         |
          +-------------------------+

                     Figure 5: The ReportSchema Class

   The elements that constitute the ReportSchema class are as follows:

      XMLDocument

         One.  The XMLDocument is a complete XML document defined by the
         iodef:ExtensionType class.  This class follows the guidelines
         in [RFC5070], Section 5, where the data type is set to 'xml'
         and meaning is set to 'xml' to include an XML document.

      URL

         Zero or One.  URL.  A reference to the XML schema of the XML
         document included.  The URL data type is defined in [RFC5070],
         Section 2.15, as "xs:anyURI" in the schema.  The schemaLocation
         for IODEF is already included in the RID schema, so this is not
         necessary to include a URL for IODEF documents.  The list of
         registered schemas for inclusion will be maintained by IANA.

      Signature

         Zero to many.  The Signature uses the iodef:ExtensionType class
         to enable this element to contain a detached or enveloped
         signature.  This class follows the guidelines in [RFC5070]
         Section 5 where the data type is set to 'xml' and meaning is
         set to 'xml' to include an XML document.  This element is used
         to encapsulate the detached signature based on the iodef:
         RecordItem class within the IODEF document to verify the
         originator of the message or to include the enveloped
         signature.  If other schemas are used instead of IODEF, they
         MUST provide guidance on what class to use if a detached
         signature is provided for this purpose.
Top   ToC   RFC6545 - Page 25
      The ReportSchema class has four attributes:

      Version

         OPTIONAL.  One.  The Version attribute is the version number of
         the specified XML schema.  That schema must be an approved
         version of IODEF or a schema registered with IANA for use with
         RID.  The IANA registry for managing schemas other than IODEF
         is specified in Section 12.

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

      ext-Version

         OPTIONAL.  One.  The ext-Version attribute is the version
         number of the included XML schema.  This attribute is used if a
         schema other than IODEF or an IANA-registered schema that has
         been added to the enumerated list for Version is included.

      XMLSchemaID

         OPTIONAL.  One.  The XMLSchemaID attribute is the identifier,
         the defined namespace [XMLNames], of the XML schema of the XML
         document included.  The XMLSchemaID and Version specify the
         format of the XMLDocument element.  The only permitted values,
         include the namespace for IODEF [RFC5070],
         "urn:ietf:params:xml:ns:iodef-1.0", any future IETF-approved
         versions of IODEF, and any namespace included in the IANA-
         managed list of registered schemas for use with RID.  The IANA
         registry for managing schemas other than IODEF is specified in
         Section 12.

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

      ext-XMLSchemaID

         OPTIONAL.  One.  The ext-XMLSchemaID attribute is the
         identifier (defined namespace) of the XML schema of the XML
         document included.  The ext-XMLSchemaID and ext-Version specify
         the format of the XMLDocument element and are used if the
         included schema is not IODEF version 1.0 or an IANA-registered
         schema that has been added to the enumerated list for
         XMLSchemaID.
Top   ToC   RFC6545 - Page 26

5.2. RequestStatus

The RequestStatus class is an aggregate class in the RID class. +--------------------------------+ | RequestStatus | +--------------------------------+ | | | ENUM restriction | | ENUM AuthorizationStatus | | ENUM Justification | | STRING ext-AuthorizationStatus | | STRING ext-Justification | | | +--------------------------------+ Figure 6: The RequestStatus Class The RequestStatus class has five attributes: restriction OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF. AuthorizationStatus One. REQUIRED. ENUM. The listed values are used to provide a response to the requesting CSIRT of the status of a Request, Report, or Query. 1. Approved. The trace was approved and will begin in the current SP. 2. Denied. The trace was denied in the current SP. The next closest SP can use this message to filter traffic from the upstream SP using the example packet to help mitigate the effects of the attack as close to the source as possible. The Acknowledgement message must be passed back to the originator and a Result message must be used from the closest SP to the source in order to indicate actions taken in the IODEF History class.
Top   ToC   RFC6545 - Page 27
         3.  Pending.  Awaiting approval; a timeout period has been
             reached, which resulted in this Pending status and
             Acknowledgement message being generated.

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

         Justification

            OPTIONAL.  ENUM.  Provides a reason for a Denied or Pending
            message.

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

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

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

            4.  Encryption.  The recipient was unable to decrypt the
                request, report, or query.

            5.  UnrecognizedFormat.  The format of the provided document
                was unrecognized.

            6.  CannotProcess.  The document could not be processed.
                Reasons may include legal or policy decisions.
                Resolution may require communication outside of this
                protocol to resolve legal or policy issues.  No further
                messages SHOULD be sent until resolved.

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

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

         AuthorizationStatus-ext

            OPTIONAL.  STRING.  A means by which to extend the
            AuthorizationStatus attribute.  See IODEF [RFC5070], Section
            5.1.
Top   ToC   RFC6545 - Page 28
         Justification-ext

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

5.3. IncidentSource

The IncidentSource class is an aggregate class in the RID class. +-------------------+ | IncidentSource | +-------------------+ | | | ENUM restriction | | |<>-------------[ SourceFound ] | | | |<>---{0..*}----[ Node ] | | +-------------------+ Figure 7: The IncidentSource Class The elements that constitute the IncidentSource class follow: SourceFound One. BOOLEAN. The Source class indicates if a source was identified. If the source was identified, it is listed in the Node element of this class. True. Source of incident was identified. False. Source of incident was not identified. Node Zero or many. The Node class is used to identify a system identified as part of an incident. If this element is used, the Address element of the Node element MUST contain the IP address of the system. If the NodeName element of the Node class is used, it contains a DNS domain name that has been checked to ensure that it resolved to that IP address when the check was performed. See Section 11 of this document for internationalization considerations for NodeName. The base definition of this class from the IODEF ([RFC5070], Section 3.16) can be expanded to include other identifiers.
Top   ToC   RFC6545 - Page 29
      The IncidentSource class has one attribute:

      restriction

         OPTIONAL.  ENUM.  This attribute indicates the disclosure
         guidelines to which the sender expects the recipient to
         adhere.This guideline provides no real security since it is the
         choice of the recipient of the document to honor it.  This
         attribute follows the same guidelines as "restriction" used in
         IODEF.

5.4. RID Name Spaces

The RID schema declares a namespace of "urn:ietf:params:xml:ns:iodef-rid-2.0" and registers it per [RFC3688]. Each IODEF-RID document MUST use the "iodef-rid-2.0" namespace in the top-level element RID-Document. It can be referenced as follows: <RID-Document version="2.0" lang="en-US" xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0" xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0.xsd">

5.5. Encoding

RID documents MUST begin with an XML declaration and MUST specify the XML version used; also, the use of UTF-8 encoding is REQUIRED ([RFC3470], Section 4.4). RID conforms to all XML data encoding conventions and constraints. The XML declaration with no character encoding will read as follows: <?xml version="1.0" encoding="UTF-8"?> The following characters have special meaning in XML and MUST be escaped with their entity reference equivalent: "&", "<", ">", "\"" (double quotation mark), and "'" (apostrophe). These entity references are "&amp;", "&lt;", "&gt;", "&quot;", and "&apos;", respectively.

5.6. Including IODEF or Other XML Documents

In order to support the changing activity of CSIRTS, the RID schema can include an IODEF or other data model. The IODEF is also extensible, enabling the schemas to evolve along with the needs of CSIRTs. This section discusses how to include the IODEF XML document or other XML documents to leverage the security and trust
Top   ToC   RFC6545 - Page 30
   relationships established through the use of RID.  These techniques
   are designed so that adding new data will not require a change to the
   RID schema.  This approach also supports the exchange of private XML
   documents relevant only to a closed consortium.  XML documents can be
   included through the ReportSchema class in the RIDPolicy class.  The
   XMLDocument attribute is set to 'xml' to allow for the inclusion of
   full IODEF or other XML documents.  The following guidelines MUST be
   followed:

   1.  The included schema MUST define a separate namespace, such as the
       declared namespace for IODEF of
       "urn:ietf:params:xml:ns:iodef-1.0".

   2.  When a parser encounters an included XML document it does not
       understand, the included document MUST be ignored (and not
       processed), but the remainder of the document MUST be processed.
       Parsers will be able to identify the XML documents for which they
       have no processing logic through the namespace declaration.
       Parsers that encounter an unrecognized element in a namespace
       that they do support SHOULD reject the document as a syntax
       error.

   3.  Implementations SHOULD NOT download schemas at runtime due to the
       security implications, and included documents MUST NOT be
       required to provide a resolvable location of their schema.

   The examples included in Section 7 demonstrate how an IODEF document
   is included.  The included schema of IODEF is represented in
   ReportSchema as follows:

      Version: "1.0"

      XMLSchemaID: "urn:ietf:params:xml:ns:iodef-1.0"

      URL: "http://www.iana.org/assignments/xml-registry/schema/
      iodef-1.0.xsd"

   The URL is optionally included for IODEF since it is already in the
   RID schema, and the schemaLocation is defined.

5.6.1. Including XML Documents in RID

XML schemas may be registered for inclusion in a RID message. This may include schemas other than IODEF or updated versions of IODEF. The registered IANA information for additional schemas MUST include the specification name, version, specification Uniform Resource Identifier (URI), and namespace. The following provides an example of the necessary information for additional schemas beyond IODEF.
Top   ToC   RFC6545 - Page 31
   Example Name (XXXX)

      Schema Name:   XXXX_1.1
      Version:       1.1
      Namespace:     <registered namespace>
      Specification URI:  http://www.example.com/XXXX

   The version attribute of the ReportSchema class is populated with the
   approved versions of IODEF or any additional schemas registered by
   IANA; see Section 12.

   The XMLSchemaID of the ReportSchema class is populated with the
   namespace of the included schema.  The attribute enumeration values
   include the namespace for IODEF and any schema registered by IANA;
   see Section 12.

   The URL element of the ReportSchema class is populated with the
   Specification URI value of the included schema.

6. RID Messages

The IODEF model is followed as specified in [RFC5070] for each of the RID message types. The RID schema is used in combination with IODEF documents to facilitate RID communications. Each message type varies slightly in format and purpose; hence, the requirements vary and are specified for each. All classes, elements, attributes, etc., that are defined in the IODEF-Document are valid in the context of a RID message; however, some listed as optional in IODEF are mandatory for RID as listed for each message type. The IODEF model MUST be fully implemented for RID messages that include IODEF payloads to ensure proper parsing of those messages. Note: The implementation of RID may automate the ability to fill in the content required for each message type from packet input, incident data, situational awareness information, or default values such as those used in the EventData class.

6.1. Request

Description: This message type is used to request assistance in a computer security investigation. The investigation request may be directed to another party that can assist with forensics and continue the investigation (the incident may have originated on the SP network to which the Request was sent), or it may be directed to an SP to trace the traffic from an unknown source. The Request message with MsgType set to 'InvestigationRequest' may leverage the existing bilateral peer relationships in order to notify the SP closest to the source of the valid traffic that some event occurred, which may be a
Top   ToC   RFC6545 - Page 32
   security-related incident.  A Request message with the MsgType set to
   'TraceRequest' may be sent to an upstream peer to trace back through
   the network to locate the source of malicious traffic.  The following
   information is REQUIRED for Request messages and is provided through
   the following data structures:

   RID Information:

      RIDPolicy

         RID message type, IncidentID, and destination policy
         information

   IODEF Information:

      Timestamps (DetectTime, StartTime, EndTime, ReportTime).

      Incident Identifier (Incident class, IncidentID).

      Confidence rating of security incident (Impact and Confidence
      class).

      System class is used to list both the Source and Destination.

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

      Path information of nested RID systems, beginning with the request
      originator used in the trace using IODEF EventData with category
      set to 'infrastructure'.

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

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

      Digital signature from initiating CSIRT or provider system sending
      the RID message, passed to all systems receiving the Request using
      a detached XML digital signature on a RecordItem entry, placed in
      an instance of the Signature element.

      Digital signature of sending CSIRT or SP for authenticity of the
      RID message, from the CSIRT or provider creating this message
      using an enveloped XML digital signature on the IODEF document,
      placed in an instance of the Signature element.
Top   ToC   RFC6545 - Page 33
      XML encryption as required by policy, agreements, and data
      markers.

   Security requirements include the ability to encrypt [XMLencrypt] the
   contents of the Request message using the public key of the
   destination RID system.  The incident number increases whether the
   Request message has the MsgDestination set to 'InvestigationRequest'
   or 'TraceRequest' in order to ensure uniqueness within the system.
   The relaying peers also append their Autonomous System (AS) or RID
   system information using the path information as the Request message
   was relayed through SPs.  This enables the response (Result message)
   to utilize the same path and trust relationships for the return
   message, indicating any actions taken.  The request is recorded in
   the state tables of both the initiating and destination SP RID
   systems.  The destination SP is responsible for any actions taken as
   a result of the request in adherence to any service level agreements
   or policies.  The SP MUST confirm that the traffic actually
   originated from the suspected system before taking any action and
   confirm the reason for the request.  The request may be sent directly
   to a known RID system or routed by the source address of the attack
   using the MsgDestination of RIDPolicy set to 'SourceOfIncident'.
   Note: Any intermediate parties in a TraceRequest MUST be able to view
   RIDPolicy information of responding message types in order to
   properly direct RID messages.

   A DDoS attack can have many sources, resulting in multiple traces to
   locate the sources of the attack.  It may be valid to continue
   multiple traces for a single attack.  The path information enables
   the administrators to determine if the exact trace already passed
   through a single network.  The Incident Identifier must also be used
   to identify multiple Requests from a single incident.  If a single
   Request results in divergent paths of Requests, a separate instance
   number MUST be used under the same IncidentID.  The IncidentID
   instance number of IODEF can be used to correlate related incident
   data that is part of a larger incident.

6.2. Acknowledgement

Description: The Acknowledgement is also used to provide a status to any message type and to provide a Justification if the message could not be processed for any reason. This message is sent to the initiating RID system from the next upstream provider's application or system designated for accepting RID communications to provide information on the request status in the current SP. The following information is REQUIRED for Acknowledgement messages and is provided through the following data structures:
Top   ToC   RFC6545 - Page 34
   RID Information:

      RIDPolicy

         RID message type, IncidentID, and destination policy
         information

      RequestStatus class:

         Status of Request

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

      Digital signature of responding CSIRT or provider for authenticity
      of Trace Status Message, from the CSIRT or provider creating this
      message using an enveloped XML digital signature.

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

   A message is sent back to the initiating CSIRT or provider's system;
   it accepts RID communications of the trace as status notification.
   This message verifies that the next RID system in the path has
   received the message from the previous system in the path.  This
   message also verifies that the trace is now continuing, has stopped,
   or is pending in the next upstream CSIRT or provider's RID system.
   The Pending status is automatically generated after a 2-minute
   timeout without system-predefined or administrator action to approve
   or disapprove the trace continuance.  If a Request is denied, the
   originator and sending peer (if they are not the same) MUST both
   receive the message.  This provides the sending peer with the option
   to take action to stop or mitigate the traffic as close to the source
   as possible.

6.3. Result

Description: This message indicates that the trace or investigation has been completed and provides the result. The Result message includes information on whether or not a source was found, and the source information is provided through the IncidentSource class. The Result information MUST go back to the originating RID system that began the investigation or trace. A provider may use any number of incident-handling data sources to ascertain the true source of an attack. All of the possible information sources may or may not be readily tied into the RID communications system.
Top   ToC   RFC6545 - Page 35
   The following information is REQUIRED for Result messages and will be
   provided through the following data structures:

      RID Information:

         RIDPolicy

            RID message type, IncidentID, and destination policy
            information

         Incident Source

            The IncidentSource class of the RID schema is used to note
            if a source was identified and provide the source
            address(es) or other Node information.

      IODEF Information:

         Timestamps (DetectTime, StartTime, EndTime, ReportTime).

         Incident Identifier (Incident class, IncidentID).

            Trace number is used for multiple traces of a single
            incident; it MUST be included if the response is specific to
            an instance of an incident.

         Confidence rating of security incident (Impact and Confidence
         class).

         System class is used to list both the Source and Destination
         Information used in the attack and must note if the traffic is
         spoofed, thus requiring in RID an upstream Request set to
         'TraceRequest'.

         History class "atype" attribute is used to note any actions
         taken.

         History class also notes any other background information
         including notes about the Confidence level or rating of the
         result information.

         Path information of nested RID systems, beginning with the
         request originator used in the trace using IODEF EventData with
         category set to 'infrastructure'.  The last SP listed is the SP
         that located the source of the traffic (the provider sending
         the Result message).
Top   ToC   RFC6545 - Page 36
         Event, Record, and RecordItem classes to include example
         packets and other information related to the incident
         (optional).  Note: Event information included here requires a
         second instance of EventData in addition to that used to convey
         SP path contact information.

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

         Digital signature of source CSIRT or provider for authenticity
         of Result message, from the CSIRT or provider creating this
         message using an enveloped XML digital signature.

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

   A message is sent back to the initiating CSIRT or provider's RID
   system to notify the CSIRT that the source has been located.  The
   actual source information may or may not be included, depending on
   the policy of the network in which the client or host is attached.
   Any action taken by the SP to act upon the discovery of the source of
   a trace should be included.  The SP may be able to automate the
   adjustment of filters at their border router to block outbound access
   for the machine(s) discovered as a part of the attack.  The filters
   may be comprehensive and block all Internet access until the host has
   taken the appropriate action to resolve any security issues.  The SP
   may be limited in their options for filtering due to agreements or
   other restrictions resulting in less comprehensive filters, such as
   rate-limiting the ingress traffic as close to the source as possible.

   Security and privacy requirements discussed in Section 9 MUST be
   taken into account.

   Note: The History class has been expanded in IODEF to accommodate all
   of the possible actions taken as a result of a RID Request using the
   "iodef:atype", or action type, attribute.  The History class should
   be used to note all actions taken close to the source of a trace or
   incident using the most appropriate option for the type of action
   along with a description.  The "atype" attribute in the Expectation
   class can also be used to request an appropriate action when a
   Request is made.

6.4. Report

Description: This message or document is sent to a RID system to provide a report of a security incident. This message does not require any actions to be taken, except to file the report on the receiving RID system or associated database.
Top   ToC   RFC6545 - Page 37
   The following information is REQUIRED for Report messages and will be
   provided through the following data structures:

      RID Information:

         RIDPolicy RID message type, IncidentID, and destination policy
         information

      The following data is RECOMMENDED if available and can be provided
      through the following data structures:

      IODEF Information:

         Timestamps (DetectTime, StartTime, EndTime, ReportTime).

         Incident Identifier (Incident class, IncidentID).

            Trace number is used for multiple traces of a single
            incident; it MUST be included if the Report is specific to
            an instance of an incident.

         Confidence rating of security incident (Impact and Confidence
         class).

         System class is used to list both the Source and Destination
         Information used in the attack.

         Event, Record, and RecordItem classes are used to include
         example packets and other information related to the incident
         (optional).

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

         Digital signature from initiating RID system, passed to all
         systems receiving the report using an enveloped XML digital
         signature, placed in an instance of the Signature element.

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

   Security requirements include the ability to encrypt [XMLencrypt] the
   contents of the Report message using the public key of the
   destination RID system.  Senders of a Report message should note that
   the information may be used to correlate security incident
   information for the purpose of trending, pattern detection, etc., and
   may be shared with other parties unless otherwise agreed upon with
   the receiving RID system.  Therefore, sending parties of a Report
Top   ToC   RFC6545 - Page 38
   message may obfuscate or remove destination addresses or other
   sensitive information before sending a Report message.  A Report
   message may be sent either to file an incident report or to respond
   to a Query, and data sensitivity must be considered in both cases.
   The SP path information is not necessary for this message, as it will
   be communicated directly between two trusted RID systems.

6.5. Query

Description: The Query message is used to request incident information from a trusted RID system. The request can include the incident number, if known, or detailed information about the incident. If the incident number is known, the Report message containing the incident information can easily be returned to the trusted requestor using automated methods. If an example packet or other unique information is included in the Query, the return report may be automated; otherwise, analyst intervention may be required. The following information is REQUIRED for a Query message and is provided through the following data structures: RID Information: RIDPolicy RID message type, IncidentID, and destination policy information IODEF Information (optional): Timestamps (DetectTime, StartTime, EndTime, ReportTime). Incident Identifier (Incident class, IncidentID). Trace number is used for multiple traces of a single incident; it MUST be included if the Query is an instance of an incident. Confidence rating of security incident (Impact and Confidence class). System class is used to list both the Source and Destination Information used in the attack. Event, Record, and RecordItem classes are used to include example packets and other information related to the incident (optional).
Top   ToC   RFC6545 - Page 39
      Standards for encryption and digital signatures [RFC3275],
      [XMLsig], [XMLencrypt]:

         Digital signature from the CSIRT or SP initiating the RID
         message, passed to all systems receiving the Query using an
         enveloped XML digital signature, placed in an instance of the
         Signature element.

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

   The proper response to the Query message is a Report message.
   Multiple incidents may be returned for a single query if an incident
   type is requested.  In this case, the receiving system sends an IODEF
   document containing multiple incidents or all instances of an
   incident.  The system sending the reply may preset a limit to the
   number of documents returned in one report.  The recommended limit is
   5, to prevent the documents from becoming too large.  Other transfer
   methods may be better suited than RID for large transfers of data.
   The Confidence rating may be used in the Query message to select only
   incidents with an equal or higher Confidence rating than what is
   specified.  This may be used for cases when information is gathered
   on a type of incident but not on specifics about a single incident.
   Source and Destination Information may not be needed if the Query is
   intended to gather data about a specific type of incident.



(page 39 continued on part 3)

Next Section