DOTS Y. Hayashi
Internet-Draft NTT
Intended status: Informational M. Chen
Expires: May 22, 2021 Li. Su
CMCC
November 18, 2020
Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry
draft-ietf-dots-telemetry-use-cases-01
Abstract
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.
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 May 22, 2021.
Copyright Notice
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
Hayashi, et al. Expires May 22, 2021 [Page 1]
Internet-Draft DOTS Telemetry Use Cases November 2020
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. DDoS Mitigation Based on Attack Traffic Bandwidth . . . . 3
3.1.1. Mitigating Attack Flow of Top-talker Preferentially . 3
3.1.2. Optimal DMS Selection for Mitigation . . . . . . . . 5
3.1.3. Best-path Selection for Redirection . . . . . . . . . 6
3.1.4. Short but Extreme Volumetric Attack Mitigation . . . 8
3.2. DDoS Mitigation Based on Attack Type . . . . . . . . . . 9
3.2.1. Selecting Mitigation Technique . . . . . . . . . . . 9
3.3. Setting up for Detection Based on Attack Detail or
Baseline . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Supervised Machine Learning of Flow Collector . . . . 11
3.3.2. Unsupervised Machine Learning of Flow Collector . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
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
Hayashi, et al. Expires May 22, 2021 [Page 2]
Internet-Draft DOTS Telemetry Use Cases November 2020
[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.
2. Terminology
The readers should be familiar with the terms defined in [RFC8612]
In addition, this document uses the following terms:
Top-talker: A top N list of attackers who attack the same target or
targets. The list is ordered in terms of a two-tuple bandwidth
such as bps or pps.
Supervised Machine Learning: A machine-learning technique that maps
an input to an output based on example input-output pairs.
Unsupervised Machine Learning: Unsupervised Learning is a machine
learning technique in which the users do not need to supervise the
model.
3. Use Cases
This section describes DOTS-Telemetry use cases that use attributes
included in DOTS Telemetry specifications.
3.1. DDoS Mitigation Based on Attack Traffic Bandwidth
3.1.1. Mitigating Attack Flow of Top-talker Preferentially
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.
Hayashi, et al. Expires May 22, 2021 [Page 3]
Internet-Draft DOTS Telemetry Use Cases November 2020
(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 target-
prefix and 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.
Hayashi, et al. Expires May 22, 2021 [Page 4]
Internet-Draft DOTS Telemetry Use Cases November 2020
3.1.2. Optimal DMS Selection for Mitigation
Transit providers, which have a number of DMSs, can deploy the DMSs
in clustered form. In the form, they can select DMS to be used to
mitigate DDoS attack under attack time.
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. 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 target-prefix and total-attack-traffic
attribute of DOTS Telemetry. The orchestrator then checks the
Hayashi, et al. Expires May 22, 2021 [Page 5]
Internet-Draft DOTS Telemetry Use Cases November 2020
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.
3.1.3. Best-path Selection for Redirection
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.
Hayashi, et al. Expires May 22, 2021 [Page 6]
Internet-Draft DOTS Telemetry Use Cases November 2020
(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 target-prefix and 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.
Hayashi, et al. Expires May 22, 2021 [Page 7]
Internet-Draft DOTS Telemetry Use Cases November 2020
3.1.4. Short but Extreme Volumetric Attack Mitigation
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. Furthermore, the aim is to
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-prefix, 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
Hayashi, et al. Expires May 22, 2021 [Page 8]
Internet-Draft DOTS Telemetry Use Cases November 2020
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).
3.2. DDoS Mitigation Based on Attack Type
3.2.1. Selecting Mitigation Technique
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.
Hayashi, et al. Expires May 22, 2021 [Page 9]
Internet-Draft DOTS Telemetry Use Cases November 2020
(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, attack_type)-tuple information to
the orchestrator the using vendor-id and attack-id attribute of DOTS
Telemetry. The orchestrator then resolves abused port and 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.
Hayashi, et al. Expires May 22, 2021 [Page 10]
Internet-Draft DOTS Telemetry Use Cases November 2020
3.3. Setting up for Detection Based on Attack Detail or Baseline
3.3.1. Supervised Machine Learning of Flow Collector
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
attack traffic or DDoS attacks bettr than flow monitoring.
The aim of this use case is to increases flow collector's detection
accuracy by carrying out supervised machine-learning techniques
according to attack detail reported by 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 Supervised Machine Learning of Flow Collector
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
Hayashi, et al. Expires May 22, 2021 [Page 11]
Internet-Draft DOTS Telemetry Use Cases November 2020
mitigates all attack traffic destined for a target. The DDoS-
mitigation system reports the vendor-id, attack-id and top-talker to
the flow collector using DOTS telemetry.
After mitigating a DDoS attack, the flow collector attaches teacher
labels, which shows normal traffic or attack type, to the statistics
of traffic flow of top-talker based on the reports. 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.
3.3.2. Unsupervised Machine Learning of Flow Collector
DMSs can detect DDoS attack traffic, which means DMSs can also
identify clean traffic. The aim of this use case is to carry out
unsupervised machine-learning for anomarly detection according to
baseline reported by DMSs. To use such a technique, forwarding
nodes, flow collector, and a DMS should cooperate. Figure 7 gives an
overview of this use case.
Hayashi, et al. Expires May 22, 2021 [Page 12]
Internet-Draft DOTS Telemetry Use Cases November 2020
+-----------+
+-----------+|
DOTS | Flow ||
--->S| collector ||
+-----------++
+------------+
+------------+|
| Forwarding ||
| nodes || Traffic
[ Dst ] <========================++==============================
| || ||
| || |+
+---||-------+
||
|/
DOTS +---X--------+
--->C| DDoS |
| mitigation |
| system |
+------------+
* C is for DOTS client functionality
* S is for DOTS client functionality
Figure 7: Training Unsupervised Machine Learning of Flow Collector
In this use case, the forwarding nodes carry out mirroring traffic
destined a dst ip address. The DMS then identifies clean traffic and
reports the baseline attributes to the flow collector using DOTS
telemetry.
The flow collector then carries out unsupervised machine learning to
be able to carry out anomarly detection.
In this case, the DMS implements a DOTS client while the flow
collector implements a DOTS server.
4. Security Considerations
TBD
5. IANA Considerations
This document does not require any action from IANA.
Hayashi, et al. Expires May 22, 2021 [Page 13]
Internet-Draft DOTS Telemetry Use Cases November 2020
6. Acknowledgement
TBD
7. References
7.1. Normative References
[I-D.ietf-dots-telemetry]
Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c.,
and J. Shallow, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-14
(work in progress), November 2020.
[I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
L., and K. Nishizuka, "Use cases for DDoS Open Threat
Signaling", draft-ietf-dots-use-cases-25 (work in
progress), July 2020.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62,
RFC 3413, DOI 10.17487/RFC3413, December 2002,
<https://www.rfc-editor.org/info/rfc3413>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[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/info/rfc8612>.
Hayashi, et al. Expires May 22, 2021 [Page 14]
Internet-Draft DOTS Telemetry Use Cases November 2020
7.2. Informative References
[I-D.ietf-dots-data-channel]
Boucadair, M. and T. Reddy.K, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Data Channel
Specification", draft-ietf-dots-data-channel-31 (work in
progress), 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", draft-
ietf-dots-signal-channel-41 (work in progress), January
2020.
Authors' Addresses
Yuhei Hayashi
NTT
3-9-11, Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Email: yuuhei.hayashi@gmail.com
Meiling Chen
CMCC
32, Xuanwumen West
BeiJing, BeiJing 100053
China
Email:
chenmeiling@chinamobile.com
Hayashi, et al. Expires May 22, 2021 [Page 15]
Internet-Draft DOTS Telemetry Use Cases November 2020
Li Su
CMCC
32, Xuanwumen West
BeiJing
100053
China
Email:
suli@chinamobile.com
Hayashi, et al. Expires May 22, 2021 [Page 16]
