YANG Data Model for Extended DOTS

Introduction

Context and motivation DDoS attacks have been a persistent network security issue plaguing global network operators and software providers. With the growth of global networks, DDoS attacks have increased in scale, frequency, and the emergence of new types, leading to a heightened focus on coordinated attack response and standardization. defines the DDoS Open Threat Signaling (DOTS) protocol for coordinating responses to DDoS attacks. DOTS can be utilized by any device or software system involved in DDoS mitigation, allowing both parties involved in the coordination to exchange necessary information such as collaborative mitigation requests and monitoring data. As DDoS mitigation technologies evolve, DDoS protection devices and software systems have expanded their functionalities, yet DOTS has not been adapted to incorporate these updates. In order for collaborative mitigation parties to formulate more effective mitigation strategies and respond more quickly to collaborative mitigation requests, it is necessary to extend the functionality interface and parameter model of DOTS. This document defines three data models for extending the existing DOTS interfaces, enabling DOTS to support the transmission of crucial information required for collaborative mitigation.

2. Terminology 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. These capitalized words are used to signify the requirements for the DOTS protocols design. This document adopts the following terms: DDoS: A distributed denial-of-service attack in which traffic originating from multiple sources is directed at a target on a network. DDoS attacks are intended to cause a negative impact on the availability and/or functionality of an attack target. Denial-of-service considerations are discussed in detail in . Mitigation: A set of countermeasures enforced against traffic destined for the target or targets of a detected or reported DDoS attack, where countermeasure enforcement is managed by an entity in the network path between attack sources and the attack target. Mitigation methodology is out of scope for this document. Mitigator: An entity, typically a network element, capable of performing mitigation of a detected or reported DDoS attack. The means by which this entity performs these mitigations and how they are requested of it are out of scope for this document. The mitigator and DOTS server receiving a mitigation request are assumed to belong to the same administrative entity. DOTS client: A DOTS-aware software module responsible for requesting attack response coordination with other DOTS-aware elements. DOTS server: A DOTS-aware software module handling and responding to messages from DOTS clients.
The DOTS server enables mitigation on behalf of the DOTS client, if requested, by communicating the DOTS client's request to the mitigator and returning selected mitigator feedback to the requesting DOTS client.

Problem statement To illustrate the collaboration for DDoS mitigation systems, the following workflow should be established for efficient collaboration:

The client sends predetermined configuration information to the server, including but not limited to mitigation strategies and required mitigation resource capacity.
Upon receiving the predetermined configuration request, the server determines based on its own capabilities whether to accept the installation.
When collaboration is needed for mitigation, the client initiates a collaborative mitigation request to the server. The mitigation request should include important information such as attack characteristics, mitigation scope, and mitigation strategies.
The server receives the mitigation request and forwards it to the mitigation party, utilizing the information within to confirm the authenticity of the attack and decide on responding to the collaborative mitigation request.
The mitigation party formulates and executes the mitigation strategy. The server sends a confirmation response to the client.
Continual exchange of monitoring information can occur between the server and client. The mitigation party can dynamically adjust mitigation strategies based on the monitoring information.
After collaborative mitigation ceases, the server should send a mitigation report to the client.

To improve collaborative mitigation efficiency, it is essential to pre-configure mitigation strategies and mitigation resource capacities. These can assist clients in initiating requests to appropriate mitigation parties and enable mitigation parties to establish mitigation strategies. Currently, DOTS only supports the installation of ACL rules, lacking other widely used mitigation methods such as BGP Flowspec. Additionally, DOTS does not support the installation of mitigation resource capacity information, making it difficult for targets to identify the optimal collaborative mitigation party when facing attacks of different scales. Within the mitigation request data model defined in DOTS, only descriptions of the mitigation scope are included, such as IP addresses and protocols. In the absence of commercial cooperation, these basic information pieces are insufficient to help mitigation parties identify attacks associated with mitigation requests and develop appropriate mitigation strategies based on the attack situation. Therefore, it is necessary to define an extended attack description model in the signaling channel, allowing mitigation parties to quickly and accurately identify associated attacks. These attack characteristics can also guide mitigation parties in formulating reasonable mitigation strategies. When requesting mitigation, providing baseline information, mitigation suggestions, or specifying mitigation strategies is also essential. The key role of mitigation is to differentiate between attack packets and non-attack packets. The targeted entities usually have extensive learning experience on their normal business packets or statistical data, enabling them to accurately identify the differences between attacks and legitimate requests, thereby filtering attack traffic more accurately. Sharing baseline information, mitigation suggestions, and mitigation strategies can fully utilize the knowledge of the requesting party to help the mitigation party formulate effective mitigation strategies.

YANG Models

Extended YANG models for signal channel Figure 1: DOTS Extended Signal Channel Tree Structure file "ietf-dots-extended-signal-channel@2024-02-20.yang" module ietf-dots-extended-signal-channel { yang-version 1.0; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-extended-signal-channel";

The mitigation request should include a description of the attack details, such as the type and characteristics of the attack. This will help the mitigator to identify the attack related to the mitigation request and decide whether to respond to the mitigation request. The attack characteristics can also serve as the basis for formulating mitigation strategies. The mitigator can develop reasonable mitigation strategies based on the specific features of the attack, such as the port, packet-level characteristics, etc. Furthermore, by utilizing statistical features of the attack, such as peak packet rate, the mitigator can allocate appropriate mitigation resources.
In a mitigation request, it is optional to include the target's daily business baseline information, such as normal business ports and average packet length. This can assist the mitigator in comparing the differences between the normal baseline and attack characteristics, thus allowing them to select appropriate mitigation strategies.
A request to be cached may selectively carry cache relief information, including specific cache relief strategies and recommendations. Cache relief strategies are policies already installed on the server by the client in advance, while cache relief recommendations can be any potentially effective cache relief strategy or important information proposed by the client. Cache relief information can assist the cache relief party in devising appropriate cache relief strategies.

Extended YANG models for data channel Figure 2: DOTS Extended Data Channel Tree Structure file "ietf-dots-extended-data-channel@2024-02-20.yang" module ietf-dots-extended-data-channel { yang-version 1.0; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-extended-data-channel"; = ../lower-port' { error-message "The upper port number must be greater than or equal to the lower port number."; } description "Upper port number of the port range."; } } leaf packet-length-range { key "lower-packet-length"; description "Packet length range. When only 'min-length' is present, it represents an avarage length."; leaf min-length { type int32; description "Minimum length of the packets."; } leaf max-length { type int32; must '. >= ../min-length' { error-message "The minium length must be smaller than maximum length."; } description "Maximum length of the packets."; } } } grouping intelligence { description "Threat intelligence, such as IP and URI blacklist, botnet activity information, etc."; leaf type { type string; description "Types of threat intelligence."; } leaf type { type content; description "The specifics of the threat intelligence."; } } ]]> }

The data channel should support pre-deployed mitigation strategies for clients to choose from in case of attacks, as clients have a better understanding of the protection target's business model. Through the data channel, it is also important to proactively share information about mitigation resources, including available mitigation strategies and capacities provided by mitigation parties.

IANA Considerations This document includes no request to IANA.

Security Considerations