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

From: Scott Barvick <[email-masked]>
Date: Mon, 29 Jun 2015 20:58:24 +0000

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 – 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.

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.

My contribution of other use cases to consider are:

  1.  Inbound link saturation attack – 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.
  2.  N/M inline mitigation through traffic redirection – 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.
  3.  Virtualized DDoS mitigation appliance – 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.

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 <[email-masked]<mailto:[email-masked]>> on behalf of Xialiang <[email-masked]<mailto:[email-masked]>>
Date: Sunday, June 28, 2015 at 10:59 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 30 Jun 2015 04:40:34 +0700

On 30 Jun 2015, at 3:58, Scott Barvick wrote:

> 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.

The use-case document is a good start, but additional work is needed to 
bring it into alignment with scenarios typically seen on production 
networks.

What we're really talking about with DOTS is a signaling mechanism - 
anything architectural or situationally-specific regarding 
detection/classification/traceback and/or mitigation mechanisms beyond 
simple verbs is probably out of scope.  That would also include 
topological references like NFV as well as adjectives like 'virtual' and 
so forth.

Some terms like supplicant, broker, relay, consumer, controller, et. al. 
may be appropriate in this context.

With regards to use-cases, we must be careful not to overthink them.  
While some basic situationally-specific data points should be included 
in each use-case, we don't want to get too far down into the weeds, 
because we want this communications mechanism to be 
generally-applicable, and we also want to ensure that our ambitions for 
the initial phase are attainable within a reasonable timeframe.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Tue, 30 Jun 2015 01:21:34 +0000

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

发件人: Scott Barvick [mailto:[email-masked]]
发送时间: 2015年6月30日 4:58
收件人: Xialiang (Frank); [email-masked]
抄送: [email-masked]
主题: Re: [Dots] My comments on draft-mglt-dots-use-cases-00:

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 – 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?

  1.  Inbound link saturation attack – 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?

  1.  N/M inline mitigation through traffic redirection – 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.

  1.  Virtualized DDoS mitigation appliance – 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?
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

Hi Daniel,

Thanks!

B.R.
Frank

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Tue, 30 Jun 2015 01:24:49 +0000

Hi Roland,
Please see my comments inline:

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Roland Dobbins
发送时间: 2015年6月30日 5:41
收件人: [email-masked]
主题: Re: [Dots] My comments on draft-mglt-dots-use-cases-00:

> agreeing on them for the WG purposes will be important.

The use-case document is a good start, but additional work is needed to bring it into alignment with scenarios typically seen on production networks.

What we're really talking about with DOTS is a signaling mechanism - anything architectural or situationally-specific regarding detection/classification/traceback and/or mitigation mechanisms beyond simple verbs is probably out of scope.  That would also include topological references like NFV as well as adjectives like 'virtual' and so forth.
[Frank]: make sense

[Frank]: agree

With regards to use-cases, we must be careful not to overthink them.  
While some basic situationally-specific data points should be included in each use-case, we don't want to get too far down into the weeds, because we want this communications mechanism to be generally-applicable, and we also want to ensure that our ambitions for the initial phase are attainable within a reasonable timeframe.
[Frank]: agree

_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 30 Jun 2015 09:06:21 +0700

> for the centralized decision.

This may or may not the be the case; we can postulate it in a given 
scenario, but this is an architectural decision which is out of scope 
for this WG, IMHO.

Our task is to build a communications protocol suited to communicating 
information regarding the need for, and some degree of guidance 
regarding, the mitigation of DDoS attacks.  Whether this protocol is 
used in a centralized or decentralized system is immaterial to us, in 
this context.

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Tue, 30 Jun 2015 02:24:36 +0000

The architecture will influence the protocol and signaling content perhaps. We need to consider it. 
Of course, the architecture irrelevant protocol is what we pursue.

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Roland Dobbins
发送时间: 2015年6月30日 10:06
收件人: [email-masked]
主题: Re: [Dots] My comments on draft-mglt-dots-use-cases-00:

> for the centralized decision.

This may or may not the be the case; we can postulate it in a given scenario, but this is an architectural decision which is out of scope for this WG, IMHO.

Our task is to build a communications protocol suited to communicating information regarding the need for, and some degree of guidance regarding, the mitigation of DDoS attacks.  Whether this protocol is used in a centralized or decentralized system is immaterial to us, in this context.

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 30 Jun 2015 09:53:02 +0700

On 30 Jun 2015, at 9:24, Xialiang (Frank) wrote:

> The architecture will influence the protocol and signaling content 
> perhaps.

Only to the extent that there will be controllers, consumers, and relays 
(or similarly-named participating nodes/roles) and so forth within the 
communications scheme, and with regards to considerations which apply 
under attack conditions

It isn't within the scope of this to recommend, or even define, a 
detection/classification/traceback/mitigation architecture.  It is 
certainly within scope to consider various architectures to the small 
extent that such consideration may have an influence on protocol 
requirements.

---

From: John Schiel <[email-masked]>
Date: Tue, 30 Jun 2015 00:00:49 -0600

On Mon, Jun 29, 2015 at 3:40 PM, Roland Dobbins <[email-masked]> wrote:

>  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.
>>
>
> simple verbs is probably out of scope.  That would also include topological
> references like NFV as well as adjectives like 'virtual' and so forth.
>

Agreed. I'm not so sure NFV or any other VM architecture really needs to be
specifically called out. Let the vendor determine what is virtual and what
is not. The protocol shouldn't care whether the device is an appliance or a
VM but should be able to communicate the parameters of the attack, report
on the attack, mitigate the attack and report on the effectiveness of the
attack.

> may be appropriate in this context.

+1

--John Schiel

> While some basic situationally-specific data points should be included in
> each use-case, we don't want to get too far down into the weeds, because we
> want this communications mechanism to be generally-applicable, and we also
> want to ensure that our ambitions for the initial phase are attainable
> within a reasonable timeframe.
>

---

From: Scott Barvick <[email-masked]>
Date: Tue, 30 Jun 2015 15:37:11 +0000

Follow-up on some of the specific question embedded below…

Scott

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

Hi Scott,

发件人: Scott Barvick [mailto:[email-masked]]
发送时间: 2015年6月30日 4:58
收件人: Xialiang (Frank); [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [Dots] My comments on draft-mglt-dots-use-cases-00:

[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…

[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 – 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 – 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

Hi Daniel,

Thanks!

B.R.
Frank