DDoS Open Threat Signaling (DOTS) Architecture
RFC 8811

Document Type RFC - Informational (August 2020; No errata)
Authors Andrew Mortensen  , Tirumaleswar Reddy.K  , Flemming Andreasen  , Nik Teague  , Rich Compton 
Last updated 2020-08-17
Replaces draft-mortensen-dots-architecture
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd Valery Smyslov
Shepherd write-up Show (last changed 2019-09-16)
IESG IESG state RFC 8811 (Informational)
Action Holders
Consensus Boilerplate Yes
Telechat date
Responsible AD Roman Danyliw
Send notices to Roman Danyliw <rdd@cert.org>, Valery Smyslov <valery@smyslov.net>
IANA IANA review state IANA OK - No Actions Needed
IANA action state No IANA Actions

Internet Engineering Task Force (IETF)                 A. Mortensen, Ed.
Request for Comments: 8811                                    Forcepoint
Category: Informational                                  T. Reddy.K, Ed.
ISSN: 2070-1721                                             McAfee, Inc.
                                                            F. Andreasen
                                                               N. Teague
                                                           Iron Mountain
                                                              R. Compton
                                                             August 2020

             DDoS Open Threat Signaling (DOTS) Architecture


   This document describes an architecture for establishing and
   maintaining Distributed Denial-of-Service (DDoS) Open Threat
   Signaling (DOTS) within and between domains.  The document does not
   specify protocols or protocol extensions, instead focusing on
   defining architectural relationships, components, and concepts used
   in a DOTS deployment.

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

Copyright Notice

   Copyright (c) 2020 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.  Context and Motivation
     1.1.  Terminology
       1.1.1.  Key Words
       1.1.2.  Definition of Terms
     1.2.  Scope
     1.3.  Assumptions
   2.  DOTS Architecture
     2.1.  DOTS Operations
     2.2.  Components
       2.2.1.  DOTS Client
       2.2.2.  DOTS Server
       2.2.3.  DOTS Gateway
     2.3.  DOTS Agent Relationships
       2.3.1.  Gatewayed Signaling
   3.  Concepts
     3.1.  DOTS Sessions
       3.1.1.  Preconditions
       3.1.2.  Establishing the DOTS Session
       3.1.3.  Maintaining the DOTS Session
     3.2.  Modes of Signaling
       3.2.1.  Direct Signaling
       3.2.2.  Redirected Signaling
       3.2.3.  Recursive Signaling
       3.2.4.  Anycast Signaling
       3.2.5.  Signaling Considerations for Network Address
     3.3.  Triggering Requests for Mitigation
       3.3.1.  Manual Mitigation Request
       3.3.2.  Automated Conditional Mitigation Request
       3.3.3.  Automated Mitigation on Loss of Signal
   4.  IANA Considerations
   5.  Security Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Authors' Addresses

1.  Context and Motivation

   Signaling the need for help to defend against an active distributed
   denial-of-service (DDoS) attack requires a common understanding of
   mechanisms and roles among the parties coordinating a defensive
   response.  The signaling layer and supplementary messaging are the
   focus of DDoS Open Threat Signaling (DOTS).  DOTS defines a method of
   coordinating defensive measures among willing peers to mitigate
   attacks quickly and efficiently, enabling hybrid attack responses
   coordinated locally at or near the target of an active attack, or
   anywhere in path between attack sources and target.  Sample DOTS use
   cases are elaborated in [DOTS-USE-CASES].

   This document describes an architecture used in establishing,
   maintaining, or terminating a DOTS relationship within a domain or
   between domains.

1.1.  Terminology

1.1.1.  Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
Show full document text