Re: [Dots] DOTS Telemetry: Interop Clarification #1

kaname nishizuka <kaname@nttv6.jp> Mon, 29 June 2020 02:08 UTC

Return-Path: <kaname@nttv6.jp>
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 1AFB43A1028 for <dots@ietfa.amsl.com>; Sun, 28 Jun 2020 19:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nttv6.jp
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 jbPWNqhNRycd for <dots@ietfa.amsl.com>; Sun, 28 Jun 2020 19:08:29 -0700 (PDT)
Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 105F73A1015 for <dots@ietf.org>; Sun, 28 Jun 2020 19:08:28 -0700 (PDT)
Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id E152825F6BB; Mon, 29 Jun 2020 11:08:26 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1593396506; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=flOdKasStvBzBoQlvFkNyiWxBd4Cp6G+v+up7KdcYxc=; b=DhGQ/1CUaJjHYRzY7xlAIFUYzrCnRZQ8WblOrpGgmxzkUiLHKdgKRAGjXEakiea2qJR0o8 e8Egwcnvm7464dtR/koDfsyIWrXy7aoVDxt8QYeeQrvDEv1vdbRhZrJFWG8JcMczIalVKj 1MrHDzfxl0QCk1Fq9iyc7TLSusgsQp8=
Received: from UG023-kaname.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id AB81175900F; Mon, 29 Jun 2020 11:08:26 +0900 (JST)
To: Jon Shallow <supjps-ietf@jpshallow.com>, mohamed.boucadair@orange.com, dots@ietf.org
References: <25679_1593113350_5EF4FB06_25679_457_1_787AE7BB302AE849A7480A190F8B9330314E762D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <084a01d64bb2$d63a86b0$82af9410$@jpshallow.com>
From: kaname nishizuka <kaname@nttv6.jp>
Message-ID: <1a429aca-5e63-188d-5d44-148fc6b38ee2@nttv6.jp>
Date: Mon, 29 Jun 2020 11:08:26 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <084a01d64bb2$d63a86b0$82af9410$@jpshallow.com>
Content-Type: multipart/alternative; boundary="------------6636C5370BF848CBABB2432D"
Content-Language: en-US
Authentication-Results: guri.nttv6.jp; spf=pass smtp.mailfrom=kaname@nttv6.jp
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Km4zVQtx8qgp4ykve40Jiy7qqpE>
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1
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: Mon, 29 Jun 2020 02:08:31 -0000

Hi Med, Jon,

Thanks for describing the issue, Jon.

One way is separating the URI-path for "the client's PUT/GET" and "GET for the values seen by the DOTS server".

The other way is treating Total Traffic/Attack Details telemetry data by the DOTS client PUT as a hint which will not be stored in the DOTS server.
However, in that situation, the DOTS client DELETE will mean nothing.

regards,
Kaname

On 2020/06/26 21:10, Jon Shallow wrote:
>
> Hi Med,
>
> I think that this refers several places.
>
> 1.Efficacy updates.  E.g.  Figure 45: An Example of Mitigation Efficacy Update with Telemetry Attributes. Here we do an efficacy update of what the client is seeing happen to a specific resource.  If the client now does a GET against the same resource – what is returned – the last efficacy update or the current state of mitigation as seen by the DOTS server?
>
> 2.Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry allows the client to update the tmid with some information.  This includes an attack-detail.  When the client wants to see what is happening with this “tmid”, it does a Figure 40: GET to Subscribe to Telemetry Asynchronous Notifications for a Specific 'tmid'.  Which attack-detail is returned – the one from the PUT or the ongoing situation?
>
> Regards
>
> Jon
>
> *From:*Dots [mailto: dots-bounces@ietf.org] *On Behalf Of *mohamed.boucadair@orange.com
> *Sent:* 25 June 2020 20:29
> *To:* kaname nishizuka
> *Cc:* dots@ietf.org
> *Subject:* [Dots] DOTS Telemetry: Interop Clarification #1
>
> Hi Kaname,
>
> We discussed this issue in the interim:
>
> ==
>
> Current Uri-Path can't distinguish telemetry resources posted by the client or created by the server.
>
> –Those are totally different resources.
>
> For example, Uri-Query won't be applicable to the telemetry resources posted by the client.
>
> ==
>
> Can you please identify precisely which parts of the text need to be updated?
>
> Thank you
>
> Cheers,
>
> Med
>
> _________________________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.