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

H Y <yuuhei.hayashi@gmail.com> Fri, 12 July 2019 05:01 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 61A9D1200F8; Thu, 11 Jul 2019 22:01:37 -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 0EvaI_m4GQow; Thu, 11 Jul 2019 22:01:35 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 D5AEC120077; Thu, 11 Jul 2019 22:01:31 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id q26so5566903lfc.3; Thu, 11 Jul 2019 22:01:31 -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=0DYwilipjCBnjpvDUnx7wkEQkZMsx4vKG/lw+j2pEZY=; b=rxWjv1Jl6+urOAPUAn3tnQUNOYvL1AX9xGGnQVdGqHaNtyLikYT48/chfqEh6HCEEi NIbuwyVEcAlpFV0DTzX3dIk6+klDshiJJXaO1ZHx1rMUYAD+4EB/FAiNapDKluerxflv cIHqj2AuewrGtSvDqprN6GUD5vFKCXzVytgYB+zR36T57DTkT7C0fECAbnezUS+dHUTz BlgvoFroXlGmPZFL1pUV7UFmD5Uzyw7D+bdiKUt+vy4FPdfSaY70e9q+EnrlFSfL3r4v J69Q/adZt/5hI5sGytOYN16RlIU6thp/ibytEQPRtr5J5ViYZdCNwbgoT3wz14+SKqaH 0lJA==
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=0DYwilipjCBnjpvDUnx7wkEQkZMsx4vKG/lw+j2pEZY=; b=fdiUm4KhMcwx3xzrs+ZVwtWyIOtZAUB07LE+ylyhpeNrHY9Q5cLl4PkOtYiATgcYxN JUIta1wRZ+H3GW3w5BbDPpTfWIGw9sJKscY4d3fLV8nHwH9XzdaDd8g8FT+q6cfiaaOG y5WW6yEADjViw5rIse0KaocGYawPYhO9s0p8VFJkeV8eKAzKTZGJ6D/myPkNmQWybu3a DDDcEGvK9fV5YGasCls/GuUS63LsgF7CEn1MSh0ml6FhKWHsywQH3icHeX9qFloEimBf +ZH+1o3vcbxefQ7ZRGwVRm1AupRP48ZtRXR4NkhPPC60FpqQFuNXMv7EDyHZCQiz7rl+ M+uA==
X-Gm-Message-State: APjAAAUIfBrJmebmH/fPAgtsVlnZ96e1/4rkm2ZW4heckWNLYCAaS6rY R1I7b7eVxIGKxQLNiY9+DBYyUHmhBsuWa8l4qmA=
X-Google-Smtp-Source: APXvYqzhlAiA8pazudYFm/nKes3xpUhU4tO94trMT37fRxzs06k8i9aXpCmaqJndWvtx4wJUIEfkU9FArUrQrSzAc5U=
X-Received: by 2002:a19:ed07:: with SMTP id y7mr3850211lfy.56.1562907690033; Thu, 11 Jul 2019 22:01:30 -0700 (PDT)
MIME-Version: 1.0
References: <C02846B1344F344EB4FAA6FA7AF481F13E7C878E@dggemm511-mbx.china.huawei.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F13E7C878E@dggemm511-mbx.china.huawei.com>
From: H Y <yuuhei.hayashi@gmail.com>
Date: Fri, 12 Jul 2019 13:59:59 +0900
Message-ID: <CAA8pjUM9M1Ur5LDjFay0nH1e8=uc5+BeBW9PrD4k3GcqZOJG+w@mail.gmail.com>
To: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
Cc: "draft-hayashi-dots-dms-offload-usecase.authors@ietf.org" <draft-hayashi-dots-dms-offload-usecase.authors@ietf.org>, Valery Smyslov <valery@smyslov.net>, "dots@ietf.org" <dots@ietf.org>, 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/b_jPUQVYF1-mO9-rpN3yRcXWwFE>
Subject: Re: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-offload-usecase-01:
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 05:01:38 -0000

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