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

[Ehud Doron <[e-mail]>]

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:[e-mail]]
Sent: Tuesday, February 28, 2017 11:14 AM
To: kaname nishizuka <[e-mail]>; Ehud Doron <[e-mail]>; 'dots' <[e-mail]>
Cc: David Aviv <[e-mail]>
Subject: RE: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

From: kaname nishizuka [mailto:[e-mail]]
Sent: Friday, February 24, 2017 10:17 AM
To: Tirumaleswar Reddy (tireddy) <[e-mail]<mailto:[e-mail]>>; Ehud Doron <[e-mail]<mailto:[e-mail]>>; 'dots' <[e-mail]<mailto:[e-mail]>>
Cc: David Aviv <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

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
> [TR] Changed to minutes

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
On 2017/02/16 23:00, Tirumaleswar Reddy (tireddy) wrote:
Hi Ehud,

Please see inline [TR2]

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

Tiru Hi

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

Thanks,

Ehud Doron |  Senior Architect, Radware CTO office | M: [phone] | T: [phone]



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

Hi Ehud,

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

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

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

[TR] Yes, will update draft.


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

[TR] Done.


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

[TR] Agreed, fixed.


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

[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.


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

[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.


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.

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


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

[TR] Changed to minutes


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 .

[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".

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


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.

[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.

[TR2] Agreed.


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.

[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.


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

[TR] Thanks.


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

[TR] Same response as above.


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 .

[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.



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?

[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.


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".


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

[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:

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



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 ?

[TR] Both, updated draft.

-Tiru

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: [phone] | T: [phone]







_______________________________________________

Dots mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/dots