RFC 9387
Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry
RFC 9387 💖 Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry 🦋
- Organization: Internet Engineering Task Force (IETF) 🌸
- Request for Comments: 9387
- Authors: Y. Hayashi (NTT), M. Chen, L. Su (China Mobile) 💜
- Category: Informational 🎀
- ISSN: 2070-1721
- Date: April 2023 ✨
- Obsoletes / Updates: the title block doesn't list any RFCs this one obsoletes or updates 🙈
Abstract 🌈
okay so DOTS telemetry basically adds extra telemetry attributes to the base DOTS protocols 🧚 so the mitigator can actually use efficient DDoS attack mitigation techniques in a network. this doc gives sample use cases for it. it covers what components get deployed in the network, how they work together, and what info gets exchanged so those techniques can do their thing 💅
Status of This Memo 📝
this doc is not an Internet Standards Track specification. it's published for informational purposes 🌸
it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every doc the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that 🫶
info about the current status of this doc, any errata, and how to give feedback on it can be found 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 doc 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. please read these carefully, because they describe your rights and restrictions for this doc 📜 Code Components pulled out of this doc must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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' Addresses1. Introduction ✨
Distributed Denial-of-Service (DDoS) attacks, like volumetric attacks and resource-consuming attacks, are seriously critical threats that service providers have to handle 😭 When these attacks happen, providers have to mitigate them immediately to protect or recover their services.
so if providers want to protect their network services from DDoS attacks right away, DDoS mitigation has to be highly automated 🤖 to make that happen, 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 those multivendor elements [RFC9132] [RFC8783] 💅 DOTS telemetry enriches the DOTS protocols with various telemetry attributes so attack mitigation can be optimal [RFC9244] 🎀 this doc presents sample use cases for DOTS telemetry to flesh out the overview and purpose described in [RFC9244]. it also shows what components are deployed in the network, how they cooperate, and what information is exchanged to use attack-mitigation techniques effectively 🌸
2. Terminology 📚
readers should already be familiar with the terms defined in [RFC8612], [RFC8903], and [RFC9244] 👀
this doc also uses the following terms:
- Supervised Machine Learning: a machine-learning technique where labeled data trains the algorithms, so the input and output data are known 🎯
- Unsupervised Machine Learning: a machine-learning technique where unlabeled data trains the algorithms, so the data has no historical labels 🌙
3. Telemetry Use Cases 🦋
this section describes DOTS telemetry use cases that use the telemetry attributes from the DOTS telemetry specification [RFC9244] 💖
the subsections below assume that once the DOTS signal channel is established, DOTS clients will go through the telemetry setup configuration detailed in Section 7 of [RFC9244]. these telemetry parameters are used:
"measurement-interval"defines the period during which percentiles are computed."measurement-sample"defines the time distribution for measuring the values 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) that already live in their network with limited resources 😩 for example, recently reported large DDoS attacks exceeded several Tbps [DOTS_Overview] 💀
this use case lets transit providers use their DMS efficiently under volume-based DDoS attacks whose volume is more than the DMS's available capacity 👑 to make it work, the attack traffic of the top talkers gets redirected to the DMS first, thanks to cooperation among forwarding nodes, flow collectors, and orchestrators 🧚
Figure 1 gives an overview of this use case 🗺️ Figure 2 shows an example of a DOTS telemetry message body 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 functionalityFigure 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 happen, the flow collectors spot the attack traffic and send info 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 with a network management protocol, like the Simple Network Management Protocol (SNMP) [RFC3413] or YANG with the Network Configuration Protocol (YANG/NETCONF) [RFC7950] 🔍 after that, the orchestrator tells the forwarding nodes to redirect as much of the top talker's traffic to the DMSes as they can handle, by disseminating Flow Specifications with tools like 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, when an attack happens, they can select which DMS to use for mitigation 💅
this use case lets transit providers pick 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 used to signal percentiles for total attack traffic 🌸
Picking up right where the DMS selection diagram left off 🎀
(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 TrafficThe forwarding nodes ship their traffic stats off to the flow collectors, e.g., using IPFIX 📊 When a DDoS attack hits, the flow collectors spot the attack traffic and tell the orchestrator how big it is, using the target-prefix and total-attack-traffic DOTS telemetry attributes 💖 Then the orchestrator checks how much room each DMS has left over a network management protocol, like the Simple Network Management Protocol (SNMP) [RFC3413] or YANG with the Network Configuration Protocol (YANG/NETCONF) [RFC7950] 🔍 After that, it picks a DMS with enough capacity to send the attack traffic to. For example, a simple DMS selection algorithm can choose a DMS whose available capacity is greater than the peak-g telemetry attribute from the DOTS telemetry message ✨ Last step: the orchestrator tells the right forwarding nodes to redirect the attack traffic to that DMS, using routing policies like BGP [RFC4271] 🦋
The detailed DMS selection algorithm is out of the scope of this document, so that's a whole other story 🙈
Quick reminder of the roles: the flow collector is the DOTS client 🫶 and the orchestrator is the DOTS server 👑
3.1.3. Path Selection for Redirection ✨
Okay so a transit provider network can have multiple paths to get attack traffic to a DMS 🛣️ In a setup like that, you can dodge congested links by picking a path that has enough bandwidth, based on how big the attack traffic is and how much total traffic there is. That's the whole vibe of this use case 💅
Figure 5 gives you the overview, and Figure 6 shows an example DOTS telemetry message body that signals 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 TrafficThe forwarding nodes send traffic stats to the flow collectors, e.g., using IPFIX 📊 When DDoS attacks happen, the flow collectors identify the attack traffic and send its volume to the orchestrator using the target-prefix and total-attack-traffic DOTS telemetry attributes 💜 The underlying forwarding nodes also send the volume of total traffic passing through them to the orchestrator, using the total-traffic telemetry attributes 🧚 Then the orchestrator selects a path with enough bandwidth for the attack flow to be redirected onto. For example, a simple selection algorithm can 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 tells the appropriate forwarding nodes to redirect the attack traffic to the DMS by disseminating 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 are DOTS clients 💖 and the orchestrator is the DOTS server 👑
3.1.4. Short but Extreme Volumetric Attack Mitigation ⚡
Okay this one is intense. Short but extreme volumetric attacks, like pulse wave DDoS attacks, are real threats to Internet transit provider networks 😭 They start at zero and shoot up to maximum values in a super short time span. Then they drop back to zero and climb back to maximum, repeating in continuous cycles at short intervals. It's really hard for transit providers to handle these with their DMSes by redirecting attack flows, because that can cause route flapping in the network 💀 The practical move is to offload the mitigation actions to a forwarding node 🌸
This use case lets transit providers mitigate short but extreme volumetric attacks. On top of that, the goal is to estimate the network-access success rate based on the bandwidth of the attack traffic 🍓 Figure 7 gives you the overview. Figure 8 shows an example DOTS telemetry message body that signals total pipe capacity, and Figure 9 shows an example that signals 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 TrafficWhen DDoS attacks happen, the network management system gets alerts 🚨 It then sends the target IP address(es) and the 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 tells the relevant forwarding nodes to rate-limit all traffic headed to the target, based on the pipe capability, by disseminating Flow Specifications using tools such as BGP Flowspec [RFC8955] 🛡️ On top of that, 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)) 🧮
Heads up, total pipe capability info can be gathered by telemetry setup in advance (Section 7.2 of [RFC9244]) 👀
The network management system is a DOTS client 🫶 and the administrative system is the DOTS server 👑
3.1.5. Selecting Mitigation Technique Based on Attack Type ✨
okay so some volumetric attacks, like DNS amplification, can be spotted with super high accuracy just by checking the Layer 3 or Layer 4 info in the attack packets 👀. These can be detected and mitigated when forwarding nodes and flow collectors work together using IPFIX 🦋. It may also be necessary to inspect the Layer 7 info of suspicious packets to catch stuff like DNS water torture attacks [DNS_Water_Torture_Attack] 💀. To pull off a DNS water torture attack, an attacker commands a botnet to make thousands of DNS requests for fake subdomains against an authoritative name server. Attack traffic like that should be detected and mitigated at the DMS 🛡️.
This use case lets transit providers pick a mitigation technique based on the type of attack traffic, whether it's an amplification attack or not 💖. To use it, the attack traffic gets blocked by forwarding nodes or redirected to a DMS depending on the attack type. This happens through teamwork between forwarding nodes, flow collectors, and an orchestrator 🫶.
Figure 10 gives you the overview of this use case 🌸. Figure 11 shows an example of attack mappings that get shared over the DOTS data channel in advance ✨. Figure 12 shows an example of a DOTS telemetry message body used to signal percentiles for total attack traffic, total attack traffic protocol, and total attack connection, and 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 DetailAttack mappings get shared over 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 happen, the flow collectors identify the attack traffic and send attack type info to the orchestrator using the vendor-id and attack-id telemetry attributes 🕵️♀️. The orchestrator then resolves abused port numbers and tells the relevant forwarding nodes to block the amplification attack traffic flow by disseminating Flow Specifications, using tools like BGP Flowspec [RFC8955] 🚫. The orchestrator also tells the 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's possible for the transit provider to add value to the DDoS mitigation service by reporting ongoing, detailed DDoS countermeasure status to the enterprise network 💅. It's also 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 mutual sharing of information about ongoing DDoS countermeasures between the transit provider and the enterprise network 🫶. Figure 13 gives you the overview 🌈. Figure 14 provides an example of a DOTS telemetry message body 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 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 DetailThe network management system in the enterprise network reports its incoming traffic volume limits to the orchestrator in the transit provider in advance 📈. This gets reported using the total-pipe-capacity telemetry attribute in the DOTS telemetry setup ⚙️.
When DDoS attacks happen, DDoS mitigation orchestration [RFC8903] gets carried out in the transit provider 🚨. Then the DDoS mitigation systems report the status of their DDoS countermeasures to the orchestrator by sending attack-detail telemetry attributes 📣. After that, the orchestrator integrates the reports from the DDoS mitigation systems, removes duplicate content, and periodically sends the integrated report to a network administrator using DOTS telemetry 🗂️.
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 🧠. The network administrator, in addition, implements a DOTS client 🙌.
3.3. Tuning Mitigation Resources 💅
3.3.1. Supervised Machine Learning of Flow Collector ✨
okay so DDoS detection with tools like IPFIX is the lighter-weight option 🦋 compared to DMSes in Internet transit provider networks. DDoS detection based on DMSes is the more accurate way to catch attack traffic than flow monitoring, bestie 💅
The goal here is to make flow collectors more accurate by running supervised machine learning on the attack details that DMSes report 🧠. To pull this off, forwarding nodes, flow collectors, and a DMS should cooperate. Figure 16 gives you the big picture, and Figure 17 shows an example DOTS telemetry message body that signals the 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 TalkersThe forwarding nodes send traffic statistics to the flow collectors, e.g., using IPFIX. When DDoS attacks happen, DDoS mitigation orchestration kicks in (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. Then the flow collector runs supervised machine learning to level up its detection accuracy, using the statistics as the explanatory variable and the labels as the 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 they can also identify clean traffic 🧼. This use case supports unsupervised machine learning for anomaly detection, based on a baseline reported by the DMSes. To make it work, forwarding nodes, flow collectors, and a DMS should cooperate. Figure 18 gives you the overview, and Figure 19 shows an example DOTS telemetry message body used to signal the 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 BaselineThe forwarding nodes do traffic mirroring to copy the traffic destined to an IP address, and then a DMS monitors that traffic 👀. The DMS identifies clean traffic and reports the baseline telemetry attributes to the flow collector using DOTS telemetry.
The flow collector then runs unsupervised machine learning so it can do 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 ✨
Okay, big thank-you energy 🫶 The authors want to thank Mohamed Boucadair and Valery Smyslov for their super valuable feedback. You two are iconic 👑
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 💜
And a big shoutout to Lars Eggert, Murray Kucherawy, Roman Danyliw, Robert Wilton, and Éric Vyncke for the IESG review 🌸
Authors' Addresses 🎀
Yuhei Hayashi, the first author, is at NTT:
Yuhei Hayashi
NTT
3-9-11, Midori-cho, Tokyo
180-8585
Japan
Email: yuuhei.hayashi@gmail.comMeiling Chen is at China Mobile 🦋:
Meiling Chen
China Mobile
32, Xuanwumen West
Beijing
100053
China
Email: chenmeiling@chinamobile.comAnd Li Su is also at China Mobile 🧚:
Li Su
China Mobile
32, Xuanwumen West
Beijing
100053
China
Email: suli@chinamobile.com📦 where this page comes from
- ietf: rfc9387 2023-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms