Subject: [Dots] draft-ietf-dots-use-cases-00 questions/comments

From: "Roman D. Danyliw" <[email-masked]>
Date: Sat, 31 Oct 2015 01:01:15 +0000

Hello Roland, Stephane, Daniel, Robert, Nik and Frank!
 
 [Note: This note is written as an individual contributor.  Chair hat off.]

Thanks again for preparing this initial WG draft of use cases.  In reviewing draft-ietf-dots-use-cases-00, I had the following questions and comments.

** Page 4: Section 3: Terminology: I'm not sure where the canonical terminology list should be.  I noticed a definition for "DDoS", "attack target" and "Countermeasure" were added to those already in draft-ietf-dots-requirements-00.  Also the following are defined "attack telemetry" and "mitigation" differently.  It would be helpful if the drafts coordinated in their language.

** Page 4: Section 4: Use Cases: "It should be noted that DOTS servers ... then initiate DDoS mitigation service by communicating directly or indirectly with a DDoS mitigators".  

To clarify, does "indirect communication" mean through a DOTS relay (i.e. client->server->relay->mitigator)?  I ask because draft-ietf-dots-requirements-00 defines a relay as something between a client and server.

** Page 6: Section 4.1.1: step (d): "The DOTS servers ... determine that they have been to honor requests ..."  There appears to be a word or phrase missing to the effect of the DOTS server determines whether it can or should honor the request.

** Page 8: Section 4.1.2: Between steps (a) and (b).  How does the network infrastructure element know to use its DOTS client functionality?  The use case in Section 4.1.1 explicitly had a detection phase in step (b).  Doesn't this use case need that too?

** Page 9: Section 4.1.3: same feedback as above.

** I liked the way the explicit steps were written up.  All of the introductions for 4.1.* were helpful.  By the time I got to 4.1.3, I noticed that the text for each of the steps was nearly identical to the previous section other than to replacement of the type of DOTS client (i.e., CPE vs. network infrastructure element).  For readability, I think it would be clearer to see the differences in the use cases if the common steps just referenced previous text.  For example, Section 4.1.1a = 4.1.2a; 4.1.1c = 4.1.2b, etc.

** The implicit protocol I got out of Section 4.1 was:
* Mitigation Service Initiation (step b per Section 4.1.1)
* Service Status Message (step d per Section 4.1.1)
* Efficacy updates (step f per Section 4.1.1)
* Mitigation Status Update (step h and k per Section 4.1.1; step f of Section 4.1.7)
* Mitigation Service Termination Request (step i per Section 4.1.1)
* Mitigation Termination Status Acknowledgement (per l per Section 4.1.1)

Regards,
Roman

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 31 Oct 2015 15:37:13 +0900

On 31 Oct 2015, at 10:01, Roman D. Danyliw wrote:

> ** Page 4: Section 3: Terminology: I'm not sure where the canonical 
> terminology list should be.  I noticed a definition for "DDoS", 
> "attack target" and "Countermeasure" were added to those already in 
> draft-ietf-dots-requirements-00.  Also the following are defined 
> "attack telemetry" and "mitigation" differently.  It would be helpful 
> if the drafts coordinated in their language.

Yes, we need to reconcile them.  The differing definitions were placed 
in draft-ietf-dots-use-cases-00 to point out the need for 
reconciliation.
>
> ** Page 4: Section 4: Use Cases: "It should be noted that DOTS servers 
> ... then initiate DDoS mitigation service by communicating directly or 
> indirectly with a DDoS mitigators".
>
> To clarify, does "indirect communication" mean through a DOTS relay 
> (i.e. client->server->relay->mitigator)?  I ask because 
> draft-ietf-dots-requirements-00 defines a relay as something between a 
> client and server.

This communication is out of the scope for DOTS - generally a 
proprietary mechanism, paradigms vary greatly.  This is one of the 
primary reasons we need DOTS.
>
> ** Page 6: Section 4.1.1: step (d): "The DOTS servers ... determine 
> that they have been to honor requests ..."  There appears to be a word 
> or phrase missing to the effect of the DOTS server determines whether 
> it can or should honor the request.

Yes, type - should be 'configured'.  Will be corrected in -01.
>
> ** Page 8: Section 4.1.2: Between steps (a) and (b).  How does the 
> network infrastructure element know to use its DOTS client 
> functionality?  The use case in Section 4.1.1 explicitly had a 
> detection phase in step (b).  Doesn't this use case need that too?

It does; if we need to spell it out again for the sake of clarity, we 
can do that in -01, no problem.
> ** Page 9: Section 4.1.3: same feedback as above.

Same as above, if we need to spell it out again, we can in -01.

>
> ** I liked the way the explicit steps were written up.  All of the 
> introductions for 4.1.* were helpful.  By the time I got to 4.1.3, I 
> noticed that the text for each of the steps was nearly identical to 
> the previous section other than to replacement of the type of DOTS 
> client (i.e., CPE vs. network infrastructure element).  For 
> readability, I think it would be clearer to see the differences in the 
> use cases if the common steps just referenced previous text.  For 
> example, Section 4.1.1a = 4.1.2a; 4.1.1c = 4.1.2b, etc.

Concur.  This repetitive text was a deliberate editorial decision for 
-00 so as to ensure that we're all clear that there's a high degree of 
commonality in the ebb and flow of DOTS communications under 
circumstances which appear to be very different from a topological and 
functional perspective, but in reality are pretty close at at abstract 
level.

We'll remove all the repetitive stuff and replace it with callbacks and 
diffs in -01.
> * Mitigation Termination Status Acknowledgement (per l per Section 

Yes, that's pretty much it, in a nutshell.  Status messages, efficacy 
updates, termination requests, and acknowledgement thereof are all 
desirable from the standpoint of each participating element and 
organization understanding the current state of play, but are not 
required in order for mitigation to be initiated, to be maintained, 
and/or to be terminated.  They're useful, but optional in terms of 
actually making things happen.

The language will be wordsmithed in -01, as well.  It was imperative to 
get something which was essentially 'feature-complete' out the door for 
discussion on Tuesday, but we'll refine and streamline the language as 
we take on board feedback from WG participants and incorporate it into 
-01.  So, -01 will be a substantial stylistic rewrite, as well as 
incorporating WG feedback.

Good feedback, thanks much!

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