Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+   SearchTech-invite World Map Symbol

RFC 6545


Real-time Inter-network Defense (RID)

Part 4 of 4, p. 62 to 84
Prev RFC Part


prevText      Top      Up      ToC       Page 62 
9.  Security Requirements

9.1.  XML Digital Signatures and Encryption

   RID leverages existing security standards and data markings in
   RIDPolicy to achieve the required levels of security for the exchange
   of incident information.  The use of standards includes TLS and the
   XML security features of encryption [XMLencrypt] and digital
   signatures [RFC3275] [XMLsig].  The standards provide clear methods
   to ensure that messages are secure, authenticated, and authorized;
   meet policy and privacy guidelines; and maintain integrity.  XML

Top      Up      ToC       Page 63 
   Signature Best Practices [XMLSigBP] should be referenced by
   implementers for information on improving security to mitigate

   As specified in the relevant sections of this document, the XML
   digital signature [RFC3275] and XML encryption [XMLencrypt] are used
   in the following cases:

   XML Digital Signature

   o  The originator of a Request MUST use a detached signature to sign
      at least one of the original elements contained in the RecordItem
      class to provide authentication to all upstream participants in
      the trace or those involved in the investigation.  All instances
      of RecordItem provided by the originator may be individually
      signed, and additional RecordItem entries by upstream peers in the
      trace or investigation may be signed by the peer adding the data,
      while maintaining the original RecordItem entry(s) and detached
      signature(s) from the original requestor.  It is important to note
      that the data is signed at the RecordItem level.  Since multiple
      RecordItems may exist within an IODEF document and may originate
      from different sources, the signature is applied at the RecordItem
      level to enable the use of an XML detached signature.  Exclusive
      canonicalization [XMLCanon] is REQUIRED for the detached signature
      and not the references, as the XML document generated is then
      included in the RID message within the Signature element of the
      ReportSchema class.  This signature MUST be passed to all
      recipients of the Request message.

   o  If a Request does not include a RecordItem entry, a timestamp MUST
      be used to ensure there is data to be signed for the multi-hop
      authentication use case.  The DateTime element of the iodef:
      RecordData class ([RFC5070], Section 3.19.1) is used for this

   o  For all message types, the full IODEF-RID document MUST be signed
      using an enveloped signature by the sending peer to provide
      authentication and integrity to the receiving RID system.  The
      signature is placed in an instance of the Signature element.

   o  XML Signature Best Practices [XMLSigBP] guidance SHOULD be
      followed to prevent or mitigate security risks.  Examples include
      the recommendation to authenticate a signature prior to processing
      (executing potentially dangerous operations) and the
      recommendation to limit the use of URIs since they may enable
      cross-site scripting attacks or access to local information.

Top      Up      ToC       Page 64 
   o  XML Path Language (XPath) 2.0 [XMLPath] MUST be followed to
      specify the portion of the XML document to be signed.  XPath is
      used to specify a location within an XML document.  Best practice
      recommendations for using XPath [XMLSigBP] SHOULD be referenced to
      reduce the risk of denial-of-service attacks.  The use of XSLT
      transforms MUST be restricted according to security guidance in

   XML Encryption

   o  The IODEF-RID document MAY be encrypted to provide an extra layer
      of security between peers so that not only the message is
      encrypted for transport.  This behavior would be agreed upon
      between peers or a consortium, or determined on a per-message
      basis, depending on security requirements.  It should be noted
      that there are cases for transport where the RIDPolicy class needs
      to be presented in clear text, as detailed in the transport
      document [RFC6546].

   o  A Request, or any other message type that may be relayed through
      RID systems before reaching the intended destination as a result
      of trust relationships, MAY be encrypted specifically for the
      intended recipient.  This may be necessary if the RID network is
      being used for message transfer, the intermediate parties do not
      need to have knowledge of the request contents, and a direct
      communication path does not exist.  In that case, the RIDPolicy
      class is used by intermediate parties and as such, RIDPolicy is
      maintained in clear text.

   o  The action taken in the Result message may be encrypted using the
      key of the request originator.  In that case, the intermediate
      parties can view the RIDPolicy information and know the trace has
      been completed and do not need to see the action.  If the use of
      encryption were limited to sections of the message, the History
      class information would be encrypted.  Otherwise, it is
      RECOMMENDED to encrypt the entire IODEF-RID document and use an
      enveloped signature for the originator of the request.  The
      existence of the Result message for an incident would tell any
      intermediate parties used in the path of the incident
      investigation that the incident handling has been completed.

   o  The iodef:restriction attribute sets expectations for the privacy
      of an incident and is defined in Section 3.2 of RFC 5070.
      Following the guidance for XML encryption in the Security
      Requirements section, the iodef:restriction attribute can be set
      in any of the RID classes to define restrictions and encryption
      requirements for the exchange of incident information.  The
      restriction options enable encryption capabilities for the

