[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-dots-use-cases

DOTS                                                     D. Migault, Ed.
Internet-Draft                                                  Ericsson
Intended status: Informational                            April 20, 2015
Expires: October 22, 2015


                  DDoS Open Threat Signaling use cases
                      draft-mglt-dots-use-cases-00

Abstract

   The document details use cases to mitigate DDoS attacks.  These use
   cases are expected to illustrates involved communications to detect
   and mitigate DDoS attacks.  It is expected that these communications
   will be in the future handled by the DDoS Open Threat Signaling
   (DOTS).  These scenarios are intended to be useful to derive
   requirements for the design of DDoS Open threat Signaling.

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 http://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 October 22, 2015.

Copyright Notice

   Copyright (c) 2015 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
   (http://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




Migault                 Expires October 22, 2015                [Page 1]


Internet-Draft               DOTS use cases                   April 2015


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Acronyms  . . . . . . . . . . . . . . . . . .   3
   3.  On-premise use case . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Symmetric . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Asymmetric  . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Cloud Use Case  . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Hybrid Cloud Use Case . . . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   DDoS is a major threat that affects any organizations of any size.
   In addition, these attacks have become more and more frequent,
   complex and sophisticated which makes DDoS attacks harder to be
   detected at a single point.

   More specifically, traditional SYN TCP or ICMP flood attacks were
   relatively easy to detect at the border of the network by an on-
   premise device.  Although such DDoS attacks remain, DDoS attacks
   become more and more applications specific.  This results in more
   specialized DDoS attacks, that require a fine grained monitoring to
   detect suspicious traffic.

   For example, DNS can be used as a channel to establish a
   communication channel between a bot and its Command and Control (CC)
   channel.  A generic DNS flow traffic monitoring is not sufficient to
   detect such attacks.  Instead it may require monitoring FQDNs with
   NXDOMAIN associated to behavioral traffic analysis.  DNS(SEC) or NTP
   are used to perform DDoS reflection attacks.  Detection of these
   attacks may involve monitoring how the source IP address may be
   unusually associated to heavy traffic.  That said, more specific
   traffic monitoring and analysis is not sufficient when DDoS attacks
   target a specific application.  In the case of slowloris flows DDoS
   attacks for example, the attacker initiates regular conversations
   with the servers, except that it maintains these conversations open.
   The use of TLS/DTLS makes on path monitoring impossible.





Migault                 Expires October 22, 2015                [Page 2]


Internet-Draft               DOTS use cases                   April 2015


   The complexity and the multitude of potential targets results in
   making DDoS detection a distributed system over a network.  Flood
   attacks can be detected at the entrance of the network, SYN flood may
   be detected by firewalls associated to behavioral analysis.  TLS and
   HTTP floods or low and slow and application based DDoS attacks are
   expected to be detected on the server side.

   The multitude of DDoS monitoring appliance requires coordination.
   Coordination is necessary in order to manage the DDoS appliances as
   well as to collect the various information provided by each appliance
   and correlate these piece of information.  Such correlation is
   expected to provide early detection, as well as more accurate alarms.
   Once a DDoS attack has been detected, the mitigation should proceed.
   Mitigation could be handled locally or outsourced.

   The document details use cases to mitigate DDoS attacks.  These use
   cases are expected to illustrates involved communications to detect
   and mitigate DDoS attacks.  It is expected that these communications
   will be in the future handled by the DDoS Open Threat Signaling
   (DOTS).  These scenarios are intended to be useful to derive
   requirements for the design of DDoS Open threat Signaling.

   The document illustrates how DOTS makes possible DDoS to go beyond
   the scope of an isolated appliance and :

   - A)  Make possible a global and cross layered DDoS Monitoring, to
         make DDoS detection more accurate and earlier.

   - B)  Make possible a global and cross layer DDoS Mitigation, to
         mitigate in an coherent and efficient way.

   - C)  Make possible to share monitored information between multiple
         parties.

   - D)  Make possible to share and delegate DDoS monitoring and
         mitigation to third party.

2.  Terminology and Acronyms

   - Deny of Service (DoS):   is an attack that makes resource of a
         service unavailable for its intended users.  The resource may
         be computing or networking resource.

   - Distributed Deny of Service (DDoS):   is a DoS attack where the
         resources used by the attacker to perform the attack are
         distributed.





Migault                 Expires October 22, 2015                [Page 3]


