]> Tsinghua University

Beijing 100084 China cuiyong@tsinghua.edu.cn http://www.cuiyong.net/

Tsinghua University

Beijing 100084 China jianping@cernet.edu.cn

Zhongguancun Laboratory

Beijing 100094 China huilb@zgclab.edu.cn

Zhongguancun Laboratory

Beijing 100094 China zhanglei@zgclab.edu.cn

Routing SAVNET Working Group Source Address Validation DDoS Detection, Mitigation, and Traceback This document proposes the SAVA-based Anti-DDoS Architecture (SADA), which can efficiently detect, mitigate, and traceback Denial-of-Service (DDoS) attacks that spoof source addresses. The SADA consists of a distributed DDoS detection mechanism based on honeynets, a multi-stage DDoS mitigation mechanism, and a suspect-based DDoS traceback mechanism. By adopting the Source Address Validation Architecture (SAVA) of SAVNET and introducing the data plane and the control plane, the SADA makes minor changes to the SAVA while providing major benefits.

Introduction DDoS attacks using spoofing addresses are notorious on the Internet. The attackers command a large number of zombie hosts to forge the target's address and send bogus requests, after which the servers respond with magnified datagrams to the target, resulting in an amplification DDoS attacks. Some other DDoS attacks (e.g., TCP SYN Flooding Attacks ) also forge source IP addresses in order to drain the target's resources. These DDoS attacks are simple to carry out but can inflict significant damage. Their attack traffic is widely dispersed and similar to normal traffic, leading challenge to detect and mitigate. Furthermore, the spoofed addresses serve as a mask for the attackers, making it difficult to traceback the attackers. Some Source Address Validation (SAV) techniques have been proposed to defend against DDoS attacks. The current practice for achieving ingress filtering is uRPF , which includes strict uRPF and loose uRPF. Unfortunately, the strict uRPF often improperly blocks legitimate traffic under asymmetric routing, and the loose uRPF generally permits all received packets. EFP-uRPF makes the uRPF more flexible about directionality, while there are mechanisms that MAY lead to improper permit or improper block problems in specific scenarios. The SAVNET Working Group provides SAV techniques for intra-domain and inter-domain networks to resolve the problems raised above. It has been deployed for experimental practice and is promising to solve the SAV problem. However, these SAV techniques are still a long way from being able to defend against DDoS attacks. First, they only discard spoofing packets at local devices, lacking coordination to detect DDoS attacks with a global view. Second, only when these SAV techniques are widely deployed will they be able to eliminate DDoS attacks using spoofing addresses, which will take a long time. Third, there are limited incentives exist to encourage Internet Service Providers (ISPs) to widely deploy SAV devices. In the above context, this document offers a SAVA-based Anti-DDoS Architecture (SADA) that incorporates the following advances.

• A distributed DDoS detection mechanism based on honeynets. The SADA introduces a SAV controller for gathering spoofing statistics from SAV routers that act as honeynets. The SADA can detect DDoS attacks with a comprehensive analysis using aggregated information from distributed SAV routers.
• A multi-stage DDoS mitigation mechanism. By overviewing the DDoS attack with a comprehensive view, the mitigation policies can be deployed at multiple stages (i.e., near-source, middle, and near-target). These policies vary at different locations and can efficiently mitigate the attack.
• A suspect-based DDoS traceback mechanism. The SADA requires SAV routers to monitor the communication logs of suspicious hosts that have ever forged addresses. The communication logs will be analyzed to find the attackers.

The SADA can provide considerable advantages for DDoS attacks by fully adopting SAVA features with only minor changes. Even with a small number of SAV routers deployed, the SADA can deliver accurate DDoS detections across a larger area. As long as the attack traffic flows through the SAV domain, the SADA is able to mitigate it. With the aggregated communication logs of suspicious hosts, the SADA can also assist in tracing back the attacker. In addition, the SADA will provide a spoofing address database and a DDoS attacks database, both of which will be available for SAV domains and other domains. The above incentives MAY induce ISPs to widely deploy SAV devices, which will, in turn, stimulate a more valuable SADA system.

Terminology

