Skip to main content

Use cases for DDoS Open Threat Signaling
draft-ietf-dots-use-cases-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8903.
Authors Roland Dobbins , Daniel Migault , Stefan Fouant , Robert Moskowitz , Nik Teague , Liang Xia , Kaname Nishizuka
Last updated 2017-07-03
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 8903 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-dots-use-cases-06
DOTS                                                          R. Dobbins
Internet-Draft                                            Arbor Networks
Intended status: Informational                                D. Migault
Expires: January 4, 2018                                        Ericsson
                                                               S. Fouant

                                                            R. Moskowitz
                                                          HTT Consulting
                                                               N. Teague
                                                                Verisign
                                                                  L. Xia
                                                                  Huawei
                                                            K. Nishizuka
                                                      NTT Communications
                                                           July 03, 2017

                Use cases for DDoS Open Threat Signaling
                      draft-ietf-dots-use-cases-06

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 DOTS
   messaging exchanges.  The purpose of describing use cases is to
   identify the interacting DOTS components, 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 January 4, 2018.

Dobbins, et al.          Expires January 4, 2018                [Page 1]
Internet-Draft               DOTS Use Cases                    July 2017

Copyright Notice

   Copyright (c) 2017 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.  Inter-domain Use Cases  . . . . . . . . . . . . . . . . .   5
       3.1.1.  End-customer with a single upstream transit provider
               offering DDoS mitigation services . . . . . . . . . .   5
       3.1.2.  End-customer with multiple upstream transit providers
               offering DDoS mitigation services . . . . . . . . . .   6
       3.1.3.  End-customer with multiple upstream transit
               providers, but only a single upstream transit
               provider offering DDoS mitigation services  . . . . .   6
       3.1.4.  End-customer with an overlay DDoS mitigation managed
               security service provider (MSSP)  . . . . . . . . . .   7
       3.1.5.  End-customer operating an application or service with
               an integrated DOTS client . . . . . . . . . . . . . .   8
       3.1.6.  End-customer operating a CPE network infrastructure
               device with an integrated DOTS client . . . . . . . .   9
       3.1.7.  End-customer with an out-of-band smartphone
               application featuring DOTS client capabilities  . . .   9
       3.1.8.  MSSP as an end-customer requesting overflow DDoS
               mitigation assistance from other MSSPs  . . . . . . .   9
     3.2.  Intra-domain Use Cases  . . . . . . . . . . . . . . . . .  10
       3.2.1.  Suppression of outbound DDoS traffic originating from
               a consumer broadband access network . . . . . . . . .  10
       3.2.2.  DDoS Orchestration  . . . . . . . . . . . . . . . . .  12
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  15

Dobbins, et al.          Expires January 4, 2018                [Page 2]
Internet-Draft               DOTS Use Cases                    July 2017

   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

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 January 4, 2018                [Page 3]
Internet-Draft               DOTS Use Cases                    July 2017

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.  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 attack telemetry 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 January 4, 2018                [Page 4]
Internet-Draft               DOTS Use Cases                    July 2017

3.1.  Inter-domain Use Cases

3.1.1.  End-customer with a single upstream transit provider offering
        DDoS mitigation services

   In this scenario, an enterprise network with self-hosted Internet-
   facing properties such as Web servers, authoritative DNS servers, and
   VoIP PBXes has an intelligent DDoS mitigation system (IDMS) deployed
   to protect those servers and applications from DDoS attacks.  In
   addition to their on-premise DDoS defense capability, they have
   contracted with their Internet transit provider for DDoS mitigation
   services which threaten to overwhelm their transit link bandwidth.

   The IDMS is configured such that if the incoming Internet traffic
   volume exceeds 50% of the provisioned upstream Internet transit link
   capacity, the IDMS will request DDoS mitigation assistance from the
   upstream transit provider.

   The requests to trigger, manage, and finalize a DDoS mitigation
   between the enterprise IDMS and the transit provider is performed
   using DOTS.  The enterprise IDMS implements a DOTS client while the
   transit provider implements a DOTS server which is integrated with
   their DDoS mitigation orchestration system.

   When the IDMS detects an inbound DDoS attack targeting the enterprise
   servers and applications, it immediately begins mitigating the
   attack.

   During the course of the attack, the inbound traffic volume exceeds
   the 50% threshold; the IDMS DOTS client signals the DOTS server on
   the upstream transit provider network to initiate DDoS mitigation.
   The DOTS server signals the DOTS client that it can service this
   request, and mitigation is initiated on the transit provider network.

   Over the course of the attack, the DOTS server on the transit
   provider network periodically signals the DOTS client on the
   enterprise IDMS in order to provide mitigation status information,
   statistics related to DDoS attack traffic mitigation, and related
   information.  Once the DDoS attack has ended, the DOTS server signals
   the enterprise IDMS DOTS client that the attack has subsided.

   The enterprise IDMS then requests that DDoS mitigation services on
   the upstream transit provider network be terminated.  The DOTS server
   on the transit provider network receives this request, communicates
   with the transit provider orchestration system controlling its DDoS
   mitigation system to terminate attack mitigation, and once the
   mitigation has ended, confirms the end of upstream DDoS mitigation
   service to the enterprise IDMS DOTS client.

