Subject: [Dots] Questions about draft-doron-dots-telemetry-00

From: "Roman D. Danyliw" <[email-masked]>
Date: Fri, 11 Nov 2016 04:29:37 +0000

Hello Ehud, Tiru, Flemming, Frank and Kaname!

Thanks for producing and submitting this draft!

Without getting into the details, what did you have in mind with this draft.  Specifically:

(1) Is there an undocumented telemetry use case that needs to be added to the use case WG document?  Section 4.0 suggests that.

(2) Is there another protocol draft coming that will incorporate the attributes enumerated in Section 3?  Or are the existing protocol drafts supposed to adopted these?

(3) What is the relationship you see between this draft and draft-andreasen-dots-info-data-model-01 (especially given all the authors on the latter are in the former as well)?

Thanks,
Roman

---

From: Ehud Doron <[email-masked]>
Date: Mon, 14 Nov 2016 08:14:23 +0000

Hi Roman

Thanks a lot for your questions.

Before getting in to each of your question, I would like to explain the goal and objectives of our work.

We want to define and standardize all the pieces of information needed by DOTS Server mitigation environment for optimal mitigation. This DOTS Telemetry need to be optionally signaled as part of "DOTS Client asks Server for help" various signaling process.

We want to bring the DOTS Telemetry various needs and meanings to be discussed and agreed in the DOTS WG.

After we will all get to the agreement on the various attributes needed, we believe the other DOTS "core" docs need to somehow adopt them and update accordingly.

Essentially we would like to build a "Telemetry" extension standard to the basic DOTS protocol, and this document would define that. Keeping the telemetry specification in a separate draft is good approach for future extensibility.

We expect that the other DOTS draft will benefit this draft by adopting the approaches it suggests to enrich the DOTS signaling. For this goal, we as the DOTS WG first need to better understand (and agree in the group) what we see as baseline mandatory capabilities and what we see as extensions. We are just at the early stages of this work, the current draft defines an initial set of attributes and obviously more discussions in the WG are needed to define the set of attribute that are the "DOTS Telemetry", and to what extend the other DOTS draft should benefit the DOTS Telemetry.

To your questions:

(1) Is there an undocumented telemetry use case that needs to be added to the use case WG document?  Section 4.0 suggests that.
     Yes. We want to DOTS use cases, the existing and maybe new others, to be enriched with Telemetry related items. It is important to emphasize "when and where" DOTS Telemetry can , or should, be signaled such that the mitigation gained for the use case is far better. We want also the other docs (requirements, architecture, protocols, data model and so on) to take the similar approaches.

(2) Is there another protocol draft coming that will incorporate the attributes enumerated in Section 3?  Or are the existing protocol drafts supposed to adopted these?
      As said, the existing protocol drafts supposed to adopt DOT Telemetry approaches by incorporating the attributes enumerated in this draft.

(3) What is the relationship you see between this draft and draft-andreasen-dots-info-data-model-01 (especially given all the authors on the latter are in the former as well)?
      The DOTS Telemetry draft purpose is to define the Telemetry attributes needed. The actual data model objects needed to signal these attributes are expected to be define in the info-data model doc. The info-data model draft will define an extension mechanism that supports adding telemetry. To what extent it will also define telemetry is a more open question for the group.

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

From: Roman D. Danyliw [mailto:[email-masked]]
Sent: Friday, November 11, 2016 6:30 AM
To: Ehud Doron <[email-masked]>; [email-masked]; [email-masked]; Xialiang (Frank) <[email-masked]>; kaname nishizuka <[email-masked]>
Cc: [email-masked]
Subject: Questions about draft-doron-dots-telemetry-00

Thanks,
Roman

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 14 Nov 2016 16:02:09 +0700

On 14 Nov 2016, at 15:14, Ehud Doron wrote:

> Essentially we would like to build a "Telemetry" extension standard to 
> the basic DOTS protocol, and this document would define that.

This may make sense at some future date; initially, since we're dealing 
with devices/software/systems which have radically different paradigms, 
capabilities, and 'worldviews', the initial focus of DOTS should be on 
signaling and status only, as the ins are universal functions which are 
readily understood by most any type of node/service/application which 
could participate in DOTS.

> Keeping the telemetry specification in a separate draft is good 
> approach for future extensibility.

> For this goal, we as the DOTS WG first need to better understand (and 
> agree in the group) what we see as baseline mandatory capabilities 
> other DOTS draft should benefit the DOTS Telemetry.

