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

mohamed.boucadair@orange.com Wed, 06 May 2020 08:43 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 4EAE33A00AD for <dots@ietfa.amsl.com>; Wed, 6 May 2020 01:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 hxdDufK-2H0i for <dots@ietfa.amsl.com>; Wed, 6 May 2020 01:43:41 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD733A0064 for <dots@ietf.org>; Wed, 6 May 2020 01:43:41 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 49H99Q5RrZz10CC; Wed, 6 May 2020 10:43:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1588754618; bh=0vE7wxPL9V9OVyGBhTpS68UW9gYmsifaSexyguBDw+c=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Tm0U/cfaTHkVB8ab3WLx4qGCG2l20tCZ9+LweNz4Txj2SwVhzVCsUdGIq38Ami07H XP7iW6GfSuHabUil3OohKSMC9kCVn0vTH1tNso4CvU0H2jdHfkSz1biuVef2LBZ1zu NC89ozv4CRSzp2OIr9IhFUBImhfat9kqUid3Y58eZaz7dQMdGzUXh8JMpw4E9GcXnS 4ufPafou9TTeiaa3WFT1MBrlvXURy1l/k9pmrSZLhA49sHq0agOW8oQvGpmwwCEE2C pUh2ddxiUl9U5vlyp7z/0sWQjpEdB2UC65qhgsg9a2xaWVH97okX1NTAAsifDpL/uD Q2wXF36HRLuGg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 49H99Q4K9Rz1xpF; Wed, 6 May 2020 10:43:38 +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+RpAmslRWUBi4S2MAK1mQgLAgiedYICVX/EVAFMNLHJApZBsHgCOgQTJAC9JjJup8T1C3CACs0/cA==
Date: Wed, 6 May 2020 08:43:38 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330314A7C8E@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> <787AE7BB302AE849A7480A190F8B9330314A10FF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <01d301d61d92$94c9c450$be5d4cf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1A69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <02e901d61e06$169244d0$43b6ce70$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1AF9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <031a01d61e13$52554460$f6ffcd20$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1B9C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <035601d61e1d$61d40ca0$257c25e0$@jpshallow.com>
In-Reply-To: <035601d61e1d$61d40ca0$257c25e0$@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_787AE7BB302AE849A7480A190F8B9330314A7C8EOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/7OMH_YEWqrjcRV-KkRsgau9pQAQ>
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: Wed, 06 May 2020 08:43:44 -0000

Hi Jon,

Agree.

I will updated the draft to reflect the outcome of this thread.

Cheers,
Med

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoyé : mercredi 29 avril 2020 13:58
À : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction

Hi Med,

See inline Jon1>

Regards

Jon

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 29 April 2020 12:37
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction

Re-,

The augment to the data channel would be:

  augment /ietf-data:dots-data/ietf-data:dots-client:
    +--rw vendor-mapping {dots-telemetry}?
       +--rw attack-detail* [vendor-id attack-id]
          +--rw vendor-id      uint32
          +--rw attack-id      string
          +--rw attack-name    string
  augment /ietf-data:dots-data/ietf-data:capabilities:
    +--ro vendor-mapping {dots-telemetry}?
       +--ro attack-detail* [vendor-id attack-id]
          +--ro vendor-id      uint32
          +--ro attack-id      string
          +--ro attack-name    string

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoyé : mercredi 29 avril 2020 12:46
À : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction

It is my belief that the client should share the mappings with the server as well, even though the server may actually have the mappings because the server is supplied by the same vendor.
[Med] Not sure to understand the last part of your sentence.

Jon1> If the server and client are provided by the same vendor, then they will both know the vendor-id specific mappings so for the client to send them (or the server to respond to respond with them) is not necessarily needed, but is useful for consistency across all vendors.


There is no harm on the server reporting any differences - there is the possibility that 2 clients have 2 different mitigator release versions though what the client does with the differences (other than log them), I am not sure.
[Med] The mapping is per client, not per domain. A diff can't be interpreted as a conflict.
Jon1> Good thinking - not an issue.  However, the client and server from the same vendor may be on different code releases (or attack matching details) and so there could be a difference (but I would have expected that one of the mappings is a superset of the other, not with any replacements, but there may be local modifications ....).  However, if the client tells the server, the server than updates its local, per client, mapping and only uses that mapping for any reporting etc.  Similarly,  when the client pulls back the server version of the mapping, it updates the active mapping table to use for telemetry being sent by the server, but continues to use the mapping tables it told the server for telemetry from client to server.
~Jon1


Regards

Jon

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 29 April 2020 11:29
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction

Re-,

We need to agree if the client has to share its mappings with the server as well. The use of the data channel would make sense as id/name mapping is similar to the alias handling functionality.

Vendor-id should be a key too.

Cheers,
Med