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