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.

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