tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6045


Pages: 75
Top     in Index     Prev     Next
 

Real-time Inter-network Defense (RID)

Part 1 of 4, p. 1 to 12
None       Next RFC Part

Obsoleted by:    6545


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                       K. Moriarty
Request for Comments: 6045                                           EMC
Category: Informational                                    November 2010
ISSN: 2070-1721


                 Real-time Inter-network Defense (RID)

Abstract

   Network security incidents, such as system compromises, worms,
   viruses, phishing incidents, and denial of service, typically result
   in the loss of service, data, and resources both human and system.
   Network providers and Computer Security Incident Response Teams need
   to be equipped and ready to assist in communicating and tracing
   security incidents with tools and procedures in place before the
   occurrence of an attack.  Real-time Inter-network Defense (RID)
   outlines a proactive inter-network communication method to facilitate
   sharing incident handling data while integrating existing detection,
   tracing, source identification, and mitigation mechanisms for a
   complete incident handling solution.  Combining these capabilities in
   a communication system provides a way to achieve higher security
   levels on networks.  Policy guidelines for handling incidents are
   recommended and can be agreed upon by a consortium using the security
   recommendations and considerations.

   RID has found use within the international research communities, but
   has not been widely adopted in other sectors.  This publication
   provides the specification to those communities that have adopted it,
   and communities currently considering solutions for real-time inter-
   network defense.  The specification may also accelerate development
   of solutions where different transports or message formats are
   required by leveraging the data elements and structures specified
   here.

Page 2 
Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6045.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................4
      1.1. Normative and Informative ..................................6
      1.2. Terminology ................................................6
      1.3. Attack Types and RID Messaging .............................6
   2. RID Integration with Network Provider Technologies ..............8
   3. Characteristics of Attacks ......................................9
      3.1. Integrating Trace Approaches ..............................11
      3.2. Superset of Packet Information for Traces .................11
   4. Communication between Network Providers ........................12
      4.1. Inter-Network Provider RID Messaging ......................14
      4.2. RID Network Topology ......................................16
      4.3. Message Formats ...........................................17
           4.3.1. RID Data Types .....................................17
                  4.3.1.1. Boolean ...................................17
           4.3.2. RID Messages and Transport .........................18
           4.3.3. IODEF-RID Schema ...................................19
                  4.3.3.1. RequestStatus Class .......................21
                  4.3.3.2. IncidentSource Class ......................23
                  4.3.3.3. RIDPolicy Class ...........................24
           4.3.4. RID Namespace ......................................29
      4.4. RID Messages ..............................................29
           4.4.1. TraceRequest .......................................29
           4.4.2. RequestAuthorization ...............................30
           4.4.3. Result .............................................31
           4.4.4. Investigation Request ..............................33
           4.4.5. Report .............................................35
           4.4.6. IncidentQuery ......................................36
      4.5. RID Communication Exchanges ...............................37
           4.5.1. Upstream Trace Communication Flow ..................39
                  4.5.1.1. RID TraceRequest Example ..................40
                  4.5.1.2. RequestAuthorization Message Example ......44
                  4.5.1.3. Result Message Example ....................44
           4.5.2. Investigation Request Communication Flow ...........47
                  4.5.2.1. Investigation Request Example .............48
                  4.5.2.2. RequestAuthorization Message Example ......50
           4.5.3. Report Communication ...............................51
                  4.5.3.1. Report Example ............................51
           4.5.4. IncidentQuery Communication Flow ...................54
                  4.5.4.1. IncidentQuery Example .....................54
   5. RID Schema Definition ..........................................55

Top      ToC       Page 4 
   6. Security Considerations ........................................60
      6.1. Message Transport .........................................62
      6.2. Message Delivery Protocol - Integrity and Authentication ..63
      6.3. Transport Communication ...................................63
      6.4. Authentication of RID Protocol ............................64
           6.4.1. Multi-Hop TraceRequest Authentication ..............65
      6.5. Consortiums and Public Key Infrastructures ................66
      6.6. Privacy Concerns and System Use Guidelines ................67
   7. IANA Considerations ............................................72
   8. Summary ........................................................72
   9. References .....................................................73
      9.1. Normative References ......................................73
      9.2. Informative References ....................................74
   Acknowledgements ..................................................75
   Sponsor Information ...............................................75