Top      Up      ToC       Page 65 
      complete exchange of an IODEF document (including any extensions),
      within specific classes of IODEF, or IODEF extensions, where more
      limited restrictions are desired.  The restriction attribute is
      contained in each of the RID classes and MUST be used in
      accordance with confidentiality expectations for either sections
      of the IODEF document or the complete IODEF document.  Consortiums
      and organizations should consider this guidance when creating
      exchange policies.

   o  Expectations based on how restriction is set:

      *  If restriction is set to 'private', the class or document MUST
         be encrypted for the recipient using XML encryption and the
         public key of the recipient.  See Section 9.3 for a discussion
         on public key infrastructure (PKI) and other security

      *  If restriction is set to 'need-to-know', the class or document
         MUST be encrypted to ensure only those with need-to-know access
         can decrypt the data.  The document can either be encrypted for
         each individual for which access is intended or be encrypted
         with a single group key.  The method used SHOULD adhere to any
         certificate policy and practices agreements between entities
         for the use of RID.  A group key in this instance refers to a
         single key (symmetric) that is used to encrypt the block of
         data.  The users with need-to-know access privileges may be
         given access to the shared key via a secure distribution
         method, for example, providing access to the symmetric key
         encrypted with each of the user's public keys.

      *  If restriction is set to 'public', the class or document MUST
         be sent in clear text.  This setting can be critical if certain
         sections of a document or an entire document are to be shared
         without restrictions.  This provides flexibility within an
         incident to share certain information freely where appropriate.

      *  If restriction is set to 'default', the information can be
         shared according to an information disclosure policy pre-
         arranged by the communicating parties.

   o  Expectations based on placement of the restriction setting:

      *  If restriction is set within one of the RID classes, the
         restriction applies to the entire IODEF document.

      *  If restriction is set within individual IODEF classes, the
         restriction applies to the specific IODEF class and the
         children of that class.

Top      Up      ToC       Page 66 
   The formation of policies is a very important aspect of using a
   messaging system like RID to exchange potentially sensitive
   information.  Many considerations should be involved for peering
   parties, and some guidelines to protect the data, systems, and
   transport are covered in this section.  Policies established should
   provide guidelines for communication methods, security, and fall-back
   procedures.  See Sections 9.4 and 9.5 for additional information on
   consortiums and PKI considerations.

   The security considerations for the storage and exchange of
   information in RID messaging may include adherence to local,
   regional, or national regulations in addition to the obligations to
   protect client information during an investigation.  RIDPolicy is a
   necessary tool for listing the requirements of messages to provide a
   method to categorize data elements for proper handling.  Controls are
   also provided for the sending entity to protect messages from third
   parties through XML encryption.

   RID provides a method to exchange incident-handling requests and
   Report messages between entities.  Administrators have the ability to
   base decisions on the available resources and other factors of their
   network and maintain control of incident investigations within their
   own network.  Thus, RID provides the ability for participating
   networks to manage their own security controls, leveraging the
   information listed in RIDPolicy.

   RID is used to transfer or exchange XML documents in an IODEF format
   or using another IANA-registered format.  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.

9.2.  Message Transport

   A transport specification is defined in a separate document
   [RFC6546].  The specified transport protocols MUST use encryption to
   provide an additional level of security and integrity, while
   supporting mutual authentication through bidirectional certificate
   usage.  Any subsequent transport method defined should take advantage
   of existing standards for ease of implementation and integration of
   RID systems.  Session encryption for the transport of RID messages is
   enforced in the transport specification.  The privacy and security
   considerations are addressed fully in RID to protect sensitive
   portions of documents and to provide a method to authenticate the
   messages.  Therefore, RID messages do not rely on the security
   provided by the transport layer alone.  The encryption requirements
   and considerations for RID messages are discussed in Section 9.1 of
   this document.

Top      Up      ToC       Page 67 
   Consortiums may vary their selected transport mechanisms and thus
   decide upon a mutual protocol to use for transport when communicating
   with peers in a neighboring consortium using RID.  RID systems MUST
   implement and deploy HTTPS as defined in the transport document
   [RFC6546] and optionally MAY support other protocols such as the
   Blocks Extensible Exchange Protocol (BEEP) [RFC3080].  Bindings would
   need to be defined to enable support for other transport protocols.

   Systems used to send authenticated RID messages between networks MUST
   use a secured system and interface to connect to a border network's
   RID systems.  Each connection to a RID system MUST meet the security
   requirements agreed upon through the consortium regulations, peering,
   or SLAs.  The RID system MUST listen for and send RID messages on
   only the designated port, which also MUST be over an encrypted tunnel
   meeting the minimum requirement of algorithms and key lengths
   established by the consortium, peering, or SLA.  The selected
   cryptographic algorithms for symmetric encryption, digital
   signatures, and hash functions MUST meet minimum security levels of
   the times.  The encryption strength MUST adhere to import and export
   regulations of the involved countries for data exchange.

   Out-of-band communications dedicated to SP interaction for RID
   messaging would provide additional security as well as guaranteed
   bandwidth during a denial-of-service attack.  For example, an out-of-
   band channel may consist of logical paths defined over the existing
   network.  Out-of-band communications may not be practical or possible
   between service providers, but provisions should be considered to
   protect the incident management systems used for RID messaging.
   Methods to protect the data transport may also be provided through
   session encryption.

