Re: [Dots] Adoption call for draft-reddy-dots-home-network-04

[Daniel Migault <[e-mail]>]

Thanks Tiru,

Thanks for the feedback. Please see my comments/response and clarification.
Apology for being so long to respond.

Yours,
Daniel

On Thu, Apr 18, 2019 at 8:53 AM Konda, Tirumaleswar Reddy <
[e-mail]> wrote:

> Hi Daniel,
>
>
>
> Thanks for the review, Please see inline [TR]
>
>
>
> *From:* Dots <[e-mail]> *On Behalf Of * Daniel Migault
> *Sent:* Monday, April 15, 2019 9:34 PM
> *To:* Panwei (William) <[e-mail]>
> *Cc:* [e-mail]; Valery Smyslov <[e-mail]>;
> [e-mail]; [e-mail]
> *Subject:* Re: [Dots] Adoption call for draft-reddy-dots-home-network-04
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> ------------------------------
>
> I support the adoption of the draft, please see my comments on the current
> version. None of them should be considered as preventing the adoption.
>
>
>
> Yours,
>
> Daniel
>
>
>
> Some random comments:
>
>
>
>
>
> Section 1:
>
>
>
> """
>
>    Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris,
>
>    and TLS re-negotiation are difficult to detect on the home network
>
>    devices without adversely affecting its performance.  The reason is
>
>    typically home routers have fast path to boost the throughput.  For
>
>    every new TCP/UDP flow, only the first few packets are punted through
>
>    the slow path.  Hence, it is not possible to detect various DDoS
>
>    attacks in the slow path, since the attack payload is sent to the
>
>    target server after the flow is switched to fast path.  Deep packet
>
>    inspection (DPI) of all the packets of a flow would be able to detect
>
>    some of the attacks.  However, a full-fledged DPI to detect these
>
>    type of DDoS attacks is functionally or operationally not possible
>
>    for all the devices attached to the home network owing to the memory
>
>    and CPU limitations of the home routers.  Further, for certain DDoS
>
>    attacks the ability to distinguish legitimate traffic from attacker
>
>    traffic on a per packet basis is complex.  This complexity originates
>
>    from the fact that the packet itself may look "legitimate" and no
>
>    attack signature can be identified.  The anomaly can be identified
>
>    only after detailed statistical analysis.
>
> """
>
>
>
> I understand, the paragraph below as saying that detection at the ISP is
>
> easier than at the homenet level as the ISP aggregates the traffic. This
>
> is correct and I agree with the text. However, if we are going a bit
>
> further, the detection is even easier to the DDoS target. I believe that
>
> the same mechanism could be deployed between a DDoS target, its Cloud
>
> provider major ISPs up to the origin. The example of the Homenet and the
>
> ISP is only one bound but the mechanism can be generalized and actually
>
> help coordination between independent domains.  I believe the draft can
>
> be placed in a larger perspective.
>
>
>
> [TR] Agreed, it is relatively easy for the DDoS mitigation provider for
> the attack target to detect sophisticated DDoS attacks (especially if the
> attack uses encrypted traffic).
>
>
>
> I will add the following lines:
>
>
>
> BGP defines a mechanism as described in [RFC5575] that can be used to
>
> automate inter-domain coordination of traffic filtering, such as what
>
> is required in order to mitigate DDoS attacks. DDoS mitigation provider
>
> for the attack target can detect sophisticated DDoS attacks
>
> using encrypted attack traffic, and can possibly use BGP flowspec
> [RFC5575] to
>
>   convey the filtering rules to filter block, or rate-limit DDoS attack
> traffic originating
>
>   from the ISP's subscribers to the attack target.
>
>
>
>
>
> Section 3.1 Procedure:
>
>
>
> I am not convinced this is the right approach to switch the roles
>
> between clients and servers. I believe that while the previous dots
>
> signal-channel was foreseeing the relation as asymmetric, we are now
>
> considering DOTS Client and DOTS Server as mostly symmetric. Maybe one
>
> way to see this could be to have a DOTS communication between different
>
> entities, and exchanges can be in both directions. The one initiating
>
> the exchange could be designated as DOTS Initiator, while the receiving
>
> side is the DOTS Responder.
>
>
>
> Here is a more concrete example while Client / Server  might be
>
> confusing. When  a server sends an alert when under attach it is designated
>
> as the DOTS Client, while the same client specifying these IP addresses
>
> are detected as belonging to an attacker will be the Server.
>
>
>
> It seems also to me that establishment of the (D)TLS channel can be sent
>
> by any other peer, not necessarily the peer sending further
>
> notification/request. Typically the DOTS Client may have set the DOTS
>
> channel protected by (D)TLS, and the DOTS Server may re-use that exact
>
> same channel.
>
>
>
> I am also wondering if the support of the extension is agreed or
>
> announced. If so this would ease the negotiation of which peer is able
>
> to handle the requests and be a "Server".
>
>
>
> [TR] Both draft-reddy-dots-home-network and RFC8071 adopt the same
> approach for managing roles and connections. You may want to look into
> RFC8071.
>
>         CoAP allows asynchronous messages but the request is always sent
> by the CoAP client.
>
>
>
<mglt>ok thanks. and we wants to map the DOTS Client with the CoAP client.
In other words, it is out of scope to have a DOT CLient with a CoAP client
and a CoAP server. When I wrote the comment I had a push request in mind,
and observe does not work ;-)</mglt>


> I believe the clarification and comparison with the
>
> "traditional"/"initial" DOTS use cases is useful and needs to stay for
>
> clarification purpose. However, one should make sure also that such
>
> signalling can also be made with a signal dots signalling established in
>
> the initial use cases. Typically, the DOTS client may have set the DOTS
>
> channel and set a DTLS session which could carry the signalling of the
>
> draft.
>
>
>
> [TR] I don’t get the above comment.
>
<mglt>I suppose my mouse pointer tricked me. The idea I wanted to provide
was that *maybe* it would be good to think as DOTS peers that establish a
channel using DTLS and each peer can be over the same channel act as a
client or server. We would rather talk about initiator and responder. In
other word, to make teh protocol less asymmetric. </mglt>

>
>
> Cheers,
>
> -Tiru
>
>
>
>
>
> On Sun, Apr 14, 2019 at 11:06 PM Panwei (William) <
> [e-mail]> wrote:
>
> Hi,
>
> I support adoption of this draft.
>
> Best Regards
> Wei Pan
>
> -----Original Message-----
> From: Dots [mailto:[e-mail]] On Behalf Of Valery Smyslov
> Sent: Monday, April 08, 2019 11:29 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: [Dots] Adoption call for draft-reddy-dots-home-network-04
>
> Hi all,
>
> the chairs recently received an adoption request for
> draft-reddy-dots-home-network-04.
>
> This message starts a two-week adoption call for
> draft-reddy-dots-home-network-04.
> The call ends up on Tuesday, April the 23rd.
>
> Please send your opinion regarding adoption of this document to the list
> before this date.
> If you think the draft should be adopted, please indicate whether you're
> willing to review it/to work on it. If you think the draft should not be
> adopted, please explain why.
>
> Regards,
> Frank & Valery.
>
>
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots
>
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots
>
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots
>