INTERNET-DRAFT Kathleen M. Moriarty draft-moriarty-ddos-rid-01.txt MIT Lincoln Laboratory Expires: November 6, 2002 May 6, 2002 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 One of the latest trends attacking Internet security is the increasing prevalence of Denial of Service (DoS) attacks. DoS attacks target system and/or network resources and seek to prevent valid access by consuming resources. Internet Service Providers (ISPs) need to be equipped and ready to assist in tracing these attacks with tools and procedures in place before the occurrence of a DoS attack. This paper proposes a proactive inter-network communication method as well as an SNMP-based tracing mechanism that can be used by ISPs to identify the source(s) of an attack. SNMP flows as described in RFC2720, implemented on routers or monitoring devices could be used to trace attacks coordinated by a Network Management System that would also provide a communication mechanism across network borders. It is imperative that ISPs have quick communication methods defined to enable neighboring ISPs to assist in tracking a security incident across the Internet. This proposal makes use of current standards for traffic and performance management, which could be extended for DoS incident handling. Policy guidelines for handling these incidents are recommended and can be used by Internet Service Providers (ISPs) and extended to their clients in conjunction with the technical recommendations. Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 TABLE OF CONTENTS Status of this Memo ................................................ 1 Abstract ........................................................... 1 1.1 Introduction ............................................... 3 2.1 Recommended Internet Service Provider (ISP) Technologies ... 4 3.1 Tracing Internet Security Incidents ........................ 5 3.2 Tracing a Single Source Attack with Filters ................ 5 3.3 Tracing a Distributed attack ............................... 6 3.4 Trace approach via SNMP Traffic Flow Analysis ............. 7 3.5 Correlating Collected Data ................................. 11 4.1 Communication amongst ISPs ................................. 12 4.2 Inter-ISP NMS Messaging .................................... 14 4.3 Message Formats ............................................ 14 4.3.1 Trace Request ........................................ 15 4.2.2 Trace Authorization Message .......................... 16 4.3.3 Source Found Message ................................. 17 4.3.4 Example Upstream Trace ............................... 18 4.4 Message Structure: ......................................... 18 4.5 Message Delivery and Security Considerations ............... 20 5.1 Security Considerations .................................... 20 6.1 Summary .................................................... 21 7.1 References ................................................. 21 8.1 Acknowledgements ........................................... 23 8.2 Author Information ......................................... 23 Moriarty Expires: November 6, 2002 [Page 2] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 1.1 Introduction 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 sourced and multiple source origins. Denial of Service attacks attempt to consume bandwidth, processing power, or system resources. The bandwidth-based attacks flood systems with TCP, UDP or ICMP packets. The bandwidth or processing power based attacks may use variations on these packets, such as altering the source address, port numbers, or TCP options. The source address might be altered in an ICMP attack where packets are sent through a site with the IP direct broadcast option enabled on their router. The IP directed broadcast would amplify the number of packets sent to the victim, thus flooding the network and consuming bandwidth. Port numbers might be altered 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. Another type of 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. Thus leaving the connection open on the server and consuming system resources. There are a limited number of connections a server can maintain, thus preventing valid connections from reaching the server under attack. DoS attacks are characterized by large amounts of traffic destined for particular Internet locations and can originate from 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 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 true origin 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. Current approaches to mitigate the effects of DoS and DDoS attacks are aimed at attackers who seek to hide the origin of their attack source address spoofing from multiple locations. In order to mitigate the effects of an attack, measures can be taken at ISP border routers providing ingress, egress, and broadcast filtering as a recommended best practice in RFC2827. These filters ensure that the traffic leaving and entering client locations contain valid source and destination addresses. Moriarty Expires: November 6, 2002 [Page 3] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 2.1 Recommended Internet Service Provider (ISP) Technologies ISPs 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 detection 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. This would enable ISPs to 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 ISP'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 a 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. The incident along with any available automated trace data should trigger an alert to the ISPs 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. Methods such as trending the packet size of traffic to and from networks may be an indicator of this type of attack. 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. Moriarty Expires: November 6, 2002 [Page 4] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 3.1 Tracing Internet Security Incidents DDoS attacks are 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 ISP 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. If the source(s) of the attack cannot be determined from tracing the increased bandwidth utilization, it may be possible to trace the traffic based on the type of packets seen by the client. This paper discusses two methods that can be used to trace back to the source of an attack, one via filtering and the other via an SNMP implementation. 3.2 Tracing a Single Source Attack with Filters In 1997, the MCI Security team wrote DoSTrack [2], a program used to trace back through a network in order to identify the origin of a DoS attack, such as the SYN flood attack. The program started its tracing efforts at the ISP border router for a client and determined if the router was seeing the attack. If the router was passing the attack traffic, DoSTrack would then identify the interface on a Cisco router in which the traffic was originating. Once the next hop was identified, DosTrack would log into the next router in the upstream path of the attack traffic and set a filter to monitor for the traffic. If the router did not see the attack traffic, DoSTrack would stop its tracing efforts at that router. If the attack traffic were seen, it would continue tracing until the source of the traffic or a bordering ISP was identified. The traces were performed through the use of access control filters implemented on each router in the upstream path of the traffic. The filters were used to permit the suspicious traffic and then log the packet information, including the source interface on the router that the packet used to identify the next hop. Router access control lists and logging are both resource intensive operations. The additional resources required to implement filters across a network are not available at many ISPs. In many cases ISPs maintain routers close to maximum capacity for normal Moriarty Expires: November 6, 2002 [Page 5] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 operation. CenterTrack [2] was an improvement on DoSTrack eliminating the need for filtering in the center of the network, however it is still taxing on router resources and lacks the ability for Inter-network communication. This approach could help identify the source of an attack, but a less resource intensive approach is needed for many ISPs. Several other limitations include: O DosTrack was primarily used for tracing Denial of Service attacks from a single source, thus the solution would not scale to a trace a multiple sourced attack. O DosTrack was written specifically for Cisco routers. Other vendors, for example higher end routers used in multi-gigabit networks, may not even provide similar filtering options. O The DoSTrack program can only be used within a single ISPs backbone because of access capabilities to neighboring network's equipment. A solution to address attacks of a distributed nature, crossing multiple network backbones, and various network equipment is needed. The approach should consider the resource limitations of many Internet Service Providers. 3.3 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 making it difficult to trace back. The sources may also alternate the type of traffic as well as vary the sources from within the pool of servers launching the attack. Immediate action would need to be taken to have any hopes of locating the origin(s) of the attack. In order to identify a DoS attack, a client may notify their ISP that they are currently under attack. Automated methods might include analysis of traffic looking at statistics such as unexpected fluctuations in bandwidth or the size and types of packets sent between networks or hosts could be used. There is ongoing 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 such as detecting 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 normally receives small packets and replies with large packets Moriarty Expires: November 6, 2002 [Page 6] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 experiences a change in traffic pattern such as sending and receiving large amounts of either small or large packets, that may 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 trace back connections might include packet information such as destination IP address and any distinguishing marks of the traffic seen by the site during the attack. If a trace can identify the sources of a distributed attack, blocking the sources at the ISP 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. 3.4 Trace approach via SNMP Traffic Flow Analysis 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. The structures defined in the Traffic Flow management RFCs could be extended for use in tracing DoS or DDoS incidents. The traffic flow management information base (MIB) could first be used in trend analysis of network behavior in order to detect anomalies. A central management station could be used to coordinate a trace of suspicious network traffic and may also be responsible for the traffic flow analysis of data gathered via SNMP from devices on the network running the traffic flow MIB. In order to expedite the trace(s) of an attack, pre-defined filters can be used to quickly trace traffic as described in the traffic flow management specifications. A further extension discussed later would be to enable traces to extend beyond the border of a network or an ISP to take place. An SNMP approach using the Traffic Flow MIB to detect DDoS may help to reduce the necessary resources used by network routers in comparison to a filter based approach. The traffic flow MIB was designed to be used for network performance measurement and took into consideration system resources in the implementation. A coordinated SNMP approach can provide the dynamic framework Moriarty Expires: November 6, 2002 [Page 7] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 necessary for tracing attacks near real time because a central management station would control trace attempts and quickly move through the network identifying the source of an attack. The communication between ISPs and their network management systems described later, provide a framework for dynamically sending traces to bordering networks to continue the search for the attack origins. The 'Traffic Flow Measurement' RFCs outline a structure for monitoring flows in a network through the use of capture filters deployed on so-called 'meters' throughout the network. A meter, as described in the Traffic Flow architecture document [RFC2722], is a device running the Traffic Flow MIB. The device could be a router or switch already in the network or an appliance-like device promiscuously monitoring the network using the Traffic Flow MIB on a broadcast segment or a mirrored port on a switch to the router. The monitoring is performed through SNMP, allowing a network device or meter to have a filter, which watches for a specific flow of traffic. The filter or rule sets can be predefined on a meter and managed by a central device collecting the data captured by the filters. A central network management station taking periodic snapshots of the flows of traffic through network devices (meter) could be extended for use in detecting abnormal behavior on the network, such as the occurrence of a denial of service attack. The NMS could also perform any post-processing and analysis of the captured data. Some examples of a network traffic meter may be a router, switch, or other device monitoring the traffic promiscuously. The meter would incur added overhead when monitoring a flow, especially in the case of a high bandwidth network. However, an SNMP traffic flow monitoring implementation may be a more viable option than a filter/logging approach, since it would be less resource intensive. The SNMP traffic flow architecture RFC suggests traffic flows should be used to measure network performance over other measurement means for performance reasons. The available buffer space on the meter limits the amount of traffic that can be stored by the meter before a 'meter reader' collects it. The RFCs outline methods that reduce the overhead by setting thresholds on the capture filter. If the threshold is met, a secondary, less granular filter is enabled to replace the initial capture filter. The intent of implementing the secondary filter is to reduce the overhead of the device and may lead to a higher degree of post processing analysis on a broader capture. If implementing meters in routers is not a viable option on a network, implementing meters in monitoring devices would avoid the additional overhead incurred by the routers or switches in the network. The monitoring device would drop any traffic it could not handle and would not affect the status of the network. The number of packets dropped by the meter is also recorded which could be used to determine the state of the network and detect abnormal behavior in the form of excessive amounts of packets as well. Moriarty Expires: November 6, 2002 [Page 8] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 The SNMP traffic flow identifier 'RuleSets' are used to set filters on meters. The RuleSets can be defined broadly to include a single destination address or to monitor a specific protocol. RuleSets can also be more specific to a particular source and destination address and protocol information. Currently, the Traffic Flow RFCs do not include methods to look at other TCP header options, but would enhance the ability to trace and detect DoS attacks. The filter capture data includes the adjacent peer information, or next-hop in the network, which can be used to track the origin of a spoofed packet upstream in the network. The next hop information is represented in the form of the protocol used, for example as an IP or IPX address at the protocol layer and a MAC address at the physical layer. Time stamps are also included in the SNMP record listing the start time for a flow and the last time a packet was detected as part of that flow. The count of packets and octets for flows is recorded in both directions: client-to-server and server- to-client. This information may be useful in detecting anomalous behavior in the following ways. If the amount of traffic between a client and server or between two networks become weighted more heavily in the reverse direction (than expected or predicted), that may serve as an indication of a denial of service attack. Also if the relationship between the number of octets and the number of packets changes significantly, that may be an indicator of unusual traffic in terms of packet size and may possibly be an attack. The flow information is reported in the following MIB entry, as listed in RFC2722: Moriarty Expires: November 6, 2002 [Page 9] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 FlowAttributeNumber ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Uniquely identifies an attribute within a flow data record." SYNTAX INTEGER { flowIndex(1), flowStatus(2), flowTimeMark(3), sourceInterface(4), sourceAdjacentType(5), sourceAdjacentAddress(6), sourceAdjacentMask(7), sourcePeerType(8), sourcePeerAddress(9), sourcePeerMask(10), sourceTransType(11), sourceTransAddress(12), sourceTransMask(13), destInterface(14), destAdjacentType(15), destAdjacentAddress(16), destAdjacentMask(17), destPeerType(18), destPeerAddress(19), destPeerMask(20), destTransType(21), destTransAddress(22), destTransMask(23), pduScale(24), octetScale(25), ruleSet(26), toOctets(27), -- Source-to-Dest toPDUs(28), fromOctets(29), -- Dest-to-Source fromPDUs(30), firstTime(31), -- Activity times lastActiveTime(32), sourceSubscriberID(33), -- Subscriber ID destSubscriberID(34), sessionID(35), sourceClass(36), -- Computed attributes destClass(37), flowClass(38), sourceKind(39), destKind(40), flowKind(41) } Moriarty Expires: November 6, 2002 [Page 10] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 During a DoS, the destination information (variables 14-25) could be used to detect the event while the source information (variables 4-13) could be used to trace the path to the origin of the attack. toPDUs and fromPDUs are the variables that keep a count of the packets in the bi-directional flow. The toOctets and fromOctets track the number of octets between the source and destination. There are 'meter readers' described in the specification, which periodically poll meters for the captured data from the current filters. The meter readers provide the data to a 'manager' that analyzes the data. The manager may be an NMS or similar server, which is responsible for network trend analysis, network outage reporting, network debugging, etc. 3.5 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 ISP 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 ISP 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, targeting either bandwidth or system resources. If an ISP was aware of such an event, it could set higher thresholds for bandwidth usage alerting during that period of time to prevent false alarms. The anomalies could be used as methods of detecting Denial of Service attacks. Since a centralized server would be recording all of the capture information from the network meters, it may be easier to track the source of an attack. If the current capture RuleSets on the meters do not provide the necessary data to trace the attack, pre-defined or new, RuleSets could be set on the meters to watch for the traffic flows known to be part of the attack. The peer information could be used by the NMS to dynamically set the new RuleSets upstream in the reverse path of the traffic flow until the central monitoring station discovers the source. However, this may limit the trace to the boundaries of a specific network. Since the trace may have begun on a specific company's network, its border with the ISP may be the boundary where the tracking must then become the responsibility of the ISP because of access limitations. This would also be true in the case of a boundary between ISPs. When tracing back an attack, the ISP could elect to enable this tracking feature, and then poll the routers on their network for the types of traffic seen during the attack. In order for this SNMP trace of traffic to be meaningful for a DDoS attack, the Moriarty Expires: November 6, 2002 [Page 11] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 destination IP or network block of the packet would be necessary as the traffic is traced back through the network. Using the traffic flow MIB the IP destination and possibly protocol information could be set in the meters for tracking via a RuleSet, this may be a viable means to trace back traffic quickly through a network. DDoS attacks have many origins and traces such as this may only lead back to a client that is a very small part of the attack. However, once a few clients are detected as being part of the attack, methods could be used to determine the location of the controller of the client to further trace the true source of the attack. That trace may involve intrusion detection or monitoring on the client and is beyond the scope of this paper. 4.1 Communication amongst ISPs Expediting the communication between ISPs is essential when responding to a security related incident such as a Denial of Service attack, which may cross network access points, (Internet backbones) between providers. As a result of the urgency involved in this inter-ISP 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. Each ISP should dedicate a phone number to reach a member of their security incident response team. The phone number could be dedicated to inter-ISP 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 ISPs 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 ISPs network. The outside resource should be able to mitigate or alleviate the financial and experience resource limitations. A technical solution may be to implement traffic flow meters, as described in the 'Traffic Flow Measurement: Architecture' document [RFC2722], that can be read by other ISPs or a neutral third party to facilitate the investigation of a denial of service attack. Meters can be read by multiple meter readers, which may limit the expense and provide the ability for a quick response to an attack. The meter uses a single active capture filter and the buffered data can be retrieved by any of the configured meter readers. Each ISP may want to maintain their own management station used for network monitoring and analysis. A neutral third party may have access to a Moriarty Expires: November 6, 2002 [Page 12] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 specific group of RuleSets that can be implemented dynamically as an event is traced beyond network borders. This could be a function of a central organization operating as a computer response team for the Internet as a whole. An alternative to permitting access to other network's meters would be to create a standard messaging mechanism to enable NMS systems to communicate trace information to neighboring networks Network Management Systems. The third party mentioned above may be used in this technical solution to assist in facilitating traces through smaller ISPs. The messaging mechanism 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. This would also enable the individual ISPs to involve any intervention by the 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 may be permanent virtual circuits configured with a small amount of bandwidth dedicated to NMS communications between ISPs. 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. Moriarty Expires: November 6, 2002 [Page 13] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 4.2 Inter-ISP NMS 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 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. A message sent between NMS systems to request the continuance of a trace through a bordering network would require the information enumerated below. 1. Messages sent between network management stations would have to contain enough information to enable the network administrators to make a decision about the importance of continuing the trace. 2. The trace request message should also contain the filter information needed to carry out the trace. 3. Contact information of the origin of the trace should be included. The contact information could be provided through the autonomous system number [RFC1930] whois information listed in the American Registry for Internet Numbers (ARIN) database. 4. Network path information to help prevent any routing loops through the network from perpetuating a trace. 5. A unique identifier for a single attack should be used to correlate traces to multiple sources in a DDoS attack. 4.3 Message Formats The following section describes the four message types used to facilitate the communication between ISPs tracing an incident. The messages would be generated and received on Network Management Systems on the ISPs network. The fields in the messages are described following the message descriptions. Moriarty Expires: November 6, 2002 [Page 14] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 4.3.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 ISP 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 Attack detected with 100 percent confidence rating Filter used to trace incident across meters in 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 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: November 6, 2002 [Page 15] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 4.2.2 Trace Authorization Message Description: This message is sent to the initiating NMS from the next upstream ISP's NMS to provide information on the trace status in the current network. Message Type 2 Time Stamp Incident Identifier ASN for originating ISP 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 meters in 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 manual administrator action taken to approve or disapprove the trace continuance. Moriarty Expires: November 6, 2002 [Page 16] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 4.3.3 Source Found Message Description: This message indicates that the source of the attack in this trace was located. Message Type 3 Time Stamp Incident Identifier ASN for originating ISP Incident number based on incremental tracking Trace number - used for multiple traces of a single incident Action Taken (multiple selections permitted) Value Meaning ______________________________________________ 0 No action at this time 1 Switch port blocked 2 Network segment blocked 3 Host 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 [Text field for True Source address information of attack and 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 ISP to act upon the discovery of the source of a trace should be included. The ISP 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 removed any Trojan or zombie on the system. Moriarty Expires: November 6, 2002 [Page 17] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 4.3.4 Example Upstream Trace The diagram below outlines the RID-DOS communication between NMS systems on different networks tracing an attack. Attack Dest ISP-1 ISP-2 ISP-3 Attack Src 1. Attack | Attack reported | detected 2. Initiate trace 3. Locate origin through upstream ISP. 4. o---Msg-Type-1------> 5. Trace Initiated 6. <-----Msg-Type-2----o 7. Locate origin through upstream ISP. 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 4.4 Message Structure: The TCP protocol would be a good candidate to provide a reliable transport mechanism for the messages sent between network management systems. The application for 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 2 share the same structure. Message type 3 differs after the incident identifier. The first 88 bytes include the consistent fields used in each packet type: ------------------------------------------------------------------- | Msg Type | Time Stamp | Incident Identifier | ------------------------------------------------------------------- 8-bit 32-bit 48-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 Moriarty Expires: November 6, 2002 [Page 18] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 Field 3: 48-bit field for Incident Identifier 16-bit field Autonomous System Number (ASN) 16-bit field for Incident number, rolls back to zero 16-bit field for Trace number 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: 304-bit field for Filter used in message type 1 and 2. Note: This field is unnecessary in message type 3, but must include space for all items listed below and unused items would be left blank for specific filters 128-bit Destination Internet IP address given in IPv6 format 128-bit Source Internet IP address given in IPv6 format 16-bit field for protocol number (8-bits needed) 16-bit field for destination port 16-bit field for source port Field 6: 2-bit field to indicate trace status in message type 3 Following 2 fields used in message type 1, 2, and 3: Field 6: 8-bit field Number of hops or contacts along the path of the trace Field 7: 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 ISP name and contact information. Note 2: A maximum of 7 identifiers may be listed within the size constraints of a TCP packet. 7 should 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 7 NMS systems listed, the originating NMS should 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. Used in Message Type 3: Field 8: 128-bit field given for true source address of attack Field 9: Optional Text Field 0-1076-bit text field used in message type 3 to provide additional attack information or contact information. 0-908-bits text field if the optional text field is used in message type 2 for NMS identification information. Moriarty Expires: November 6, 2002 [Page 19] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 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 ISPs in multiple countries. 4.5 Message Delivery and Security Considerations Security considerations should include the integrity and authorization of the messages sent between NMS systems. The communication between NMS systems should be authenticated and encrypted to ensure the integrity of the messages and the NMS systems involved in the trace. Using out-of band communications dedicated to ISP interaction would provide additional security as well as guaranteed bandwidth. This might be accomplished through logical paths defined over the existing network. It may be 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. In order to address the integrity and authenticity of messages, IPSec could be used to authenticate and encrypt the traffic sent between NMS systems with pre-defined trust relationships. 5.1 Security Considerations Communication between ISPs NMS must be protected. An out of band network, either logical or physical would prevent outside attacks. Authenticated encryption tunnels between stations would protect the data in transit as well as provide integrity of the data. 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 severity rating is low it may not be in the ISPs best interest to continue a trace. Moriarty Expires: November 6, 2002 [Page 20] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 Policy between ISPs must be established to provide guidelines for communication. The policy should include communication methods and fall back procedures. The Policy should establish a method to protect communications between NMS systems between all bordering ISPs. The trust relationships would have to extend to all bordering ISPs in order to be successful in tracing and stopping attacks. A fully meshed communication ability would provide the means for message type 3 to be sent to an initiating NMS. Other policy considerations include how the AS number and NMS IP address should 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 pre-shared in a table between cooperating networks. This information may be stored locally on NMS systems or a central database accessible on the secured network used for inter-ISP messaging on NMS. A Certificate Authority may be used to establish security associations between NMS systems. The method of passing the trace to subsequent networks eliminates the need for either granting access to remote entities to configure network equipment. This also prevents the need for sharing authentication information to the devices. 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.1 Summary Denials of service attacks have always been difficult to trace as a result of the spoofed sources, resource limitations, and bandwidth utilization problems. Methods to identify and trace attacks near real time are essential to thwarting attack attempts. ISPs 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 ISPs is essential in incident handling. 7.1 References [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. Moriarty Expires: November 6, 2002 [Page 21] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 [RFC1930] "Guidelines for creation, selection, and registration of an Autonomous System (AS)". J. Hawkinson and T. Bates. March 1996. [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. [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. ;login. November 2001. [4] 'MULTOPS: A Data-Structure For Bandwidth Attack Detection'. Thomer M. Gil, Massimiliano Poletta. ;login. November 2001. [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. Moriarty Expires: November 6, 2002 [Page 22] Internet-Draft DDoS Incident Handling: RID-DoS May 6, 2002 8.1 Acknowledgements Dr. Robert K. Cunningham, MIT Lincoln Laboratory David J. Fried, MIT Lincoln Laboratory Cynthia D. McLain, MIT Lincoln Laboratory Dr. William Streilein, MIT Lincoln Laboratory 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 Air Force." Moriarty Expires: November 6, 2002 [Page 23]