We've already held extensive discussions on this topic; initially, we 
need a minimum viable capability to allow signaling and status 
information to be passed between DOTS participants.

> (1) Is there an undocumented telemetry use case that needs to be added 
> to the use case WG document?  Section 4.0 suggests that.
>      Yes. We want to DOTS use cases, the existing and maybe new 
> others, to be enriched with Telemetry related items.

This can come at a later state, if the group believes it to be 
important.

It's sub-optimal to duplicate the work done on IPFIX, I2NSF, I2RS, et. 
al. in DOTS.  By leaving mitigation technique specifics and telemetry 
specifics to one side, we can concentrate on signaling and status, which 
is all that's actually required for successful inter- and intra-domain 
DOTS-enabled DDoS mitigation assistance and provisioning.

It's important to get to an initial operating capability with the 
requisite baseline capability before we expand the scope of DOTS itself, 
IMHO.

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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 14 Nov 2016 16:36:44 -0500

On 11/14/16 3:14 AM, Ehud Doron wrote:
> We want to *define and standardize* all the pieces of information 
> needed by DOTS Server mitigation environment for optimal mitigation. 
> This DOTS Telemetry need to be optionally signaled as part of “DOTS 
> Client asks Server for help” various signaling process.
>
> After we will all get to the agreement on the various attributes 
> needed, we believe the other DOTS “core” docs need to somehow adopt 
> them and update accordingly.
>
> the basic DOTS protocol, and this document would define that. Keeping 
> the telemetry specification in a separate draft is good approach for 
> future extensibility.
>
> We expect that the other DOTS draft will benefit this draft by 
> adopting the approaches it suggests to enrich the DOTS signaling. For 
> this goal, we as the DOTS WG first need to better understand (and 
> agree in the group) what we see as baseline mandatory capabilities and 
> what we see as extensions. We are just at the early stages of this 
> work, the current draft defines an initial set of attributes and 
> obviously more discussions in the WG are needed to define the set of 
> attribute that are the “DOTS Telemetry”, and to what extend the other 
> DOTS draft should benefit the DOTS Telemetry.
>
> To your questions:
>
> others, to be enriched with Telemetry related items. It is important 
> to emphasize *“when and where”* DOTS Telemetry can , or should, be 
> signaled such that the mitigation gained for the use case is far 
> better. We want also the other docs (requirements, architecture, 
> protocols, data model and so on) to take the similar approaches.
>
> (2) Is there another protocol draft coming that will incorporate the 
> attributes enumerated in Section 3?  Or are the existing protocol 
> drafts supposed to adopted these?
>
>       As said, the existing protocol drafts supposed to adopt DOT 
> Telemetry approaches by incorporating the attributes enumerated in 
> this draft.
>
> (3) What is the relationship you see between this draft and 
> draft-andreasen-dots-info-data-model-01 (especially given all the 
> authors on the latter are in the former as well)?
>
>       The DOTS Telemetry draft purpose is to *define* the Telemetry 
> attributes needed. The actual data model objects needed to signal 
> these attributes are expected to be define in the info-data model doc. 
> The info-data model draft will define an extension mechanism that 
> supports adding telemetry. To what extent it will also define 
> telemetry is a more open question for the group.
>
To clarify my view on 2) and 3), I think telemetry attributes (with the 
possible exception of a small baseline set) should be defined as 
extensions in separate documents, and that applies to the info-data 
model as well as the protocol. I do think the info-data model as well as 
the protocol should be explicitly defined to accommodate this by 
including an extension model that supports this in a well-defined and 
interoperable manner (modular approach).

Thanks

-- Flemming

> Best wishes,
>
> *Ehud Doron *| Senior Architect, *Radware* CTO office | 
> *M:*+972-54-7575503 | *T:* +972-72-3917120
>
> *From:* Roman D. Danyliw [mailto:[email-masked]]
> *Sent:* Friday, November 11, 2016 6:30 AM
> *To:* Ehud Doron <[email-masked]>; [email-masked]; 
> [email-masked]; Xialiang (Frank) <[email-masked]>; 
> kaname nishizuka <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Questions about draft-doron-dots-telemetry-00
>
> (2) Is there another protocol draft coming that will incorporate the 
> attributes enumerated in Section 3? Or are the existing protocol 
> drafts supposed to adopted these?
>
> (3) What is the relationship you see between this draft and 
> draft-andreasen-dots-info-data-model-01 (especially given all the 
> authors on the latter are in the former as well)?
>
> Thanks,
>
> Roman
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 14 Nov 2016 16:41:06 -0500

