Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry

This section describes DOTS telemetry use cases that use attributes included in the DOTS telemetry specification . The following subsections assume that once the DOTS signal channel is established, DOTS clients proceed with the telemetry setup configuration as detailed in Section 7 of . The following telemetry parameters are used:

'measurement-interval' to define the period during which percentiles are computed.
'measurement-sample' to define the time distribution for measuring values that are used to compute percentiles.

Some transit providers have to mitigate large-scale DDoS attacks by using DDoS Mitigation Systems (DMSes) with limited resources, which are already deployed in their network. For example, recently reported large DDoS attacks exceeded several Tbps. 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::2/128 and 2001:db8::3/128).

| Flow ||C<-->S| Orchestrator | e.g., BGP Flowspec | collector |+ | |---> (Redirect) +-----------+ +--------------+ +-------------+ e.g., IPFIX +-------------+| e.g., BGP Flowspec <---| Forwarding ||<--- (Redirect) | nodes || | || DDoS Attack [ Target(s) ]=========================================== | ++=========================[top-talker] | || ++======================[top-talker] +----|| ||---+ || || || || |/ |/ +----x--x----+ | DDoS | e.g., SNMP or YANG/NETCONF | mitigation |<--- | system | +------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 1: Mitigating DDoS Attack Flow of Top-talkers Preferentially ]]>

The forwarding nodes send traffic statistics to the flow collectors, e.g., using IP Flow Information Export (IPFIX) . 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 by using a network management protocol, such as Simple Network Management Protocol (SNMP) or YANG with Network Configuration Protocol (YANG/NETCONF) . After that, the orchestrator orders the forwarding nodes to redirect as much of the top-talker's traffic to each DMS as that DMS can handle by dissemination of Flow Specifications using tools such as Border Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec) . The flow collector implements a DOTS client while the orchestrator implements a DOTS server.

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 an DMS with sufficient capacity for mitigation based on the volume of the attack traffic and the capacity of a 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 various attack traffic percentiles.

| Flow ||C<-->S| Orchestrator | e.g., BGP | collector |+ | |---> (Redirect) +-----------+ +--------------+ +------------+ e.g., IPFIX +------------+| e.g., BGP <---| Forwarding ||<--- (Redirect) | nodes || | || DDoS Attack [Target A] | ++=================== [Destined for Target A] [Target B] | || ++=============== [Destined for Target B] +-||--||-----+ || || ++====++ || (congested DMS) || || +-----------+ || |/ | DMS3 | || +-----x------+ |<--- e.g., SNMP or YANG/NETCONF |/ | DMS2 |--------+ +--x---------+ |<--- e.g., SNMP or YANG/NETCONF | DMS1 |------+ | |<--- e.g., SNMP or YANG/NETCONF +------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 3: DMS Selection for Mitigation ]]>

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 by using the "target-prefix" and "total-attack-traffic" DOTS telemetry attributes. The orchestrator then checks the available capacity of the DMSes by using a network management protocol, such as Simple Network Management Protocol (SNMP) or YANG with Network Configuration Protocol (YANG/NETCONF) . After that, the orchestrator selects an DMS with sufficient capacity to which attack traffic should be redirected. For example, a simple DMS selection algorithm is to choose a DMS whose available capacity is greater than the "peak-g" 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 . 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.

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 an 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 various attack traffic percentiles and total traffic percentiles.

| collector ||C<-->S| | e.g., BGP Flowspec | |+ | |---> (Redirect) +-----------+ +--------------+ DOTS +------------+ DOTS +------------+ e.g., IPFIX --->C| Forwarding | --->C| Forwarding |---> e.g., BGP Flowspec | node | | node | (Redirect) --->| | | | DDoS Attack [Target] | ++==================================== +-------||---+ +------------+ || / || / (congested link) || / DOTS +-||----------------+ e.g., BGP Flowspec --->C| || Forwarding |<--- (Redirect) | ++=== node | +----||-------------+ |/ +--x-----------+ | DMS | +--------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 5: Path Selection for Redirection ]]>

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 by using "target-prefix" and "total-attack-traffic" DOTS telemetry attributes. The underlying forwarding nodes send the volume on the total traffic passing the node to the orchestrator by using "total-traffic" telemetry attributes. The orchestrator then selects an path with sufficient bandwidth to which attack-traffic flow should be redirected. For example, the simple algorithm of the selection is to choose a path whose available capacity is greater than the "peak-g" 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 Border Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec) . 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.

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, then go back to zero, and then back to maximum, repeating in continuous cycles at short intervals. It is difficult for the transit providers to mitigate such an attack with their DMSes using a 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 attack traffic percentiles and total traffic percentiles.

| Management |C<--->S| System | e.g., BGP Flowspec | System | | |---> (Rate-Limit) +------------+ +----------------+ +------------+ +------------+ e.g., BGP Flowspec | Forwarding | | Forwarding |<--- (Rate-Limit X bps) | node | | node | Link1 | | | | DDoS & Normal traffic [Target]<------------------------------------================ Pipe +------------+ +------------+ Attack Traffic Capability Bandwidth e.g., X bps e.g., Y bps Network access success rate e.g., X / (X + Y) * C is for DOTS client functionality * S is for DOTS server functionality Figure 7: Short but Extreme Volumetric Attack Mitigation ]]>

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 by 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 Border Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec) . 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 ). The network management system implements a DOTS client while the administrative system implements a DOTS server.

Some volumetric attacks, such as 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 by 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 . 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: 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 by using the DOTS data channel in advance. Figure 12 provides an example of a DOTS telemetry message body that is used to signal various attack traffic percentiles, total traffic percentiles, total attack connection, and attack type. The example in Figure 11 uses the folding defined in for long lines.

| | BGP (Redirect) IPFIX | Flow ||C S| Orchestrator | BGP Flowspec (Drop) --->| collector |+ | |---> +-----------+ +--------------+ +------------+ e.g., BGP (Redirect) e.g., IPFIX +------------+| BGP Flowspec (Drop) <---| Forwarding ||<--- | nodes || DDoS Attack | ++=====||================ | || ||x<==============[e.g., DNS Amp] | || |+x<==============[e.g., NTP Amp] +-----||-----+ || |/ +-----x------+ | DDoS | | mitigation | | system | +------------+ * C is for DOTS client functionality * S is for DOTS server functionality * DNS Amp: DNS Amplification * NTP Amp: NTP Amplification Figure 10: DDoS Mitigation Based on Attack Type ]]>

Attack mappings are shared by using the DOTS data channel in advance (Section 8.1.6 of ). 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 by using "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 Border Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec) . Also, the orchestrator orders relevant forwarding nodes to redirect other traffic than the amplification attack traffic by using a routing protocol, such as BGP . The flow collector implements a DOTS client while the orchestrator implements a DOTS server.

It is possible for the transit provider to add value to the DDoS mitigation service by reporting on-going 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 sharing of information about on-going DDoS countermeasures between the transit provider and the enterprise network mutually. 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 various total traffic percentiles, total attack traffic percentiles, and attack details from the orchestrator to the network.

| Orchestrator | | | | strator | | | +--------------+ | | +------------+ | | C ^ | | | | | DOTS | | | | S v | | | | +---------------+ DDoS Attack | | | | DMS |+======= | | | +---------------+ | | | | || Clean | | | | |/ Traffic | | +---------+ | | +---------------+ | | | DDoS | | | | Forwarding | Normal Traffic | | Target |<================| Node |======== | +---------+ | Link1 | +---------------+ | +------------------+ +------------------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 13: Detailed DDoS Mitigation Report ]]>

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 by using the "total-pipe-capacity" telemetry attribute in the DOTS telemetry setup. When DDoS attacks occur, DDoS mitigation orchestration 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 by using DOTS telemetry periodically. During the DDoS mitigation, the orchestrator in the transit provider retrieves link congestion status from the network manager in the enterprise network by using "total-traffic" telemetry attributes. Then, the orchestrator checks whether the DDoS countermeasures are effective or not by comparing the "total-traffic" and the "total-pipe-capacity" 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.

DDoS detection based on tools, such as IPFIX, is a lighter weight method of detecting DDoS attacks than 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 various total attack traffic percentiles and attack detail.

| collector || +-----------++ +------------+ e.g., IPFIX +------------+| <---| Forwarding || | nodes || DDoS Attack [ Target ] | ++============================== | || ++=========================== | || || ++======================== +---||-|| ||-+ || || || |/ |/ |/ DOTS +---X--X--X--+ --->C| DDoS | | mitigation | | system | +------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 16: Training Supervised Machine Learning of Flow Collectors ]]>

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 ) 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 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.

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.

S| collector || +-----------++ +------------+ +------------+| | Forwarding || | nodes || Traffic [ Destination ] <== =============++============================== | || || | || |+ +---||-------+ || |/ DOTS +---X--------+ --->C| DDoS | | mitigation | | system | +------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 18: Training Unsupervised Machine Learning of Flow Collectors ]]>

The forwarding nodes carry out traffic mirroring to copy the traffic destined a IP address and to monitor the traffic by a DMS. The DMS then identifies "clean" traffic and reports the baseline attributes to the flow collector by 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.