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

[[e-mail]]

Hi Jon,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[e-mail]]
Envoyé : vendredi 26 juin 2020 12:41
À : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; [e-mail]
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #3

Hi All,

See inline

Regards

Jon.


From: Dots [mailto: [e-mail]] On Behalf Of [e-mail]
Sent: 26 June 2020 08:52
To: Konda, Tirumaleswar Reddy; kaname nishizuka
Cc: [e-mail]
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #3

Re-,

I do agree that having a latest-update leaf in the mapping table is useful (easily detect mismatches). This is something we can add to the data channel extension.

Jon> In the attack mapping over the dots data channel I would like to see "vendor-name" and "vendor-mapping-last-updated".
[Med] Works for me as well

I'm not sure it is useful to send that new attribute in the signal channel as the attack details won' be useful in the lack of the attack description.

Jon> If a new attack-id has been created and the new attack vector is occurring, but mappings have not been refreshed, then I think that the attack-id should be used over the signal channel.  If the receiving DOTS agent is a DOTS client, it can then try to initiate the transfer of a new mapping over the data channel.
[Med] ... which will fail.

If the receiving DOTS agent is a server, then I can think of no server triggered mechanism that can be used to request the client to send a new mapping table.  However, the client should know it has a new attack-id - hence new mapping - and should initiate the sending of a new mapping.
[Med] which it needs to do anyway before an attack happens. We do already have the following:

   The DOTS client uses the PUT request to modify its vendor attack
   mapping details maintained by the DOTS server (e.g., add a new
   mapping).

Jon> Worst case is an out of band conversation to determine what this new attack-id really is.

I do think that the current wording in the draft is appropriate: (1) agents should ensure they are in sync as much as possible, (2) avoid including the attack details in the signal channel with one exception when an agent detects a synch issue.

==
   When conveying attack details in DOTS telemetry messages (Sections
   7.2, 7.3, and 8), DOTS agents MUST NOT include 'attack-name'
   attribute except if the corresponding attack mapping details were not
   shared with the peer DOTS agent.
==

If there is a message size issue, a dots agent can send the telemetry in separate messages, use the new bloc options, etc.

Jon> I am moving in the direction of attack-name/attack-description should never be used over  the signal channel.  Makes things a lot simpler.
[Med] Going that direction has many implications:

·         Mandate the data channel, which is against what we set in the arch spec:

   "As illustrated in Figure 2, there are two interfaces between a DOTS
   server and a DOTS client; a signal channel and (optionally) a data
                                              ^^^^^^^^^^^^^^^^
   channel."


·         Change the following to a MUST

   In order to optimize the size of telemetry data conveyed over the
   DOTS signal channel, DOTS agents MAY use the DOTS data channel
   [RFC8783] to exchange vendor-specific attack mapping details (that
   is, {vendor identifier, attack identifier} ==> attack description).

And so on.

The current approach in the draft accommodates all these concerns.

~Jon


_________________________________________________________________________________________________________________________

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.