Internet DRAFT - draft-hayashi-dots-telemetry-use-cases

draft-hayashi-dots-telemetry-use-cases







DOTS                                                          Y. Hayashi
Internet-Draft                                                       NTT
Intended status: Informational                                   M. Chen
Expires: September 3, 2020                                          CMCC
                                                           March 2, 2020


       Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry
               draft-hayashi-dots-telemetry-use-cases-00

Abstract

   Denial-of-service Open Threat Signaling (DOTS) Telemetry enriches the
   base DOTS protocols to assist the mitigator in using efficient DDoS-
   attack-mitigation techniques in a network.  This document presents
   sample use cases for DOTS Telemetry: what components are deployed in
   the network, how they cooperate, and what information is exchanged to
   effectively use these techniques.

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

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



Hayashi & Chen          Expires September 3, 2020               [Page 1]

Internet-Draft          DOTS Telemetry Use Cases              March 2020


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  DDoS Mitigation Based on Attack Traffic Bandwidth . . . .   3
       3.1.1.  Mitigating Attack Flow of Top-talker Preferentially .   3
       3.1.2.  Optimal DMS Selection for Mitigation  . . . . . . . .   5
       3.1.3.  Best-path Selection for Redirection . . . . . . . . .   6
       3.1.4.  Short but Extreme Volumetric Attack Mitigation  . . .   8
     3.2.  DDoS Mitigation Based on Attack Type  . . . . . . . . . .   9
       3.2.1.  Selecting Mitigation Technique  . . . . . . . . . . .   9
     3.3.  Training Flow Collector Using Supervised Machine Learning  11
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   6.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Denial-of-Service (DDoS), attacks such as volumetric attacks and
   resource-consumption attacks, are critical threats to be handled by
   service providers.  When such DDoS attacks occur, service providers
   have to mitigate them immediately to protect or recover their
   services.

   Therefore, for service providers to immediately protect their network
   services from DDoS attacks, DDoS mitigation needs to be automated.
   To automate DDoS-attack mitigation, multi-vendor components involved
   in DDoS-attack detection and mitigation should cooperate and support
   standard interfaces to communicate.

   DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time
   signaling, threat-handling requests, and data filtering between the
   multi-vendor elements
   [I-D.ietf-dots-signal-channel][I-D.ietf-dots-data-channel].
   Furthermore, DOTS Telemetry enriches the DOTS protocols with various
   telemetry attributes allowing optimal DDoS-attack mitigation
   [I-D.ietf-dots-telemetry].  This document presents sample use cases
   for DOTS Telemetry: what components are deployed in the network, how
   they cooperate, and what information is exchanged to effectively use
   attack-mitigation techniques.



Hayashi & Chen          Expires September 3, 2020               [Page 2]

Internet-Draft          DOTS Telemetry Use Cases              March 2020


2.  Terminology

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

   In addition, this document uses the following terms:

   Top-talker:  A top N list of attackers who attack the same target or
      targets.  The list is ordered in terms of a two-tuple bandwidth
      such as bps or pps.

   Supervised Machine Learning:  A machine-learning technique that maps
      an input to an output based on example input-output pairs

3.  Use Cases

   This section describes DOTS-Telemetry use cases that use attributes
   included in DOTS Telemetry specifications.

3.1.  DDoS Mitigation Based on Attack Traffic Bandwidth

3.1.1.  Mitigating Attack Flow of Top-talker Preferentially

   Large-scale DDoS attacks, such as amplification attacks, often occur.
   Some transit providers have to mitigate large-scale DDoS attacks
   using DMS with limited resources, which is already deployed in their
   network.

   The aim of this use case is to enable transit providers to use their
   DMS efficiently under volume-based DDoS attacks whose bandwidth is
   more than the available capacity of the DMS.  To enable this, attack
   traffic of top talkers is redirected to the DMS preferentially by
   cooperation among forwarding nodes, flow collectors, and
   orchestrators.  Figure 1 gives an overview of this use case.


















Hayashi & Chen          Expires September 3, 2020               [Page 3]

