Subject: [Dots] Feedback on draft-ietf-dots-use-cases-02

From: "Roman D. Danyliw" <[email-masked]>
Date: Fri, 11 Nov 2016 21:27:34 +0000

Hello Roland, Daniel, Bob, Nik and Frank!

(Chair hat off)

Thanks for producing this -02 draft.  The following is feedback from reviewing this draft:

==[ Section 3 ]==

** It's stated that "[a]ll scenarios presents [sic] a coordination between the DDoS target, the DDoS attack telemetry and the mitigator".  These three terms of "target", "attack telemetry" and "mitigator" are not the same.  "target" and "mitigator" are elements of the architecture.  "Attack telemetry" is data that is exchanged.  I'm not sure how these dissimilar things can be coordinated together.  Also per the definitions in the requirements document, "DDoS target" should be "DDoS attack target".

==[ Section 3.1 ]==

** The use case name, "CPE Intra-domain ...", is misleading.  Yes, the equipment is at the customer location, but the significant property about these devices is not their location but their inability to send telemetry (or anything beyond "help is needed").  Their characterization as "very basic equipment" is vague and unclear.  I'd recommend using a different name for this use case and alternative language to characterize these devices.

** The acronym "CPE" is not spelled out the first time it is used.

** A reference to "the upstream equipment belong [sic] to the same domain" is made.  What makes a domain is not made clear.  Given that a distinction is being made between intra and inter domain use cases, it would be valuable to expand on this key idea.

** The statement "that a specific contract is established between the CPE ..." is made.  What kind of contract?  Legal?  It should be explicitly stated.

** The statement "[t]he CPE and concerned traffic is likely to be identified by the source of the alert" is made.  What is "concerned traffic"?  Also, what is meant by the CPE being "identified by the source of the alert"?

** The statement "[t]he DDoS mitigation service may be activated only for the traffic associated to the CPE sending the alert or instead to the traffic associated to all CPEs" is made.  What is meant by "all CPEs" isn't clear.

==[ Section 3.2 ]==

** As noted for Section 3.1, this use case name, "Service/System" isn't clear.  The distinguishing property of the devices being highlighted in this use case seems to be that they are capable of generating telemetry.  Their characterization as "specialized equipment" isn't clear.

** The second paragraph states "[s]imilarly when an attack is detected by the target service."  In this context, it isn't clear what a target service is.

** In the next sentence, "[t]he destination of the alert is likely to receive alert [sic] from multiple different services".  In this context, which services and destinations are being referenced?

** In the next sentence, "Such information is likely to be trusted and considered by the mitigator to apply the appropriate security appliance".  In this context, what is a security appliance?

** In the third paragraph, there are multiple references to an "analysis phase".  What lifecycle are those phases references?  What happens before and after "analysis"?

==[ Section 3.3 ]==

** The way this use cases is written is inconsistent with Section 3.1 and 3.2.  In those use cases, the scenario was framed in terms of the capabilities of the DOTS client.  This scenario is framed around what is added to the alert sent to the DOTS server.  What does this suggest about the capabilities of the DOTS client?

==[ Section 3.4 ]==

** This section describes a use case that arises when there are inter-domain issues.  However, there is no treatment of why deployments are inter vs. intra domain makes any difference.

==[ Section 4.0 ]==

** The sentence "A DOTS Client or DOTS Server can be hosted on different nodes which are associated with different functionalities and thus leading to different expectations from DOTS".  What is meant by "different functionalities" and "expectations of DOTS" isn't clear to me.

==[ Section 4.1 ]==

** The first paragraph restates the role of DOTS client.  A similar, but more concise and descriptive description is already found in Section 2.2.1 of the architecture draft.  I'd recommend only one place for this text.

** DOTS client (a).(i) reads "target attack" but likely should be "attack target"

** The purpose of this section isn't clear to me.  Paragraph 3 ("When the DOTS Client is hosted ...") appears to restate and expound about the use case in Section 3.1.  The same is true for Paragraph 4 ("When the DOTS Client is hosted on a monitoring system ...") relative to Section 3.2; and Paragraph 5 - 6 to Section 3.3.

==[ Section 4.2 ]==

** The first paragraph ("DOTS Servers terminate ...") doesn't appear to be consistent with Figure 1 in the architecture draft.

** In the second paragraph, it is stated that "Some DOTS Clients do not expect any interaction from the DOTS Server".  This seems to conflict with the examples in the Appendix.

==[ Section 4.3 ]==

I don't disagree with the content, but need help understanding how this section clarifies the use cases.

Regards,
Roman

---

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

Adding to this thread, I generally agree with Roman's comments.

Taking a step back, can the authors explain a bit more about the new 
structure of the document ?

- In particular, Section 3 calls out a number of different types of 
scenarios, however it's not obvious to me how all of those map to the 
actual use cases described in Appendix A (which seem like a carry-over 
from previous versions and need some "relay" clean-up). It would also be 
helpful with a diagram for each of these that clearly show how they map 
back to the overall DOTS architecture.

- Section 4 seems to stray into aspects of architecture, requirements 
and protocol design, and I don't think it should. It may work better to 
merge Section 3 and 4 (using the Section 3 structure) and add some 
ladder diagrams and relevant descriptions for each high-level scenario. 
In that case, you would probably still need something like the message 
taxonomy (Section 4.3) upfront to explain what goes in these 
ladder/message diagrams.