Internet-Draft               DOTS use cases                   April 2015


   - DDoS Monitoring:   designates the ability to inspect and monitor
         the traffic.  This may include, exporting flow information to a
         Flow Repository or generating an alarm to the DDoS Controller
         when some threshold have been reached.  In this document, DDoS
         Monitoring represents indifferently either a specific and
         dedicated DDoS Appliance, a virtual DDoS Appliance or a module.

   - DDoS Mitigation:   designates the ability to mitigate the DDoS
         attack.  This may include providing filtering rules for
         example.  In this document, DDoS Mitigation represents
         indifferently either a specific and dedicated DDoS Appliance, a
         virtual DDoS Appliance or a module.

   - DDoS Controller:   designates the entity that centralized
         monitoring, the alarms received and provides the mitigation
         actions.  As DDoS attacks become more and more complex, a
         single DDoS monitoring device become dedicated to limited
         aspect of DDoS.  As a result, these devices have only a
         fractional view of the ongoing activity.  On the other hand,
         the DDoS Controller can aggregate and correlate this
         information have as such has a global view of the attacks.  As
         result the DDoS Controller is more likely to take the
         appropriated decision to mitigate the attack.

   - DDoS Appliance:   designates an appliance that embeds DDoS
         Monitoring and/or DDoS Mitigation function.  In this document,
         DDoS Appliance can be indifferently a hardware or virtual
         virtual DDoS Appliance.

   - Flow Repository:   designates the entity that centralized all the
         flow information.  The Repository, may be shared between
         various entities and third parties.  In fact, it is expected
         that information could be shared between independent actors, in
         order to mitigate DDoS Internet wild.

   - Service:   designates the destination of the traffic and the
         service that is under attack.

3.  On-premise use case

   The on-premise uses cases describe scenarios where DDoS is detected
   and mitigated on site.  Section 3.1 describes the symmetric on-
   premise scenario, where the DDoS Appliance is place on path both the
   inbound and outbound traffic to the Service.  Section 3.2, on the
   other hand presents the case where only a sub traffic is dynamically
   directed to the DDoS Appliance.





Migault                 Expires October 22, 2015                [Page 4]


Internet-Draft               DOTS use cases                   April 2015


3.1.  Symmetric

   As depicted in Figure 1 the DDoS Appliance is on path of the inbound
   and outbound traffic to the Service.  In other words, traffic coming
   from the Service to the end users goes also through the DDOS
   Appliance.

   Such scenario may be associated to Small Office Home Office (SOHO)
   networks.  In this case, the network, most likely, has a single DDoS
   Appliance.  On the other hand, this scenario may also apply to large
   data center where, for example, each VM could be associated to a
   virtual DDoS Appliance.

   The typical use case includes the following steps:

   1.    The DDoS Controller requests the DDoS Monitoring and DDoS
         Mitigation capabilities of the DDoS Appliance.  Such request
         provides flexibility for both the DDoS Controller and the DDoS
         Appliances.  First the DDoS Controller does not need to be tied
         to the DDoS Appliance, and so a single DDoS Controller may be
         used for various heterogeneous DDoS Appliances.  Heterogeneity
         can be in term of vendors and/or in term of proposed
         capabilities.  Similarly, this provides flexibility for the
         DDoS Appliances, as a DDoS Appliance may implement a subset of
         capabilities.  In our example, the DDoS Controller, discovers
         both the DDoS Monitoring and DDoS Mitigating capabilities.
         DDoS Monitoring capabilities are necessary for monitoring the
         traffic and latter setting the alarms (see 2.).  DDoS
         Mitigation capabilities are not mandatory to be requested here,
         as they are only expected to be used when the network is under
         attack.  The reason the DDoS Controller requests those at this
         stage is to be able to plan its strategy for DDoS mitigation in
         advance instead of doing so while being under attack.

   2.    The DDoS Controller, then configures the appropriated
         capabilities on the DDoS Appliance.  The configuration can
         typically be setting the thresholds upon which an alarm is
         raised by the DDoS Appliance to the DDoS Controller.  Another
         type of setting may also be related to monitoring.  DDoS
         Appliance may be configured to provide flow or resource (like
         CPU usage) information.  These information may be exported to
         the Flow Repository in an appropriated format that enabled
         processing and correlation analysis by the DDoS Controller.

   3.    The DDoS Appliance sends the monitoring information to the Flow
         Repository.  Note that the Flow Repository must be provided
         some means to authenticated the received packets as well as to




Migault                 Expires October 22, 2015                [Page 5]