Internet-Draft          DOTS Telemetry Use Cases              March 2020


   (Internet Transit Provider)

                  +-----------+      +--------------+ e.g., SNMP
     e.g., IPFIX +-----------+| DOTS |              |<---
             --->| Flow      ||C<-->S| Orchestrator | e.g., BGP Flowspec
                 | collector |+      |              |--->   (Redirect)
                 +-----------+       +--------------+

                            +-------------+
               e.g., IPFIX +-------------+| e.g., BGP Flowspec
                       <---| Forwarding  ||<---   (Redirect)
                           |    nodes    ||
                           |             ||           DDoS Attack
   [ Target  ]<============|===============================
   [   or    ]             |    ++=========================[top talker]
   [ Targets ]             |    || ++======================[top talker]
                           +----|| ||---+
                                || ||
                                || ||
                                |/ |/
                           +----x--x----+
                           | DDoS       | e.g., SNMP
                           | mitigation |<---
                           | system     |
                           +------------+

   * C is for DOTS client functionality
   * S is for DOTS client functionality

   Figure 1: Mitigating DDoS Attack Flow of Top-talker Preferentially


   In this use case, the forwarding nodes always send statistics of
   traffic flow to the flow collectors by using monitoring functions
   such as IPFIX[RFC7011].  When DDoS attacks occur, the flow collectors
   detect attack traffic and send (src_ip, dst_ip, bandwidth)-tuple
   information of the top talker to the orchestrator using the top-
   talkers attribute of DOTS Telemetry.  The orchestrator then checks
   the available capacity of DMS by using a network management protocol
   such as SNMP[RFC3413].  After that, the orchestrator orders
   forwarding nodes to redirect as much of the top taker's traffic to
   the DMS as possible by dissemination of flow-specification-rule
   protocols such as BGP Flowspec[RFC5575].

   In this case, the flow collector implements a DOTS client while the
   orchestrator implements a DOTS server.





Hayashi & Chen          Expires September 3, 2020               [Page 4]

Internet-Draft          DOTS Telemetry Use Cases              March 2020


3.1.2.  Optimal DMS Selection for Mitigation

   Transit providers, which have a number of DMSs, usually deploy a DMS
   in various forms to satisfy their requirements; individual or
   clustered.  In both forms, they can identify attributes of the DMSs
   such as total capacity, available capacity, and the last hop
   bandwidth.

   The aim of this use case is to enable transit providers to select an
   optimal DMS for mitigation based on the bandwidth of attack traffic,
   capacity of a DMS, and the last hop bandwidth.  Figure 2 gives an
   overview of this use case.

   (Internet Transit Provider)

                  +-----------+      +--------------+ e.g., SNMP
     e.g., IPFIX +-----------+| DOTS |              |<---
             --->| Flow      ||C<-->S| Orchestrator | e.g., BGP
                 | collector |+      |              |--->   (Redirect)
                 +-----------+       +--------------+

                            +------------+
               e.g., IPFIX +------------+| e.g., BGP
                       <---| Forwarding ||<---   (Redirect)
                           |    nodes   ||
                           |            ||            DDoS Attack
   [Target]                | ++============================
   [Target]                | ||  ++========================
                           +-||--||-----+
                             ||  ||
                       ++====++  ||  (congested DMS)
                       ||        ||  +-----------+
                       ||        |/  |      DMS3 |
                       ||  +-----x------+        |<--- e.g., SNMP
                       |/  |       DMS2 |--------+
                    +--x---------+      |<--- e.g., SNMP
                    |       DMS1 |------+
                    |            |<--- e.g., SNMP
                    +------------+

   * C is for DOTS client functionality
   * S is for DOTS client functionality

   Figure 2: Optimal DMS selection for Mitigation

   In this use case, the forwarding nodes always send statistics of
   traffic flow to the flow collectors by using monitoring functions
   such as IPFIX[RFC7011].  When DDoS attacks occur, the flow collectors



Hayashi & Chen          Expires September 3, 2020               [Page 5]

Internet-Draft          DOTS Telemetry Use Cases              March 2020


   detect attack traffic and send (dst_ip, bandwidth)-tuple information
   to the orchestrator using the total-attack-traffic attribute of DOTS
   Telemetry.  The orchestrator then checks the available capacity of
   the DMSs by using a network management protocol such as
   SNMP[RFC3413].  After that, the orchestrator chooses optimal DMS
   which each attack traffic should be redirected.  The orchestrator
   then orders forwarding nodes to redirect the attack traffic to the
   optimal DMS by a routing protocol such as BGP[RFC4271].  The
   algorithm of selecting a DMS is out of the scope of this draft.

   In this case, the flow collector implements a DOTS client while the
   orchestrator implements a DOTS server.

