Problem Statement:Collaborative Defense of DDoS Attacks

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.¶

Copyright Notice

Copyright (c) 2023 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.¶

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.¶

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:¶

• Increase in peak and average attack traffic, reaching terabit-level peak volume.¶

• Rapid surge in attack traffic, capable of escalating to 800 Gbps within seconds.¶

• Emergence of combination attacks as the mainstream approach, where attackers employ multiple attack methods concurrently or sequentially.¶

• Continual emergence of new attack techniques, such as leveraging novel vulnerabilities or using innovative means to exploit weaknesses in defense systems. These evolving DDoS attack trends pose significant challenges to current DDoS mitigation systems.¶

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:¶

• International ingress/egress points: These critical nodes handle the exchange of network packets between different countries and regions. Typically, they deploy DDoS mitigation capabilities like blackhole routing and BGP Flowspec.¶

• ISP backbone and metropolitan networks: These networks possess abundant resources and robust mitigation capabilities to handle high-volume attacks. However, due to the substantial volume of network traffic, traffic analysis can be time-consuming.¶

• Software service providers: As the last line of defense, these providers have detection capabilities for various attacks. However, limited resources are allocated for mitigation due to cost constraints. The internet is a highly complex and extensive network composed of numerous LANs (Local Area Networks). Different LANs have different owners, varying in scale and DDoS defense resource allocations.¶

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:¶

• Attack details, including ongoing and historical attacks.¶

• Malicious IP addresses or URIs.¶

• Threat intelligence.¶

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:¶

• Lack of consensus on attack definitions: Currently, there is no unified standard for categorizing and naming DDoS attacks. This lack of consensus regarding attack definitions may lead to misunderstandings between mitigators and requesters when transmitting collaborative information. Establishing attack definitions would help both parties better define collaboration requirements and available capabilities.¶

• Absence of attack type-based collaborative data models: While DOTS provides parameters for describing attack details, the importance of specific attack detail parameters varies depending on the type of DDoS attack. For example, source IP address is crucial for reflection-based attacks but may not be necessary for flooding attacks. To enhance collaboration efficiency, it is essential to define collaborative data models based on attack types, including attack details and mitigation specifics.¶

• Lack of specific scenario guidance for collaborative information transmission: Mitigation requesters often lack a comprehensive understanding of defense capabilities at different network locations. Providing guidance for collaborative information transmission methods based on specific collaboration scenarios allows mitigators to understand when to initiate mitigation requests and which mitigation capabilities they should offer. In conclusion, addressing these challenges will improve the effectiveness of collaborative DDoS mitigation and provide better protection against the growing threat of DDoS attacks.¶

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, May 2019, <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, August 2020, <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, May 2020, <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, February 2021, <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, May 2021, <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, March 2021, <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, March 1997, <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, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgements

Authors' Addresses