Skip to main content

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

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 , Robert Moskowitz , Nik Teague , Liang Xia , Kaname Nishizuka
Last updated 2020-06-11 (Latest revision 2020-05-29)
Replaces draft-mglt-dots-use-cases
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Valery Smyslov
Shepherd write-up Show Last changed 2019-09-05
IESG IESG state Became RFC 8903 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Benjamin Kaduk
Send notices to Valery Smyslov <valery@smyslov.net>
IANA IANA review state IANA OK - No Actions Needed
draft-ietf-dots-use-cases-23
[Ballot comment]
Tim Wicinski  performed the opsdir review.

   serve this request, and mitigation is initiated on the ITP network by
   the ITP DMS.

   Over the course of the attack, the DOTS server of the ITP
   periodically informs the DOTS client on the mitigation status,
   statistics related to DDoS attack traffic mitigation, and related
   information.  Once the DDoS attack has ended, or decreased to the
   certain level that the enterprise DMS might handle by itself, the
   DOTS server signals the enterprise DMS DOTS client that the attack
   has subsided.

   The DOTS client on the enterprise DMS then requests the ITP to
   terminate the DDoS Mitigation.  The DOTS server on the ITP receives
   this request and once the mitigation has ended, confirms the end of
   upstream DDoS Mitigation to the enterprise DMS DOTS client.

   The following is an overview of the DOTS communication model for this
   use-case:

   o  (a) A DDoS attack is initiated against resources of a network
      organization (here, the enterprise) which has deployed a DOTS-
      capable DMS - typically a DOTS client.

   o  (b) The enterprise DMS detects, classifies, and begins the DDoS
      Mitigation.

   o  (c) The enterprise DMS determines that its capacity and/or
      capability to mitigate the DDoS attack is insufficient, and sends
      via its DOTS client a DOTS DDoS Mitigation request to one or more
      DOTS servers residing on the upstream ITP.

   o  (d) The DOTS server which receives the DOTS Mitigation request
      determines that it has been configured to honor requests from the
      requesting DOTS client, and honors the request by orchestrating
      its own DMS.

   o  (e) While the DDoS Mitigation is active, the DOTS server regularly
      transmits DOTS DDoS Mitigation status updates to the DOTS client.

   o  (f) Informed by the DOTS server status update that the attack has
      ended or subsided, the DOTS client transmits a DOTS DDoS
      Mitigation termination request to the DOTS server.

   o  (g) The DOTS server terminates DDoS Mitigation, and sends the
      notification to the DOTS client.

   Note that communications between the enterprise DOTS client and the
   upstream ITP DOTS server may take place in-band within the main

Dobbins, et al.         Expires November 30, 2020               [Page 6]
Internet-Draft               DOTS Use Cases                     May 2020

   Internet WAN link between the enterprise and the ITP; 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 connectivity.

   Note also that a DOTS client that sends a DOTS Mitigation request may
   be also triggered by a network admin that manually confirms the
   request to the upstream ITP, in which case the request may be sent
   from an application such as a web browser or a dedicated mobile
   application.

   Note also that when the enterprise is multihomed and connected to
   multiple upstream ITPs, each ITP is only able to provide a DDoS
   Mitigation Service for the traffic it transits.  As a result, the
   enterprise network may be required to coordinate the various DDoS
   Mitigation Services associated to each link.  More multi-homing
   considerations are discussed in [I-D.ietf-dots-multihoming].

3.2.  DDoS Mitigation by a Third Party DDoS Mitigation Service Provider

   This use case differs from the previous use case described in
   Section 3.1 in that the DDoS Mitigation Service is not provided by an
   upstream ITP.  In other words, as represented in Figure 2, the
   traffic is not forwarded through the DDoS Mitigation Service Provider
   by default.  In order to steer the traffic to the DDoS Mitigation
   Service Provider, some network configuration changes are required.
   As such, this use case is likely to apply to large enterprises or
   large data centers, but as for the other use cases is not exclusively
   limited to them.

   Another typical scenario for this use case is for there to be a
   relationship between DDoS Mitigation Service Providers, forming an
   overlay of DMS.  When a DDoS Mitigation Service Provider mitigating a
   DDoS attack reaches its resources capacity, it may chose to delegate
   the DDoS Mitigation to another DDoS Mitigation Service Provider.

