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

<mohamed.boucadair@orange.com> Thu, 25 April 2019 06:58 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88CC120136 for <dots@ietfa.amsl.com>; Wed, 24 Apr 2019 23:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHfFK-SmPPn9 for <dots@ietfa.amsl.com>; Wed, 24 Apr 2019 23:58:42 -0700 (PDT)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D6A1200EA for <dots@ietf.org>; Wed, 24 Apr 2019 23:58:42 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 44qShJ0sJbz308h; Thu, 25 Apr 2019 08:58:40 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 44qShJ051qz3wbb; Thu, 25 Apr 2019 08:58:40 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Thu, 25 Apr 2019 08:58:39 +0200
From: mohamed.boucadair@orange.com
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, Daniel Migault <daniel.migault@ericsson.com>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] Adoption call for draft-reddy-dots-home-network-04
Thread-Index: AdTuHVZNyfDh6IMnTiyfhZP8vM2pOAFGr25wABsxq4AAi6JHcAAE2iQQAAHe34AAAJITIAFQh6kA
Date: Thu, 25 Apr 2019 06:58:39 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA656D3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <023d01d4ee1f$c2bcb190$483614b0$@smyslov.net> <30E95A901DB42F44BA42D69DB20DFA6A69F3A581@nkgeml513-mbx.china.huawei.com> <CADZyTkmtyO25-JiHMicZDUL2F+5RXpnFPsYHmyn67yfHTns5fA@mail.gmail.com> <BYAPR16MB2790ECCDECA7EA5E62F76F0DEA260@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA62879@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790D5CB67D6A4C1BE6D022BEA260@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA62A43@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA62A43@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA656D3OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/VrNQqZ120uu3oDJdl-JVmACmCuc>
Subject: Re: [Dots] Adoption call for draft-reddy-dots-home-network-04
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Apr 2019 06:58:47 -0000

Hi Tiru, Daniel,

I’d like we conclude on this one.

Here is a NEW text proposal to capture what I think is the main comment from Daniel while avoiding to include considerations that are not currently supported by DOTS:

   A DOTS client relies upon a variety of triggers to invoke the Call
   Home function (e.g., scrubbing the traffic from the attack source,
   receiving an alert from an attack target, a peer DDoS Mitigation
   System (DMS), or a transit provider).  The definition of these
   triggers is deployment-specific.  It is therefore out of the scope of
   this document to elaborate on how these triggers are made available
   to a DOTS client.

Cheers,
Med

De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@orange.com
Envoyé : jeudi 18 avril 2019 16:33
À : Konda, Tirumaleswar Reddy; Daniel Migault
Cc : dots-chairs@ietf.org; Valery Smyslov; dots@ietf.org; kaduk@mit.edu
Objet : Re: [Dots] Adoption call for draft-reddy-dots-home-network-04

Re-,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoyé : jeudi 18 avril 2019 15:59
À : BOUCADAIR Mohamed TGI/OLN; Daniel Migault
Cc : dots-chairs@ietf.org; Valery Smyslov; dots@ietf.org; kaduk@mit.edu
Objet : RE: [Dots] Adoption call for draft-reddy-dots-home-network-04

From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
Sent: Thursday, April 18, 2019 6:43 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Daniel Migault <daniel.migault@ericsson.com>
Cc: dots-chairs@ietf.org; Valery Smyslov <valery@smyslov.net>; dots@ietf.org; kaduk@mit.edu
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.


________________________________
Hi Tiru, Daniel,

With regards to:

“ I believe that
the same mechanism could be deployed between a DDoS target, its Cloud
provider major ISPs up to the origin.”

This is not currently doable with DOTS. Some key functional components are needed:
(1) To identify the appropriate ISP which is hosting a DDoS source once a DDoS target has detected/reported an attack to its DOTS server/provider. The target may not be on the same network as the source.
(2) That ISP needs to expose a service to receive these notifications.

Of course, if the ISP is capable of receiving these notifications, it can invoke the procedure in draft-reddy-dots-home-network.

The scenario mentioned by Daniel is an interesting problem to address…but I’m afraid this is out of scope of the current DOTS charter.

[TR] Agree with your response

I don’t see how BGP Flowspec solves this.

[TR], BGP Flowspec allows the ISP to receive the filtering rules from the mitigation provider (downstream ISP) for the attack target, do you see a problem with my proposed text ?
[Med] The attack target is not necessarily attached to the downstream ISP. Multi-hop ASes may be between the AS hosting the target and the one connecting the attack source.

-Tiru

Cheers,
Med

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoyé : jeudi 18 avril 2019 14:52
À : Daniel Migault; Panwei (William)
Cc : dots-chairs@ietf.org<mailto:dots-chairs@ietf.org>; Valery Smyslov; dots@ietf.org<mailto:dots@ietf.org>; kaduk@mit.edu<mailto:kaduk@mit.edu>
Objet : Re: [Dots] Adoption call for draft-reddy-dots-home-network-04

Hi Daniel,

Thanks for the review, Please see inline [TR]

From: Dots <dots-bounces@ietf.org<mailto:dots-bounces@ietf.org>> On Behalf Of Daniel Migault
Sent: Monday, April 15, 2019 9:34 PM
To: Panwei (William) <william.panwei@huawei.com<mailto:william.panwei@huawei.com>>
Cc: dots-chairs@ietf.org<mailto:dots-chairs@ietf.org>; Valery Smyslov <valery@smyslov.net<mailto:valery@smyslov.net>>; dots@ietf.org<mailto:dots@ietf.org>; kaduk@mit.edu<mailto:kaduk@mit.edu>
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.

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.

Cheers,
-Tiru


On Sun, Apr 14, 2019 at 11:06 PM Panwei (William) <william.panwei@huawei.com<mailto:william.panwei@huawei.com>> wrote:
Hi,

I support adoption of this draft.

Best Regards
Wei Pan

-----Original Message-----
From: Dots [mailto:dots-bounces@ietf.org<mailto:dots-bounces@ietf.org>] On Behalf Of Valery Smyslov
Sent: Monday, April 08, 2019 11:29 PM
To: dots@ietf.org<mailto:dots@ietf.org>
Cc: dots-chairs@ietf.org<mailto:dots-chairs@ietf.org>; kaduk@mit.edu<mailto:kaduk@mit.edu>
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@ietf.org<mailto:Dots@ietf.org>
https://www.ietf.org/mailman/listinfo/dots

_______________________________________________
Dots mailing list
Dots@ietf.org<mailto:Dots@ietf.org>
https://www.ietf.org/mailman/listinfo/dots