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

[Jon Shallow <[e-mail]>]

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

 

 

From: Dots [mailto: [e-mail]] On Behalf Of
[e-mail]
Sent: 29 June 2020 13:21
To: Jon Shallow; kaname nishizuka; [e-mail]
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1

 

Re-, 

 

Please see inline. 

 

Cheers,

Med

 

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

 

From: Dots [mailto: [e-mail]] On Behalf Of
[e-mail]
Sent: 29 June 2020 11:45
To: Jon Shallow; kaname nishizuka; [e-mail]
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.

[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

 

De : Jon Shallow [mailto:[e-mail]] 
Envoyé : lundi 29 juin 2020 11:13
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; [e-mail]
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: [e-mail]] On Behalf Of
[e-mail]
Sent: 29 June 2020 07:38
To: Jon Shallow; kaname nishizuka; [e-mail]
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:[e-mail]] 
Envoyé : vendredi 26 juin 2020 14:11
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; [e-mail]
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: [e-mail]] On Behalf Of
[e-mail]
Sent: 25 June 2020 20:29
To: kaname nishizuka
Cc: [e-mail]
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.