DOTS use cases: Use Cases for DDoS Open Threat Signaling
Example scenarios showing how organizations coordinate to stop a distributed denial-of-service attack.
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>.
@misc{rfc8903,
series = {Request for Comments},
number = 8903,
howpublished = {RFC 8903},
publisher = {RFC Editor},
doi = {10.17487/RFC8903},
url = {https://www.rfc-editor.org/info/rfc8903},
author = {R. Dobbins and D. Migault and R. Moskowitz and N. Teague and L. Xia and K. Nishizuka},
title = {{Use Cases for DDoS Open Threat Signaling}},
pagetotal = 13,
year = 2021,
month = may,
} RFC text
Contents
Internet Engineering Task Force (IETF) R. Dobbins
Request for Comments: 8903 Netscout, Inc.
Category: Informational D. Migault
ISSN: 2070-1721 Ericsson
R. Moskowitz
HTT Consulting
N. Teague
Iron Mountain Data Centers
L. Xia
Huawei
K. Nishizuka
NTT Communications
May 2021
Use Cases for DDoS Open Threat Signaling
Abstract
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 that
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 the typical information to be exchanged is.
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/rfc8903.
Copyright Notice
Copyright (c) 2021 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.
Table of Contents
1. Introduction
2. Terminology and Acronyms
3. Use Cases
3.1. Upstream DDoS Mitigation by an Upstream Internet Transit
Provider
3.2. DDoS Mitigation by a Third-Party DDoS Mitigation Service
Provider
3.3. DDoS Orchestration
4. Security Considerations
5. IANA Considerations
6. Informative References
Acknowledgments
Authors' Addresses
1. Introduction
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
that are generally highly dependent on a timely reaction by the
system.
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 terms 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
requirements [RFC8612] and design of the DOTS protocols
[RFC8782][RFC8783]. The use cases are not exhaustive, and future use
cases are expected to emerge as DOTS is adopted and evolves.
2. Terminology and Acronyms
This document makes use of the same terminology and definitions as
[RFC8612]. In addition, it uses the terms defined below:
DDoS Mitigation System (DMS):
A system that performs DDoS Mitigation. The DDoS Mitigation
System may be composed of a cluster of hardware and/or software
resources but could also involve an orchestrator that may make
decisions, such as outsourcing some or all of the mitigation to
another DDoS Mitigation System.
DDoS Mitigation:
The action performed by the DDoS Mitigation System.
DDoS Mitigation Service:
Designates a service provided to a customer to mitigate DDoS
attacks. Each service subscription usually involve Service Level
Agreement (SLA) that has to be met. It is the responsibility of
the DDoS Service provider to instantiate the DDoS Mitigation
System to meet these SLAs.
DDoS Mitigation Service Provider:
Designates the administrative entity providing the DDoS Mitigation
Service.
Internet Transit Provider (ITP):
Designates the entity that delivers the traffic to a customer
network. It can be an Internet Service Provider (ISP) or an
upstream entity delivering the traffic to the ISP.
3. Use Cases
3.1. Upstream DDoS Mitigation by an Upstream Internet Transit Provider
This use case describes how an enterprise or a residential customer
network may take advantage of a pre-existing relation with its 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 is well aware of the networking parameters
associated with the enterprise network WAN connectivity. This eases
both the configuration and the instantiation of a DDoS Mitigation
Service.
This section considers two kinds of DDoS Mitigation Service between
an enterprise network and an ITP:
* The upstream ITP may instantiate a DMS upon receiving a request
from the enterprise network. This typically corresponds to a case
when the enterprise network is under attack.
* On the other hand, the ITP may identify an enterprise network as
the source of an attack and send a mitigation request to the
enterprise DMS to mitigate this at the source.
The two scenarios, though 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 Voice over IP (VoIP) servers has a DMS
deployed to protect those servers and applications from DDoS attacks.
In addition to on-premise DDoS defense capabilities, 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 are made 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 a
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 that the ITP
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:
1. A DDoS attack is initiated against resources of a network
organization (here, the enterprise), which has deployed a DOTS-
capable DMS -- typically a DOTS client.
2. The enterprise DMS detects, classifies, and begins the DDoS
Mitigation.
3. The enterprise DMS determines that its capacity and/or capability
to mitigate the DDoS attack is insufficient and sends a DOTS DDoS
Mitigation request via its DOTS client to one or more DOTS
servers residing on the upstream ITP.
4. The DOTS server, which receives the DOTS Mitigation request,
determines that it has been configured to honor requests from the
requesting DOTS client and does so by orchestrating its own DMS.
5. While the DDoS Mitigation is active, the DOTS server regularly
transmits DOTS DDoS Mitigation status updates to the DOTS client.
6. Informed by the DOTS server status update that the attack has
ended or subsided, the DOTS client transmits a DOTS DDoS
Mitigation termination request to the DOTS server.
7. The DOTS server terminates DDoS Mitigation and sends the
notification to the DOTS client.
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 third-party wireless 4G network connectivity.
Note also that a DOTS client that sends a DOTS Mitigation request may
also be 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 with each link. More multihoming
considerations are discussed in [DOTS-MULTIHOMING].
3.2. DDoS Mitigation by a Third-Party DDoS Mitigation Service Provider
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 resource capacity, it may choose 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 a
Third-Party DDoS Mitigation Service Provider
In this scenario, an enterprise network has entered into a
prearranged 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 or any other given DMS to
mitigate the attack on its own.
The prearrangement 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). The exact mechanisms used for traffic steering are out of
scope of DOTS but will need to be prearranged, 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 that the DDoS Mitigation Service Provider terminate the
DDoS Mitigation.
3.3. DDoS Orchestration
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 DMSs 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 analyzes the various sets of information it receives
from DDoS telemetry systems and initiates one or more DDoS Mitigation
strategies. For example, the orchestrator could select the DMS in
the enterprise network or one provided by the ITP.
DMS selection and DDoS Mitigation techniques may depend on the type
of the DDoS attack. In some cases, 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 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, for example, a web interface that interacts with a DOTS client,
while the orchestrator implements a DOTS server.
The communication between the orchestrator and the DMSs is performed
using DOTS. The orchestrator implements a DOTS client while the DMSs
implement a DOTS server.
The configuration aspects of each DMS, as well as the instantiations
of DDoS Mitigation functions or network configuration, are 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)
| admini- |<-+
| strator | |
+----------+ |
|
+----------+ | 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 aspects of the 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 is possible for something
that looks like an attack locally to one telemetry system 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, for
example, a web interface. If the network administrator decides to
start the mitigation, the network administrator triggers the DDoS
Mitigation request using, for example, a 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, elaborate, and
coordinate the appropriate DDoS Mitigation.
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 DMSs 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 DMSs. The orchestrator DOTS server returns
this information to the network administrator.
Similarly, when the DDoS attack has stopped, the orchestrator DOTS
client is notified and the orchestrator's DOTS server indicates the
end of the DDoS Mitigation to the DDoS telemetry systems as well as
to the network administrator.
In addition to the DDoS orchestration shown in Figure 4, the selected
DMS can return a mitigation request to the orchestrator as an
offloading. For example, when the DDoS attack becomes severe and the
DMS's utilization rate reaches its maximum capacity, the DMS can send
mitigation requests with additional hints, such as its blocked
traffic information, to the orchestrator. Then the orchestrator can
take further actions such as requesting forwarding nodes (e.g.,
routers) to filter the traffic. In this case, the DMS 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.
4. Security Considerations
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.
5. IANA Considerations
This document has no IANA actions.
6. Informative References
[DOTS-MULTIHOMING]
Boucadair, M., Reddy, T., and W. Pan, "Multi-homing
Deployment Considerations for Distributed-Denial-of-
Service Open Threat Signaling (DOTS)", Work in Progress,
Internet-Draft, draft-ietf-dots-multihoming-06, 25 May
2021, <https://tools.ietf.org/html/draft-ietf-dots-
multihoming-06>.
[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>.
[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel
Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
<https://www.rfc-editor.org/info/rfc8782>.
[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>.
Acknowledgments
The authors would like to thank, among others, Tirumaleswar Reddy.K,
Andrew Mortensen, Mohamed Boucadair, Artyom Gavrichenkov, Jon
Shallow, Yuuhei Hayashi, Elwyn Davies, the DOTS WG Chairs (at the
time of writing) 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, who was one of the
initial coauthors of the documents.
Authors' Addresses
Roland Dobbins
Netscout, Inc.
Singapore
Email: roland.dobbins@netscout.com
Daniel Migault
Ericsson
8275 Trans Canada Route
Saint Laurent, Quebec 4S 0B6
Canada
Email: daniel.migault@ericsson.com
Robert Moskowitz
HTT Consulting
Oak Park, MI 48237
United States of America
Email: rgm@labs.htt-consult.com
Nik Teague
Iron Mountain Data Centers
United Kingdom
Email: nteague@ironmountain.co.uk
Liang Xia
Huawei
No. 101, Software Avenue, Yuhuatai District
Nanjing
China
Email: Frank.xialiang@huawei.com
Kaname Nishizuka
NTT Communications
GranPark 16F
3-4-1 Shibaura, Minato-ku, Tokyo
108-8118
Japan
Email: kaname@nttv6.jp
ISO Plain Language
On this page
§1Why Defenders Need to Talk to Each Other
At the time of writing, distributed denial-of-service (DDoS) mitigation is built on siloed, proprietary signalling schemes, with vendor lock-in as a side effect. Configuring, provisioning, operating and activating a defence is a manual and often slow process. Running several defences at once adds both technical and organisational hurdles. That raises operational complexity, which in turn degrades the defences, because those defences depend on reacting quickly.
The DDoS Open Threat Signaling (DOTS) effort sets out to specify protocols that let different mitigation solutions work together, so that attacks are detected in the same way, mitigation is requested in the same way, and attacks are described in the same way.
Because the solutions from different vendors differ widely, the primary goal of DOTS is high-level interaction between them: detecting an attack, starting and stopping help, and asking for the status of a mitigation in progress.
This RFC supplies sample use cases. They fed the requirements in RFC 8612 and the design of the DOTS protocols in RFC 8782 and RFC 8783. The RFC is explicit that the list is not exhaustive and that further use cases are expected as DOTS is adopted.
Each vendor's defence product talks to itself and to nobody else. So when an attack is too big for one defence to handle, the people who need to help have to be phoned by hand.
DOTS tries to make that call automatic and standard.
§2The Roles the Scenarios Use
The RFC reuses the terminology of RFC 8612 and adds five terms of its own.
A DDoS Mitigation System (DMS) is the system that actually performs the mitigation. It may be a cluster of hardware or software, and it may include an orchestrator that decides to outsource some or all of the mitigation to another DMS.
DDoS mitigation is the action that DMS performs. A DDoS Mitigation Service is a service sold to a customer, usually with a service level agreement that has to be met; the provider of that service is the DDoS Mitigation Service Provider, and it is that provider's job to run a DMS good enough to meet the agreement.
An Internet Transit Provider (ITP) is the entity that delivers the traffic to a customer's network. That may be an Internet service provider (ISP) or an upstream entity that delivers the traffic to the ISP.
The scenarios use four kinds of organisation: the network being attacked, the system that defends it, the company that sells the defending service, and the transit provider that carries the traffic.
Keeping these straight matters, because the same word, mitigation, covers both the action and the service around it.
§3.1Asking a Transit Provider for Help
An enterprise network usually has an existing relationship with its transit provider. That provider already sits on the path of the enterprise's inbound and outbound traffic and already knows the parameters of the enterprise's WAN connection, which makes configuring a mitigation service easier.
The scenario in Section 3.1 is the first of two directions. The enterprise runs a DMS in front of its own Internet-facing properties, such as web servers, authoritative DNS servers and Voice over IP servers, and has contracted with its transit provider for mitigation when an attack threatens to overwhelm the WAN links. In the other direction, the transit provider notices that the enterprise is the source of an attack and asks the enterprise's DMS to stop it at the source. Both directions involve the same client and server interactions, so only the first is detailed, though the second is also in scope.
The enterprise's DMS is configured so that when inbound traffic exceeds 50 percent of the provisioned upstream WAN link capacity it asks the transit provider for help. The DMS acts as the DOTS client and the transit provider acts as the DOTS server, which is integrated with its own DMS.
The exchange has seven steps. The attack starts against the enterprise's resources. The enterprise DMS detects it, classifies it and begins mitigating. It then finds that its own capacity or capability is not enough, and sends a mitigation request through its DOTS client to one or more DOTS servers on the transit provider. The server decides whether it is configured to honour requests from that client, and if so it asks its own DMS to act. While the mitigation runs, the server sends regular status updates with mitigation statistics and related information. When the attack ends, or falls to a level the enterprise can handle, the server tells the client that it has subsided. The client then asks the server to terminate the mitigation, and the server confirms once it has ended.
The signalling may travel in band on the same WAN link as the attack, or out of band on a separate dedicated link, or over some other connectivity such as a third-party 4G network. A request may also be triggered by a network administrator who confirms it manually, in which case it may come from a web browser or a mobile application. Where the enterprise is multihomed across several transit providers, each provider can only mitigate the traffic it transits, so the enterprise has to coordinate the services for each link.
The enterprise defends itself first. When the flood is bigger than its own link can take, it asks its transit provider to filter the traffic upstream, where there is more capacity.
The exchange has a clear shape: request help, get status updates, then ask for the help to be withdrawn once the attack is over.
- MITIGATION REQUESTSent when local capacity is not enough.
- REQUEST ACCEPTEDThe server asks its own DMS to act.
- STATUS UPDATESSent regularly while the mitigation runs.
- ATTACK SUBSIDED
- TERMINATION REQUEST
- MITIGATION ENDED
§3.2Asking a Third-Party Service for Help
This scenario differs from the previous one because the mitigation service is not provided by the transit provider. The attack traffic does not pass through the third-party provider unless the network is configured to send it there, which needs changes to the routing or to DNS. Because of that, it suits large enterprises and large data centres, though it is not limited to them.
A common pattern is that providers have relationships with each other, forming an overlay of mitigation systems. When a provider's own capacity runs out during an attack, it may delegate the mitigation to another provider.
The enterprise first signs an agreement with one or more third-party providers, covering how traffic will be redirected to them and how the cleaned traffic will be returned. Redirection usually means announcing the prefix with BGP or redirecting with DNS, and the traffic may be tunnelled back, for example with GRE. Those traffic steering mechanisms are outside DOTS, but they have to be arranged in advance, and in some contexts such a change could be detected and mistaken for an attack.
When the enterprise is under attack, or is close to its capacity, the DOTS client asks the third-party provider to divert the traffic and start mitigating. Ongoing attack and mitigation status may be exchanged the same way. When the attack stops or eases, the client asks the provider to terminate the mitigation.
Some companies buy their defence from a third party that is not the company carrying their traffic. That means the traffic has to be redirected to the defender before it can be cleaned.
The redirection is arranged in advance, using routing or DNS changes. The RFC notes that such a change could itself look like an attack.
| Aspect | Transit provider | Third-party service |
|---|---|---|
| Where the traffic already flows | Through the provider | Not through the provider by default |
| Network change needed | None | BGP announcement or DNS redirection |
| Cleaned traffic returns by | The normal path | A tunnel such as GRE |
| Agreement needed | A contract with the transit provider | A prearranged assistance agreement |
§3.3Orchestrating Several Defences at Once
In the orchestration scenario, one or more telemetry systems or monitoring devices watch a network, which may be an ISP network, an enterprise network or a data centre. When one of them detects an attack, it alerts an orchestrator that coordinates the mitigation systems within that domain. The telemetry systems may pass along a preliminary analysis of what they saw.
The orchestrator weighs the information it receives and starts one or more mitigation strategies, choosing for example between the DMS inside the enterprise and one provided by the transit provider. Which system and which technique to use may depend on the type of attack, and a person may have to confirm the choice by hand. The mitigation itself may take several steps, such as reconfiguring the network or updating functions that are already running, and it may involve outside resources such as a transit provider or a third-party service provider.
Three separate conversations use DOTS here, and the roles swap each time. The telemetry systems talk to the orchestrator as clients, with the orchestrator as server. A network administrator talks to the orchestrator through a web interface backed by a DOTS client, again with the orchestrator as server. The orchestrator then talks to the mitigation systems as a client, with each of them as server.
The telemetry systems are configured so that when a measurement crosses a set level, their DOTS client sends a mitigation request to the orchestrator, optionally with hints about what triggered it. The hints matter, because something that looks like an attack to one telemetry system may not be an attack when seen from the wider view of the orchestrator. The orchestrator acknowledges the request, so that it is not sent again, and may then collect finer information from other telemetry systems to correlate the measurements.
The orchestrator may be configured to start a mitigation only after a network administrator approves it, and it reports its analysis to that administrator, who then triggers the mitigation through a DOTS client. The orchestrator evaluates the volume of the attack and the value of the target, may pick a service provider according to the severity, and may also coordinate other work such as moving the target to another network so that new sessions are not affected. It then asks the chosen systems to mitigate, as in Section 3.1, and reports back that the mitigation is effective.
The reverse direction also exists. A mitigation system that reaches its own maximum capacity can send a request back to the orchestrator, known as offloading, with hints such as the traffic it has blocked. The orchestrator can then act further, for example by asking forwarding nodes such as routers to filter the traffic. Here the mitigation system is the DOTS client and the orchestrator the server. Configuring the mitigation systems, and discovering what functions they offer, are both outside DOTS.
A large network may run several monitoring tools and several defence systems at once. An orchestrator sits between them, gathers what the monitors saw, and decides which defence to use.
Under pressure, a defence system can also ask the orchestrator for more help, in case the attack outgrows what it can filter.
- MITIGATION REQUESTSent when a measurement crosses a set level, with optional hints.
- ACKNOWLEDGMENTStops the request being sent again.
- MITIGATION REQUESTSent once the orchestrator has chosen a defence.
- OFFLOAD REQUESTSent when the defence reaches its own capacity.
§4Security Considerations
The document describes no protocol, but it does set out a few high-level security points. DOTS is at risk from three primary attacks: impersonation of a DOTS agent, injection of traffic, and blocking of the signalling.
Impersonation and traffic injection are addressed by ordinary secure communication practice, including mutual authentication. Loss of keepalive traffic can be partly handled by preconfiguring what happens when keepalives stop. Against an attacker who can selectively block any or all traffic, though, no comprehensive defence is possible. Using a different communication path that the attacker may not be able to block is another possible measure.
The detailed security requirements for DOTS are in RFC 8612. Service disruption may still be experienced if inadequate mitigation actions are applied, and the RFC leaves that out of scope.
The signalling itself becomes a target. An attacker could pretend to be a defender, feed false information into the system, or simply block the messages that ask for help.
Mutual authentication handles the first two. The third cannot be fully solved, so the RFC suggests using a second path for the signalling.