Subject: Re: [Dots] DOTS Telemetry

From: Ehud Doron <[email-masked]>
Date: Tue, 21 Feb 2017 08:22:32 +0000

All

My personal thought about the DOT Telemetry  (and I am speaking for myself, not for the other DOTS Telemetry draft authors) is that in order to build a viable anti-DoS service, both NOC / SOC teams at client and server side will definitely need some sort of information about the on-going attack being mitigated. No doubt about that.

When it comes to operations of DDoS attacks, "life can be complicated" in the sense that attacks are not always successfully mitigated and cases of blocking legitimate traffic can be frequent.... Therefore I believe that the so called "Telemetry for Visibility" is mandatory, for some extent. Meaning that information about attacks (whether we call it telemetry or use other terminology) need to be presented to the SOC/NOC teams, and we MUST deal with it as an MVP. I think that what Tiru has suggested in the Signal Channel draft can be a very good starting point.

My concerns are that if such information will not be covered as part of DOTS standard, we will end up with a lot of vendor extensions and other "out of band" proprietary signaling... and I don't think that this is the ultimate goal of IETF in general and in particular for DOTS.

As per the "Telemetry for Mitigation" below, I have some concerns that this part might be more complicated and can tend to be aligned with a specific implementation, thus can be difficult to standardized. Therefore I think that this part can be considered in the future phases of DOTS.

Thanks,
Ehud Doron |  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120

From: Ehud Doron
Sent: Thursday, February 16, 2017 4:44 PM
To: 'dots' <[email-masked]>
Subject: DOTS Telemetry

All

Following the WG last F2F meeting in Seoul, we would like to elaborate the discussion about the DOTS Telemetry, mainly its general aspects and directives.

Up to now, we have two declarations for DOTS Telemetry:

1.       The DOTS Requirement draft draft-ietf-dots-requirements-03d defines : "DDoS attack telemetry:  Collected behavioral characteristics defining the nature of a DDoS attack. " .

2.       The DOTS Telemetry draft draft-doron-dots-telemetry-00  defines  ""DOTS Telemetry" is defined as the collection of attributes characterizing the actual attacks that have been detected and mitigated. The DOTS Telemetry is an optional set of attributes that can be signaled in the various DOTS protocol messages. The DOTS Telemetry can be optionally sent from the DOTS Client to Server and vice versa.

We are now figuring out the general view on the DOTS Telemetry theme and have mapped two main categorizes of telemetry we believe are most relevant to DOTS:

1.       Telemetry for Visibility - The main objectives of this category is to allow SOC / NOC teams, on both DOTS Client and Server side, to gain visibility on the overall service provided by facilitating the DOTS signaling. As perceptible examples, we can suggest the Mitigation Status requirement (OP-004 from DOTS Requirement draft), attack details, attack BW and PPS, packet / bytes drops and so on.

2.       Telemetry for Mitigation - The main objective of this category is to allow mitigation facilities to improve their detection and mitigation performance. As perceptible examples, we can suggest the Mitigation Efficacy requirement (OP-007 from DOTS Requirement draft), traffic baseline in certain levels and so on.

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. It is preferable for us to get feedbacks on the suggested categories as a whole, rather than on a specific telemetry attribute within a specific category.

The main objective is allowing us to be able to direct, and focus, our work on draft-doron-dots-telemetry-00  according the WG directives and needs.

Kindly, we will appreciate any kind of feedbacks,

DOTS Telemetry draft authors

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 21 Feb 2017 15:53:02 +0700

On 21 Feb 2017, at 15:22, Ehud Doron wrote:

> that in order to build a viable anti-DoS service,

Viable DDoS mitigation services exist today, and have for years.  Lots 
of them.

> both NOC / SOC teams at client and server side will definitely need 
> some sort of information about the on-going attack being mitigated.

This information is already available, in different forms, and has been 
for years.

> Therefore I believe that the so called "Telemetry for Visibility" is 
> mandatory,

It is *not* mandatory to be included in DOTS, according to the sense of 
the WG.  Currently, we are focusing on the signaling mechanisms, 
communications models, and MVP functionality which allows bidirectional 
signaling to take place.

That is the MVP.  Everything else is extra, above and beyond that.

If one reads through the various drafts, meeting minutes, and the 
considerable discussion which has taken place over the history of the 
WG, one will see that this has already been discussed in great detail, 
and that the general sense is that it's best to focus on the immediate, 
well-bounded task of creating a viable standards-based signaling 
mechanism first.

Let's concentrate on the task at hand, first, and get something out the 
door that vendors and coders can implement and get some immediate relief 
out there which will make a measurable positive impact on coordinated 
DDoS mitigation efforts.

We definitely want to ensure that DOTS can be extended in future phases 
to cover areas which the WG membership deem to be in-scope and 
important.

> Meaning that information about attacks (whether we call it telemetry 
> or use other terminology) need to be presented to the SOC/NOC teams, 
> and we MUST deal with it as an MVP.

I couldn't disagree more.  Telemetry is available and used today.  There 
is no need to re-invent that wheel in the DOTS WG.

Status-messaging is enough to get DOTS off the ground in an immediately 
useful and deployable form.  Let's concentrate on that, first.

Getting deep into telemetry formats is a significant challenge and one 
which isn't restricted to the DDoS arena.  It's both broader and deeper, 
and much more generally applicable.  Once DOTS Phase I is out there and 
being adopted, we can then take a look at telemetry, and determine if we 
need to work with the appropriate WGs to enhance existing standards, or 
simply adopt them as-is.

> My concerns are that if such information will not be covered as part 
> of DOTS standard, we will end up with a lot of vendor extensions and 
> other "out of band" proprietary signaling...

That is the reality today.  The initial intent is to supplement, not 
replace, those siloed systems.  Again, note that readily-extensible, 
standards-based telemetry formats are already in use today.  There is no 
lack of telemetry formats to choose from.

At some point, these additional aspects of the problem-space can be 
addressed.  What we're building with DOTS isn't intended to *replace* 
extant mechanisms - it is a *new* mechanism which provides capabilities 
which do not already exist.

Standards-based telemetry already exists.  Standards-based mitigation 
assistance signaling *doesn't* already exist.  And that's the gap DOTS 
is intended to address.

We have to restrict our scope to something that is well-defined, solves 
real-world problems, and is achievable in a finite amount of time, or 
we'll never get anything out the door.

> and I don't think that this is the ultimate goal of IETF in general 
> and in particular for DOTS.

We are creating something with DOTS which doesn't already exist - i.e., 
a standards-based mechanism for organizations to request/provide DDoS 
mitigation assistance.  That is something new and immediately useful.

Scope-creep is something we should guard against.  Let's not make the 
perfect the enemy of the merely good, yes?

;>

> As per the "Telemetry for Mitigation" below, I have some concerns that 
> this part might be more complicated and can tend to be aligned with a 
> specific implementation, thus can be difficult to standardized.

Correct.

> Therefore I think that this part can be considered in the future 
> phases of DOTS.

Concur 100% - we should take a measured look at these additional areas 
of the problem space after we've addressed the fundamental challenge of 
inter- (and intra-) organizational DDoS mitigation assistance 
signaling/response.

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