Internet-Draft               DOTS use cases                   April 2015


         check the received information corresponds to the one requested
         by the DDoS Controller.

   4.    The DDoS Appliance raises an alarm that some suspicious traffic
         has been detected.  This alarm corresponds to the settings
         performed by the DDoS Controller in step 2.  As mentioned in
         Section 1 it may be difficult for the DDoS Appliance to
         determine from a local observation that a DDoS attack is
         ongoing or not.  This is the reason the alarm is raised for
         suspicious traffic.

   5.    The DDoS Controller analyzes and correlates the received alarm
         for suspicious traffic and confirm or not that a DDoS attack is
         ongoing.  Confirmation may require the DDoS Controller to
         perform some traffic analysis and correlates the alarm with
         some additional data.  To do so, the DDoS Controller may
         consult the Flow Repository.

   6.    The DDoS Controller concludes that the network is under attack,
         and so proceeds to DDoS mitigation.  In this example, the DDoS
         Controller is aware of the DDoS Mitigation capabilities of the
         DDoS Appliance as it has proceeded to the discovery mechanism
         in step 1.  If that is not the case, the DDoS Controller should
         discover the DDoS mitigation capacities now.  DDoS mitigations
         performed by the DDoS Controller are related to DDoS service.
         This may include for example setting some filtering rules or
         activation rate limitation.  If traffic redirection should be
         performed, it is not expected to be performed by the DDoS
         Controller.  In fact redirection implies a network
         reconfiguration and is considered outside the scope of the DDoS
         Controller.  In addition to mitigate the DDoS attack, the DDoS
         Controller may also adjust its DDoS Monitoring settings.
         Motivations for doing so, may be for example to reduce the
         traffic on the network, or reversely, to provide a more
         accurate monitoring.

   6bis.   Eventually, the DDoS Controller may conclude that the network
         is not under attack.  In this case the alarm is ignored or
         acknowledged to avoid the alert is re-sent and eventually load
         the network or the DDoS Controller.  Similarly to step 6, the
         DDoS may also decide to adjust the monitoring settings to
         reduce false positive alarms.  Note that the latest should be
         used cautiously as, such mechanism may be used as a vector of
         attack.







Migault                 Expires October 22, 2015                [Page 6]


Internet-Draft               DOTS use cases                   April 2015


                                   ***** DDoS traffic
                                   ooooo Legitimate traffic


              |
   Internet   |         Attacked Network
              |
              |   DDoS Appliance
              |  +-----------------+       +---------+
   >***>***>  |* | DDoS Monitor    |       |         |
   >ooo>ooo>  |o | ----------      | >ooo> | Service |
   <ooo<ooo<  |o | DDoS Mitigation | <ooo< |         |
              |  +-----------------+       +---------+
              |    |       ^
              |    |       |  1. Capabilities
                   |       |  2. Monitoring settings
     3. Monitored  |       |  4. Alarm is raised
     Flow          |       |  6. DDoS Mitigation
                   |       +----------------+
                   v                        v
       +---------------------+        +------------------+
       |   Flow Repository   |<------>|   DDoS Control   |
       +---------------------+        +------------------+
                        5. Alert Correlation

                  Figure 1: On-premise Symmetric Use Case

   Figure 1 shows the DDoS Controller as distinct from the DDoS
   Appliance.  In fact nothing prevents the DDoS Controller to be
   located on the DDoS Appliance.  In this case the communications
   between the DDoS Controller and the DDoS Monitoring or DDoS
   Mitigation functions would be implementation dependent and thus
   outside of the scope of DOTS.  The DDoS Appliance may embed a basic
   and limited DDoS Controller for basic configuration of the device.
   This is one reason why a DDOS Appliance may be configured by multiple
   DDoS Controllers.

   Similarly, there is no requirements that the DDoS Controller belongs
   to the same network as the DDoS Appliances.  The DDoS Controller
   could be placed inside the on-premise DDoS Appliances' network or
   remotely see Section 5 for more details.

   How the DDoS Controller handles alarms and determines a suspicious
   traffic corresponds or not to a DDoS attack is out of scope of DOTS.
   Similarly, the mitigating strategies are also out of scope of DOTS.






Migault                 Expires October 22, 2015                [Page 7]


Internet-Draft               DOTS use cases                   April 2015


