| DOTS | Y. Hayashi |
| Internet-Draft | NTT |
| Intended status: Informational | M. Chen |
| Expires: September 3, 2020 | CMCC |
| March 2, 2020 |
Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry
draft-hayashi-dots-telemetry-use-cases-00
Denial-of-service Open Threat Signaling (DOTS) Telemetry enriches the base DOTS protocols to assist the mitigator in using efficient DDoS-attack-mitigation techniques in a network. This document presents sample use cases for DOTS Telemetry: what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use these techniques.
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 September 3, 2020.
Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Denial-of-Service (DDoS), attacks such as volumetric attacks and resource-consumption attacks, are critical threats to be handled by service providers. When such DDoS attacks occur, service providers have to mitigate them immediately to protect or recover their services.
Therefore, for service providers to immediately protect their network services from DDoS attacks, DDoS mitigation needs to be automated. To automate DDoS-attack mitigation, multi-vendor components involved in DDoS-attack detection and mitigation should cooperate and support standard interfaces to communicate.
DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time signaling, threat-handling requests, and data filtering between the multi-vendor elements [I-D.ietf-dots-signal-channel][I-D.ietf-dots-data-channel]. Furthermore, DOTS Telemetry enriches the DOTS protocols with various telemetry attributes allowing optimal DDoS-attack mitigation [I-D.ietf-dots-telemetry]. This document presents sample use cases for DOTS Telemetry: what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use attack-mitigation techniques.
The readers should be familiar with the terms defined in [RFC8612]
In addition, this document uses the following terms:
This section describes DOTS-Telemetry use cases that use attributes included in DOTS Telemetry specifications.
Large-scale DDoS attacks, such as amplification attacks, often occur. Some transit providers have to mitigate large-scale DDoS attacks using DMS with limited resources, which is already deployed in their network.
The aim of this use case is to enable transit providers to use their DMS efficiently under volume-based DDoS attacks whose bandwidth is more than the available capacity of the DMS. To enable this, attack traffic of top talkers is redirected to the DMS preferentially by cooperation among forwarding nodes, flow collectors, and orchestrators. Figure 1 gives an overview of this use case.
(Internet Transit Provider)
+-----------+ +--------------+ e.g., SNMP
e.g., IPFIX +-----------+| DOTS | |<---
--->| Flow ||C<-->S| Orchestrator | e.g., BGP Flowspec
| collector |+ | |---> (Redirect)
+-----------+ +--------------+
+-------------+
e.g., IPFIX +-------------+| e.g., BGP Flowspec
<---| Forwarding ||<--- (Redirect)
| nodes ||
| || DDoS Attack
[ Target ]<============|===============================
[ or ] | ++=========================[top talker]
[ Targets ] | || ++======================[top talker]
+----|| ||---+
|| ||
|| ||
|/ |/
+----x--x----+
| DDoS | e.g., SNMP
| mitigation |<---
| system |
+------------+
* C is for DOTS client functionality
* S is for DOTS client functionality
Figure 1: Mitigating DDoS Attack Flow of Top-talker Preferentially
In this use case, the forwarding nodes always send statistics of traffic flow to the flow collectors by using monitoring functions such as IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors detect attack traffic and send (src_ip, dst_ip, bandwidth)-tuple information of the top talker to the orchestrator using the top-talkers attribute of DOTS Telemetry. The orchestrator then checks the available capacity of DMS by using a network management protocol such as SNMP[RFC3413]. After that, the orchestrator orders forwarding nodes to redirect as much of the top taker's traffic to the DMS as possible by dissemination of flow-specification-rule protocols such as BGP Flowspec[RFC5575].
In this case, the flow collector implements a DOTS client while the orchestrator implements a DOTS server.
Transit providers, which have a number of DMSs, usually deploy a DMS in various forms to satisfy their requirements; individual or clustered. In both forms, they can identify attributes of the DMSs such as total capacity, available capacity, and the last hop bandwidth.
The aim of this use case is to enable transit providers to select an optimal DMS for mitigation based on the bandwidth of attack traffic, capacity of a DMS, and the last hop bandwidth. Figure 2 gives an overview of this use case.
(Internet Transit Provider)
+-----------+ +--------------+ e.g., SNMP
e.g., IPFIX +-----------+| DOTS | |<---
--->| Flow ||C<-->S| Orchestrator | e.g., BGP
| collector |+ | |---> (Redirect)
+-----------+ +--------------+
+------------+
e.g., IPFIX +------------+| e.g., BGP
<---| Forwarding ||<--- (Redirect)
| nodes ||
| || DDoS Attack
[Target] | ++============================
[Target] | || ++========================
+-||--||-----+
|| ||
++====++ || (congested DMS)
|| || +-----------+
|| |/ | DMS3 |
|| +-----x------+ |<--- e.g., SNMP
|/ | DMS2 |--------+
+--x---------+ |<--- e.g., SNMP
| DMS1 |------+
| |<--- e.g., SNMP
+------------+
* C is for DOTS client functionality
* S is for DOTS client functionality
Figure 2: Optimal DMS selection for Mitigation
In this use case, the forwarding nodes always send statistics of traffic flow to the flow collectors by using monitoring functions such as IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors detect attack traffic and send (dst_ip, bandwidth)-tuple information to the orchestrator using the total-attack-traffic attribute of DOTS Telemetry. The orchestrator then checks the available capacity of the DMSs by using a network management protocol such as SNMP[RFC3413]. After that, the orchestrator chooses optimal DMS which each attack traffic should be redirected. The orchestrator then orders forwarding nodes to redirect the attack traffic to the optimal DMS by a routing protocol such as BGP[RFC4271]. The algorithm of selecting a DMS is out of the scope of this draft.
In this case, the flow collector implements a DOTS client while the orchestrator implements a DOTS server.
A transit-provider network, which adopts a mesh network, has multiple paths to convey attack traffic to a DMS. In this network, attack traffic can be conveyed while avoiding congested links by selecting an available path.
The aim of this use case is to enable transit providers to select an optimal path for redirecting attack traffic to a DMS according to the bandwidth of the attack traffic, total traffic, and total pipe capability. Figure 3 gives an overview of this use case.
(Internet Transit Provider)
+-----------+ +--------------+ DOTS
e.g., +-----------+| | |S<---
IPFIX | Flow || DOTS | Orchestrator |
-->| collector ||C<-->S| | e.g., BGP Flow spec
| |+ | |---> (Redirect)
+-----------+ +--------------+
DOTS +------------+ DOTS +------------+ e.g., IPFIX
--->C| Forwarding | --->C| Forwarding |--->
e.g., BGP Flow spec | node | | node |
(Redirect) --->| | | | DDoS Attack
[Target] | ++====================================
+-------||---+ +------------+
|| /
|| / (congested link)
|| /
DOTS +-||----------------+ e.g., BGP Flow spec
--->C| || Forwarding |<--- (Redirect)
| ++=== node |
+----||-------------+
|/
+--x-----------+
| DMS |
+--------------+
* C is for DOTS client functionality
* S is for DOTS client functionality
Figure 3: Best-path Selection for Redirection
In this use case, the forwarding nodes always send statistics of traffic flow to the flow collectors by using monitoring functions such as IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors detect attack traffic and send (dst_ip, bandwidth)-tuple information to the orchestrator using a total-attack-traffic attribute of DOTS Telemetry. On the other hands, forwarding nodes send bandwidth of total traffic passing the node and total pipe capability to the orchestrator using total-traffic and total-pipe-capability attributes of DOTS Telemetry. The orchestrator then selects an optimal path to which each attack-traffic flow should be redirected. After that, the orchestrator orders forwarding nodes to redirect the attack traffic to the optimal DMS by dissemination of flow-specification-rules protocols such as BGP Flowspec[RFC5575]. The algorithm of selecting a path is out of the scope of this draft.
Short but extreme volumetric attacks, such as pulse wave DDoS attacks, are threats to internet transit provider networks. It is difficult for them to mitigate an attack by DMS by redirecting attack flows because it may cause route flapping in the network. The practical way to mitigate short but extreme volumetric attacks is to offload a mitigation actions to a forwarding node.
The aim of this use case is to enable transit providers to mitigate short but extreme volumetric attacks and estimate the network-access success rate based on the bandwidth of attack traffic and total pipe capability. Figure 4 gives an overview of this use case.
(Internet Transit Provider)
+------------+ +----------------+
e.g., | Network | DOTS | Administrative |
Alert --->| Management |C<--->S| System | e.g., BGP Flow spec
| System | | |---> (Rate-Limit)
+------------+ +----------------+
+------------+ +------------+ e.g., BGP Flow spec
| Forwarding | | Forwarding |<--- (Rate-Limit X bps)
| node | | node |
| | | | DDoS & Normal traffic
[Target]<------------------------------------================
Pipe +------------+ +------------+ Attack Traffic
Capability Bandwidth
e.g., X bps e.g., Y bps
Network access success rate
e.g., X / (X + Y)
* C is for DOTS client functionality
* S is for DOTS client functionality
Figure 4: Short but Extreme Volumetric Attack Mitigation
In this use case, when DDoS attacks occur, the network management system receives alerts. It then sends the target ip address, pipe capability of the target's link, and bandwidth of the DDoS attack traffic to the administrative system using the target, total-pipe-capability and total-attack-traffic attributes of DOTS Telemetry. After that, the administrative system orders upper forwarding nodes to carry out rate-limit all traffic destined to the target based on the pipe capability by the dissemination of the flow -specification-rules protocols such as BGP Flowspec[RFC5575]. In addition, the administrative system estimates the network-access success rate of the target, which is calculated by total pipe capability / (total pipe capability + total attack traffic).
Some volumetric attacks, such as amplification attacks, can be detected with high accuracy by checking the layer-3 or layer-4 information of attack packets. These attacks can be detected and mitigated through cooperation among forwarding nodes and flow collectors using IPFIX[RFC7011]. On the other hand, it is necessary to inspect the layer-7 information of attack packets to detect attacks such as DNS Water Torture Attacks. Such attack traffic should be detected and mitigated at a DMS.
The aim of this use case is to enable transit providers to select a mitigation technique based on the type of attack traffic: amplification attack or not. To use such a technique, attack traffic is blocked at forwarding nodes or redirected to a DMS based on attack type through cooperation among forwarding nodes, flow collectors, and an orchestrator. Figure 5 gives an overview of this use case.
(Internet Transit Provider)
+-----------+ DOTS +--------------+ e.g.,
e.g., +-----------+|<---->| | BGP (Redirect)
IPFIX | Flow ||C S| Orchestrator | BGP Flowspec (Drop)
--->| collector |+ | |--->
+-----------+ +--------------+
+------------+ e.g., BGP (Redirect)
e.g., IPFIX +------------+| BGP Flowspec (Drop)
<---| Forwarding ||<---
| nodes || DDoS Attack
| ++=====||================
| || ||x<==============[e.g.,DNS Amp]
| || |+x<==============[e.g.,NTP Amp]
+-----||-----+
||
|/
+-----x------+
| DDoS |
| mitigation |
| system |
+------------+
* C is for DOTS client functionality
* S is for DOTS server functionality
Figure 5: DDoS Mitigation Based on Attack Type
In this use case, the forwarding nodes send statistics of traffic flow to the flow collectors by using a monitoring function such as IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors detect attack traffic and send (dst_ip, src_port, attack_type)-tuple information to the orchestrator the using attack-name attribute of DOTS Telemetry. The orchestrator then orders forwarding nodes to block the (dst_ip, src_port)-tuple flow of amp attack traffic by dissemination of flow-specification-rule protocols such as BGP Flowspec[RFC5575]. On the other hand, the orchestrator orders forwarding nodes to redirect other traffic than the amp attack traffic by a routing protocol such as BGP[RFC4271].
In this case, the flow collector implements a DOTS client while the orchestrator implements a DOTS server.
DDoS detection based on monitoring functions, such as IPFIX[RFC7011], is a lighter weight method of detecting DDoS attacks than DMSs in internet transit provider networks. On the other hand, DDoS detection based on the DMSs is a more accurate method of detecting DDoS attacks than DDoS detection based on flow monitoring.
The aim of this use case is to increases flow collector's detection accuracy by carrying out supervised machine-learning techniques based on the detection results of the DMSs. To use such a technique, forwarding nodes, flow collector, and a DMS should cooperate. Figure 5 gives an overview of this use case.
+-----------+
+-----------+| DOTS
e.g., IPFIX | Flow ||S<---
--->| collector ||
+-----------++
+------------+
e.g., IPFIX +------------+|
<---| Forwarding ||
| nodes || DDoS Attack
[ Target ] | ++==============================
| || ++===========================
| || || ++========================
+---||-|| ||-+
|| || ||
|/ |/ |/
DOTS +---X--X--X--+
--->C| DDoS |
| mitigation |
| system |
+------------+
* C is for DOTS client functionality
* S is for DOTS client functionality
Figure 6: Training Flow Collector Using Supervised Machine Learning
In this use case, the forwarding nodes always send statistics of traffic flow to the flow collectors by using monitoring functions such as IPFIX[RFC7011]. When DDoS attacks occur, DDoS orchestration use case[I-D.ietf-dots-use-cases] is carried out and the DMS mitigates all attack traffic destined for a target. The DDoS-mitigation system reports the (src_ip, dst_ip)-tuple information of the top talker to the orchestrator the using top-talkers attribute of DOTS Telemetry.
After mitigating a DDoS attack, the flow collector attaches teacher labels to the statistics of traffic flow based on the reports. The label shows normal traffic or attack name. The flow collector then carries out supervised machine learning to increase its detection accuracy, setting the statistics as an explanatory variable and setting the labels as an objective variable.
In this case, the DMS implements a DOTS client while the flow collector implements a DOTS server.
TBD
This document does not require any action from IANA.
The authors would like to thank among others brabra...
| [I-D.ietf-dots-data-channel] | Boucadair, M. and T. Reddy.K, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", Internet-Draft draft-ietf-dots-data-channel-31, July 2019. |
| [I-D.ietf-dots-signal-channel] | Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A. and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", Internet-Draft draft-ietf-dots-signal-channel-41, January 2020. |