Skip to main content

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

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 , Stefan Fouant , Daniel Migault , Robert Moskowitz , Nik Teague , Liang Xia , Kaname Nishizuka
Last updated 2017-03-27
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-04
DOTS WG                                                  R. Dobbins, Ed.
Internet-Draft                                            Arbor Networks
Intended status: Informational                                 S. Fouant
Expires: September 28, 2017
                                                              D. Migault
                                                                Ericsson
                                                            R. Moskowitz
                                                          HTT Consulting
                                                               N. Teague
                                                            Verisign Inc
                                                                  L. Xia
                                                                  Huawei
                                                            K. Nishizuka
                                                      NTT Communications
                                                          March 27, 2017

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

Abstract

   The DDoS Open Threat Signaling (DOTS) effort is intended to provide a
   protocol that facilitates interoperability between multivendor
   solutions/services.  This document presents use cases to evaluate the
   interactions expected between the DOTS components as well as the DOTS
   exchanges.  The purpose of the use cases is to identify the
   interacting DOTS component, how they collaborate and what are the
   types of information to be exchanged.

Status of This Memo

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

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

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

   This Internet-Draft will expire on September 28, 2017.

Dobbins, et al.        Expires September 28, 2017               [Page 1]
Internet-Draft               DOTS Use cases                   March 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Acronyms  . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Terminology  . . . . . . . . . . . . . . . .   3
     2.2.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases Scenarios . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Inter-domain Use Cases  . . . . . . . . . . . . . . . . .   4
       3.1.1.  Enterprise with an upsteam transit provider DDoS
               mitigation Service  . . . . . . . . . . . . . . . . .   4
       3.1.2.  Enterprise with on Cloud DDoS mitigation provider . .   5
     3.2.  Intra-domain Use Cases  . . . . . . . . . . . . . . . . .   6
       3.2.1.  Homenet DDoS protection by ISP  . . . . . . . . . . .   6
       3.2.2.  DDoS Orchestration  . . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

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

Dobbins, et al.        Expires September 28, 2017               [Page 2]
Internet-Draft               DOTS Use cases                   March 2017

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

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

Dobbins, et al.        Expires September 28, 2017               [Page 3]
Internet-Draft               DOTS Use cases                   March 2017

   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.

3.1.  Inter-domain Use Cases

3.1.1.  Enterprise with an upsteam transit provider DDoS mitigation
        Service

   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

Dobbins, et al.        Expires September 28, 2017               [Page 4]
Internet-Draft               DOTS Use cases                   March 2017

   capacity, the IDMS will request DDoS mitigation assistance from the
   upstream transit provider.

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

   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.

3.1.2.  Enterprise with on Cloud DDoS mitigation provider

   This use case details an enterprise that has a local DDoS detection
   and classification capability and may or may not have a mitigation
   capability.  The enterprise is contracted with a cloud DDoS
   mitigation provider who can redirect (offramp) traffic away from the
   enterprise, provide scrubbing services and return clean traffic back
   to the enterprise (onramp) on an ad-hoc, on demand basis.

   The enterprise may, either by hard coding or on a case by case basis,
   determine thresholds at which a request for mitigation is triggered
   indicating to the cloud provider that traffic should be redirected
   and scrubbed.

Dobbins, et al.        Expires September 28, 2017               [Page 5]
Internet-Draft               DOTS Use cases                   March 2017

   The communication to trigger, manage, and finalize a DDoS mitigation
   between the enterprise and the Cloud provider is performed using
   DOTS.  The enterprise implements a DOTS client while the Cloud
   Provider implements a DOTS server.

   The enterprise detection and classification systems encompass a DOTS
   client and the cloud provider a DOTS server.

   When an attack is detected an automated or manual DOTS mitigation
   request will be generatd and sent to the cloud provider.  The cloud
   provider will assess the request for validity and if passed a
   mitigation action may then be initiated.  This action will usually
   involve the offramp of all traffic destined to the target for further
   scrutiny and filtering by the cloud provider.  This should not only
   result in an alleviation of pressure on the enterprise network but
   also on its upstream provider and peers.

   The cloud provider should signal via DOTS to the enterprise that a
   mitigation request has been received and acted upon and should also
   include a basic situational status of the attack.  The cloud provider
   may respond periodically with additional updates on the status to
   enable the enterprise to make an informed decision on whether to
   maintain or cancel 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 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 flow based monitoring and analysis service to customers whose
   networks may be protected by any one of a number of 3rd party
   providers.  The enterprise in question may integrate with these 3rd
   party providers using DOTS and signal accordingly when a customer is
   attacked - the enterprise may then manage the life-cycle of the
   attack on behalf of the enterprise.

3.2.  Intra-domain Use Cases

3.2.1.  Homenet DDoS protection by ISP

   In this use case home networks or small businesses networks (SOHO),
   subscribe with their upstream ISP a DDoS mitigation service.

   Home networks run with limited bandwidth as well as limited routing
   resources, while they are expected to provide services reachable from
   the outside [RFC7368].  This makes such organizations some easy
   targets to DDoS attacks.  In addition, these DDoS attacks might even
   not be noticed by the upstream ISP.