9.3.  Public Key Infrastructure

   It is RECOMMENDED that RID, the XML security functions, and transport
   protocols properly integrate with a PKI managed by the consortium,
   federate PKIs within a consortium, or use a PKI managed by a trusted
   third party.  Entities MAY use shared keys as an alternate solution,
   although this may limit the ability to validate certificates and
   could introduce risk.  For the Internet, a few examples of existing
   efforts that could be leveraged to provide the supporting PKI include
   the Regional Internet Registry's (RIR's) PKI hierarchy, vendor issued
   certificates, or approved issuers of Extended Validation (EV)
   Certificates.  Security and privacy considerations related to
   consortiums are discussed in Sections 9.4 and 9.5.

   The use of PKI between entities or by a consortium SHOULD adhere to
   any applicable certificate policy and practices agreements for the
   use of RID.  [RFC3647] specifies a commonly used format for

Top      Up      ToC       Page 68 
   certificate policy (CP) and certification practices statements (CPS).
   Systems with predefined relationships for RID include those who peer
   directly or through a consortium with agreed-upon appropriate use
   agreements.  The agreements to trust other entities may be based on
   assurance levels that could be determined by a comparison of the CP,
   CPS, and/or RID operating procedures.  The initial comparison of
   policies and the ability to audit controls provide a baseline
   assurance level for entities to form and maintain trust
   relationships.  Trust relationships may also be defined through a
   bridged or hierarchical PKI in which both peers belong.  If shared
   keys or keys issued from a common CA are used, the verification of
   controls to determine the assurance level to trust other entities may
   be limited to the RID policies and operating procedures.

   XML security functions utilized in RID require a trust center such as
   a PKI for the distribution of credentials to provide the necessary
   level of security for this protocol.  Layered transport protocols
   also utilize encryption and rely on a trust center.  Public key
   certificate pairs issued by a trusted Certification Authority (CA)
   MAY be used to provide the necessary level of authentication and
   encryption for the RID protocol.  The CA used for RID messaging must
   be trusted by all involved parties and may take advantage of similar
   efforts, such as the Internet2 federated PKI or the ARIN/RIR effort
   to provide a PKI to service providers.  The PKI used for
   authentication also provides the necessary certificates needed for
   encryption used for the RID transport protocol [RFC6546].

9.3.1.  Authentication

   Hosts receiving a RID message MUST be able to verify that the sender
   of the request is valid and trusted.  Using digital signatures on a
   hash of the RID message with an X.509 version 3 certificate issued by
   a trusted party MUST be used to authenticate the request.  The X.509
   version 3 specifications as well as the digital signature
   specifications and path validation standards set forth in [RFC5280]
   MUST be followed in order to interoperate with a PKI designed for
   similar purposes.  Full path validation verifies the chaining
   relationship to a trusted root and also performs a certificate
   revocation check.  The use of digital signatures in RID XML messages
   MUST follow the World Wide Web Consortium (W3C) recommendations for
   signature syntax and processing when either the XML encryption
   [XMLencrypt] or digital signature [XMLsig] [RFC3275] is used within a

Top      Up      ToC       Page 69 
   It might be helpful to define an extension to the authentication
   scheme that uses attribute certificates [RFC5755] in such a way that
   an application could automatically determine whether human
   intervention is needed to authorize a request; however, the
   specification of such an extension is out of scope for this document.

   The use of pre-shared keys may be considered for authentication at
   the transport layer.  If this option is selected, the specifications
   set forth in "Pre-Shared Key Ciphersuites for Transport Layer
   Security (TLS)" [RFC4279] MUST be followed.  Transport specifications
   are detailed in a separate document [RFC6546].

9.3.2.  Multi-Hop Request Authentication

   The use of multi-hop authentication in a Request is used when a
   Request is sent to multiple entities or SPs in an iterative manner.
   Multi-hop authentication is REQUIRED in Requests that involve
   multiple SPs where Requests are forwarded iteratively through peers.
   Bilateral trust relationships MAY be used between peers; multi-hop
   authentication MUST be used for cases where the originator of a
   message is authenticated several hops into the message flow.

   For practical reasons, SPs may want to prioritize incident-handling
   events based upon the immediate peer for a Request, the originator of
   a request, and the listed Confidence rating for the incident.  In
   order to provide a higher assurance level of the authenticity of a
   Request, the originating RID system is included in the Request along
   with contact information and the information of all RID systems in
   the path the trace has taken.  This information is provided through
   the IODEF EventData class, which nests the list of systems and
   contacts involved in a trace, while setting the category attribute to

   To provide multi-hop authentication, the originating RID system MUST
   include a digital signature in the Request sent to all systems in the
   upstream path.  The digital signature from the RID system is
   performed on the RecordItem class of the IODEF following the XML
   digital signature specifications from W3C [XMLsig] using a detached
   signature.  The signature MUST be passed to all parties that receive
   a Request, and each party MUST be able to perform full path
   validation on the digital signature [RFC5280].  In order to
   accommodate that requirement, the RecordItem data MUST remain
   unchanged as a request is passed along between providers and is the
   only element for which the signature is applied.  If additional
   RecordItems are included in the document at upstream peers, the
   initial RecordItem entry MUST still remain with the detached
   signature.  The subsequent RecordItem elements may be signed by the
   peer adding the incident information for the investigation.  A second

