Re: [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Interop Testing

mohamed.boucadair@orange.com Wed, 22 April 2020 09:04 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 F2C683A0BEC for <dots@ietfa.amsl.com>; Wed, 22 Apr 2020 02:04:06 -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 WujyQdjJ8uVf for <dots@ietfa.amsl.com>; Wed, 22 Apr 2020 02:04:05 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B073A0BEA for <dots@ietf.org>; Wed, 22 Apr 2020 02:04:05 -0700 (PDT)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 496ZHR2NLgz2xlP; Wed, 22 Apr 2020 11:04:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1587546243; bh=r8cKKDMZ+FtrZ4rsGFfCQAyoQDSDfewbFKyu15dcm70=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=OP2HiwX2kBPASuaOqKuZtOvdxlNizXePnz95PERr3zX0lRq0h8JacfoqocpB5ssK7 WroPHSTNtxt/+dXA+y85BMAk5IqqI2I7R4Eu5zJIbaf1s7w2v9NO7v8cjg2wtPHVrg gPql0LC4PZtfPsxS8apy9TSt+lnXtk7NB9sjBoHI9uuxb4EBfAXSsLAvJ979bLUOyq VCXOESk019n0Dg7HPYJk4N+UjM1fOlyCl71Od8sESWnetsJqZ5dw6JCQV+4UyEiJsz GREesVMtgLYBFPHrT7/gA/Auwy5vP8MTjrrO6UjhVS7aTuuey1Ehq9+ja8wIoxm4f9 inamJg/68h+aw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 496ZHR1RdVz5vNn; Wed, 22 Apr 2020 11:04:03 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: Jon Shallow <supjps-ietf@jpshallow.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Interop Testing
Thread-Index: AdYX0QGihtMaUguYXUgw3qxX+TclMAAs9JbA
Date: Wed, 22 Apr 2020 09:04:02 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93303149C253@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B93303149B4CB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93303149B4CB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303149C253OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/FIfhv96czZbLwUaqfyASM7oCh2o>
Subject: Re: [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Interop Testing
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: Wed, 22 Apr 2020 09:04:07 -0000

Hi Jon,

Here is a text proposal with a warning about the use of these filters:

   DOTS clients may also filter out the asynchronous notifications from
   the DOTS server by indicating a specific source information.  To that
   aim, a DOTS client may include source-prefix, source-port, or source-
   icmp-type in an Uri-Query option.  The same considerations (ranges,
   multiple values) specified for target clauses apply for source
   clauses.  Special care SHOULD be taken when using these filters as
   some attacks may be hidden to the requesting DOTS client (e.g., the
   attack changes its source information).

Do we need to say more?

Cheers,
Med

De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@orange.com
Envoyé : mardi 21 avril 2020 13:36
À : Jon Shallow; dots@ietf.org
Objet : [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Interop Testing

Re-,

Why filtering on the source if all the attack traffic is coming from the same port number?

I'm nervous about setting a filter that may hide useful attack telemetry (not matching that filter).

Cheers,
Med


De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoyé : mardi 21 avril 2020 12:56
À : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing


  Do we need to be able to filter on source attributes as well?
[Med] What would be the usage? Is it the case of an administrator that is aware (using some means) that some sources are involved an attacks on other networks, then sends a request to its server to filter telemetry data bound to these source? Filtering in this case may be problematic as some attacks may be observed but are hidden by the filter on the source. Or do we want to focus on very few talkers? For example, the client would instruct the server to send data only related to the top-talker, 3 first top-talkers, etc.?

Jon> Source-port= could be useful - especially when being subjected to a reflected type attach where all the traffic is coming from, say, source port 53

Jon> Otherwise, it may help to filter on top-talkers, vendor specific attack types etc.

Jon> Which then leads me on to something else.  If we asking for telemetry for 2 (or more) different target IPs and the server is returning vendor specific attack details.  For attack-detail, keyed by attack-id, if the same attack is hitting more than 1 target IP, can I display this information per IP or does it have to be aggregated?