Re: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-offload-usecase-01:

<mohamed.boucadair@orange.com> Fri, 12 July 2019 05:38 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 C78CA12016B; Thu, 11 Jul 2019 22:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 5ufCMv_JEBdF; Thu, 11 Jul 2019 22:38:03 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B38120104; Thu, 11 Jul 2019 22:38:03 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 45lMCF3Rjnzywt; Fri, 12 Jul 2019 07:38:01 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 45lMCF31NfzDq75; Fri, 12 Jul 2019 07:38:01 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905%18]) with mapi id 14.03.0439.000; Fri, 12 Jul 2019 07:38:01 +0200
From: <mohamed.boucadair@orange.com>
To: H Y <yuuhei.hayashi@gmail.com>, "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
CC: "draft-hayashi-dots-dms-offload-usecase.authors@ietf.org" <draft-hayashi-dots-dms-offload-usecase.authors@ietf.org>, Valery Smyslov <valery@smyslov.net>, "dots@ietf.org" <dots@ietf.org>, "neshi-nwsec-p-ml@hco.ntt.co.jp" <neshi-nwsec-p-ml@hco.ntt.co.jp>
Thread-Topic: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-offload-usecase-01:
Thread-Index: AdU4Xd5vj9xW+DVwTo2s5d/iB7L+dAAAAXSAAAUphyA=
Date: Fri, 12 Jul 2019 05:38:01 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EACACC9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <C02846B1344F344EB4FAA6FA7AF481F13E7C878E@dggemm511-mbx.china.huawei.com> <CAA8pjUM9M1Ur5LDjFay0nH1e8=uc5+BeBW9PrD4k3GcqZOJG+w@mail.gmail.com>
In-Reply-To: <CAA8pjUM9M1Ur5LDjFay0nH1e8=uc5+BeBW9PrD4k3GcqZOJG+w@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/hreKQRUXTNpaZeHu-9psokLS-gY>
Subject: Re: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-offload-usecase-01:
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: Fri, 12 Jul 2019 05:38:06 -0000

Franck,

An important contribution from this draft is to assess to what extent current DOTS specs can be applied in a particular deployment context and there is no void, while the use case draft was done to drive the specification. 

There is IMO a need for an effort to socialize DOTS and exemplify how it can be used in various deployment contexts. This draft is a contribution in that aim.

BTW, I'm not sure to understand this comment:

> And be careful using signal channel call home for your use case, since it is a special mechanism for near source attack mitigation with DOTS server create TLS connection with DOTS client, which I don’t think it’s very suitable for your case.