3.1.3.  Best-path Selection for Redirection

   A transit-provider network, which adopts a mesh network, has multiple
   paths to convey attack traffic to a DMS.  In this network, attack
   traffic can be conveyed while avoiding congested links by selecting
   an available path.

   The aim of this use case is to enable transit providers to select an
   optimal path for redirecting attack traffic to a DMS according to the
   bandwidth of the attack traffic, total traffic, and total pipe
   capability.  Figure 3 gives an overview of this use case.



























Hayashi & Chen          Expires September 3, 2020               [Page 6]

Internet-Draft          DOTS Telemetry Use Cases              March 2020


   (Internet Transit Provider)

             +-----------+      +--------------+ DOTS
     e.g.,  +-----------+|      |              |S<---
      IPFIX | Flow      || DOTS | Orchestrator |
         -->| collector ||C<-->S|              | e.g., BGP Flow spec
            |           |+      |              |--->   (Redirect)
            +-----------+       +--------------+

                  DOTS +------------+  DOTS +------------+ e.g., IPFIX
                  --->C| Forwarding |  --->C| Forwarding |--->
   e.g., BGP Flow spec |   node     |       |   node     |
        (Redirect) --->|            |       |            |  DDoS Attack
   [Target]            |       ++====================================
                       +-------||---+       +------------+
                               ||              /
                               ||             / (congested link)
                               ||            /
                       DOTS  +-||----------------+ e.g., BGP Flow spec
                        --->C| ||  Forwarding    |<---   (Redirect)
                             | ++===  node       |
                             +----||-------------+
                                  |/
                               +--x-----------+
                               |     DMS      |
                               +--------------+

   * C is for DOTS client functionality
    * S is for DOTS client functionality

   Figure 3: Best-path Selection for Redirection

   In this use case, the forwarding nodes always send statistics of
   traffic flow to the flow collectors by using monitoring functions
   such as IPFIX[RFC7011].  When DDoS attacks occur, the flow collectors
   detect attack traffic and send (dst_ip, bandwidth)-tuple information
   to the orchestrator using a total-attack-traffic attribute of DOTS
   Telemetry.  On the other hands, forwarding nodes send bandwidth of
   total traffic passing the node and total pipe capability to the
   orchestrator using total-traffic and total-pipe-capability attributes
   of DOTS Telemetry.  The orchestrator then selects an optimal path to
   which each attack-traffic flow should be redirected.  After that, the
   orchestrator orders forwarding nodes to redirect the attack traffic
   to the optimal DMS by dissemination of flow-specification-rules
   protocols such as BGP Flowspec[RFC5575].  The algorithm of selecting
   a path is out of the scope of this draft.





Hayashi & Chen          Expires September 3, 2020               [Page 7]

Internet-Draft          DOTS Telemetry Use Cases              March 2020


3.1.4.  Short but Extreme Volumetric Attack Mitigation

   Short but extreme volumetric attacks, such as pulse wave DDoS
   attacks, are threats to internet transit provider networks.  It is
   difficult for them to mitigate an attack by DMS by redirecting attack
   flows because it may cause route flapping in the network.  The
   practical way to mitigate short but extreme volumetric attacks is to
   offload a mitigation actions to a forwarding node.

   The aim of this use case is to enable transit providers to mitigate
   short but extreme volumetric attacks and estimate the network-access
   success rate based on the bandwidth of attack traffic and total pipe
   capability.  Figure 4 gives an overview of this use case.

   (Internet Transit Provider)

             +------------+       +----------------+
   e.g.,     | Network    |  DOTS | Administrative |
   Alert --->| Management |C<--->S| System         | e.g., BGP Flow spec
             | System     |       |                |--->   (Rate-Limit)
             +------------+       +----------------+

               +------------+     +------------+ e.g., BGP Flow spec
               | Forwarding |     | Forwarding |<---  (Rate-Limit X bps)
               |   node     |     |   node     |
               |            |     |            | DDoS & Normal traffic
   [Target]<------------------------------------================
   Pipe        +------------+     +------------+  Attack Traffic
   Capability                                     Bandwidth
   e.g., X bps                                    e.g., Y bps

                       Network access success rate
                           e.g., X / (X + Y)

   * C is for DOTS client functionality
   * S is for DOTS client functionality

   Figure 4: Short but Extreme Volumetric Attack Mitigation


   In this use case, when DDoS attacks occur, the network management
   system receives alerts.  It then sends the target ip address, pipe
   capability of the target's link, and bandwidth of the DDoS attack
   traffic to the administrative system using the target, total-pipe-
   capability and total-attack-traffic attributes of DOTS Telemetry.
   After that, the administrative system orders upper forwarding nodes
   to carry out rate-limit all traffic destined to the target based on
   the pipe capability by the dissemination of the flow -specification-



