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

Jon Shallow <supjps-ietf@jpshallow.com> Mon, 29 June 2020 11:41 UTC

Return-Path: <supjps-ietf@jpshallow.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 49C6D3A0E1A for <dots@ietfa.amsl.com>; Mon, 29 Jun 2020 04:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 sgmoeYHmyIPP for <dots@ietfa.amsl.com>; Mon, 29 Jun 2020 04:41:37 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325FB3A0E12 for <dots@ietf.org>; Mon, 29 Jun 2020 04:41:34 -0700 (PDT)
Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1jpsAE-00047t-7b; Mon, 29 Jun 2020 12:41:30 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: mohamed.boucadair@orange.com, kaname nishizuka <kaname@nttv6.jp>, dots@ietf.org
References: <25679_1593113350_5EF4FB06_25679_457_1_787AE7BB302AE849A7480A190F8B9330314E762D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <084a01d64bb2$d63a86b0$82af9410$@jpshallow.com> <9226_1593412702_5EF98C5E_9226_29_1_787AE7BB302AE849A7480A190F8B9330314E8989@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0ad501d64df5$74b89b30$5e29d190$@jpshallow.com> <16374_1593427492_5EF9C624_16374_188_1_787AE7BB302AE849A7480A190F8B9330314E8BF2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <16374_1593427492_5EF9C624_16374_188_1_787AE7BB302AE849A7480A190F8B9330314E8BF2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Mon, 29 Jun 2020 12:41:22 +0100
Message-ID: <0b1401d64e0a$36c332d0$a4499870$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B15_01D64E12.98892170"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH0NBewyz0cz3gVN6O99zZ2D4scewEFmq9oAkUV0A4B4ImsbALKkiyFqHP409A=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/svsa4Oi6AgaaOS7-qGStX1P5jlc>
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 11:41:40 -0000

Hi Med,

 

I’m still confused – could be that we are talking cross purposes here.

 

See inline Jon>

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of
mohamed.boucadair@orange.com
Sent: 29 June 2020 11:45
To: Jon Shallow; kaname nishizuka; dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Jon, 

 

It is the other way around: the server will filter out the data it will
return to match the filters conveyed in GET.

Jon> That filtering I agree with.  It just is what is the data source used
for the server GET response.

 

So, 

·         if we refer to your case (1), the PUT used for efficacy update
does not interfere with the handling of GET to retrieve the server’s status.

Jon> Figure 45 PUT includes

           "ietf-dots-telemetry:total-attack-traffic": [

             {

               "ietf-dots-telemetry:unit": "megabit-ps",

               "ietf-dots-telemetry:mid-percentile-g": "900"

             }

           ]

Jon>  What does the DOTS server respond with for a GET – the value “900
megabit-ps” or what the DOTS server (as told by DOTS mitigator etc.) thinks
is actually happening – e.g. “11 gigabit-ps” because a lot of attack traffic
is being dropped by the DOTS mitigators?  Just to be absolutely sure – the
server is getting its status from multiple sources – which status does it
report on in the GET.

·         if we refer to your case (2), the PUT in Figure 36 sets the target
(telemetry) scope. So for any telemetry-related GET, the server will only
return data that is bound to the target as set in the PUT. These data is
further filtered out based of any uri-query in the GET. 

Jon> Figure 36 PUT goes beyond defining the target (alias-name in this case)
and includes

           "attack-detail": [

             {

               "vendor-id": 1234,

               "attack-id": 77,

               "start-time": "1957811234",

               "attack-severity": "high"

             }

           ]

Jon> So what is returned in the GET for this target – this attack detail or
the attack detail that the DOTS server is being told by the DOTS mitigators
– which could include the same vendor-id + attack-id (but maybe with a
different start time)?

~Jon   

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] 
Envoyé : lundi 29 juin 2020 11:13
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Med,

 

So for absolute clarity, the DOTS server will return the values it has
internally determined (from DOTS mitigator etc.), not those provided by the
DOTS client using a PUT, as modified by the GET Query filters.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of
mohamed.boucadair@orange.com
Sent: 29 June 2020 07:38
To: Jon Shallow; kaname nishizuka; dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Jon, all,

 

The server will return the data that match the filters included in the GET
that triggered the response. 

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] 
Envoyé : vendredi 26 juin 2020 14:11
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

 

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.
____________________________________________________________________________
_____________________________________________
 
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.
____________________________________________________________________________
_____________________________________________
 
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.