1.  Introduction

   Incident handling involves the detection, reporting, identification,
   and mitigation of an attack, whether it be a system compromise,
   socially engineered phishing attack, or a denial-of-service (DoS)
   attack.  When an attack is detected, the response may include simply
   filing a report, notification to the source of the attack, a request
   for mitigation, or the request to locate the source.  One of the more
   difficult cases is that in which the source of an attack is unknown,
   requiring the ability to trace the attack traffic iteratively
   upstream through the network for the possibility of any further
   actions to take place.  In cases when accurate records of an active
   session between the victim system and the attacker or source system
   are available, the source is easy to identify.  The problem of
   tracing incidents becomes more difficult when the source is obscured
   or spoofed, logs are deleted, and the number of sources is
   overwhelming.  If the source of an attack is known or identified, it
   may be desirable to request actions be taken to stop or mitigate the
   effects of the attack.

   Current approaches to mitigating the effects of security incidents
   are aimed at identifying and filtering or rate-limiting packets from
   attackers who seek to hide the origin of their attack by source
   address spoofing from multiple locations.  Measures can be taken at
   network provider (NP) edge routers providing ingress, egress, and
   broadcast filtering as a recommended best practice in [RFC2827].

   Network providers have devised solutions, in-house or commercial, to
   trace attacks across their backbone infrastructure to either identify
   the source on their network or on the next upstream network in the
   path to the source.  Techniques such as collecting packets as traffic
   traverses the network have been implemented to provide the capability

Top      ToC       Page 5 
   to trace attack traffic after an incident has occurred.  Other
   methods use packet-marking techniques or flow-based traffic analysis
   to trace traffic across the network in real time.  The single-network
   trace mechanisms use similar information across the individual
   networks to trace traffic.  Problems may arise when an attempt is
   made to have a trace continued through the next upstream network
   since the trace mechanism and management may vary.

   In the case in which the traffic traverses multiple networks, there
   is currently no established communication mechanism for continuing
   the trace.  If the next upstream network has been identified, a phone
   call might be placed to contact the network administrators in an
   attempt to have them continue the trace.  A communication mechanism
   is needed to facilitate the transfer of information to continue
   traces accurately and efficiently to upstream networks.  The
   communication mechanism described in this paper, Real-time Inter-
   network Defense (RID), takes into consideration the information
   needed by various single-network trace implementations and the
   requirement for network providers to decide if a TraceRequest should
   be permitted to continue.  The data in RID messages is represented in
   an Extensible Markup Language (XML) [XML1.0] document using the
   Incident Object Description Exchange Format (IODEF) and RID.  By
   following this model, integration with other aspects of the network
   for incident handling is simplified.  Finally, methods are
   incorporated into the communication system to indicate what actions
   need to be taken closest to the source in order to halt or mitigate
   the effects of the attack at hand.  RID is intended to provide a
   method to communicate the relevant information between Computer
   Security Incident Response Teams (CSIRTs) while being compatible with
   a variety of existing and possible future detection tracing and
   response approaches.

   At this point, RID has found use within the international research
   communities, but has not been widely adopted in other sectors.  This
   publication provides the specification to those communities that have
   adopted it, and communities currently considering solutions for real-
   time inter-network defense.  The specification may also accelerate
   development of solutions where different transports or message
   formats are required by leveraging the data elements and structures
   specified here.

   Security and privacy considerations are of high concern since
   potentially sensitive information may be passed through RID messages.
   RID messaging takes advantage of XML security and privacy policy
   information set in the RID schema.  The RID schema acts as an XML
   envelope to support the communication of IODEF documents for
   exchanging or tracing information regarding security incidents.  RID
   messages are encapsulated for transport, which is defined in a

Top      ToC       Page 6 
   separate document [RFC6046].  The authentication, integrity, and
   authorization features each layer has to offer are used to achieve a
   necessary level of security.

