[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-mglt-dots-use-cases) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20

DOTS WG                                                  R. Dobbins, Ed.
Internet-Draft                                            Arbor Networks
Intended status: Informational                                 S. Fouant
Expires: April 21, 2016                          Corero Network Security
                                                              D. Migault
                                                                Ericsson
                                                            R. Moskowitz
                                                          HTT Consulting
                                                               N. Teague
                                                            Verisign Inc
                                                                  L. Xia
                                                                  Huawei
                                                        October 19, 2015


                Use cases for DDoS Open Threat Signaling
                    draft-ietf-dots-use-cases-00.txt

Abstract

   This document delineates principal and ancillary use cases for DDoS
   Open Threat Signaling (DOTS), a communications protocol intended to
   facilitate the programmatic, coordinated mitigation of Distributed
   Denial of Service (DDoS) attacks via a standards-based mechanism.
   DOTS is purposely designed to support requests for DDoS mitigation
   services and status updates across inter-organizational
   administrative boundaries.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 21, 2016.







Dobbins, et al.          Expires April 21, 2016                 [Page 1]


Internet-Draft               DOTS Use cases                 October 2015


Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology and Acronyms  . . . . . . . . . . . . . . . . . .   4
   4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Primary Use Cases . . . . . . . . . . . . . . . . . . . .   5
       4.1.1.  Successful Automatic or Operator-Assisted CPE or PE
               Mitigators Request Upstream DDoS Mitigation Services    5
       4.1.2.  Successful Automatic or Operator-Assisted CPE or PE
               Network Infrastructure Element Request to Upstream
               Mitigator . . . . . . . . . . . . . . . . . . . . . .   7
       4.1.3.  Successful Automatic or Operator-Assisted CPE or PE
               Attack Telemetry Detection/Classification System
               Request to Upstream Mitigator . . . . . . . . . . . .   9
       4.1.4.  Successful Automatic or Operator-Assisted Targeted
               Service/Application Request to Upstream Mitigator . .  12
       4.1.5.  Successful Manual Web Portal Request to Upstream
               Mitigator . . . . . . . . . . . . . . . . . . . . . .  14
       4.1.6.  Successful Manual Mobile Device Application Request
               to Upstream Mitigator . . . . . . . . . . . . . . . .  16
       4.1.7.  Unsuccessful Automatic or Operator-Assisted CPE or PE
               Mitigators Request Upstream DDoS Mitigation Services   18
     4.2.  Ancillary Use Cases . . . . . . . . . . . . . . . . . . .  19
       4.2.1.  Auto-registration of DOTS clients with DOTS servers .  19
       4.2.2.  Auto-provisioning of DDoS countermeasures . . . . . .  20
       4.2.3.  Informational DDoS attack notification to interested
               and authorized third parties  . . . . . . . . . . . .  20
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  21



Dobbins, et al.          Expires April 21, 2016                 [Page 2]


Internet-Draft               DOTS Use cases                 October 2015


     8.2.  Informative References  . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   Currently, distributed denial-of-service (DDoS) attack mitigation
   solutions/services are largely based upon siloed, proprietary
   communications paradigms which result in vendor/service lock-in, and
   as a side-effect make the configuration, provisioning, operation, and
   activation of these solutions a highly manual and often time-
   consuming process.  Additionally, coordination of multiple DDoS
   mitigation solutions/services simultaneously engaged in defending the
   same organization against DDoS attacks is fraught with both technical
   and process-related hurdles which greatly increase operational
   complexity and often result in suboptimal DDoS attack mitigation
   efficacy.

   The DDoS Open Threat Signaling (DOTS) effort is intended to
   facilitate interoperability between DDoS solutions/services by
   providing a standards-based, programmatic communications mechanism
   for the invitation and termination of heterogeneous DDoS attack
   mitigation systems and services.  This allows for a much higher
   degree of automation and concomitant efficacy and rapidity of DDoS
   attack mitigation involving multiple DDoS mitigation systems and
   services than is currently the norm, as well as providing additional
   benefits such as automatic DDoS mitigation service registration and
   provisioning.

   This document provides an overview of common DDoS mitigation system/
   service deployment and operational models which are in use today, but
   which are currently limited in scope to a single vendor and/or
   service provider and are often highly manual in nature, which can
   lead to miscommunications, misconfigurations, and delays in bringing
   mitigation services to bear against an attack.  The introduction of
   DOTS into these scenarios will reduce reaction times and the risks
   associated with manual processes, simplify the use of multiple types
   of DDoS mitigation systems and services as required, and make
   practical the simultaneous use multiple DDoS mitigation systems and
   services as circumstances warrant.






Dobbins, et al.          Expires April 21, 2016                 [Page 3]


Internet-Draft               DOTS Use cases                 October 2015


3.  Terminology and Acronyms

   This document makes use of the same terminology and definitions as
   [I-D.draft-ietf-dots-requirements], except where noted below:

   - DDoS:   A distributed denial-of-service attack.  DDoS attacks are
         intended to cause a negative impact on the availability of
         servers, services, applications, and/or other functionality of
         an attack target.

   - Attack target:   The intended target of a DDoS attack.

   - Attack telemetry:   Collected network traffic characteristics
         enabling the detection, classification, and in many cases
         traceback of a DDoS attack.

   - Mitigation:   A defensive response against a detected DDoS attack,
         performed by an entity in the network path between attack
         sources and the attack target, either through inline deployment
         or some form of traffic diversion, consisting of one or more
         countermeasures.  The form a given mitigation takes is out of
         scope for this document.

   - Countermeasure:   An action or set of actions taken by a mitigator
         to evaluate and filter out a significant proportion of DDoS
         attack traffic while forwarding onwards a significant
         proportion of legitimate traffic directed towards an attack
         target.

