Use cases for DDoS Open Threat Signaling
draft-ietf-dots-use-cases-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8903.
|
|
|---|---|---|---|
| Authors | Roland Dobbins , Stephane Fouant, Daniel Migault , Robert Moskowitz , Nik Teague , Liang Xia | ||
| Last updated | 2015-10-19 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-23)
by Elwyn Davies
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 8903 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-dots-use-cases-00
DOTS WG R. Dobbins, Ed.
Internet-Draft Arbor Networks
Intended status: Informational S. Fouant
Expires: April 21, 2016 Corero Network Security
D. Migault
Ericsson
R. Moskowitz
HTT Consulting
N. Teague
Verisign Inc
L. Xia
Huawei
October 19, 2015
Use cases for DDoS Open Threat Signaling
draft-ietf-dots-use-cases-00.txt
Abstract
This document delineates principal and ancillary use cases for DDoS
Open Threat Signaling (DOTS), a communications protocol intended to
facilitate the programmatic, coordinated mitigation of Distributed
Denial of Service (DDoS) attacks via a standards-based mechanism.
DOTS is purposely designed to support requests for DDoS mitigation
services and status updates across inter-organizational
administrative boundaries.
Status of This Memo
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 http://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 April 21, 2016.
Dobbins, et al. Expires April 21, 2016 [Page 1]
Internet-Draft DOTS Use cases October 2015
Copyright Notice
Copyright (c) 2015 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
(http://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. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Primary Use Cases . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Successful Automatic or Operator-Assisted CPE or PE
Mitigators Request Upstream DDoS Mitigation Services 5
4.1.2. Successful Automatic or Operator-Assisted CPE or PE
Network Infrastructure Element Request to Upstream
Mitigator . . . . . . . . . . . . . . . . . . . . . . 7
4.1.3. Successful Automatic or Operator-Assisted CPE or PE
Attack Telemetry Detection/Classification System
Request to Upstream Mitigator . . . . . . . . . . . . 9
4.1.4. Successful Automatic or Operator-Assisted Targeted
Service/Application Request to Upstream Mitigator . . 12
4.1.5. Successful Manual Web Portal Request to Upstream
Mitigator . . . . . . . . . . . . . . . . . . . . . . 14
4.1.6. Successful Manual Mobile Device Application Request
to Upstream Mitigator . . . . . . . . . . . . . . . . 16
4.1.7. Unsuccessful Automatic or Operator-Assisted CPE or PE
Mitigators Request Upstream DDoS Mitigation Services 18
4.2. Ancillary Use Cases . . . . . . . . . . . . . . . . . . . 19
4.2.1. Auto-registration of DOTS clients with DOTS servers . 19
4.2.2. Auto-provisioning of DDoS countermeasures . . . . . . 20
4.2.3. Informational DDoS attack notification to interested
and authorized third parties . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
Dobbins, et al. Expires April 21, 2016 [Page 2]
Internet-Draft DOTS Use cases October 2015
8.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
Currently, distributed denial-of-service (DDoS) attack mitigation
solutions/services are largely based upon siloed, proprietary
communications paradigms which result in vendor/service lock-in, and
as a side-effect make the configuration, provisioning, operation, and
activation of these solutions a highly manual and often time-
consuming process. Additionally, coordination of multiple DDoS
mitigation solutions/services simultaneously engaged in defending the
same organization against DDoS attacks is fraught with both technical
and process-related hurdles which greatly increase operational
complexity and often result in suboptimal DDoS attack mitigation
efficacy.
The DDoS Open Threat Signaling (DOTS) effort is intended to
facilitate interoperability between DDoS solutions/services by
providing a standards-based, programmatic communications mechanism
for the invitation and termination of heterogeneous DDoS attack
mitigation systems and services. This allows for a much higher
degree of automation and concomitant efficacy and rapidity of DDoS
attack mitigation involving multiple DDoS mitigation systems and
services than is currently the norm, as well as providing additional
benefits such as automatic DDoS mitigation service registration and
provisioning.
This document provides an overview of common DDoS mitigation system/
service deployment and operational models which are in use today, but
which are currently limited in scope to a single vendor and/or
service provider and are often highly manual in nature, which can
lead to miscommunications, misconfigurations, and delays in bringing
mitigation services to bear against an attack. The introduction of
DOTS into these scenarios will reduce reaction times and the risks
associated with manual processes, simplify the use of multiple types
of DDoS mitigation systems and services as required, and make
practical the simultaneous use multiple DDoS mitigation systems and
services as circumstances warrant.
Dobbins, et al. Expires April 21, 2016 [Page 3]
Internet-Draft DOTS Use cases October 2015
3. Terminology and Acronyms
This document makes use of the same terminology and definitions as
[I-D.draft-ietf-dots-requirements], except where noted below:
- DDoS: A distributed denial-of-service attack. DDoS attacks are
intended to cause a negative impact on the availability of
servers, services, applications, and/or other functionality of
an attack target.
- Attack target: The intended target of a DDoS attack.
- Attack telemetry: Collected network traffic characteristics
enabling the detection, classification, and in many cases
traceback of a DDoS attack.
- Mitigation: A defensive response against a detected DDoS attack,
performed by an entity in the network path between attack
sources and the attack target, either through inline deployment
or some form of traffic diversion, consisting of one or more
countermeasures. The form a given mitigation takes is out of
scope for this document.
- Countermeasure: An action or set of actions taken by a mitigator
to evaluate and filter out a significant proportion of DDoS
attack traffic while forwarding onwards a significant
proportion of legitimate traffic directed towards an attack
target.
4. Use Cases
This section provides a high-level overview of likely use cases and
deployment scenarios for DOTS-enabled DDoS mitigation services. It
should be noted that DOTS servers may be standalone entities which,
upon receiving a DOTS mitigation service request from a DOTS client,
then initiate DDoS mitigation service by communicating directly or
indirectly with DDoS mitigators, and likewise terminate the service
upon receipt of a DOTS service termination request; conversely, the
DDoS mitigators themselves may incorporate DOTS servers and/or DOTS
clients. The mechanisms by which DOTS servers initiate and terminate
DDoS mitigation service with DDoS mitigators is beyond the scope of
this document.
All of the primary use cases described in this section are derived
from current, real-world DDoS mitigation functionality, capabilities,
and operational models which have been implemented in a largely
proprietary manner by various DDoS mitigation solution vendor and/or
service providers, resulting in vendor/service lock-in and mutually
Dobbins, et al. Expires April 21, 2016 [Page 4]
Internet-Draft DOTS Use cases October 2015
incompatible solutions/services. The overarching goal of the DOTS
effort is to provide a standards-based mechanism to allow
heterogeneous DDoS mitigation solutions and services to be woven
together in order to allow broader, more pervasive adoption of
coordinated DDoS defense.
The posited ancillary use cases described in this section are
reasonable and highly desirable extrapolations of the functionality
of baseline DOTS capabilities, and are readily attainable in the near
term.
Another important goal of DOTS is interoperability and coordination
via a common standards-based mechanism between multiple DDoS
mitigation service providers contemporaneously engaged in defending
the same organization against DDoS attacks. Each of the primary and
ancillary use cases described in this section may be read as
involving one or more DDoS mitigation service providers; DOTS makes
multi-provider coordinated DDoS defenses much more effective and
practical due to abstraction of the particulars of a given DDoS
mitigation service/solution set.
Both the primary and ancillary use cases may be facilitated by direct
DOTS client - DOTS server communications or via DOTS relays deployed
in order to aggregate DOTS mitigation service requests/responses, to
mediate between stateless and stateful underlying transport
protocols, to aggregate multiple DOTS requests and/or responses, to
filter DOTS requests and/or responses via configured policy
mechanisms, or some combination of these functions.
These use cases requirements are intended to inform the DOTS
requirements described in [I-D.draft-ietf-dots-requirements].
4.1. Primary Use Cases
4.1.1. Successful Automatic or Operator-Assisted CPE or PE Mitigators
Request Upstream DDoS Mitigation Services
In this scenario, one or more CPE or PE mitigators with DOTS client
capabilities may be configured to signal to one or more DOTS servers
in order to request upstream DDoS mitigation service initiation
during an attack when DDoS attack volumes and/or attack
characteristics exceed the capabilities of such CPE mitigators. DDoS
mitigation service may be terminated either automatically or manually
via a DOTS mitigation service termination request initiated by the
mitigator when it has been determined that the DDoS attack has ended.
All DOTS messages exchanged between the DOTS clients and DOTS servers
in this use case may be communicated directly between the DOTS
Dobbins, et al. Expires April 21, 2016 [Page 5]
Internet-Draft DOTS Use cases October 2015
clients and servers, or mediated by one or more DOTS relays residing
on the network of the originating network, the network where upstream
DDoS mitigation service takes place, an intervening network or
networks, or some combination of the above.
(a) A DDoS attack is initiated against online properties of an
organization which has deployed DOTS-client-capable DDoS
mitigators.
(b) CPE or PE DDoS mitigators detect, classify, and begin mitigating
the DDoS attack.
(c) CPE or PE DDoS mitigators determine that their capacity and/or
capability to mitigate the DDoS attack is insufficient, and
utilize their DOTS client functionality to send a DOTS
mitigation service initiation request to one or more DOTS
servers residing on one or more upstream transit networks, peer
networks, or overlay MSSP networks. The scope, format, and
content of these messages must be codified by the DOTS WG. This
DOTS mitigation service initiation request may be automatically
initiated by the CPE or PE DDoS mitigators, or may be manually
triggered by personnel of the requesting organization in
response to an alert from the mitigators (the mechanism by which
this process takes place is beyond the scope of this document).
(d) The DOTS servers which receive the DOTS mitigation service
initiation requests determine that they have been to honor
requests from the requesting CPE or PE mitigators, and initiate
situationally-appropriate DDoS mitigation service on their
respective networks (the mechanism by which this process takes
place is beyond the scope of this document).
(e) The DOTS servers transmit a DOTS service status message to the
requesting CPE or PE mitigators indicating that upstream DDoS
mitigation service has been initiated.
(f) While DDoS mitigation services are active, the DOTS servers
regularly transmit DOTS mitigation status updates to the
requesting CPE or PE mitigators. The scope, format, and content
of these messages must be codified by the DOTS WG.
(g) While DDoS mitigation services are active, the CPE or PE
mitigators may optionally regularly transmit DOTS mitigation
efficacy updates to the relevant DOTS servers. The scope,
format, and content of these messages must be codified by the
DOTS WG.
Dobbins, et al. Expires April 21, 2016 [Page 6]
Internet-Draft DOTS Use cases October 2015
(h) When the upstream DDoS mitigators determine that the DDoS attack
has ceased, they indicate this change in status to their
respective DOTS servers (the mechanism by which this process
takes place is beyond the scope of this document).
(i) The DOTS servers transmit a DOTS mitigation status update to the
CPE or PE mitigators indicating that the DDoS attack has ceased.
The scope, format, and content of these messages must be
codified by the DOTS WG.
(j) The CPE or PE DDoS mitigators transmit a DOTS mitigation service
termination request to the DOTS servers. [The scope, format,
and content of these messages must be codified by the DOTS WG.]
This DOTS mitigation service termination request may be
automatically initiated by the CPE or PE DDoS mitigators, or may
be manually triggered by personnel of the requesting
organization in response to an alert from the mitigators or a
management system which monitors them (the mechanism by which
this process takes place is beyond the scope of this document).
(k) The DOTS servers terminate DDoS mitigation service on their
respective networks (the mechanism by which this process takes
place is beyond the scope of this document).
(l) The DOTS servers transmit a DOTS mitigation status update to the
CPE or PE mitigators indicating that DDoS mitigation services
have been terminated. The scope, format, and content of these
messages must be codified by the DOTS WG.
(m) The CPE or PE DDoS mitigators transmit a DOTS mitigation
termination status acknowledgement to the DOTS servers. [The
scope, format, and content of these messages must be codified by
the DOTS WG.]
4.1.2. Successful Automatic or Operator-Assisted CPE or PE Network
Infrastructure Element Request to Upstream Mitigator
In this scenario, CPE or PE network infrastructure elements such as
routers, switches, load-balancers, firewalls, 'IPSes', etc. which
have the capability to detect and classify DDoS attacks and which
have DOTS client capabilities may be configured to signal to one or
more DOTS servers in order to request upstream DDoS mitigation
service initiation during an attack. DDoS mitigation service may be
terminated either automatically or manually via a DOTS mitigation
service termination request initiated by the network element when it
has been determined that the DDoS attack has ended.
Dobbins, et al. Expires April 21, 2016 [Page 7]
Internet-Draft DOTS Use cases October 2015
All DOTS messages exchanged between the DOTS clients and DOTS servers
in this use case may be communicated directly between the DOTS
clients and servers, or mediated by one or more DOTS relays residing
on the network of the originating network, the network where upstream
DDoS mitigation service takes place, an intervening network or
networks, or some combination of the above.
(a) A DDoS attack is initiated against online properties of an
organization with DOTS-client-capable network infrastructure
elements deployed.
(b) The network infrastructure elements utilize their DOTS client
functionality to send a DOTS mitigation service initiation
request to one or more DOTS servers residing on one or more
upstream transit networks, peer networks, or overlay MSSP
networks, either directly or via intermediate DOTS relays
residing upon the requesting organization's network, the
upstream mitigation provider's network, or both. The scope,
format, and content of these messages must be codified by the
DOTS WG. This DOTS mitigation service initiation request may be
automatically initiated by the network infrastructure elements,
or may be manually triggered by personnel of the requesting
organization in response to an alert from the network elements
or a management system which monitors them (the mechanism by
which this process takes place is beyond the scope of this
document).
(c) The DOTS servers which receive the DOTS mitigation service
initiation requests determine that they have been to honor
requests from the requesting network infrastructure elements,
and initiate situationally-appropriate DDoS mitigation service
on their respective networks (the mechanism by which this
process takes place is beyond the scope of this document).
(d) The DOTS servers transmit a DOTS service status message to the
requesting network infrastructure elements indicating that
upstream DDoS mitigation service has been initiated. The scope,
format, and content of these messages must be codified by the
DOTS WG.
(e) While DDoS mitigation services are active, the DOTS servers
regularly transmit DOTS mitigation status updates to the
requesting requesting network infrastructure elements. The
scope, format, and content of these messages must be codified by
the DOTS WG.
(f) While DDoS mitigation services are active, the network
infrastructure elements may optionally regularly transmit DOTS
Dobbins, et al. Expires April 21, 2016 [Page 8]
Internet-Draft DOTS Use cases October 2015
mitigation efficacy updates to the relevant DOTS servers. The
scope, format, and content of these messages must be codified by
the DOTS WG.
(g) When the upstream DDoS mitigators determine that the DDoS attack
has ceased, they indicate this change in status to their
respective DOTS servers (the mechanism by which this process
takes place is beyond the scope of this document).
(h) The DOTS servers transmit a DOTS mitigation status update to the
network infrastructure elements indicating that the DDoS attack
has ceased. The scope, format, and content of these messages
must be codified by the DOTS WG.
(i) The network infrastructure elements transmit a DOTS mitigation
service termination request to the DOTS servers. The scope,
format, and content of these messages must be codified by the
DOTS WG. This DOTS mitigation service termination request may
be automatically initiated by the network infrastructure
elements, or may be manually triggered by personnel of the
requesting organization in response to an alert from the
mitigators (the mechanism by which this process takes place is
beyond the scope of this document).
(j) The DOTS servers terminate DDoS mitigation service on their
respective networks (the mechanism by which this process takes
place is beyond the scope of this document).
(k) The DOTS servers transmit a DOTS mitigation status update to the
network infrastructure elements indicating that DDoS mitigation
services have been terminated. The scope, format, and content
of these messages must be codified by the DOTS WG.
(l) The network infrastructure elements transmit a DOTS mitigation
termination status acknowledgement to the DOTS servers. The
scope, format, and content of these messages must be codified by
the DOTS WG.
4.1.3. Successful Automatic or Operator-Assisted CPE or PE Attack
Telemetry Detection/Classification System Request to Upstream
Mitigator
In this scenario, CPE or PE Attack Telemetry Detection/Classification
Systems which have DOTS client capabilities may be configured so that
upon detecting and classifying a DDoS attack, they signal one or more
DOTS servers in order to request upstream DDoS mitigation service
initiation. DDoS mitigation service may be terminated either
automatically or manually via a DOTS mitigation service termination
Dobbins, et al. Expires April 21, 2016 [Page 9]
Internet-Draft DOTS Use cases October 2015
request initiated by the Attack Telemetry Detection/Classification
System when it has been determined that the DDoS attack has ended.
All DOTS messages exchanged between the DOTS clients and DOTS servers
in this use case may be communicated directly between the DOTS
clients and servers, or mediated by one or more DOTS relays residing
on the network of the originating network, the network where upstream
DDoS mitigation service takes place, an intervening network or
networks, or some combination of the above.
(a) A DDoS attack is initiated against online properties of an
organization with DOTS-client-capable CPE or PE Attack Telemetry
Detection/Classification Systems deployed.
(b) The CPE or PE Attack Telemetry Detection/Classification Systems
utilize their DOTS client functionality to send a DOTS
mitigation service initiation request to one or more DOTS
servers residing on one or more upstream transit networks, peer
networks, or overlay MSSP networks, either directly or via
intermediate DOTS relays residing upon the requesting
organization's network, the upstream mitigation provider's
network, or both. [The scope, format, and content of these
messages must be codified by the DOTS WG.] This DOTS mitigation
service initiation request may be automatically initiated by the
CPE or PE Attack Telemetry Detection/Classification Systems, or
may be manually triggered by personnel of the requesting
organization in response to an alert from the CPE or PE Attack
Telemetry Detection/Classification Systems (the mechanism by
which this process takes place is beyond the scope of this
document).
(c) The DOTS servers which receive the DOTS mitigation service
initiation requests determine that they have been to honor
requests from the requesting CPE or PE Attack Telemetry
Detection/Classification Systems, and initiate situationally-
appropriate DDoS mitigation service on their respective networks
(the mechanism by which this process takes place is beyond the
scope of this document).
(d) The DOTS servers transmit a DOTS service status message to the
requesting CPE or PE Attack Telemetry Detection/Classification
Systems indicating that upstream DDoS mitigation service has
been initiated. The scope, format, and content of these
messages must be codified by the DOTS WG.
(e) While DDoS mitigation services are active, the DOTS servers
regularly transmit DOTS mitigation status updates to the
requesting CPE or PE Attack Telemetry Detection/Classification
Dobbins, et al. Expires April 21, 2016 [Page 10]
Internet-Draft DOTS Use cases October 2015
Systems. The scope, format, and content of these messages must
be codified by the DOTS WG.
(f) While DDoS mitigation services are active, the CPE or PE Attack
Telemetry Detection/Classification Systems may optionally
regularly transmit DOTS mitigation efficacy updates to the
relevant DOTS servers. The scope, format, and content of these
messages must be codified by the DOTS WG.
(g) When the upstream DDoS mitigators determine that the DDoS attack
has ceased, they indicate this change in status to their
respective DOTS servers (the mechanism by which this process
takes place is beyond the scope of this document).
(h) The DOTS servers transmit a DOTS mitigation status update to the
CPE or PE Attack Telemetry Detection/Classification Systems
indicating that the DDoS attack has ceased. The scope, format,
and content of these messages must be codified by the DOTS WG.
(i) The CPE or PE Attack Telemetry Detection/Classification Systems
transmit a DOTS mitigation service termination request to the
DOTS servers. The scope, format, and content of these messages
must be codified by the DOTS WG. This DOTS mitigation service
termination request may be automatically initiated by the CPE or
PE Attack Telemetry Detection/Classification Systems, or may be
manually triggered by personnel of the requesting organization
in response to an alert from the CPE or PE Attack Telemetry
Detection/Classification Systems (the mechanism by which this
process takes place is beyond the scope of this document).
(j) The DOTS servers terminate DDoS mitigation service on their
respective networks (the mechanism by which this process takes
place is beyond the scope of this document).
(k) The DOTS servers transmit a DOTS mitigation status update to the
CPE or PE Attack Telemetry Detection/Classification Systems
indicating that DDoS mitigation services have been terminated.
The scope, format, and content of these messages must be
codified by the DOTS WG.
(l) The CPE or PE Attack Telemetry Detection/Classification Systems
transmit a DOTS mitigation termination status acknowledgement to
the DOTS servers. The scope, format, and content of these
messages must be codified by the DOTS WG.
Dobbins, et al. Expires April 21, 2016 [Page 11]
Internet-Draft DOTS Use cases October 2015
4.1.4. Successful Automatic or Operator-Assisted Targeted Service/
Application Request to Upstream Mitigator
In this scenario, a service or application which is the target of a
DDoS attack and which has the capability to detect and classify DDoS
attacks (i.e, Apache mod_security [APACHE], BIND RRL [RRL], etc.) as
well as DOTS client functionality may be configured so that upon
detecting and classifying a DDoS attack, it signals one or more DOTS
servers in order to request upstream DDoS mitigation service
initiation. DDoS mitigation service may be terminated either
automatically or manually via a DOTS mitigation service termination
request initiated by the service/application when it has been
determined that the DDoS attack has ended.
All DOTS messages exchanged between the DOTS clients and DOTS servers
in this use case may be communicated directly between the DOTS
clients and servers, or mediated by one or more DOTS relays residing
on the network of the originating network, the network where upstream
DDoS mitigation service takes place, an intervening network or
networks, or some combination of the above.
(a) A DDoS attack is initiated against online properties of an
organization which include DOTS-client-capable services or
applications that are the specific target(s) of the attack.
(b) The targeted services or applications utilize their DOTS client
functionality to send a DOTS mitigation service initiation
request to one or more DOTS servers residing on the same network
as the services or applications, one or more upstream transit
networks, peer networks, or overlay MSSP networks, either
directly or via intermediate DOTS relays residing upon the
requesting organization's network, the upstream mitigation
provider's network, or both. The scope, format, and content of
these messages must be codified by the DOTS WG. This DOTS
mitigation service initiation request may be automatically
initiated by the targeted services or applications, or may be
manually triggered by personnel of the requesting organization
in response to an alert from the targeted services or
applications or a system which monitors them (the mechanism by
which this process takes place is beyond the scope of this
document).
(c) The DOTS servers which receive the DOTS mitigation service
initiation requests determine that they have been provisioned to
honor requests from the requesting services or applications, and
initiate situationally-appropriate DDoS mitigation service on
their respective networks (the mechanism by which this process
takes place is beyond the scope of this document).
Dobbins, et al. Expires April 21, 2016 [Page 12]
Internet-Draft DOTS Use cases October 2015
(d) The DOTS servers transmit a DOTS service status message to the
services or applications indicating that upstream DDoS
mitigation service has been initiated. [The scope, format, and
content of these messages must be codified by the DOTS WG.
(e) While DDoS mitigation services are active, the DOTS servers
regularly transmit DOTS mitigation status updates to the
requesting services or applications. The scope, format, and
content of these messages must be codified by the DOTS WG.
(f) While DDoS mitigation services are active, the requesting
services or applications may optionally regularly transmit DOTS
mitigation efficacy updates to the relevant DOTS servers. The
scope, format, and content of these messages must be codified by
the DOTS WG.
(g) When the upstream DDoS mitigators determine that the DDoS attack
has ceased, they indicate this change in status to their
respective DOTS servers (the mechanism by which this process
takes place is beyond the scope of this document).
(h) The DOTS servers transmit a DOTS mitigation status update to the
requesting services or applications indicating that the DDoS
attack has ceased. The scope, format, and content of these
messages must be codified by the DOTS WG.
(i) The targeted services or applications transmit a DOTS mitigation
service termination request to the DOTS servers. [The scope,
format, and content of these messages must be codified by the
DOTS WG.] This DOTS mitigation service termination request may
be automatically initiated by the targeted services or
applications, or may be manually triggered by personnel of the
requesting organization in response to an alert from a system
which monitors them (the mechanism by which this process takes
place is beyond the scope of this document).
(j) The DOTS servers terminate DDoS mitigation service on their
respective networks (the mechanism by which this process takes
place is beyond the scope of this document).
(k) The DOTS servers transmit a DOTS mitigation status update to the
targeted services or applications indicating that DDoS
mitigation services have been terminated. The scope, format,
and content of these messages must be codified by the DOTS WG.
(l) The targeted services or applications transmit a DOTS mitigation
termination status acknowledgement to the DOTS servers. The
Dobbins, et al. Expires April 21, 2016 [Page 13]
Internet-Draft DOTS Use cases October 2015
scope, format, and content of these messages must be codified by
the DOTS WG.
4.1.5. Successful Manual Web Portal Request to Upstream Mitigator
In this scenario, a Web portal which has DOTS client capabilities has
been configured in order to allow authorized personnel of
organizations which are targeted by DDoS attacks to manually request
upstream DDoS mitigation service initiation from a DOTS server. When
an organization has reason to believe that it is under active attack,
authorized personnel may utilize the Web portal to manually initiate
a DOTS client mitigation request to one or more DOTS servers. DDoS
mitigation service may be terminated manually via a DOTS mitigation
service termination request through the Web portal when it has been
determined that the DDoS attack has ended.
All DOTS messages exchanged between the DOTS client and DOTS servers
in this use case may be communicated directly between the DOTS client
and servers, or mediated by one or more DOTS relays residing on the
network of the originating network, the network where upstream DDoS
mitigation service takes place, an intervening network or networks,
or some combination of the above.
(a) A DDoS attack is initiated against online properties of an
organization have access to a Web portal which incorporates DOTS
client functionality and can generate DOTS mitigation service
requests upon demand.
(b) Authorized personnel utilize the Web portal to send a DOTS
mitigation service initiation request to one or more upstream
transit networks, peer networks, or overlay MSSP networks,
either directly or via intermediate DOTS relays residing upon
the requesting organization's network, the upstream mitigation
provider's network, or both. [The scope, format, and content of
these messages must be codified by the DOTS WG.] This DOTS
mitigation service initiation request is manually triggered by
personnel of the requesting organization when it is judged that
the organization is under DDoS attack (the mechanism by which
this process takes place is beyond the scope of this document).
(c) The DOTS servers which receive the DOTS mitigation service
initiation requests determine that they have been provisioned to
honor requests from the Web portal, and initiate situationally-
appropriate DDoS mitigation service on their respective networks
(the mechanism by which this process takes place is beyond the
scope of this document).
Dobbins, et al. Expires April 21, 2016 [Page 14]
Internet-Draft DOTS Use cases October 2015
(d) The DOTS servers transmit a DOTS service status message to the
Web portal indicating that upstream DDoS mitigation service has
been initiated. [The scope, format, and content of these
messages must be codified by the DOTS WG.
(e) While DDoS mitigation services are active, the DOTS servers
regularly transmit DOTS mitigation status updates to the Web
portal. The scope, format, and content of these messages must
be codified by the DOTS WG.
(f) While DDoS mitigation services are active, the Web portal may
optionally regularly transmit manually-triggered DOTS mitigation
efficacy updates to the relevant DOTS servers. The scope,
format, and content of these messages must be codified by the
DOTS WG.
(g) When the upstream DDoS mitigators determine that the DDoS attack
has ceased, they indicate this change in status to their
respective DOTS servers (the mechanism by which this process
takes place is beyond the scope of this document).
(h) The DOTS servers transmit a DOTS mitigation status update to the
Web portal indicating that the DDoS attack has ceased. [The
scope, format, and content of these messages must be codified by
the DOTS WG.
(i) The Web portal transmits a manually-triggered DOTS mitigation
service termination request to the DOTS servers (the mechanism
by which this process takes place is beyond the scope of this
document). The scope, format, and content of these messages
must be codified by the DOTS WG.
(j) The DOTS servers terminate DDoS mitigation service on their
respective networks (the mechanism by which this process takes
place is beyond the scope of this document).
(k) The DOTS servers transmit a DOTS mitigation status update to the
Web portal indicating that DDoS mitigation services have been
terminated. The scope, format, and content of these messages
must be codified by the DOTS WG.
(l) The Web portal transmits a DOTS mitigation termination status
acknowledgement to the DOTS servers. The scope, format, and
content of these messages must be codified by the DOTS WG.
Dobbins, et al. Expires April 21, 2016 [Page 15]
Internet-Draft DOTS Use cases October 2015
4.1.6. Successful Manual Mobile Device Application Request to Upstream
Mitigator
In this scenario, an application for mobile devices such as
smartphones and tablets which incorporates DOTS client capabilities
has been made available to authorized personnel of an organization.
When the organization has reason to believe that it is under active
DDoS attack, authorized personnel may utilize the mobile device
application to manually initiate a DOTS client mitigation request to
one or more DOTS servers in order to initiate upstream DDoS
mitigation services. DDoS mitigation service may be terminated
manually via a DOTS mitigation service termination request initiated
through the mobile device application when it has been determined
that the DDoS attack has ended.
All DOTS messages exchanged between the DOTS client and DOTS servers
in this use case may be communicated directly between the DOTS client
and servers, or mediated by one or more DOTS relays residing on the
network of the originating network, the network where upstream DDoS
mitigation service takes place, an intervening network or networks,
or some combination of the above.
(a) A DDoS attack is initiated against online properties of an
organization have access to a Web portal which incorporates DOTS
client functionality and can generate DOTS mitigation service
requests upon demand.
(b) Authorized personnel utilize the mobile application to send a
DOTS mitigation service initiation request to one or more DOTS
servers residing on the same network as the targeted Internet
properties, one or more upstream transit networks, peer
networks, or overlay MSSP networks, either directly or via
intermediate DOTS relays residing upon the requesting
organization's network, the upstream mitigation provider's
network, or both. [The scope, format, and content of these
messages must be codified by the DOTS WG.] This DOTS mitigation
service initiation request is manually triggered by personnel of
the requesting organization when it is judged that the
organization is under DDoS attack (the mechanism by which this
process takes place is beyond the scope of this document).
(c) The DOTS servers which receive the DOTS mitigation service
initiation requests determine that they have been provisioned to
honor requests from the mobile application, and initiate
situationally-appropriate DDoS mitigation service on their
respective networks (the mechanism by which this process takes
place is beyond the scope of this document).
Dobbins, et al. Expires April 21, 2016 [Page 16]
Internet-Draft DOTS Use cases October 2015
(d) The DOTS servers transmit a DOTS service status message to the
mobile application indicating that upstream DDoS mitigation
service has been initiated. The scope, format, and content of
these messages must be codified by the DOTS WG.
(e) While DDoS mitigation services are active, the DOTS servers
regularly transmit DOTS mitigation status updates to the mobile
application. The scope, format, and content of these messages
must be codified by the DOTS WG.
(f) While DDoS mitigation services are active, the mobile
application may optionally regularly transmit manually-triggered
DOTS mitigation efficacy updates to the relevant DOTS servers.
The scope, format, and content of these messages must be
codified by the DOTS WG.
(g) When the upstream DDoS mitigators determine that the DDoS attack
has ceased, they indicate this change in status to their
respective DOTS servers (the mechanism by which this process
takes place is beyond the scope of this document).
(h) The DOTS servers transmit a DOTS mitigation status update to the
mobile application indicating that the DDoS attack has ceased.
The scope, format, and content of these messages must be
codified by the DOTS WG.
(i) The mobile application transmits a manually-triggered DOTS
mitigation service termination request to the DOTS servers (the
mechanism by which this process takes place is beyond the scope
of this document). The scope, format, and content of these
messages must be codified by the DOTS WG.
(j) The DOTS servers terminate DDoS mitigation service on their
respective networks (the mechanism by which this process takes
place is beyond the scope of this document).
(k) The DOTS servers transmit a DOTS mitigation status update to the
mobile application indicating that DDoS mitigation services have
been terminated. The scope, format, and content of these
messages must be codified by the DOTS WG.
(l) The mobile application transmits a DOTS mitigation termination
status acknowledgement to the DOTS servers. The scope, format,
and content of these messages must be codified by the DOTS WG.
Dobbins, et al. Expires April 21, 2016 [Page 17]
Internet-Draft DOTS Use cases October 2015
4.1.7. Unsuccessful Automatic or Operator-Assisted CPE or PE Mitigators
Request Upstream DDoS Mitigation Services
In this scenario, one or more CPE or PE mitigators with DOTS client
capabilities may be configured to signal to one or more DOTS servers
in order to request upstream DDoS mitigation service initiation
during an attack when DDoS attack volumes and/or attack
characteristics exceed the capabilities of such CPE mitigators. DDoS
mitigation service may be terminated either automatically or manually
via a DOTS mitigation service termination request initiated by the
mitigator when it has been determined that the DDoS attack has ended.
All DOTS messages exchanged between the DOTS clients and DOTS servers
in this use case may be communicated directly between the DOTS
clients and servers, or mediated by one or more DOTS relays residing
on the network of the originating network, the network where upstream
DDoS mitigation service takes place, an intervening network or
networks, or some combination of the above.
(a) A DDoS attack is initiated against online properties of an
organization which has deployed DOTS-client-capable DDoS
mitigators.
(b) CPE or PE DDoS mitigators detect, classify, and begin mitigating
the DDoS attack.
(c) CPE or PE DDoS mitigators determine that their capacity and/or
capability to mitigate the DDoS attack is insufficient, and
utilize their DOTS client functionality to send a DOTS
mitigation service initiation request to one or more DOTS
servers residing on one or more upstream transit networks, peer
networks, or overlay MSSP networks. The scope, format, and
content of these messages must be codified by the DOTS WG.]
This DOTS mitigation service initiation request may be
automatically initiated by the CPE or PE DDoS mitigators, or may
be manually triggered by personnel of the requesting
organization in response to an alert from the mitigators (the
mechanism by which this process takes place is beyond the scope
of this document).
(d) The DOTS servers which receive the DOTS mitigation service
initiation requests determine that they have been to honor
requests from the requesting CPE or PE mitigators, and attempt
to initiate situationally-appropriate DDoS mitigation service on
their respective networks (the mechanism by which this process
takes place is beyond the scope of this document).
Dobbins, et al. Expires April 21, 2016 [Page 18]
Internet-Draft DOTS Use cases October 2015
(e) The DDoS mitigators on the upstream network report back to the
DOTS servers that they are unable to initiate DDoS mitigation
service for the requesting organization due to mitigation
capacity constraints, bandwidth constraints, functionality
constraints, hardware casualties, or other impediments (the
mechanism by which this process takes place is beyond the scope
of this document).
(f) The DOTS servers transmit a DOTS service status message to the
requesting CPE or PE mitigators indicating that upstream DDoS
mitigation service cannot be initiated as requested. The scope,
format, and content of these messages must be codified by the
DOTS WG.
(g) The CPE or PE mitigators may optionally regularly re-transmit
DOTS mitigation status request messages to the relevant DOTS
servers until acknowledgement that mitigation services have been
initiated. The scope, format, and content of these messages
must be codified by the DOTS WG.
(h) The CPE or PE mitigators may optionally transmit a DOTS
mitigation service initiation request to DOTS servers associated
with a configured fallback upstream DDoS mitigation service.
The scope, format, and content of these messages must be
codified by the DOTS WG. Multiple fallback DDoS mitigation
services may optionally be configured.
(i) The process describe above cyclically continues until the DDoS
mitigation service request is fulfilled; the CPE or PE
mitigators determine that the DDoS attack volume has decreased
to a level and/or complexity which they themselves can
successfully mitigate; the DDoS attack has ceased; or manual
intervention by personnel of the requesting organization has
taken place.
4.2. Ancillary Use Cases
4.2.1. Auto-registration of DOTS clients with DOTS servers
An additional benefit of DOTS is that by utilizing agreed-upon
authentication mechanisms, DOTS clients can automatically register
for DDoS mitigation service with one or more upstream DOTS servers.
The details of such registration are beyond the scope of this
document.
Dobbins, et al. Expires April 21, 2016 [Page 19]
Internet-Draft DOTS Use cases October 2015
4.2.2. Auto-provisioning of DDoS countermeasures
The largely manual tasks associated with provisioning effective,
situationally-appropriate DDoS countermeasures is a significant
barrier to providing/obtaining DDoS mitigation services for both
mitigation providers and mitigation recipients. Due to the 'self-
descriptive' nature of DOTS registration messages and mitigation
requests, the implementation and deployment of DOTS has the potential
to automate countermeasure selection and configuration for DDoS
mitigators. The details of such provisioning are beyond the scope of
this document.
4.2.3. Informational DDoS attack notification to interested and
authorized third parties
In addition to its primary role of providing a standardized,
programmatic approach to the automated and/or operator-assisted
request of DDoS mitigation services and providing status updates of
those mitigations to requesters, DOTS may be utilized to notify
security researchers, law enforcement agencies, regulatory bodies,
etc. of DDoS attacks against attack targets, assuming that
organizations making use of DOTS choose to share such third-party
notifications, in keeping with all applicable laws, regulations,
privacy and confidentiality considerations, and contractual
agreements between DOTS users and said third parties.
5. Security Considerations
DOTS is at risk from three primary attacks: DOTS agent impersonation,
traffic injection, and signaling blocking. The DOTS protocol MUST be
designed for minimal data transfer to address the blocking risk.
Impersonation and traffic injection mitigation can be managed through
current secure communications best practices. DOTS is not subject to
anything new in this area. One consideration could be to minimize
the security technologies in use at any one time. The more needed,
the greater the risk of failures coming from assumptions on one
technology providing protection that it does not in the presence of
another technology.
6. IANA Considerations
7. Acknowledgments
Dobbins, et al. Expires April 21, 2016 [Page 20]
Internet-Draft DOTS Use cases October 2015
8. References
8.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI
10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, DOI 10.17487/RFC1518,
September 1993, <http://www.rfc-editor.org/info/rfc1518>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <http://www.rfc-editor.org/info/rfc4632>.
8.2. Informative References
[APACHE] "Apache mod_security", <https://www.modsecurity.org>.
[RRL] "BIND RRL", <https://deepthought.isc.org/article/AA-
00994/0/Using-the-Response-Rate-Limiting-Feature-in-BIND-
9.10.html>.
Authors' Addresses
Roland Dobbins (editor)
Arbor Networks
30 Raffles Place
Level 17 Chevron House
Singapore 048622
Singapore
Email: rdobbins@arbor.net
Dobbins, et al. Expires April 21, 2016 [Page 21]
Internet-Draft DOTS Use cases October 2015
Stephane Fouant
Corero Network Security
Email: Stefan.Fouant@corero.com
Daniel Migault
Ericsson
8400 boulevard Decarie
Montreal, QC H4P 2N2
Canada
Phone: +1 514-452-2160
Email: daniel.migault@ericsson.com
Robert Moskowitz
HTT Consulting
Oak Park, MI 48237
USA
Email: rgm@labs.htt-consult.com
Nik Teague
Verisign Inc
12061 Bluemont Way
Reston, VA 20190
US
Phone: +44 791 763 5384
Email: nteague@verisign.com
Liang Xia
Huawei
No. 101, Software Avenue, Yuhuatai District
Nanjing
China
Email: Frank.xialiang@huawei.com
Dobbins, et al. Expires April 21, 2016 [Page 22]