1.1.  Normative and Informative

   The XML schema [XMLschema] and transport requirements contained in
   this document are normative; all other information provided is
   intended as informative.  More specifically, the following sections
   of this document are intended as informative: Sections 1, 2, and 3;
   and the sub-sections of 4 including the introduction to 4, 4.1, and
   4.2.  The following sections of this document are normative: The
   sub-sections of 4 including 4.3, 4.4, and 4.5; Section 5; and
   Section 6.

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.3.  Attack Types and RID Messaging

   RID messaging is intended for use in coordinating incident handling
   to locate the source of an attack and stop or mitigate the effects of
   the attack.  The attack types include system or network compromises,
   denial-of-service attacks, or other malicious network traffic.  RID
   is essentially a messaging system coordinating attack detection,
   tracing mechanisms, and the incident handling responses to locate the
   source of traffic.  If a source address is spoofed, a more detailed
   trace of a packet (RID TraceRequest) would be required to locate the
   true source.  If the source address is valid, the incident handling
   may only involve the use of routing information to determine what
   network provider is closest to the source (RID Investigation request)
   and can assist with the remediation.  The type of RID message used to
   locate a source is determined by the validity of the source address.
   RID message types are discussed in Section 4.3.

   DoS [DoS] attacks are characterized by large amounts of traffic
   destined for particular Internet locations and can originate from a
   single or multiple sources.  An attack from multiple sources is known
   as a distributed denial-of-service (DDoS) attack.  Because DDoS
   attacks can originate from multiple sources, tracing such an attack
   can be extremely difficult or nearly impossible.  Many TraceRequests
   may be required to accomplish the task and may require the use of
   dedicated network resources to communicate incident handling
   information to prevent a DoS attack against the RID system and
   network used for tracing and remediation.  Provisions are suggested

Top      ToC       Page 7 
   to reduce the load and prevent the same trace from occurring twice on
   a single-network backbone discussed in Section 4 on communication
   between NPs.  The attacks can be launched from systems across the
   Internet unified in their efforts or by compromised systems enlisted
   as "zombies" that are controlled by servers, thereby providing
   anonymity to the controlling server of the attack.  This scenario may
   require multiple RID traces, one to locate the zombies and an
   additional one to locate the controlling server.  DDoS attacks do not
   necessarily spoof the source of an attack since there are a large
   number of source addresses, which make it difficult to trace anyway.
   DDoS attacks can also originate from a single system or a subset of
   systems that spoof the source address in packet headers in order to
   mask the identity of the attack source.  In this case, an iterative
   trace through the upstream networks in the path of the attack traffic
   may be required.

   RID traces may also be used to locate a system used in an attack to
   compromise another system.  Compromising a system can be accomplished
   through one of many attack vectors, using various techniques from a
   remote host or through local privilege escalation attempts.  The
   attack may exploit a system or application level vulnerability that
   may be the result of a design flaw or a configuration issue.  A
   compromised system, as described above, can be used to later attack
   other systems.  A single RID Investigation request may be used in
   this case since it is probable that the source address is valid.
   Identifying the sources of system compromises may be difficult since
   an attacker may access the compromised system from various sources.
   The attacker may also take measures to hide their tracks by deleting
   log files or by accessing the system through a series of compromised
   hosts.  Iterative RID traces may be required for each of the
   compromised systems used to obscure the source of the attack.  If the
   source address is valid, an Investigation request may be used in lieu
   of a full RID TraceRequest.

   Once an attack has been reported, CSIRTs may want to query other
   CSIRTs if they have detected an attack or simply report that one has
   taken place.  The Report message can be used to file a report without
   an action taken, and an IncidentQuery can be used to ask if an attack
   has been seen by another CSIRT.

   System compromises may result from other security incident types such
   as worms, Trojans, or viruses.  It is often the case that an incident
   goes unreported even if valid source address information is available
   because it is difficult to take any action to mitigate or stop the
   attack.  Incident handling is a difficult task for an NP and even at
   some client locations due to network size and resource limitations.

