From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9387.txt | 1195 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1195 insertions(+) create mode 100644 doc/rfc/rfc9387.txt (limited to 'doc/rfc/rfc9387.txt') 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, + . + +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, + . + + [DOTS_Overview] + Reddy, T. and M. Boucadair, "DDoS Open Threat Signaling + (DOTS)", July 2020, + . + + [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network + Management Protocol (SNMP) Applications", STD 62, + RFC 3413, DOI 10.17487/RFC3413, December 2002, + . + + [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, + . + + [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, + . + + [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, + . + + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + . + + [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open + Threat Signaling (DOTS) Requirements", RFC 8612, + DOI 10.17487/RFC8612, May 2019, + . + + [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, . + + [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, + . + + [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, + . + + [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, + . + + [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, + . + +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 -- cgit v1.2.3