• SADA: the SAVA-based Anti-DDoS Architecture.
• SAV router: a router that can validate source addresses, make statistics of suspicious hosts, and execute filtering policies.
• SAV controller: a server that communicates with SAV routers. It can detect, mitigate, and traceback DDoS attacks.
• SAV device: either a SAV router or a SAV controller.
• SAV domain: a network domain that has SAV routers deployed.
• suspect: a host that ever forged source addresses in the past is considered a suspect, also called a suspicious host.
• honeynet: consists of SAV routers that record the spoofing packets' statistics instead of always blocking them.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Architecture The proposed SADA is shown in Figure 1. The SADA consists of the data plane and the control plane, where the primary functions of the data plane are monitoring, measurement, and filtering, and the primary functions of the control plane are detecting the attacks, formulating defense strategies, and tracing back the attacks. The northbound interface is used to send statistics data to the control plane, and the southbound interface is used to receive defense strategies from the control plane. The two planes communicate with each other and work together to defend against DDoS attacks.

Distributed DDoS Detection Mechanism Based on Honeynets The data plane reflects the widely distributed SAV routers that serve as the architecture's foundation. When detecting packets using spoofed addresses, the SAV routers do not simply block them but record their statistics and behaviors, which is regarded as a honeynet. The SAV routers need periodically transmit the statistics data to the SAVA controller. Based on the statistics data aggregated from the data plane, the control plane determines whether there is an ongoing DDoS attack. The judgment MAY refer to the traffic volume, the number of distinct addresses, the protocol, and the port numbers. A convincing judgment results include factors such as the ongoing traffic volume, impacted scope, duration time, and so on.

Multi-stage DDoS Mitigation Mechanism The control plane represents the SAV controller, which is the core of the architecture. With the detailed judgment results, the control plane then formulates mitigation strategies for multiple stages. From the spatial perspective, the attack traffic can be divided into three stages of near-source, middle, and near-target. Mitigation MAY include various filtering mechanisms on SAV routers at different stages. After the mitigation strategies validating by the SAV controller, the mitigation instructions will be issued to SAV routers. The near-source SAV routers MAY directly filter the spoofed packets using the specific forged source address. The middle SAV routers MAY route the spoofed packets of specific target addresses and protocols into unreachable destinations. The near-target SAV routers MAY adopt other filtering techniques to block the malicious packets based on specific target address, protocol, and packet size. Such a multi-stage mechanism can mitigate the DDoS attack as much as possible.

Suspect-based DDoS Traceback Mechanism The data plane MUST record the communication logs of the suspicious host that forged source addresses in the past. The communication logs include the spoofing packets' IP addresses, port numbers, packet amounts, intervals, frequencies, and so on. These logs will be periodically transmitted to the SAV controller for further analysis. When DDoS attacks occur, zombie hosts with spoofing addresses are potentially communicating with the attackers. Analyzing the communication logs of these suspicious zombie hosts, the SAV controller is able to trace back the attacker.

Connection Example Figure 2 depicts a connection example of SAV devices. There are SAV routers distributed throughout the network, and they MUST communicate with the SAV controller in order to collaborate. This document suggests that each SAV router stores several records of the SAV controller for backup. Each SAV router MUST try to connect to its nearest SAV controller at all times. If the SAV router loses contact with the present controller, it MUST seek the next closest controller. Such a mechanism can assist SAV routers in maintaining connections to the best of their abilities. The SAV controller appears as a single server to the external. Realizing the full functionality of the SAV controller, it MAY require much computing and storage resources. As a result, the SAV controller can be built as clustered or distributed servers, where consistency and scalability are the primary concerns. Each SAV controller can communicate with many SAV routers and perform the corresponding functions.

Establish and Keep Communication SAV | | Router <---------------+ Controller | +------------+ +------------+ ]]> Figure 3: SAV Router and SAV Controller Establish and Keep Communications Given the broad deployment of SAV routers, each configured SAV router MUST automatically establish connections with a SAV controller. They MUST maintain contact after building connections. This document suggests that an OSPF-like approach be considered. Furthermore, the SAV router MUST be able to communicate with the SAV controller during DDoS attacks, and such a mechanism MAY refer to the DOTS Working Group .

