DDoS Open Threat Signaling (DOTS) Requirements
RFC 8612
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]
Show full document text