Top      ToC       Page 8 
2.  RID Integration with Network Provider Technologies

   For the purpose of this document, a network provider (NP) shall be
   defined as a backbone infrastructure manager of a network.  The
   network provider's Computer Security Incident Response Team shall be
   referred to as the CSIRT.  The backbone may be that of an
   organization providing network (Internet or private) access to
   commercial, personal, government, or educational institutions, or the
   backbone provider of the connected network.  The connected network
   provider is an extension meant to include Intranet and Extranet
   providers as well as instances such as a business or educational
   institute's private network.

   NPs typically manage and monitor their networks through a centralized
   network management system (NMS).  The acronym "NMS" will be used to
   generically represent management systems on a network used for the
   management of network resources.  An incident handling system (IHS)
   is used to communicate RID messages and may be integrated with an NMS
   as well as other components of the network.  The components of the
   network that may be integrated through the RID messaging system
   include attack or event detection, network tracing, and network
   devices to stop the effects of an attack.

   The detection of security incidents may rely on manual reporting,
   automated intrusion detection tools, and variations in traffic types
   or levels on a network.  Intrusion detection systems (IDSs) may be
   integrated into the IHS to create IODEF documents or RID messages to
   facilitate security incident handling.  Detection of a security
   incident is outside the scope of this paper; however, it should be
   possible to integrate detection methods with RID messaging.

   RID messaging in an IHS is intended to be flexible in order to
   accommodate various traceback systems currently in use as well as
   those that may evolve with technology.  RID is intended to
   communicate the necessary information needed by a trace mechanism to
   the next upstream NP in the path of a trace.  Therefore, a RID
   message must carry the superset of data required for all tracing
   systems.  If possible, the trace may need to inspect packets to
   determine a pattern, which could assist reverse path identification.
   This may be accomplished by inspecting packet header information such
   as the source and destination IP addresses, ports, and protocol flags
   to determine if there is a way to distinguish the packets being
   traced from other packets.  A description of the incident along with
   any available automated trace data should trigger an alert to the
   NP's CSIRT for further investigation.  The various technologies used
   to trace traffic across a network are described in Section 3.1.

Top      ToC       Page 9 
   Another area of integration is the ability to mitigate or stop attack
   traffic once a source has been located.  Any automated solution
   should consider the possible side effects to the network.  A change
   control process or a central point for configuration management might
   be used to ensure that the security of the network and necessary
   functionality are maintained and that equipment configuration changes
   are documented.  Automated solutions may depend upon the capabilities
   and current configuration management solutions on a particular
   network.  The solutions may be based on HTTP/TLS (Transport Layer
   Security) or an appropriate protocol defined in the transport
   specification.

3.  Characteristics of Attacks

   The goal of tracing a security incident may be to identify the source
   or to find a point on the network as close to the origin of the
   incident as possible.  A security incident may be defined as a system
   compromise, a worm or Trojan infection, or a single- or multiple-
   source denial-of-service attack.  Incident tracing can be used to
   identify the source(s) of an attack in order to halt or mitigate the
   undesired behavior.  The communication system, RID, described in this
   paper can be used to trace any type of security incident and allows
   for actions to be taken when the source of the attack or a point
   closer to the source is known or has been identified.  The purpose of
   tracing an attack would be to halt or mitigate the effects of the
   attack through methods such as filtering or rate-limiting the traffic
   close to the source or by using methods such as taking the host or
   network offline.  Care must also be taken to ensure that the system
   is not abused and to use proper analysis in determining if attack
   traffic is, in fact, attack traffic at each NP along the path of a
   trace.

   Tracing security incidents can be a difficult task since attackers go
   to great lengths to obscure their identity.  In the case of a
   security incident, the true source might be identified through an
   existing established connection to the attacker's point of origin.
   However, the attacker may not connect to the compromised system for a
   long period of time after the initial compromise or may access the
   system through a series of compromised hosts spread across the
   network.  Other methods of obscuring the source may include targeting
   the host with the same attack from multiple sources using both valid
   and spoofed source addresses.  This tactic can be used to compromise
   a machine and leave the difficult task of locating the true origin
   for the administrators.  Security incidents, including DDoS attacks,
   can be difficult or nearly impossible to trace because of the nature
   of the attack.  Some of the difficulties in tracing attacks include
   the following:

Top      ToC       Page 10 
   o  the attack originates from multiple sources;

   o  the attack may include various types of traffic meant to consume
      server resources, such as a SYN flood attack without a significant
      increase in bandwidth utilization;

   o  the type of traffic could include valid destination services,
      which cannot be blocked since they are essential services to
      business, such as DNS servers at an NP or HTTP requests sent to an
      organization connected to the Internet;

   o  the attack may utilize varying types of packets including TCP,
      UDP, ICMP, or other IP protocols;

   o  the attack may be from "zombies", which then require additional
      searches to locate a controlling server as the true origin of the
      attack;

   o  the attack may use a very small number of packets from any
      particular source, thus making a trace after the fact nearly
      impossible.

   If the source(s) of the attack cannot be determined from IP address
   information or tracing the increased bandwidth utilization, it may be
   possible to trace the traffic based on the type of packets seen by
   the client.  In the case of packets with spoofed source addresses, it
   is no longer a trivial task to identify the source of an attack.  In
   the case of an attack using valid source addresses, methods such as
   the traceroute utility can be used to fairly accurately identify the
   path of the traffic between the source and destination of an attack.
   If the true source has been identified, actions should be taken to
   halt or mitigate the effects of the attack by reporting the incident
   to the NP or the upstream NP closest to the source.  In the case of a
   spoofed source address, other methods can be used to trace back to
   the source of an attack.  The methods include packet filtering,
   packet hash comparisons, IP marking techniques, ICMP traceback, and
   packet flow analysis.  As in the case of attack detection, tracing
   traffic across a single network is a function that can be used with
   RID in order to provide the network with the ability to trace spoofed
   traffic to the source, while RID provides all the necessary
   information to accommodate the approach used on any single network to
   accomplish this task.  RID can also be used to report attack traffic
   close to the source where the IP address used was determined to be
   valid or simply to report that an incident occurred.

Top      ToC       Page 11 
3.1.  Integrating Trace Approaches

   There have been many separate research initiatives to solve the
   problem of tracing upstream packets to detect the true source of
   attack traffic.  Upstream packet tracing is currently confined to the
   borders of a network or an NP's network.  Traces require access to
   network equipment and resources, thus potentially limiting a trace to
   a specific network.  Once a trace reaches the boundaries of a
   network, the network manager or NP adjacent in the upstream trace
   must be contacted in order to continue the trace.  NPs have been
   working on individual solutions to accomplish upstream tracing within
   their own network environments.  The tracing mechanisms implemented
   thus far have included proprietary or custom solutions requiring
   specific information such as IP packet header data, hash values of
   the attack packets, or marked packets.  Hash values are used to
   compare a packet against a database of packets that have passed
   through the network as described in "Hash-Based IP Traceback"
   [HASH-IPtrace].  Other research solutions involve marking packets as
   explained in "ICMP Traceback Messages" [ICMPtrace], "Practical
   network support for IP traceback" [NTWK-IPtrace], the IP Flow
   Information eXport (IPFIX) protocol [RFC3917], and IP marking
   [IPtrace].  The single-network traceback solutions were considered in
   developing RID to determine the information needed to accomplish an
   inter-network trace where different solutions may be in place.

3.2.  Superset of Packet Information for Traces

   In order for network traffic to be traced across a network, an
   example packet from the attack must be sent along with the
   TraceRequest or Investigation request.  According to the research for
   hash-based IP traceback, all of the non-changing fields of an IP
   header along with 8 bytes of payload are required to provide enough
   information to uniquely trace the path of a packet.  The non-changing
   fields of the packet header and the 8 bytes of payload are the
   superset of data required by most single-network tracing systems
   used; limiting the shared data to the superset of the packet header
   and 8 bytes of payload prevents the need for sharing potentially
   sensitive information that may be contained in the data portion of a
   packet.

   The RecordItem class in the IODEF is used to store a hexadecimal
   formatted packet including all packet header information plus 8 bytes
   of payload, or the entire packet contents.  The above trace systems
   do not require a full packet, but it may be useful in some cases, so
   the option is given to allow a full packet to be included in the data
   model.

Top      ToC       Page 12 
   If a subset of a packet is used, the research presented in "Hash-
   Based IP Traceback" [HASH-IPtrace] provides guidelines to establish a
   minimum requirement for distinguishing packets.  The full packet and
   content SHOULD be provided, but the minimum requirement MUST be
   provided.  The research from [HASH-IPtrace] found that the first 28
   invariant bytes of a packet (masked IP header plus the first 8 bytes
   of the payload) are sufficient to differentiate almost all non-
   identical IPv4 packets.  RID requires the first 28 invariant bytes of
   an IPv4 packet in order to perform a trace.  RID requires the first
   48 invariant bytes for an IPv6 packet in order to distinguish the
   packet in a trace.  Reference [HASH-IPtrace] for additional details.

   The input mechanism for packets to be traced should be flexible to
   allow intrusion detection systems or packet sniffers to provide the
   information.  The system creating the RID message should also use the
   packet information to populate the Incident class information in
   order to avoid human error and also allow a system administrator to
   override the automatically populated information.



(page 12 continued on part 2)

Next RFC Part