Data Plane The data plane is primarily comprised of distributed SAV routers. SAV routers MAY be deployed in access networks, within Autonomous System (AS) domains, or at the AS domains boundary. The general features of SAV routers are the same wherever they are deployed and can be summarized as follows.

• Collect Spoofing Information. SAV routers need to collect the statistical data of packets with spoofed addresses. The information includes but is not limited to spoofed source addresses, destination addresses, port numbers, packet intervals, and frequencies.
• Collect information of suspicious hosts. When SAV routers detect a host forging source addresses, they MAY add the host to the list of suspicious hosts. The SAV routers MUST then monitor the communication logs of these suspicious hosts. The logs contain information that includes but is not limited to destination addresses, protocols, packet intervals, and frequencies.
• Receive and Execute Instructions. When the SAV controller issue the defense strategies, the SAV routers MUST respond appropriately. The response mainly consists of Access Control Lists (ACL) filtering and black-hole routing . SAV routers with various locations will perform different actions, such as filtering spoofed packets at the access network and black-hole routing at the AS domain boundary.
• Keep the Capacity for Escape. Attack traffic can sometimes exceed router links, resulting in disconnection from SAV routers to the SAV controller. To avoid the terrible circumstance, SAV routers MUST reserve a specified amount of bandwidth to maintain a continuous connection with the SAV controller.

Control Plane The control plane consists of the SAV controller that can be clustered or distributed servers. The SAV controller are responsible for detecting, mitigating, and tracing back DDoS attacks. They also provide spoofing address database and DDoS attacks database for others to reference. The following are the features of the SAV controller.

• Aggregate Spoofing Information. The SAV controller collects spoofing statistics from SAV routers everywhere and aggregates them for further analysis.
• Detect DDoS Attacks. The SAV controller MUST determine whether a DDoS attack is ongoing based on the aggregated information. The judgment results MUST specify the attack target, traffic volume, impacted scope, duration time, and so on.
• Formulate Defense Strategies. Based on judgment results, the SAV controller will devise the appropriate defense strategies. The defense mechanisms MAY include ACL-based filtering and black-hole routing, which vary on specific SAV routers according to their locations. The SAV controller then issues detailed defense instructions to individual SAV routers for execution.
• traceback Attacks. The SAV controller also aggregates information about suspicious hosts and analyzes the communication logs of these suspicious hosts to locate the attacker.
• Build and Maintain the databases. The SAV controller MUST build and maintain the spoofing address database at a global view, which will, in turn, help to detect DDoS attacks. The SAV controller MUST also build the DDoS attack database with the detection results, which contain the details about each attack, such as the attacker address, the target address, traffic volume, impacted scope, and duration time. Such a DDoS attack database will help to review the entire process of attacks.
• Provide Management Interface. Detecting, mitigating, and tracing back DDoS attacks MAY necessitate some manual settings in certain contexts. The management interface provides a convenient way to adjust these settings.

Incentives for Deployment

• Provide DDoS Defense Ability. Whenever the attack traffic flows through the SAV domains, the SAV devices can react to mitigate the attack. Any ISP that has deployed SAV devices can also obtain the spoofing address information and DDoS attacks information. With this accurate and real-time information, ISPs can decide how to take measures to protect their customers.
• Locate the Malicious Hosts and Reduce Costs. With deployed SAV devices, ISPs can identify the zombie hosts and help to traceback the attackers. These zombie hosts MAY incur additional traffic and energy costs. Locating and removing these malicious hosts not only help to reduce the costs but also improve the reputation of ISPs.

IANA Considerations This document includes no request to IANA.

Security Considerations

• When DDoS attacks appear, the SAV routers MAY perform different filtering policies at different locations. If SAV routers get a bogus mitigation policy, they MAY undertake destructive filtering activities.
• The SAV controller is the core of the SADA and MUST be secure at all times. The SAV controller SHOULD be able to defend themselves against any invasions.
• The SAV controller's functions are based on statistical data aggregated from the SAV routers. Fake statistical data might have unanticipated consequences.

References Normative References BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation. This memo defines an Experimental Protocol for the Internet community. This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations. This memo provides information for the Internet community. This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet. Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks. This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well. This memo provides information for the Internet community. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References

Acknowledgements TBD