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

[kaname nishizuka <[e-mail]>]

I support adoption of this draft.
And +1 to this Daniel's comment.

 > the mechanism can be generalized and actually
 > help coordination between independent domains.  I believe the draft can
 > be placed in a larger perspective.

thanks,
Kaname Nishizuka

On 2019/04/16 1:04, Daniel Migault wrote:
> 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.
>
>
> 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".
>
>
> 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.
>
>
> On Sun, Apr 14, 2019 at 11:06 PM Panwei (William) <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi,
>
>     I support adoption of this draft.
>
>     Best Regards
>     Wei Pan
>
>     -----Original Message-----
>     From: Dots [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Valery Smyslov
>     Sent: Monday, April 08, 2019 11:29 PM
>     To: [e-mail] <mailto:[e-mail]>
>     Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[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] <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