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

kaname nishizuka <> Thu, 18 April 2019 00:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 374B3120033; Wed, 17 Apr 2019 17:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qrJZLa8oi85G; Wed, 17 Apr 2019 17:48:51 -0700 (PDT)
Received: from ( [IPv6:2402:c800:ff06:136::140]) by (Postfix) with ESMTP id 9ECFC1201A2; Wed, 17 Apr 2019 17:48:50 -0700 (PDT)
Received: from ( []) by (NTTv6MTA) with ESMTP id 24B2825F68C; Thu, 18 Apr 2019 09:48:49 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20180820; t=1555548529; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AIWR8ftY73skIA3E65O4MfG0s7RZxzIngocXW54OUjI=; b=sBEGtJo99CldOWAC42AUcSz1RRPWfUOmU76rBvrfZXAdAqRBnplf7v76ADoCRgIt8ZbpUY Zvsgi822fU7sYqUqcOow6PIbduJwJaRTamt+7HP1Ihu7SZtLm3lqQI1B+sZUvQsJvJw3jo cImVPTtCPUDOuFyGt/rgE8qf55wKhlw=
Received: from [IPv6:::1] ( [IPv6:2402:c800:ff06:136::141]) by (NTTv6MTA) with ESMTP id B1D22759011; Thu, 18 Apr 2019 09:48:48 +0900 (JST)
To: Valery Smyslov <>
Cc: "" <>, "" <>, "" <>
References: <023d01d4ee1f$c2bcb190$483614b0$> <> <>
From: kaname nishizuka <>
Message-ID: <>
Date: Thu, 18 Apr 2019 09:48:48 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------8ADB9A9317699F12309A52FD"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Dots] Adoption call for draft-reddy-dots-home-network-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Apr 2019 00:48:54 -0000

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.

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) < <>> wrote:
>     Hi,
>     I support adoption of this draft.
>     Best Regards
>     Wei Pan
>     -----Original Message-----
>     From: Dots [ <>] On Behalf Of Valery Smyslov
>     Sent: Monday, April 08, 2019 11:29 PM
>     To: <>
>     Cc: <>; <>
>     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
> <>
>     _______________________________________________
>     Dots mailing list
> <>
> _______________________________________________
> Dots mailing list