Subject: Re: [Dots] DOTS Telemetry

From: "Teague, Nik" <[email-masked]>
Date: Thu, 16 Feb 2017 15:14:50 +0000

On 16/02/2017, 14:43, "Dots on behalf of Ehud Doron" <[email-masked] on behalf of [email-masked]> wrote:

    As part of the WG effort to define the DOTS baseline features (the DOTS MVPs), we would like to get the WG feedbacks about the abovementioned telemetry categories and also about other possible suggested telemetry categories. We encourage group members from both vendors and service providers to bring-in their valuable feedbacks and needs on this matter.

I wouldn’t classify telemetry as an optional feature as necessary or relevant to MVP – Telemetry has varying degrees of usefulness depending upon specific architectures or vendor implementations and in many cases, may be covered by other mechanisms such as flow collection etc. to the point of being redundant all together.  I don’t believe telemetry should be included in the base DOTS signals and as its frequently called out to be optional I would simply look to utilize extensions or vendor specific fields.

Thanks,

-Nik

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 16 Feb 2017 22:16:11 +0700

On 16 Feb 2017, at 22:14, Teague, Nik wrote:

> I don’t believe telemetry should be included in the base DOTS 
> signals and as its frequently called out to be optional I would simply 
> look to utilize extensions or vendor specific fields.

+1

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

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 16 Feb 2017 16:43:59 -0500

> I wouldn’t classify telemetry as an optional feature as necessary or relevant to MVP – Telemetry has varying degrees of usefulness depending upon specific architectures or vendor implementations an…
I agree for a very basic definition of MVP, but we clearly have several 
requirements that go beyond MVP (e.g. most of the data-channel 
definition), so where do we draw the line (this is the recurring 
mandatory/optional/extension classification of requirements, that we 
have yet to complete) ?

Looking at requirements that (potentially) pertain more directly to 
telemetry, we have for example:

    OP-007  Mitigation Efficacy: When a mitigation request by a DOTS
       client is active, DOTS clients SHOULD transmit a metric of
       perceived mitigation efficacy to the DOTS server, per "Automatic
       or Operator-Assisted CPE or PE Mitigators Request Upstream DDoS
       Mitigation Services" in [I-D.ietf-dots-use-cases].  DOTS servers
       MAY use the efficacy metric to adjust countermeasures activated on
       a mitigator on behalf of a DOTS client.

We also have the following as part of OP-004 (for the reverse direction):

       A server MAY refuse to engage in coordinated attack response with
       a client.  To make the status of a client's request clear, the
       server MUST indicate in server signals whether client-initiated
       mitigation is active.  When a client-initiated mitigation is
       active, and threat handling details such as mitigation scope and
       statistics are available to the server, the server SHOULD include
       those details in server signals sent to the client.  DOTS clients
       SHOULD take mitigation statistics into account when deciding
       whether to request the DOTS server cease mitigation.

What are your thoughts on satisfying those requirements ?

Thanks

-- Flemming

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

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 17 Feb 2017 05:42:48 +0700

> What are your thoughts on satisfying those requirements ?

Those things aren't 'telemetry' in the sense it's used in the DDoS 
mitigation space.  It's status information.

And it ought to be standardized as part of this WG's efforts at some 
point, IMHO.

However, that's more of a forward-looking recommendation.  Quantifying 
mitigation efficacy is something that we want to see included within the 
scope of DDoS mitigation solut to ionsthe degree that it's practical to 
do so, but is not a capability we really see today.  It's largely done 
out-of-band to date.

So, this shouldn't be a MVP requirement, because it's forward-looking 
guidance.  We want to a) encourage its implementation and adoption and 
b) be ready to accommodate it once it's implemented and adopted.

---

From: kaname nishizuka <[email-masked]>
Date: Fri, 17 Feb 2017 22:13:12 +0900

>> What are your thoughts on satisfying those requirements ?
client-to-server and server-to-client bandwidth information are very important for our network's DDoS protection.
Let me introduce our way to satisfy these requirement.