Hayashi & Chen          Expires September 3, 2020               [Page 8]

Internet-Draft          DOTS Telemetry Use Cases              March 2020


   rules protocols such as BGP Flowspec[RFC5575].  In addition, the
   administrative system estimates the network-access success rate of
   the target, which is calculated by total pipe capability / (total
   pipe capability + total attack traffic).

3.2.  DDoS Mitigation Based on Attack Type

3.2.1.  Selecting Mitigation Technique

   Some volumetric attacks, such as amplification attacks, can be
   detected with high accuracy by checking the layer-3 or layer-4
   information of attack packets.  These attacks can be detected and
   mitigated through cooperation among forwarding nodes and flow
   collectors using IPFIX[RFC7011].  On the other hand, it is necessary
   to inspect the layer-7 information of attack packets to detect
   attacks such as DNS Water Torture Attacks.  Such attack traffic
   should be detected and mitigated at a DMS.

   The aim of this use case is to enable transit providers to select a
   mitigation technique based on the type of attack traffic:
   amplification attack or not.  To use such a technique, attack traffic
   is blocked at forwarding nodes or redirected to a DMS based on attack
   type through cooperation among forwarding nodes, flow collectors, and
   an orchestrator.  Figure 5 gives an overview of this use case.



























Hayashi & Chen          Expires September 3, 2020               [Page 9]

Internet-Draft          DOTS Telemetry Use Cases              March 2020


   (Internet Transit Provider)

            +-----------+ DOTS +--------------+ e.g.,
     e.g., +-----------+|<---->|              | BGP (Redirect)
     IPFIX | Flow      ||C    S| Orchestrator | BGP Flowspec (Drop)
       --->| collector |+      |              |--->
           +-----------+       +--------------+

                       +------------+ e.g., BGP (Redirect)
          e.g., IPFIX +------------+|       BGP Flowspec (Drop)
                  <---| Forwarding ||<---
                      |    nodes   ||              DDoS Attack
                      |     ++=====||================
                      |     ||     ||x<==============[e.g.,DNS Amp]
                      |     ||     |+x<==============[e.g.,NTP Amp]
                      +-----||-----+
                            ||
                            |/
                      +-----x------+
                      | DDoS       |
                      | mitigation |
                      | system     |
                      +------------+

   * C is for DOTS client functionality
   * S is for DOTS server functionality

   Figure 5: DDoS Mitigation Based on Attack Type


   In this use case, the forwarding nodes send statistics of traffic
   flow to the flow collectors by using a monitoring function such as
   IPFIX[RFC7011].  When DDoS attacks occur, the flow collectors detect
   attack traffic and send (dst_ip, src_port, attack_type)-tuple
   information to the orchestrator the using attack-name attribute of
   DOTS Telemetry.  The orchestrator then orders forwarding nodes to
   block the (dst_ip, src_port)-tuple flow of amp attack traffic by
   dissemination of flow-specification-rule protocols such as BGP
   Flowspec[RFC5575].  On the other hand, the orchestrator orders
   forwarding nodes to redirect other traffic than the amp attack
   traffic by a routing protocol such as BGP[RFC4271].

   In this case, the flow collector implements a DOTS client while the
   orchestrator implements a DOTS server.







Hayashi & Chen          Expires September 3, 2020              [Page 10]

Internet-Draft          DOTS Telemetry Use Cases              March 2020


3.3.  Training Flow Collector Using Supervised Machine Learning

   DDoS detection based on monitoring functions, such as IPFIX[RFC7011],
   is a lighter weight method of detecting DDoS attacks than DMSs in
   internet transit provider networks.  On the other hand, DDoS
   detection based on the DMSs is a more accurate method of detecting
   DDoS attacks than DDoS detection based on flow monitoring.

   The aim of this use case is to increases flow collector's detection
   accuracy by carrying out supervised machine-learning techniques based
   on the detection results of the DMSs.  To use such a technique,
   forwarding nodes, flow collector, and a DMS should cooperate.
   Figure 5 gives an overview of this use case.


                                   +-----------+
                                  +-----------+| DOTS
                      e.g., IPFIX | Flow      ||S<---
                              --->| collector ||
                                  +-----------++

                                   +------------+
                      e.g., IPFIX +------------+|
                              <---| Forwarding ||
                                  |    nodes   ||           DDoS Attack
    [ Target ]                    |   ++==============================
                                  |   || ++===========================
                                  |   || || ++========================
                                  +---||-|| ||-+
                                      || || ||
                                      |/ |/ |/
                            DOTS  +---X--X--X--+
                             --->C| DDoS       |
                                  | mitigation |
                                  | system     |
                                  +------------+

           * C is for DOTS client functionality
           * S is for DOTS client functionality

   Figure 6: Training Flow Collector Using Supervised Machine Learning

   In this use case, the forwarding nodes always send statistics of
   traffic flow to the flow collectors by using monitoring functions
   such as IPFIX[RFC7011].  When DDoS attacks occur, DDoS orchestration
   use case[I-D.ietf-dots-use-cases] is carried out and the DMS
   mitigates all attack traffic destined for a target.  The DDoS-
   mitigation system reports the (src_ip, dst_ip)-tuple information of



