Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

From: Ehud Doron <[email-masked]>
Date: Wed, 8 Feb 2017 13:51:11 +0000

Tiru and authors Hi

Attached please find my comments and feedbacks to draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy-dots-signal-channel-07

1.       General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

2.       General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API

3.       Page 3 second paragraph : DOTS should not be limited to "enterprise network" only
.

4.       Page 4 chapter 4: The overall context of the "happy eyeballs" and its relations (or coexistence) to CoAP is not clear.

5.       Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft

6.       Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

7.       Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested

8.       Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only "stand alone" attributes , port and protocol are companion attributes. See also figure 9 .

9.       Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ?   "policy ID" ? I think the best is have another attribute to define the priority of mitigation requests

10.   Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

11.   Page 15 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

12.   Page 21 last paragraph: This is very strong point.

13.   Page 25 : Regarding attack status, same point about telemetry.

14.   Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 .

15.   Page 27:  The necessity of policy_id here is not clear enough, are the "Signal Channel Session Configuration" define only "single" DOTS session or the entire communication between Client and Server for several DOTS request for mitigation?

16.   Page 27: Not sure about the reason for "at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present." Also consider to change to "presented".

17.   Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the  redirection occurred ?

Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-dots-data-channel-03

1.       General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions

2.       Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ?

3.       Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ?

4.       Page 9 figure 3 : Need to find the way to bind the target-ips with target-port-ranges and target-protocols, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.

5.       Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing.

6.       Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ?

7.       Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how).

8.       Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting.

9.       Page 15 : The action field cannot be optional attribute.

10.   Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue...

Thanks,

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 14 Feb 2017 14:53:20 +0000

Hi Ehud,

Thanks for the detailed review, Please see inline (I will respond to data channel comments in a separate mail)

From: Dots [mailto:[email-masked]] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <[email-masked]>
Cc: David Aviv <[email-masked]>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

Tiru and authors Hi

[TR] Yes, will update draft.

[TR] Done.

[TR] Agreed, fixed.

[TR] Happy eyeballs mechanism is used to reduce connection delay to setup (D)TLS session with the DOTS server. Happy eyeballs mechanism is not related to CoAP.

[TR] YANG is a data modeling language used to model configuration and state data;  The configuration and state data defined using YANG can be represented in JSON or CBOR or XML. Since CBOR is binary, JSON is used in the draft but only for illustrative purpose.

[TR] Yes, I plan to update the draft with telemetry info based on outcome of draft-doron-dots-telemetry-00.

[TR] Changed to minutes

[TR] Good point, fixed.

9.       Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ?   "policy ID" ? I think the best is have another attribute to define the priority of mitigation requests
[TR] policy-id is specific to a DOTS client, DOTS server need not compare the policy-id of one customer with the policy-id of another customer. Policy-ids are only compared b/w multiple mitigation requests from the same DOTS client to determine the priority. DOTS signaling channel runs over UDP, and packets may arrive out-of-order; this was also one of the reasons to introduce policy-id.

[TR] Same response as 6; for now will update the draft to convey the following telemetry info from the DOTS server : total dropped byte count, average dropped bytes per second, total dropped packet count and average dropped packets per second. The list is not complete, what kind of telemetry info is required for L7 attacks (e.g. attack at TLS, partial HTTP request, garbage request etc.) and how do we deal with new type of DDOS attacks (Do we keep updating the spec as and when a new DDOS attack is discovered) ?

[TR] Yes, it's possible; create different aliases for IP1 TCP port 80 and IP 2 UDP port 53 using DOTS data channel and convey the aliases in DOTS signal channel.

[TR] Thanks.

[TR] Same response as above.

[TR] 5.3 gives background how GET, POST, DELETE and PUT will be used, hence did not see a need to add a high level description in Section 5.4.

[TR]  It's for a single DOTS session between DOTS client and server, a single DOTS session can be used for several DOTS requests and responses.

[TR] what is the point in conveying a POST request without any configuration parameters/attributes ?

[TR] Both, updated draft.

-Tiru

Thanks,

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 14 Feb 2017 14:58:34 +0000

Hi Ehud,

Please see inline for responses to comments on draft-reddy-dots-data-channel-03

Tiru and authors Hi

[TR] Agreed, updated draft.

[TR] No need to configure DOTS signal channel session, fixed second paragraph.

[TR] Identifiers created for resources in DOTS data channel are used in DOTS signal channel to request DDOS mitigation. It's the responsibility of DOTS data channel to create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS signal channel not creating identifiers is the message size may exceed Path MTU.

[TR] Yes, it is possible; create different aliases for IP1 TCP port 80 and IP2 UDP port 53.

[TR] Thanks, fixed chapter 3.3.

[TR]  Yes, "permit" action is used for white-list installation; it's defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09

[TR] Done, updated draft.

