Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6045

Real-time Inter-network Defense (RID)

Pages: 75
Obsoleted by:  6545
Part 2 of 4 – Pages 12 to 37
First   Prev   Next

ToP   noToC   RFC6045 - Page 12   prevText

4. Communication between Network Providers

Note: The Introduction, and Sub-sections 4.1 and 4.2, are informative, with the exception of references to IODEF/RID Transport [RFC6046]. Sub-sections 4.3, 4.4, and 4.5 are normative. Expediting the communication between CSIRTs is essential when responding to a security-related incident, which may cross network access points (Internet backbones) between providers. As a result of the urgency involved in this inter-NP security incident communication, there must be an effective system in place to facilitate the interaction. This communication policy or system should involve multiple means of communication to avoid a single point of failure. Email is one way to transfer information about the incident, packet traces, etc. However, email may not be received in a timely fashion or be acted upon with the same urgency as a phone call or other communication mechanism. Each NP should dedicate a phone number to reach a member of their respective CSIRT. The phone number could be dedicated to inter-NP incident communications and must be a hotline that provides a 24x7 live response. The phone line should reach someone who would have the authority, expertise, and the means to expedite the necessary action to investigate the incident. This may be a difficult policy to establish at smaller NPs due to resource limitations, so another solution may be necessary. An outside group may be able to serve this function if given the necessary access to the NP's network. The outside resource should be able to mitigate or alleviate the financial limitations and any lack of experienced resource personnel.
ToP   noToC   RFC6045 - Page 13
   A technical solution to trace traffic across a single NP may include
   homegrown or commercial systems for which RID messaging must
   accommodate the input requirements.  The IHS used on the NP's
   backbone by the CSIRT to coordinate the trace across the single
   network requires a method to accept and process RID messages and
   relay TraceRequests to the system, as well as to wait for responses
   from the system to continue the RID request process as appropriate.
   In this scenario, each NP would maintain its own RID/IHS and
   integrate with a management station used for network monitoring and
   analysis.  An alternative for NPs lacking sufficient resources may be
   to have a neutral third party with access to the NP's network
   resources who could be used to perform the incident handling
   functions.  This could be a function of a central organization
   operating as a CSIRT for the Internet as a whole or within a
   consortium that may be able to provide centralized resources.
   Consortiums would consist of a group of NPs and/or CSIRTs that agree
   to participate in the RID communication protocol with an agreed-upon
   policy and communication protocol facilitating the secure transport
   of IODEF/RID XML documents.  Transport for RID messages is specified
   in the IODEF/RID Transport [RFC6046] document.

   One goal of RID is to prevent the need to permit access to other
   networks' equipment through the use of a standard messaging mechanism
   to enable IHSs to communicate incident handling information to other
   networks in a consortium or in neighboring networks.  The third party
   mentioned above may be used in this technical solution to assist in
   facilitating incident handling and possibly traceback through smaller
   NPs.  The RID messaging mechanism may be a logical or physical out-
   of-band network to ensure that the communication is secure and
   unaffected by the state of the network under attack.  The two
   management methods would accommodate the needs of larger NPs to
   maintain full management of their network, and the third-party option
   could be available to smaller NPs who lack the necessary human
   resources to perform incident handling operations.  The first method
   enables the individual NPs to involve their network operations staff
   to authorize the continuance of a trace or other necessary response
   to a RID communication request through their network via a
   notification and alerting system.  The out-of-band logical solution
   for messaging may be permanent virtual circuits configured with a
   small amount of bandwidth dedicated to RID communications between
   NPs.

   The network used for the communication should consist of out-of-band
   or protected channels (direct communication links) or encrypted
   channels dedicated to the transport of RID messages.  The
   communication links would be direct connections between network peers
   who have agreed-upon use and abuse policies through the use of a
   consortium.  Consortiums might be linked through policy comparisons
