| DOTS | R. Dobbins |
| Internet-Draft | Arbor Networks |
| Intended status: Informational | D. Migault |
| Expires: November 30, 2020 | Ericsson |
| R. Moskowitz | |
| HTT Consulting | |
| N. Teague | |
| Iron Mountain Data Centers | |
| L. Xia | |
| Huawei | |
| K. Nishizuka | |
| NTT Communications | |
| May 29, 2020 |
Use cases for DDoS Open Threat Signaling
draft-ietf-dots-use-cases-22
The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS mitigation solutions. This document presents sample use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what are the typical information to be exchanged.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 30, 2020.
Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
At the time of writing, distributed denial-of-service (DDoS) attack mitigation solutions are largely based upon siloed, proprietary communications schemes with vendor lock-in as a side-effect. This can result in the configuration, provisioning, operation, and activation of these solutions being a highly manual and often time-consuming process. Additionally, coordinating multiple DDoS mitigation solutions simultaneously is fraught with both technical and process-related hurdles. This greatly increases operational complexity which, in turn, can degrade the efficacy of mitigations.
The DDoS Open Threat Signaling (DOTS) effort is intended to specify protocols that facilitate interoperability between diverse DDoS mitigation solutions and ensure greater integration in term of attack detection, mitigation requests, and attack characterization patterns.
As DDoS solutions are broadly heterogeneous among vendors, the primary goal of DOTS is to provide high-level interaction amongst differing DDoS solutions, such as detecting DDoS attacks, initiating/terminating DDoS mitigation assistance, or requesting the status of a DDoS mitigation.
This document provides sample use cases that provided input for the design of the DOTS protocols [RFC8772][RFC8773]. The use cases are not exhaustive and future use cases are expected to emerge as DOTS is adopted and evolves.
This document makes use of the same terminology and definitions as [RFC8612]. In addition it uses the terms defined below:
This use case describes how an enterprise or a residential customer network may take advantage of a pre-existing relation with its Internet Transit Provider (ITP) in order to mitigate a DDoS attack targeting its network.
For clarity of discussion, the targeted network is indicated as an enterprise network, but the same scenario applies to any downstream network, including residential and cloud hosting networks.
As the ITP provides connectivity to the enterprise network, it is already on the path of the inbound and outbound traffic of the enterprise network and well aware of the networking parameters associated to the enterprise network WAN connectivity. This eases both the configuration and the instantiation of a DDoS Mitigation Service.
This section considers two kind of DDoS Mitigation Service between an enterprise network and an ITP:
The two scenarios, thought different, have similar interactions between the DOTS client and server. For the sake of simplicity, only the first scenario will be detailed in this section. Nevertheless, the second scenario is also in scope for DOTS.
In the first scenario, as depicted in Figure 1, an enterprise network with self-hosted Internet-facing properties such as Web servers, authoritative DNS servers, and VoIP servers has a DMS deployed to protect those servers and applications from DDoS attacks. In addition to on-premise DDoS defense capability, the enterprise has contracted with its ITP for DDoS Mitigation Services when attacks threaten to overwhelm the bandwidth of their WAN link(s).
+------------------+ +------------------+
| Enterprise | | Upstream |
| Network | | Internet Transit |
| | | Provider |
| +--------+ | | DDoS Attack
| | DDoS | | <=================================
| | Target | | <=================================
| +--------+ | | +------------+ |
| | +-------->| DDoS | |
| | | |S | Mitigation | |
| | | | | System | |
| | | | +------------+ |
| | | | |
| | | | |
| | | | |
| +------------+ | | | |
| | DDoS |<---+ | |
| | Mitigation |C | | |
| | System | | | |
| +------------+ | | |
+------------------+ +------------------+
* C is for DOTS client functionality
* S is for DOTS server functionality
Figure 1: Upstream Internet Transit Provider DDoS Mitigation
The enterprise DMS is configured such that if the incoming Internet traffic volume exceeds 50% of the provisioned upstream Internet WAN link capacity, the DMS will request DDoS mitigation assistance from the upstream transit provider. More sophisticated detection means may be considered as well.
The requests to trigger, manage, and finalize a DDoS Mitigation between the enterprise DMS and the ITP is performed using DOTS. The enterprise DMS implements a DOTS client while the ITP implements a DOTS server which is integrated with their DMS in this example.
When the enterprise DMS locally detects an inbound DDoS attack targeting its resources (e.g., servers, hosts, or applications), it immediately begins a DDoS Mitigation.
During the course of the attack, the inbound traffic volume to the enterprise network exceeds the 50% threshold and the enterprise DMS escalates the DDoS mitigation. The enterprise DMS DOTS client signals to the DOTS server on the upstream ITP to initiate DDoS Mitigation. The DOTS server replies to the DOTS client that it can serve this request, and mitigation is initiated on the ITP network by the ITP DMS.
Over the course of the attack, the DOTS server of the ITP periodically informs the DOTS client on the mitigation status, statistics related to DDoS attack traffic mitigation, and related information. Once the DDoS attack has ended, or decreased to the certain level that the enterprise DMS might handle by itself, the DOTS server signals the enterprise DMS DOTS client that the attack has subsided.
The DOTS client on the enterprise DMS then requests the ITP to terminate the DDoS Mitigation. The DOTS server on the ITP receives this request and once the mitigation has ended, confirms the end of upstream DDoS Mitigation to the enterprise DMS DOTS client.
The following is an overview of the DOTS communication model for this use-case:
Note that communications between the enterprise DOTS client and the upstream ITP DOTS server may take place in-band within the main Internet WAN link between the enterprise and the ITP; out-of-band via a separate, dedicated wireline network link utilized solely for DOTS signaling; or out-of-band via some other form of network connectivity such as a third-party wireless 4G network connectivity.
Note also that a DOTS client that sends a DOTS Mitigation request may be also triggered by a network admin that manually confirms the request to the upstream ITP, in which case the request may be sent from an application such as a web browser or a dedicated mobile application.
Note also that when the enterprise is multihomed and connected to multiple upstream ITPs, each ITP is only able to provide a DDoS Mitigation Service for the traffic it transits. As a result, the enterprise network may be required to coordinate the various DDoS Mitigation Services associated to each link. More multi-homing considerations are discussed in [I-D.ietf-dots-multihoming].
This use case differs from the previous use case described in Section 3.1 in that the DDoS Mitigation Service is not provided by an upstream ITP. In other words, as represented in Figure 2, the traffic is not forwarded through the DDoS Mitigation Service Provider by default. In order to steer the traffic to the DDoS Mitigation Service Provider, some network configuration changes are required. As such, this use case is likely to apply to large enterprises or large data centers, but as for the other use cases is not exclusively limited to them.
Another typical scenario for this use case is for there to be a relationship between DDoS Mitigation Service Providers, forming an overlay of DMS. When a DDoS Mitigation Service Provider mitigating a DDoS attack reaches its resources capacity, it may chose to delegate the DDoS Mitigation to another DDoS Mitigation Service Provider.
+------------------+ +------------------+
| Enterprise | | Upstream |
| Network | | Internet Transit |
| | | Provider |
| +--------+ | | DDoS Attack
| | DDoS | | <=================================
| | Target | | <=================================
| +--------+ | | |
| | | |
| | +------------------+
| |
| | +------------------+
| | | DDoS Mitigation |
| | | Service Provider |
| | | |
| +------------+ | | +------------+ |
| | DDoS |<------------>| DDoS | |
| | Mitigation |C | | S| Mitigation | |
| | System | | | | System | |
| +------------+ | | +------------+ |
+------------------+ +------------------+
* C is for DOTS client functionality
* S is for DOTS server functionality
Figure 2: DDoS Mitigation between an Enterprise Network and Third
Party DDoS Mitigation Service Provider
In this scenario, an enterprise network has entered into a pre-arranged DDoS mitigation assistance agreement with one or more third-party DDoS Mitigation Service Providers in order to ensure that sufficient DDoS mitigation capacity and/or capabilities may be activated in the event that a given DDoS attack threatens to overwhelm the ability of the enterprise's or any other given DMS to mitigate the attack on its own.
The pre-arrangement typically includes agreement on the mechanisms used to redirect the traffic to the DDoS Mitigation Service Provider, as well as the mechanism to re-inject the traffic back to the Enterprise Network. Redirection to the DDoS Mitigation Service Provider typically involves BGP prefix announcement or DNS redirection, while re-injection of the scrubbed traffic to the enterprise network may be performed via tunneling mechanisms (e.g., GRE). These exact mechanisms used for traffic steering are out of scope of DOTS, but will need to be pre-arranged, while in some contexts such changes could be detected and considered as an attack.
In some cases the communication between the enterprise DOTS client and the DOTS server of the DDoS Mitigation Service Provider may go through the ITP carrying the DDoS attack, which would affect the communication. On the other hand, the communication between the DOTS client and DOTS server may take a path that is not undergoing a DDoS attack.
+------------------+ +------------------+
| Enterprise | | Upstream |
| Network | | Internet Transit |
| | | Provider |
| +--------+ | | DDoS Attack
| | DDoS | |<----------------+ | ++====
| | Target | | Mitigated | | || ++=
| +--------+ | | | | || ||
| | | | | || ||
| | +--------|---------+ || ||
| | | || ||
| | +--------|---------+ || ||
| | | DDoS Mitigation | || ||
| | | Service Provider | || ||
| | | | | || ||
| +------------+ | | +------------+ | || ||
| | DDoS |<------------>| DDoS | | || ||
| | mitigation |C | |S | mitigation |<===++ ||
| | system | | | | system |<======++
| +------------+ | | +------------+ |
+------------------+ +------------------+
* C is for DOTS client functionality
* S is for DOTS server functionality
Figure 3: Redirection to a DDoS Mitigation Service Provider
When the enterprise network is under attack or at least is reaching its capacity or ability to mitigate a given DDoS attack, the DOTS client sends a DOTS request to the DDoS Mitigation Service Provider to initiate network traffic diversion – as represented in Figure 3 – and DDoS mitigation activities. Ongoing attack and mitigation status messages may be passed between the enterprise network and the DDoS Mitigation Service Provider using DOTS. If the DDoS attack has stopped or the severity of the attack has subsided, the DOTS client can request the DDoS Mitigation Service Provider to terminate the DDoS Mitigation.
In this use case, one or more DDoS telemetry systems or monitoring devices monitor a network – typically an ISP network, an enterprise network, or a data center. Upon detection of a DDoS attack, these DDoS telemetry systems alert an orchestrator in charge of coordinating the various DMS's within the domain. The DDoS telemetry systems may be configured to provide required information, such as a preliminary analysis of the observation, to the orchestrator.
The orchestrator analyses the various information it receives from DDoS telemetry systems, and initiates one or more DDoS mitigation strategies. For example, the orchestrator could select the DDoS mitigation system in the enterprise network or one provided by the ITP.
DDoS Mitigation System selection and DDoS Mitigation techniques may depend on the type of the DDoS attack. In some case, a manual confirmation or selection may also be required to choose a proposed strategy to initiate a DDoS Mitigation. The DDoS Mitigation may consist of multiple steps such as configuring the network, or of updating already instantiated DDoS mitigation functions. Eventually, the coordination of the mitigation may involve external DDoS mitigation resources such as a transit provider or a Third Party DDoS Mitigation Service Provider.
The communication used to trigger a DDoS Mitigation between the DDoS telemetry and monitoring systems and the orchestrator is performed using DOTS. The DDoS telemetry system implements a DOTS client while the orchestrator implements a DOTS server.
The communication between a network administrator and the orchestrator is also performed using DOTS. The network administrator uses a web interface which interacts with a DOTS client, while the orchestrator implements a DOTS server.
The communication between the orchestrator and the DDoS Mitigation Systems is performed using DOTS. The orchestrator implements a DOTS client while the DDoS Mitigation Systems implement a DOTS server.
The configuration aspects of each DDoS Mitigation System, as well as the instantiations of DDoS mitigation functions or network configuration is not part of DOTS. Similarly, the discovery of available DDoS mitigation functions is not part of DOTS; and as such is out of scope.
+----------+
| network |C (Enterprise Network)
| adminis |<-+
| trator | |
+----------+ |
|
+----------+ | S+--------------+ +-----------+
|telemetry/| +->| |C S| DDoS |+
|monitoring|<--->| Orchestrator |<--->| mitigation||
|systems |C S| |<-+ | systems ||
+----------+ +--------------+C | +-----------+|
| +----------+
-----------------------------------|-----------------
|
|
(Internet Transit Provider) |
| +-----------+
| S| DDoS |+
+->| mitigation||
| systems ||
+-----------+|
* C is for DOTS client functionality +----------+
* S is for DOTS server functionality
Figure 4: DDoS Orchestration
The DDoS telemetry systems monitor various network traffic and perform some measurement tasks.
These systems are configured so that when an event or some measurement indicators reach a predefined level their associated DOTS client sends a DOTS mitigation request to the orchestrator DOTS server. The DOTS mitigation request may be associated with some optional mitigation hints to let the orchestrator know what has triggered the request. In particular, it's possible for something that locally to one telemetry system looks like an attack is not actually an attack when seen from the broader scope (e.g., of the orchestrator)
Upon receipt of the DOTS mitigation request from the DDoS telemetry system, the orchestrator DOTS server responds with an acknowledgment, to avoid retransmission of the request for mitigation. The orchestrator may begin collecting additional fine-grained and specific information from various DDoS telemetry systems in order to correlate the measurements and provide an analysis of the event. Eventually, the orchestrator may ask for additional information from the DDoS telemetry system; however, the collection of this information is out of scope of DOTS.
The orchestrator may be configured to start a DDoS Mitigation upon approval from a network administrator. The analysis from the orchestrator is reported to the network administrator via a web interface. If the network administrator decides to start the mitigation, the network administrator triggers the DDoS mitigation request using the web interface of a DOTS client communicating to the orchestrator DOTS server. This request is expected to be associated with a context that provides sufficient information to the orchestrator DOTS server to infer the DDoS Mitigation to elaborate and coordinate.
Upon receiving a request to mitigate a DDoS attack aimed at a target, the orchestrator may evaluate the volume of the attack as well as the value that the target represents. The orchestrator may select the DDoS Mitigation Service Provider based on the attack severity. It may also coordinate the DDoS Mitigation performed by the DDoS Mitigation Service Provider with some other tasks such as, for example, moving the target to another network so new sessions will not be impacted. The orchestrator requests a DDoS Mitigation by the selected DDoS mitigation systems via its DOTS client, as described in Section 3.1.
The orchestrator DOTS client is notified that the DDoS Mitigation is effective by the selected DDoS mitigation systems. The orchestrator DOTS servers returns this information back to the network administrator.
Similarly, when the DDoS attack has stopped, the orchestrator DOTS client is notified and the orchestrator's DOTS servers indicate to the DDoS telemetry systems as well as to the network administrator the end of the DDoS Mitigation.
In addition to the above DDoS Orchestration, the selected DDoS mitigation system can return back a mitigation request to the orchestrator as an offloading. For example, when the DDoS attack becomes severe and the DDoS mitigation system's utilization rate reaches its maximum capacity, the DDoS mitigation system can send mitigation requests with additional hints such as its blocked traffic information to the orchestrator. Then the orchestrator can take further actions like requesting forwarding nodes such as routers to filter the traffic. In this case, the DDoS mitigation system implements a DOTS client while the orchestrator implements a DOTS server. Similar to other DOTS use cases, the offloading scenario assumes that some validation checks are followed by the DMS, the orchestrator, or both (e.g., avoid exhausting the resources of the forwarding nodes or inadvertent disruption of legitimate services). These validation checks are part of the mitigation, and are therefore out of the scope of the document.
The document does not describe any protocol, though there are still a few high-level security considerations to discuss.
DOTS is at risk from three primary attacks: DOTS agent impersonation, traffic injection, and signaling blocking.
Impersonation and traffic injection mitigation can be mitigated through current secure communications best practices including mutual authentication. Preconfigured mitigation steps to take on the loss of keepalive traffic can partially mitigate signal blocking, but in general it is impossible to comprehensively defend against an attacker that can selectively block any or all traffic. Alternate communication paths that are (hopefully) not subject to blocking by the attacker in question is another potential mitigation.
Additional details of DOTS security requirements can be found in [RFC8612].
Service disruption may be experienced if inadequate mitigation actions are applied. These considerations are out of the scope of DOTS.
No IANA considerations exist for this document.
The authors would like to thank among others Tirumaleswar Reddy; Andrew Mortensen; Mohamed Boucadair; Artyom Gavrichenkov; Jon Shallow, Yuuhei Hayashi, the DOTS WG chairs, Roman Danyliw and Tobias Gondrom as well as the Security AD Benjamin Kaduk for their valuable feedback.
We also would like to thank Stephan Fouant that was part of the initial co-authors of the documents.
| [RFC8612] | Mortensen, A., Reddy, T. and R. Moskowitz, "DDoS Open Threat Signaling (DOTS) Requirements", RFC 8612, DOI 10.17487/RFC8612, May 2019. |
| [RFC8772] | Hu, S., Eastlake, D., Qin, F., Chua, T. and D. Huang, "The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP)", RFC 8772, DOI 10.17487/RFC8772, May 2020. |
| [RFC8773] | Housley, R., "TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key", RFC 8773, DOI 10.17487/RFC8773, March 2020. |
| [I-D.ietf-dots-multihoming] | Boucadair, M., Reddy.K, T. and W. Pan, "Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)", Internet-Draft draft-ietf-dots-multihoming-03, January 2020. |