[TR]  We are not doing anything new to ACL, ACL an ordered list of Access List Entries (ACE) based on priority.

[TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 if the action field not specified then "deny" is the default action.

[TR] Chapter 3.3.3 only discusses telemetry details of number of matches for the installed filtering rules.

-Tiru

Thanks,

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 15 Feb 2017 14:57:05 +0900

Hi Tiru,

I really appreciate your time and effort.
Please see my comments on the drafts.

# draft-reddy-dots-signal-channel-07

1. [General] I believe that DOTS request should not be another tool of blocking other one's traffic. Is there any validation mechanism of requested target-ips, target-ports and target-protocols? Even If it is out side of the DOTS specification, how about returning 4.xx codes when the requested target-* is not a property of the organization.

2. [page14] Does one DOTS client and DOTS server peer have only one signal channel and one data channel? (I'm thinking about a namespace of the "alias-name")
If their are multiple data channels, "DOTS signal" in Fig.5 should specify according data channel when it refers to "alias-names" of the identifiers.

3. [Page21] How about adding status of "mitigation delete is in progress" like status:1.
     Here is a life cycle of a mitigation in our environment. Activating and deleting of mitigation could take several seconds (or minutes).
     POST.
      - activating(status=1)
     STATUS AFTER ACTIVATED
      - attack mitigated (status=2)
      - attack stopped (status=3)
      - attack exceeded capability(status=4)
     DELETE
      - deleting(status=5?)
      - deleted(RETURN 4.04)

4. [Page25] 5.4 b) I couldn't find "retransmission timeout value" attribute in the later figures. Is that equivalent to "ack-timeout"?

5. [Page27] "policy-id" in "signal-config" is different from "policy-id" in "mitigation-scole". How about using "session-id" in this case?

# draft-reddy-dots-data-channel-03

1. [General] Data channel doesn't have heartbeat mechanism. I guess the reason is that there is heartbeat mechanism in the signal channel so it is enough, is that right?

2. [related to Ehud's question 8] I-D.ietf-netmod-acl-model says "ACL is an ordered list of Access List Entries (ACE)" but I couldn't find a text about how they are ordered. Should we have a operation of changing the order of ACEs installed in a DOTS server?

thank you,
Kaname

On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wrote:
> *From:* Dots [mailto:[email-masked]] *On Behalf Of *Ehud Doron
> *Sent:* Wednesday, February 8, 2017 7:21 PM
> *To:* 'dots' <[email-masked]>
> *Cc:* David Aviv <[email-masked]>
> *Subject:* [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .
>
> Tiru and authors Hi
>
> *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel  draft-reddy-dots-signal-channel-07_*
>
> 1.General comment: For all signals in the draft, need to add means to allow vendor specific attributes as part of all signals transactions
>
> 2.General comment: Just for clarity, need to explicitly mention on each figure when it is an example or the actual API
>
> 3.Page 3 second paragraph : DOTS should not be limited to “enterprise network” only
>
> .
>
> 4.Page 4 chapter 4: The overall context of the “happy eyeballs” and its relations (or coexistence) to CoAP is not clear.
>
> 5.Page 7 chapter 5.2.1: The need for YANG model cannot be understood from text. What are the needs for YANG models? What is the relation to the JSONs in the other chapters in the draft
>
> 6.Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.
>
> 7.Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested
>
> 8.Page 15 last paragraph: Not sure that target port or target protocol can define a protected entity. IP, FQDN, URI are the only “stand alone” attributes , port and protocol are companion attributes. See also figure 9 .
>
> 9.Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ?   “policy ID” ? I think the best is have another attribute to define the priority of mitigation requests
>
> 10.Page 21 table: The return status are right but not enough. Need to add more telemetry info about the actual mitigation going on (how much traffic was mitigated) and the attack that are mitigated, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.
>
> 11.Page 15 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.
>
> 12.Page 21 last paragraph: This is very strong point.
>
> 13.Page 25 : Regarding attack status, same point about telemetry.
>
> 14.Page 25 chapter 5.4: I believe it can valuable to add a short high level description about the proposed API flow, same as you did for 5.3 .
>
> 15.Page 27:  The necessity of policy_id here is not clear enough, are the “Signal Channel Session Configuration” define only “single” DOTS session or the entire communication between Client and Server for several DOTS request for mitigation?
>
> 16.Page 27: Not sure about the reason for “at least one of the attributes heartbeat-interval or max-retransmit or ack-timeout or ack-random-factor MUST be present.” Also consider to change to “presented”.
>
> 17.Page 30 chapter 5.5: Need to specify the overall scenario, in reaction to which signal (or API transaction POST of Mitigation Request , unidirectional notification from Server as describes in page 23 in page 21 ?) the  redirection occurred ?
>
> *_Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel  draft-reddy-dots-data-channel-03_*
>
> 1.General comment: For all signal in the draft, need to add means to allow vendor specific attributes as part of all signals transactions
>
> 2.Page 5 second paragraph: Why it is required to configure the DOTS signal channel session ?
>
> 3.Page 8 chapter 3.2.1 : Any reason for not including these identifiers in the DOTS signal channel draft ?
>
> [TR] Identifiers created for resources in DOTS data channel are used in DOTS signal channel to request DDOS mitigation. It’s the responsibility of DOTS data channel to create aliases for resources (see https://tools.ietf.org/html/draft-ietf-dots-requirements-03#section-2.3). The main reason for DOTS signal channel not creating identifiers is the message size may exceed Path MTU.
>
> 4.Page 9 figure 3 : Need to find the way to bind the target-ip*s* with target-port-range*s* and target-protocol*s*, meaning that the server needs to understand the exact scope of attack, e.g. IP1 TCP port 80, IP2 UDP port 53 and so on so forth.
>
> 5.Page 13 chapter 3.3 : Need to emphasize that filtering rules are relevant for both client server direct communication and through a DOTS gateway. The chapter is a bit confusing.
>
> 6.Page 14 chapter 3.3 : I am missing the white-list installation, is it by using the permit action ?
>
> [TR]  Yes, “permit” action is used for white-list installation; it’s defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09
>
> 7.Page 15 figure 8: For DDoS it is highly valuable to have rate limit as an action. Consider adding such action (if already defined need to explain where and how).
>
> 8.Page 15 figure 8: Need to consider adding priority to an ACL to support cases when several filtering rules are conflicting.
>
> 9.Page 15 : The action field cannot be optional attribute.
>
> [TR] As per https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09if the action field not specified then “deny” is the default action.
>
> 10.Page 16 chapter 3.3.3: Need to add more telemetry info about the actual traffic that was blocked (bps, pps and so on), but as I believe this might be another issue…
>
> **
> *Ehud Doron *| Senior Architect, *Radware* CTO office | *M:*+972-54-7575503 | *T:* +972-72-3917120
>
>
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Wed, 15 Feb 2017 16:17:50 +0000

On Feb 14, 2017, at 9:53 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ehud,

 … snip...

I understand need for and support the effort to ensure telemetry between DOTS agents, but I’m skeptical about the suggestion that the right place for it is in the signal channel. The signal channel requirements are restrictive by design (sub-MTU message size, expectation of packet loss, etc.), suggesting incompatibility with the proposed telemetry attributes in draft-doron-dots-telemetry-00. Among other things, that draft proposes CEF for attack details and the inclusion of a list of authenticated sources. Tiru’s signal channel draft suggests assuming an MTU of no more than 1280 bytes if the PMTU is not known, and concludes that a maximum datagram size of 576 bytes with a DOTS payload size of 500 bytes is best to ensure the signal channel will not be fragmented.

All of that is to say I disagree with the suggestion that the signal channel should be the primary vehicle for telemetry. Feedback, yes; unscoped telemetry, no. How do we determine if there’s enough telemetry? How much telemetry does vendor A require to function as a DOTS server or client? How much telemetry loss can either agent (and vendor implementation) withstand?

In contrast, the data channel seems like the ideal place for the sort of telemetry described in draft-doron-dots-telemetry-00. There are no restrictive size or packet loss handling requirements, and RESTCONF supports event streams that would seem to fit the need quite well.

andrew

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 16 Feb 2017 04:18:47 +0000

Hi Kaname,

Please see inline [TR] for responses

From: kaname nishizuka [mailto:[email-masked]]
Sent: Wednesday, February 15, 2017 11:27 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; Ehud Doron <[email-masked]>; 'dots' <[email-masked]>
Cc: David Aviv <[email-masked]>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

Hi Tiru,

1. [General] I believe that DOTS request should not be another tool of blocking other one's traffic. Is there any validation mechanism of requested target-ips, target-ports and target-protocols? Even If it is out side of the DOTS specification, how about returning 4.xx codes when the requested target-* is not a property of the organization.
[TR] The validation scope is outside the scope of this draft, 4.xx error code is already used in the draft to identity invalid requests.
2. [page14] Does one DOTS client and DOTS server peer have only one signal channel and one data channel? (I'm thinking about a namespace of the "alias-name")
[TR] No, DOTS peers can have more than one signal and data channel but the recommendation is to use only signal and data channel to reduce connection setup delay.
If their are multiple data channels, "DOTS signal" in Fig.5 should specify according data channel when it refers to "alias-names" of the identifiers.
[TR] I did not get the comment.
3. [Page21] How about adding status of "mitigation delete is in progress" like status:1.
    Here is a life cycle of a mitigation in our environment. Activating and deleting of mitigation could take several seconds (or minutes).
    POST.
     - activating(status=1)
    STATUS AFTER ACTIVATED
     - attack mitigated (status=2)
     - attack stopped (status=3)
     - attack exceeded capability(status=4)
    DELETE
     - deleting(status=5?)
     - deleted(RETURN 4.04)

[TR] Delete is a confirmable message, DOTS server will send an ACK to acknowledge the receipt of the message to avoid retransmissions from the DOTS client. After the mitigation request is successfully deleted, DOTS server returns 2.02 (Deleted) response code, thus conveying the transient status in this case is not necessary.
4. [Page25] 5.4 b) I couldn't find "retransmission timeout value" attribute in the later figures. Is that equivalent to "ack-timeout"?
[TR] The initial retransmission timeout value is based on the ack-timeout (see https://tools.ietf.org/html/rfc7252#section-4.2).

5. [Page27] "policy-id" in "signal-config" is different from "policy-id" in "mitigation-scole". How about using "session-id" in this case?
[TR] Policy-id is a unique identifier identifying the signal channel session configuration request.
# draft-reddy-dots-data-channel-03

1. [General] Data channel doesn't have heartbeat mechanism. I guess the reason is that there is heartbeat mechanism in the signal channel so it is enough, is that right?
[TR] No, the heartbeat mechanism in signal channel cannot be used for data channel. DOTS signal channel is using the "CoAP ping mechanism". For data channel, TLS heartbeat can be used. I have updated draft.
2. [related to Ehud's question 8] I-D.ietf-netmod-acl-model says "ACL is an ordered list of Access List Entries (ACE)" but I couldn't find a text about how they are ordered. Should we have a operation of changing the order of ACEs installed in a DOTS server?
[TR] PUT can be used by the DOTS client to re-order/update/modify the list of ACE conveyed to the DOTS server. Updated draft to discuss about PUT.
-Tiru

thank you,
Kaname

From: Dots [mailto:[email-masked]] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <[email-masked]><mailto:[email-masked]>
Cc: David Aviv <[email-masked]><mailto:[email-masked]>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

Tiru and authors Hi

-Tiru

Thanks,

Dots mailing list

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

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 16 Feb 2017 16:52:03 +0900

Hi Tiru,

please see inline.

On 2017/02/16 13:18, Tirumaleswar Reddy (tireddy) wrote:
> *From:*kaname nishizuka [mailto:[email-masked]]
> *Sent:* Wednesday, February 15, 2017 11:27 AM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked]>; Ehud Doron <[email-masked]>; 'dots' <[email-masked]>
> *Subject:* Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .
>
> Hi Tiru,
>
[kaname]OK, understood.

> [TR] No, DOTS peers can have more than one signal and data channel but the recommendation is to use only signal and data channel to reduce connection setup delay.
[kaname] If there are more than one signal and data channel, how can they coupled?
One DOTS server will accommodate more than one DOTS client, so is there any way to know which data channel is belong to which signal channel? Source IP?
I recommend to use only one signal and data channel per one DOTS peer, too.

> [TR] I did not get the comment.
[kaname] Different DOTS clients will be belonging to different customers(organizations).
So I think there is a chance of requesting the same "alias-names" from different customers.
Then, will the DOTS server reject conflicted "alias-names" between different customers? or keep them with prefixes like customerA:<same-alias-name> and customerB:<same-alias-name> internally? Also, customerA should not use an alias-name of customerB. How can the DOTS server check that.

> [TR] Delete is a confirmable message, DOTS server will send an ACK to acknowledge the receipt of the message to avoid retransmissions from the DOTS client. After the mitigation request is successfu…
[kaname] As I noted, deleting of mitigation could take several seconds (or minutes) in real-life.
If the DOTS client retrieve the status while that time, getting "deleting status", not "2.02 status", will help operators.

> [TR] The initial retransmission timeout value is based on the ack-timeout (see https://tools.ietf.org/html/rfc7252#section-4.2).
[kaname] Thank you, I found the reference.
> [TR] Policy-id is a unique identifier identifying the signal channel session configuration request.
[kaname] "policy-id" in Fig.9 and Fig.15 are totally different. I've got confused when reading the draft because they have the same name.

> [TR] No, the heartbeat mechanism in signal channel cannot be used for data channel. DOTS signal channel is using the “CoAP ping mechanism”. For data channel, TLS heartbeat can be used. I have updated draft.
>
[kaname] OK. I'll see updated draft.

> [TR] PUT can be used by the DOTS client to re-order/update/modify the list of ACE conveyed to the DOTS server. Updated draft to discuss about PUT.
[kaname] OK. I'll see updated draft.

thank you,
kaname
>     *To:* 'dots' <[email-masked]> <mailto:[email-masked]>
>     *Cc:* David Aviv <[email-masked]> <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 16 Feb 2017 12:09:13 +0000

Hi Kaname,

Please see inline [TR2]

Sent: Thursday, February 16, 2017 1:22 PM

Hi Tiru,

please see inline.

To: Tirumaleswar Reddy (tireddy) <[email-masked]><mailto:[email-masked]>; Ehud Doron <[email-masked]><mailto:[email-masked]>; 'dots' <[email-masked]><mailto:[email-masked]>

Hi Tiru,

[TR2] DOTS client authenticate to the DOTS server (see https://tools.ietf.org/html/draft-reddy-dots-signal-channel-07#page-35), the DOTS server knows the DOTS client identity to couple the signal and data channel sessions.

Then, will the DOTS server reject conflicted "alias-names" between different customers?

[TR] No.

or keep them with prefixes like customerA:<same-alias-name> and customerB:<same-alias-name> internally? Also, customerA should not use an alias-name of customerB. How can the DOTS server check that.

[TR2] Same response as above. Aliases do not have global scope, they are specific to a DOTS client (DOTS server knows the DOTS client identity).

[TR2] Yes, but the DOTS server immediately sends a ACK (acknowledging the receipt of the DELETE message), thus the DOTS client knows the server has received the Delete request and is processing the request. After deleting the mitigation (may take several seconds), server sends 2.02 (Delete) response code. I don't see a problem.

-Tiru

thank you,
kaname

-Tiru

thank you,
Kaname

Tiru and authors Hi

-Tiru

Thanks,

Dots mailing list

Dots mailing list

---

From: Ehud Doron <[email-masked]>
Date: Thu, 16 Feb 2017 13:12:50 +0000

Tiru Hi

Thanks for your response and clarifications.
Please see inline (Followed after [Ehud] )

Thanks,

From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Tuesday, February 14, 2017 4:53 PM
To: Ehud Doron <[email-masked]>; 'dots' <[email-masked]>
Cc: David Aviv <[email-masked]>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

Hi Ehud,

From: Dots [mailto:[email-masked]] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <[email-masked]<mailto:[email-masked]>>
Cc: David Aviv <[email-masked]<mailto:[email-masked]>>
Subject: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

Tiru and authors Hi

[TR] Done.

[TR] Agreed, fixed.

[TR] Changed to minutes

[TR] Good point, fixed.

9.       Page 15 last paragraph: The mitigation request is not clear, to which identifier the text is related ?   "policy ID" ? I think the best is have another attribute to define the priority of mitigation requests
[TR] policy-id is specific to a DOTS client, DOTS server need not compare the policy-id of one customer with the policy-id of another customer. Policy-ids are only compared b/w multiple mitigation requests from the same DOTS client to determine the priority. DOTS signaling channel runs over UDP, and packets may arrive out-of-order; this was also one of the reasons to introduce policy-id.
[Ehud] Consider to update the text in page 15 with your explanations here, mainly regarding the "per customer uniqueness of DOTS".

[TR] Same response as 6; for now will update the draft to convey the following telemetry info from the DOTS server : total dropped byte count, average dropped bytes per second, total dropped packet count and average dropped packets per second. The list is not complete, what kind of telemetry info is required for L7 attacks (e.g. attack at TLS, partial HTTP request, garbage request etc.) and how do we deal with new type of DDOS attacks (Do we keep updating the spec as and when a new DDOS attack is discovered) ?
[Ehud] Agreed with the bytes / packets count drop you proposed. For the Layer 7 telemetries and for DDoS attacks list , I think we should first get to an agreement about the needs for this attributes and then figure out the best way to signal this information. Personally I don't believe we should update the spec for each attack, therefor we need to figure out an efficient means to signal this information.

[TR] Thanks.

[Ehud] OK, understood. So I think you need to emphasize that in cases not all attributes are defined, need to use default values. In page 26 you wrote something about "need not be default". Consider to re-write.

-Tiru

Thanks,

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 16 Feb 2017 14:00:54 +0000

Hi Ehud,

Please see inline [TR2]

From: Ehud Doron [mailto:[email-masked]]
Sent: Thursday, February 16, 2017 6:43 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'dots' <[email-masked]>
Cc: David Aviv <[email-masked]>
Subject: RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

Tiru Hi

Thanks,

To: Ehud Doron <[email-masked]<mailto:[email-masked]>>; 'dots' <[email-masked]<mailto:[email-masked]>>

Hi Ehud,

Tiru and authors Hi

[TR] Done.

[TR] Agreed, fixed.

[TR] Changed to minutes

[TR] Good point, fixed.

[TR2] NEW:
The relative order of two mitigation requests from a DOTS client is determined by comparing their respective policy-id values.

[TR2] Agreed.

[TR] Thanks.

[TR2] NEW:

The DOTS agents MUST use the negotiated values for message transmission

parameters and default values for non-negotiated message transmission

parameters.  The signaling channel session configuration is

applicable to a single DOTS signal channel session between the DOTS

agents.

-Tiru

-Tiru

Thanks,

---

From: Ehud Doron <[email-masked]>
Date: Thu, 16 Feb 2017 16:10:25 +0000

Andrew

Thanks for your feedback.

Let me please clarified my points here. I totally agree with your standpoints that the signal channel restrictions should not be violated by any kind of information.

My view is that draft-doron-dots-telemetry-00 should not dictate how any kind of  telemetry information should be signaled and in which channel. I believe that this should not be discussed as part of the DOTS Telemetry work, but rather as part of the relevant protocol standard work. I see the DOTS Telemetry draft as the DOTS knowledgebase for the telemetry matter. As part do the DOTS protocol work, it should be considered what can (or can’t) be signaled, on which channel and how.

Moreover, we can think on small basic set of “essential” telemetry conveyed using the signaling channel, e.g. attack BW, PPS, dropped traffic or similar (see Tiru’s suggestions in his email), and the rest of information using the data channel.

Nevertheless, the WG need to first get to an agreement about the kind of telemetry required to facilitate a viable anti-DoS service (see please the email the DOTS telemetry authors sent to the WG).

I think this is a very good discussion.

Thanks, Ehud

From: Mortensen, Andrew [mailto:[email-masked]]
Sent: Wednesday, February 15, 2017 6:18 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>
Cc: Ehud Doron <[email-masked]>; dots <[email-masked]>; David Aviv <[email-masked]>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

Hi Ehud,

andrew

---

From: kaname nishizuka <[email-masked]>
Date: Fri, 17 Feb 2017 13:36:43 +0900

Hi Tiru,

Thanks for your response and clarifications.
Please see my response inline[kaname2]

On 2017/02/16 21:09, Tirumaleswar Reddy (tireddy) wrote:
> *Sent:* Thursday, February 16, 2017 1:22 PM
>     *To:* Tirumaleswar Reddy (tireddy) <[email-masked]> <mailto:[email-masked]>; Ehud Doron <[email-masked]> <mailto:[email-masked]>; 'dots' <[email-masked]> <mailto:[email-masked]>
[kaname2] I see. Could I confirm that my understanding is right.
The signal and data channel sessions are coupled based on the client certification. So, the same client certification should be used among (D)TLS in signal channel session and TLS in data channel session.
If so, how about writing it explicitly in the main part of [draft-reddy-dots-data-channel-04]? Now, mutual authentication is described only in 6. Security Considerations.

> [TR2] Same response as above. Aliases do not have global scope, they are specific to a DOTS client (DOTS server knows the DOTS client identity).
[kaname2]OK, I understood.

> [TR2] Yes, but the DOTS server immediately sends a ACK (acknowledging the receipt of the DELETE message), thus the DOTS client knows the server has received the Delete request and is processing the request. After deleting the mitigation (may take several seconds), server sends 2.02 (Delete) response code. I don’t see a problem.
>
> -Tiru
>
>
[kaname2] The same story could be applied to the status:1 (Attack mitigation is in progress)

thank you,
Kaname

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 17 Feb 2017 12:39:54 +0700

On 16 Feb 2017, at 23:10, Ehud Doron wrote:

> Nevertheless, the WG need to first get to an agreement about the kind 
> of telemetry required to facilitate a viable anti-DoS service (see 
> please the email the DOTS telemetry authors sent to the WG).

Why?

There are already viable anti-DDoS services today, using a variety of 
telemetry.

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 21 Feb 2017 06:59:15 +0000

Please see inline [TR3]

Sent: Friday, February 17, 2017 10:07 AM

Hi Tiru,

Please see inline [TR2]

Hi Tiru,

please see inline.

Hi Tiru,

[TR3] Yes.

[TR3] Good point, will update signal channel draft how signal and data channel sessions are coupled using DOTS client identity.
NEW:

   In both DOTS signal and data channel sessions, the DOTS client MUST
   authenticate itself to the DOTS server (Section 9).  The DOTS server
   couples the DOTS signal and data channel sessions using the DOTS
   client identity, so the DOTS server can validate whether the aliases
   conveyed in the mitigation request were indeed created by the same
   DOTS client using the DOTS data channel session.  If the aliases were
   not created by the DOTS client then the DOTS server returns 4.00 (Bad
   Request) in the response.

[TR] No.

-Tiru

[TR3] No, the DOTS client needs to know the mitigation status and DDOS attack status so that it can withdraw the mitigation request when the DDOS attack stops (see Section 5.3.3.1) and to know whether the DOTS mitigation provider is able to successfully mitigate the attack or is re-directing the client to an alternate DOTS server.
These unsolicited notifications are not required for withdraw because after validating the DELETE request DOTS server immediately send an ACK or returns an error that the DELETE request was invalid and it is DOTS server responsibility to withdraw the mitigation request from the DDOS mitigator(s) (which may take several seconds).

-Tiru

thank you,
Kaname

thank you,
kaname

-Tiru

thank you,
Kaname

Tiru and authors Hi

-Tiru

Thanks,

Dots mailing list

Dots mailing list

Dots mailing list

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 22 Feb 2017 12:38:45 +0900

Hi Tiru,

On 2017/02/21 15:59, Tirumaleswar Reddy (tireddy) wrote:
> *Sent:* Friday, February 17, 2017 10:07 AM
[kaname3] I'm OK with the new text. It's clear to me now.

thank you,
Kaname

---

From: kaname nishizuka <[email-masked]>
Date: Fri, 24 Feb 2017 13:46:48 +0900

Hi Tiru,

I'd like to add a comment on lifetime attribute in signal-channel

 > 7.       Page 15 Life time attribute: More reasonable to have this attribute in minutes rather than seconds, bigger default can also suggested

I prefer seconds than minutes because I think granularity of minutes is rough.
If we are to leverage programmable and automated feature of DOTS, lifetime in "seconds" is fine.

thank you,
Kaname

On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wrote:
>
> Hi Ehud,
>
> Please see inline [TR2]
>
> *From:* Ehud Doron [mailto:[email-masked]]
> *Sent:* Thursday, February 16, 2017 6:43 PM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked]>; 'dots' <[email-masked]>
> *Subject:* RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .
>
> Tiru Hi
>
> *From:* Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> *Sent:* Tuesday, February 14, 2017 4:53 PM
> *To:* Ehud Doron <[email-masked] <mailto:[email-masked]>>; 'dots' <[email-masked] <mailto:[email-masked]>>
> *Cc:* David Aviv <[email-masked] <mailto:[email-masked]>>
> *Subject:* RE: Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .
>
> Hi Ehud,
>
> *To:* 'dots' <[email-masked] <mailto:[email-masked]>>
> *Cc:* David Aviv <[email-masked] <mailto:[email-masked]>>
> [Ehud] Consider to update the text in page 15 with your explanations here, mainly regarding the “per customer uniqueness of DOTS”.
>
> [TR2] NEW:
>
> [Ehud] Agreed with the bytes / packets count drop you proposed. For the Layer 7 telemetries and for DDoS attacks list , I think we should first get to an agreement about the needs for this attributes and then figure out the best way to signal this information. Personally I don’t believe we should update the spec for each attack, therefor we need to figure out an efficient means to signal this information.
>
> [TR2] Agreed.
>
> [TR] Yes, it’s possible; create different aliases for IP1 TCP port 80 and IP 2 UDP port 53 using DOTS data channel and convey the aliases in DOTS signal channel.
>
> [TR]  It’s for a single DOTS session between DOTS client and server, a single DOTS session can be used for several DOTS requests and responses.
>
> [Ehud] OK, understood. So I think you need to emphasize that in cases not all attributes are defined, need to use default values. In page 26 you wrote something about “need not be default”. Consider to re-write.
> [TR2] NEW:

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 28 Feb 2017 09:13:45 +0000

Sent: Friday, February 24, 2017 10:17 AM

Hi Tiru,

I prefer seconds than minutes because I think granularity of minutes is rough.
If we are to leverage programmable and automated feature of DOTS, lifetime in "seconds" is fine.
Works for me.
Ehud - Any specific reason for suggesting minutes ?
-Tiru

thank you,
Kaname

Please see inline [TR2]

To: Tirumaleswar Reddy (tireddy) <[email-masked]><mailto:[email-masked]>; 'dots' <[email-masked]><mailto:[email-masked]>

Tiru Hi

Thanks,

Hi Ehud,

Tiru and authors Hi

[TR] Done.

[TR] Agreed, fixed.

[TR] Changed to minutes

[TR] Good point, fixed.

[TR2] NEW:

[TR2] Agreed.

[TR] Thanks.

[TR2] NEW:

agents.

-Tiru

-Tiru

Thanks,

Dots mailing list

---

From: Ehud Doron <[email-masked]>
Date: Tue, 28 Feb 2017 14:57:23 +0000

Hi Tiru, Kaname

As this attribute is defined as the lifetime of the all mitigation request (i.e. the entire attack period), as per my knowledge this kind of period can typically be relatively long (hours and more),  so that why minutes can be more comfortable to operate.
However if Kaname thinks seconds is better as it is more granular, this can be suggested here as well.

Thanks, Ehud

From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Tuesday, February 28, 2017 11:14 AM
To: kaname nishizuka <[email-masked]>; Ehud Doron <[email-masked]>; 'dots' <[email-masked]>
Cc: David Aviv <[email-masked]>
Subject: RE: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; Ehud Doron <[email-masked]<mailto:[email-masked]>>; 'dots' <[email-masked]<mailto:[email-masked]>>

Hi Tiru,

thank you,
Kaname

Please see inline [TR2]

Tiru Hi

Thanks,

Hi Ehud,

Tiru and authors Hi

[TR] Done.

[TR] Agreed, fixed.

[TR] Changed to minutes

[TR] Good point, fixed.

[TR2] NEW:

[TR2] Agreed.

[TR] Thanks.

[TR2] NEW:

agents.

-Tiru

-Tiru

Thanks,

Dots mailing list

---

From: Dave Dolson <[email-masked]>
Date: Tue, 28 Feb 2017 19:26:43 +0000

In my opinion, units of seconds are preferable in a protocol, if only because they are the base S.I. unit.

Any user interface (or programming interface) can easily convert minutes to seconds if desired.

From: Dots [mailto:[email-masked]] On Behalf Of Ehud Doron
Sent: Tuesday, February 28, 2017 9:57 AM
To: Tirumaleswar Reddy (tireddy); kaname nishizuka; 'dots'
Cc: David Aviv
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

Hi Tiru, Kaname

Thanks, Ehud

Hi Tiru,

thank you,
Kaname

Please see inline [TR2]

Tiru Hi

Thanks,

Hi Ehud,

Tiru and authors Hi

[TR] Done.

[TR] Agreed, fixed.

[TR] Changed to minutes

[TR] Good point, fixed.

[TR2] NEW:

[TR2] Agreed.

[TR] Thanks.

[TR2] NEW:

agents.

-Tiru

-Tiru

Thanks,

Dots mailing list

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 1 Mar 2017 02:05:13 +0000

From: Dave Dolson [mailto:[email-masked]]
Sent: Wednesday, March 1, 2017 12:57 AM
To: Ehud Doron <[email-masked]>; Tirumaleswar Reddy (tireddy) <[email-masked]>; kaname nishizuka <[email-masked]>; 'dots' <[email-masked]>
Cc: David Aviv <[email-masked]>
Subject: RE: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

Agreed, fixed in my local copy.

-Tiru

Hi Tiru, Kaname

Thanks, Ehud

To: kaname nishizuka <[email-masked]<mailto:[email-masked]>>; Ehud Doron <[email-masked]<mailto:[email-masked]>>; 'dots' <[email-masked]<mailto:[email-masked]>>

Hi Tiru,

thank you,
Kaname

Please see inline [TR2]

Tiru Hi

Thanks,

Hi Ehud,

Tiru and authors Hi

[TR] Done.

[TR] Agreed, fixed.

[TR] Changed to minutes

[TR] Good point, fixed.

[TR2] NEW:

[TR2] Agreed.

[TR] Thanks.

[TR2] NEW:

agents.

-Tiru

-Tiru

Thanks,

Dots mailing list

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 1 Mar 2017 11:14:06 +0900

On 2017/03/01 11:05, Tirumaleswar Reddy (tireddy) wrote:
>
> *From:*Dave Dolson [mailto:[email-masked]]
> *Sent:* Wednesday, March 1, 2017 12:57 AM
> *To:* Ehud Doron <[email-masked]>; Tirumaleswar Reddy (tireddy) <[email-masked]>; kaname nishizuka <[email-masked]>; 'dots' <[email-masked]>
> *Subject:* RE: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .
>

Yes. I agree.

thank you,
Kaname

> *From:*Dots [mailto:[email-masked]] *On Behalf Of *Ehud Doron
> *Sent:* Tuesday, February 28, 2017 9:57 AM
> *To:* Tirumaleswar Reddy (tireddy); kaname nishizuka; 'dots'
> *Cc:* David Aviv
> *From:*Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> *Sent:* Tuesday, February 28, 2017 11:14 AM
> *To:* kaname nishizuka <[email-masked] <mailto:[email-masked]>>; Ehud Doron <[email-masked] <mailto:[email-masked]>>; 'dots' <[email-masked] <mailto:[email-masked]>>
> *Subject:* RE: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .
>
> *Sent:* Friday, February 24, 2017 10:17 AM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked] <mailto:[email-masked]>>; Ehud Doron <[email-masked] <mailto:[email-masked]>>; 'dots' <[email-masked] <mailto:[email-masked]>>
> Ehud – Any specific reason for suggesting minutes ?
>
> -Tiru
>
>
>
> thank you,
> Kaname
>
>     *To:* Tirumaleswar Reddy (tireddy) <[email-masked]> <mailto:[email-masked]>; 'dots' <[email-masked]> <mailto:[email-masked]>