Subject: Re: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback.

From: "dongyue (D)" <[email-masked]>
Date: Mon, 27 Nov 2017 06:34:10 +0000

Here are a few questions/comments on the use cases:

* section 3.1.1.1, paragraph 7 -- In this paragraph, the DOTS server will send a confirmation to the enterprise IDMS DOTS client once the mitigation has already been ended. However, to the best of my knowledge, this feature does not exist in the DOTS signal channel draft. Will you suggest this to be added in the signal channel? 

* section 3.1.2.1. , paragraph 5 -- In this paragraph the time to live (TTL) is proposed to be included in the mitigation request as an alternative way to terminate the mitigation. In my opinion, the TTL approach could be used in all the DOTS use case scenarios. Hence I recommend to explain it in the very first use case in 3.1.1.1., otherwise it looks only be used in use cases that MSSP offering the mitigation services.

* section 3.2.2. --  Firstly, this use case placed too much emphasis on how the DDoS attack is detected. Secondly, I think it is better to have a schematic diagram (like the figure in section 3.2.3) to show the architecture and explain the work flow in detail to show how the DOTS protocol works in this scenario.  

* section 3.2.2. -- the last paragraph on page 17, line7,   'rather then' --> 'rather than'
* section 3.2.2. -- the second paragraph on page 18, line 1, 'it notifies automatically or the ISP' --> 'it notifies automatically to the ISP'
* section 3.2.2. -- the fourth paragraph on page 18, line 3, 'traffic patter' --> 'traffic pattern'

Best Regards,
Yue

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Roland Dobbins
发送时间: 2017年11月13日 6:39
收件人: dots <[email-masked]>
主题: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback.

We've re-organized the use-cases so that DOTS implementors won't feel compelled to read through multiple use-cases with similar DOTS communications models, while at the same time retaining those use-cases because they contain significant procedural, operational, and topological variances which are of great significance to network operators and end-customer organizations.

The wording in the DOTS communications model listings and several of the use-cases has been streamlined.  The security considerations were updated to include DDoS attacks.

Finally, we really need WG feedback on the applicability of Section 3.2.2, 'Home Network DDoS Detection Collaboration for ISP network management'.

Thanks much!

<https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/>

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

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

---

From: <[email-masked]>
Date: Mon, 27 Nov 2017 07:19:22 +0000

Dear Yue, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de dongyue (D)
> Envoyé : lundi 27 novembre 2017 07:34
> À : Roland Dobbins; dots
> Objet : Re: [Dots] draft-ietf-dots-use-cases-09 posted - please review and
> provide feedback.
> 
> * section 3.1.1.1, paragraph 7 -- In this paragraph, the DOTS server will
> send a confirmation to the enterprise IDMS DOTS client once the mitigation
> has already been ended. However, to the best of my knowledge, this feature
> does not exist in the DOTS signal channel draft. 

[Med] A dots client can retrieve the status of an ongoing mitigation request by periodically poking the server or by subscribing to unsolicited notifications. Below an example from the signal-channel draft to illustrate this  behavior: 

                       DOTS Client            DOTS Server
                          |                               |
                          |  GET /<mitigation-id number>  |
                          |  Token: 0x4a                  |   Registration
                          |  Observe: 0                   |
                          +------------------------------>|
                          |                               |
                          |  2.05 Content                 |
                          |  Token: 0x4a                  |   Notification of
                          |  Observe: 12                  |   the current state
                          |  status: "mitigation          |
                          |          in progress"         |
                          |<------------------------------+
                          |  2.05 Content                 |
                          |  Token: 0x4a                  |   Notification upon
                          |  Observe: 44                  |    a state change
                          |  status: "mitigation          |
                          |          complete"            |
                          |<------------------------------+
                          |  2.05 Content                 |
                          |  Token: 0x4a                  |   Notification upon
                          |  Observe: 60                  |   a state change
                          |  status: "attack stopped"     |
                          |<------------------------------+
                          |                               |