Dobbins, et al.          Expires January 4, 2018                [Page 5]
Internet-Draft               DOTS Use Cases                    July 2017

   Note that communications between the enterprise DOTS client and the
   upstream transit provider DOTS server may take place in-band within
   the main Internet transit link between the enterprise and the transit
   provider; out-of-band via a separate, dedicated wireline network link
   utilized solely for DOTS signaling; or out-of-band via some other
   form of network connectivity such as a third-party wireless 4G
   network link.

3.1.2.  End-customer with multiple upstream transit providers offering
        DDoS mitigation services

   This scenario shares many characteristics with the above, but with
   the key difference that the enterprise in question is multi-homed,
   i.e., has two or more upstream transit providers, and that they all
   provide DDoS mitigation services.

   In most cases, the communications model for a multi-homed model would
   be the same as in the single-homed model, merely duplicated in
   parallel.  However, if two or more of the upstream transit providers
   have entered into a mutual DDoS mitigation agreement and have
   established DOTS peering between the participants, DDoS mitigation
   status messages may exchanged between the DOTS servers of the
   participants in order to provide a more complete picture of the DDoS
   attack scope, and allow for either automated or operator-assisted
   programmatic cooperative DDoS mitigation activities on the part of
   the transit providers.

3.1.3.  End-customer with multiple upstream transit providers, but only
        a single upstream transit provider offering DDoS mitigation
        services

   This scenario is similar to the multi-homed scenario referenced
   above; however, only one of the upstream transit providers in
   question offers DDoS mitigation services.  In this situation, the
   enterprise would cease advertising the relevant network prefixes via
   the transit providers which do not provide DDoS mitigation services -
   or, in the case where the enterprise does not control its own
   routing, request that the upstream transit providers which do not
   offer DDoS mitigation services stop advertising the relevant network
   prefixes on their behalf.

   Once it has been determined that the DDoS attack has ceased, the
   enterprise once again announces the relevant routes to the upstream
   transit providers which do not offer DDoS mitigation services, or
   requests that they resume announcing the relevant routes on behalf of
   the enterprise.

Dobbins, et al.          Expires January 4, 2018                [Page 6]
Internet-Draft               DOTS Use Cases                    July 2017

   Note that falling back to a single transit provider has the effect of
   reducing available inbound transit bandwidth during a DDoS attack.
   Without proper planning and sufficient provisioning of both the link
   capacity and DDoS mitigation capacity of the sole transit provider
   offering DDoS mitigation services, this reduction of available
   bandwidth could lead to network link congestion caused by legitimate
   inbound network traffic.  Therefore, careful planning and
   provisioning of both upstream transit bandwidth as well as DDoS
   mitigation capacity is required in scenarios of this nature.

   The withdrawal and announcement of routing prefixes described in this
   use-case falls outside the scope of DOTS, although they could
   conceivably be triggered as a result of provider-specific
   orchestration triggered by the receipt of specific DOTS messages from
   the enterprise in question.

