Skip to main content

DOTS client carry ddos attack informations in signal channel
draft-chen-dots-attack-informations-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Meiling Chen , Li Su , Jin Peng
Last updated 2019-07-22
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chen-dots-attack-informations-02
DOTS                                                             M. Chen
Internet-Draft                                                    Li. Su
Intended status: Informational                                 Jin. Peng
Expires: January 23, 2020                                           CMCC
                                                           July 22, 2019

      DOTS client carry ddos attack informations in signal channel
                 draft-chen-dots-attack-informations-02

Abstract

   This document describes DDoS attack information which can be obtained
   by DOTS client when the enterprise suspects it is under DDoS attack,
   these informations will be send from DOTS client to DOTS server using
   Signal channel within Mitigation Request.

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 January 23, 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.

Chen, et al.            Expires January 23, 2020                [Page 1]
Internet-Draft          DDoS attack informations               July 2019

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Key Words . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Definition of Terms . . . . . . . . . . . . . . . . . . .   3
   3.  Mitigation Use Case 1 . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Mitigations for attack flow . . . . . . . . . . . . . . .   4
     3.2.  Optimal device selection  . . . . . . . . . . . . . . . .   5
     3.3.  Optimum path for disposal . . . . . . . . . . . . . . . .   5
     3.4.  Mitigation request parameters . . . . . . . . . . . . . .   6
   4.  Mitigation Use Case 2 . . . . . . . . . . . . . . . . . . . .   6
     4.1.  classified disposal . . . . . . . . . . . . . . . . . . .   6
     4.2.  Standard of Attack Type Definition  . . . . . . . . . . .   7
   5.  Mitigation Use Case 3 . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Mitigation alarm baseline . . . . . . . . . . . . . . . .   8
   6.  Mitigation request optional parameters  . . . . . . . . . . .   9
   7.  Mitigation response parameters  . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  11
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     11.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Distributed Denial of Service (DDoS) is a type of resource-consuming
   attack, which exploits a large number of attack resources and uses
   standard protocols to attack target objects.  DDoS attacks consume a
   large amount of target network resources or server resources
   (including computing power, storage capacity, etc.).  At present,
   DDoS attack is one of the most powerful and indefensible attacks on
   the Internet, and due to the extensive use of mobile devices and IoT
   devices in recent years, it is easier for DDoS attackers to attack
   with real attack sources (broilers).

   The IETF is specifying the DDoS Open Threat Signaling (DOTS)
   [I-D.ietf-dots-architecture]architecture, where a DOTS client can
   inform a DOTS server that the network is under a potential attack and
   that appropriate mitigation actions are required.  In the
   architecture draft, it says in the draft the enterprise has a DOTS
   client, which obtains information about the DDoS attack, and signals
   the DOTS server for help in mitigating the attack. but it doesn't
   says what the information of DDoS attack is. the scope of this draft
   is about the information of DDoS attack which DOTS client can obtain.

Chen, et al.            Expires January 23, 2020                [Page 2]
Internet-Draft          DDoS attack informations               July 2019

   In the architecture draft, it says in the draft the client signal may
   also include telemetry information about the attack, if the DOTS
   client has such information available.  But in the signal channel
   draft it doesn't define optional parameter about the telemetry
   information which will be regarded as DDoS portrait information.

   "DDoS portrait information" is defined as the collection of
   attributes characterizing the actual attacks that have been detected
   and mitigated.  The DDoS portrait information is an optional set of
   attributes that can be signaled in the DOTS signal channel.  The
   portrait can be optionally sent from the DOTS Client to Server and
   vice versa.

   This document will divide two directions, before mitigation request
   and after mitigation is complete.  Before mitigation request, DOTS
   client can obtain informations of attack; After mitigation, DOTS
   server can obtain from mitigator.

2.  Terminology

2.1.  Key Words

   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
   [RFC2119]

2.2.  Definition of Terms

   The readers should be familiar with the terms defined in
   [I-D.ietf-dots-requirements] [I-D.ietf-dots-use-cases]

   The terminology related to YANG data modules is defined in [RFC7950]

   In addition, this document uses the terms defined below:

   Attack-bandwidth:  the amount of traffic under attack, it is usually
      expressed numerically.

   Flow clean:  one selection of Attack traffic deposition, the
      operation contains recognize, discard and reinage.

   Attack Type:  used to distinguish between different methods of ddos
      attack.

   Attack type definition:  General definition method, Covers most
      current attack types.

Chen, et al.            Expires January 23, 2020                [Page 3]
Internet-Draft          DDoS attack informations               July 2019

   Attack-source-ip-number:  Number of all attack sources(ip).

   Target-attack-type-threshold:  The DDoS detection device sets a
      threshold for each type of attack, this threshold is usually
      exceeded to generate DDoS alarms.