3.2.  Asymmetric

   The asymmetric on-premise scenario optimize resources compared to the
   symmetric on-premise scenario.  More specifically, in the symmetric
   on premise scenario, the traffic going from the Service to the end
   users also goes through the DDoS Appliance.  Such deployment may lead
   to unnecessary load on the DDoS Appliance.  In fact, the outbound
   traffic may not need to be either monitored or mitigated, and as such
   may reduce the packet rate or bit rate upper bound limit for inbound
   traffic.  This may be one motivation for splitting the DDoS
   Monitoring module and the DDoS Mitigation modules in two different
   DDoS Appliances.  In addition, for large networks, having a dedicated
   DDoS Appliance for DDoS mitigation may rationalize the cost and use
   of DDoS Mitigation Appliances.  In fact, DDoS Mitigation Appliances
   may be shared by multiple Services or instances of VM of a given
   Service.  As a result, the DDoS Mitigation Appliance do not need to
   scale the service traffic but instead the traffic of DDoS attacks --
   which is most likely expected to remain smaller.  This may not be the
   case for the DDoS Monitor Appliance as there is a need to always
   monitor the whole service traffic.

   In the use case depicted by Figure 2 and Figure 3 the DDoS Mitigation
   Appliance only handles DDoS traffic.

   The typical use case includes the following steps:

   1.    corresponds to the capabilities discovery phase.  It is similar
         as the one exposed in Section 3.1.  The main difference remains
         that DDoS Monitoring capabilities and DDoS Mitigating
         capabilities are discovered on two distinct DDoS Appliances.

   2., 3., 4. and 5.   corresponds to the monitoring and alarms
         settings.  Monitoring may result in exporting data to the Flow
         Repository.  This is similar as the steps described in
         Section 3.1.

   6.    If the DDoS Controller determines the network is under a DDoS
         attack, mitigation is performed in two steps.  They may be
         ordered differently depending on criteria that are beyond the
         scope of this use case.  First, the DDoS Mitigation is
         configured as described in Section 3.1 as a result of an
         analysis performed by the DDoS Controller.  Then, traffic
         redirection is performed.  In our case, the redirected traffic
         corresponds only to the inbound traffic from the end users.
         The traffic from the service to the end users is not
         redirected.  This operation is not directly handled by the DDoS
         Controller.  It can be performed manually, or upon a request
         from the DDoS Controller.  This request is then treated by a



Migault                 Expires October 22, 2015                [Page 8]


Internet-Draft               DOTS use cases                   April 2015


         network management function in order to perform the
         appropriated network configurations.

   6bis.   In the case, the DDoS Controller determines the network is
         not under a DDoS attack, this step similar to the one described
         in Section 3.1.

                                            ***** DDoS traffic
    Internet   Attacked Network             ooooo Legitimate traffic
             |
             |
             |
             |   DDoS Appliance
             | +-----------------+       +---------+       +---------+
   <ooo<ooo< | |                 | <ooo< |         | <ooo< |         |
   >ooo>ooo> | |  DDoS Monitor   | >ooo> | Network | >ooo> | Service |
   >***>***> | |                 | >***> |         | >***> |         |
             | +-----------------+       +---------+       +---------+
             |   |  ^
             |   |  | 1. Capabilities
             |   |  | 2. Monitoring settings
             |   |  |                     +---------------------+
             |   |  +----------------+    |  DDoS Mitigation    |
             |   |                   |    +---------------------+
             |   |  3. Monitored     |     DDoS Appliance    ^
             |   |  Flows            |                       |
             |   v                   v     1. Capabilities   |
      +-----------------+        +-----------------------------------+
      | Flow Repository |<------>|         DDoS  Controller          |
      +-----------------+        +-----------------------------------+

         Figure 2: On-premise Asymmetric Use Case Monitoring Phase



















Migault                 Expires October 22, 2015                [Page 9]


Internet-Draft               DOTS use cases                   April 2015


                                            ***** DDoS traffic
    Internet   Attacked Network             ooooo Legitimate traffic
             |
             |                                +------------
             |                                | Traffic Redirection
             |   DDoS Appliance               v
             | +-----------------+       +---------+       +---------+
   <ooo<ooo< | |                 | <ooo< |         | <ooo< |         |
   >ooo>ooo> | |  DDoS Monitor   | >ooo> | Network |       | Service |
   >***>***> | |                 | >***> |         |       |         |
             | +-----------------+       +---------+       +---------+
             |   |  ^                         vv             ^
             |   |  |                         *o             o
             |   |  |                         vv             ^
             |   |  | 4. Alarm is raised  +---------------------+
             |   |  +----------------+    |  DDoS Mitigation    |
             |   |                   |    +---------------------+
             |   |  3. Monitored     |     DDoS Appliance     ^
             |   |  Flows            |                        |
             |   v                   v    6. Mitigation settings
      +-----------------+        +-----------------------------------+
      | Flow Repository |<------>|          DDoS Controller          |
      +-----------------+        +-----------------------------------+
                   5. Alert Correlation

         Figure 3: On-premise Asymmetric Use Case Mitigation Phase

