[Dots] Telemetry draft: Vendor Specific data reduction

Jon Shallow <supjps-ietf@jpshallow.com> Thu, 23 April 2020 09:48 UTC

Return-Path: <supjps-ietf@jpshallow.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 4263E3A17F3 for <dots@ietfa.amsl.com>; Thu, 23 Apr 2020 02:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 E05C0LvGqRQN for <dots@ietfa.amsl.com>; Thu, 23 Apr 2020 02:48:52 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C473A17F2 for <dots@ietf.org>; Thu, 23 Apr 2020 02:48:51 -0700 (PDT)
Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1jRYTL-0005Yn-Ex for ietf-supjps-dots@ietf.org; Thu, 23 Apr 2020 10:48:43 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: dots@ietf.org
Date: Thu, 23 Apr 2020 10:48:51 +0100
Message-ID: <020a01d61954$64b50320$2e1f0960$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_020B_01D6195C.C6796B20"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdYZVGSfUZa45G/WRP2eUjBc2dtf7w==
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/_rvaGsCcUP-CcVN4I7cxODK-hxs>
Subject: [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: Thu, 23 Apr 2020 09:48:55 -0000

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