3.  Mitigation Use Case 1

3.1.  Mitigations for attack flow

   when attack target is under attack, it has to make corresponding
   disposal, there are two options for disposal, one is blackhole
   directly which may be take effect in routers, in this way all the
   attack flow will be discarded by router upper path of attack target,
   this means that the attack target will not receive any traffic during
   the attack depending on the routing strategy, all the traffic
   forwards attack target will be discarded, this has a huge impact on
   the work environment, especially the host that provide external
   service.  The other way of the disposition is to drainage all the
   traffic flow to clean center from router, then the clean center will
   use pattern matching or any other method to find out the attack
   traffic flow to discard, finally, clean center reinage the normal
   business traffic back to attack target by upper router, the whole
   process above is defined as flow clean(Figure 1).

               attack flow +--------+                   +--------+
               ----------->| router |------------------>| clean  |
                 1         +--------+         2         | center |
                            |                           +--------+
                          3 |                               |
                            |       +--------+              |
                            +------>| attack |<-------------+
                                    | target |
                                    +--------+

               Figure 1: diagram of DDoS Mitigation usecase

   Generally, the bandwidth of the link 1 must be larger than link 2 and
   link 3, and the clean ability of clean center limited to hardware
   resources.  An example of link situation is as below(Figure 2):

Chen, et al.            Expires January 23, 2020                [Page 4]
Internet-Draft          DDoS attack informations               July 2019

            +------------+------------+
            |   figure   | bandwidth/ |
            |   tag      | capability |
            +------------+------------+
            |  link 1    | 100Gb      |
            |  link 2    | 50Gb       |
            |  link 3    | 10Gb       |
            |clean center| 80Gb       |
            +------------+------------+

                  Figure 2: an example of link bandwidth

   The Figure2 is a scenario of the link bandwidth, when a ddos attack
   is ongoing, if the link 1 bandwidth is completely jammed, the best
   way to mitigate the attack is to discard all the attack flow; if the
   amount of the traffic flow is lower than the remainder cleaning
   ability, the most suitable disposition is to drainage all the attack
   flow to clean center.  Therefore, it is an obvious requirement in the
   current network environment.

3.2.  Optimal device selection

   Mitigator may owns a cleaning device cluster and can manage cleaning
   devices.  The capacity of each cleaning equipment is variable,
   usually each cleaning equipment utilization rate is different, then
   the remaining cleaning capacity is not consistent.  When the attack
   flow is less than the ability of a cleaning equipment, according to
   the attack-bandwidth can choose a suitable cleaning equipment, that
   is conducive to the utilization of equipment; When the attack flow is
   larger than the cleaning capacity of one cleaning device, several
   cleaning devices can be optimally scheduled according to the attack-
   bandwidth.

3.3.  Optimum path for disposal

   When mitigator is an attack flow cleaning service, they typically
   deployed the mitigator in a distributed way because of the cost of
   bandwidth usage with their own leased operator's link bandwidth, and
   choosing the best traction path was the key to profitability.  If the
   parameter of attack-bandwidth is carried, then the generation of the
   best drainage path is very meaningful.

   When mitigator is at the upstream service operator level, they might
   have multiple networks, with the attack alert using one network and
   the flow drainage using another, and the link load is not the same,
   then carrying the attack-bandwidth is very beneficial for choosing
   the drainage path, mainly for link load balancing.

Chen, et al.            Expires January 23, 2020                [Page 5]
Internet-Draft          DDoS attack informations               July 2019

3.4.  Mitigation request parameters

   When a DOTS client requires mitigation for some reason, the DOTS
   client uses the CoAP PUT method to send a mitigation request to its
   DOTS server(s).  If a DOTS client is entitled to solicit the DOTS
   service, the DOTS server enables mitigation on behalf of the DOTS
   client by communicating the DOTS client's request to a mitigator
   (which may be colocated with the DOTS server) and relaying the
   feedback of the thus-selected mitigator to the requesting DOTS
   client.

   DOTS clients use the PUT method to request mitigation from a DOTS
   server.  During active mitigation, DOTS clients may use PUT requests
   to carry mitigation efficacy updates to the DOTS server.  We suggest
   to add attack bandwidth to satiesfy the requirement.

   total traffic when ddos attack occur, The recommended format is
   numerical form, such as xxGb.  Different attack has different attack
   bandwidth, numerical value directly reflects the urgency of the
   current attack.  Serious attacks are treated with blackhole, Other
   cases use flow cleaning, attack-bandwidth is conducive to the
   selection of disposal mode.

   This is an optional attribute.