Dobbins, et al.         Expires November 30, 2020               [Page 7]
Internet-Draft               DOTS Use Cases                     May 2020

      +------------------+        +------------------+
      | Enterprise       |        | Upstream         |
      | Network          |        | Internet Transit |
      |                  |        | Provider         |
      |      +--------+  |        |             DDoS Attack
      |      | DDoS   |  | <=================================
      |      | Target |  | <=================================
      |      +--------+  |        |                  |
      |                  |        |                  |
      |                  |        +------------------+
      |                  |
      |                  |        +------------------+
      |                  |        | DDoS Mitigation  |
      |                  |        | Service Provider |
      |                  |        |                  |
      |  +------------+  |        |  +------------+  |
      |  | DDoS       |<------------>| DDoS       |  |
      |  | Mitigation |C |        | S| Mitigation |  |
      |  | System     |  |        |  | System     |  |
      |  +------------+  |        |  +------------+  |
      +------------------+        +------------------+

          * C is for DOTS client functionality
          * S is for DOTS server functionality

      Figure 2: DDoS Mitigation between an Enterprise Network and Third
                Party DDoS Mitigation Service Provider

   In this scenario, an enterprise network has entered into a pre-
   arranged DDoS mitigation assistance agreement with one or more third-
   party DDoS Mitigation Service Providers 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 the enterprise's or any other given DMS to
   mitigate the attack on its own.

   The pre-arrangement typically includes agreement on the mechanisms
   used to redirect the traffic to the DDoS Mitigation Service Provider,
   as well as the mechanism to re-inject the traffic back to the
   Enterprise Network.  Redirection to the DDoS Mitigation Service
   Provider typically involves BGP prefix announcement or DNS
   redirection, while re-injection of the scrubbed traffic to the
   enterprise network may be performed via tunneling mechanisms (e.g.,
   GRE).  These exact mechanisms used for traffic steering are out of
   scope of DOTS, but will need to be pre-arranged, while in some
   contexts such changes could be detected and considered as an attack.

Dobbins, et al.         Expires November 30, 2020               [Page 8]
Internet-Draft               DOTS Use Cases                     May 2020

   In some cases the communication between the enterprise DOTS client
   and the DOTS server of the DDoS Mitigation Service Provider may go
   through the ITP carrying the DDoS attack, which would affect the
   communication.  On the other hand, the communication between the DOTS
   client and DOTS server may take a path that is not undergoing a DDoS
   attack.

     +------------------+        +------------------+
     | Enterprise       |        | Upstream         |
     | Network          |        | Internet Transit |
     |                  |        | Provider         |
     |      +--------+  |        |             DDoS Attack
     |      | DDoS   |  |<----------------+         | ++====
     |      | Target |  |    Mitigated    |         | || ++=
     |      +--------+  |        |        |         | || ||
     |                  |        |        |         | || ||
     |                  |        +--------|---------+ || ||
     |                  |                 |           || ||
     |                  |        +--------|---------+ || ||
     |                  |        | DDoS Mitigation  | || ||
     |                  |        | Service Provider | || ||
     |                  |        |        |         | || ||
     |  +------------+  |        |  +------------+  | || ||
     |  | DDoS       |<------------>| DDoS       |  | || ||
     |  | mitigation |C |        |S | mitigation |<===++ ||
     |  | system     |  |        |  | system     |<======++
     |  +------------+  |        |  +------------+  |
     +------------------+        +------------------+

          * C is for DOTS client functionality
          * S is for DOTS server functionality

     Figure 3: Redirection to a DDoS Mitigation Service Provider

   When the enterprise network is under attack or at least is reaching
   its capacity or ability to mitigate a given DDoS attack, the DOTS
   client sends a DOTS request to the DDoS Mitigation Service Provider
   to initiate network traffic diversion - as represented in Figure 3 -
   and DDoS mitigation activities.  Ongoing attack and mitigation status
   messages may be passed between the enterprise network and the DDoS
   Mitigation Service Provider using DOTS.  If the DDoS attack has
   stopped or the severity of the attack has subsided, the DOTS client
   can request the DDoS Mitigation Service Provider to terminate the
   DDoS Mitigation.

Dobbins, et al.         Expires November 30, 2020               [Page 9]
Internet-Draft               DOTS Use Cases                     May 2020