Top      Up      ToC       Page 70 
   benefit to this requirement is that the integrity of the filter used
   is ensured as it is passed to subsequent SPs in the upstream trace of
   the incident.  The trusted PKI also provides the keys used to
   digitally sign the RecordItem class for a Request to meet the
   requirement of authenticating the original request.  Any host in the
   path of the trace should be able to verify the digital signature
   using the trusted PKI.

   In the case in which an enterprise using RID sends a Request to its
   provider, the signature from the enterprise MUST be included in the
   initial request.  The SP may generate a new request to send upstream
   to members of the SP consortium to continue the investigation.  If
   the original request is sent, the originating SP, acting on behalf of
   the enterprise network under attack, MUST also digitally sign, with
   an enveloped signature, the full IODEF document to assure the
   authenticity of the Request.  An SP that offers RID as a service may
   be using its own PKI to secure RID communications between its RID
   system and the attached enterprise networks.  SPs participating in
   the trace MUST be able to determine the authenticity of RID requests.

9.4.  Consortiums and Public Key Infrastructures

   Consortiums are an ideal way to establish a communication web of
   trust for RID messaging.  It should be noted that direct
   relationships may be ideal for some communications, such as those
   between a provider of incident information and a subscriber of the
   incident reports.  The consortium could provide centralized
   resources, such as a PKI, and established guidelines and control
   requirements for use of RID.  The consortium may assist in
   establishing trust relationships between the participating SPs to
   achieve the necessary level of cooperation and experience-sharing
   among the consortium entities.  This may be established through PKI
   certificate policy [RFC3647] reviews to determine the appropriate
   trust levels between organizations or entities.  The consortium may
   also be used for other purposes to better facilitate communication
   among SPs in a common area (Internet, region, government, education,
   private networks, etc.).

   Using a PKI to distribute certificates used by RID systems provides
   an already established method to link trust relationships between
   consortiums that peer with SPs belonging to a separate consortium.
   In other words, consortiums could peer with other consortiums to
   enable communication of RID messages between the participating SPs.
   The PKI along with Memorandums of Agreement could be used to link
   border directories to share public key information in a bridge, a
   hierarchy, or a single cross-certification relationship.

Top      Up      ToC       Page 71 
   Consortiums also need to establish guidelines for each participating
   SP to adhere to.  The RECOMMENDED guidelines include:

   o  Physical and logical practices to protect RID systems;

   o  Network- and application-layer protection for RID systems and

   o  Proper use guidelines for RID systems, messages, and requests; and

   o  A PKI, certificate policy, and certification practices statement
      to provide authentication, integrity, and privacy.

   The functions described for a consortium's role parallel those of a
   PKI federation.  The PKI federations that currently exist are
   responsible for establishing security guidelines and PKI trust
   models.  The trust models are used to support applications to share
   information using trusted methods and protocols.

   A PKI can also provide the same level of security for communication
   between an end entity (enterprise, educational, or government
   customer network) and the SP.

9.5.  Privacy Concerns and System Use Guidelines

   Privacy issues raise many concerns when information-sharing is
   required to achieve the goal of stopping or mitigating the effects of
   a security incident.  The RIDPolicy class is used to automate the
   enforcement of the privacy concerns listed within this document.  The
   privacy and system use concerns for the system communicating RID
   messages and other integrated components include the following:

   Service Provider Concerns:

   o  Privacy of data monitored and/or stored on Intrusion Detection
      Systems (IDSs) for attack detection.

   o  Privacy of data monitored and stored on systems used to trace
      traffic across a single network.

   o  Privacy of incident information stored on incident management
      systems participating in RID communications.

   Customer Attached Networks Participating in RID with SP:

   o  Customer networks may include enterprise, educational, government,
      or other networks attached to an SP participating in RID.
      Customers should review data handling policies to understand how

Top      Up      ToC       Page 72 
      data will be protected by a service provider.  This information
      will enable customers to decide what types of data at what
      sensitivity level can be shared with service providers.  This
      information could be used at the application layer to establish
      sharing profiles for entities and groups; see Section 9.6.

   o  Customers should request information on the security and privacy
      considerations in place by their SP and the consortium of which
      the SP is a member.  Customers should understand if their data
      were to be forwarded, how it might be sanitized and how it will be
      protected.  In advance of sharing data with their SP, customers
      should also understand if limitations can be placed on how it will
      be used.

   o  Customers should be aware that their data can and will be sent to
      other SPs in order to complete a trace unless an agreement stating
      otherwise is made in the service level agreements between the
      customer and SP.  Customers considering privacy options may limit
      the use of this feature if they do not want the data forwarded.

   Parties Involved in the Attack:

   o  Privacy of the identity of a host involved in an attack or any
      indicators of compromise.

   o  Privacy of information such as the source and destination used for
      communication purposes over the monitored or RID-connected

   o  Protection of data from being viewed by intermediate parties in
      the path of an Request request should be considered.

   Consortium Considerations:

   o  System use restrictions for security incident handling within the
      local region's definitions of appropriate traffic.  When
      participating in a consortium, appropriate use guidelines should
      be agreed upon and entered into contracts.

   o  System use prohibiting the consortium's participating SPs from
      inappropriately tracing traffic to locate sources or mitigate
      traffic unlawfully within the jurisdiction or region.

   Inter-Consortium Considerations:

   o  System use between peering consortiums should consider any
      government communication regulations that apply between those two
      regions, such as encryption export and import restrictions.

