Re: [Dots] 答复: My comments on draft-mglt-dots-use-cases-00:

[Scott Barvick <[e-mail]>]

Follow-up on some of the specific question embedded below¡­

Scott


From: Dots [mailto:[e-mail]] On Behalf Of Xialiang (Frank)
Sent: Monday, June 29, 2015 9:22 PM
To: Scott Barvick
Cc: [e-mail]; [e-mail]
Subject: [Dots] ´ð¸´: My comments on draft-mglt-dots-use-cases-00:

Hi Scott,
Thanks for your comments. My comments are inline:

·¢¼þÈË: Scott Barvick [mailto:[e-mail]]
·¢ËÍʱ¼ä: 2015Äê6ÔÂ30ÈÕ 4:58
ÊÕ¼þÈË: Xialiang (Frank); [e-mail]<mailto:[e-mail]>
³­ËÍ: [e-mail]<mailto:[e-mail]>
Ö÷Ìâ: Re: [Dots] My comments on draft-mglt-dots-use-cases-00:

These documents are good starts on capturing the use cases that we will use to drive the requirements for our work.

I tend to agree with Frank¡¯s comments below and believe that we have to be careful to not create complex new architectural components (e.g. Controller or Flow Repository) that will limit implementation and deployment options ¨C and might not work in some cases (see my #1 below).   Perhaps it just a case of only 6 use cases out of many more captured so far that we need to document as an official output of the WG.
[Frank]: At this initial stage, having different use cases is not a bad thing. Actually, they can help us to consider and discuss more widely and find the right direction to solve the real requirements. DOTS work can have a evolving path. Of course, we must focus down to the key use cases and solution in the first stage, then we can extend DOTS work scope to more advanced use cases or solutions.

One thing these documents and my contribution below highlight is that we will need to quickly agree on the terms we will use for the endpoints that are communicating e.g. DDoS mitigation appliance/function, Virtualized DDoS mitigation appliance, NFV DDoS monitor/mitigation, DOTS Receiver, DOTS Collecting Process, etc.  I know we all might use slightly different terms in our daily lives so agreeing on them for the WG purposes will be important.
[Frank]: Agree. But how to?

[Scott] I agree with how the conversation went in subsequent messages.    The best path may be to just give names to the endpoints representing generic producer/consumer operation.  That will keep particular implementation specifics from creeping in.   More on this in other threads¡­


My contribution of other use cases to consider are:

  1.  Inbound link saturation attack ¨C This may sound similar to hybrid use case identified in both drafts, but the point needs to be made that if the inbound link becomes saturated by a DDoS attack, even with a DDoS appliance that can handle the load, we need to make sure that the communication protocol used to signal either the traffic level data or DDoS alert will not fail if response traffic is caught behind the saturation attack.   I particularly like this use case because it is real and it will enforce a discipline of focus and efficiency on us.  It also will help us identify exactly what information needs to be signaled in order for the upstream provider to reroute the most specific data possible so that as the cloud-based scrubbing center isn¡¯t itself overwhelmed or the cause of excessive latency to good traffic.
[Frank]: what information needs to be signaled has nothing to do with the inbound link saturation condition, what protocol to carry these information does. In addition, do you imply that DOTS may signal the reroute policy?

[Scott] I disagree that the information that needs to be signaled has nothing to do with the saturation condition.  In that situation, the traffic will be dominated by the attack traffic, most likely to a small set of victim destinations and ports and probably from a large set of (reflected) source addresses.   This information would be useful to the other side of the signaling channel to (probably, but not necessarily) result in a reroute.  I am NOT saying that DOTS will be specifying a reroute policy.  What to do with the signaled information is for the receiver of the signal to decide and is out of scope for us.

  1.  N/M inline mitigation through traffic redirection ¨C In an inline DDoS appliance scenario with several (M) links operating as a single trunk (e.g. Mx10G links), it may be the case that only N appliances would be deployed in the trunk and a DDoS signal could be sent to reroute flows through one of the N inline DDoS appliances.  Note that this is all local and will likely have the luxury of a separate management network that will not be affected during an attack.
[Frank]: interesting. In this use case, maybe a controller is needed for the centralized decision.
[Scott] The use of something called a controller or how a decision gets made based on signals would be outside the scope of DOTS.   All DOTS needs to do is be able to provide IPFIX (-like) info or signals from something watching/sampling the data to someone who can affect the change in the event of an attack.

  1.  Virtualized DDoS mitigation appliance ¨C I realize the example in Section 4 of draft-xia defines NFV perhaps in this way, but we need to have 2 use cases (at least), one for the basic case of virtualizing an appliance, complete with access to network ports, but yet running in a hypervisor and capable of being spun up or down on demand in front of other VM-based servers and services.    The other is the full NFV service-chaining infrastructure that continues to gain momentum as well.   Both will exist as we roll out this document.
[Frank]: two NFV use cases: single VNF vs NFV service-chaining? Where are they deployed?
[Scott]  Both of these cases have plenty of examples of real or projected deployments in product and standards documents.   Some might end up more likely than others, but there are enough of each that these use cases should be on our list so that we can checkpoint our solution(s) against deployments in these types of scenarios.
I¡¯m sure I will think of more, but I wanted to keep the discussion going so that we can get as much on the table before the next meeting.

Regards,
Scott

From: Dots <[e-mail]<mailto:[e-mail]>> on behalf of Xialiang <[e-mail]<mailto:[e-mail]>>
Date: Sunday, June 28, 2015 at 10:59 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [Dots] My comments on draft-mglt-dots-use-cases-00:

Hi Daniel,
Thanks for bringing the use case draft for DOTS. I have reviewed it and have some comments on it:
1. In the introduction section, the statement made in the first paragraph "...make DDoS attacks harder to be detected at a single point" is a little vague. I don't think the following examples of this section explain the statement well. They can be detected by one dpi device nowadays in fact, which only needs more fine-grained monitoring and more detecting intelligence, i.e., signature, session state analysis, etc. The coordination between distributed anti-ddos system aims for not only detecting, but also for mitigating with better accuracy, performance and efficiency. Maybe better examples can be on-premise anti-ddos device plus anti-ddos cloud service and attack source tracking, and so on;
2. Actually, dedicated anti-ddos appliance can detect ddos attacks by itself and send the attack infomation to controller directly, not every ddos attacks need to be determined by the controller;
3. The flow repository is not essential in some cases, although it's very important for ddos centralized analysis based on flow information in many cases;
4. For On-premise Asymmetric Use Case, why does it still need ddos monitoring for the outbound traffic if the ddos mitigation function is not provided for it?

FYI, we have submitted another DOTS use cases draft to describe several promising DOTS use cases being complementary to yours, your review and comments are welcome.

Thanks!

B.R.
Frank