4.  Mitigation Use Case 2

4.1.  classified disposal

   DDoS attack is a hybrid attack across multiple protocol layers and
   multiple method, when we deal with DDoS attacks, we find it more
   reasonable and effective to deal with them according to the types of
   attacks, It is easier to handle if the type of attack is already
   included in the mitigation request.  There is no doubt that the
   information may not be accurate, but we can take it as a reference.
   Therefore, with attack type the disposal process is more helpful.
   The ddos attack alarm in the industry is set according to the attack
   type, from the point of view of cleaning, different types of attacks
   are handled differently.  For example, Memcached reflection flood use
   UDP 11211 port for DDoS flood, but tcp syn flood use defects of TCP
   three-way handshake to consuming connection resources.  This two
   attacks are alarmed respectively and cleaned in different ways.  We
   suggest to add attack type to satiesfy the requirement.

   A list of attack types involved in an attack.

Chen, et al.            Expires January 23, 2020                [Page 6]
Internet-Draft          DDoS attack informations               July 2019

   There is no uniform definition of attack types, It is often the case
   that the same type of attack has different names, An attack type is
   defined in section 4.

   The parameter of Target-attack-type contains two value, one is
   Attack-Name, the other is Attack-Alias, Attack-Alias will solve the
   abbreviation problem.An attack could be a hybrid attack, then the
   target-attack-type represents major types of attacks

   This is an optional attribute.

4.2.  Standard of Attack Type Definition

   For the target-attack-type field, we define it as a string Type, and
   define the two fields according to the attack method and extension
   name. there may be problems in the actual network environment, that
   attack target and mitigator (such as cleaning equipment) belong to
   different models of different vendors, because different vendors have
   different definitions of Attack in understanding and implementation.
   When an attack occurs, some devices may not be considered as an
   attack.  It is also possible that the detection device considere it
   as A type attack, while the cleaning device consider it as B type
   attack.  When performing the cleaning schedule, it will cause the
   problem of incorrect cleaning or over-cleaning.  Both of these errors
   will cause the normal business to fail to link.  Therefore, it is
   necessary to unify the attack definition, form a standard attack
   definition, and solve the problem of cleaning errors from the source.
   we give out a complete format for DDoS attacks as below:

   [protocol layer] [protocol name] [message name/operation name/port]
   [attack methods feature description field 1] [attack methods feature
   description field 2] [attack methods describe the standard field]

   protocol layer(mandatory): Network layer, transport layer,
   application layer;

   protocol name(mandatory): The protocol type used for the attack, such
   as http, TCP, ICMP, NTP...;

   message name/ operation name/ port(optional): The message name,
   operation name, or port used for the attack is a further addition to
   the protocol used for the attack, with message names such as SYN and
   operation names such as GET, Post, SYN, ACK, Query...;

   attack methods feature description field 1 or 2 (optional):
   Description of the method used in the attack, such as Fragment,
   Amplification, Misuse, Slow...;

Chen, et al.            Expires January 23, 2020                [Page 7]
Internet-Draft          DDoS attack informations               July 2019

   attack methods describe the standard field(mandatory): Used to
   describe the type of attack, as the end field, such as flood, attack;

   The protocol name and message name must contain at least one item in
   the abbreviation.

   interval between each field operators use special symbol or any other
   symbol agreed.  For example:HTTP Get Flood(CC) definition, we defined
   the target-Attack-Type field as below(Figure 3):

     {
       "Attack-Name":" Application_Layer, HTTP, Get,,, Flood"
       "Attack-Alias":"HTTP CC Flood"

     }

                 Figure 3: Attack type definition example

   An example of abbreviation: Define the target-attack-type using the
   methods specified above, complete attack name: Transport_Layer TCP
   SYN Flood; abbreviated form: TCP SYN Flood.

5.  Mitigation Use Case 3

5.1.  Mitigation alarm baseline

   Attack target looks like to be attacked by DDoS, then DOTS client
   send mitigation request to DOTS server, So there are exist false
   alarms.  In practice, there are standards for alerting whether or not
   they are appropriate, such as alarm baseline.  With this parameter,
   it is possible to determine whether the standard is reasonable or
   not, False alarms can be corrected and normal alarms can be
   optimized.  It is suggested to use target_attack_Type_threshold to
   carry this information.

   DDoS attacks are distributed attacks, it means there are many sources
   of attack that the traffic from each attack source varies little, so
   it is more efficient to record the numbers of source ip than the
   details ip address.  Blocking every IP address is a thankless task
   and short-lived.  After mitigation, mitigators can feedback the
   source ip number to DOTS server, and this information must be more
   closer to the attack scene, these informations will be used in the
   feedback module for more application.

   target_attack_Type_threshold:  Baseline for a type of attack .

      If attack target have the ability to classify each type of DDoS
      attack, it must have ability to feedback criteria for each type of