Top      Up      ToC       Page 73 
   o  System use between consortiums SHOULD NOT request traffic traces
      and actions beyond the scope intended and permitted by law or
      inter-consortium agreements.

   o  System use between consortiums should consider national boundary
      issues and request limits in their appropriate system use
      agreements.  Appropriate use should include restrictions to
      prevent the use of the protocol for limiting or restricting
      traffic that is otherwise permitted within the country in which
      the peering consortium resides.

   The security and privacy considerations listed above are for the
   consortiums, SPs, and enterprises to agree upon.  The agreed-upon
   policies may be facilitated through use of the RIDPolicy class and
   application-layer options.  Some privacy considerations are addressed
   through the RID guidelines for encryption and digital signatures as
   described in Section 9.1.

   RID is useful in determining the true source of an incident that
   traverses multiple networks or to communicate security incidents and
   automate the response.  The information obtained from the
   investigation may determine the identity of the source host or the SP
   used by the source of the traffic.  It should be noted that the trace
   mechanism used across a single SP may also raise privacy concerns for
   the clients of the network.  Methods that may raise concern include
   those that involve storing packets for some length of time in order
   to trace packets after the fact.  Monitoring networks for intrusions
   and for tracing capabilities also raises concerns for potentially
   sensitive valid traffic that may be traversing the monitored network.
   IDSs and single-network tracing are outside of the scope of this
   document, but the concern should be noted and addressed within the
   use guidelines of the network.  Some IDSs and single-network trace
   mechanisms attempt to properly address these issues.  RID is designed
   to provide the information needed by any single-network trace
   mechanism.  The provider's choice of a single trace mechanism depends
   on resources, existing solutions, and local legislation.  Privacy
   concerns in regard to the single-network trace must be dealt with at
   the client-to-SP level and are out of scope for RID messaging.

   The identity of the true source of an attack being traced through RID
   could be sensitive.  The true identity listed in a Result message can
   be protected through the use of encryption [XMLencrypt] enveloping
   the IODEF document and RID Result information, using the public
   encryption key of the originating SP.  Alternatively, the action
   taken may be listed without the identity being revealed to the
   originating SP.  The ultimate goal of the RID communication system is
   to stop or mitigate attack traffic, not to ensure that the identity
   of the attack traffic is known to involved parties.  The SP that

Top      Up      ToC       Page 74 
   identifies the source should deal directly with the involved parties
   and proper authorities in order to determine the guidelines for the
   release of such information, if it is regarded as sensitive.  In some
   situations, systems used in attacks are compromised by an unknown
   source and, in turn, are used to attack other systems.  In that
   situation, the reputation of a business or organization may be at
   stake, and the action taken may be the only additional information
   reported in the Result message to the originating system.  If the
   security incident is a minor incident, such as a zombie system used
   in part of a large-scale DDoS attack, ensuring the system is taken
   off the network until it has been fixed may be sufficient.  The
   decision is left to the system users and consortiums to determine
   appropriate data to be shared given that the goal of the
   specification is to provide the appropriate technical options to
   remain compliant.  The textual descriptions should include details of
   the incident in order to protect the reputation of the unknowing
   attacker and prevent the need for additional investigation.  Local,
   state, or national laws may dictate the appropriate reporting action
   for specific security incidents.

   Privacy becomes an issue whenever sensitive data traverses a network.
   For example, if an attack occurred between a specific source and
   destination, then every SP in the path of the trace becomes aware
   that the cyber attack occurred.  In a targeted attack, it may not be
   desirable that information about two nation states that are battling
   a cyber war would become general knowledge to all intermediate
   parties.  However, it is important to allow the traces to take place
   in order to halt the activity since the health of the networks in the
   path could also be at stake during the attack.  This provides a
   second argument for allowing the Result message to only include an
   action taken and not the identity of the offending host.  In the case
   of a Request or Report, where the originating SP is aware of the SP
   that will receive the request for processing, the free-form text
   areas of the document could be encrypted [XMLencrypt] using the
   public key of the destination SP to ensure that no other SP in the
   path can read the contents.  The encryption is accomplished through
   the W3C [XMLencrypt] specification for encrypting an element.

   In some situations, all network traffic of a nation may be granted
   through a single SP.  In that situation, options must support sending
   Result messages from a downstream peer of that SP.  That option
   provides an additional level of abstraction to hide the identity and
   the SP of the identified source of the traffic.  Legal action may
   override this technical decision after the trace has taken place, but
   that is out of the technical scope of this document.

Top      Up      ToC       Page 75 
   Privacy concerns when using an Request message to request action
   close to the source of valid attack traffic need to be considered.
   Although the intermediate SPs may relay the request if there is no
   direct trust relationship to the closest SP to the source, the
   intermediate SPs do not require the ability to see the contents of
   the packet or the text description field(s) in the request.  This
   message type does not require any action by the intermediate RID
   systems, except to relay the packet to the next SP in the path.
   Therefore, the contents of the request may be encrypted for the
   destination system.  The intermediate SPs only need to know how to
   direct the request to the manager of the ASN in which the source IP
   address belongs.

   Traces must be legitimate security-related incidents and not used for
   purposes such as sabotage or censorship.  An example of such abuse of
   the system includes a request to block or rate-limit legitimate
   traffic to prevent information from being shared between users on the
   Internet (restricting access to online versions of papers) or
   restricting access from a competitor's product in order to sabotage a

   Intra-consortium RID communications raise additional issues,
   especially when the peering consortiums reside in different regions
   or nations.  Request messages and requested actions to mitigate or
   stop traffic must adhere to the appropriate use guidelines and yet
   prevent abuse of the system.  First, the peering consortiums must
   identify the types of traffic that can be traced between the borders
   of the participating SPs of each consortium.  The traffic traced
   should be limited to security-incident-related traffic.  Second, the
   traces permitted within one consortium, if passed to a peering
   consortium, may infringe upon the peering consortium's freedom-of-
   information laws.  An example would be a consortium in one country
   permitting a trace of traffic containing objectionable material,
   outlawed within that country.  The RID trace may be a valid use of
   the system within the confines of that country's network border;
   however, it may not be permitted to continue across network
   boundaries where such content is permitted under law.  By continuing
   the trace in another country's network, the trace and response could
   have the effect of improperly restricting access to data.  A
   continued trace into a second country may break the laws and
   regulations of that nation.  Any such traces MUST cease at the
   country's border.

   The privacy concerns listed in this section address issues among the
   trusted parties involved in a trace within an SP, a RID consortium,
   and peering RID consortiums.  Data used for RID communications must
   also be protected from parties that are not trusted.  This protection
   is provided through the authentication and encryption of documents as

Top      Up      ToC       Page 76 
   they traverse the path of trusted servers and through the local
   security controls in place for the incident management systems.  Each
   RID system MUST perform a bidirectional authentication when sending a
   RID message and use the public encryption key of the upstream or
   downstream peer to send a message or document over the network.  This
   means that the document is decrypted and re-encrypted at each RID
   system via TLS over a transport protocol such as [RFC6546].  The RID
   messages may be decrypted at each RID system in order to properly
   process the request or relay the information.  Today's processing
   power is more than sufficient to handle the minimal burden of
   encrypting and decrypting relatively small typical RID messages.

9.6.  Sharing Profiles and Policies

   The application layer can be used to establish workflows and rulesets
   specific to sharing profiles for entities or consortiums.  The
   profiles can leverage sharing agreements to restrict data types or
   classifications of data that are shared.  The level of information or
   classification of data shared with any entity may be based on
   protection levels offered by the receiving entity and periodic
   validation of those controls.  The profile may also indicate how far
   information can be shared according to the entity and data type.  The
   profile may also indicate whether requests to share data from an
   entity must go directly to that entity.

   In some cases, pre-defined sharing profiles will be possible.  These
   include any use case where an agreement is in place in advance of
   sharing.  Examples may be between clients and SPs, entities such as
   partners, or consortiums.  There may be other cases when sharing
   profiles may not be established in advance, such as an organization
   dealing with an incident who requires assistance from an entity that
   it has not worked with before.  An organization may want to establish
   sharing profiles specific to possible user groups to prepare for
   possible incident scenarios.  The user groups could include business
   partners, industry peers, service providers, experts not part of a
   service provider, law enforcement, or regulatory reporting bodies.

   Workflows to approve transactions may be specific to sharing profiles
   and data types.  Application developers should include capabilities
   to enable these decision points for users of the system.

   Any expectations between entities to preserve the weight and
   admissibility of evidence should be handled at the policy and
   agreement level.  A sharing profile may include notes or an indicator
   for approvers in workflows to reflect if such agreements exist.

Top      Up      ToC       Page 77 
10.  Security Considerations

   RID has many security requirements and considerations built into the
   design of the protocol, several of which are described in the
   Security Requirements section.  For a complete view of security,
   considerations include the availability, confidentiality, and
   integrity concerns for the transport, storage, and exchange of

   Protected tunnels between systems accepting RID communications are
   used to provide confidentiality, integrity, authenticity, and privacy
   for the data at the transport layer.  Encryption and digital
   signatures are also used at the IODEF document level through RID
   options to provide confidentiality, integrity, authenticity, privacy
   and traceability of the document contents at the application layer.
   Trust relationships are based on PKI and the comparison/validation of
   security controls for the incident management systems communicating
   via RID.  Trust levels can be established in cross-certification
   processes where entities compare PKI policies that include the
   specific management and handling of an entity's PKI and certificates
   issued under that policy.  [RFC3647] defines an Internet X.509 Public
   Key Infrastructure Certificate Policy and Certification Practices
   Framework that may be used in the comparison of policies to establish
   trust levels and agreements between entities, an entity and a
   consortium, and consortiums.  The agreements SHOULD consider key
   management practices including the ability to perform path validation
   on certificates [RFC5280], key distribution techniques [RFC2585], and
   Certificate Authority and Registration Authority management

   The agreements between entities SHOULD also include a common
   understanding of the usage of RID security, policy, and privacy
   options discussed in both the Security Requirements and Security
   Considerations sections.  The formality, requirements, and complexity
   of the agreements for the certificate policy, practices, supporting
   infrastructure, and the use of RID options SHOULD be decided by the
   entities or consortiums creating those agreements.

11.  Internationalization Issues

   The Node class identifies a host or network device.  This document
   reuses the definition of Node from the IODEF specification [RFC5070],
   Section 3.16.  However, that document did not clearly specify whether
   a NodeName could be an Internationalized Domain Name (IDN).  RID
   systems MUST treat the NodeName class as a domain name slot
   [RFC5890].  RID systems SHOULD support IDNs in the NodeName class.
   If they do so, the UTF-8 representation of the domain name MUST be
   used, i.e., all of the domain name's labels MUST be U-labels

