Re: [Dots] Telemetry draft: Vendor Specific data reduction

[Jon Shallow <[e-mail]>]

Hi Med,

 

I was not thinking of dropping attack-name.  I was more thinking of
uploading / downloading as appropriate the entire list of
id->attack-id<->attack-name.  The attack-id<->attack-name list will evolve
over time so there will need to be a mechanism of doing updates, or
signalling that there are new attack-id in use.

 

However, the first time that an attack-id is used, the attack-name can also
be included.  Two immediate issues that come to mind are 

“What happens if the telemetry information packet that contains the
attack-name gets lost in transit”

“If a major attack kicks off with many vectors, all of the attack-ids for
the first time, there will be a lot of traffic”

 

Regards

 

Jon

 

From: Dots [mailto: [e-mail]] On Behalf Of
[e-mail]
Sent: 28 April 2020 16:57
To: Jon Shallow; [e-mail]
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction

 

Re-, 

 

If attack-name is completely removed for the attack-details, this means the
remote peer can’t make use of the information till the list is refreshed. 

 

Isn’t better to maintain the attribute as in the current design but an agent
uses this attribute only for new attacks? 

 

Cheers,

Med

 

De : Jon Shallow [mailto:[e-mail]] 
Envoyé : mardi 28 avril 2020 17:16
À : BOUCADAIR Mohamed TGI/OLN; [e-mail]
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction

 

Hi Med,

 

To give an example for “attack-id” and “attack-name” the DDOS Mitigator that
I work with has several components that identify the same attack

 

Index: 3016

Short-Name: tcpattack_synflood

Descriptive-Name: “TCP Attack - Syn Flood"

 

And in the code I was using the index for “attack-id” and the
Descriptive-Name for the “attack-name” for the recent telemetry Interop with
Kaname.

 

With a multi-vector attack, the descriptive name information was a
substantive part of the telemetry information being passed back to the
client.

 

Similarly, if the DDoS Mitigator was to act as a client to an upstream DOTS
server (which in my case it can), then again there is a lot of information
being relayed that could be reduced with a mapping between” attack-id” and
“attack-name” for a specific vendor “id” being uploaded ahead of time – and
can be refreshed if new attacks are discovered and mitigated.

 

Regards

 

Jon

 

From: Dots [mailto: [e-mail]] On Behalf Of
[e-mail]
Sent: 28 April 2020 12:00
To: Jon Shallow; [e-mail]
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction

 

Hi Jon,

 

Apologies for the delay to follow on this one. 

 

attack-name is more about a description than a name. This field may also be
used to map attack details from distinct vendors because there is no a
global registry (and we don’t want to create one). 

 

Having the ability to retrieve a list prior to an attack is interesting to
consider but the (optional) attribute may still be needed to be included for
new attack types. 

 

Note that the name attribute is also used by a DOTS client to send telemetry
to a DOTS server. 

 

Attack-id is defined as a string because we inspired from existing event
notification formats. Some of these formats allow for an even ID to be
integer or string. 

 

Cheers,

Med

 

De : Dots [mailto:[e-mail]] De la part de Jon Shallow
Envoyé : mardi 28 avril 2020 10:29
À : [e-mail]
Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduction

 

Hi All,

 

Any thoughts on this data reduction?

 

While it is possible for a Vendor to come up with their own augmented YANG
to cover their vendor specifics, it gets problematic when 2 or more Vendor
specifics need to be understood by a client or a server.

 

Having a “/vendor-mapping” operation path means that vendor mapping of
“attack-id” and “attack-name” can easily be exchanged.

 

If “attack-id” is an integer instead of a string, then “attack-id” could
become a Vendor specific set of enums (they do not need to start from 1)
based on “id”.

 

Regards

 

Jon

 

From: Dots [mailto: [e-mail]] On Behalf Of Jon Shallow
Sent: 23 April 2020 10:49
To: [e-mail]
Subject: [Dots] Telemetry draft: Vendor Specific data reduction

 

Hi All,

 

When passing telemetry attack information back and forth, there are some
ways that we need to consider on data reduction, thus reducing the
likelihood of having to do Block transfers.

 

My understanding is that there is a one-to-one relationship between
“attack-id” and “attack-name”.

 

My first suggestion is that the client is able to upload to a server, and
the server can download on request, a vendor’s mapping of “attack-id” to
“attack-name” for the specific vendor “id”.  Then, whenever there is
telemetry information ”id” + “attack-id” need to be provided, but much space
can be saved by not having to also include “attack-name”.

 

Second suggestion is that “attack-id” is an integer instead of a string to
again save on space in the telemetry data.

 

Regards

 

Jon