rfc9387.original   rfc9387.txt 
DOTS Y. Hayashi Internet Engineering Task Force (IETF) Y. Hayashi
Internet-Draft NTT Request for Comments: 9387 NTT
Intended status: Informational M. Chen Category: Informational M. Chen
Expires: 26 April 2023 Li. Su ISSN: 2070-1721 L. Su
CMCC China Mobile
23 October 2022 April 2023
Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry
draft-ietf-dots-telemetry-use-cases-15
Abstract Abstract
DDoS Open Threat Signaling (DOTS) Telemetry enriches the base DOTS DDoS Open Threat Signaling (DOTS) telemetry enriches the base DOTS
protocols to assist the mitigator in using efficient DDoS attack protocols to assist the mitigator in using efficient DDoS attack
mitigation techniques in a network. This document presents sample mitigation techniques in a network. This document presents sample
use cases for DOTS Telemetry. It discusses what components are use cases for DOTS telemetry. It discusses what components are
deployed in the network, how they cooperate, and what information is deployed in the network, how they cooperate, and what information is
exchanged to effectively use these techniques. exchanged to effectively use these techniques.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 26 April 2023. 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 Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Telemetry Use Cases . . . . . . . . . . . . . . . . . . . . . 3 3. Telemetry Use Cases
3.1. Mitigation Resources Assignment . . . . . . . . . . . . . 3 3.1. Mitigation Resources Assignment
3.1.1. Mitigating Attack Flow of Top-talker 3.1.1. Mitigating Attack Flow of Top Talker Preferentially
Preferentially . . . . . . . . . . . . . . . . . . . 4 3.1.2. DMS Selection for Mitigation
3.1.2. DMS Selection for Mitigation . . . . . . . . . . . . 6 3.1.3. Path Selection for Redirection
3.1.3. Path Selection for Redirection . . . . . . . . . . . 9 3.1.4. Short but Extreme Volumetric Attack Mitigation
3.1.4. Short but Extreme Volumetric Attack Mitigation . . . 11 3.1.5. Selecting Mitigation Technique Based on Attack Type
3.1.5. Selecting Mitigation Technique Based on Attack 3.2. Detailed DDoS Mitigation Report
Type . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Tuning Mitigation Resources
3.2. Detailed DDoS Mitigation Report . . . . . . . . . . . . . 18 3.3.1. Supervised Machine Learning of Flow Collector
3.3. Tuning Mitigation Resources . . . . . . . . . . . . . . . 21 3.3.2. Unsupervised Machine Learning of Flow Collector
3.3.1. Supervised Machine Learning of Flow Collector . . . . 21 4. Security Considerations
3.3.2. Unsupervised Machine Learning of Flow Collector . . . 24 5. IANA Considerations
4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. References
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6.1. Normative References
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26 6.2. Informative References
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 Acknowledgements
7.1. Normative References . . . . . . . . . . . . . . . . . . 26 Authors' Addresses
7.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Distributed Denial-of-Service (DDoS) attacks, such as volumetric Distributed Denial-of-Service (DDoS) attacks, such as volumetric
attacks and resource-consumption attacks, are critical threats to be attacks and resource-consuming attacks, are critical threats to be
handled by service providers. When such DDoS attacks occur, service handled by service providers. When such DDoS attacks occur, service
providers have to mitigate them immediately to protect or recover providers have to mitigate them immediately to protect or recover
their services. their services.
Therefore, for service providers to immediately protect their network For service providers to immediately protect their network services
services from DDoS attacks, DDoS mitigation needs to be highly from DDoS attacks, DDoS mitigation needs to be highly automated. To
automated. To that aim, multivendor components involved in DDoS that aim, multivendor components involved in DDoS attack detection
attack detection and mitigation should cooperate and support standard and mitigation should cooperate and support standard interfaces.
interfaces.
DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time
signaling, threat-handling requests, and data filtering between the signaling, threat-handling requests, and data filtering between the
multivendor elements [RFC9132][RFC8783]. DOTS Telemetry enriches the multivendor elements [RFC9132] [RFC8783]. DOTS telemetry enriches
DOTS protocols with various telemetry attributes allowing optimal the DOTS protocols with various telemetry attributes allowing optimal
DDoS attack mitigation [RFC9244]. This document presents sample use DDoS attack mitigation [RFC9244]. This document presents sample use
cases for DOTS Telemetry which makes concrete overview and purpose cases for DOTS telemetry to enhance the overview and the purpose
described in [RFC9244]. This document also presents what components described in [RFC9244]. This document also presents what components
are deployed in the network, how they cooperate, and what information are deployed in the network, how they cooperate, and what information
is exchanged to effectively use attack-mitigation techniques. is exchanged to effectively use attack-mitigation techniques.
2. Terminology 2. Terminology
The readers should be familiar with the terms defined in [RFC8612], Readers should be familiar with the terms defined in [RFC8612],
[RFC8903] and [RFC9244]. [RFC8903], and [RFC9244].
In addition, this document uses the following terms: In addition, this document uses the following terms:
Top-talker: A list of attack sources that are involved in an attack
and which are generating an important part of the attack traffic.
Supervised Machine Learning: A machine-learning technique in which Supervised Machine Learning: A machine-learning technique in which
labeled data is used to train the algorithms (the input and output labeled data is used to train the algorithms (the input and output
data are known). data are known).
Unsupervised Machine Learning: A machine learning technique in which Unsupervised Machine Learning: A machine-learning technique in which
unlabeled data is used to train the algorithms (the data has no unlabeled data is used to train the algorithms (the data has no
historical labels). historical labels).
3. Telemetry Use Cases 3. Telemetry Use Cases
This section describes DOTS telemetry use cases that use attributes This section describes DOTS telemetry use cases that use telemetry
included in the DOTS telemetry specification [RFC9244]. attributes included in the DOTS telemetry specification [RFC9244].
The following subsections assume that once the DOTS signal channel is The following subsections assume that once the DOTS signal channel is
established, DOTS clients proceed with the telemetry setup established, DOTS clients will proceed with the telemetry setup
configuration as detailed in Section 7 of [RFC9244]. The following configuration detailed in Section 7 of [RFC9244]. The following
telemetry parameters are used: telemetry parameters are used:
* 'measurement-interval' to define the period during which * "measurement-interval" defines the period during which percentiles
percentiles are computed. are computed.
* 'measurement-sample' to define the time distribution for measuring * "measurement-sample" defines the time distribution for measuring
values that are used to compute percentiles. values that are used to compute percentiles.
3.1. Mitigation Resources Assignment 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 by 3.1.1. Mitigating Attack Flow of Top Talker Preferentially
using DDoS Mitigation Systems (DMSes) with limited resources, which
are already deployed in their network. For example, recently Some transit providers have to mitigate large-scale DDoS attacks
reported large DDoS attacks exceeded several Tbps. [DOTS_Overview] 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 This use case enables transit providers to use their DMS efficiently
under volume-based DDoS attacks whose volume is more than the under volume-based DDoS attacks whose volume is more than the
available capacity of the DMS. To enable this, the attack traffic of available capacity of the DMS. To enable this, the attack traffic of
top-talkers is redirected to the DMS preferentially by cooperation top talkers is redirected to the DMS preferentially by cooperation
among forwarding nodes, flow collectors, and orchestrators. among forwarding nodes, flow collectors, and orchestrators.
Figure 1 gives an overview of this use case. Figure 2 provides an 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- example of a DOTS telemetry message body that is used to signal top
talkers (2001:db8:1::/48 and 2001:db8:2::/48). talkers (2001:db8:1::/48 and 2001:db8:2::/48).
(Internet Transit Provider) (Internet Transit Provider)
+-----------+ +--------------+ SNMP or YANG/NETCONF +-----------+ +--------------+ SNMP or YANG/NETCONF
IPFIX +-----------+| DOTS | |<--- IPFIX +-----------+| DOTS | |<---
--->| Flow ||C<-->S| Orchestrator | BGP Flowspec --->| Flow ||C<-->S| Orchestrator | BGP Flowspec
| collector |+ | |---> (Redirect) | collector |+ | |---> (Redirect)
+-----------+ +--------------+ +-----------+ +--------------+
+-------------+ +-------------+
IPFIX +-------------+| BGP Flowspec (Redirect) IPFIX +-------------+| BGP Flowspec (Redirect)
<---| Forwarding ||<--- <---| Forwarding ||<---
| nodes || | nodes ||
| || DDoS Attack | || DDoS Attack
[ Target(s) ]<========================================== [ Target(s) ]<==========================================
| ++=========================[top-talker] | ++=========================[top talker]
| || ++======================[top-talker] | || ++======================[top talker]
+----|| ||---+ +----|| ||----+
|| || || ||
|| || || ||
|/ |/ |/ |/
+----x--x----+ +----x--x----+
| DDoS | SNMP or YANG/NETCONF | DDoS | SNMP or YANG/NETCONF
| mitigation |<--- | mitigation |<---
| system | | system |
+------------+ +------------+
* C is for DOTS client functionality C: DOTS client functionality
* S is for DOTS server functionality S: DOTS server functionality
Figure 1: Mitigating Attack Flow of Top Talker Preferentially
Figure 1: Mitigating DDoS Attack Flow of Top-talkers Preferentially
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::1/128" "2001:db8::1/128"
] ]
}, },
"total-attack-traffic-protocol": [ "total-attack-traffic-protocol": [
skipping to change at page 6, line 4 skipping to change at line 226
"mid-percentile-g": "90" "mid-percentile-g": "90"
} }
] ]
} }
] ]
} }
} }
] ]
} }
] ]
} }
} }
Figure 2: An Example of Message Body to Signal Top-Talkers Figure 2: Example of Message Body to Signal Top Talkers
The forwarding nodes send traffic statistics to the flow collectors, The forwarding nodes send traffic statistics to the flow collectors,
e.g., using IP Flow Information Export (IPFIX) [RFC7011]. When DDoS e.g., using IP Flow Information Export (IPFIX) [RFC7011]. When DDoS
attacks occur, the flow collectors identify the attack traffic and attacks occur, the flow collectors identify the attack traffic and
send information about the top-talkers to the orchestrator using the send information about the top talkers to the orchestrator using the
"target-prefix" and "top-talkers" DOTS telemetry attributes. The "target-prefix" and "top-talkers" DOTS telemetry attributes. The
orchestrator then checks the available capacity of the DMSes by using orchestrator then checks the available capacity of the DMSes using a
a network management protocol, such as Simple Network Management network management protocol, such as the Simple Network Management
Protocol (SNMP) [RFC3413] or YANG with Network Configuration Protocol Protocol (SNMP) [RFC3413] or YANG with the Network Configuration
(YANG/NETCONF) [RFC7950]. After that, the orchestrator orders the Protocol (YANG/NETCONF) [RFC7950]. After that, the orchestrator
forwarding nodes to redirect as much of the top-talker's traffic to orders the forwarding nodes to redirect as much of the top talker's
each DMS as that DMS can handle by dissemination of Flow traffic to the DMSes as they can handle by dissemination of Flow
Specifications using tools such as Border Gateway Protocol Specifications using tools such as Border Gateway Protocol
Dissemination of Flow Specification Rules (BGP Flowspec) [RFC8955]. Dissemination of Flow Specification Rules (BGP Flowspec) [RFC8955].
The flow collector implements a DOTS client while the orchestrator The flow collector implements a DOTS client while the orchestrator
implements a DOTS server. implements a DOTS server.
3.1.2. DMS Selection for Mitigation 3.1.2. DMS Selection for Mitigation
Transit providers can deploy their DMSes in clusters. Then, they can 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 select the DMS to be used to mitigate a DDoS attack at the time of an
attack. attack.
This use case enables transit providers to select a DMS with This use case enables transit providers to select a DMS with
sufficient capacity for mitigation based on the volume of the attack sufficient capacity for mitigation based on the volume of the attack
traffic and the capacity of a DMS. Figure 3 gives an overview of 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 this use case. Figure 4 provides an example of a DOTS telemetry
message body that is used to signal various attack traffic message body that is used to signal percentiles for total attack
percentiles. traffic.
(Internet Transit Provider) (Internet Transit Provider)
+-----------+ +--------------+ SNMP or YANG/NETCONF +-----------+ +--------------+ SNMP or YANG/NETCONF
IPFIX +-----------+| DOTS | |<--- IPFIX +-----------+| DOTS | |<---
--->| Flow ||C<-->S| Orchestrator | BGP (Redirect) --->| Flow ||C<-->S| Orchestrator | BGP (Redirect)
| collector |+ | |---> | collector |+ | |--->
+-----------+ +--------------+ +-----------+ +--------------+
+------------+ +------------+
skipping to change at page 7, line 32 skipping to change at line 288
++====++ || (congested DMS) ++====++ || (congested DMS)
|| || +-----------+ || || +-----------+
|| |/ | DMS3 | || |/ | DMS3 |
|| +-----x------+ |<--- SNMP or YANG/NETCONF || +-----x------+ |<--- SNMP or YANG/NETCONF
|/ | DMS2 |--------+ |/ | DMS2 |--------+
+--x---------+ |<--- SNMP or YANG/NETCONF +--x---------+ |<--- SNMP or YANG/NETCONF
| DMS1 |------+ | DMS1 |------+
| |<--- SNMP or YANG/NETCONF | |<--- SNMP or YANG/NETCONF
+------------+ +------------+
* C is for DOTS client functionality C: DOTS client functionality
* S is for DOTS server functionality S: DOTS server functionality
Figure 3: DMS Selection for Mitigation
Figure 3: DMS Selection for Mitigation
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"target": { "target": {
"target-prefix": [ "target-prefix": [
"192.0.2.3/32" "192.0.2.3/32"
] ]
}, },
"total-attack-traffic": [ "total-attack-traffic": [
skipping to change at page 8, line 28 skipping to change at line 317
"high-percentile-g": "1000", "high-percentile-g": "1000",
"peak-g":"1100", "peak-g":"1100",
"current-g":"700" "current-g":"700"
} }
] ]
} }
] ]
} }
} }
Figure 4: Example of Message Body with Total Attack Traffic Figure 4: Example of Message Body with Total Attack Traffic
The forwarding nodes send traffic statistics to the flow collectors, The forwarding nodes send traffic statistics to the flow collectors,
e.g., using IPFIX. When DDoS attacks occur, the flow collectors e.g., using IPFIX. When DDoS attacks occur, the flow collectors
identify the attack traffic and send information about the attack identify the attack traffic and send information about the attack
traffic volume to the orchestrator by using the "target-prefix" and traffic volume to the orchestrator using the "target-prefix" and
"total-attack-traffic" DOTS telemetry attributes. The orchestrator "total-attack-traffic" DOTS telemetry attributes. The orchestrator
then checks the available capacity of the DMSes by using a network then checks the available capacity of the DMSes using a network
management protocol, such as Simple Network Management Protocol management protocol, such as the Simple Network Management Protocol
(SNMP) [RFC3413] or YANG with Network Configuration Protocol (YANG/ (SNMP) [RFC3413] or YANG with the Network Configuration Protocol
NETCONF) [RFC7950]. After that, the orchestrator selects a DMS with (YANG/NETCONF) [RFC7950]. After that, the orchestrator selects a DMS
sufficient capacity to which attack traffic should be redirected. with sufficient capacity to which attack traffic should be
For example, a simple DMS selection algorithm is to choose a DMS redirected. For example, a simple DMS selection algorithm can be
whose available capacity is greater than the "peak-g" attribute used to choose a DMS whose available capacity is greater than the
indicated in the DOTS telemetry message. The orchestrator orders the "peak-g" telemetry attribute indicated in the DOTS telemetry message.
appropriate forwarding nodes to redirect the attack traffic to the The orchestrator orders the appropriate forwarding nodes to redirect
DMS relying upon routing policies, such as BGP [RFC4271]. 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 The detailed DMS selection algorithm is out of the scope of this
document. document.
The flow collector implements a DOTS client while the orchestrator The flow collector implements a DOTS client while the orchestrator
implements a DOTS server. implements a DOTS server.
3.1.3. Path Selection for Redirection 3.1.3. Path Selection for Redirection
A transit provider network has multiple paths to convey attack A transit provider network has multiple paths to convey attack
traffic to a DMS. In such a network, the attack traffic can be traffic to a DMS. In such a network, the attack traffic can be
conveyed while avoiding congested links by adequately selecting an conveyed while avoiding congested links by adequately selecting an
available path. available path.
This use case enables transit providers to select a path with This use case enables transit providers to select a path with
sufficient bandwidth for redirecting attack traffic to a DMS sufficient bandwidth for redirecting attack traffic to a DMS
according to the bandwidth of the attack traffic and total traffic. according to the bandwidth of the attack traffic and total traffic.
Figure 5 gives an overview of this use case. Figure 6 provides an 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 example of a DOTS telemetry message body that is used to signal
various attack traffic percentiles and total traffic percentiles. percentiles for total traffic and total attack traffic.
(Internet Transit Provider) (Internet Transit Provider)
+-----------+ +--------------+ DOTS +-----------+ +--------------+ DOTS
+-----------+| | |S<--- +-----------+| | |S<---
IPFIX | Flow || DOTS | Orchestrator | IPFIX | Flow || DOTS | Orchestrator |
-->| collector ||C<-->S| | BGP Flowspec (Redirect) -->| collector ||C<-->S| | BGP Flowspec (Redirect)
| |+ | |---> | |+ | |--->
+-----------+ +--------------+ +-----------+ +--------------+
skipping to change at page 9, line 46 skipping to change at line 383
|| / || /
DOTS +-||----------------+ BGP Flowspec (Redirect) DOTS +-||----------------+ BGP Flowspec (Redirect)
--->C| || Forwarding |<--- --->C| || Forwarding |<---
| ++=== node | | ++=== node |
+----||-------------+ +----||-------------+
|/ |/
+--x-----------+ +--x-----------+
| DMS | | DMS |
+--------------+ +--------------+
* C is for DOTS client functionality C: DOTS client functionality
* S is for DOTS server functionality S: DOTS server functionality
Figure 5: Path Selection for Redirection
Figure 5: Path Selection for Redirection
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::1/128" "2001:db8::1/128"
] ]
}, },
"total-traffic": [ "total-traffic": [
skipping to change at page 10, line 35 skipping to change at line 419
"high-percentile-g": "1000", "high-percentile-g": "1000",
"peak-g": "1100", "peak-g": "1100",
"current-g": "700" "current-g": "700"
} }
] ]
} }
] ]
} }
} }
Figure 6: An Example of Message Body with Total Attack Figure 6: Example of Message Body with Total Attack Traffic and
Traffic and Total Traffic Total Traffic
The forwarding nodes send traffic statistics to the flow collectors, The forwarding nodes send traffic statistics to the flow collectors,
e.g., using IPFIX. When DDoS attacks occur, the flow collectors e.g., using IPFIX. When DDoS attacks occur, the flow collectors
identify attack traffic and send information about the attack traffic identify attack traffic and send information about the attack traffic
volume to the orchestrator by using "target-prefix" and "total- volume to the orchestrator using the "target-prefix" and "total-
attack-traffic" DOTS telemetry attributes. The underlying forwarding attack-traffic" DOTS telemetry attributes. The underlying forwarding
nodes send the volume on the total traffic passing the node to the nodes send the volume of the total traffic passing the node to the
orchestrator by using "total-traffic" telemetry attributes. The orchestrator using the "total-traffic" telemetry attributes. The
orchestrator then selects a path with sufficient bandwidth to which orchestrator then selects a path with sufficient bandwidth to which
attack-traffic flow should be redirected. For example, the simple the flow of attack traffic should be redirected. For example, a
algorithm of the selection is to choose a path whose available simple selection algorithm can be used to choose a path whose
capacity is greater than the "peak-g" attribute that was indicated in available capacity is greater than the "peak-g" telemetry attribute
a DOTS telemetry message. After that, the orchestrator orders the that was indicated in a DOTS telemetry message. After that, the
appropriate forwarding nodes to redirect the attack traffic to the orchestrator orders the appropriate forwarding nodes to redirect the
DMS by dissemination of Flow Specifications using tools such as attack traffic to the DMS by dissemination of Flow Specifications
Border Gateway Protocol Dissemination of Flow Specification Rules using tools such as BGP Flowspec [RFC8955].
(BGP Flowspec) [RFC8955].
The detailed path selection algorithm is out of the scope of this The detailed path selection algorithm is out of the scope of this
document. document.
The flow collector and forwarding nodes implement a DOTS client while The flow collector and forwarding nodes implement a DOTS client while
the orchestrator implements a DOTS server. the orchestrator implements a DOTS server.
3.1.4. Short but Extreme Volumetric Attack Mitigation 3.1.4. Short but Extreme Volumetric Attack Mitigation
Short but extreme volumetric attacks, such as pulse wave DDoS Short but extreme volumetric attacks, such as pulse wave DDoS
attacks, are threats to Internet transit provider networks. These attacks, are threats to Internet transit provider networks. These
attacks start from zero and go to maximum values in a very short time attacks start from zero and go to maximum values in a very short time
span, then go back to zero, and then back to maximum, repeating in span. The attacks go back to zero and then back to maximum values,
continuous cycles at short intervals. It is difficult for the repeating in continuous cycles at short intervals. It is difficult
transit providers to mitigate such an attack with their DMSes using a for transit providers to mitigate such an attack with their DMSes by
redirecting attack flows because this may cause route flapping in the redirecting attack flows because this may cause route flapping in the
network. The practical way to mitigate short but extreme volumetric network. The practical way to mitigate short but extreme volumetric
attacks is to offload mitigation actions to a forwarding node. attacks is to offload mitigation actions to a forwarding node.
This use case enables transit providers to mitigate short but extreme This use case enables transit providers to mitigate short but extreme
volumetric attacks. Furthermore, the aim is to estimate the network- volumetric attacks. Furthermore, the aim is to estimate the network-
access success rate based on the bandwidth of the attack traffic. access success rate based on the bandwidth of the attack traffic.
Figure 7 gives an overview of this use case. Figure 8 provides an 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 example of a DOTS telemetry message body that is used to signal total
pipe capacity. Figure 9 provides an example of a DOTS telemetry pipe capacity. Figure 9 provides an example of a DOTS telemetry
message body that is used to signal various attack traffic message body that is used to signal various percentiles for total
percentiles and total traffic percentiles. traffic and total attack traffic.
(Internet Transit Provider)
+------------+ +----------------+ (Internet Transit Provider)
| Network | DOTS | Administrative |
Alert ----->| Management |C<--->S| System | BGP Flowspec (Rate-Limit)
| System | | |--->
+------------+ +----------------+
+------------+ +------------+ BGP Flowspec (Rate-Limit X bps) +------------+ +----------------+
| Forwarding | | Forwarding |<--- | Network | DOTS | Administrative | BGP Flowspec
| node | | node | Alert----->| Management |C<--->S| System | (Rate-Limit)
Link1 | | | | DDoS & Normal traffic | System | | |--->
[Target]<------------------------------------================ +------------+ +----------------+
Pipe +------------+ +------------+ Attack Traffic BGP Flowspec
Capability Bandwidth +------------+ +------------+ (Rate-Limit X bps)
X bps Y bps | Forwarding | | Forwarding |<---
| node | | node |
Link1 | | | | DDoS & Normal traffic
[Target]<------------------------------------================
Pipe +------------+ +------------+ Attack Traffic
Capability Bandwidth
X bps Y bps
Network access success rate Network-access success rate
X / (X + Y) X / (X + Y)
* C is for DOTS client functionality C: DOTS client functionality
* S is for DOTS server functionality S: DOTS server functionality
Figure 7: Short but Extreme Volumetric Attack Mitigation Figure 7: Short but Extreme Volumetric Attack Mitigation
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
{ {
"total-pipe-capacity": [ "total-pipe-capacity": [
{ {
"link-id": "link1", "link-id": "link1",
"capacity": "1000", "capacity": "1000",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
Figure 8: Example of Message Body with Total Pipe Capacity
Figure 8: Example of Message Body with Total Pipe Capacity
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::1/128" "2001:db8::1/128"
] ]
}, },
"total-traffic": [ "total-traffic": [
skipping to change at page 13, line 35 skipping to change at line 539
"high-percentile-g": "500", "high-percentile-g": "500",
"peak-g": "600", "peak-g": "600",
"current-g": "400" "current-g": "400"
} }
] ]
} }
] ]
} }
} }
Figure 9: Example of Message Body with Total Attack Traffic, Figure 9: Example of Message Body with Total Attack Traffic and
and Total Traffic Total Traffic
When DDoS attacks occur, the network management system receives When DDoS attacks occur, the network management system receives
alerts. Then, it sends the target IP address(es) and volume of the alerts. Then, it sends the target IP address(es) and volume of the
DDoS attack traffic to the administrative system by using the DDoS attack traffic to the administrative system using the "target-
"target-prefix" and "total-attack-traffic" DOTS telemetry attributes. prefix" and "total-attack-traffic" DOTS telemetry attributes. After
After that, the administrative system orders relevant forwarding that, the administrative system orders relevant forwarding nodes to
nodes to carry out rate-limiting of all traffic destined to the carry out rate-limiting of all traffic destined to the target based
target based on the pipe capability by the dissemination of the Flow on the pipe capability by the dissemination of the Flow
Specifications using tools such as Border Gateway Protocol Specifications using tools such as BGP Flowspec [RFC8955]. In
Dissemination of Flow Specification Rules (BGP Flowspec) [RFC8955]. addition, the administrative system estimates the network-access
In addition, the administrative system estimates the network-access
success rate of the target, which is calculated by (total-pipe- success rate of the target, which is calculated by (total-pipe-
capability / (total-pipe-capability + total-attack-traffic)). capability / (total-pipe-capability + total-attack-traffic)).
Note that total pipe capability information can be gathered by Note that total pipe capability information can be gathered by
telemetry setup in advance (Section 7.2 of [RFC9244]). telemetry setup in advance (Section 7.2 of [RFC9244]).
The network management system implements a DOTS client while the The network management system implements a DOTS client while the
administrative system implements a DOTS server. administrative system implements a DOTS server.
3.1.5. Selecting Mitigation Technique Based on Attack Type 3.1.5. Selecting Mitigation Technique Based on Attack Type
Some volumetric attacks, such as DNS amplification attacks, can be Some volumetric attacks, such as DNS amplification attacks, can be
detected with high accuracy by checking the Layer 3 or Layer 4 detected with high accuracy by checking the Layer 3 or Layer 4
information of attack packets. These attacks can be detected and information of attack packets. These attacks can be detected and
mitigated through cooperation among forwarding nodes and flow mitigated through cooperation among forwarding nodes and flow
collectors by using IPFIX. It may also be necessary to inspect the collectors using IPFIX. It may also be necessary to inspect the
Layer 7 information of suspicious packets to detect attacks such as Layer 7 information of suspicious packets to detect attacks such as
DNS Water Torture Attacks [DNS_Water_Torture_Attack]. To carry out DNS water torture attacks [DNS_Water_Torture_Attack]. To carry out
the DNS water torture attack, an attacker commands a botnet to make the DNS water torture attack, an attacker commands a botnet to make
thousands of DNS requests for fake subdomains against an thousands of DNS requests for fake subdomains against an
Authoritative Name Server. Such attack traffic should be detected authoritative name server. Such attack traffic should be detected
and mitigated at the DMS. and mitigated at the DMS.
This use case enables transit providers to select a mitigation This use case enables transit providers to select a mitigation
technique based on the type of attack traffic: amplification attack technique based on the type of attack traffic, whether it is an
or not. To use such a technique, the attack traffic is blocked by amplification attack or not. To use such a technique, the attack
forwarding nodes or redirected to a DMS based on the attack type traffic is blocked by forwarding nodes or redirected to a DMS based
through cooperation among forwarding nodes, flow collectors, and an on the attack type through cooperation among forwarding nodes, flow
orchestrator. collectors, and an orchestrator.
Figure 10 gives an overview of this use case. Figure 11 provides an Figure 10 gives an overview of this use case. Figure 11 provides an
example of attack mappings that are shared by using the DOTS data example of attack mappings that are shared using the DOTS data
channel in advance. Figure 12 provides an example of a DOTS channel in advance. Figure 12 provides an example of a DOTS
telemetry message body that is used to signal various attack traffic telemetry message body that is used to signal percentiles for total
percentiles, total traffic percentiles, total attack connection, and attack traffic, total attack traffic protocol, and total attack
attack type. connection; it also shows attack details.
The example in Figure 11 uses the folding defined in [RFC8792] for The example in Figure 11 uses the folding defined in [RFC8792] for
long lines. long lines.
(Internet Transit Provider) (Internet Transit Provider)
+-----------+ DOTS +--------------+ +-----------+ DOTS +--------------+
+-----------+|<---->| | BGP (Redirect) +-----------+|<---->| | BGP (Redirect)
IPFIX | Flow ||C S| Orchestrator | BGP Flowspec (Drop) IPFIX | Flow ||C S| Orchestrator | BGP Flowspec (Drop)
--->| collector |+ | |---> --->| collector |+ | |--->
+-----------+ +--------------+ +-----------+ +--------------+
+------------+ BGP (Redirect) +------------+ BGP (Redirect)
IPFIX +------------+| BGP Flowspec (Drop) IPFIX +------------+| BGP Flowspec (Drop)
<---| Forwarding ||<--- <---| Forwarding ||<---
skipping to change at page 15, line 29 skipping to change at line 615
| || |+x<==============[NTP Amp] | || |+x<==============[NTP Amp]
+-----||-----+ +-----||-----+
|| ||
|/ |/
+-----x------+ +-----x------+
| DDoS | | DDoS |
| mitigation | | mitigation |
| system | | system |
+------------+ +------------+
* C is for DOTS client functionality C: DOTS client functionality
* S is for DOTS server functionality S: DOTS server functionality
* DNS Amp: DNS Amplification DNS Amp: DNS Amplification
* NTP Amp: NTP Amplification NTP Amp: NTP Amplification
Figure 10: Selecting Mitigation Technique Based on Attack Type
Figure 10: DDoS Mitigation Based on Attack Type
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-dots-mapping:vendor-mapping": { "ietf-dots-mapping:vendor-mapping": {
"vendor": [ "vendor": [
{ {
"vendor-id": 32473, "vendor-id": 32473,
"vendor-name": "mitigator-c", "vendor-name": "mitigator-c",
"last-updated": "1629898958", "last-updated": "1629898958",
"attack-mapping": [ "attack-mapping": [
skipping to change at page 16, line 34 skipping to change at line 652
This attack is a type of reflection attack in which attackers \ This attack is a type of reflection attack in which attackers \
spoof a target's IP address. The attackers abuse vulnerabilities \ spoof a target's IP address. The attackers abuse vulnerabilities \
in NTP servers to turn small queries into larger payloads." in NTP servers to turn small queries into larger payloads."
} }
] ]
} }
] ]
} }
} }
Figure 11: Example of Message Body with Attack Mappings Figure 11: Example of Message Body with Attack Mappings
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::1/128" "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
}
] ]
} },
], "total-attack-traffic": [
"attack-detail": [ {
{ "unit": "megabit-ps",
"vendor-id": 32473, "low-percentile-g": "600",
"attack-id": 77, "mid-percentile-g": "800",
"start-time": "1641169211", "high-percentile-g": "1000",
"attack-severity": "high" "peak-g": "1100",
}, "current-g": "700"
{ }
"vendor-id": 32473, ],
"attack-id": 92, "total-attack-traffic-protocol": [
"start-time": "1641172809", {
"attack-severity": "high" "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, Figure 12: Example of Message Body with Total Attack Traffic,
Total Attack Traffic Protocol, Total Attack Connection and Attack Type Total Attack Traffic Protocol, Total Attack Connection, and
Attack Detail
Attack mappings are shared by using the DOTS data channel in advance Attack mappings are shared using the DOTS data channel in advance
(Section 8.1.6 of [RFC9244]). The forwarding nodes send traffic (Section 8.1.6 of [RFC9244]). The forwarding nodes send traffic
statistics to the flow collectors, e.g., using IPFIX. When DDoS statistics to the flow collectors, e.g., using IPFIX. When DDoS
attacks occur, the flow collectors identify attack traffic and send attacks occur, the flow collectors identify attack traffic and send
attack type information to the orchestrator by using "vendor-id" and attack type information to the orchestrator using the "vendor-id" and
"attack-id" telemetry attributes. The orchestrator then resolves "attack-id" telemetry attributes. The orchestrator then resolves
abused port numbers and orders relevant forwarding nodes to block the abused port numbers and orders relevant forwarding nodes to block the
amplification attack traffic flow by dissemination of Flow amplification attack traffic flow by dissemination of Flow
Specifications using tools such as Border Gateway Protocol Specifications using tools such as BGP Flowspec [RFC8955]. Also, the
Dissemination of Flow Specification Rules (BGP Flowspec) [RFC8955]. orchestrator orders relevant forwarding nodes to redirect traffic
Also, the orchestrator orders relevant forwarding nodes to redirect other than the amplification attack traffic using a routing protocol,
other traffic than the amplification attack traffic by using a such as BGP [RFC4271].
routing protocol, such as BGP [RFC4271].
The flow collector implements a DOTS client while the orchestrator The flow collector implements a DOTS client while the orchestrator
implements a DOTS server. implements a DOTS server.
3.2. Detailed DDoS Mitigation Report 3.2. Detailed DDoS Mitigation Report
It is possible for the transit provider to add value to the DDoS It is possible for the transit provider to add value to the DDoS
mitigation service by reporting ongoing and detailed DDoS mitigation service by reporting ongoing and detailed DDoS
countermeasure status to the enterprise network. In addition, it is countermeasure status to the enterprise network. In addition, it is
possible for the transit provider to know whether the DDoS possible for the transit provider to know whether the DDoS
countermeasure is effective or not by receiving reports from the countermeasure is effective or not by receiving reports from the
enterprise network. enterprise network.
This use case enables sharing of information about ongoing DDoS This use case enables the mutual sharing of information about ongoing
countermeasures between the transit provider and the enterprise DDoS countermeasures between the transit provider and the enterprise
network mutually. Figure 13 gives an overview of this use case. network. Figure 13 gives an overview of this use case. Figure 14
Figure 14 provides an example of a DOTS telemetry message body that provides an example of a DOTS telemetry message body that is used to
is used to signal total pipe capacity from the enterprise network signal total pipe capacity from the enterprise network administrator
administrator to the orchestrator in the ISP. Figure 15 provides an to the orchestrator in the ISP. Figure 15 provides an example of a
example of a DOTS telemetry message body that is used to signal DOTS telemetry message body that is used to signal percentiles for
various total traffic percentiles, total attack traffic percentiles, total traffic and total attack traffic as well as attack details from
and attack details from the orchestrator to the network. the orchestrator to the network.
+------------------+ +------------------------+ +------------------+ +------------------------+
| Enterprise | | Upstream | | Enterprise | | Upstream |
| Network | | Internet Transit | | Network | | Internet Transit |
| +------------+ | | Provider | | +------------+ | | Provider |
| | Network |C | | S+--------------+ | | | Network |C | | S+--------------+ |
| | admini- |<-----DOTS---->| Orchestrator | | | | admini- |<-----DOTS---->| Orchestrator | |
| | strator | | | +--------------+ | | | strator | | | +--------------+ |
| +------------+ | | C ^ | | +------------+ | | C ^ |
| | | | DOTS | | | | | DOTS |
skipping to change at page 19, line 26 skipping to change at line 780
| | | | DMS |+======= | | | | DMS |+=======
| | | +---------------+ | | | | +---------------+ |
| | | || Clean | | | | || Clean |
| | | |/ Traffic | | | | |/ Traffic |
| +---------+ | | +---------------+ | | +---------+ | | +---------------+ |
| | DDoS | | | | Forwarding | Normal Traffic | | DDoS | | | | Forwarding | Normal Traffic
| | Target |<================| Node |======== | | Target |<================| Node |========
| +---------+ | Link1 | +---------------+ | | +---------+ | Link1 | +---------------+ |
+------------------+ +------------------------+ +------------------+ +------------------------+
* C is for DOTS client functionality C: DOTS client functionality
* S is for DOTS server functionality S: DOTS server functionality
Figure 13: Detailed DDoS Mitigation Report Figure 13: Detailed DDoS Mitigation Report
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
{ {
"total-pipe-capacity": [ "total-pipe-capacity": [
{ {
"link-id": "link1", "link-id": "link1",
"capacity": "1000", "capacity": "1000",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
Figure 14: An Example of Message Body with Total Pipe Capacity
Figure 14: Example of Message Body with Total Pipe Capacity
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"tmid": 567, "tmid": 567,
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::1/128" "2001:db8::1/128"
] ]
}, },
skipping to change at page 20, line 42 skipping to change at line 841
"attack-id": 77, "attack-id": 77,
"start-time": "1644819611", "start-time": "1644819611",
"attack-severity": "high" "attack-severity": "high"
} }
] ]
} }
] ]
} }
} }
Figure 15: An Example of Message Body with Total Traffic, Figure 15: Example of Message Body with Total Traffic, Total
Total Attack Traffic Protocol, and Attack Detail Attack Traffic, and Attack Detail
The network management system in the enterprise network reports The network management system in the enterprise network reports
limits of incoming traffic volume from the transit provider to the limits of incoming traffic volume from the transit provider to the
orchestrator in the transit provider in advance. It is reported by orchestrator in the transit provider in advance. It is reported
using the "total-pipe-capacity" telemetry attribute in the DOTS using the "total-pipe-capacity" telemetry attribute in the DOTS
telemetry setup. telemetry setup.
When DDoS attacks occur, DDoS mitigation orchestration [RFC8903] is When DDoS attacks occur, DDoS mitigation orchestration [RFC8903] is
carried out in the transit provider. Then, the DDoS mitigation carried out in the transit provider. Then, the DDoS mitigation
systems report the status of DDoS countermeasures to the orchestrator systems report the status of DDoS countermeasures to the orchestrator
by sending "attack-detail" telemetry attributes. After that, the by sending "attack-detail" telemetry attributes. After that, the
orchestrator integrates the reports from the DDoS mitigation systems, orchestrator integrates the reports from the DDoS mitigation systems,
while removing duplicate contents, and sends the integrated report to while removing duplicate contents, and sends the integrated report to
a network administrator by using DOTS telemetry periodically. a network administrator using DOTS telemetry periodically.
During the DDoS mitigation, the orchestrator in the transit provider During the DDoS mitigation, the orchestrator in the transit provider
retrieves link congestion status from the network manager in the retrieves the link congestion status from the network manager in the
enterprise network by using "total-traffic" telemetry attributes. enterprise network using the "total-traffic" telemetry attributes.
Then, the orchestrator checks whether the DDoS countermeasures are Then, the orchestrator checks whether or not the DDoS countermeasures
effective or not by comparing the "total-traffic" and the "total- are effective by comparing the "total-traffic" and the "total-pipe-
pipe-capacity" attributes. capacity" telemetry attributes.
The DMS implements a DOTS server while the orchestrator behaves as a The DMS implements a DOTS server while the orchestrator behaves as a
DOTS client and a server in the transit provider. In addition, the DOTS client and a server in the transit provider. In addition, the
network administrator implements a DOTS client. network administrator implements a DOTS client.
3.3. Tuning Mitigation Resources 3.3. Tuning Mitigation Resources
3.3.1. Supervised Machine Learning of Flow Collector 3.3.1. Supervised Machine Learning of Flow Collector
DDoS detection based on tools, such as IPFIX, is a lighter weight DDoS detection based on tools, such as IPFIX, is a lighter-weight
method of detecting DDoS attacks than DMSes in Internet transit method of detecting DDoS attacks compared to DMSes in Internet
provider networks. DDoS detection based on the DMSes is a more transit provider networks. DDoS detection based on the DMSes is a
accurate method for detecting attack traffic than flow monitoring. more accurate method for detecting attack traffic than flow
monitoring.
The aim of this use case is to increase flow collectors' detection The aim of this use case is to increase flow collectors' detection
accuracy by carrying out supervised machine-learning techniques accuracy by carrying out supervised machine-learning techniques
according to attack detail reported by the DMSes. To use such a according to attack detail reported by the DMSes. To use such a
technique, forwarding nodes, flow collectors, and a DMS should technique, forwarding nodes, flow collectors, and a DMS should
cooperate. Figure 16 gives an overview of this use case. Figure 17 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 provides an example of a DOTS telemetry message body that is used to
signal various total attack traffic percentiles and attack detail. signal attack detail.
+-----------+ +-----------+
+-----------+| DOTS +-----------+| DOTS
IPFIX | Flow ||S<--- IPFIX | Flow ||S<---
--->| collector || --->| collector ||
+-----------++ +-----------++
+------------+ +------------+
IPFIX +------------+| IPFIX +------------+|
<---| Forwarding || <---| Forwarding ||
skipping to change at page 22, line 27 skipping to change at line 909
| || || ++======================== | || || ++========================
+---||-|| ||-+ +---||-|| ||-+
|| || || || || ||
|/ |/ |/ |/ |/ |/
DOTS +---X--X--X--+ DOTS +---X--X--X--+
--->C| DDoS | --->C| DDoS |
| mitigation | | mitigation |
| system | | system |
+------------+ +------------+
* C is for DOTS client functionality C: DOTS client functionality
* S is for DOTS server functionality S: DOTS server functionality
Figure 16: Supervised Machine Learning of Flow Collector
Figure 16: Training Supervised Machine Learning of Flow Collectors
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [ "pre-or-ongoing-mitigation": [
{ {
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::1/128" "2001:db8::1/128"
] ]
}, },
"attack-detail": [ "attack-detail": [
skipping to change at page 23, line 33 skipping to change at line 943
} }
] ]
} }
} }
] ]
} }
] ]
} }
} }
Figure 17: An Example of Message Body with Attack Type Figure 17: Example of Message Body with Attack Detail and Top Talkers
and top-talkers
The forwarding nodes send traffic statistics to the flow collectors, The forwarding nodes send traffic statistics to the flow collectors,
e.g., using IPFIX. When DDoS attacks occur, DDoS mitigation e.g., using IPFIX. When DDoS attacks occur, DDoS mitigation
orchestration is carried out (as per Section 3.3 of [RFC8903]) and orchestration is carried out (as per Section 3.3 of [RFC8903]), and
the DMS mitigates all attack traffic destined for a target. The DDoS the DMS mitigates all attack traffic destined for a target. The DDoS
mitigation system reports the "vendor-id", "attack-id", and "top- mitigation system reports the "vendor-id", "attack-id", and "top-
talker" telemetry attributes to a flow collector. talker" telemetry attributes to a flow collector.
After mitigating a DDoS attack, the flow collector attaches outputs After mitigating a DDoS attack, the flow collector attaches outputs
of the DMS as labels to the statistics of traffic flow of top- of the DMS as labels to the statistics of the traffic flow of top
talkers. The outputs, for example, are the "attack-id" telemetry talkers. The outputs, for example, are the "attack-id" telemetry
attributes. The flow collector then carries out supervised machine attributes. The flow collector then carries out supervised machine
learning to increase its detection accuracy, setting the statistics learning to increase its detection accuracy, setting the statistics
as an explanatory variable and setting the labels as an objective as an explanatory variable and setting the labels as an objective
variable. variable.
The DMS implements a DOTS client while the flow collector implements The DMS implements a DOTS client while the flow collector implements
a DOTS server. a DOTS server.
3.3.2. Unsupervised Machine Learning of Flow Collector 3.3.2. Unsupervised Machine Learning of Flow Collector
DMSes can detect DDoS attack traffic, which means DMSes can also DMSes can detect DDoS attack traffic, which means DMSes can also
identify clean traffic. This use case supports unsupervised machine- identify clean traffic. This use case supports unsupervised machine
learning for anomaly detection according to a baseline reported by learning for anomaly detection according to a baseline reported by
the DMSes. To use such a technique, forwarding nodes, flow the DMSes. To use such a technique, forwarding nodes, flow
collectors, and a DMS should cooperate. Figure 18 gives an overview collectors, and a DMS should cooperate. Figure 18 gives an overview
of this use case. Figure 19 provides an example of a DOTS telemetry of this use case. Figure 19 provides an example of a DOTS telemetry
message body that is used to signal baseline. message body that is used to signal baseline.
+-----------+ +-----------+
+-----------+| +-----------+|
DOTS | Flow || DOTS | Flow ||
--->S| collector || --->S| collector ||
skipping to change at page 24, line 40 skipping to change at line 995
| || |+ | || |+
+---||-------+ +---||-------+
|| ||
|/ |/
DOTS +---X--------+ DOTS +---X--------+
--->C| DDoS | --->C| DDoS |
| mitigation | | mitigation |
| system | | system |
+------------+ +------------+
* C is for DOTS client functionality C: DOTS client functionality
* S is for DOTS server functionality S: DOTS server functionality
Figure 18: Unsupervised Machine Learning of Flow Collector
Figure 18: Training Unsupervised Machine Learning of Flow Collectors
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
{ {
"baseline": [ "baseline": [
{ {
"id": 1, "id": 1,
"target-prefix": [ "target-prefix": [
"2001:db8:6401::1/128" "2001:db8:6401::1/128"
], ],
skipping to change at page 25, line 38 skipping to change at line 1034
"peak-g": "70" "peak-g": "70"
} }
] ]
} }
] ]
} }
] ]
} }
} }
Figure 19: An Example of Message Body with Traffic Baseline Figure 19: Example of Message Body with Traffic Baseline
The forwarding nodes carry out traffic mirroring to copy the traffic The forwarding nodes carry out traffic mirroring to copy the traffic
destined an IP address and to monitor the traffic by a DMS. The DMS destined to an IP address and to monitor the traffic by a DMS. The
then identifies "clean" traffic and reports the baseline attributes DMS then identifies clean traffic and reports the baseline telemetry
to the flow collector by using DOTS telemetry. attributes to the flow collector using DOTS telemetry.
The flow collector then carries out unsupervised machine learning to The flow collector then carries out unsupervised machine learning to
be able to carry out anomaly detection. be able to carry out anomaly detection.
The DMS implements a DOTS client while the flow collector implements The DMS implements a DOTS client while the flow collector implements
a DOTS server. a DOTS server.
4. Security Considerations 4. Security Considerations
DOTS telemetry security considerations are discussed in Section 14 of Security considerations for DOTS telemetry are discussed in
[RFC9244]. These considerations apply for the communication Section 14 of [RFC9244]. These considerations apply to the
interfaces where DOTS is used. communication interfaces where DOTS is used.
Some use cases involve controllers, orchestrators, and programmable Some use cases involve controllers, orchestrators, and programmable
interfaces. These interfaces can be misused by misbehaving nodes to interfaces. These interfaces can be misused by misbehaving nodes to
further exacerbate DDoS attacks. The considerations are for end-to- further exacerbate DDoS attacks. The considerations are for end-to-
end systems for DoS mitigation, so the mechanics are outside the end systems for DoS mitigation, so the mechanics are outside the
scope of DOTS protocols. Section 5 of [RFC7149] discusses some scope of DOTS protocols. Section 5 of [RFC7149] discusses some
generic security considerations to take into account in such contexts generic security considerations to take into account in such contexts
(e.g., reliable access control). Specific security measures depend (e.g., reliable access control). Specific security measures depend
on the actual mechanism used to control underlying forwarding nodes on the actual mechanism used to control underlying forwarding nodes
and other controlled elements. For example, Section 13 of [RFC8955] and other controlled elements. For example, Section 12 of [RFC8955]
discusses security considerations that are relevant to BGP Flowspec. discusses security considerations that are relevant to BGP Flowspec.
IPFIX-specific considerations are discussed in Section 11 of IPFIX-specific considerations are discussed in Section 11 of
[RFC7011]. [RFC7011].
5. IANA Considerations 5. IANA Considerations
This document does not require any action from IANA. This document has no IANA actions.
6. Acknowledgement
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, Phillip Hallam-Baker, Sean Turner,
and Peter Yee for the AD review.
Thanks to Lars Eggert, Murray Kucherawy, Roman Danyliw, Robert
Wiltonm, and Eric Vyncke for the IESG review.
7. References 6. References
7.1. Normative References 6.1. Normative References
[RFC9244] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M., [RFC9244] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M.,
and J. Shallow, "Distributed Denial-of-Service Open Threat and J. Shallow, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry", RFC 9244, Signaling (DOTS) Telemetry", RFC 9244,
DOI 10.17487/RFC9244, June 2022, DOI 10.17487/RFC9244, June 2022,
<https://www.rfc-editor.org/info/rfc9244>. <https://www.rfc-editor.org/info/rfc9244>.
7.2. Informative References 6.2. Informative References
[DNS_Water_Torture_Attack] [DNS_Water_Torture_Attack]
Xi, L., "A Large Scale Analysis of DNS Water Torture Luo, X., Wang, L., Xu, Z., Chen, K., Yang, J., and T.
Attack", DOI 10.1145/3297156.3297272, December 2018, 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>. <https://dl.acm.org/doi/10.1145/3297156.3297272>.
[DOTS_Overview] [DOTS_Overview]
Reddy, T. and M. Boucadair, "DOTS Overview (RFCs 8782, Reddy, T. and M. Boucadair, "DDoS Open Threat Signaling
8783)", July 2020, (DOTS)", July 2020,
<https://datatracker.ietf.org/meeting/108/materials/ <https://datatracker.ietf.org/meeting/108/materials/
slides-108-saag-dots-overview-00>. slides-108-saag-dots-overview-00>.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, Management Protocol (SNMP) Applications", STD 62,
RFC 3413, DOI 10.17487/RFC3413, December 2002, RFC 3413, DOI 10.17487/RFC3413, December 2002,
<https://www.rfc-editor.org/info/rfc3413>. <https://www.rfc-editor.org/info/rfc3413>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
skipping to change at page 28, line 26 skipping to change at line 1153
Bacher, "Dissemination of Flow Specification Rules", Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020, RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/info/rfc8955>. <https://www.rfc-editor.org/info/rfc8955>.
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
"Distributed Denial-of-Service Open Threat Signaling "Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification", RFC 9132, (DOTS) Signal Channel Specification", RFC 9132,
DOI 10.17487/RFC9132, September 2021, DOI 10.17487/RFC9132, September 2021,
<https://www.rfc-editor.org/info/rfc9132>. <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 Authors' Addresses
Yuhei Hayashi Yuhei Hayashi
NTT NTT
3-9-11, Midori-cho, Tokyo 3-9-11, Midori-cho, Tokyo
180-8585 180-8585
Japan Japan
Email: yuuhei.hayashi@gmail.com Email: yuuhei.hayashi@gmail.com
Meiling Chen Meiling Chen
CMCC China Mobile
32, Xuanwumen West 32, Xuanwumen West
BeiJing Beijing
BeiJing, 100053 100053
China China
Email: chenmeiling@chinamobile.com Email: chenmeiling@chinamobile.com
Li Su Li Su
CMCC China Mobile
32, Xuanwumen West 32, Xuanwumen West
BeiJing, BeiJing Beijing
100053 100053
China China
Email: suli@chinamobile.com Email: suli@chinamobile.com
 End of changes. 105 change blocks. 
331 lines changed or deleted 336 lines changed or added

This html diff was produced by rfcdiff 1.48.