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

"Panwei (William)" <william.panwei@huawei.com> Fri, 12 July 2019 06:41 UTC

Return-Path: <william.panwei@huawei.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 52D69120052; Thu, 11 Jul 2019 23:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 dxoCrIIzwEHQ; Thu, 11 Jul 2019 23:41:16 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA469120048; Thu, 11 Jul 2019 23:41:15 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id CBBA2CBBB9F92CF4DA32; Fri, 12 Jul 2019 07:41:13 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 12 Jul 2019 07:41:13 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.66]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Fri, 12 Jul 2019 14:36:56 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "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: AQHVOHr3Oc/8Lrt640yrc86ykd4NzKbGhvRQ
Date: Fri, 12 Jul 2019 06:36:56 +0000
Message-ID: <30E95A901DB42F44BA42D69DB20DFA6A69FAD716@nkgeml513-mbx.china.huawei.com>
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> <787AE7BB302AE849A7480A190F8B93302EACADB4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EACADB4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.37.117]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/T0MSZyLYvgPbl_lvU9bKM0ORdE0>
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:41:19 -0000

Hi Med,

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

This is also my confusion when I read the draft, it's good to be fixed.

Regards & Thanks!
潘伟 Wei Pan
华为技术有限公司 Huawei Technologies Co., Ltd.

> -----Original Message-----
> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Friday, July 12, 2019 2:28 PM
> 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; Valery
> Smyslov <valery@smyslov.net>;; dots@ietf.org; neshi-nwsec-p-
> ml@hco.ntt.co.jp
> Subject: Re: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-
> offload-usecase-01:
> 
> 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.
> >
> 
> 
> > 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
> > > ----------------------------------
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots