Subject: [Dots] DOTS Telemetry

From: Ehud Doron <[email-masked]>
Date: Thu, 16 Feb 2017 14:43:55 +0000

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: Thu, 16 Feb 2017 21:52:29 +0700

> Kindly, we will appreciate any kind of feedbacks,

This is duplicative of existing telemetry formats such as NetFlow, 
IPFIX, dnstap, et. al., and should be more properly addressed in the 
relevant WGs, IMHO.  The requirements-draft definition is intended to 
explain terminology used in discussions.

There is no need for any additional telemetry in order to get DOTS to 
MVP status.  Let's concentrate on the signaling functionality, and 
circle back to telemetry after that?

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