DOTS WG R. Dobbins, Ed.
Internet-Draft Arbor Networks
Intended status: Informational S. Fouant
Expires: May 21, 2017 Corero Network Security
D. Migault
Ericsson
R. Moskowitz
Huawei
N. Teague
Verisign Inc
L. Xia
Huawei
K. Nishizuka
NTT Communications
November 17, 2016
Use cases for DDoS Open Threat Signaling
draft-ietf-dots-use-cases-03.txt
Abstract
The DDoS Open Threat Signaling (DOTS) effort is intended to provide a
protocol that facilitates interoperability between multivendor
solutions/services. This document presents use cases to evaluate the
interactions expected between the DOTS components as well as the DOTS
exchanges. The purpose of the use cases is to identify the
interacting DOTS component, how they collaborate and what are the
types of information to be exchanged.
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 May 21, 2017.
Dobbins, et al. Expires May 21, 2017 [Page 1]
Internet-Draft DOTS Use cases November 2016
Copyright Notice
Copyright (c) 2016 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases Scenarios . . . . . . . . . . . . . . . . . . . . . 4
3.1. Elementary Intra-organizational DDoS Mitigation . . . . . 5
3.2. Advanced/Extended Intra-Organizational DDoS Mitigation . 6
3.3. Orchestrated Intra-Organizational DDoS Mitigation . . . . 6
3.4. Inter-Organizational DDoS Mitigation . . . . . . . . . . 7
4. Use Cases Taxonomy . . . . . . . . . . . . . . . . . . . . . 7
4.1. DOTS Client Taxonomy . . . . . . . . . . . . . . . . . . 8
4.2. DOTS Server Taxonomy . . . . . . . . . . . . . . . . . . 10
4.3. DOTS Message Taxonomy . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 12
A.1. Primary Use Cases . . . . . . . . . . . . . . . . . . . . 15
A.1.1. Automatic or Operator-Assisted DOTS Clients Request
Upstream DDoS Mitigation Services . . . . . . . . . . 15
A.1.2. Manual Request to Upstream Mitigator . . . . . . . . 17
A.1.3. Unsuccessful Automatic or Operator-Assisted DOTS
Clients Request Upstream DDoS Mitigation
Services . . . . . . . . . . . . . . . . . . . . . . 19
A.2. Ancillary Use Cases . . . . . . . . . . . . . . . . . . . 20
A.2.1. Auto-registration of DOTS clients with DOTS servers 20
A.2.2. Auto-provisioning of DDoS countermeasures . . . . . . 21
Dobbins, et al. Expires May 21, 2017 [Page 2]
Internet-Draft DOTS Use cases November 2016
A.2.3. Informational DDoS attack notification to
interested and authorized third parties . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. 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. As
a side-effect, this makes 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. This greatly increase operational
complexity and often results in suboptimal DDoS attack mitigation
efficacy.
The DDoS Open Threat Signaling (DOTS) effort is intended to provide a
protocol that facilitates interoperability between multivendor DDoS
mitigation solutions/services. As DDoS solutions/services are
broadly heterogeneous among different vendors, the primary goal for
DOTS is to provide a high level interaction with these DDoS
solutions/services such as initiating or terminating DDoS mitigation
assistance.
It should be noted that DOTS is not in and of itself intended to
perform orchestration functions duplicative of the functionality
being developed by the [I2NSF] WG; rather, DOTS is intended to allow
devices, services, and applications to request DDoS attack mitigation
assistance and receive mitigation status updates from systems of this
nature.
The use cases presented in the document are intended to provide
examples of communications interactions DOTS-enabled nodes in both
inter- and intra-organizational DDoS mitigation scenarios. These use
cases are expected to provide inputs for the design of the DOTS
protocol(s).
2. Terminology and Acronyms
2.1. Requirements Terminology
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 RFC 2119 [RFC2119].
Dobbins, et al. Expires May 21, 2017 [Page 3]
Internet-Draft DOTS Use cases November 2016
2.2. Acronyms
This document makes use of the same terminology and definitions as
[I-D.ietf-dots-requirements], except where noted.
2.3. Terms
Inter-organizational: a DOTS communications relationship between
distinct organizations with separate spans of administrative control.
Typical inter-organizational DOTS communication relationships would
be between a DDoS mitigation service provider and an end-customer
organizational which requires DDoS mitigation assistance; between
multiple DDoS mitigation service providers coordinating mutual
defense of a mutual end-customer; or between DDoS mitigation service
providers which are requesting additional DDoS mitigation assistance
in for attacks which exceed their inherent DDoS mitigation capacities
and/or capabilities.
Intra-organizational: a DOTS communications relationship between
various elements within a single span of administrative control. A
typical intra-organizational DOTS communications relationship would
be between DOTS clients, DOTS gateways, and DOTS servers within the
same organization.
3. Use Cases Scenarios
This section provides a high-level description of scenarios addressed
by DOTS. These scenarios are described in more detail in Appendix A.
In both sections, the scenarios are provided in order to illustrate
the use of DOTS in typical DDoS attack scenarios. They are not
definitive, and other use cases are expected to emerge with
widespread DOTS deployment.
All scenarios present a coordination between the targeted
organization, the DDoS attack telemetry and the mitigator. The
coordination and communication between these entity depends, for
example on the characteristic or functionality of the equipment, the
reliability of the information provided by DDoS attack telemetry, and
the business relationship between the DDoS target domain and the
mitigator.
More explicitly, in some cases, the DDoS telemetry attack may simply
activate a DDoS mitigation, whereas in other cases, it may
collaborate by providing some information about an attack. In some
cases, the DDoS mitigation may be orchestrated, which includes
selecting a specific appliance as well as starting/ending a
mitigation.
Dobbins, et al. Expires May 21, 2017 [Page 4]
Internet-Draft DOTS Use cases November 2016
3.1. Elementary Intra-organizational DDoS Mitigation
The most elementary scenario considers equipment such as a CPE that
when overloaded sends an alert to specific equipment located
upstream. In many cases, these very basic devices are unlikely to
diagnose whether an DDoS attack is ongoing or not and detection as
well as potential mitigation is left to the upstream equipment.
In many deployments, the upstream equipment belongs to the same
organization as the CPE. In such cases, it is not expected that a
specific commercial contract is established between the CPE and the
DDoS mitigation service. The CPE and concerned traffic is likely to
be identified by the source of the alert, which also imply the
mitigator is aware of the nature of the equipment as well as the
architecture of the organization.
For example, the DDoS mitigation service may be equipment that is
located on path or a controller that will configure the network to
the traffic to be analyzed and mitigated is redirected to a dedicated
vendor specific equipment or solution. The DDoS mitigation service
may be activated only for the traffic associated to the CPE sending
the alert or instead to the traffic associated to all CPE. Such
decisions are not part of DOTS, but instead depend on the policies of
the network administrator.
The DDoS mitigation service is expected to acknowledge the reception
of the alert in order to avoid retransmission. This may become an
issue if an ISP receives alerts from all CPEs multiple times.
However, it is unlikely that in such cases the CPE will follow the
status of the mitigation. Instead, as the DDoS mitigation service
and the CPE belongs to the same administrative domain, it is expected
that the decision of mitigating or not, as well as the decision to
end an ongoing mitigation will be left to DDoS mitigation service
without notice to the CPEs.
There are several merits of using DOTS signaling in an intra-
organizational manner:
1. It will facilitate interoperability between DDoS solutions/
services by providing a standards-based, programmatic communications
mechanism
2. It will reduce time to initiate DDoS mitigation services
The required data exchange between DOTS client and DOTS server may be
equivalent to or a subset of information set of inter-organizational
use cases.
Dobbins, et al. Expires May 21, 2017 [Page 5]
Internet-Draft DOTS Use cases November 2016
3.2. Advanced/Extended Intra-Organizational DDoS Mitigation
This section considers that more specialized equipment is generating
DDoS alerts. These devices are likely to provide reliable
information about the ongoing attack.
Such equipment could typically be a telemetry system, or a specific
targeted service such as a web server, or another type application
detecting application-specific attacks.
Typically, a telemetry system may indicate classifiers of DDoS attack
traffic as well indicators or qualification of the detected attack.
As the telemetry system is expected to monitor multiple aspects of
the traffic, similarly when an attack is detected by the target
service.
The destination of the alert is likely to receive alerts from
multiple different services (DNS, HTTP, TCP, UDP, application layer
specific...). Such information is likely to be trusted and
considered by the mitigator to apply to the appropriated security
appliance.
Note that within a single domain it is likely that the service or the
telemetry system is the most accurate equipment to qualify the
attack.
As a result, not providing the information is likely to re-do the
analysis phase. Providing the information while sending the alert
avoid re-processing the analysis. Instead the mitigator directly
uses the information to redirect the traffic to the appropriated
specialized appliance.
For the same reasons as the CPE, as mitigation of the DDoS Service is
performed in a single administrative domain, the source of the alert
may not manage the end of the mitigation service and leave such
decision to the administrator of domain or the DDoS mitigation
service.
3.3. Orchestrated Intra-Organizational DDoS Mitigation
This section presents a generalization of the Service/System intra-
organizational scenario. Orchestration goes one step further and
considers that the information carried by the alert could have some
management purpose. This includes explicitly starting/ending
mitigation as well as selecting a specific DDoS mitigation service.
This differs from the previous case in that the source of the alert
Dobbins, et al. Expires May 21, 2017 [Page 6]
Internet-Draft DOTS Use cases November 2016
does not leave the decision on how to mitigate the attack by the
mitigator. Instead the mitigator is orchestrated.
Typical example of orchestrators could be a network administrator
that monitors the traffic and manually initiates a DDoS mitigation
from its web portal. Orchestration may also applied automatically by
an orchestrator.
3.4. Inter-Organizational DDoS Mitigation
In the case of inter-organizational mitigation, it is expected that a
DDoS mitigation service provider can provide DDoS mitigation service
to the targeted organization. The relationship between the two
organizations is generally expected to be described into a pre-agreed
contract, although ad-hoc mitigation scenarios without a pre-existing
business relationship are also quite common, and DOTS is intended to
work in either scenario, once the appropriate DOTS communications
relationships are configured by the involved parties.
Mutual authentication between all elements in the DOTS communications
chain is required in both intra- and inter-organizational scenarios.
DDoS attacks are often sourced from multiple independent networks on
the Internet. The targeted organization may request DDoS mitigation
services from multiple peered DOTS organizations with cooperation
contract in order to mitigate a given attack.
The coordination relationship among the DOTS organizations will often
be bilateral, which represents a direct peer to peer communication
between each DOTS organization without the existence of a broker or
orchestrator. The other case is a broker or orchestrator
facilitating DDOS mitigation coordination among multiple DOTS-enabled
organizations.
4. Use Cases Taxonomy
DOTS communication is a communication between a DOTS Client and a
DOTS Server. A DOTS Client or DOTS Server can be hosted on different
nodes which are associated to different functionalities, and thus
leading to different expectations from DOTS. This section provides a
classification of the DOTS Client, DOTS Servers as well as the
different examples of DOTS message exchanges.
Appendix A provides more details of anticipated DOTS communications
relationships, message flow, and message type examples.
Dobbins, et al. Expires May 21, 2017 [Page 7]
Internet-Draft DOTS Use cases November 2016
4.1. DOTS Client Taxonomy
DOTS clients initiate DOTS communications in order to request DDoS
mitigation assistance. This includes initiation/termination ofDDoS
mitigation service as well as requesting and reporting the status and
efficacy of an ongoing DDoS mitigation.
Note that this section only considers DOTS Client that are actually
initiating an exchange with a DOTS Server, and nodes that simply
relay DOTS messages are not considered here.
Here are the categories of DOTS Client envisioned in this document:
(a) DOTS Client alerting a DDoS attack is ongoing
i) hosted on the target attack
ii) hosted on a monitoring service/system
(b) DOTS Client coordinating an DDoS attack mitigation
i) hosted on an orchestrator
ii) hosted on administrative GUI
When an alert is raised by the node under attack, very little
information is expected to be provided by DOTS Client to the DDoS
mitigation service/system. More particularly telemetric information
or characteristics of the attack are likely to be unreliable as the
host is already overloaded, and may not have sophisticated DDoS
detection/classification capabilities.
When the DOTS Client is hosted on a more sophisticated attack
monitoring system, the monitoring system may raise an alert an attack
is ongoing. Unlike the host under attack, the monitoring system is
expected to have sufficient resource so it is not itself overload and
impacted by the ongoing attack. As a result, the DOTS Client is more
likely to provide additional information associated to the alert, as
this information is expected to be reliable. The type of information
associated may be associated to the asset to protect and eventually
some information qualifying the attack. The information associated
also depends on what has been agreed with DDoS mitigation service/
system. In most cases, when a DDoS attack is detected all the
traffic is redirected to the DDoS mitigation procedure that has been
agreed between the DDoS mitigation service/system and the entity
hosting the monitoring service. In such cases, very little
information is needed.
Dobbins, et al. Expires May 21, 2017 [Page 8]
Internet-Draft DOTS Use cases November 2016
When the DOTS Client is hosted on an orchestrator, the DOTS Client
contacts the DDoS mitigation service/system to initiates a DDoS
mitigation. The orchestrator is responsible for setting the network
to redirect the traffic to the DDoS mitigation service/system. If
the DDoS mitigation service/system is not available, the orchestrator
is responsible for finding an alternative. Again the orchestrator is
likely to provide additional information to the DDoS mitigation
service/system. For example, typical information may be the asset to
protect, as well as the specific mitigation function requested.
The service is usually expected to be associated with the mitigation
service, and so may not be explicitly specified. In addition, the
DOTS Client is also expected to control how the DDoS mitigation is
performed. More specifically, it is expected that the DOTS Client
can terminate the DDoS mitigation. The DOTS Client should have
sufficient information to decide how to operate next. For example,
it should be able to check if the mitigation is ongoing as well as
the efficiency of the mitigation.
When the DOTS client is hosted on an administrative system, the DOTS
Client may be triggered by the network administrator to initiate a
DDoS mitigation. In this case, the DOTS Server is likely to be an
orchestrator, and all necessary information may be provided so the
DDoS mitigation can be initiated. This includes, the asset to be
protected, the action expected to be performed by the orchestrator,
the DDoS mitigation service/system to contact...
Note that information included by DOTS Client in a request for
mitigation is not limited to simple mitigation assistance requests;
it can be more detailed. However, as DDoS mitigation systems are
highly heterogeneous, if there is a need to provide interoperability
between the vendors and DDoS mitigation services/systems, the actions
provided by a DOTS Clients remains small and accepted by all
services/systems. As a result here are the envisioned optional
information provided by the DOTS Client.
(a) recommended asset to protect (e.g. IP, port number, DNS record,
URI, et. all.). This information specifies the expected action
from the DDoS mitigation service/system.
(b) optional DDoS Mitigation Contract ID: which references the
contract agreed out-of-band. This information specifies the
expected action from the DDoS mitigation service/system.
(c) optional Requested Service: which designates the function or
service associated to the DDoS mitigation service/system. This
information specifies the expected action from the DDoS
mitigation service/system.
Dobbins, et al. Expires May 21, 2017 [Page 9]
Internet-Draft DOTS Use cases November 2016
(d) optional DDoS attack information (e.g. suspected attack,
telemetry): This information is expected to help the mitigation
service/system to diagnose the ongoing attack.
In both cases, the DOTS Client sends a request for DDoS mitigation to
the DOTS Server, and expects the DDoS mitigation service/system to
mitigate the DDoS attack. The difference between sending a request
for DDoS mitigation as an alert or for coordinating an DDoS
mitigation is that an alert is a request to completely outsource the
mitigation, whereas the coordination requires additional control over
the DDoS mitigation. An alert may be acknowledged by the DOTS Server
to acknowledge the reception whereas during the coordination, the
DOTS server may acknowledge the initiation of the DDoS mitigation.
4.2. DOTS Server Taxonomy
DOTS Servers terminate DOTS communications. The DOTS Server is
typically hosted on a DDoS mitigation service/system or an
intermediary node such as an orchestrator.
The DOTS Server is expected to be the entry point of a DDoS
mitigation service/system. Some DOTS Clients do not expect any
further interaction from the DOTS Server, once a DDoS mitigation has
been requested. This is especially true for DOTS Clients hosted on
the attack target. Other DOTS Clients hosted on orchestrators or
DDoS mitigation service/systems are likely to expect from the DOTS
Server a confirmation the system accepts the DDoS mitigation task.
These DOTS Client are also likely to expect a confirmation when DDoS
mitigation service termination has been requested.
In addition, DOTS Servers are also expected to provide information
related to the mitigation status when requested by the DOTS Client.
It is also expected that the DOTS Server could provide some status
report of the DDoS mitigation on a push basis.
4.3. DOTS Message Taxonomy
The core essential messages to coordination a heterogeneous set of
DDoS mitigation services/system needs to be small and enable future
options. Here are the different exchanges envisioned in this
document between a DOTS Client and a DOTS Server.
(a) DOTS MITIGATION CONTROL messages are used by the DOTS Client to
initiate or terminate a DDoS mitigation. The initiator the
termination can be specified by the action type START or STOP.
These messages can carry some additional options that specify
Dobbins, et al. Expires May 21, 2017 [Page 10]
Internet-Draft DOTS Use cases November 2016
information such as the asset under attack. These DOTS
MITIGATION CONTROL messages are expected to be ACKed by the DOTS
Server, in order to indicate the DOTS Server will perform the
requested action. In any other case an error is expected to be
returned. In the case of a DOTS Client sends an alert, ACK is
recommended so the DOTS Client stop sending the alert.
(b) DOTS MITIGATION INFORMATIONAL message are left for any
additional interaction between a DOTS Client and DOTS Server
regarding an ongoing request. An INFORMATIONAL message can be
ignored by the receiver if it does not understand the requested
information or options. In the current document an
informational message can be the status of the ongoing
mitigation.
(c) DOTS ERROR contains the errors associated to a request.
(d) DOTS OPTIONS: options can be used to indicate some optional
information. The option is expected to specify whether the DOTS
Server can ignore it or must return an error if it is not
understood. Options are not messages, but part of the message.
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.
Additional details of DOTS security requirements may be found in
[I-D.ietf-dots-requirements].
6. IANA Considerations
No IANA considerations exist for this document at this time.
7. Acknowledgments
TBD
Dobbins, et al. Expires May 21, 2017 [Page 11]
Internet-Draft DOTS Use cases November 2016
8. References
8.1. Normative References
[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>.
8.2. Informative References
[APACHE] "Apache mod_security", <https://www.modsecurity.org>.
[I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-03 (work in
progress), October 2016.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>.
[RRL] "BIND RRL", <https://deepthought.isc.org/article/AA-
00994/0/Using-the-Response-Rate-Limiting-Feature-in-BIND-
9.10.html>.
Appendix A. 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,
proceed to 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.
Dobbins, et al. Expires May 21, 2017 [Page 12]
Internet-Draft DOTS Use cases November 2016
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.
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.
All DOTS messages exchanged between the DOTS clients and DOTS servers
in these use cases may be communicated directly between 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.
DOTS is intended to apply to both inter- and Intra-organizational
DDoS attack mitigation scenarios. The technical and operational
requirements for inter- and Intra-organizational DOTS communications
are identical. The main difference is administrative in nature;
although it should be noted that provisioning challenges which are
typically associated with inter-organizational DOTS communications
relationships may also apply in intra-organizational deployment
scenarios, based upon organizational factors. All of the same
complexities surrounding authentication and authorization can apply
in both contexts, including considerations such as network access
policies to allow DOTS communications; DOTS transport selection
(including considerations of the implications of link congestion if a
stateful DOTS transport option is selected), etc. Registration of
well-known ports for DOTS transports per [RFC6335] should be
considered in light of these challenges.
It should also be noted that DOTS does not directly ameliorate the
various administrative challenges required for successful DDoS attack
mitigation. Letters of authorization, RADB updates, DNS zone
delegations, alteration of network access policies, technical
configurations required to facilitate network traffic diversion and
re-injection, etc., are all outside the scope of DOTS. DOTS may,
Dobbins, et al. Expires May 21, 2017 [Page 13]
Internet-Draft DOTS Use cases November 2016
however, prove useful in automating the registration of DOTS clients
with DOTS servers, as well as in the automatic provisioning of
situationally-appropriate DDoS defenses and countermeasures. This
ancillary DOTS functionality is described in Appendix A.2.
Many of the 'external' administrative challenges associated with
establishing workable DDoS attack mitigation service may be addressed
by work currently in progress in the I2RS and I2NSF WGs. Interested
parties may wish to consider tracking those efforts, and coordination
with both I2RS and I2NSF is highly desirable.
Note that all the use-cases in this document are universal in nature.
They apply equally to endpoint networks, transit backbone providers,
cloud providers, broadband access providers, ASPs, CDNs, etc. They
are not specific to particular business models, topological models,
or application types, and are deliberately generalizable. Both
networks targeted for attack as well as any adjacent or topologically
distant networks involved in a given scenario may be either single-
or multi-homed. In the accompanying vector illustrations
incorporated into draft-ietf-dots-use-cases-01.pdf, specific business
and topological models are described in order to provide context.
Likewise, both DOTS itself and the use cases described in this
document are completely independent of technologies utilized for the
detection, classification, traceback, and mitigation of DDoS attacks.
Flow telemetry such as NetFlow and IPFIX, direct full-packet
analysis, log-file analysis, indirection manual observation, etc. can
and will be enablers for detection, classification and traceback.
Intelligent DDoS mitigation systems (IDMSes), flowspec, S/RTBH, ACLs,
and other network traffic manipulation tools and techniques may be
used for DDoS attack mitigation. BGP, flowspec, DNS, inline
deployment, and various 'NFV' technologies may be used for network
traffic diversion into mitigation centers or devices in applicable
scenarios; GRE, MPLS, 'NFV', inline deployment and other techniques
may be utilized for 'cleaned' traffic re-injection to its intended
destination.
The scope, format, and content of all DOTS message types cited in
this document must be codified by the DOTS WG.
The following use cases are intended to inform the DOTS requirements
described in [I-D.ietf-dots-requirements].
Dobbins, et al. Expires May 21, 2017 [Page 14]
Internet-Draft DOTS Use cases November 2016
A.1. Primary Use Cases
A.1.1. Automatic or Operator-Assisted DOTS Clients Request Upstream
DDoS Mitigation Services
DOTS client can be supported on different devices or systems, like:
- CPE or PE mitigators: CPE or PE mitigators can mitigate the DDoS
attack by itself, but also 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;
- CPE or PE network infrastructure elements: Refer to the network
elements like routers, switches, load-balancers, firewalls, 'IPSes',
etc, which have the capability to detect and classify DDoS attacks.
These network elements involved are not engaged in mitigating DDoS
attack traffic, instead have DOTS client capabilities to be
configured to signal to one or more DOTS servers in order to request
upstream DDoS mitigation service initiation during an attack;
- CPE or PE Attack Telemetry Detection/Classification Systems: These
systems having 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. These systems do not possess any inherent capability to
mitigate DDoS attack traffic, and is signaling for upstream
mitigation assistance;
- The DDoS targeted service/applications: 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. They do not possess any inherent
capability to mitigate DDoS attack traffic, and is signaling for
upstream mitigation assistance.
Despite the different implementations of DOTS client, the DOTS
signaling process of them are very similar. For simplicity, the
abstract term 'DOTS client' is used here as a general representation
for all kinds of implementation.
One or more DOTS clients 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
Dobbins, et al. Expires May 21, 2017 [Page 15]
Internet-Draft DOTS Use cases November 2016
terminated either automatically or manually via a DOTS mitigation
service termination request initiated by the DOTS client when it has
been determined that the DDoS attack has ended. The DOTS signaling
process listed below applies to both intra- and inter-organizational
scenarios:
(a) A DDoS attack is initiated against online properties of an
organization with DOTS clients deployed.
(b) DOTS client detects, classifies, and maybe begin mitigating the
DDoS attack (if it's implemented as the DDoS mitigator).
(c) DOTS client determine to send a DOTS mitigation service
initiation request (for DDoS mitigator, if their capability to
mitigate the DDoS attack is insufficient) 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. This DOTS mitigation service initiation
request may be automatically initiated by the DOTS clients, or
may be manually triggered by personnel of the requesting
organization in response to an alert from the DOTS clients (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 configured to
honor requests from the requesting DOTS clients, 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 DOTS clients 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 DOTS clients.
(g) While DDoS mitigation services are active, the DOTS clients may
optionally regularly transmit DOTS mitigation efficacy updates
to the relevant DOTS servers.
(h) When the upstream DDoS mitigators determine that the DDoS attack
has ceased, they indicate this change in status to their
Dobbins, et al. Expires May 21, 2017 [Page 16]
Internet-Draft DOTS Use cases November 2016
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
DOTS clients indicating that the DDoS attack has ceased.
(j) The DOTS clients transmit a DOTS mitigation service termination
request to the DOTS servers. This DOTS mitigation service
termination request may be automatically initiated by the DOTS
clients, or may be manually triggered by personnel of the
requesting organization in response to an alert from the DOTS
clients 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
DOTS clients indicating that DDoS mitigation services have been
terminated.
(m) The DOTS clients transmit a DOTS mitigation termination status
acknowledgement to the DOTS servers.
A.1.2. Manual Request to Upstream Mitigator
A Web portal, or application for mobile devices such as smartphones
and tablets, 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 or 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 through the Web portal or
mobile device application when it has been determined that the DDoS
attack has ended.
In this use-case, the organization targeted for attack does not
possess any automated or operator-assisted mechanisms for DDoS attack
detection, classification, traceback, or mitigation; the existence of
an attack has been inferred manually, and the organization is
requesting upstream mitigation assistance. This can theoretically be
Dobbins, et al. Expires May 21, 2017 [Page 17]
Internet-Draft DOTS Use cases November 2016
an inter- or Intra-organizational use-case, but is more typically an
inter-organizational scenario.
(a) A DDoS attack is initiated against online properties of an
organization have access to a Web portal or mobile device
application which incorporates DOTS client functionality and can
generate DOTS mitigation service requests upon demand.
(b) Authorized personnel utilize the Web portal or mobile device
application 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. 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 or mobile device 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).
(d) The DOTS servers transmit a DOTS service status message to the
Web portal or mobile device application indicating that upstream
DDoS mitigation service has been initiated.
(e) While DDoS mitigation services are active, the DOTS servers
regularly transmit DOTS mitigation status updates to the Web
portal or mobile device application.
(f) While DDoS mitigation services are active, the Web portal or
mobile device application may optionally regularly transmit
manually-triggered DOTS mitigation efficacy updates to the
relevant DOTS servers.
(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 or mobile device application indicating that the DDoS
attack has ceased.
Dobbins, et al. Expires May 21, 2017 [Page 18]
Internet-Draft DOTS Use cases November 2016
(i) The Web portal or mobile device 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).
(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 or mobile device application indicating that DDoS
mitigation services have been terminated.
(l) The Web portal or mobile device application transmits a DOTS
mitigation termination status acknowledgement to the DOTS
servers.
A.1.3. Unsuccessful Automatic or Operator-Assisted DOTS Clients Request
Upstream DDoS Mitigation Services
One or more DOTS clients may be configured to signal to one or more
DOTS servers in order to request upstream DDoS mitigation service
initiation during an attack (for DDoS mitigators, when DDoS attack
volumes and/or attack characteristics exceed the capabilities of such
mitigators). DDoS mitigation service may be terminated either
automatically or manually via a DOTS mitigation service termination
request initiated by the DOTS client when it has been determined that
the DDoS attack has ended.
This can theoretically be an inter- or Intra-organizational use-case,
but is more typically an inter-organizational scenario.
(a) A DDoS attack is initiated against online properties of an
organization with DOTS clients deployed.
(b) DOTS client detects, classifies, and begins mitigating the DDoS
attack (if it's implemented as the DDoS mitigator).
(c) DOTS clients determine to send a DOTS mitigation service
initiation request (for DDoS mitigator, if their capability to
mitigate the DDoS attack is insufficient) 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. This DOTS mitigation service initiation
request may be automatically initiated by the DOTS clients, or
may be manually triggered by personnel of the requesting
Dobbins, et al. Expires May 21, 2017 [Page 19]
Internet-Draft DOTS Use cases November 2016
organization in response to an alert from the DOTS clients (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 configured to
honor requests from the requesting DOTS clients, 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).
(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 DOTS clients indicating that upstream DDoS mitigation
service cannot be initiated as requested.
(g) The DOTS clients may optionally regularly re-transmit DOTS
mitigation status request messages to the relevant DOTS servers
until acknowledgement that mitigation services have been
initiated.
(h) The DOTS clients may optionally transmit a DOTS mitigation
service initiation request to DOTS servers associated with a
configured fallback upstream DDoS mitigation service. 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 DOTS clients
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.
A.2. Ancillary Use Cases
A.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.
Dobbins, et al. Expires May 21, 2017 [Page 20]
Internet-Draft DOTS Use cases November 2016
The details of such registration are beyond the scope of this
document.
A.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.
This can theoretically be an inter- or Intra-organizational use-case,
but is more typically an inter-organizational scenario.
A.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.
This is an inter-organizational scenario.
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 May 21, 2017 [Page 21]
Internet-Draft DOTS Use cases November 2016
Stefan 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
Huawei
Oak Park, MI 48237
USA
Email: rgm@labs.htt-consult.com
Nik Teague
Verisign Inc
12061 Bluemont Way
Reston, VA 20190
USA
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 May 21, 2017 [Page 22]
Internet-Draft DOTS Use cases November 2016
Kaname Nishizuka
NTT Communications
GranPark 16F
3-4-1 Shibaura, Minato-ku, Tokyo
108-8118,Japan
Email: kaname@nttv6.jp
Dobbins, et al. Expires May 21, 2017 [Page 23]
