DDoS Open Threat Signaling (DOTS) Requirements
RFC 8612

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08
• 09
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22

Internet Engineering Task Force (IETF)                      A. Mortensen
Request for Comments: 8612                                Arbor Networks
Category: Informational                                         T. Reddy
ISSN: 2070-1721                                                   McAfee
                                                            R. Moskowitz
                                                                  Huawei
                                                                May 2019

             DDoS Open Threat Signaling (DOTS) Requirements

Abstract

   This document defines the requirements for the Distributed Denial-of-
   Service (DDoS) Open Threat Signaling (DOTS) protocols enabling
   coordinated response to DDoS attacks.

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

Copyright Notice

   Copyright (c) 2019 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.

Mortensen, et al.             Informational                     [Page 1]
RFC 8612                    DOTS Requirements                   May 2019

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Context and Motivation  . . . . . . . . . . . . . . . . .   2
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  General Requirements  . . . . . . . . . . . . . . . . . .   7
     2.2.  Signal Channel Requirements . . . . . . . . . . . . . . .   8
     2.3.  Data Channel Requirements . . . . . . . . . . . . . . . .  13
     2.4.  Security Requirements . . . . . . . . . . . . . . . . . .  14
     2.5.  Data Model Requirements . . . . . . . . . . . . . . . . .  16
   3.  Congestion Control Considerations . . . . . . . . . . . . . .  17
     3.1.  Signal Channel  . . . . . . . . . . . . . . . . . . . . .  17
     3.2.  Data Channel  . . . . . . . . . . . . . . . . . . . . . .  17
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  21
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

1.1.  Context and Motivation

   Distributed Denial-of-Service (DDoS) attacks afflict networks
   connected to the Internet, plaguing network operators at service
   providers and enterprises around the world.  High-volume attacks
   saturating inbound links are now common as attack scale and frequency
   continue to increase.

   The prevalence and impact of these DDoS attacks has led to an
   increased focus on coordinated attack response.  However, many
   enterprises lack the resources or expertise to operate on-premise
   attack mitigation solutions themselves, or are constrained by local
   bandwidth limitations.  To address such gaps, service providers have
   begun to offer on-demand traffic scrubbing services, which are
   designed to separate the DDoS attack traffic from legitimate traffic
   and forward only the latter.

   Today, these services offer proprietary interfaces for subscribers to
   request attack mitigation.  Such proprietary interfaces tie a
   subscriber to a service and limit the abilities of network elements
   that would otherwise be capable of participating in attack
   mitigation.  As a result of signaling interface incompatibility,

Mortensen, et al.             Informational                     [Page 2]