3.1.4.  End-customer with an overlay DDoS mitigation managed security
        service provider (MSSP)

   This use case details an enterprise that has a local DDoS detection
   and classification capability and may or may not have an on-premise
   mitigation capability.  The enterprise is contracted with an overlay
   DDoS mitigation MSSP, topologically distant from the enterprise
   network (i.e., not a direct upstream transit provider), which can
   redirect (divert) traffic away from the enterprise, provide DDoS
   mitigation services services, and then forward (re-inject) legitimate
   traffic to the enterprise on an on-demand basis.  In this scenario,
   diversion of Internet traffic destined for the enterprise network
   into the overlay DDoS mitigation MSSP network is typically
   accomplished via eBGP announcements of the relevant enterprise
   network CIDR blocks, or via authoritative DNS subdomain-based
   mechanisms (other mechanisms are not precluded, these are merely the
   most common ones in use today).

   The enterprise determines thresholds at which a request for
   mitigation is triggered indicating to the MSSP that inbound network
   traffic should be diverted into the MSSP network and that DDoS
   mitigation should be initiated.  The enterprise may also elect to
   manually request diversion and mitigation via the MSSP network as
   desired.

   The communications required to initiate, manage, and terminate active
   DDoS mitigation by the MSSP is performed using DOTS.  The enterprise
   DDoS detection/classification system implements a DOTS client, while
   the MSSP implements a DOTS server integrated with its DDoS mitigation
   orchestration system.  One or more out-of-band methods for initiating
   a mitigation request, such as a Web portal, a smartphone app, or
   voice support hotline, may also be made available by the MSSP.

Dobbins, et al.          Expires January 4, 2018                [Page 7]
Internet-Draft               DOTS Use Cases                    July 2017

   When an attack is detected, an automated or manual DOTS mitigation
   request is be generated by the enterprise and sent to the MSSP.  The
   enterprise DOTS mitigation request is processed by the MSSP DOTS
   server, which validates the origin of the request and passes it to
   the MSSP DDoS mitigation orchestration system, which then initiates
   active DDoS mitigation.  This action will usually involve the
   diversion of all network traffic destined for the targeted enterprise
   into the MSSP DDoS mitigation network, where it will be subjected to
   further scrutiny, with DDoS attack traffic filtered by the MSSP.
   Successful mitigation of the DDoS attack will not only result
   preserving the availability of services and applications resident on
   the enterprise network, but will also prevent DDoS attack traffic
   from ingressing the networks of the enterprise upstream transit
   providers/peers.

   The MSSP should signal via DOTS to the enterprise that a mitigation
   request has been received and acted upon, and should also include an
   update of the mitigation status.  The MSSP may respond periodically
   with additional updates on the mitigation status to in order to
   enable the enterprise to make an informed decision on whether to
   maintain or terminate the mitigation.  An alternative approach would
   be for the DOTS client mitigation request to include a time to live
   (TTL) for the mitigation, which may also be extended by the client
   should the attack still be ongoing as the TTL reaches expiration.

   A variation of this use case may be that the enterprise is providing
   a DDoS monitoring and analysis service to customers whose networks
   may be protected by any one of a number of third-party providers.
   The enterprise in question may integrate with these third-party
   providers using DOTS and signal accordingly when a customer is
   attacked - the MSSP may then manage the life-cycle of the attack
   mitigation on behalf of the enterprise.

3.1.5.  End-customer operating an application or service with an
        integrated DOTS client

   In this scenario, a Web server has a built-in mechanism to detect and
   classify DDoS attacks, which also incorporates a DOTS client.  When
   an attack is detected, the self-defense mechanism is activated, and
   local DDoS mitigation is initiated.

   The DOTS client built into the Web server has been configured to
   request DDoS mitigation services from an upstream transit provider or
   overlay MSSP once specific attack traffic thresholds have been
   reached, or certain network traffic conditions prevail.  Once the
   specified conditions have been met, the DOTS communications dialogue
   and subsequent DDoS mitigation initiation and termination actions
   described above take place.

Dobbins, et al.          Expires January 4, 2018                [Page 8]
Internet-Draft               DOTS Use Cases                    July 2017

3.1.6.  End-customer operating a CPE network infrastructure device with
        an integrated DOTS client

   Similar to the above use-case featuring applications or services with
   built-in DDoS attack detection/classification and DOTS client
   capabilities, in this scenario, an end-customer network
   infrastructure CPE device such as a router, layer-3 switch, firewall,
   or load-balance incorporates both the functionality required to
   detect and classify incoming DDoS attacks as well as DOTS client
   functionality.

   The subsequent DOTS communications dialogue and resultant DDoS
   mitigation initiation and termination activities take place in the
   same manner as the use-cases described above.

3.1.7.  End-customer with an out-of-band smartphone application
        featuring DOTS client capabilities

   This scenario would typically apply in a small office/home office
   (SOHO) setting, where the end-customer does not have CPE equipment or
   software capable of detecting/classifying/mitigating DDoS attack, yet
   still has a requirement for on-demand DDoS mitigation services.  A
   smartphone application containing a DOTS client would be provided by
   the upstream transit mitigation provider or overlay DDoS MSSP to the
   SOHO end-customer; this application would allow a manual 'panic-
   button' to request the initiation and termination of DDoS mitigation
   services.

   The DOTS communications dialogue and resultant DDoS mitigation
   initiation/status reporting/termination actions would then take place
   as in the other use-cases described above, with the end-customer DOTS
   client serving to display received status information while DDoS
   mitigation activities are taking place.