Chen, et al.            Expires January 23, 2020                [Page 8]
Internet-Draft          DDoS attack informations               July 2019

      attack.  It doesn't matter that if it can not provide this
      information, it is just an optional attribute.

      This is an optional attribute.

   attack_src_ip_number:  Number of attack sources .

      This is an optional attribute.

6.  Mitigation request optional parameters

   Added parameters show in put method are show as below(Figure 4)

  Content-Format: "application/dots+cbor"
                   {
                   "ietf-dots-signal-channel:mitigation-scope": {
                     "scope": [
                       {
                         "target-prefix": [
                            "string"
                          ],
                         "target-port-range": [
                            {
                              "lower-port": number,
                              "upper-port": number
                            }
                          ],
                          "target-protocol": [
                            number
                          ],
                          "target-fqdn": [
                            "string"
                          ],
                          "target-Attack-Type": [
                             {
                               "Attack-Name": ["string"],
                               "Attack-Alias": ["string"],
                               "target_attack_Type_threshold":["string"]
                             }
                           ],
                           "target-bandwidth":[
                                 "string"
                           ],
                           attack_src_ip_number:[
                             "string"
                           ],

                           "target-uri": [

Chen, et al.            Expires January 23, 2020                [Page 9]
Internet-Draft          DDoS attack informations               July 2019

                            "string"
                          ],
                          "alias-name": [
                            "string"
                          ],
                         "lifetime": number,
                         "trigger-mitigation": true|false
                       }
                     ]
                   }
                   }

               Figure 4: Mitigation Response for Get Request

7.  Mitigation response parameters

   After the mitigation of a DDoS attack, DOTS server can obtain some
   informations from mitigator, these informations are optional
   parameters only as a suggestion when use DOTS to inform the message
   between attack target and mitigator.Figure5Figure 5 shows a response
   example of a mitigation request.

Chen, et al.            Expires January 23, 2020               [Page 10]
Internet-Draft          DDoS attack informations               July 2019

    Content-Format: "application/dots+cbor"
                   {
                    "ietf-dots-signal-channel:mitigation-scope": {
                      "scope": [
                        {
                          "mid": 12332,
                          "mitigation-start": "1507818434",
                          "target-prefix": [
                               "2001:db8:6401::1/128",
                               "2001:db8:6401::2/128"
                          ],
                          "target-protocol": [
                            17
                          ],
                          "lifetime": 1756,
                          "status": "attack-successfully-mitigated",
                          "bytes-dropped": "134334555",
                          "bps-dropped": "43344",
                          "pkts-dropped": "333334444",
                          "pps-dropped": "432432",
                          "attack_src_ip_number": "5231"
                        },
                        ]
                    }
                  }
                 }

             Figure 5: PUT to Convey DOTS Mitigation Requests

8.  Security Considerations

   TBD

9.  IANA Considerations

   TBD

10.  Acknowledgement

   TBD

11.  References

11.1.  Normative References

Chen, et al.            Expires January 23, 2020               [Page 11]
Internet-Draft          DDoS attack informations               July 2019

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

11.2.  Informative References

   [I-D.ietf-dots-architecture]
              Mortensen, A., K, R., Andreasen, F., Teague, N., and R.
              Compton, "Distributed-Denial-of-Service Open Threat
              Signaling (DOTS) Architecture", draft-ietf-dots-
              architecture-14 (work in progress), May 2019.

   [I-D.ietf-dots-requirements]
              Mortensen, A., K, R., and R. Moskowitz, "Distributed
              Denial of Service (DDoS) Open Threat Signaling
              Requirements", draft-ietf-dots-requirements-22 (work in
              progress), March 2019.

   [I-D.ietf-dots-signal-channel]
              K, R., 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-35 (work in progress), July 2019.

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

Authors' Addresses

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

   Email: chenmeiling@chinamobile.com

Chen, et al.            Expires January 23, 2020               [Page 12]
Internet-Draft          DDoS attack informations               July 2019

   Li Su
   CMCC
   32, Xuanwumen West
   BeiJing   100053
   China

   Email: suli@chinamobile.com

   Jin Peng
   CMCC
   32, Xuanwumen West
   BeiJing   100053
   China

   Email: pengjin@chinamobile.com

Chen, et al.            Expires January 23, 2020               [Page 13]