Subject: [I2nsf] draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

From: Luyuan Fang <[email-masked]>
Date: Mon, 28 Mar 2016 03:44:27 +0000

Hi Linda, Adrian, and all,

We posted draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01 on 3/21.
https://tools.ietf.org/html/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

We extend more on the DDOS attack trends we are observing and the urgent need for automated inter-cloud/provider DDoS mitigation. We propose categories and formats of basic set of APIs. We also address comments/questions on 00 draft from the WG.

Characteristics of the DDoS attacks that we have seen:
1) Growing in volume, e.g., 450 Gbps peak speed DDoS attack was observed by an ISP in 12/2014, while over 300 Gbps DDoS attack was reported by another provider 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, and may extend to more general security information exchange. We need mechanisms which can enable DDoS mitigation across Cloud Service Providers (CSPs) and Network Service Providers (NSPs). These mechanisms must support real time, automated information exchange among CSPs and NSPs, and achieve rapid protective response and effective Inter Cloud/Inter Provider DDoS attack mitigation.

We propose the following categories of basic set of Inter-cloud APIs:

1)      Capability information exchange: Support "Query" the DDoS capabilities from one provider to another provider.

2)      Mitigation Request and response: One provider can "Request" for mitigation. The provider received DDoS mitigation request can ack request, execute mitigation procedure,  and respond back.

3)      Monitoring and Reporting: Allow another provider to monitor DDoS status and mitigation processes; and provide DDoS status reports to partner providers.

4)      Knowledge sharing: Allow partner providers to query for a specific DDoS related data to enhance their DDoS resiliency and perform coordinated mitigation whenever possible.

We also propose to use REST API format (examples in the draft).

We'd like to discuss on the list, and F2F at IETF95. We are open to ideas, and welcome contributions to progress the draft and make it usable for deployment.

Thanks,
Luyuan

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 29 Mar 2016 23:14:37 +0000

LuYuan,

DOTS people pointed out that the request for help in mitigating DDoS  between Providers  is not that much different from an end point requesting for help in mitigating DDoS. While you can continue the debate on why request for DDoS mitigating between providers is different on the DOTS mailing list, we (I2NSF mailing list) can focus on the discussion to piece out the portion from your draft that might fit the I2NSF WG scope.

With a more close-up look at your draft, it seems to me that you also want to specify the interfaces (i.e. the Restful APIs in Section 4.2) between operators (or Domains). The  Section 4.2 specifies the policies/rules to restrict or rate limit certain traffic from one domain to another, and the capability inquiry from one domain to the other.
This portion might fit to the I2NSF Service Layer  Interface.  While DOTS is signaling between DDoS mitigation client and servers, I2NSF is to for one party to specify the rules/policies to the other party on how to treat  their specific traffic.

If you agree with my analysis,  you can elaborate this aspect for  I2NSF WG.  That means, the goal in I2NSF is more about one domain informing another domain on the rules/policies to treat their specific traffic.

As I2NSF is converging to Event- Condition - Action paradigm, do you think the "Security Object" of your proposed Rules can be articulated in to the following format:

o   Event ,

o   Condition (such as bandwidth threshold for specific ports, or flows, plus contextual condition) , and

o   Actions (such as Alert, Rate Limiting, Invoking a function, etc)
Thanks, Linda

From: Luyuan Fang [mailto:[email-masked]]
Sent: Sunday, March 27, 2016 10:44 PM
To: [email-masked]
Cc: Linda Dunbar; [email-masked]
Subject: draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

Thanks,
Luyuan

---

From: Luyuan Fang <[email-masked]>
Date: Wed, 30 Mar 2016 03:24:11 +0000

Hi Linda,

Thank you for highlighting the important aspects here, very much appreciated.
See in-line my comments marked with [lf].

From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, March 29, 2016 4:15 PM
To: Luyuan Fang <[email-masked]>; [email-masked]
Cc: [email-masked]; Tobias Gondrom <[email-masked]>; Roman D. Danyliw <[email-masked]>
Subject: piece out I2NSF portion and DOTS portion from the draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

LuYuan,

[lf] Inter-provider cases are VERY different than inter-region within ourselves, or inter-connecting to end customers. To be more granular, even Inter-provider case varies between each partner provider we are working with. But at least we want to have a set of standard API we can based on when working between providers.

[lf] Very much agree with you, Linda. Actually, the APIs we are talking about, not necessarily limited to DDoS mitigation, it is about security policy in general. And the API is not only used when DDoS attack happens, it is used to exchange information before and after the attacks, and at any time.

For example, we work with an ISP in a different country, we like to exchange security policy info at the time the connection is set up, or when this new API implemented by both sides. The info can include: Here is our security capability and policies, what is yours? We want you to block certain traffic coming to us (the policy can be changes real time), we can do the same for you upon request. We are observing DDoS happening in certain networks, want share with you on the attack signature, volume, location, time stamp, etc. We expect the partners share the same with us. Or even let's agree on a combined mitigation strategy together (this may need more than simple API, or possible predefined as plan A, plan B, circuit move, etc.)

o   Event ,

[lf] Yes.

Thanks, Linda

Thanks,
Luyuan

From: Luyuan Fang [mailto:[email-masked]]
Sent: Sunday, March 27, 2016 10:44 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

We posted draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01 on 3/21.
https://tools.ietf.org/html/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01&data=01%7c01%7clufang%40microsoft.com%7c0ff928ed5b13415cded008d35827eb98%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2bRo6twc5iJhrVZNqQe3LvcK6DwUAxlycOK4Xsn%2bGUos%3d>

Thanks,
Luyuan

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 30 Mar 2016 15:34:47 +0000

Lu Yuan,

Thanks for the reply.

For I2NSF WG, can you elaborate the following statement, i.e. drilling down to the detailed attributes/parameters needed for the "SecurityObject" used for Inter-domain security policy & capability exchange?  That will be very useful in shaping up the I2NSF Service Layer Information & data model.

Thanks, Linda

From: Luyuan Fang [mailto:[email-masked]]
Sent: Tuesday, March 29, 2016 10:24 PM
To: Linda Dunbar; [email-masked]
Cc: [email-masked]; Tobias Gondrom; Roman D. Danyliw
Subject: RE: piece out I2NSF portion and DOTS portion from the draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

Hi Linda,

From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, March 29, 2016 4:15 PM
To: Luyuan Fang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Tobias Gondrom <[email-masked]<mailto:[email-masked]>>; Roman D. Danyliw <[email-masked]<mailto:[email-masked]>>
Subject: piece out I2NSF portion and DOTS portion from the draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

LuYuan,

o   Event ,

Thanks, Linda

Thanks,
Luyuan

Thanks,
Luyuan

---

From: Luyuan Fang <[email-masked]>
Date: Wed, 30 Mar 2016 19:37:51 +0000

Thanks Linda.
We will work more with the focus around "information model of the inter-provider security policy  & capability exchange", and we plan to upload new version next Monday.
Thx,
Luyuan

Sent: Wednesday, March 30, 2016 8:35 AM

Lu Yuan,

Thanks for the reply.

Thanks, Linda

From: Luyuan Fang [mailto:[email-masked]]
Sent: Tuesday, March 29, 2016 10:24 PM
To: Linda Dunbar; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Tobias Gondrom; Roman D. Danyliw
Subject: RE: piece out I2NSF portion and DOTS portion from the draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

Hi Linda,

LuYuan,

o   Event ,

Thanks, Linda

Thanks,
Luyuan

Thanks,
Luyuan