ToP   noToC   RFC6045 - Page 14
   and additional agreements to form a larger web or iterative network
   of peers that correlates to the traffic paths available over the
   larger web of networks.  The maintenance of the individual links is
   the responsibility of the two network peers hosting the link.
   Contact information, IP addresses of RID systems, and other
   information must be coordinated between bilateral peers by a
   consortium and may use existing databases, such as the Routing
   Arbiter.  The security, configuration, and Confidence rating schemes
   of the RID messaging peers must be negotiated by peers and must meet
   certain overall requirements of the fully connected network
   (Internet, government, education, etc.) through the peering and/or a
   consortium-based agreement.

   RID messaging established with clients of an NP may be negotiated in
   a contract as part of a value-added service or through a service
   level agreement (SLA).  Further discussion is beyond the scope of
   this document and may be more appropriately handled in network
   peering or service level agreements.

   Procedures for incident handling need to be established and well
   known by anyone that may be involved in incident response.  The
   procedures should also contain contact information for internal
   escalation procedures, as well as for external assistance groups such
   as a CSIRT, CERT Coordination Center (CERT/CC), Global Information
   Assurance Certification (GIAC), and the FBI or other assisting
   government organization in the country of the investigation.

4.1. Inter-Network Provider RID Messaging

In order to implement a messaging mechanism between RID communication systems or IHSs, a standard protocol and format is required to ensure inter-operability between vendors. The messages would have to meet several requirements in order to be meaningful as they traverse multiple networks. RID provides the framework necessary for communication between networks involved in the incident handling, possible traceback, and mitigation of a security incident. Several message types described in Section 4.3 are necessary to facilitate the handling of a security incident. The message types include the Report, IncidentQuery, TraceRequest, RequestAuthorization, Result, and the Investigation request message. The Report message is used when an incident is to be filed on a RID system or associated database, where no further action is required. An IncidentQuery message is used to request information on a particular incident. A TraceRequest message is used when the source of the traffic may have been spoofed. In that case, each network provider in the upstream path who receives a TraceRequest will issue a trace across the network to determine the upstream source of the traffic. The RequestAuthorization and Result messages are used to communicate the
ToP   noToC   RFC6045 - Page 15
   status and result of a TraceRequest or Investigation request.  The
   Investigation request message would only involve the RID
   communication systems along the path to the source of the traffic and
   not the use of network trace systems.  The Investigation request
   leverages the bilateral relationships or a consortium's
   interconnections to mitigate or stop problematic traffic close to the
   source.  Routes could determine the fastest path to a known source IP
   address in the case of an Investigation request.  A message sent
   between RID systems for a TraceRequest or an Investigation request to
   stop traffic at the source through a bordering network would require
   the information enumerated below:

   1. Enough information to enable the network administrators to make a
      decision about the importance of continuing the trace.

   2. The incident or IP packet information needed to carry out the
      trace or investigation.

   3. Contact information of the origin of the RID communication.  The
      contact information could be provided through the Autonomous
      System Number (ASN) [RFC1930] or Network Information Center (NIC)
      handle information listed in the Registry for Internet Numbers or
      other Internet databases.

   4. Network path information to help prevent any routing loops through
      the network from perpetuating a trace.  If a RID system receives a
      TraceRequest containing its own information in the path, the trace
      must cease and the RID system should generate an alert to inform
      the network operations staff that a tracing loop exists.

   5. A unique identifier for a single attack.  This identifier should
      be used to correlate traces to multiple sources in a DDoS attack.

   Use of the communication network and the RID protocol must be for
   pre-approved, authorized purposes only.  It is the responsibility of
   each participating party to adhere to guidelines set forth in both a
   global use policy for this system and one established through the
   peering agreements for each bilateral peer or agreed-upon consortium
   guidelines.  The purpose of such policies is to avoid abuse of the
   system; the policies shall be developed by a consortium of
   participating entities.  The global policy may be dependent on the
   domain it operates under; for example, a government network or a
   commercial network such as the Internet would adhere to different
   guidelines to address the individual concerns.  Privacy issues must
   be considered in public networks such as the Internet.  Privacy
   issues are discussed in the Security Considerations section, along
   with other requirements that must be agreed upon by participating
   entities.
ToP   noToC   RFC6045 - Page 16
   RID requests must be legitimate security-related incidents and not
   used for purposes such as sabotage or censorship.  An example of such
   abuse of the system would include a request to rate-limit legitimate
   traffic to prevent information from being shared between users on the
   Internet (restricting access to online versions of papers) or
   restricting access from a competitor's product in order to sabotage a
   business.

   The RID system should be configurable to either require user input or
   automatically continue traces.  This feature would enable a network
   manager to assess the available resources before continuing a trace.
   A trace initiated from a TraceRequest may cause adverse effects on a
   network.  If the Confidence rating is low, it may not be in the NP's
   best interest to continue the trace.  The Confidence ratings must
   adhere to the specifications for selecting the percentage used to
   avoid abuse of the system.  TraceRequests must be issued by
   authorized individuals from the initiating network, set forth in
   policy guidelines established through peering or SLA.

