Internet DRAFT - draft-cui-anti-ddos-problem-statement
draft-cui-anti-ddos-problem-statement
IETF Y. Cui
Internet-Draft Tsinghua University
Intended status: Informational L. Li
Expires: 25 April 2024 L. Zhang
Zhongguancun Laboratory
23 October 2023
Problem Statement:Collaborative Defense of DDoS Attacks
draft-cui-anti-ddos-problem-statement-02
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.
Cui, et al. Expires 25 April 2024 [Page 1]
Internet-Draft Problem Statement:Collaborative Defense October 2023
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. DDoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Current Defense Landscape . . . . . . . . . . . . . . . . . . 3
4. The Necessity of Collaboration . . . . . . . . . . . . . . . 4
5. Existing Collaborative Methods . . . . . . . . . . . . . . . 4
6. Current Collaboration Challenges . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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.
Cui, et al. Expires 25 April 2024 [Page 2]
Internet-Draft Problem Statement:Collaborative Defense October 2023
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
Cui, et al. Expires 25 April 2024 [Page 3]
Internet-Draft Problem Statement:Collaborative Defense October 2023
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:
Cui, et al. Expires 25 April 2024 [Page 4]
Internet-Draft Problem Statement:Collaborative Defense October 2023
* 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>.
Cui, et al. Expires 25 April 2024 [Page 5]
Internet-Draft Problem Statement:Collaborative Defense October 2023
[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
Yong Cui
Tsinghua University
Beijing, 100084
China
Email: cuiyong@tsinghua.edu.cn
URI: http://www.cuiyong.net/
Linzhe Li
Zhongguancun Laboratory
Beijing, 100094
China
Cui, et al. Expires 25 April 2024 [Page 6]
Internet-Draft Problem Statement:Collaborative Defense October 2023
Email: lilz@zgclab.edu.cn
Lei Zhang
Zhongguancun Laboratory
Beijing, 100094
China
Email: zhanglei@zgclab.edu.cn
Cui, et al. Expires 25 April 2024 [Page 7]
