Internet-Draft Problem Statement:Collaborative Defense October 2023
Cui, et al. Expires 25 April 2024 [Page]
Workgroup:
IETF
Internet-Draft:
draft-cui-anti-ddos-problem-statement-02
Published:
Intended Status:
Informational
Expires:
Authors:
Y. Cui
Tsinghua University
L. Li
Zhongguancun Laboratory
L. Zhang
Zhongguancun Laboratory

Problem Statement:Collaborative Defense of DDoS Attacks

Abstract

This document presents a problem statement on collaborative mitigation of Distributed Denial-of-Service (DDoS) attacks.
The evolving trends of DDoS attacks, including their types, intensities, and attack methods, pose formidable challenges to existing defense systems. This problem statement examines the current defense landscape, highlighting the distributed deployment of defense systems across various network positions and the imbalances in defense capabilities. Collaboration is crucial for effective DDoS attack mitigation, considering that a considerable number of attacks are spread across operators. The existing collaborative framework, DOTS, shows promise but requires addressing these challenges to enhance its efficacy. The existing collaborative framework DOTS demonstrates potential, but there are still numerous challenges in its practical application. This document aims to address these key issues that impact the implementation of collaborative technologies.

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 25 April 2024.

Table of Contents

1. Introduction

Distributed Denial of Service (DDoS) attacks have become a pervasive threat, causing significant disruptions to online services and networks. Collaborative mitigation strategies are needed to effectively counter these attacks. This problem statement aims to address the challenges and issues associated with collaborative defense against DDoS attacks.

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. DDoS Attacks

A Distributed Denial-of-Service (DDoS) attack is a method where multiple hosts are controlled to simultaneously target and disrupt the services, hindering legitimate users' access. DDoS attacks can be categorized into three main types based on their effects: resource exhaustion-based, link exhaustion-based, and network exhaustion-based attacks. Due to their low cost and significant impact, DDoS attacks have become increasingly popular, with attackers continuously improving their techniques and intensifying their attacks. The following trends characterize the evolution of DDoS attacks:

3. Current Defense Landscape

DDoS defense systems have been deployed at various nodes in the global network topology. From a network topology perspective, the deployment locations of DDoS defense systems can be classified as follows:

4. The Necessity of Collaboration

DDoS attacks have become an international threat, often traversing multiple LANs and involving various network operators, spanning different regions and countries. A global view of the internet is crucial for understanding the propagation behavior of malicious traffic. Moreover, in terms of DDoS attack mitigation, protecting the front-end of the malicious traffic propagation chain is more effective. This is because malicious traffic not only disrupts the services of target victims but can also impact critical links along the path, such as international ingress/egress points and interconnections between different ISPs. Additionally, with the increasing intensity and evolving tactics of DDoS attacks, relying solely on the defense capabilities at one network location is inadequate. Thus, collaboration among multiple defense systems upstream and downstream in the network is necessary. Based on the analysis above, we identify the following information that needs to be communicated through collaboration:

5. Existing Collaborative Methods

The DOTS framework[RFC8612] provides a foundation for collaborative defense DDoS attacks by facilitating threat signaling and coordinated mitigation actions. It enables the exchange of attack-related information, enhances situational awareness, and enables effective response coordination among involved parties. [RFC8811] describes the technical framework of DOTS. [RFC8782] and [RFC8816] describe the communication methods between DOTS clients and servers. [RFC8903], [RFC9005], and others provide use cases for using DOTS and its communication methods.

6. Current Collaboration Challenges

Through an analysis of practical issues encountered in DOTS applications, we have identified the following key challenges in current collaboration efforts:

7. IANA Considerations

This document includes no request to IANA.

8. Security Considerations

9. Normative References

[RFC8612]
Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open Threat Signaling (DOTS) Requirements", RFC 8612, DOI 10.17487/RFC8612, , <https://www.rfc-editor.org/rfc/rfc8612>.
[RFC8811]
Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., Teague, N., and R. Compton, "DDoS Open Threat Signaling (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, , <https://www.rfc-editor.org/rfc/rfc8811>.
[RFC8782]
Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 8782, DOI 10.17487/RFC8782, , <https://www.rfc-editor.org/rfc/rfc8782>.
[RFC8816]
Rescorla, E. and J. Peterson, "Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases", RFC 8816, DOI 10.17487/RFC8816, , <https://www.rfc-editor.org/rfc/rfc8816>.
[RFC8903]
Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use Cases for DDoS Open Threat Signaling", RFC 8903, DOI 10.17487/RFC8903, , <https://www.rfc-editor.org/rfc/rfc8903>.
[RFC9005]
Litkowski, S., Sivabalan, S., Tantsura, J., Hardwick, J., and C. Li, "Path Computation Element Communication Protocol (PCEP) Extension for Associating Policies and Label Switched Paths (LSPs)", RFC 9005, DOI 10.17487/RFC9005, , <https://www.rfc-editor.org/rfc/rfc9005>.
[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>.

Acknowledgements

Authors' Addresses

Yong Cui
Tsinghua University
Beijing, 100084
China
Linzhe Li
Zhongguancun Laboratory
Beijing, 100094
China
Lei Zhang
Zhongguancun Laboratory
Beijing, 100094
China