4.2. RID Network Topology

The most basic topology for communicating RID systems would be a direct connection or a bilateral relationship as illustrated below. ___________ __________ | | | | | RID |__________-------------___________| RID | |_________| | NP Border | |________| ------------- Figure 1. Direct Peer Topology Within the consortium model, several topologies might be agreed upon and used. One would leverage bilateral network peering relationships of the members of the consortium. The peers for RID would match that of routing peers, and the logical network borders would be used. This approach may be necessary for an iterative trace where the source is unknown. The model would look like the above diagram; however, there may be an extensive number of interconnections of bilateral relationships formed. Also within a consortium model, it may be useful to establish an integrated mesh of networks to pass RID messages. This may be beneficial when the source address is known, and an interconnection may provide a faster route to reach the closest upstream peer to the source of the attack traffic. An example is illustrated below.
ToP   noToC   RFC6045 - Page 17
     _______                     _______                     _______
     |     |                     |     |                     |     |
   __| RID |____-------------____| RID |____-------------____| RID |__
     |_____|    | NP Border |    |_____|    | NP Border |    |_____|
        |       -------------               -------------       |
        |_______________________________________________________|

    Direct connection to network that is not an immediate network peer

                       Figure 2.  Mesh Peer Topology

   By using a fully meshed model in a consortium, broadcasting RID
   requests would be possible, but not advisable.  By broadcasting a
   request, RID peers that may not have carried the attack traffic on
   their network would be asked to perform a trace for the potential of
   decreasing the time in which the true source was identified.  As a
   result, many networks would have utilized unnecessary resources for a
   TraceRequest that may have also been unnecessary.

4.3. Message Formats

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

4.3.1. RID Data Types

RID is derived from the IODEF data model and inherits all of the data types defined in the IODEF model. One data type is added by RID: BOOLEAN.
4.3.1.1. Boolean
A boolean value is represented by the BOOLEAN data type. The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in the schema.
ToP   noToC   RFC6045 - Page 18

4.3.2. RID Messages and Transport

The six RID message types follow: 1. TraceRequest. This message is sent to the RID system next in the upstream trace. It is used to initiate a TraceRequest or to continue a TraceRequest to an upstream network closer to the source address of the origin of the security incident. The TraceRequest would trigger a traceback on the network to locate the source of the attack traffic. 2. RequestAuthorization. This message is sent to the initiating RID system from each of the upstream NPs' RID systems to provide information on the request status in the current network. 3. Result. This message is sent to the initiating RID system through the network of RID systems in the path of the trace as notification that the source of the attack was located. The Result message is also used to provide the notification of actions taken for an Investigation request. 4. Investigation. This message type is used when the source of the traffic is believed not to be spoofed. The purpose of the Investigation request message is to leverage the existing peer relationships in order to notify the network provider closest to the source of the valid traffic of a security-related incident for any necessary actions to be taken. 5. Report. This message is used to report a security incident, for which no action is requested. This may be used for the purpose of correlating attack information by CSIRTs, statistics and trending information, etc. 6. IncidentQuery. This message is used to request information about an incident or incident type from a trusted RID system. The response is provided through the Report message. When a system receives a RID message, it must be able to determine the type of message and parse it accordingly. The message type is specified in the RIDPolicy class. The RIDPolicy class may also be used by the transport protocol to facilitate the communication of security incident data to trace, investigate, query, or report information regarding security incidents.
ToP   noToC   RFC6045 - Page 19

4.3.3. IODEF-RID Schema

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

        +------------------+
        |        RID       |
        +------------------+
        | ANY              |
        |                  |<>---{0..1}----[ RIDPolicy      ]
        | ENUM restriction |
        | ENUM type        |<>---{0..1}----[ RequestStatus  ]
        | STRING meaning   |
        |                  |<>---{0..1}----[ IncidentSource ]
        +------------------+

                         Figure 3.  The RID Schema

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

   RIDPolicy

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

   RequestStatus

      Zero or One.  The RequestStatus class is used only in
      RequestAuthorization messages to report back to the originating
      RID system if the trace will be continued by each RID system that
      received a TraceRequest in the path to the source of the traffic.

   IncidentSource

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

   Each of the three listed classes may be the only class included in
   the RID class, hence the option for zero or one.  In some cases,
   RIDPolicy MAY be the only class in the RID definition when used by
   the transport protocol [RFC6046], as that information should be as
   small as possible and may not be encrypted.  The RequestStatus
   message MUST be able to stand alone without the need for an IODEF
   document to facilitate the communication, limiting the data
   transported to the required elements per [RFC6046].