4.  Use Cases

   This section provides a high-level overview of likely use cases and
   deployment scenarios for DOTS-enabled DDoS mitigation services.  It
   should be noted that DOTS servers may be standalone entities which,
   upon receiving a DOTS mitigation service request from a DOTS client,
   then initiate DDoS mitigation service by communicating directly or
   indirectly with DDoS mitigators, and likewise terminate the service
   upon receipt of a DOTS service termination request; conversely, the
   DDoS mitigators themselves may incorporate DOTS servers and/or DOTS
   clients.  The mechanisms by which DOTS servers initiate and terminate
   DDoS mitigation service with DDoS mitigators is beyond the scope of
   this document.

   All of the primary use cases described in this section are derived
   from current, real-world DDoS mitigation functionality, capabilities,
   and operational models which have been implemented in a largely
   proprietary manner by various DDoS mitigation solution vendor and/or
   service providers, resulting in vendor/service lock-in and mutually



Dobbins, et al.          Expires April 21, 2016                 [Page 4]


Internet-Draft               DOTS Use cases                 October 2015


   incompatible solutions/services.  The overarching goal of the DOTS
   effort is to provide a standards-based mechanism to allow
   heterogeneous DDoS mitigation solutions and services to be woven
   together in order to allow broader, more pervasive adoption of
   coordinated DDoS defense.

   The posited ancillary use cases described in this section are
   reasonable and highly desirable extrapolations of the functionality
   of baseline DOTS capabilities, and are readily attainable in the near
   term.

   Another important goal of DOTS is interoperability and coordination
   via a common standards-based mechanism between multiple DDoS
   mitigation service providers contemporaneously engaged in defending
   the same organization against DDoS attacks.  Each of the primary and
   ancillary use cases described in this section may be read as
   involving one or more DDoS mitigation service providers; DOTS makes
   multi-provider coordinated DDoS defenses much more effective and
   practical due to abstraction of the particulars of a given DDoS
   mitigation service/solution set.

   Both the primary and ancillary use cases may be facilitated by direct
   DOTS client - DOTS server communications or via DOTS relays deployed
   in order to aggregate DOTS mitigation service requests/responses, to
   mediate between stateless and stateful underlying transport
   protocols, to aggregate multiple DOTS requests and/or responses, to
   filter DOTS requests and/or responses via configured policy
   mechanisms, or some combination of these functions.

   These use cases requirements are intended to inform the DOTS
   requirements described in [I-D.draft-ietf-dots-requirements].

4.1.  Primary Use Cases

4.1.1.  Successful Automatic or Operator-Assisted CPE or PE Mitigators
        Request Upstream DDoS Mitigation Services

   In this scenario, one or more CPE or PE mitigators with DOTS client
   capabilities may be configured to signal to one or more DOTS servers
   in order to request upstream DDoS mitigation service initiation
   during an attack when DDoS attack volumes and/or attack
   characteristics exceed the capabilities of such CPE mitigators.  DDoS
   mitigation service may be terminated either automatically or manually
   via a DOTS mitigation service termination request initiated by the
   mitigator when it has been determined that the DDoS attack has ended.

   All DOTS messages exchanged between the DOTS clients and DOTS servers
   in this use case may be communicated directly between the DOTS



Dobbins, et al.          Expires April 21, 2016                 [Page 5]


Internet-Draft               DOTS Use cases                 October 2015


   clients and servers, or mediated by one or more DOTS relays residing
   on the network of the originating network, the network where upstream
   DDoS mitigation service takes place, an intervening network or
   networks, or some combination of the above.

   (a)  A DDoS attack is initiated against online properties of an
        organization which has deployed DOTS-client-capable DDoS
        mitigators.

   (b)  CPE or PE DDoS mitigators detect, classify, and begin mitigating
        the DDoS attack.

   (c)  CPE or PE DDoS mitigators determine that their capacity and/or
        capability to mitigate the DDoS attack is insufficient, and
        utilize their DOTS client functionality to send a DOTS
        mitigation service initiation request to one or more DOTS
        servers residing on one or more upstream transit networks, peer
        networks, or overlay MSSP networks.  The scope, format, and
        content of these messages must be codified by the DOTS WG.  This
        DOTS mitigation service initiation request may be automatically
        initiated by the CPE or PE DDoS mitigators, or may be manually
        triggered by personnel of the requesting organization in
        response to an alert from the mitigators (the mechanism by which
        this process takes place is beyond the scope of this document).

   (d)  The DOTS servers which receive the DOTS mitigation service
        initiation requests determine that they have been to honor
        requests from the requesting CPE or PE mitigators, and initiate
        situationally-appropriate DDoS mitigation service on their
        respective networks (the mechanism by which this process takes
        place is beyond the scope of this document).

   (e)  The DOTS servers transmit a DOTS service status message to the
        requesting CPE or PE mitigators indicating that upstream DDoS
        mitigation service has been initiated.

   (f)  While DDoS mitigation services are active, the DOTS servers
        regularly transmit DOTS mitigation status updates to the
        requesting CPE or PE mitigators.  The scope, format, and content
        of these messages must be codified by the DOTS WG.

   (g)  While DDoS mitigation services are active, the CPE or PE
        mitigators may optionally regularly transmit DOTS mitigation
        efficacy updates to the relevant DOTS servers.  The scope,
        format, and content of these messages must be codified by the
        DOTS WG.





