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

From: <[email-masked]>
Date: Thu, 25 Jun 2020 19:29:09 +0000

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.

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 26 Jun 2020 13:10:52 +0100

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: [email-masked]] On Behalf Of
[email-masked]
Sent: 25 June 2020 20:29
To: kaname nishizuka
Cc: [email-masked]
Subject: [Dots] DOTS Telemetry: Interop Clarification #1

Hi Kaname, 

==

Current Uri-Path can't distinguish telemetry resources posted by the client
or created by the server.

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.

---

From: kaname nishizuka <[email-masked]>
Date: Mon, 29 Jun 2020 11:08:26 +0900

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:
> 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: [email-masked]] *On Behalf Of [email-masked]
> *Sent:* 25 June 2020 20:29
> *To:* kaname nishizuka
> *Cc:* [email-masked]
> *Subject:* [Dots] DOTS Telemetry: Interop Clarification #1
>
> Hi Kaname,
>
> –Those are totally different resources.
>

---

From: <[email-masked]>
Date: Mon, 29 Jun 2020 06:38:21 +0000

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:[email-masked]]
Envoyé : vendredi 26 juin 2020 14:11
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; [email-masked]
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

Hi Med,

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: [email-masked]] On Behalf Of [email-masked]
Sent: 25 June 2020 20:29
To: kaname nishizuka
Cc: [email-masked]
Subject: [Dots] DOTS Telemetry: Interop Clarification #1

Hi Kaname,

==

Thank you

Cheers,
Med

Thank you.

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 29 Jun 2020 10:12:47 +0100

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: [email-masked]] On Behalf Of
[email-masked]
Sent: 29 June 2020 07:38
To: Jon Shallow; kaname nishizuka; [email-masked]
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

Hi Med,

does a GET against the same resource – what is returned – the last efficacy

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

Hi Kaname, 

==

==

Thank you 

Cheers,

Med

---

From: <[email-masked]>
Date: Mon, 29 Jun 2020 10:44:51 +0000

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.

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.

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

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 29 juin 2020 11:13
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; [email-masked]
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

Hi Jon, all,

Cheers,
Med

Hi Med,

Regards

Jon

Hi Kaname,

==

Thank you

Cheers,
Med

Thank you.

Thank you.

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 29 Jun 2020 12:41:22 +0100

Hi Med,

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

See inline Jon>

Regards

Jon

Sent: 29 June 2020 11:45

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

Hi Med,

Regards

Jon

Hi Jon, all,

Cheers,

Med

Hi Med,

Regards

Jon

Hi Kaname, 

==

==

Thank you 

Cheers,

Med

a l'expediteur et le detruire ainsi que les pieces jointes.. Les messages

a l'expediteur et le detruire ainsi que les pieces jointes.. Les messages

---

From: <[email-masked]>
Date: Mon, 29 Jun 2020 12:20:38 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 29 juin 2020 13:41
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; [email-masked]
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

Hi Med,

I'm still confused - could be that we are talking cross purposes here.

See inline Jon>

Regards

Jon

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.
[Med] OK.
  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.
[Med] The server will report the status it is seeing (reported from mitigators), not the one inferred from the efficacy update from the client. We are not changing the behavior we have in the base spec.

·         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)?
[Med] Like above, the status that will be reported is the one from mitigators.

~Jon

Cheers,
Med

Hi Med,

Regards

Jon

Hi Jon, all,

Cheers,
Med

Hi Med,

Regards

Jon

Hi Kaname,

==

Thank you

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 29 Jun 2020 15:31:18 +0100

Hi Med,

I think that it is worth adding a note for clarity such as

OLD

     Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry

                     Notification from the DOTS Server

NEW

     Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry

                     Notification from the DOTS Server

Note: Any information uploaded by a PUT (see Figure 36) will not be included
in such a response.

END

and

OLD

    Figure 45: An Example of Mitigation Efficacy Update with Telemetry

                                Attributes

NEW

    Figure 45: An Example of Mitigation Efficacy Update with Telemetry

                                Attributes

Note: Any information retrieved by a GET command for this ‘mid’ will not
include any efficacy update information.

END

Regards

Jon

Sent: 29 June 2020 13:21

Re-, 

Please see inline. 

Cheers,

Med

Hi Med,

See inline Jon>

Regards

Jon

Hi Jon, 

[Med] OK.

So, 

             {

             }

           ]

[Med] The server will report the status it is seeing (reported from
mitigators), not the one inferred from the efficacy update from the client.
We are not changing the behavior we have in the base spec. 

           "attack-detail": [

             {

               "vendor-id": 1234,

               "attack-id": 77,

             }

           ]

[Med] Like above, the status that will be reported is the one from
mitigators.   

~Jon   

Cheers,

Med

Hi Med,

Regards

Jon

Hi Jon, all,

Cheers,

Med

Hi Med,

Regards

Jon

Hi Kaname, 

==

==

Thank you 

Cheers,

Med

---

From: <[email-masked]>
Date: Tue, 30 Jun 2020 05:35:16 +0000

Hi Jon,

We can't say "will not include any efficacy update information" because the efficacy update includes also the mitigation scope that is returned by the server. The server treats the supplied telemetry data as a hint; this is the same way it handles "attack-status" from the client. Also, we do have the following:

   DOTS clients can send mitigation hints derived from attack details to
   DOTS servers, with the full understanding that the DOTS server may
   ignore mitigation hints

Please note that the efficacy update is clearly indicated as a refresh of the mitigation request in RFC8782. We can add a reminder if needed.

I suspect that what confused you is the use of the same "tmid" in Figure 43 and Figure 36. I changed Figures 39-43 to use a new value "567".

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 29 juin 2020 16:31
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; [email-masked]
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

Hi Med,

OLD

Note: Any information uploaded by a PUT (see Figure 36) will not be included in such a response.
END

and

OLD

Note: Any information retrieved by a GET command for this 'mid' will not include any efficacy update information.
END

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

See inline Jon>

Regards

Jon

Hi Jon,

So,

~Jon

Cheers,
Med

Hi Med,

Regards

Jon

Hi Jon, all,

Cheers,
Med

Hi Med,

Regards

Jon

Hi Kaname,

==

Thank you

Cheers,
Med