| 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
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.
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 (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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
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 :
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.
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:
***** 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.
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:
***** 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
***** 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
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.
***** 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
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 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.
This document makes no request of IANA.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |