< draft-ietf-dots-use-cases-17.txt   draft-ietf-dots-use-cases-18.txt >
DOTS R. Dobbins DOTS R. Dobbins
Internet-Draft Arbor Networks Internet-Draft Arbor Networks
Intended status: Informational D. Migault Intended status: Informational D. Migault
Expires: July 14, 2019 Ericsson Expires: January 9, 2020 Ericsson
S. Fouant S. Fouant
R. Moskowitz R. Moskowitz
HTT Consulting HTT Consulting
N. Teague N. Teague
Verisign Iron Mountain Data Centers
L. Xia L. Xia
Huawei Huawei
K. Nishizuka K. Nishizuka
NTT Communications NTT Communications
January 10, 2019 July 08, 2019
Use cases for DDoS Open Threat Signaling Use cases for DDoS Open Threat Signaling
draft-ietf-dots-use-cases-17 draft-ietf-dots-use-cases-18
Abstract Abstract
The DDoS Open Threat Signaling (DOTS) effort is intended to provide The DDoS Open Threat Signaling (DOTS) effort is intended to provide
protocols to facilitate interoperability across disparate DDoS protocols to facilitate interoperability across disparate DDoS
mitigation solutions. This document presents use cases which mitigation solutions. This document presents sample use cases which
describe the interactions expected between the DOTS components as describe the interactions expected between the DOTS components as
well as DOTS messaging exchanges. These use cases are meant to well as DOTS messaging exchanges. These use cases are meant to
identify the interacting DOTS components, how they collaborate and identify the interacting DOTS components, how they collaborate, and
what are the typical information to be exchanged. what are the typical information to be exchanged.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 14, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Upstream DDoS Mitigation by an Upstream Internet Transit 3.1. Upstream DDoS Mitigation by an Upstream Internet Transit
Provider . . . . . . . . . . . . . . . . . . . . . . . . 3 Provider . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. DDoS Mitigation by a Third Party DDoS Mitigation Service 3.2. DDoS Mitigation by a Third Party DDoS Mitigation Service
Provider . . . . . . . . . . . . . . . . . . . . . . . . 7 Provider . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. DDoS Orchestration . . . . . . . . . . . . . . . . . . . 9 3.3. DDoS Orchestration . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . 13 7. Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
At the time of writing, distributed denial-of-service (DDoS) attack At the time of writing, distributed denial-of-service (DDoS) attack
mitigation solutions are largely based upon siloed, proprietary mitigation solutions are largely based upon siloed, proprietary
communications schemes with vendor lock-in as a side-effect. This communications schemes with vendor lock-in as a side-effect. This
can result in the configuration, provisioning, operation, and can result in the configuration, provisioning, operation, and
activation of these solutions being a highly manual and often time- activation of these solutions being a highly manual and often time-
consuming process. Additionally, coordinating multiple DDoS consuming process. Additionally, coordinating multiple DDoS
mitigation solutions simultaneously is fraught with both technical mitigation solutions simultaneously is fraught with both technical
and process-related hurdles. This greatly increases operational and process-related hurdles. This greatly increases operational
complexity which, in turn, can degrade the efficacy of mitigations. complexity which, in turn, can degrade the efficacy of mitigations.
The DDoS Open Threat Signaling (DOTS) effort is intended to specify The DDoS Open Threat Signaling (DOTS) effort is intended to specify
protocols that facilitate interoperability between diverse DDoS protocols that facilitate interoperability between diverse DDoS
mitigation solutions and ensure greater integration in term of mitigation solutions and ensure greater integration in term of attack
mitigation requests and attack characterization patterns. As DDoS detection, mitigation requests, and attack characterization patterns.
solutions are broadly heterogeneous among vendors, the primary goal As DDoS solutions are broadly heterogeneous among vendors, the
of DOTS is to provide high-level interaction amongst differing DDoS primary goal of DOTS is to provide high-level interaction amongst
solutions, such as initiating, terminating DDoS mitigation assistance differing DDoS solutions, such as detecting, initiating, terminating
or requesting the status of a DDoS mitigation. DDoS mitigation assistance or requesting the status of a DDoS
mitigation.
This document provides use cases to provide inputs for the design of This document provides sample use cases to provide inputs for the
the DOTS protocol(s). The use cases are not exhaustive and future design of the DOTS protocols. The use cases are not exhaustive and
use cases are expected to emerge as DOTS is adopted and evolves. future use cases are expected to emerge as DOTS is adopted and
evolves.
2. Terminology and Acronyms 2. Terminology and Acronyms
This document makes use of the same terminology and definitions as This document makes use of the same terminology and definitions as
[I-D.ietf-dots-requirements]. In addition it uses the terms defined [RFC8612]. In addition it uses the terms defined below:
below:
o DDoS Mitigation Service Provider: designates the administrative o DDoS Mitigation Service Provider: designates the administrative
entity providing the DDoS Mitigation Service. entity providing the DDoS Mitigation Service.
o DDoS Mitigation System (DMS): A system that performs DDoS o DDoS Mitigation System (DMS): A system that performs DDoS
mitigation. The DDoS Mitigation System may be composed by a mitigation. The DDoS Mitigation System may be composed by a
cluster of hardware and/or software resources, but could also cluster of hardware and/or software resources, but could also
involve an orchestrator that may take decisions such as involve an orchestrator that may take decisions such as
outsourcing partial or more of the mitigation to another DDoS outsourcing partial or more of the mitigation to another DDoS
Mitigation System. Mitigation System.
o DDoS Mitigation: The action performed by the DDoS Mitigation o DDoS Mitigation: The action performed by the DDoS Mitigation
System. System.
o DDoS Mitigation Service: designates a DDoS mitigation service o DDoS Mitigation Service: designates a service provided to a
provided to a customer and which is scoped to mitigate DDoS customer to mitigate DDoS attacks. Service subscriptions usually
attacks. Services usually involve Service Level Agreement (SLA) involve Service Level Agreement (SLA) that have to be met. It is
that have to be met. It is the responsibility of the DDoS Service the responsibility of the DDoS Service provider to instantiate the
provider to instantiate the DDoS Mitigation System to meet these DDoS Mitigation System to meet these SLAs.
SLAs.
o Internet Transit Provider (ITP): designates the entity that o Internet Transit Provider (ITP): designates the entity that
delivers the traffic to the network. It can be an Internet delivers the traffic to a customer network. It can be an Internet
Service Provider (ISP), or an upstream entity delivering the Service Provider (ISP), or an upstream entity delivering the
traffic to the ISP. traffic to the ISP.
3. Use Cases 3. Use Cases
3.1. Upstream DDoS Mitigation by an Upstream Internet Transit Provider 3.1. Upstream DDoS Mitigation by an Upstream Internet Transit Provider
This use case describes how an enterprise or a residential customer This use case describes how an enterprise or a residential customer
network may take advantage of a pre-existing relation with its network may take advantage of a pre-existing relation with its
Internet Transit Provider (ITP) in order to mitigate a DDoS attack Internet Transit Provider (ITP) in order to mitigate a DDoS attack
targeting its network. To improve the clarity of our purpose, the targeting its network.
targeted network will be designated as enterprise network, but the
same scenario applies to any downstream network, including To improve the clarity of our purpose, the targeted network will be
residential network and cloud hosting network. As the ITP provides designated as enterprise network, but the same scenario applies to
connectivity to the enterprise network, it is already on the path of any downstream network, including residential network and cloud
the inbound or outbound traffic of the enterprise network and well hosting network.
aware of the networking parameters associated to the enterprise
network connectivity. This eases both the configuration and the As the ITP provides connectivity to the enterprise network, it is
instantiation of a DDoS Mitigation Service. This section considers already on the path of the inbound and outbound traffic of the
two kind of DDoS Mitigation Service between an enterprise network and enterprise network and well aware of the networking parameters
an ITP: associated to the enterprise network WAN connectivity. This eases
both the configuration and the instantiation of a DDoS Mitigation
Service.
This section considers two kind of DDoS Mitigation Service between an
enterprise network and an ITP:
o The upstream ITP may instantiate a DDoS Mitigation System (DMS) o The upstream ITP may instantiate a DDoS Mitigation System (DMS)
upon receiving a request from the enterprise network. This upon receiving a request from the enterprise network. This
typically corresponds to the case when the enterprise network is typically corresponds to the case when the enterprise network is
under attack. under attack.
o On the other hand, the ITP may identify an enterprise network as o On the other hand, the ITP may identify an enterprise network as
the source of an attack and send a mitigation request to the the source of an attack and send a mitigation request to the
enterprise DMS to mitigate this at the source. enterprise DMS to mitigate this at the source.
The two scenarios, thought different, have similar interactions
between the DOTS client and server. For the sake of simplicity, only
the first scenario will be detailed in this section. Nevertheless,
the second scenario is also in scope of DOTS.
In the first scenario, as depicted in Figure 1, an enterprise network In the first scenario, as depicted in Figure 1, an enterprise network
with self-hosted Internet-facing properties such as Web servers, with self-hosted Internet-facing properties such as Web servers,
authoritative DNS servers, and VoIP servers has a DMS deployed to authoritative DNS servers, and VoIP servers has a DMS deployed to
protect those servers and applications from DDoS attacks. In protect those servers and applications from DDoS attacks. In
addition to on-premise DDoS defense capability, enterprises have addition to on-premise DDoS defense capability, the enterprise has
contracted with their ITP for DDoS Mitigation Services which threaten contracted with its ITP for DDoS Mitigation Services which threaten
to overwhelm their WAN link(s) bandwidth. to overwhelm their WAN link(s) bandwidth.
+------------------+ +------------------+ +------------------+ +------------------+
| Enterprise | | Upstream | | Enterprise | | Upstream |
| Network | | Internet Transit | | Network | | Internet Transit |
| | | Provider | | | | Provider |
| +--------+ | | DDoS Attack | +--------+ | | DDoS Attack
| | DDoS | | <================================= | | DDoS | | <=================================
| | Target | | <================================= | | Target | | <=================================
| +--------+ | | +------------+ | | +--------+ | | +------------+ |
skipping to change at page 5, line 35 skipping to change at page 5, line 35
+------------------+ +------------------+ +------------------+ +------------------+
* C is for DOTS client functionality * C is for DOTS client functionality
* S is for DOTS server functionality * S is for DOTS server functionality
Figure 1: Upstream Internet Transit Provider DDoS Mitigation Figure 1: Upstream Internet Transit Provider DDoS Mitigation
The enterprise DMS is configured such that if the incoming Internet The enterprise DMS is configured such that if the incoming Internet
traffic volume exceeds 50% of the provisioned upstream Internet WAN traffic volume exceeds 50% of the provisioned upstream Internet WAN
link capacity, the DMS will request DDoS mitigation assistance from link capacity, the DMS will request DDoS mitigation assistance from
the upstream transit provider. the upstream transit provider. More sophisticated detection means
may be considered.
The requests to trigger, manage, and finalize a DDoS Mitigation The requests to trigger, manage, and finalize a DDoS Mitigation
between the enterprise DMS and the ITP is performed using DOTS. The between the enterprise DMS and the ITP is performed using DOTS. The
enterprise DMS implements a DOTS client while the ITP implements a enterprise DMS implements a DOTS client while the ITP implements a
DOTS server which is integrated with their DMS. DOTS server which is integrated with their DMS in this example.
When the enterprise DMS detects an inbound DDoS attack targeting its When the enterprise DMS locally detects an inbound DDoS attack
resources ( e.g. servers, hosts or applications), it immediately targeting its resources (e.g., servers, hosts, or applications), it
begins a DDoS Mitigation. immediately begins a DDoS Mitigation.
During the course of the attack, the inbound traffic volume exceeds During the course of the attack, the inbound traffic volume to the
the 50% threshold; the DMS DOTS client signals the DOTS server on the enterprise network exceeds the 50% threshold and the enterprise DMS
upstream ITP to initiate DDoS Mitigation. The DOTS server signals escalates the DDoS mitigation. The enterprise DMS DOTS client
the DOTS client that it can serve this request, and mitigation is signals to the DOTS server on the upstream ITP to initiate DDoS
initiated on the ITP network by the ITP DMS. Mitigation. The DOTS server replies to the DOTS client that it can
serve this request, and mitigation is initiated on the ITP network by
the ITP DMS.
Over the course of the attack, the DOTS server of the ITP Over the course of the attack, the DOTS server of the ITP
periodically informs the DOTS client on the enterprise DMS mitigation periodically informs the DOTS client on the enterprise DMS mitigation
status, statistics related to DDoS attack traffic mitigation, and status, statistics related to DDoS attack traffic mitigation, and
related information. Once the DDoS attack has ended, or decreased to related information. Once the DDoS attack has ended, or decreased to
the certain level that the DOTS client can handle by itself, the DOTS the certain level that the enterprise DMS can handle by itself, the
server signals the enterprise DMS DOTS client that the attack has DOTS server signals the enterprise DMS DOTS client that the attack
subsided. has subsided.
The enterprise DMS then requests the ITP to terminate the DDoS The DOTS client on the enterprise DMS then requests the ITP to
Mitigation. The DOTS server on the ITP receives this request and terminate the DDoS Mitigation. The DOTS server on the ITP receives
once the mitigation has ended, confirms the end of upstream DDoS this request and once the mitigation has ended, confirms the end of
Mitigation to the enterprise DMS DOTS client. upstream DDoS Mitigation to the enterprise DMS DOTS client.
The following is an overview of the DOTS communication model for this The following is an overview of the DOTS communication model for this
use-case: use-case:
o (a) A DDoS attack is initiated against resources of a network o (a) A DDoS attack is initiated against resources of a network
organization which has deployed a DOTS-capable DMS - typically a organization (here, the enterprise) which has deployed a DOTS-
DOTS client. capable DMS - typically a DOTS client.
o (b) The enterprise DMS detects, classifies, and begins the DDoS o (b) The enterprise DMS detects, classifies, and begins the DDoS
Mitigation. Mitigation.
o (c) The enterprise DMS determines that its capacity and/or o (c) The enterprise DMS determines that its capacity and/or
capability to mitigate the DDoS attack is insufficient, and sends capability to mitigate the DDoS attack is insufficient, and sends
via its DOTS client a DOTS DDoS Mitigation request to one or more via its DOTS client a DOTS DDoS Mitigation request to one or more
DOTS servers residing on the upstream ITP. DOTS servers residing on the upstream ITP.
o (d) The DOTS server which receives the DOTS Mitigation request o (d) The DOTS server which receives the DOTS Mitigation request
determines that it has been configured to honor requests from the determines that it has been configured to honor requests from the
requesting DOTS client, and honored its DDoS Mitigation by requesting DOTS client, and honors its DDoS Mitigation by
orchestrating its DMS. orchestrating its DMS.
o (e) While the DDoS Mitigation is active, DOTS server regularly o (e) While the DDoS Mitigation is active, the DOTS server regularly
transmits DOTS DDoS Mitigation status updates to the DOTS client. transmits DOTS DDoS Mitigation status updates to the DOTS client.
o (f) Informed by the DOTS server status update that the attack has o (f) Informed by the DOTS server status update that the attack has
ended or subsided, the DOTS client transmits a DOTS DDoS ended or subsided, the DOTS client transmits a DOTS DDoS
Mitigation termination request to the DOTS server. Mitigation termination request to the DOTS server.
o (g) The DOTS server terminates DDoS Mitigation, and sends the o (g) The DOTS server terminates DDoS Mitigation, and sends the
notification to the DOTS client. notification to the DOTS client.
Note that communications between the enterprise DOTS client and the Note that communications between the enterprise DOTS client and the
upstream ITP DOTS Server may take place in-band within the main upstream ITP DOTS server may take place in-band within the main
Internet WAN link between the enterprise and the ITP; out-of-band via Internet WAN link between the enterprise and the ITP; out-of-band via
a separate, dedicated wireline network link utilized solely for DOTS a separate, dedicated wireline network link utilized solely for DOTS
signaling; or out-of-band via some other form of network connectivity signaling; or out-of-band via some other form of network connectivity
such as a third-party wireless 4G network connectivity. such as a third-party wireless 4G network connectivity.
Note also that a DOTS client that sends a DOTS Mitigation request may Note also that a DOTS client that sends a DOTS Mitigation request may
be also triggered by a network admin that manually confirms the be also triggered by a network admin that manually confirms the
request to the upstream ITP, in which case the request may be sent request to the upstream ITP, in which case the request may be sent
from an application such as a web browser or a dedicated mobile from an application such as a web browser or a dedicated mobile
application. application.
Note also that when the enterprise is multihomed and connected to Note also that when the enterprise is multihomed and connected to
multiple upstream ITPs, each ITP is only able to provide a DDoS multiple upstream ITPs, each ITP is only able to provide a DDoS
Mitigation Service for the traffic it transits. As a result, the Mitigation Service for the traffic it transits. As a result, the
enterprise network may require to coordinate the various DDoS enterprise network may require to coordinate the various DDoS
Mitigation Services associated to each link. More multi-homing Mitigation Services associated to each link. More multi-homing
considerations are discussed in [I-D.boucadair-dots-multihoming]. considerations are discussed in [I-D.ietf-dots-multihoming].
3.2. DDoS Mitigation by a Third Party DDoS Mitigation Service Provider 3.2. DDoS Mitigation by a Third Party DDoS Mitigation Service Provider
This use case differs from the previous use case described in This use case differs from the previous use case described in
Section 3.1 in that the DDoS Mitigation Service is not provided by an Section 3.1 in that the DDoS Mitigation Service is not provided by an
upstream ITP. In other words, as represented in Figure 2, the upstream ITP. In other words, as represented in Figure 2, the
traffic is not forwarded through the DDoS Mitigation Service Provider traffic is not forwarded through the DDoS Mitigation Service Provider
by default. In order to steer the traffic to the DDoS Mitigation by default. In order to steer the traffic to the DDoS Mitigation
Service Provider, some network configuration changes are required. Service Provider, some network configuration changes are required.
As such, this use case likely to match large enterprises or large As such, this use case is likely to match large enterprises or large
data centers, but not exclusively. Another typical scenario for this data centers, but not exclusively.
use case is the relation between DDoS Mitigation Service Providers
forming an overlay of DMS. When a DDoS Mitigation Service Provider Another typical scenario for this use case is the relation between
mitigating a DDoS attack reaches it resources capacities, it may DDoS Mitigation Service Providers forming an overlay of DMS. When a
chose to delegate the DDoS Mitigation to another DDoS Mitigation DDoS Mitigation Service Provider mitigating a DDoS attack reaches it
Service Provider. resources capacities, it may chose to delegate the DDoS Mitigation to
another DDoS Mitigation Service Provider.
+------------------+ +------------------+ +------------------+ +------------------+
| Enterprise | | Upstream | | Enterprise | | Upstream |
| Network | | Internet Transit | | Network | | Internet Transit |
| | | Provider | | | | Provider |
| +--------+ | | DDoS Attack | +--------+ | | DDoS Attack
| | DDoS | | <================================= | | DDoS | | <=================================
| | Target | | <================================= | | Target | | <=================================
| +--------+ | +----------------------------+ | +--------+ | | |
| | | | | | | | | |
| | | +------------------+ | | | +------------------+
| | | | | |
| | | +------------------+ | | | +------------------+
| | | | DDoS Mitigation | | | | | DDoS Mitigation |
| | | | Service Provider | | | | | Service Provider |
| | | | | | | | | |
| +------------+ | | | +------------+ | | | +------------+ | | +------------+ |
| | DDoS |<---+ | | DDoS |<----+ | | DDoS |<------------>| DDoS | |
| | Mitigation |C | | | Mitigation |S | | | Mitigation |C | | S| Mitigation | |
| | System | | | | System | | | | System | | | | System | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
+------------------+ +------------------+ +------------------+ +------------------+
* C is for DOTS client functionality * C is for DOTS client functionality
* S is for DOTS server functionality * S is for DOTS server functionality
Figure 2: DDoS Mitigation between an Enterprise Network and Third Figure 2: DDoS Mitigation between an Enterprise Network and Third
Party DDoS Mitigation Service Provider Party DDoS Mitigation Service Provider
In this scenario, an Enterprise Network has entered into a pre- In this scenario, an enterprise network has entered into a pre-
arranged DDoS mitigation assistance agreement with one or more other arranged DDoS mitigation assistance agreement with one or more other
DDoS Mitigation Service Providers in order to ensure that sufficient DDoS Mitigation Service Providers in order to ensure that sufficient
DDoS mitigation capacity and/or capabilities may be activated in the DDoS mitigation capacity and/or capabilities may be activated in the
event that a given DDoS attack threatens to overwhelm the ability of event that a given DDoS attack threatens to overwhelm the ability of
a given DMS to mitigate the attack on its own. the enterprise's or any other given DMS to mitigate the attack on its
own.
The pre-arrangement typically includes the agreement on the The pre-arrangement typically includes the agreement on the
mechanisms used to redirect the traffic to the DDoS Mitigation mechanisms used to redirect the traffic to the DDoS Mitigation
Service Provider, as well as the mechanism to re-inject the traffic Service Provider, as well as the mechanism to re-inject the traffic
back to the Enterprise Network. Redirection to the DDoS Mitigation back to the Enterprise Network. Redirection to the DDoS Mitigation
Service Provider typically involves BGP prefix announcement or DNS Service Provider typically involves BGP prefix announcement or DNS
redirection, while re-injection of the scrubbed traffic to the redirection, while re-injection of the scrubbed traffic to the
enterprise network may be performed via tunneling mechanisms such as enterprise network may be performed via tunneling mechanisms (e.g.,
GRE for example. These exact mechanisms used for traffic steering GRE). These exact mechanisms used for traffic steering are out of
are out of scope. scope.
In some cases the communication between the enterprise DOTS client
and the DOTS server of the DDoS Mitigation Service Provider may go
through the ITP carrying the DDoS attack, which would affect the
communication. On the other hand, the communication between the DOTS
client and DOTS server may take a path that is not undergoing a DDoS
attack.
+------------------+ +------------------+ +------------------+ +------------------+
| Enterprise | | Upstream | | Enterprise | | Upstream |
| Network | | Internet Transit | | Network | | Internet Transit |
| | | Provider | | | | Provider |
| +--------+ | | DDoS Attack | +--------+ | | DDoS Attack
| | DDoS | |<----------------+ | ++==== | | DDoS | |<----------------+ | ++====
| | Target | | Mitigated | | || ++= | | Target | | Mitigated | | || ++=
| +--------+ | | | | || || | +--------+ | | | | || ||
| | | | | || || | | | | | || ||
skipping to change at page 9, line 32 skipping to change at page 9, line 36
| | mitigation |C | |S | mitigation |<===++ || | | mitigation |C | |S | mitigation |<===++ ||
| | system | | | | system |<======++ | | system | | | | system |<======++
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
+------------------+ +------------------+ +------------------+ +------------------+
* C is for DOTS client functionality * C is for DOTS client functionality
* S is for DOTS server functionality * S is for DOTS server functionality
Figure 3: Redirection to a DDoS Mitigation Service Provider Figure 3: Redirection to a DDoS Mitigation Service Provider
When the Enterprise Network is under attack or at least is reaching When the enterprise network is under attack or at least is reaching
its capacity or ability to mitigate a given DDoS attack traffic, the its capacity or ability to mitigate a given DDoS attack traffic, the
DOTS client sends a DOTS request to the DDoS Mitigation Service DOTS client sends a DOTS request to the DDoS Mitigation Service
Provider to initiate network traffic diversion - as represented in Provider to initiate network traffic diversion - as represented in
Figure 3 - and DDoS mitigation activities. Ongoing attack and Figure 3 - and DDoS mitigation activities. Ongoing attack and
mitigation status messages may be passed between the Enterprise mitigation status messages may be passed between the enterprise
Network and the DDoS Mitigation Service Provider. If the DDoS attack network and the DDoS Mitigation Service Provider using DOTS. If the
has stopped or the severity of the attack has subsided, the DOTS DDoS attack has stopped or the severity of the attack has subsided,
client can request the DDoS Mitigation Service Provider to stop the the DOTS client can request the DDoS Mitigation Service Provider to
DDoS Mitigation. stop the DDoS Mitigation.
3.3. DDoS Orchestration 3.3. DDoS Orchestration
In this use case, one or more DDoS telemetry systems or monitoring In this use case, one or more DDoS telemetry systems or monitoring
devices monitor a network - typically an ISP network, an Enterprise devices monitor a network - typically an ISP network, an enterprise
network, or a data center. Upon detection of a DDoS attack, these network, or a data center. Upon detection of a DDoS attack, these
DDoS telemetry systems alert an orchestrator in charge of DDoS telemetry systems alert an orchestrator in charge of
coordinating the various DMS within the domain. The DDoS telemetry coordinating the various DMS's within the domain. The DDoS telemetry
systems may be configured to provide required information, such as a systems may be configured to provide required information, such as a
preliminary analysis of the observation to the orchestrator. preliminary analysis of the observation to the orchestrator.
The orchestrator analyses the various information it receives from The orchestrator analyses the various information it receives from
DDoS telemetry system, and initiates one or multiple DDoS mitigation DDoS telemetry system, and initiates one or multiple DDoS mitigation
strategies. For example, the orchestrator could select the DDoS strategies. For example, the orchestrator could select the DDoS
mitigation system in the Enterprise network or one provided by the mitigation system in the enterprise network or one provided by the
ITP. DDoS Mitigation System selection and DDoS Mitigation technique ITP.
may depends on the type of DDoS attack. In some case, a manual
DDoS Mitigation System selection and DDoS Mitigation techniques may
depends on the type of the DDoS attack. In some case, a manual
confirmation or selection may also be required to choose a proposed confirmation or selection may also be required to choose a proposed
strategy to initiate a DDoS Mitigation. The DDoS Mitigation may strategy to initiate a DDoS Mitigation. The DDoS Mitigation may
consist of multiple steps such as configuring the network, or consist of multiple steps such as configuring the network, or
updating already instantiated DDoS mitigation functions. Eventually, updating already instantiated DDoS mitigation functions. Eventually,
the coordination of the mitigation may involve external DDoS the coordination of the mitigation may involve external DDoS
mitigation resources such as a transit provider or a Third Party DDoS mitigation resources such as a transit provider or a Third Party DDoS
Mitigation Service Provider. Mitigation Service Provider.
The communication used to trigger a DDoS Mitigation between the DDoS The communication used to trigger a DDoS Mitigation between the DDoS
telemetry and monitoring systems and the orchestrator is performed telemetry and monitoring systems and the orchestrator is performed
using DOTS. The DDoS telemetry system implements a DOTS client while using DOTS. The DDoS telemetry system implements a DOTS client while
the orchestrator implements a DOTS server. the orchestrator implements a DOTS server.
The communication between a network administrator and the The communication between a network administrator and the
orchestrator is also performed using DOTS. The network administrator orchestrator is also performed using DOTS. The network administrator
via its web interfaces implements a DOTS client, while the uses a web interface which interacts with a DOTS client, while the
Orchestrator implements a DOTS server. orchestrator implements a DOTS server.
The communication between the orchestrator and the DDoS mitigation The communication between the orchestrator and the DDoS Mitigation
systems is performed using DOTS. The orchestrator implements a DOTS Systems is performed using DOTS. The orchestrator implements a DOTS
Client while the DDoS mitigation systems implement a DOTS Server. client while the DDoS Mitigation Systems implement a DOTS server.
The configuration aspects of each DDoS mitigation system, as well as The configuration aspects of each DDoS Mitigation System, as well as
the instantiations of DDoS mitigation functions or network the instantiations of DDoS mitigation functions or network
configuration is not part of DOTS. Similarly, the discovery of configuration is not part of DOTS. Similarly, the discovery of
available DDoS mitigation functions is not part of DOTS; and as such available DDoS mitigation functions is not part of DOTS; and as such
is out of scope. is out of scope.
+----------+ +----------+
| network |C (Enterprise Network) | network |C (Enterprise Network)
| adminis |<-+ | adminis |<-+
| trator | | | trator | |
+----------+ | +----------+ |
skipping to change at page 11, line 22 skipping to change at page 11, line 22
|telemetry/| +->| |C S| DDoS |+ |telemetry/| +->| |C S| DDoS |+
|monitoring|<--->| Orchestrator |<--->| mitigation|| |monitoring|<--->| Orchestrator |<--->| mitigation||
|systems |C S| |<-+ | systems || |systems |C S| |<-+ | systems ||
+----------+ +--------------+C | +-----------+| +----------+ +--------------+C | +-----------+|
| +----------+ | +----------+
-----------------------------------|----------------- -----------------------------------|-----------------
| |
| |
(Internet Transit Provider) | (Internet Transit Provider) |
| +-----------+ | +-----------+
| S| DDoS | | S| DDoS |+
+->| mitigation| +->| mitigation||
| systems | | systems ||
+-----------+ +-----------+|
* C is for DOTS client functionality * C is for DOTS client functionality +----------+
* S is for DOTS server functionality * S is for DOTS server functionality
Figure 4: DDoS Orchestration Figure 4: DDoS Orchestration
The DDoS telemetry systems monitor various network traffic and The DDoS telemetry systems monitor various network traffic and
perform some measurement tasks. perform some measurement tasks.
These systems are configured so that when an event or some These systems are configured so that when an event or some
measurement indicators reach a predefined level to send DOTS measurement indicators reach a predefined level their associated DOTS
mitigation request to the orchestrator. The DOTS mitigation request client sends a DOTS mitigation request to the orchestrator DOTS
may be associated with some optional mitigation hints to let the server. The DOTS mitigation request may be associated with some
orchestrator know what has triggered the request. optional mitigation hints to let the orchestrator know what has
triggered the request.
Upon receipt of the DOTS mitigation request from the DDoS telemetry Upon receipt of the DOTS mitigation request from the DDoS telemetry
system, the orchestrator responds with an acknowledgment, to avoid system, the orchestrator DOTS server responds with an acknowledgment,
retransmission of the request for mitigation. The orchestrator may to avoid retransmission of the request for mitigation. The
begin collecting additional fined grain and specific information from orchestrator may begin collecting additional fine-grained and
various DDoS telemetry systems in order to correlate the measurements specific information from various DDoS telemetry systems in order to
and provide an analysis of the event. Eventually, the orchestrator correlate the measurements and provide an analysis of the event.
may ask additional information to the DDoS telemetry system, however, Eventually, the orchestrator may ask for additional information from
the collection of these information is out of scope. the DDoS telemetry system; however, the collection of this
information is out of scope.
The orchestrator may be configured to start a DDoS Mitigation upon The orchestrator may be configured to start a DDoS Mitigation upon
approval from a network administrator. The analysis from the approval from a network administrator. The analysis from the
orchestrator is reported to the network administrator via a web orchestrator is reported to the network administrator via a web
interface. If the network administrator decides to start the interface. If the network administrator decides to start the
mitigation, the network administrator triggers the DDoS mitigation mitigation, the network administrator triggers the DDoS mitigation
request using the web interface of a DOTS client connected to the request using the web interface of a DOTS client connected to the
orchestrator. This request is expected to be associated with a orchestrator DOTS server. This request is expected to be associated
context that provides sufficient information to the orchestrator to with a context that provides sufficient information to the
infer the DDoS Mitigation to elaborate and coordinate. orchestrator DOTS server to infer the DDoS Mitigation to elaborate
and coordinate.
Upon receiving a request to mitigate a DDoS attack performed over a Upon receiving a request to mitigate a DDoS attack performed over a
target, the orchestrator, may evaluate the volumetry of the attack as target, the orchestrator may evaluate the volumetry of the attack as
well as the value that represent the target. The orchestrator may well as the value that the target represents. The orchestrator may
select the DDoS Mitigation Service Provider based on the attack select the DDoS Mitigation Service Provider based on the attack
severity. It may also coordinate the DDoS Mitigation performed by severity. It may also coordinate the DDoS Mitigation performed by
the DDoS Mitigation Service Provider with some other tasks such as the DDoS Mitigation Service Provider with some other tasks such as
for example, moving the target to another network so new sessions for example, moving the target to another network so new sessions
will not be impacted. When DDoS Mitigation is requested, the status will not be impacted. The orchestrator requests a DDoS Mitigation to
indicates the DDoS Mitigation is starting while not effective. The the selected DDoS mitigation systems via its DOTS client, as
DOTS client of the orchestrator will later be notified that the DDoS described in Section 3.1.
Mitigation is effective.
Orchestration of the DDoS mitigation systems works similarly as The orchestrator DOTS client is notified that the DDoS Mitigation is
described in Section 3.1. The orchestrator indicates with its status effective by the selected DDoS mitigation systems. The orchestrator
whether the DDoS Mitigation is effective. DOTS servers returns back this information to the network
administrator.
When the DDoS attack has stopped, the orchestrator indicates to the Similarly, when the DDoS attack has stopped, the orchestrator DOTS
DDoS telemetry systems as well as to the network administrator the client are being notified and the orchestrator's DOTS servers
end of the DDoS Mitigation. indicate to the DDoS telemetry systems as well as to the network
administrator the end of the DDoS Mitigation.
4. Security Considerations 4. Security Considerations
The document does not describe any protocol. The document does not describe any protocol.
DOTS is at risk from three primary attacks: DOTS agent impersonation, DOTS is at risk from three primary attacks: DOTS agent impersonation,
traffic injection, and signaling blocking. traffic injection, and signaling blocking.
Impersonation and traffic injection mitigation can be mitigated Impersonation and traffic injection mitigation can be mitigated
through current secure communications best practices. through current secure communications best practices. Preconfigured
mitigation steps to take on the loss of keepalive traffic can
partially mitigate signal blocking, but in general it is impossible
to comprehensively defend against an attacker that can selectively
block any or all traffic
Additional details of DOTS security requirements can be found in Additional details of DOTS security requirements can be found in
[I-D.ietf-dots-requirements]. [RFC8612].
5. IANA Considerations 5. IANA Considerations
No IANA considerations exist for this document at this time. No IANA considerations exist for this document.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank among others Tirumaleswar Reddy; The authors would like to thank among others Tirumaleswar Reddy;
Andrew Mortensen; Mohamed Boucadaire; Artyom Gavrichenkov; Jon Andrew Mortensen; Mohamed Boucadair; Artyom Gavrichenkov; Jon Shallow
Shallow and the DOTS WG chairs, Roman Danyliw and Tobias Gondrom, for the DOTS WG chairs, Roman Danyliw and Tobias Gondrom as well as the
their valuable feedback. Security AD Benjamin Kaduk for their valuable feedback.
7. Informative References 7. Informative References
[I-D.boucadair-dots-multihoming] [I-D.ietf-dots-multihoming]
Boucadair, M. and R. K, "Multi-homing Deployment Boucadair, M. and R. K, "Multi-homing Deployment
Considerations for Distributed-Denial-of-Service Open Considerations for Distributed-Denial-of-Service Open
Threat Signaling (DOTS)", draft-boucadair-dots- Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01
multihoming-04 (work in progress), October 2018. (work in progress), January 2019.
[I-D.ietf-dots-requirements] [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
Mortensen, A., Moskowitz, R., and R. K, "Distributed Threat Signaling (DOTS) Requirements", RFC 8612,
Denial of Service (DDoS) Open Threat Signaling DOI 10.17487/RFC8612, May 2019,
Requirements", draft-ietf-dots-requirements-16 (work in <https://www.rfc-editor.org/info/rfc8612>.
progress), October 2018.
Authors' Addresses Authors' Addresses
Roland Dobbins Roland Dobbins
Arbor Networks Arbor Networks
Singapore Singapore
EMail: rdobbins@arbor.net EMail: rdobbins@arbor.net
Daniel Migault Daniel Migault
skipping to change at page 13, line 41 skipping to change at page 14, line 4
8275 Trans Canada Route 8275 Trans Canada Route
Saint Laurent, QC 4S 0B6 Saint Laurent, QC 4S 0B6
Canada Canada
EMail: daniel.migault@ericsson.com EMail: daniel.migault@ericsson.com
Stefan Fouant Stefan Fouant
USA USA
EMail: stefan.fouant@copperriverit.com EMail: stefan.fouant@copperriverit.com
Robert Moskowitz Robert Moskowitz
HTT Consulting HTT Consulting
Oak Park, MI 48237 Oak Park, MI 48237
USA USA
EMail: rgm@labs.htt-consult.com EMail: rgm@labs.htt-consult.com
Nik Teague Nik Teague
Verisign Iron Mountain Data Centers
12061 Bluemont Way UK
Reston, VA 20190
EMail: nteague@verisign.com EMail: nteague@ironmountain.co.uk
Liang Xia Liang Xia
Huawei Huawei
No. 101, Software Avenue, Yuhuatai District No. 101, Software Avenue, Yuhuatai District
Nanjing Nanjing
China China
EMail: Frank.xialiang@huawei.com EMail: Frank.xialiang@huawei.com
Kaname Nishizuka Kaname Nishizuka
 End of changes. 59 change blocks. 
153 lines changed or deleted 183 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/