Will you suggest this to
> be added in the signal channel?
> 
> * section 3.1.2.1. , paragraph 5 -- In this paragraph the time to live
> (TTL) is proposed to be included in the mitigation request as an
> alternative way to terminate the mitigation. In my opinion, the TTL
> approach could be used in all the DOTS use case scenarios. Hence I
> recommend to explain it in the very first use case in 3.1.1.1., otherwise
> it looks only be used in use cases that MSSP offering the mitigation
> services.
> 
> * section 3.2.2. --  Firstly, this use case placed too much emphasis on
> how the DDoS attack is detected. Secondly, I think it is better to have a
> schematic diagram (like the figure in section 3.2.3) to show the
> architecture and explain the work flow in detail to show how the DOTS
> protocol works in this scenario.
> 
> * section 3.2.2. -- the second paragraph on page 18, line 1, 'it notifies
> automatically or the ISP' --> 'it notifies automatically to the ISP'
> We've re-organized the use-cases so that DOTS implementors won't feel
> compelled to read through multiple use-cases with similar DOTS
> communications models, while at the same time retaining those use-cases
> because they contain significant procedural, operational, and topological
> variances which are of great significance to network operators and end-
> customer organizations.
> 
> The wording in the DOTS communications model listings and several of the
> use-cases has been streamlined.  The security considerations were updated
> to include DDoS attacks.
> 
> Finally, we really need WG feedback on the applicability of Section 3.2.2,
> 'Home Network DDoS Detection Collaboration for ISP network management'.
> 
> Thanks much!
>

---

From: "dongyue (D)" <[email-masked]>
Date: Tue, 28 Nov 2017 03:22:49 +0000

Hi Med,

Thanks for your reply!

According to the use case, firstly when a client request to terminate a mitigation, the server has to send a status message (mitigation is active but terminating, listed in the table in page 28 in signal channel draft). Then, the mitigation is exactly terminated by the mitigator, the sever requires to send another status message (not listed in the table) to confirm the termination. I just enquires if the second stage should be explained in the signal channel draft.  
For the subscribing approach, the server will send the notifications upon the status change. This approach is ok.
For another approach, namely the client sending status request periodically, the time to stop sending the status request is another issue that need to be determined by the mitigation termination status message. Because I think it is unnecessary to always send the status request if the mitigation is stopped. 

Best Regards,
Yue

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2017年11月27日 15:19
收件人: dongyue (D) <[email-masked]>; Roland Dobbins <[email-masked]>; dots <[email-masked]>
主题: RE: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback.

Dear Yue, 

Please see inline. 

Cheers,
Med

> Envoyé : lundi 27 novembre 2017 07:34 À : Roland Dobbins; dots Objet : 
> Re: [Dots] draft-ietf-dots-use-cases-09 posted - please review and 
> provide feedback.
> 
> * section 3.1.1.1, paragraph 7 -- In this paragraph, the DOTS server 
> will send a confirmation to the enterprise IDMS DOTS client once the 
> mitigation has already been ended. However, to the best of my 
> knowledge, this feature does not exist in the DOTS signal channel draft.

                       DOTS Client            DOTS Server
                          |                               |

Will you suggest this to
> recommend to explain it in the very first use case in 3.1.1.1., 
> otherwise it looks only be used in use cases that MSSP offering the 
> mitigation services.
> 
> * section 3.2.2. --  Firstly, this use case placed too much emphasis 
> on how the DDoS attack is detected. Secondly, I think it is better to 
> have a schematic diagram (like the figure in section 3.2.3) to show 
> the architecture and explain the work flow in detail to show how the 
> DOTS protocol works in this scenario.
> 
> * section 3.2.2. -- the second paragraph on page 18, line 1, 'it 
> notifies automatically or the ISP' --> 'it notifies automatically to the ISP'
> communications models, while at the same time retaining those 
> use-cases because they contain significant procedural, operational, 
> and topological variances which are of great significance to network 
> operators and end- customer organizations.
> 
> The wording in the DOTS communications model listings and several of 
> the use-cases has been streamlined.  The security considerations were 
> updated to include DDoS attacks.
> 
> Finally, we really need WG feedback on the applicability of Section 
> 3.2.2, 'Home Network DDoS Detection Collaboration for ISP network management'.
> 
> Thanks much!
>

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 28 Nov 2017 10:51:49 -0000

Hi Med,