4.  Cloud Use Case

   Figure 4 illustrates the Cloud use case.  In this scenario, the
   entire DDoS monitoring and mitigation service is outsourced to a
   third party designated as Cloud Based DDoS Cleaning Service or Cloud
   for short.  In order to do so, the traffic associated to the Service
   goes through the Cloud Based DDoS Cleaning Service as detailed in
   Figure 4.  On the other hand, this scenario makes DDoS mitigation
   transparent to the Service provider, which then benefits from a
   "clean pipe".

   Figure 4 presents the case where the Cloud is on path of both inbound
   and outbound traffic, a similar scenario may also consider that only
   the inbound traffic, that is the traffic destined to the service is
   directed to the cloud whereas the outbound traffic destined to the
   users does not.

   Internal organization of the Cloud Based DDoS Cleaning Service is
   transparent to the Service provider.  A combination of the on-
   premises scenarios may be used.




Migault                 Expires October 22, 2015               [Page 10]


Internet-Draft               DOTS use cases                   April 2015


                           ***** DDoS traffic
                            ooooo Legitimate traffic

                  +----------------------------------+
                  | Cloud Base DDoS Cleaning Service |
                  |                                  |
                  |  DDoS Monitor                    |
                  |             /                    |
                  |            DDoS Mitigation       |
                  +----------------------------------+
                            ^^   v             v   ^
                            *o   o             o   o
                            ^^   v             v   ^
             >***>***>   ,---------.       +---------+
     Users   >ooo>ooo>,-'           `-.    |         |
                     (   Internet      )   | Service |
             <ooo<ooo<`-.           ,-'    |         |
                         `---------'       +---------+

                         Figure 4: Cloud Use Case

5.  Hybrid Cloud Use Case

   The inconvenient the cloud use case scenario described in Section 4
   is that redirecting the traffic to the cloud is likely to introduce
   additional latency.  This is inconvenient as it adds a constant
   service degradation and cost to the Service provider.  In order to
   address this, this section details the Hybrid Cloud scenario that
   combines the on-premise scenarios detailed in Section 3 and the cloud
   scenario detailed in Section 4

   The main driver for combining the cloud and on-premise scenarios is
   to be able to outsource the DDoS attack mitigation to a third party
   only when the Service provider is under attack, or when it is not
   able to handle the ongoing DDoS attack.  In the general case, the
   determination on how the service provider is able to cope and detect
   a DDoS attack is up to the Service provider.  A continuum of
   scenarios can be considered and this section details only a few of
   them.

   A specific case may consider that DDoS mitigation is outsourced by
   outsourcing the DDoS Controller to a third party.  This DDoS
   Controller, drives the DDoS Monitor functions on the premise.  When
   an alert is raised, the DDoS Controller may take the decision to
   mitigate internally with the DDoS attack only using on-premise
   facilities.  This case correspond to the scenarios detailed in
   Section 3, except that the DDoS Controller is either located
   remotely, or at least accessed remotely by the third party.  On the



Migault                 Expires October 22, 2015               [Page 11]


Internet-Draft               DOTS use cases                   April 2015


   other hand, the DDoS Controller may also decide that the DDoS attack
   cannot be mitigated on premise, and that mitigation should be
   outsourced to a cloud service as described in Section 4.  In this
   case, the DDoS Controller is expected to redirect at least the
   inbound traffic of the Service provider to the cloud infrastructure.
   This case corresponds to the on premise asymmetric scenario detailed
   in Section 3.2.  The difference is that redirection does not occur
   inside the Service provider, but involves sites redirection -- most
   likely using BGP signaling.

   Another scenario may provide more independence to the Service
   provider.  In this scenario, the Service provider, may have the
   complete control on the DDoS Monitor and DDoS Mitigation Appliances,
   and only uses the Cloud as a backup solution when it is not likely to
   deal with the DDoS attack.  In this case, the DDoS Controller sends
   an alert to the DDoS Controller of the third party.  The third party
   first analyzes the attack, which may require to grant access to the
   third party to the Flow Repository.  If DDoS mitigation action are
   performed by the third party DDoS Controller, means should be
   provided to transmit information from the third party DDoS Controller
   to the DDoS Appliances.  This could be done for example by providing
   access to the DDoS Appliances, or by DDoS Controller that acts as a
   proxy for the third party DDoS Controller.

6.  Security Considerations

7.  Privacy Considerations

8.  IANA Considerations

   This document makes no request of IANA.

9.  Acknowledgments

10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Author's Address











Migault                 Expires October 22, 2015               [Page 12]


Internet-Draft               DOTS use cases                   April 2015


   Daniel Migault (editor)
   Ericsson
   8400 boulevard Decarie
   Montreal, QC   H4P 2N2
   Canada

   Phone: +1 514-452-2160
   Email: daniel.migault@ericsson.com











































Migault                 Expires October 22, 2015               [Page 13]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/