Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6045


Real-time Inter-network Defense (RID)

Part 4 of 4, p. 60 to 75
Prev RFC Part


prevText      Top      Up      ToC       Page 60 
6.  Security Considerations

   Communication between NPs' RID systems must be protected.  RID has
   many security considerations built into the design of the protocol,
   several of which are described in the following sub-sections.  For a
   complete view of security, considerations need to include the
   availability, confidentiality, and integrity concerns for the
   transport, storage, and exchange of information.

   When considering the transport of RID messages, an out-of-band
   network, either logical or physical, would prevent outside attacks
   against RID communication.  An out-of-band connection would be ideal,
   but not necessarily practical.  Authenticated encrypted tunnels
   between RID systems MUST be used to provide confidentiality,
   integrity, authenticity, and privacy for the data.  Trust
   relationships are based on consortiums and established trust
   relationships of public key infrastructure (PKI) cross-certifications
   of consortiums.  By using RIDPolicy information, TLS, and the XML
   security features of encryption [XMLencrypt] and digital signatures
   [RFC3275], [XMLsig], RID takes advantage of existing security
   standards.  The standards provide clear methods to ensure that
   messages are secure, authenticated, and authorized, and that the
   messages meet policy and privacy guidelines and maintain integrity.

   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 the TraceRequest or Investigation request MUST
      use a detached signature to sign at least one of the original IP
      packets included in the RecordItem class data to provide
      authentication to all upstream participants in the trace of the
      origin.  All IP packets provided by the originator may be signed,
      and additional packets added by upstream peers in the trace may be
      signed by the peer adding the data, while maintaining the IP
      packet and detached signature from the original requestor.  This
      signature MUST be passed to all recipients of the TraceRequest.

   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.

Top      Up      ToC       Page 61 
   XML Encryption

   o  The IODEF/RID document may be encrypted to provide an extra layer
      of security between peers so that the message is not only
      encrypted for the transport, but also while stored.  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 [RFC6046].

   o  An Investigation request, or any other message type that may be
      relayed through RID systems other than the intended destination as
      a result of trust relationships, may be encrypted 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 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, using 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.

   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

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

Top      Up      ToC       Page 62 
   RID provides a method to exchange incident handling request and
   Report messages to peer networks.  Network administrators, who have
   the ability to base the decision on the available resources and other
   factors of their network, 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.

6.1.  Message Transport

   The transport specifications are fully defined in a separate document
   [RFC6046].  The specified transport protocols MUST use encryption to
   provide an additional level of security and integrity, while
   supporting mutual authentication through bi-directional 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 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 are discussed at the beginning of
   Section 6 of this document.

   XML security functions such as the digital signature [RFC3275] and
   encryption [XMLencrypt] provide a standards-based method to encrypt
   and digitally sign RID messages.  RID messages specify system use and
   privacy guidelines through the RIDPolicy class.  A public key
   infrastructure (PKI) provides the base for authentication and
   authorization, encryption, and digital signatures to establish trust
   relationships between members of a RID consortium or a peering

   XML security functions such as the digital signature [RFC3275] and
   encryption [XMLencrypt] can be used within the contents of the
   message for privacy and security in cases for which certain elements
   must remain encrypted or signed as they traverse the path of a trace.
   For example, the digital signature on a TraceRequest can be used to
   verify the identity of the trace originator.  The use of the XML
   security features in RID messaging is in accordance with the
   specifications for the IODEF model; however, the use requirements may
   differ since RID also incorporates communication of security incident