3.1.8.  MSSP as an end-customer requesting overflow DDoS mitigation
        assistance from other MSSPs

   This is a more complex use-case involving multiple DDoS MSSPs,
   whether transit operators, overlay MSSPs, or both.  In this scenario,
   an MSSP has entered into a pre-arranged DDoS mitigation assistance
   agreement with one or more other DDoS MSSPs in order to ensure that
   sufficient DDoS mitigation capacity and/or capabilities may be
   activated in the event that a given DDoS attack threatens to
   overwhelm the ability of a given DDoS MSSP to mitigate the attack on
   its own.

   BGP-based diversion (including relevant Letters of Authorization, or
   LoAs), DNS-based diversion (including relevant LoAs), traffic re-

Dobbins, et al.          Expires January 4, 2018                [Page 9]
Internet-Draft               DOTS Use Cases                    July 2017

   injection mechanisms such as Generic Routing Encapsulation (GRE)
   tunnels, provisioning of DDoS orchestration systems, et. al. must be
   arranged in advance between the DDoS MSSPs which are parties to the
   agreement.  They should also be tested on a regular basis.

   When a DDoS MSSP which is party to the agreement is nearing its
   capacity or ability to mitigate a given DDoS attack traffic, the DOTS
   client integrated with the MSSP DDoS mitigation orchestration system
   signals partner MSSPs to initiate network traffic diversion and DDoS
   mitigation activities.  Ongoing attack and mitigation status messages
   may be passed between the DDoS MSSPs, and between the requesting MSSP
   and the ultimate end-customer of the attack.

   The DOTS dialogues and resultant DDoS mitigation-related activities
   in this scenario progress as described in the other use-cases
   detailed above.  Once the requesting DDoS MSSP is confident that the
   DDoS attack has either ceased or has fallen to levels of traffic/
   complexity which they can handle on their own, the requesting DDoS
   MSSP DOTS client sends mitigation termination requests to the
   participating overflow DDoS MSSPs.

3.2.  Intra-domain Use Cases

3.2.1.  Suppression of outbound DDoS traffic originating from a consumer
        broadband access network

   While most DDoS defenses concentrate on inbound DDoS attacks
   ingressing from direct peering links or upstream transit providers,
   the DDoS attack traffic in question originates from one or more
   Internet-connected networks.  In some cases, compromised devices
   residing on the local networks of broadband access customers are used
   to directly generate this DDoS attack traffic; in others,
   misconfigured devices residing on said local customer networks are
   exploited by attackers to launch reflection/amplification DDoS
   attacks.  In either scenario, the outbound DDoS traffic emanating
   from these devices can be just as disruptive as an inbound DDoS
   attack, and can cause disruption for substantial proportions of the
   broadband access network operator's customer base.

   Some broadband access network operators provide CPE devices (DSL
   modems/routers, cablemodems, FTTH routers, etc.) to their end-
   customers.  Others allow end-customers to provide their own CPE
   devices.  Many will either provide CPE devices or allow end-customers
   to supply their own.

   Broadband access network operators typically have mechanisms to
   detect and classify both inbound and outbound DDoS attacks, utilizing
   flow telemetry exported from their peering/transit and customer

