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

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

Re-,

You reported the following in the interim :
==
3."DOTS agents MUST NOT include 'attack-name' attribute except if the corresponding attack mapping details were not shared with the peer DOTS agent". But how can the DOTS server know they're shared or not?
===

This is implementation-specific. The DOTS server may record which version of the mapping table it shared with a DOTS client.

Do you think that we need to include such details in the spec? or do you have mind something else?

Thanks.

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: Fri, 26 Jun 2020 10:50:59 +0900

Hi Med,

Yes, it's implementation-specific.
I didn't intend to suggest a text here, but wanted to hear ideas on how others might handle it.

regards,
kaname

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 26 Jun 2020 05:15:05 +0000

Hi Med,

I don't think the capabilities of the mitigator will get updated dynamically during an active attack to send the new attack details (attack-name) in the DOTS signal channel protocol.

Cheers,
-Tiru

From: Dots <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, June 26, 2020 1:02 AM
To: kaname nishizuka <[email-masked]>
Cc: [email-masked]
Subject: [Dots] DOTS Telemetry: Interop Clarification #3

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Re-,

Thanks.

Cheers,
Med

Thank you.

---

From: <[email-masked]>
Date: Fri, 26 Jun 2020 06:03:50 +0000

Hi Tiru,

Not sure to get your comment. Can you please clarify?

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 26 juin 2020 07:15
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka
Cc : [email-masked]
Objet : RE: DOTS Telemetry: Interop Clarification #3

Hi Med,

Cheers,
-Tiru

Thanks.

Cheers,
Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 26 Jun 2020 06:36:05 +0000

I meant attack mapping details can be sent in the DOTS data channel and no need to use DOTS signal channel. The capabilities of a DOTS mitigator cannot be updated dynamically during mitigation that would warrant the need to send the attack-description in the DOTS signal channel during attack mitigation. Identifying a new attack requires update to the DOTS mitigator, human-intervention is required to create the attack description and attack-id.

In short, no need overload DOTS signal channel to send the attack description.

-Tiru

From: [email-masked] <[email-masked]>
Sent: Friday, June 26, 2020 11:34 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>; kaname nishizuka <[email-masked]>
Cc: [email-masked]
Subject: RE: DOTS Telemetry: Interop Clarification #3

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>

Hi Med,

Cheers,
-Tiru

From: Dots <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, June 26, 2020 1:02 AM
To: kaname nishizuka <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Dots] DOTS Telemetry: Interop Clarification #3

Thanks.

Cheers,
Med

Thank you.

---

From: <[email-masked]>
Date: Fri, 26 Jun 2020 07:21:07 +0000

Re-,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 26 juin 2020 08:36
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka
Cc : [email-masked]
Objet : RE: DOTS Telemetry: Interop Clarification #3

I meant attack mapping details can be sent in the DOTS data channel and no need to use DOTS signal channel.
[Med] Sure. We are not changing this behavior.

The capabilities of a DOTS mitigator cannot be updated dynamically during mitigation that would warrant the need to send the attack-description in the DOTS signal channel during attack mitigation.
[Med] The issue is when the mapping details were updated but the client didn't retrieved the up-to-date list. If an attack occurs, sending the attack-id only won't be useful for the client; hence the need to send also the attack-name if attack-details are included in the telemetry data.

Identifying a new attack requires update to the DOTS mitigator, human-intervention is required to create the attack description and attack-id.
[Med] We are not making assumptions why the mapping details are not in-sync between the client and server.

In short, no need overload DOTS signal channel to send the attack description.
[Med] As you know, the reco we have is to avoid sending attack-name in the signal channel. There are exceptions where the attack-name may be included, though.

-Tiru

Cheers,
Med

Hi Med,

Cheers,
-Tiru

Thanks.

Cheers,
Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 26 Jun 2020 07:27:15 +0000

Hi Med,

I prefer avoiding the need to send attack description in the DOTS signal channel. One way is to send the attack-id and last-update timestamp so the peer knows whether it has received the latest snapshot or not.

Cheers,
-Tiru

From: [email-masked] <[email-masked]>
Sent: Friday, June 26, 2020 12:51 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; kaname nishizuka <[email-masked]>
Cc: [email-masked]
Subject: RE: DOTS Telemetry: Interop Clarification #3

Please see inline.

Cheers,
Med

-Tiru

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Friday, June 26, 2020 11:34 AM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; kaname nishizuka <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: DOTS Telemetry: Interop Clarification #3

Cheers,
Med

Hi Med,

Cheers,
-Tiru