The intent is to use the src-* signal channel extensions. I don't see any issue in doing that.

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : H Y [mailto:yuuhei.hayashi@gmail.com]
> Envoyé : vendredi 12 juillet 2019 07:00
> À : Xialiang (Frank, Network Standard & Patent Dept)
> Cc : draft-hayashi-dots-dms-offload-usecase.authors@ietf.org; Valery
> Smyslov; dots@ietf.org; neshi-nwsec-p-ml@hco.ntt.co.jp
> Objet : Re: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-
> offload-usecase-01:
> 
> Hi Frank,
> 
> Thank you for reviewing my draft :-)
> Please see inline.
> 
> > 1.  I see your proposed offload use case as an variant of DOTS
> Orchestration use case (section 3.3 of draft-ietf-dots-use-cases-18).
> [hayashi]Yes, that's right.
> 
> > If so, what is your propose for this part of content? Do you want to
> improve the existing DOTS use cases WG draft with your addition?
> [hayashi]Yes, I want to add our use case to improve the DOTS
> orchestration use cases.
> About the DOTS orchestration use case in current use cases WG draft,
> DMS doesn't have DOTS client function.
> IMO, it's effective that DMSs send blocked information to an
> orchestrator via standardized IF and the orchestrator carries out some
> action in the network.
> 
> At IETF 104, I proposed to add our use case to improve the DOTS
> orchestration use cases, however, I could not do it because the use
> case WG draft now is in Publication Requested status.
> Some people gave me the advice to include DOTS deployment
> consideration to my draft, so I update my draft based on the comments.
> 
> Please see IETF104 minute https://datatracker.ietf.org/doc/minutes-104-
> dots/
> 
> > 2.      Right now, DOTS protocol defines sending DOTS request via signal
> channel, do you propose to send it via data channel in some situation? If
> so, I personally disagree with it, since we originally define signal
> channel and data channel for different functionalities & messages, we can
> not send any DOTS messages over wrong channel, like: DOTS request via data
> channel.
> [hayashi] After I submitted
> draft-h-dots-mitigation-offload-expansion-00,  some people gave me
> comments not to use signal channel but to use data channel via out-of
> band because link b/w the DMS and Orchestrator won't be congested
> under attack time.
> 
> Please see the mail thread [Dots]
> draft-h-dots-mitigation-offload-expansion-00: Reasons why we want to
> standardize between DMS and orchestrator using DOTS
> 
> Current data channel has the capability to send filtering rules
> immediately, so I think it can be used to send blocked information
> from DMS to Orchestrator.
> If the signal channel has the capability to convey the attacker's
> information, the signal channel can be also used to send it to form
> DMS to Orchestrator.
> 
> > 3.      In addition to extended offload use case content, I do not see
> any new protocol, message or attribute extension comparing to the existing
> defined DOTS protocols, the left content are just some examples about how
> you use the existing DOTS protocol for your offload use case. So, what do
> you want DOTS WG to do for this draft, since there are no new thing here?
> [hayashi] This draft requires that ...
> - It's effective that DMS have DOTS client function in DOTS
> orchestration use case.
> - It's effective that signal channel has the capability to send src
> information.
> For example, it's useful and feasible to send src port information via
> the DOTS signal channel to request mitigation against reflection
> attack.
> 
> > And be careful using signal channel call home for your use case, since
> it is a special mechanism for near source attack mitigation with DOTS
> server create TLS connection with DOTS client, which I don’t think it’s
> very suitable for your case.
> Thank you for giving me comments. Could I define another signal
> channel expansion to send src information via signal channel?
> 
> Thanks,
> Yuhei
> 
> 2019年7月12日(金) 12:10 Xialiang (Frank, Network Standard & Patent Dept)
> <frank.xialiang@huawei.com>;:
> >
> > Hi authors,
> >
> > I have reviewed this new version and have 3 questions as below:
> >
> > 1.      I see your proposed offload use case as an variant of DOTS
> Orchestration use case (section 3.3 of draft-ietf-dots-use-cases-18). If
> so, what is your propose for this part of content? Do you want to improve
> the existing DOTS use cases WG draft with your addition?
> >
> > 2.      Right now, DOTS protocol defines sending DOTS request via signal
> channel, do you propose to send it via data channel in some situation? If
> so, I personally disagree with it, since we originally define signal
> channel and data channel for different functionalities & messages, we can
> not send any DOTS messages over wrong channel, like: DOTS request via data
> channel.
> >
> > 3.      In addition to extended offload use case content, I do not see
> any new protocol, message or attribute extension comparing to the existing
> defined DOTS protocols, the left content are just some examples about how
> you use the existing DOTS protocol for your offload use case. So, what do
> you want DOTS WG to do for this draft, since there are no new thing here?
> And be careful using signal channel call home for your use case, since it
> is a special mechanism for near source attack mitigation with DOTS server
> create TLS connection with DOTS client, which I don’t think it’s very
> suitable for your case.
> >
> >
> >
> > Thanks!
> >
> >
> >
> > B.R.
> >
> > Frank
> >
> >
> >
> > _______________________________________________
> > Dots mailing list
> > Dots@ietf.org
> > https://www.ietf.org/mailman/listinfo/dots
> 
> 
> 
> --
> ----------------------------------
> Yuuhei HAYASHI
> 08065300884
> yuuhei.hayashi@gmail.com
> iehuuy_0220@docomo.ne.jp
> ----------------------------------