Hi, I know I come to this issue with a long delay, but this is the problem you have to deal when trying to keep so many knives in the air…
Looking at Luyuan document, and the further discussions with the chairs I tend to see a clear value in the proposal, and a clear applicability to what we could call a recursive I2NSF, able to support some of the use case we are considering in the ETSI NFV SEC working group on different security domains, and the considerations around network slicing in the 5G community, going beyond the (already interesting) use case of the collaboration between cloud and network providers. Be goode, On 30 Mar 2016, at 05:24 , Luyuan Fang <[email protected]<mailto:[email protected]>> wrote: 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 protected]] Sent: Tuesday, March 29, 2016 4:15 PM To: Luyuan Fang <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Tobias Gondrom <[email protected]<mailto:[email protected]>>; Roman D. Danyliw <[email protected]<mailto:[email protected]>> Subject: piece out I2NSF portion and DOTS portion from the draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01 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. [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. 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. [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.) 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) [lf] Yes. Thanks, Linda Thanks, Luyuan From: Luyuan Fang [mailto:[email protected]] Sent: Sunday, March 27, 2016 10:44 PM To: [email protected]<mailto:[email protected]> Cc: Linda Dunbar; [email protected]<mailto:[email protected]> Subject: draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01 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<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> 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 _______________________________________________ I2nsf mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: [email protected] Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