Top      Up      ToC       Page 63 
6.2.  Message Delivery Protocol - Integrity and Authentication

   The RID protocol must be able to guarantee delivery and meet the
   necessary security requirements of a state-of-the-art protocol.  In
   order to guarantee delivery, TCP should be considered as the
   underlying protocol within the current network standard practices.

   Security considerations must include the integrity, authentication,
   privacy, and authorization of the messages sent between RID
   communication systems or IHSs.  The communication between RID systems
   must be authenticated and encrypted to ensure the integrity of the
   messages and the RID systems involved in the trace.  Another concern
   that needs to be addressed is authentication for a request that
   traverses multiple networks.  In this scenario, systems in the path
   of the multi-hop TraceRequest need to authorize a trace from not only
   their neighbor network, but also from the initiating RID system as
   discussed in Section 6.4.  Several methods can be used to ensure
   integrity and privacy of the communication.

   The transport mechanism selected MUST follow the defined transport
   protocol [RFC6046] when using RID messaging to ensure consistency
   among the peers.  Consortiums may vary their selected transport
   mechanisms and thus must 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 [RFC6046] and optionally support other
   protocols such as the Blocks Extensible Exchange Protocol (BEEP).
   RID, the XML security functions, and transport protocols must
   properly integrate with a public key infrastructure (PKI) managed by
   the consortium or one managed by a trusted entity.  For the Internet,
   an example of an existing effort that could be leveraged to provide
   the supporting PKI could be the American Registry for Internet
   Numbers (ARIN) and the Regional Internet Registry's (RIR's) PKI
   hierarchy.  Security and privacy considerations related to
   consortiums are discussed in Sections 6.5 and 6.6.

6.3.  Transport Communication

   Out-of-band communications dedicated to NP 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 possible between all
   network providers, but should be considered to protect the network
   management systems used for RID messaging.  Methods to protect the
   data transport may also be provided through session encryption.

Top      Up      ToC       Page 64 
   In order to address the integrity and authenticity of messages,
   transport encryption MUST be used to secure the traffic sent between
   RID systems.  Systems with predefined relationships for RID would
   include those who peer within a consortium with agreed-upon
   appropriate use regulations and for peering consortiums.  Trust
   relationships may also be defined through a bridged or hierarchical
   PKI in which both peers belong.

   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 only listen for and send RID messages
   on 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.

6.4.  Authentication of RID Protocol

   In order to ensure the authenticity of the RID messages, a message
   authentication scheme is used to secure the protocol.  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 network providers.  The PKI used for authentication would also
   provide the necessary certificates needed for encryption used for the
   RID transport protocol [RFC6046].

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

   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

Top      Up      ToC       Page 65 
   specifications and path validation standards set forth in [RFC5280]
   MUST be followed in order to interoperate with a PKI designed for
   similar purposes.  The IODEF specification MUST be followed for
   digital signatures to provide the authentication and integrity
   aspects required for secure messaging between network providers.  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 document.  Transport
   specifications are detailed in a separate document [RFC6046].

   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.

6.4.1.  Multi-Hop TraceRequest Authentication

   Bilateral trust relations between network providers ensure the
   authenticity of requests for TraceRequests from immediate peers in
   the web of networks formed to provide the traceback capability.  A
   network provider several hops into the path of the RID trace must
   trust the information from its own trust relationships as well as the
   previous trust relationships in the downstream path.  For practical
   reasons, the NPs may want to prioritize incident handling events
   based upon the immediate peer for a TraceRequest, the originator, and
   the listed Confidence rating for the incident.  In order to provide a
   higher assurance level of the authenticity of the TraceRequest, the
   originating RID system is included in the TraceRequest 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 nesting the list of systems and contacts
   involved in a trace, while setting the category attribute to

   A second measure MUST be taken to ensure the identity of the
   originating RID system.  The originating RID system MUST include a
   digital signature in the TraceRequest 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 TraceRequest, and each party MUST be able to perform full path
   validation on the digital signature.  Full path validation verifies
   the chaining relationship to a trusted root and also performs a
   certificate revocation check.  In order to accommodate that
   requirement, the IP packet in the RecordItem data MUST remain

Top      Up      ToC       Page 66 
   unchanged as a request is passed along between providers and is the
   only element for which the signature is applied.  If additional
   packets are included in the document at upstream peers, the initial
   packet MUST still remain with the detached signature.  The subsequent
   packets may be signed by the peer adding the incident information for
   the investigation.  A second benefit to this requirement is that the
   integrity of the filter used is ensured as it is passed to subsequent
   NPs in the upstream trace of the packet.  The trusted PKI also
   provides the keys used to digitally sign the RecordItem class for
   TraceRequests 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 network using RID sends a
   TraceRequest to its provider, the signature from the enterprise
   network MUST be included in the initial request.  The NP may generate
   a new request to send upstream to members of the NP consortium to
   continue the trace.  If the original request is sent, the originating
   NP, 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 TraceRequest.  An NP 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.  NPs participating in the trace MUST be able to determine
   the authenticity of RID requests.