ToP   noToC   RFC6045 - Page 21
4.3.3.1. RequestStatus Class
The RequestStatus class is an aggregate class in the RID class. +--------------------------------+ | RequestStatus | +--------------------------------+ | | | ENUM restriction | | ENUM AuthorizationStatus | | ENUM Justification | | STRING ext-AuthorizationStatus | | STRING ext-Justification | | | +--------------------------------+ Figure 4. The RequestStatus Class The RequestStatus class has five attributes: restriction OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF. AuthorizationStatus REQUIRED. ENUM. The listed values are used to provide a response to the requesting CSIRT of the status of a TraceRequest in the current network. 1. Approved. The trace was approved and will begin in the current NP. 2. Denied. The trace was denied in the current NP. The next closest NP can use this message to filter traffic from the upstream NP using the example packet to help mitigate the effects of the attack as close to the source as possible. The RequestAuthorization message must be passed back to the originator and a Result message used from the closest NP to the source to indicate actions taken in the IODEF History class.
ToP   noToC   RFC6045 - Page 22
      3. Pending.  Awaiting approval; a timeout period has been reached,
         which resulted in this Pending status and RequestAuthorization
         message being generated.

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

   Justification

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

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

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

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

      4. Encryption.  Unable to decrypt the request.

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

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

   AuthorizationStatus-ext

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

   Justification-ext

      OPTIONAL.  STRING.  A means by which to extend the Justification
      attribute.  See IODEF [RFC5070], Section 5.1.
ToP   noToC   RFC6045 - Page 23
4.3.3.2. IncidentSource Class
The IncidentSource class is an aggregate class in the RID class. +-------------------+ | IncidentSource | +-------------------+ | | | ENUM restriction | | |<>-------------[ SourceFound ] | | | |<>---{0..*}----[ Node ] | | +-------------------+ Figure 5. The IncidentSource Class The elements that constitute the IncidentSource class follow: SourceFound One. BOOLEAN. The Source class indicates if a source was identified. If the source was identified, it is listed in the Node element of this class. True. Source of incident was identified. False. Source of incident was not identified. Node One. The Node class is used to identify a host or network device, in this case to identify the system communicating RID messages. The base definition of this class is reused from the IODEF specification [RFC5070], Section 3.16. The IncidentSource class has one attribute: restriction OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF.
ToP   noToC   RFC6045 - Page 24
4.3.3.3. RIDPolicy Class
The RIDPolicy class facilitates the delivery of RID messages and is also referenced for transport in the transport document [RFC6046]. +------------------------+ | RIDPolicy | +------------------------+ | | | ENUM restriction |<>-------------[ Node ] | ENUM MsgType | | ENUM MsgDestination |<>---{0..1}----[ IncidentID ] | ENUM ext-MsgType | | ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ] | | | |<>---{1..*}----[ TrafficType ] | | +------------------------+ Figure 6. The RIDPolicy Class The aggregate elements that constitute the RIDPolicy class are as follows: Node One. The Node class is used to identify a host or network device, in this case to identify the system communicating RID messages. The base definition of this class is reused from the IODEF specification [RFC5070], Section 3.16. IncidentID Zero or one. Global reference pointing back to the IncidentID defined in the IODEF data model. The IncidentID includes the name of the CSIRT, an incident number, and an instance of that incident. The instance number is appended with a dash separating the values and is used in cases for which it may be desirable to group incidents. Examples of incidents that may be grouped would be botnets, DDoS attacks, multiple hops of compromised systems found during an investigation, etc. PolicyRegion One or many. REQUIRED. The values for the attribute "region" are used to determine what policy area may require consideration before a trace can be approved. The PolicyRegion may include
ToP   noToC   RFC6045 - Page 25
      multiple selections from the attribute list in order to fit all
      possible policy considerations when crossing regions, consortiums,
      or networks.

   region

      One.  ENUM.

      1. ClientToNP.  An enterprise network initiated the request.

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

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

      4. PeerToPeer.  A trace that should have no restrictions between
         two peers but may require further evaluation before continuance
         beyond that point with the agreed-upon use and abuse
         guidelines.

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

      6. AcrossNationalBoundaries.  This selection must be set if the
         trace type is anything but a trace of attack traffic with
         malicious intent.  This must also be set if the traffic request
         is based upon regulations of a specific nation that would not
         apply to all nations.  This is different from the
         "BetweenConsortiums" setting since it may be possible to have
         multiple nations as members of the same consortium, and this
         option must be selected if the traffic is of a type that may
         have different restrictions in other nations.

      7. ext-value.  An escape value used to extend this attribute.  See
         IODEF [RFC5070], Section 5.1.
