INTERNET-DRAFT Kathleen M. Moriarty draft-moriarty-ddos-rid-05.txt MIT Lincoln Laboratory Expires: March 3, 2004 September 3, 2003 Distributed Denial of Service Incident Handling: Real-Time Inter-Network Defense Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Network security incidents such as Denial of Service (DoS), system compromises, worms, and viruses typically result in the loss of service, data, and resources both human and system. Security incidents can be detrimental to the health of the network as a whole. Network Providers (NP) need to be equipped and ready to assist in tracing security incidents with tools and procedures in place before the occurrence of an attack. This paper proposes a proactive inter-network communication method to integrate existing tracing mechanisms across NP boundaries to identify the source(s) of an attack. The various methods implemented to trace attacks must be coordinated both on the NPs network as well as provide a communication mechanism across network borders. It is imperative that NPs have quick communication methods defined to enable neighboring NPs to assist in tracking a security incident across the Internet. This proposal makes use of current tracing practices for traffic and performance management, which could be extended for security incident handling. Policy guidelines for handling these incidents are recommended and can be used by NPs and extended to their clients in conjunction with the technical recommendations. Internet-Draft September 3, 2003 TABLE OF CONTENTS Status of this Memo ................................................ 1 Abstract ........................................................... 1 1.0 Introduction ............................................... 3 1.1 Overview of Attack Types ................................... 4 2.0 Recommended Network Provider (NP) Technologies ............. 5 3.0 Characteristics of Attacks ................................. 6 3.1 Tracing a Distributed attack ............................... 8 3.2 Trace Approaches ........................................... 9 3.2.1 Trace approach via Traffic Flow Analysis ............. 9 3.2.2 Trace Approach via Hash-Based IP Traceback ........... 10 3.3 Correlating Collected Data ................................. 11 4.0 Communication Between Network Providers .................... 12 4.1 Inter-Network Provider RID-DoS Messaging ................... 13 4.2 Message Formats ............................................ 15 4.2.1 Trace Request ........................................ 15 4.2.2 Trace Authorization Message .......................... 16 4.2.3 Source Found Message ................................. 17 4.2.4 Relay Message Request ................................ 18 4.2.5 Example Upstream Trace ............................... 20 4.3 Message Structure: ......................................... 21 4.4 Message Delivery Protocol - Integrity and Authentication ... 23 4.4.1 Transport Communication .............................. 24 4.4.2 Authentication of RID-DoS protocol ................... 25 4.4.3 Authentication Considerations for a Multi-hop Trace Request 26 4.4.4 Privacy Concerns ..................................... 26 5.0 Security Considerations .................................... 28 6.0 Summary .................................................... 29 7.0 References ................................................. 30 8.1 Acknowledgements ........................................... 32 8.2 Author Information ......................................... 32 Moriarty Expires: March 3, 2004 [Page 2] Internet-Draft September 3, 2003 1.0 Introduction Incident handling involves the identification of the source of an attack, whether it be a system compromise or a denial of service attack. In order to identify the source of an attack, there must be a way to trace the attack traffic iteratively upstream through the network to the source. In cases where an active session between the compromised system and the attacker or source system is available, the source is easy to identify as in the case of attacks where the source address was not spoofed and sufficient evidence is left behind. The problem of tracing incidents becomes more difficult when the source is obscured or spoofed, logs are deleted, and the number of sources are overwhelming. Current approaches to mitigating the effects of security incidents, DoS, and DDoS attacks 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) border routers providing ingress, egress, and broadcast filtering as a recommended best practice in RFC2827. These filters ensure that traffic leaving and entering client locations contains valid source and destination addresses. Network providers have devised solutions to trace attacks across their backbone infrastructure to either identify the source on their network or the next upstream network in the path to the source. Many of the single network tracing mechanisms have been developed as in-house solutions and are specific to the network that is traced. Techniques such as collecting packets as traffic traverses the network have been implemented to provide the capability to trace attack traffic after an incident has occurred. Other methods use 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, but encounter problems when they attempt to have a trace continued through the next upstream network. In the case where the traffic traverses multiple networks, there is currently no established communication mechanism to provide the ability to continue the trace. If the next upstream network has been identified, a phone call might be placed to contact the network administrators in hopes to have them continue the trace. A communication mechanism is needed to facilitate the transfer of information needed in order 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 needs of network providers to have the ability to decide if a trace request should be permitted to continue. Finally, methods are incorporated into the communication system to indicate what actions were taken to cease Moriarty Expires: March 3, 2004 [Page 3] Internet-Draft September 3, 2003 or mitigate the effects of the attack at hand. RID is intended to provide a method to communicate the relevant information between NPs while being compatible with a variety of existing and possible future tracing approaches. 1.1 Overview of Attack Types The CERT Coordination Center published a paper in October, 2001 entitled, "Trends in Denial of Service Attack Technology"[6]. The paper outlined the behavior of Denial of Service attacks of both single-source and multiple-source origins. Denial of Service (DoS) attacks attempt to consume bandwidth, processing power, or system resources for the purposes of denying use by normal users. Bandwidth-based attacks flood systems with TCP, UDP or ICMP packets. Bandwidth or processing power based attacks may use variations on these packets, such as altering the source address, port numbers, or TCP options. Many attacks types including various DoS attacks and system compromise use tactics such as altering port numbers to enable packets to bypass packet filters. Other approaches are to use packets, which are targeting valid services hosted by the network since they must be permitted and the attack traffic cannot be deciphered from valid network traffic. In bandwidth based DoS attacks, tactics including altering the source address as in the case of an ICMP attack where packets are sent through a site with the IP direct broadcast option enabled on the site's router. The IP directed broadcast would amplify the number of packets sent to the victim, thus flooding the network and consuming bandwidth. Another type of DoS attack is aimed at consuming system resources, as in the SYN flood attack. A SYN flood attack is a TCP attack where the initiator of the attack begins the TCP handshake sequence by sending a SYN packet to the destination server of the attack with a spoofed source address. The server responds with an acknowledgement of the SYN packet, but the response packet is sent to the spoofed source address, which does not accept the unexpected acknowledgment packet. This leaves the connection open on the server and consumes system resources. There are a limited number of connections a server can maintain, and once this limit is reached, valid connections are denied. This is just one example of a class of attacks targeting a single system or service to prevent valid traffic from accessing the system. 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 attack (DDoS). Because DDoS attacks can originate from multiple sources, tracing such an attack can be Moriarty Expires: March 3, 2004 [Page 4] Internet-Draft September 3, 2003 extremely difficult or nearly impossible. These 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. 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. Compromising a system can be accomplished through one of many attack vectors, using various techniques from a remote host or through a 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. The subsequent attacks may be targeted systems or an attempt to recruit zombies to later be used in DoS or DDoS attacks. Identifying the sources of system compromises may also 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. System compromises may occur from valid source addresses, which may also be the case for other security incidents such as worms, Trojans, or viruses. It is often the case that an incident goes unreported even if valid source address information is available. Incident handling is a difficult task for a NP and even at some client locations due to the size of a network and resource limitations. 2.0 Recommended Network Provider (NP) Technologies For the purpose of this document, a network provider (NP) shall be defined as a backbone infrastructure manager of a network. The backbone may be that of an organization providing network (Internet or private) access to commercial, personal, government, and 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, (etc.) private network. NPs typically manage and monitor their networks through a centralized network management system (NMS). This system usually performs trend analysis for bandwidth utilization and reports communication problems. As a part of the bandwidth trend analysis performed, denial of service traffic or unusually unexpected increases in bandwidth could also be reported. With the capability of seeing the entire network under management, the NMS could be utilized to trace to the origin of network traffic within its own Moriarty Expires: March 3, 2004 [Page 5] Internet-Draft September 3, 2003 network. NPs could become proactive in handling denial of service attacks through the use of tools already in existence on their networks. If trend analysis is not already being performed for bandwidth utilization, this may require the use of an additional server to perform this function. Such a server would need to account for traffic redirection events resulting in bandwidth fluctuations due to networking problems in other areas of an NP's backbone. Ideally, this system would have the ability to perform a trend analysis on the network to determine if there was an unusually large increase in traffic without explanation, such as a network event elsewhere on the backbone. Client events, such as the launch of a new web site or streaming video of a noteworthy news event should be programmable exceptions to the alert. Once it can be determined that the event may be significant, a trace back for the source of the increased traffic should be performed through analysis on the neighboring connections on the network. 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 them from other packets. A description of the incident along with any available automated trace data should trigger an alert to the NPs security team for further investigation. The proactive monitoring for bandwidth related attacks could use trending analysis as a guideline to determine acceptable levels of traffic across the network. Unexplained and extended spikes in traffic would be a signal that a DoS attack may be in progress. Resource related attacks would be more difficult to detect because the effects of resource exhaustion are not readily apparent in network traffic. Methods such as trending the packet size of traffic to and from networks may be an indicator of this type of attack. For example, if there is a large increase in small packets sent to and from a network, that may be an indicator of a SYN flood attack. TCP connections begin with small packets, but the session data over the established connection may be a mixture of large and small packets. A change in the size of packets to or from a network or host may be an indicator of a DoS attack using different types of traffic than normally seen in the monitored network. The detection of other security incidents may rely more on reporting rather than automated detection tools, except perhaps in the case of some worms, which can result in large increases of traffic. Detection of a security incident is outside the scope of this paper, however it should be possible to integrate detection methods with RID messaging. 3.0 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 Moriarty Expires: March 3, 2004 [Page 6] Internet-Draft September 3, 2003 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 cease or mitigate the undesired behavior. The communication system, RID-DoS, 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 has been identified. The purpose of tracing an attack would be to cease or mitigate the affects 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. 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 due to an existing established connection to the attackers 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 a difficult task of locating the true origin for the administrators. DDoS attacks are also difficult or nearly impossible to trace because of the nature of the attack. Some of the difficulties in tracing these attacks include: 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 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 Moriarty Expires: March 3, 2004 [Page 7] Internet-Draft September 3, 2003 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 cease 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 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, 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 networked ability to trace spoofed traffic to the source, while RID is flexible to the approach used on any single network to accomplish this task. 3.1 Tracing a Distributed attack Tracing a DDoS attack is a very difficult problem. Since DDoS attacks may involve multiple sources with spoofed addresses, there may only be a small amount of traffic from each of the originating hosts. This makes it difficult to trace back to the sources. The sources may also alternate the type of traffic and the master may vary the sources from within the pool of sources launching the attack. Because of the dynamic nature of the DDos attack, immediate action would need to be taken to have any hope of locating the origin(s) of the attack with a near real-time trace. In order to identify a DoS attack or DDoS, a client may notify its NP that it is currently under attack. Automated methods might include statistical traffic analysis, which looks for unexpected fluctuations in bandwidth or in the size and types of packets sent between networks or hosts. There is on-going research in the area of detecting DoS and DDoS, and any effective techniques could be integrated with the tracing techniques described in this paper. Current research approaches range from methods that detect backscatter traffic [3], using a data structure for bandwidth attack detection [4], and monitoring congestion through packet retransmission information [5]. Another detection method may include monitoring any changes in the size of packets sent to and from a network. For example, if a site that normally receives small packets and replies with large packets experiences a change in traffic pattern such as the sending and receiving of large amounts of either small or large packets, this could indicate a DoS attack. Once an attack has been detected through traffic analysis and bandwidth usage statistics, traces would have to quickly identify the various sources of the attack. Once an attack is detected, a generalized approach to tracing back connections might include the inspection of packet header information such as the destination IP address and any distinguishing header values of the traffic seen by the site during the attack. Moriarty Expires: March 3, 2004 [Page 8] Internet-Draft September 3, 2003 If a trace can identify the sources of a distributed attack, blocking the sources at the NP level close to the attacker could be an immediate action to stopping the attack. In the case of a DDoS attack, further information may be obtained from the attacking computers as to the controller of the attack sending the 'zombies' control information to carry out the attack. This additional trace is beyond the scope of this paper, but may use additional tracing mechanisms such as sniffing the network to locate the controllers of the attack. Finding a faster and more efficient way to trace multiple sources of an attack is essential to combating DDoS attacks. The ability to quickly relay and act upon the trace information gathered is imperative to stopping DDoS attacks. Tracing multiple attack paths can also cause additional stress on the network and does not scale well. 3.2 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 a NP's network. Traces require access to network equipment and resources, which limit 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 environment. The tracing mechanisms implemented thus far have included proprietary solutions requiring specific information such as IP packet header data or hash values of the attack packets in the case of the 'Hash Based IP Traceback'[8]. Other research solutions involve marking packets as explained in 'ICMP Traceback Messages'[10] and 'Practical Support for IP Traceback' [9]. The following sections outline some available solutions for implementing traceback within the confines of a network managed by a single entity. Later in the paper the focus will be on the information needed to accomplish the trace and to make possible the Inter-NP communication specified. 3.2.1 Trace approach via Traffic Flow Analysis Traffic flow analysis is used to monitor individual network traffic streams, such as a single TCP session beginning with the SYN packet and ending with the final FIN ACK in a session. There have been a few efforts to standardize flow analysis for network management, one through the traffic flow management MIB and another through NetFlow. The 'Traffic Flow Management' RFC [RFC2720] was Designed to provide management information such as behavior models, Capacity planning, network performance, quality of service, and Attribution of network usage to system administrators. NetFlow from Cisco [7] provides similar capabilities to the traffic flow Moriarty Expires: March 3, 2004 [Page 9] Internet-Draft September 3, 2003 mib, except that it is specific to IP traffic and has already been implemented for traffic management in Cisco equipment. Although NetFlow was developed by Cisco, it is also an open standard. The flow analysis in both implementations can monitor with a capture filter on source and destination addresses, the number of packets and the count of bytes in each flow, the originating interface of the traffic, and the upstream peer information. The upstream peer information is essential to tracing a spoofed packet back to the true origin. There are several differences in the implementations and the monitor and capture capabilities of the two flow analysis implementations. NetFlow collects all packets and maintains the following information on packet flows for later analysis: O Source and destination IP address O Source and destination TCP/User Datagram Protocol (UDP) ports O Type of service (ToS) O Packet and byte counts O Start and end timestamps O Input and output interface numbers O TCP flags and encapsulated protocol (TCP/UDP) O Routing information (next-hop address, source autonomous system (AS) number, destination AS number, source prefix mask, destination prefix mask) Based on the information listed above, a spoofed packet can be traced upstream through a network to either identify the true source or the upstream peer. Various flow based solutions have been developed and implemented for use on a single backbone based on flow analysis and the RID messaging described later must be able to support existing and future solutions to trace attacks across multiple networks. The AS number listed associated with a source IP address is only valid if the source IP address is valid. The AS number in this case cannot be trusted, however it may be trusted in the iterative trace and from the actual address information gathered from that trace. 3.2.2 Trace Approach via Hash-Based IP Traceback BBN implemented a trace back solution, which collects hashes of IP packets across the network. The Hash-Based IP Traceback was designed specifically to trace attack traffic and achieve the following objectives O trace attacks after specific flows of the attack have completed O reduce storage requirements needed to save traceable packet data O provide a secure method to store packet captures on the Internet Hash-based IP traceback is another solution to provide the ability to trace attack traffic. By capturing all packets across the Moriarty Expires: March 3, 2004 [Page 10] Internet-Draft September 3, 2003 network and saving hash values for the IP header information that does not get altered as it traverses the network, attacks can be traced after the fact. Since hashes of IP header information are stored instead of the actual header information, privacy concerns are no longer an issue as might be the case with packet captures across the Internet. If a system used to store the packet captures was compromised, the data could not be used to identify which entities are 'talking' to each other on the Internet. BBN also considered how traces could be performed across a single network, for example an NP's backbone. The solution divides the network up into regions, each with its own collection station. The trace might be initiated at a particular collection station where data for a specific router is stored. When the collection station traces through its database for the matches of particular hashes of IP packets, it follows the trace through the network equipment for its own region. The collection station then determines which bordering region was the next upstream source of the attack and the trace is continued at the next collection agent. The trace continues until the source is identified or a neighboring network is identified as the upstream source of the attack. The upstream network must then be notified in some way in order to continue the trace. The upstream network will require the IP packet information in order to continue the trace. The upstream provider will want to look at its network and resources and decide if it would like to initiate a trace across their network. A possible solution for communicating the upstream trace request between bordering networks is discussed later with the RID protocol. The trace solution implemented across the single network is independent of the messaging system and would have a greater impact on the effectiveness and efficiency of a trace across the network. 3.3 Correlating Collected Data Integrating this extended monitoring capability into the NMS would allow for the formulation of network behavior statistics and thus the detection of anomalous usage behavior. The network trend analysis capability could be used to detect unexplained spikes in bandwidth usage on the network as a whole, as well as, on specific networks in an NP backbone or servers on a local network. The NMS would be aware of network outages that may result in traffic being redirected through alternate paths of the network, which would be an example of an explained spike in bandwidth. A client connected to an NP may be hosting an event, such as a web cast. An abundance of valid connection attempts can also result in bringing a web site down, exhausting either bandwidth or system resources. If an NP was aware of such an event, it could set higher thresholds for bandwidth usage alerting during that period of time Moriarty Expires: March 3, 2004 [Page 11] Internet-Draft September 3, 2003 to prevent false alarms. The anomalies could be used as methods of detecting Denial of Service attacks, worms or other security incidents. 4.0 Communication Between Network Providers Expediting the communication between NPs is essential when responding to a security related incident, which may cross network access points, (Internet backbones) between providers. As a result of the urgency involved in this inter-NP security incident communication, there must be an effective system in place to facilitate the interaction. This communication policy or system should involve multiple means of communication to avoid a single point of failure. Email may be the best way to transfer information about the incident, packet traces, etc. However, email may not be received in a timely fashion or be acted upon with the same urgency as a phone call or other communication system. Each NP should dedicate a phone number to reach a member of their security incident response team. The phone number could be dedicated to inter-NP incident communications and must be a hotline that provides a 24x7 live response. The phone line should reach someone who would have either the authority and expertise or the means to expedite the necessary action to investigate the incident. This may be a difficult policy to establish at smaller NPs due to resource limitations, so another solution may be necessary. An outside group may be able to serve this function given the necessary access to the NPs network. The outside resource should be able to mitigate or alleviate the financial and experience resource limitations. A technical solution to trace traffic across a single NP may include home grown or commercial systems in which RID messaging must accommodate the input requirements of. The network management systems used on the NPs backbone to coordinate the trace across the single network requires a method to accept and process RID messages and relay trace requests to the system as well as wait for responses from the system to continue the RID request process as appropriate. In this scenario, each NP would maintain their own management station used for network monitoring and analysis. An alternative for NPs lacking sufficient resources may be to have a neutral third party with access to the NPs network resources that could be used to perform the trace functions. This could be a function of a central organization operating as a computer response team for the Internet as a whole. The first method described prevents the need to permit access to other network's equipment through the use of a standard messaging mechanism to enable Network Management Systems (NMS) to communicate trace information to neighboring networks' NMSs. The third party mentioned above may be used in this technical solution to assist in facilitating traces through smaller NPs. The messaging mechanism Moriarty Expires: March 3, 2004 [Page 12] Internet-Draft September 3, 2003 may be a logical or physical out-of-band network to ensure the communication is secure and unaffected by the state of the network under attack. The two management methods would accommodate the needs of larger NPs to maintain full management of their network and the third party option could be available to smaller NPs who lack the necessary human resources to perform a trace. The first method enables the individual NPs to involve their network operations staff to authorize the continuance of a trace through their network via a notification and alerting system. The out-of-band logical solution for messaging may be permanent virtual circuits configured with a small amount of bandwidth dedicated to NMS communications between NPs. The network used for the communication, out-of-band or protected channels discussed later, would be direct communication links to relay RID-DoS messages, accepting only this messaging protocol. The communication links would be direct connections between network peers, which would form a larger web or iterative network that correlates to the paths available over the larger web of networks. The maintenance of the individual links will be the responsibility of the two network peers hosting the link. Contact information, IP addresses of network management systems and other information must be coordinated between the bilateral peers as with any changes to the involved systems. The security, configuration, and confidence rating schemes of the peering NMSs for bilateral RID messaging peers must be negotiated by peers and must meet certain overall requirements of the fully connected network, (Internet, government, education, etc.) through the peering agreements. RID messaging established with clients of an NP may be negotiated in a contract as part of a value added service or through a service level agreements. Further discussion is beyond the scope of this document and may be more appropriately handled in network peering or service level agreements. Procedures for incident handling need to be established and well known by anyone that may be involved in incident response. The procedures should also contain contact information for internal escalation procedures, as well as external assistance groups such as CERT, GIAC, and the FBI. 4.1 Inter-Network Provider RID-DoS Messaging In order to implement a messaging mechanism between NMS systems, a standard protocol and format is required to ensure inter- operability between vendors. The messages would have several requirements in order to be meaningful as they traversed multiple networks. The Real-Time Inter-Network Defense against DoS (RID DoS) provides the framework necessary for communication between networks involved in the trace back and mitigation of a DoS attack. There are several types of messages that would be needed to facilitate a trace across multiple networks. Another type of message would be used to leverage the bi-lateral relationships to Moriarty Expires: March 3, 2004 [Page 13] Internet-Draft September 3, 2003 relay a request to mitigate or stop potentially malicious or spurious valid traffic close to the source, which would not involve the use of single network trace systems. A message sent between NMS systems to request the continuance of a trace or to relay a request to stop traffic at the source through a bordering network would require the information enumerated below. 1. Enough information to enable the network administrators to make a decision about the importance of continuing the trace. 2. The filter or IP packet hash information needed to carry out the trace. 3. Contact information of the origin of the trace. The contact information could be provided through the autonomous system number [RFC1930] whois information listed in the Registry for Internet Numbers databases. 4. Network path information to help prevent any routing loops through the network from perpetuating a trace. If an NMS receives a trace request containing its own information in the path, the trace must cease and the NMS should generate an alert to inform the network operations staff that a routing loop exists. 5. A unique identifier for a single attack should be used to correlate traces to multiple sources in a DDoS attack. Use of the communication network and the RID-Dos protocol must be for pre-approved, authorized purposes only. It is the responsibility of each participating party to adhere to guidelines set forth in both a global use policy for this system as well as one established though the peering agreements for each bilateral peer. The purpose of such policies are to avoid abuse of the system and shall be developed by a consortium of participating entities. The global policy may be dependent on the domain in which it operates under, for example, a government network or a commercial network such as the Internet would adhere to different guidelines to address the individual concerns. Privacy issues must be considered in public networks such as the Internet. Moriarty Expires: March 3, 2004 [Page 14] Internet-Draft September 3, 2003 4.2 Message Formats The following section describes the four message types used to facilitate the communication between NPs tracing an incident. The messages would be generated and received on Network Management Systems on the NPs network. The fields in the messages are described following the message descriptions. 4.2.1 Trace Request Description: This message is sent to the Network Management Station next in the upstream trace. Message Type 1 Time Stamp Incident Identifier ASN for originating NP Incident number based on incremental tracking Trace number - used for multiple traces of a single incident Confidence rating of detected Denial of Service attack (0-100) Level Meaning ______________________ 1 Low probability the detected attack occurred 100 High probability the detected attack occurred Filter used to trace incident across the network Number of NMS in the path listed in message (count of items in following list) Path information of Network Management Systems used in the trace Autonomous System Number and NMS IP address of Next Network Autonomous System Number and NMS IP address Current Network ... Autonomous System Number and NMS IP address of Originating Network [Text field for any additional information on justification for trace] Digital signature of 32-bit hash of packet filter from initiating NMS, passed to all systems in upstream trace A DDoS attack can have many sources resulting in multiple traces to locate the sources of the attack. It may be valid to continue multiple traces for a single attack. The path information would enable the administrators to determine if the exact trace had already passed through a single network. Moriarty Expires: March 3, 2004 [Page 15] Internet-Draft September 3, 2003 4.2.2 Trace Authorization Message Description: This message is sent to the initiating NMS from the next upstream NP's NMS to provide information on the trace status in the current network. Message Type 2 Time Stamp Incident Identifier ASN for originating NP Incident number based on incremental tracking Trace number - used for multiple traces of a single incident Confidence rating of detected Denial of Service attack (0-100) Filter used to trace incident across the network Trace Status 0 Pending 1 Approved 2 Denied Number of NMS in the path listed in message (count of items in following list) Path information of Network Management Systems used in the trace Autonomous System Number and NMS IP address of Next Network Autonomous System Number and NMS IP address Current Network ... Autonomous System Number and NMS IP address of Originating Network A message is sent back to the NMS that initiated the trace as a notification means. This message verifies that the next NMS in the path has received the message from the previous NMS in the path. This message also verifies that the trace is now continuing, stopped or pending in the next upstream network in the path of the trace. The pending status would be automatically generated after a 2-minute timeout without system predefined or administrator action taken to approve or disapprove the trace continuance. Moriarty Expires: March 3, 2004 [Page 16] Internet-Draft September 3, 2003 4.2.3 Source Found Message Description: This message indicates that the source of the attack in this trace was located and is sent to the initiating NMS through the network of out-of-band NMS systems in the path of the trace. Message Type 3 Time Stamp Incident Identifier ASN for originating NP Incident number based on incremental tracking Trace number - used for multiple traces of a single incident Action Taken (multiple selections permitted) Bit Meaning ______________________________________________ 0 No action at this time 1 Filter at upstream peer ingress point 2 Network segment blocked 3 Host (IP Address) blocked from Internet access 4 Protocol port used in attack blocked 5 Alert generated 6 Site notified 7 Other Number of contacts listed in packet Value should always be 1 for this message type Autonomous System Number and NMS IP address of the system, which located the source of the trace Digital signature of source NP for authenticity of source found Message, signature of hash of all fields of message Starting with the time stamp and including the AS number and NMS IP address of the system sending the found message. [True Source address information of attack] [Text field for any additional information for the action taken] A message sent back to initiating NMS to notify the originating network administrators that the source has been located. The actual source information may or may not be included depending on the policy of the network in which the client or host is attached. Any action taken by the NP to act upon the discovery of the source of a trace should be included. The NP may be able to automate the adjustment of filters at their border router to block outbound access for the machine(s) discovered as a part of the attack. The filters may be as comprehensive as to block all Internet access until the host has taken the appropriate action to resolve any security issues or to rate limit the ingress traffic as close to the source as possible. Security and privacy considerations discussed later must be taken into account with source found messages. Moriarty Expires: March 3, 2004 [Page 17] Internet-Draft September 3, 2003 4.2.4 Relay Message Request Description: This message type is used when the source of the traffic is believed to be valid. The purpose of the relay message request is to leverage the existing bi-lateral peer relationships in order to notify the network provider closest to the source of the valid traffic of some event that has occurred, which may be a security related incident. Message Type 4 Time Stamp Incident Identifier ASN for originating NP Incident number based on incremental tracking Trace number - used for multiple traces of a single incident Confidence rating of Security Incident (0-100) Level Meaning ______________________ 1 Low probability the detected attack occurred 100 High probability the detected attack occurred Filter used to trace incident across the network Number of NMS in the path listed in message (count of items in following list) Path information of Network Management Systems used in the trace Autonomous System Number and NMS IP address of Source IP Autonomous System Number and NMS IP address of Next Network Autonomous System Number and NMS IP address Current Network ... Autonomous System Number and NMS IP address of Originating Network [Text field for any additional information on justification for relay message request] Digital signature of 32-bit hash of packet filter from initiating NMS, passed to all systems in upstream trace Security considerations would include the ability to encrypt the contents of the relay message request using the public key of the destination network provider. The incident number would increase as if it were a trace request message in order to ensure uniqueness within the system. The relaying peers would also append their AS information as the request message was relayed along the web of network providers so that the source found message could utilize the same path as set of trust relationships for the return message, which would indicate any actions taken. The request would also be recorded in both the state table of the initiating and destination NP NMS. The destination NP would be responsible for any actions taken as a result of the request in adherence to any service level agreements or internal policies. The NP should confirm the traffic actually originated from the suspected system before taking any action and confirm the reason for the request. Moriarty Expires: March 3, 2004 [Page 18] Internet-Draft September 3, 2003 Note: The AS number of the source IP address is listed as the first AS in the path information for the NMSs. The last relay packet sent to the source AS will include the same path information twice. The AS information is necessary in order to direct the message appropriately to the closest NP to the source of the traffic. In the case of message type 4, the filter information may be encrypted, so the relaying NMSs may have no other way to determine how to direct the packets. Moriarty Expires: March 3, 2004 [Page 19] Internet-Draft September 3, 2003 4.2.5 Example Upstream Trace The diagram below outlines the RID-DOS communication between NMS systems on different networks tracing an attack. Attack Dest NP-1 NP-2 NP-3 Attack Src 1. Attack | Attack reported | detected 2. Initiate trace 3. Locate origin through upstream NP. 4. o---Msg-Type-1------> 5. Trace Initiated 6. <-----Msg-Type-2----o 7. Locate origin through upstream NP. 8. o---Msg-Type-1---> 9. Trace Initiated 10. <------------Msg-Type-2------------o 11. Locate attack source on network X 12. <------------Msg-Type-3------------o The NP who detected the attack initiates the trace. The attack is traced to the source or the next upstream NP. This process continues until the trace identifies the source of the attack. Any type 2 and 3 messages must pass through all NMS systems in the path back to the initiator of the trace because of the secure connections established between NMS systems of border networks. The involved systems in the path for type 2 and 3 messages would then have the ability to see the acknowledge the trace status before sending the messages back along the NMS path to the originating NMS. Before a trace can be initialized, the originating NMS must check an internal database to determine if a trace to the same IP address or network address has occurred within a specified period of time, no less than 1 day. The trace may have also been initiated by the same NMS or this NMS may have been in the path of the trace. The previous filter must be maintained for a minimum of a one-week period in order to retrieve the filter for comparison before initiating a trace request or allowing a trace continuance to occur. If the network administrator justifies a similar trace, a note might be added to the text section of the packet to provide an additional confidence indication to the upstream NPs in the path of the trace. Moriarty Expires: March 3, 2004 [Page 20] Internet-Draft September 3, 2003 A single trace may be limited in time by factors determined by the single network trace system used by the NPs in the path of the trace. The single trace system may either trace a packet dynamically or search through stored packet data for evidence that the packet had traversed the network. In the case of a dynamic trace, the traffic would need to be active on the network for the trace to be successful or the trace would cease and a message would be sent to indicate the status that the trace cannot continue to the originating NMS through the bilateral trust relationships formed by the NMS' in the path of the trace. The packet trace may also be limited due to the storage space on networks, which save traffic data. A trace status message would be sent in this case as well to provide the path information up to the point in which the trace could no longer be continued to the originator of the trace through the bilateral trust relationships in the path of the trace. 4.3 Message Structure: The TCP protocol is a good candidate to provide a reliable transport mechanism for the messages sent between network management systems. RID-DoS would operate on a port assigned by the Internet Assigned Numbers Authority (IANA). The message structure for the data portion of the packet is detailed below. Message types 1 and 4 are identical except in how they are handled at each NMS. Message Type 2 shares the same basic structure as types 1 and 4 with a few exceptions which are listed below. Message type 3 differs after the incident identifier. The first 136 bytes include the consistent fields used in each packet type: ------------------------------------------------------------------- | Msg Type | Time Stamp | Incident Identifier | ------------------------------------------------------------------- 8-bit 32-bit 96-bit Field 1: 8-bit field for Message Type containing the number associated with the message type given in the above descriptions Field 2: 32-bit field for Time Stamp containing the current time in seconds since January 1,1970 Greenwich Mean Time from the sender of the packet Field 3: 96-bit field for Incident Identifier 64-bit field Autonomous System Number (ASN) 16-bit field for Incident number, rolls over to zero 16-bit field for Trace number, rolls over to zero Note: The incident number used in a trace request is generated by the initiating NMS. The incident number is unique per incident, (security incident, DoS, DDoS), and is incrementally increased from 0 until the roll over point is reached. The trace number is also incrementally increased from 0, but is reset for each new incident number. Moriarty Expires: March 3, 2004 [Page 21] Internet-Draft September 3, 2003 Field 4: 8-bit field depending on message type Percentage for Confidence rating in message type 1 and 2 Bit set for Action taken (bit set to 1 if selected option) in message type 3 Field 5: 424-bit field for Filter used in message type 1, 2, and 4. Note: This field is unnecessary in message type 3. Must include space for all items listed below and unused items would be left blank for specific filters. All non-changing fields of the IP header are included as well as 8 bytes from the payload to meet the needs of the Hash-based IP Traceback. The protocol and port information is listed for flow analysis or filter based traces. 4-bit field for IP header version 4-bit field for the IP header length, usually 20 bytes In Version 6 packets, this field is used for priority 16-bit field for size of datagram (IP header plus payload listed in bytes) field used for payload length in version 6 packets 16-bit field for identification to uniquely identify packets Version 6 8-bit for next hop and 8-bit for hop limit 3-bit field for IP flags, pad unused fields 13-bit field for fragmentation offset, listed in bytes 8-bit field for protocol number 128-bit Destination Internet IP address given in IPv6 format 128-bit Source Internet IP address given in IPv6 format 16-bit field for destination port 16-bit field for source port 64-bit field for 8 bytes of payload Field 6: 2-bit field to indicate trace status in message type 2, Followed by 6-bit of padding Following 2 fields used in message type 1, 2, 3, and 4: Field 6 in Msg 1,4: Field 7 in Msg 2: Field 5 in Msg 3: 8-bit field Number of hops or contacts along the path of the trace Next Field 7, 8, or 6: 144-bit field for each identifier. 16-bit for AS number 128-bit for NMS IP address in IPv6 format Note 1: If identifier is unavailable, the IPv6 formatted address should be listed and the AS number field null terminated and padded. The optional text box at the end of the packet should be used to provide NP name and contact information. Note 2: A maximum of 80 identifiers may be listed within the size constraints of a TCP packet. 15 would be large enough considering that this is a count of the NMS systems used to trace the attack. If the number is exceeded, that may indicate a loop or other problem with the trace. In the case were it is valid to have more than 15 NMS systems listed, the originating NMS should Moriarty Expires: March 3, 2004 [Page 22] Internet-Draft September 3, 2003 be left in the packet and the rollover should begin with the second hop. Each NMS should also track the trace identifiers that have already passed through their systems to prevent loops. Following 4 fields for Message type 1 and 4: Field 8: 8-bit field with size of optional text field or null. Field 9: Optional Text Field used to explain reason for request Field 10: 8-bit for size of Digital Signature for message type 1, 4 Field 11: Digital signature of 128-160-bit hash of filter 128-bit hash produced from MD5, 160-bit hash produced from the SHA hash algorithm Remaining Fields in Message Type 3: Field 7: 8-bit for size of Digital Signature for message type 3 Field 8: Digital signature of 128-160-bit hash of message 3 contents 128-bit hash produced from MD5, 160-bit hash produced from the SHA hash algorithm Field 9: 128-bit field given for true source address of attack Field 10: 8-bit field with size of optional text field or null. Field 11: Optional Text Field 0-1398-byte text field used in message type 3 to provide additional attack information or contact information, minus the size of the digital signature. 0-1130-byte text field if the optional text field is used in message type 2 for NMS identification information. The text field can extend to the end of the TCP packet data unit size limit of 1460 bytes. The number of bytes used for the text field is listed in the first 8-bits or a null character must be used to indicate the text field was not used. The text field must be terminated with a null character to signify the end of the text portion of the packet. Note: The text is in English and is represented using ASCII format. A single language would reduce management complexity, particularly in the case where the event spans NPs in multiple countries. Total size of Message Type 1 and 4 messages (without IP and TCP headers) = 710 bits with 1 NMS listed, 2496-bits with 15 NMS listed, plus the size of the text field listed in field 8 Total size of Message Type 2 packet is 8-bits larger than Message Type 1 and 4 Message Type 3 size before the optional text field is 262-bit 4.4 Message Delivery Protocol - Integrity and Authentication Moriarty Expires: March 3, 2004 [Page 23] Internet-Draft September 3, 2003 The RID-Dos 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. It may seem appropriate to use SNMP trap messages since Network Management Systems already use this messaging structure. However, RFC1215 discourages the use of traps for this type of application and attempts to discourage the creation of new trap types. The current trap messaging structure does not satisfy the information requirements in order to successfully carry out a trace. Trap messages are sent via UDP, which assist in the quick delivery of packets, however they do not guarantee delivery as in TCP. The RID DoS protocol for inter-NMS communication could provide the transport mechanism for message delivery. Another protocol choice that may seem appropriate is the IDMEF protocol used for Intrusion Detection messaging. However, the design of the packets and messages used for that system do not meet the needs of RID-DoS to ensure all the necessary information is included in the messages sent between network providers. Security considerations must include the integrity, authentication, and authorization of the messages sent between NMS systems. The communication between NMS systems must be authenticated and encrypted to ensure the integrity of the messages and the NMS 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 path of the multi-hop trace request need to authorize a trace from not only their neighbor network, but also from the initiating NMS. Several methods can be used to ensure integrity of the communication. 4.4.1 Transport Communication Out-of band communications dedicated to NP interaction for RID-DoS messaging would provide additional security as well as guaranteed bandwidth during a denial of service attack. This might be accomplished through logical paths defined over the existing network. Out-of-band communications may not be possible between all network providers, but should be considered if feasible to protect the network management systems used for RID-DoS messaging on the network. In order to address the integrity and authenticity of messages, IPSec tunnels MUST be used to encrypt the traffic sent between NMS systems with pre-defined trust relationships. Systems used to send authenticated RID-DoS messages between networks MUST use a dedicated and secured interface to connect to a border network management system. If a single system is used to connect to multiple network management systems, each connection must have a dedicated interface and the security requirements MUST meet those agreed upon through peering or service level agreements (SLA). The NMS interface must only listen for and send RID-DoS messages over Moriarty Expires: March 3, 2004 [Page 24] Internet-Draft September 3, 2003 an IPSec tunnel, using the Encryption Security Protocol and meeting a minimum requirement of algorithms and keys established by the peering or SLA agreement. IPSec transport mode using ESP is preferred, however tunnel mode using filters to limit the communication to the RID-DoS protocol is sufficient. Tunnel mode is acceptable due to limitations in the availability of compatible IPSec transport mode implementations. Transport Layer Security (TLS) would be similar to IPSec Transport mode in that it is used to wrap the specific protocol with encryption to provide transport level security. The selected algorithm must have minimum security levels of the times, 3DES or 128-bit AES are sufficient at the time this draft was written. 4.4.2 Authentication of RID-DoS protocol In order to insure the authenticity of the RID-DoS messages, a message authentication scheme using a public key infrastructure (PKI) must be inherent to the protocol. Public key certificates and digital signatures issued by a trusted Certificate Authority (CA) will be used to provide the necessary level of authentication for the RID-DoS protocol. The trusted CA used for RID-DoS messaging must be trusted by all involved parties and may take advantage of similar efforts, such as the dot-root project (http://dot-root.com). The PKI infrastructure used for authentication would also provide the necessary certificates needed to establish the above mentioned IPSec tunnels. Hosts receiving a RID-DoS message, such as a trace request, for example, must be able to verify that the sender of the request is valid and trusted. Using digital signatures on a hash of the RID-DoS message with an X.509 version 3 certificate issued by a trusted party can be used to authenticate the request. The X.509 version 3 specifications as well as the digital signature specifications and Certificate Revocation List (CRL) Internet standards set forth in RFC2459 must be followed in order to interoperate with a PKI designed for similar Internet purposes. A one-way certificate based authentication protocol as described in the ISO Authentication Framework (ISO/IEC 9594/8) and cited in 24.9 of Applied Cryptography must be used. The ISO authentication framework provides the authentication and integrity aspects required for secure messaging between network providers. An optional extension to the authentication scheme would be to incorporate the use of attribute certificates to provide authorization capabilities as described in RFC3281. This may be useful as messages are sent from network peers to determine authorization levels based on the attribute information in the certificate, which could be used to determine priority of a trace request. The attribute information might be used to determine if a trace request should be processed automatically or if human intervention is required. Moriarty Expires: March 3, 2004 [Page 25] Internet-Draft September 3, 2003 4.4.3 Authentication Considerations for a Multi-hop Trace Request Bilateral trust relations between network providers ensure the authenticity of requests for trace requests from immediate peers in the web of networks formed to provide the trace back capability. A network provider several hops into the path of the RID-DoS trace must trust the information from their peer as to the confidence rating of the attack and the previous trust relationships in the downstream path. In order to provide a higher assurance level as to the authenticity of the trace request, the originating NMS is included in the trace request along with contact information as well as the information of all NMS systems in the path the trace has taken. A second measure must be taken to ensure the identity of the originating NMS. The originating NMS, also listed as originator of the request in the path information, must include a digital signature in the trace request sent to all systems in the NMS upstream path. The initiating NMS system is required to include a digitally signed hash of the packet filter information, all necessary fields of the IP header and 8 bytes of payload, in the trace request. 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 used to provide authentication listed in the authentication section will also provide the certificates used to digitally sign the necessary information in the trace requests. Since the CA is known and trusted by all parties, any host in the path of the trace can verify the digital signature. The digitally signed hash must be included in all upstream trace requests to allow subsequent NPs to verify the authenticity of a trace request. 4.4.4 Privacy Concerns RID-DoS is useful when trying to determine the true source of a packet when it traverses multiple networks or to provide a means to communicate security incidents and provide a way to automate response. In order to identify the source and trace multiple networks, the packet header information along with 8 bytes of payload are used in the packet identification. The information obtained from the trace may result in the identity of the source host or the network provider used by the source of the traffic. The trace mechanism used across a single network provider may also raise privacy concerns if the provider uses a method, which involves storing packets for some length of time in order to trace packets after the fact. The identity of the true source of a packet could be protected through service level agreements with network providers. In some situations, systems used in attacks are compromised by an unknown source and then in turn are used to attack other systems. In this type of situation, the reputation of a business or organization may Moriarty Expires: March 3, 2004 [Page 26] Internet-Draft September 3, 2003 be at stake and the action taken through RID-DoS would be to report the action taken to the originating system. If the security incident was a minor incident such 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. Local, state, or national laws may dictate the appropriate reporting action for specific security incidents. The packet information is sent across multiple networks that happen to be in the path of a trace. Another concern may be that an attack occurred between a specific source and destination and every network provider in the path of the trace is now aware that the cyber attack occurred. In cases where compromised systems are responsible for the attack, this may not raise privacy concerns. However, in a targeted attack it may not be desirable for the knowledge of two nation states battling a cyber war to become general knowledge to all intermediate parties. It is important to allow the traces to take place in order to cease 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 third message type, source found to only include an action taken instead of identity of the offending host. In some situations, all network traffic of a nation may be granted through a single network provider. In order to gain support for tracing mechanisms, options must also include the ability to send a source found message from the downstream peer of the network provider where the source was found to provide another layer of protection to the attack source identity. 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 message type 4 to request action close to the source of valid attack traffic needs to be considered. Although the intermediate NPs would rely the request to the closest NP to the source, they would not require the ability to see the contents of filter or the optional text field in the request. This message type does not require any action in the intermediate systems, except to rely the packet to the next NP in the path. Therefore, the contents of the request may be encrypted. The intermediate NPs would only need to know how to direct the request to the manager of the AS number in which the source IP address belongs. Finally, privacy concerns may also include the storage of packet information that could be used for single network traces. RID-DoS is designed to pass the information needed by any single network trace mechanism used. The decision of what single trace mechanism used by a provider may depend on resources, existing solutions, and local legislation. Privacy concerns in regard to the single network trace must be dealt with at the client to network provider level and are out of the scope for RID-DoS messaging. Moriarty Expires: March 3, 2004 [Page 27] Internet-Draft September 3, 2003 The ability to dynamically trace packets through packet flow data could be used with malicious intent and reach beyond the intended scope of this protocol. However, if using a valid source address, RID-DoS traces would not be necessary since the true source information would already be valid in the packet. Tools such as traceroute can be used to identify path information and/or the relay message could be used for notification purposes to the NP closest to the source to allow for an automated response and action to mitigate the effects of the attack traffic. If tools such as traceroute do not provide the necessary path information in a security incident, the trace request must note the system use to avoid instances where the trace is providing information outside the intended and agreed upon scope of the system. Appropriate system use must be defined by the collaborative effort of the NPs connected in a RID-DoS web. 5.0 Security Considerations Communication between NP's NMSes must be protected. An out of band network, either logical or physical would prevent outside attacks against NMS communication. Authenticated encryption tunnels between stations would protect the data in transit as well as provide integrity of the data and must be used. Since the RID-DoS network is a bilateral interconnection of adjacent peers, the NMSs would permit messages between peering networks, which would relay messages to upstream peers on behalf of the initiating network peer. The NMS should be configurable to either require user input or automatically continue traces. This feature would enable a network manager to assess the available resources before continuing a trace. A trace may cause adverse affects on a network. If the confidence rating is low it may not be in the Network Provider's best interest to continue the trace. The confidence ratings must adhere to the specifications for selecting the percentage used to avoid abuse of the system. Trace requests must be issued by authorized individuals from the initiating network, set forth in policy guidelines established through peering or SLA agreements. Policy between NPs must be established to provide guidelines for communication. The policy should include communication methods, security, and fall-back procedures. The Policy should establish a method to protect communications between NMS systems between all bordering NPs. The trust relationships would have to extend to all bordering NPs in order to be successful in tracing and stopping attacks. A fully meshed communication ability would provide the means for message type 3 (Source Found Message) to be sent to an initiating NMS. If a fully meshed communication system is not available, messages may have to traverse multiple systems to reach the initiating NMS as a result of the linear trust relationships established between management systems. Other policy considerations include how the AS number and NMS IP address should Moriarty Expires: March 3, 2004 [Page 28] Internet-Draft September 3, 2003 be shared. This should also be coupled with any necessary pre-shared key or certificate (or trusted Security Authority) stored in the NMS for encryption negotiation. Note: The AS number and corresponding IP address for a network NMS would be shared between cooperating networks via a predefined table. This information may be stored locally on NMS systems or a central database accessible on the secured network used for inter-NP messaging on NMS. A Certificate Authority may be used to establish security associations between NMS systems. The method of passing the trace request to subsequent networks eliminates the need for granting access to remote entities to configure network equipment on border networks. Access to network equipment to configure systems for trace continuance would remain in the responsibility of the parties who own and manage the equipment. This also prevents the need for sharing authentication information to the devices outside of the network operation center managing the device. Network administrators who have the ability to base the decision on the available resources and other factors of their network maintain control of the continuance of a trace. 6.0 Summary Denials of service attacks have always been difficult to trace as a result of the spoofed sources, resource limitations, and bandwidth utilization problems. Incident response is often slow as well even when the valid address is known because of the resources required to notify the responsible party of the attack and then to stop the attack traffic. Methods to identify and trace attacks near real time are essential to thwarting attack attempts. Network Providers need automated methods as well as policies in place in order to attempt to combat the hacker's efforts. Proactive monitoring and alerting of backbone and client bandwidth with trend analysis is an approach that can be used to help identify and trace attacks quickly without resource intensive side effects. Subsequent more detailed analysis could be used to complement the bandwidth monitoring. Timely communication between NPs is essential in incident handling. Moriarty Expires: March 3, 2004 [Page 29] Internet-Draft September 3, 2003 7.0 References [ISO 9594/8] CCITT Rec. X.509 (1994) | ISO/IEC 9594-8:1994, Information Technology - Open Systems Interconnection The Directory: Authentication Framework [RFC791] "Internet Protocol, DARPA Internet Program, Protocol Specification". Information Sciences Institute, University of Southern California. September 1981. [RFC1213] "Management Information Base for Network Management of TCP/IP-based Internets: MIB-II". K. McCloghrie, M . Rose. March 1991. [RFC1215] "A Convention for Defining Traps for use with the SNMP". M. Rose. March 1991. [RFC1930] "Guidelines for creation, selection, and registration of an Autonomous System (AS)". J. Hawkinson and T. Bates. March 1996. [RFC2246] "The TLS Protocol". Dierks, T. and C. Allen. January 1999. [RFC2459] "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile". Housley, R., Ford, W., Polk, W. and D. Solo. January 1999. [RFC2527] "Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework". Chokhani, S., Ford, W. March 1999. [RFC2528] "Internet X.509 Public Key Infrastructure: Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates". Housley, R., Polk, W. March 1999. [RFC2720] "Traffic Flow Measurement: Meter MIB". N. Brownlee. October 1999. [RFC2722]"Traffic Flow Measurement: Architecture". N. Brownlee, C. Mills, G. Ruth. October 1999. [RFC2723] "SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups". N. Brownlee. October 1999. [RFC2827] "Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing". P. Ferguson and D. Senie. May 2000. [RFC3821] "An Internet Attribute Certificate Profile for Authorization". Farrell, S., Housley, R. April 2002. Moriarty Expires: March 3, 2004 [Page 30] Internet-Draft September 3, 2003 [1] http://www.info-sec.com/denial/infosece.html-ssi [2] `CenterTrack: An IP Overlay Network for Tracing DoS Floods'. Robert Stone. 9th Usenix Security Symposium Proceedings, August 2000. [3] 'Inferring Internet Denial of Service Activity`. David Moore, Geoffrey M. Voelker and Stephan Savage. Published in proceedings of the 2001 USENIX Security Symposium. [4] 'MULTOPS: A Data-Structure For Bandwidth Attack Detection'. Thomer M. Gil, Massimiliano Poletta. Published in proceedings of the 2001 USENIX Security Symposium. [5] 'Network Congestion Monitoring and Detection using the IMI infrastructure'. Takeo Saitoh, Glenn Mansfield, and Norio Shiratori. Graduate School of Information Sciences, Tohoku University. [6] 'Trends in Denial of Service Attack Technology`. Kevin J. Houle and George M. Weaver. CERT Coordination Center. October 2001. [7] http://www.cisco.com/go/netflow [8] 'Hash Based IP Traceback'. A. Snoren, L. Sanchez, C. Jones, F. Tchakountio, S. Kent, and W. Strayer. SIGCOMM'01. August 2001. [9] 'Practical Network support for IP Traceback'. S.Savage, D. Wetherall, A. Karlin and T. Anderson. SIGCOMM'00. August 2000. [10] 'ICMP Traceback Messages'. S. M. Bellovin. Internet Draft: draft-bellovin-itrace-00.txt, March 2000. [11] PKCS 5 v2.0 Password-Based Cryptography Standard. RSA Security http://www.rsasecurity.com/rsalabs/pkcs/pkcs-5/index.html. March 1999. [12] PKCS 7 Cryptographic Message Syntax Standard. RSA Security. http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/index.html. May 1997. [13] Applied Cryptography: Protocols, Algoritms, and Source Code in C. Schneier, Bruce. Second edition. John Wiley & Sons. 1996. Moriarty Expires: March 3, 2004 [Page 31] Internet-Draft September 3, 2003 8.1 Acknowledgements Dr. Robert K. Cunningham, MIT Lincoln Laboratory Cynthia D. McLain, MIT Lincoln Laboratory Dr. William Streilein, MIT Lincoln Laboratory Many thanks to the Internet community for reviewing and commenting on the draft, most notably Jose Nazaro, Jean-Francois Morfin, Tony Tauber, Steve Bellovin, Jeffrey Schiller, Iljitsch van Beijnum, and Stephen Northcutt. 8.2 Author Information Kathleen M. Moriarty MIT Lincoln Laboratory 244 Wood Street Lexington, MA 02420 Phone: 781-981-5500 Email: Moriarty@ll.mit.edu This work was sponsored by the Air Force under Air Force Contract Number F19628-00-C-0002. "Opinions, interpretations, conclusions, and recommendations are those of the author and are not necessarily endorsed by the United States Government." Moriarty Expires: March 3, 2004 [Page 32]