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

mohamed.boucadair@orange.com Tue, 28 April 2020 15:56 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01533A03EF for <dots@ietfa.amsl.com>; Tue, 28 Apr 2020 08:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWhaYPAMyqkw for <dots@ietfa.amsl.com>; Tue, 28 Apr 2020 08:56:46 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB753A03EE for <dots@ietf.org>; Tue, 28 Apr 2020 08:56:46 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 49BR8q5CCcz1ygN; Tue, 28 Apr 2020 17:56:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1588089403; bh=4+iCWriHFP8TGcJemrx8V76w31L7+JRY0vFyP75ErVI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=V3GiOC8Ji+VoFH8SSWpkjFPPSwwYMgX8Uj2qUhmK3mSxj4XcI6F7LDs+hDiYiAKzg yxZ/KrhEizgW3gXwFOjGx4Xx9peIrU9sSxuDmYqZGACkyUkM8g+UIOL04gS6PVgOF3 6yS52ucFSRponTuOwOLI9iHyoFzT8YOiDBKYmveV+w7iEQxAQXT42JxGk4MQh9dsty 2+1B0Wm57IXa2nPUClRDWMFqbQ2p3G0cqOUSjjFh2XQ2O3ko4KainA0efkoHxtj5Lj 24kCPq5CKgiN4I6T+qAGB84mpVW3ePzE3zZzUxnhrxGMVJNQO77X1AsvKx2aNqfe9I ZqurNJFTBHdPg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 49BR8q4FDGz8sY1; Tue, 28 Apr 2020 17:56:43 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Jon Shallow <supjps-ietf@jpshallow.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] Telemetry draft: Vendor Specific data reduction
Thread-Index: AQHtT51ggH6aH9X9eXlnZao+3cestAGwV+RpAmslRWWoP1QcgIAAFv1Q
Date: Tue, 28 Apr 2020 15:56:42 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330314A10FF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> <00a301d61d37$219f1990$64dd4cb0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <017201d61d6f$e40b75e0$ac2261a0$@jpshallow.com>
In-Reply-To: <017201d61d6f$e40b75e0$ac2261a0$@jpshallow.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330314A10FFOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/0jvM_DXjr9_xEdTFJiEiR1QFWM8>
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Apr 2020 15:56:49 -0000

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:supjps-ietf@jpshallow.com]
Envoyé : mardi 28 avril 2020 17:16
À : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
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: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 28 April 2020 12:00
To: Jon Shallow; dots@ietf.org
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:dots-bounces@ietf.org] De la part de Jon Shallow
Envoyé : mardi 28 avril 2020 10:29
À : dots@ietf.org
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: dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: 23 April 2020 10:49
To: dots@ietf.org
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