Re: [Dots] Telemetry draft: Vendor Specific data reduction Tue, 28 April 2020 11:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 761BD3A134B for <>; Tue, 28 Apr 2020 04:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yhv__KDgfNWz for <>; Tue, 28 Apr 2020 04:00:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B438B3A1349 for <>; Tue, 28 Apr 2020 04:00:25 -0700 (PDT)
Received: from (unknown [xx.xx.xx.65]) by (ESMTP service) with ESMTP id 49BJZw0yKrz10Cw; Tue, 28 Apr 2020 13:00:24 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1588071624; bh=p5znIcmZmTAHCMFdHbMhk2BeUJNYdrPsRrZtGPur4P4=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=nX0EzR7ko8SRFKhe+AJnztrQNTS7omdPOIH4R4k7AsjAJ1O1ps179aCfP3WrhGEvZ yf/gyMPWkN0yIPlZ5CCzdpxkEGQPjxtu5k+g3QggvlyEoTIgRrOPwVUXWtvUl3TzRX 0uGBvRdgDdcVcr4EBegr2dlgpGvIcg8vTKFeI6TdKFDIAEYx24Rz/BVRc1fD8uDS8z OtkkHL2iYsQJKA/70CN69gesIHxFJzPFL4XT73g95VuqIKV5aFJVa2v43GwOnpsOEy B5LCd6BwyOLqmTicy+cqtudnZvYI+60U22Bvo8hVC139Axy/NP1oiyxjJU5eaHbudy EoIDeYb0igdkA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by (ESMTP service) with ESMTP id 49BJZv756nzDq86; Tue, 28 Apr 2020 13:00:23 +0200 (CEST)
From: <>
To: Jon Shallow <>, "" <>
Thread-Topic: [Dots] Telemetry draft: Vendor Specific data reduction
Thread-Index: AQHtT51gUZa45G/WRP2eUjBc2dtf76hfzPjggAAIUDA=
Date: Tue, 28 Apr 2020 11:00:23 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <020a01d61954$64b50320$2e1f0960$> <00a301d61d37$219f1990$64dd4cb0$>
In-Reply-To: <00a301d61d37$219f1990$64dd4cb0$>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330314A0CEDOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Apr 2020 11:00:28 -0000

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.


De : Dots [] De la part de Jon Shallow
Envoyé : mardi 28 avril 2020 10:29
À :
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".



From: Dots [mailto:] On Behalf Of Jon Shallow
Sent: 23 April 2020 10:49
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.