Dobbins, et al.          Expires January 4, 2018               [Page 10]
Internet-Draft               DOTS Use Cases                    July 2017

   aggregation routers.  In the event of an outbound DDoS attack, they
   may make use of internally-developed systems which leverage their
   subscriber-management systems to de-provision end-customers who are
   sourcing outbound DDoS traffic; in some cases, they may have
   implemented quarantine systems to block all outbound traffic sourced
   from the offending end-customers.  In either case, the perceived
   disruption of the end-customer's Internet access often prompts a
   help-desk call, which erodes the margins of the broadband access
   provider and can cause end-customer dissatisfaction.

   Increasingly, CPE devices themselves are targeted by attackers who
   exploit security flaws in these devices in order to compromise them
   and subsume them into botnets, and then leverage them to launch
   outbound DDoS attacks.  In all of the described scenarios, the end-
   customers are unaware that their computers and/or CPE devices have
   been compromised and are being used to launch outbound DDoS attacks -
   however, they may notice a degradation of their Internet connectivity
   as a result of outbound bandwidth consumption or other disruption.

   By deploying DOTS-enabled telemetry systems and CPE devices (and
   possibly requiring DOTS functionality in customer-provided CPE
   devices), broadband access providers can utilize a standards-based
   mechanism to suppress outbound DDoS attack traffic while optionally
   allowing legitimate end-customer traffic to proceed unmolested.

   In order to achieve this capability, the telemetry analysis system
   utilized by the broadband access provider must have DOTS client
   functionality, and the end-customer CPE devices must have DOTS server
   functionality.  When the telemetry analysis system detects and
   classifies an outbound DDoS attack sourced from one or more end-
   customer networks/devices, the DOTS client of the telemetry analysis
   system sends a DOTS request to the DOTS server implemented on the CPE
   devices, requesting local mitigation assistance in suppressing either
   the identified outbound DDoS traffic, or all outbound traffic sourced
   from the end-customer networks/devices.  The DOTS server residing
   within the CPE device(s) would then perform predefined actions such
   as implementing on-board access-control lists (ACLs) to suppress the
   outbound traffic in question and prevent it from leaving the local
   end-customer network(s).

   Broadband access network operators may choose to implement a
   quarantine of all or selected network traffic originating from end-
   customer networks/devices which are sourcing outbound DDoS traffic,
   redirecting traffic from interactive applications such as Web
   browsers to an internal portal which informs the end-customer of the
   quarantine action, and providing instructions for self-remediation
   and/or helpdesk contact information.

Dobbins, et al.          Expires January 4, 2018               [Page 11]
Internet-Draft               DOTS Use Cases                    July 2017

   Quarantine systems for broadband access networks are typically
   custom-developed and -maintained, and are generally deployed only by
   a relatively small number of broadband access providers with
   considerable internal software development and support capabilities.
   By requiring the manufacturers of operator-supplied CPE devices to
   implement DOTS server functionality, and requiring customer-provided
   CPE devices to feature DOTS server functionality, broadband access
   network operators who previously could not afford the development
   expense of creating custom quarantine systems to integrate DOTS-
   enabled network telemetry systems to act as DOTS clients and perform
   effective quarantine of end-customer networks and devices until such
   time as they have been remediated.

3.2.2.  DDoS Orchestration

   In this use case, one or multiple telemetry systems or monitoring
   devices like a flow collector monitor a network -- typically an ISP
   network.  Upon detection of a DDoS attack, these telemetry systems
   alert an orchestrator in charge of coordinating the various DDoS
   mitigation systems within the domain.  The telemetry systems may be
   configured to provide some necessary or useful pieces of
   informations, such as a preliminary analysis of the observation to
   the orchestrator.

   The orchestrator analyses the various information it receives from
   specialized equipements, and elaborates one or multiple DDoS
   mitigation strategies.  In some case, a manual confirmation may also
   be required to chose a proposed strategy or to start the DDoS
   mitigation.  The DDoS mitigation may consists in multiple steps such
   as configuring the network, the various hardware or already
   instantiated DDoS mitigation functions.  In some cases, some specific
   virtual DDoS mitigation functions need to be instantiated and
   properly chained between each other.  Eventually, the coordination of
   the mitigation may involved external DDoS resources such as a transit
   provider (Section 3.1.1) or an MSSP (Section 3.1.4).

   The communication to trigger a DDoS mitigation between the telemetry
   and monitoring systems and the orchestrator is performed using DOTS.
   The telemetry systems implements a DOTS client while the Orchestrator
   implements a DOTS server.

   The communication between to select a DDoS strategy by a network
   administrator and the orchestrator is also performed using DOTS.  The
   network administrator via its web interfaces implements a DOTS client
   while the Orchestrator implements a DOTS server.

