Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
draft-ietf-dots-signal-channel-41

DOTS                                                       T. Reddy, Ed.
Internet-Draft                                                    McAfee
Intended status: Standards Track                       M. Boucadair, Ed.
Expires: April 20, 2020                                           Orange
                                                                P. Patil
                                                                   Cisco
                                                            A. Mortensen
                                                    Arbor Networks, Inc.
                                                               N. Teague
                                              Iron Mountain Data Centers
                                                        October 18, 2019


   Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
                         Channel Specification
                   draft-ietf-dots-signal-channel-38

Abstract

   This document specifies the DOTS signal channel, a protocol for
   signaling the need for protection against Distributed Denial-of-
   Service (DDoS) attacks to a server capable of enabling network
   traffic mitigation on behalf of the requesting client.

   A companion document defines the DOTS data channel, a separate
   reliable communication layer for DOTS management and configuration
   purposes.

Editorial Note (To be removed by RFC Editor)

   Please update these statements within the document with the RFC
   number to be assigned to this document:

   o  "This version of this YANG module is part of RFC XXXX;"

   o  "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
      (DOTS) Signal Channel Specification";

   o  "| [RFCXXXX] |"

   o  reference: RFC XXXX

   Please update this statement with the RFC number to be assigned to
   the following documents:

   o  "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
      (DOTS) Data Channel Specification (used to be I-D.ietf-dots-data-
      channel)



Reddy, et al.            Expires April 20, 2020                 [Page 1]


Internet-Draft        DOTS Signal Channel Protocol          October 2019


   Please update TBD/TBD1/TBD2 statements with the assignments made by
   IANA to DOTS Signal Channel Protocol.

   Also, please update the "revision" date of the YANG modules.

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 20, 2020.

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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Design Overview . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  DOTS Signal Channel: Messages & Behaviors . . . . . . . . . .   9
     4.1.  DOTS Server(s) Discovery  . . . . . . . . . . . . . . . .   9
     4.2.  CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.3.  Happy Eyeballs for DOTS Signal Channel  . . . . . . . . .  10
     4.4.  DOTS Mitigation Methods . . . . . . . . . . . . . . . . .  12
       4.4.1.  Request Mitigation  . . . . . . . . . . . . . . . . .  13



Reddy, et al.            Expires April 20, 2020                 [Page 2]