Dobbins, et al.          Expires April 21, 2016                 [Page 6]


Internet-Draft               DOTS Use cases                 October 2015


   (h)  When the upstream DDoS mitigators determine that the DDoS attack
        has ceased, they indicate this change in status to their
        respective DOTS servers (the mechanism by which this process
        takes place is beyond the scope of this document).

   (i)  The DOTS servers transmit a DOTS mitigation status update to the
        CPE or PE mitigators indicating that the DDoS attack has ceased.
        The scope, format, and content of these messages must be
        codified by the DOTS WG.

   (j)  The CPE or PE DDoS mitigators transmit a DOTS mitigation service
        termination request to the DOTS servers.  [The scope, format,
        and content of these messages must be codified by the DOTS WG.]
        This DOTS mitigation service termination request may be
        automatically initiated by the CPE or PE DDoS mitigators, or may
        be manually triggered by personnel of the requesting
        organization in response to an alert from the mitigators or a
        management system which monitors them (the mechanism by which
        this process takes place is beyond the scope of this document).

   (k)  The DOTS servers terminate DDoS mitigation service on their
        respective networks (the mechanism by which this process takes
        place is beyond the scope of this document).

   (l)  The DOTS servers transmit a DOTS mitigation status update to the
        CPE or PE mitigators indicating that DDoS mitigation services
        have been terminated.  The scope, format, and content of these
        messages must be codified by the DOTS WG.

   (m)  The CPE or PE DDoS mitigators transmit a DOTS mitigation
        termination status acknowledgement to the DOTS servers.  [The
        scope, format, and content of these messages must be codified by
        the DOTS WG.]

4.1.2.  Successful Automatic or Operator-Assisted CPE or PE Network
        Infrastructure Element Request to Upstream Mitigator

   In this scenario, CPE or PE network infrastructure elements such as
   routers, switches, load-balancers, firewalls, 'IPSes', etc. which
   have the capability to detect and classify DDoS attacks and which
   have DOTS client capabilities may be configured to signal to one or
   more DOTS servers in order to request upstream DDoS mitigation
   service initiation during an attack.  DDoS mitigation service may be
   terminated either automatically or manually via a DOTS mitigation
   service termination request initiated by the network element when it
   has been determined that the DDoS attack has ended.





Dobbins, et al.          Expires April 21, 2016                 [Page 7]


Internet-Draft               DOTS Use cases                 October 2015


   All DOTS messages exchanged between the DOTS clients and DOTS servers
   in this use case may be communicated directly between the DOTS
   clients and servers, or mediated by one or more DOTS relays residing
   on the network of the originating network, the network where upstream
   DDoS mitigation service takes place, an intervening network or
   networks, or some combination of the above.

   (a)  A DDoS attack is initiated against online properties of an
        organization with DOTS-client-capable network infrastructure
        elements deployed.

   (b)  The network infrastructure elements utilize their DOTS client
        functionality to send a DOTS mitigation service initiation
        request to one or more DOTS servers residing on one or more
        upstream transit networks, peer networks, or overlay MSSP
        networks, either directly or via intermediate DOTS relays
        residing upon the requesting organization's network, the
        upstream mitigation provider's network, or both.  The scope,
        format, and content of these messages must be codified by the
        DOTS WG.  This DOTS mitigation service initiation request may be
        automatically initiated by the network infrastructure elements,
        or may be manually triggered by personnel of the requesting
        organization in response to an alert from the network elements
        or a management system which monitors them (the mechanism by
        which this process takes place is beyond the scope of this
        document).

   (c)  The DOTS servers which receive the DOTS mitigation service
        initiation requests determine that they have been to honor
        requests from the requesting network infrastructure elements,
        and initiate situationally-appropriate DDoS mitigation service
        on their respective networks (the mechanism by which this
        process takes place is beyond the scope of this document).

   (d)  The DOTS servers transmit a DOTS service status message to the
        requesting network infrastructure elements indicating that
        upstream DDoS mitigation service has been initiated.  The scope,
        format, and content of these messages must be codified by the
        DOTS WG.

   (e)  While DDoS mitigation services are active, the DOTS servers
        regularly transmit DOTS mitigation status updates to the
        requesting requesting network infrastructure elements.  The
        scope, format, and content of these messages must be codified by
        the DOTS WG.

   (f)  While DDoS mitigation services are active, the network
        infrastructure elements may optionally regularly transmit DOTS



Dobbins, et al.          Expires April 21, 2016                 [Page 8]


