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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Ehud,

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

From: Dots [mailto:[e-mail]] On Behalf Of Ehud Doron
Sent: Wednesday, February 8, 2017 7:21 PM
To: 'dots' <[e-mail]>
Cc: David Aviv <[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


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

[TR] Agreed, updated draft.



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

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


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-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 is possible; create different aliases for IP1 TCP port 80 and IP2 UDP port 53.



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.

[TR] Thanks, fixed chapter 3.3.



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

[TR] Done, updated draft.


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

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




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

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


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

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

-Tiru

Thanks,

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