On 11/14/16 4:02 AM, Roland Dobbins wrote:
>> Essentially we would like to build a "Telemetry" extension standard 
>> to the basic DOTS protocol, and this document would define that.
>
> This may make sense at some future date; initially, since we're 
> dealing with devices/software/systems which have radically different 
> paradigms, capabilities, and 'worldviews', the initial focus of DOTS 
> should be on signaling and status only, as the ins are universal 
> functions which are readily understood by most any type of 
> node/service/application which could participate in DOTS.
>
>> (1) Is there an undocumented telemetry use case that needs to be 
>> added to the use case WG document? Section 4.0 suggests that.
> This can come at a later state, if the group believes it to be important.
>
The above statements do not seem to align with the discussion of 
telemetry in the use-cases-2 draft ? Can you elaborate ?

> specifics to one side, we can concentrate on signaling and status, 
> which is all that's actually required for successful inter- and 
> intra-domain DOTS-enabled DDoS mitigation assistance and provisioning.
>
Are you saying we don't need the data channel either ?

> requisite baseline capability before we expand the scope of DOTS 
> itself, IMHO.
>
Agreed we should focus on getting a baseline capability in place sooner 
rather than later, especially if we include a solid and interopeable 
extension mechanism from the beginning.

-- Flemming

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

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 15 Nov 2016 08:27:31 +0700

> telemetry in the use-cases-2 draft ? Can you elaborate ?

Not at this time.  -02 is transitional.

> Are you saying we don't need the data channel either ?

Not at all, and apologies for the misimpression!

---

From: Ehud Doron <[email-masked]>
Date: Wed, 16 Nov 2016 16:30:59 +0000

Ronald, Flemming and all

Thanks for your comments. 

I appreciate the standpoints you present in your comments, however I really believe the DOTS WG must also look and consider others views of the challenges DOTS has with regards to DOTS telemetry.   

No doubt that for the world of DDoS services the "security visibility" is a major concern to both the anti-DoS service providers and consumers. In all cases where the DOTS Client will be implemented in an organizations with a sustainable SOC/NOC teams, the ability to have "customer portal" with visibility into the on-going attacks is a critical part of the service. Likewise, anti-DoS service providers need visibility into their customers view on the on-going attacks and other sort of views relates to the service and its fulfillments. These are critical parts of the service. 

Getting deeper, having comprehensive telemetry about the ongoing attacks will improve the overall mitigation accomplished, in terms of time to mitigate, accuracy, false-negative, false-positive, and other measures. We must keep in our minds the value gained here.  

I see all these as a major points and really want to get your view on that, as well as the view of others at the WG.

Obviously, I agree with your points that there are many cases where telemetry is with less relevance, mainly since DOTS agents will be integrated in " radically different paradigms, capabilities, and 'worldviews'...." (which for my opinion is the right architecture). Having say all that, we must consider environments where DOTS Client has DoS/DDoS detection and mitigation capabilities and can practically signal valuable telemetry. These are definitely not rear use cases that must be considered as well. 

For my mind, after we will get to a consensus about WG view on the needs for telemetry, we can define the best way to standardize it (in which doc and how) and also consider the right time to do. Then we can define the baseline set of telemetry we believe are adequate, or the bare minimum, to standardize.  

I am looking forward to continue this discussion with you and the entire the WG.

Please see also my comments inline. 

Best wishes,  

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Monday, November 14, 2016 11:02 AM
To: dots <[email-masked]>
Subject: Re: [Dots] Questions about draft-doron-dots-telemetry-00

> the basic DOTS protocol, and this document would define that.

This may make sense at some future date; initially, since we're dealing with devices/software/systems which have radically different paradigms, capabilities, and 'worldviews', the initial focus of DOTS should be on signaling and status only, as the ins are universal functions which are readily understood by most any type of node/service/application which could participate in DOTS.
[ED] See my view in the body of the mail.

> other DOTS draft should benefit the DOTS Telemetry.

We've already held extensive discussions on this topic; initially, we need a minimum viable capability to allow signaling and status information to be passed between DOTS participants.
[ED] I was not part of this discussions, sorry for that. For my mind, we need to truly define (or re-define...) the needs for DOTS Telemetry for the actual users (SP, MSSP, Enterprises, carrier and so on) of DOTS, and also the baseline set of this telemetry. 

It's sub-optimal to duplicate the work done on IPFIX, I2NSF, I2RS, et. 
al. in DOTS.  By leaving mitigation technique specifics and telemetry specifics to one side, we can concentrate on signaling and status, which is all that's actually required for successful inter- and intra-domain DOTS-enabled DDoS mitigation assistance and provisioning.

[ED] Agree, we shouldn't duplicate any work done at IPFIX, I2NSF.

It's important to get to an initial operating capability with the requisite baseline capability before we expand the scope of DOTS itself, IMHO.

[ED] Agree, we just need to define and get to the mutual understanding about the " baseline capability" in term of telemetry. Mainly for the users and customers of the actual anti-DoS service.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 16 Nov 2016 17:58:00 -0500

Ehud:

Can you indicate what additional features the telemetry that you propose for
DOTS needs over the telemetry provided by IPFIX? 

Sue 

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Ehud Doron
Sent: Wednesday, November 16, 2016 11:31 AM
To: Roland Dobbins; dots; [email-masked]
Cc: Ehud Doron
Subject: Re: [Dots] Questions about draft-doron-dots-telemetry-00

Ronald, Flemming and all

I appreciate the standpoints you present in your comments, however I really
believe the DOTS WG must also look and consider others views of the
challenges DOTS has with regards to DOTS telemetry.   

No doubt that for the world of DDoS services the "security visibility" is a
major concern to both the anti-DoS service providers and consumers. In all
cases where the DOTS Client will be implemented in an organizations with a
sustainable SOC/NOC teams, the ability to have "customer portal" with
visibility into the on-going attacks is a critical part of the service.
Likewise, anti-DoS service providers need visibility into their customers
view on the on-going attacks and other sort of views relates to the service
and its fulfillments. These are critical parts of the service. 

Getting deeper, having comprehensive telemetry about the ongoing attacks
will improve the overall mitigation accomplished, in terms of time to
mitigate, accuracy, false-negative, false-positive, and other measures. We
must keep in our minds the value gained here.  

I see all these as a major points and really want to get your view on that,
as well as the view of others at the WG.

Obviously, I agree with your points that there are many cases where
telemetry is with less relevance, mainly since DOTS agents will be
integrated in " radically different paradigms, capabilities, and
'worldviews'...." (which for my opinion is the right architecture). Having
say all that, we must consider environments where DOTS Client has DoS/DDoS
detection and mitigation capabilities and can practically signal valuable
telemetry. These are definitely not rear use cases that must be considered
as well. 

For my mind, after we will get to a consensus about WG view on the needs for
telemetry, we can define the best way to standardize it (in which doc and
how) and also consider the right time to do. Then we can define the baseline
set of telemetry we believe are adequate, or the bare minimum, to
standardize.  

I am looking forward to continue this discussion with you and the entire the
WG.

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

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Monday, November 14, 2016 11:02 AM
To: dots <[email-masked]>
Subject: Re: [Dots] Questions about draft-doron-dots-telemetry-00

> the basic DOTS protocol, and this document would define that.

This may make sense at some future date; initially, since we're dealing with
devices/software/systems which have radically different paradigms,
capabilities, and 'worldviews', the initial focus of DOTS should be on
signaling and status only, as the ins are universal functions which are
readily understood by most any type of node/service/application which could
participate in DOTS.
[ED] See my view in the body of the mail.

> other DOTS draft should benefit the DOTS Telemetry.

We've already held extensive discussions on this topic; initially, we need a
minimum viable capability to allow signaling and status information to be
passed between DOTS participants.
[ED] I was not part of this discussions, sorry for that. For my mind, we
need to truly define (or re-define...) the needs for DOTS Telemetry for the
actual users (SP, MSSP, Enterprises, carrier and so on) of DOTS, and also
the baseline set of this telemetry. 

It's sub-optimal to duplicate the work done on IPFIX, I2NSF, I2RS, et. 
al. in DOTS.  By leaving mitigation technique specifics and telemetry
specifics to one side, we can concentrate on signaling and status, which is
all that's actually required for successful inter- and intra-domain
DOTS-enabled DDoS mitigation assistance and provisioning.

It's important to get to an initial operating capability with the requisite
baseline capability before we expand the scope of DOTS itself, IMHO.