ToP   noToC   RFC6045 - Page 26
   TrafficType

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

   type

      One.  ENUM.

      1. Attack.  This option should only be selected if the traffic is
         related to a network-based attack.  The type of attack MUST
         also be listed in more detail in the IODEF Method and Impact
         classes for further clarification to assist in determining if
         the trace can be continued ([RFC5070], Sections 3.9 and
         3.10.1).

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

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

      4. OfficialBusiness.  This option MUST be used if the traffic
         being traced is requested or is affiliated with any government
         or other official business request.  This would be used during
         an investigation by government authorities or other government
         traces to track suspected criminal or other activities.

      5. Other.  If this option is selected, a description of the
         traffic type MUST be provided so that policy decisions can be
         made to continue or stop the trace.  The information should be
         provided in the IODEF message in the Expectation class or in
         the History class using a HistoryItem log.

      6. ext-value.  An escape value used to extend this attribute.  See
         IODEF [RFC5070], Section 5.1.
ToP   noToC   RFC6045 - Page 27
   The RIDPolicy class has five attributes:

   restriction

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

   MsgType

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

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

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

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

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

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

      6. IncidentQuery.  This message is used to request information
         from a trusted RID system about an incident or incident type.
ToP   noToC   RFC6045 - Page 28
      Additionally, there is an extension attribute to add new
      enumerated values:

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

   MsgDestination

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

      1. RIDSystem.  The address listed in the Node element of the
         RIDPolicy class is the next upstream RID system that will
         receive the RID message.

      2. SourceOfIncident.  The address listed in the Node element of
         the RIDPolicy class is the incident source.  The IP address is
         used to determine the path of RID systems that will be used to
         find the closest RID system to the source of an attack in which
         the IP address used by the source is believed to be valid and
         an Investigation request message is used.  This is not to be
         confused with the IncidentSource class, as the defined value
         here is from an initial trace or Investigation request, not the
         source used in a Result message.

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

   MsgType-ext

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

   MsgDestination-ext

      OPTIONAL.  STRING.  A means by which to extend the MsgDestination
      attribute.  See IODEF [RFC5070], Section 5.1.
ToP   noToC   RFC6045 - Page 29

4.3.4. RID Namespace

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

4.4. RID Messages

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

4.4.1. TraceRequest

Description: This message or document is sent to the network management station next in the upstream trace once the upstream source of the traffic has been identified. The following information is required for TraceRequest messages and is provided through: RID Information: RIDPolicy RID message type, IncidentID, and destination policy information IODEF Information: Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
ToP   noToC   RFC6045 - Page 30
         Incident Identifier (Incident class, IncidentID).
            Trace number - used for multiple traces of a single
            incident; must be noted.

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

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

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

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

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

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

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

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

4.4.2. RequestAuthorization

Description: This message is sent to the initiating RID system from the next upstream NP's RID system to provide information on the request status in the current network.
ToP   noToC   RFC6045 - Page 31
   The following information is required for RequestAuthorization
   messages and is provided through:

      RID Information:

         RIDPolicy
            RID message type, IncidentID, and destination
            policy information

         Status of TraceRequest
            RequestStatus class in RID schema

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

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

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

4.4.3. Result

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

      RID Information:

         RIDPolicy
            RID message type, IncidentID, and destination
            policy information

         Incident Source
            The IncidentSource class of the RID schema is used to note
            if a source was identified and provide the source
            address(es).

      IODEF Information:

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

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

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

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

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

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

         Path information of nested RID systems, beginning with the
            request originator used in the trace using IODEF EventData
            with category set to "infrastructure".  The last NP listed
            is the NP that located the source of the traffic (the NP
            sending the Result message).

         Event, Record, and RecordItem classes to include example
            packets and other information related to the incident
            (optional).
            Note: Event information included here requires a second
            instance of EventData in addition to that used to convey NP
            path contact information.
ToP   noToC   RFC6045 - Page 33
      Standards for encryption and digital signatures [RFC3275]:

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

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

   Security and privacy considerations discussed in Section 6 MUST be
   taken into account.

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

4.4.4. Investigation Request

Description: This message type is used when the source of the traffic is believed not to be spoofed. The purpose of the Investigation request message is to leverage the existing bilateral peer relationships in order to notify the network provider closest to the source of the valid traffic that some event occurred, which may be a security-related incident. The following information is required for Investigation request messages and is provided through: RID Information: RID Policy RID message type, IncidentID, and destination policy information
ToP   noToC   RFC6045 - Page 34
      IODEF Information:

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

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

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

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

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

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

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

      Standards for encryption and digital signatures [RFC3275]:

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

   Security considerations would include the ability to encrypt
   [XMLencrypt] the contents of the Investigation request message using
   the public key of the destination RID system.  The incident number
   would increase as if it were a TraceRequest message in order to
   ensure uniqueness within the system.  The relaying peers would also
   append their Autonomous System (AS) or RID system information as the
   request message was relayed along the web of network providers so
   that the Result message could utilize the same path as the set of
   trust relationships for the return message, thus indicating any
   actions taken.  The request would also be recorded in the state
   tables of both the initiating and destination NP RID systems.  The
   destination NP is responsible for any actions taken as a result of
   the request in adherence to any service level agreements or internal
   policies.  The NP should confirm that the traffic actually originated
   from the suspected system before taking any action and confirm the
ToP   noToC   RFC6045 - Page 35
   reason for the request.  The request may be sent directly to a known
   RID system or routed by the source address of the attack using the
   message destination of RIDPolicy, SourceOfIncident.

   Note: All intermediate parties must be able to view RIDPolicy
   information in order to properly direct RID messages.

4.4.5. Report

Description: This message or document is sent to a RID system to provide a report of a security incident. This message does not require any actions to be taken, except to file the report on the receiving RID system or associated database. The following information is required for Report messages and will be provided through: RID Information: RID Policy RID message type, IncidentID, and destination policy information The following data is recommended if available and can be provided through: IODEF Information: Time Stamps (DetectTime, StartTime, EndTime, ReportTime). Incident Identifier (Incident class, IncidentID). Trace number - used for multiple traces of a single incident; must be noted. Confidence rating of security incident (Impact and Confidence class). System class is used to list both the Source and Destination Information used in the attack. Event, Record, and RecordItem classes to include example packets and other information related to the incident (optional). Standards for encryption and digital signatures [RFC3275]: Digital signature from initiating RID system, passed to all systems receiving the report using XML digital signature.
ToP   noToC   RFC6045 - Page 36
   Security considerations would include the ability to encrypt
   [XMLencrypt] the contents of the Report message using the public key
   of the destination RID system.  Senders of a Report message should
   note that the information may be used to correlate security incident
   information for the purpose of trending, pattern detection, etc., and
   may be shared with other parties unless otherwise agreed upon with
   the receiving RID system.  Therefore, sending parties of a Report
   message may obfuscate or remove destination addresses or other
   sensitive information before sending a Report message.  A Report
   message may be sent either to file an incident report or in response
   to an IncidentQuery, and data sensitivity must be considered in both
   cases.  The NP path information is not necessary for this message, as
   it will be communicated directly between two trusted RID systems.

4.4.6. IncidentQuery

Description: The IncidentQuery message is used to request incident information from a trusted RID system. The request can include the incident number, if known, or detailed information about the incident. If the incident number is known, the Report message containing the incident information can easily be returned to the trusted requestor using automated methods. If an example packet or other unique information is included in the IncidentQuery, the return report may be automated; otherwise, analyst intervention may be required. The following information must be used for an IncidentQuery message and is provided through: RID Information: RID Policy RID message type, IncidentID, and destination policy information IODEF Information (optional): Time Stamps (DetectTime, StartTime, EndTime, ReportTime). Incident Identifier (Incident class, IncidentID). Trace number - used for multiple traces of a single incident; must be noted. Confidence rating of security incident (Impact and Confidence class). System class is used to list both the Source and Destination Information used in the attack.
ToP   noToC   RFC6045 - Page 37
         Event, Record, and RecordItem classes to include example
            packets and other information related to the incident
            (optional).

      Standards for encryption and digital signatures [RFC3275]:

         Digital signature from initiating RID system, passed to all
         systems receiving the IncidentQuery using XML digital
         signature.  If a packet is not included, the signature may be
         based on the RIDPolicy class.

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



(page 37 continued on part 3)

Next Section