Re: [Dots] DOTS Telemetry

Ehud Doron <EhudD@Radware.com> Tue, 21 February 2017 08:22 UTC

Return-Path: <EhudD@Radware.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 175E8129643 for <dots@ietfa.amsl.com>; Tue, 21 Feb 2017 00:22:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 U-SHloAQ1uvn for <dots@ietfa.amsl.com>; Tue, 21 Feb 2017 00:22:36 -0800 (PST)
Received: from mailout1.radware.com (mailout1.radware.com [192.115.180.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10FCB129416 for <dots@ietf.org>; Tue, 21 Feb 2017 00:22:36 -0800 (PST)
Received: from ILMB1.corp.radware.com ([169.254.1.237]) by ILCAS1.corp.radware.com ([176.200.120.121]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 10:22:33 +0200
From: Ehud Doron <EhudD@Radware.com>
To: 'dots' <dots@ietf.org>
Thread-Topic: DOTS Telemetry
Thread-Index: AdKIYTXgs9jnVMU+R1WnPYyVGJhdZADtHDpQ
Date: Tue, 21 Feb 2017 08:22:32 +0000
Message-ID: <E58182C4A35A8E498E553AD3D33FA0010117191753@ILMB1.corp.radware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [176.200.121.206]
x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-22898.006
x-tm-as-result: No--18.556200-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_E58182C4A35A8E498E553AD3D33FA0010117191753ILMB1corpradw_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/ngMKxpPMCkP3UIr9Nfsm17R3FDs>
Subject: Re: [Dots] DOTS Telemetry
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Feb 2017 08:22:39 -0000

All

My personal thought about the DOT Telemetry  (and I am speaking for myself, not for the other DOTS Telemetry draft authors) is that in order to build a viable anti-DoS service, both NOC / SOC teams at client and server side will definitely need some sort of information about the on-going attack being mitigated. No doubt about that.

When it comes to operations of DDoS attacks, "life can be complicated" in the sense that attacks are not always successfully mitigated and cases of blocking legitimate traffic can be frequent.... Therefore I believe that the so called "Telemetry for Visibility" is mandatory, for some extent. Meaning that information about attacks (whether we call it telemetry or use other terminology) need to be presented to the SOC/NOC teams, and we MUST deal with it as an MVP. I think that what Tiru has suggested in the Signal Channel draft can be a very good starting point.

My concerns are that if such information will not be covered as part of DOTS standard, we will end up with a lot of vendor extensions and other "out of band" proprietary signaling... and I don't think that this is the ultimate goal of IETF in general and in particular for DOTS.

As per the "Telemetry for Mitigation" below, I have some concerns that this part might be more complicated and can tend to be aligned with a specific implementation, thus can be difficult to standardized. Therefore I think that this part can be considered in the future phases of DOTS.

Thanks,
Ehud Doron |  Senior Architect, Radware CTO office | M: +972-54-7575503 | T: +972-72-3917120



From: Ehud Doron
Sent: Thursday, February 16, 2017 4:44 PM
To: 'dots' <dots@ietf.org>
Subject: DOTS Telemetry

All

Following the WG last F2F meeting in Seoul, we would like to elaborate the discussion about the DOTS Telemetry, mainly its general aspects and directives.

Up to now, we have two declarations for DOTS Telemetry:

1.       The DOTS Requirement draft draft-ietf-dots-requirements-03d defines : "DDoS attack telemetry:  Collected behavioral characteristics defining the nature of a DDoS attack. " .

2.       The DOTS Telemetry draft draft-doron-dots-telemetry-00  defines  ""DOTS Telemetry" is defined as the collection of attributes characterizing the actual attacks that have been detected and mitigated. The DOTS Telemetry is an optional set of attributes that can be signaled in the various DOTS protocol messages. The DOTS Telemetry can be optionally sent from the DOTS Client to Server and vice versa.

We are now figuring out the general view on the DOTS Telemetry theme and have mapped two main categorizes of telemetry we believe are most relevant to DOTS:


1.       Telemetry for Visibility - The main objectives of this category is to allow SOC / NOC teams, on both DOTS Client and Server side, to gain visibility on the overall service provided by facilitating the DOTS signaling. As perceptible examples, we can suggest the Mitigation Status requirement (OP-004 from DOTS Requirement draft), attack details, attack BW and PPS, packet / bytes drops and so on.



2.       Telemetry for Mitigation - The main objective of this category is to allow mitigation facilities to improve their detection and mitigation performance. As perceptible examples, we can suggest the Mitigation Efficacy requirement (OP-007 from DOTS Requirement draft), traffic baseline in certain levels and so on.

As part of the WG effort to define the DOTS baseline features (the DOTS MVPs), we would like to get the WG feedbacks about the abovementioned telemetry categories and also about other possible suggested telemetry categories. We encourage group members from both vendors and service providers to bring-in their valuable feedbacks and needs on this matter. It is preferable for us to get feedbacks on the suggested categories as a whole, rather than on a specific telemetry attribute within a specific category.

The main objective is allowing us to be able to direct, and focus, our work on draft-doron-dots-telemetry-00  according the WG directives and needs.

Kindly, we will appreciate any kind of feedbacks,

DOTS Telemetry draft authors