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

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Xialiang (Frank, Network Standard & Patent Dept)
> [mailto:[e-mail]]
> Envoyé : vendredi 12 juillet 2019 08:20
> À : BOUCADAIR Mohamed TGI/OLN; H Y
> Cc : [e-mail]; Valery
> Smyslov; [e-mail]; [e-mail]
> 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
> 
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]]
> 发送时间: 2019年7月12日 13:38
> 收件人: H Y <[e-mail]>; Xialiang (Frank, Network Standard &
> Patent Dept) <[e-mail]>
> 抄送: [e-mail]; Valery
> Smyslov <[e-mail]>; [e-mail]; neshi-nwsec-p-
> [e-mail]
> 主题: 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:[e-mail]] Envoyé : vendredi 12
> > juillet 2019 07:00 À : Xialiang (Frank, Network Standard & Patent
> > Dept) Cc : [e-mail];
> > Valery Smyslov; [e-mail]; [e-mail] 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)
> > <[e-mail]>:
> > >
> > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dots
> >
> >
> >
> > --
> > ----------------------------------
> > Yuuhei HAYASHI
> > 08065300884
> > [e-mail]
> > [e-mail]
> > ----------------------------------