Internet DRAFT - draft-fang-i2nsf-inter-cloud-ddos-mitigation-api
draft-fang-i2nsf-inter-cloud-ddos-mitigation-api
INTERNET-DRAFT Luyuan Fang
Intended Status: Standards Track Deepak Bansal
Expires: September 21, 2016 Microsoft
March 21, 2016
Inter-Cloud DDoS Mitigation API
draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01
Abstract
This document defines an Inter-Cloud DDoS Mitigation Abstract Layer
and corresponding standardized APIs to enable the exchange of real
time automated information to enable DDoS mitigation across Cloud
Service Providers and Network Service Providers.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (c) 2016 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
Fang et al. Expires <September 21, 2016> [Page 1]
INTERNET DRAFT Inter-Cloud DDoS Mitigation API March 21, 2016
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4
3. Inter-Cloud DDoS Mitigation Layer . . . . . . . . . . . . . . . 5
4. Inter-Cloud DDoS Mitigation API . . . . . . . . . . . . . . . 7
4.1. Categories of Inter-cloud API . . . . . . . . . . . . . . . 7
4.1.1. Capability information exchange: . . . . . . . . . . . 8
4.1.2. Mitigation Request and response: . . . . . . . . . . . 8
4.1.3. Monitoring and Reporting: . . . . . . . . . . . . . . . 8
4.1.4. Knowledge sharing: . . . . . . . . . . . . . . . . . . 8
4.2. REST API format . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Capability . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1.1. GET . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2.1. POST . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2.2. GET . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2.4. DELETE . . . . . . . . . . . . . . . . . . . . . . 9
4.2.3. Monitor & Reporting . . . . . . . . . . . . . . . . . . 10
4.2.3.1. POST . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.3.2. GET . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.3.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.3.4. DELETE . . . . . . . . . . . . . . . . . . . . . . 10
4.2.3.5. GET . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.4. Knowledge Sharing . . . . . . . . . . . . . . . . . . . 11
4.2.4.1. GET . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributing Authors' Addresses . . . . . . . . . . . . . . . . . 12
Fang et al. Expires <September 21, 2016> [Page 2]
INTERNET DRAFT Inter-Cloud DDoS Mitigation API March 21, 2016
1. Introduction
We recently observe the following characteristics of the DDoS attacks
in the Cloud era: 1) Growing in volume: for example, 450 Gbps peak
speed DDoS attack in an ISP network was observed in December 2014,
while over 300 Gbps DDoS attack was reported in 2013; 2) Growing in
frequency; 3) Using Cloud services to launch major attacks,
especially when some cloud services do not impose bandwidth and
compute resource limitation; 4) Growing in sophistication: leverage
vulnerable services like NTP, DNS, and BitTorrent to amplify the
available bandwidth; 5) Growing attack to Inter-cloud/Inter-provider
connection links, large volume attack can disrupt all cloud services
traversing through the inter-connection links.
This draft is focus on Inter-Cloud/Inter-provider DDoS attack
mitigation. The fast growth in volume and scale of Distributed Denial
of Service (DDoS) attacks, particularly its impact on the large pipes
of Inter-Cloud, Inter-Provider connections, calls for mechanisms to
enable DDoS mitigation across Cloud Service Providers (CSPs) and
Network Service Providers (NSPs). These mechanisms require to define
an Inter-Cloud DDoS Mitigation Abstract Layer with corresponding
standardized APIs to allow real time, automated information exchange
among CSPs and NSPs, and achieve rapid protective response and
effective Inter Cloud/Inter Provider DDoS attack mitigation. The need
for such standard Inter-Cloud DDoS Mitigation APIs is strong and
urgent.
This document defines the Inter-Cloud DDoS Mitigation Abstract Layer
and APIs.
This document focuses on Inter-Cloud, Inter-Provider automated
exchange of DDoS Mitigation information, although similar APIs could
be used within each cloud for handling malicious traffic.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the terminology defined in
[I-D.draft-ietf-i2nsf-gap-analysis].
In addition, this document uses the following terms.
Fang et al. Expires <September 21, 2016> [Page 3]
INTERNET DRAFT Inter-Cloud DDoS Mitigation API March 21, 2016
Term Definition
----------- --------------------------------------------------
BGP Border Gateway Protocol
CSP Cloud Service Provider
DC Data Center
DCI Data Center Interconnect
DDoS Distributed Denial of Service
DLC Disruption Life Cycle
Inter-Cloud The interconnection between the cloud of different
providers
NSP Network Service Provider
SDN Software Defined Network
SVR Server
2. Problem Statement
Along with the rapid growth of cloud services, the large pipes of
Inter-Cloud, Inter-Provider connections are increasingly the subject
of DDoS attacks. Since these connections are between clouds of
different providers, implementing mechanism to achieve rapid
protective response in case of attack is challenging. While within
its own cloud each provider may be able to protect effectively its
network using various DDoS protection techniques, for the Inter-
Cloud/Inter-Provider links, each provider does not have full
visibility of the attack, and therefore response times may be longer,
counter-measures may be less effective, and therefore the severity
and impact of the attacks may be very significant.
Large DDoS attacks targeting the Inter-Cloud, Inter-Provider links
may consume the available bandwidth or the router/switch/server
resources within tens of seconds. While the attack is on, legitimate
traffic is prevented from being forwarded over the saturated links.
With saturated Inter-Cloud, Inter-Provider links, even if within each
cloud the DDoS mitigation may be working effectively, it can quickly
be rendered irrelevant.
How does Distributed DoS attack relate to Inter-Cloud connections?
The DDoS attack can be targeting the hosts, servers, end-points,
gateways, or any devices in between. Regardless of the target, the
attack traffic flows through the "Pipes"/inter-connection links, and
can saturate these large pipes. Attack volume is the key issue here.
DDoS attack BW is increasing very fast is the recent years. Attack BW
greater than 100G is not uncommon any more, and 450G peek speed DDoS
attack has been seen in some SP networks end of 2014. The DDoS attack
can consume BW, impact multi-region Data Centers and Inter-Cloud
connectivity, and interrupt multi-services. Because of its massive
scale, it can also make fast mitigation more challenging.
Fang et al. Expires <September 21, 2016> [Page 4]
INTERNET DRAFT Inter-Cloud DDoS Mitigation API March 21, 2016
Today, exchange of DDoS attack information and mitigation strategy
among providers is largely manual and typically relies on customized
operation processes established ad hoc between each provider. Manual
means someone has to send emails, or make phone calls to reach the
people in another Cloud, another ISP, etc. No signaling, no common
API, no automation across the provider boundaries available. Because
of largely manual escalation procedures, providers' reaction times to
DDoS attacks to Inter-Cloud, Inter-Provider links tends to be slow
(it can easily take tens of minutes if not hours to put effective
mitigation measures in place) compared to Intra-Cloud DDoS
mitigation, and thus the damage caused by such attacks can be
substantial. The reaction time may exceed the Disruption Life Cycle
(DLC) of the attack.
Sophisticated and determined malicious attackers are able to quickly
learn the intended Inter-Cloud Inter-Provider link capabilities and
limitations through probing. This includes bandwidth capacity,
saturation resistance - the attack cannot saturate the connection
links and make them unusable, and DDoS absorption resilience of the
link - the attack can be absorbed without taking down the network
connections and impact the services. The attacker is also able to
learn the DDoS countermeasures and their response times, from which
the attacker can infer the DLC that can be exacted toward the
intended target. The DLC is measured by the assailant from the time
the attack is initiated to the time the mitigation response becomes
evident. An attacker can then use this information to design the
attacks in such a way that the current and subsequent attacks inflict
the most harm.
In order to achieve rapid protective response, the exchange of DDoS
mitigation information between providers must be enabled in real time
and in an automated, standardized fashion.
3. Inter-Cloud DDoS Mitigation Layer
The Inter-Cloud DDoS Mitigation Layer and its corresponding
standardized, secure Inter-Cloud DDoS Mitigation APIs is illustrated
in Figure 1.
Fang et al. Expires <September 21, 2016> [Page 5]
INTERNET DRAFT Inter-Cloud DDoS Mitigation API March 21, 2016
.-----. .-----.
( ') ( ')
.--(. '.---. .--(. '.---.
( ' ' ) ( ' ' )
( Network SP 1 ) ( Network SP 2 )
(. .) (. .)
( ( .) ( ( .)
'--' '-''---' '--' '-''---'
|| ||
____ ____
---- Secure API ---- Secure API
|| ||
+----------------------------------------------+
| |
| Inter-Cloud DDoS Mitigation Abstract Layer |
| |
+----------------------------------------------+
||
____
---- Secure API
||
.-----.
( ')
.--(. '.---.
( ' ' )
( Cloud SP A )
(. .)
( ( .)
'--' '-''---'
Figure 1. Inter-Cloud DDoS Mitigation Abstract Layer and APIs
Today there is no accepted industry common DDoS Mitigation Layer that
can be used to reduce the reaction time and increase the
effectiveness of mitigation in case of attack.
The Inter-Cloud DDoS Mitigation Abstract Layer provides standardized
secure APIs that can be used by each provider to programmatically
initiate real time information exchanges to other providers to
provide visibility of the attack and coordinate DDoS mitigation
mechanisms, Exchanged information may include signatures and forensic
of the attack, timestamps, and black-holing countermeasures.
The Inter-Cloud DDoS Mitigation Abstract Layer provides corresponding
API calls to exchange mitigation information on the following areas.
Fang et al. Expires <September 21, 2016> [Page 6]
INTERNET DRAFT Inter-Cloud DDoS Mitigation API March 21, 2016
DDoS Protection Types:
o TCP flood rate limiting
o UDP flood rate limiting
o TCP SYN.ACK/RST flood protection and authentication
o Maximum concurrent connections per interval rate limiting
o Maximum number of new connections allowed per interval rate
limiting
o Maximum fragment packets allowed per interval rate limiting
o Maximum number of packets allowed per interval rate
limiting
o Black-holing
o Use BGP Flowspec [RFC5575] to auto-coordinate traffic
filtering, DDoS mitigation
o Other BGP Signaling and Mitigation examples
o BGP /24 route advertisement with community string option
o Mitigation support for /32 with type and rate limit
thresholds
o /32 removal from mitigation
o BGP support for /24 removal
Attack Lifecycle Monitoring and Reporting
o Volume and scale of the attack, signatures, forensic
o Timestamps
4. Inter-Cloud DDoS Mitigation API
4.1. Categories of Inter-cloud API
The following describe the basic functions the Inter-Cloud DDoS
mitigation MUST support.
Fang et al. Expires <September 21, 2016> [Page 7]
INTERNET DRAFT Inter-Cloud DDoS Mitigation API March 21, 2016
4.1.1. Capability information exchange:
Support "Query" the DDoS capabilities from one provider to another
provider.
4.1.2. Mitigation Request and response:
Mitigation Request: One provider can "Request" for mitigation by
partner provider based on pre-agreement.
Mitigation Response: The provider received DDoS mitigation request
first acknowledge the request, then execute a particular DDoS
capability on behalf of the requesting provider, and respond back
with the logged actions performed and mitigation status.
4.1.3. Monitoring and Reporting:
Monitoring: Allow another provider to monitor DDoS status and
mitigation processes.
Reporting: Provider DDoS status reports to partner providers.
4.1.4. Knowledge sharing:
Allow partner providers to query for a specific DDoS related data to
enhance their DDoS resiliency and perform coordinate mitigation when
possible.
4.2. REST API format
4.2.1. Capability
Definition: A participating provider should allow another provider to
query for its DDoS capabilities.
The following REST API are the basic ones that every provider
participating MUST provide.
4.2.1.1. GET
Example 1: GET (DDoS mitigation Capabilities)
a. Description: The receiving provide returns a list of DDoS
mitigation it can perform
b. Parameters: None
c. Responses: 200, an array of mitigation objects format.
Fang et al. Expires <September 21, 2016> [Page 8]
INTERNET DRAFT Inter-Cloud DDoS Mitigation API March 21, 2016
Example 2: GET (DDoS mitigation Capabilities - protocol)
a. Description: Return a list of DDoS mitigation that this provider
can perform for the protocol specified.
b. Parameters: protocol is one of the following strings {tcp, udp,
dns}
c. Responses: 200, OK, an array of mitigation objects format.
(more details to be added especially around format of the object
to be returned).
4.2.2. Mitigation
Definition: Mitigation Request and Response must be supported between
participating providers for executing a particular DDoS capability.
The following REST API are the baselines that each participating
providers MUST support.
4.2.2.1. POST
a. Description: Create a new policy what will cause a mitigation to
be performed based on a specific trigger.
b. Parameters: PolicyObject {To be specified}
c. Responses: 200, OK, return an identifier.
4.2.2.2. GET
a. Description: Get an existing policy.
b. Parameters: id identifier of the policy that was created.
c. Responses: 200, OK, return the policy of the specified id
4.2.2.3. PUT
a. Description: Update a particular policy.
b. Parameters: PolicyObject {To be specified} & id which is the
identifier which was returned after a successful create of a policy.
4.2.2.4. DELETE
a. Description: Delete a policy and therefore end any mitigation that
is currently active.
b. Parameters: id the identifier of the policy that was created.
Fang et al. Expires <September 21, 2016> [Page 9]
INTERNET DRAFT Inter-Cloud DDoS Mitigation API March 21, 2016
c. Response: 200, OK, policy deleted.
4.2.3. Monitor & Reporting
Definition: A participating provider MUST allow another provider to
monitor a particular DDoS mitigation.
The following REST API are the basic ones that every provider must
provide.
4.2.3.1. POST
a. Description: Created a new monitored object for a
policy/mitigation.
b. Parameter: MonitoredObject {To be specified} & id which is the
mitigation identifier. The MonitoredObject will have parameter to
enable retrieving sFlow to a particular endpoint for collection of
the metrics. By default, you can use REST API calls as defined below
to retrieve monitored objects stats.
c. Responses: 200, OK
4.2.3.2. GET
a. Description: Get the current monitoring settings for this
mitigation/policy.
b. Parameter: id identifier for the mitigation/policy.
c. Responses: 200, OK, monitoring settings
4.2.3.3. PUT
a. Description: Update the current monitoring settings for this
mitigation/policy
b. Parameter: id identifier for the mitigation/policy.
c. Responses: 200, OK
4.2.3.4. DELETE
a. Description: Remove all monitoring configuration for this
mitigation/policy
b. Parameter: id identifier for the mitigation/policy.
c. Responses: 200, OK
Fang et al. Expires <September 21, 2016> [Page 10]
INTERNET DRAFT Inter-Cloud DDoS Mitigation API March 21, 2016
4.2.3.5. GET
a. Description: Return the stats available for this mitigation and
monitored object.
b. Parameters: None
c. Responses: 200, OK, stats
4.2.4. Knowledge Sharing
Definition: A participating provider MUST allow another participating
provider to query for a specific DDoS related data to enhance their DDoS
resiliency.
The following REST API are the basic ones that every provider must
provide.
4.2.4.1. GET
a. Description: Return the current blacklist.
b. Parameter: Size to limit the returned list.
c. Responses: 200, OK, return a string array of blacklisted IPs.
5. Security Considerations
Given the subject of the draft is Inter-Cloud/Inter-Provider DDoS
mitigation, security policies among the participating providers must
be agreed upon and strictly followed. Authentication MUST be enforced
on all interconnections and APIs in discussion.
6. IANA Considerations
None.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March
1997.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification Rules," RFC
Fang et al. Expires <September 21, 2016> [Page 11]
INTERNET DRAFT Inter-Cloud DDoS Mitigation API March 21, 2016
5575, August 2009.
7.2. Informative References
[I-D.draft-ietf-i2nsf-gap-analysis] S. Hares et al., "Analysis of
Use Cases and Gaps in Technology for I2NSF ",draft-ietf-i2nsf-gap-
analysis-00.txt, Feb. 2016.
Authors' Addresses
Luyuan Fang
Microsoft
15590 NE 31st St
Redmond, WA 98052
Email: lufang@microsoft.com
Deepak Bansal
Microsoft
15590 NE 31st St
Redmond, WA 98052
Email: dbansal@microsoft.com
Contributing Authors' Addresses
Jim Nyland
Microsoft
15590 NE 31st St
Redmond, WA 98052
Email: jnyland@microsoft.com
Geoff Outhred
Microsoft
15590 NE 31st St
Redmond, WA 98052
Email: geoffo@microsoft.com
Anh Cao
Microsoft
15590 NE 31st St
Redmond, WA 98052
Email: anhcao@microsoft.com
Fang et al. Expires <September 21, 2016> [Page 12]