Hayashi & Chen          Expires September 3, 2020              [Page 11]

Internet-Draft          DOTS Telemetry Use Cases              March 2020


   the top talker to the orchestrator the using top-talkers attribute of
   DOTS Telemetry.

   After mitigating a DDoS attack, the flow collector attaches teacher
   labels to the statistics of traffic flow based on the reports.  The
   label shows normal traffic or attack name.  The flow collector then
   carries out supervised machine learning to increase its detection
   accuracy, setting the statistics as an explanatory variable and
   setting the labels as an objective variable.

   In this case, the DMS implements a DOTS client while the flow
   collector implements a DOTS server.

4.  Security Considerations

   TBD

5.  IANA Considerations

   This document does not require any action from IANA.

6.  Acknowledgement

   The authors would like to thank among others brabra...

7.  References

7.1.  Normative References

   [I-D.ietf-dots-telemetry]
              Boucadair, M., Reddy.K, T., Doron, E., and c. chenmeiling,
              "Distributed Denial-of-Service Open Threat Signaling
              (DOTS) Telemetry", draft-ietf-dots-telemetry-02 (work in
              progress), February 2020.

   [I-D.ietf-dots-use-cases]
              Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
              L., and K. Nishizuka, "Use cases for DDoS Open Threat
              Signaling", draft-ietf-dots-use-cases-20 (work in
              progress), September 2019.

   [RFC3413]  Levi, D., Meyer, P., and B. Stewart, "Simple Network
              Management Protocol (SNMP) Applications", STD 62,
              RFC 3413, DOI 10.17487/RFC3413, December 2002,
              <https://www.rfc-editor.org/info/rfc3413>.






Hayashi & Chen          Expires September 3, 2020              [Page 12]

Internet-Draft          DOTS Telemetry Use Cases              March 2020


   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC5575]  Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
              and D. McPherson, "Dissemination of Flow Specification
              Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
              <https://www.rfc-editor.org/info/rfc5575>.

   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
              "Specification of the IP Flow Information Export (IPFIX)
              Protocol for the Exchange of Flow Information", STD 77,
              RFC 7011, DOI 10.17487/RFC7011, September 2013,
              <https://www.rfc-editor.org/info/rfc7011>.

   [RFC8612]  Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
              Threat Signaling (DOTS) Requirements", RFC 8612,
              DOI 10.17487/RFC8612, May 2019,
              <https://www.rfc-editor.org/info/rfc8612>.

7.2.  Informative References

   [I-D.ietf-dots-data-channel]
              Boucadair, M. and T. Reddy.K, "Distributed Denial-of-
              Service Open Threat Signaling (DOTS) Data Channel
              Specification", draft-ietf-dots-data-channel-31 (work in
              progress), July 2019.

   [I-D.ietf-dots-signal-channel]
              Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and
              N. Teague, "Distributed Denial-of-Service Open Threat
              Signaling (DOTS) Signal Channel Specification", draft-
              ietf-dots-signal-channel-41 (work in progress), January
              2020.

Authors' Addresses

   Yuhei Hayashi
   NTT
   3-9-11, Midori-cho
   Musashino-shi, Tokyo  180-8585
   Japan

   Email: yuuhei.hayashi@gmail.com






Hayashi & Chen          Expires September 3, 2020              [Page 13]

Internet-Draft          DOTS Telemetry Use Cases              March 2020


   Meiling Chen
   CMCC
   32, Xuanwumen West
   BeiJing, BeiJing  100053
   China

   Email:
            chenmeiling@chinamobile.com











































Hayashi & Chen          Expires September 3, 2020              [Page 14]