* client-to-server
We are providing various countermeasures: 1) RTBH, 2) ACL and 3) dedicated mitigation boxes.
We are requesting our customers to send attack bandwidth(bps/pps) information before starting the request for protection because we are caring about the rest of capacity of the mitigation boxes.
If the mitigation boxes could be overwhelmed when the new protection request is added on them, we avoid to use them and select RTBH/ACL to protect our customer and our platform(mitigation boxes). Then, bandwidth information from client to our system is crucial hint of selection of the countermeasures.

* server-to-client
We are providing bandwidth(bps/pps) information of passed(it seems legitimate) and dropped traffic to our customers.
This is critical requirement from customers.
They want to check the efficacy of the protection, then if it is not satisfactory, they will decide to take another action to make their services work again as soon as possible.

With these in my mind, I draw lines like this:
mandatory: MVP(targeted IP etc..)
optional: Bandwidth(bps/pps) information (client-to-server and server-to-client)
extension: other telemetries

I think DOTS is mainly about volumetric DDoS attacks because it is concerning about the hostile condition of upper circuit.
If DOTS protocol can convey volumetric information in its spec, it is reasonable and can relief operators who are interested in using it.

When it comes to WG strategy, I tend to agree with Roland's step-by-step approach.
step1:  concentrate on the signaling functionality, step2: circle back to telemetry

thank you,
Kaname

On 2017/02/17 7:42, Roland Dobbins wrote:
> Those things aren't 'telemetry' in the sense it's used in the DDoS mitigation space.  It's status information.
>
> And it ought to be standardized as part of this WG's efforts at some point, IMHO.
>
> However, that's more of a forward-looking recommendation. Quantifying mitigation efficacy is something that we want to see included within the scope of DDoS mitigation solut to ionsthe degree that it's practical to do so, but is not a capability we really see today.  It's largely done out-of-band to date.
>
> So, this shouldn't be a MVP requirement, because it's forward-looking guidance.  We want to a) encourage its implementation and adoption and b) be ready to accommodate it once it's implemented and adopted.
>

---

From: "Dobbins, Roland" <[email-masked]>
Date: Fri, 17 Feb 2017 13:21:00 +0000

On Feb 17, 2017, at 20:13, kaname nishizuka <[email-masked]<mailto:[email-masked]>> wrote:

I think DOTS is mainly about volumetric DDoS attacks because it is concerning about the hostile condition of upper circuit.
No, it isn't mainly about volumetric attacks - that's just what a lot of the discussion is about.

It applies to all forms of DDoS attack - by design.

There's nothing about DOTS which is specific to circuit conditions.

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

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

---

From: Barry Raveendran Greene <[email-masked]>
Date: Fri, 17 Feb 2017 05:57:35 -0800

> On Feb 17, 2017, at 5:13 AM, kaname nishizuka <[email-masked]> wrote:
> 

On the Telemetry side, this sort of information is NOT going to make a dent in the problem. We need information that would contribute to a trackback and backtrace to a DOS attack. 

For the people who really mitigate attacks, the most tedious part of the process is calling each of their peers for whom the attack is inbound from, then working with them to trace back to that peer’s entry point. From there, the next upstream point of the attack. Then getting into the ASN to find the origin points. If the ASN has the tools turned on the router to do traffic engineering and traffic analytics for business/planning, then they also have the tools to run the tracebacks. That would be an ideal tools for DOTS Telemetry to “ask for information.”

This was done in TIDP/TMS. So it can be done.

---

From: "Dobbins, Roland" <[email-masked]>
Date: Fri, 17 Feb 2017 14:05:30 +0000

On Feb 17, 2017, at 20:57, Barry Raveendran Greene <[email-masked]<mailto:[email-masked]>> wrote:

This was done in TIDP/TMS. So it can be done.
When operators have DOTS peers set up, all they have to do is request mitigation for the target.  Their peers do the same, etc.

That will spread mitigation in 'inkblot' fashion - i.e., 'traceback via pervasive mitigation'.

The status messages also serve this purpose.

If we want to add explicit traceback requests later, we can.  But pervasive mitigation in and of itself accomplishes the goal, to a large extent.