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

Document Type Active Internet-Draft (dots WG)
Last updated 2018-11-03 (latest revision 2018-10-22)
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 In Last Call (ends 2018-11-23)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Benjamin Kaduk
Send notices to Liang Xia <frank.xialiang@huawei.com>
IANA IANA review state IANA OK - No Actions Needed
IANA action state None
DOTS                                                        A. Mortensen
Internet-Draft                                            Arbor Networks
Intended status: Informational                              R. Moskowitz
Expires: April 25, 2019                                           Huawei
                                                                T. Reddy
                                                                  McAfee
                                                        October 22, 2018

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

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 April 25, 2019.

Copyright Notice

   Copyright (c) 2018 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 April 25, 2019                 [Page 1]
Internet-Draft              DOTS Requirements               October 2018

   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  . . . . . . . . . . . . . . . . . .   6
     2.2.  Signal Channel Requirements . . . . . . . . . . . . . . .   7
     2.3.  Data Channel Requirements . . . . . . . . . . . . . . . .  12
     2.4.  Security Requirements . . . . . . . . . . . . . . . . . .  13
     2.5.  Data Model Requirements . . . . . . . . . . . . . . . . .  15
   3.  Congestion Control Considerations . . . . . . . . . . . . . .  16
     3.1.  Signal Channel  . . . . . . . . . . . . . . . . . . . . .  16
     3.2.  Data Channel  . . . . . . . . . . . . . . . . . . . . . .  16
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  17
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

1.1.  Context and Motivation

   Distributed Denial of Service (DDoS) attacks afflict networks of all
   kinds, 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 while also limiting the network elements

Mortensen, et al.        Expires April 25, 2019                 [Page 2]
Show full document text