Internet-Draft               DOTS Use cases                 October 2015


        mitigation efficacy updates to the relevant DOTS servers.  The
        scope, format, and content of these messages must be codified by
        the DOTS WG.

   (g)  When the upstream DDoS mitigators determine that the DDoS attack
        has ceased, they indicate this change in status to their
        respective DOTS servers (the mechanism by which this process
        takes place is beyond the scope of this document).

   (h)  The DOTS servers transmit a DOTS mitigation status update to the
        network infrastructure elements indicating that the DDoS attack
        has ceased.  The scope, format, and content of these messages
        must be codified by the DOTS WG.

   (i)  The network infrastructure elements transmit a DOTS mitigation
        service termination request to the DOTS servers.  The scope,
        format, and content of these messages must be codified by the
        DOTS WG.  This DOTS mitigation service termination request may
        be automatically initiated by the network infrastructure
        elements, or may be manually triggered by personnel of the
        requesting organization in response to an alert from the
        mitigators (the mechanism by which this process takes place is
        beyond the scope of this document).

   (j)  The DOTS servers terminate DDoS mitigation service on their
        respective networks (the mechanism by which this process takes
        place is beyond the scope of this document).

   (k)  The DOTS servers transmit a DOTS mitigation status update to the
        network infrastructure elements indicating that DDoS mitigation
        services have been terminated.  The scope, format, and content
        of these messages must be codified by the DOTS WG.

   (l)  The network infrastructure elements transmit a DOTS mitigation
        termination status acknowledgement to the DOTS servers.  The
        scope, format, and content of these messages must be codified by
        the DOTS WG.

4.1.3.  Successful Automatic or Operator-Assisted CPE or PE Attack
        Telemetry Detection/Classification System Request to Upstream
        Mitigator

   In this scenario, CPE or PE Attack Telemetry Detection/Classification
   Systems which have DOTS client capabilities may be configured so that
   upon detecting and classifying a DDoS attack, they signal one or more
   DOTS servers in order to request upstream DDoS mitigation service
   initiation.  DDoS mitigation service may be terminated either
   automatically or manually via a DOTS mitigation service termination



Dobbins, et al.          Expires April 21, 2016                 [Page 9]


Internet-Draft               DOTS Use cases                 October 2015


   request initiated by the Attack Telemetry Detection/Classification
   System when it has been determined that the DDoS attack has ended.

   All DOTS messages exchanged between the DOTS clients and DOTS servers
   in this use case may be communicated directly between the DOTS
   clients and servers, or mediated by one or more DOTS relays residing
   on the network of the originating network, the network where upstream
   DDoS mitigation service takes place, an intervening network or
   networks, or some combination of the above.

   (a)  A DDoS attack is initiated against online properties of an
        organization with DOTS-client-capable CPE or PE Attack Telemetry
        Detection/Classification Systems deployed.

   (b)  The CPE or PE Attack Telemetry Detection/Classification Systems
        utilize their DOTS client functionality to send a DOTS
        mitigation service initiation request to one or more DOTS
        servers residing on one or more upstream transit networks, peer
        networks, or overlay MSSP networks, either directly or via
        intermediate DOTS relays residing upon the requesting
        organization's network, the upstream mitigation provider's
        network, or both.  [The scope, format, and content of these
        messages must be codified by the DOTS WG.]  This DOTS mitigation
        service initiation request may be automatically initiated by the
        CPE or PE Attack Telemetry Detection/Classification Systems, or
        may be manually triggered by personnel of the requesting
        organization in response to an alert from the CPE or PE Attack
        Telemetry Detection/Classification Systems (the mechanism by
        which this process takes place is beyond the scope of this
        document).

   (c)  The DOTS servers which receive the DOTS mitigation service
        initiation requests determine that they have been to honor
        requests from the requesting CPE or PE Attack Telemetry
        Detection/Classification Systems, and initiate situationally-
        appropriate DDoS mitigation service on their respective networks
        (the mechanism by which this process takes place is beyond the
        scope of this document).

   (d)  The DOTS servers transmit a DOTS service status message to the
        requesting CPE or PE Attack Telemetry Detection/Classification
        Systems indicating that upstream DDoS mitigation service has
        been initiated.  The scope, format, and content of these
        messages must be codified by the DOTS WG.

   (e)  While DDoS mitigation services are active, the DOTS servers
        regularly transmit DOTS mitigation status updates to the
        requesting CPE or PE Attack Telemetry Detection/Classification



Dobbins, et al.          Expires April 21, 2016                [Page 10]


Internet-Draft               DOTS Use cases                 October 2015


        Systems.  The scope, format, and content of these messages must
        be codified by the DOTS WG.

   (f)  While DDoS mitigation services are active, the CPE or PE Attack
        Telemetry Detection/Classification Systems may optionally
        regularly transmit DOTS mitigation efficacy updates to the
        relevant DOTS servers.  The scope, format, and content of these
        messages must be codified by the DOTS WG.

   (g)  When the upstream DDoS mitigators determine that the DDoS attack
        has ceased, they indicate this change in status to their
        respective DOTS servers (the mechanism by which this process
        takes place is beyond the scope of this document).

   (h)  The DOTS servers transmit a DOTS mitigation status update to the
        CPE or PE Attack Telemetry Detection/Classification Systems
        indicating that the DDoS attack has ceased.  The scope, format,
        and content of these messages must be codified by the DOTS WG.

   (i)  The CPE or PE Attack Telemetry Detection/Classification Systems
        transmit a DOTS mitigation service termination request to the
        DOTS servers.  The scope, format, and content of these messages
        must be codified by the DOTS WG.  This DOTS mitigation service
        termination request may be automatically initiated by the CPE or
        PE Attack Telemetry Detection/Classification Systems, or may be
        manually triggered by personnel of the requesting organization
        in response to an alert from the CPE or PE Attack Telemetry
        Detection/Classification Systems (the mechanism by which this
        process takes place is beyond the scope of this document).

   (j)  The DOTS servers terminate DDoS mitigation service on their
        respective networks (the mechanism by which this process takes
        place is beyond the scope of this document).

   (k)  The DOTS servers transmit a DOTS mitigation status update to the
        CPE or PE Attack Telemetry Detection/Classification Systems
        indicating that DDoS mitigation services have been terminated.
        The scope, format, and content of these messages must be
        codified by the DOTS WG.

   (l)  The CPE or PE Attack Telemetry Detection/Classification Systems
        transmit a DOTS mitigation termination status acknowledgement to
        the DOTS servers.  The scope, format, and content of these
        messages must be codified by the DOTS WG.







