Re: [Dots] we can consider update current DOTS use cases draft to reflect your case://答复: Hi, authors, 3 questions on draft-hayashi-dots-dms-offload-usecase-01:

H Y <yuuhei.hayashi@gmail.com> Fri, 12 July 2019 07:57 UTC

Return-Path: <yuuhei.hayashi@gmail.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B920C120128; Fri, 12 Jul 2019 00:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.703
X-Spam-Level:
X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TE_trD_fga3N; Fri, 12 Jul 2019 00:57:05 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5DA120096; Fri, 12 Jul 2019 00:57:04 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id q26so5839758lfc.3; Fri, 12 Jul 2019 00:57:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Q70LDuykITnWyLhlrgsXoSsBYHwCxzc/dnIbAAVgG2o=; b=ttuJ0kwNh1EbgX6J00A9tkN4lB45g15kydT1iBXbXLCJ5PkQxo0xrCtacaAaY3qVCX TX67hNSlqT6olQrjfeHMsbp5TbDz5z43sAOBTPdxeNLpf1vmFtBKU907dJnN8SuFnHvE tv5rcdlcmgR+QfUVchTNN4U1IudtISWWN5HyirOen3uSOYeCZouCFr0fQu170qcyQNvM eMn36Lm+bdVxooBFtKflVAKjpWejosah54J+RrrKUC26ZD7jj6VMbqGp7q6DNyObpksf 4VRvkUTKMcJ5GS9LHkoduwo77rarJKs3ihuzmNttKuWnlVWP6sqr8pfZY8rCN6SL5aHy 4x9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Q70LDuykITnWyLhlrgsXoSsBYHwCxzc/dnIbAAVgG2o=; b=QJrvcLazJs5NjTFREdkgtMhfxje5gY0JvUgWF+nGymi484saNCN9MEcEmoFiWRJDrS /jgIXUcgUwHyv6IsOiKz4+I2d7IuA7oa6/d39FQbwvKQJwPnaj8ubB89WuXVsRdWxFz9 b6MYLs1OXzhFLGctoC3Bq03GRXNZr9UnXWvXS72BLIguz5ebwLSYkuqE5THv+Wy1WveJ J8h1ALgHYLxYFtJ4wQmrxfdr1pE54Wm9rQUXLsJaJ2pHzWi0zTLguOMhQthE/gkxG6Y0 X+Dfoqd1AAcgmZRGiKOnucvLvWYNgtX16+uyZ9oNjLdLcmEuCdroUOIFRcANmdE1rt7x xYlw==
X-Gm-Message-State: APjAAAVUC6Ciy6ayWDHbMmPsOxbn59/T5jEH9yEtCv30LTkyK8AB8GX1 aK+tgUWjzQLTO0zn/pBhu1bqPnBAJu3fDxlNlzuhZJBu9og=
X-Google-Smtp-Source: APXvYqyrjHijI3ddg0K4GosViJktB/AH/ExmMKiEmyVXgHEH0kouUJYEV6aJNl1xMNzyXrn5bX4FN4gRztnH6PWwYQA=
X-Received: by 2002:a19:550f:: with SMTP id n15mr4098537lfe.34.1562918222573; Fri, 12 Jul 2019 00:57:02 -0700 (PDT)
MIME-Version: 1.0
References: <C02846B1344F344EB4FAA6FA7AF481F13E7C88B2@dggemm511-mbx.china.huawei.com> <CAA8pjUMegj1npZ+hfEcugb++P822e3B_b_OpLfkxO_77QpTaeA@mail.gmail.com>
In-Reply-To: <CAA8pjUMegj1npZ+hfEcugb++P822e3B_b_OpLfkxO_77QpTaeA@mail.gmail.com>
From: H Y <yuuhei.hayashi@gmail.com>
Date: Fri, 12 Jul 2019 16:55:31 +0900
Message-ID: <CAA8pjUMHhZs3i-av0tR1K15Z1TdgKGHeLwUMUu76jQBJ62RMHQ@mail.gmail.com>
To: draft-ietf-dots-use-cases@ietf.org
Cc: "draft-hayashi-dots-dms-offload-usecase.authors@ietf.org" <draft-hayashi-dots-dms-offload-usecase.authors@ietf.org>, "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>, Valery Smyslov <valery@smyslov.net>, "dots@ietf.org" <dots@ietf.org>, "neshi-nwsec-p-ml@hco.ntt.co.jp" <neshi-nwsec-p-ml@hco.ntt.co.jp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/kl1_LhbQEE6ESPkY8zaNVZKSxwY>
Subject: Re: [Dots] =?utf-8?q?we_can_consider_update_current_DOTS_use_cases_d?= =?utf-8?b?cmFmdCB0byByZWZsZWN0IHlvdXIgY2FzZTovL+etlOWkjTogSGksIGF1dGhv?= =?utf-8?q?rs=2C_3_questions_on_draft-hayashi-dots-dms-offload-usecase-01?= =?utf-8?q?=3A?=
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2019 07:57:08 -0000

Hi use cases WG draft authors,

I'm Yuhei, author of draft-hayashi-dots-dms-offload-usecase which is
an variant of DOTS Orchestration use case.
The summary of the draft is as below.
- DMS has DOTS client function and Orchestrator has DOTS server fucntion.
- DMS sends blocked or detected traffic information to the
orchestrator via DOTS protocol.

IMO, it's effective that DMSs send blocked traffic information to an
orchestrator via standardized IF, and the orchestrator carries out
some action in the network such as the DMS offload use case.

So I would like to minor-change and improve Section 3.3 in the current
use case WG.
Is there any problem?
If it is no problem, I would like to make amendments asap.

I'm glad if you give me a comment.

Thanks,
Yuhei

2019年7月12日(金) 16:03 H Y <yuuhei.hayashi@gmail.com>;:
>
> Hi Frank,
>
> Please see inline.
>
> 2019年7月12日(金) 15:15 Xialiang (Frank, Network Standard & Patent Dept)
> <frank.xialiang@huawei.com>;:
> >
> > Hi Yuhei,
> > Thanks for quick and clear clarification.
> >
> > See inline:
> >
> > And in summary from my side, the only thing we may need to do according to your proposal is to update the DOTS use cases draft to reflect your new case: " It's effective that DMS have DOTS client function in DOTS orchestration use case ".
> > But we welcome more discussions.
> [hayashi]
> Thanks. I would like to contact use case authors asap.
> And I would like to discuss more at IETF 105.
>
> >
> > B.R.
> > Frank
> >
> > -----邮件原件-----
> > 发件人: H Y [mailto:yuuhei.hayashi@gmail.com]
> > 发送时间: 2019年7月12日 13:00
> > 收件人: 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:
> >
> > 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/
> >
> > [Frank]: So, I suggest you to contact with DOTS use cases draft authors about this proposal asap, since it's in the AD Evaluation status and I think your improvement is just a minor part.
> [hayashi]
> Thank you for giving me advice.
> I would like to do so.
>
> >
> > > 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.
> >
> > [Frank]: sending acl filtering rules via DOTS data channel is ok.
> [hayashi]
> Thanks.
>
> >
> > > 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.
> >
> > [Frank]: this is not excluded in current DOTS architecture, just lack of clear text of this point. You can discuss this point with use cases draft authors.
> [hayashi]
> OK.
>
> >
> > - 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.
> >
> > [Frank]: DOTS signal channel call home draft has already specified it. No more needs to be done.
> [hayashi]
> OK.
>
> >
> > > 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?
> >
> > [Frank]: I think it's not necessary. You can see my discussion with Med about the same thing just now in: https://mailarchive.ietf.org/arch/msg/dots/hRd3BRTUjXx5roIS2jJ6UXzTny4
> [hayashi]
> OK.
>
> Thanks,
> Yuhei
>
> >
> > 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
>
>
>
> --
> ----------------------------------
> Yuuhei HAYASHI
> 08065300884
> yuuhei.hayashi@gmail.com
> iehuuy_0220@docomo.ne.jp
> ----------------------------------



-- 
----------------------------------
Yuuhei HAYASHI
08065300884
yuuhei.hayashi@gmail.com
iehuuy_0220@docomo.ne.jp
----------------------------------