DOTS Telemetry Use Cases: Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry
Using detailed attack information to mitigate DDoS attacks more efficiently.
Hayashi, Y., Chen, M., and L. Su, "Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry", RFC 9387, DOI 10.17487/RFC9387, April 2023, <https://www.rfc-editor.org/info/rfc9387>.
@misc{rfc9387,
series = {Request for Comments},
number = 9387,
howpublished = {RFC 9387},
publisher = {RFC Editor},
doi = {10.17487/RFC9387},
url = {https://www.rfc-editor.org/info/rfc9387},
author = {Y. Hayashi and M. Chen and L. Su},
title = {{Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry}},
pagetotal = 26,
year = 2023,
month = apr,
} RFC text
Contents
Internet Engineering Task Force (IETF) Y. Hayashi
Request for Comments: 9387 NTT
Category: Informational M. Chen
ISSN: 2070-1721 L. Su
China Mobile
April 2023
Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry
Abstract
DDoS 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. It discusses 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 document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9387.
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. Terminology
3. Telemetry Use Cases
3.1. Mitigation Resources Assignment
3.1.1. Mitigating Attack Flow of Top Talker Preferentially
3.1.2. DMS Selection for Mitigation
3.1.3. Path Selection for Redirection
3.1.4. Short but Extreme Volumetric Attack Mitigation
3.1.5. Selecting Mitigation Technique Based on Attack Type
3.2. Detailed DDoS Mitigation Report
3.3. Tuning Mitigation Resources
3.3.1. Supervised Machine Learning of Flow Collector
3.3.2. Unsupervised Machine Learning of Flow Collector
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Authors' Addresses
1. Introduction
Distributed Denial-of-Service (DDoS) attacks, such as volumetric
attacks and resource-consuming 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.
For service providers to immediately protect their network services
from DDoS attacks, DDoS mitigation needs to be highly automated. To
that aim, multivendor components involved in DDoS attack detection
and mitigation should cooperate and support standard interfaces.
DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time
signaling, threat-handling requests, and data filtering between the
multivendor elements [RFC9132] [RFC8783]. DOTS telemetry enriches
the DOTS protocols with various telemetry attributes allowing optimal
DDoS attack mitigation [RFC9244]. This document presents sample use
cases for DOTS telemetry to enhance the overview and the purpose
described in [RFC9244]. This document also presents what components
are deployed in the network, how they cooperate, and what information
is exchanged to effectively use attack-mitigation techniques.
2. Terminology
Readers should be familiar with the terms defined in [RFC8612],
[RFC8903], and [RFC9244].
In addition, this document uses the following terms:
Supervised Machine Learning: A machine-learning technique in which
labeled data is used to train the algorithms (the input and output
data are known).
Unsupervised Machine Learning: A machine-learning technique in which
unlabeled data is used to train the algorithms (the data has no
historical labels).
3. Telemetry Use Cases
This section describes DOTS telemetry use cases that use telemetry
attributes included in the DOTS telemetry specification [RFC9244].
The following subsections assume that once the DOTS signal channel is
established, DOTS clients will proceed with the telemetry setup
configuration detailed in Section 7 of [RFC9244]. The following
telemetry parameters are used:
* "measurement-interval" defines the period during which percentiles
are computed.
* "measurement-sample" defines the time distribution for measuring
values that are used to compute percentiles.
3.1. Mitigation Resources Assignment
3.1.1. Mitigating Attack Flow of Top Talker Preferentially
Some transit providers have to mitigate large-scale DDoS attacks
using DDoS Mitigation Systems (DMSes) with limited resources that are
already deployed in their network. For example, recently reported
large DDoS attacks exceeded several Tbps [DOTS_Overview].
This use case enables transit providers to use their DMS efficiently
under volume-based DDoS attacks whose volume is more than the
available capacity of the DMS. To enable this, the 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. Figure 2 provides an
example of a DOTS telemetry message body that is used to signal top
talkers (2001:db8:1::/48 and 2001:db8:2::/48).
(Internet Transit Provider)
+-----------+ +--------------+ SNMP or YANG/NETCONF
IPFIX +-----------+| DOTS | |<---
--->| Flow ||C<-->S| Orchestrator | BGP Flowspec
| collector |+ | |---> (Redirect)
+-----------+ +--------------+
+-------------+
IPFIX +-------------+| BGP Flowspec (Redirect)
<---| Forwarding ||<---
| nodes ||
| || DDoS Attack
[ Target(s) ]<==========================================
| ++=========================[top talker]
| || ++======================[top talker]
+----|| ||----+
|| ||
|| ||
|/ |/
+----x--x----+
| DDoS | SNMP or YANG/NETCONF
| mitigation |<---
| system |
+------------+
C: DOTS client functionality
S: DOTS server functionality
Figure 1: Mitigating Attack Flow of Top Talker Preferentially
{
"ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [
{
"target": {
"target-prefix": [
"2001:db8::1/128"
]
},
"total-attack-traffic-protocol": [
{
"protocol": 17,
"unit": "megabit-ps",
"mid-percentile-g": "900"
}
],
"attack-detail": [
{
"vendor-id": 32473,
"attack-id": 77,
"start-time": "1645057211",
"attack-severity": "high",
"top-talker":{
"talker": [
{
"source-prefix": "2001:db8:1::/48",
"total-attack-traffic": [
{
"unit": "megabit-ps",
"mid-percentile-g": "100"
}
]
},
{
"source-prefix": "2001:db8:2::/48",
"total-attack-traffic": [
{
"unit": "megabit-ps",
"mid-percentile-g": "90"
}
]
}
]
}
}
]
}
]
}
}
Figure 2: Example of Message Body to Signal Top Talkers
The forwarding nodes send traffic statistics to the flow collectors,
e.g., using IP Flow Information Export (IPFIX) [RFC7011]. When DDoS
attacks occur, the flow collectors identify the attack traffic and
send information about the top talkers to the orchestrator using the
"target-prefix" and "top-talkers" DOTS telemetry attributes. The
orchestrator then checks the available capacity of the DMSes using a
network management protocol, such as the Simple Network Management
Protocol (SNMP) [RFC3413] or YANG with the Network Configuration
Protocol (YANG/NETCONF) [RFC7950]. After that, the orchestrator
orders the forwarding nodes to redirect as much of the top talker's
traffic to the DMSes as they can handle by dissemination of Flow
Specifications using tools such as Border Gateway Protocol
Dissemination of Flow Specification Rules (BGP Flowspec) [RFC8955].
The flow collector implements a DOTS client while the orchestrator
implements a DOTS server.
3.1.2. DMS Selection for Mitigation
Transit providers can deploy their DMSes in clusters. Then, they can
select the DMS to be used to mitigate a DDoS attack at the time of an
attack.
This use case enables transit providers to select a DMS with
sufficient capacity for mitigation based on the volume of the attack
traffic and the capacity of the DMS. Figure 3 gives an overview of
this use case. Figure 4 provides an example of a DOTS telemetry
message body that is used to signal percentiles for total attack
traffic.
(Internet Transit Provider)
+-----------+ +--------------+ SNMP or YANG/NETCONF
IPFIX +-----------+| DOTS | |<---
--->| Flow ||C<-->S| Orchestrator | BGP (Redirect)
| collector |+ | |--->
+-----------+ +--------------+
+------------+
IPFIX +------------+| BGP (Redirect)
<---| Forwarding ||<---
| nodes ||
| || DDoS Attack
[Target A] | ++=================== [Destined for Target A]
[Target B] | || ++=============== [Destined for Target B]
+-||--||-----+
|| ||
++====++ || (congested DMS)
|| || +-----------+
|| |/ | DMS3 |
|| +-----x------+ |<--- SNMP or YANG/NETCONF
|/ | DMS2 |--------+
+--x---------+ |<--- SNMP or YANG/NETCONF
| DMS1 |------+
| |<--- SNMP or YANG/NETCONF
+------------+
C: DOTS client functionality
S: DOTS server functionality
Figure 3: DMS Selection for Mitigation
{
"ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [
{
"target": {
"target-prefix": [
"192.0.2.3/32"
]
},
"total-attack-traffic": [
{
"unit": "megabit-ps",
"low-percentile-g": "600",
"mid-percentile-g": "800",
"high-percentile-g": "1000",
"peak-g":"1100",
"current-g":"700"
}
]
}
]
}
}
Figure 4: Example of Message Body with Total Attack Traffic
The forwarding nodes send traffic statistics to the flow collectors,
e.g., using IPFIX. When DDoS attacks occur, the flow collectors
identify the attack traffic and send information about the attack
traffic volume to the orchestrator using the "target-prefix" and
"total-attack-traffic" DOTS telemetry attributes. The orchestrator
then checks the available capacity of the DMSes using a network
management protocol, such as the Simple Network Management Protocol
(SNMP) [RFC3413] or YANG with the Network Configuration Protocol
(YANG/NETCONF) [RFC7950]. After that, the orchestrator selects a DMS
with sufficient capacity to which attack traffic should be
redirected. For example, a simple DMS selection algorithm can be
used to choose a DMS whose available capacity is greater than the
"peak-g" telemetry attribute indicated in the DOTS telemetry message.
The orchestrator orders the appropriate forwarding nodes to redirect
the attack traffic to the DMS relying upon routing policies, such as
BGP [RFC4271].
The detailed DMS selection algorithm is out of the scope of this
document.
The flow collector implements a DOTS client while the orchestrator
implements a DOTS server.
3.1.3. Path Selection for Redirection
A transit provider network has multiple paths to convey attack
traffic to a DMS. In such a network, the attack traffic can be
conveyed while avoiding congested links by adequately selecting an
available path.
This use case enables transit providers to select a path with
sufficient bandwidth for redirecting attack traffic to a DMS
according to the bandwidth of the attack traffic and total traffic.
Figure 5 gives an overview of this use case. Figure 6 provides an
example of a DOTS telemetry message body that is used to signal
percentiles for total traffic and total attack traffic.
(Internet Transit Provider)
+-----------+ +--------------+ DOTS
+-----------+| | |S<---
IPFIX | Flow || DOTS | Orchestrator |
-->| collector ||C<-->S| | BGP Flowspec (Redirect)
| |+ | |--->
+-----------+ +--------------+
DOTS +------------+ DOTS +------------+ IPFIX
--->C| Forwarding | --->C| Forwarding |--->
BGP Flowspec | node | | node |
(Redirect) --->| | | | DDoS Attack
[Target] | ++====================================
+-------||---+ +------------+
|| /
|| / (congested link)
|| /
DOTS +-||----------------+ BGP Flowspec (Redirect)
--->C| || Forwarding |<---
| ++=== node |
+----||-------------+
|/
+--x-----------+
| DMS |
+--------------+
C: DOTS client functionality
S: DOTS server functionality
Figure 5: Path Selection for Redirection
{
"ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [
{
"target": {
"target-prefix": [
"2001:db8::1/128"
]
},
"total-traffic": [
{
"unit": "megabit-ps",
"mid-percentile-g": "1300",
"peak-g": "800"
}
],
"total-attack-traffic": [
{
"unit": "megabit-ps",
"low-percentile-g": "600",
"mid-percentile-g": "800",
"high-percentile-g": "1000",
"peak-g": "1100",
"current-g": "700"
}
]
}
]
}
}
Figure 6: Example of Message Body with Total Attack Traffic and
Total Traffic
The forwarding nodes send traffic statistics to the flow collectors,
e.g., using IPFIX. When DDoS attacks occur, the flow collectors
identify attack traffic and send information about the attack traffic
volume to the orchestrator using the "target-prefix" and "total-
attack-traffic" DOTS telemetry attributes. The underlying forwarding
nodes send the volume of the total traffic passing the node to the
orchestrator using the "total-traffic" telemetry attributes. The
orchestrator then selects a path with sufficient bandwidth to which
the flow of attack traffic should be redirected. For example, a
simple selection algorithm can be used to choose a path whose
available capacity is greater than the "peak-g" telemetry attribute
that was indicated in a DOTS telemetry message. After that, the
orchestrator orders the appropriate forwarding nodes to redirect the
attack traffic to the DMS by dissemination of Flow Specifications
using tools such as BGP Flowspec [RFC8955].
The detailed path selection algorithm is out of the scope of this
document.
The flow collector and forwarding nodes implement a DOTS client while
the orchestrator implements a DOTS server.
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. These
attacks start from zero and go to maximum values in a very short time
span. The attacks go back to zero and then back to maximum values,
repeating in continuous cycles at short intervals. It is difficult
for transit providers to mitigate such an attack with their DMSes by
redirecting attack flows because this may cause route flapping in the
network. The practical way to mitigate short but extreme volumetric
attacks is to offload mitigation actions to a forwarding node.
This use case enables 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 the attack traffic.
Figure 7 gives an overview of this use case. Figure 8 provides an
example of a DOTS telemetry message body that is used to signal total
pipe capacity. Figure 9 provides an example of a DOTS telemetry
message body that is used to signal various percentiles for total
traffic and total attack traffic.
(Internet Transit Provider)
+------------+ +----------------+
| Network | DOTS | Administrative | BGP Flowspec
Alert----->| Management |C<--->S| System | (Rate-Limit)
| System | | |--->
+------------+ +----------------+
BGP Flowspec
+------------+ +------------+ (Rate-Limit X bps)
| Forwarding | | Forwarding |<---
| node | | node |
Link1 | | | | DDoS & Normal traffic
[Target]<------------------------------------================
Pipe +------------+ +------------+ Attack Traffic
Capability Bandwidth
X bps Y bps
Network-access success rate
X / (X + Y)
C: DOTS client functionality
S: DOTS server functionality
Figure 7: Short but Extreme Volumetric Attack Mitigation
{
"ietf-dots-telemetry:telemetry-setup": {
"telemetry": [
{
"total-pipe-capacity": [
{
"link-id": "link1",
"capacity": "1000",
"unit": "megabit-ps"
}
]
}
]
}
}
Figure 8: Example of Message Body with Total Pipe Capacity
{
"ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [
{
"target": {
"target-prefix": [
"2001:db8::1/128"
]
},
"total-traffic": [
{
"unit": "megabit-ps",
"mid-percentile-g": "800",
"peak-g": "1300"
}
],
"total-attack-traffic": [
{
"unit": "megabit-ps",
"low-percentile-g": "200",
"mid-percentile-g": "400",
"high-percentile-g": "500",
"peak-g": "600",
"current-g": "400"
}
]
}
]
}
}
Figure 9: Example of Message Body with Total Attack Traffic and
Total Traffic
When DDoS attacks occur, the network management system receives
alerts. Then, it sends the target IP address(es) and volume of the
DDoS attack traffic to the administrative system using the "target-
prefix" and "total-attack-traffic" DOTS telemetry attributes. After
that, the administrative system orders relevant forwarding nodes to
carry out rate-limiting of all traffic destined to the target based
on the pipe capability by the dissemination of the Flow
Specifications using tools such as BGP Flowspec [RFC8955]. 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)).
Note that total pipe capability information can be gathered by
telemetry setup in advance (Section 7.2 of [RFC9244]).
The network management system implements a DOTS client while the
administrative system implements a DOTS server.
3.1.5. Selecting Mitigation Technique Based on Attack Type
Some volumetric attacks, such as DNS 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. It may also be necessary to inspect the
Layer 7 information of suspicious packets to detect attacks such as
DNS water torture attacks [DNS_Water_Torture_Attack]. To carry out
the DNS water torture attack, an attacker commands a botnet to make
thousands of DNS requests for fake subdomains against an
authoritative name server. Such attack traffic should be detected
and mitigated at the DMS.
This use case enables transit providers to select a mitigation
technique based on the type of attack traffic, whether it is an
amplification attack or not. To use such a technique, the attack
traffic is blocked by forwarding nodes or redirected to a DMS based
on the attack type through cooperation among forwarding nodes, flow
collectors, and an orchestrator.
Figure 10 gives an overview of this use case. Figure 11 provides an
example of attack mappings that are shared using the DOTS data
channel in advance. Figure 12 provides an example of a DOTS
telemetry message body that is used to signal percentiles for total
attack traffic, total attack traffic protocol, and total attack
connection; it also shows attack details.
The example in Figure 11 uses the folding defined in [RFC8792] for
long lines.
(Internet Transit Provider)
+-----------+ DOTS +--------------+
+-----------+|<---->| | BGP (Redirect)
IPFIX | Flow ||C S| Orchestrator | BGP Flowspec (Drop)
--->| collector |+ | |--->
+-----------+ +--------------+
+------------+ BGP (Redirect)
IPFIX +------------+| BGP Flowspec (Drop)
<---| Forwarding ||<---
| nodes || DDoS Attack
| ++=====||================
| || ||x<==============[DNS Amp]
| || |+x<==============[NTP Amp]
+-----||-----+
||
|/
+-----x------+
| DDoS |
| mitigation |
| system |
+------------+
C: DOTS client functionality
S: DOTS server functionality
DNS Amp: DNS Amplification
NTP Amp: NTP Amplification
Figure 10: Selecting Mitigation Technique Based on Attack Type
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-dots-mapping:vendor-mapping": {
"vendor": [
{
"vendor-id": 32473,
"vendor-name": "mitigator-c",
"last-updated": "1629898958",
"attack-mapping": [
{
"attack-id": 77,
"attack-description": "DNS amplification Attack: \
This attack is a type of reflection attack in which attackers \
spoof a target's IP address. The attackers abuse vulnerabilities \
in DNS servers to turn small queries into larger payloads."
},
{
"attack-id": 92,
"attack-description":"NTP amplification Attack: \
This attack is a type of reflection attack in which attackers \
spoof a target's IP address. The attackers abuse vulnerabilities \
in NTP servers to turn small queries into larger payloads."
}
]
}
]
}
}
Figure 11: Example of Message Body with Attack Mappings
{
"ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [
{
"target": {
"target-prefix": [
"2001:db8::1/128"
]
},
"total-attack-traffic": [
{
"unit": "megabit-ps",
"low-percentile-g": "600",
"mid-percentile-g": "800",
"high-percentile-g": "1000",
"peak-g": "1100",
"current-g": "700"
}
],
"total-attack-traffic-protocol": [
{
"protocol": 17,
"unit": "megabit-ps",
"mid-percentile-g": "500"
},
{
"protocol": 15,
"unit": "megabit-ps",
"mid-percentile-g": "200"
}
],
"total-attack-connection": [
{
"mid-percentile-l": [
{
"protocol": 15,
"connection": 200
}
],
"high-percentile-l": [
{
"protocol": 17,
"connection": 300
}
]
}
],
"attack-detail": [
{
"vendor-id": 32473,
"attack-id": 77,
"start-time": "1641169211",
"attack-severity": "high"
},
{
"vendor-id": 32473,
"attack-id": 92,
"start-time": "1641172809",
"attack-severity": "high"
}
]
}
]
}
}
Figure 12: Example of Message Body with Total Attack Traffic,
Total Attack Traffic Protocol, Total Attack Connection, and
Attack Detail
Attack mappings are shared using the DOTS data channel in advance
(Section 8.1.6 of [RFC9244]). The forwarding nodes send traffic
statistics to the flow collectors, e.g., using IPFIX. When DDoS
attacks occur, the flow collectors identify attack traffic and send
attack type information to the orchestrator using the "vendor-id" and
"attack-id" telemetry attributes. The orchestrator then resolves
abused port numbers and orders relevant forwarding nodes to block the
amplification attack traffic flow by dissemination of Flow
Specifications using tools such as BGP Flowspec [RFC8955]. Also, the
orchestrator orders relevant forwarding nodes to redirect traffic
other than the amplification attack traffic using a routing protocol,
such as BGP [RFC4271].
The flow collector implements a DOTS client while the orchestrator
implements a DOTS server.
3.2. Detailed DDoS Mitigation Report
It is possible for the transit provider to add value to the DDoS
mitigation service by reporting ongoing and detailed DDoS
countermeasure status to the enterprise network. In addition, it is
possible for the transit provider to know whether the DDoS
countermeasure is effective or not by receiving reports from the
enterprise network.
This use case enables the mutual sharing of information about ongoing
DDoS countermeasures between the transit provider and the enterprise
network. Figure 13 gives an overview of this use case. Figure 14
provides an example of a DOTS telemetry message body that is used to
signal total pipe capacity from the enterprise network administrator
to the orchestrator in the ISP. Figure 15 provides an example of a
DOTS telemetry message body that is used to signal percentiles for
total traffic and total attack traffic as well as attack details from
the orchestrator to the network.
+------------------+ +------------------------+
| Enterprise | | Upstream |
| Network | | Internet Transit |
| +------------+ | | Provider |
| | Network |C | | S+--------------+ |
| | admini- |<-----DOTS---->| Orchestrator | |
| | strator | | | +--------------+ |
| +------------+ | | C ^ |
| | | | DOTS |
| | | S v |
| | | +---------------+ DDoS Attack
| | | | DMS |+=======
| | | +---------------+ |
| | | || Clean |
| | | |/ Traffic |
| +---------+ | | +---------------+ |
| | DDoS | | | | Forwarding | Normal Traffic
| | Target |<================| Node |========
| +---------+ | Link1 | +---------------+ |
+------------------+ +------------------------+
C: DOTS client functionality
S: DOTS server functionality
Figure 13: Detailed DDoS Mitigation Report
{
"ietf-dots-telemetry:telemetry-setup": {
"telemetry": [
{
"total-pipe-capacity": [
{
"link-id": "link1",
"capacity": "1000",
"unit": "megabit-ps"
}
]
}
]
}
}
Figure 14: Example of Message Body with Total Pipe Capacity
{
"ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [
{
"tmid": 567,
"target": {
"target-prefix": [
"2001:db8::1/128"
]
},
"target-protocol": [
17
],
"total-traffic": [
{
"unit": "megabit-ps",
"mid-percentile-g": "800"
}
],
"total-attack-traffic": [
{
"unit": "megabit-ps",
"mid-percentile-g": "100"
}
],
"attack-detail": [
{
"vendor-id": 32473,
"attack-id": 77,
"start-time": "1644819611",
"attack-severity": "high"
}
]
}
]
}
}
Figure 15: Example of Message Body with Total Traffic, Total
Attack Traffic, and Attack Detail
The network management system in the enterprise network reports
limits of incoming traffic volume from the transit provider to the
orchestrator in the transit provider in advance. It is reported
using the "total-pipe-capacity" telemetry attribute in the DOTS
telemetry setup.
When DDoS attacks occur, DDoS mitigation orchestration [RFC8903] is
carried out in the transit provider. Then, the DDoS mitigation
systems report the status of DDoS countermeasures to the orchestrator
by sending "attack-detail" telemetry attributes. After that, the
orchestrator integrates the reports from the DDoS mitigation systems,
while removing duplicate contents, and sends the integrated report to
a network administrator using DOTS telemetry periodically.
During the DDoS mitigation, the orchestrator in the transit provider
retrieves the link congestion status from the network manager in the
enterprise network using the "total-traffic" telemetry attributes.
Then, the orchestrator checks whether or not the DDoS countermeasures
are effective by comparing the "total-traffic" and the "total-pipe-
capacity" telemetry attributes.
The DMS implements a DOTS server while the orchestrator behaves as a
DOTS client and a server in the transit provider. In addition, the
network administrator implements a DOTS client.
3.3. Tuning Mitigation Resources
3.3.1. Supervised Machine Learning of Flow Collector
DDoS detection based on tools, such as IPFIX, is a lighter-weight
method of detecting DDoS attacks compared to DMSes in Internet
transit provider networks. DDoS detection based on the DMSes is a
more accurate method for detecting attack traffic than flow
monitoring.
The aim of this use case is to increase flow collectors' detection
accuracy by carrying out supervised machine-learning techniques
according to attack detail reported by the DMSes. To use such a
technique, forwarding nodes, flow collectors, and a DMS should
cooperate. Figure 16 gives an overview of this use case. Figure 17
provides an example of a DOTS telemetry message body that is used to
signal attack detail.
+-----------+
+-----------+| DOTS
IPFIX | Flow ||S<---
--->| collector ||
+-----------++
+------------+
IPFIX +------------+|
<---| Forwarding ||
| nodes || DDoS Attack
[ Target ] | ++==============================
| || ++===========================
| || || ++========================
+---||-|| ||-+
|| || ||
|/ |/ |/
DOTS +---X--X--X--+
--->C| DDoS |
| mitigation |
| system |
+------------+
C: DOTS client functionality
S: DOTS server functionality
Figure 16: Supervised Machine Learning of Flow Collector
{
"ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [
{
"target": {
"target-prefix": [
"2001:db8::1/128"
]
},
"attack-detail": [
{
"vendor-id": 32473,
"attack-id": 77,
"start-time": "1634192411",
"attack-severity": "high",
"top-talker": {
"talker": [
{
"source-prefix": "2001:db8::2/127"
}
]
}
}
]
}
]
}
}
Figure 17: Example of Message Body with Attack Detail and Top Talkers
The forwarding nodes send traffic statistics to the flow collectors,
e.g., using IPFIX. When DDoS attacks occur, DDoS mitigation
orchestration is carried out (as per Section 3.3 of [RFC8903]), and
the DMS mitigates all attack traffic destined for a target. The DDoS
mitigation system reports the "vendor-id", "attack-id", and "top-
talker" telemetry attributes to a flow collector.
After mitigating a DDoS attack, the flow collector attaches outputs
of the DMS as labels to the statistics of the traffic flow of top
talkers. The outputs, for example, are the "attack-id" telemetry
attributes. 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.
The DMS implements a DOTS client while the flow collector implements
a DOTS server.
3.3.2. Unsupervised Machine Learning of Flow Collector
DMSes can detect DDoS attack traffic, which means DMSes can also
identify clean traffic. This use case supports unsupervised machine
learning for anomaly detection according to a baseline reported by
the DMSes. To use such a technique, forwarding nodes, flow
collectors, and a DMS should cooperate. Figure 18 gives an overview
of this use case. Figure 19 provides an example of a DOTS telemetry
message body that is used to signal baseline.
+-----------+
+-----------+|
DOTS | Flow ||
--->S| collector ||
+-----------++
+------------+
+------------+|
| Forwarding ||
| nodes || Traffic
[ Destination ] <== =============++==============================
| || ||
| || |+
+---||-------+
||
|/
DOTS +---X--------+
--->C| DDoS |
| mitigation |
| system |
+------------+
C: DOTS client functionality
S: DOTS server functionality
Figure 18: Unsupervised Machine Learning of Flow Collector
{
"ietf-dots-telemetry:telemetry-setup": {
"telemetry": [
{
"baseline": [
{
"id": 1,
"target-prefix": [
"2001:db8:6401::1/128"
],
"target-port-range": [
{
"lower-port": "53"
}
],
"target-protocol": [
17
],
"total-traffic-normal": [
{
"unit": "megabit-ps",
"low-percentile-g": "30",
"mid-percentile-g": "50",
"high-percentile-g": "60",
"peak-g": "70"
}
]
}
]
}
]
}
}
Figure 19: Example of Message Body with Traffic Baseline
The forwarding nodes carry out traffic mirroring to copy the traffic
destined to an IP address and to monitor the traffic by a DMS. The
DMS then identifies clean traffic and reports the baseline telemetry
attributes to the flow collector using DOTS telemetry.
The flow collector then carries out unsupervised machine learning to
be able to carry out anomaly detection.
The DMS implements a DOTS client while the flow collector implements
a DOTS server.
4. Security Considerations
Security considerations for DOTS telemetry are discussed in
Section 14 of [RFC9244]. These considerations apply to the
communication interfaces where DOTS is used.
Some use cases involve controllers, orchestrators, and programmable
interfaces. These interfaces can be misused by misbehaving nodes to
further exacerbate DDoS attacks. The considerations are for end-to-
end systems for DoS mitigation, so the mechanics are outside the
scope of DOTS protocols. Section 5 of [RFC7149] discusses some
generic security considerations to take into account in such contexts
(e.g., reliable access control). Specific security measures depend
on the actual mechanism used to control underlying forwarding nodes
and other controlled elements. For example, Section 12 of [RFC8955]
discusses security considerations that are relevant to BGP Flowspec.
IPFIX-specific considerations are discussed in Section 11 of
[RFC7011].
5. IANA Considerations
This document has no IANA actions.
6. References
6.1. Normative References
[RFC9244] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M.,
and J. Shallow, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry", RFC 9244,
DOI 10.17487/RFC9244, June 2022,
<https://www.rfc-editor.org/info/rfc9244>.
6.2. Informative References
[DNS_Water_Torture_Attack]
Luo, X., Wang, L., Xu, Z., Chen, K., Yang, J., and T.
Tian, "A Large Scale Analysis of DNS Water Torture
Attack", CSAI '18: Proceedings of the 2018 2nd
International Conference on Computer Science and
Artificial Intelligence, pp. 168-173,
DOI 10.1145/3297156.3297272, December 2018,
<https://dl.acm.org/doi/10.1145/3297156.3297272>.
[DOTS_Overview]
Reddy, T. and M. Boucadair, "DDoS Open Threat Signaling
(DOTS)", July 2020,
<https://datatracker.ietf.org/meeting/108/materials/
slides-108-saag-dots-overview-00>.
[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>.
[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>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[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>.
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
Denial-of-Service Open Threat Signaling (DOTS) Data
Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
May 2020, <https://www.rfc-editor.org/info/rfc8783>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[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/info/rfc8903>.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/info/rfc8955>.
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
"Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification", RFC 9132,
DOI 10.17487/RFC9132, September 2021,
<https://www.rfc-editor.org/info/rfc9132>.
Acknowledgements
The authors would like to thank Mohamed Boucadair and Valery Smyslov
for their valuable feedback.
Thanks to Paul Wouters for the detailed AD review.
Many thanks to Donald Eastlake 3rd, Phillip Hallam-Baker, Sean
Turner, and Peter Yee for their reviews.
Thanks to Lars Eggert, Murray Kucherawy, Roman Danyliw, Robert
Wilton, and Éric Vyncke for the IESG review.
Authors' Addresses
Yuhei Hayashi
NTT
3-9-11, Midori-cho, Tokyo
180-8585
Japan
Email: yuuhei.hayashi@gmail.com
Meiling Chen
China Mobile
32, Xuanwumen West
Beijing
100053
China
Email: chenmeiling@chinamobile.com
Li Su
China Mobile
32, Xuanwumen West
Beijing
100053
China
Email: suli@chinamobile.com
AI ELI5
On this page
§1DOTS Telemetry Overview
DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time communication between DDoS detection systems and mitigation systems. The base DOTS protocols, defined in RFC 9132 (Signal Channel) and RFC 8783 (Data Channel), allow a network client to request mitigation and to exchange filtering rules with a mitigation server. These protocols focus on the mechanics of requesting and configuring mitigation.
DOTS telemetry, specified in RFC 9244, enriches the base DOTS protocols with detailed attack metrics. Rather than just saying "mitigate this target", a DOTS client can now say "mitigate this target; we are seeing 900 Mbps of UDP traffic from sources in networks 2001:db8:1::/48 and 2001:db8:2::/48, with the first being the top talker at 100 Mbps". This detailed information allows mitigation systems to respond more intelligently.
RFC 9387 presents practical use cases showing how DOTS telemetry helps. It describes the components involved in each scenario, how they cooperate, and what telemetry attributes are exchanged to achieve efficient mitigation.
DOTS is the way computers talk about DDoS attacks. DOTS telemetry adds details: instead of just saying "we are under attack", you can say "we are being hit by a flood of traffic from these sources at this rate". That detail helps computers react faster.
§2Network Components and Data Flow
A typical DOTS telemetry deployment involves several components:
Forwarding nodes (routers) observe traffic flowing through the network. They collect statistics using IPFIX (IP Flow Information Export) and send them to flow collectors. During a DDoS attack, these statistics include information about packet rates, bytes, protocol distribution, and source addresses of attack traffic.
Flow collectors aggregate data from forwarding nodes. They process these statistics to identify attack patterns, compute percentiles of traffic volume, and identify "top talkers"—the source networks or addresses sending the most attack traffic. The flow collector acts as a DOTS client, sending this analysis to the orchestrator using the DOTS protocol.
Orchestrators (management systems) receive telemetry from flow collectors and use it to make mitigation decisions. They can query the available capacity of DDoS Mitigation Systems (DMSes) using management protocols like SNMP or YANG/NETCONF. Based on telemetry and DMS capacity, the orchestrator orders forwarding nodes to redirect attack traffic, typically using BGP Flow Specifications (BGP Flowspec) to specify which traffic should be rerouted to which mitigation system. The orchestrator acts as a DOTS server.
DDoS Mitigation Systems (DMSes) are dedicated devices or clusters that filter attack traffic. They have limited capacity and may be shared across multiple customer networks or attack targets. The orchestrator must select which DMS to use based on available capacity and attack volume.
Routers watch traffic, tell a collector what they see. The collector tells an orchestrator. The orchestrator looks at available DDoS scrubbers and tells the routers where to send the bad traffic. All of this is automatic.
§3Telemetry Attributes and Metrics
DOTS telemetry defines several key attributes that flow collectors can send to orchestrators:
Target prefixes: The IP address prefix (e.g., 2001:db8::1/128 or 192.0.2.3/32) being attacked. Multiple prefixes can be protected in a single mitigation request.
Total attack traffic: Percentile-based metrics of the volume of traffic identified as attack. The metrics include: current-g (the current rate), low-percentile-g (the 25th percentile), mid-percentile-g (the 50th percentile), high-percentile-g (the 75th percentile), and peak-g (the maximum observed rate). Each value is expressed in units such as "megabit-ps" (megabits per second).
Top talkers: A list of source networks or addresses sending large amounts of attack traffic, ranked by volume. For each top talker, the telemetry includes its source prefix and its traffic volume. This allows mitigation to prioritize filtering high-volume sources.
Protocol breakdown: The total attack traffic broken down by protocol (UDP, TCP, ICMP, etc.), allowing mitigation to apply protocol-specific techniques.
Attack severity: A severity level (low, medium, high, critical) assigned to an attack or attack component.
Measurement parameters: The measurement-interval defines the time window over which statistics are computed, and measurement-sample defines the sampling or reporting frequency.
The telemetry says how much traffic is bad, where it is coming from, what kind of traffic it is, and how serious it is. This helps decide what to do faster.
- Attack Volume PercentilesLow, medium, high, and peak traffic rates help select mitigation capacity.
- Top TalkersSource networks or addresses sending the most attack traffic.
- Protocol BreakdownWhich protocols (UDP, TCP, ICMP, etc.) dominate the attack.
- Attack SeverityRating of attack urgency: low, medium, high, or critical.
§4Practical Use Cases
Mitigation of top talkers preferentially: In a large DDoS attack, the DMS has limited capacity. Rather than trying to block all attack traffic, the orchestrator uses telemetry to identify the top-sending networks and redirects only those to the DMS. Forwarding nodes apply BGP Flowspec rules to send traffic from the top talkers through the DMS while less aggressive sources are either allowed through or discarded at the edge. This maximizes the protection of the target with available resources.
DMS selection: A transit provider operates multiple DMSes in different locations. When an attack arrives, the flow collector sends attack volume percentiles to the orchestrator. The orchestrator compares the peak-g metric (the highest observed traffic rate) against the capacity of each DMS and selects the one(s) with sufficient available capacity. This prevents sending traffic to a DMS that is already congested, improving response latency.
Path selection for redirection: The network has multiple paths from the attack target to the DMS. The orchestrator receives telemetry about total traffic volume and attack traffic volume on each link. Using this information, it can select a path that has enough bandwidth to carry the redirected attack traffic without congesting critical links. This keeps normal traffic flowing even while mitigation is active.
Detailed DDoS reports: After an attack, the orchestrator aggregates telemetry data into comprehensive reports showing attack timeline, peak rates, affected targets, and mitigation actions taken. These reports help incident response teams understand what happened and improve future defenses.
Machine learning and adaptation: Flow collectors can apply supervised or unsupervised machine learning to historical telemetry data. Supervised learning uses labeled attack and non-attack traffic to train classifiers. Unsupervised learning (anomaly detection) identifies unusual traffic patterns that might indicate new attack types. The resulting models are deployed in the network to automatically detect and classify attacks in real time.
Here are ways to use the telemetry: block the biggest attackers first, pick a scrubber that is not busy, use unclogged paths, keep records, and teach computers to spot new kinds of attacks.
§5Implementation and Deployment Considerations
Implementing DOTS telemetry requires cooperation among multiple vendors and technologies. The flow collector implements DOTS client software and must export IPFIX data from forwarding nodes. The orchestrator implements the DOTS server and management interfaces (SNMP, YANG/NETCONF) to DMSes and routing systems.
The DOTS specification defines standard JSON structures for telemetry messages. Applications must configure measurement parameters (interval and sample frequency) appropriate for their attack detection and mitigation speed requirements. High-frequency sampling gives rapid response but generates more data; low-frequency sampling reduces overhead but may miss fast-changing attack patterns.
Forwarding nodes must have sufficient capacity to collect and export IPFIX data. For high-speed networks, this can be a bottleneck. Some deployments use sampling (exporting only a fraction of flows) to reduce the load, but this reduces accuracy of the telemetry.
Security of the DOTS protocol itself is critical. The signal channel uses TLS for encryption and authentication. Both DOTS client and server must validate each other's certificates. Telemetry data contains information about network topology and attack patterns, which is sensitive; it should be protected from eavesdropping and modification.
To use DOTS telemetry, many computers have to work together: the ones watching traffic, the ones collecting, the ones deciding, and the ones scrubbing. All of it is encrypted and signed so only trusted computers can talk to each other.
§6Status and Scope
RFC 9387 is an Informational RFC published by the IETF. It has received IESG approval and represents IETF community consensus on the use cases, even though it does not define a standards-track protocol itself. The RFC does not specify the details of the machine-learning algorithms or the exact DMS selection algorithms; these remain implementation-specific. Instead, it identifies what information flows are needed and what decisions can be made based on telemetry.
The RFC explicitly notes that implementation details like the DMS selection algorithm are out of scope. Different vendors and networks may implement these algorithms differently based on their specific constraints and priorities. The DOTS telemetry specification (RFC 9244) provides the protocol machinery; RFC 9387 explains how to use it effectively.
This RFC is useful for network operators planning DOTS deployments, for vendors implementing DOTS servers and management tools, and for standards bodies defining GOST requirements on DDoS mitigation. It has not been updated or obsoleted and remains the primary reference for DOTS telemetry use cases.
This document explains use cases and best practices for DOTS telemetry but does not make strict rules. Different networks can do things their own way, as long as they follow the DOTS protocol for talking to each other.