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

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