Dobbins, et al.        Expires September 28, 2017               [Page 6]
Internet-Draft               DOTS Use cases                   March 2017

   This scenario is considered as an intra-domain as ISPs have a
   specific relationship with these customers.  The ISP is the
   connectivity provider, and in some cases, they even provides the CPE
   with a set of associated services.  Moreover, in case of any
   connectivity issue the customer is likely to call the hotline.  In
   order to improve the QoS of the connectivity as well as to automate
   the request for DDoS mitigation, ISP is likely to consider a standard
   mean for CPEs to notify when they are under a suspected DDoS.  Such
   notification may be triggered automatically or manually.  As the ISP
   and the customer share a common interest in mitigating the DDoS
   attack, this slightly differs from cases where a contract is
   negotiated with a third party, such as in the inter-domain use cases.

   In most cases, CPEs are unlikely to diagnose whether an DDoS attack
   is ongoing or not and simply rely on the upstream equipment provided
   by the ISP for detection and potential mitigation.

   The DDoS Mitigation service of the ISP may be hard coded or may be
   configured by the customer manually or automatically while the CPE is
   being connected to the Internet -- eventually the DHCP server may
   provide the DDoS Mitigation service via specific DHCP options.

   The communication to trigger a DDoS mitigation between the home
   network and the ISP is performed using DOTS.  The home network CPE
   implements a DOTS client while the ISP implements a DOTS server.

   The DOTS Client on the CPE monitors the status of CPE's resource and
   link bandwidth usage.  If something unusual happens based on
   preconfigured throughput or some heuristics methods, the DOTS Client
   sends a DOTS mitigation request to the ISP DOTS Server.  Typically, a
   default configuration with no additional information associated to
   the DOTS mitigation request is expected.  The ISP derives traffic to
   mitigate from the CPE IP address.

   In some cases, the DOTS mitigation request contains options such as
   some IP addresses or prefixes that belongs to a whitelist or
   respectively to a blacklist.  In this case, the white and black lists
   are not associated to some analysis performed by the CPE -- as the
   CPE is clearly not expected to analyze such attacks.  Instead these
   are part of some configuration parameters.  For example, in the case
   of small business, one may indicate specific legitimate IP addresses
   such as those used for VPNs, or third party services the company is
   likely to set a session.  Similarly, the CPE may provides the IP
   addresses of the assets to be protected inside the network.  Such
   options may include the IP address as well as a service description.
   Similarly to the previous blacklist and whitelist, such information
   are not derived from a traffic analysis performed by the CPE, but
   instead are more related to configuration parameters.

Dobbins, et al.        Expires September 28, 2017               [Page 7]
Internet-Draft               DOTS Use cases                   March 2017

   Upon receiving the DOTS mitigation request, the ISP acknowledges its
   reception and confirms DDoS mitigation starts or not.  Such feed back
   is mostly to avoid retransmission of the request.

   Note that the ISP is connected to multiple CPEs and as such the CPE
   can potentially perform DDoS attack to the DOTS server.  ISP may use
   relays to absorbs the traffic.  In addition, such attack may be
   triggered by a large scale DDoS attack, which is expected to be
   detected and mitigated by the upstream architecture.

   ISP may activate mitigation for the traffic associated to the CPE
   sending the alert or instead to the traffic associated to all CPE.
   Such decisions are not part of DOTS, but instead depend on the
   policies of the ISP network administrator.

   It is unlikely the CPE will follow the status of the mitigation.  The
   ISP is only expected to inform the CPE the mitigation has been
   stopped.

   Upon receipt of such notification the CPE may re-activate the
   monitoring jobs and thus is likely to provide some further DOTS
   alert.

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 or a cloud provider Section 3.1.2.

   The communication to trigger a DDoS mitigation between the telemetry
   and monitoring systems and the orchestrator is performed using DOTS.

Dobbins, et al.        Expires September 28, 2017               [Page 8]
Internet-Draft               DOTS Use cases                   March 2017

   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.

   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 pat of DOTS.

   The Telemetry or monitoring systems monitors each various traffic
   network and each performs their measurement tasks.  They are
   configure 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, or analysis.

   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
   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.  In fact the

Dobbins, et al.        Expires September 28, 2017               [Page 9]
Internet-Draft               DOTS Use cases                   March 2017

   orchestrator is expected to proceed to a significant number of
   configurations.

   Orchestration of the DDoS mitigation systems works similarly as
   described in Section 3.1 or Section 3.1.2.  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.

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

Dobbins, et al.        Expires September 28, 2017              [Page 10]
Internet-Draft               DOTS Use cases                   March 2017

7.2.  Informative References

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

   [I-D.ietf-dots-requirements]
              Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
              Denial of Service (DDoS) Open Threat Signaling
              Requirements", draft-ietf-dots-requirements-04 (work in
              progress), March 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", <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

   Stefan Fouant

   Email: stefan.fouant@copperriverit.com

Dobbins, et al.        Expires September 28, 2017              [Page 11]
Internet-Draft               DOTS Use cases                   March 2017

   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
   USA

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

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

   Email: Frank.xialiang@huawei.com

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

   Email: kaname@nttv6.jp

Dobbins, et al.        Expires September 28, 2017              [Page 12]