Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification
RFC 8783

Document Type RFC - Proposed Standard (May 2020; No errata)
Last updated 2020-05-30
Replaces draft-reddy-dots-data-channel
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Yang Validation 0 errors, 0 warnings.
Reviews
Additional Resources
- Yang catalog entry for ietf-dots-data-channel@2019-05-09.yang
- Yang impact analysis for draft-ietf-dots-data-channel
- Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Roman Danyliw
Shepherd write-up Show (last changed 2019-02-27)
IESG IESG state RFC 8783 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Benjamin Kaduk
Send notices to Roman Danyliw <rdd@cert.org>
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack


Internet Engineering Task Force (IETF)                 M. Boucadair, Ed.
Request for Comments: 8783                                        Orange
Category: Standards Track                                T. Reddy.K, Ed.
ISSN: 2070-1721                                                   McAfee
                                                                May 2020

Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel
                             Specification

Abstract

   The document specifies a Distributed Denial-of-Service Open Threat
   Signaling (DOTS) data channel used for bulk exchange of data that
   cannot easily or appropriately communicated through the DOTS signal
   channel under attack conditions.

   This is a companion document to "Distributed Denial-of-Service Open
   Threat Signaling (DOTS) Signal Channel Specification" (RFC 8782).

Status of This Memo

   This is an Internet Standards Track document.

   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).  Further information on
   Internet Standards is available in 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/rfc8783.

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.  Introduction
   2.  Terminology
   3.  DOTS Data Channel
     3.1.  Design Overview
     3.2.  DOTS Server(s) Discovery
     3.3.  DOTS Gateways
     3.4.  Detecting and Preventing Infinite Loops
     3.5.  Preventing Stale Entries
   4.  DOTS Data Channel YANG Module
     4.1.  Generic Tree Structure
     4.2.  Filtering Fields
     4.3.  YANG Module
   5.  Managing DOTS Clients
     5.1.  Registering DOTS Clients
     5.2.  De-registering DOTS Clients
   6.  Managing DOTS Aliases
     6.1.  Creating Aliases
     6.2.  Retrieving Installed Aliases
     6.3.  Deleting Aliases
   7.  Managing DOTS Filtering Rules
     7.1.  Retrieving DOTS Filtering Capabilities
     7.2.  Installing Filtering Rules
     7.3.  Retrieving Installed Filtering Rules
     7.4.  Removing Filtering Rules
   8.  Operational Considerations
   9.  IANA Considerations
   10. Security Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Appendix A.  Examples: Filtering Fragments
   Appendix B.  Examples: Filtering TCP Messages
     B.1.  Discard TCP Null Attack
     B.2.  Rate-Limit SYN Flooding
     B.3.  Rate-Limit ACK Flooding
   Acknowledgements
   Contributors
   Authors' Addresses

1.  Introduction

   A distributed denial-of-service (DDoS) attack is an attempt to make
   machines or network resources unavailable to their intended users.
   In most cases, sufficient scale can be achieved by compromising
   enough end hosts and using those infected hosts to perpetrate and
   amplify the attack.  The victim of such an attack can be an
   application server, a router, a firewall, an entire network, etc.

   As discussed in [RFC8612], the lack of a common method to coordinate
   a real-time response among involved actors and network domains
   inhibits the speed and effectiveness of DDoS attack mitigation.  From
   that standpoint, DDoS Open Threat Signaling (DOTS) defines an
   architecture that allows a DOTS client to send requests to a DOTS
   server for DDoS attack mitigation [DOTS-ARCH].  The DOTS approach is
   thus meant to minimize the impact of DDoS attacks, thereby
   contributing to the enforcement of more efficient defensive if not
   proactive security strategies.  To that aim, DOTS defines two
   channels: the signal channel and the data channel (Figure 1).

   +---------------+                                 +---------------+
   |               | <------- Signal Channel ------> |               |
   |  DOTS Client  |                                 |  DOTS Server  |
   |               | <=======  Data Channel  ======> |               |
   +---------------+                                 +---------------+

                          Figure 1: DOTS Channels

   The DOTS signal channel is used to carry information about a device
Show full document text