Internet-Draft        DOTS Signal Channel Protocol          October 2019


       4.4.2.  Retrieve Information Related to a Mitigation  . . . .  29
         4.4.2.1.  DOTS Servers Sending Mitigation Status  . . . . .  34
         4.4.2.2.  DOTS Clients Polling for Mitigation Status  . . .  37
       4.4.3.  Efficacy Update from DOTS Clients . . . . . . . . . .  38
       4.4.4.  Withdraw a Mitigation . . . . . . . . . . . . . . . .  40
     4.5.  DOTS Signal Channel Session Configuration . . . . . . . .  41
       4.5.1.  Discover Configuration Parameters . . . . . . . . . .  43
       4.5.2.  Convey DOTS Signal Channel Session Configuration  . .  47
       4.5.3.  Configuration Freshness and Notifications . . . . . .  53
       4.5.4.  Delete DOTS Signal Channel Session Configuration  . .  54
     4.6.  Redirected Signaling  . . . . . . . . . . . . . . . . . .  55
     4.7.  Heartbeat Mechanism . . . . . . . . . . . . . . . . . . .  57
   5.  DOTS Signal Channel YANG Modules  . . . . . . . . . . . . . .  58
     5.1.  Tree Structure  . . . . . . . . . . . . . . . . . . . . .  59
     5.2.  IANA DOTS Signal Channel YANG Module  . . . . . . . . . .  61
     5.3.  IETF DOTS Signal Channel YANG Module  . . . . . . . . . .  65
   6.  YANG/JSON Mapping Parameters to CBOR  . . . . . . . . . . . .  75
   7.  (D)TLS Protocol Profile and Performance Considerations  . . .  77
     7.1.  (D)TLS Protocol Profile . . . . . . . . . . . . . . . . .  77
     7.2.  (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . .  79
     7.3.  DTLS MTU and Fragmentation  . . . . . . . . . . . . . . .  81
   8.  Mutual Authentication of DOTS Agents & Authorization of DOTS
       Clients . . . . . . . . . . . . . . . . . . . . . . . . . . .  82
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  84
     9.1.  DOTS Signal Channel UDP and TCP Port Number . . . . . . .  84
     9.2.  Well-Known 'dots' URI . . . . . . . . . . . . . . . . . .  84
     9.3.  Media Type Registration . . . . . . . . . . . . . . . . .  84
     9.4.  CoAP Content-Formats Registration . . . . . . . . . . . .  85
     9.5.  CBOR Tag Registration . . . . . . . . . . . . . . . . . .  85
     9.6.  DOTS Signal Channel Protocol Registry . . . . . . . . . .  86
       9.6.1.  DOTS Signal Channel CBOR Key Values Sub-Registry  . .  86
         9.6.1.1.  Registration Template . . . . . . . . . . . . . .  86
         9.6.1.2.  Initial Sub-Registry Content  . . . . . . . . . .  87
       9.6.2.  Status Codes Sub-Registry . . . . . . . . . . . . . .  89
       9.6.3.  Conflict Status Codes Sub-Registry  . . . . . . . . .  90
       9.6.4.  Conflict Cause Codes Sub-Registry . . . . . . . . . .  92
       9.6.5.  Attack Status Codes Sub-Registry  . . . . . . . . . .  92
     9.7.  DOTS Signal Channel YANG Modules  . . . . . . . . . . . .  93
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  94
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  96
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  97
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  97
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  97
     13.2.  Informative References . . . . . . . . . . . . . . . . . 100
   Appendix A.  CUID Generation  . . . . . . . . . . . . . . . . . . 105
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 105





Reddy, et al.            Expires April 20, 2020                 [Page 3]


Internet-Draft        DOTS Signal Channel Protocol          October 2019


1.  Introduction

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

   Network applications have finite resources like CPU cycles, the
   number of processes or threads they can create and use, the maximum
   number of simultaneous connections they can handle, the limited
   resources of the control plane, etc.  When processing network
   traffic, such applications are supposed to use these resources to
   provide the intended functionality in the most efficient manner.
   However, a DDoS attacker may be able to prevent an application from
   performing its intended task by making the application exhaust its
   finite resources.

   A TCP DDoS SYN-flood [RFC4987], for example, is a memory-exhausting
   attack while an ACK-flood is a CPU-exhausting attack.  Attacks on the
   link are carried out by sending enough traffic so that the link
   becomes congested, thereby likely causing packet loss for legitimate
   traffic.  Stateful firewalls can also be attacked by sending traffic
   that causes the firewall to maintain an excessive number of states
   that may jeopardize the firewall's operation overall, besides likely
   performance impacts.  The firewall then runs out of memory, and can
   no longer instantiate the states required to process legitimate
   flows.  Other possible DDoS attacks are discussed in [RFC4732].

   In many cases, it may not be possible for network administrators to
   determine the cause(s) of an attack.  They may instead just realize
   that certain resources seem to be under attack.  This document
   defines a lightweight protocol that allows a DOTS client to request
   mitigation from one or more DOTS servers for protection against
   detected, suspected, or anticipated attacks.  This protocol enables
   cooperation between DOTS agents to permit a highly-automated network
   defense that is robust, reliable, and secure.  Note that "secure"
   means the support of the features defined in Section 2.4 of
   [RFC8612].

   An example of a network diagram that illustrates a deployment of DOTS
   agents is shown in Figure 1.  In this example, a DOTS server is
   operating on the access network.  A DOTS client is located on the LAN
   (Local Area Network), while a DOTS gateway is embedded in the CPE
   (Customer Premises Equipment).




Reddy, et al.            Expires April 20, 2020                 [Page 4]


Internet-Draft        DOTS Signal Channel Protocol          October 2019


      Network
      Resource        CPE router         Access network     __________
    +-----------+   +--------------+    +-------------+    /          \
    |           |___|              |____|             |___ | Internet |
    |DOTS client|   | DOTS gateway |    | DOTS server |    |          |
    |           |   |              |    |             |    |          |
    +-----------+   +--------------+    +-------------+    \__________/

                   Figure 1: Sample DOTS Deployment (1)

   DOTS servers can also be reachable over the Internet, as depicted in
   Figure 2.

      Network                                           DDoS mitigation
      Resource          CPE router      __________        service
    +-----------+   +-------------+    /          \    +-------------+
    |           |___|             |____|          |___ |             |
    |DOTS client|   |DOTS gateway |    | Internet |    | DOTS server |
    |           |   |             |    |          |    |             |
    +-----------+   +-------------+    \__________/    +-------------+

                   Figure 2: Sample DOTS Deployment (2)

   In typical deployments, the DOTS client belongs to a different
   administrative domain than the DOTS server.  For example, the DOTS
   client is embedded in a firewall protecting services owned and
   operated by a customer, while the DOTS server is owned and operated
   by a different administrative entity (service provider, typically)
   providing DDoS mitigation services.  The latter might or might not
   provide connectivity services to the network hosting the DOTS client.

   The DOTS server may (not) be co-located with the DOTS mitigator.  In
   typical deployments, the DOTS server belongs to the same
   administrative domain as the mitigator.  The DOTS client can
   communicate directly with a DOTS server or indirectly via a DOTS
   gateway.

   The document adheres to the DOTS architecture
   [I-D.ietf-dots-architecture].  The requirements for DOTS signal
   channel protocol are documented in [RFC8612].  This document
   satisfies all the use cases discussed in [I-D.ietf-dots-use-cases].

   This document focuses on the DOTS signal channel.  This is a
   companion document of the DOTS data channel specification
   [I-D.ietf-dots-data-channel] that defines a configuration and a bulk
   data exchange mechanism supporting the DOTS signal channel.





Reddy, et al.            Expires April 20, 2020                 [Page 5]


Internet-Draft        DOTS Signal Channel Protocol          October 2019


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   (D)TLS is used for statements that apply to both Transport Layer
   Security [RFC5246][RFC8446] and Datagram Transport Layer Security
   [RFC6347].  Specific terms are used for any statement that applies to
   either protocol alone.

   The reader should be familiar with the terms defined in [RFC8612].

   The