Re: [Dots] DOTS Telemetry: Interop Clarification #3

mohamed.boucadair@orange.com Fri, 26 June 2020 07:52 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 958773A11B3 for <dots@ietfa.amsl.com>; Fri, 26 Jun 2020 00:52:23 -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 lXaaV_BQW69D for <dots@ietfa.amsl.com>; Fri, 26 Jun 2020 00:52:21 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1B13A11A6 for <dots@ietf.org>; Fri, 26 Jun 2020 00:52:21 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 49tTcf6Ycyz8swm; Fri, 26 Jun 2020 09:52:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593157938; bh=b1++HJRComVeCWh2+r50X80wr5Fd9yolepDbfF1N7EY=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=QeCZw1R4nayDX0oZ0Z9ta3WP63cxdYxK8wsvt7OowPa7V2p2fovggyWqou5GlSa4A ThVF5c5aQrwuRGkZQrAOqRXDs4K0drS9VvAtWQt5AFVxAvUHd/2ObOx3H4njV+cXbY BIEN1DrApO+/+n8vr74SODXCfe6uvl23yR+QaLmh3KJThFWp2xcI/ELyxq95xn6He9 ZdZDVa9XTdcPEM7POGp1WEIh+4iWLyEhWdqmfdYvA0p+dC5l7EKOFv5tXqS2OVeRed ePv+bVOq/nhl+01xHPw4sWMMU7sP6VMS9pxWJzXKtpulGh+qVxNJ1VZqbMRzojFcev OWKq6nlc7Tm2g==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 49tTcf5PYMzBrLH; Fri, 26 Jun 2020 09:52:18 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, kaname nishizuka <kaname@nttv6.jp>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: DOTS Telemetry: Interop Clarification #3
Thread-Index: AdZLJzstzanwENMBRvG6m9wslEq8bAAUJqWgAAHUhuAAAQ4R4AABayNQAABwD7AAAB7bgA==
Date: Fri, 26 Jun 2020 07:52:18 +0000
Message-ID: <25557_1593157938_5EF5A932_25557_94_1_787AE7BB302AE849A7480A190F8B9330314E7A8E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <27464_1593113494_5EF4FB96_27464_425_1_787AE7BB302AE849A7480A190F8B9330314E7645@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <SA0PR16MB38388F3CDF8A3298DDEF2543EA930@SA0PR16MB3838.namprd16.prod.outlook.com> <18913_1593151431_5EF58FC7_18913_57_1_787AE7BB302AE849A7480A190F8B9330314E78C0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <SA0PR16MB3838F0878467387C54C8C69BEA930@SA0PR16MB3838.namprd16.prod.outlook.com> <29225_1593156067_5EF5A1E3_29225_308_1_787AE7BB302AE849A7480A190F8B9330314E7A1F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BLAPR16MB38278E86C67891BF1449D78BEA930@BLAPR16MB3827.namprd16.prod.outlook.com>
In-Reply-To: <BLAPR16MB38278E86C67891BF1449D78BEA930@BLAPR16MB3827.namprd16.prod.outlook.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.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330314E7A8EOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/WeK9l0CT-ICzuggvVSw6N5-PrPM>
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #3
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: Fri, 26 Jun 2020 07:52:24 -0000

Re-,

I do agree that having a latest-update leaf in the mapping table is useful (easily detect mismatches). This is something we can add to the data channel extension.

I'm not sure it is useful to send that new attribute in the signal channel as the attack details won' be useful in the lack of the attack description.

I do think that the current wording in the draft is appropriate: (1) agents should ensure they are in sync as much as possible, (2) avoid including the attack details in the signal channel with one exception when an agent detects a synch issue.

==
   When conveying attack details in DOTS telemetry messages (Sections
   7.2, 7.3, and 8), DOTS agents MUST NOT include 'attack-name'
   attribute except if the corresponding attack mapping details were not
   shared with the peer DOTS agent.
==

If there is a message size issue, a dots agent can send the telemetry in separate messages, use the new bloc options, etc.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoyé : vendredi 26 juin 2020 09:27
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka
Cc : dots@ietf.org
Objet : RE: DOTS Telemetry: Interop Clarification #3

Hi Med,

I prefer avoiding the need to send attack description in the DOTS signal channel. One way is to send the attack-id and last-update timestamp so the peer knows whether it has received the latest snapshot or not.

Cheers,
-Tiru

From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
Sent: Friday, June 26, 2020 12:51 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>
Cc: dots@ietf.org
Subject: RE: DOTS Telemetry: Interop Clarification #3


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Re-,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoyé : vendredi 26 juin 2020 08:36
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka
Cc : dots@ietf.org<mailto:dots@ietf.org>
Objet : RE: DOTS Telemetry: Interop Clarification #3

I meant attack mapping details can be sent in the DOTS data channel and no need to use DOTS signal channel.
[Med] Sure. We are not changing this behavior.

The capabilities of a DOTS mitigator cannot be updated dynamically during mitigation that would warrant the need to send the attack-description in the DOTS signal channel during attack mitigation.
[Med] The issue is when the mapping details were updated but the client didn't retrieved the up-to-date list. If an attack occurs, sending the attack-id only won't be useful for the client; hence the need to send also the attack-name if attack-details are included in the telemetry data.

Identifying a new attack requires update to the DOTS mitigator, human-intervention is required to create the attack description and attack-id.
[Med] We are not making assumptions why the mapping details are not in-sync between the client and server.

In short, no need overload DOTS signal channel to send the attack description.
[Med] As you know, the reco we have is to avoid sending attack-name in the signal channel. There are exceptions where the attack-name may be included, though.

-Tiru

From: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Sent: Friday, June 26, 2020 11:34 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com<mailto:TirumaleswarReddy_Konda@McAfee.com>>; kaname nishizuka <kaname@nttv6.jp<mailto:kaname@nttv6.jp>>
Cc: dots@ietf.org<mailto:dots@ietf.org>
Subject: RE: DOTS Telemetry: Interop Clarification #3


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi Tiru,

Not sure to get your comment. Can you please clarify?

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoyé : vendredi 26 juin 2020 07:15
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka
Cc : dots@ietf.org<mailto:dots@ietf.org>
Objet : RE: DOTS Telemetry: Interop Clarification #3

Hi Med,

I don't think the capabilities of the mitigator will get updated dynamically during an active attack to send the new attack details (attack-name) in the DOTS signal channel protocol.

Cheers,
-Tiru

From: Dots <dots-bounces@ietf.org<mailto:dots-bounces@ietf.org>> On Behalf Of mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>
Sent: Friday, June 26, 2020 1:02 AM
To: kaname nishizuka <kaname@nttv6.jp<mailto:kaname@nttv6.jp>>
Cc: dots@ietf.org<mailto:dots@ietf.org>
Subject: [Dots] DOTS Telemetry: Interop Clarification #3


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Re-,

You reported the following in the interim :
==
3."DOTS agents MUST NOT include 'attack-name' attribute except if the corresponding attack mapping details were not shared with the peer DOTS agent". But how can the DOTS server know they're shared or not?
===

This is implementation-specific. The DOTS server may record which version of the mapping table it shared with a DOTS client.

Do you think that we need to include such details in the spec? or do you have mind something else?

Thanks.

Cheers,
Med



_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.