Also, should their not be any use case scenarious illustrating the data 
channel ?

Thanks

-- Flemming

On 11/11/16 4:27 PM, Roman D. Danyliw wrote:
> ** It’s stated that “[a]ll scenarios presents [sic] a coordination 
> between the DDoS target, the DDoS attack telemetry and the 
> mitigator”.  These three terms of “target”, “attack telemetry” and 
> “mitigator” are not the same.  “target” and “mitigator” are elements 
> of the architecture.  “Attack telemetry” is data that is exchanged. 
> I’m not sure how these dissimilar things can be coordinated together.  
> Also per the definitions in the requirements document, “DDoS target” 
> should be “DDoS attack target”.
>
> ==[ Section 3.1 ]==
>
> ** The use case name, “CPE Intra-domain …”, is misleading.  Yes, the 
> equipment is at the customer location, but the significant property 
> about these devices is not their location but their inability to send 
> telemetry (or anything beyond “help is needed”).  Their 
> characterization as “very basic equipment” is vague and unclear.  I’d 
> recommend using a different name for this use case and alternative 
> language to characterize these devices.
>
> ** The acronym “CPE” is not spelled out the first time it is used.
>
> ** A reference to “the upstream equipment belong [sic] to the same 
> domain” is made.  What makes a domain is not made clear.  Given that a 
> distinction is being made between intra and inter domain use cases, it 
> would be valuable to expand on this key idea.
>
> ** The statement “that a specific contract is established between the 
> CPE …” is made.  What kind of contract?  Legal?  It should be 
> explicitly stated.
>
> ** The statement “[t]he CPE and concerned traffic is likely to be 
> identified by the source of the alert” is made.  What is “concerned 
> traffic”?  Also, what is meant by the CPE being “identified by the 
> source of the alert”?
>
> ** The statement “[t]he DDoS mitigation service may be activated only 
> for the traffic associated to the CPE sending the alert or instead to 
> the traffic associated to all CPEs” is made.  What is meant by “all 
> CPEs” isn’t clear.
>
> ==[ Section 3.2 ]==
>
> ** As noted for Section 3.1, this use case name, “Service/System” 
> isn’t clear.  The distinguishing property of the devices being 
> highlighted in this use case seems to be that they are capable of 
> generating telemetry. Their characterization as “specialized 
> equipment” isn’t clear.
>
> ** The second paragraph states “[s]imilarly when an attack is detected 
> by the target service.”  In this context, it isn’t clear what a target 
> service is.
>
> ** In the next sentence, “[t]he destination of the alert is likely to 
> receive alert [sic] from multiple different services”.  In this 
> context, which services and destinations are being referenced?
>
> ** In the next sentence, “Such information is likely to be trusted and 
> considered by the mitigator to apply the appropriate security 
> appliance”.  In this context, what is a security appliance?
>
> ** In the third paragraph, there are multiple references to an 
> “analysis phase”.  What lifecycle are those phases references?  What 
> happens before and after “analysis”?
>
> ==[ Section 3.3 ]==
>
> ** The way this use cases is written is inconsistent with Section 3.1 
> and 3.2.  In those use cases, the scenario was framed in terms of the 
> capabilities of the DOTS client.  This scenario is framed around what 
> is added to the alert sent to the DOTS server.  What does this suggest 
> about the capabilities of the DOTS client?
>
> ==[ Section 3.4 ]==
>
> ** This section describes a use case that arises when there are 
> inter-domain issues.  However, there is no treatment of why 
> deployments are inter vs. intra domain makes any difference.
>
> ==[ Section 4.0 ]==
>
> ** The sentence “A DOTS Client or DOTS Server can be hosted on 
> different nodes which are associated with different functionalities 
> and thus leading to different expectations from DOTS”.  What is meant 
> by “different functionalities” and “expectations of DOTS” isn’t clear 
> to me.
>
> ==[ Section 4.1 ]==
>
> ** The first paragraph restates the role of DOTS client.  A similar, 
> but more concise and descriptive description is already found in 
> Section 2.2.1 of the architecture draft.  I’d recommend only one place 
> for this text.
>
> ** DOTS client (a).(i) reads “target attack” but likely should be 
> “attack target”
>
> ** The purpose of this section isn’t clear to me.  Paragraph 3 (“When 
> the DOTS Client is hosted …”) appears to restate and expound about the 
> use case in Section 3.1.  The same is true for Paragraph 4 (“When the 
> DOTS Client is hosted on a monitoring system …”) relative to Section 
> 3.2; and Paragraph 5 – 6 to Section 3.3.
>
> ==[ Section 4.2 ]==
>
> ** The first paragraph (“DOTS Servers terminate …”) doesn’t appear to 
> be consistent with Figure 1 in the architecture draft.
>
> ** In the second paragraph, it is stated that “Some DOTS Clients do 
> not expect any interaction from the DOTS Server”.  This seems to 
> conflict with the examples in the Appendix.
>
> ==[ Section 4.3 ]==
>
> I don’t disagree with the content, but need help understanding how 
> this section clarifies the use cases.
>
> Regards,
>
> Roman
>
>
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots