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

[Jon Shallow <[e-mail]>]

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.