I agree that Table 2: (-09 version) on dots-signal should have an additional status entry

   +-----------+-------------------------------------------------------+
   |         6 | The mitigation has now terminated  |
   +-----------+-------------------------------------------------------+

Which will only get sent if 'Observe' is active.
 
Hi Yue,

If the client periodically sends a status request with the appropriate mitigation-id, once the mitigation has terminated, the DOTS server will send back a 4.04 message (first paragraph of 4.4.3. Retrieve Information Related to a Mitigation) as the mitigation-id is no longer in use.  However, as you effectively say, the DOTS client should know by that stage that the mitigation is getting closed down and does not necessarily need to send a status query to find out what is happening.

Regards

Jon
-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of dongyue (D)
Sent: 28 November 2017 03:23
To: [email-masked]; Roland Dobbins; dots
Subject: [Dots] 答复: draft-ietf-dots-use-cases-09 posted - please review and provide feedback.

Hi Med,

Thanks for your reply!

Best Regards,
Yue

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2017年11月27日 15:19
收件人: dongyue (D) <[email-masked]>; Roland Dobbins <[email-masked]>; dots <[email-masked]>
主题: RE: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback.

Dear Yue, 

Please see inline. 

Cheers,
Med

                       DOTS Client            DOTS Server
                          |                               |

Will you suggest this to

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 28 Nov 2017 11:00:40 +0000

Done, added additional status entry.

Cheers,
-Tiru

> From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
> Sent: Tuesday, November 28, 2017 4:22 PM
> To: 'dongyue (D)' <[email-masked]>;
> [email-masked]; Roland Dobbins <[email-masked]>;
> [email-masked]
> Subject: Re: [Dots] 答复: draft-ietf-dots-use-cases-09 posted - please review
> and provide feedback.
> 
> Hi Med,
> 
> If the client periodically sends a status request with the appropriate
> mitigation-id, once the mitigation has terminated, the DOTS server will send
> back a 4.04 message (first paragraph of 4.4.3. Retrieve Information Related
> to a Mitigation) as the mitigation-id is no longer in use.  However, as you
> effectively say, the DOTS client should know by that stage that the mitigation
> is getting closed down and does not necessarily need to send a status query
> to find out what is happening.
> 
> Regards
> 
> Jon
> According to the use case, firstly when a client request to terminate a
> mitigation, the server has to send a status message (mitigation is active but
> terminating, listed in the table in page 28 in signal channel draft). Then, the
> mitigation is exactly terminated by the mitigator, the sever requires to send
> another status message (not listed in the table) to confirm the termination. I
> just enquires if the second stage should be explained in the signal channel
> draft.
> For another approach, namely the client sending status request periodically,
> the time to stop sending the status request is another issue that need to be
> determined by the mitigation termination status message. Because I think it
> is unnecessary to always send the status request if the mitigation is stopped.
> 
> Best Regards,
> Yue
> 
> -----邮件原件-----
> 收件人: dongyue (D) <[email-masked]>; Roland Dobbins
> <[email-masked]>; dots <[email-masked]>
> [Med] A dots client can retrieve the status of an ongoing mitigation request
> by periodically poking the server or by subscribing to unsolicited notifications.
> Below an example from the signal-channel draft to illustrate this  behavior:
> 
>                        DOTS Client            DOTS Server
>                           |                               |

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 28 Nov 2017 18:07:16 +0700

On 28 Nov 2017, at 17:42, Konda, Tirumaleswar Reddy wrote:

> However, if we think it's useful the DOTS server can send a mitigation 
> terminated message just before removing the mitigation request.

Very much so, yes.

This is the kind of thing which makes DOTS useful.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 28 Nov 2017 10:42:06 +0000

After the mitigation request is withdrawn by the DOTS client and mitigation is terminated by the mitigator, the mitigation request is removed and the DOTS client cannot get any status messages regarding the mitigation status. However, if we think it's useful the DOTS server can send a mitigation terminated message just before removing the mitigation request.

-Tiru

> From: Dots [mailto:[email-masked]] On Behalf Of dongyue (D)
> Sent: Tuesday, November 28, 2017 8:53 AM
> To: [email-masked]; Roland Dobbins