Top      Up      ToC       Page 78 
   expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be
   used.  An application communicating via RID can convert between
   A-labels and U-labels by using the Punycode encoding [RFC3492] for
   A-labels as described in the protocol specification for
   Internationalized Domain Names in Applications [RFC5891].

12.  IANA Considerations

   This document uses URNs to describe XML namespaces and XML schemas
   [XMLschema] conforming to a registry mechanism described in

   Registration request for the iodef-rid namespace:

      URI: urn:ietf:params:xml:ns:iodef-rid-2.0

      Registrant Contact: IESG.

      XML: None.  Namespace URIs do not represent an XML specification.

   Registration request for the iodef-rid XML schema:

      URI: urn:ietf:params:xml:schema:iodef-rid-2.0

      Registrant Contact: IESG.

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

   The following registry has been created and is now managed by IANA:

      Name of the registry: "XML Schemas Exchanged via RID"

      Namespace details: A registry entry for an XML Schema Transferred
      via RID consists of:

         Schema Name: A short string that represents the schema
         referenced.  This value is for reference only in the table.
         The version of the schema MUST be included in this string to
         allow for multiple versions of the same specification to be in
         the registry.

         Version: The version of the registered XML schema.  The version
         is a string that SHOULD be formatted as numbers separated by a
         '.' (period) character.

