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

[[e-mail]]

Hi all,

The conclusion for this one is that no change is required.

Please speak up if you disagree. Thank you.

Cheers,
Med

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

Hi Med et al,

Please see inline Jon1>

Regards

Jon

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

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.
Jon1> Yes - if we are into pipe losses and data channel fails to work.  However, the likelihood is that the lossy pipe is inbound, so then the client will never see the packet containing the new attack-id.  I still think that if the DOTS client sees an unrecognized attack-id it should try to get the latest mappings.

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.
Jon1> It is possible that an attack is under way, someone does some analysis and either comes up with a new attack-id to describe what is going on or does a code update and then sends the new mapping - the attack has not ceased....

[Med] 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).
Jon1> Agreed.  As a side note, we do not give a PUT example which has vendor-id= in the URL.

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

Jon1> I had forgotten that the data channel was optional.  Sending the vendor mapping over the signal channel could be done - most likely has to be in peace time unless we can use the new block options.  My vendor mapping takes about 10k bytes.
~Jon1

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.