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

<mohamed.boucadair@orange.com> Fri, 12 July 2019 06:27 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 9EE851203C1; Thu, 11 Jul 2019 23:27:50 -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 oSdzYl-_6gWV; Thu, 11 Jul 2019 23:27:47 -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 F35E61200E5; Thu, 11 Jul 2019 23:27:46 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 45lNJc6vq2z105p; Fri, 12 Jul 2019 08:27:44 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 45lNJc6HsBz8sY1; Fri, 12 Jul 2019 08:27:44 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM24.corporate.adroot.infra.ftgroup ([fe80::b43f:9973:861e:42af%21]) with mapi id 14.03.0439.000; Fri, 12 Jul 2019 08:27:44 +0200
From: <mohamed.boucadair@orange.com>
To: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>, H Y <yuuhei.hayashi@gmail.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+dP//m3aAgAAKoID//3AtkP/+3WUA
Date: Fri, 12 Jul 2019 06:27:44 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EACADB4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <C02846B1344F344EB4FAA6FA7AF481F13E7C878E@dggemm511-mbx.china.huawei.com> <CAA8pjUM9M1Ur5LDjFay0nH1e8=uc5+BeBW9PrD4k3GcqZOJG+w@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EACACC9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <C02846B1344F344EB4FAA6FA7AF481F13E7C88D4@dggemm511-mbx.china.huawei.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F13E7C88D4@dggemm511-mbx.china.huawei.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/CuHG8yUaILZ8QSDlKGVpULWcgUI>
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 06:27:51 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Xialiang (Frank, Network Standard & Patent Dept)
> [mailto:frank.xialiang@huawei.com]
> Envoyé : vendredi 12 juillet 2019 08:20
> À : BOUCADAIR Mohamed TGI/OLN; H Y
> Cc : draft-hayashi-dots-dms-offload-usecase.authors@ietf.org; Valery
> Smyslov; dots@ietf.org; neshi-nwsec-p-ml@hco.ntt.co.jp
> Objet : 答复: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-
> offload-usecase-01:
> 
> Hi Med,
> I understand your intention more now.
> As the chairs, we prefer to hear more to help us consider how to deal with
> this draft.
> 
> See inline:
> 
> Thank you!
> 
> B.R.
> Frank
> 
> -----邮件原件-----
> 发件人: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
> 发送时间: 2019年7月12日 13:38
> 收件人: H Y <yuuhei.hayashi@gmail.com>;; Xialiang (Frank, Network Standard &
> Patent Dept) <frank.xialiang@huawei.com>;
> 抄送: draft-hayashi-dots-dms-offload-usecase.authors@ietf.org; Valery
> Smyslov <valery@smyslov.net>;; dots@ietf.org; neshi-nwsec-p-
> ml@hco.ntt.co.jp
> 主题: RE: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-
> offload-usecase-01:
> 
> 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.
> 
> [Frank]: I mean DOTS signal channel is ok for this use case, no need to
> use call home signal channel. And the call home signal channel's
> interaction way is not appropriate for this case too.
> 

[Med] The text may not be clear. It should be fixed: the intent is to use the src-* attributes defined in the call-home, not the call-home functionality. 

> 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
> > ----------------------------------