[ED] Agree, we just need to define and get to the mutual understanding about
the " baseline capability" in term of telemetry. Mainly for the users and
customers of the actual anti-DoS service.

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 17 Nov 2016 06:04:33 +0700

On 16 Nov 2016, at 23:30, Ehud Doron wrote:

> Getting deeper, having comprehensive telemetry about the ongoing 
> attacks will improve the overall mitigation accomplished,

There's already lots of telemetry out there that's used every day to 
detect, classify, and traceback DDoS attacks.

It is orthogonal to signaling for DDoS mitigation assistance and 
providing status updates regarding same.

---

From: Ehud Doron <[email-masked]>
Date: Thu, 17 Nov 2016 15:04:28 +0000

Roland Hi

Let me please clarify, we are not trying to argue that DOTS Telemetry should be used to detect DDoS attacks, this is definitely not the case. 

We are talking about the overall needs to mutually signal telemetry about ongoing attacks that DOTS Client asks Server to mitigate upstream.  

As said, the ultimate objective is to optimize the anti-DoS service provisioned using DOTS signaling, and not to detect the attacks.

Thanks, 

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Thursday, November 17, 2016 1:05 AM
To: dots <[email-masked]>
Subject: Re: [Dots] Questions about draft-doron-dots-telemetry-00

> attacks will improve the overall mitigation accomplished,

There's already lots of telemetry out there that's used every day to detect, classify, and traceback DDoS attacks.

It is orthogonal to signaling for DDoS mitigation assistance and providing status updates regarding same.

---

From: Ehud Doron <[email-masked]>
Date: Thu, 17 Nov 2016 15:04:28 +0000

Susan

I believe the telemetry needs by DOTS is not relates to "flow based" information, the DOTS telemetry is more "higher" and mainly describes the ongoing attacks and their attributes.

Thanks, Ehud 

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Thursday, November 17, 2016 12:58 AM
To: Ehud Doron <[email-masked]>; 'Roland Dobbins' <[email-masked]>; 'dots' <[email-masked]>; [email-masked]
Subject: RE: [Dots] Questions about draft-doron-dots-telemetry-00

Ehud:

Can you indicate what additional features the telemetry that you propose for DOTS needs over the telemetry provided by IPFIX? 

Sue 

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Ehud Doron
Sent: Wednesday, November 16, 2016 11:31 AM
To: Roland Dobbins; dots; [email-masked]
Cc: Ehud Doron
Subject: Re: [Dots] Questions about draft-doron-dots-telemetry-00

Ronald, Flemming and all

I appreciate the standpoints you present in your comments, however I really believe the DOTS WG must also look and consider others views of the
challenges DOTS has with regards to DOTS telemetry.   

No doubt that for the world of DDoS services the "security visibility" is a major concern to both the anti-DoS service providers and consumers. In all cases where the DOTS Client will be implemented in an organizations with a sustainable SOC/NOC teams, the ability to have "customer portal" with visibility into the on-going attacks is a critical part of the service.
Likewise, anti-DoS service providers need visibility into their customers view on the on-going attacks and other sort of views relates to the service and its fulfillments. These are critical parts of the service. 

For my mind, after we will get to a consensus about WG view on the needs for telemetry, we can define the best way to standardize it (in which doc and
how) and also consider the right time to do. Then we can define the baseline set of telemetry we believe are adequate, or the bare minimum, to standardize.  

Best wishes,

---

From: "Dobbins, Roland" <[email-masked]>
Date: Thu, 17 Nov 2016 16:59:20 +0000

On Nov 18, 2016, at 12:04 AM, Ehud Doron <[email-masked]<mailto:[email-masked]>> wrote:

We are talking about the overall needs to mutually signal telemetry about ongoing attacks that DOTS Client asks Server to mitigate upstream.
And what I'm saying is that straying beyond simple signaling & basic mitigation-related information is a bridge too far, for the initial stages, at least.

The paradigms for and capabilities of nodes which will participate in DOTS vary widely, & the parameters posited in draft-doron-dots-telemetry-00 are a) way too subjective, b) beyond the capabilities for most potential DOTS nodes, c) a barrier to entry for DOTS participation, & d) unnecessary for simple, useful DOTS signaling to perform its intended function.

This is something to be taken up in later phases of DOTS (if indeed it should be included in DOTS at all), IMHO.

We need a minimum viable operational capability, to start.   We can get fancy later.

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