Thanks.

Cheers,
Med

Thank you.

---

From: <[email-masked]>
Date: Fri, 26 Jun 2020 07:52:18 +0000

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.

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.

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.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 26 juin 2020 09:27
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka
Cc : [email-masked]
Objet : RE: DOTS Telemetry: Interop Clarification #3

Hi Med,

Cheers,
-Tiru

Please see inline.

Cheers,
Med

-Tiru

Cheers,
Med

Hi Med,

Cheers,
-Tiru

Thanks.

Cheers,
Med

Thank you.

---

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

Hi All,

See inline

Regards

Jon.

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 26 June 2020 08:52
To: Konda, Tirumaleswar Reddy; kaname nishizuka
Cc: [email-masked]
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”.

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

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. 

==

==

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.

~Jon

Cheers,

Med

Hi Med,

I prefer avoiding the need to send attack description in the DOTS signal
channel. One way is to send the attack-id and last-update timestamp so the
peer knows whether it has received the latest snapshot or not.

Cheers,

-Tiru 

From: [email-masked] <[email-masked]> 
Sent: Friday, June 26, 2020 12:51 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; kaname
nishizuka <[email-masked]>
Cc: [email-masked]
Subject: RE: DOTS Telemetry: Interop Clarification #3

CAUTION: External email. Do not click links or open attachments unless you
recognize the sender and know the content is safe.

  _____  

Re-, 

Please see inline.

Cheers,

Med

I meant attack mapping details can be sent in the DOTS data channel and no
need to use DOTS signal channel.

The capabilities of a DOTS mitigator cannot be updated dynamically during
mitigation that would warrant the need to send the attack-description in the
DOTS signal channel during attack mitigation. 

[Med] The issue is when the mapping details were updated but the client
didn’t retrieved the up-to-date list. If an attack occurs, sending the
attack-id only won’t be useful for the client; hence the need to send also
the attack-name if attack-details are included in the telemetry data.  

Identifying a new attack requires update to the DOTS mitigator,
human-intervention is required to create the attack description and
attack-id.

[Med] We are not making assumptions why the mapping details are not in-sync
between the client and server.  

In short, no need overload DOTS signal channel to send the attack
description.

[Med] As you know, the reco we have is to avoid sending attack-name in the
signal channel. There are exceptions where the attack-name may be included,
though.    

-Tiru

From: [email-masked] <[email-masked]> 
Sent: Friday, June 26, 2020 11:34 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>; kaname
nishizuka <[email-masked]>
Cc: [email-masked]
Subject: RE: DOTS Telemetry: Interop Clarification #3

CAUTION: External email. Do not click links or open attachments unless you
recognize the sender and know the content is safe.

  _____  

Hi Tiru, 

Cheers,

Med

Hi Med,

I don’t think the capabilities of the mitigator will get updated dynamically
during an active attack to send the new attack details (attack-name) in the
DOTS signal channel protocol. 

Cheers,

-Tiru

From: Dots <[email-masked]> On Behalf Of
[email-masked] <mailto:[email-masked]> 
Sent: Friday, June 26, 2020 1:02 AM
To: kaname nishizuka <[email-masked]>
Cc: [email-masked]
Subject: [Dots] DOTS Telemetry: Interop Clarification #3

CAUTION: External email. Do not click links or open attachments unless you
recognize the sender and know the content is safe.

  _____  

Re-,

==

3."DOTS agents MUST NOT include 'attack-name' attribute except if the
corresponding attack mapping details were not shared with the peer DOTS
agent". But how can the DOTS server know they're shared or not?

===

This is implementation-specific. The DOTS server may record which version of
the mapping table it shared with a DOTS client. 

Do you think that we need to include such details in the spec? or do you
have mind something else?

Thanks.

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.
____________________________________________________________________________
_____________________________________________
 
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: <[email-masked]>
Date: Fri, 26 Jun 2020 11:32:39 +0000

Hi Jon,

Please see inline.

Cheers,
Med

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

Hi All,

See inline

Regards

Jon.

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

Re-,

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

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.

==

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

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 26 Jun 2020 15:24:33 +0100

Hi Med et al,

Please see inline Jon1>

Regards

Jon

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

Hi Jon,

Please see inline. 

Cheers,

Med

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

Hi All,

See inline

Regards

Jon.

Re-,

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: 

   mapping).

Jon1> Agreed.  As a side note, we do not give a PUT example which has
vendor-id= in the URL.

==

==

·         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

                                              ^^^^^^^^^^^^^^^^

   channel.”

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. 

~Jon