Dobbins, et al.          Expires April 21, 2016                [Page 11]


Internet-Draft               DOTS Use cases                 October 2015


4.1.4.  Successful Automatic or Operator-Assisted Targeted Service/
        Application Request to Upstream Mitigator

   In this scenario, a service or application which is the target of a
   DDoS attack and which has the capability to detect and classify DDoS
   attacks (i.e, Apache mod_security [APACHE], BIND RRL [RRL], etc.) as
   well as DOTS client functionality may be configured so that upon
   detecting and classifying a DDoS attack, it signals one or more DOTS
   servers in order to request upstream DDoS mitigation service
   initiation.  DDoS mitigation service may be terminated either
   automatically or manually via a DOTS mitigation service termination
   request initiated by the service/application when it has been
   determined that the DDoS attack has ended.

   All DOTS messages exchanged between the DOTS clients and DOTS servers
   in this use case may be communicated directly between the DOTS
   clients and servers, or mediated by one or more DOTS relays residing
   on the network of the originating network, the network where upstream
   DDoS mitigation service takes place, an intervening network or
   networks, or some combination of the above.

   (a)  A DDoS attack is initiated against online properties of an
        organization which include DOTS-client-capable services or
        applications that are the specific target(s) of the attack.

   (b)  The targeted services or applications utilize their DOTS client
        functionality to send a DOTS mitigation service initiation
        request to one or more DOTS servers residing on the same network
        as the services or applications, one or more upstream transit
        networks, peer networks, or overlay MSSP networks, either
        directly or via intermediate DOTS relays residing upon the
        requesting organization's network, the upstream mitigation
        provider's network, or both.  The scope, format, and content of
        these messages must be codified by the DOTS WG.  This DOTS
        mitigation service initiation request may be automatically
        initiated by the targeted services or applications, or may be
        manually triggered by personnel of the requesting organization
        in response to an alert from the targeted services or
        applications or a system which monitors them (the mechanism by
        which this process takes place is beyond the scope of this
        document).

   (c)  The DOTS servers which receive the DOTS mitigation service
        initiation requests determine that they have been provisioned to
        honor requests from the requesting services or applications, and
        initiate situationally-appropriate DDoS mitigation service on
        their respective networks (the mechanism by which this process
        takes place is beyond the scope of this document).



Dobbins, et al.          Expires April 21, 2016                [Page 12]


Internet-Draft               DOTS Use cases                 October 2015


   (d)  The DOTS servers transmit a DOTS service status message to the
        services or applications indicating that upstream DDoS
        mitigation service has been initiated.  [The scope, format, and
        content of these messages must be codified by the DOTS WG.

   (e)  While DDoS mitigation services are active, the DOTS servers
        regularly transmit DOTS mitigation status updates to the
        requesting services or applications.  The scope, format, and
        content of these messages must be codified by the DOTS WG.

   (f)  While DDoS mitigation services are active, the requesting
        services or applications may optionally regularly transmit DOTS
        mitigation efficacy updates to the relevant DOTS servers.  The
        scope, format, and content of these messages must be codified by
        the DOTS WG.

   (g)  When the upstream DDoS mitigators determine that the DDoS attack
        has ceased, they indicate this change in status to their
        respective DOTS servers (the mechanism by which this process
        takes place is beyond the scope of this document).

   (h)  The DOTS servers transmit a DOTS mitigation status update to the
        requesting services or applications indicating that the DDoS
        attack has ceased.  The scope, format, and content of these
        messages must be codified by the DOTS WG.

   (i)  The targeted services or applications transmit a DOTS mitigation
        service termination request to the DOTS servers.  [The scope,
        format, and content of these messages must be codified by the
        DOTS WG.]  This DOTS mitigation service termination request may
        be automatically initiated by the targeted services or
        applications, or may be manually triggered by personnel of the
        requesting organization in response to an alert from a system
        which monitors them (the mechanism by which this process takes
        place is beyond the scope of this document).

   (j)  The DOTS servers terminate DDoS mitigation service on their
        respective networks (the mechanism by which this process takes
        place is beyond the scope of this document).

   (k)  The DOTS servers transmit a DOTS mitigation status update to the
        targeted services or applications indicating that DDoS
        mitigation services have been terminated.  The scope, format,
        and content of these messages must be codified by the DOTS WG.

   (l)  The targeted services or applications transmit a DOTS mitigation
        termination status acknowledgement to the DOTS servers.  The




Dobbins, et al.          Expires April 21, 2016                [Page 13]


Internet-Draft               DOTS Use cases                 October 2015


        scope, format, and content of these messages must be codified by
        the DOTS WG.

4.1.5.  Successful Manual Web Portal Request to Upstream Mitigator

   In this scenario, a Web portal which has DOTS client capabilities has
   been configured in order to allow authorized personnel of
   organizations which are targeted by DDoS attacks to manually request
   upstream DDoS mitigation service initiation from a DOTS server.  When
   an organization has reason to believe that it is under active attack,
   authorized personnel may utilize the Web portal to manually initiate
   a DOTS client mitigation request to one or more DOTS servers.  DDoS
   mitigation service may be terminated manually via a DOTS mitigation
   service termination request through the Web portal when it has been
   determined that the DDoS attack has ended.

   All DOTS messages exchanged between the DOTS client and DOTS servers
   in this use case may be communicated directly between the DOTS client
   and servers, or mediated by one or more DOTS relays residing on the
   network of the originating network, the network where upstream DDoS
   mitigation service takes place, an intervening network or networks,
   or some combination of the above.

   (a)  A DDoS attack is initiated against online properties of an
        organization have access to a Web portal which incorporates DOTS
        client functionality and can generate DOTS mitigation service
        requests upon demand.

   (b)  Authorized personnel utilize the Web portal to send a DOTS
        mitigation service initiation request to one or more upstream
        transit networks, peer networks, or overlay MSSP networks,
        either directly or via intermediate DOTS relays residing upon
        the requesting organization's network, the upstream mitigation
        provider's network, or both.  [The scope, format, and content of
        these messages must be codified by the DOTS WG.]  This DOTS
        mitigation service initiation request is manually triggered by
        personnel of the requesting organization when it is judged that
        the organization is under DDoS attack (the mechanism by which
        this process takes place is beyond the scope of this document).

   (c)  The DOTS servers which receive the DOTS mitigation service
        initiation requests determine that they have been provisioned to
        honor requests from the Web portal, and initiate situationally-
        appropriate DDoS mitigation service on their respective networks
        (the mechanism by which this process takes place is beyond the
        scope of this document).





