doc: Add RFC documents

1 files changed, 659 insertions, 0 deletions

diff --git a/doc/rfc/rfc8903.txt b/doc/rfc/rfc8903.txt
new file mode 100644
index 0000000..33592ee
--- /dev/null
+++ b/doc/rfc/rfc8903.txt
@@ -0,0 +1,659 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        R. Dobbins
+Request for Comments: 8903                                Netscout, Inc.
+Category: Informational                                       D. Migault
+ISSN: 2070-1721                                                 Ericsson
+                                                            R. Moskowitz
+                                                          HTT Consulting
+                                                               N. Teague
+                                              Iron Mountain Data Centers
+                                                                  L. Xia
+                                                                  Huawei
+                                                            K. Nishizuka
+                                                      NTT Communications
+                                                                May 2021
+
+
+                Use Cases for DDoS Open Threat Signaling
+
+Abstract
+
+   The DDoS Open Threat Signaling (DOTS) effort is intended to provide
+   protocols to facilitate interoperability across disparate DDoS
+   Mitigation solutions.  This document presents sample use cases that
+   describe the interactions expected between the DOTS components as
+   well as DOTS messaging exchanges.  These use cases are meant to
+   identify the interacting DOTS components, how they collaborate, and
+   what the typical information to be exchanged is.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8903.
+
+Copyright Notice
+
+   Copyright (c) 2021 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
+   (https://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.  Terminology and Acronyms
+   3.  Use Cases
+     3.1.  Upstream DDoS Mitigation by an Upstream Internet Transit
+           Provider
+     3.2.  DDoS Mitigation by a Third-Party DDoS Mitigation Service
+           Provider
+     3.3.  DDoS Orchestration
+   4.  Security Considerations
+   5.  IANA Considerations
+   6.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   At the time of writing, distributed denial-of-service (DDoS) attack
+   mitigation solutions are largely based upon siloed, proprietary
+   communications schemes with vendor lock-in as a side effect.  This
+   can result in the configuration, provisioning, operation, and
+   activation of these solutions being a highly manual and often time-
+   consuming process.  Additionally, coordinating multiple DDoS
+   Mitigation solutions simultaneously is fraught with both technical
+   and process-related hurdles.  This greatly increases operational
+   complexity, which in turn can degrade the efficacy of mitigations
+   that are generally highly dependent on a timely reaction by the
+   system.
+
+   The DDoS Open Threat Signaling (DOTS) effort is intended to specify
+   protocols that facilitate interoperability between diverse DDoS
+   Mitigation solutions and ensure greater integration in terms of
+   attack detection, mitigation requests, and attack characterization
+   patterns.
+
+   As DDoS solutions are broadly heterogeneous among vendors, the
+   primary goal of DOTS is to provide high-level interaction amongst
+   differing DDoS solutions, such as detecting DDoS attacks, initiating/
+   terminating DDoS Mitigation assistance, or requesting the status of a
+   DDoS Mitigation.
+
+   This document provides sample use cases that provided input for the
+   requirements [RFC8612] and design of the DOTS protocols
+   [RFC8782][RFC8783].  The use cases are not exhaustive, and future use
+   cases are expected to emerge as DOTS is adopted and evolves.
+
+2.  Terminology and Acronyms
+
+   This document makes use of the same terminology and definitions as
+   [RFC8612].  In addition, it uses the terms defined below:
+
+   DDoS Mitigation System (DMS):
+      A system that performs DDoS Mitigation.  The DDoS Mitigation
+      System may be composed of a cluster of hardware and/or software
+      resources but could also involve an orchestrator that may make
+      decisions, such as outsourcing some or all of the mitigation to
+      another DDoS Mitigation System.
+
+   DDoS Mitigation:
+      The action performed by the DDoS Mitigation System.
+
+   DDoS Mitigation Service:
+      Designates a service provided to a customer to mitigate DDoS
+      attacks.  Each service subscription usually involve Service Level
+      Agreement (SLA) that has to be met.  It is the responsibility of
+      the DDoS Service provider to instantiate the DDoS Mitigation
+      System to meet these SLAs.
+
+   DDoS Mitigation Service Provider:
+      Designates the administrative entity providing the DDoS Mitigation
+      Service.
+
+   Internet Transit Provider (ITP):
+      Designates the entity that delivers the traffic to a customer
+      network.  It can be an Internet Service Provider (ISP) or an
+      upstream entity delivering the traffic to the ISP.
+
+3.  Use Cases
+
+3.1.  Upstream DDoS Mitigation by an Upstream Internet Transit Provider
+
+   This use case describes how an enterprise or a residential customer
+   network may take advantage of a pre-existing relation with its ITP in
+   order to mitigate a DDoS attack targeting its network.
+
+   For clarity of discussion, the targeted network is indicated as an
+   enterprise network, but the same scenario applies to any downstream
+   network, including residential and cloud hosting networks.
+
+   As the ITP provides connectivity to the enterprise network, it is
+   already on the path of the inbound and outbound traffic of the
+   enterprise network and is well aware of the networking parameters
+   associated with the enterprise network WAN connectivity.  This eases
+   both the configuration and the instantiation of a DDoS Mitigation
+   Service.
+
+   This section considers two kinds of DDoS Mitigation Service between
+   an enterprise network and an ITP:
+
+   *  The upstream ITP may instantiate a DMS upon receiving a request
+      from the enterprise network.  This typically corresponds to a case
+      when the enterprise network is under attack.
+
+   *  On the other hand, the ITP may identify an enterprise network as
+      the source of an attack and send a mitigation request to the
+      enterprise DMS to mitigate this at the source.
+
+   The two scenarios, though different, have similar interactions
+   between the DOTS client and server.  For the sake of simplicity, only
+   the first scenario will be detailed in this section.  Nevertheless,
+   the second scenario is also in scope for DOTS.
+
+   In the first scenario, as depicted in Figure 1, an enterprise network
+   with self-hosted Internet-facing properties such as web servers,
+   authoritative DNS servers, and Voice over IP (VoIP) servers has a DMS
+   deployed to protect those servers and applications from DDoS attacks.
+   In addition to on-premise DDoS defense capabilities, the enterprise
+   has contracted with its ITP for DDoS Mitigation Services when attacks
+   threaten to overwhelm the bandwidth of their WAN link(s).
+
+       +------------------+        +------------------+
+       | Enterprise       |        | Upstream         |
+       | Network          |        | Internet Transit |
+       |                  |        | Provider         |
+       |      +--------+  |        |             DDoS Attack
+       |      | DDoS   |  | <=================================
+       |      | Target |  | <=================================
+       |      +--------+  |        |  +------------+  |
+       |                  | +-------->| DDoS       |  |
+       |                  | |      |S | Mitigation |  |
+       |                  | |      |  | System     |  |
+       |                  | |      |  +------------+  |
+       |                  | |      |                  |
+       |                  | |      |                  |
+       |                  | |      |                  |
+       |  +------------+  | |      |                  |
+       |  | DDoS       |<---+      |                  |
+       |  | Mitigation |C |        |                  |
+       |  | System     |  |        |                  |
+       |  +------------+  |        |                  |
+       +------------------+        +------------------+
+
+          * C is for DOTS client functionality
+          * S is for DOTS server functionality
+
+        Figure 1: Upstream Internet Transit Provider DDoS Mitigation
+
+   The enterprise DMS is configured such that if the incoming Internet
+   traffic volume exceeds 50% of the provisioned upstream Internet WAN
+   link capacity, the DMS will request DDoS Mitigation assistance from
+   the upstream transit provider.  More sophisticated detection means
+   may be considered as well.
+
+   The requests to trigger, manage, and finalize a DDoS Mitigation
+   between the enterprise DMS and the ITP are made using DOTS.  The
+   enterprise DMS implements a DOTS client while the ITP implements a
+   DOTS server, which is integrated with their DMS in this example.
+
+   When the enterprise DMS locally detects an inbound DDoS attack
+   targeting its resources (e.g., servers, hosts, or applications), it
+   immediately begins a DDoS Mitigation.
+
+   During the course of the attack, the inbound traffic volume to the
+   enterprise network exceeds the 50% threshold, and the enterprise DMS
+   escalates the DDoS Mitigation.  The enterprise DMS DOTS client
+   signals to the DOTS server on the upstream ITP to initiate DDoS
+   Mitigation.  The DOTS server replies to the DOTS client that it can
+   serve this request, and mitigation is initiated on the ITP network by
+   the ITP DMS.
+
+   Over the course of the attack, the DOTS server of the ITP
+   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 a
+   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 that the ITP
+   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:
+
+   1.  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.
+
+   2.  The enterprise DMS detects, classifies, and begins the DDoS
+       Mitigation.
+
+   3.  The enterprise DMS determines that its capacity and/or capability
+       to mitigate the DDoS attack is insufficient and sends a DOTS DDoS
+       Mitigation request via its DOTS client to one or more DOTS
+       servers residing on the upstream ITP.
+
+   4.  The DOTS server, which receives the DOTS Mitigation request,
+       determines that it has been configured to honor requests from the
+       requesting DOTS client and does so by orchestrating its own DMS.
+
+   5.  While the DDoS Mitigation is active, the DOTS server regularly
+       transmits DOTS DDoS Mitigation status updates to the DOTS client.
+
+   6.  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.
+
+   7.  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
+   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 third-party wireless 4G network connectivity.
+
+   Note also that a DOTS client that sends a DOTS Mitigation request may
+   also be 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 with each link.  More multihoming
+   considerations are discussed in [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 resource capacity, it may choose to delegate
+   the DDoS Mitigation to another DDoS Mitigation Service Provider.
+
+      +------------------+        +------------------+
+      | 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 a
+                Third-Party DDoS Mitigation Service Provider
+
+   In this scenario, an enterprise network has entered into a
+   prearranged 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 or any other given DMS to
+   mitigate the attack on its own.
+
+   The prearrangement 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).  The exact mechanisms used for traffic steering are out of
+   scope of DOTS but will need to be prearranged, while in some contexts
+   such changes could be detected and considered as an attack.
+
+   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 that the DDoS Mitigation Service Provider terminate the
+   DDoS Mitigation.
+
+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 DMSs 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 analyzes the various sets of information it receives
+   from DDoS telemetry systems and initiates one or more DDoS Mitigation
+   strategies.  For example, the orchestrator could select the DMS in
+   the enterprise network or one provided by the ITP.
+
+   DMS selection and DDoS Mitigation techniques may depend on the type
+   of the DDoS attack.  In some cases, 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 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, for example, a web interface that interacts with a DOTS client,
+   while the orchestrator implements a DOTS server.
+
+   The communication between the orchestrator and the DMSs is performed
+   using DOTS.  The orchestrator implements a DOTS client while the DMSs
+   implement a DOTS server.
+
+   The configuration aspects of each DMS, as well as the instantiations
+   of DDoS Mitigation functions or network configuration, are not part
+   of DOTS.  Similarly, the discovery of available DDoS Mitigation
+   functions is not part of DOTS and, as such, is out of scope.
+
+          +----------+
+          | network  |C            (Enterprise Network)
+          | admini-  |<-+
+          | strator  |  |
+          +----------+  |
+                        |
+          +----------+  | 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 aspects of the 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 is possible for something
+   that looks like an attack locally to one telemetry system 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.
+
+   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, for
+   example, a web interface.  If the network administrator decides to
+   start the mitigation, the network administrator triggers the DDoS
+   Mitigation request using, for example, a 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, elaborate, and
+   coordinate the appropriate DDoS Mitigation.
+
+   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 DMSs 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 DMSs.  The orchestrator DOTS server returns
+   this information to the network administrator.
+
+   Similarly, when the DDoS attack has stopped, the orchestrator DOTS
+   client is notified and the orchestrator's DOTS server indicates the
+   end of the DDoS Mitigation to the DDoS telemetry systems as well as
+   to the network administrator.
+
+   In addition to the DDoS orchestration shown in Figure 4, the selected
+   DMS can return a mitigation request to the orchestrator as an
+   offloading.  For example, when the DDoS attack becomes severe and the
+   DMS's utilization rate reaches its maximum capacity, the DMS can send
+   mitigation requests with additional hints, such as its blocked
+   traffic information, to the orchestrator.  Then the orchestrator can
+   take further actions such as requesting forwarding nodes (e.g.,
+   routers) to filter the traffic.  In this case, the DMS 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.
+
+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
+
+   This document has no IANA actions.
+
+6.  Informative References
+
+   [DOTS-MULTIHOMING]
+              Boucadair, M., Reddy, T., and W. Pan, "Multi-homing
+              Deployment Considerations for Distributed-Denial-of-
+              Service Open Threat Signaling (DOTS)", Work in Progress,
+              Internet-Draft, draft-ietf-dots-multihoming-06, 25 May
+              2021, <https://tools.ietf.org/html/draft-ietf-dots-
+              multihoming-06>.
+
+   [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>.
+
+   [RFC8782]  Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
+              Mortensen, A., and N. Teague, "Distributed Denial-of-
+              Service Open Threat Signaling (DOTS) Signal Channel
+              Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
+              <https://www.rfc-editor.org/info/rfc8782>.
+
+   [RFC8783]  Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
+              Denial-of-Service Open Threat Signaling (DOTS) Data
+              Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
+              May 2020, <https://www.rfc-editor.org/info/rfc8783>.
+
+Acknowledgments
+
+   The authors would like to thank, among others, Tirumaleswar Reddy.K,
+   Andrew Mortensen, Mohamed Boucadair, Artyom Gavrichenkov, Jon
+   Shallow, Yuuhei Hayashi, Elwyn Davies, the DOTS WG Chairs (at the
+   time of writing) 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, who was one of the
+   initial coauthors of the documents.
+
+Authors' Addresses
+
+   Roland Dobbins
+   Netscout, Inc.
+   Singapore
+
+   Email: roland.dobbins@netscout.com
+
+
+   Daniel Migault
+   Ericsson
+   8275 Trans Canada Route
+   Saint Laurent, Quebec 4S 0B6
+   Canada
+
+   Email: daniel.migault@ericsson.com
+
+
+   Robert Moskowitz
+   HTT Consulting
+   Oak Park, MI 48237
+   United States of America
+
+   Email: rgm@labs.htt-consult.com
+
+
+   Nik Teague
+   Iron Mountain Data Centers
+   United Kingdom
+
+   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