3.3.  DDoS Orchestration

   In this use case, one or more DDoS telemetry systems or monitoring
   devices monitor a network - typically an ISP network, an enterprise
   network, or a data center.  Upon detection of a DDoS attack, these
   DDoS telemetry systems alert an orchestrator in charge of
   coordinating the various DMS's within the domain.  The DDoS telemetry
   systems may be configured to provide required information, such as a
   preliminary analysis of the observation, to the orchestrator.

   The orchestrator analyses the various information it receives from
   DDoS telemetry systems, and initiates one or more DDoS mitigation
   strategies.  For example, the orchestrator could select the DDoS
   mitigation system in the enterprise network or one provided by the
   ITP.

   DDoS Mitigation System selection and DDoS Mitigation techniques may
   depend on the type of the DDoS attack.  In some case, a manual
   confirmation or selection may also be required to choose a proposed
   strategy to initiate a DDoS Mitigation.  The DDoS Mitigation may
   consist of multiple steps such as configuring the network, or of
   updating already instantiated DDoS mitigation functions.  Eventually,
   the coordination of the mitigation may involve external DDoS
   mitigation resources such as a transit provider or a Third Party DDoS
   Mitigation Service Provider.

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

   The communication between a network administrator and the
   orchestrator is also performed using DOTS.  The network administrator
   uses a web interface which interacts with 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 System, as well as
   the instantiations of DDoS mitigation functions or network
   configuration is not part of DOTS.  Similarly, the discovery of
   available DDoS mitigation functions is not part of DOTS; and as such
   is out of scope.

Dobbins, et al.         Expires November 30, 2020              [Page 10]
Internet-Draft               DOTS Use Cases                     May 2020

          +----------+
          | network  |C            (Enterprise Network)
          | adminis  |<-+
          | trator   |  |
          +----------+  |
                        |
          +----------+  | S+--------------+     +-----------+
          |telemetry/|  +->|              |C   S| DDoS      |+
          |monitoring|<--->| Orchestrator |<--->| mitigation||
          |systems   |C   S|              |<-+  | systems   ||
          +----------+     +--------------+C |  +-----------+|
                                             |    +----------+
          -----------------------------------|-----------------
                                             |
                                             |
             (Internet Transit Provider)     |
                                             |  +-----------+
                                             | S| DDoS      |+
                                             +->| mitigation||
                                                | systems   ||
                                                +-----------+|
          * C is for DOTS client functionality    +----------+
          * S is for DOTS server functionality

            Figure 4: DDoS Orchestration

   The DDoS telemetry systems monitor various network traffic and
   perform some measurement tasks.

   These systems are configured so that when an event or some
   measurement indicators reach a predefined level their associated DOTS
   client sends a DOTS mitigation request to the orchestrator DOTS
   server.  The DOTS mitigation request may be associated with some
   optional mitigation hints to let the orchestrator know what has
   triggered the request.  In particular, it's possible for something
   that locally to one telemetry system looks like an attack is not
   actually an attack when seen from the broader scope (e.g., of the
   orchestrator)

   Upon receipt of the DOTS mitigation request from the DDoS telemetry
   system, the orchestrator DOTS server responds with an acknowledgment,
   to avoid retransmission of the request for mitigation.  The
   orchestrator may begin collecting additional fine-grained and
   specific information from various DDoS telemetry systems in order to
   correlate the measurements and provide an analysis of the event.
   Eventually, the orchestrator may ask for additional information from
   the DDoS telemetry system; however, the collection of this
   information is out of scope of DOTS.

Dobbins, et al.         Expires November 30, 2020              [Page 11]
Internet-Draft               DOTS Use Cases                     May 2020

   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, the network administrator triggers the DDoS mitigation
   request using the web interface of a DOTS client communicating to the
   orchestrator DOTS server.  This request is expected to be associated
   with a context that provides sufficient information to the
   orchestrator DOTS server to infer the DDoS Mitigation to elaborate
   and coordinate.

   Upon receiving a request to mitigate a DDoS attack aimed at a target,
   the orchestrator may evaluate the volume of the attack as well as the
   value that the target represents.  The orchestrator may select the
   DDoS Mitigation Service Provider based on the attack severity.  It
   may also coordinate the DDoS Mitigation performed by the DDoS
   Mitigation Service Provider with some other tasks such as, for
   example, moving the target to another network so new sessions will
   not be impacted.  The orchestrator requests a DDoS Mitigation by the
   selected DDoS mitigation systems via its DOTS client, as described in
   Section 3.1.

   The orchestrator DOTS client is notified that the DDoS Mitigation is
   effective by the selected DDoS mitigation systems.  The orchestrator
   DOTS servers returns this information back to the network
   administrator.

   Similarly, when the DDoS attack has stopped, the orchestrator DOTS
   client is notified and the orchestrator's DOTS servers indicate to
   the DDoS telemetry systems as well as to the network administrator
   the end of the DDoS Mitigation.

   In addition to the above DDoS Orchestration, the selected DDoS
   mitigation system can return back a mitigation request to the
   orchestrator as an offloading.  For example, when the DDoS attack
   becomes severe and the DDoS mitigation system's utilization rate
   reaches its maximum capacity, the DDoS mitigation system can send
   mitigation requests with additional hints such as its blocked traffic
   information to the orchestrator.  Then the orchestrator can take
   further actions like requesting forwarding nodes such as routers to
   filter the traffic.  In this case, the DDoS mitigation system
   implements a DOTS client while the orchestrator implements a DOTS
   server.  Similar to other DOTS use cases, the offloading scenario
   assumes that some validation checks are followed by the DMS, the
   orchestrator, or both (e.g., avoid exhausting the resources of the
   forwarding nodes or inadvertent disruption of legitimate services).
   These validation checks are part of the mitigation, and are therefore
   out of the scope of the document.

