Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
draft-ietf-dots-requirements-22

Document Type Active Internet-Draft (dots WG)
Last updated 2019-04-09 (latest revision 2019-03-25)
Stream IETF
Intended RFC status Informational
Formats plain text xml pdf html bibtex
Reviews
Stream WG state Submitted to IESG for Publication (wg milestone: Dec 2017 - Requirements documen... )
Document shepherd Liang Xia
Shepherd write-up Show (last changed 2018-08-30)
IESG IESG state RFC Ed Queue
Consensus Boilerplate Yes
Telechat date
Responsible AD Benjamin Kaduk
Send notices to Liang Xia <frank.xialiang@huawei.com>
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions
RFC Editor RFC Editor state EDIT
DOTS                                                        A. Mortensen
Internet-Draft                                            Arbor Networks
Intended status: Informational                                  T. Reddy
Expires: September 24, 2019                                       McAfee
                                                            R. Moskowitz
                                                                  Huawei
                                                          March 23, 2019

Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
                    draft-ietf-dots-requirements-22

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 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 https://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 24, 2019.

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

Mortensen, et al.      Expires September 24, 2019               [Page 1]
Internet-Draft              DOTS Requirements                 March 2019

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

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.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  18
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  19
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   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-premises
   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

Mortensen, et al.      Expires September 24, 2019               [Page 2]
Show full document text