Internet-Draft | SAV-D | October 2024 |
Cui, et al. | Expires 21 April 2025 | [Page] |
- Workgroup:
- Operations and Management Area Working Group
- Internet-Draft:
- draft-cui-savnet-anti-ddos-05
- Published:
- Intended Status:
- Informational
- Expires:
SAV-based Anti-DDoS Architecture
Abstract
Existing Source Address Validation (SAV) schemes can not effectively defend against IP Spoofing DDoS under incremental deployment. This document proposes SAV-based anti-DDoS architecture (SAV-D), a distributed defense architecture to enhance SAV's defense. The main idea of SAV-D is to collect and aggregate more threat data from existing SAV devices and then distribute crucial knowledge to widespread devices, thus significantly expanding defense across the entire network.¶
Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 21 April 2025.¶
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
1. Introduction
Distributed Denial-of-Service (DDoS) attacks have been a persistent cyber threat, where IP spoofing DDoS is one of the major contributors. According to CAIDA's Spoofer Project[CAIDA], 28.6% of IPv4 autonomous systems (excluding NAT), and 35.6% of IPv6 autonomous systems are still spoofable by September 2024. These statistical data presents the severe situation of spoof IP DDoS attack. Amplification DDoS typically exploit IP spoofing to generate large volumes of traffic with small requests, allowing attackers to overwhelm the target's resources while evading detection. Other volumetric DDoS attacks (e.g., TCP SYN Flooding [RFC4987]) also forge source IP addresses in order to drain the target's resources.¶
To eliminate IP spoofing, several Source Address Validation (SAV) schemes have been proposed, such as SAVI[RFC7039], uRPF[RFC3704] and EFP-uRPF[RFC8704]. However, the defense effectiveness of current SAV schemes highly depends on the SAV devices' deployment ratio. A large number of spoofed packets can only be prevented with a significantly high deployment ratio, but the incremental deployment process is often slow. One reason behind this is that uRPF and EFP-uRPF have issues with filtering accuracy in certain scenarios, leading the network managers being hesitate to enable SAV. Morever, SAV can prevent spoofed packets from being sent out, but it cannot provide protection for the deployers. The lack of direct benefits may also impede the deployment process. These reasons result in a limited SAV deployment, thus the defense effectiveness.¶
In the above context, to effectively defend against IP spoofing DDoS attacks and thus stimulating the deployment of SAV devices, it is essential to tackle the following limitations. Firstly, in amplification DDoS, the reflected packets sent to victims have the authentic src-IP, making them unfilterable by SAV devices. Secondly, although today's SAV mechanism can filter spoofed packets at local devices, the important threat data they provide has yet to be globally utilized. If victims were made comprehensive aware of the type of spoofing traffic targeting them, they could execute faster and more accurate countermeasures.¶
This document offers an SAV-based anti-DDoS architecture that eliminates the above limitations by incorporating the following advances.¶
-
SAV-honeynet based threat data collection. Each SAV device functions as a honeypot that not only drops spoofed packets but also records the spoofing characteristics and sends them to a centralized control plane.¶
-
Collaborative defense with both SAV and non-SAV devices. The control plane detects ongoing attacks and generates filtering rules. These rules are then distributed to both SAV and non-SAV devices along the attack paths to manipulate malicious traffic.¶
-
Threat information sharing with the victim-end. The control plane shares attack detection information and IP blocklists with victim-end defense systems to assist their mitigations.¶
Through the mechanisms of honeynet, data aggregation and distribution, SAV-D can fully leverage the value of SAV devices and threat data, resulting in a significant defense improvement.¶
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
2. SAV-D Architecture
+--------------------------------------------------------------+ | Control Plane (SAV-D Controller) | +--------------------------------------------------------------+ | +----------------+ +----------------+ +--------------+ | | | Detecting DDoS | |Generating Rules| |Issuing Rules | | | +----------------+ +----------------+ +--------------+ | | -\ -\ | | -/ -/ | | +----------------+ +----------------+ +--------------+ | | |Attack Situation| | Maintain IP | |Sharing Threat| | | | Awareness | | Blocklists | |Information | | | +----------------+ +----------------+ +--------------+ ... | +---------/\-------------------------------------++------------+ || +-------------------+| || |+------------------+| || || || +---------++-----------------\/--+ +-------------\/------------+ | Data Plane | | Data Plane (Legacy | | (SAV Devices) | | Devices,Victims' Defense) | +--------------------------------+ +---------------------------+ | +----------+ +---------------+ | | +---------------+ | | |Monitoring| | Filtering | | | | Filtering | | | +----------+ +---------------+ | | +---------------+ | | +---------------+ | | +---------------+ | | |Receiving Rules| | | |Receiving Rules| | | +---------------+ | | +---------------+ | | ... | | ... | +--------------------------------+ +---------------------------+ Figure 1: The SAV-based Anti-DDoS Architecture¶
The proposed SAV-D is shown in Figure 1, which can be deployed on both intra-domain and inter-domain metwork with SAV devices. It introduces a centralized control plane (i.e., the controller) that connects SAV devices, legacy devices, and victims' defense systems. The functions of the controller can be divided into three parts: attack detection, analysis and defense execution. The controllers can collect spoofing characteristics from SAV devices (as honeypots) and aggregate them for further analysis. From a whole viewpoint, the controller can detect ongoing attacks and generate filtering rules for both SAV and non-SAV devices. In addition, the controller can maintain IP blocklists based on the information reported by SAV devices, which can assist in detectiong DDoS attacks and generating filtering rules. And then the rules will be distributed to corresponding devices to perform filtering. Moreover, the controller will share the attack information with the victims' defense system to assist in their defense operations.¶
2.1. SAV Controller
The controller is a logical entity that can be implemented as a distributed or centralized cluster system. The placement of controllers may take several factors into consideration, including latency, resiliency, and load balancing to connected devices.¶
-
To collect spoofing information, the controller will passively receive the data sent from the certified SAV devices. The collected spoofing information should include but not limited to timestamp, 5-tuple (i.e., src-IP, dst-IP, src-port, dst-port, and protocol), TCP flag, packet size, and amounts. This information will be readily stored in a database for further analysis.¶
-
To analyze the aggregated statistics, the controller retrieves the spoofing information periodically (e.g., every 10 seconds). The spoofed packets information are analyzed based on their src-IP to detect reflection attacks or flooding attacks with certain algorithms. A large volume of spoofed packets using a specific protocol (e.g., NTP, DNS) is a clear indication that the src-IP is being targeted by reflection attacks. For flooding attacks, the possible evidence is a large number of spoofed packets with same target IP and different source IP. The detection results include the attack target, type, duration, malicious IP lists, etc. The detection algorithm should also fully consider the source of the forged source address packets. SAV devices deployed at different locations may report different levels of information.¶
-
Generating filtering rules based on detection results is a straightforward process. Before the reflection, the filtering rules are based on src-IP and ports. After reflection, the src-IP is the server's address, and the dst-IP is the victim's address. Considering the reflected packets are often much larger than legitimate packets, filtering rules could be generated based on dst-IP, ports, and packet size. The time required to generate filtering rules depends on the severity and duration of attacks.¶
-
Communicating with relevant devices consists of two folds. One fold is distributing filtering rules to SAV and legacy devices and receiving feedback from SAV devices. The other fold is to provide the victim's defense system with attack detection information, which is essential to efficiently stop the attack traffic. In addition, the controller may generate more high-level threat intelligence information with advanced statistical algorithms, such as geographic distribution statistics of IP blacklists, attribute statistics of forged IP, and so on. These attack information and situation can assist operators to analyze and fine tune the defense strategies.¶
2.2. SAV Device
The SAV devices refer to routers or switches that are capable of validating the source IP address through schemas including SAVI, uRPF, etc. Compared to simply dropping spoofed packets, SAV devices are required to selectively allow spoofed packets through if they do not match the filtering rules. This mechanism can be considered as a SAV-honeynet that records threat data related to spoofing.¶
-
The SAV device must register it to the controller when being installed, in which a unique identification number and other information (e.g., location, management IP address) may needed. Whenever a spoofed packet is detected, the SAV device will record its timestamp, 5-tuple, TCP flag, packet size, and so on. However, only if the spoofed packet matches existing filtering rules, will the packet be dropped. After a certain interval, the recorded data will be compressed and sent to the controller.¶
-
Modern devices are generally capable of filtering based on packet length and counting the number of filtered packets. Upon receiving filtering rules from the controller, the SAV device must install them into its data plane. The SAV device also needs to record the number of packets filtered by each rule. If a rule filters no packet during some periods, the rule will be automatically removed to save the rule's space.¶
2.3. Legacy Device
The commercial routers that are widely deployed in production are considered to be legacy devices. Access Control List (ACL) is universally supported in today's routers for packet filtering. Legacy devices can achieve extensive filtering by simply connecting their management interface to the controller and receiving the rules. Since ACLs may vary across legacy devices, filtering rules must be adapted to meet the specific requirements of each device. The legacy routers can join the SAV-D system by registering it to the controller with information similar to the SAV router. Once registered, the legacy routers can receive the filtering rules from the controller in a safe and trusted channel. These rules will be installed into the data plane. Similar to SAV devices, if a rule filters no packet during some period, the rule will be automatically removed.¶
2.4. Victims' Defense
Victim's defense can be a DDoS mitigation system, a dedicated DDoS defense device, or any system or device that can receive filtering rules and threat information. The Victim's defense operator can request access to the attack detection information related to themselves. Upon receiving the request, SAV-D controller can provide real-time updated details such as the attack target, type, duration, and malicious IP lists, which can be efficiently used for blocking malicious traffic. In an ideal situation, the defense system could provide an interface to directly receive the information and automatically perform corresponding filtering policies. In this way, these details can serve as auxiliary signals to boost the detection speed. This mechanism could improve the effectiveness of DDoS defense and incentivize more SAV deployment.¶
2.5. Connection Example
+-------------------------------+ +-------+ | +-------+ +-------+ | +-------+ | SR 1 +---+ | SC 1 +----+----+ SC 2 | +--+ SR 3 | +-------+ | +-------+ | +-------+ | +-------+ | | | +-------+ | +---+---+ | +-------+ | SR 2 +---+ | SC 3 | +--+ SR 4 | +-------+ | +-------+ | +-------+ +-------------------------------+ SR: SAV router SC: SAV-D controller Figure 2: Connection Example of SAV Devices¶
Figure 2 depicts a connection example of SAV-D system. 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 entity to the external. Realizing the full functionality of the SAV controller MAY require many computing and storage resources. As a result, the SAV controller can be built on 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.¶
2.6. Data transmission
Data transmission includes bidirectional data transmission of control plane and data plane. The monitoring information of the spoofed src-IP packets is transmitted from the data plane to the control plane. Following the existing definition of savnet, the monitoring information transmission protocol should follow YANG Data Model for Intra-domain and Inter-domain Source Address Validation. In the opposite direction, the filtering rules and threat information are transmitted. The transmission of filtering instructions can be referred to DOTS Telemetry[RFC8783], which describes the transmission requirements of collaborative filtering instructions. The threat information includes the attack detection resultant, victim IP address segmant and etc. [RFC9244] and [RFC8783] describe the transmission requirements for threat information, which can be the candidate protocol.¶
3. Workflow
The proposed SAV-D architecture can collaboratively defend the IP spoofing DDoS in a distributed pattern. The typical procedures are described as follows.¶
(i). The SAV routers validate and record the characteristics of spoofed packets, and periodically send this data to the logically centralized controller, where the global spoofing information is aggregated.¶
(ii). Based on the aggregated statistics, the controller can accurately detect whether there are ongoing IP spoofing attacks with the help of predefined algorithms.¶
(iii). Based on the detection results, the controller can generate defense policies for both SAV and non-SAV devices. The policies mainly involve filtering rules on 5-tuple and packet size.¶
(iv). For detected attacks, the defense policies will be distributed to all SAV and legacy devices. Moreover, the detection results will also be sent to the victim's defense system.¶
(v). The filtering rules will be installed on relevant devices to block the malicious packets. If a rule filters no packet during some period, the rule will be automatically removed.¶
4. Scalability
When there are large amounts of devices introduced into the SAV-D, the control plane could be implemented with hierarchical structure, where multiple sub-level controllers are in charge of the devices inside AS domains. The single top-level controller can exchange information (i.e., IP spoofing statistics and filtering rules) with these sub-level controllers. Additionally, a large number of attacks and filtering rules could introduce another scalability problem. One possible solution is to prioritize the mitigations of these attacks, where severe attacks will be tackled first so that the number of filtering rules will be limited to moderate scope.¶
5. IANA Considerations
This document includes no request to IANA.¶
6. Security Considerations
Adversaries may send forged IP spoofing statistics to the control plane or send forged filtering rules to SAV and legacy devices, which could cause severe harm to legitimate traffic. To avoid this situation, the information transmissions of SAV-D could be encrypted with certification. There could also be attacks directly on the SAV-D controllers. As common systems, security systems (e.g., firewalls) are essential to protect the controllers. In addition, hot-standby controllers can also significantly improve security and availability.¶
7. References
7.1. Normative References
- [RFC3704]
- Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, , <https://www.rfc-editor.org/rfc/rfc3704>.
- [RFC8704]
- Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, , <https://www.rfc-editor.org/rfc/rfc8704>.
- [RFC4987]
- Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, , <https://www.rfc-editor.org/rfc/rfc4987>.
- [RFC7039]
- Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, , <https://www.rfc-editor.org/rfc/rfc7039>.
- [RFC8783]
- Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", RFC 8783, DOI 10.17487/RFC8783, , <https://www.rfc-editor.org/rfc/rfc8783>.
- [RFC9244]
- Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M., and J. Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry", RFC 9244, DOI 10.17487/RFC9244, , <https://www.rfc-editor.org/rfc/rfc9244>.
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
- [RFC8174]
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
7.2. Informative References
- [CAIDA]
- "State of IP Spoofing", , <https://spoofer.caida.org/summary.php>.
Acknowledgements
Thanks to Linbo Hui, Yannan Hu, Wenyong Wang, Shuisong Hu, Haoran Luo, Linzhe Li for their contribution to this draft.¶