Dobbins, et al.         Expires November 30, 2020              [Page 12]
Internet-Draft               DOTS Use Cases                     May 2020

4.  Security Considerations

   The document does not describe any protocol, though there are still a
   few high-level security considerations to discuss.

   DOTS is at risk from three primary attacks: DOTS agent impersonation,
   traffic injection, and signaling blocking.

   Impersonation and traffic injection mitigation can be mitigated
   through current secure communications best practices including mutual
   authentication.  Preconfigured mitigation steps to take on the loss
   of keepalive traffic can partially mitigate signal blocking, but in
   general it is impossible to comprehensively defend against an
   attacker that can selectively block any or all traffic.  Alternate
   communication paths that are (hopefully) not subject to blocking by
   the attacker in question is another potential mitigation.

   Additional details of DOTS security requirements can be found in
   [RFC8612].

   Service disruption may be experienced if inadequate mitigation
   actions are applied.  These considerations are out of the scope of
   DOTS.

5.  IANA Considerations

   No IANA considerations exist for this document.

6.  Acknowledgments

   The authors would like to thank among others Tirumaleswar Reddy;
   Andrew Mortensen; Mohamed Boucadair; Artyom Gavrichenkov; Jon
   Shallow, Yuuhei Hayashi, the DOTS WG chairs, Roman Danyliw and Tobias
   Gondrom as well as the Security AD Benjamin Kaduk for their valuable
   feedback.

   We also would like to thank Stephan Fouant that was part of the
   initial co-authors of the documents.

7.  References

7.1.  Normative References

   [RFC8612]  Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
              Threat Signaling (DOTS) Requirements", RFC 8612,
              DOI 10.17487/RFC8612, May 2019,
              <https://www.rfc-editor.org/info/rfc8612>.

Dobbins, et al.         Expires November 30, 2020              [Page 13]
Internet-Draft               DOTS Use Cases                     May 2020

   [RFC8782]  Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N.
              Teague, "RFC8782 Distributed Denial-of-Service Open Threat
              Signaling (DOTS) Signal Channel Specification (TO BE
              UPDATED)", n.d.,
              <https://www.rfc-editor.org/rfc/authors/test8782.html>.

   [RFC8783]  Boucadair, M. and T. Reddy, "RFC8783 Distributed Denial-
              of-Service Open Threat Signaling (DOTS) Data Channel
              Specification (TO BE UPDATED)", n.d.,
              <https://www.rfc-editor.org/rfc/authors/rfc8783.html>.

7.2.  Informative References

   [I-D.ietf-dots-multihoming]
              Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing
              Deployment Considerations for Distributed-Denial-of-
              Service Open Threat Signaling (DOTS)", draft-ietf-dots-
              multihoming-03 (work in progress), January 2020.

Authors' Addresses

   Roland Dobbins
   Arbor Networks
   Singapore

   EMail: rdobbins@arbor.net

   Daniel Migault
   Ericsson
   8275 Trans Canada Route
   Saint Laurent, QC  4S 0B6
   Canada

   EMail: daniel.migault@ericsson.com

   Robert Moskowitz
   HTT Consulting
   Oak Park, MI  48237
   USA

   EMail: rgm@labs.htt-consult.com

Dobbins, et al.         Expires November 30, 2020              [Page 14]
Internet-Draft               DOTS Use Cases                     May 2020

   Nik Teague
   Iron Mountain Data Centers
   UK

   EMail: nteague@ironmountain.co.uk

   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 November 30, 2020              [Page 15]