summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9387.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9387.txt')
-rw-r--r--doc/rfc/rfc9387.txt1195
1 files changed, 1195 insertions, 0 deletions
diff --git a/doc/rfc/rfc9387.txt b/doc/rfc/rfc9387.txt
new file mode 100644
index 0000000..bdc1891
--- /dev/null
+++ b/doc/rfc/rfc9387.txt
@@ -0,0 +1,1195 @@
+
+
+
+
+Internet Engineering Task Force (IETF) Y. Hayashi
+Request for Comments: 9387 NTT
+Category: Informational M. Chen
+ISSN: 2070-1721 L. Su
+ China Mobile
+ April 2023
+
+
+ Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry
+
+Abstract
+
+ DDoS Open Threat Signaling (DOTS) telemetry enriches the base DOTS
+ protocols to assist the mitigator in using efficient DDoS attack
+ mitigation techniques in a network. This document presents sample
+ use cases for DOTS telemetry. It discusses what components are
+ deployed in the network, how they cooperate, and what information is
+ exchanged to effectively use these techniques.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are candidates for any level of Internet
+ Standard; see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc9387.
+
+Copyright Notice
+
+ Copyright (c) 2023 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Revised BSD License text as described in Section 4.e of the
+ Trust Legal Provisions and are provided without warranty as described
+ in the Revised BSD License.
+
+Table of Contents
+
+ 1. Introduction
+ 2. Terminology
+ 3. Telemetry Use Cases
+ 3.1. Mitigation Resources Assignment
+ 3.1.1. Mitigating Attack Flow of Top Talker Preferentially
+ 3.1.2. DMS Selection for Mitigation
+ 3.1.3. Path Selection for Redirection
+ 3.1.4. Short but Extreme Volumetric Attack Mitigation
+ 3.1.5. Selecting Mitigation Technique Based on Attack Type
+ 3.2. Detailed DDoS Mitigation Report
+ 3.3. Tuning Mitigation Resources
+ 3.3.1. Supervised Machine Learning of Flow Collector
+ 3.3.2. Unsupervised Machine Learning of Flow Collector
+ 4. Security Considerations
+ 5. IANA Considerations
+ 6. References
+ 6.1. Normative References
+ 6.2. Informative References
+ Acknowledgements
+ Authors' Addresses
+
+1. Introduction
+
+ Distributed Denial-of-Service (DDoS) attacks, such as volumetric
+ attacks and resource-consuming attacks, are critical threats to be
+ handled by service providers. When such DDoS attacks occur, service
+ providers have to mitigate them immediately to protect or recover
+ their services.
+
+ For service providers to immediately protect their network services
+ from DDoS attacks, DDoS mitigation needs to be highly automated. To
+ that aim, multivendor components involved in DDoS attack detection
+ and mitigation should cooperate and support standard interfaces.
+
+ DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time
+ signaling, threat-handling requests, and data filtering between the
+ multivendor elements [RFC9132] [RFC8783]. DOTS telemetry enriches
+ the DOTS protocols with various telemetry attributes allowing optimal
+ DDoS attack mitigation [RFC9244]. This document presents sample use
+ cases for DOTS telemetry to enhance the overview and the purpose
+ described in [RFC9244]. This document also presents what components
+ are deployed in the network, how they cooperate, and what information
+ is exchanged to effectively use attack-mitigation techniques.
+
+2. Terminology
+
+ Readers should be familiar with the terms defined in [RFC8612],
+ [RFC8903], and [RFC9244].
+
+ In addition, this document uses the following terms:
+
+ Supervised Machine Learning: A machine-learning technique in which
+ labeled data is used to train the algorithms (the input and output
+ data are known).
+
+ Unsupervised Machine Learning: A machine-learning technique in which
+ unlabeled data is used to train the algorithms (the data has no
+ historical labels).
+
+3. Telemetry Use Cases
+
+ This section describes DOTS telemetry use cases that use telemetry
+ attributes included in the DOTS telemetry specification [RFC9244].
+
+ The following subsections assume that once the DOTS signal channel is
+ established, DOTS clients will proceed with the telemetry setup
+ configuration detailed in Section 7 of [RFC9244]. The following
+ telemetry parameters are used:
+
+ * "measurement-interval" defines the period during which percentiles
+ are computed.
+
+ * "measurement-sample" defines the time distribution for measuring
+ values that are used to compute percentiles.
+
+3.1. Mitigation Resources Assignment
+
+3.1.1. Mitigating Attack Flow of Top Talker Preferentially
+
+ Some transit providers have to mitigate large-scale DDoS attacks
+ using DDoS Mitigation Systems (DMSes) with limited resources that are
+ already deployed in their network. For example, recently reported
+ large DDoS attacks exceeded several Tbps [DOTS_Overview].
+
+ This use case enables transit providers to use their DMS efficiently
+ under volume-based DDoS attacks whose volume is more than the
+ available capacity of the DMS. To enable this, the attack traffic of
+ top talkers is redirected to the DMS preferentially by cooperation
+ among forwarding nodes, flow collectors, and orchestrators.
+
+ Figure 1 gives an overview of this use case. Figure 2 provides an
+ example of a DOTS telemetry message body that is used to signal top
+ talkers (2001:db8:1::/48 and 2001:db8:2::/48).
+
+ (Internet Transit Provider)
+
+ +-----------+ +--------------+ SNMP or YANG/NETCONF
+ IPFIX +-----------+| DOTS | |<---
+ --->| Flow ||C<-->S| Orchestrator | BGP Flowspec
+ | collector |+ | |---> (Redirect)
+ +-----------+ +--------------+
+
+ +-------------+
+ IPFIX +-------------+| BGP Flowspec (Redirect)
+ <---| Forwarding ||<---
+ | nodes ||
+ | || DDoS Attack
+ [ Target(s) ]<==========================================
+ | ++=========================[top talker]
+ | || ++======================[top talker]
+ +----|| ||----+
+ || ||
+ || ||
+ |/ |/
+ +----x--x----+
+ | DDoS | SNMP or YANG/NETCONF
+ | mitigation |<---
+ | system |
+ +------------+
+
+ C: DOTS client functionality
+ S: DOTS server functionality
+
+ Figure 1: Mitigating Attack Flow of Top Talker Preferentially
+
+ {
+ "ietf-dots-telemetry:telemetry": {
+ "pre-or-ongoing-mitigation": [
+ {
+ "target": {
+ "target-prefix": [
+ "2001:db8::1/128"
+ ]
+ },
+ "total-attack-traffic-protocol": [
+ {
+ "protocol": 17,
+ "unit": "megabit-ps",
+ "mid-percentile-g": "900"
+ }
+ ],
+ "attack-detail": [
+ {
+ "vendor-id": 32473,
+ "attack-id": 77,
+ "start-time": "1645057211",
+ "attack-severity": "high",
+ "top-talker":{
+ "talker": [
+ {
+ "source-prefix": "2001:db8:1::/48",
+ "total-attack-traffic": [
+ {
+ "unit": "megabit-ps",
+ "mid-percentile-g": "100"
+ }
+ ]
+ },
+ {
+ "source-prefix": "2001:db8:2::/48",
+ "total-attack-traffic": [
+ {
+ "unit": "megabit-ps",
+ "mid-percentile-g": "90"
+ }
+ ]
+ }
+ ]
+ }
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+ Figure 2: Example of Message Body to Signal Top Talkers
+
+ The forwarding nodes send traffic statistics to the flow collectors,
+ e.g., using IP Flow Information Export (IPFIX) [RFC7011]. When DDoS
+ attacks occur, the flow collectors identify the attack traffic and
+ send information about the top talkers to the orchestrator using the
+ "target-prefix" and "top-talkers" DOTS telemetry attributes. The
+ orchestrator then checks the available capacity of the DMSes using a
+ network management protocol, such as the Simple Network Management
+ Protocol (SNMP) [RFC3413] or YANG with the Network Configuration
+ Protocol (YANG/NETCONF) [RFC7950]. After that, the orchestrator
+ orders the forwarding nodes to redirect as much of the top talker's
+ traffic to the DMSes as they can handle by dissemination of Flow
+ Specifications using tools such as Border Gateway Protocol
+ Dissemination of Flow Specification Rules (BGP Flowspec) [RFC8955].
+
+ The flow collector implements a DOTS client while the orchestrator
+ implements a DOTS server.
+
+3.1.2. DMS Selection for Mitigation
+
+ Transit providers can deploy their DMSes in clusters. Then, they can
+ select the DMS to be used to mitigate a DDoS attack at the time of an
+ attack.
+
+ This use case enables transit providers to select a DMS with
+ sufficient capacity for mitigation based on the volume of the attack
+ traffic and the capacity of the DMS. Figure 3 gives an overview of
+ this use case. Figure 4 provides an example of a DOTS telemetry
+ message body that is used to signal percentiles for total attack
+ traffic.
+
+(Internet Transit Provider)
+
+ +-----------+ +--------------+ SNMP or YANG/NETCONF
+ IPFIX +-----------+| DOTS | |<---
+ --->| Flow ||C<-->S| Orchestrator | BGP (Redirect)
+ | collector |+ | |--->
+ +-----------+ +--------------+
+
+ +------------+
+ IPFIX +------------+| BGP (Redirect)
+ <---| Forwarding ||<---
+ | nodes ||
+ | || DDoS Attack
+[Target A] | ++=================== [Destined for Target A]
+[Target B] | || ++=============== [Destined for Target B]
+ +-||--||-----+
+ || ||
+ ++====++ || (congested DMS)
+ || || +-----------+
+ || |/ | DMS3 |
+ || +-----x------+ |<--- SNMP or YANG/NETCONF
+ |/ | DMS2 |--------+
+ +--x---------+ |<--- SNMP or YANG/NETCONF
+ | DMS1 |------+
+ | |<--- SNMP or YANG/NETCONF
+ +------------+
+
+ C: DOTS client functionality
+ S: DOTS server functionality
+
+ Figure 3: DMS Selection for Mitigation
+
+ {
+ "ietf-dots-telemetry:telemetry": {
+ "pre-or-ongoing-mitigation": [
+ {
+ "target": {
+ "target-prefix": [
+ "192.0.2.3/32"
+ ]
+ },
+ "total-attack-traffic": [
+ {
+ "unit": "megabit-ps",
+ "low-percentile-g": "600",
+ "mid-percentile-g": "800",
+ "high-percentile-g": "1000",
+ "peak-g":"1100",
+ "current-g":"700"
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+ Figure 4: Example of Message Body with Total Attack Traffic
+
+ The forwarding nodes send traffic statistics to the flow collectors,
+ e.g., using IPFIX. When DDoS attacks occur, the flow collectors
+ identify the attack traffic and send information about the attack
+ traffic volume to the orchestrator using the "target-prefix" and
+ "total-attack-traffic" DOTS telemetry attributes. The orchestrator
+ then checks the available capacity of the DMSes using a network
+ management protocol, such as the Simple Network Management Protocol
+ (SNMP) [RFC3413] or YANG with the Network Configuration Protocol
+ (YANG/NETCONF) [RFC7950]. After that, the orchestrator selects a DMS
+ with sufficient capacity to which attack traffic should be
+ redirected. For example, a simple DMS selection algorithm can be
+ used to choose a DMS whose available capacity is greater than the
+ "peak-g" telemetry attribute indicated in the DOTS telemetry message.
+ The orchestrator orders the appropriate forwarding nodes to redirect
+ the attack traffic to the DMS relying upon routing policies, such as
+ BGP [RFC4271].
+
+ The detailed DMS selection algorithm is out of the scope of this
+ document.
+
+ The flow collector implements a DOTS client while the orchestrator
+ implements a DOTS server.
+
+3.1.3. Path Selection for Redirection
+
+ A transit provider network has multiple paths to convey attack
+ traffic to a DMS. In such a network, the attack traffic can be
+ conveyed while avoiding congested links by adequately selecting an
+ available path.
+
+ This use case enables transit providers to select a path with
+ sufficient bandwidth for redirecting attack traffic to a DMS
+ according to the bandwidth of the attack traffic and total traffic.
+ Figure 5 gives an overview of this use case. Figure 6 provides an
+ example of a DOTS telemetry message body that is used to signal
+ percentiles for total traffic and total attack traffic.
+
+ (Internet Transit Provider)
+
+ +-----------+ +--------------+ DOTS
+ +-----------+| | |S<---
+ IPFIX | Flow || DOTS | Orchestrator |
+ -->| collector ||C<-->S| | BGP Flowspec (Redirect)
+ | |+ | |--->
+ +-----------+ +--------------+
+
+ DOTS +------------+ DOTS +------------+ IPFIX
+ --->C| Forwarding | --->C| Forwarding |--->
+ BGP Flowspec | node | | node |
+ (Redirect) --->| | | | DDoS Attack
+ [Target] | ++====================================
+ +-------||---+ +------------+
+ || /
+ || / (congested link)
+ || /
+ DOTS +-||----------------+ BGP Flowspec (Redirect)
+ --->C| || Forwarding |<---
+ | ++=== node |
+ +----||-------------+
+ |/
+ +--x-----------+
+ | DMS |
+ +--------------+
+
+ C: DOTS client functionality
+ S: DOTS server functionality
+
+ Figure 5: Path Selection for Redirection
+
+ {
+ "ietf-dots-telemetry:telemetry": {
+ "pre-or-ongoing-mitigation": [
+ {
+ "target": {
+ "target-prefix": [
+ "2001:db8::1/128"
+ ]
+ },
+ "total-traffic": [
+ {
+ "unit": "megabit-ps",
+ "mid-percentile-g": "1300",
+ "peak-g": "800"
+ }
+ ],
+ "total-attack-traffic": [
+ {
+ "unit": "megabit-ps",
+ "low-percentile-g": "600",
+ "mid-percentile-g": "800",
+ "high-percentile-g": "1000",
+ "peak-g": "1100",
+ "current-g": "700"
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+ Figure 6: Example of Message Body with Total Attack Traffic and
+ Total Traffic
+
+ The forwarding nodes send traffic statistics to the flow collectors,
+ e.g., using IPFIX. When DDoS attacks occur, the flow collectors
+ identify attack traffic and send information about the attack traffic
+ volume to the orchestrator using the "target-prefix" and "total-
+ attack-traffic" DOTS telemetry attributes. The underlying forwarding
+ nodes send the volume of the total traffic passing the node to the
+ orchestrator using the "total-traffic" telemetry attributes. The
+ orchestrator then selects a path with sufficient bandwidth to which
+ the flow of attack traffic should be redirected. For example, a
+ simple selection algorithm can be used to choose a path whose
+ available capacity is greater than the "peak-g" telemetry attribute
+ that was indicated in a DOTS telemetry message. After that, the
+ orchestrator orders the appropriate forwarding nodes to redirect the
+ attack traffic to the DMS by dissemination of Flow Specifications
+ using tools such as BGP Flowspec [RFC8955].
+
+ The detailed path selection algorithm is out of the scope of this
+ document.
+
+ The flow collector and forwarding nodes implement a DOTS client while
+ the orchestrator implements a DOTS server.
+
+3.1.4. Short but Extreme Volumetric Attack Mitigation
+
+ Short but extreme volumetric attacks, such as pulse wave DDoS
+ attacks, are threats to Internet transit provider networks. These
+ attacks start from zero and go to maximum values in a very short time
+ span. The attacks go back to zero and then back to maximum values,
+ repeating in continuous cycles at short intervals. It is difficult
+ for transit providers to mitigate such an attack with their DMSes by
+ redirecting attack flows because this may cause route flapping in the
+ network. The practical way to mitigate short but extreme volumetric
+ attacks is to offload mitigation actions to a forwarding node.
+
+ This use case enables transit providers to mitigate short but extreme
+ volumetric attacks. Furthermore, the aim is to estimate the network-
+ access success rate based on the bandwidth of the attack traffic.
+ Figure 7 gives an overview of this use case. Figure 8 provides an
+ example of a DOTS telemetry message body that is used to signal total
+ pipe capacity. Figure 9 provides an example of a DOTS telemetry
+ message body that is used to signal various percentiles for total
+ traffic and total attack traffic.
+
+ (Internet Transit Provider)
+
+ +------------+ +----------------+
+ | Network | DOTS | Administrative | BGP Flowspec
+ Alert----->| Management |C<--->S| System | (Rate-Limit)
+ | System | | |--->
+ +------------+ +----------------+
+ BGP Flowspec
+ +------------+ +------------+ (Rate-Limit X bps)
+ | Forwarding | | Forwarding |<---
+ | node | | node |
+ Link1 | | | | DDoS & Normal traffic
+ [Target]<------------------------------------================
+ Pipe +------------+ +------------+ Attack Traffic
+ Capability Bandwidth
+ X bps Y bps
+
+ Network-access success rate
+ X / (X + Y)
+
+ C: DOTS client functionality
+ S: DOTS server functionality
+
+ Figure 7: Short but Extreme Volumetric Attack Mitigation
+
+ {
+ "ietf-dots-telemetry:telemetry-setup": {
+ "telemetry": [
+ {
+ "total-pipe-capacity": [
+ {
+ "link-id": "link1",
+ "capacity": "1000",
+ "unit": "megabit-ps"
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+ Figure 8: Example of Message Body with Total Pipe Capacity
+
+ {
+ "ietf-dots-telemetry:telemetry": {
+ "pre-or-ongoing-mitigation": [
+ {
+ "target": {
+ "target-prefix": [
+ "2001:db8::1/128"
+ ]
+ },
+ "total-traffic": [
+ {
+ "unit": "megabit-ps",
+ "mid-percentile-g": "800",
+ "peak-g": "1300"
+ }
+ ],
+ "total-attack-traffic": [
+ {
+ "unit": "megabit-ps",
+ "low-percentile-g": "200",
+ "mid-percentile-g": "400",
+ "high-percentile-g": "500",
+ "peak-g": "600",
+ "current-g": "400"
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+ Figure 9: Example of Message Body with Total Attack Traffic and
+ Total Traffic
+
+ When DDoS attacks occur, the network management system receives
+ alerts. Then, it sends the target IP address(es) and volume of the
+ DDoS attack traffic to the administrative system using the "target-
+ prefix" and "total-attack-traffic" DOTS telemetry attributes. After
+ that, the administrative system orders relevant forwarding nodes to
+ carry out rate-limiting of all traffic destined to the target based
+ on the pipe capability by the dissemination of the Flow
+ Specifications using tools such as BGP Flowspec [RFC8955]. In
+ addition, the administrative system estimates the network-access
+ success rate of the target, which is calculated by (total-pipe-
+ capability / (total-pipe-capability + total-attack-traffic)).
+
+ Note that total pipe capability information can be gathered by
+ telemetry setup in advance (Section 7.2 of [RFC9244]).
+
+ The network management system implements a DOTS client while the
+ administrative system implements a DOTS server.
+
+3.1.5. Selecting Mitigation Technique Based on Attack Type
+
+ Some volumetric attacks, such as DNS amplification attacks, can be
+ detected with high accuracy by checking the Layer 3 or Layer 4
+ information of attack packets. These attacks can be detected and
+ mitigated through cooperation among forwarding nodes and flow
+ collectors using IPFIX. It may also be necessary to inspect the
+ Layer 7 information of suspicious packets to detect attacks such as
+ DNS water torture attacks [DNS_Water_Torture_Attack]. To carry out
+ the DNS water torture attack, an attacker commands a botnet to make
+ thousands of DNS requests for fake subdomains against an
+ authoritative name server. Such attack traffic should be detected
+ and mitigated at the DMS.
+
+ This use case enables transit providers to select a mitigation
+ technique based on the type of attack traffic, whether it is an
+ amplification attack or not. To use such a technique, the attack
+ traffic is blocked by forwarding nodes or redirected to a DMS based
+ on the attack type through cooperation among forwarding nodes, flow
+ collectors, and an orchestrator.
+
+ Figure 10 gives an overview of this use case. Figure 11 provides an
+ example of attack mappings that are shared using the DOTS data
+ channel in advance. Figure 12 provides an example of a DOTS
+ telemetry message body that is used to signal percentiles for total
+ attack traffic, total attack traffic protocol, and total attack
+ connection; it also shows attack details.
+
+ The example in Figure 11 uses the folding defined in [RFC8792] for
+ long lines.
+
+ (Internet Transit Provider)
+
+ +-----------+ DOTS +--------------+
+ +-----------+|<---->| | BGP (Redirect)
+ IPFIX | Flow ||C S| Orchestrator | BGP Flowspec (Drop)
+ --->| collector |+ | |--->
+ +-----------+ +--------------+
+
+ +------------+ BGP (Redirect)
+ IPFIX +------------+| BGP Flowspec (Drop)
+ <---| Forwarding ||<---
+ | nodes || DDoS Attack
+ | ++=====||================
+ | || ||x<==============[DNS Amp]
+ | || |+x<==============[NTP Amp]
+ +-----||-----+
+ ||
+ |/
+ +-----x------+
+ | DDoS |
+ | mitigation |
+ | system |
+ +------------+
+
+ C: DOTS client functionality
+ S: DOTS server functionality
+ DNS Amp: DNS Amplification
+ NTP Amp: NTP Amplification
+
+ Figure 10: Selecting Mitigation Technique Based on Attack Type
+
+ =============== NOTE: '\' line wrapping per RFC 8792 ================
+
+ {
+ "ietf-dots-mapping:vendor-mapping": {
+ "vendor": [
+ {
+ "vendor-id": 32473,
+ "vendor-name": "mitigator-c",
+ "last-updated": "1629898958",
+ "attack-mapping": [
+ {
+ "attack-id": 77,
+ "attack-description": "DNS amplification Attack: \
+ This attack is a type of reflection attack in which attackers \
+ spoof a target's IP address. The attackers abuse vulnerabilities \
+ in DNS servers to turn small queries into larger payloads."
+ },
+ {
+ "attack-id": 92,
+ "attack-description":"NTP amplification Attack: \
+ This attack is a type of reflection attack in which attackers \
+ spoof a target's IP address. The attackers abuse vulnerabilities \
+ in NTP servers to turn small queries into larger payloads."
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+ Figure 11: Example of Message Body with Attack Mappings
+
+ {
+ "ietf-dots-telemetry:telemetry": {
+ "pre-or-ongoing-mitigation": [
+ {
+ "target": {
+ "target-prefix": [
+ "2001:db8::1/128"
+ ]
+ },
+ "total-attack-traffic": [
+ {
+ "unit": "megabit-ps",
+ "low-percentile-g": "600",
+ "mid-percentile-g": "800",
+ "high-percentile-g": "1000",
+ "peak-g": "1100",
+ "current-g": "700"
+ }
+ ],
+ "total-attack-traffic-protocol": [
+ {
+ "protocol": 17,
+ "unit": "megabit-ps",
+ "mid-percentile-g": "500"
+ },
+ {
+ "protocol": 15,
+ "unit": "megabit-ps",
+ "mid-percentile-g": "200"
+ }
+ ],
+ "total-attack-connection": [
+ {
+ "mid-percentile-l": [
+ {
+ "protocol": 15,
+ "connection": 200
+ }
+ ],
+ "high-percentile-l": [
+ {
+ "protocol": 17,
+ "connection": 300
+ }
+ ]
+ }
+ ],
+ "attack-detail": [
+ {
+ "vendor-id": 32473,
+ "attack-id": 77,
+ "start-time": "1641169211",
+ "attack-severity": "high"
+ },
+ {
+ "vendor-id": 32473,
+ "attack-id": 92,
+ "start-time": "1641172809",
+ "attack-severity": "high"
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+ Figure 12: Example of Message Body with Total Attack Traffic,
+ Total Attack Traffic Protocol, Total Attack Connection, and
+ Attack Detail
+
+ Attack mappings are shared using the DOTS data channel in advance
+ (Section 8.1.6 of [RFC9244]). The forwarding nodes send traffic
+ statistics to the flow collectors, e.g., using IPFIX. When DDoS
+ attacks occur, the flow collectors identify attack traffic and send
+ attack type information to the orchestrator using the "vendor-id" and
+ "attack-id" telemetry attributes. The orchestrator then resolves
+ abused port numbers and orders relevant forwarding nodes to block the
+ amplification attack traffic flow by dissemination of Flow
+ Specifications using tools such as BGP Flowspec [RFC8955]. Also, the
+ orchestrator orders relevant forwarding nodes to redirect traffic
+ other than the amplification attack traffic using a routing protocol,
+ such as BGP [RFC4271].
+
+ The flow collector implements a DOTS client while the orchestrator
+ implements a DOTS server.
+
+3.2. Detailed DDoS Mitigation Report
+
+ It is possible for the transit provider to add value to the DDoS
+ mitigation service by reporting ongoing and detailed DDoS
+ countermeasure status to the enterprise network. In addition, it is
+ possible for the transit provider to know whether the DDoS
+ countermeasure is effective or not by receiving reports from the
+ enterprise network.
+
+ This use case enables the mutual sharing of information about ongoing
+ DDoS countermeasures between the transit provider and the enterprise
+ network. Figure 13 gives an overview of this use case. Figure 14
+ provides an example of a DOTS telemetry message body that is used to
+ signal total pipe capacity from the enterprise network administrator
+ to the orchestrator in the ISP. Figure 15 provides an example of a
+ DOTS telemetry message body that is used to signal percentiles for
+ total traffic and total attack traffic as well as attack details from
+ the orchestrator to the network.
+
+ +------------------+ +------------------------+
+ | Enterprise | | Upstream |
+ | Network | | Internet Transit |
+ | +------------+ | | Provider |
+ | | Network |C | | S+--------------+ |
+ | | admini- |<-----DOTS---->| Orchestrator | |
+ | | strator | | | +--------------+ |
+ | +------------+ | | C ^ |
+ | | | | DOTS |
+ | | | S v |
+ | | | +---------------+ DDoS Attack
+ | | | | DMS |+=======
+ | | | +---------------+ |
+ | | | || Clean |
+ | | | |/ Traffic |
+ | +---------+ | | +---------------+ |
+ | | DDoS | | | | Forwarding | Normal Traffic
+ | | Target |<================| Node |========
+ | +---------+ | Link1 | +---------------+ |
+ +------------------+ +------------------------+
+
+ C: DOTS client functionality
+ S: DOTS server functionality
+
+ Figure 13: Detailed DDoS Mitigation Report
+
+ {
+ "ietf-dots-telemetry:telemetry-setup": {
+ "telemetry": [
+ {
+ "total-pipe-capacity": [
+ {
+ "link-id": "link1",
+ "capacity": "1000",
+ "unit": "megabit-ps"
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+ Figure 14: Example of Message Body with Total Pipe Capacity
+
+ {
+ "ietf-dots-telemetry:telemetry": {
+ "pre-or-ongoing-mitigation": [
+ {
+ "tmid": 567,
+ "target": {
+ "target-prefix": [
+ "2001:db8::1/128"
+ ]
+ },
+ "target-protocol": [
+ 17
+ ],
+ "total-traffic": [
+ {
+ "unit": "megabit-ps",
+ "mid-percentile-g": "800"
+ }
+ ],
+ "total-attack-traffic": [
+ {
+ "unit": "megabit-ps",
+ "mid-percentile-g": "100"
+ }
+ ],
+ "attack-detail": [
+ {
+ "vendor-id": 32473,
+ "attack-id": 77,
+ "start-time": "1644819611",
+ "attack-severity": "high"
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+ Figure 15: Example of Message Body with Total Traffic, Total
+ Attack Traffic, and Attack Detail
+
+ The network management system in the enterprise network reports
+ limits of incoming traffic volume from the transit provider to the
+ orchestrator in the transit provider in advance. It is reported
+ using the "total-pipe-capacity" telemetry attribute in the DOTS
+ telemetry setup.
+
+ When DDoS attacks occur, DDoS mitigation orchestration [RFC8903] is
+ carried out in the transit provider. Then, the DDoS mitigation
+ systems report the status of DDoS countermeasures to the orchestrator
+ by sending "attack-detail" telemetry attributes. After that, the
+ orchestrator integrates the reports from the DDoS mitigation systems,
+ while removing duplicate contents, and sends the integrated report to
+ a network administrator using DOTS telemetry periodically.
+
+ During the DDoS mitigation, the orchestrator in the transit provider
+ retrieves the link congestion status from the network manager in the
+ enterprise network using the "total-traffic" telemetry attributes.
+ Then, the orchestrator checks whether or not the DDoS countermeasures
+ are effective by comparing the "total-traffic" and the "total-pipe-
+ capacity" telemetry attributes.
+
+ The DMS implements a DOTS server while the orchestrator behaves as a
+ DOTS client and a server in the transit provider. In addition, the
+ network administrator implements a DOTS client.
+
+3.3. Tuning Mitigation Resources
+
+3.3.1. Supervised Machine Learning of Flow Collector
+
+ DDoS detection based on tools, such as IPFIX, is a lighter-weight
+ method of detecting DDoS attacks compared to DMSes in Internet
+ transit provider networks. DDoS detection based on the DMSes is a
+ more accurate method for detecting attack traffic than flow
+ monitoring.
+
+ The aim of this use case is to increase flow collectors' detection
+ accuracy by carrying out supervised machine-learning techniques
+ according to attack detail reported by the DMSes. To use such a
+ technique, forwarding nodes, flow collectors, and a DMS should
+ cooperate. Figure 16 gives an overview of this use case. Figure 17
+ provides an example of a DOTS telemetry message body that is used to
+ signal attack detail.
+
+ +-----------+
+ +-----------+| DOTS
+ IPFIX | Flow ||S<---
+ --->| collector ||
+ +-----------++
+
+ +------------+
+ IPFIX +------------+|
+ <---| Forwarding ||
+ | nodes || DDoS Attack
+ [ Target ] | ++==============================
+ | || ++===========================
+ | || || ++========================
+ +---||-|| ||-+
+ || || ||
+ |/ |/ |/
+ DOTS +---X--X--X--+
+ --->C| DDoS |
+ | mitigation |
+ | system |
+ +------------+
+
+ C: DOTS client functionality
+ S: DOTS server functionality
+
+ Figure 16: Supervised Machine Learning of Flow Collector
+
+ {
+ "ietf-dots-telemetry:telemetry": {
+ "pre-or-ongoing-mitigation": [
+ {
+ "target": {
+ "target-prefix": [
+ "2001:db8::1/128"
+ ]
+ },
+ "attack-detail": [
+ {
+ "vendor-id": 32473,
+ "attack-id": 77,
+ "start-time": "1634192411",
+ "attack-severity": "high",
+ "top-talker": {
+ "talker": [
+ {
+ "source-prefix": "2001:db8::2/127"
+ }
+ ]
+ }
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+ Figure 17: Example of Message Body with Attack Detail and Top Talkers
+
+ The forwarding nodes send traffic statistics to the flow collectors,
+ e.g., using IPFIX. When DDoS attacks occur, DDoS mitigation
+ orchestration is carried out (as per Section 3.3 of [RFC8903]), and
+ the DMS mitigates all attack traffic destined for a target. The DDoS
+ mitigation system reports the "vendor-id", "attack-id", and "top-
+ talker" telemetry attributes to a flow collector.
+
+ After mitigating a DDoS attack, the flow collector attaches outputs
+ of the DMS as labels to the statistics of the traffic flow of top
+ talkers. The outputs, for example, are the "attack-id" telemetry
+ attributes. The flow collector then carries out supervised machine
+ learning to increase its detection accuracy, setting the statistics
+ as an explanatory variable and setting the labels as an objective
+ variable.
+
+ The DMS implements a DOTS client while the flow collector implements
+ a DOTS server.
+
+3.3.2. Unsupervised Machine Learning of Flow Collector
+
+ DMSes can detect DDoS attack traffic, which means DMSes can also
+ identify clean traffic. This use case supports unsupervised machine
+ learning for anomaly detection according to a baseline reported by
+ the DMSes. To use such a technique, forwarding nodes, flow
+ collectors, and a DMS should cooperate. Figure 18 gives an overview
+ of this use case. Figure 19 provides an example of a DOTS telemetry
+ message body that is used to signal baseline.
+
+ +-----------+
+ +-----------+|
+ DOTS | Flow ||
+ --->S| collector ||
+ +-----------++
+
+ +------------+
+ +------------+|
+ | Forwarding ||
+ | nodes || Traffic
+ [ Destination ] <== =============++==============================
+ | || ||
+ | || |+
+ +---||-------+
+ ||
+ |/
+ DOTS +---X--------+
+ --->C| DDoS |
+ | mitigation |
+ | system |
+ +------------+
+
+ C: DOTS client functionality
+ S: DOTS server functionality
+
+ Figure 18: Unsupervised Machine Learning of Flow Collector
+
+ {
+ "ietf-dots-telemetry:telemetry-setup": {
+ "telemetry": [
+ {
+ "baseline": [
+ {
+ "id": 1,
+ "target-prefix": [
+ "2001:db8:6401::1/128"
+ ],
+ "target-port-range": [
+ {
+ "lower-port": "53"
+ }
+ ],
+ "target-protocol": [
+ 17
+ ],
+ "total-traffic-normal": [
+ {
+ "unit": "megabit-ps",
+ "low-percentile-g": "30",
+ "mid-percentile-g": "50",
+ "high-percentile-g": "60",
+ "peak-g": "70"
+ }
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+ Figure 19: Example of Message Body with Traffic Baseline
+
+ The forwarding nodes carry out traffic mirroring to copy the traffic
+ destined to an IP address and to monitor the traffic by a DMS. The
+ DMS then identifies clean traffic and reports the baseline telemetry
+ attributes to the flow collector using DOTS telemetry.
+
+ The flow collector then carries out unsupervised machine learning to
+ be able to carry out anomaly detection.
+
+ The DMS implements a DOTS client while the flow collector implements
+ a DOTS server.
+
+4. Security Considerations
+
+ Security considerations for DOTS telemetry are discussed in
+ Section 14 of [RFC9244]. These considerations apply to the
+ communication interfaces where DOTS is used.
+
+ Some use cases involve controllers, orchestrators, and programmable
+ interfaces. These interfaces can be misused by misbehaving nodes to
+ further exacerbate DDoS attacks. The considerations are for end-to-
+ end systems for DoS mitigation, so the mechanics are outside the
+ scope of DOTS protocols. Section 5 of [RFC7149] discusses some
+ generic security considerations to take into account in such contexts
+ (e.g., reliable access control). Specific security measures depend
+ on the actual mechanism used to control underlying forwarding nodes
+ and other controlled elements. For example, Section 12 of [RFC8955]
+ discusses security considerations that are relevant to BGP Flowspec.
+ IPFIX-specific considerations are discussed in Section 11 of
+ [RFC7011].
+
+5. IANA Considerations
+
+ This document has no IANA actions.
+
+6. References
+
+6.1. Normative References
+
+ [RFC9244] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M.,
+ and J. Shallow, "Distributed Denial-of-Service Open Threat
+ Signaling (DOTS) Telemetry", RFC 9244,
+ DOI 10.17487/RFC9244, June 2022,
+ <https://www.rfc-editor.org/info/rfc9244>.
+
+6.2. Informative References
+
+ [DNS_Water_Torture_Attack]
+ Luo, X., Wang, L., Xu, Z., Chen, K., Yang, J., and T.
+ Tian, "A Large Scale Analysis of DNS Water Torture
+ Attack", CSAI '18: Proceedings of the 2018 2nd
+ International Conference on Computer Science and
+ Artificial Intelligence, pp. 168-173,
+ DOI 10.1145/3297156.3297272, December 2018,
+ <https://dl.acm.org/doi/10.1145/3297156.3297272>.
+
+ [DOTS_Overview]
+ Reddy, T. and M. Boucadair, "DDoS Open Threat Signaling
+ (DOTS)", July 2020,
+ <https://datatracker.ietf.org/meeting/108/materials/
+ slides-108-saag-dots-overview-00>.
+
+ [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
+ Management Protocol (SNMP) Applications", STD 62,
+ RFC 3413, DOI 10.17487/RFC3413, December 2002,
+ <https://www.rfc-editor.org/info/rfc3413>.
+
+ [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+ Border Gateway Protocol 4 (BGP-4)", RFC 4271,
+ DOI 10.17487/RFC4271, January 2006,
+ <https://www.rfc-editor.org/info/rfc4271>.
+
+ [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
+ "Specification of the IP Flow Information Export (IPFIX)
+ Protocol for the Exchange of Flow Information", STD 77,
+ RFC 7011, DOI 10.17487/RFC7011, September 2013,
+ <https://www.rfc-editor.org/info/rfc7011>.
+
+ [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
+ Networking: A Perspective from within a Service Provider
+ Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
+ <https://www.rfc-editor.org/info/rfc7149>.
+
+ [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
+ RFC 7950, DOI 10.17487/RFC7950, August 2016,
+ <https://www.rfc-editor.org/info/rfc7950>.
+
+ [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
+ Threat Signaling (DOTS) Requirements", RFC 8612,
+ DOI 10.17487/RFC8612, May 2019,
+ <https://www.rfc-editor.org/info/rfc8612>.
+
+ [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
+ Denial-of-Service Open Threat Signaling (DOTS) Data
+ Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
+ May 2020, <https://www.rfc-editor.org/info/rfc8783>.
+
+ [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
+ "Handling Long Lines in Content of Internet-Drafts and
+ RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
+ <https://www.rfc-editor.org/info/rfc8792>.
+
+ [RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
+ L., and K. Nishizuka, "Use Cases for DDoS Open Threat
+ Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021,
+ <https://www.rfc-editor.org/info/rfc8903>.
+
+ [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
+ Bacher, "Dissemination of Flow Specification Rules",
+ RFC 8955, DOI 10.17487/RFC8955, December 2020,
+ <https://www.rfc-editor.org/info/rfc8955>.
+
+ [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
+ "Distributed Denial-of-Service Open Threat Signaling
+ (DOTS) Signal Channel Specification", RFC 9132,
+ DOI 10.17487/RFC9132, September 2021,
+ <https://www.rfc-editor.org/info/rfc9132>.
+
+Acknowledgements
+
+ The authors would like to thank Mohamed Boucadair and Valery Smyslov
+ for their valuable feedback.
+
+ Thanks to Paul Wouters for the detailed AD review.
+
+ Many thanks to Donald Eastlake 3rd, Phillip Hallam-Baker, Sean
+ Turner, and Peter Yee for their reviews.
+
+ Thanks to Lars Eggert, Murray Kucherawy, Roman Danyliw, Robert
+ Wilton, and Éric Vyncke for the IESG review.
+
+Authors' Addresses
+
+ Yuhei Hayashi
+ NTT
+ 3-9-11, Midori-cho, Tokyo
+ 180-8585
+ Japan
+ Email: yuuhei.hayashi@gmail.com
+
+
+ Meiling Chen
+ China Mobile
+ 32, Xuanwumen West
+ Beijing
+ 100053
+ China
+ Email: chenmeiling@chinamobile.com
+
+
+ Li Su
+ China Mobile
+ 32, Xuanwumen West
+ Beijing
+ 100053
+ China
+ Email: suli@chinamobile.com