6.5.  Consortiums and Public Key Infrastructures

   Consortiums of NPs are an ideal way to establish a communication web
   of trust for RID messaging.  The consortium could provide centralized
   resources, such as a PKI, and established guidelines for use of the
   RID protocol.  The consortium would also assist in establishing trust
   relationships between the participating NPs 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 NPs in a common
   area (Internet, region, government, education, private networks,

   Using a PKI to distribute certificates used by RID systems provides
   an already established method to link trust relationships between NPs
   of consortiums that would peer with NPs belonging to a separate
   consortium.  In other words, consortiums could peer with other
   consortiums to enable communication of RID messages between the

Top      Up      ToC       Page 67 
   participating NPs.  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.

   Consortiums also need to establish guidelines for each participating
   NP 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 to provide authentication, integrity, and privacy.

   The functions described for a consortium's role would parallel that
   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 NP.  The PKI may be a subordinate CA or in
   the CA hierarchy from the NP's consortium to establish the trust
   relationships necessary as the request is made to other connected

6.6.  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 that MUST be addressed in the RID
   system and other integrated components include the following:

   Network Provider Concerns:

   o  Privacy of data monitored and/or stored on IDSs for attack

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

Top      Up      ToC       Page 68 
   Customer Attached Networks Participating in RID with NP:

   o  Customer networks may include an enterprise, educational,
      government, or other attached networks to an NP participating in
      RID and MUST be made fully aware of the security and privacy
      considerations for using RID.

   o  Customers MUST know the security and privacy considerations in
      place by their NP and the consortium of which the NP is a member.

   o  Customers MUST understand that their data can and will be sent to
      other NPs in order to complete a trace unless an agreement stating
      otherwise is made in the service level agreements between the
      customer and NP.

   Parties Involved in the Attack:

   o  Privacy of the identity of a host involved in an attack.

   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 Investigation request MUST be considered.

   Consortium Considerations:

   o  System use restricted to security incident handling within the
      local region's definitions of appropriate traffic for the network
      monitored and linked via RID in a single consortium also abiding
      by the consortium's use guidelines.

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

   Inter-Consortium Considerations:

   o  System use between peering consortiums MUST also adhere to any
      government communication regulations that apply between those two
      regions, such as encryption export and import restrictions.  This
      may include consortiums that are categorized as
      "BetweenConsortiums" or "AcrossNationalBoundaries".

   o  System use between consortiums MUST NOT request traffic traces and
      actions beyond the scope intended and permitted by law or
      inter-consortium agreements.

Top      Up      ToC       Page 69 
   o  System use between consortiums classified as
      "AcrossNationalBoundaries" MUST respect national boundary issues
      and limit requests to appropriate system use and not to achieve
      their own agenda to limit or restrict traffic that is otherwise
      permitted within the country in which the peering consortium

   The security and privacy considerations listed above are for the
   consortiums, NPs, and enterprises to agree upon.  The agreed-upon
   policies may be facilitated through use of the RIDPolicy class.  Some
   privacy considerations are addressed through the RID guidelines for
   encryption and digital signatures as described at the beginning of
   Section 6.

   RID is useful in determining the true source of a packet that
   traverses multiple networks or to communicate security incidents and
   automate the response.  The information obtained from the trace may
   determine the identity of the source host or the network provider
   used by the source of the traffic.  It should be noted that the trace
   mechanism used across a single-network provider 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-NP level and are out of
   scope for RID messaging.

   The identity of the true source of an attack packet 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 NP.  Alternatively, the
   action taken may be listed without the identity being revealed to the
   originating NP.  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 NP that
   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

Top      Up      ToC       Page 70 
   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 network provider in the path of the trace
   would become 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 an Investigation request, where the originating
   NP is aware of the NP 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 NP to ensure
   that no other NP in the path can read the contents.  The encryption
   would be 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 network provider.  In that situation, options must
   support sending Result messages from a downstream peer of that
   network provider.  That option provides an additional level of
   abstraction to hide the identity and the NP 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.

   Privacy concerns when using an Investigation request to request
   action close to the source of valid attack traffic needs to be
   considered.  Although the intermediate NPs may relay the request if

Top      Up      ToC       Page 71 
   there is no direct trust relationship to the closest NP to the
   source, the intermediate NPs 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 NP
   in the path.  Therefore, the contents of the request may be encrypted
   for the destination system.  The intermediate NPs would 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 would include 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.  TraceRequests and requested actions to mitigate 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 NPs 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 NP, 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
   they traverse the path of trusted servers.  Each RID system MUST
   perform a bi-directional 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

Top      Up      ToC       Page 72 
   document is decrypted and re-encrypted at each RID system via TLS
   over the transport protocol [RFC6046].  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.

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

   Registrant Contact: See the "Author's Address" section of this

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

   Registrant Contact: See the "Author's Address" section of this

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

8.  Summary

   Security incidents have always been difficult to trace as a result of
   the 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.  Network providers need
   policies and automated methods to combat the hacker's efforts.  NPs
   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 NP resources
   for each aspect of attack detection, tracing, and source

Top      Up      ToC       Page 73 
   identification and extends the communication capabilities among
   network providers.  The communication is accomplished through the use
   of flexible IODEF XML-based documents passed between IHSs or RID
   systems.  A TraceRequest or Investigation request is communicated to
   an upstream NP 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 NPs, which is essential for incident handling.

9.  References

9.1.  Normative References

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

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

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

   [RFC4279]      Eronen, P., Ed., and H. Tschofenig, Ed., "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.

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

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

   [RFC6046]      Moriarty, K. and B. Trammell, "Transport of Real-Time
                  Inter-Network Defense (RID) Messages," RFC 6046,
                  November 2010.

Top      Up      ToC       Page 74 
   [XML1.0]       "Extensible Markup Language (XML) 1.0 (Second
                  Edition)".  W3C Recommendation.  T. Bray, E. Maler, J.
                  Paoli, and C.M. Sperberg-McQueen.  October 2000.

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

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

   [XMLschema]    "XML Schema".  E. Van der Vlist.  O'Reilly.  2002.

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

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

   [RFC2827]      Ferguson, P. and D. Senie, "Network Ingress Filtering:
                  Defeating Denial of Service Attacks which employ IP
                  Source Address Spoofing", BCP 38, RFC 2827, May 2000.

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

   [RFC3917]      Quittek, J., Zseby, T., Claise, B., and S. Zander,
                  "Requirements for IP Flow Information Export (IPFIX)",
                  RFC 3917, October 2004.

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

   [IPtrace]      "Advanced and Authenticated Marking Schemes for IP
                  Traceback".  D. Song and A. Perrig.  IEEE INFOCOM

Top      Up      ToC       Page 75 
   [HASH-IPtrace] "Hash-Based IP Traceback".  A. Snoeren, C. Partridge,
                  L. Sanchez, C. Jones, F. Tchakountio, S. Kent, and W.
                  Strayer.  SIGCOMM'01.  August 2001.

   [ICMPtrace]    Bellovin, S., Leech, M., and T. Taylor, "ICMP
                  Traceback Messages", Work in Progress, February 2003.

   [NTWK-IPtrace] "Practical network support for IP traceback".  S.
                  Savage, D. Wetherall, A. Karlin, and T. Anderson.
                  SIGCOMM'00.  August 2000.

   [DoS]          "Trends in Denial of Service Attack Technology".  K.
                  Houle, G. Weaver, N. Long, and R. Thomas.  CERT
                  Coordination Center.  October 2001.


   Many thanks to coworkers and the Internet community for reviewing and
   commenting on the document as well as providing recommendations to
   simplify and secure the protocol: Robert K. Cunningham, Ph.D, Cynthia
   D. McLain, Dr. William Streilein, Iljitsch van Beijnum, Steve
   Bellovin, Yuri Demchenko, Jean-Francois Morfin, Stephen Northcutt,
   Jeffrey Schiller, Brian Trammell, Roman Danyliw, Tony Tauber, and
   Sandra G. Dykes, Ph.D.

Sponsor Information

   This work was sponsored by the Air Force under Air Force Contract
   FA8721-05-C-0002, while working at MIT Lincoln Laboratory.

   "Opinions, interpretations, conclusions, and recommendations are
   those of the author and are not necessarily endorsed by the United
   States Government".

Author's Address

   Kathleen M. Moriarty
   RSA, The Security Division of EMC
   174 Middlesex Turnpike
   Bedford, MA  01730