Dobbins, et al.          Expires January 4, 2018               [Page 12]
Internet-Draft               DOTS Use Cases                    July 2017

   The communication between the Orchestrator and the DDoS mitigation
   systems is performed using DOTS.  The Orchestrator implements a DOTS
   client while the DDoS mitigation systems implement a DOTS server.

   The configuration aspects of each DDoS mitigation systems, as well as
   the instantiations of DDoS mitigation functions or network
   configuration is not part of DOTS.  Similarly the discovery of the
   available DDoS mitigation functions is not part of DOTS.

              +----------+
              | network  |C
              | adminis  |<-+
              | trator   |  |
              +----------+  |
                            |                       (internal)
              +----------+  | S+--------------+     +-----------+
              |telemetry/|  +->|              |C   S| DDoS      |+
              |monitoring|<--->| Orchestrator |<--->| mitigation||
              |systems   |C   S|              |<-+  | systems   ||
              +----------+     +--------------+C |  +-----------+|
                                                 |    +----------+
                                                 |
                                                 |  (external)
                                                 |  +-----------+
                                                 | S| DDoS      |
                                                 +->| mitigation|
                                                    | systems   |
                                                    +-----------+
              * C is for DOTS client functionality
              * S is for DOTS server functionality

      Figure 1: DDoS Orchestration

   The telemetry systems monitor various traffic network and perform
   their measurement tasks.  They are configured so that when an event
   or some measurements reach a predefined level to report a DOTS
   mitigation request to the Orchestrator.  The DOTS mitigation request
   may be associated with some element such as specific reporting.

   Upon receipt of the DOTS mitigation request from the telemetry
   system, the orchestrator responds with an acknowledgement, to avoid
   retransmission of the request for mitigation.  The status of the DDoS
   mitigation indicates the orchestrator is in an analysing phase.  The
   orchestrator begins collecting various informations from various
   telemetry systems on the network in order to correlate the
   measurements and provide an analyse of the event.  Eventually, the

Dobbins, et al.          Expires January 4, 2018               [Page 13]
Internet-Draft               DOTS Use Cases                    July 2017

   orchestrator may ask additional informations to the telemetry system
   that just sent the DOTS request, however, the collection of these
   information is performed outside DOTS.

   The orchestrator may be configured to start a DDoS mitigation upon
   approval from a network administrator.  The analysis from the
   orchestrator is reported to the network administrator via a web
   interface.  If the network administrator decides to start the
   mitigation, she order through her web interface a DOTS client to send
   a request for DDoS mitigation.  This request is expected to be
   associated with a context that identifies the DDoS mitigation
   selected.

   Upon receiving the DOTS request for DDoS mitigation from the network
   administrator, the orchestrator orchestrates the DDoS mitigation
   according to the specified strategy.  It status first indicates the
   DDoS mitigation is starting while not effective.

   Orchestration of the DDoS mitigation systems works similarly as
   described in Section 3.1.1 or Section 3.1.4.  The orchestrator
   indicates with its status the DDoS Mitigation is effective.

   When the DDoS mitigation is finished on the DDoS mitigation systems,
   the orchestrator indicates to the Telemetry systems as well as to the
   network administrator the DDoS mitigation is finished.

4.  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].

5.  IANA Considerations

   No IANA considerations exist for this document at this time.

Dobbins, et al.          Expires January 4, 2018               [Page 14]
Internet-Draft               DOTS Use Cases                    July 2017

6.  Acknowledgments

   TBD

7.  References

7.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>.

7.2.  Informative References

   [APACHE]   "Apache mod_security", n.d.,
              <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-05 (work in
              progress), June 2017.

   [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>.

   [RFC7368]  Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
              Weil, "IPv6 Home Networking Architecture Principles",
              RFC 7368, DOI 10.17487/RFC7368, October 2014,
              <http://www.rfc-editor.org/info/rfc7368>.

   [RRL]      "BIND RRL", August 2014,
              <https://deepthought.isc.org/article/AA-00994/0/Using-the-
              Response-Rate-Limiting-Feature-in-BIND-9.10.html>.

Authors' Addresses

   Roland Dobbins
   Arbor Networks
   Singapore

   EMail: rdobbins@arbor.net

Dobbins, et al.          Expires January 4, 2018               [Page 15]
Internet-Draft               DOTS Use Cases                    July 2017

   Daniel Migault
   Ericsson
   8400 boulevard Decarie
   Montreal, QC  H4P 2N2
   Canada

   EMail: daniel.migault@ericsson.com

   Stefan Fouant
   USA

   EMail: stefan.fouant@copperriverit.com

   Robert Moskowitz
   HTT Consulting
   Oak Park, MI  48237
   USA

   EMail: rgm@labs.htt-consult.com

   Nik Teague
   Verisign
   12061 Bluemont Way
   Reston, VA  20190

   EMail: nteague@verisign.com

   Liang Xia
   Huawei
   No. 101, Software Avenue, Yuhuatai District
   Nanjing
   China

   EMail: Frank.xialiang@huawei.com

   Kaname Nishizuka
   NTT Communications
   GranPark 16F 3-4-1 Shibaura, Minato-ku
   Tokyo  108-8118
   Japan

   EMail: kaname@nttv6.jp

Dobbins, et al.          Expires January 4, 2018               [Page 16]