Dobbins, et al.          Expires April 21, 2016                [Page 14]


Internet-Draft               DOTS Use cases                 October 2015


   (d)  The DOTS servers transmit a DOTS service status message to the
        Web portal indicating that upstream DDoS mitigation service has
        been initiated.  [The scope, format, and content of these
        messages must be codified by the DOTS WG.

   (e)  While DDoS mitigation services are active, the DOTS servers
        regularly transmit DOTS mitigation status updates to the Web
        portal.  The scope, format, and content of these messages must
        be codified by the DOTS WG.

   (f)  While DDoS mitigation services are active, the Web portal may
        optionally regularly transmit manually-triggered DOTS mitigation
        efficacy updates to the relevant DOTS servers.  The scope,
        format, and content of these messages must be codified by the
        DOTS WG.

   (g)  When the upstream DDoS mitigators determine that the DDoS attack
        has ceased, they indicate this change in status to their
        respective DOTS servers (the mechanism by which this process
        takes place is beyond the scope of this document).

   (h)  The DOTS servers transmit a DOTS mitigation status update to the
        Web portal indicating that the DDoS attack has ceased.  [The
        scope, format, and content of these messages must be codified by
        the DOTS WG.

   (i)  The Web portal transmits a manually-triggered DOTS mitigation
        service termination request to the DOTS servers (the mechanism
        by which this process takes place is beyond the scope of this
        document).  The scope, format, and content of these messages
        must be codified by the DOTS WG.

   (j)  The DOTS servers terminate DDoS mitigation service on their
        respective networks (the mechanism by which this process takes
        place is beyond the scope of this document).

   (k)  The DOTS servers transmit a DOTS mitigation status update to the
        Web portal indicating that DDoS mitigation services have been
        terminated.  The scope, format, and content of these messages
        must be codified by the DOTS WG.

   (l)  The Web portal transmits a DOTS mitigation termination status
        acknowledgement to the DOTS servers.  The scope, format, and
        content of these messages must be codified by the DOTS WG.







Dobbins, et al.          Expires April 21, 2016                [Page 15]


Internet-Draft               DOTS Use cases                 October 2015


4.1.6.  Successful Manual Mobile Device Application Request to Upstream
        Mitigator

   In this scenario, an application for mobile devices such as
   smartphones and tablets which incorporates DOTS client capabilities
   has been made available to authorized personnel of an organization.
   When the organization has reason to believe that it is under active
   DDoS attack, authorized personnel may utilize the mobile device
   application to manually initiate a DOTS client mitigation request to
   one or more DOTS servers in order to initiate upstream DDoS
   mitigation services.  DDoS mitigation service may be terminated
   manually via a DOTS mitigation service termination request initiated
   through the mobile device application when it has been determined
   that the DDoS attack has ended.

   All DOTS messages exchanged between the DOTS client and DOTS servers
   in this use case may be communicated directly between the DOTS client
   and servers, or mediated by one or more DOTS relays residing on the
   network of the originating network, the network where upstream DDoS
   mitigation service takes place, an intervening network or networks,
   or some combination of the above.

   (a)  A DDoS attack is initiated against online properties of an
        organization have access to a Web portal which incorporates DOTS
        client functionality and can generate DOTS mitigation service
        requests upon demand.

   (b)  Authorized personnel utilize the mobile application to send a
        DOTS mitigation service initiation request to one or more DOTS
        servers residing on the same network as the targeted Internet
        properties, one or more upstream transit networks, peer
        networks, or overlay MSSP networks, either directly or via
        intermediate DOTS relays residing upon the requesting
        organization's network, the upstream mitigation provider's
        network, or both.  [The scope, format, and content of these
        messages must be codified by the DOTS WG.]  This DOTS mitigation
        service initiation request is manually triggered by personnel of
        the requesting organization when it is judged that the
        organization is under DDoS attack (the mechanism by which this
        process takes place is beyond the scope of this document).

   (c)  The DOTS servers which receive the DOTS mitigation service
        initiation requests determine that they have been provisioned to
        honor requests from the mobile application, and initiate
        situationally-appropriate DDoS mitigation service on their
        respective networks (the mechanism by which this process takes
        place is beyond the scope of this document).




Dobbins, et al.          Expires April 21, 2016                [Page 16]


Internet-Draft               DOTS Use cases                 October 2015


   (d)  The DOTS servers transmit a DOTS service status message to the
        mobile application indicating that upstream DDoS mitigation
        service has been initiated.  The scope, format, and content of
        these messages must be codified by the DOTS WG.

   (e)  While DDoS mitigation services are active, the DOTS servers
        regularly transmit DOTS mitigation status updates to the mobile
        application.  The scope, format, and content of these messages
        must be codified by the DOTS WG.

   (f)  While DDoS mitigation services are active, the mobile
        application may optionally regularly transmit manually-triggered
        DOTS mitigation efficacy updates to the relevant DOTS servers.
        The scope, format, and content of these messages must be
        codified by the DOTS WG.

   (g)  When the upstream DDoS mitigators determine that the DDoS attack
        has ceased, they indicate this change in status to their
        respective DOTS servers (the mechanism by which this process
        takes place is beyond the scope of this document).

   (h)  The DOTS servers transmit a DOTS mitigation status update to the
        mobile application indicating that the DDoS attack has ceased.
        The scope, format, and content of these messages must be
        codified by the DOTS WG.

   (i)  The mobile application transmits a manually-triggered DOTS
        mitigation service termination request to the DOTS servers (the
        mechanism by which this process takes place is beyond the scope
        of this document).  The scope, format, and content of these
        messages must be codified by the DOTS WG.

   (j)  The DOTS servers terminate DDoS mitigation service on their
        respective networks (the mechanism by which this process takes
        place is beyond the scope of this document).

   (k)  The DOTS servers transmit a DOTS mitigation status update to the
        mobile application indicating that DDoS mitigation services have
        been terminated.  The scope, format, and content of these
        messages must be codified by the DOTS WG.

   (l)  The mobile application transmits a DOTS mitigation termination
        status acknowledgement to the DOTS servers.  The scope, format,
        and content of these messages must be codified by the DOTS WG.







Dobbins, et al.          Expires April 21, 2016                [Page 17]


Internet-Draft               DOTS Use cases                 October 2015


4.1.7.  Unsuccessful Automatic or Operator-Assisted CPE or PE Mitigators
        Request Upstream DDoS Mitigation Services

   In this scenario, one or more CPE or PE mitigators with DOTS client
   capabilities may be configured to signal to one or more DOTS servers
   in order to request upstream DDoS mitigation service initiation
   during an attack when DDoS attack volumes and/or attack
   characteristics exceed the capabilities of such CPE mitigators.  DDoS
   mitigation service may be terminated either automatically or manually
   via a DOTS mitigation service termination request initiated by the
   mitigator when it has been determined that the DDoS attack has ended.

   All DOTS messages exchanged between the DOTS clients and DOTS servers
   in this use case may be communicated directly between the DOTS
   clients and servers, or mediated by one or more DOTS relays residing
   on the network of the originating network, the network where upstream
   DDoS mitigation service takes place, an intervening network or
   networks, or some combination of the above.

   (a)  A DDoS attack is initiated against online properties of an
        organization which has deployed DOTS-client-capable DDoS
        mitigators.

   (b)  CPE or PE DDoS mitigators detect, classify, and begin mitigating
        the DDoS attack.

   (c)  CPE or PE DDoS mitigators determine that their capacity and/or
        capability to mitigate the DDoS attack is insufficient, and
        utilize their DOTS client functionality to send a DOTS
        mitigation service initiation request to one or more DOTS
        servers residing on one or more upstream transit networks, peer
        networks, or overlay MSSP networks.  The scope, format, and
        content of these messages must be codified by the DOTS WG.]
        This DOTS mitigation service initiation request may be
        automatically initiated by the CPE or PE DDoS mitigators, or may
        be manually triggered by personnel of the requesting
        organization in response to an alert from the mitigators (the
        mechanism by which this process takes place is beyond the scope
        of this document).

   (d)  The DOTS servers which receive the DOTS mitigation service
        initiation requests determine that they have been to honor
        requests from the requesting CPE or PE mitigators, and attempt
        to initiate situationally-appropriate DDoS mitigation service on
        their respective networks (the mechanism by which this process
        takes place is beyond the scope of this document).





Dobbins, et al.          Expires April 21, 2016                [Page 18]


Internet-Draft               DOTS Use cases                 October 2015


   (e)  The DDoS mitigators on the upstream network report back to the
        DOTS servers that they are unable to initiate DDoS mitigation
        service for the requesting organization due to mitigation
        capacity constraints, bandwidth constraints, functionality
        constraints, hardware casualties, or other impediments (the
        mechanism by which this process takes place is beyond the scope
        of this document).

   (f)  The DOTS servers transmit a DOTS service status message to the
        requesting CPE or PE mitigators indicating that upstream DDoS
        mitigation service cannot be initiated as requested.  The scope,
        format, and content of these messages must be codified by the
        DOTS WG.

   (g)  The CPE or PE mitigators may optionally regularly re-transmit
        DOTS mitigation status request messages to the relevant DOTS
        servers until acknowledgement that mitigation services have been
        initiated.  The scope, format, and content of these messages
        must be codified by the DOTS WG.

   (h)  The CPE or PE mitigators may optionally transmit a DOTS
        mitigation service initiation request to DOTS servers associated
        with a configured fallback upstream DDoS mitigation service.
        The scope, format, and content of these messages must be
        codified by the DOTS WG.  Multiple fallback DDoS mitigation
        services may optionally be configured.

   (i)  The process describe above cyclically continues until the DDoS
        mitigation service request is fulfilled; the CPE or PE
        mitigators determine that the DDoS attack volume has decreased
        to a level and/or complexity which they themselves can
        successfully mitigate; the DDoS attack has ceased; or manual
        intervention by personnel of the requesting organization has
        taken place.

4.2.  Ancillary Use Cases

4.2.1.  Auto-registration of DOTS clients with DOTS servers

   An additional benefit of DOTS is that by utilizing agreed-upon
   authentication mechanisms, DOTS clients can automatically register
   for DDoS mitigation service with one or more upstream DOTS servers.
   The details of such registration are beyond the scope of this
   document.







Dobbins, et al.          Expires April 21, 2016                [Page 19]


Internet-Draft               DOTS Use cases                 October 2015


4.2.2.  Auto-provisioning of DDoS countermeasures

   The largely manual tasks associated with provisioning effective,
   situationally-appropriate DDoS countermeasures is a significant
   barrier to providing/obtaining DDoS mitigation services for both
   mitigation providers and mitigation recipients.  Due to the 'self-
   descriptive' nature of DOTS registration messages and mitigation
   requests, the implementation and deployment of DOTS has the potential
   to automate countermeasure selection and configuration for DDoS
   mitigators.  The details of such provisioning are beyond the scope of
   this document.

4.2.3.  Informational DDoS attack notification to interested and
        authorized third parties

   In addition to its primary role of providing a standardized,
   programmatic approach to the automated and/or operator-assisted
   request of DDoS mitigation services and providing status updates of
   those mitigations to requesters, DOTS may be utilized to notify
   security researchers, law enforcement agencies, regulatory bodies,
   etc. of DDoS attacks against attack targets, assuming that
   organizations making use of DOTS choose to share such third-party
   notifications, in keeping with all applicable laws, regulations,
   privacy and confidentiality considerations, and contractual
   agreements between DOTS users and said third parties.

5.  Security Considerations

   DOTS is at risk from three primary attacks: DOTS agent impersonation,
   traffic injection, and signaling blocking.  The DOTS protocol MUST be
   designed for minimal data transfer to address the blocking risk.

   Impersonation and traffic injection mitigation can be managed through
   current secure communications best practices.  DOTS is not subject to
   anything new in this area.  One consideration could be to minimize
   the security technologies in use at any one time.  The more needed,
   the greater the risk of failures coming from assumptions on one
   technology providing protection that it does not in the presence of
   another technology.

6.  IANA Considerations

7.  Acknowledgments








Dobbins, et al.          Expires April 21, 2016                [Page 20]


Internet-Draft               DOTS Use cases                 October 2015


8.  References

8.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI
              10.17487/RFC0768, August 1980,
              <http://www.rfc-editor.org/info/rfc768>.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, DOI 10.17487/RFC0793, September 1981,
              <http://www.rfc-editor.org/info/rfc793>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC1518]  Rekhter, Y. and T. Li, "An Architecture for IP Address
              Allocation with CIDR", RFC 1518, DOI 10.17487/RFC1518,
              September 1993, <http://www.rfc-editor.org/info/rfc1518>.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
              2006, <http://www.rfc-editor.org/info/rfc4632>.

8.2.  Informative References

   [APACHE]   "Apache mod_security", <https://www.modsecurity.org>.

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

Authors' Addresses

   Roland Dobbins (editor)
   Arbor Networks
   30 Raffles Place
   Level 17 Chevron House
   Singapore 048622
   Singapore

   Email: rdobbins@arbor.net







Dobbins, et al.          Expires April 21, 2016                [Page 21]


Internet-Draft               DOTS Use cases                 October 2015


   Stephane Fouant
   Corero Network Security

   Email: Stefan.Fouant@corero.com


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

   Phone: +1 514-452-2160
   Email: daniel.migault@ericsson.com


   Robert Moskowitz
   HTT Consulting
   Oak Park, MI  48237
   USA

   Email: rgm@labs.htt-consult.com


   Nik Teague
   Verisign Inc
   12061 Bluemont Way
   Reston, VA 20190
   US

   Phone: +44 791 763 5384
   Email: nteague@verisign.com


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

   Email: Frank.xialiang@huawei.com










Dobbins, et al.          Expires April 21, 2016                [Page 22]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/