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

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Fri, 12 Jul 2019 03:08:15 +0000

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

---

From: H Y <[email-masked]>
Date: Fri, 12 Jul 2019 13:59:59 +0900

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 origin…
[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)
<[email-masked]>:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

-- 
----------------------------------
Yuuhei HAYASHI
08065300884
[email-masked]
[email-masked]
----------------------------------

---

From: <[email-masked]>
Date: Fri, 12 Jul 2019 05:38:01 +0000

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.

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

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:[email-masked]]
> Envoyé : vendredi 12 juillet 2019 07:00
> À : Xialiang (Frank, Network Standard & Patent Dept)
> Cc : [email-masked]; Valery
> Smyslov; [email-masked]; [email-masked]
> Objet : Re: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-
> offload-usecase-01:
> 
> Hi Frank,
> 
> > 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.
> > 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
> >
> >
> >

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Fri, 12 Jul 2019 06:20:15 +0000

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

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2019年7月12日 13:38
收件人: H Y <[email-masked]>; Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]>
抄送: [email-masked]; Valery Smyslov <[email-masked]>; [email-masked]; [email-masked]
主题: RE: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-offload-usecase-01:

Franck,

[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

> De : H Y [mailto:[email-masked]] Envoyé : vendredi 12 
> juillet 2019 07:00 À : Xialiang (Frank, Network Standard & Patent 
> Dept) Cc : [email-masked]; 
> Valery Smyslov; [email-masked]; [email-masked] Objet : 
> Re: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-
> offload-usecase-01:
> 
> Hi Frank,
> 
> Please see IETF104 minute 
> https://datatracker.ietf.org/doc/minutes-104-
> dots/
> 
> 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.
> 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?
> server create TLS connection with DOTS client, which I don’t think 
> it’s very suitable for your case.
> 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.
> >
> 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?
> server create TLS connection with DOTS client, which I don’t think 
> it’s very suitable for your case.
> >
> >
> >
> > Thanks!
> >
> >
> >
> > B.R.
> >
> > Frank
> >
> >
> >

---

From: <[email-masked]>
Date: Fri, 12 Jul 2019 06:27:44 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Xialiang (Frank, Network Standard & Patent Dept)
> [mailto:[email-masked]]
> Envoyé : vendredi 12 juillet 2019 08:20
> À : BOUCADAIR Mohamed TGI/OLN; H Y
> Objet : 答复: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-
> offload-usecase-01:
> 
> Hi Med,
> 抄送: [email-masked]; Valery
> Smyslov <[email-masked]>; [email-masked]; neshi-nwsec-p-
> [email-masked]
> 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.
> 
> [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.

---

From: "Panwei (William)" <[email-masked]>
Date: Fri, 12 Jul 2019 06:36:56 +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:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, July 12, 2019 2:28 PM
> To: Xialiang (Frank, Network Standard & Patent Dept)
> <[email-masked]>; H Y <[email-masked]>
> Cc: [email-masked]; Valery
> Subject: Re: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-
> offload-usecase-01:
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > Envoyé : vendredi 12 juillet 2019 08:20 À : BOUCADAIR Mohamed
> TGI/OLN;
> > H Y Cc : [email-masked];
> > 答复: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-
> > offload-usecase-01:
> >
> > Hi Med,
> > 收件人: H Y <[email-masked]>; Xialiang (Frank, Network
> Standard
> > & Patent Dept) <[email-masked]>
> > 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.
> >
> > [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
> > > Thank you for reviewing my draft :-) Please see inline.
> > >
> > > orchestrator via standardized IF and the orchestrator carries out
> > > some action in the network.
> > >
> > > 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.
> > >
> > > 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?
> > > For example, it's useful and feasible to send src port information
> > > via the DOTS signal channel to request mitigation against reflection
> > > attack.
> > >
> > > 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.
> > > 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
> > > >
> > > >
> > > >

---

From: H Y <[email-masked]>
Date: Sun, 21 Jul 2019 04:02:53 -0400

Hi all,

We updated the draft based on comments.
I replaced the previous draft.

>Frank, William
Thank you for reviewing my draft!

> Med
Thank you for revising my draft!

A new version of I-D, draft-hayashi-dots-dms-offload-00.txt
has been successfully submitted by Yuhei Hayashi and posted to the
IETF repository.

Name:           draft-hayashi-dots-dms-offload
Revision:       00
Title:          DDoS Mitigation Offload: DOTS Applicability and
Deployment Considerations
Document date:  2019-07-20
Group:          Individual Submission
Pages:          20
URL:
https://www.ietf.org/internet-drafts/draft-hayashi-dots-dms-offload-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hayashi-dots-dms-offload/
Htmlized:       https://tools.ietf.org/html/draft-hayashi-dots-dms-offload-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-hayashi-dots-dms-offload

Abstract:
   This document describes a deployment scenario to assess the
   applicability of DOTS protocols together with a discussion on DOTS
   deployment considerations of such scenario.  This scenario assumes
   that a DMS (DDoS Mitigation System) whose utilization rate is high
   sends its blocked traffic information to an orchestrator using DOTS
   protocols, then the orchestrator requests forwarding nodes such as
   routers to filter the traffic.  Doing so enables service providers to
   mitigate the DDoS attack traffic automatically while ensuring
   interoperability and distributed filter enforcement.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

2019年7月12日(金) 2:41 Panwei (William) <[email-masked]>:
> > > > since
> > > > > since

---

From: "Meiling Chen" <[email-masked]>
Date: Wed, 24 Jul 2019 11:48:08 +0800

Hi yuuhei,
I have read your latest draft draft-hayashi-dots-dms-offload-00, I have a question:
In the figure 3, In-band case: 
Attack Time                       | Attack Time      |
  |             | Method : Signal Channel           | Method : Signal  |
  |             |          Control Filtering        |          Channel |
  |             | Info : ACL name                   | Control Filtering|
  |             |                                   | Info : ACL name
what's your mean of ACL name, can you give an example?
if the ACL strategy installed, you have to consider the process of uninstall.

during your draft of section 5, you said 
What type of information can
   be conveyed by DMS relays on attack type detected by the DMS:
we also think attack type is really important, so we want to unify the attack type and this will benefit for mitigation coroperation.

Best Regards.
Meiling Chen.
From: H Y
Date: 2019-07-21 16:02
To: [email-masked]
CC: [email-masked]; [email-masked]
Subject: Re: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-offload-usecase-01:
Hi all,

 

Abstract:

 
 
The IETF Secretariat

---

From: H Y <[email-masked]>
Date: Wed, 24 Jul 2019 05:58:15 -0400

Hi Meiling,

Thank you for reading my draft.
Please see inline.

> what's your mean of ACL name, can you give an example?
[hayashi] The example is written in  5.2.3. Data Channel and Signal
Channel Controlling Filtering. The strategy is that the DOTS client
registers ACL against well-known attack to DOTS server in peace time,
and the DOTS client under attack activates the ACL using
control-filtering based on a detection result of DMS.

> if the ACL strategy installed, you have to consider the process of uninstall.
[hayashi] Thank you for comments. I will consider it.

> we also think attack type is really important, so we want to unify the attack type and this will benefit for mitigation coroperation.
[hayashi] If the orchestrator just has to filter attack at routers to
offload DMS after receiving mitigation request from the DMS, attack
type is not needed. However, if the orchestrator has to carry out
optimized action based on attack type, the attack type is important
attribute.
For example...
- Filtering attack traffic at router against L3-L4 attack.
- Steering attack traffic to security appliance against L7 attack.
I would like to discuss it.

Thanks,
Yuhei