Top      Up      ToC       Page 79 
         Namespace: The namespace of the referenced XML schema.  This is
         represented in the RID ReportSchema class in the XMLSchemaID
         attribute as an enumerated value is represented by a URN or

         Specification URI: A URI [RFC3986] from which the registered
         specification can be obtained.  The specification MUST be
         publicly available from this URI.

         Reference: The reference to the document that describes the

      Information that must be provided to assign a new value: The above
      list of information.

      Fields to record in the registry: Schema Name, Version, Namespace,
      Specification URI, Reference

      Initial registry contents: See Section 5.6.1.

      Allocation Policy: Expert Review [RFC5226] and Specification
      Required [RFC5226].

   The Designated Expert is expected to consult with the MILE (Managed
   Incident Lightweight Exchange) working group or its successor if any
   such WG exists (e.g., via email to the working group's mailing list).
   The Designated Expert is expected to retrieve the XML schema
   specification from the provided URI in order to check the public
   availability of the specification and verify the correctness of the
   URI.  An important responsibility of the Designated Expert is to
   ensure that the XML schema is appropriate for use in RID.

   The following registry has been created and is now managed by IANA:

      Name of the registry: "RID Enumeration List"

      The registry is intended to enable enumeration value additions to
      attributes in the iodef-rid XML schema.

      Fields to record in the registry: Attribute Name, Attribute Value,
      Description, Reference

      Initial registry content: none.

      Allocation Policy: Expert Review [RFC5226]

Top      Up      ToC       Page 80 
   The Designated Expert is expected to consult with the MILE (Managed
   Incident Lightweight Exchange) working group or its successor if any
   such WG exists (e.g., via email to the working group's mailing list).
   The Designated Expert is expected to review the request and validate
   the appropriateness of the enumeration for the attribute.  If a
   specification is associated with the request, it MUST be reviewed by
   the Designated Expert.

13.  Summary

   Security incidents have always been difficult to trace as a result of
   spoofed sources, resource limitations, and bandwidth utilization
   problems.  Incident response is often slow even when the IP address
   is known to be valid because of the resources required to notify the
   responsible party of the attack and then to stop or mitigate the
   attack traffic.  Methods to identify and trace attacks near real time
   are essential to thwarting attack attempts.  SPs need policies and
   automated methods to combat the hacker's efforts.  SPs need automated
   monitoring and response capabilities to identify and trace attacks
   quickly without resource-intensive side effects.  Integration with a
   centralized communication system to coordinate the detection,
   tracing, and identification of attack sources on a single network is
   essential.  RID provides a way to integrate SP resources for each
   aspect of attack detection, tracing, and source identification and
   extends the communication capabilities among SPs.  The communication
   is accomplished through the use of flexible IODEF XML-based documents
   passed between incident-handling systems or RID systems.  A Request
   is communicated to an upstream SP and may result in an upstream trace
   or in an action to stop or mitigate the attack traffic.  The messages
   are communicated among peers with security inherent to the RID
   messaging scheme provided through existing standards such as XML
   encryption and digital signatures.  Policy information is carried in
   the RID message itself through the use of the RIDPolicy.  RID
   provides the timely communication among SPs, which is essential for
   incident handling.

14.  References

14.1.  Normative References

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

   [RFC2585]     Housley, R. and P. Hoffman, "Internet X.509 Public Key
                 Infrastructure Operational Protocols: FTP and HTTP",
                 RFC 2585, May 1999.

Top      Up      ToC       Page 81 
   [RFC3023]     Murata, M., St. Laurent, S., and D. Kohn, "XML Media
                 Types", RFC 3023, January 2001.

   [RFC3275]     Eastlake, D., Reagle, J., and D. Solo, "(Extensible
                 Markup Language) XML-Signature Syntax and Processing",
                 RFC 3275, March 2002.

   [RFC3470]     Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines
                 for the Use of Extensible Markup Language (XML)
                 within IETF Protocols", BCP 70, RFC 3470, January 2003.

   [RFC3492]     Costello, A., "Punycode: A Bootstring encoding of
                 Unicode for Internationalized Domain Names in
                 Applications (IDNA)", RFC 3492, March 2003.

   [RFC3688]     Mealling, M., "The IETF XML Registry", BCP 81,
                 RFC 3688, January 2004.

   [RFC4051]     Eastlake, D., "Additional XML Security Uniform Resource
                 Identifiers (URIs)", RFC 4051, April 2005.

   [RFC4279]     Eronen, P. and H. Tschofenig, "Pre-Shared Key
                 Ciphersuites for Transport Layer Security (TLS)",
                 RFC 4279, December 2005.

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

   [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
                 an IANA Considerations Section in RFCs", BCP 26,
                 RFC 5226, May 2008.

   [RFC5280]     Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                 Housley, R., and W. Polk, "Internet X.509 Public Key
                 Infrastructure Certificate and Certificate Revocation
                 List (CRL) Profile", RFC 5280, May 2008.

   [RFC5646]     Phillips, A. and M. Davis, "Tags for Identifying
                 Languages", BCP 47, RFC 5646, September 2009.

   [RFC5755]     Farrell, S., Housley, R., and S. Turner, "An Internet
                 Attribute Certificate Profile for Authorization",
                 RFC 5755, January 2010.

   [RFC5890]     Klensin, J., "Internationalized Domain Names for
                 Applications (IDNA): Definitions and Document
                 Framework", RFC 5890, August 2010.

Top      Up      ToC       Page 82 
   [RFC5891]     Klensin, J., "Internationalized Domain Names in
                 Applications (IDNA): Protocol", RFC 5891, August 2010.

   [RFC6546]     Trammell, B., "Transport of Real-time Inter-network
                 Defense (RID) Messages over HTTP/TLS", RFC 6546,
                 April 2012.

   [XML1.0]      Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C.,
                 and F. Yergeau, "Extensible Markup Language (XML) 1.0",
                 W3C Recommendation XML 1.0, November 2008,

   [XMLCanon]    Boyer, J., "Canonical XML 1.0", W3C Recommendation 1.0,
                 December 2001, <>.

   [XMLPath]     Berglund, A., Boag, S., Chamberlin, D., Fernandez, M.,
                 Kay, M., Robie, J., and J. Simeon, "XML Schema Part 1:
                 Structures", W3C Recommendation Second Edition,
                 December 2010, <>.

   [XMLSigBP]    Hirsch, F. and P. Datta, "XML-Signature Best
                 Practices", W3C Recommendation, August 2011,

   [XMLencrypt]  Imaura, T., Dillaway, B., and E. Simon, "XML Encryption
                 Syntax and Processing", W3C Recommendation,
                 December 2002, <>.

   [XMLschema]   Thompson, H., Beech, D., Maloney, M., and N.
                 Mendelsohn, "XML Schema Part 1: Structures", W3C
                 Recommendation Second Edition, October 2004,

   [XMLsig]      Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E.
                 Simon, "XML-Signature Syntax and Processing", W3C
                 Recommendation Second Edition, June 2008,

14.2.  Informative References

   [RFC1930]     Hawkinson, J. and T. Bates, "Guidelines for creation,
                 selection, and registration of an Autonomous System
                 (AS)", BCP 6, RFC 1930, March 1996.

   [RFC3080]     Rose, M., "The Blocks Extensible Exchange Protocol
                 Core", RFC 3080, March 2001.

Top      Up      ToC       Page 83 
   [RFC3647]     Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
                 Wu, "Internet X.509 Public Key Infrastructure
                 Certificate Policy and Certification Practices
                 Framework", RFC 3647, November 2003.

   [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
                 "Uniform Resource Identifier (URI): Generic Syntax",
                 STD 66, RFC 3986, January 2005.

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

   [RFC6045]     Moriarty, K., "Real-time Inter-network Defense (RID)",
                 RFC 6045, November 2010.

   [RFC6194]     Polk, T., Chen, L., Turner, S., and P. Hoffman,
                 "Security Considerations for the SHA-0 and SHA-1
                 Message-Digest Algorithms", RFC 6194, March 2011.

   [XMLNames]    Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
                 Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C
                 Recommendation , December 2009,

Top      Up      ToC       Page 84 
Appendix A.  Acknowledgements

   Many thanks to colleagues and the Internet community for reviewing
   and commenting on the document as well as providing recommendations
   to improve, simplify, and secure the protocol: Steve Bellovin, David
   Black, Harold Booth, Paul Cichonski, Robert K. Cunningham, Roman
   Danyliw, Yuri Demchenko, Sandra G. Dykes, Stephen Farrell, Katherine
   Goodier, Cynthia D. McLain, Thomas Millar, Jean-Francois Morfin,
   Stephen Northcutt, Damir Rajnovic, Tony Rutkowski, Peter Saint-Andre,
   Jeffrey Schiller, Robert Sparks, William Streilein, Richard Struse,
   Tony Tauber, Brian Trammell, Sean Turner, Iljitsch van Beijnum, and
   David Waltermire.

Author's Address

   Kathleen M. Moriarty
   EMC Corporation
   176 South Street
   Hopkinton, MA
   United States