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

[kaname nishizuka <[e-mail]>]

Hi Tiru,


On 2017/02/21 15:59, Tirumaleswar Reddy (tireddy) wrote:
>
> Please see inline [TR3]
>
> *From:*kaname nishizuka [mailto:[e-mail]]
> *Sent:* Friday, February 17, 2017 10:07 AM
> *To:* Tirumaleswar Reddy (tireddy) <[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 .
>
> Hi Tiru,
>
> Thanks for your response and clarifications.
> Please see my response inline[kaname2]
>
> On 2017/02/16 21:09, Tirumaleswar Reddy (tireddy) wrote:
>
>     Hi Kaname,
>
>     Please see inline [TR2]
>
>     *From:*kaname nishizuka [mailto:[e-mail]]
>     *Sent:* Thursday, February 16, 2017 1:22 PM
>     *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,
>
>     please see inline.
>
>     On 2017/02/16 13:18, Tirumaleswar Reddy (tireddy) wrote:
>
>         Hi Kaname,
>
>         Please see inline [TR] for responses
>
>         *From:*kaname nishizuka [mailto:[e-mail]]
>         *Sent:* Wednesday, February 15, 2017 11:27 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 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.
>
>         [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.
>
>     [kaname]OK, understood.
>
>
>
>         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.
>
>     [kaname] If there are more than one signal and data channel, how can they coupled?
>
>     [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.
>
> [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.
>
> [TR3] Yes.
>
>
> 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.
>
> [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.
>
[kaname3] I'm OK with the new text. It's clear to me now.

thank you,
Kaname

>     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.
>
>         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.
>
>     [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?
>
>     [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).
>
> [kaname2]OK, I understood.
>
>
>
>         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.
>
>     [kaname] As I noted, deleting of mitigation could take several seconds (or minutes) in real-life.
>
>     [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)
>
> [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
>
>     If the DOTS client retrieve the status while that time, getting "deleting status", not "2.02 status", will help operators.
>
>
>         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).
>
>     [kaname] Thank you, I found the reference.
>
>
>         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.
>
>     [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.
>
>
>         # 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.
>
>     [kaname] OK. I'll see 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.
>
>     [kaname] OK. I'll see updated draft.
>
>
>     thank you,
>     kaname
>
>
>         -Tiru
>
>
>         thank you,
>         Kaname
>
>         On 2017/02/14 23:58, Tirumaleswar Reddy (tireddy) wrote:
>
>             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]> <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
>
>             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
>
>             [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-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.
>
>             [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-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…
>
>             [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]
>
>
>
>
>
>
>             _______________________________________________
>
>             Dots mailing list
>
>             [e-mail] <mailto:[e-mail]>
>
>             https://www.ietf.org/mailman/listinfo/dots
>
>
>
>
>
>         _______________________________________________
>
>         Dots mailing list
>
>         [e-mail] <mailto:[e-mail]>
>
>         https://www.ietf.org/mailman/listinfo/dots
>
>
>
>
>     _______________________________________________
>
>     Dots mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/dots
>
>
>
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots